Message-ID: <297fa021fb243072dbbb7bca455e57c13e8c6843.camel@fi.rohmeurope.com>
Date:   Mon, 2 Dec 2019 07:57:13 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     "broonie@...nel.org" <broonie@...nel.org>
CC:     "corbet@....net" <corbet@....net>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "phil.edworthy@...esas.com" <phil.edworthy@...esas.com>,
        "dmurphy@...com" <dmurphy@...com>,
        "linux-leds@...r.kernel.org" <linux-leds@...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>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "wsa+renesas@...g-engineering.com" <wsa+renesas@...g-engineering.com>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "hofrat@...dl.org" <hofrat@...dl.org>,
        "linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>,
        "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>,
        "lee.jones@...aro.org" <lee.jones@...aro.org>,
        "sboyd@...nel.org" <sboyd@...nel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "pavel@....cz" <pavel@....cz>
Subject: Re: [PATCH v5 01/16] dt-bindings: regulator: Document ROHM BD71282
 regulator bindings

Hello Mark!

On Fri, 2019-11-29 at 12:09 +0000, Mark Brown wrote:
> On Fri, Nov 29, 2019 at 07:48:13AM +0000, Vaittinen, Matti wrote:
> > On Tue, 2019-11-19 at 19:36 +0000, Mark Brown wrote:
> > > The driver interface was added in "regulator: add PM suspend and
> > > resume
> > > hooks".
> > I looked through the set but didn't spot any new interface towards
> > the
> > regulator driver (which accesses the HW). I saw interface towards
> > regulator consumer driver which can be used to set the constrains
> > though.
> 
> The regulator driver has a bunch fo set_suspend_ operations.

Hmm. I saw these. But unless I am mistaken linux only knows one
'suspend' state whereas the PMIC has a few separate states I can see as
'suspend' states. As far as I understood the set_suspend_voltage does
not allow setting separate suspend voltages depending on the "type of
suspend" (as there is only one 'suspend' state).

For example, from CPU point of view the BD71828 PMIC states HIBERNATE
and LPSR are probably both just "suspend" - but the PMIC could set
different voltages or ON/OFF states for some regulators depending on
the 'suspend' target (LPSR or HIBERNATE or STANDBY).

Yet, as I said, I haven't seen how these states are used by real
devices - we don't currently have any in-tree SoCs which use BD71828
and utilize these states (as far as I know). Hence I can't really
figure out how to add support for these PMIC features if there is no
'de-facto' mechanism in place :(
> 
> > Specifically, I don't see voltage setting callback for different
> > run-
> > modes. Nor do I see voltage setting (or differentiation) of more
> > than
> > one suspend state.
> 
> set_suspend_voltage.

Yes. But this does only allow setting one suspend voltage for
regulator, not own voltage for HIBERNATE, LPSR, STANDBY etc - or am I
mistaken?

> > To explain it further - my assumption is that the BD71828 'run-
> > levels'
> > (RUN0, ... RUN3) could be mapped to regulator modes
> > REGULATOR_MODE_FAST, REGULATOR_MODE_NORMAL, REGULATOR_MODE_IDLE
> > and 
> > REGULATOR_MODE_STANDBY. But regulators which are controlled by
> > these
> 
> That doesn't make sense at all, the modes affect the quality of
> regulation not the voltage that is set.

Thanks. I misunderstood this. I thought these states could be used for
some adaptive voltages. My understanding is that the RUN0,...RUN3 are
designed for that - but I didn't know if regulator framework is
designed for this.

> > run-levels, can't be individually controlled. If state for one is
> > changed, the state is changed for all of them. The DVS bucks 1,2,6
> > and
> 
> We don't really have anything that'd only work for group
> configuration
> except for the suspend modes.

Thanks. As I said, I thought the 'quality of regulation' states could
have been supporting also changing the voltages.

> 
> > > Ah, that's actually better.  It opens up possiblities for making
> > > use
> > > of
> > > the feature without encoding voltages in DT.  For example, you
> > > can
> > > cache
> > > the last however many voltages that were set and jump quickly to
> > > them
> > > or
> > > do something like put the top of the constraints in to help with
> > > governors like ondemand.  I'd recommend trying for something like
> > > that
> > > rather than encoding in DT, it'll probably be more robust with
> > > things
> > > like cpufreq changing.
> > I wish I was working with the full product so that I could see and
> > learn a proper example on how the cpufreq actually uses these
> > interfaces :) I'd really like to understand this much better. Maybe
> > this could be a topic for you to present in some Linux conference
> > ;)
> > Just please ping me when you are doing that and I'll be listening
> > there
> > for sure ;)
> 
> The cpufreq code is all there in kernel - drivers/cpufreq.  I can't
> remember if Android still has a custom governor in their trees but it
> doesn't really make much difference in terms of how it interacts with
> the regulator drivers.

Right. I guess your answers mean that there is no "regulator group
control" for "adaptive voltage changes" supported by regulator
framework / cpufreq - as of now. Furthermore, I have understood that it
is different story depending on PMIC and CPU/SoC capabilities. (Like
PMIC inbuilt states and state change mechanisms, SoC voltage scaling
support etc.)

>  Anyways, my idea was to set the inital voltage values for these
> states
> > via DT - but allow the voltages to be changed at run-time too (I
> > guess
> > this idea is visible in the patch 12).
> 
> It'd be much better if you could avoid putting the voltages in the
> binding if they're not strictly required.

Hmm.. I guess I can omit that from in-tree driver for now. I can try
maintaining own set of patches for existing customers for now. I think
adding these to bindings later is not impossible :) Removing them would
probably be harder.

Thanks again Mark. I truly appreciate your help and guidance :)

Br,
	Matti

Powered by blists - more mailing lists