lkml.org 
[lkml]   [2002]   [Dec]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] generic device DMA (dma_pool update)
Yes, that was exactly what I was demonstrating ... those are
the callbacks that'd be supplied to mempool_create(), showing
that it doesn't need to change for that kind of usage. (Which
isn't allocating DMA buffers, note!)

But we still need lower level allocators that are reasonable
for use with 1/Nth page allocations ... which isn't a problem
that mempool even attempts to solve. Hence dma_pool, in any of
its implementations, would go underneath mempool to achieve what
Adam was describing (for drivers that need it).

- Dave


Andrew Morton wrote:
> David Brownell wrote:
>
>> 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;
>> }
>
>
> The existing mempool code can be used to implement this, I believe. The
> pool->alloc callback is passed an opaque void *, and it returns
> a void * which can point at any old composite caller-defined blob.
>



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

\
 
 \ /
  Last update: 2005-03-22 13:32    [W:0.052 / U:13.316 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site