[alsa-devel] [PATCH] ASoC: Intel: hdac_hdmi: add Icelake support

[Pierre-Louis Bossart]

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 at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel