On Mon, 19 Feb 2024 at 11:42, <neil.armstrong@xxxxxxxxxx> wrote: > > 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. >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
