standard property to convey device dma address width?

[Mitch Bradley]

Kumar Gala wrote:
> On Aug 16, 2010, at 3:17 PM, Mitch Bradley wrote:
>
>   
>> Kumar Gala wrote:
>>     
>>> Do we or should we have a standard property to convey that address width a device is capable of?
>>>  
>>>       
>> ...
>> If I had to describe a partial address, I'd consider a property name like "dma-address-mask", whose value is a bitmap of implemented bits, corresponding to the bits in a unit address for the parent bus.  Low-order bits might be zero if the DMA addressing hardware had alignment restrictions.
>>     
>
> As I said to Stuart.  On the Freescale SOCs we have different device blocks w/varying dma address capabilities.  Some are limited to 32-bits some are capable of 36-bits on the same SOC.
>
> - k
>
>   

The closest existing property that I know of is "dma-ranges" - see 
http://playground.sun.com/1275/proposals/Closed/Accepted/410-it.txt

That's not directly applicable, as "dma-ranges" in its current form 
applies to bus bridges, describing the translation between DMA addresses 
on a child bus to DMA addresses on a parent bus.

The case in question has some general similarities, in that the limited 
devices have an implicit 32-bit "child bus" that is translated to the 
36-bit parent bus, presumably by concatenating zeros in bits 35:32.  Is 
that correct, i.e. are the high bits implicitly 0?

The dma-ranges representation doesn't assume the "zero-extend" property, 
but rather explicitly lists child-base-address,parent-base-address,size 
triples.  I wonder if that generality is justifiable in this case?

I see several obvious representations with varying degrees of generality:

a) boolean property saying "this is one of those 32-bit only devices, 
with all the implications"
b) width in bits - assumes an implicit translation rule (e.g. zero-extend)
c) bitmask - assumes implicit translation rule, capable of representing 
alignment restrictions with low-order zeros
d) something like dma-ranges - explicitly represents translation rule, 
no representation for alignment restriction

My 2 cents: Generality is often only justified when you have a good 
collection of problem instances, so you can amortize the generality over 
several specific known examples.  Otherwise you often end up 
implementing something elaborate that never gets used.