Date: Mon, 19 Feb 2024 11:22:18 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: neil.armstrong@...aro.org
Cc: Bartosz Golaszewski <brgl@...ev.pl>, 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>, Mark Brown <broonie@...nel.org>, 
	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>, 
	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>, 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 00/18] power: sequencing: implement the subsystem and
 add first users

On Mon, 19 Feb 2024 at 10:14, Neil Armstrong <neil.armstrong@...aro.org> wrote:
>
> On 18/02/2024 13:53, Dmitry Baryshkov wrote:
> > On Fri, 16 Feb 2024 at 22:33, Bartosz Golaszewski <brgl@...ev.pl> wrote:
> >>
> >> From: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> >>
> >> First, I'd like to apologize for the somewhat chaotic previous iterations
> >> of this series and improper versioning which was rightfully pointed out
> >> to me. I figured that the scope changed so much that it didn't make sense
> >> to consider previous submissions part of the same series as the original
> >> RFC but others thought otherwise so this one becomes v5 and I'll keep the
> >> versioning going forward.
> >>
> >> This is the summary of the work so far:
> >>
> >> v1: Original RFC:
> >>
> >> https://lore.kernel.org/lkml/20240104130123.37115-1-brgl@bgdev.pl/T/
> >>
> >> v2: First real patch series (should have been PATCH v2) adding what I
> >>      referred to back then as PCI power sequencing:
> >>
> >> https://lore.kernel.org/linux-arm-kernel/2024021413-grumbling-unlivable-c145@gregkh/T/
> >>
> >> v3: RFC for the DT representation of the PMU supplying the WLAN and BT
> >>      modules inside the QCA6391 package (was largely separate from the
> >>      series but probably should have been called PATCH or RFC v3):
> >>
> >> https://lore.kernel.org/all/CAMRc=Mc+GNoi57eTQg71DXkQKjdaoAmCpB=h2ndEpGnmdhVV-Q@mail.gmail.com/T/
> >>
> >> v4: Second attempt at the full series with changed scope (introduction of
> >>      the pwrseq subsystem, should have been RFC v4)
> >>
> >> https://lore.kernel.org/lkml/20240201155532.49707-1-brgl@bgdev.pl/T/
> >>
> >> ===
> >>
> >> With that out of the way, I'd like to get down to explaining the two
> >> problems I'm trying to solve.
> >>
> >> Problem statement #1: Dynamic bus chicken-and-egg problem.
> >>
> >> Certain on-board PCI devices need to be powered up before they are can be
> >> detected but their PCI drivers won't get bound until the device is
> >> powered-up so enabling the relevant resources in the PCI device driver
> >> itself is impossible.
> >>
> >> Problem statement #2: Sharing inter-dependent resources between devices.
> >>
> >> Certain devices that use separate drivers (often on different busses)
> >> share resources (regulators, clocks, etc.). Typically these resources
> >> are reference-counted but in some cases there are additional interactions
> >> between them to consider, for example specific power-up sequence timings.
> >>
> >> ===
> >>
> >> The reason for tackling both of these problems in a single series is the
> >> fact the the platform I'm working on - Qualcomm RB5 - deals with both and
> >> both need to be addressed in order to enable WLAN and Bluetooth support
> >> upstream.
> >>
> >> The on-board WLAN/BT package - QCA6391 - has a Power Management Unit that
> >> takes inputs from the host and exposes LDO outputs consumed by the BT and
> >> WLAN modules which can be powered-up and down independently. However
> >> a delay of 100ms must be respected between enabling the BT- and
> >> WLAN-enable GPIOs[*].
> >>
> >> ===
> >>
> >> This series is logically split into several sections. I'll go
> >> patch-by-patch and explain each step.
> >>
> >> Patch 1/18:
> >>
> >> This is a commit taken from the list by Jonathan Cameron that adds
> >> a __free() helper for OF nodes. Not strictly related to the series but
> >> until said commit ends in next, I need to carry it with this series.
> >>
> >> Patch 2/18:
> >>
> >> This enables the ath12k PCI module in arm64 defconfig as Qualcomm sm8650
> >> and sm8550 reference platforms use it in the WCN7850 module.
> >>
> >> Patches 3/18-6/18:
> >>
> >> These contain all relevant DT bindings changes. We add new documents for
> >> the QCA6390 PMU and ATH12K devices as well as extend the bindings for the
> >> Qualcomm Bluetooth and ATH11K modules with regulators used by them in
> >> QCA6390.
> >>
> >> Patches 7/18-9/18:
> >>
> >> These contain changes to device-tree sources for the three platforms we
> >> work with in this series. As the WCN7850 module doesn't require any
> >> specific timings introducing dependencies between the Bluetooth and WLAN
> >> modules, while the QCA6390 does, we take two different approaches to how
> >> me model them in DT.
> >>
> >> For WCN7850 we hide the existence of the PMU as modeling it is simply not
> >> necessary. The BT and WLAN devices on the device-tree are represented as
> >> consuming the inputs (relevant to the functionality of each) of the PMU
> >> directly.
> >
> > We are describing the hardware. From the hardware point of view, there
> > is a PMU. I think at some point we would really like to describe all
> > Qualcomm/Atheros WiFI+BT units using this PMU approach, including the
> > older ath10k units present on RB3 (WCN3990) and db820c (QCA6174).
>
> While I agree with older WiFi+BT units, I don't think it's needed for
> WCN7850 since BT+WiFi are now designed to be fully independent and PMU is
> transparent.

I don't see any significant difference between WCN6750/WCN6855 and
WCN7850 from the PMU / power up point of view. Could you please point
me to the difference?

-- 
With best wishes
Dmitry

Powered by blists - more mailing lists