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

David Brownell (david-b@pacbell.net)
Tue, 31 Dec 2002 13:17:47 -0800


James Bottomley wrote:
> david-b@pacbell.net said:
>
>>You didn't make anything store or return the dma_addr_t ... that was
>>the issue I was referring to, it's got to be either (a) passed up from
>>the very lowest level, like the pci_*() calls assume, or else (b)
>>cheaply derived from the virtual address. My patch added slab support
>>in common cases where (b) applies.
>
>
> That's fairly simply done as part of the wrappers: The allocator stores the
> vaddr, paddr and size in a hash table. Thus, the paddr can be deduced when
> kmem_cache_alloc is called by the allocation wrapper using the linearity
> property.

However it'd be done, it'd be an essential part, and it was missing. In fact,
your getpages() didn't have a way to return the dma_addr_t values, and your
freepages() didn't provide it as an input. (But it did pass mem_flags in, as
I had at some point suggested should be done with dma_alloc_coherent.)

> I've got to say though that the most sensible course of action is still to
> generalise pci_pool, which can be done easily and safely. I think replacing
> it with a slab based scheme is probably a 2.7 thing.

I think the patch I posted "easily and safely" does that, appropriate for 2.5,
even though some platforms can't yet collect that win.

I'd agree that morphing drivers/pci/pool.c into drivers/base/pool.c (or whatever)
would be appropriate, but I haven't heard any arguments to justify using that
allocator on systems where the the slab code can be used (more cheaply).

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