bus_dmamem_alloc

[Jason Harmening]

On Wednesday 11 June 2008, John-Mark Gurney wrote:
>
> Why not use the SRAM for this?  That's what my driver does...  w/ 32k
> SRAM, it's more than enough for more programs...

The DMA programs (or at least a significant chunk of them) will get stored in 
the SRAM, if there's enough room.  That's often the case with just MPEG TS, 
but once you add analog video there's usually not enough room.

>
> > For case 1), I malloc(9) the buffers and then feed them to busdma, since
> > on most machines bus_dmamem_alloc just calls contigmalloc.  Use of
> > malloc(9) is suboptimal as it may result in bounce buffering for
> > non-IOMMU machines with large amounts of RAM.
>
> I prefer to do direct to use DMA as it saves on allocating a buffer in
> the kernel, and then coping the data from that buffer...

The driver actually supports both.  Kernel-mode buffers are mmap'ed, so there 
shouldn't be a copy.  Of course user-mode buffers can still bounce...

> > 1)  Would it be possible to provide a bus_dmamem_alloc overload that
> > takes a size parameter?   We could call it bus_dmamem_alloc_size and have
> > bus_dmamem_alloc just call bus_dmamem_alloc_size with dmat->maxsize to
> > preserve source-level compatibility with existing drivers.
>
> It would be nice, but hasn't been something someone has gotten around to
> implementing yet...

That's probably my only real complaint here--it seems like dmat->maxsize 
should just be a restriction, not an allocation unit.  I don't want to sound 
ungrateful--busdma, at an API level at least, is great compared to what other 
OSes have to offer.

>
> I know that one person recently was working on Intel's VT IOMMU and I
> thought it was close to being committed, but I haven't been following
> the work...

That'll be awesome when it's ready.