Trent Piepho wrote:
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?
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
mutex on your own ring buffer is localized to your instance of the driver. It
would be up to your drivers worker thread (instantiated and managed incidentally
by the demux core, not at irq level), to acquire the long term spinlock via
sw_filter_n (already in demux core) underdiscussion and NOT block a driver
calling demux->feedMyPersonalRingBuffer().
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
low bitrate low frequency buffer into your demux's personal ring buffer. That
has to be more efficient than the current drivers that feed sw_filter_n()
directly, but not ideal. It's a half-way-house solution that consolidates
complicated code into code, and keeps the drivers clean and easier to manage.
Trade off an infrequent memcpy on a low volume stream in < 50% of the drivers
for a simplified approach. You don't have to do this for every driver,
especially drivers that already implement videobuf_dvb, do it for the current
problematic drivers...... or, have a volunteer add videobuf_dvb to all of the
existing drivers.
- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
