1. 01 5月, 2013 1 次提交
  2. 20 4月, 2013 1 次提交
  3. 10 4月, 2013 2 次提交
  4. 07 4月, 2013 1 次提交
    • E
      ALSA: usb-audio: fix endianness bug in snd_nativeinstruments_* · 889d6684
      Eldad Zack 提交于
      The usb_control_msg() function expects __u16 types and performs
      the endianness conversions by itself.
      However, in three places, a conversion is performed before it is
      handed over to usb_control_msg(), which leads to a double conversion
      (= no conversion):
      * snd_usb_nativeinstruments_boot_quirk()
      * snd_nativeinstruments_control_get()
      * snd_nativeinstruments_control_put()
      
      Caught by sparse:
      
      sound/usb/mixer_quirks.c:512:38: warning: incorrect type in argument 6 (different base types)
      sound/usb/mixer_quirks.c:512:38:    expected unsigned short [unsigned] [usertype] index
      sound/usb/mixer_quirks.c:512:38:    got restricted __le16 [usertype] <noident>
      sound/usb/mixer_quirks.c:543:35: warning: incorrect type in argument 5 (different base types)
      sound/usb/mixer_quirks.c:543:35:    expected unsigned short [unsigned] [usertype] value
      sound/usb/mixer_quirks.c:543:35:    got restricted __le16 [usertype] <noident>
      sound/usb/mixer_quirks.c:543:56: warning: incorrect type in argument 6 (different base types)
      sound/usb/mixer_quirks.c:543:56:    expected unsigned short [unsigned] [usertype] index
      sound/usb/mixer_quirks.c:543:56:    got restricted __le16 [usertype] <noident>
      sound/usb/quirks.c:502:35: warning: incorrect type in argument 5 (different base types)
      sound/usb/quirks.c:502:35:    expected unsigned short [unsigned] [usertype] value
      sound/usb/quirks.c:502:35:    got restricted __le16 [usertype] <noident>
      Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
      Acked-by: NDaniel Mack <zonque@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      889d6684
  5. 05 4月, 2013 1 次提交
  6. 04 4月, 2013 6 次提交
  7. 03 4月, 2013 1 次提交
    • T
      ALSA: usb: Work around CM6631 sample rate change bug · 690a863f
      Torstein Hegge 提交于
      The C-Media CM6631 USB receiver doesn't respond to changes in sample rate
      while the interface is active. The same behavior is observed in other UAC2
      hardware like the VIA VT1731.
      
      Reset the interface after setting the sampling frequency on sample rate
      changes, to ensure that the sample rate set by snd_usb_init_sample_rate() is
      used. Otherwise, the device will try to use the sample rate of the previous
      stream, causing distorted sound on sample rate changes.
      
      The reset is performed for all UAC2 devices, as it should not affect a
      standards compliant device, but it is only necessary for C-Media CM6631,
      VIA VT1731 and possibly others.
      
      Failure to read sample rate from the device is not handled as an error in
      set_sample_rate_v2(), as (permanent or intermittent) failure to read sample
      rate isn't essential for a successful sample rate set.
      Signed-off-by: NTorstein Hegge <hegge@resisty.net>
      Acked-by: NClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      690a863f
  8. 02 4月, 2013 2 次提交
  9. 28 3月, 2013 1 次提交
  10. 26 3月, 2013 1 次提交
  11. 22 3月, 2013 2 次提交
    • L
      ASoC: dma-sh7760: Fix compile error · 417a1178
      Lars-Peter Clausen 提交于
      The dma-sh7760 currently fails with the following compile error:
      	sound/soc/sh/dma-sh7760.c:346:2: error: unknown field 'pcm_ops' specified in initializer
      	sound/soc/sh/dma-sh7760.c:346:2: warning: initialization from incompatible pointer type
      	sound/soc/sh/dma-sh7760.c:347:2: error: unknown field 'pcm_new' specified in initializer
      	sound/soc/sh/dma-sh7760.c:347:2: warning: initialization makes integer from pointer without a cast
      	sound/soc/sh/dma-sh7760.c:348:2: error: unknown field 'pcm_free' specified in initializer
      	sound/soc/sh/dma-sh7760.c:348:2: warning: initialization from incompatible pointer type
      	sound/soc/sh/dma-sh7760.c: In function 'sh7760_soc_platform_probe':
      	sound/soc/sh/dma-sh7760.c:353:2: warning: passing argument 2 of 'snd_soc_register_platform' from incompatible pointer type
      	include/sound/soc.h:368:5: note: expected 'struct snd_soc_platform_driver *' but argument is of type 'struct snd_soc_platform *'
      
      This is due the misnaming of the snd_soc_platform_driver type name and 'ops'
      field. The issue was introduced in commit f0fba2ad("ASoC: multi-component - ASoC
      Multi-Component Support").
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Cc: stable@vger.kernel.org
      417a1178
    • T
      ALSA: hda - Fix DAC assignment for independent HP · 55a63d4d
      Takashi Iwai 提交于
      The generic parser should evaluate the availability of the independent
      HP when specified.  Otherwise a DAC without the direct connection to
      the corresponding pin may be assigned for the HP, but the driver
      doesn't check it at all.  The problem was actually seen on some
      machines with VT1708s or equivalent codec, where DAC0 is assigned to
      HP although it can be connected only via aamix.
      
      This patch adds the badness evaluation for the independent HP to make
      it working properly.
      Reported-by: NLydia Wang <LydiaWang@viatech.com.cn>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      55a63d4d
  12. 21 3月, 2013 1 次提交
    • T
      ALSA: hda - Fix abuse of snd_hda_lock_devices() for DSP loader · eb49faa6
      Takashi Iwai 提交于
      The current DSP loader code abuses snd_hda_lock_devices() for ensuring
      the DSP loader not conflicting with the other normal operations.  But
      this trick obviously doesn't work for the PM resume since the streams
      are kept opened there where snd_hda_lock_devices() returns -EBUSY.
      That means we need another lock mechanism instead of abuse.
      
      This patch provides the new lock state to azx_dev.  Theoretically it's
      possible that the DSP loader conflicts with the stream that has been
      already assigned for another PCM.  If it's running, the DSP loader
      should simply fail.  If not -- it's the case for PM resume --, we
      should assign this stream temporarily to the DSP loader, and take it
      back to the PCM after finishing DSP loading.  If the PCM is operated
      during the DSP loading, it should get an error, too.
      Reported-and-tested-by: NDylan Reid <dgreid@chromium.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      eb49faa6
  13. 20 3月, 2013 7 次提交
  14. 18 3月, 2013 3 次提交
  15. 15 3月, 2013 6 次提交
  16. 14 3月, 2013 1 次提交
  17. 13 3月, 2013 3 次提交