> >
> >> -----Original Message-----
> >> From: Marco Felsch <m.felsch@xxxxxxxxxxxxxx>
> >> Sent: Tuesday, October 22, 2024 4:23 PM
> >> To: Sherry Sun <sherry.sun@xxxxxxx>
> >> Cc: POPESCU Catalin <catalin.popescu@xxxxxxxxxxxxxxxxxxxx>;
> Amitkumar
> >> Karwar <amitkumar.karwar@xxxxxxx>; Neeraj Sanjay Kale
> >> <neeraj.sanjaykale@xxxxxxx>; marcel@xxxxxxxxxxxx;
> >> luiz.dentz@xxxxxxxxx; robh@xxxxxxxxxx; krzk+dt@xxxxxxxxxx;
> >> conor+dt@xxxxxxxxxx; p.zabel@xxxxxxxxxxxxxx; linux-
> >> bluetooth@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux-
> >> kernel@xxxxxxxxxxxxxxx; GEO-CHHER-bsp-development <bsp-
> >> development.geo@xxxxxxxxxxxxxxxxxxxx>; Krzysztof Kozlowski
> >> <krzk@xxxxxxxxxx>
> >> Subject: Re: [PATCH 1/2] dt-bindings: net: bluetooth: nxp: add
> >> support for supply and reset
> >>
> >> On 24-10-22, Sherry Sun wrote:
> >>>
> >>>> -----Original Message-----
> >>>> From: Marco Felsch <m.felsch@xxxxxxxxxxxxxx>
> >>>> Sent: Tuesday, October 22, 2024 3:23 PM
> >>>> To: Sherry Sun <sherry.sun@xxxxxxx>
> >>>> Cc: POPESCU Catalin <catalin.popescu@xxxxxxxxxxxxxxxxxxxx>;
> >>>> Amitkumar Karwar <amitkumar.karwar@xxxxxxx>; Neeraj Sanjay Kale
> >>>> <neeraj.sanjaykale@xxxxxxx>; marcel@xxxxxxxxxxxx;
> >>>> luiz.dentz@xxxxxxxxx; robh@xxxxxxxxxx; krzk+dt@xxxxxxxxxx;
> >>>> conor+dt@xxxxxxxxxx; p.zabel@xxxxxxxxxxxxxx; linux-
> >>>> bluetooth@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux-
> >>>> kernel@xxxxxxxxxxxxxxx; GEO-CHHER-bsp-development <bsp-
> >>>> development.geo@xxxxxxxxxxxxxxxxxxxx>; Krzysztof Kozlowski
> >>>> <krzk@xxxxxxxxxx>
> >>>> Subject: Re: [PATCH 1/2] dt-bindings: net: bluetooth: nxp: add
> >>>> support for supply and reset
> >>>>
> >>>> On 24-10-22, Sherry Sun 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
> >>>>> Actually we should use vcc-supply to control the PDn pin, this is
> >>>>> the power supply for NXP wifi/BT.
> >>>> Please don't since this is regular pin on the wlan/bt device not
> >>>> the
> >> regulator.
> >>>> People often do that for GPIOs if the driver is missing the support
> >>>> to pull the reset/pdn/enable gpio but the enable-gpio on the
> >>>> regulator is to enable the regulator and _not_ the bt/wlan device.
> >>>>
> >>>> Therefore the implementation Catalin provided is the correct one.
> >>>>
> >>> For NXP wifi/BT, the PDn is the only power control pin, no specific
> >>> regulator, per my understanding, it is a common way to configure
> >>> this pin as the vcc-supply for the wifi interface(SDIO or PCIe).
> >> NACK. Each active external chip needs power, this is supplied via an
> >> supply- rail and this is what vcc/vdd/va/vdio/v***-supply are used for.
> >>
> >> The PDn is a digital input signal which tells the chip to go into
> >> power- down/reset mode or not.
> >>
> >>> reg_usdhc3_vmmc: regulator-usdhc3 {
> >>> compatible = "regulator-fixed";
> >>> regulator-name = "WLAN_EN";
> >>> regulator-min-microvolt = <3300000>;
> >>> regulator-max-microvolt = <3300000>;
> >>> gpio = <&pcal6524 20 GPIO_ACTIVE_HIGH>;
> >>> enable-active-high;
> >>> };
> >> This is what I meant previously, you do use a regualtor device for
> >> switching the PDn signal. This is not correct, albeit a lot of people
> >> are doing this because they don't want to adapt the driver. The 'gpio'
> >> within this regualtor should enable/disable this particular physical
> regualtor.
> >>
> > Sorry I see it differently. I checked the datasheet of NXP wifi
> > chip(taking IW612 as an example), the PDn pin is not the BT reset pin,
> > we usually take it as the PMIC_EN/WL_REG_ON pin to control the whole
> chip power supply.
> >
> > I think the reset-gpio added here should control the IND_RST_BT pin
> > (Independent software reset for Bluetooth), similar for the IND_RST_WL
> > pin(Independent software reset for Wi-Fi).
> >
> > Best Regards
> > Sherry
>
> PDn is not the BT reset :
>
> - PDn is a chip reset and is shared b/w BT and WIFI : hence, it needs to be
> managed as a reset control
>
Ok, so can you please also send out the corresponding wifi driver changes
for the reset control for reference? Otherwise I suppose the wifi part will
be powered off unexpectedly if unload the BT driver with your patch.
Best Regards
Sherry
> - BT reset is specific to BT and can be handled as a simple gpio as it's not
> being shared with other driver (e.g WIFI)
>
> I've only added support for power-supply and PDn.
>
> BT specific reset has been ignored so far as it's optional software reset and it
> can be left open if not needed in the design.
>
