Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 06 6月, 2011 3 次提交
    • S
      ALSA: hda: Virtualize SPDIF out controls · 74b654c9
      由 Stephen Warren 提交于 
      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: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      74b654c9
    • S
      ALSA: hda: Allow multple SPDIF controls per codec · 7c935976
      由 Stephen Warren 提交于 
      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: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      7c935976
    • S
      ALSA: hda: Gate ELD usage only by whether ELD is valid · c3d52105
      由 Stephen Warren 提交于 
      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: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      c3d52105
  3. 03 6月, 2011 4 次提交
  5. 28 5月, 2011 1 次提交
    • L
      ALSA: fix hda AZX_DCAPS_NO_TCSEL quirk check in driver_caps · 46f2cc80
      由 Linus Torvalds 提交于 
      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: NLinus Torvalds <torvalds@linux-foundation.org>
      46f2cc80
  7. 26 5月, 2011 3 次提交
  9. 25 5月, 2011 3 次提交
    • T
      ALSA: hda - Use model=auto for Lenovo G555 · af4ccf4f
      由 Takashi Iwai 提交于 
      The new auto-parser fixes problems on Lenovo G555.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      af4ccf4f
    • S
      ALSA: HDA: Unify HDMI hotplug handling. · 5d44f927
      由 Stephen Warren 提交于 
      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: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      5d44f927
    • T
      ALSA: hda - Force AD1988_6STACK_DIG for Asus M3N-HT Deluxe · 4e60b4f8
      由 Tony Vroon 提交于 
      The microphone input on the back panel (pink connector)
stopped operating correctly after an upgrade from
2.6.35 to 2.6.38; the actual problem manifests itself
as a lack of microphone bias voltage (VREF_HIZ) on
node 0x17.
With AD1988_6STACK_DIG the maximum bias voltage (VREF_80)
is applied and the headset operates correctly.
Signed-off-by: NTony Vroon <tony@linx.net>
Tested-by: NDoug Redlich <pbrigade@nxltech.net>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      4e60b4f8
  11. 24 5月, 2011 3 次提交
  13. 23 5月, 2011 1 次提交
  15. 20 5月, 2011 8 次提交
  17. 19 5月, 2011 1 次提交
  19. 18 5月, 2011 4 次提交
  21. 17 5月, 2011 9 次提交