[linux-dvb] Re: CVS UNLOCKED

[Gerd Knorr <kraxel@bytesex.org>]

> >>   volatile unsigned long dma_pos; /* DMA write pointer in buffer
> >>[(current_dma_buffer+1)%num_dma_buffers] */

> Some DMA controllers can throw interrupts at programmable DMA buffer 
> watermarks, some not. For the latter ones this pointer is always zero, a 
> somewhat higher latency is the result.

I'd try to bring down the latency by using many small buffers instead of
having a pointer telling me how much of the currrent buffer is already
filled.  But, well, if the later is optional thats fine with me, I don't
care that much ...

> it's just the table that announces the buffer layout to both sides. 
> Usually you allocate one big chunk of DMA memory using 
> consistent_alloc() and all buffers are simply (sometimes page-aligned) 
> fixed-sized blocks inside this chunk.

consistent_alloc() is limited to 128k IIRC, which isn't that much ...

> You could as well allocate multiple chunks (but need to ensure that 
> their size is multiple of a page size and they are page-aligned) and 
> concatenate them in the remap() call.

Yep.

> >Hmm, while thinking about it, 188 is a odd number, so we might run in
> >trouble with page alignment.  Is that the reason for one entry per dma
> >buffer?  I'd still make all buffers the same size and then have a
> >table with just the offsets.

> How would you determine the size of each DMA buffer block then?

If the they are all equal-sized you don't need a size field for each
one, one global is enougth, so you can move that out of the table...

> by calling poll() or select()?

Fine.

  Gerd

-- 
#define printk(args...) fprintf(stderr, ## args)