Messages in this thread | | | Date | Tue, 07 Jan 2020 13:34:04 +0800 | From | Rocky Liao <> | Subject | Re: [PATCH v3 2/4] Bluetooth: hci_qca: Retry btsoc initialize when it fails |
| |
在 2020-01-04 00:27,Matthias Kaehlcke 写道: > On Fri, Jan 03, 2020 at 02:31:46PM +0800, rjliao@codeaurora.org wrote: >> 在 2020-01-03 02:41,Matthias Kaehlcke 写道: >> >> > Hi Rocky, >> > >> > On Fri, Dec 27, 2019 at 03:21:28PM +0800, Rocky Liao wrote: >> > >> > > This patch adds the retry of btsoc initialization when it fails. >> > > There are >> > > reports that the btsoc initialization may fail on some platforms but >> > > the >> > > repro ratio is very low. The failure may be caused by UART, platform >> > > HW or >> > > the btsoc itself but it's very difficlut to root cause, given the >> > > repro >> > > ratio is very low. Add a retry for the btsoc initialization will >> > > resolve >> > > most of the failures and make Bluetooth finally works. >> > >> > Is this problem specific to a certain chipset? >> > >> > What are the symptoms? >> >> It's reported on Rome so far but I think the patch is potentially >> helpful >> for >> wcn399x as well. >> >> The symptoms is the firmware downloading failed due to the UART write >> timed >> out. > > Working around this with retries seems ok for now if the repro rate is > really low, but it shouldn't necessarily be interpreted as "the problem > is > fixed". Please mention the symptoms in the commit message for > documentation, > then the retries can potentially be removed in the futures when the > root > cause is fixed. > >> > > enum qca_btsoc_type soc_type = qca_soc_type(hu); >> > > const char *firmware_name = qca_get_firmware_name(hu); >> > > int ret; >> > > @@ -1275,6 +1280,7 @@ static int qca_setup(struct hci_uart *hu) >> > > */ >> > > set_bit(HCI_QUIRK_SIMULTANEOUS_DISCOVERY, &hdev->quirks); >> > > >> > > +retry: >> > > if (qca_is_wcn399x(soc_type)) { >> > > bt_dev_info(hdev, "setting up wcn3990"); >> > > >> > > @@ -1293,6 +1299,12 @@ static int qca_setup(struct hci_uart *hu) >> > > return ret; >> > > } else { >> > > bt_dev_info(hdev, "ROME setup"); >> > > + if (hu->serdev) { >> > > + qcadev = serdev_device_get_drvdata(hu->serdev); >> > > + gpiod_set_value_cansleep(qcadev->bt_en, 1); >> > > + /* Controller needs time to bootup. */ >> > > + msleep(150); >> > >> > Shouldn't this be in qca_power_on(), analogous to the power off code >> > from >> > "[1/4]Bluetooth: hci_qca: Add QCA Rome power off support to the >> > qca_power_off()"? >> > >> > qca_power_on() should then also be called for ROME. If you opt for this >> > it >> > should be done in a separate patch, or possibly merged into the one >> > mentioned above. >> > >> >> There is no qca_power_on() func and wcn399x is calling >> qca_wcn3990_init() to >> do power on, I prefer to not do this change this time. > > I would say it's precisely the right time to add this function. Patch 1 > of this > series adds handling of the BT_EN GPIO to qca_power_off(), now this > patch > duplicates the code of the BT_EN handling in qca_open(). > >> If it's needed > > 'needed' is a relative term. It certainly isn't needed from a purely > functional > POV. However it is desirable for encapsulation and to avoid code > duplication. > >> it should be a new patch to add qca_power_on() which supports both >> Rome and wcn399x. > > Agreed >
Have sent out a new patch to add the qca_power_on() API, will refresh this patch after that new patch merged.
> m.
| |