On 19/02/2024 10:22, Dmitry Baryshkov wrote:
On Mon, 19 Feb 2024 at 10:14, Neil Armstrong <neil.armstrong@xxxxxxxxxx> wrote:
On 18/02/2024 13:53, Dmitry Baryshkov wrote:
On Fri, 16 Feb 2024 at 22:33, Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx>
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@xxxxxxxx/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@xxxxxxxxxxxxxx/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@xxxxxxxx/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.
Neil
