Message-ID:
 <DB9PR04MB84299E3E1776C60F5D1F0FF792202@DB9PR04MB8429.eurprd04.prod.outlook.com>
Date: Tue, 19 Nov 2024 10:09:35 +0000
From: Sherry Sun <sherry.sun@....com>
To: Marco Felsch <m.felsch@...gutronix.de>, Bough Chen <haibo.chen@....com>
CC: POPESCU Catalin <catalin.popescu@...ca-geosystems.com>, Amitkumar Karwar
	<amitkumar.karwar@....com>, Neeraj Sanjay Kale <neeraj.sanjaykale@....com>,
	"marcel@...tmann.org" <marcel@...tmann.org>, "luiz.dentz@...il.com"
	<luiz.dentz@...il.com>, "robh@...nel.org" <robh@...nel.org>,
	"krzk+dt@...nel.org" <krzk+dt@...nel.org>, "conor+dt@...nel.org"
	<conor+dt@...nel.org>, "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
	"linux-bluetooth@...r.kernel.org" <linux-bluetooth@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	GEO-CHHER-bsp-development <bsp-development.geo@...ca-geosystems.com>,
	Krzysztof Kozlowski <krzk@...nel.org>, Shenwei Wang <shenwei.wang@....com>,
	Jun Li <jun.li@....com>
Subject: RE: [PATCH 1/2] dt-bindings: net: bluetooth: nxp: add support for
 supply and reset



> -----Original Message-----
> From: Marco Felsch <m.felsch@...gutronix.de>
> Sent: Tuesday, November 19, 2024 6:18 AM
> To: Sherry Sun <sherry.sun@....com>
> Cc: POPESCU Catalin <catalin.popescu@...ca-geosystems.com>; Amitkumar
> Karwar <amitkumar.karwar@....com>; Neeraj Sanjay Kale
> <neeraj.sanjaykale@....com>; marcel@...tmann.org; luiz.dentz@...il.com;
> robh@...nel.org; krzk+dt@...nel.org; conor+dt@...nel.org;
> p.zabel@...gutronix.de; linux-bluetooth@...r.kernel.org;
> devicetree@...r.kernel.org; linux-kernel@...r.kernel.org; GEO-CHHER-bsp-
> development <bsp-development.geo@...ca-geosystems.com>; Krzysztof
> Kozlowski <krzk@...nel.org>
> Subject: Re: [PATCH 1/2] dt-bindings: net: bluetooth: nxp: add support for supply
> and reset
> 
> Hi,
> 
> gentle ping on this discussion since I'm still convinced that this the correct
> approach to add the reset mechanism and handle the power.

Hi Marco,

Sorry for the late reply. After internal discussion, we still have some confusion regarding this new feature.
This patch do improve the independent handling of wifi/BT, but with the controlling granularity segmentation, many different wifi/BT use cases need to be considered.
For the case -- WLAN (SDIO) not used + BT (UART) used:
The ideal behavior of BT should be reset and the standalone BT FW should be re-downloaded when unloading and re-loading the BT driver.
However, due to the regulator control and PDn reset control are bound to the SDIO bus instead of the WLAN device, the SDIO bus may be ready after kernel boot up. Although the WLAN is not used(WLAN driver is not loaded and WLAN FW is not downloaded), the corresponding regulator count and PDn reset count are both incremented by 1 through MMC pwrseq. Then with the BT driver remove & re-probe, the PDn reset cannot truly reset the BT chip due to the count been +1 by MMC pwrseq. So the BT will not reset and BT FW won't be re-downloaded when re-loading the BT driver, right?

Best Regards
Sherry
> 
> Regards,
>   Marco
> 
> On 24-10-28, Marco Felsch wrote:
> > On 24-10-28, Sherry Sun wrote:
> > >
> > > > From: Marco Felsch <m.felsch@...gutronix.de>
> > > >
> > > > On 24-10-28, Sherry Sun wrote:
> > > > >
> > > > > > From: Marco Felsch <m.felsch@...gutronix.de>
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > On 24-10-28, Sherry Sun wrote:
> > > > > > >
> > > > > > > > From: POPESCU Catalin
> > > > > > > > <catalin.popescu@...ca-geosystems.com>
> > > > > > > >
> > > > > > > > We use the NXP downstream driver mwifiex which doesn't
> > > > > > > > have support for regulator or PDn.
> > > > > > > >
> > > > > > > > However, regulator is already supported by the MMC core
> > > > > > > > (vmmc-
> > > > supply).
> > > > > > > >
> > > > > > > > For PDn, we use mmc pwrseq simple driver that has been
> > > > > > > > patched to add support for reset-control.
> > > > > > >
> > > > > > > Ok, thanks, the mmc change looks good for me, so there is no
> > > > > > > problem with the NXP SDIO wifi.
> > > > > > >
> > > > > > > But how do you plan to handle the NXP PCIe wifi? We also
> > > > > > > need to make sure the BT patch won't break the PCIe wifi function.
> > > > > >
> > > > > > Can you please elaborate how this could break the PCIe use-case?
> > > > >
> > > > > Similar to the SDIO wifi, if no corresponding reset control for
> > > > > the PDn pin in PCIe wifi driver, the wifi part will be
> > > > > unexpectedly powered off when removing the BT driver.
> > > >
> > > > Nope it's not that easy for PCIe case since the phy + link layer
> > > > handling is much more complex compared to the MMC case. For the
> > > > PCIe case the intial handling is very strict according to the PCIe
> > > > spec and we can't handle the BT device independently.
> > > >
> > > > _BUT_ this patch doesn't cause any regression for the PCIe
> > > > use-case since the support added by Catalin is optional which
> > > > means that the user don't have to use these options.
> > > >
> > > > To sum up:
> > > >
> > > > WLAN (PCIe) used + BT (UART) used -> no independent handling
> > > >                                      possible. BT depends on WLAN.
> > > >
> > > > WLAN (PCIe) not used + BT (UART) used -> This patchset allow us to
> > > >                                          handle BT. Without the patchset
> > > > 					 this is not possible.
> > > >
> > > > WLAN (SDIO) + BT (UART) -> This patchset and the mmc-power-seq
> patchset
> > > >                            allow us to handle WLAN and BT independently
> > > > 			   regardless if BT or WLAN is used or not.
> > >
> > > If we add the reset-gpios property in the BT dts node when using the
> > > SDIO wifi chip, my concern is for some host platforms, taking
> > > i.MX95-19x19-EVK as an example, it supports both SDIO and PCIe
> > > interface wifi chip through the M.2 connector, when customers want
> > > to plug in the PCIe wifi chip, they have to remove the reset-gpios
> > > in the BT dts node to avoid the PCIe WLAN been affected by BT, right?
> >
> > I don't know the i.MX95-19x19-EVK platform since it is not upstream.
> > If you want to support both:
> >
> > > > WLAN (PCIe) used + BT (UART) used -> no independent handling
> > > >                                      possible. BT depends on WLAN.
> >
> > and
> >
> > > > WLAN (SDIO) + BT (UART) -> This patchset and the mmc-power-seq
> patchset
> > > >                            allow us to handle WLAN and BT independently
> > > > 			   regardless if BT or WLAN is used or not.
> >
> > you need to stick with the dependent handling which is no problem once
> > this patchset get applied if your system support hot-plug. If hot-plug
> > is not possible you could consider unsing overlays.
> >
> > However, this patchset does _NOT_ cause any regression neither for the
> > MMC nor the PCIe use-case, and you don't have to touch your DTS files.
> > It would be an improvement for platforms (not speaking of NXP EVK
> > platforms) which utilize the MMC+UART interfaces only.
> >
> > > And it looks strange that we can only add the reset-gpios BT
> > > property to the hosts that only support SDIO WLAN, we hope there is
> > > a solution for the PCIe WLAN too.
> >
> > "We hope there is a solution" <-- This is not how upstream work.
> >
> > Also as said: The WLAN PCIe interface must/should be compatible with
> > the PCIe Spec. There is no way that we can handle both devices
> > independent since the PCIe spec specifies the power-up-sequence very
> > strict.
> >
> > If for example, we do handle it independent and the BT part brings the
> > device out-of-reset while the PCIe bus is not yet ready, the device's
> > WLAN PCIe subsystem may get confused.
> >
> > There are two solution NXP could provide:
> >
> >  - The PCIe WLAN/BT devices exposes all devices WLAN + BT via PCIe, this
> >    would eliminate the UART part.
> >  - All new WLAN/BT devices do have a separate hw reset line for each
> >    radio the device supports.
> >
> > Regards,
> >   Marco

Powered by blists - more mailing lists