| Message ID | 20181106120528.30342-2-bgodavar@codeaurora.org (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | Andy Gross |
| Headers | show |
| Series | [v1,1/4] Bluetooth: hci_qca: use wait_until_sent() for power pulses | expand |
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@codeaurora.org> > --- > 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. > @@ -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. 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. Thanks Matthias
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@codeaurora.org> >> --- >> 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
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@codeaurora.org> > --- > 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); Don't you want a non-zero timeout here? Otherwise you might as well call serdev_device_write() directly. Also have you made sure that serdev_device_write_wakeup() is called in the drivers write-wakeup callback as serdev_device_write() requires? See this series in case what you really wanted was to wait indefinitely (you can use MAX_SCHEDULE_TIMEOUT): https://lkml.kernel.org/r/<20181114150904.19653-1-johan@kernel.org> > + 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); > @@ -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); Same here. > + serdev_device_wait_until_sent(serdev, 0); > hci_uart_set_flow_control(hu, false); > qca_power_setup(hu, false); > } Johan
Hi Johan, On 2018-11-14 20:57, Johan Hovold 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@codeaurora.org> >> --- >> 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); > > Don't you want a non-zero timeout here? Otherwise you might as well > call > serdev_device_write() directly. > [Bala]: we need an in definite timeout for these commands. will use HCI_UART_TX_WAKEUP. > Also have you made sure that serdev_device_write_wakeup() is called in > the drivers write-wakeup callback as serdev_device_write() requires? > > See this series in case what you really wanted was to wait indefinitely > (you can use MAX_SCHEDULE_TIMEOUT): > > https://lkml.kernel.org/r/<20181114150904.19653-1-johan@kernel.org> > [Bala]: thanks for pointers. from https://lore.kernel.org/patchwork/patch/1012358/ it was clear to me that i need call below functions in order to wait until full data is sent. serdev_device_write_wakeup() serdev_device_write() serdev_device_wait_until_sent() correct me whether my understanding is correct. >> + 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); >> @@ -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); > > Same here. > >> + serdev_device_wait_until_sent(serdev, 0); >> hci_uart_set_flow_control(hu, false); >> qca_power_setup(hu, false); >> } > > Johan
On Thu, Nov 15, 2018 at 08:04:29PM +0530, Balakrishna Godavarthi wrote: > Hi Johan, > > On 2018-11-14 20:57, Johan Hovold 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@codeaurora.org> > >> --- > >> 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); > > > > Don't you want a non-zero timeout here? Otherwise you might as well > > call serdev_device_write() directly. > > [Bala]: we need an in definite timeout for these commands. will use > HCI_UART_TX_WAKEUP. > > > Also have you made sure that serdev_device_write_wakeup() is called in > > the drivers write-wakeup callback as serdev_device_write() requires? > > > > See this series in case what you really wanted was to wait indefinitely > > (you can use MAX_SCHEDULE_TIMEOUT): > > > > https://lkml.kernel.org/r/<20181114150904.19653-1-johan@kernel.org> > > [Bala]: thanks for pointers. from > https://lore.kernel.org/patchwork/patch/1012358/ > it was clear to me that i need call below functions in order to > wait until full data is sent. > > serdev_device_write_wakeup() > serdev_device_write() > serdev_device_wait_until_sent() > > correct me whether my understanding is correct. No, serdev_device_write_wakeup() needs to be called from the serdev driver's write_wakeup() callback (as defined in struct struct serdev_device_ops). Either use serdev_device_write_wakeup() as the callback, or call it from your driver's custom write_wakeup() callback. Hmm, I see now that the callbacks are set in hci_uart_register_device() to hci_serdev_client_ops, which is shared by all serdev BT drivers. You may be able to just add the call to the callback defined there so that all Bluetooth drivers can use serdev_device_write(). Johan
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); @@ -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); qca_power_setup(hu, false); }
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@codeaurora.org> --- drivers/bluetooth/hci_qca.c | 22 +++++++++------------- 1 file changed, 9 insertions(+), 13 deletions(-)