On 24-11-19, Sherry Sun wrote: > > > -----Original Message----- > > From: Marco Felsch <m.felsch@xxxxxxxxxxxxxx> > > > > 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. Sure! > 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. To make it clear, I assumed that it's clear that independent (sub-)device handling require independent firmware (fw) files, which can be the case. NXP already supplies independent FW files for bt and wifi. We just need to ensure that the drivers are using these. That said the bt driver already checks if the fw has to be downloaded. > 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. Right, but this is a separate discussion not belonging to these driver changes. Also it's the common chicken-egg issue. You need to power the bus and release the device-reset before you can check which device is connected and to check if there would be a proper driver. > 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? You're aware that the btnxpuart.c driver already has the support for an independent software based reset? Not sure what this sw-reset does, due to the lack of missing documentation, but this is the only option to over-come your above mentioned use-case. I have to ask, is this really a use-case for someone? Either your device supports both: WLAN and BT or only one of WLAN/BT. If it would be only BT or WLAN you just don't need the specify the other one within your devicetree. Furthermore, this patchset does not break any current use-case you/NXP has. You still can use the combined fw version and still can use the not so user friendly user-space dependency of: "wlan driver _must_ be loaded" before the "bt driver _can_ be loaded" by just not using the split power handling. For use-space which wants to use the split version because there is no such dependecy. Regards, Marco
