Bug fixes for Qualcomm BT chip wcn3990.

PATCH Superseded Balakrishna Godavarthi 3 participants 11 messages Jan 16, 2019 – Jan 24, 2019

Subsystems (3)

Arm Qualcomm mailing list Bluetooth drivers Qualcomm Bluetooth driver

lore

Share & tools

lore

Balakrishna Godavarthi

author

2019-01-16 11:46 UTC #0 lore raw

v8 cover Bug fixes for Qualcomm BT chip wcn3990.

The below issues are found in our recent testing.

1. Observed device is not going into off state or not responding. As wcn3990 require a power pulses to turn on the irrespctive of igniting regulators, it was observed that power on or power off pulses are not in sync with respective to chip.
The below patch will help us to wait until byte is pushed on to wires.

* Bluetooth: hci_qca: use wait_until_sent() for power pulses

2. Observed Chip responding when we are in sleep.
This is due to turn on flow control during change baudrate request. The below patch will only pull the RTS line high instead of turning off the flow.

* Bluetooth: hci_qca: Pull RTS line high for baudrate change command.

3. Disable IBS state machine and flush Tx buffer
We are disabling IBS and flushing the Tx buffer before turning off the chip.

This is due to IBS state machine is active when we turn off the chip. This will stop queuing IBS protocol bytes.

* Bluetooth: hci_qca: Disable IBS state machine and flush Tx buffer

Changes in v8:
* dropped inject the command complete event.
* added one second time for the power pules instead of the indefinite time.

Changes in v7:
* dropped frame reassmebly error patch.
* dropped baudrate change wait time patch.
* increased a wait to 5 ms for power pulses.

Changes in v6:
* added serdev_device_write_flush in qca_send_power_pulse().
* added new patch to update the baudrate change wait time.

Changes in V5:
* added serdev_device_write_flush before sending the power off pulse during shutdown.

Changes in v4:
* used serdev_device_write_buf() instead of serdev_device_write().
* added new patch to stop logging of 0xfc00 timeout on console.

Changes in v3:
* moved IBS & qca_flush to different patch
* updated comments in code fo Deassert RTS patch

Balakrishna Godavarthi (3):
Bluetooth: hci_qca: use wait_until_sent() for power pulses
Bluetooth: hci_qca: Deassert RTS while baudrate change command
Bluetooth: hci_qca: Disable IBS state machine and flush Tx buffer

 drivers/bluetooth/hci_qca.c | 76 +++++++++++++++++++------------------
 1 file changed, 40 insertions(+), 36 deletions(-)

Signature · 2 lines

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Balakrishna Godavarthi

author

2019-01-16 11:46 UTC #1 lore raw

PATCH v8 1/3 Bluetooth: hci_qca: use wait_until_sent() for power pulses

wcn3990 requires a power pulse to turn ON/OFF along with regulators. Sometimes we are observing the power pulses are sent out with some time delay, due to queuing these commands. This is causing synchronization issues with chip, which intern delay the chip setup or may end up with communication issues.

Signed-off-by Balakrishna Godavarthi <[email protected]>

---
Changes in v8:
* Updated 1 second timeout instead of indefinite wait.

Changes in v7:
* updated the wait time to 5 ms after sending power pulses.

Changes in v6:
* added serdev_device_write_flush() in qca_send_power_pulse instead during the power off pulse.

Changes in v5:
* added serdev_device_write_flush() in qca_power_off().

---
 drivers/bluetooth/hci_qca.c | 46 ++++++++++++++++---------------------
 1 file changed, 20 insertions(+), 26 deletions(-)

drivers/bluetooth/hci_qca.c +20 ~~-26~~

index f036c8f98ea3..681bfa30467e 100644
@@ -60,6 +60,7 @@
 #define IBS_WAKE_RETRANS_TIMEOUT_MS	100
 #define IBS_TX_IDLE_TIMEOUT_MS		2000
 #define BAUDRATE_SETTLE_TIMEOUT_MS	300
+#define POWER_PULSE_TRANS_TIMEOUT_MS	1000
 
 /* susclk rate */
 #define SUSCLK_RATE_32KHZ	32768

@@ -1013,11 +1014,10 @@ static inline void host_set_baudrate(struct hci_uart *hu, unsigned int speed)
 		hci_uart_set_baudrate(hu, speed);
 }
 
-static int qca_send_power_pulse(struct hci_dev *hdev, u8 cmd)
+static int qca_send_power_pulse(struct hci_uart *hu, u8 cmd)
 {
-	struct hci_uart *hu = hci_get_drvdata(hdev);
-	struct qca_data *qca = hu->priv;
-	struct sk_buff *skb;
+	int ret;
+	int timeout = __msecs_to_jiffies(POWER_PULSE_TRANS_TIMEOUT_MS);
 
 	/* These power pulses are single byte command which are sent
 	 * at required baudrate to wcn3990. On wcn3990, we have an external

@@ -1029,22 +1029,22 @@ static int qca_send_power_pulse(struct hci_dev *hdev, u8 cmd)
 	 * save power. Disabling hardware flow control is mandatory while
 	 * sending power pulses to SoC.
 	 */
-	bt_dev_dbg(hdev, "sending power pulse %02x to SoC", cmd);
-
-	skb = bt_skb_alloc(sizeof(cmd), GFP_KERNEL);
-	if (!skb)
-		return -ENOMEM;
+	bt_dev_dbg(hu->hdev, "sending power pulse %02x to controller", cmd);
 
+	serdev_device_write_flush(hu->serdev);
 	hci_uart_set_flow_control(hu, true);
+	ret = serdev_device_write_buf(hu->serdev, &cmd, sizeof(cmd));
+	if (ret < 0) {
+		bt_dev_err(hu->hdev, "failed to send power pulse %02x", cmd);
+		return ret;
+	}
 
-	skb_put_u8(skb, cmd);
-	hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
-
-	skb_queue_tail(&qca->txq, skb);
-	hci_uart_tx_wakeup(hu);
-
-	/* Wait for 100 uS for SoC to settle down */
-	usleep_range(100, 200);
+	serdev_device_wait_until_sent(hu->serdev, timeout);
+	/* Wait of 5ms is required for assuring to send the byte on the Tx
+	 * line and also for the controller to settle down for the received
+	 * byte.
+	 */
+	usleep_range(5000, 6000);
 	hci_uart_set_flow_control(hu, false);
 
 	return 0;

@@ -1116,7 +1116,6 @@ static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type)
 
 static int qca_wcn3990_init(struct hci_uart *hu)
 {
-	struct hci_dev *hdev = hu->hdev;
 	struct qca_serdev *qcadev;
 	int ret;

@@ -1139,12 +1138,12 @@ static int qca_wcn3990_init(struct hci_uart *hu)
 
 	/* Forcefully enable wcn3990 to enter in to boot mode. */
 	host_set_baudrate(hu, 2400);
-	ret = qca_send_power_pulse(hdev, QCA_WCN3990_POWEROFF_PULSE);
+	ret = qca_send_power_pulse(hu, QCA_WCN3990_POWEROFF_PULSE);
 	if (ret)
 		return ret;
 
 	qca_set_speed(hu, QCA_INIT_SPEED);
-	ret = qca_send_power_pulse(hdev, QCA_WCN3990_POWERON_PULSE);
+	ret = qca_send_power_pulse(hu, QCA_WCN3990_POWERON_PULSE);
 	if (ret)
 		return ret;

@@ -1274,13 +1273,8 @@ static const struct qca_vreg_data qca_soc_data = {
 
 static void qca_power_shutdown(struct hci_uart *hu)
 {
-	struct serdev_device *serdev = hu->serdev;
-	unsigned char cmd = QCA_WCN3990_POWEROFF_PULSE;
-
 	host_set_baudrate(hu, 2400);
-	hci_uart_set_flow_control(hu, true);
-	serdev_device_write_buf(serdev, &cmd, sizeof(cmd));
-	hci_uart_set_flow_control(hu, false);
+	qca_send_power_pulse(hu, QCA_WCN3990_POWEROFF_PULSE);
 	qca_power_setup(hu, false);
 }

Signature · 2 lines

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Matthias Kaehlcke

2019-01-16 20:22 UTC #2 lore raw

Re: [PATCH v8 1/3] Bluetooth: hci_qca: use wait_until_sent() for power pulses

Quoted 29 lines · Balakrishna Godavarthi

wcn3990 requires a power pulse to turn ON/OFF along with regulators. Sometimes we are observing the power pulses are sent out with some time delay, due to queuing these commands. This is causing synchronization issues with chip, which intern delay the chip setup or may end up with communication issues.
Signed-off-by Balakrishna Godavarthi <[email protected]>
---
Changes in v8:
* Updated 1 second timeout instead of indefinite wait.
Changes in v7:
* updated the wait time to 5 ms after sending power pulses.
Changes in v6:
* added serdev_device_write_flush() in qca_send_power_pulse instead during the power off pulse.
Changes in v5:
* added serdev_device_write_flush() in qca_power_off().
---
 drivers/bluetooth/hci_qca.c | 46 ++++++++++++++++---------------------
 1 file changed, 20 insertions(+), 26 deletions(-)
drivers/bluetooth/hci_qca.c +0 -0
index f036c8f98ea3..681bfa30467e 100644

drivers/bluetooth/hci_qca.c line 63

Quoted 4 lines

drivers/bluetooth/hci_qca.c +1 -0

@@ -60,6 +60,7 @@
 #define IBS_WAKE_RETRANS_TIMEOUT_MS	100
 #define IBS_TX_IDLE_TIMEOUT_MS		2000
 #define BAUDRATE_SETTLE_TIMEOUT_MS	300
+#define POWER_PULSE_TRANS_TIMEOUT_MS	1000

nit: Not that it should make a different in normal operation, but 1s seems extreme. Is there really any chance that the byte hasn't been sent after say 100ms (which is still an eternity for a single byte)?

Quoted 4 lines

drivers/bluetooth/hci_qca.c +0 -0

 /* susclk rate */
 #define SUSCLK_RATE_32KHZ	32768

@@ -1013,11 +1014,10 @@ static inline void host_set_baudrate(struct hci_uart *hu, unsigned int speed)
 		hci_uart_set_baudrate(hu, speed);

drivers/bluetooth/hci_qca.c static inline void host_set_baudrate(struct hci_uart *hu, unsigned int speed) · line 1020

Quoted 10 lines

drivers/bluetooth/hci_qca.c +3 -4

 }
 
-static int qca_send_power_pulse(struct hci_dev *hdev, u8 cmd)
+static int qca_send_power_pulse(struct hci_uart *hu, u8 cmd)
 {
-	struct hci_uart *hu = hci_get_drvdata(hdev);
-	struct qca_data *qca = hu->priv;
-	struct sk_buff *skb;
+	int ret;
+	int timeout = __msecs_to_jiffies(POWER_PULSE_TRANS_TIMEOUT_MS);

use msecs_to_jiffies()

Quoted 25 lines

drivers/bluetooth/hci_qca.c +7 -9

 	/* These power pulses are single byte command which are sent
 	 * at required baudrate to wcn3990. On wcn3990, we have an external

@@ -1029,22 +1029,22 @@ static int qca_send_power_pulse(struct hci_dev *hdev, u8 cmd)
 	 * save power. Disabling hardware flow control is mandatory while
 	 * sending power pulses to SoC.
 	 */
-	bt_dev_dbg(hdev, "sending power pulse %02x to SoC", cmd);
-
-	skb = bt_skb_alloc(sizeof(cmd), GFP_KERNEL);
-	if (!skb)
-		return -ENOMEM;
+	bt_dev_dbg(hu->hdev, "sending power pulse %02x to controller", cmd);
 
+	serdev_device_write_flush(hu->serdev);
 	hci_uart_set_flow_control(hu, true);
+	ret = serdev_device_write_buf(hu->serdev, &cmd, sizeof(cmd));
+	if (ret < 0) {
+		bt_dev_err(hu->hdev, "failed to send power pulse %02x", cmd);
+		return ret;
+	}
 
-	skb_put_u8(skb, cmd);
-	hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
-
-	skb_queue_tail(&qca->txq, skb);

drivers/bluetooth/hci_qca.c static int qca_send_power_pulse(struct hci_dev *hdev, u8 cmd) · line 1047

Quoted 10 lines

drivers/bluetooth/hci_qca.c +6 -4

-	hci_uart_tx_wakeup(hu);
-
-	/* Wait for 100 uS for SoC to settle down */
-	usleep_range(100, 200);
+	serdev_device_wait_until_sent(hu->serdev, timeout);
+	/* Wait of 5ms is required for assuring to send the byte on the Tx
+	 * line and also for the controller to settle down for the received
+	 * byte.
+	 */
+	usleep_range(5000, 6000);

I incorrectly claimed that there might be still bytes sitting in the UART FIFO when serdev_device_wait_until_sent() returns, Johan corrected me on that (thanks!). So if it takes the SoC 100us to settle down we should be good with the original code.

Cheers

Matthias

Balakrishna Godavarthi

author

2019-01-17 10:25 UTC #3 lore raw

Re: [PATCH v8 1/3] Bluetooth: hci_qca: use wait_until_sent() for power pulses

Hi Matthias,

Quoted 47 lines · Matthias Kaehlcke

Quoted 30 lines · Balakrishna Godavarthi
wcn3990 requires a power pulse to turn ON/OFF along with regulators. Sometimes we are observing the power pulses are sent out with some time delay, due to queuing these commands. This is causing synchronization issues with chip, which intern delay the chip setup or may end up with communication issues.
Signed-off-by Balakrishna Godavarthi <[email protected]>
---
Changes in v8:
* Updated 1 second timeout instead of indefinite wait.
Changes in v7:
* updated the wait time to 5 ms after sending power pulses.
Changes in v6:
* added serdev_device_write_flush() in qca_send_power_pulse instead during the power off pulse.
Changes in v5:
* added serdev_device_write_flush() in qca_power_off().
---
 drivers/bluetooth/hci_qca.c | 46 
++++++++++++++++---------------------
 1 file changed, 20 insertions(+), 26 deletions(-)
drivers/bluetooth/hci_qca.c +0 -0
index f036c8f98ea3..681bfa30467e 100644
drivers/bluetooth/hci_qca.c line 63
Quoted 4 lines
drivers/bluetooth/hci_qca.c +1 -0
@@ -60,6 +60,7 @@
 #define IBS_WAKE_RETRANS_TIMEOUT_MS	100
 #define IBS_TX_IDLE_TIMEOUT_MS		2000
 #define BAUDRATE_SETTLE_TIMEOUT_MS	300
+#define POWER_PULSE_TRANS_TIMEOUT_MS	1000
nit: Not that it should make a different in normal operation, but 1s seems extreme. Is there really any chance that the byte hasn't been sent after say 100ms (which is still an eternity for a single byte)?
Quoted 7 lines
drivers/bluetooth/hci_qca.c +0 -0
 /* susclk rate */
 #define SUSCLK_RATE_32KHZ	32768
@@ -1013,11 +1014,10 @@ static inline void host_set_baudrate(struct 
 hci_uart *hu, unsigned int speed)
 		hci_uart_set_baudrate(hu, speed);
 }
 

Quoted 11 lines

drivers/bluetooth/hci_qca.c static inline void host_set_baudrate(struct hci_uart *hu, unsigned int speed) · line 1020
Quoted 8 lines
drivers/bluetooth/hci_qca.c +3 -4
-static int qca_send_power_pulse(struct hci_dev *hdev, u8 cmd)
+static int qca_send_power_pulse(struct hci_uart *hu, u8 cmd)
 {
-	struct hci_uart *hu = hci_get_drvdata(hdev);
-	struct qca_data *qca = hu->priv;
-	struct sk_buff *skb;
+	int ret;
+	int timeout = __msecs_to_jiffies(POWER_PULSE_TRANS_TIMEOUT_MS);
use msecs_to_jiffies()

[Bala]: will upadte.

Quoted 33 lines

drivers/bluetooth/hci_qca.c +10 ~~-13~~

 	/* These power pulses are single byte command which are sent
 	 * at required baudrate to wcn3990. On wcn3990, we have an external

@@ -1029,22 +1029,22 @@ static int qca_send_power_pulse(struct hci_dev 
 *hdev, u8 cmd)
 	 * save power. Disabling hardware flow control is mandatory while
 	 * sending power pulses to SoC.
 	 */
-	bt_dev_dbg(hdev, "sending power pulse %02x to SoC", cmd);
-
-	skb = bt_skb_alloc(sizeof(cmd), GFP_KERNEL);
-	if (!skb)
-		return -ENOMEM;
+	bt_dev_dbg(hu->hdev, "sending power pulse %02x to controller", cmd);
 
+	serdev_device_write_flush(hu->serdev);
 	hci_uart_set_flow_control(hu, true);
+	ret = serdev_device_write_buf(hu->serdev, &cmd, sizeof(cmd));
+	if (ret < 0) {
+		bt_dev_err(hu->hdev, "failed to send power pulse %02x", cmd);
+		return ret;
+	}
 
-	skb_put_u8(skb, cmd);
-	hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
-
-	skb_queue_tail(&qca->txq, skb);
-	hci_uart_tx_wakeup(hu);
-
-	/* Wait for 100 uS for SoC to settle down */
-	usleep_range(100, 200);
+	serdev_device_wait_until_sent(hu->serdev, timeout);
+	/* Wait of 5ms is required for assuring to send the byte on the Tx
+	 * line and also for the controller to settle down for the received

Quoted 8 lines

drivers/bluetooth/hci_qca.c static int qca_send_power_pulse(struct hci_dev *hdev, u8 cmd) · line 1047
Quoted 3 lines
drivers/bluetooth/hci_qca.c +3 -0
+	 * byte.
+	 */
+	usleep_range(5000, 6000);
I incorrectly claimed that there might be still bytes sitting in the UART FIFO when serdev_device_wait_until_sent() returns, Johan corrected me on that (thanks!). So if it takes the SoC 100us to settle down we should be good with the original code.

[Bala]: sure will revert, i think he commented that wait_until_sent()
will only guarantee circular buffer is empty. if
wait_until_sent()
guarantee us that the data was transmitted from the FIFO, then
100us will work.

Quoted 4 lines

Cheers
Matthias

Signature · 2 lines

Regards
Balakrishna.

Johan Hovold

2019-01-17 16:13 UTC #4 lore raw

Re: [PATCH v8 1/3] Bluetooth: hci_qca: use wait_until_sent() for power pulses

Quoted 18 lines · Balakrishna Godavarthi

Hi Matthias,
Quoted 5 lines · Matthias Kaehlcke
Quoted 5 lines
drivers/bluetooth/hci_qca.c +3 -2
-	/* Wait for 100 uS for SoC to settle down */
-	usleep_range(100, 200);
+	serdev_device_wait_until_sent(hu->serdev, timeout);
+	/* Wait of 5ms is required for assuring to send the byte on the Tx
+	 * line and also for the controller to settle down for the received
Quoted 8 lines
drivers/bluetooth/hci_qca.c static int qca_send_power_pulse(struct hci_dev *hdev, u8 cmd) · line 1047
Quoted 3 lines
drivers/bluetooth/hci_qca.c +3 -0
+	 * byte.
+	 */
+	usleep_range(5000, 6000);
I incorrectly claimed that there might be still bytes sitting in the UART FIFO when serdev_device_wait_until_sent() returns, Johan corrected me on that (thanks!). So if it takes the SoC 100us to settle down we should be good with the original code.

Quoted 4 lines

[Bala]: sure will revert, i think he commented that wait_until_sent() will only guarantee circular buffer is empty. if wait_until_sent() guarantee us that the data was transmitted from the FIFO, then 100us will work.

No, Matthias is correct; I claimed that the UART FIFO will be empty (at least as long as flow control is disabled, otherwise it may never empty and we therefore also have a time out).

Johan

Balakrishna Godavarthi

author

2019-01-17 16:55 UTC #5 lore raw

Re: [PATCH v8 1/3] Bluetooth: hci_qca: use wait_until_sent() for power pulses

Quoted 24 lines · Johan Hovold

Quoted 18 lines · Balakrishna Godavarthi
Hi Matthias,
Quoted 5 lines · Matthias Kaehlcke
Quoted 5 lines
drivers/bluetooth/hci_qca.c +3 -2
-	/* Wait for 100 uS for SoC to settle down */
-	usleep_range(100, 200);
+	serdev_device_wait_until_sent(hu->serdev, timeout);
+	/* Wait of 5ms is required for assuring to send the byte on the Tx
+	 * line and also for the controller to settle down for the received
Quoted 8 lines
drivers/bluetooth/hci_qca.c static int qca_send_power_pulse(struct hci_dev *hdev, u8 cmd) · line 1047
Quoted 3 lines
drivers/bluetooth/hci_qca.c +3 -0
+	 * byte.
+	 */
+	usleep_range(5000, 6000);
I incorrectly claimed that there might be still bytes sitting in the UART FIFO when serdev_device_wait_until_sent() returns, Johan corrected me on that (thanks!). So if it takes the SoC 100us to settle down we should be good with the original code.
Quoted 4 lines
[Bala]: sure will revert, i think he commented that wait_until_sent() will only guarantee circular buffer is empty. if wait_until_sent() guarantee us that the data was transmitted from the FIFO, then 100us will work.

Quoted 5 lines

No, Matthias is correct; I claimed that the UART FIFO will be empty (at least as long as flow control is disabled, otherwise it may never empty and we therefore also have a time out).
Johan

[Bala]: Thanks Johan for clarification.

Signature · 2 lines

Regards
Balakrishna.

Balakrishna Godavarthi

author

2019-01-24 11:20 UTC #6 lore raw

Re: [PATCH v8 1/3] Bluetooth: hci_qca: use wait_until_sent() for power pulses

In reply to Matthias Kaehlcke

Hi Matthias,

Quoted 26 lines · Matthias Kaehlcke

Quoted 25 lines · Balakrishna Godavarthi
wcn3990 requires a power pulse to turn ON/OFF along with regulators. Sometimes we are observing the power pulses are sent out with some time delay, due to queuing these commands. This is causing synchronization issues with chip, which intern delay the chip setup or may end up with communication issues.
Signed-off-by Balakrishna Godavarthi <[email protected]>
---
Changes in v8:
* Updated 1 second timeout instead of indefinite wait.
Changes in v7:
* updated the wait time to 5 ms after sending power pulses.
Changes in v6:
* added serdev_device_write_flush() in qca_send_power_pulse instead during the power off pulse.
Changes in v5:
* added serdev_device_write_flush() in qca_power_off().
---
 drivers/bluetooth/hci_qca.c | 46 
++++++++++++++++---------------------
 1 file changed, 20 insertions(+), 26 deletions(-)

Quoted 14 lines

drivers/bluetooth/hci_qca.c line 63
Quoted 9 lines
drivers/bluetooth/hci_qca.c +1 -0
index f036c8f98ea3..681bfa30467e 100644
@@ -60,6 +60,7 @@
 #define IBS_WAKE_RETRANS_TIMEOUT_MS	100
 #define IBS_TX_IDLE_TIMEOUT_MS		2000
 #define BAUDRATE_SETTLE_TIMEOUT_MS	300
+#define POWER_PULSE_TRANS_TIMEOUT_MS	1000
nit: Not that it should make a different in normal operation, but 1s seems extreme. Is there really any chance that the byte hasn't been sent after say 100ms (which is still an eternity for a single byte)?

[Bala]: i missed to address this. for now let us have 1 second delay.
based on stress test or further enchantments we can reduce this
delay.

Quoted 63 lines

Quoted 5 lines

drivers/bluetooth/hci_qca.c +0 -0

 /* susclk rate */
 #define SUSCLK_RATE_32KHZ	32768

@@ -1013,11 +1014,10 @@ static inline void host_set_baudrate(struct 
 hci_uart *hu, unsigned int speed)
 		hci_uart_set_baudrate(hu, speed);

drivers/bluetooth/hci_qca.c static inline void host_set_baudrate(struct · line 1021

Quoted 10 lines

drivers/bluetooth/hci_qca.c +3 -4

 }
 
-static int qca_send_power_pulse(struct hci_dev *hdev, u8 cmd)
+static int qca_send_power_pulse(struct hci_uart *hu, u8 cmd)
 {
-	struct hci_uart *hu = hci_get_drvdata(hdev);
-	struct qca_data *qca = hu->priv;
-	struct sk_buff *skb;
+	int ret;
+	int timeout = __msecs_to_jiffies(POWER_PULSE_TRANS_TIMEOUT_MS);

use msecs_to_jiffies()

Quoted 26 lines

drivers/bluetooth/hci_qca.c +7 -9

 	/* These power pulses are single byte command which are sent
 	 * at required baudrate to wcn3990. On wcn3990, we have an external

@@ -1029,22 +1029,22 @@ static int qca_send_power_pulse(struct hci_dev 
 *hdev, u8 cmd)
 	 * save power. Disabling hardware flow control is mandatory while
 	 * sending power pulses to SoC.
 	 */
-	bt_dev_dbg(hdev, "sending power pulse %02x to SoC", cmd);
-
-	skb = bt_skb_alloc(sizeof(cmd), GFP_KERNEL);
-	if (!skb)
-		return -ENOMEM;
+	bt_dev_dbg(hu->hdev, "sending power pulse %02x to controller", cmd);
 
+	serdev_device_write_flush(hu->serdev);
 	hci_uart_set_flow_control(hu, true);
+	ret = serdev_device_write_buf(hu->serdev, &cmd, sizeof(cmd));
+	if (ret < 0) {
+		bt_dev_err(hu->hdev, "failed to send power pulse %02x", cmd);
+		return ret;
+	}
 
-	skb_put_u8(skb, cmd);
-	hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
-
-	skb_queue_tail(&qca->txq, skb);

drivers/bluetooth/hci_qca.c static int qca_send_power_pulse(struct hci_dev · line 1048

Quoted 10 lines

drivers/bluetooth/hci_qca.c +6 -4

-	hci_uart_tx_wakeup(hu);
-
-	/* Wait for 100 uS for SoC to settle down */
-	usleep_range(100, 200);
+	serdev_device_wait_until_sent(hu->serdev, timeout);
+	/* Wait of 5ms is required for assuring to send the byte on the Tx
+	 * line and also for the controller to settle down for the received
+	 * byte.
+	 */
+	usleep_range(5000, 6000);

Cheers

Matthias

Signature · 2 lines

Regards
Balakrishna.

Balakrishna Godavarthi

author

2019-01-16 11:46 UTC #7 lore raw

PATCH v8 2/3 Bluetooth: hci_qca: Deassert RTS while baudrate change command

In reply to Balakrishna Godavarthi

This patch will help to stop frame reassembly errors while changing the baudrate. This is because host send a change baudrate request command to the chip with 115200 bps, Whereas chip will change their UART clocks to the enable for new baudrate and sends the response for the change request command with newer baudrate, On host side we are still operating in 115200 bps which results of reading garbage data. Here we are pulling RTS line, so that chip we will wait to send data to host until host change its baudrate.

Signed-off-by Balakrishna Godavarthi <[email protected]>

Tested-by Matthias Kaehlcke <[email protected]>

Reviewed-by Matthias Kaehlcke <[email protected]>

---
Note: will keep this change for now. If any change required after further
discussions i will update accordingly.

---
 drivers/bluetooth/hci_qca.c | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

drivers/bluetooth/hci_qca.c +13 ~~-11~~

index 681bfa30467e..7e4afcf40da2 100644
@@ -964,7 +964,6 @@ static int qca_set_baudrate(struct hci_dev *hdev, uint8_t baudrate)
 	struct hci_uart *hu = hci_get_drvdata(hdev);
 	struct qca_data *qca = hu->priv;
 	struct sk_buff *skb;
-	struct qca_serdev *qcadev;
 	u8 cmd[] = { 0x01, 0x48, 0xFC, 0x01, 0x00 };
 
 	if (baudrate > QCA_BAUDRATE_3200000)

@@ -978,13 +977,6 @@ static int qca_set_baudrate(struct hci_dev *hdev, uint8_t baudrate)
 		return -ENOMEM;
 	}
 
-	/* Disabling hardware flow control is mandatory while
-	 * sending change baudrate request to wcn3990 SoC.
-	 */
-	qcadev = serdev_device_get_drvdata(hu->serdev);
-	if (qcadev->btsoc_type == QCA_WCN3990)
-		hci_uart_set_flow_control(hu, true);
-
 	/* Assign commands to change baudrate and packet type. */
 	skb_put_data(skb, cmd, sizeof(cmd));
 	hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;

@@ -1000,9 +992,6 @@ static int qca_set_baudrate(struct hci_dev *hdev, uint8_t baudrate)
 	schedule_timeout(msecs_to_jiffies(BAUDRATE_SETTLE_TIMEOUT_MS));
 	set_current_state(TASK_RUNNING);
 
-	if (qcadev->btsoc_type == QCA_WCN3990)
-		hci_uart_set_flow_control(hu, false);
-
 	return 0;
 }

@@ -1091,6 +1080,7 @@ static int qca_check_speeds(struct hci_uart *hu)
 static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type)
 {
 	unsigned int speed, qca_baudrate;
+	struct qca_serdev *qcadev;
 	int ret;
 
 	if (speed_type == QCA_INIT_SPEED) {

@@ -1102,6 +1092,15 @@ static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type)
 		if (!speed)
 			return 0;
 
+		/* Deassert RTS while changing the baudrate of chip and host.
+		 * This will prevent chip from transmitting its response with
+		 * the new baudrate while the host port is still operating at
+		 * the old speed.
+		 */
+		qcadev = serdev_device_get_drvdata(hu->serdev);
+		if (qcadev->btsoc_type == QCA_WCN3990)
+			serdev_device_set_rts(hu->serdev, false);
+
 		qca_baudrate = qca_get_baudrate_value(speed);
 		bt_dev_dbg(hu->hdev, "Set UART speed to %d", speed);
 		ret = qca_set_baudrate(hu->hdev, qca_baudrate);

@@ -1109,6 +1108,9 @@ static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type)
 			return ret;
 
 		host_set_baudrate(hu, speed);
+
+		if (qcadev->btsoc_type == QCA_WCN3990)
+			serdev_device_set_rts(hu->serdev, true);
 	}
 
 	return 0;

Signature · 2 lines

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Balakrishna Godavarthi

author

2019-01-16 11:46 UTC #8 lore raw

PATCH v8 3/3 Bluetooth: hci_qca: Disable IBS state machine and flush Tx buffer

In reply to Balakrishna Godavarthi

During hci down we observed IBS sleep commands are queued in the Tx buffer and hci_uart_write_work is sending data to the chip which is not required as the chip is powered off. This patch will disable IBS and flush the Tx buffer before we turn off the chip.

Signed-off-by Balakrishna Godavarthi <[email protected]>

---
 drivers/bluetooth/hci_qca.c | 8 ++++++++
 1 file changed, 8 insertions(+)

drivers/bluetooth/hci_qca.c +8 -0

index 7e4afcf40da2..7330ba71ada4 100644
@@ -1275,6 +1275,14 @@ static const struct qca_vreg_data qca_soc_data = {
 
 static void qca_power_shutdown(struct hci_uart *hu)
 {
+	struct qca_data *qca = hu->priv;
+
+	/* From this point we go into power off state. But serial port is
+	 * still open, stop queueing the IBS data and flush all the buffered
+	 * data in skb's.
+	 */
+	clear_bit(STATE_IN_BAND_SLEEP_ENABLED, &qca->flags);
+	qca_flush(hu);
 	host_set_baudrate(hu, 2400);
 	qca_send_power_pulse(hu, QCA_WCN3990_POWEROFF_PULSE);
 	qca_power_setup(hu, false);

Signature · 2 lines

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Matthias Kaehlcke

2019-01-16 23:08 UTC #9 lore raw

Re: [PATCH v8 3/3] Bluetooth: hci_qca: Disable IBS state machine and flush Tx buffer

Quoted 19 lines · Balakrishna Godavarthi

During hci down we observed IBS sleep commands are queued in the Tx buffer and hci_uart_write_work is sending data to the chip which is not required as the chip is powered off. This patch will disable IBS and flush the Tx buffer before we turn off the chip.
Signed-off-by Balakrishna Godavarthi <[email protected]>
---
 drivers/bluetooth/hci_qca.c | 8 ++++++++
 1 file changed, 8 insertions(+)
drivers/bluetooth/hci_qca.c +1 -0
index 7e4afcf40da2..7330ba71ada4 100644
@@ -1275,6 +1275,14 @@ static const struct qca_vreg_data qca_soc_data = {
 
 static void qca_power_shutdown(struct hci_uart *hu)
 {
+	struct qca_data *qca = hu->priv;

drivers/bluetooth/hci_qca.c static const struct qca_vreg_data qca_soc_data = { · line 1288

Quoted 10 lines

drivers/bluetooth/hci_qca.c +7 -0

+
+	/* From this point we go into power off state. But serial port is
+	 * still open, stop queueing the IBS data and flush all the buffered
+	 * data in skb's.
+	 */
+	clear_bit(STATE_IN_BAND_SLEEP_ENABLED, &qca->flags);
+	qca_flush(hu);
 	host_set_baudrate(hu, 2400);
 	qca_send_power_pulse(hu, QCA_WCN3990_POWEROFF_PULSE);
 	qca_power_setup(hu, false);

Due to a race-condition there could be an IBS sleep command queued even after clearing the bit and flushing the queue.

In qca_enqueue() we have this:

static int qca_enqueue(struct hci_uart *hu, struct sk_buff *skb)

{
        ...

        /* Don't go to sleep in middle of patch download or
         * Out-Of-Band(GPIOs control) sleep is selected.
         */
        if (!test_bit(STATE_IN_BAND_SLEEP_ENABLED, &qca->flags)) {
                skb_queue_tail(&qca->txq, skb);
                return 0;
        }

        spin_lock_irqsave(&qca->hci_ibs_lock, flags);
}

With process X executing qca_power_shutdown() and process Y running qca_enqueue() this could happen:

[X] test_bit(STATE_IN_BAND_SLEEP_ENABLED) => set
[Y] clear_bit(STATE_IN_BAND_SLEEP_ENABLED)
[Y] qca_flush(hu);
[X] skb_queue_tail(&qca->txq, skb);

The following should fix this race:

drivers/bluetooth/hci_qca.c +7 -2

@@ -770,16 +770,17 @@ static int qca_enqueue(struct hci_uart *hu, struct sk_buff *skb)
 	/* Prepend skb with frame type */
 	memcpy(skb_push(skb, 1), &hci_skb_pkt_type(skb), 1);
 
+	spin_lock_irqsave(&qca->hci_ibs_lock, flags);
+
 	/* Don't go to sleep in middle of patch download or
 	 * Out-Of-Band(GPIOs control) sleep is selected.
 	 */
 	if (!test_bit(STATE_IN_BAND_SLEEP_ENABLED, &qca->flags)) {
 		skb_queue_tail(&qca->txq, skb);
+		spin_unlock_irqrestore(&qca->hci_ibs_lock, flags);
 		return 0;
 	}
 
-	spin_lock_irqsave(&qca->hci_ibs_lock, flags);
-
 	/* Act according to current state */
 	switch (qca->tx_ibs_state) {
 	case HCI_IBS_TX_AWAKE:

@@ -1275,13 +1276,17 @@ static const struct qca_vreg_data qca_soc_data = {
 static void qca_power_shutdown(struct hci_uart *hu)
 {
 	struct qca_data *qca = hu->priv;
+	unsigned long flags;
 
 	/* From this point we go into power off state. But serial port is
 	 * still open, stop queueing the IBS data and flush all the buffered
 	 * data in skb's.
 	 */
+	spin_lock_irqsave(&qca->hci_ibs_lock, flags);
 	clear_bit(STATE_IN_BAND_SLEEP_ENABLED, &qca->flags);
 	qca_flush(hu);
+	spin_unlock_irqrestore(&qca->hci_ibs_lock, flags);
+
 	host_set_baudrate(hu, 2400);
 	qca_send_power_pulse(hu, QCA_WCN3990_POWEROFF_PULSE);
 	qca_power_setup(hu, false);

Cheers

Matthias

Balakrishna Godavarthi

author

2019-01-17 10:27 UTC #10 lore raw

Re: [PATCH v8 3/3] Bluetooth: hci_qca: Disable IBS state machine and flush Tx buffer

Quoted 91 lines · Matthias Kaehlcke

Quoted 29 lines · Balakrishna Godavarthi
During hci down we observed IBS sleep commands are queued in the Tx buffer and hci_uart_write_work is sending data to the chip which is not required as the chip is powered off. This patch will disable IBS and flush the Tx buffer before we turn off the chip.
Signed-off-by Balakrishna Godavarthi <[email protected]>
---
 drivers/bluetooth/hci_qca.c | 8 ++++++++
 1 file changed, 8 insertions(+)
drivers/bluetooth/hci_qca.c +8 -0
index 7e4afcf40da2..7330ba71ada4 100644
@@ -1275,6 +1275,14 @@ static const struct qca_vreg_data qca_soc_data 
 = {
 
 static void qca_power_shutdown(struct hci_uart *hu)
 {
+	struct qca_data *qca = hu->priv;
+
+	/* From this point we go into power off state. But serial port is
+	 * still open, stop queueing the IBS data and flush all the buffered
+	 * data in skb's.
+	 */
+	clear_bit(STATE_IN_BAND_SLEEP_ENABLED, &qca->flags);
+	qca_flush(hu);
 	host_set_baudrate(hu, 2400);
 	qca_send_power_pulse(hu, QCA_WCN3990_POWEROFF_PULSE);
Quoted 1 line
qca_power_setup(hu, false);
Due to a race-condition there could be an IBS sleep command queued even after clearing the bit and flushing the queue.
In qca_enqueue() we have this:
static int qca_enqueue(struct hci_uart *hu, struct sk_buff *skb)
{
        ...

        /* Don't go to sleep in middle of patch download or
         * Out-Of-Band(GPIOs control) sleep is selected.
         */
        if (!test_bit(STATE_IN_BAND_SLEEP_ENABLED, &qca->flags)) {
                skb_queue_tail(&qca->txq, skb);
                return 0;
        }

        spin_lock_irqsave(&qca->hci_ibs_lock, flags);
}
With process X executing qca_power_shutdown() and process Y running qca_enqueue() this could happen:
[X] test_bit(STATE_IN_BAND_SLEEP_ENABLED) => set
[Y] clear_bit(STATE_IN_BAND_SLEEP_ENABLED)
[Y] qca_flush(hu);
[X] skb_queue_tail(&qca->txq, skb);
The following should fix this race:
drivers/bluetooth/hci_qca.c +3 -2
@@ -770,16 +770,17 @@ static int qca_enqueue(struct hci_uart *hu,
 struct sk_buff *skb)
 	/* Prepend skb with frame type */
 	memcpy(skb_push(skb, 1), &hci_skb_pkt_type(skb), 1);
 
+	spin_lock_irqsave(&qca->hci_ibs_lock, flags);
+
 	/* Don't go to sleep in middle of patch download or
 	 * Out-Of-Band(GPIOs control) sleep is selected.
 	 */
 	if (!test_bit(STATE_IN_BAND_SLEEP_ENABLED, &qca->flags)) {
 		skb_queue_tail(&qca->txq, skb);
+		spin_unlock_irqrestore(&qca->hci_ibs_lock, flags);
 		return 0;
 	}
 
-	spin_lock_irqsave(&qca->hci_ibs_lock, flags);
-
 	/* Act according to current state */
 	switch (qca->tx_ibs_state) {
drivers/bluetooth/hci_qca.c +1 -0
 	case HCI_IBS_TX_AWAKE:
@@ -1275,13 +1276,17 @@ static const struct qca_vreg_data qca_soc_data 
 = {
 static void qca_power_shutdown(struct hci_uart *hu)
 {
 	struct qca_data *qca = hu->priv;
+	unsigned long flags;

drivers/bluetooth/hci_qca.c static const struct qca_vreg_data qca_soc_data · line 1290

Quoted 10 lines

drivers/bluetooth/hci_qca.c +3 -0

 
 	/* From this point we go into power off state. But serial port is
 	 * still open, stop queueing the IBS data and flush all the buffered
 	 * data in skb's.
 	 */
+	spin_lock_irqsave(&qca->hci_ibs_lock, flags);
 	clear_bit(STATE_IN_BAND_SLEEP_ENABLED, &qca->flags);
 	qca_flush(hu);
+	spin_unlock_irqrestore(&qca->hci_ibs_lock, flags);
+

[Bala]: Thanks for catch this. yes you are rite, we will have an byte queued in the skb.
will update with the lock.

Quoted 7 lines

drivers/bluetooth/hci_qca.c +0 -0
 	host_set_baudrate(hu, 2400);
 	qca_send_power_pulse(hu, QCA_WCN3990_POWEROFF_PULSE);
qca_power_setup(hu, false);
Cheers
Matthias

Signature · 2 lines

Regards
Balakrishna.