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: <557a4c5993a6fb16710342438f74f92bdfb40ec0.camel@fi.rohmeurope.com>
Date:   Tue, 10 Dec 2019 12:41:47 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     "broonie@...nel.org" <broonie@...nel.org>
CC:     "corbet@....net" <corbet@....net>, "pavel@....cz" <pavel@....cz>,
        "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>,
        "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>,
        "phil.edworthy@...esas.com" <phil.edworthy@...esas.com>,
        "lee.jones@...aro.org" <lee.jones@...aro.org>,
        "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,

On Tue, 2019-12-10 at 12:11 +0000, Mark Brown wrote:
> On Tue, Dec 10, 2019 at 11:14:48AM +0000, Vaittinen, Matti wrote:
> 
> > Problem is that if no default voltages are given from DT, the the
> > first
> > voltage changes are likely to be slow (require register access - I
> > guess the HW defaults are not working for many use-cases) - which
> > may
> > be undesirable.
> 
> I don't think that's likely to be a practical problem, and it's not
> likely it'd be worse than always doing writes.  A lot of things are
> slower the first time you do them and you're still going to have to
> do the writes no matter what.

The thing is that if we do initial setting of voltages (based on
binding data) we can set the voltages to registers before we switch to
that run-level. If we don't do initial setting then we will only do
setting when voltage change is actually requested - which may be too
late. (I actually heard somewhere that there is 40 uS time limit - but
I don't see how this is counted. Starting from what? - and I don't see
how this is guaranteed even with GPIO if interrupts are to be served).

OTOH, I also heard that the SoC probably require at least two of the
bucks to be controlled as a group (bucks connected to SRAM and CORE) -
probably all four.

So, I am again wondering if I should just upstream the basic control
with I2C for SoCs which do not require fast DVS voltage changes and
perhaps maintain/provide own set of patches with additional interface
for run-level control for those customers who require it... Sorry for
being such a difficult guy. Decision making seems to not be my strong
point :/

Br,
	Matti Vaittinen