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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Matthias,

On 2018-11-14 05:47, Matthias Kaehlcke wrote:
On Tue, Nov 06, 2018 at 05:35:25PM +0530, Balakrishna Godavarthi wrote:
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 <bgodavar@xxxxxxxxxxxxxx>
---
 drivers/bluetooth/hci_qca.c | 22 +++++++++-------------
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index f72ded4ec9ae..051f081d1835 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1016,8 +1016,7 @@ static inline void host_set_baudrate(struct hci_uart *hu, unsigned int speed)
 static int qca_send_power_pulse(struct hci_dev *hdev, u8 cmd)
 {
 	struct hci_uart *hu = hci_get_drvdata(hdev);
-	struct qca_data *qca = hu->priv;
-	struct sk_buff *skb;
+	int ret;

 	/* These power pulses are single byte command which are sent
 	 * at required baudrate to wcn3990. On wcn3990, we have an external
@@ -1030,18 +1029,14 @@ static int qca_send_power_pulse(struct hci_dev *hdev, u8 cmd)
 	 * 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;
-
 	hci_uart_set_flow_control(hu, true);
+	ret = serdev_device_write(hu->serdev, &cmd, sizeof(cmd), 0);
+	if (ret < 0) {
+		bt_dev_err(hdev, "failed to send power pulse %02x to SoC", 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);
+	serdev_device_wait_until_sent(hu->serdev, 0);

 	/* Wait for 100 uS for SoC to settle down */
 	usleep_range(100, 200);

Is the delay still needed now that we wait for the pulse to be sent? I
didn't observe any problems without it in a few dozens of iterations.

[Bala]: chip require some time to boot up
        so this delay will helps us to be in sync with the chip. for now
we will go with this delay, if really required we can change 100us to some where
        around 10us.

@@ -1283,7 +1278,8 @@ static void qca_power_shutdown(struct hci_uart *hu)

 	host_set_baudrate(hu, 2400);
 	hci_uart_set_flow_control(hu, true);
-	serdev_device_write_buf(serdev, &cmd, sizeof(cmd));
+	serdev_device_write(serdev, &cmd, sizeof(cmd), 0);
+	serdev_device_wait_until_sent(serdev, 0);
 	hci_uart_set_flow_control(hu, false);

You could call qca_send_power_pulse(hdev, QCA_WCN3990_POWEROFF_PULSE)
instead, as an earlier patch set did before skbs were used to send the
power pulse.


[Bala]: will update.

You can also consider to set the baudrate in qca_send_power_pulse()
depending on the power pulse. On the plus side this would reduce a bit
of clutter in the callers of qca_send_power_pulse(), on the negative
side it would be harder to follow when baudrate changes occur (not
sure this is a problem). Up to you, just an idea.

[Bala]: moving bd change request to power_pulse has both plus & minus side. but my opinion is let us we leave qca_send_power_pulse() to be generic might be feature chip will use the same function with an different bd.

Thanks

Matthias

--
Regards
Balakrishna.



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux