> -----Original Message----- > From: Marco Felsch <m.felsch@xxxxxxxxxxxxxx> > Sent: Tuesday, November 19, 2024 8:52 PM > To: Sherry Sun <sherry.sun@xxxxxxx> > Cc: Bough Chen <haibo.chen@xxxxxxx>; 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>; Shenwei Wang <shenwei.wang@xxxxxxx>; Jun Li > <jun.li@xxxxxxx> > Subject: ttyRe: [PATCH 1/2] dt-bindings: net: bluetooth: nxp: add support for > supply and reset > > 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
