linux-kernel - RE: [PATCH 1/1] pwm_bl: Add support for backlight enable GPIO

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]

Date:	Mon, 4 Mar 2013 20:48:52 -0800
From:	Andrew Chew <AChew@...dia.com>
To:	Alex Courbot <acourbot@...dia.com>
CC:	Thierry Reding <thierry.reding@...onic-design.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/1] pwm_bl: Add support for backlight enable GPIO

I sent out a new patch that enables/disables the backlight enable gpio.

> On 03/05/2013 01:00 PM, Andrew Chew wrote:
> > I did come to the same conclusion regarding the platform data breakage.
> > I'm expecting that the use of platform data will go away, at least on
> > ARM, since we are all aggressively moving what used to be in platform
> > data into the device tree.  Do other platforms use this driver?
> 
> I can see at least 29 users of platform_pwm_backlight_data, all ARM with the
> exception of one unicore32. I guess at least for the foreseeable future
> platform data will remain.

I'm not sure how to solve this, then.  Any suggestions?

> > I remember hearing that there is some work in progress to encapsulate
> > gpios into a struct, rather than passing it around as a bare integer,
> > so when that happens, we can use NULL for no-gpio, which should take
> > care of the platform data issue as well.  It's kind of difficult to
> > work around this problem otherwise.
> 
> Yes, actually I am doing the GPIO rework. If you are not too much in a hurry
> you might want for it to happen (should not be too long now that the core
> has been reworked). At the same time, GPIO descriptors will also enable the
> power sequences, so if you wait even longer (or help me with it), this patch
> might not even be needed at all. Of course if you want to support this
> *now*, this is still the shortest path.

Sadly, I do need this now, and I'd rather do it as cleanly as possible rather
than maintaining a hack.  The project I am working on is very pedantic.

> > I agree that we should be turning on and off the backlight enable gpio
> > as needed to save power.  I just haven't gotten there yet.  I can try
> > to modify this patch if that's your preference, or I can follow up
> > with a patch to add this in the very near future.
> 
> That's ultimately for Thierry to say, but submitting a new revision makes
> more sense IMHO - it is not a big change and there are other issues to
> address (uninitialized GPIO in platform data) anyway.

Done.

> > To answer your last question, yes, this single patch does allow me to
> > enable the backlight on some boards (in particular, the one I'm working
> on).
> 
> Cool - may I ask which one? All the NV boards I tried to far required more
> complex sequences for their panels.

This is for t114-dalmore.  There may be other gpios that are needed that I'm
not aware of off the top of my head.  For the backlight itself, this seems to
be the only one.
--
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/