[PATCH v6 0/4] Runtime Interpreted Power Sequences

[Alex Courbot]

On Thursday 13 September 2012 13:50:47 Tomi Valkeinen wrote:
> * PGP Signed by an unknown key
> 
> On Wed, 2012-09-12 at 18:57 +0900, Alexandre Courbot wrote:
> 
> > New revision of the power sequences, taking as usual the feedback that
> > was
> > kindly provided about the last version.
> > 
> > I think now is a good time to discuss integrating this and to start
> > looking for a maintainer who would be willing to merge this into his/her
> > tree (I am especially thinking about the power framework maintainers,
> > since this is where the code is right now. The second patch in this
> > series enables the pwm_backlight driver to be used with the device tree,
> > without relying on board-dependent callbacks to support complex power
> > sequences. We also plan to use power sequences in other Tegra drivers,
> > and other people have expressed interest in this work during earlier
> > reviews. See for instance
> > 
> > https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-
August/018532.html 
> > and
> > 
> > https://lkml.org/lkml/2012/9/6/270
> > 
> > There is probably some more details to fix and improve, but the current
> > shape should be enough to know if we want this and where - therefore any
> > sign from a maintainer would be greatly appreciated!
> 
> 
> I want to reiterate my opinion that I think power sequences in DT data
> is the wrong way to go. Powering sequences are device specific issues
> and should be handled in the device driver. But I also think that power
> sequences inside the drivers would probably be useful.

I understand the logic behind handling powering sequences in the device 
driver, but as we discussed for some classes of devices this might just not 
scale. I don't know how many different panels (each with different powering 
sequences) are relying on pwm_backlight, but the alternative of embedding 
support for all of them into the kernel (and bloating the kernel image) or 
having a 3 kilometers list in the kernel configuration to individually chose 
which panel to support (which would be cumbersome and make the kernel less 
portable across boards) does not look much appealing to me. With power 
sequences encoded in the DT, we could have one .dtsi file per panel that would 
be included from the board's .dts file - no bloat, no drivers explosion, 
portability preserved.

DT support is actually the main point of power sequences, as outside of the DT 
we can always work the old way and use callbacks. If we were to remove DT 
support, I am not sure this work would still be worth being merged.

Alex.