1. 10 1月, 2011 4 次提交
  2. 30 12月, 2010 2 次提交
  3. 23 12月, 2010 5 次提交
  4. 21 12月, 2010 3 次提交
  5. 20 12月, 2010 5 次提交
  6. 17 12月, 2010 5 次提交
  7. 15 12月, 2010 2 次提交
  8. 14 12月, 2010 1 次提交
  9. 13 12月, 2010 1 次提交
  10. 09 12月, 2010 7 次提交
  11. 08 12月, 2010 5 次提交
    • D
      ALSA: HDA: Remove unconnected PCM devices for Intel HDMI · 116dcde6
      David Henningsson 提交于
      Some newer chips have more than one HDMI output, but usually not
      all of them are exposed as physical jacks. Removing the unused
      PCM devices (as indicated by BIOS in the pin config default) will
      reduce user confusion as they currently have to choose between
      several HDMI devices, some of them not working anyway.
      Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      116dcde6
    • T
      Merge branch 'fix/hda' into topic/hda · d0fa15e0
      Takashi Iwai 提交于
      d0fa15e0
    • 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