Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 6
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 10 10月, 2009 1 次提交
    • R
      ALSA: ice1724: Fix surround on Chaintech AV-710 · 43189a38
      由 Robert Hancock 提交于 
      Fix the num_total_dacs setting for Chaintech AV710. The existing comment
that only PSDOUT0 is connected is correct, but since the card is using
packed AC97 mode to send 6 channels to the codec, num_total_dacs should be
set to 6 and not 2. This allows 6-channel surround to work. Also clarify
a comment regarding the additional WM8728 codec on this card (it's connected
to the SPDIF output and always receives the same data).
Signed-off-by: NRobert Hancock <hancockrwd@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      43189a38
  3. 08 10月, 2009 5 次提交
    • T
      Merge branch 'fix/misc' into for-linus · 378e869f
      由 Takashi Iwai 提交于
      378e869f
    • T
      Merge branch 'fix/hda' into for-linus · d2a764dd
      由 Takashi Iwai 提交于
      d2a764dd
    • R
      ALSA: ice1724: increase SPDIF and independent stereo buffer sizes · 1d4efa66
      由 Robert Hancock 提交于 
      Increase the default and maximum PCM buffer prellocation size for ice1724's
SPDIF and independent stereo pair outputs to 256K, which is the hardware's
maximum supported size. This allows a reduction in interrupt rate and
potentially power usage when an application is not latency-critical.
Signed-off-by: NRobert Hancock <hancockrwd@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      1d4efa66
    • K
      ALSA: opl3: circular locking in the snd_opl3_note_on() and snd_opl3_note_off() · 8dce39b8
      由 Krzysztof Helt 提交于 
      Fix following circular locking in the opl3 driver.

=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.32-rc3 #87
-------------------------------------------------------
swapper/0 is trying to acquire lock:
 (&opl3->voice_lock){..-...}, at: [<cca748fe>] snd_opl3_note_off+0x1e/0xe0 [snd_opl3_synth]

but task is already holding lock:
 (&opl3->sys_timer_lock){..-...}, at: [<cca75169>] snd_opl3_timer_func+0x19/0xc0 [snd_opl3_synth]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&opl3->sys_timer_lock){..-...}:
       [<c02461d5>] validate_chain+0xa25/0x1040
       [<c0246aca>] __lock_acquire+0x2da/0xab0
       [<c024731a>] lock_acquire+0x7a/0xa0
       [<c044c300>] _spin_lock_irqsave+0x40/0x60
       [<cca75046>] snd_opl3_note_on+0x686/0x790 [snd_opl3_synth]
       [<cca68912>] snd_midi_process_event+0x322/0x590 [snd_seq_midi_emul]
       [<cca74245>] snd_opl3_synth_event_input+0x15/0x20 [snd_opl3_synth]
       [<cca4dcc0>] snd_seq_deliver_single_event+0x100/0x200 [snd_seq]
       [<cca4de07>] snd_seq_deliver_event+0x47/0x1f0 [snd_seq]
       [<cca4e50b>] snd_seq_dispatch_event+0x3b/0x140 [snd_seq]
       [<cca5008c>] snd_seq_check_queue+0x10c/0x120 [snd_seq]
       [<cca5037b>] snd_seq_enqueue_event+0x6b/0xe0 [snd_seq]
       [<cca4e0fd>] snd_seq_client_enqueue_event+0xdd/0x100 [snd_seq]
       [<cca4eb7a>] snd_seq_write+0xea/0x190 [snd_seq]
       [<c02827b6>] vfs_write+0x96/0x160
       [<c0282c9d>] sys_write+0x3d/0x70
       [<c0202c45>] syscall_call+0x7/0xb

-> #0 (&opl3->voice_lock){..-...}:
       [<c02467e6>] validate_chain+0x1036/0x1040
       [<c0246aca>] __lock_acquire+0x2da/0xab0
       [<c024731a>] lock_acquire+0x7a/0xa0
       [<c044c300>] _spin_lock_irqsave+0x40/0x60
       [<cca748fe>] snd_opl3_note_off+0x1e/0xe0 [snd_opl3_synth]
       [<cca751f0>] snd_opl3_timer_func+0xa0/0xc0 [snd_opl3_synth]
       [<c022ac46>] run_timer_softirq+0x166/0x1e0
       [<c02269e8>] __do_softirq+0x78/0x110
       [<c0226ac6>] do_softirq+0x46/0x50
       [<c0226e26>] irq_exit+0x36/0x40
       [<c0204bd2>] do_IRQ+0x42/0xb0
       [<c020328e>] common_interrupt+0x2e/0x40
       [<c021092f>] apm_cpu_idle+0x10f/0x290
       [<c0201b11>] cpu_idle+0x21/0x40
       [<c04443cd>] rest_init+0x4d/0x60
       [<c055c835>] start_kernel+0x235/0x280
       [<c055c066>] i386_start_kernel+0x66/0x70

other info that might help us debug this:

2 locks held by swapper/0:
 #0:  (&opl3->tlist){+.-...}, at: [<c022abd0>] run_timer_softirq+0xf0/0x1e0
 #1:  (&opl3->sys_timer_lock){..-...}, at: [<cca75169>] snd_opl3_timer_func+0x19/0xc0 [snd_opl3_synth]

stack backtrace:
Pid: 0, comm: swapper Not tainted 2.6.32-rc3 #87
Call Trace:
 [<c0245188>] print_circular_bug+0xc8/0xd0
 [<c02467e6>] validate_chain+0x1036/0x1040
 [<c0247f14>] ? check_usage_forwards+0x54/0xd0
 [<c0246aca>] __lock_acquire+0x2da/0xab0
 [<c024731a>] lock_acquire+0x7a/0xa0
 [<cca748fe>] ? snd_opl3_note_off+0x1e/0xe0 [snd_opl3_synth]
 [<c044c300>] _spin_lock_irqsave+0x40/0x60
 [<cca748fe>] ? snd_opl3_note_off+0x1e/0xe0 [snd_opl3_synth]
 [<cca748fe>] snd_opl3_note_off+0x1e/0xe0 [snd_opl3_synth]
 [<c044c307>] ? _spin_lock_irqsave+0x47/0x60
 [<cca751f0>] snd_opl3_timer_func+0xa0/0xc0 [snd_opl3_synth]
 [<c022ac46>] run_timer_softirq+0x166/0x1e0
 [<c022abd0>] ? run_timer_softirq+0xf0/0x1e0
 [<cca75150>] ? snd_opl3_timer_func+0x0/0xc0 [snd_opl3_synth]
 [<c02269e8>] __do_softirq+0x78/0x110
 [<c044c0fd>] ? _spin_unlock+0x1d/0x20
 [<c025915f>] ? handle_level_irq+0xaf/0xe0
 [<c0226ac6>] do_softirq+0x46/0x50
 [<c0226e26>] irq_exit+0x36/0x40
 [<c0204bd2>] do_IRQ+0x42/0xb0
 [<c024463c>] ? trace_hardirqs_on_caller+0x12c/0x180
 [<c020328e>] common_interrupt+0x2e/0x40
 [<c0208d88>] ? default_idle+0x38/0x50
 [<c021092f>] apm_cpu_idle+0x10f/0x290
 [<c0201b11>] cpu_idle+0x21/0x40
 [<c04443cd>] rest_init+0x4d/0x60
 [<c055c835>] start_kernel+0x235/0x280
 [<c055c210>] ? unknown_bootoption+0x0/0x210
 [<c055c066>] i386_start_kernel+0x66/0x70
Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      8dce39b8
    • P
      ALSA: ICE1712/24 - Change the Multi Track Peak control (level meters) from MIXER to PCM type · 2bdf6633
      由 Pavel Hofman 提交于 
      * PLEASE NOTE - this change requires the corresponding update of
  envy24control for ice1712 - kind of an ABI change.
* The "Multi Track Peak" control is read-only level meters indicator.
* The control is VERY confusing to most users since it is currently displayed
  in regular mixers. E.g. alsamixer ignores its read-only status
  and allows changing the levels with keys which makes no sense.
Signed-off-by: NPavel Hofman <pavel.hofman@ivitera.com>
Acked-by: NJaroslav Kysela <perex@perex.cz>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      2bdf6633
  5. 07 10月, 2009 4 次提交
  7. 06 10月, 2009 4 次提交
  9. 05 10月, 2009 20 次提交
  11. 04 10月, 2009 6 次提交
    • L
      Merge branch 'for-linus' of git://www.linux-m32r.org/git/takata/linux-2.6_dev · 8a0382f6
      由 Linus Torvalds 提交于 
      * 'for-linus' of git://www.linux-m32r.org/git/takata/linux-2.6_dev:
  m32r: Fix IPI function calls for SMP
  m32r: Fix set_memory() for DISCONTIGMEM
  m32r: add rtc_lock variable
  m32r: define ioread* and iowrite* macros
  m32r: export delay loop symbols
  m32r: fix tme_handler
      8a0382f6
    • L
      tty: Avoid dropping ldisc_mutex over hangup tty re-initialization · 0b5759c6
      由 Linus Torvalds 提交于 
      A couple of people have hit the WARN_ON() in drivers/char/tty_io.c,
tty_open() that is unhappy about seeing the tty line discipline go away
during the tty hangup. See for example

	http://bugzilla.kernel.org/show_bug.cgi?id=14255

and the reason is that we do the tty_ldisc_halt() outside the
ldisc_mutex in order to be able to flush the scheduled work without a
deadlock with vhangup_work.

However, it turns out that we can solve this particular case by

 - using "cancel_delayed_work_sync()" in tty_ldisc_halt(), which waits
   for just the particular work, rather than synchronizing with any
   random outstanding pending work.

   This won't deadlock, since the buf.work we synchronize with doesn't
   care about the ldisc_mutex, it just flushes the tty ldisc buffers.

 - realize that for this particular case, we don't need to wait for any
   hangup work, because we are inside the hangup codepaths ourselves.

so as a result we can just drop the flush_scheduled_work() entirely, and
then move the tty_ldisc_halt() call to inside the mutex.  That way we
never expose the partially torn down ldisc state to tty_open(), and hold
the ldisc_mutex over the whole sequence.
Reported-by: NIngo Molnar <mingo@elte.hu>
Reported-by: NHeinz Diehl <htd@fancy-poultry.org>
Cc: stable@kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0b5759c6
    • T
      m32r: Fix IPI function calls for SMP · 0a3d31b7
      由 Toshihiro HANAWA 提交于 
      This patch fixes the m32r SMP kernel after 2.6.27.

A part of the following patch breaks m32r SMP operation.
> m32r: convert to generic helpers for IPI function calls
> commit 7b7426c8

In the above patch, a CALL_FUNC_SINGLE_IPI was newly introduced,
but the its IPI vector number was wrong in the patch code.

The m32r SMP kernel hanged-up during boot operation, because
the CPU_BOOT_IPI was called instead of CALL_FUNC_SINGLE_IPI
(CPU_BOOT_IPI had no side effect at that time because the 2nd
core had already been started up),
as a result, csd_unlock() was not called, then a dead lock
occurred in csd_lock_wait() after the detection of Compact Flash
memory as IDE generic disk.
Signed-off-by: NToshihiro HANAWA <hanawa@ccs.tsukuba.ac.jp>
Signed-off-by: NHirokazu Takata <takata@linux-m32r.org>
      0a3d31b7
    • H
      m32r: Fix set_memory() for DISCONTIGMEM · 6b6fabce
      由 Hirokazu Takata 提交于 
      In case CONFIG_DISCONTIGMEM is set, the memory size of system was
always determined by CONFIG_MEMORY_SIZE and was not changeable.

This patch fixes set_memory() of arch/m32r/mm/discontig.c so that
we can specify memory size by the "mem=<size>" kernel parameter.
Signed-off-by: NHirokazu Takata <takata@linux-m32r.org>
      6b6fabce
    • H
      m32r: add rtc_lock variable · bac33bd5
      由 Hirokazu Takata 提交于 
      Add a spinlock variable "rtc_lock".
This is taken from arch/arm/kernel/time.c.
Signed-off-by: NHirokazu Takata <takata@linux-m32r.org>
      bac33bd5
    • H
      m32r: define ioread* and iowrite* macros · d2c5821c
      由 Hirokazu Takata 提交于 
      Define ioread* and iowrite* macros to fix the following build errors:

  CC [M]  drivers/uio/uio_smx.o
drivers/uio/uio_smx.c: In function 'smx_handler':
drivers/uio/uio_smx.c:31: error: implicit declaration of function 'ioread32'
drivers/uio/uio_smx.c:37: error: implicit declaration of function 'iowrite32'
Signed-off-by: NHirokazu Takata <takata@linux-m32r.org>
      d2c5821c