Google
  Web www.spinics.net

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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.

_______________________________________________
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

[Linux Media]     [Video 4 Linux]     [Video Technology]     [Asterisk]     [Photo]     [Samba]     [Xorg]     [Xfree86]     [Devices]     [DVB Maintainer]     [Linux USB]