On Thu, 2012-03-08 at 17:59 -0700, Grant Likely wrote: > > > This would need some documentation. There is already "dma-ranges" > > > defined for OF which nay do what's needed. > > what is dma-ranges I see no doc about it > > but I don't think it could be used for the dma mask > > As Rob says, it's documented in ePAPR.
dma-ranges is generally defined for bridges to indicate the dma window to system memory, it's not been by actual devices so far. It provides the opposite of "ranges", ie a translation from children to parent address space. So it's not quite the same thing. Now the fact that we are limited to power-of-2 masks is a Linux implementation detail. We might want to make the device-tree a bit more flexible and use something like dma-limit instead. However hardware limits tend to be in term of number of bits anyways so it's not a big issue. I don't see a need to keep a "ranges" type of semantic. If we ever do that we can do a new binding for it or add a dma-base... > We could merely add an empty dma_mask u64 to the containing struct > platform_device and then assign the pointer to dev.dma_mask if it is > needed. That would eliminate the malloc. Agreed. > Or we could by default > use dev->dev.dma_mask = &dev->dev.coherent_dma_mask; Drivers or > notifier code could override whatever we setup here as the default. > > dma-ranges really is the property that should be used for this, but > dma-ranges can describe a different set of permutations than dma_mask. I don't think so. As I said, dma-ranges is about a bridge/bus exposing DMA windows & translations. It has nothing to do with the device intrinsic DMA'ing capabilities. Cheers, Ben. _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
