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