Re: [PATCH v1 1/4] Bluetooth: hci_qca: use wait_until_sent() for power pulses
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
> >> ---
> >> 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, , 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-jo...@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
Re: [PATCH v1 1/4] Bluetooth: hci_qca: use wait_until_sent() for power pulses
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
> >> ---
> >> 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, , 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-jo...@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
Re: [PATCH v1 1/4] Bluetooth: hci_qca: use wait_until_sent() for power pulses
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
---
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, , 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-jo...@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(>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, , sizeof(cmd));
+ serdev_device_write(serdev, , 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
--
Regards
Balakrishna.
Re: [PATCH v1 1/4] Bluetooth: hci_qca: use wait_until_sent() for power pulses
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
---
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, , 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-jo...@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(>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, , sizeof(cmd));
+ serdev_device_write(serdev, , 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
--
Regards
Balakrishna.
Re: [PATCH v1 1/4] Bluetooth: hci_qca: use wait_until_sent() for power pulses
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
> ---
> 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, , 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-jo...@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(>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, , sizeof(cmd));
> + serdev_device_write(serdev, , 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
Re: [PATCH v1 1/4] Bluetooth: hci_qca: use wait_until_sent() for power pulses
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
> ---
> 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, , 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-jo...@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(>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, , sizeof(cmd));
> + serdev_device_write(serdev, , 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
Re: [PATCH v1 1/4] Bluetooth: hci_qca: use wait_until_sent() for power pulses
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
---
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, , 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(>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, , sizeof(cmd));
+ serdev_device_write(serdev, , 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.
Re: [PATCH v1 1/4] Bluetooth: hci_qca: use wait_until_sent() for power pulses
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
---
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, , 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(>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, , sizeof(cmd));
+ serdev_device_write(serdev, , 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.
Re: [PATCH v1 1/4] Bluetooth: hci_qca: use wait_until_sent() for power pulses
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
> ---
> 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, , 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(>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, , sizeof(cmd));
> + serdev_device_write(serdev, , 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
Re: [PATCH v1 1/4] Bluetooth: hci_qca: use wait_until_sent() for power pulses
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
> ---
> 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, , 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(>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, , sizeof(cmd));
> + serdev_device_write(serdev, , 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
[PATCH v1 1/4] 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
---
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, , 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(>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, , sizeof(cmd));
+ serdev_device_write(serdev, , sizeof(cmd), 0);
+ serdev_device_wait_until_sent(serdev, 0);
hci_uart_set_flow_control(hu, false);
qca_power_setup(hu, false);
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v1 1/4] 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
---
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, , 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(>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, , sizeof(cmd));
+ serdev_device_write(serdev, , sizeof(cmd), 0);
+ serdev_device_wait_until_sent(serdev, 0);
hci_uart_set_flow_control(hu, false);
qca_power_setup(hu, false);
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
