Re: [PATCH v5 1/5] Bluetooth: hci_qca: use wait_until_sent() for power pulses
Hi Matthias,
On 2019-01-12 05:08, Matthias Kaehlcke wrote:
On Fri, Jan 11, 2019 at 08:02:00PM +0530, Balakrishna Godavarthi wrote:
On 2019-01-11 06:25, Matthias Kaehlcke wrote:
> On Thu, Jan 10, 2019 at 08:18:37PM +0530, Balakrishna Godavarthi wrote:
> > Hi Johan,
> >
> > On 2019-01-09 20:08, Johan Hovold wrote:
> > > On Fri, Dec 21, 2018 at 05:59:47PM -0800, Matthias Kaehlcke wrote:
> > > > On Thu, Dec 20, 2018 at 08:16:35PM +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 | 38
++---
> > > > > 1 file changed, 14 insertions(+), 24 deletions(-)
> > > > >
> > > > > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> > > > > index f036c8f98ea3..5a07c2370289 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,16 @@ 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;
> > > > > -
> > > > > + 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);
> > >
> > > Again, do you really want to wait indefinitely here?
> > >
> > [Bala]: these commands are mandatory to turn ON or OFF the chip.
> > so blocking to the max time is required.
> > these commands are sent during the BT chip ON & OFF.
> > in the latest series, i have flushed the uart before sending
> > this
> > commands
> > so the uart FIFO(as just opened the port before calling this
> > function) or the circular
> > buffer will be empty and also i am disabling the flow
> > control too.
> >https://patchwork.kernel.org/patch/10744435/
>
> The commands may be mandatory for switching the chip on or off, but
> what is better if there is a problem with sending them (e.g. a buggy
> UART driver):
>
> 1. wait a reasonable time, report an error
> 2. wait forever
>
> ?
>
> If the single byte command couldn't be sent after a few milliseconds,
> it likely never will, waiting forever doesn't fix that. An error
> report at least provides some information about the problem and the
> driver is in a not-hanging state.
>
> Cheers
>
> Matthias
[Bala]: will update this with a bound TIMEOUT value. But
wait_until_sent()
is void return
type how could we know that the data is sent out on the lines.
Good point, I didn't check and expected it to return an error. If you
feel really motivated and have maintainer support you could possibly
change the API, however it seems this would be a somewhat larger
change.
I guess the next best thing to do is to proceed as if all data was
sent and if there was a problem it will likely manifest through
another error (especially for the ON pulse), which still seems better
than a hanging driver.
Cheers
Matthias
[Bala]: sure, will add the timeout to one second and if data didn't sent
to the lines anyways
we will get an
Re: [PATCH v5 1/5] Bluetooth: hci_qca: use wait_until_sent() for power pulses
On Fri, Jan 11, 2019 at 08:02:00PM +0530, Balakrishna Godavarthi wrote:
> On 2019-01-11 06:25, Matthias Kaehlcke wrote:
> > On Thu, Jan 10, 2019 at 08:18:37PM +0530, Balakrishna Godavarthi wrote:
> > > Hi Johan,
> > >
> > > On 2019-01-09 20:08, Johan Hovold wrote:
> > > > On Fri, Dec 21, 2018 at 05:59:47PM -0800, Matthias Kaehlcke wrote:
> > > > > On Thu, Dec 20, 2018 at 08:16:35PM +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 | 38
> > > > > > ++---
> > > > > > 1 file changed, 14 insertions(+), 24 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/bluetooth/hci_qca.c
> > > > > > b/drivers/bluetooth/hci_qca.c
> > > > > > index f036c8f98ea3..5a07c2370289 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,16 @@ 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;
> > > > > > -
> > > > > > + 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);
> > > >
> > > > Again, do you really want to wait indefinitely here?
> > > >
> > > [Bala]: these commands are mandatory to turn ON or OFF the chip.
> > > so blocking to the max time is required.
> > > these commands are sent during the BT chip ON & OFF.
> > > in the latest series, i have flushed the uart before sending
> > > this
> > > commands
> > > so the uart FIFO(as just opened the port before calling this
> > > function) or the circular
> > > buffer will be empty and also i am disabling the flow
> > > control too.
> > >https://patchwork.kernel.org/patch/10744435/
> >
> > The commands may be mandatory for switching the chip on or off, but
> > what is better if there is a problem with sending them (e.g. a buggy
> > UART driver):
> >
> > 1. wait a reasonable time, report an error
> > 2. wait forever
> >
> > ?
> >
> > If the single byte command couldn't be sent after a few milliseconds,
> > it likely never will, waiting forever doesn't fix that. An error
> > report at least provides some information about the problem and the
> > driver is in a not-hanging state.
> >
> > Cheers
> >
> > Matthias
>
> [Bala]: will update this with a bound TIMEOUT value. But wait_until_sent()
> is void return
> type how could we know that the data is sent out on the lines.
Good point, I didn't check and expected it to return an error. If you
feel really motivated and have maintainer support you could possibly
change the API, however it seems this would be a somewhat larger
change.
I guess the next best thing to do is to proceed as if all data was
sent and if there was a problem it will likely manifest through
another error (especially for the ON pulse), which still seems better
than a hanging driver.
Re: [PATCH v5 1/5] Bluetooth: hci_qca: use wait_until_sent() for power pulses
On 2019-01-11 06:25, Matthias Kaehlcke wrote:
On Thu, Jan 10, 2019 at 08:18:37PM +0530, Balakrishna Godavarthi wrote:
Hi Johan,
On 2019-01-09 20:08, Johan Hovold wrote:
> On Fri, Dec 21, 2018 at 05:59:47PM -0800, Matthias Kaehlcke wrote:
> > On Thu, Dec 20, 2018 at 08:16:35PM +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 | 38 ++---
> > > 1 file changed, 14 insertions(+), 24 deletions(-)
> > >
> > > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> > > index f036c8f98ea3..5a07c2370289 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,16 @@ 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;
> > > -
> > > +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);
>
> Again, do you really want to wait indefinitely here?
>
[Bala]: these commands are mandatory to turn ON or OFF the chip.
so blocking to the max time is required.
these commands are sent during the BT chip ON & OFF.
in the latest series, i have flushed the uart before sending
this
commands
so the uart FIFO(as just opened the port before calling this
function) or the circular
buffer will be empty and also i am disabling the flow control
too.
https://patchwork.kernel.org/patch/10744435/
The commands may be mandatory for switching the chip on or off, but
what is better if there is a problem with sending them (e.g. a buggy
UART driver):
1. wait a reasonable time, report an error
2. wait forever
?
If the single byte command couldn't be sent after a few milliseconds,
it likely never will, waiting forever doesn't fix that. An error
report at least provides some information about the problem and the
driver is in a not-hanging state.
Cheers
Matthias
[Bala]: will update this with a bound TIMEOUT value. But
wait_until_sent() is void return
type how could we know that the data is sent out on the lines.
--
Regards
Balakrishna.
Re: [PATCH v5 1/5] Bluetooth: hci_qca: use wait_until_sent() for power pulses
On Thu, Jan 10, 2019 at 08:18:37PM +0530, Balakrishna Godavarthi wrote:
> Hi Johan,
>
> On 2019-01-09 20:08, Johan Hovold wrote:
> > On Fri, Dec 21, 2018 at 05:59:47PM -0800, Matthias Kaehlcke wrote:
> > > On Thu, Dec 20, 2018 at 08:16:35PM +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 | 38 ++---
> > > > 1 file changed, 14 insertions(+), 24 deletions(-)
> > > >
> > > > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> > > > index f036c8f98ea3..5a07c2370289 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,16 @@ 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;
> > > > -
> > > > + 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);
> >
> > Again, do you really want to wait indefinitely here?
> >
> [Bala]: these commands are mandatory to turn ON or OFF the chip.
> so blocking to the max time is required.
> these commands are sent during the BT chip ON & OFF.
> in the latest series, i have flushed the uart before sending this
> commands
> so the uart FIFO(as just opened the port before calling this
> function) or the circular
> buffer will be empty and also i am disabling the flow control too.
>https://patchwork.kernel.org/patch/10744435/
The commands may be mandatory for switching the chip on or off, but
what is better if there is a problem with sending them (e.g. a buggy
UART driver):
1. wait a reasonable time, report an error
2. wait forever
?
If the single byte command couldn't be sent after a few milliseconds,
it likely never will, waiting forever doesn't fix that. An error
report at least provides some information about the problem and the
driver is in a not-hanging state.
Cheers
Matthias
Re: [PATCH v5 1/5] Bluetooth: hci_qca: use wait_until_sent() for power pulses
Hi Johan,
On 2019-01-09 20:08, Johan Hovold wrote:
On Fri, Dec 21, 2018 at 05:59:47PM -0800, Matthias Kaehlcke wrote:
On Thu, Dec 20, 2018 at 08:16:35PM +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 | 38 ++---
> 1 file changed, 14 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index f036c8f98ea3..5a07c2370289 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,16 @@ 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;
> -
> + 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);
Again, do you really want to wait indefinitely here?
[Bala]: these commands are mandatory to turn ON or OFF the chip.
so blocking to the max time is required.
these commands are sent during the BT chip ON & OFF.
in the latest series, i have flushed the uart before sending
this commands
so the uart FIFO(as just opened the port before calling this
function) or the circular
buffer will be empty and also i am disabling the flow control
too.
https://patchwork.kernel.org/patch/10744435/
serdev_device_wait_until_sent() might only guarantee that the UART
circular buffer is empty (see
https://elixir.bootlin.com/linux/v4.19/source/drivers/tty/tty_ioctl.c#L225),
not that the data has actually sent (e.g. it might be sitting in
the UART FIFO).
For serial core, uart_wait_until_sent() makes sure also the UART FIFO
is
empty, although it may time out when using flow control (as then the
FIFO may never empty, and flow control appears to be enabled here).
Johan
[Bala]: Pls refer the latest patch series
https://patchwork.kernel.org/patch/10744435/
where i am flushing the circular buffer before calling the
qca_send_power_pulse().
this how the flow
1. open serial port (gurantess that UART FIFO is empty)
2. flush the circular buffer
3. disable the flow control.
4. send the command byte.
5. wait for the circular buffer is empty.
the above is one time process,
--
Regards
Balakrishna.
Re: [PATCH v5 1/5] Bluetooth: hci_qca: use wait_until_sent() for power pulses
On Fri, Dec 21, 2018 at 05:59:47PM -0800, Matthias Kaehlcke wrote:
> On Thu, Dec 20, 2018 at 08:16:35PM +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 | 38 ++---
> > 1 file changed, 14 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> > index f036c8f98ea3..5a07c2370289 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,16 @@ 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;
> > -
> > + 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);
Again, do you really want to wait indefinitely here?
> serdev_device_wait_until_sent() might only guarantee that the UART
> circular buffer is empty (see
> https://elixir.bootlin.com/linux/v4.19/source/drivers/tty/tty_ioctl.c#L225),
> not that the data has actually sent (e.g. it might be sitting in
> the UART FIFO).
For serial core, uart_wait_until_sent() makes sure also the UART FIFO is
empty, although it may time out when using flow control (as then the
FIFO may never empty, and flow control appears to be enabled here).
Johan
Re: [PATCH v5 1/5] Bluetooth: hci_qca: use wait_until_sent() for power pulses
Hi Matthias,
On 2018-12-27 03:51, Matthias Kaehlcke wrote:
On Wed, Dec 26, 2018 at 12:01:51PM +0530, Balakrishna Godavarthi wrote:
Hi Matthias,
On 2018-12-22 07:29, Matthias Kaehlcke wrote:
> On Thu, Dec 20, 2018 at 08:16:35PM +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 | 38
> > ++---
> > 1 file changed, 14 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> > index f036c8f98ea3..5a07c2370289 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,16 @@ 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;
> > -
> > + 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);
>
> serdev_device_wait_until_sent() might only guarantee that the UART
> circular buffer is empty (see
> https://elixir.bootlin.com/linux/v4.19/source/drivers/tty/tty_ioctl.c#L225),
> not that the data has actually sent (e.g. it might be sitting in
> the UART FIFO). However with this:
>
> > /* Wait for 100 uS for SoC to settle down */
> > usleep_range(100, 200);
>
> we should probably be fine, unless there's tons of data in the
> FIFO.
>
> You currently call serdev_device_write_flush() in
> qca_power_shutdown(), I wonder if it would make sense to call it in
> qca_send_power_pulse(), regardless of whether it's an on or off
[Bala]: during sending the ON pulse we will not have any data in the
UART circular buffer as this is the first command to send and
we are
sending it as soon as we open the port.
so i taught why should be flush the circular as it is already
empty.
> pulse. In any case we don't care if the chip receives any 'pending'
> data when we switch it on or off, right?
>
[Bala]: during on we freshly open port and i see that flush() called
while
port opening.
https://elixir.bootlin.com/linux/latest/source/drivers/tty/serial/serial_core.c#L207
I would argue that the serdev_device_write_flush() call in
qca_power_shutdown() is related with/needed for sending the power off
pulse, hence it should be part of qca_send_power_pulse(), unless it
adds a significant overhead and we really want to call it only in the
shutdown case.
Flushing the buffer should be fairly lightweight and power pulses are
only sent when the device is switched on or off, so the overhead
should be negligible. You *could* restrict the flush to the power off
pulse, assuming that the driver always re-opens the port in
qca_wcn3990_init() (tests with this patch set suggest this might not
be needed) and that serdev_device_open() flushes the buffer (which
seems a sane assumption). Yet given the minimal overhead I'd suggest
to not make assumptions about what happened previously in other code
and avoid the clutter of a condition that doesn't add much value.
[Bala]: will call the flush() while sending the power pulses
irrespective of the pulse type.
Cheers
Matthias
--
Regards
Balakrishna.
Re: [PATCH v5 1/5] Bluetooth: hci_qca: use wait_until_sent() for power pulses
On Wed, Dec 26, 2018 at 12:01:51PM +0530, Balakrishna Godavarthi wrote:
> Hi Matthias,
>
> On 2018-12-22 07:29, Matthias Kaehlcke wrote:
> > On Thu, Dec 20, 2018 at 08:16:35PM +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 | 38
> > > ++---
> > > 1 file changed, 14 insertions(+), 24 deletions(-)
> > >
> > > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> > > index f036c8f98ea3..5a07c2370289 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,16 @@ 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;
> > > -
> > > + 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);
> >
> > serdev_device_wait_until_sent() might only guarantee that the UART
> > circular buffer is empty (see
> > https://elixir.bootlin.com/linux/v4.19/source/drivers/tty/tty_ioctl.c#L225),
> > not that the data has actually sent (e.g. it might be sitting in
> > the UART FIFO). However with this:
> >
> > > /* Wait for 100 uS for SoC to settle down */
> > > usleep_range(100, 200);
> >
> > we should probably be fine, unless there's tons of data in the
> > FIFO.
> >
> > You currently call serdev_device_write_flush() in
> > qca_power_shutdown(), I wonder if it would make sense to call it in
> > qca_send_power_pulse(), regardless of whether it's an on or off
>
> [Bala]: during sending the ON pulse we will not have any data in the
> UART circular buffer as this is the first command to send and we are
> sending it as soon as we open the port.
> so i taught why should be flush the circular as it is already empty.
> > pulse. In any case we don't care if the chip receives any 'pending'
> > data when we switch it on or off, right?
> >
>
> [Bala]: during on we freshly open port and i see that flush() called while
> port opening.
>
> https://elixir.bootlin.com/linux/latest/source/drivers/tty/serial/serial_core.c#L207
I would argue that the serdev_device_write_flush() call in
qca_power_shutdown() is related with/needed for sending the power off
pulse, hence it should be part of qca_send_power_pulse(), unless it
adds a significant overhead and we really want to call it only in the
shutdown case.
Flushing the buffer should be fairly lightweight and power pulses are
only sent when the device is switched on or off, so the overhead
should be negligible. You *could* restrict the flush to the power off
pulse, assuming that the driver always re-opens the port in
qca_wcn3990_init() (tests with this patch set suggest this might not
be needed) and that serdev_device_open() flushes the buffer (which
seems a sane assumption). Yet given the minimal overhead I'd suggest
to not make assumptions about what happened previously in other code
and avoid the clutter of a condition that doesn't add much value.
Cheers
Matthias
Re: [PATCH v5 1/5] Bluetooth: hci_qca: use wait_until_sent() for power pulses
Hi Matthias,
On 2018-12-22 07:29, Matthias Kaehlcke wrote:
On Thu, Dec 20, 2018 at 08:16:35PM +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 | 38
++---
1 file changed, 14 insertions(+), 24 deletions(-)
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index f036c8f98ea3..5a07c2370289 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,16 @@ 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;
-
+ 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);
serdev_device_wait_until_sent() might only guarantee that the UART
circular buffer is empty (see
https://elixir.bootlin.com/linux/v4.19/source/drivers/tty/tty_ioctl.c#L225),
not that the data has actually sent (e.g. it might be sitting in
the UART FIFO). However with this:
/* Wait for 100 uS for SoC to settle down */
usleep_range(100, 200);
we should probably be fine, unless there's tons of data in the
FIFO.
You currently call serdev_device_write_flush() in
qca_power_shutdown(), I wonder if it would make sense to call it in
qca_send_power_pulse(), regardless of whether it's an on or off
[Bala]: during sending the ON pulse we will not have any data in the
UART circular buffer as this is the first command to send and we
are sending it as soon as we open the port.
so i taught why should be flush the circular as it is already
empty.
pulse. In any case we don't care if the chip receives any 'pending'
data when we switch it on or off, right?
[Bala]: during on we freshly open port and i see that flush() called
while port opening.
https://elixir.bootlin.com/linux/latest/source/drivers/tty/serial/serial_core.c#L207
Cheers
Matthias
--
Regards
Balakrishna.
Re: [PATCH v5 1/5] Bluetooth: hci_qca: use wait_until_sent() for power pulses
On Thu, Dec 20, 2018 at 08:16:35PM +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 | 38 ++---
> 1 file changed, 14 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index f036c8f98ea3..5a07c2370289 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,16 @@ 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;
> -
> + 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);
serdev_device_wait_until_sent() might only guarantee that the UART
circular buffer is empty (see
https://elixir.bootlin.com/linux/v4.19/source/drivers/tty/tty_ioctl.c#L225),
not that the data has actually sent (e.g. it might be sitting in
the UART FIFO). However with this:
> /* Wait for 100 uS for SoC to settle down */
> usleep_range(100, 200);
we should probably be fine, unless there's tons of data in the
FIFO.
You currently call serdev_device_write_flush() in
qca_power_shutdown(), I wonder if it would make sense to call it in
qca_send_power_pulse(), regardless of whether it's an on or off
pulse. In any case we don't care if the chip receives any 'pending'
data when we switch it on or off, right?
Cheers
Matthias
[PATCH v5 1/5] 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 | 38 ++---
1 file changed, 14 insertions(+), 24 deletions(-)
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index f036c8f98ea3..5a07c2370289 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,16 @@ 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;
-
+ 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 +,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 +1133,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 +1268,9 @@ 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;
-
+ serdev_device_write_flush(hu->serdev);
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
