lkml.org 
[lkml]   [2020]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.

\
 
 \ /
  Last update: 2020-01-07 06:34    [W:0.095 / U:1.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site