On Tue, 17 Feb 2009, Andreas Oberritter wrote: > Oliver Endriss wrote: > > 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. > > > > 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. Don't most drivers already feed the demuxer from process context and not the irq handler? What drivers _do_ have a problem? I see pluto2 is one. Anyone have documentation for this chip? > So, if the assumtions above are correct, then spin_lock_irq must be > used by all functions called from process context and > spin_lock_irqsave must be used by all functions called from an unknown > context. I agree, to be correct that's what's necessary. Some drivers call the demuxer functions from interrupt context, so we have to use the irq disabling functions everywhere. But disabling irqs for demuxing causes too much latency. The proper fix is to not call the demuxer from interrupt context. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
