On Wed, Oct 19, 2011 at 8:11 AM, Stephen Warren <swarren@xxxxxxxxxx> wrote:
> 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.
Sure, anything can probably be used so that's fine with me -- it won't
change the table walking code.
-Olof
--
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
