lkml.org 
[lkml]   [2015]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] regulator: core: Fix enable GPIO reference counting
Hello Mark,

On 03/02/2015 07:57 PM, Mark Brown wrote:
> On Fri, Feb 27, 2015 at 10:01:23PM +0100, Javier Martinez Canillas wrote:
>
>> I noticed the same problem in regulator_suspend_finish() when I was working
>> on S2R for Exynos a couple of months ago and had patch [0] on my local tree
>> but never found the time to do extensive testing so I never posted it.
>
> Please don't bury patches in the middle of mails where they're hard to
> apply if they're useful.
>

Sorry, if my intention was you to apply the patch then I would had posted
it properly. But what I wanted was to share that I had the same issue and
my approach to see if that also fixed Doug's issue.

Otherwise is hard to maintain a conversation across different threads.

>> I see that the check is already in _regulator_enable() so another option
>> is to call _regulator_enable() instead of _regulator_do_enable() in
>> regulator_suspend_finish().
>
> I'm not entirely sure what "the check" is?
>

The check I was referring to is _regulator_is_enabled() but now looking again
I see that _regulator_enable() can't be used in regulator_suspend_finish()
because that will increment the reference counting which is wrong.

>> Trying to enable an already enabled regulator may cause issues so is
>> better to skip enabling regulators that were not disabled before suspend.
>
>> mutex_lock(&rdev->mutex);
>> if (rdev->use_count > 0 || rdev->constraints->always_on) {
>> - error = _regulator_do_enable(rdev);
>> - if (error)
>> - ret = error;
>> + if (!_regulator_is_enabled(rdev)) {
>> + error = _regulator_do_enable(rdev);
>> + if (error)
>> + ret = error;
>> + }
>
> This seems like a better fix or at least a better approach - essentially
> the assumption in most of the code is that regulator enables are just
> register writes so repeated updates don't have any effect. We may need

Which doesn't seem to be the case for all regulators since at least I got
failures when a FET in the tps65090 pmu was tried to be enabled twice.

> a specific per client count here... I've not looked at the code and I

Sorry, I'm not sure I understood what you meant. The suspend path:

suspend_prepare() -> suspend_set_state() -> .set_suspend_*

doesn't decrement use_count so is correct to call _regulator_do_enable()
directly. The problem is the assumption that all regulators were either
disabled on suspend or that enabling an enabled regulator is a no-op.

I'll post as a proper patch so you can review it.

Best regards,
Javier


\
 
 \ /
  Last update: 2015-03-02 21:41    [W:0.084 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site