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 deferable work. 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. > Is > it needed at all? I would assume yes, but I haven't inspected the dvb code to verify. Regards, Andy > thanks for you input in advance, > Patrick. > > -- > Mail: patrick.boettcher@xxxxxxx > WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ _______________________________________________ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@xxxxxxxxxxxxxxx linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
