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.
