[linux-dvb] [BUG] changeset 9029 (http://linuxtv.org/hg/v4l-dvb/rev/aa3e5cc1d833)

Trent Piepho xyzzy at speakeasy.org
Wed Feb 18 10:15:57 CET 2009

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.

More information about the linux-dvb mailing list