Trent Piepho wrote: > On Sun, 15 Feb 2009, Oliver Endriss wrote: > > e9hack 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). > > > > @Mauro: > > > > 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! > > 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.
Agreed, this would be the best solution. On the other hand, a workqueue handler would be scheduled later, so you need larger buffers in the driver. Some chipsets have very small buffers... Anway, this would be a major change. All drivers must be carefully modified and tested for an extended period. Meanwhile I had a look at the changeset, and I do not understand why spin_lock_irq... should be required everywhere. Afaics a driver may safely call dvb_dmx_swfilter_packets, dvb_dmx_swfilter_204 or dvb_dmx_swfilter from process context, tasklet or interrupt handler 'as is'. @Andreas: Could you please explain in more detail what bad things might happen? CU Oliver -- ---------------------------------------------------------------- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ ---------------------------------------------------------------- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
