On 11/16/18 7:49 AM, Takashi Iwai wrote:
On Wed, 14 Nov 2018 15:53:23 +0100, Takashi Iwai wrote:
On Mon, 12 Nov 2018 15:00:36 +0100, Pierre-Louis Bossart wrote:
And btw the big topic is still how we provide distributions the means to handle a 'graceful' fallback from DSP-enabled solutions (SST or SOF) to legacy HDAudio, it's already popped up for cases where we have HDaudio solutions with DMICs.
Yeah, that's a long-standing problem. I've experimented some scenarios in the past, and the conclusion is that there is no really working fallback mechanism in general in Linux driver binding. That is, the only reasonable way seems to make a dedicated driver for the specific PCI ID (SKL+) doing the probe-and-fallback by itself, while excluding these IDs from other existing driver entries.
I'd love to proceed this but unfortunately I have no machine that can run SKL+ SST driver right now. I have a new CFL devel box, but it has no support (PCI ID 8086:a348) as well as no firmware...
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.
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).
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.
Just my 2 cents before coffee.
Comments / suggestions appreciated.
thanks,
Takashi
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel