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: <524408BE.40402@ti.com>
Date:	Thu, 26 Sep 2013 13:13:18 +0300
From:	Tomi Valkeinen <tomi.valkeinen@...com>
To:	Mike Dunn <mikedunn@...sguy.com>,
	Thierry Reding <thierry.reding@...il.com>
CC:	Richard Purdie <rpurdie@...ys.net>,
	Jingoo Han <jg1.han@...sung.com>,
	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <rob.herring@...xeda.com>,
	<linux-pwm@...r.kernel.org>, <linux-fbdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
	Robert Jarzmik <robert.jarzmik@...e.fr>,
	Marek Vasut <marex@...x.de>
Subject: Re: [PATCH] pwm-backlight: add support for device tree gpio control

On 11/09/13 14:40, Mike Dunn wrote:
> On 09/10/2013 10:21 AM, Thierry Reding wrote:

>> Do you have a real setup that actually needs multiple GPIOs? Usually
>> such a setup requires some kind of timing or other additional constraint
>> which can't be represented by this simple binding.
>>
>> Looking at the Palm Treo code it seems like the reason why multiple
>> GPIOs are needed is because one is to enable the backlight, while the
>> other is in fact used to enable the LCD panel. 
> 
> 
> There are actually four GPIOs involved!  (There is an embarrasingly horrible
> hack in arch/arm/mach-pxa/palmtreo.c that handles the others.)  One is almost
> certainly simply backlight power.  The other three are probably LCD related.

When you say "power", do you mean the gpio enables a regulator to feed
power to the backlight? If so, wouldn't that be a regulator, not gpio,
from the bl driver's point of view?

Generally speaking, this same problem appears in many places, but for
some reason especially in display. I'm a bit hesitant in adding "free
form" gpio/regulator support for drivers, as, as Thierry pointed out,
there are often timing requirements, or sometimes the gpios are
inverted, or sometimes the gpio is, in fact, a reset gpio, where you'll
assert the gpio for a short moment only.

I haven't seen new versions for the power sequences framework (without
DT support), I think it could help us here a bit by simplifying how we
present the sequences inside the driver. But we still need multiple
drivers or the same driver supporting multiple devices.

And I also think that the model where we have just one driver for, say,
backlight may not be enough. There may be multiple hardware components,
that used together will generate the backlight. And each component
requires specific management.

 Tomi



Download attachment "signature.asc" of type "application/pgp-signature" (902 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ