lkml.org 
[lkml]   [2020]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] regulator: do not balance 'boot-on' coupled regulators without constraints
From
Date
Hi Mark,

On 05.06.2020 12:20, Mark Brown wrote:
> On Fri, Jun 05, 2020 at 08:37:24AM +0200, Marek Szyprowski wrote:
>
>> Balancing of the 'boot-on' coupled regulators must wait until the clients
>> set their constraints, otherwise the balancing code might change the
> No, this is not what boot-on means at all. It is there for cases where
> we can't read the enable status from the hardware. Trying to infer
> *anything* about the runtime behaviour from it being present or absent
> is very badly broken.

Okay, what about the 'always-on' property? I don't think that we need
another property for annotating this behavior, as in my opinion this is
just an implementation issue on the Linux kernel and regulator
framework. Alternatively I can drop the property check, but then it
won't be possible to have a regulator without a consumer, which follows
the other one (although we still don't have a real use case for it).

If you don't like this idea at all, I will try to move this logic to the
custom coupler again, although it would mean some code copying.

> Saravana (CCed) was working on some patches which tried to deal with
> some stuff around this for enables using the sync_state() callback.
> Unfortunately there's quite a few problems with the current approach
> (the biggest one from my point of view being that it's implemented so
> that it requires every single consumer of every device on the PMIC to
> come up but there's others at more of an implementation level).
I'm not sure if we really need such complex solution for this...

Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland

\
 
 \ /
  Last update: 2020-06-05 15:39    [W:0.055 / U:0.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site