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:	Tue, 5 Mar 2013 13:59:06 +0900
From:	Alex Courbot <acourbot@...dia.com>
To:	Andrew Chew <AChew@...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

On 03/05/2013 01:48 PM, Andrew Chew wrote:
> 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?

In one of my (many) attempts to add power sequencing to pwm-backlight, I 
just added a boolean to the platform data that must be explicitly set in 
order to enable control by GPIO. I.e.

	bool			use_enable_gpio
	int			enable_gpio;
	unsigned int		enable_gpio_flags;

enable_gpio and enable_gpio_flags would then only be considered if 
use_enable_gpio is true. Granted, it's not the best solution here but 
that's the only way to handle this correctly with integer GPIOS, and it 
does not pollute the DT anyway (use_enable_gpio will only be set by 
pwm_backlight_parse_dt() if of_get_named_gpio() returned a valid GPIO. 
Btw, you also want to check if the enable-gpio property exists first 
because otherwise probe() will fails if no GPIO is specified).

>> 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.

Well, if you can get this right and make the GPIO optional, I think this 
is a reasonable feature to have in pwm-backlight, until a more generic 
powerseq-backlight driver takes over. ;)

>>> 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.

I don't know the details of Dalmore but would think there must also be 
at least one regulator involved. If it is set to be always on in the DT, 
then your solution of using an enable GPIO should work then, even if not 
necessarily optimal wrt power usage.

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/