Thread (45 messages) read the whole thread 45 messages, 7 authors, 2012-10-03

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

From: Alex Courbot <acourbot@nvidia.com>
Date: 2012-09-13 06:21:16
Also in: linux-devicetree, linux-tegra, lkml

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:
quoted
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 
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help