linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Saravana Kannan <skannan@codeaurora.org>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] regulator: Update consumer state only after set voltage succeeds.
Date: Mon, 20 Dec 2010 14:27:40 -0800	[thread overview]
Message-ID: <4D0FD85C.1020307@codeaurora.org> (raw)
In-Reply-To: <20101220123903.GE26706@rakim.wolfsonmicro.main>

On 12/20/10 04:39, Mark Brown wrote:
> On Fri, Dec 17, 2010 at 02:44:28PM -0800, Saravana Kannan wrote:
>
>>   static int regulator_check_consumers(struct regulator_dev *rdev,
>> +				     struct regulator *ignore,
>>   				     int *min_uV, int *max_uV)
>
> This feels really invasive, and prone to robustness issues as we're just
> randomly not checking one of the consumers on a single call, meaning we
> skip some checking some of the time.  It's not going to make the code
> more maintainable.

I agree it looks a bit odd and I'm willing to do the code reorg if there 
is a better way. But I definitely wouldn't call this as randomly 
ignoring a consumer. We are just avoiding the consumer that's changing 
the range from "voting twice". We already send the new request thru 
min/max params.

We will also need the option of not including the calling consumer when 
computing the min/max for the next patch. See below.

Do you have any suggestions for a better way to compute the min/max 
while leaving out a single consumer? I'm very much open to do that.

Would something like below be better?

regulator_check_consumers_except(rdev, ignore, min, max)
{
  ...
}

regulator_check_consumers(rdev, min, max)
{
  regulator_check_consumer(rdev, NULL, min, max);
}

>
>> -	regulator->min_uV = min_uV;
>> -	regulator->max_uV = max_uV;
>> -
>> -	ret = regulator_check_consumers(rdev,&min_uV,&max_uV);
>> +	ret = regulator_check_consumers(rdev, regulator,&min_uV,&max_uV);
>>   	if (ret<  0)
>>   		goto out;
>>
>>   	ret = _regulator_do_set_voltage(rdev, min_uV, max_uV);
>> +	if (!ret) {
>> +		regulator->min_uV = min_uV;
>> +		regulator->max_uV = max_uV;
>> +	}
>
> If you're going to do something probably unwinding the assignment on
> error would cover it.

It would, but the next patch was going to be to optimize out the call to 
the regulator driver if the votes of the calling consumer doesn't make a 
difference. To do that, we will need to compute the voltage range with 
and without the calling consumer's min/max and then figure out if the 
change in the calling consumer's min/max makes a difference.

Thanks,
Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

  reply	other threads:[~2010-12-20 22:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-17 22:44 [PATCH] regulator: Update consumer state only after set voltage succeeds Saravana Kannan
2010-12-20 12:39 ` Mark Brown
2010-12-20 22:27   ` Saravana Kannan [this message]
2010-12-21 16:34     ` Mark Brown

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=4D0FD85C.1020307@codeaurora.org \
    --to=skannan@codeaurora.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lrg@slimlogic.co.uk \
    /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;
as well as URLs for NNTP newsgroup(s).