Re: updated dma to user space API

[Sebastien R. <Seb...@sy...>]

>>>>> "Andreas" == Andreas Bombe <and...@mu...> writes:

Andreas> On Tue, Apr 25, 2000 at 08:14:57PM +1000, Sebastien Rougeaux wrote:
>>  I have updated the API for the direct iso dma to user space feature that
>> is available for the ohci driver. Previously the buffer filling was running
>> continuously in the driver, and the user app was only waiting for irq
>> generated for each frame. The problem was doing so you could easily create
>> synchronization problems. Now the user app has to queue the buffers for
>> each frame. If the user app can not keep up with the framerate, the dma
>> context will wait until fresh buffers are queued. It is very similar to the
>> video4linux API.

Andreas> Is there anything special about this DMA?  I guess it just does
Andreas> header stripping instead of giving the complete packet like libraw
Andreas> does.  Strictly seen it's also not DMA to user space but having
Andreas> kernel buffers mapped to user space (what I intended to do for libraw
Andreas> once I figure it out and get to it).

Strictly speaking yes... Is there anything wrong with that ? It is what
framegrabber drivers like bttv are doing... anyway I don't know any other 
way of doing it. If this feature could be included in libraw, it would
be good...

Andreas> What I have problems with is that it duplicates a lot of bttv code,
Andreas> something Linus probably will also complain about.  Plus, from my
Andreas> understanding, the bttv code handles a lot of cases which are not
Andreas> required for OHCI hardware.

Yes it duplicates the bttv code for the buffer allocation and mapping.
Again, if there is such function in the kernel, I would be happy to
use it. If not we have to write something anyway... 
 
Andreas> What I have in mind for better iso receiving is something like a
Andreas> manager part in the subsystem handing out chunks of 64kB (or
Andreas> something, should be tunable) contiguous mem to the hardware drivers
Andreas> which receive iso packets into those.  When the remaining space in
Andreas> the chunk is too small for more packets, the driver tells the
Andreas> subsystem and gets a new chunk.

Andreas> The filled chunks have then a soft and a hard reference count.  The
Andreas> soft count indicates that someone is interested in the contained data
Andreas> at all (otherwise it could just as well be freed immediately).  The
Andreas> hard count indicates that it must not be freed at this time
Andreas> (e.g. it's mapped to user space by raw1394 currently).  If a limit is
Andreas> reached or memory gets low the oldest chunks with soft references but
Andreas> no hard refs can be freed (i.e. packets get lost).

Sounds good. My code is temporary anyway (I needed the functionality ASAP so 
I wrote it as fast as I could). If you come up without something similar with
no loss of performance, I'll be very interested. The important part for me 
is that the driver:

    . allows multi-buffering (tunable)
    . doesn't waste CPU time
    . does frame synchronization

-- 
Sebastien Rougeaux
RSISE, The Australian National University