All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zijun Hu <zijuhu@codeaurora.org>
To: Matthias Kaehlcke <mka@chromium.org>
Cc: marcel@holtmann.org, johan.hedberg@gmail.com,
	linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, bgodavar@codeaurora.org,
	c-hbandi@codeaurora.org, hemantg@codeaurora.org,
	rjliao@codeaurora.org
Subject: Re: [PATCH v3] bluetooth: hci_qca: Fix qca6390 enable failure after warm reboot
Date: Thu, 28 May 2020 13:04:25 +0800	[thread overview]
Message-ID: <4c5c9fd8-e90c-c7e2-8f21-edad3c3ca7ff@codeaurora.org> (raw)
In-Reply-To: <20200527164832.GH4525@google.com>



On 5/28/2020 12:48 AM, Matthias Kaehlcke wrote:
> Hi Zijun,
> 
> On Wed, May 27, 2020 at 10:32:39AM +0800, Zijun Hu wrote:
>> Warm reboot can not restore qca6390 controller baudrate
>> to default due to lack of controllable BT_EN pin or power
>> supply, so fails to download firmware after warm reboot.
>>
>> Fixed by sending EDL_SOC_RESET VSC to reset controller
>> within added device shutdown implementation.
>>
>> Signed-off-by: Zijun Hu <zijuhu@codeaurora.org>
>> ---
>>  drivers/bluetooth/hci_qca.c | 29 +++++++++++++++++++++++++++++
>>  1 file changed, 29 insertions(+)
>>
>> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
>> index e4a6823..4b6f8b6 100644
>> --- a/drivers/bluetooth/hci_qca.c
>> +++ b/drivers/bluetooth/hci_qca.c
>> @@ -1975,6 +1975,34 @@ static void qca_serdev_remove(struct serdev_device *serdev)
>>  	hci_uart_unregister_device(&qcadev->serdev_hu);
>>  }
>>  
>> +static void qca_serdev_shutdown(struct device *dev)
>> +{
>> +	int ret;
>> +	int timeout = msecs_to_jiffies(CMD_TRANS_TIMEOUT_MS);
>> +	struct serdev_device *serdev = to_serdev_device(dev);
>> +	struct qca_serdev *qcadev = serdev_device_get_drvdata(serdev);
>> +	const u8 ibs_wake_cmd[] = { 0xFD };
>> +	const u8 edl_reset_soc_cmd[] = { 0x01, 0x00, 0xFC, 0x01, 0x05 };
>> +
>> +	if (qcadev->btsoc_type == QCA_QCA6390) {
>> +		serdev_device_write_flush(serdev);
>> +		serdev_device_write_buf(serdev,
>> +				ibs_wake_cmd, sizeof(ibs_wake_cmd));
>> +		serdev_device_wait_until_sent(serdev, timeout);
> 
> Why no check of the return value of serdev_device_write_buf() here,
> does it make sense to continue if sending the wakeup command failed?
> 
i will correct it at v4 patch
> Couldn't serdev_device_write() be used instead of the _write_buf() +
> _wait_until_sent() combo?
> 
i don't think so, serdev_device_write() is not appropriate at here.
serdev_device_write_wakeup() should be used to release completion hold
by serdev_device_write(), however @hci_serdev_client_ops doesn't use
serdev_device_write_wakeup() to implement its write_wakeup operation.
we don't want to touch common hci_serdev.c code.

>> +		usleep_range(8000, 10000);
>> +
>> +		serdev_device_write_flush(serdev);
> 
> I suppose the flush is done because _wait_until_sent() could have timed out.
> Another reason to use _device_write() (if suitable), since it returns
> -ETIMEDOUT in that case?
>
flush is prefixed at write operation to speed up
shutdown procedure in case of unexpected data injected
during waiting for controller wakeup.
the combo have been used and i just follow it>> +		ret = serdev_device_write_buf(serdev,
>> +				edl_reset_soc_cmd, sizeof(edl_reset_soc_cmd));
>> +		if (ret < 0) {
>> +			BT_ERR("QCA send EDL_RESET_REQ error: %d", ret);
>> +			return;
>> +		}
>> +		serdev_device_wait_until_sent(serdev, timeout);
>> +		usleep_range(8000, 10000);
>> +	}
>> +}
>> +
>>  static int __maybe_unused qca_suspend(struct device *dev)
>>  {
>>  	struct hci_dev *hdev = container_of(dev, struct hci_dev, dev);
>> @@ -2100,6 +2128,7 @@ static struct serdev_device_driver qca_serdev_driver = {
>>  		.name = "hci_uart_qca",
>>  		.of_match_table = of_match_ptr(qca_bluetooth_of_match),
>>  		.acpi_match_table = ACPI_PTR(qca_bluetooth_acpi_match),
>> +		.shutdown = qca_serdev_shutdown,
>>  		.pm = &qca_pm_ops,
>>  	},
>>  };
>> -- 
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
>>

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

  reply	other threads:[~2020-05-28  5:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-27  2:32 [PATCH v3] bluetooth: hci_qca: Fix qca6390 enable failure after warm reboot Zijun Hu
2020-05-27 16:48 ` Matthias Kaehlcke
2020-05-28  5:04   ` Zijun Hu [this message]
2020-05-28 15:44     ` Matthias Kaehlcke
2020-05-28 19:34       ` Zijun Hu

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=4c5c9fd8-e90c-c7e2-8f21-edad3c3ca7ff@codeaurora.org \
    --to=zijuhu@codeaurora.org \
    --cc=bgodavar@codeaurora.org \
    --cc=c-hbandi@codeaurora.org \
    --cc=hemantg@codeaurora.org \
    --cc=johan.hedberg@gmail.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcel@holtmann.org \
    --cc=mka@chromium.org \
    --cc=rjliao@codeaurora.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.