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

[David Brownell]

>>        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