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:
> >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.
> >>+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
Attachment:
pgpv9E76YohF1.pgp
Description: PGP signature
