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

On Thu, 2012-09-13 at 09:29 +0200, Thierry Reding wrote:

On Thu, Sep 13, 2012 at 10:03:27AM +0300, Tomi Valkeinen wrote:

quoted

On Thu, 2012-09-13 at 09:00 +0200, Sascha Hauer wrote:

quoted

On Thu, Sep 13, 2012 at 09:54:09AM +0300, Tomi Valkeinen wrote:

quoted

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

quoted

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

quoted

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).

Yes, that's one concern of mine... I already can imagine someone
suggesting adding conditionals to the power sequence data. Perhaps also
direct memory read/writes so you can twiddle registers directly. And so
on. Where's the limit what it should contain? Can we soon write full
drivers with the DT data? =)

I have this concern aswell, that's why I'm sceptical about this patch
set. But what are the alternatives? Adding power code to the drivers and
thus adding board specific code to them is backwards.

As was pointed out in earlier posts in this thread, these are almost
always device specific, not board specific.

Do you have examples of board specific power sequences or such?

It is true that most (perhaps all) power sequences can be associated
with a specific device, but if we go and implement drivers for these
kinds of devices we will probably end up with loads of variations of
the same scheme.

Lets take display panels as an example. One of the devices that we build
has gone through two generations so far and both are slightly different
in how they control the panel backlight: one has an external backlight
controller, the other has the display controller built into the panel.
However, from the board's perspective the control of the backlight
doesn't change, because both devices get the same inputs (an enable pin
and a PWM) that map to the same pins on the SoC.

We had something a bit similar in Nokia. First versions had an
"independent" backlight controlled via pwm. Later versions had a
backlight that is controlled by the panel IP, so it was changed by
sending DSI commands to the panel.

This may not be a very good example because the timing isn't relevant,
but the basic point is still valid: if we provide a driver for both
panel devices, the code will be exactly the same. So we end up having to
refactor to avoid code duplication and use the same driver for a number
of backlight/panel combinations. Which in itself isn't very bad, but it
also means that we'll probably get to see a large number of "generic"
drivers which aren't very generic after all.

Another problem, which also applies to the case of power-sequences, is
that often the panel and backlight are not the same device. So you could
have the same panel with any number of different backlight controllers
or vice-versa any number of different panels with the same backlight
controller.

Yes, I think the backlight and the panel should be considered separate
devices. Just like, say, a touch screen and a panel may happen to be in
the same display module, a backlight and a panel can be in the same
display module. They are still separate, independent things, although
they are, of course, used together.

 Tomi