So instead of having fixed "power-supply" and "enable-gpio"
properties, how about having properties describing the power-on and
power-off sequences which odd cells alternate between phandles to
regulators/gpios/pwm and delays in microseconds before continuing
the sequence. For example:
power-on = <&pwm 2 5000000
10000
&backlight_reg
0
&gpio 28 0>;
power-off = <&gpio 28 0
0
&backlight_reg
10000
&pwm 2 0>;
Here the power-on sequence would translate to, power on the second
PWM with a duty-cycle of 5ms, wait 10ms, then enable the backlight
regulator and GPIO 28 without delay. Power-off is the exact
opposite. The nice thing with this scheme is that you can reorder
the sequence at will and support the weirdest setups.
I generally like the idea. I'm Cc'ing the devicetree-discuss mailing
list, let's see what people there think about it. I've also added Mitch
Bradley who already helped a lot with the initial binding.
What I don't know (device tree newbie here!) is:
1) Is it legal to refer the same phandle several times in the same node?
2) Is it ok to mix phandles of different types with integer values?
The DT above compiled, but can you e.g. resolve a regulator phandle
in the middle of a property?
I believe these shouldn't be a problem.
3) Can you "guess" the type of a phandle before parsing it? Here the
first phandle is a GPIO, but it could as well be the regulator. Do
we have means to know that in the driver code?
That isn't possible. But you could for instance use a cell to specify
the type of the following phandle.
Sorry for the long explanation, but I really wonder if doing this is
possible at all. If it is, then I think that's the way to do for
backlight initialization.
OTOH we basically end up describing a code sequence in the DT. But as
you mention above sometimes the hardware requires specific timing
parameters so this might actually be a kind of valid sequence to
describe in the DT.