From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Subject: Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings Date: Wed, 30 May 2018 10:37:01 +0100 Message-ID: <20180530093701.GD6920@sirena.org.uk> References: <20180523082908.GB4828@sirena.org.uk> <20180523154057.GL4828@sirena.org.uk> <20180523155617.GN4828@sirena.org.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xB0nW4MQa6jZONgY" Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Doug Anderson Cc: David Collins , Liam Girdwood , Rob Herring , Mark Rutland , linux-arm-msm@vger.kernel.org, Linux ARM , devicetree@vger.kernel.org, LKML , Rajendra Nayak , Stephen Boyd List-Id: linux-arm-msm@vger.kernel.org --xB0nW4MQa6jZONgY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, May 29, 2018 at 10:30:33PM -0700, Doug Anderson wrote: > On Wed, May 23, 2018 at 8:56 AM, Mark Brown wrote: > > Yes, that's definitely not what's expected but it's unfortunately what > > the firmware chose to implement so we may well be stuck with it > > unfortunately. > We're not really stuck with it if we do what I was suggesting. I was > suggesting that every time we disable the regulator in Linux we have > Linux vote for the lowest voltage it's comfortable with. Linux keeps > track of the true voltage that the driver wants and will always change > its vote back to that before enabling. Thus (assuming Linux is OK > with 1.2 V - 1.4 V for a rail): That's pretty much what it should do anyway with normally designed hardware. --xB0nW4MQa6jZONgY Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAlsOcL0ACgkQJNaLcl1U h9DM5wf/ZIB/GXA/GKedSaSDuEH7anyaK0FDs0T5+c5BeuhSOKMMO56wPSCmNKOS wiMVH2Oe+SjF07QaUMXYAnBKhSJ95P2c+U+MbzexI9MVcaV2DCyqE2PYlALX4Gsg 1p+F/ESu6fLIbNMWhUQ9jzqIsoNL5fAWX/B5sJeSb1hXPTo/QXvKGMz9SnO0LoLM btZh5hlny9lzNGPxEz+8IrcDi/y1JoAjtFUICAfiWlxlk45g88rJ43GciuBb4yYT HN4DTFugMryqY97VeQ28RXO5gnvAq5PKjLGfCraDRzy9irgTqyBiuF5mzdCV6vm9 qMtsByT1THQmE6RX/ab4hL3xbchr/w== =hbBI -----END PGP SIGNATURE----- --xB0nW4MQa6jZONgY-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: broonie@kernel.org (Mark Brown) Date: Wed, 30 May 2018 10:37:01 +0100 Subject: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings In-Reply-To: References: <20180523082908.GB4828@sirena.org.uk> <20180523154057.GL4828@sirena.org.uk> <20180523155617.GN4828@sirena.org.uk> Message-ID: <20180530093701.GD6920@sirena.org.uk> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, May 29, 2018 at 10:30:33PM -0700, Doug Anderson wrote: > On Wed, May 23, 2018 at 8:56 AM, Mark Brown wrote: > > Yes, that's definitely not what's expected but it's unfortunately what > > the firmware chose to implement so we may well be stuck with it > > unfortunately. > We're not really stuck with it if we do what I was suggesting. I was > suggesting that every time we disable the regulator in Linux we have > Linux vote for the lowest voltage it's comfortable with. Linux keeps > track of the true voltage that the driver wants and will always change > its vote back to that before enabling. Thus (assuming Linux is OK > with 1.2 V - 1.4 V for a rail): That's pretty much what it should do anyway with normally designed hardware. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: