Message-ID: <CAA8EJpq=iyOfYzNATRbpqfBaYSdJV1Ao5t2ewLK+wY+vEaFYAQ@mail.gmail.com>
Date: Mon, 19 Feb 2024 12:26:39 +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 11:42, <neil.armstrong@...aro.org> wrote:
>
> On 19/02/2024 10:22, Dmitry Baryshkov wrote:
> > 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?
> >
>
> The WCN7850 datasheet clearly states there's not contraint on the WLAN_EN
> and BT_EN ordering and the only requirement is to have all input regulators
> up before pulling up WLAN_EN and/or BT_EN.
>
> This makes the PMU transparent and BT and WLAN can be described as independent.

>From the hardware perspective, there is a PMU. It has several LDOs. So
the device tree should have the same style as the previous
generations.

-- 
With best wishes
Dmitry

Powered by blists - more mailing lists