diff mbox series

[v1] usb: chipidea: tegra: Delay PHY suspending

Message ID 20210609120404.3991-1-digetx@gmail.com (mailing list archive)
State New, archived
Headers show
Series [v1] usb: chipidea: tegra: Delay PHY suspending | expand

Commit Message

Dmitry Osipenko June 9, 2021, 12:04 p.m. UTC
The ChipIdea driver enters into suspend immediately after seeing a
VBUS disconnection. Some devices need an extra delay after losing
VBUS, otherwise VBUS may be floating, preventing the PHY's suspending
by the VBUS detection sensors. This problem was found on Tegra30 Asus
Transformer TF700T tablet device, where the USB PHY wakes up immediately
from suspend because VBUS sensor continues to detect VBUS as active after
disconnection. A minimum delay of 20ms is needed in order to fix this
issue, hence add 25ms delay before suspending the PHY.

Reported-by: Maxim Schwalm <maxim.schwalm@gmail.com> # Asus TF700T
Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> # Asus TF700T
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
---
 drivers/usb/chipidea/ci_hdrc_tegra.c | 8 ++++++++
 1 file changed, 8 insertions(+)

Comments

Dmitry Osipenko June 9, 2021, 12:07 p.m. UTC | #1
09.06.2021 15:04, Dmitry Osipenko пишет:
> The ChipIdea driver enters into suspend immediately after seeing a
> VBUS disconnection. Some devices need an extra delay after losing
> VBUS, otherwise VBUS may be floating, preventing the PHY's suspending
> by the VBUS detection sensors. This problem was found on Tegra30 Asus
> Transformer TF700T tablet device, where the USB PHY wakes up immediately
> from suspend because VBUS sensor continues to detect VBUS as active after
> disconnection. A minimum delay of 20ms is needed in order to fix this
> issue, hence add 25ms delay before suspending the PHY.
> 
> Reported-by: Maxim Schwalm <maxim.schwalm@gmail.com> # Asus TF700T
> Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> # Asus TF700T
> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
> ---
>  drivers/usb/chipidea/ci_hdrc_tegra.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_tegra.c b/drivers/usb/chipidea/ci_hdrc_tegra.c
> index 60361141ac04..d1359b76a0e8 100644
> --- a/drivers/usb/chipidea/ci_hdrc_tegra.c
> +++ b/drivers/usb/chipidea/ci_hdrc_tegra.c
> @@ -4,6 +4,7 @@
>   */
>  
>  #include <linux/clk.h>
> +#include <linux/delay.h>
>  #include <linux/io.h>
>  #include <linux/module.h>
>  #include <linux/of_device.h>
> @@ -255,6 +256,13 @@ static int tegra_ehci_hub_control(struct ci_hdrc *ci, u16 typeReq, u16 wValue,
>  
>  static void tegra_usb_enter_lpm(struct ci_hdrc *ci, bool enable)
>  {
> +	/*
> +	 * Give hardware time to settle down after VBUS disconnection,
> +	 * otherwise PHY may wake up from suspend immediately.
> +	 */
> +	if (enable)
> +		msleep(25);
> +
>  	/*
>  	 * Touching any register which belongs to AHB clock domain will
>  	 * hang CPU if USB controller is put into low power mode because
> 

I missed that Peter's email address changed. Making this reply to the
new address for visibility.
Peter Chen June 12, 2021, 7:34 a.m. UTC | #2
On 21-06-09 15:04:04, Dmitry Osipenko wrote:
> The ChipIdea driver enters into suspend immediately after seeing a
> VBUS disconnection. Some devices need an extra delay after losing
> VBUS, otherwise VBUS may be floating, preventing the PHY's suspending
> by the VBUS detection sensors. This problem was found on Tegra30 Asus
> Transformer TF700T tablet device, where the USB PHY wakes up immediately
> from suspend because VBUS sensor continues to detect VBUS as active after
> disconnection. A minimum delay of 20ms is needed in order to fix this
> issue, hence add 25ms delay before suspending the PHY.
> 
> Reported-by: Maxim Schwalm <maxim.schwalm@gmail.com> # Asus TF700T
> Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> # Asus TF700T
> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
> ---
>  drivers/usb/chipidea/ci_hdrc_tegra.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_tegra.c b/drivers/usb/chipidea/ci_hdrc_tegra.c
> index 60361141ac04..d1359b76a0e8 100644
> --- a/drivers/usb/chipidea/ci_hdrc_tegra.c
> +++ b/drivers/usb/chipidea/ci_hdrc_tegra.c
> @@ -4,6 +4,7 @@
>   */
>  
>  #include <linux/clk.h>
> +#include <linux/delay.h>
>  #include <linux/io.h>
>  #include <linux/module.h>
>  #include <linux/of_device.h>
> @@ -255,6 +256,13 @@ static int tegra_ehci_hub_control(struct ci_hdrc *ci, u16 typeReq, u16 wValue,
>  
>  static void tegra_usb_enter_lpm(struct ci_hdrc *ci, bool enable)
>  {
> +	/*
> +	 * Give hardware time to settle down after VBUS disconnection,
> +	 * otherwise PHY may wake up from suspend immediately.
> +	 */
> +	if (enable)
> +		msleep(25);
> +

How could you know 25ms is enough for other Tegra designs?
Could you poll VBUS wakeup threshold register to ensure the
wakeup will not occur? The similar design exists at function:
hw_wait_vbus_lower_bsv.
Dmitry Osipenko June 12, 2021, 1:55 p.m. UTC | #3
12.06.2021 10:34, Peter Chen пишет:
> On 21-06-09 15:04:04, Dmitry Osipenko wrote:
>> The ChipIdea driver enters into suspend immediately after seeing a
>> VBUS disconnection. Some devices need an extra delay after losing
>> VBUS, otherwise VBUS may be floating, preventing the PHY's suspending
>> by the VBUS detection sensors. This problem was found on Tegra30 Asus
>> Transformer TF700T tablet device, where the USB PHY wakes up immediately
>> from suspend because VBUS sensor continues to detect VBUS as active after
>> disconnection. A minimum delay of 20ms is needed in order to fix this
>> issue, hence add 25ms delay before suspending the PHY.
>>
>> Reported-by: Maxim Schwalm <maxim.schwalm@gmail.com> # Asus TF700T
>> Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> # Asus TF700T
>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>> ---
>>  drivers/usb/chipidea/ci_hdrc_tegra.c | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/usb/chipidea/ci_hdrc_tegra.c b/drivers/usb/chipidea/ci_hdrc_tegra.c
>> index 60361141ac04..d1359b76a0e8 100644
>> --- a/drivers/usb/chipidea/ci_hdrc_tegra.c
>> +++ b/drivers/usb/chipidea/ci_hdrc_tegra.c
>> @@ -4,6 +4,7 @@
>>   */
>>  
>>  #include <linux/clk.h>
>> +#include <linux/delay.h>
>>  #include <linux/io.h>
>>  #include <linux/module.h>
>>  #include <linux/of_device.h>
>> @@ -255,6 +256,13 @@ static int tegra_ehci_hub_control(struct ci_hdrc *ci, u16 typeReq, u16 wValue,
>>  
>>  static void tegra_usb_enter_lpm(struct ci_hdrc *ci, bool enable)
>>  {
>> +	/*
>> +	 * Give hardware time to settle down after VBUS disconnection,
>> +	 * otherwise PHY may wake up from suspend immediately.
>> +	 */
>> +	if (enable)
>> +		msleep(25);
>> +
> 
> How could you know 25ms is enough for other Tegra designs?

I don't know what is the maximum timeout could be, but it shouldn't be a
problem to bump the timeout if somebody will report the need to do so.

> Could you poll VBUS wakeup threshold register to ensure the
> wakeup will not occur?

We indeed can poll the wakeup threshold status in the PHY driver, it
works too. I'll make the patch for the PHY driver, thank you for the
suggestion.

> The similar design exists at function:
> hw_wait_vbus_lower_bsv.

The hw_wait_vbus_lower_bsv uses 5sec timeout, which should be too much.
I'll set the polling timeout to 100ms.
diff mbox series

Patch

diff --git a/drivers/usb/chipidea/ci_hdrc_tegra.c b/drivers/usb/chipidea/ci_hdrc_tegra.c
index 60361141ac04..d1359b76a0e8 100644
--- a/drivers/usb/chipidea/ci_hdrc_tegra.c
+++ b/drivers/usb/chipidea/ci_hdrc_tegra.c
@@ -4,6 +4,7 @@ 
  */
 
 #include <linux/clk.h>
+#include <linux/delay.h>
 #include <linux/io.h>
 #include <linux/module.h>
 #include <linux/of_device.h>
@@ -255,6 +256,13 @@  static int tegra_ehci_hub_control(struct ci_hdrc *ci, u16 typeReq, u16 wValue,
 
 static void tegra_usb_enter_lpm(struct ci_hdrc *ci, bool enable)
 {
+	/*
+	 * Give hardware time to settle down after VBUS disconnection,
+	 * otherwise PHY may wake up from suspend immediately.
+	 */
+	if (enable)
+		msleep(25);
+
 	/*
 	 * Touching any register which belongs to AHB clock domain will
 	 * hang CPU if USB controller is put into low power mode because