Skip to content
  1. Oct 13, 2009
  2. Oct 12, 2009
  3. Oct 10, 2009
    • Robert Hancock's avatar
      ALSA: ice1724: Fix surround on Chaintech AV-710 · 43189a38
      Robert Hancock authored
      
      
      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: default avatarRobert Hancock <hancockrwd@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      43189a38
  4. Oct 08, 2009
    • Takashi Iwai's avatar
      Merge branch 'fix/misc' into for-linus · 378e869f
      Takashi Iwai authored
      378e869f
    • Takashi Iwai's avatar
      Merge branch 'fix/hda' into for-linus · d2a764dd
      Takashi Iwai authored
      d2a764dd
    • Robert Hancock's avatar
      ALSA: ice1724: increase SPDIF and independent stereo buffer sizes · 1d4efa66
      Robert Hancock authored
      
      
      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: default avatarRobert Hancock <hancockrwd@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      1d4efa66
    • Krzysztof Helt's avatar
      ALSA: opl3: circular locking in the snd_opl3_note_on() and snd_opl3_note_off() · 8dce39b8
      Krzysztof Helt authored
      
      
      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: default avatarKrzysztof Helt <krzysztof.h1@wp.pl>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      8dce39b8
    • Pavel Hofman's avatar
      ALSA: ICE1712/24 - Change the Multi Track Peak control (level meters) from MIXER to PCM type · 2bdf6633
      Pavel Hofman authored
      
      
      * 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: default avatarPavel Hofman <pavel.hofman@ivitera.com>
      Acked-by: default avatarJaroslav Kysela <perex@perex.cz>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      2bdf6633
  5. Oct 07, 2009
  6. Oct 06, 2009
  7. Oct 05, 2009
  8. Oct 04, 2009
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://www.linux-m32r.org/git/takata/linux-2.6_dev · 8a0382f6
      Linus Torvalds authored
      * '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
    • Linus Torvalds's avatar
      tty: Avoid dropping ldisc_mutex over hangup tty re-initialization · 0b5759c6
      Linus Torvalds authored
      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: default avatarIngo Molnar <mingo@elte.hu>
      Reported-by: default avatarHeinz Diehl <htd@fancy-poultry.org>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0b5759c6
    • Toshihiro HANAWA's avatar
      m32r: Fix IPI function calls for SMP · 0a3d31b7
      Toshihiro HANAWA authored
      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: default avatarToshihiro HANAWA <hanawa@ccs.tsukuba.ac.jp>
      Signed-off-by: default avatarHirokazu Takata <takata@linux-m32r.org>
      0a3d31b7