The below issues are found in the recent testing. 1. Observed device is not going into off state or not responding. As wcn3990 require a power pulses to turn on the irrespctive of igniting regulators, it was observed that power on or power off pulses are not in sync with respective to chip. The below patch will help us to wait until byte is pushed on to wires. * Bluetooth: hci_qca: use wait_until_sent() for power pulses 2. Observed Chip responding when we are in sleep. This is due to turn on flow control during change baudrate request. The below patch will only pull the RTS line high instead of turning off the flow. * Bluetooth: hci_qca: Pull RTS line high for baudrate change command. 3. Frame reassembly errors splashing on console. wcn3990 requires will use multiple baudrates during booting stage. i.e. 2400 bps while sending power off pulse 115200 bps while sending power on pulse port close port open set baudrate to 115200 request the chip version. during above process, we are seeing some stray bytes coming up on the UART Rx FIFO it could be due to frequent baudrate change. This patch will stop the frame reassembly errors. * Bluetooth: hci_qca: Fix frame reassembly errors for wcn3990 Changes in v2: * Removed Bluetooth: hci_qca: clear HCI_QUIRK_RESET_ON_CLOSE flag patch will be sending as separate series. Balakrishna Godavarthi (3): Bluetooth: hci_qca: use wait_until_sent() for power pulses Bluetooth: hci_qca: Deassert RTS while baudrate change command Bluetooth: hci_qca: Fix frame reassembly errors for wcn3990 drivers/bluetooth/hci_qca.c | 76 ++++++++++++++++++++----------------- 1 file changed, 42 insertions(+), 34 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
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> --- v2: * Updated function qca_send_power_pulse() * addressed reviewer comments. v1: * initial patch --- drivers/bluetooth/hci_qca.c | 37 +++++++++++++------------------------ 1 file changed, 13 insertions(+), 24 deletions(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index f036c8f98ea3..f5dd323c1967 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(hu->serdev, &cmd, sizeof(cmd), 0); + 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(&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); @@ -1116,7 +1111,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,8 @@ static const struct qca_vreg_data qca_soc_data = { static void qca_power_shutdown(struct hci_uart *hu) { - struct serdev_device *serdev = hu->serdev; - unsigned char cmd = QCA_WCN3990_POWEROFF_PULSE; - host_set_baudrate(hu, 2400); - hci_uart_set_flow_control(hu, true); - serdev_device_write_buf(serdev, &cmd, 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
This patch will help to stop frame reassembly errors while changing the baudrate. This is because host send a change baudrate request command to the chip with 115200 bps, Whereas chip will change their UART clocks to the enable for new baudrate and sends the response for the change request command with newer baudrate, On host side we are still operating in 115200 bps which results of reading garbage data. Here we are pulling RTS line, so that chip we will wait to send data to host until host change its baudrate. Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org> Tested-by: Matthias Kaehlcke <mka@chromium.org> --- v2: * updated commit text and comments. v1: * initial patch --- drivers/bluetooth/hci_qca.c | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index f5dd323c1967..ed905ea1c58a 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -963,7 +963,6 @@ static int qca_set_baudrate(struct hci_dev *hdev, uint8_t baudrate) struct hci_uart *hu = hci_get_drvdata(hdev); struct qca_data *qca = hu->priv; struct sk_buff *skb; - struct qca_serdev *qcadev; u8 cmd[] = { 0x01, 0x48, 0xFC, 0x01, 0x00 }; if (baudrate > QCA_BAUDRATE_3200000) @@ -977,13 +976,6 @@ static int qca_set_baudrate(struct hci_dev *hdev, uint8_t baudrate) return -ENOMEM; } - /* Disabling hardware flow control is mandatory while - * sending change baudrate request to wcn3990 SoC. - */ - qcadev = serdev_device_get_drvdata(hu->serdev); - if (qcadev->btsoc_type == QCA_WCN3990) - hci_uart_set_flow_control(hu, true); - /* Assign commands to change baudrate and packet type. */ skb_put_data(skb, cmd, sizeof(cmd)); hci_skb_pkt_type(skb) = HCI_COMMAND_PKT; @@ -999,9 +991,6 @@ static int qca_set_baudrate(struct hci_dev *hdev, uint8_t baudrate) schedule_timeout(msecs_to_jiffies(BAUDRATE_SETTLE_TIMEOUT_MS)); set_current_state(TASK_RUNNING); - if (qcadev->btsoc_type == QCA_WCN3990) - hci_uart_set_flow_control(hu, false); - return 0; } @@ -1086,6 +1075,7 @@ static int qca_check_speeds(struct hci_uart *hu) static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type) { unsigned int speed, qca_baudrate; + struct qca_serdev *qcadev; int ret; if (speed_type == QCA_INIT_SPEED) { @@ -1097,6 +1087,14 @@ static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type) if (!speed) return 0; + /* Deassert RTS while changing the baudrate of chip and host. + * This will stop chip to transmit it response with an newer + * baudrate until we change the baudarte. + */ + qcadev = serdev_device_get_drvdata(hu->serdev); + if (qcadev->btsoc_type == QCA_WCN3990) + serdev_device_set_rts(hu->serdev, false); + qca_baudrate = qca_get_baudrate_value(speed); bt_dev_dbg(hu->hdev, "Set UART speed to %d", speed); ret = qca_set_baudrate(hu->hdev, qca_baudrate); @@ -1104,6 +1102,9 @@ static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type) return ret; host_set_baudrate(hu, speed); + + if (qcadev->btsoc_type == QCA_WCN3990) + serdev_device_set_rts(hu->serdev, true); } return 0; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
During initalization of wcn3990, we observed UART is reading some stray bytes on the Rx line. This is logging Frame reassembly errors on the serial console. This could be because of tristate of Tx line of wcn3990 during boot up. [ 176.929612] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84) [ 176.945734] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84) [ 176.953298] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84) [ 177.010660] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84) [ 177.067633] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84) Now we enable a flag during bootup to stop executing proto receive function and clear it back once the initialization is done. Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org> Tested-by: Matthias Kaehlcke <mka@chromium.org> --- v2: * Updated commit text & comments. v1: * initial patch --- drivers/bluetooth/hci_qca.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index ed905ea1c58a..2f3d9e16ba5a 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -56,6 +56,7 @@ /* Controller states */ #define STATE_IN_BAND_SLEEP_ENABLED 1 +#define STATE_DISCARD_RX 2 #define IBS_WAKE_RETRANS_TIMEOUT_MS 100 #define IBS_TX_IDLE_TIMEOUT_MS 2000 @@ -511,6 +512,7 @@ static int qca_open(struct hci_uart *hu) } else { hu->init_speed = qcadev->init_speed; hu->oper_speed = qcadev->oper_speed; + set_bit(STATE_DISCARD_RX, &qca->flags); ret = qca_power_setup(hu, true); if (ret) { destroy_workqueue(qca->workqueue); @@ -903,6 +905,13 @@ static int qca_recv(struct hci_uart *hu, const void *data, int count) if (!test_bit(HCI_UART_REGISTERED, &hu->flags)) return -EUNATCH; + /* We discard Rx data received while device is in booting + * stage, This is because of BT chip Tx line is in tristate. + * Due to this we read some garbage data on UART Rx. + */ + if (test_bit(STATE_DISCARD_RX, &qca->flags)) + return 0; + qca->rx_skb = h4_recv_buf(hu->hdev, qca->rx_skb, data, count, qca_recv_pkts, ARRAY_SIZE(qca_recv_pkts)); if (IS_ERR(qca->rx_skb)) { @@ -1193,6 +1202,7 @@ static int qca_setup(struct hci_uart *hu) if (ret) return ret; + clear_bit(STATE_DISCARD_RX, &qca->flags); ret = qca_read_soc_version(hdev, &soc_ver); if (ret) return ret; @@ -1269,6 +1279,14 @@ static const struct qca_vreg_data qca_soc_data = { static void qca_power_shutdown(struct hci_uart *hu) { + struct qca_data *qca = hu->priv; + + /* From this point we go into power off state, + * disable IBS and discard all the queued data. + */ + clear_bit(STATE_IN_BAND_SLEEP_ENABLED, &qca->flags); + set_bit(STATE_DISCARD_RX, &qca->flags); + qca_flush(hu); host_set_baudrate(hu, 2400); 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
On Thu, Nov 22, 2018 at 05:45:10PM +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> > --- > v2: > * Updated function qca_send_power_pulse() > * addressed reviewer comments. These unspecific descriptions require people to open v1, read through the comments and assume you addressed all of them. Better describe briefly what the actual changes are. > v1: > * initial patch > > --- > drivers/bluetooth/hci_qca.c | 37 +++++++++++++------------------------ > 1 file changed, 13 insertions(+), 24 deletions(-) > > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c > index f036c8f98ea3..f5dd323c1967 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(hu->serdev, &cmd, sizeof(cmd), 0); > + if (ret < 0) { > + bt_dev_err(hu->hdev, "failed to send power pulse %02x to SoC", > + cmd); Re-enable flow control? The controller or serial port might be in a non-operational state anyway, but better not complicate matters further. Cheers Matthias
On Thu, Nov 22, 2018 at 05:45:11PM +0530, Balakrishna Godavarthi wrote: > This patch will help to stop frame reassembly errors while changing > the baudrate. This is because host send a change baudrate request > command to the chip with 115200 bps, Whereas chip will change their > UART clocks to the enable for new baudrate and sends the response > for the change request command with newer baudrate, On host side > we are still operating in 115200 bps which results of reading garbage > data. Here we are pulling RTS line, so that chip we will wait to send data > to host until host change its baudrate. Thanks for updating the commit message and provide more details! > Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org> > Tested-by: Matthias Kaehlcke <mka@chromium.org> > --- > v2: > * updated commit text and comments. > v1: > * initial patch > --- > drivers/bluetooth/hci_qca.c | 23 ++++++++++++----------- > 1 file changed, 12 insertions(+), 11 deletions(-) > > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c > index f5dd323c1967..ed905ea1c58a 100644 > --- a/drivers/bluetooth/hci_qca.c > +++ b/drivers/bluetooth/hci_qca.c > @@ -963,7 +963,6 @@ static int qca_set_baudrate(struct hci_dev *hdev, uint8_t baudrate) > struct hci_uart *hu = hci_get_drvdata(hdev); > struct qca_data *qca = hu->priv; > struct sk_buff *skb; > - struct qca_serdev *qcadev; > u8 cmd[] = { 0x01, 0x48, 0xFC, 0x01, 0x00 }; > > if (baudrate > QCA_BAUDRATE_3200000) > @@ -977,13 +976,6 @@ static int qca_set_baudrate(struct hci_dev *hdev, uint8_t baudrate) > return -ENOMEM; > } > > - /* Disabling hardware flow control is mandatory while > - * sending change baudrate request to wcn3990 SoC. > - */ > - qcadev = serdev_device_get_drvdata(hu->serdev); > - if (qcadev->btsoc_type == QCA_WCN3990) > - hci_uart_set_flow_control(hu, true); > - > /* Assign commands to change baudrate and packet type. */ > skb_put_data(skb, cmd, sizeof(cmd)); > hci_skb_pkt_type(skb) = HCI_COMMAND_PKT; > @@ -999,9 +991,6 @@ static int qca_set_baudrate(struct hci_dev *hdev, uint8_t baudrate) > schedule_timeout(msecs_to_jiffies(BAUDRATE_SETTLE_TIMEOUT_MS)); > set_current_state(TASK_RUNNING); > > - if (qcadev->btsoc_type == QCA_WCN3990) > - hci_uart_set_flow_control(hu, false); > - > return 0; > } > > @@ -1086,6 +1075,7 @@ static int qca_check_speeds(struct hci_uart *hu) > static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type) > { > unsigned int speed, qca_baudrate; > + struct qca_serdev *qcadev; > int ret; > > if (speed_type == QCA_INIT_SPEED) { > @@ -1097,6 +1087,14 @@ static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type) > if (!speed) > return 0; > > + /* Deassert RTS while changing the baudrate of chip and host. > + * This will stop chip to transmit it response with an newer > + * baudrate until we change the baudarte. nit: baudrate re-nit (to consider if you respin anyway): 'This prevents the chip from transmitting its response with the new baudrate while the host port is still operating at the old speed'? (I'm not a native English speaker, probably there is still room for improvement ;-) Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
On Thu, Nov 22, 2018 at 05:45:12PM +0530, Balakrishna Godavarthi wrote: > During initalization of wcn3990, we observed UART is reading some > stray bytes on the Rx line. This is logging Frame reassembly errors > on the serial console. This could be because of tristate of Tx line > of wcn3990 during boot up. > > [ 176.929612] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84) > [ 176.945734] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84) > [ 176.953298] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84) > [ 177.010660] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84) > [ 177.067633] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84) > > Now we enable a flag during bootup to stop executing proto receive > function and clear it back once the initialization is done. > > Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org> > Tested-by: Matthias Kaehlcke <mka@chromium.org> > --- > v2: > * Updated commit text & comments. > v1: > * initial patch > --- > drivers/bluetooth/hci_qca.c | 18 ++++++++++++++++++ > 1 file changed, 18 insertions(+) > > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c > index ed905ea1c58a..2f3d9e16ba5a 100644 > --- a/drivers/bluetooth/hci_qca.c > +++ b/drivers/bluetooth/hci_qca.c > @@ -56,6 +56,7 @@ > > /* Controller states */ > #define STATE_IN_BAND_SLEEP_ENABLED 1 > +#define STATE_DISCARD_RX 2 > > #define IBS_WAKE_RETRANS_TIMEOUT_MS 100 > #define IBS_TX_IDLE_TIMEOUT_MS 2000 > @@ -511,6 +512,7 @@ static int qca_open(struct hci_uart *hu) > } else { > hu->init_speed = qcadev->init_speed; > hu->oper_speed = qcadev->oper_speed; > + set_bit(STATE_DISCARD_RX, &qca->flags); > ret = qca_power_setup(hu, true); > if (ret) { > destroy_workqueue(qca->workqueue); > @@ -903,6 +905,13 @@ static int qca_recv(struct hci_uart *hu, const void *data, int count) > if (!test_bit(HCI_UART_REGISTERED, &hu->flags)) > return -EUNATCH; > > + /* We discard Rx data received while device is in booting > + * stage, This is because of BT chip Tx line is in tristate. > + * Due to this we read some garbage data on UART Rx. > + */ > + if (test_bit(STATE_DISCARD_RX, &qca->flags)) > + return 0; > + > qca->rx_skb = h4_recv_buf(hu->hdev, qca->rx_skb, data, count, > qca_recv_pkts, ARRAY_SIZE(qca_recv_pkts)); > if (IS_ERR(qca->rx_skb)) { > @@ -1193,6 +1202,7 @@ static int qca_setup(struct hci_uart *hu) > if (ret) > return ret; > > + clear_bit(STATE_DISCARD_RX, &qca->flags); > ret = qca_read_soc_version(hdev, &soc_ver); > if (ret) > return ret; > @@ -1269,6 +1279,14 @@ static const struct qca_vreg_data qca_soc_data = { > > static void qca_power_shutdown(struct hci_uart *hu) > { > + struct qca_data *qca = hu->priv; > + > + /* From this point we go into power off state, > + * disable IBS and discard all the queued data. > + */ > + clear_bit(STATE_IN_BAND_SLEEP_ENABLED, &qca->flags); Is IBS actually related to the frame reassembly errors or is this addressing a different issue? In 100 iteratios of 'hciconfig up/down' without clearing the flag I didn't observe any frame reassembly errors. > + set_bit(STATE_DISCARD_RX, &qca->flags); > + qca_flush(hu); > host_set_baudrate(hu, 2400); > qca_send_power_pulse(hu, QCA_WCN3990_POWEROFF_PULSE); > qca_power_setup(hu, false);
On Mon, Nov 26, 2018 at 04:09:50PM -0800, Matthias Kaehlcke wrote:
> On Thu, Nov 22, 2018 at 05:45:12PM +0530, Balakrishna Godavarthi wrote:
> > During initalization of wcn3990, we observed UART is reading some
> > stray bytes on the Rx line. This is logging Frame reassembly errors
> > on the serial console. This could be because of tristate of Tx line
> > of wcn3990 during boot up.
> >
> > [ 176.929612] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84)
> > [ 176.945734] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84)
> > [ 176.953298] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84)
> > [ 177.010660] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84)
> > [ 177.067633] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84)
> >
> > Now we enable a flag during bootup to stop executing proto receive
> > function and clear it back once the initialization is done.
> >
> > Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
> > Tested-by: Matthias Kaehlcke <mka@chromium.org>
> > ---
> > v2:
> > * Updated commit text & comments.
> > v1:
> > * initial patch
> > ---
> > drivers/bluetooth/hci_qca.c | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> > index ed905ea1c58a..2f3d9e16ba5a 100644
> > --- a/drivers/bluetooth/hci_qca.c
> > +++ b/drivers/bluetooth/hci_qca.c
> > @@ -56,6 +56,7 @@
> >
> > /* Controller states */
> > #define STATE_IN_BAND_SLEEP_ENABLED 1
> > +#define STATE_DISCARD_RX 2
> >
> > #define IBS_WAKE_RETRANS_TIMEOUT_MS 100
> > #define IBS_TX_IDLE_TIMEOUT_MS 2000
> > @@ -511,6 +512,7 @@ static int qca_open(struct hci_uart *hu)
> > } else {
> > hu->init_speed = qcadev->init_speed;
> > hu->oper_speed = qcadev->oper_speed;
> > + set_bit(STATE_DISCARD_RX, &qca->flags);
> > ret = qca_power_setup(hu, true);
> > if (ret) {
> > destroy_workqueue(qca->workqueue);
> > @@ -903,6 +905,13 @@ static int qca_recv(struct hci_uart *hu, const void *data, int count)
> > if (!test_bit(HCI_UART_REGISTERED, &hu->flags))
> > return -EUNATCH;
> >
> > + /* We discard Rx data received while device is in booting
> > + * stage, This is because of BT chip Tx line is in tristate.
> > + * Due to this we read some garbage data on UART Rx.
> > + */
> > + if (test_bit(STATE_DISCARD_RX, &qca->flags))
> > + return 0;
> > +
> > qca->rx_skb = h4_recv_buf(hu->hdev, qca->rx_skb, data, count,
> > qca_recv_pkts, ARRAY_SIZE(qca_recv_pkts));
> > if (IS_ERR(qca->rx_skb)) {
> > @@ -1193,6 +1202,7 @@ static int qca_setup(struct hci_uart *hu)
> > if (ret)
> > return ret;
> >
> > + clear_bit(STATE_DISCARD_RX, &qca->flags);
> > ret = qca_read_soc_version(hdev, &soc_ver);
> > if (ret)
> > return ret;
> > @@ -1269,6 +1279,14 @@ static const struct qca_vreg_data qca_soc_data = {
> >
> > static void qca_power_shutdown(struct hci_uart *hu)
> > {
> > + struct qca_data *qca = hu->priv;
> > +
> > + /* From this point we go into power off state,
> > + * disable IBS and discard all the queued data.
> > + */
> > + clear_bit(STATE_IN_BAND_SLEEP_ENABLED, &qca->flags);
>
> Is IBS actually related to the frame reassembly errors or is this
> addressing a different issue? In 100 iteratios of 'hciconfig up/down'
> without clearing the flag I didn't observe any frame reassembly
> errors.
Looks like this addresses the "Bluetooth: Received HCI_IBS_SLEEP_IND
in rx state 0" messages that are seen when the interface is brought up
on a system with firmware binaries (with IBS support?). Please spin
this out into a separate patch.
Thanks
Matthias
Hi Matthias, On 2018-11-27 01:12, Matthias Kaehlcke wrote: > On Thu, Nov 22, 2018 at 05:45:11PM +0530, Balakrishna Godavarthi wrote: >> This patch will help to stop frame reassembly errors while changing >> the baudrate. This is because host send a change baudrate request >> command to the chip with 115200 bps, Whereas chip will change their >> UART clocks to the enable for new baudrate and sends the response >> for the change request command with newer baudrate, On host side >> we are still operating in 115200 bps which results of reading garbage >> data. Here we are pulling RTS line, so that chip we will wait to send >> data >> to host until host change its baudrate. > > Thanks for updating the commit message and provide more details! > >> Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org> >> Tested-by: Matthias Kaehlcke <mka@chromium.org> >> --- >> v2: >> * updated commit text and comments. >> v1: >> * initial patch >> --- >> drivers/bluetooth/hci_qca.c | 23 ++++++++++++----------- >> 1 file changed, 12 insertions(+), 11 deletions(-) >> >> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c >> index f5dd323c1967..ed905ea1c58a 100644 >> --- a/drivers/bluetooth/hci_qca.c >> +++ b/drivers/bluetooth/hci_qca.c >> @@ -963,7 +963,6 @@ static int qca_set_baudrate(struct hci_dev *hdev, >> uint8_t baudrate) >> struct hci_uart *hu = hci_get_drvdata(hdev); >> struct qca_data *qca = hu->priv; >> struct sk_buff *skb; >> - struct qca_serdev *qcadev; >> u8 cmd[] = { 0x01, 0x48, 0xFC, 0x01, 0x00 }; >> >> if (baudrate > QCA_BAUDRATE_3200000) >> @@ -977,13 +976,6 @@ static int qca_set_baudrate(struct hci_dev *hdev, >> uint8_t baudrate) >> return -ENOMEM; >> } >> >> - /* Disabling hardware flow control is mandatory while >> - * sending change baudrate request to wcn3990 SoC. >> - */ >> - qcadev = serdev_device_get_drvdata(hu->serdev); >> - if (qcadev->btsoc_type == QCA_WCN3990) >> - hci_uart_set_flow_control(hu, true); >> - >> /* Assign commands to change baudrate and packet type. */ >> skb_put_data(skb, cmd, sizeof(cmd)); >> hci_skb_pkt_type(skb) = HCI_COMMAND_PKT; >> @@ -999,9 +991,6 @@ static int qca_set_baudrate(struct hci_dev *hdev, >> uint8_t baudrate) >> schedule_timeout(msecs_to_jiffies(BAUDRATE_SETTLE_TIMEOUT_MS)); >> set_current_state(TASK_RUNNING); >> >> - if (qcadev->btsoc_type == QCA_WCN3990) >> - hci_uart_set_flow_control(hu, false); >> - >> return 0; >> } >> >> @@ -1086,6 +1075,7 @@ static int qca_check_speeds(struct hci_uart *hu) >> static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type >> speed_type) >> { >> unsigned int speed, qca_baudrate; >> + struct qca_serdev *qcadev; >> int ret; >> >> if (speed_type == QCA_INIT_SPEED) { >> @@ -1097,6 +1087,14 @@ static int qca_set_speed(struct hci_uart *hu, >> enum qca_speed_type speed_type) >> if (!speed) >> return 0; >> >> + /* Deassert RTS while changing the baudrate of chip and host. >> + * This will stop chip to transmit it response with an newer >> + * baudrate until we change the baudarte. > > nit: baudrate > > re-nit (to consider if you respin anyway): 'This prevents the chip > from transmitting its response with the new baudrate while the host > port is still operating at the old speed'? > (I'm not a native English speaker, probably there is still room for > improvement ;-) [Bala]: will update. > > Reviewed-by: Matthias Kaehlcke <mka@chromium.org> -- Regards Balakrishna.
Hi Matthias, On 2018-11-27 05:57, Matthias Kaehlcke wrote: > On Mon, Nov 26, 2018 at 04:09:50PM -0800, Matthias Kaehlcke wrote: >> On Thu, Nov 22, 2018 at 05:45:12PM +0530, Balakrishna Godavarthi >> wrote: >> > During initalization of wcn3990, we observed UART is reading some >> > stray bytes on the Rx line. This is logging Frame reassembly errors >> > on the serial console. This could be because of tristate of Tx line >> > of wcn3990 during boot up. >> > >> > [ 176.929612] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84) >> > [ 176.945734] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84) >> > [ 176.953298] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84) >> > [ 177.010660] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84) >> > [ 177.067633] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84) >> > >> > Now we enable a flag during bootup to stop executing proto receive >> > function and clear it back once the initialization is done. >> > >> > Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org> >> > Tested-by: Matthias Kaehlcke <mka@chromium.org> >> > --- >> > v2: >> > * Updated commit text & comments. >> > v1: >> > * initial patch >> > --- >> > drivers/bluetooth/hci_qca.c | 18 ++++++++++++++++++ >> > 1 file changed, 18 insertions(+) >> > >> > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c >> > index ed905ea1c58a..2f3d9e16ba5a 100644 >> > --- a/drivers/bluetooth/hci_qca.c >> > +++ b/drivers/bluetooth/hci_qca.c >> > @@ -56,6 +56,7 @@ >> > >> > /* Controller states */ >> > #define STATE_IN_BAND_SLEEP_ENABLED 1 >> > +#define STATE_DISCARD_RX 2 >> > >> > #define IBS_WAKE_RETRANS_TIMEOUT_MS 100 >> > #define IBS_TX_IDLE_TIMEOUT_MS 2000 >> > @@ -511,6 +512,7 @@ static int qca_open(struct hci_uart *hu) >> > } else { >> > hu->init_speed = qcadev->init_speed; >> > hu->oper_speed = qcadev->oper_speed; >> > + set_bit(STATE_DISCARD_RX, &qca->flags); >> > ret = qca_power_setup(hu, true); >> > if (ret) { >> > destroy_workqueue(qca->workqueue); >> > @@ -903,6 +905,13 @@ static int qca_recv(struct hci_uart *hu, const void *data, int count) >> > if (!test_bit(HCI_UART_REGISTERED, &hu->flags)) >> > return -EUNATCH; >> > >> > + /* We discard Rx data received while device is in booting >> > + * stage, This is because of BT chip Tx line is in tristate. >> > + * Due to this we read some garbage data on UART Rx. >> > + */ >> > + if (test_bit(STATE_DISCARD_RX, &qca->flags)) >> > + return 0; >> > + >> > qca->rx_skb = h4_recv_buf(hu->hdev, qca->rx_skb, data, count, >> > qca_recv_pkts, ARRAY_SIZE(qca_recv_pkts)); >> > if (IS_ERR(qca->rx_skb)) { >> > @@ -1193,6 +1202,7 @@ static int qca_setup(struct hci_uart *hu) >> > if (ret) >> > return ret; >> > >> > + clear_bit(STATE_DISCARD_RX, &qca->flags); >> > ret = qca_read_soc_version(hdev, &soc_ver); >> > if (ret) >> > return ret; >> > @@ -1269,6 +1279,14 @@ static const struct qca_vreg_data qca_soc_data = { >> > >> > static void qca_power_shutdown(struct hci_uart *hu) >> > { >> > + struct qca_data *qca = hu->priv; >> > + >> > + /* From this point we go into power off state, >> > + * disable IBS and discard all the queued data. >> > + */ >> > + clear_bit(STATE_IN_BAND_SLEEP_ENABLED, &qca->flags); >> >> Is IBS actually related to the frame reassembly errors or is this >> addressing a different issue? In 100 iteratios of 'hciconfig up/down' >> without clearing the flag I didn't observe any frame reassembly >> errors. > > Looks like this addresses the "Bluetooth: Received HCI_IBS_SLEEP_IND > in rx state 0" messages that are seen when the interface is brought up > on a system with firmware binaries (with IBS support?). Please spin > this out into a separate patch. > [Bala]: "Bluetooth: Received HCI_IBS_SLEEP_IND in rx state 0 is an different issue. i suspect that is due to mismatch of ibs timers over flow value between wcn3990 & HOST. clearing ibs is required, to stop ibs state machine while we do hci close this is intern help in resolving the frame reassembly errors during close (in rare case observed) anyways will send this a separate patch. > Thanks > > Matthias -- Regards Balakrishna.