Thread (16 messages) 16 messages, 4 authors, 2012-09-07

Re: [PATCH v5 1/4] Runtime Interpreted Power Sequences

From: Alex Courbot <acourbot@nvidia.com>
Date: 2012-09-07 08:02:42
Also in: linux-devicetree, linux-tegra, lkml

Hi Heiko,

On Thursday 06 September 2012 22:14:53 Heiko Stübner wrote:
Hi Alexander,

Am Freitag, 31. August 2012, 13:34:03 schrieb Alexandre Courbot:
quoted
Some device drivers (panel backlights especially) need to follow precise
sequences for powering on and off, involving gpios, regulators, PWMs
with a precise powering order and delays to respect between each steps.
These sequences are board-specific, and do not belong to a particular
driver - therefore they have been performed by board-specific hook
functions to far.

With the advent of the device tree and of ARM kernels that are not
board-tied, we cannot rely on these board-specific hooks anymore but
need a way to implement these sequences in a portable manner. This patch
introduces a simple interpreter that can execute such power sequences
encoded either as platform data or within the device tree.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
I really like this idea, also because I'll have to solve similar problems on
the way to dt for my tinker-platform.
Glad to read that! :)
For your power_seq_run function you write that it simply returns an error
code on failure and looking through it I also just found the error return
statement. This would leave a device half turned on.

So I'm wondering, if it shouldn't turn off all the things it turned on until
the step that produced the error. All your possible step types (execpt the
delay) are booleans, so it should be possible to simply negate them when
backtracking through the previous steps.
Indeed, I think you raised an important point. Right now all step types are 
invertible, but we cannot rely on that statement to be true forever. For 
instance, one short-term improvement will be to allow finer regulator control, 
like voltage setting. In this case, how can we go back to the initial state 
without recording it?

If e.g. the power on sequence fails at step N (of M steps for that sequence), 
one could try playing the corresponding power off sequence (either completely 
of from step M - N), but then again we cannot rely on sequences to be 
perfectly symetrical. Maybe this is more something for the calling driver to 
check for and control?

Alex.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help