Messages in this thread | | | Date | Sun, 30 Dec 2018 10:21:04 +0100 | From | Takashi Iwai <> | Subject | Re: [GIT PULL] sound updates for 4.21 |
| |
On Fri, 28 Dec 2018 20:04:48 +0100, Linus Torvalds wrote: > > On Fri, Dec 28, 2018 at 9:07 AM Takashi Iwai <tiwai@suse.de> wrote: > > > > 1) Whether ASoC driver cannot work with these Dell machines at all > > I'm willing to test patches. > > Right now, the reason it fails to even load is that "codec_mask" is 0x0001. > > And the skl_hda_dsp_generic.c code requires > > // This will be 1 for 0x0001 > codec_count = hweight_long(codec_mask); > > if (codec_count == 1 && codec_mask & IDISP_CODEC_MASK) { > .. this is ok .. > } else if (codec_count == 2 && codec_mask & IDISP_CODEC_MASK) { > .. as is this .. > } else { > .. but here we return -EINVAL; > } > > and that basically requires that IDISP_CODEC_MASK be part of > codec_mask. Which it isn't (IDISP_CODEC_MASK is 0x4). > > Anyway, as long as the ASoC driver refuses to touch this, the default > pretty much *has* to be the legacy PCI driver.
Thanks, the above seems to be the likely cause.
This is a good news and a bad news, actually. The good news is that we know the cause, and this can be detected earlier, too. The bad news is that the possible detection (the probe of codec mask) is done in an async probe work in the legacy HDA driver, hence the PCI driver probe() call cannot return -ENODEV for this.
And, it brings me a question: does the audio routing work without iDISP at all? The current code looks mandating the iDISP, and I thought this is a core part of HD-audio routing on DSP.
Intel people, could you clarify this?
If iDISP is mandatory and really missing on these machines, we need another way to identify such systems without codec mask checks. Maybe DMI or such listing; ugly but should be still manageable since the number of devices hitting the problem must be fairly low.
Or, an alternative is to let ASoC driver bind at first, e.g. by changing the driver name from snd-soc-skl to snd-hda-asoc, and drop the selective binding from snd-hda-intel, so that it'd work as catch-all after binding with ASoC fails.
The above would work for the modules, but for built-in, we need to rearrange the link order, too, supposedly. (For the mixed case with built-in and module? I don't know, maybe we may forgive us by the presence of module options to control the binding.)
BTW, one thing I'd really like to avoid is to rearrange the probe procedure of the legacy HDA driver (so that we can get codec_mask during pci probe() call). The async probe is the result of the many struggles with the various and complex configurations. Moving the codec probe to the beginning isn't trivial and quite risky to break something else.
thanks,
Takashi
| |