Attachment 68467 Details for Bug 55556 – Bad commit, full description

Bad commit, full description

bad_commit.txt (text/plain), 4.49 KB, created by Charles Lahaine on 2012-10-12 02:44:04 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Charles Lahaine

Created: 2012-10-12 02:44:04 UTC

Size: 4.49 KB

patch

obsolete

>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

Actions: View

Attachments on bug 55556: 68010 | 68012 | 68013 | 68014 | 68067 | 68467 | 68468 | 68767 | 71493

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.