linux-kernel - Re: [PATCH v4 1/3] Runtime Interpreted Power Sequences

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1562509.b0FYTUZ1D8@percival>
Date:	Tue, 21 Aug 2012 17:22:12 +0900
From:	Alex Courbot <acourbot@...dia.com>
To:	Tomi Valkeinen <tomi.valkeinen@...com>
CC:	Stephen Warren <swarren@...dia.com>,
	Thierry Reding <thierry.reding@...onic-design.de>,
	Simon Glass <sjg@...omium.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Anton Vorontsov <cbou@...l.ru>,
	David Woodhouse <dwmw2@...radead.org>,
	Arnd Bergmann <arnd@...db.de>,
	Leela Krishna Amudala <leelakrishna.a@...il.com>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v4 1/3] Runtime Interpreted Power Sequences

Hi Tomi,

On Tuesday 21 August 2012 15:44:29 Tomi Valkeinen wrote:
> > +Problem
> > +-------
> > +One very common board-dependent code is the out-of-driver code that is
> > used to +turn a device on or off. For instance, SoC boards very commonly
> > use a GPIO +(abstracted to a regulator or not) to control the power
> > supply of a backlight, +disabling it when the backlight is not used in
> > order to save power. The GPIO +that should be used, however, as well as
> > the exact power sequence that may +also involve other resources, is
> > board-dependent and thus unknown of the driver. +
> > +This was previously addressed by having hooks in the device's platform
> > data that +are called whenever the state of the device might reflect a
> > power change. This +approach, however, introduces board-dependant code
> > into the kernel and is not +compatible with the device tree.
> 
> I've been having the same problems on OMAP display related code, but the
> problem has always been fixable by just having the driver to use a
> common framework to do the job (a framework which may not have existed
> at the time). The problems have never been board specific in the end,
> but device specific.
> 
> Can you describe your particular HW problem a bit more? In the backlight
> case, what exactly requires the delays and the sequence you show in the
> example to enable/disable the backlight?

In the example, the sequence (including delays) is clearly stated by the 
backlight specification, which is part of the panel specification. The backlight 
uses a PWM, which makes it suitable to use the generic PWM backlight driver, 
but how to turn the backlight on and off is very backlight specific. The power 
sequences allow to replace the board-specific backlight callbacks by sequences 
in the DT.

On the other hand, I saw your discussion with Laurent about the panel 
framework, and I wonder how this would fit into it. Backlights are typically 
embedded within panels. Power sequences are a good way to deal with the 
absence of specific drivers for every panels, since they allow to tailor the 
behavior of generic drivers to fit particular needs. But if every panel comes 
with its own driver (which would define the backlight device using the most 
appropriate driver), then it could just as well perform its backlight's 
sequences via regular callbacks. In this particular case, there would be no 
need for power sequences.

Power sequences are supposed to go beyond backlight drivers and support all 
sort of devices (I have heard that it could be useful for modems as well), but 
I wonder how relevant they are when there is a proper driver for a device. I 
hate to question my own work but now I cannot help but think that a proper 
driver could do the same job. So what are we trying to achieve with power 
sequences? Are we trying to avoid a drivers' explosion by keeping some of the 
specifics out of them? Which approach would be preferable? Are there cases 
where a dedicated driver could not replace power sequences?

Alex.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/