[RFC] [PATCH] ARM: tegra: emc: device tree bindings

[Stephen Warren]

Olof Johansson wrote at Tuesday, October 18, 2011 2:54 PM:
> On Tue, Oct 18, 2011 at 11:54 AM, Stephen Warren <swarren at nvidia.com> wrote:
> > Olof Johansson wrote at Tuesday, October 18, 2011 12:43 PM:
...
> >> Compatible is still needed, in my opinion -- otherwise there will be
> >> no way to tell if the node is there to describe emc timings or if it's
> >> some new node used to describe something else (such as SDRAM chips as
> >> mentioned above).
> >
> > Can't you go by node name; enumerate all nodes with a particular name.
> > Or define another intermediate node that will always contain tables and
> > nothing else, then just enumerate all child nodes of that node:
> >
> > emc at xxxxx {
> >    emc-tables {
> >        table-333 at 0 {};
> >        table-666 at 0 {};
> >    };
> > };
> >
> > The Tegra pinmux bindings I proposed certainly used this technique; a
> > main node with a well-known name, followed by enumeration of all child
> > nodes of that, and nobody /said/ anything about that being a bad idea.
> 
> I'm not really picky on this, but I think I would rather use a
> compatible field than rely on naming.
> 
> That being said, doing a two-level approach will probably make it
> easier than the flat structure I initially had. So:
> 
> emc at xxx {
>     nvidia,use-ram-code;
>     emc-table-ram-code-0 {
>         nvidia,ram-code = < 0 >;
>         table-166 { compatible = "tegra20-emc-table"; ... };
>         table-333 { ... };
>     };
> 
>     emc-table-ram-code-1 {
>         nvidia,ram-code = < 1 >;
>         ...
>     };
> };
> 
> ... and for none-ram-code, just leave out the emc-table-ramcode-x level.
> 
> So, for nvidia,use-ram-code case, it'll be one intermediate step of
> finding the right subnode, the rest of the table setup code will be
> common. None of it will be bound to actual node names though -- first
> step is iterating child nodes looking for nvidia,ram-code properties
> to match, and second step iterates by matching compatible fields.

I only suggested the well-known-named sub-nodes in order to eliminate
the need for a compatible property.

My inclination is that if we use compatible to distinguish the tables
from anything else, there's little point having the extra level of nodes;
we may as well lay it out as in your original patch, just with an explicit
nvidia,ram-code property in each table (or omitted/ignored when not using
it) instead of reg?

-- 
nvpublic