On Wed, 18 Feb 2009, Steven Toth wrote:
> Trent Piepho wrote:
> > On Tue, 17 Feb 2009, Steven Toth wrote:
> >> Trent Piepho wrote:
> >>> On Mon, 16 Feb 2009, Steven Toth wrote:
> >>>> 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?
>
> That's not what I was suggesting. I was suggesting adding some ring buffer 
> code
> and a worker thread for each driver context (done in a mythical 
> demux->register
> func). This means that each driver get's it's own worker and ringbuffer. 
> Driver

But won't this new ringbuffer be fed from interrupt context?  So instead of
feeding the demuxer from an irq, you are feeding the pre-demuxer ringbuffer
from an irq.  Isn't that going to have the same long term lock holding with
irqs disabled problem?

> >> 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.
>
> That was the point I was trying to make. IE. Push videobuf_dvb like behavior
> into the demux core, having drivers register, give each driver it's own worker
> thread and have that thread, running not in the interrupt context, feed the
> existing sw_filter_n() functions. The price is the cost of doing a memcpy of a

If you look at the pluto2 fix I did, the code to create a work queue is
very simple.  I don't think moving that to the demuxer would make the patch
to the driver much simpler.

The difficulty comes from not using a single buffer so the driver doesn't
need to hold a spin lock while it copies data out.
--
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

Reply via email to