Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences

On Tue, Jul 31, 2012 at 05:37:07PM +0900, Alex Courbot wrote:

Hi Simon,

On 07/30/2012 08:00 PM, Simon Glass wrote:

quoted

For the delay, I think milliseconds is reasonable. I suppose there is
no reasonable need for microseconds?

I don't see any need for microseconds myself - anybody sees use for
finer-grained delays?

Btw, I noticed I was using mdelay instead of msleep - caught and fixed that.

You might want to take a look at Documentation/timers/timers-howto.txt.
msleep() isn't very accurate for periods shorter than 20 ms.

quoted

quoted

+Device tree
+-----------
+All the same, power sequences can be encoded as device tree nodes. The following
+properties and nodes are equivalent to the platform data defined previously:
+
+               power-supply = <&mydevice_reg>;
+               enable-gpio = <&gpio 6 0>;
+
+               power-on-sequence {
+                       regulator@0 {
+                               id = "power";

Is there a reason not to put the phandle here, like:

                                   id = <&mydevice_reg>;

(or maybe 'device' instead of id?)

There is one reason, but it might be a bad one. On Tegra, PWM
phandle uses an extra cell to encode the duty-cycle the PWM should
have when we call get_pwm().

This is not only the case on Tegra, but it is the default unless a
driver specifically overrides it. The second cell specifies the index of
the PWM device within the PWM chip. The third cell doesn't specify the
duty cycle but the period of the PWM.

This makes it possible to address the
same PWM with different phandles (and different duty cycles),

How so? A phandle will always refer to a PWM chip. Paired with the
second cell, of_pwm_request() will resolve that into the correct PWM
device.

which
causes an issue to know whether a PWM is already used in a sequence
(potentially resulting in multiple get_pwm calls on the same PWM,
and also opens the door to ambiguities in behavior (what is the
correct duty-cycle to use if several different values are passed?)

You can't request a PWM multiple times. The second call well return
-EBUSY, or rather ERR_PTR(-EBUSY).

Thierry