1. 02 4月, 2013 1 次提交
  2. 20 2月, 2013 2 次提交
  3. 10 4月, 2012 1 次提交
  4. 14 3月, 2012 1 次提交
    • A
      ALSA: hda - fix printing of high HDMI sample rates · 25dc16f6
      Anssi Hannula 提交于
      A previous commit af65cbf2 (ALSA: hdmi: fix printout of SAD sampling
      rates) fixed the sample rates shown in /proc/asound/cardX/eldY and
      kernel log to not be entirely wrong. However, a missing rate from the
      array added in the patch causes HDMI rates 88.2 kHz, 96 kHz, 176.4 kHz,
      and 192 kHz to be shown as 96 kHz, 176.4 kHz, 192 kHz, and 384 kHz,
      respectively.
      
      Fix the reporting by adding the ALSA rate 64 kHz into the conversion
      array between 48 kHz and 88.2 kHz.
      Signed-off-by: NAnssi Hannula <anssi.hannula@iki.fi>
      Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Cc: stable@kernel.org
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      25dc16f6
  5. 22 11月, 2011 1 次提交
  6. 16 11月, 2011 2 次提交
  7. 06 10月, 2011 2 次提交
  8. 03 10月, 2011 1 次提交
    • P
      ALSA: hda/hdmi: expose ELD control · 14bc52b8
      Pierre-Louis Bossart 提交于
      Applications may want to read ELD information to
      understand what codecs are supported on the HDMI
      receiver and handle the a-v delay for better lip-sync.
      
      ELD information is exposed in a device-specific
      IFACE_PCM kcontrol. Tested both with amixer and
      PulseAudio; with a corresponding patch passthrough modes
      are enabled automagically.
      
      ELD control size is set to zero in case of errors or
      wrong configurations. No notifications are implemented
      for now, it is expected that jack detection is used to
      reconfigure the audio outputs.
      Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      14bc52b8
  9. 20 8月, 2011 1 次提交
    • T
      ALSA: hda - Don't spew too many ELD errors · b6acf013
      Takashi Iwai 提交于
      Currently HD-audio driver shows the all error ELD byte as an error
      in the kernel message.  This is annoying when the video driver doesn't
      set the correct ELD from the beginning. e.g. radeon sends a zero-byte
      data, but we still check ELD with the fixed 128 byte as a workaround
      for some broken devices, it spews 128-times errors.
      
      For avoiding this, the driver aborts reading when the first byte is
      invalid.  In such a case, the whole data is certainly invalid.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      b6acf013
  10. 29 6月, 2011 1 次提交
    • W
      ALSA: HDMI - fix ELD monitor name length · f5b2d0ef
      Wu Fengguang 提交于
      I noticed that the last character of the ELD monitor name is lost,
      this fixes the issue.
      
      This fix should be confirming to the HDA spec, and works together with
      the DRM part of the ELD patch.
      
      The HDA spec does not mention that Monitor_Name_String is an '\0'
      ending string, and it allows NML to be 1, which is only valid when MNL
      does not count the possible ending '\0'.
      Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      f5b2d0ef
  11. 06 6月, 2011 1 次提交
  12. 25 5月, 2011 1 次提交
    • 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
  13. 26 1月, 2011 1 次提交
  14. 08 12月, 2010 3 次提交
    • A
      ALSA: hda - Reset sample sizes and max bitrates when reading ELD · 0bbaee3a
      Anssi Hannula 提交于
      When a new HDMI/DP device is plugged in, hdmi_update_short_audio_desc()
      is called for every SAD (Short Audio Descriptor) in the ELD data. For
      LPCM coding type SAD defines the supported sample sizes. For several
      other coding types (such as AC-3), a maximum bitrate is defined.
      
      The maximum bitrate and sample size fields are not always cleared.
      Therefore, if a device is unplugged and a different one is plugged in,
      and the coding types of some SAD positions differ between the devices,
      the old max_bitrate or sample_bits values will persist if the new SADs
      do not define those values.
      
      The leftover max_bitrate and sample_bits do not cause any issues other
      than wrongly showing up in eld#X.Y procfs file and kernel log.
      
      Fix that by always clearing sample_bits and max_bitrate when reading
      SADs.
      Signed-off-by: NAnssi Hannula <anssi.hannula@iki.fi>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      0bbaee3a
    • A
      ALSA: hda - Always allow basic audio irrespective of ELD info · 3dc86429
      Anssi Hannula 提交于
      Commit bbbe3390 added functionality to restrict PCM parameters
      based on ELD info (derived from EDID data) of the audio sink.
      
      However, according to CEA-861-D no SAD is needed for basic audio
      (32/44.1/48kHz stereo 16-bit audio), which is instead indicated with a
      basic audio flag in the CEA EDID Extension.
      
      The flag is not present in ELD. However, as all audio capable sinks are
      required to support basic audio, we can assume it to be always
      available.
      
      Fix allowed audio formats with sinks that have SADs (Short Audio
      Descriptors) which do not completely overlap with the basic audio
      formats (there are no reports of affected devices so far) by always
      assuming that basic audio is supported.
      Reported-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NAnssi Hannula <anssi.hannula@iki.fi>
      Cc: stable@kernel.org
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      3dc86429
    • A
      ALSA: hda - Do not wrongly restrict min_channels based on ELD · 4b0dbdb1
      Anssi Hannula 提交于
      Commit bbbe3390 added functionality to restrict PCM parameters
      based on ELD info (derived from EDID data) of the audio sink.
      
      However, it wrongly assumes that the bits 0-2 of the first byte of
      CEA Short Audio Descriptors mean a supported number of channels. In
      reality, they mean the maximum number of channels (as per CEA-861-D
      7.5.2). This means that the channel count can only be used to restrict
      max_channels, not min_channels.
      
      Restricting min_channels causes us to deny opening the device in stereo
      mode if the sink only has SADs that declare larger numbers of channels
      (like Primare SP32 AV Processor does).
      
      Fix that by not restricting min_channels based on ELD information.
      Signed-off-by: NAnssi Hannula <anssi.hannula@iki.fi>
      Reported-by: NJean-Yves Avenard <jyavenard@gmail.com>
      Tested-by: NJean-Yves Avenard <jyavenard@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      4b0dbdb1
  15. 20 9月, 2010 1 次提交
    • T
      ALSA: hda - Merge all HDMI modules into the unified module · 84eb01be
      Takashi Iwai 提交于
      This patch merges all three patch_*hdmi variants to the single HDMI
      parser.  There is only one snd-hda-codec-hdmi module now.
      
      In this patch, the behavior of each parser isn't changed much.
      The old ATI parser still doesn't use the dynamic parser yet.
      In later patches, they'll be cleaned up.
      
      Also, this patch gets rid of the individual snd-hda-eld module and
      builds into snd-hda-codec-hdmi, since this is referred only from the
      HDMI parser.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      84eb01be
  16. 19 8月, 2010 1 次提交
  17. 13 8月, 2010 1 次提交
    • T
      ALSA: hda - Restrict PCM parameters per ELD information over HDMI · bbbe3390
      Takashi Iwai 提交于
      When a device is plugged over HDMI, it passes some information in ELD
      including the supported PCM parameters like formats, rates, channels.
      This patch adds the check to PCM open callback of HDMI streams so that
      only valid parameters the device supports are used.
      
      When no device is plugged, the parameters the codec supports are used;
      it's mostly all parameters the hardware can work.  This is for apps
      that are started before device plugging and do probing (e.g. a sound
      daemon), so that at least, probing would work even before the device
      plugging.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      bbbe3390
  18. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  19. 04 3月, 2010 1 次提交
  20. 18 11月, 2009 2 次提交
  21. 30 10月, 2009 1 次提交
    • W
      ALSA: hda - vectorize intelhdmi · 54a25f87
      Wu Fengguang 提交于
      The Intel IbexPeak HDMI codec supports 2 converters and 3 pins,
      which requires converting the cvt_nid/pin_nid to arrays.
      
      The active pin number (the one connected with a live HDMI monitor/sink)
      will be dynamically identified on hotplug events.
      
      It exports two HDMI devices, so that user space can choose the A/V pipe
      for sending the audio samples.
      
      It's still undefined behavior when there are two active monitors
      connected and routed to the same audio converter.
      Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      54a25f87
  22. 29 7月, 2009 1 次提交
  23. 22 11月, 2008 4 次提交
  24. 21 11月, 2008 4 次提交
  25. 19 11月, 2008 4 次提交