Re: [PATCH] generic device DMA (dma_pool update)

David Brownell
2002-12-31T23:09:06Z

>> Such a facility could be layered on top of your interface
>>perhaps by extending the mempool code to pass an extra parameter
>>around. If so, then you should think about arranging your interface
>>so that it could be driven with as little glue as possible by mempool.
>>
>
>
> What is that parameter? The size, I assume. To do that you'd
> need to create different pools for different allocation sizes.

In the other allocators it'd be the dma_addr_t for the memory
being returned ...

I don't think the mempool stuff needs that, see the fragments below.

> Bear in mind that mempool only makes sense with memory objects
> which have the special characteristic that "if you wait long enough,
> someone will free one". ie: BIOs, nfs requests, etc. Probably,
> DMA buffers fit into that picture as well.Inside the USB host controller drivers I think that mostly applies
to transfer descriptors (tds), which are freed when some other request
completes. An 8K buffer takes 1 (ehci), 2 (ohci) or 128 (uhci)
of those, and as you know scatterlists can queue quite a few pages.

I'd imagine mempool based td allocation might go like this; it should
be easy enough to slip into most of the HCDs:

void *mempool_alloc_td (int mem_flags, void *pool)
{
struct td *td;
dma_addr_t dma;

td = dma_pool_alloc (pool, mem_flags, &dma);
if (!td)
return td;
td->td_dma = dma; /* feed to the hardware */
... plus other init
return td;
}

void mempool_free_td (void *_td, void *pool)
{
struct td *td = _td;

dma_pool_free (pool, td, td->dma);
}

USB device drivers tend to either allocate and reuse one dma buffer
(kmalloc/kfree usage pattern) or use dma mapping ... so far.

- Dave