[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zw_dE1rQ-Ljsh-sY@linaro.org>
Date: Wed, 16 Oct 2024 17:34:43 +0200
From: Stephan Gerhold <stephan.gerhold@...aro.org>
To: Johan Hovold <johan@...nel.org>, Bartosz Golaszewski <brgl@...ev.pl>
Cc: Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
Abel Vesa <abel.vesa@...aro.org>,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Subject: Re: [PATCH 3/3] arm64: dts: qcom: x1e80100-qcp: Add WiFi/BT pwrseq
On Tue, Oct 15, 2024 at 02:27:56PM +0200, Johan Hovold wrote:
> On Fri, Oct 11, 2024 at 12:11:43PM +0200, Stephan Gerhold wrote:
> > On Thu, Oct 10, 2024 at 11:34:44AM +0200, Johan Hovold wrote:
>
> > > Based on our discussions it seems we do not really need to describe the
> > > internal PMU at all for WCN7850 (as the bluetooth and wlan blocks can be
> > > enabled indepdendently) so perhaps we can just restore the old binding
> > > and drop most of this boilerplate for all boards.
> > >
> >
> > I think there is no clear conclusion on that yet. The old bindings
> > didn't describe any power supplies for WiFi at all. The pwrseq bindings
> > are currently the only way to do that.
> >
> > We could potentially move all the "PMU supplies" to the WiFi/BT nodes
> > and rely on reference counting to handle them. But I think it's better
> > to wait how the M.2/generic PCI power control discussion turns out
> > before investing any time to refactor the current solution.
> >
> > There are existing users of qcom,wcn7850-pmu already in 6.11, so I think
> > it does not hurt to take this patch as-is for now. We can clean them up
> > together later if needed.
>
> Sounds good.
>
> But can you please address the following warning that I see with this
> series:
>
> pwrseq-qcom_wcn wcn7850-pmu: supply vddio1p2 not found, using dummy regulator
>
> Not sure if it's the dtsi that's missing a supply if it's the driver
> that needs fixing.
>
It's the driver, the DT should be correct. This supply exists on the
WCN7850 chip, but nothing is connected there on the QCP.
Unfortunately, it's not entirely straightforward to drop the warning
since the pwrseq-qcom-wcn driver uses the bulk regulator APIs and
(AFAIK) there is no good way to make only one of the regulators optional
there.
@Bartosz: Any thoughts on this? sm8550-qrd and sm8550-hdk are also
missing the vddio1p2-supply, so they probably have the same warning in
latest mainline.
Thanks,
Stephan
Powered by blists - more mailing lists