kernel.git/drivers/media/dvb/dvb-core, branch linux-2.6.31.y

headers: smp_lock.h redux

2009-07-12T19:22:34Z

* Remove smp_lock.h from files which don't need it (including some headers!) * Add smp_lock.h to files which do need it * Make smp_lock.h include conditional in hardirq.h It's needed only for one kernel_locked() usage which is under CONFIG_PREEMPT This will make hardirq.h inclusion cheaper for every PREEMPT=n config (which includes allmodconfig/allyesconfig, BTW) Signed-off-by: Alexey Dobriyan Signed-off-by: Linus Torvalds

Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6

2009-06-17T04:15:42Z

* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6: (425 commits) V4L/DVB (11870): gspca - main: VIDIOC_ENUM_FRAMESIZES ioctl added. V4L/DVB (12004): poll method lose race condition V4L/DVB (11894): flexcop-pci: dmesg visible names broken V4L/DVB (11892): Siano: smsendian - declare function as extern V4L/DVB (11891): Siano: smscore - bind the GPIO SMS protocol V4L/DVB (11890): Siano: smscore - remove redundant code V4L/DVB (11889): Siano: smsdvb - add DVB v3 events V4L/DVB (11888): Siano: smsusb - remove redundant ifdef V4L/DVB (11887): Siano: smscards - add board (target) events V4L/DVB (11886): Siano: smscore - fix some new GPIO definitions names V4L/DVB (11885): Siano: Add new GPIO management interface V4L/DVB (11884): Siano: smssdio - revert to stand alone module V4L/DVB (11883): Siano: cards - add two additional (USB) devices V4L/DVB (11824): Siano: smsusb - change exit func debug msg V4L/DVB (11823): Siano: smsusb - fix typo in module description V4L/DVB (11822): Siano: smscore - bug fix at get_device_mode V4L/DVB (11821): Siano: smscore - fix isdb-t firmware name V4L/DVB (11820): Siano: smscore - fix byte ordering bug V4L/DVB (11819): Siano: smscore - fix get_common_buffer bug V4L/DVB (11818): Siano: smscards - assign gpio to HPG targets ...

V4L/DVB (11875): dvb_frontend: fix case where fepriv->exit not reset

2009-06-16T22:14:15Z

The fact that we now explicitly set fepriv->exit = 1 when the thread is shutting down exposed an edge case where it was not being reset back to zero once the thread went away in some cases. This resulted in failures in cases where the frontend was closed, and then opened O_RDONLY, since in that case the thread is not being restarted but it was checking the fepriv->exit flag. Thanks to Thierry Lelegard, who and encountered and debugged a large portion of the issue in the same twelve hours that I did (as well as testing my patch). Cc: Thierry Lelegard Signed-off-by: Devin Heitmueller Signed-off-by: Mauro Carvalho Chehab

V4L/DVB (11785): dvb_frontend: fix race condition resulting in dropped tuning commands

2009-06-16T22:14:14Z

A race condition was detected in the case that putting the tuner to sleep takes an unusually long period of time, combined with applications that quickly close/open the dvb frontend. The kaffeine channel scanner closes and reopens the dvb frontend between each tuning attempt. If it takes an unusually longer period of time to put the tuner to sleep (for example, the Pinnacle 801e takes 660 ms), the dvb_frontend thread will still be in a running state (and hence fepriv->thread is still set) but the fepriv->exit field will still be zero. As a result, if a dvb_frontend_start() call arrives while the frontend thread is in the process of terminating, the call will return 0 without actually starting a new thread. This results in the tuning request being dropped. To address this, mark fepriv->exit as soon as we know the thread is going to be terminated, so that dvb_frontend_start() knows to start a new instance. Problem encountered with Kaffeine 0.8.7 doing ATSC scanning against the Pinnacle 801e tuner, in conjunction with new code to power down the xc5000 when not in use. Signed-off-by: Devin Heitmueller Signed-off-by: Mauro Carvalho Chehab

V4L/DVB (11930): TS continuity check: show error message when discontinuity detected or TEI flag detected in header

2009-06-16T22:07:23Z

Signed-off-by: Abylay Ospan Signed-off-by: Mauro Carvalho Chehab

V4L/DVB (11841): core: fix potential mutex_unlock without mutex_lock in dvb_dvr_read

2009-06-16T21:21:10Z

dvb_dvr_read may unlock the dmxdev mutex and return -ENODEV, except this function is a file op and will never be called with the mutex held. There's existing mutex_lock and mutex_unlock around the actual read but it's commented out. These should probably be uncommented but the read blocks and this could block another non-blocking reader on the mutex instead. This change comments out the extra mutex_unlock. [akpm@linux-foundation.org: cleanups, simplification] Signed-off-by: Simon Arlott Signed-off-by: Andrew Morton Signed-off-by: Mauro Carvalho Chehab

Driver Core: dvb: add nodename for dvb drivers

2009-06-16T04:30:26Z

This adds support to the dvb core to report the proper device name to userspace for their devices. Signed-off-by: Kay Sievers Signed-off-by: Jan Blunck Signed-off-by: Greg Kroah-Hartman

V4L/DVB (10391): dvb: constify VFTs

2009-03-30T15:42:34Z

dvb: constify VFTs Signed-off-by: Jan Engelhardt Signed-off-by: Mauro Carvalho Chehab

V4L/DVB (10976): Bug fix: For legacy applications stv0899 performs search only first time after insmod.

2009-03-13T16:19:24Z

For legacy applications stv0899 performs search only first time after insmod due to not set DVBFE_ALGO_SEARCH_AGAIN bit Signed-off-by: Igor M. Liplianin Signed-off-by: Manu Abraham Signed-off-by: Mauro Carvalho Chehab

V4L/DVB (10572): Revert commit dda06a8e4610757def753ee3a541a0b1a1feb36b

2009-02-17T12:43:09Z

On Mon, 02 Feb 2009, Hartmut wrote: This change set is wrong. The affected functions cannot be called from an interrupt context, because they may process large buffers. In this case, interrupts are disabled for a long time. Functions, like dvb_dmx_swfilter_packets(), could be called only from a tasklet. This change set does hide some strong design bugs in dm1105.c and au0828-dvb.c. Please revert this change set and do fix the bugs in dm1105.c and au0828-dvb.c (and other files). On Sun, 15 Feb 2009, Oliver Endriss wrote: This changeset _must_ be reverted! It breaks all kernels since 2.6.27 for applications which use DVB and require a low interrupt latency. It is a very bad idea to call the demuxer to process data buffers with interrupts disabled! On Mon, 16 Feb 2009, Trent Piepho wrote: I agree, this is bad. The demuxer is far too much work to be done with IRQs off. IMHO, even doing it under a spin-lock is excessive. It should be a mutex. Drivers should use a work-queue to feed the demuxer. Thank you for testing this changeset and discovering the issues on it. Cc: Trent Piepho Cc: Hartmut Cc: Oliver Endriss Cc: Andreas Oberritter Signed-off-by: Mauro Carvalho Chehab