1. 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
  2. 06 12月, 2010 1 次提交
  3. 05 12月, 2010 1 次提交
  4. 04 12月, 2010 1 次提交
  5. 03 12月, 2010 5 次提交
  6. 02 12月, 2010 1 次提交
  7. 30 11月, 2010 1 次提交
  8. 29 11月, 2010 2 次提交
  9. 27 11月, 2010 1 次提交
  10. 25 11月, 2010 1 次提交
  11. 24 11月, 2010 2 次提交
  12. 23 11月, 2010 4 次提交
  13. 22 11月, 2010 11 次提交
  14. 19 11月, 2010 1 次提交
  15. 18 11月, 2010 4 次提交
    • J
      ASoC: Add support for MAX98089 CODEC · fb762a5b
      Jesse Marroquin 提交于
      This patch adds initial support for the MAX98089 CODEC.
      Signed-off-by: NJesse Marroquin <jesse.marroquin@maxim-ic.com>
      Acked-by: NLiam Girdwood <lrg@slimlogic.co.uk>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      fb762a5b
    • C
      ASoC: davinci: fixes for multi-component · bedad0ca
      Chris Paulson-Ellis 提交于
      Multi-component commit f0fba2ad broke a few things which this patch should
      fix. Tested on the DM355 EVM. I've been as careful as I can, but it would be
      good if those with access to other Davinci boards could test.
      
      --
      
      The multi-component commit put the initialisation of
      snd_soc_dai.[capture|playback]_dma_data into snd_soc_dai_ops.hw_params of the
      McBSP, McASP & VCIF drivers (davinci-i2s.c, davinci-mcasp.c & davinci-vcif.c).
      The initialisation had to be moved from the probe function in these drivers
      because davinci_*_dai changed from snd_soc_dai to snd_soc_dai_driver.
      
      Unfortunately, the DMA params pointer is needed by davinci_pcm_open (in
      davinci-pcm.c) before hw_params is called. I have moved the initialisation to
      a new snd_soc_dai_ops.startup function in each of these drivers. This fix
      indicates that all platforms that use davinci-pcm must have been broken and
      need to test with this fix.
      
      --
      
      The multi-component commit also changed the McBSP driver name from
      "davinci-asp" to "davinci-i2s" in davinci-i2s.c without updating the board
      level references to the driver name. This change is understandable, as there
      is a similarly named "davinci-mcasp" driver in davinci-mcasp.c.
      
      There is probably no 'correct' name for this driver. The DM6446 datasheet
      calls it the "ASP" and describes it as a "specialised McBSP". The DM355
      datasheet calls it the "ASP" and describes it as a "specialised ASP". The
      DM365 datasheet calls it the "McBSP". Rather than fix this problem by
      reverting to "davinci-asp", I've elected to avoid future confusion with the
      "davinci-mcasp" driver by changing it to "davinci-mcbsp", which is also
      consistent with the names of the functions in the driver. There are other
      fixes required, so it was never going to be as simple as a revert anyway.
      
      --
      
      The DM365 only has one McBSP port (of the McBSP platforms, only the DM355 has
      2 ports), so I've changed the the id of the platform_device from 0 to -1.
      
      --
      
      In davinci-evm.c, the DM6446 EVM can no longer share a snd_soc_dai_link
      structure with the DM355 EVM as they use different cpu DAI names (the DM355
      has 2 ports and the EVM uses the second port, but the DM6446 only has 1 port).
      This also means that the 2 boards need different snd_soc_card structures.
      
      --
      
      The codec_name entries in davinci-evm.c didn't match the i2c ids in the board
      files. I have only checked and fixed the details of the names used for the
      McBSP based platforms. Someone with a McASP based platform (eg DA8xx) should
      check the others.
      Signed-off-by: NChris Paulson-Ellis <chris@edesix.com>
      Acked-by: NLiam Girdwood <lrg@slimlogic.co.uk>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      bedad0ca
    • M
      ASoC: Fix register cache setup WM8994 for multi-component · 11e713a0
      Mark Brown 提交于
      During the multi-component conversion the WM8994 register cache init
      got lost.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NLiam Girdwood <lrg@slimlogic.co.uk>
      11e713a0
    • A
      BKL: remove extraneous #include <smp_lock.h> · 451a3c24
      Arnd Bergmann 提交于
      The big kernel lock has been removed from all these files at some point,
      leaving only the #include.
      
      Remove this too as a cleanup.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      451a3c24
  16. 15 11月, 2010 1 次提交