Re: [RFC/PARTIAL PATCH 0/3] dma: passing "attributes" to dma_map_*routines

From: James Bottomley
Date: Tue Jan 08 2008 - 11:27:24 EST


On Mon, 2008-01-07 at 21:32 -0500, akepner@xxxxxxx wrote:
> The following patchset allows additional "attributes" to be
> passed to dma_map_*/dma_unmap_* implementations. (The reason
> why this is useful/necessary has been mentioned several
> times,
> most recently here:
> http://marc.info/?l=linux-kernel&m=119258541412724&w=2.)
>
> This is incomplete in that only ia64 and x86_64 are supported
> -
> the purpose is mainly to give us something specific to
> discuss.

I'm already on record saying I don't think attributes in the generic
code is the right approach. All of the attributes I can see adding are
bus specific (even to the extent that PCIe ones wouldn't apply to PCI
for instance). I really think the right approach is to sort out the
attribute infrastructure and not try to overload the generic DMA API. I
can certainly see that we might like to use it to take advantage of
other PCIe attributes (where available, of course).

Ultimately, it might be the best implementation course to pass the
attributes in to the dma_map routines, but I can't see them being
generic, they'd still be bus specific, so the correct way is to have a
bus specific attribute setup routine and pass some sort of opaque
attribute handle (or even just use the existing dma handle).

> The approach here is to change the dma_map_* interface so
> that the last argument is an u32 which encodes the direction
> of the dma and, optionally, other attributes. Changing the
> interface is a bit intrusive, but callers of dma_map_* don't
> need to be modified.
>
> There are 3 patches:
>
> [1/3] dma: create linux/dma-direction.h
> [2/3] dma: ia64/sn2 allow "attributes" to be used by dma_map_*
> [2/3] dma: x86_64 allow "attributes" to be used by dma_map_*

James

P.S. please update my email address: the @steeleye.com one no longer
works now.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/