>> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Dec 31 2002 - 22:00:20 EST