On 07/12/2012 11:27 PM, Simon Glass wrote

quoted

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:

quoted

quoted

quoted

+               power-on-sequence = "REGULATOR", "power", <1>,
+                                   "DELAY", <10>,
+                                   "PWM", "backlight", <1>,
+                                   "GPIO", "enable", <1>;

About 106 bytes I think

quoted

quoted

     step@0 { 16

             type = "regulator"; 24

quoted

quoted

        phandle = <&backlight_reg>; 16
        enable = <1>; 16
        post-delay = <10>; 16
     }
     step@1 { 16

             type = "pwm"; 16

quoted

quoted

        phandle = <&pwm 2 5000000>; 24
     }
     step@2 { 16

             type = "gpio"; 20

quoted

quoted

        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.