linux-kernel - Re: [PATCH v5 01/16] dt-bindings: regulator: Document ROHM BD71282 regulator bindings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fd1e4e652840346bd990c769eabe2f966bda4ed6.camel@fi.rohmeurope.com>
Date:   Mon, 18 Nov 2019 18:03:42 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     "broonie@...nel.org" <broonie@...nel.org>
CC:     "corbet@....net" <corbet@....net>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "phil.edworthy@...esas.com" <phil.edworthy@...esas.com>,
        "linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>,
        "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>,
        "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "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>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "wsa+renesas@...g-engineering.com" <wsa+renesas@...g-engineering.com>,
        "m.szyprowski@...sung.com" <m.szyprowski@...sung.com>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "bgolaszewski@...libre.com" <bgolaszewski@...libre.com>,
        "hofrat@...dl.org" <hofrat@...dl.org>,
        "lee.jones@...aro.org" <lee.jones@...aro.org>,
        "pavel@....cz" <pavel@....cz>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "sboyd@...nel.org" <sboyd@...nel.org>
Subject: Re: [PATCH v5 01/16] dt-bindings: regulator: Document ROHM BD71282
 regulator bindings

Hello Mark,

It's nice to hear from you again :) I hope you're enjoying all the new
things :)

On Mon, 2019-11-18 at 16:25 +0000, Mark Brown wrote:
> On Mon, Nov 18, 2019 at 08:53:57AM +0200, Matti Vaittinen wrote:
> 
> > +#Supported default DVS states:
> > +#buck		| run		| idle		| suspend	
> > | lpsr
> > +#-----------------------------------------------------------------
> > -----------
> > +#1, 2, 6, and 7	| supported	| supported	| 	supported
> > (*)
> > +#-----------------------------------------------------------------
> > -----------
> > +#3, 4, and 5	| 			supported (**)
> > +#-----------------------------------------------------------------
> > -----------
> > +#(*)  LPSR and SUSPEND states use same voltage but both states
> > have own enable /
> > +#     disable settings. Voltage 0 can be specified for a state to
> > make regulator
> > +#     disabled on that state.
> > +#(**) All states use same voltage but have own enable / disable
> > settings.
> > +#     Voltage 0 can be specified for a state to make regulator
> > disabled on that
> > +#     state.
> > +
> > +      rohm,dvs-runlvl-ctrl:
> > +        description: |
> > +          buck control is done based on run-level. Regulator is
> > not
> > +          individually controllable. See ../mfd/rohm,bd71828-
> > pmic.yaml for
> > +          how to specify run-level control mechanism. Only bucks
> > 1, 2, 6
> > +          and 7 support this.
> > +        type: boolean
> 
> I don't think I saw this having the effect on set_voltage() that I'd
> have expected in the driver?  

The support for this is added in patch 12. I should've ordered the
patch series so that all regulator patches were one after another.
Sorry for that.
The patch 12 adds the run-level support. Please see the functions
get_runcontrolled_bucks_dt(),
mark_regulator_runlvl_controlled() (sets the g->runlvl)
and set_buck_runlvl_controlled() (called based on g->runlvl)
which changes the ops to disallow setters and to get voltage based on
current runlevel - and different ops depending on if runlevels are
controlled by GPIO or I2C. Additionally set_buck_runlvl_controlled()
adds DT parsing call-back for setting the initial voltages.

Complex, I know. I'm open to hints,tips and suggestions :)

> > +      rohm,dvs-runlevel-microvolts:
> > +        minimum: 0
> > +        maximum: 2000000
> > +        maxItems: 4
> > +        description:
> > +          Array of voltages for run-levels. First value is for
> > run-level 0,
> > +          second for run-level 1 etc. Microvolts.
> 
> What's the mapping from array indexes to the names used elsewhere to
> support runlevels?

Hmm. Sorry Mark, I don't think I follow your question. Do you mean
names like LPSR, SUSPEND, IDLE, RUN? If so, then I might need to
rephrase this. The runlevels referred here are different from LPSR,
SUSPEND, IDLE etc. They are actually 'sub-levels' for PMIC's RUN state.
Eg, kind of a 'fast way' to change voltages for multiple power rails
when SoC is at RUN state. The names I have seen are RUN0, RUN1, RUN2
and RUN3. That mapping is described in description above.

Br,
	Matti Vaittinen