From: Thierry Reding <thierry.reding@avionic-design.de>
To: Alex Courbot <acourbot@nvidia.com>
Cc: Andrew Chew <AChew@nvidia.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] pwm_bl: Add support for backlight enable GPIO
Date: Tue, 5 Mar 2013 08:03:08 +0100 [thread overview]
Message-ID: <20130305070308.GA7212@avionic-0098.mockup.avionic-design.de> (raw)
In-Reply-To: <51357B9A.8080004@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 2192 bytes --]
On Tue, Mar 05, 2013 at 01:59:06PM +0900, Alex Courbot wrote:
> 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).
There are two more options that I can see. The first involves updating
all users to initialize the GPIO to -1 in the platform data, which will
remove the requirement for an extra flag field. Another option would be
to make this feature DT only, so that the GPIO can always be assumed to
be -1 for non-DT and DT without an enable-gpio property.
There's a third alternative, namely using a regulator for this, which
has better lookup support and therefore should be easier to make
optional. And as Alex mentioned it already has support for always-on
functionality and such.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
prev parent reply other threads:[~2013-03-05 7:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-04 21:49 [PATCH 1/1] pwm_bl: Add support for backlight enable GPIO Andrew Chew
2013-03-04 22:46 ` Thierry Reding
2013-03-05 2:59 ` Alex Courbot
2013-03-05 4:00 ` Andrew Chew
2013-03-05 4:40 ` Alex Courbot
2013-03-05 4:48 ` Andrew Chew
2013-03-05 4:59 ` Alex Courbot
2013-03-05 5:14 ` Alex Courbot
2013-03-05 7:03 ` Thierry Reding [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130305070308.GA7212@avionic-0098.mockup.avionic-design.de \
--to=thierry.reding@avionic-design.de \
--cc=AChew@nvidia.com \
--cc=acourbot@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox