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? -- With best wishes Dmitry
