Date:   Wed, 4 Dec 2019 13:13:08 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     "broonie@...nel.org" <broonie@...nel.org>
CC:     "corbet@....net" <corbet@....net>,
        "sboyd@...nel.org" <sboyd@...nel.org>,
        "dmurphy@...com" <dmurphy@...com>,
        "linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>,
        "linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>,
        "jeffrey.t.kirsher@...el.com" <jeffrey.t.kirsher@...el.com>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "mchehab+samsung@...nel.org" <mchehab+samsung@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
        "mturquette@...libre.com" <mturquette@...libre.com>,
        "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "jacek.anaszewski@...il.com" <jacek.anaszewski@...il.com>,
        "mazziesaccount@...il.com" <mazziesaccount@...il.com>,
        "a.zummo@...ertech.it" <a.zummo@...ertech.it>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "hofrat@...dl.org" <hofrat@...dl.org>,
        "wsa+renesas@...g-engineering.com" <wsa+renesas@...g-engineering.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "m.szyprowski@...sung.com" <m.szyprowski@...sung.com>,
        "bgolaszewski@...libre.com" <bgolaszewski@...libre.com>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        "pavel@....cz" <pavel@....cz>,
        "phil.edworthy@...esas.com" <phil.edworthy@...esas.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "lee.jones@...aro.org" <lee.jones@...aro.org>
Subject: Re: [PATCH v5 01/16] dt-bindings: regulator: Document ROHM BD71282
 regulator bindings


On Wed, 2019-12-04 at 12:47 +0000, Mark Brown wrote:
> On Mon, Dec 02, 2019 at 02:02:41PM +0000, Vaittinen, Matti wrote:
> > On Mon, 2019-12-02 at 13:11 +0000, Mark Brown wrote:
> > > No, look at the bindings - we support a bunch of different
> > > suspend states matching the different suspend states that the
> > > kernel as a whole supports.  We don't assume that the device will
> > > know this but you can always use the current suspend we're going
> > > for to decide where to update.
> > Hm. So if I understand this correctly, you mean user should set the
> > suspend 'target' - and then call the set_suspend_voltage for this
> > state. To set voltages for all states one should do loop
> 
> The general idea is that we set the suspend state during the
> process of suspending rather than in advance - that way when the
> hardware doesn't understand different types of suspsend things
> work fine.

Ok. So voltage for the specific suspend state is set just before going
to suspend - when the target suspend state is already selected. Makes
sense. Thanks.

> > get_current_mode()
> > for_all_modes() {
> > 	set_mode()
> > 	set_voltage()
> > }
> > restore_original_mode()
> > am I on a right track? I'll try to see if I can find some examples
> > of
> > this - thanks.
> 
> I don't understand the save and restore of mode?

I was thinking that there is some 'cahced suspend target state' in
framework. This get mode is pseudo-code for getting the suspend mode
from framework - "restore mode" is returning back the "original mode"
after voltages for all modes are set. But please ignore this - I think
I captured your message already :)

>   If setting the
> suspend configuration affects the runtime state then the hardware
> doesn't support suspend configuration.

No, it does not. I probably explained this badly.

> 
> > > The framework doesn't care how a device is controlled, that's up
> > > to the device.  Like I said I recommend figuring out what
> > > voltages are useful to have quick access to at runtime, for
> > > example it's likely that it's good to have quick access to the
> > > highest voltage that's been set (and/or the top of the
> > > constraints).
> > Problem is that the run-level controlled regulator can't be
> > individually controlled (unless it is only regulator in the group).
> > I
> 
> Regulators that have to be controlled en masse aren't really
> supported by the API, it only understands regulators that are
> individually controllable.

Thanks. This was the piece of information I wanted and assumed. Thus
the patch 12 did introduce new in-kernel APIs - but as I said, we don't
have any in-tree socs using BD71828 RUN0, ..., RUN3 states for now so
I'll drop the patch 12 and leave only the basic support for
individually controllable regulators.

> > But just to confirm, I meant for example assigning bucks 1,2,6 and
> > 7
> > into a group which 'state' is changed via GPIO line. Say 'states'
> > are
> > RUN0, RUN1. For each of these bucks we can define a voltage and
> > enable/disable status which is to be used on RUN0, and another
> > voltage/state tuple for RUN1.
> 
> So you could also just create a group consisting of a single
> regulator?  That would be fine for the API.

I think I once again explained myself badly. There can be only one
group with 4 RUN states selected by combination of 2 GPIO lines. bucks
1,2,6 and 7 can each either be assigned into this one group or
controlled individually via I2C. But I doubt assigning only one of the
bucks in this group is the typical use-case. What we would need would
really be the 'en-masse' control - either via GPIO or I2C - but I don't
want to suggest any framework expansion as I don't have proper in-tree
use-case for this as of now :) So I'll forget this for now (and thanks
for all the help!) and drop the patch 12 from series. I'll see if I can
send updated series tomorrow - or latest early next week :)

Br,
	Matti Vaittinen

Powered by blists - more mailing lists