From: Matthias Kaehlcke <mka@chromium.org>
To: Balakrishna Godavarthi <bgodavar@codeaurora.org>
Cc: marcel@holtmann.org, johan.hedberg@gmail.com, johan@kernel.org,
linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org,
hemantg@codeaurora.org, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH v9 2/3] Bluetooth: hci_qca: Deassert RTS while baudrate change command
Date: Thu, 24 Jan 2019 16:12:59 -0800 [thread overview]
Message-ID: <20190125001259.GB81583@google.com> (raw)
In-Reply-To: <20190124120808.8275-3-bgodavar@codeaurora.org>
Hi Balakrishna,
On Thu, Jan 24, 2019 at 05:38:07PM +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.
>
> Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
> Tested-by: Matthias Kaehlcke <mka@chromium.org>
> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> Changes in v9:
> * disabled flow control while setting the baudrate of HOST and chip.
> ---
> drivers/bluetooth/hci_qca.c | 24 +++++++++++++-----------
> 1 file changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index c08f4d105e73..6b5bcd44e24c 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -964,7 +964,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)
> @@ -978,13 +977,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;
> @@ -1000,9 +992,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;
> }
>
> @@ -1089,6 +1078,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) {
> @@ -1100,6 +1090,15 @@ 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 prevent chip from transmitting its response with
> + * the new baudrate while the host port is still operating at
> + * the old speed.
> + */
It is not necessarily evident which action deasserts RTS, I suggest to
rephrase it to something like:
"Disable flow control for wcn3990 to deassert RTS while ... "
> + qcadev = serdev_device_get_drvdata(hu->serdev);
> + if (qcadev->btsoc_type == QCA_WCN3990)
> + hci_uart_set_flow_control(hu, true);
> +
> 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);
flow control should be re-enabled in the error path.
Cheers
Matthias
next prev parent reply other threads:[~2019-01-25 0:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-24 12:08 [PATCH v9 0/3] Bug fixes for Qualcomm BT chip wcn3990 Balakrishna Godavarthi
2019-01-24 12:08 ` [PATCH v9 1/3] Bluetooth: hci_qca: use wait_until_sent() for power pulses Balakrishna Godavarthi
2019-01-25 1:14 ` Matthias Kaehlcke
2019-01-28 13:49 ` Balakrishna Godavarthi
2019-01-28 17:47 ` Matthias Kaehlcke
2019-01-29 13:08 ` Balakrishna Godavarthi
2019-01-24 12:08 ` [PATCH v9 2/3] Bluetooth: hci_qca: Deassert RTS while baudrate change command Balakrishna Godavarthi
2019-01-25 0:12 ` Matthias Kaehlcke [this message]
2019-01-28 13:45 ` Balakrishna Godavarthi
2019-01-24 12:08 ` [PATCH v9 3/3] Bluetooth: hci_qca: Disable IBS state machine and flush Tx buffer Balakrishna Godavarthi
2019-01-25 0:55 ` Matthias Kaehlcke
2019-02-01 11:40 ` Balakrishna Godavarthi
2019-02-01 18:35 ` Matthias Kaehlcke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190125001259.GB81583@google.com \
--to=mka@chromium.org \
--cc=bgodavar@codeaurora.org \
--cc=hemantg@codeaurora.org \
--cc=johan.hedberg@gmail.com \
--cc=johan@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcel@holtmann.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).