Regression due to 6169b673618b "ALSA: hda - Always turn on pins for HDMI/DP"

Regression due to 6169b673618b "ALSA: hda - Always turn on pins for HDMI/DP"

[Stephen Warren]

Takashi,

It looks like commit 6169b673618b "ALSA: hda - Always turn on pins for
HDMI/DP" has caused a regression on NVIDIA graphics cards. It's been
reported to us by at least two separate users.

On NVIDIA GPUs, it appears that if multiple pin complex widgets have
their input mux set to the same audio output widget and PIN_OUT, then
only one of the pin complex widgets will actually receive the audio.
That's the reason we need to dynamically toggle PIN_OUT on and off, so
that only actually active pin complex widgets are enabled. Without this,
audio will be routed to the same pin complex all the time, rather than
the user-selected device. I'm not sure if this is the way HDA CODECs are
meant to work, but it certainly is how they do work:-)

So, I'd like to basically revert 6169b673618b "ALSA: hda - Always turn
on pins for HDMI/DP", and return the code to the state it was after
commit 384a48d71520 "ALSA: hda: HDMI: Support codecs with fewer cvts
than pins". However, I obviously don't want to re-introduce the
regression that your commit solved. I think we should solve this by
including the code for both behaviours in the kernel, and having either
a flag in struct hdmi_spec, or some extra ops in struct hdmi_ops, select
between the two paths. Does that seem reasonable?

If so, the only remaining question is: which behaviour should be default
a/k/a should I blacklist the problematic GM965 (mentioned in
https://bugzilla.kernel.org/show_bug.cgi?id=51421) against having the
dynamic PIN_OUT behaviour, or whitelist NVIDIA GPUs as requiring the
dynamic PIN_OUT behaviour? I know that my patch worked fine on my wife's
Intel chipset, but I have no idea if the dynamic PIN_OUT behaviour was
actually needed there, or simply tolerated, and I have no way to test
much aside from NVIDIA GPUs. That all said, the dynamic PIN_OUT
behaviour seems to make most sense to me, or some systems may end up
with audio being sent to multiple outputs when only one was expected.

Re: Regression due to 6169b673618b "ALSA: hda - Always turn on pins for HDMI/DP"

[Takashi Iwai]

At Wed, 29 Jan 2014 16:34:11 -0700,
Stephen Warren wrote:
> 
> Takashi,
> 
> It looks like commit 6169b673618b "ALSA: hda - Always turn on pins for
> HDMI/DP" has caused a regression on NVIDIA graphics cards. It's been
> reported to us by at least two separate users.
> 
> On NVIDIA GPUs, it appears that if multiple pin complex widgets have
> their input mux set to the same audio output widget and PIN_OUT, then
> only one of the pin complex widgets will actually receive the audio.
> That's the reason we need to dynamically toggle PIN_OUT on and off, so
> that only actually active pin complex widgets are enabled. Without this,
> audio will be routed to the same pin complex all the time, rather than
> the user-selected device. I'm not sure if this is the way HDA CODECs are
> meant to work, but it certainly is how they do work:-)

AFAIK, there is no concrete definitions.

> So, I'd like to basically revert 6169b673618b "ALSA: hda - Always turn
> on pins for HDMI/DP", and return the code to the state it was after
> commit 384a48d71520 "ALSA: hda: HDMI: Support codecs with fewer cvts
> than pins". However, I obviously don't want to re-introduce the
> regression that your commit solved. I think we should solve this by
> including the code for both behaviours in the kernel, and having either
> a flag in struct hdmi_spec, or some extra ops in struct hdmi_ops, select
> between the two paths. Does that seem reasonable?

Yes, that's a good option.  I don't mind either way.

> If so, the only remaining question is: which behaviour should be default
> a/k/a should I blacklist the problematic GM965 (mentioned in
> https://bugzilla.kernel.org/show_bug.cgi?id=51421) against having the
> dynamic PIN_OUT behaviour, or whitelist NVIDIA GPUs as requiring the
> dynamic PIN_OUT behaviour? I know that my patch worked fine on my wife's
> Intel chipset, but I have no idea if the dynamic PIN_OUT behaviour was
> actually needed there, or simply tolerated, and I have no way to test
> much aside from NVIDIA GPUs. That all said, the dynamic PIN_OUT
> behaviour seems to make most sense to me, or some systems may end up
> with audio being sent to multiple outputs when only one was expected.

My vote is to apply the dynamic PIN_OUT only for Nvidia.
AMD devices have been tested with the recent kernels, so they should
be no problem with static PIN_OUT setting.  Some Intel chip seem to
mandate it.  And the rest devices have no multiple pins, in anyway :)

Could you care the fix patch?


thanks,

Takashi