[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8e392aed-b5f7-486b-b5c0-5568e13796ec@sirena.org.uk>
Date: Mon, 19 Feb 2024 19:59:46 +0000
From: Mark Brown <broonie@...nel.org>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Marcel Holtmann <marcel@...tmann.org>,
Luiz Augusto von Dentz <luiz.dentz@...il.com>,
"David S . Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>, Kalle Valo <kvalo@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Liam Girdwood <lgirdwood@...il.com>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
Saravana Kannan <saravanak@...gle.com>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Arnd Bergmann <arnd@...db.de>,
Neil Armstrong <neil.armstrong@...aro.org>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Alex Elder <elder@...aro.org>,
Srini Kandagatla <srinivas.kandagatla@...aro.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Abel Vesa <abel.vesa@...aro.org>,
Manivannan Sadhasivam <mani@...nel.org>,
Lukas Wunner <lukas@...ner.de>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
linux-bluetooth@...r.kernel.org, netdev@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-wireless@...r.kernel.org, linux-arm-msm@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-pci@...r.kernel.org,
linux-pm@...r.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH v5 09/18] arm64: dts: qcom: qrb5165-rb5: model the PMU of
the QCA6391
On Mon, Feb 19, 2024 at 07:48:20PM +0100, Bartosz Golaszewski wrote:
> On Mon, Feb 19, 2024 at 7:03 PM Mark Brown <broonie@...nel.org> wrote:
> > On Fri, Feb 16, 2024 at 09:32:06PM +0100, Bartosz Golaszewski wrote:
> > > + vreg_pmu_aon_0p59: ldo1 {
> > > + regulator-name = "vreg_pmu_aon_0p59";
> > > + regulator-min-microvolt = <540000>;
> > > + regulator-max-microvolt = <840000>;
> > > + };
> > That's a *very* wide voltage range for a supply that's got a name ending
> > in _0_p59 which sounds a lot like it should be fixed at 0.59V.
> > Similarly for a bunch of the other supplies, and I'm not seeing any
> > evidence that the consumers do any voltage changes here? There doesn't
> > appear to be any logic here, I'm not convinced these are validated or
> > safe constraints.
> No, the users don't request any regulators (or rather: software
> representations thereof) because - as per the cover letter - no
> regulators are created by the PMU driver. This is what is physically
> on the board - as the schematics and the datasheet define it. I took
The above makes no sense. How can constraints be "what is physically on
the board", particularly variable constrants when there isn't even a
consumer? What values are you taking from which documentation?
The cover letter and binding both claimed (buried after large amounts of
changelog) that these PMUs were exposing regulators to consumers and the
DTS puports to do exactly that...
> the values from the docs verbatim. In C, we create a power sequencing
> provider which doesn't use the regulator framework at all.
For something that doesn't use the regulator framework at all what
appears to be a provider in patch 16 ("power: pwrseq: add a driver for
the QCA6390 PMU module") seems to have a lot of regualtor API calls?
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists