Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 31 7月, 2015 1 次提交
  3. 30 7月, 2015 1 次提交
  5. 29 7月, 2015 2 次提交
  7. 27 7月, 2015 3 次提交
    • W
      ALSA: hda - Add pin quirk for the headset mic jack detection on Dell laptop · 5ce000b2
      由 Woodrow Shen 提交于 
      The new Dell laptop with codec 256 can't detect headset mic when
headset was inserted on the machine. From alsa-info, we check
init_pin_configs and need to define the new register value for pin
0x1d & 0x1e because the original macro ALC256_STANDARD_PINS can't
match pin definition. Also, the macro ALC256_STANDARD_PINS is
simplified by removing them. This makes headset mic works on laptop.

Codec: Realtek ALC256
Vendor Id: 0x10ec0256
Subsystem Id: 0x102806f2

BugLink: https://bugs.launchpad.net/bugs/1478497Signed-off-by: NWoodrow Shen <woodrow.shen@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      5ce000b2
    • T
      ALSA: hda - Apply fixup for another Toshiba Satellite S50D · b9d9c9ef
      由 Takashi Iwai 提交于 
      Toshiba Satellite S50D has another model with a different PCI SSID
(1179:fa93) while the previous fixup was for 1179:fa91.  Adjust the
fixup entry with SND_PCI_QUIRK_MASK() to match with both devices.
Reported-by: NTim Sample <timsample@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      b9d9c9ef
    • T
      ALSA: fireworks: add support for AudioFire2 quirk · 9c6893e0
      由 Takashi Sakamoto 提交于 
      Fireworks uses TSB43CB43(IceLynx-Micro) as its IEC 61883-1/6 interface.
This chip includes ARM7 core, and loads and runs program. The firmware
is stored in on-board memory and loaded every powering-on.

Echo Audio ships several versions of firmwares for each model. These
firmwares have each quirk and the quirk changes a sequence of packets.

AudioFire2 has a quirk to transfer a first packet with non-zero in
its dbc field. This causes ALSA Fireworks driver to detect discontinuity.
As long as I investigated, firmware 5.7, 5.7.6 and 5.8 have this quirk.

This commit adds a support for the quirk to handle AudioFire2 packets.
For safe, CIP_SKIP_INIT_DBC_CHECK is applied to all versions of
AudioFire2's firmwares.

02 00050002 90ffffff <-
42 0005000a 90013000
42 00050012 90014400
42 0005001a 90015800
02 0005001a 90ffffff
42 00050022 90019000
42 0005002a 9001a400
42 00050032 9001b800
02 00050032 90ffffff
42 0005003a 9001d000
42 00050042 9001e400
42 0005004a 9001f800
02 0005004a 90ffffff
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      9c6893e0
  9. 25 7月, 2015 2 次提交
  11. 24 7月, 2015 1 次提交
  13. 22 7月, 2015 4 次提交
  15. 21 7月, 2015 2 次提交
    • L
      ASoC: dapm: Don't add prefix to widget stream name · a798c24a
      由 Lars-Peter Clausen 提交于 
      Commit fdb6eb0a ("ASoC: dapm: Modify widget stream name according to
prefix") fixed the case where a DAPM route between a DAI widget and a
DAC/ADC/AIF widget with a matching stream name was not created when the
DAPM context was using a prefix.

Unfortunately the patch introduced a few issues on its own like leaking the
dynamically allocated stream name memory and also not checking whether the
allocation succeeded in the first place.

It is also incomplete in that it still does not handle the case where
stream name of the widget is a substring of the stream name of the DAI,
which is explicitly allowed and works fine if no DAPM prefix is used.

Revert the commit and take a slightly different approach to solving the
issue. Instead of comparing the widget's stream name to the name of the DAI
widget compare it to the stream name of the DAI widget. The stream name of
the DAI widget is identical to the name of the DAI widget except that it
wont have the DAPM prefix added. So this approach behaves identical
regardless to whether the DAPM context uses a prefix or not.

We don't have to worry about potentially matching with a widget with the
same stream name, but from a different DAPM context with a different
prefix, since the code already makes sure that both the DAI widget and the
matched widget are from the same DAPM context.

Fixes: fdb6eb0a ("ASoC: dapm: Modify widget stream name according to prefix")
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
      a798c24a
    • A
      ALSA: hda - Add new GPU codec ID 0x10de007d to snd-hda · 6c3d9119
      由 Aaron Plattner 提交于 
      Vendor ID 0x10de007d is used by a yet-to-be-named GPU chip.

This chip also has the 2-ch audio swapping bug, so patch_nvhdmi is
appropriate here.
Signed-off-by: NAaron Plattner <aplattner@nvidia.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      6c3d9119
  17. 20 7月, 2015 2 次提交
  19. 19 7月, 2015 1 次提交
  21. 18 7月, 2015 1 次提交
  23. 17 7月, 2015 2 次提交
    • T
      ALSA: pcm: Fix lockdep warning with nonatomic PCM ops · 67756e31
      由 Takashi Iwai 提交于 
      With the nonatomic PCM ops, the system may spew lockdep warnings like:

 =============================================
 [ INFO: possible recursive locking detected ]
 4.2.0-rc1-jeejaval3 #12 Not tainted
 ---------------------------------------------
 aplay/4029 is trying to acquire lock:
  (snd_pcm_link_rwsem){.+.+.+}, at: [<ffffffff816fd473>] snd_pcm_stream_lock+0x43/0x60

 but task is already holding lock:
  (snd_pcm_link_rwsem){.+.+.+}, at: [<ffffffff816fcf29>] snd_pcm_action_nonatomic+0x29/0x80

 other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(snd_pcm_link_rwsem);
   lock(snd_pcm_link_rwsem);

Although this is false-positive as the rwsem is taken always as
read-only for these code paths, it's certainly annoying to see this at
any occasion.  A simple fix is to use down_read_nested() in
snd_pcm_stream_lock() that can be called inside another lock.
Reported-by: NVinod Koul <vinod.koul@intel.com>
Reported-by: NJeeja Kp <jeeja.kp@intel.com>
Tested-by: NJeeja Kp <jeeja.kp@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      67756e31
    • N
      ASoC: rt5645: Check if codec is initialized in workqueue handler · f2a5ded3
      由 Nicolas Boichat 提交于 
      This fixes kernel panic on boot, if rt5645->codec is NULL when
rt5645_jack_detect_work is first called.

rt5645_jack_detect_work needs rt5645->codec to be initialized to setup
dapm pins. Also, reporting jack events is useless, as the jacks cannot
be set before the codec is ready.

Since we manually call the interrupt handler in
rt5645_set_jack_detect, the initial jack state will be reported
correctly, and dapm pins will be setup at that time.
Signed-off-by: NNicolas Boichat <drinkcat@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
      f2a5ded3
  25. 16 7月, 2015 2 次提交
  27. 14 7月, 2015 2 次提交
  29. 13 7月, 2015 2 次提交
  31. 09 7月, 2015 4 次提交
  33. 08 7月, 2015 1 次提交
  35. 07 7月, 2015 3 次提交
  37. 06 7月, 2015 1 次提交
  39. 02 7月, 2015 1 次提交
  41. 01 7月, 2015 2 次提交