Message-ID: <eb685cc78b936bc61ed9f7fbfa18c96398b00909.camel@fi.rohmeurope.com>
Date:   Fri, 29 Nov 2019 07:48:13 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     "broonie@...nel.org" <broonie@...nel.org>
CC:     "corbet@....net" <corbet@....net>,
        "lee.jones@...aro.org" <lee.jones@...aro.org>,
        "hofrat@...dl.org" <hofrat@...dl.org>,
        "linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>,
        "dmurphy@...com" <dmurphy@...com>,
        "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>,
        "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>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "m.szyprowski@...sung.com" <m.szyprowski@...sung.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "bgolaszewski@...libre.com" <bgolaszewski@...libre.com>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        "sboyd@...nel.org" <sboyd@...nel.org>,
        "pavel@....cz" <pavel@....cz>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "phil.edworthy@...esas.com" <phil.edworthy@...esas.com>
Subject: Re: [PATCH v5 01/16] dt-bindings: regulator: Document ROHM BD71282
 regulator bindings

Hello Again Mark,

Sorry for long delay - I am really having too many things on my table
right now :/

On Tue, 2019-11-19 at 19:36 +0000, Mark Brown wrote:
> On Tue, Nov 19, 2019 at 06:51:37PM +0000, Vaittinen, Matti wrote:
> > On Tue, 2019-11-19 at 18:13 +0000, Mark Brown wrote:
> > > Ah, OK.  I didn't even notice that patch when I scanned the
> > > series.
> > > I'll look out for this next time around but that sounds like it's
> > > generally going in the right direction, especially if it's
> > > integrated
> > > with the suspend mode regulator bindings that Chunyan did.
> > Probably it is not as I am not familiar with Chunyan's work. I'll
> > try
> > looking what has been done on that front :) And I am pretty sure
> > you
> > might not be happy with that patch - but perhaps you can give me a
> > nudge to better direction...
> 
> 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.

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.

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
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
7 support this. Rest of the LDOs and BUCKs (and also those DVS bucks
which are not configured to be controlled by run-levels) have modes RUN
and IDLE, where the processor stays powered.

In addition to these (active) modes/states, there is few states where
processor is not powered. I guess these could be mapped to 'different'
suspend states. At least LPSR, HBNT and SHIP states are such. These are
again global PMIC states - not per regulator states. They can be either
controlled by driving a pin on PMIC - or by I2C register setting. I
don't see how I could differentiate these states when using standard
APIs - nor do I know if these should be changed via regulator
interfaces at all.

All in all - I am also a bit unsure how I should do the mapping of the
PMIC low-power modes to the modes used by Linux - the curse of working
for component vendor is that I have limited visibility to actual end-
products - if they are not in-tree. :( And I don't think we have any
in-tree boards which use these low-power states (at least for now) - So
if you or Rob do not object - I will leave these bindings in this doc -
but I need to consider the value of adding stuff presented in patch 12
in-tree kernel... Guess I'll drop it out unless I get some better
understanding how run-levels and low-power modes are handled in some of
the actual devices. We can always add this support later :)

> > > Yes, I think this needs clarification as I completely failed to
> > > pick
> > > up
> > > on this and did indeed read this as referring to the
> > > modes.  "Voltages
> > > that can be set in RUN mode" or something?  I take it these
> > > voltages
> > > are
> > > fixed and the OS can't change them?
> > Unfortunately they are not. Voltages and enable/disable statuses
> > for
> > each run-level (and individually for each run-level capable buck)
> > can
> > be changed at runtime via I2C. And a customer requested me also to
> > support this - hence the in-kernel API - but I am sure you have
> > some
> > nice words when you check the patch 12. :]
> 
> 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 ;)

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).

Br,
	Matti Vaittinen

Powered by blists - more mailing lists