Re: [PATCH v7 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes

[Stephen Warren <swarren@wwwdotorg.org>]

On 08/21/2013 04:57 PM, Scott Wood wrote:
> On Wed, 2013-08-21 at 16:40 -0600, Stephen Warren wrote:
>> On 07/29/2013 04:49 AM, hongbo.zhang@freescale.com wrote:

>>> +- ranges            : describes the mapping between the address space of the
>>> +                      DMA channels and the address space of the DMA controller
>>
>> Oh, so looking at the example, this is simply about being able to write
>> the reg value in the child nodes more easily without having to write out
>> the full based address of the controller in each child node.
>>
>> I don't think the binding document should require this;
> 
> It doesn't.  It just requires that there be a mapping; it doesn't have
> to be any particular mapping.
> 
>> all the binding document should care about is that the child nodes have a valid reg
>> value. Whether that reg value is <0x100100 0x80> without a ranges in the
>> top-level DMA
> 
> Without a ranges property there is no translation and the registers
> would not be memory mappable.  Linux may treat the absence of ranges as
> an identity mapping for compatibility with some broken OF trees, but
> it's not standard.

I would argue that missing ranges meaning 1:1 translation is now a
standard, given that it must be true to support some DTs, it therefore
can now be assumed?

>> nor or whether that reg value is <0x0 0x80> with a ranges
>> value in the top-level DMA node isn't something that the binding should
>> specify. Either way will work equally without affecting a driver for the
>> DMA controller; the parsing of reg with/without a ranges property is
>> more of a core part of DT than anything to do with this binding.
>>
>>> +- DMA channel nodes:
>>> +        - compatible        : must include "fsl,eloplus-dma-channel"
>>
>> Why do the channel nodes even need a compatible value? Presumably the
>> driver for the top-level DMA node will scan these dma-channel nodes to
>> extract the information it needs and will simply assume that all these
>> nodes are DMA channel nodes rather than something else? I suppose this
>> doesn't hurt, it just seems unnecessary unless you foresee other child
>> nodes types existing in the future and hence a need to differentiate
>> different types of nodes.
> 
> Other than "this is how the existing binding works and we're not going
> to break compatibility", it allows the OS more flexibility to choose
> whether to bind to controllers or directly to the channels.  Sometimes a
> channel will be labelled with a different compatible if it has a fixed
> purpose such as being connected to audio hardware (e.g. mpc8610_hpcd.dts
> where some channels are "fsl,ssi-dma-channel").

That sounds terribly like encoding policy into DT rather than it being a
HW description.