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

Trent Piepho xyzzy at speakeasy.org
Wed Feb 18 03:32:14 CET 2009


On Tue, 17 Feb 2009, Steven Toth wrote:
> Trent Piepho wrote:
> > On Mon, 16 Feb 2009, Steven Toth wrote:
> >>> Hartmut, Oliver and Trent: Thanks for helping with this issue. I've just
> >>> reverted the changeset. We still need a fix at dm1105, au0828-dvb and maybe
> >>> other drivers that call the filtering routines inside IRQ's.
> >> Fix the demux, add a worker thread and allow drivers to call it directly.
> >>
> >> I'm not a big fan of videobuf_dvb or having each driver do it's own thing as an
> >> alternative.
> >>
> >> Fixing the demux... Would this require and extra buffer copy? probably, but it's
> >> a trade-off between  the amount of spent during code management on a driver by
> >> driver basis vs wrestling with videobuf_dvb and all of problems highlighted on
> >> the ML over the last 2 years.
> >
> > Have the driver copy the data into the demuxer from the interrupt handler
> > with irqs disabled?  That's still too much.
> >
> > The right way to do it is to have a queue of DMA buffers.  In the interrupt
> > handler the driver takes the completed DMA buffer off the "to DMA" queue
> > and puts it in the "to process" queue.  The driver should not copy and
> > cetainly not demux the data from the interrupt handler.
>
> I know what the right way is Trent (see cx23885) although thank you for
> reminding me. videobuf_dvb hasn't convinced people like me to bury myself in its
> mess or complexity during retro fits cases. Retro fitting videobuf_dvb into cx18
> (at the time) was way too much effort.
>
> Retro fitting it into existing drivers can be painful and I haven't seen any
> volunteers stand up over the last 24 months to get this done.
>
> My suggestion? For the most part we're talking about very low data rates for
> DVB, coupled with fast memory buses for memcpy's. If the group doesn't want
> calls to the sw_filter methods then implement a half-way-house replacement for
> those drivers - as I mentioned above - with the memcpy. Either this approach, or

The problem is holding a spin lock with irqs disabled for a long amount of
time.  What exactly is your plan that will remove this, yet allow drivers
to process their buffers from an irq handler?

> A general question to the group: Who wants to volunteer to retro fit
> videobuf_dvb into the current drivers so we can avoid calls to sw_filter_...n()
> directly?

I don't see why videobuf_dvb is needed.



More information about the linux-dvb mailing list