On 07/12/2012 11:27 PM, Simon Glass wrote
I agree the type strings are a problem in the current form - if we could get
constants in the device tree, that would be much better. Your way of
representing the sequences is interesting though, if we can solve the type
issue (and also evaluate its cost in terms of memory footprint), it would be
interesting to consider it as well.
At a guess:
+ power-on-sequence = "REGULATOR", "power", <1>,
+ "DELAY", <10>,
+ "PWM", "backlight", <1>,
+ "GPIO", "enable", <1>;
About 106 bytes I think
step@0 { 16
type = "regulator"; 24
phandle = <&backlight_reg>; 16
enable = <1>; 16
post-delay = <10>; 16
}
step@1 { 16
type = "pwm"; 16
phandle = <&pwm 2 5000000>; 24
}
step@2 { 16
type = "gpio"; 20
phandle = <&gpio 28 0>; 24
enable = <1>; 16
}
220?
I compiled both versions to try it out. Your version was just 50 bytes
larger than mine (I assumed that with yours, we would be able to remove
the top-level pwm/regulator/gpio definitions that are referred by the
sequence). The question here is do we want to have something more
DT-ish, or are we trying to save every possible byte in the DT structure?
As Thierry also mentionned, we are trying to provide the same feature
using the platform interface. I am not sure how we can elegantly support
both ways through this.
From my understanding mixing strings and numbers in a property is
frowned on though.
But doesn't it make sense in the current case? The power sequence is
basically a program that is run by an interpreter. From this
perspective, it makes more sense to me to have it as a binary field
rather than a hierarchy of nodes and properties that will be harder to
parse and will make error detection more complicated. I don't really see
any practical benefit from turning the steps into sub-nodes, but then
again I am not so familiar with the DT.
Alex.
--
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
