Re: [RFC] generic device DMA implementation

Adam J. Richter (adam@yggdrasil.com)
Fri, 6 Dec 2002 09:07:16 -0800


On Fri, 06 Dec 2002, James Bottomley wrote:
>adam@yggdrasil.com said:
>> I like your term DMA_CONSISTENT better than DMA_CONFORMANCE_CONSISTANT
>> . I think the word "conformance" in there does not reduce the time
>> that it takes to figure out what the symbol means. I don't think any
>> other facility will want to use the terms DMA_{,IN}CONSISTENT, so I
>> prefer that we go with the more medium sized symbol.

>I'm not so keen on this. The idea of this parameter is not to tell the
>allocation routine what type of memory you would like, but to tell it what
>type of memory the driver can cope with. I think for the inconsistent case,
>DMA_INCONSISTENT looks like the driver is requiring inconsistent memory, and
>expecting to get it. I'm open to changing the "CONFORMANCE" part, but I'd
>like to name these parameters something that doesn't imply they're requesting
>a type of memory.

How about renaming DMA_INCONSISTENT to DMA_MAYBE_CONSISTENT?

By the way, I previously suggested a flags field to indicate
what the driver could cope with. 0 would mean consistent memory, 1's
would indicate other things that the driver could cope with that would
be added if and when a real need for them arises (read caching, write
back cachine, cpu-cpu consistency, cache line size smaller than 2**n
bytes, etc.). Regarding the debugging capability of
DMA_CONFORMANCE_NONE, I don't think that will be as useful in the way
that DMA_DIRECTION_NONE is, because transfer direction is often passed
through the io path of a device driver and errors in doing so are a
common. In comparison, I think the calls to dma_malloc will typically
have this argument specified as a constant where the call is made,
with the possible exception of some allocation being consolidated in
the generic device layer.

Adam J. Richter __ ______________ 575 Oroville Road
adam@yggdrasil.com \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
-
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/