Re: [PATCH v6 5/6] Bluetooth: hci_qca: Update baudrate change wait time for wcn3990

From: Balakrishna Godavarthi
Date: Fri Dec 28 2018 - 06:25:48 EST

Hi Matthias,

On 2018-12-28 02:30, Matthias Kaehlcke wrote:
On Thu, Dec 27, 2018 at 01:01:35PM +0530, Balakrishna Godavarthi wrote:
This patch will update the baudrate change request wait time from
300 ms to 100 ms. When host sends the change baudrate request to
the controller, controller sets its clock and wait until the
clocks settle down. Here the Wait time is required for both
host and controller to be on sync.

Ultimately up to you, but I would advise against adding 'improvement'
changes to this series. The scope of the series is already fairly
vague ("Bug fixes for Qualcomm BT chip wcn3990"), with at least some
patches that could be sent individually, which would reduce churn when

[Bala]: yes your correct will send this as improvement patch once the series is merged.

Signed-off-by: Balakrishna Godavarthi <bgodavar@xxxxxxxxxxxxxx>

Changes in v6:
* intial patch.

drivers/bluetooth/hci_qca.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 4677a6a2716a..61b0fb1ff32f 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -60,7 +60,8 @@

+#define WCN3990_BD_SETTLE_TIMEOUT_MS 100

My testing suggests that even the lower 100 ms delay isn't needed, if
different parts that require a delay are addressed more specifically,
instead of using a single long 'settle' delay
( has some

[Bala]: i to agree with you. but from the point 1, we have many chances of getting
baudrate change delay. after lot of stress test and experiments we found 100 ms is reasonable to handle all
of them together.

My idea was to sent a patch after this series has landed to avoid
interfering with it.

[Bala]: sure will drop this change from the series.