Hi Takashi,
So, with a working machine, I could finally hack this a bit. Below is a freshly cooked patch(set). The first one is just to add the support for my CFL machine, and another one is to add the fallback binding with the legacy HD-audio on snd-soc-skl. The changes aren't that big. And you can still control the binding via a module option, e.g. snd_soc_skl.legacy=1 will let it bound only with the legacy driver, snd_soc_skl.legacy=2 for ASoC only. The default is 0, the fallback to legacy if ASoC binding fails. It's still a PoC, no proper patch description is put yet.Thanks Takashi, much appreciate. will give it a try later today.
One comment is that we will have to deal with SOF as well. While the end-goal is to converge on a single SOF-based driver, it'll take time to support all shipping platforms and deal with firmware authentication issues, so the fallback could be SOF->SST->legacy (hopefully on a small set of platforms). SST->SOF will likely never happen.
OK, good to know.
I also wanted to try what happens with your solution if the authentication fails with SST (as in your case with the current CNL firmware). It's my understanding that the firmware download is deferred with a work queue and takes time anyways, so maybe the decision not to go back to legacy would be made too early? We'd also need to check with a platform where the DSP is not enabled to see if the fallback happens immediately (no need to try and download firmware to a non-enabled DSP).
It's a good question, and I guess it's hard to give a fallback in that level. IOW, the fallback to the legacy is only for the case where no DSP is available at all in the hardware level. If the legacy driver is required by some reason (faulty hardware detection or the non-public firmware), we can still enforce to the legacy mode via a module option.
But for the fallback of SOF to SST is a different question. I guess we should check the availability of the firmware at the beginning of probe? But request_firmware() inside the probe is basically no-go (although it might work), so the fallback point would be pushed later in that case.
Even my simple PoC has a potential problem: as it doesn't reach to the probe error in the driver core, the previously called devres and other stuff aren't cleared at calling the fallback driver. This problem will remain even if we change the fallback place, so this needs to be solved (or just ignore if it's only a few memory allocations).
I took a longer look at the suggested code, and it's good enough for me - actually smarter than what I had in mind :-).
What we really want is detect if the DSP is present or not, and fall back to legacy if not.
The problems with firmware are one step too far, there are cases where we have firmware but it's the wrong one due to authentication issues that cannot be handled automagically.
Likewise the fallback between SOF and SST is also one bridge too far. If the problem is with firmware authentication, then likewise it's something that needs to be sorted out by Intel releasing the correct firmware and/or users selecting a different firmware which is specific to their platforms.
Also the SST driver depends on topology files that have not been shared in most cases, so a generic distribution that doesn't have access to all the parts would just not work. It's just simpler to select what is known to work (e.g. legacy until KBL, SST after), and gradually deprecate the SST driver as both features and topologies are provided with SOF.
You have a good point on the allocations, but if we modify the skylake driver to only allocate all the resources if the DSP is present, then it's only a couple of structures that matter. Today the test
/* check if dsp is there */ if (bus->ppcap) {
in skl.c is done too late, there is no point in e.g allocating DMA pages and stuff if the DSP is not there is the first place...
And while I am at it, we may want to think about a single table for PCI IDs so that by construction we remove the risk of a platform supported with legacy but not the others, and vice versa.
It's also what I thought, too, but it turned out to be difficult because both drivers require the own driver_data field.
Yes agree. I think we can have a more granular approach though, it's simple enough to change the Skylake driver and select SKL/APL/GLK/KBL independently (as we do for SOF), so we could do this fallback on an SOC basis, e.g something like:
/* Sunrise Point-LP */ { PCI_DEVICE(0x8086, 0x9d70), .driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE | IS_ENABLED(CONFIG_SND_HDA_INTEL_SKL_SHARED) & AZX_DCAPS_INTEL_SHARED },
with SND_HDA_INTEL_SKL_SHARED selected by the SKL driver.
this would scale well with SOF as well.
Thanks for starting this POC, much appreciated.
-Pierre