[PATCH v2] Bluetooth: btusb: Improve stability for QCA devices

[PATCH v2] Bluetooth: btusb: Improve stability for QCA devices

[Zijun Hu]

From: Zijun Hu <quic_zijuhu@quicinc.com>

Controller will reset after NVM is downloaded for QCA
device, so wait a moment for reset Done then go ahead
to improve stability.

Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
---
 drivers/bluetooth/btusb.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index e03dfbd92fcc..20e36f53d2e7 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2994,6 +2994,7 @@ static int btusb_set_bdaddr_wcn6855(struct hci_dev *hdev,
 #define QCA_PATCH_UPDATED	0x80
 #define QCA_DFU_TIMEOUT		3000
 #define QCA_FLAG_MULTI_NVM      0x80
+#define QCA_BT_RESET_WAIT_MS    100
 
 #define WCN6855_2_0_RAM_VERSION_GF 0x400c1200
 #define WCN6855_2_1_RAM_VERSION_GF 0x400c1211
@@ -3320,6 +3321,10 @@ static int btusb_setup_qca(struct hci_dev *hdev)
 		err = btusb_setup_qca_load_nvm(hdev, &ver, info);
 		if (err < 0)
 			return err;
+		/* Controller will reset after NVM is downloaded, so wait a moment
+		 * for reset Done, it will improve stability.
+		 */
+		msleep(QCA_BT_RESET_WAIT_MS);
 	}
 
 	return 0;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

RE: [v2] Bluetooth: btusb: Improve stability for QCA devices

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=613387

---Test result---

Test Summary:
CheckPatch                    PASS      1.65 seconds
GitLint                       PASS      1.05 seconds
SubjectPrefix                 PASS      0.87 seconds
BuildKernel                   PASS      30.51 seconds
BuildKernel32                 PASS      27.10 seconds
Incremental Build with patchesPASS      37.19 seconds
TestRunner: Setup             PASS      474.61 seconds
TestRunner: l2cap-tester      PASS      13.49 seconds
TestRunner: bnep-tester       PASS      6.11 seconds
TestRunner: mgmt-tester       PASS      104.89 seconds
TestRunner: rfcomm-tester     PASS      7.80 seconds
TestRunner: sco-tester        PASS      7.87 seconds
TestRunner: smp-tester        PASS      7.64 seconds
TestRunner: userchan-tester   PASS      6.38 seconds



---
Regards,
Linux Bluetooth

Re: [PATCH v2] Bluetooth: btusb: Improve stability for QCA devices

[Marcel Holtmann]

Hi Zijun,

> Controller will reset after NVM is downloaded for QCA
> device, so wait a moment for reset Done then go ahead
> to improve stability.
> 
> Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
> ---
> drivers/bluetooth/btusb.c | 5 +++++
> 1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index e03dfbd92fcc..20e36f53d2e7 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -2994,6 +2994,7 @@ static int btusb_set_bdaddr_wcn6855(struct hci_dev *hdev,
> #define QCA_PATCH_UPDATED	0x80
> #define QCA_DFU_TIMEOUT		3000
> #define QCA_FLAG_MULTI_NVM      0x80
> +#define QCA_BT_RESET_WAIT_MS    100
> 
> #define WCN6855_2_0_RAM_VERSION_GF 0x400c1200
> #define WCN6855_2_1_RAM_VERSION_GF 0x400c1211
> @@ -3320,6 +3321,10 @@ static int btusb_setup_qca(struct hci_dev *hdev)
> 		err = btusb_setup_qca_load_nvm(hdev, &ver, info);
> 		if (err < 0)
> 			return err;
> +		/* Controller will reset after NVM is downloaded, so wait a moment
> +		 * for reset Done, it will improve stability.
> +		 */
> +		msleep(QCA_BT_RESET_WAIT_MS);

how hard is to just grab the data sheet and figure out the appropriate time to wait? I will be all documented and then reference the documentation.

I really dislike this "add a sleep here and sleep there". It might just work for now. The next hardware generation comes around or if placed on a different board just behaves a little bit different. And at some point we are at 10 seconds sleep and you start complaining why the controller initialization takes so long. Stop guessing and reference the data sheet.

Regards

Marcel

Re: [PATCH v2] Bluetooth: btusb: Improve stability for QCA devices

[zijuhu]

On 2022-02-12 00:22, Marcel Holtmann wrote:
> Hi Zijun,
> 
>> Controller will reset after NVM is downloaded for QCA
>> device, so wait a moment for reset Done then go ahead
>> to improve stability.
>> 
>> Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
>> ---
>> drivers/bluetooth/btusb.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>> 
>> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
>> index e03dfbd92fcc..20e36f53d2e7 100644
>> --- a/drivers/bluetooth/btusb.c
>> +++ b/drivers/bluetooth/btusb.c
>> @@ -2994,6 +2994,7 @@ static int btusb_set_bdaddr_wcn6855(struct 
>> hci_dev *hdev,
>> #define QCA_PATCH_UPDATED	0x80
>> #define QCA_DFU_TIMEOUT		3000
>> #define QCA_FLAG_MULTI_NVM      0x80
>> +#define QCA_BT_RESET_WAIT_MS    100
>> 
>> #define WCN6855_2_0_RAM_VERSION_GF 0x400c1200
>> #define WCN6855_2_1_RAM_VERSION_GF 0x400c1211
>> @@ -3320,6 +3321,10 @@ static int btusb_setup_qca(struct hci_dev 
>> *hdev)
>> 		err = btusb_setup_qca_load_nvm(hdev, &ver, info);
>> 		if (err < 0)
>> 			return err;
>> +		/* Controller will reset after NVM is downloaded, so wait a moment
>> +		 * for reset Done, it will improve stability.
>> +		 */
>> +		msleep(QCA_BT_RESET_WAIT_MS);
> 
> how hard is to just grab the data sheet and figure out the appropriate
> time to wait? I will be all documented and then reference the
> documentation.
> 

let me explain more for this patch:
a BT enable failure issue is reported for WCN6855 2.1 chip, the root
cause located is that HCI command is sent before controller reset is 
Done.
100ms delay is suggested by firmware team and it is a appropriate 
interval
based on verification. so these info is not available from data sheet 
currently.

> I really dislike this "add a sleep here and sleep there". It might
> just work for now. The next hardware generation comes around or if
> placed on a different board just behaves a little bit different. And
> at some point we are at 10 seconds sleep and you start complaining why
> the controller initialization takes so long. Stop guessing and
> reference the data sheet.
> 

you are right.
i will only restrict that delay to WCN6855 2.1 chip this issue is 
reported for.

> Regards
> 
> Marcel