[RFC] Fix Kconfigs, make hda link + HDAudio codec optional

[plbossart]

Same work as for SST driver upstream, we have a code dependency that needs to be fixed, otherwise randconfig will complain.

Compile-tested only for now.

[keyonjie]

It will make more sense to me if we can align on these items firstly:

1. what's the dependency of soc codec driver and legacy HDA/HDMI drivers?
   e.g. should we let SND_SOC_HDAC_HDA select SND_HDA_INTEL or SND_HDA_CODEC_REALTEK or SND_HDA_GENERIC?
   should we let SND_SOC_HDAC_HDMI select SND_HDA_CODEC_HDMI(I believe we don't need this)?

2. in SOF driver, should we select HDA/HDMI support manually, or select them automatically once specific machine driver(sound/soc/intel/boards/xxx) is selected?
   I prefer the latter one, which is more friendly to user IMO, you only need to select SOF and the machine/board you are running, don't need to know HDA Links specific so won't forget to select that.
   Another benefit with the latter solution is, we won't select HDA/HDMI support on machines/boards where customers don't want them.

3. For generic/nocodec fallback machine driver, should we select all HDA/HDMI items?
   The ideal solution to me is that we can detect all of them one by one, e.g. if codec_mask has HDA, then register HDA Analog/Digital BE dai_links, if codec_mask has iDisp, then register iDisp BE dai_links, if bus->ppcap!=NULL, then register SSP dummy BE dai_links, ...

After all those are clarified, maybe we can define less SOF_HDA_xxx items, and make life easier.

[RanderWang]

It is good to me. And I discuss with keyon, can we remove SST and legacy HDA when SOF is selected.
If SST or legacy HDA is selected, SOF can't work. This is another thing.

[plbossart]

@keyonjie The Kconfigs are based on the platform drivers first. You select which SOC you want support for. Then you have a second choice for machine drivers, based on the initial selection of SOCs. You do not select machines first, and then try to reverse-engineer what configs are needed for the platform side. I spend a considerable amount of time last year to make sure we have a hierarchical definition of configurations, we are not going back on this.

I don't understand your point #1. The selection of legacy codec driver is independent from the SOF choices. And if you look at the hdaudio-codecs-defconfig you'll see that they are all manually added. I have no way of knowing which codecs are needed or not since it's a run-time information.

For point #2, we have to change the intel/boards Kconfig so that machine drivers that require HDMI are only selected when the platform side enables HDMI. This is missing from the patchset but I wanted to align first on the platform side. Note that unless the machine driver has conditional support for HDMI (as I did for bxt_pcm512x), you will include/remove machines that need HDMI unconditionally. We cannot make magic at the Kconfig level, the machine driver code itself needs to support more granularity if this is desired.

For the point #3, I already filed an issue on this. We have a chicken-and-egg problem in that the machine selection is made before we know if there is any actual HDaudio codec, so until this is fixed all these discussions on fallback are academic. If you want nocodec support you have to disable HDaudio for now.

@RanderWang no we cannot add a mutually exclusive SOF vs. SST condition, for the simple reason that some distributions will take SST for SKL, KBL, APL but SOF for GLK. We may need to add more granularity in the SST driver but that's a different story. For now, you have to deal with this using sof-defconfig or sst-defconfig which guarantee that you will have no collision.

[plbossart]

@keyonjie See last update with better handling of HDMI dependencies based on what SOF supports.

[keyonjie]

the code change looks almost fine to me except questions about the HDAC_HDMI missing and necessity of SOF_HDA_LINK for cnl-rt274.

[keyonjie]

We don't have HDMI BE dai_links in cnl_rt274.c now so no need this adding?

[plbossart]

We don't have HDMI BE dai_links in cnl_rt274.c now so no need this adding?

Ah yes, this was added in a prototype code. Will remove all this anyways.

[keyonjie]

@keyonjie The Kconfigs are based on the platform drivers first. You select which SOC you want support for. Then you have a second choice for machine drivers, based on the initial selection of SOCs. You do not select machines first, and then try to reverse-engineer what configs are needed for the platform side. I spend a considerable amount of time last year to make sure we have a hierarchical definition of configurations, we are not going back on this.

OK, then we are aligned on this, select platforms first, then machines.

I don't understand your point #1. The selection of legacy codec driver is independent from the SOF choices. And if you look at the hdaudio-codecs-defconfig you'll see that they are all manually added. I have no way of knowing which codecs are needed or not since it's a run-time information.

I was wondering if possible to select hdaudio codecs via dependency as some people are missing this and then reporting that HDaudio doesn't work on SOF.
Your reply already clarified to me about that, so this is also aligned, people need to select that manually, or follow hdaudio-codecs-defconfig.

For point #2, we have to change the intel/boards Kconfig so that machine drivers that require HDMI are only selected when the platform side enables HDMI. This is missing from the patchset but I wanted to align first on the platform side. Note that unless the machine driver has conditional support for HDMI (as I did for bxt_pcm512x), you will include/remove machines that need HDMI unconditionally. We cannot make magic at the Kconfig level, the machine driver code itself needs to support more granularity if this is desired.

OK, that makes sense to me.

For the point #3, I already filed an issue on this. We have a chicken-and-egg problem in that the machine selection is made before we know if there is any actual HDaudio codec, so until this is fixed all these discussions on fallback are academic. If you want nocodec support you have to disable HDaudio for now.

I think hda_codec_probe_bus() happens before we creating machine platform device, so we still have choice to choose machine driver based on the existence of actual HDaudio codec.

[plbossart]

I think hda_codec_probe_bus() happens before we creating machine platform device, so we still have choice to choose machine driver based on the existence of actual HDaudio codec.

That's not what I see in sof-pci-dev. We first select the machine, then create the sof-audio platform device.

[keyonjie]

I think hda_codec_probe_bus() happens before we creating machine platform device, so we still have choice to choose machine driver based on the existence of actual HDaudio codec.

That's not what I see in sof-pci-dev. We first select the machine, then create the sof-audio platform device.

We select matched machine in sof-pci-dev.c:sof_pci_probe(), but create machine platform device at sof/core.c:sof_probe(), after hda_dsp_probe() is finished and FW booted, so here we have chance to change/configure machine driver according to the result of hda-codec existence.

[plbossart]

We select matched machine in sof-pci-dev.c:sof_pci_probe(), but create machine platform device at sof/core.c:sof_probe(), after hda_dsp_probe() is finished and FW booted, so here we have chance to change/configure machine driver according to the result of hda-codec existence.

Not sure how it would work, the sof::sof_probe also creates the PCM platform device which will load the topology, so it's too late to fall back to nocodec....Not to mention that the soc_acpi machine structure does not contains read-only parts only, so it's hard to change on the fly.

[keyonjie]

We select matched machine in sof-pci-dev.c:sof_pci_probe(), but create machine platform device at sof/core.c:sof_probe(), after hda_dsp_probe() is finished and FW booted, so here we have chance to change/configure machine driver according to the result of hda-codec existence.

Not sure how it would work, the sof::sof_probe also creates the PCM platform device which will load the topology, so it's too late to fall back to nocodec....Not to mention that the soc_acpi machine structure does not contains read-only parts only, so it's hard to change on the fly.

Actually, the topology is loaded late(after FW booted), hda_dsp_probe() finished before that, we have enough time to do that, we don't need to change the matched machine itself(so don't need to care if it is read only), we only need to change the pointer plat_data->machine to point to another machine.