On 21/10/2024 12:25, Marco Felsch wrote: > On 24-10-21, Krzysztof Kozlowski wrote: >> On 21/10/2024 08:41, Marco Felsch wrote: >>> On 24-10-07, Krzysztof Kozlowski wrote: >>>> On 07/10/2024 14:58, POPESCU Catalin wrote: >>>>>>>> >>>>>>>> + vcc-supply: >>>>>>>> + description: >>>>>>>> + phandle of the regulator that provides the supply voltage. >>>>>>>> + >>>>>>>> + reset-gpios: >>>>>>>> + description: >>>>>>>> + Chip powerdown/reset signal (PDn). >>>>>>>> + >>>>>>> Hi Catalin, >>>>>>> >>>>>>> For NXP WIFI/BT chip, WIFI and BT share the one PDn pin, which means that both wifi and BT controller will be powered on and off at the same time. >>>>>>> Taking the M.2 NXP WIFI/BT module as an example, pin56(W_DISABLE1) is connected to the WIFI/BT chip PDn pin, we has already controlled this pin in the corresponding PCIe/SDIO controller dts nodes. >>>>>>> It is not clear to me what exactly pins for vcc-supply and reset-gpios you describing here. Can you help understand the corresponding pins on M.2 interface as an example? Thanks. >>>>> >>>>> Hi Sherry, >>>>> >>>>> Regulators and reset controls being refcounted, we can then implement >>>>> powerup sequence in both bluetooth/wlan drivers and have the drivers >>>>> operate independently. This way bluetooth driver would has no dependance >>>>> on the wlan driver for : >>>>> >>>>> - its power supply >>>>> >>>>> - its reset pin (PDn) >>>>> >>>>> - its firmware (being downloaded as part of the combo firmware) >>>>> >>>>> For the wlan driver we use mmc power sequence to drive the chip reset >>>>> pin and there's another patchset that adds support for reset control >>>>> into the mmc pwrseq simple driver. >>>>> >>>>>> Please wrap your replies. >>>>>> >>>>>> It seems you need power sequencing just like Bartosz did for Qualcomm WCN. >>>>> >>>>> Hi Krzysztof, >>>>> >>>>> I'm not familiar with power sequencing, but looks like way more >>>>> complicated than reset controls. So, why power sequencing is recommended >>>>> here ? Is it b/c a supply is involved ? >>>> >>>> Based on earlier message: >>>> >>>> "For NXP WIFI/BT chip, WIFI and BT share the one PDn pin, which means >>>> that both wifi and BT controller will be powered on and off at the same >>>> time." >>>> >>>> but maybe that's not needed. No clue, I don't know the hardware. But be >>>> carefully what you write in the bindings, because then it will be ABI. >>> >>> We noticed the new power-sequencing infrastructure which is part of 6.11 >>> too but I don't think that this patch is wrong. The DT ABI won't break >>> if we switch to the power-sequencing later on since the "reset-gpios" >>> are not marked as required. So it is up to the driver to handle it >>> either via a separate power-sequence driver or via "power-supply" and >>> "reset-gpios" directly. >> >> That's not the point. We expect correct hardware description. If you say >> now it has "reset-gpios" but later say "actually no, because it has >> PMU", I respond: no. Describe the hardware, not current Linux. > > I know that DT abstracts the HW. That said I don't see the problem with > this patch. The HW is abstracted just fine: > > shared PDn -> reset-gpios > shared power-supply -> vcc-supply > > Right now the DT ABI for the BT part is incomplete since it assume a > running WLAN part or some hog-gpios to pull the device out-of-reset > which is addressed by this patchset. > > Making use of the new power-sequencing fw is a Linux detail and I don't > see why the DT can't be extended later on. We always extend the DT if > something is missing or if we found a better way to handle devices. Sure, although I am not really confident that you understand the implications - you will not be able to switch to proper power-sequencing with above bindings, because it will not be just possible without breaking the ABI or changing hardware description (which you say it is "fine", so complete/done). I am fine with it, just mind the implications. Best regards, Krzysztof
