Hi,
On 12/31/18 9:10 PM, Pierre-Louis Bossart wrote:
On 12/31/18 12:15 PM, Takashi Iwai wrote:
On Mon, 31 Dec 2018 11:24:41 +0100,
Pierre-Louis Bossart wrote:
On 12/31/18 2:11 AM, Takashi Iwai wrote:
On Mon, 31 Dec 2018 00:17:58 +0100,
Pierre-Louis Bossart wrote:
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.
Agree, mucking with the probe isn't something we should look into,
especially with this Skylake driver being eventually deprecated once
SOF is at feature parity. This set of autodetection patches for 4.21
was really targeting CFL/WHL+ devices, where the DSP usage is
mandatory when directly-attached digital microphones are used. For
Skylake and kabylake using the legacy by default is just fine.
OK, then how about applying the PCI class check only for such ones
like the patch below? The macro isn't sexy and can be replaced with
another way, but you have an idea.
The two patches which added the PCI class checks were supposed to be a
simple bullet-proof way of detecting the DSP presence and solving a
problem of coexistence between two drivers. At this point if we start
adding quirks and still have unclear issues with HDMI support which
isn't different for CFL+, it may be wiser to revert them to let the
4.21 merge window progress? It's frustrating but I'd rather solve this
problem the right way than with multiple iterations rushed because of
the merge window timing.
Fair enough, let's revert them for now. I'm going to submit the
revert patch.
Thanks Takashi. If everyone who has been impacted by this issue can send me
privately the result of the following two commands it'd help us figure out
which machines expose the DSP - we may ask for additional information, e.g.
NHLT tables. We clearly need to widen the validation scope since there is
obviously a disconnect between what 3rd party BIOS expose and the technical
consensus within Intel audio teams. Thanks in advance for your time.
-Pierre
On my Apollo Lake laptop which is also affected by this:
lspci -s 0:1f.3 -vn
00:0e.0 0403: 8086:5a98 (rev 0b) (prog-if 80)
Subsystem: 10ec:111a
Flags: bus master, fast devsel, latency 0, IRQ 128
Memory at 91218000 (64-bit, non-prefetchable) [size=16K]
Memory at 91000000 (64-bit, non-prefetchable) [size=1M]
Capabilities: <access denied>
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel, snd_soc_skl
more /sys/bus/pci/devices/0000\:00\:1f.3/class (should return 0x040100 or
0x040380, if the value is 0x040300 then the DSP is not exposed)
0x040380
Regards,
Hans
