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
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html