Skip to content
  1. Jun 10, 2011
  3. Jun 07, 2011
  5. Jun 06, 2011
    • Stephen Warren's avatar
      ALSA: hda: HDMI: Support codecs with fewer cvts than pins · 384a48d7
      Stephen Warren authored 
      

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: default avatarStephen Warren <swarren@nvidia.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      384a48d7
    • Stephen Warren's avatar
      ALSA: hda: hdmi_eld_update_pcm_info: update a stream in place · 2def8172
      Stephen Warren authored 
      

A future change won't store an entire hda_pcm_stream just to represent
the capabilities of a codec; a custom data-structure will be used. To
ease that transition, modify hdmi_eld_update_pcm_info to expect the
hda_pcm_stream to be pre-initialized with the codec's capabilities, and
to update those capabilities in-place based on the ELD.

Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      2def8172
    • Stephen Warren's avatar
      ALSA: hda: Separate generic and non-generic implementations · 3aaf8980
      Stephen Warren authored 
      

A future change will significantly rework the generic implementation
in order to support codecs with a different number of pins and
converters. Isolate the more custom codec variants from this change by
duplicating the small portions of generic code they share. This
simplifies the later rework of that previously shared code, since we
don't have to consider the more custom codecs, and also prevents
support for those codecs from regressing.

Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3aaf8980
    • Stephen Warren's avatar
      ALSA: hda: Virtualize SPDIF out controls · 74b654c9
      Stephen Warren authored 
      

The SPDIF output controls apply to converter widgets. A future change
will create a PCM device per pin widget, and hence a set of SPDIF output
controls per pin widget, for certain HDMI codecs. To support this, we
need the ability to virtualize the SPDIF output controls. Specifically:

* Controls can be "unassigned" from real hardware when a converter is
  not used for the PCM the control was created for.
* Control puts only write to hardware when they are assigned.
* Controls can be "assigned" to real hardware when a converter is picked
  to support output for a particular PCM.
* When a converter is assigned, the hardware is updated to the cached
  configuration.

Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      74b654c9
    • Stephen Warren's avatar
      ALSA: hda: Allow multple SPDIF controls per codec · 7c935976
      Stephen Warren authored 
      

Currently, the data that backs the kcontrols created by
snd_hda_create_spdif_out_ctls is stored directly in struct hda_codec. When
multiple sets of these controls are stored, they will all manipulate the
same data, causing confusion. Instead, store an array of this data, one
copy per converter, to isolate the controls.

This patch would cause a behavioural change in the case where
snd_hda_create_spdif_out_ctls was called multiple times for a single codec.
As best I can tell, this is never the case for any codec.

This will be relevant at least for some HDMI audio codecs, such as the
NVIDIA GeForce 520 and Intel Ibex Peak. A future change will modify the
driver's handling of those codecs to create multiple PCMs per codec. Note
that this issue isn't affected by whether one creates a PCM-per-converter
or PCM-per-pin; there are multiple of both within a single codec in both
of those codecs.

Note that those codecs don't currently create multiple PCMs for the codec
due to the default HW mux state of all pins being to point at the same
converter, hence there is only a single converter routed to any pin, and
hence only a single PCM.

Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      7c935976
    • Stephen Warren's avatar
      ALSA: hda: Gate ELD usage only by whether ELD is valid · c3d52105
      Stephen Warren authored 
      

It's perfectly valid for an ELD to contain no SADs. This simply means that
only basic audio is supoprted.

In this case, we still want to limit a PCM's capabilities based on the ELD.

History:

* Originally, ELD application was limited solely by sad_count>0, which
  was used to check that an ELD had been read.
* Later, eld_valid was added to the conditions to satisfy.

This change removes the original sad_count>0 check, which when squashed
with the above two changes ends up replacing if (sad_count) with
if (eld_valid).

Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      c3d52105
  7. Jun 03, 2011
  9. Jun 02, 2011
  11. May 28, 2011
    • Linus Torvalds's avatar
      ALSA: fix hda AZX_DCAPS_NO_TCSEL quirk check in driver_caps · 46f2cc80
      Linus Torvalds authored 
      

Commit 9477c58e ("ALSA: hda - Reorganize controller quriks with bit
flags") changed the driver type compares into various quirk bits.
However, the check for AZX_DCAPS_NO_TCSEL got reverted: instead of
clearing TCSEL for chipsets that have that standard capability, it
cleared then when the NO_TCSEL bit was set.

This can lead to noise and repeated sounds - a weird "echo" behavior.
As the comment just above says: "Ensuring these bits are 0 clears
playback static on some HD Audio codecs".  Which is definitely true at
least on my Core i5 Westmere system.

Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      46f2cc80
  13. May 27, 2011
  15. May 26, 2011
  17. May 25, 2011
    • Daniel Mack's avatar
      ALSA: usb-audio: more control quirks for M-Audio FastTrack devices · d5a0bf6c
      Daniel Mack authored 
      

Make use of the freshly introduced methods to re-use standard mixer
handling and add some controls that are hidden but implemented in a
standard conform way on M-Audio's FastTrack devices.

Signed-off-by: default avatarDaniel Mack <zonque@gmail.com>
Original-code-by: default avatarFelix Homann <linuxaudio@showlabor.de>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d5a0bf6c
    • Daniel Mack's avatar
      ALSA: usb-audio: add new quirk type QUIRK_AUDIO_STANDARD_MIXER · 014950b0
      Daniel Mack authored 
      

This quirk type will let the driver assume that there is a standard
mixer on a given interface, or that a specific mixer quirks will handle
the device.

Signed-off-by: default avatarDaniel Mack <zonque@gmail.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      014950b0
    • Daniel Mack's avatar
      ALSA: usb-audio: export snd_usb_feature_unit_ctl · 9e38658f
      Daniel Mack authored 
      

In order to allow quirks functions to hook up to the standard feature
unit op tables, this patch exports a pointer to the struct that is used
internally.

That way, all the code handling the control can be kept private, and
external code can reference the symbol to re-use it.

Signed-off-by: default avatarDaniel Mack <zonque@gmail.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      9e38658f
    • Daniel Mack's avatar
      ALSA: usb-audio: rework add_control_to_empty() · ef9d5970
      Daniel Mack authored 
      

This patch renames add_control_to_empty() to snd_usb_mixer_add_control()
and exports it, so the quirks functions can make use of it.

Also, as "struct mixer_build" is private to mixer.c, rewrite the
function to take an argument of type "struct usb_mixer_interface"
instead.

Signed-off-by: default avatarDaniel Mack <zonque@gmail.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      ef9d5970
    • Daniel Mack's avatar
      ALSA: usb-audio: move assignment of chip->ctrl_intf · 5875c2cb
      Daniel Mack authored 
      

This is needed for upcoming changes to the quirks mechanism.

Signed-off-by: default avatarDaniel Mack <zonque@gmail.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      5875c2cb
    • Takashi Iwai's avatar
      ALSA: hda - Use model=auto for Lenovo G555 · af4ccf4f
      Takashi Iwai authored 
      

The new auto-parser fixes problems on Lenovo G555.

Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      af4ccf4f
    • Stephen Warren's avatar
      ALSA: HDA: Unify HDMI hotplug handling. · 5d44f927
      Stephen Warren authored 
      

This change unifies the initial handling of a pin's state with the code to
update a pin's state after a hotplug (unsolicited response) event. The
initial probing, and all updates, are now routed through hdmi_present_sense.

The stored PD and ELDV status is now always derived from GetPinSense verb
execution, and not from the data in the unsolicited response. This means:

a) The WAR for NVIDIA codec's UR.PD values ("old_pin_detect") can be
   removed, since this only affected the no-longer-used unsolicited
   response payload.

b) In turn, this means that most NVIDIA codecs can simply use
   patch_generic_hdmi instead of having a custom variant just to set
   old_pin_detect.

c) When PD && ELDV becomes true, no extra verbs are executed, because the
   GetPinSense that was previously executed by snd_hdmi_get_eld (really,
   hdmi_eld_valid) has simply moved into hdmi_present_sense.

d) When PD && ELDV becomes false, there is a single extra GetPinSense verb
   executed for codecs where old_pin_detect wasn't set, i.e. some NVIDIA,
   and all ATI/AMD and Intel codecs. I doubt this will be a performance
   issue.

The new unified code in hdmi_present_sense also ensures that eld->eld_valid
is not set unless eld->monitor_present is also set. This protects against
potential invalid combinations of PD and ELDV received from HW, and
transitively from a graphics driver.

Also, print the derived PD/ELDV bits from hdmi_present_sense so the kernel
log always displays the actual state stored, which will differ from the
values in the unsolicited response for NVIDIA HW where old_pin_detect was
previously set.

Finally, a couple of small tweaks originally by Takashi:

* Clear the ELD content to zero before reading it, so that if it's not
  read (i.e. when !(PD && ELDV)) it's in a known state.

* Don't show ELD fields in /proc ELD files when the ELD isn't valid.

The only possibility I can see for regression here is a codec where the
GetPinSense verb returns incorrect data. However, we're already exposed
to that, since that data is used (a) from hdmi_add_pin to set up the
initial pin state, and (b) within snd_hda_input_jack_report to query
a pin's presence value. As such, I don't believe any HW has bugs here.

Includes-changes-by: default avatarTakashi Iwai <tiwai@suse.de>
Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
Acked-by: default avatarWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      5d44f927