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

2018-12-27 Thread Balakrishna Godavarthi

HI Matthias,

On 2018-12-28 01:48, Matthias Kaehlcke wrote:

On Thu, Dec 27, 2018 at 01:01:31PM +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 
---
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 | 38 
++---

 1 file changed, 14 insertions(+), 24 deletions(-)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index f036c8f98ea3..507a2355c758 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1013,11 +1013,9 @@ 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;

/* These power pulses are single byte command which are sent
 * at required baudrate to wcn3990. On wcn3990, we have an external
@@ -1029,19 +1027,17 @@ 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;
-
+   serdev_device_write_flush(hu->serdev);
+   bt_dev_dbg(hu->hdev, "sending power pulse %02x to SoC", cmd);


nit: why clutter the code flow by putting the log statement in the
middle of code that is actually doing something with the serial
interface?

In case you respin anyway I suggest to structure it like this:

  bt_dev_dbg(hu->hdev, "sending power pulse %02x to SoC", cmd);

  hci_uart_set_flow_control(hu, true);
  serdev_device_write_flush(hu->serdev);
  ret = serdev_device_write_buf(hu->serdev, , sizeof(cmd));



hci_uart_set_flow_control(hu, true);
+   ret = serdev_device_write_buf(hu->serdev, , sizeof(cmd));
+   if (ret < 0) {
+   bt_dev_err(hu->hdev, "failed to send power pulse %02x to SoC",


nit: especially on 'embedded' devices 'SoC' is typically associated
with the CPU running Linux, you might want to change it to
'controller'.



[Bala]: will update.


+  cmd);
+   return ret;
+   }

-   skb_put_u8(skb, cmd);
-   hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
-
-   skb_queue_tail(>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);


I said earlier the delay here should be enough to ensure that the byte
gets transferred from a hardware buffer/FIFO to the controller,
however that didn't take into account that the power pulses are sent
with a baudrate of 2400. That translates to ~240 bytes/s, hence a
delay of 5 ms is needed to be on the safe side.



[Bala]: sure will update the delay of 5 ms.


In case you change the delay please also update the comment to make
clear this is not only time for the BT controller to settle, but also
to guarantee that the command was actually sent to the controller.



[Bala]: will update the comment.


So far it seems no problems have been observed, though this could be
thanks to the 100 ms delay in qca_wcn3990_init().

Cheers

Matthias


--
Regards
Balakrishna.


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

2018-12-27 Thread Matthias Kaehlcke
On Thu, Dec 27, 2018 at 01:01:31PM +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 
> ---
> 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 | 38 ++---
>  1 file changed, 14 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index f036c8f98ea3..507a2355c758 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -1013,11 +1013,9 @@ 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;
>  
>   /* These power pulses are single byte command which are sent
>* at required baudrate to wcn3990. On wcn3990, we have an external
> @@ -1029,19 +1027,17 @@ 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;
> -
> + serdev_device_write_flush(hu->serdev);
> + bt_dev_dbg(hu->hdev, "sending power pulse %02x to SoC", cmd);

nit: why clutter the code flow by putting the log statement in the
middle of code that is actually doing something with the serial
interface?

In case you respin anyway I suggest to structure it like this:

  bt_dev_dbg(hu->hdev, "sending power pulse %02x to SoC", cmd);

  hci_uart_set_flow_control(hu, true);
  serdev_device_write_flush(hu->serdev);
  ret = serdev_device_write_buf(hu->serdev, , sizeof(cmd));


>   hci_uart_set_flow_control(hu, true);
> + ret = serdev_device_write_buf(hu->serdev, , sizeof(cmd));
> + if (ret < 0) {
> + bt_dev_err(hu->hdev, "failed to send power pulse %02x to SoC",

nit: especially on 'embedded' devices 'SoC' is typically associated
with the CPU running Linux, you might want to change it to
'controller'.

> +cmd);
> + return ret;
> + }
>  
> - skb_put_u8(skb, cmd);
> - hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
> -
> - skb_queue_tail(>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);

I said earlier the delay here should be enough to ensure that the byte
gets transferred from a hardware buffer/FIFO to the controller,
however that didn't take into account that the power pulses are sent
with a baudrate of 2400. That translates to ~240 bytes/s, hence a
delay of 5 ms is needed to be on the safe side.

In case you change the delay please also update the comment to make
clear this is not only time for the BT controller to settle, but also
to guarantee that the command was actually sent to the controller.

So far it seems no problems have been observed, though this could be
thanks to the 100 ms delay in qca_wcn3990_init().

Cheers

Matthias


[PATCH v6 1/6] Bluetooth: hci_qca: use wait_until_sent() for power pulses

2018-12-26 Thread 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 
---
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 | 38 ++---
 1 file changed, 14 insertions(+), 24 deletions(-)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index f036c8f98ea3..507a2355c758 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1013,11 +1013,9 @@ 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;
 
/* These power pulses are single byte command which are sent
 * at required baudrate to wcn3990. On wcn3990, we have an external
@@ -1029,19 +1027,17 @@ 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;
-
+   serdev_device_write_flush(hu->serdev);
+   bt_dev_dbg(hu->hdev, "sending power pulse %02x to SoC", cmd);
hci_uart_set_flow_control(hu, true);
+   ret = serdev_device_write_buf(hu->serdev, , sizeof(cmd));
+   if (ret < 0) {
+   bt_dev_err(hu->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(>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);
@@ -1116,7 +1112,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 +1134,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 +1269,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, , sizeof(cmd));
-   hci_uart_set_flow_control(hu, false);
+   qca_send_power_pulse(hu, QCA_WCN3990_POWEROFF_PULSE);
qca_power_setup(hu, false);
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project