1. 21 Feb, 2009 2 commits
  2. 03 Feb, 2009 12 commits
  3. 02 Feb, 2009 23 commits
  4. 01 Feb, 2009 3 commits
    • Linus Torvalds's avatar
      Manually revert "mlock: downgrade mmap sem while populating mlocked regions" · 27421e21
      Linus Torvalds authored
      This essentially reverts commit 8edb08ca.
      
      It downgraded our mmap semaphore to a read-lock while mlocking pages, in
      order to allow other threads (and external accesses like "ps" et al) to
      walk the vma lists and take page faults etc.  Which is a nice idea, but
      the implementation does not work.
      
      Because we cannot upgrade the lock back to a write lock without
      releasing the mmap semaphore, the code had to release the lock entirely
      and then re-take it as a writelock.  However, that meant that the caller
      possibly lost the vma chain that it was following, since now another
      thread could come in and mmap/munmap the range.
      
      The code tried to work around that by just looking up the vma again and
      erroring out if that happened, but quite frankly, that was just a buggy
      hack that doesn't actually protect against anything (the other thread
      could just have replaced the vma with another one instead of totally
      unmapping it).
      
      The only way to downgrade to a read map _reliably_ is to do it at the
      end, which is likely the right thing to do: do all the 'vma' operations
      with the write-lock held, then downgrade to a read after completing them
      all, and then do the "populate the newly mlocked regions" while holding
      just the read lock.  And then just drop the read-lock and return to user
      space.
      
      The (perhaps somewhat simpler) alternative is to just make all the
      callers of mlock_vma_pages_range() know that the mmap lock got dropped,
      and just re-grab the mmap semaphore if it needs to mlock more than one
      vma region.
      
      So we can do this "downgrade mmap sem while populating mlocked regions"
      thing right, but the way it was done here was absolutely not correct.
      Thus the revert, in the expectation that we will do it all correctly
      some day.
      
      Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      27421e21
    • Devin Heitmueller's avatar
      V4L/DVB (10411): s5h1409: Perform s5h1409 soft reset after tuning · 67e70baf
      Devin Heitmueller authored
      Just like with the s5h1411, the s5h1409 needs a soft-reset in order for it
      to know that the tuner has been told to change frequencies.  This change
      changes the behavior from "random tuning times between 500ms to complete
      tuning lock failures" to "tuning lock consistently within 700ms".
      
      Thanks to Robert Krakora <rob.krakora@messagenetsystems.com> for doing
      initial testing of the patch on the KWorld 330U.
      
      Thanks to Andy Walls <awalls@radix.net> for doing testing of the patch on
      the HVR-1600.
      
      Thanks to Michael Krufky <mkrufky@linuxtv.org> for doing additional testing.
      Signed-off-by: default avatarDevin Heitmueller <dheitmueller@linuxtv.org>
      Signed-off-by: default avatarMichael Krufky <mkrufky@linuxtv.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      67e70baf
    • Mauro Carvalho Chehab's avatar
      V4L/DVB (10403): saa7134-alsa: saa7130 doesn't support digital audio · 40c41c8c
      Mauro Carvalho Chehab authored
      According with saa7130 public datasheet, saa7130 doesn't support
      digital audio. This is also confirmed by experimental tests. So, it
      doesn't make sense to let saa7134-alsa register for those chipsets.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      40c41c8c