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 1/3] Bluetooth: hci_qca: use wait_until_sent() for power pulses
Date: Thu, 24 Jan 2019 17:14:12 -0800 [thread overview]
Message-ID: <20190125011412.GE81583@google.com> (raw)
In-Reply-To: <20190124120808.8275-2-bgodavar@codeaurora.org>
On Thu, Jan 24, 2019 at 05:38:06PM +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>
> ---
> Changes in v9:
> * Reverted to 100us sleep.
> * used inline call msecs_to_jiffies()
>
> Changes in v8:
> * Updated 1 second timeout instead of indefinite wait.
>
> Changes in v7:
> * updated the wait time to 5 ms after sending power pulses.
>
> Changes in v6:
> * added serdev_device_write_flush() in qca_send_power_pulse
> instead during the power off pulse.
>
> Changes in v5:
> * added serdev_device_write_flush() in qca_power_off().
> ---
> drivers/bluetooth/hci_qca.c | 40 +++++++++++++++----------------------
> 1 file changed, 16 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index f036c8f98ea3..c08f4d105e73 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -60,6 +60,7 @@
> #define IBS_WAKE_RETRANS_TIMEOUT_MS 100
> #define IBS_TX_IDLE_TIMEOUT_MS 2000
> #define BAUDRATE_SETTLE_TIMEOUT_MS 300
> +#define POWER_PULSE_TRANS_TIMEOUT_MS 1000
I still doubt that this mega-timeout of 1s is needed, but it shouldn't
do any harm either, so whatever ...
> /* susclk rate */
> #define SUSCLK_RATE_32KHZ 32768
> @@ -1013,11 +1014,10 @@ 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;
> + int timeout = msecs_to_jiffies(POWER_PULSE_TRANS_TIMEOUT_MS);
>
> /* These power pulses are single byte command which are sent
> * at required baudrate to wcn3990. On wcn3990, we have an external
> @@ -1029,21 +1029,19 @@ 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 controller", cmd);
>
> + serdev_device_write_flush(hu->serdev);
> hci_uart_set_flow_control(hu, true);
> + ret = serdev_device_write_buf(hu->serdev, &cmd, sizeof(cmd));
> + if (ret < 0) {
> + bt_dev_err(hu->hdev, "failed to send power pulse %02x", 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, timeout);
>
> - /* Wait for 100 uS for SoC to settle down */
> + /* Wait for 100 uS for SoC to settle down for the received byte. */
I don't think 'for the received byte' adds much value here. If you
respin anyway I'd suggest to leave the comment as is.
> usleep_range(100, 200);
> hci_uart_set_flow_control(hu, false);
>
> @@ -1116,7 +1114,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 +1136,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 +1271,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);
> }
>
Looks good to me besides possible minor improvements:
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
next prev parent reply other threads:[~2019-01-25 1:14 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 [this message]
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
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=20190125011412.GE81583@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.