On Tue, Oct 18, 2011 at 2:01 PM, Stephen Warren <swarren@xxxxxxxxxx> wrote:
> Olof Johansson wrote at Tuesday, October 18, 2011 2:54 PM:
>> On Tue, Oct 18, 2011 at 11:54 AM, Stephen Warren <swarren@xxxxxxxxxx> 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@xxxxx {
>> > emc-tables {
>> > table-333@0 {};
>> > table-666@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@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.
Using compatible has one more benefit: It allows the data format to
change in the future if it has to, by bumping to a new compatible
string.
Also, since names have to be unique (due to lack of unit addressing),
the well-known-name is really a well-known-name-prefix. Using
compatible just seems cleaner.
> 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?
The main point of having one more level is to not have to iterate
through all tables to find which ones apply to the current ram-code
strapping. The cost of having another level is low, so it's not much
overhead.
I should revisit the pinmux patch, I suppose, and see if I agree with
the conventions there. :)
-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
