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

On Thursday 13 September 2012 14:22:57 Tomi Valkeinen wrote:

* PGP Signed by an unknown key

On Thu, 2012-09-13 at 15:08 +0900, Alex Courbot wrote:

quoted

On Thursday 13 September 2012 13:45:39 Tomi Valkeinen wrote:

quoted

quoted

Old Signed by an unknown key

On Wed, 2012-09-12 at 18:57 +0900, Alexandre Courbot wrote:

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.

The sequences are not board-specific, they are device (backlight, etc.)
specific. The sequences have been handled in board-specific hook
functions so far because there hasn't been proper drivers for the
devices.

If I were to take the same panel (and backlight) you have and install
it
on my board, I would need the same power sequence.

You could also have power sequences that control a set of GPIOs for an 
external interface (and would then be more board-specific), but you are
right 

What do you mean with "external interface"?

Any crazy circuit design that would make the regular power sequence not usable 
on a specific board. Sorry, I don't have any concrete example in mind, the 
above is just speculation.

But it's true that there can always be interesting board specific
hardware designs, and they truly are board specific. In my experience
these are quite rare, though, but perhaps not so rare that we wouldn't
need to care about them.

However, I fear these board specific things may be quite a bit anything,
so it may well be pwm, gpios and regulators are not enough for them. For
example, there could be an FPGA on the board which requires some
configuration to accomplish the task at hand. It could be rather
difficult to handle it with a generic power sequence.

Right. Note that this framework is supposed to be extended - I would like to 
at least add regulator voltage setting, and maybe even support for clocks and 
pinmux (but that might be out of place).

So I guess what I'm saying is that mostly these issues are device
specific, and when they are not, they may be rather complex/strange and
require c code.

You're definitely right about the powering issue being a device issue 99% of 
the time. For the rest I do not have enough insight to emit an opinion.

Alex.