Bug#660111: [3.0 -> 3.1.8 regression] intel ibexpeak hdmi no sound out
Found the first bad commit. It was the one you suspected all along!
I will submit this issue upstream. Thanks for your invaluable help and demos!
Cheers
Andres
384a48d71520ca569a63f1e61e51a538bedb16df is the first bad commit
commit 384a48d71520ca569a63f1e61e51a538bedb16df
Author: Stephen Warren <swarren@nvidia.com>
Date: Wed Jun 1 11:14:21 2011 -0600
ALSA: hda: HDMI: Support codecs with fewer cvts than pins
The general concept of this change is to create a PCM device for each
pin widget instead of each converter widget. Whenever a PCM is opened,
a converter is dynamically selected to drive that pin based on those
available for muxing into the pin.
The one thing this model doesn't support is a single PCM/converter
sending audio to multiple pin widgets at once.
Note that this means that a struct hda_pcm_stream's nid variable is
set to 0 except between a stream's open and cleanup calls. The dynamic
de-assignment of converters to PCMs occurs within cleanup, not close,
in order for it to co-incide with when controller stream IDs are
cleaned up from converters.
While the PCM for a pin is not open, the pin is disabled (its widget
control's PIN_OUT bit is cleared) so that if the currently routed
converter is used to drive a different PCM/pin, that audio does not
leak out over a disabled pin.
We use the recently added SPDIF virtualization feature in order to
create SPDIF controls for each pin widget instead of each converter
widget, so that state is specific to a PCM.
In order to support this, a number of more mechanical changes are made:
* s/nid/pin_nid/ or s/nid/cvt_nid/ in many places in order to make it
clear exactly what the code is dealing with.
* We now have per_pin and per_cvt arrays in hdmi_spec to store relevant
data. In particular, we store a converter's capabilities in the per_cvt
entry, rather than relying on a combination of codec_pcm_pars and
the struct hda_pcm_stream.
* ELD-related workarounds were removed from hdmi_channel_allocation
into hdmi_instrinsic in order to simplifiy infoframe calculations and
remove HW dependencies.
* Various functions only apply to a single pin, since there is now
only 1 pin per PCM. For example, hdmi_setup_infoframe,
hdmi_setup_stream.
* hdmi_add_pin and hdmi_add_cvt are more oriented at pure codec parsing
and data retrieval, rather than determining which pins/converters
are to be used for creating PCMs.
This is quite a large change; it may be appropriate to simply read the
result of the patch rather than the diffs. Some small parts of the change
might be separable into different patches, but I think the bulk of the
change will probably always be one large patch. Hopefully the change
isn't too opaque!
This has been tested on:
* NVIDIA GeForce 400 series discrete graphics card. This model has the
classical 1:1:1 codec:converter:pcm widget model. Tested stereo PCM
audio to a PC monitor that supports audio.
* NVIDIA GeForce 520 discrete graphics card. This model is the new
1 codec n converters m pins m>n model. Tested stereo PCM audio to a
PC monitor that supports audio.
* NVIDIA GeForce 400 series laptop graphics chip. This model has the
classical 1:1:1 codec:converter:pcm widget model. Tested stereo PCM,
multi-channel PCM, and AC3 pass-through to an AV receiver.
* Intel Ibex Peak laptop. This model is the new 1 codec n converters m
pins m>n model. Tested stereo PCM, multi-channel PCM, and AC3 pass-
through to an AV receiver.
Note that I'm not familiar at all with AC3 pass-through. Hence, I may
not have covered all possible mechanisms that are applicable here. I do
know that my receiver definitely received AC3, not decoded PCM. I tested
with mplayer's "-afm hwac3" and/or "-af lavcac3enc" options, and alsa a
WAV file that I believe has AC3 content rather than PCM.
I also tested:
* Play a stream
* Mute while playing
* Stop stream
* Play some other streams to re-assign the converter to a different
pin, PCM, set of SPDIF controls, ... hence hopefully triggering
cleanup for the original PCM.
* Unmute original stream while not playing
* Play a stream on the original pin/PCM.
This was to test SPDIF control virtualization.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
:040000 040000 894370c6534b1bf03df9a8a8c7d85c2eeffc7555 98cb8a73a0ed46f034e25bd35002930bc22376ef M sound
git bisect log
git bisect start
# bad: [76531d4166fb620375ff3c1ac24753265216d579] Merge branch 'topic/hda' into for-linus
git bisect bad 76531d4166fb620375ff3c1ac24753265216d579
# good: [7d339ae99758bc21033d4a19bcd4f7b55f96e24e] Merge branch 'topic/misc' into for-linus
git bisect good 7d339ae99758bc21033d4a19bcd4f7b55f96e24e
# bad: [39fa84e94a7df64a6ba27669ef98b51994fb6894] ALSA: hda - Simplify EAPD control in patch_realtek.c
git bisect bad 39fa84e94a7df64a6ba27669ef98b51994fb6894
# bad: [096a885494f6b89a9962c6faf18e1c6092e7919c] ALSA: hda - Initialize input-path dynamically in patch_via.c
git bisect bad 096a885494f6b89a9962c6faf18e1c6092e7919c
# bad: [e06e5a297474c8027beffe10541981845ca0c98b] ALSA: hda - Defer mixer element creation to the right time in patch_via.c
git bisect bad e06e5a297474c8027beffe10541981845ca0c98b
# bad: [b4a655e81d4d1d12abc92d29dfb7550e66a08799] ALSA: hda - Judge playback stream from stream id in azx_via_get_position()
git bisect bad b4a655e81d4d1d12abc92d29dfb7550e66a08799
# good: [3aaf898025b1f75f30457e00e890c9f7c43567ab] ALSA: hda: Separate generic and non-generic implementations
git bisect good 3aaf898025b1f75f30457e00e890c9f7c43567ab
# bad: [384a48d71520ca569a63f1e61e51a538bedb16df] ALSA: hda: HDMI: Support codecs with fewer cvts than pins
git bisect bad 384a48d71520ca569a63f1e61e51a538bedb16df
# good: [2def8172c6611f2577260287ebf5dd3b63f7ef55] ALSA: hda: hdmi_eld_update_pcm_info: update a stream in place
git bisect good 2def8172c6611f2577260287ebf5dd3b63f7ef55
Reply to: