[linux-dvb] RFC - Flexcop Streaming watchdog (VDSB)
awalls at radix.net
Sat Jan 17 04:37:22 CET 2009
On Fri, 2009-01-16 at 16:03 +0100, Patrick Boettcher wrote:
> Hi lists,
> There a struct-work-watchdog looking at the number of irq-received while
> having PIDs active in the PID-filter. If no IRQs are received, the
> pid-filter-system is reset.
> It seems to fix the problem and so far I've not seen any false positives
> (like resetting the pid-filter even though streaming is working fine).
> Before asking to pull the patch I'd like to discuss an issue: my
> work-around is iterating over the pid-filter-list in the dvb_demux. I'm
> doing this in the struct-work-callback. In dvb_demux.c I see that this
> list is protected with a spinlock. When I now try to take the spinlock in
> the work-function I'll get a nice message saying, that I cannot do take a
> spinlock in a work-function.
> What can I do?
I am surprised you cannot acquire a spinlock in a deferable work
handler. I would not have thought this the case, but I don't know for
sure. BTW, why are you using spin_lock_irq() to disable local
interrupts in the work handler instead of spin_lock_irqsave()? I would
think one would only call spin_lock_irq() in the irq handler and then
under limited circumstances (I could be wrong).
However, if you cannot take a spinlock in a work handler, then you must
acquire the spinlock in the irq handler, walk the list there to *collect
information* on the deferable work you must do, and then submit the
information about deferable work you need to do onto the work queue.
You can pass the information to the work-handler in a structure that
contains a struct work object plus the other data you need. If you use
a single-threaded work handler, then ordering of the work is preserved
by virtue of only one thread pulling work off of the work queue. The
normal multithreaed work-handling doesn't preserve ordering of the
For an example which you can look at:
In cx18, I used "work orders" that would be submitted to the deferable
work-handler. In struct cx18, you will see an array (pool) of
epu_work_orders for each device. All of the work handling and
scheduling is done in cx18-mailbox.c, IIRC.
> What is the proper way to protect access to this list?
To acquire the spinlock. If you don't, you invalidate a fundamental
assumption made by other code that accesses that list.
> it needed at all?
I would assume yes, but I haven't inspected the dvb code to verify.
> thanks for you input in advance,
> Mail: patrick.boettcher at desy.de
> WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/
More information about the linux-dvb