public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Courbot <acourbot@nvidia.com>
To: Andrew Chew <AChew@nvidia.com>
Cc: Thierry Reding <thierry.reding@avionic-design.de>,
	"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 13:59:06 +0900	[thread overview]
Message-ID: <51357B9A.8080004@nvidia.com> (raw)
In-Reply-To: <643E69AA4436674C8F39DCC2C05F7638629BFE1B11@HQMAIL03.nvidia.com>

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.


  reply	other threads:[~2013-03-05  4:59 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 [this message]
2013-03-05  5:14             ` Alex Courbot
2013-03-05  7:03             ` Thierry Reding

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=51357B9A.8080004@nvidia.com \
    --to=acourbot@nvidia.com \
    --cc=AChew@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thierry.reding@avionic-design.de \
    /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