Hi Simon,
On Thu 12 Jul 2012 06:37:33 PM JST, Simon Glass wrote:
I would like to do something similar in U-Boot for Tegra, although
perhaps not right away. For now I will go with something considerably
simpler! But if this is merged into the kernel we will move to it in
U-Boot.
Cool, I'd love to see that used in U-Boot as well.
+ default-brightness-level = <12>;
+
+ pwms = <&pwm 2 5000000>;
+ pwm-names = "backlight";
+ power-supply = <&backlight_reg>;
+ enable-gpios = <&gpio 28 0>;
+
+ power-on-sequence = "REGULATOR", "power", <1>,
+ "DELAY", <10>,
+ "PWM", "backlight", <1>,
+ "GPIO", "enable", <1>;
So the names REGULATOR, DELAY, etc. here are looked up through some
existing mechanism? In general I am not a big fan of mixing strings
and numbers in a property.
Yes, these are strings we are looking up to know the type of the next
element to power on/off in the sequence. I don't like these, honestly,
and would rather have them replaced by constants - however there is no
way to define constants in the DT AFAIK (but I have heard some other
persons are interested in having them too), and this is the only way I
have found to keep the sequence readable.
Maybe something like:
power_on_sequence {
step@0 {
phandle = <&backlight_reg>;
enable = <1>;
post-delay = <10>;
}
step@1 {
phandle = <&pwm 2 5000000>;
}
step@2 {
phandle = <&gpio 28 0>;
enable = <1>;
}
I see a few problems with this: first, how do you know the types of your
phandles? At step 0, we should get a regulator, step 1 is a PWM and step
2 is a GPIO. This is why I have used strings to identify the type of the
phandle and the number (and type) of additional arguments to parse for a
step.
Second, I am afraid the representation in memory would be significantly
bigger since the properties names would have to be stored as well (I am
no DT expert, please correct me if I am wrong). Lastly, the additional
freedom of having extra properties might make the parser more complicated.
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.
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
