From: Kai-Heng Feng <kai.heng.feng@canonical.com>
To: 陆朱伟 <alex_lu@realsil.com.cn>
Cc: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>,
Marcel Holtmann <marcel@holtmann.org>,
Johan Hedberg <johan.hedberg@gmail.com>,
"open list:BLUETOOTH DRIVERS" <linux-bluetooth@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
"open list:USB XHCI DRIVER" <linux-usb@vger.kernel.org>
Subject: Re: [PATCH] Bluetooth: btusb: Avoid unnecessary reset upon system resume
Date: Fri, 25 Sep 2020 15:56:00 +0800 [thread overview]
Message-ID: <B7DF43CE-1BD7-4A2B-838F-2CAC914E209B@canonical.com> (raw)
In-Reply-To: <70edd6da224048488806d2af89294d3e@realsil.com.cn>
Hi Alex,
> On Sep 25, 2020, at 15:42, 陆朱伟 <alex_lu@realsil.com.cn> wrote:
>
> Hi Kai-Heng,
>
>> On 25 September 2020 at 15:14, Kai-Heng Feng wrote:
>>
>> Hi Alex,
[snipped]
>> Apparently for my case, RTL8821CE, firmware was kept without setting
>> remote wakeup.
>
> So you got the btusb disconnect and reprobe sequence after resume, and " Bluetooth: hci0: command 0x1001 tx timeout " before firmware downloading ?
USB power wasn't lost, but it got USB warm reset because btusb driver explicitly flagged "reset_resume = 1".
Then the issue appeared as "Bluetooth: hci0: command 0x1001 tx timeout", before downloading firmware.
>
>> Is it okay to also set remote wakeup for global suspend to retain the
>> firmware?
>
> Yes, it's ok.
Abhishek, does setting remote wakeup during global suspend works for you?
>
>> If firmware was retained, does USB warm reset affect BT controller in
>> anyway?
>
> USB warm reset shouldn't affect BT controller.
> But hci device will not work after resume, because btrtl will find "unknown IC info, lmp subvert ..." and return error when hci device setup is called.
> Tips: The lmp subver in controller changes after firmware downloading. And driver will find " unknown IC info, lmp subver ..." when setup is called with firmware retained.
This should already be fixed by "Bluetooth: btrtl: Restore old logic to assume firmware is already loaded".
Kai-Heng
>
>>
>> Kai-Heng
>>
>>>
>>>>
>>>> Kai-Heng
>>>>
>>>>>
>>>>> @Alex -- What is the common behavior for Realtek controllers? Should
>>>>> we set BTUSB_WAKEUP_DISABLE only on RTL8822CE or should we unset
>> it
>>>>> only on RTL8821CE?
>>>>>
>>>>>>>
>>>>>>> I would prefer this doesn't get accepted in its current state.
>>>>>>
>>>>>> Of course.
>>>>>> I think we need to find the root cause for your case before applying this
>>>> one.
>>>>>>
>>>>>> Kai-Heng
>>>>>>
>>>>>>>
>>>>>>> Abhishek
>>>>>>>
>>>>>>> On Wed, Sep 23, 2020 at 10:56 AM Kai-Heng Feng
>>>>>>> <kai.heng.feng@canonical.com> wrote:
>>>>>>>>
>>>>>>>> Realtek bluetooth controller may fail to work after system sleep:
>>>>>>>> [ 1272.707670] Bluetooth: hci0: command 0x1001 tx timeout
>>>>>>>> [ 1280.835712] Bluetooth: hci0: RTL: HCI_OP_READ_LOCAL_VERSION
>>>> failed (-110)
>>>>>>>>
>>>>>>>> If platform firmware doesn't cut power off during suspend, the
>>>> firmware
>>>>>>>> is considered retained in controller but the driver is still asking USB
>>>>>>>> core to perform a reset-resume. This can make bluetooth controller
>>>>>>>> unusable.
>>>>>>>>
>>>>>>>> So avoid unnecessary reset to resolve the issue.
>>>>>>>>
>>>>>>>> For devices that really lose power during suspend, USB core will
>> detect
>>>>>>>> and handle reset-resume correctly.
>>>>>>>>
>>>>>>>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>>>>>>>> ---
>>>>>>>> drivers/bluetooth/btusb.c | 8 +++-----
>>>>>>>> 1 file changed, 3 insertions(+), 5 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
>>>>>>>> index 8d2608ddfd08..de86ef4388f9 100644
>>>>>>>> --- a/drivers/bluetooth/btusb.c
>>>>>>>> +++ b/drivers/bluetooth/btusb.c
>>>>>>>> @@ -4255,17 +4255,15 @@ static int btusb_suspend(struct
>>>> usb_interface *intf, pm_message_t message)
>>>>>>>> enable_irq(data->oob_wake_irq);
>>>>>>>> }
>>>>>>>>
>>>>>>>> - /* For global suspend, Realtek devices lose the loaded fw
>>>>>>>> - * in them. But for autosuspend, firmware should remain.
>>>>>>>> - * Actually, it depends on whether the usb host sends
>>>>>>>> + /* For global suspend, Realtek devices lose the loaded fw in
>> them
>>>> if
>>>>>>>> + * platform firmware cut power off. But for autosuspend,
>>>> firmware
>>>>>>>> + * should remain. Actually, it depends on whether the usb host
>>>> sends
>>>>>>>> * set feature (enable wakeup) or not.
>>>>>>>> */
>>>>>>>> if (test_bit(BTUSB_WAKEUP_DISABLE, &data->flags)) {
>>>>>>>> if (PMSG_IS_AUTO(message) &&
>>>>>>>> device_can_wakeup(&data->udev->dev))
>>>>>>>> data->udev->do_remote_wakeup = 1;
>>>>>>>> - else if (!PMSG_IS_AUTO(message))
>>>>>>>> - data->udev->reset_resume = 1;
>>>>>>>> }
>>>>>>>>
>>>>>>>> return 0;
>>>>>>>> --
>>>>>>>> 2.17.1
>>>>
>>>>
>>>> ------Please consider the environment before printing this e-mail.
next prev parent reply other threads:[~2020-09-25 7:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-25 7:04 [PATCH] Bluetooth: btusb: Avoid unnecessary reset upon system resume 陆朱伟
2020-09-25 7:14 ` Kai-Heng Feng
2020-09-25 7:42 ` 答复: " 陆朱伟
2020-09-25 7:56 ` Kai-Heng Feng [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-09-25 8:23 陆朱伟
2020-09-25 11:51 ` Kai-Heng Feng
2020-09-25 6:40 陆朱伟
2020-09-25 6:47 ` Kai-Heng Feng
[not found] <20200923175602.9523-1-kai.heng.feng@canonical.com>
[not found] ` <CANFp7mV7fC9_EZHd7B0Cu-owgCVdA6CNd2bb7XwFf5+6b7FVpg@mail.gmail.com>
2020-09-24 7:10 ` Kai-Heng Feng
2020-09-25 3:33 ` Abhishek Pandit-Subedi
2020-09-25 6:03 ` Kai-Heng Feng
2020-09-28 9:37 ` Oliver Neukum
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=B7DF43CE-1BD7-4A2B-838F-2CAC914E209B@canonical.com \
--to=kai.heng.feng@canonical.com \
--cc=abhishekpandit@chromium.org \
--cc=alex_lu@realsil.com.cn \
--cc=johan.hedberg@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@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).