public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Courbot <acourbot@nvidia.com>
To: Thierry Reding <thierry.reding@avionic-design.de>
Cc: Andrew Chew <AChew@nvidia.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1 v4] pwm_bl: Add support for backlight enable regulator
Date: Thu, 7 Mar 2013 19:11:25 +0900	[thread overview]
Message-ID: <513867CD.4030201@nvidia.com> (raw)
In-Reply-To: <20130307071102.GB3451@avionic-0098.mockup.avionic-design.de>

On 03/07/2013 04:11 PM, Thierry Reding wrote:
>> +	bool			en_supply_enabled;
>
> This boolean can be dropped. As discussed in a previous thread, the
> pwm-backlight driver shouldn't need to know about any other uses of the
> regulator.

Sorry for being obstinate - but I'm still not convinced we can get rid 
of it. I checked the regulator code, and as you mentioned in the 
previous version, calls to regulator_enable() and regulator_disable() 
*must* be balanced in this driver.

Without this variable we would call regulator_enable() every time 
pwm_backlight_enable() is called (and same thing when disabling). Now 
imagine the driver is asked to set the following intensities: 5, 12, 
then 0. You would have two calls to regulator_enable() but only one to 
regulator_disable(), which would result in the enable GPIO remaining 
active even though it would be shut down. Or I missed something obvious.

The regulator must be enabled/disabled on transitions from/to 0, and 
AFAICT there is no way for this driver to detect them.

>> +static void pwm_backlight_enable(struct backlight_device *bl)
>> +{
>> +	struct pwm_bl_data *pb = dev_get_drvdata(&bl->dev);
>> +
>> +	pwm_enable(pb->pwm);
>> +
>> +	if (pb->en_supply && !pb->en_supply_enabled) {
>> +		if (regulator_enable(pb->en_supply) != 0)
>> +			dev_warn(&bl->dev, "Failed to enable regulator");
>> +		else
>> +			pb->en_supply_enabled = true;
>> +	}
>> +}
>> +
>> +static void pwm_backlight_disable(struct backlight_device *bl)
>> +{
>> +	struct pwm_bl_data *pb = dev_get_drvdata(&bl->dev);
>> +
>> +	if (pb->en_supply && pb->en_supply_enabled) {
>> +		if (regulator_disable(pb->en_supply) != 0)
>> +			dev_warn(&bl->dev, "Failed to disable regulator");
>> +		else
>> +			pb->en_supply_enabled = false;
>> +	}
>> +
>> +	pwm_disable(pb->pwm);
>> +}
>
> Alex already brought this up: shouldn't the sequences be reversed. That
> is, when enabling the backlight, turn on the regulator first, then
> enable the PWM. When disabling, disable the PWM first, then turn off the
> regulator?

Actually the current sequence seems to make sense - the PWM is always 
active when the enable GPIO is switched. If we do the contrary, we might 
have a short time where the backlight is enabled without receiving 
anything from the PWM. Don't think that would be serious, but the 
current behavior is similar to e.g. panels which we enable only after a 
signal is available.

>> @@ -213,6 +238,13 @@ static int pwm_backlight_probe(struct platform_device *pdev)
>>   	pb->exit = data->exit;
>>   	pb->dev = &pdev->dev;
>>
>> +	pb->en_supply = devm_regulator_get(&pdev->dev, "enable");
>> +	if (IS_ERR(pb->en_supply)) {
>> +		ret = PTR_ERR(pb->en_supply);
>> +		pb->en_supply = NULL;
>> +		goto err_alloc;
>> +	}
>
> This effectively makes the regulator mandatory, so the board files that
> use pwm-backlight need to be updated or otherwise will break.

Yes. Btw, should such changes go into the same patch? This seems 
difficult to split without breaking things at some point.

Alex.


  reply	other threads:[~2013-03-07 10:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-06 17:17 [PATCH 1/1 v4] pwm_bl: Add support for backlight enable regulator Andrew Chew
2013-03-07  7:11 ` Thierry Reding
2013-03-07 10:11   ` Alex Courbot [this message]
2013-03-07 11:27     ` Thierry Reding
2013-03-07 21:07       ` Andrew Chew
2013-03-08  2:21         ` Alex Courbot
2013-03-08  7:23           ` 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=513867CD.4030201@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