Skip to content

L
linux
Switch branch/tag
  1. 17 Jul, 2011 8 commits
  3. 16 Jul, 2011 8 commits
  5. 15 Jul, 2011 13 commits
  7. 14 Jul, 2011 7 commits
  9. 13 Jul, 2011 4 commits
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc · 51414d41
      Linus Torvalds authored 
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc:
  mmc: core: Bus width testing needs to handle suspend/resume
      51414d41
    • Mauro Carvalho Chehab's avatar
      [media] tuner-core: fix a 2.6.39 regression with mt20xx · a1ad5ec7
      Mauro Carvalho Chehab authored 
      As Simon reported, digital TV broke with mt20xx tuner due to
commit ad020dc2.

The mt20xx tuner passes V4L2_TUNER_DIGITAL_TV to tuner core. However, the
check_mode code now doesn't handle it well. Change the logic there to
avoid the breakage, and fix a test for analog-only at g_tuner.
Reported-by: default avatarSimon Arlott <simon@fire.lp0.eu>
Tested-by: default avatarSimon Arlott <simon@fire.lp0.eu>
Cc: stable@kernel.org
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      a1ad5ec7
    • Devin Heitmueller's avatar
      [media] dvb_frontend: fix race condition in stopping/starting frontend · 2d196931
      Devin Heitmueller authored 
      Attached is a patch which addresses a race condition in the DVB core
related to closing/reopening the DVB frontend device in quick
succession.  This is the reason that devices such as the HVR-1300,
HVR-3000, and HVR-4000 have been failing to scan properly under MythTV
and w_scan.

The gory details of the race are described in the patch.

Devin

There is a race condition exhibited when channel scanners such as w_scan and
MythTV quickly close and then reopen the frontend device node.

Under normal conditions, the behavior is as follows:

1.  Application closes the device node
2.  DVB frontend ioctl calls dvb_frontend_release which sets
    fepriv->release_jiffies
3.  DVB frontend thread *eventually* calls dvb_frontend_is_exiting() which
    compares fepriv->release_jiffies, and shuts down the thread if timeout has
    expired
4.  Thread goes away
5.  Application opens frontend device
6.  DVB frontend ioctl() calls ts_bus_ctrl(1)
7.  DVB frontend ioctl() creates new frontend thread, which calls
    dvb_frontend_init(), which has demod driver init() routine setup initial
    register state for demod chip.
8.  Tuning request is issued.

The race occurs when the application in step 5 performs the new open() call
before the frontend thread is shutdown.  In this case the ts_bus_ctrl() call
is made, which strobes the RESET pin on the demodulator, but the
dvb_frontend_init() function never gets called because the frontend thread
hasn't gone away yet.  As a result, the initial register config for the demod
is *never* setup, causing subsequent tuning requests to fail.

If there is time between the close and open (enough for the dvb frontend
thread to be torn down), then in that case the new frontend thread is created
and thus the dvb_frontend_init() function does get called.

The fix is to set the flag which forces reinitialization if we did in fact
call ts_bus_ctrl().

This problem has been seen on the HVR-1300, HVR-3000, and HVR-4000, and is
likely occuring on other designs as well where ts_bus_ctrl() actually strobes
the reset pin on the demodulator.

Note that this patch should supercede any patches submitted for the
1300/3000/4000 which remove the code that removes GPIO code in
cx8802_dvb_advise_acquire(), which have been circulating by users for some
time now...

Canonical tracking this issue in Launchpad 439163:

Thanks to Jon Sayers from Hauppauge and Florent Audebert from Anevia S.A. for
providing hardware to test/debug with.
Signed-off-by: default avatarDevin Heitmueller <dheitmueller@kernellabs.com>
Cc: Jon Sayers <j.sayers@hauppauge.co.uk>
Cc: Florent Audebert <florent.audebert@anevia.com>
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      2d196931
    • Randy Dunlap's avatar
      [media] media: fix radio-sf16fmr2 build when SND is not enabled · 42a741dc
      Randy Dunlap authored 
      When CONFIG_SND is not enabled, radio-sf16fmr2 build fails with:

so make this driver depend on SND.
Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: linux-media@vger.kernel.org
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      42a741dc
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7