Hi Marco, Catalin, Thank you for the patch. > > > > 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. > > Hi Marco, > I am not sure if this is a real use case for customers, we just thought of this > possibility during internal discussions. > Currently our actual use case is to use both wlan & bt at the same time. > Thanks for the clarification, now I am okay with this patch set. > > Best Regards > Sherry I think the patch series is an improvement. It looks good to me. Thanks, Neeraj
