[PATCH] ARM: vexpress: initial device tree support

[Mitch Bradley]

On 9/21/2011 7:15 AM, Dave Martin wrote:
> On Wed, Sep 21, 2011 at 11:37:54AM -0500, Rob Herring wrote:
>> On 09/21/2011 09:57 AM, Grant Likely wrote:
>>> On Wed, Sep 21, 2011 at 7:24 AM, Rob Herring<robherring2 at gmail.com>  wrote:
>>>> On 09/21/2011 04:19 AM, Dave Martin wrote:
>>>>>        * arm,amba-bus -- widely used by other boards and patchsets, but
>>>>>          seems not to be documented.
>>>>>
>>>>
>>>> This should be dropped. There's not really any bus component to an amba
>>>> bus. All the probing info is within the primecell peripherals.
>>>
>>> No, if it is an AMBA bus, then it is entirely appropriate to declare
>>> it as an amba bus, but to also be compatible with "simple-bus".  In
>>> fact, it would be better to use a compatible string that specifies the
>>> specific implementation of AMBA bus since there are several versions
>>> of the spec.
>>
>> And type of AMBA bus as the spec includes AXI, AHB, and APB. None of
>> which have any sort of programmability or software view.
>>
>> If this is required, then the policy should be simple-bus should never
>> be allowed alone as every bus has some underlying type. Seems like
>> overkill for buses like this.
>
> The key question is _where_ to draw the line between generic and specific.
> By definition, the DT can never be a comprehensive description of the
> hardware -- rather a good DT is a description of those details of the hardware
> which could relevant to any hypothetical OS.
>
> The flipside is that details which were thought to be irrelevant at
> design/implementation time can turn out to be relevant in practice, due
> to errata and implementation issues etc.  So taking the description slightly
> beyond what the OS needs to know can still have some merit.
>
>
> I still don't know how to say where the line should be drawn in this particular
> case though.

Here are some criteria:

If the controller for the bus itself has registers, include the bus node

If it is possible to plug new stuff into the bus, include the bus node

If the base address for the bus can be changed, thereby changing all the 
addresses of its subordinates by the same offset, include the bus node 
(this usually goes along with "has registers".)

ARM buses typically don't have any of those attributes, but there are 
some weaker criteria that can be used to justify including a bus node. 
The SoC on which I'm currently working has some peripherals on AXI and 
others on APB.  That doesn't matter from that addressing standpoint - 
the individual peripherals can each be viewed as having an address, end 
of story - but it does matter from a power management standpoint.  The 
clock tree is quite related to the bus layout.  Including bus nodes in 
the device tree might provide useful place-holders for properties 
describing power or clock domains.

So, on the whole, I'm in favor of including bus nodes for ARM standard 
buses.  There is little down side to doing so, and a fair chance that it 
might come in handy in the future.

>
> Cheers
> ---Dave
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>