Olof Johansson wrote at Wednesday, October 19, 2011 9:07 AM:
> On Wed, Oct 19, 2011 at 7:36 AM, Rob Herring <robherring2@xxxxxxxxx> wrote:
...
> > Using the frequency as was previously proposed would work assuming that
> > is unique.
>
> Someone suggested (off-list) to just use dummy addressing like cpu
> nodes do. Sounds reasonable to me.
>
> So:
>
> emc {
> compatible = "tegra20-emc";
> nvidia,use-ram-code;
> emc-tables@<ram-code> {
> nvidia,ram-code = < <ram-code> >;
> emc-table@<dummy enumerator> {
> compatible = "tegra20-emc-table";
> clock-frequency = < >;
> nvidia,emc-regs = < >;
> }
> }
>
> This also avoids having to handle 2-dimensional dummy numbering (i.e.
> <ramcode,table-number>) by breaking it in two levels:
>
> Where nvidia,use-ram-code is missing in the emc node, the immediate
> child nodes will be scanned for the compatible nodes
> Where nvidia,use-ram-code is present, first scan will be of all child
> nodes containing an nvidia,ram-code property, then from there treat it
> the same as the first case.
>
> In the above, none of the names have meaning, so they can be changed
> as needed (but these seem like a reasonably generic and descriptive
> name to me).
OK, I'm good with that general structure.
But, as Rob suggests, you may as well use the frequency instead of the
<dummy enumerator> for the unit address of the final tables, right?
The search algorithm might not care, but it'll be easier for humans
to read the resulting dts file.
--
nvpublic
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
