diff mbox

[RESEND,3/4] usb: dwc2: assert phy reset when waking up in rk3288 platform

Message ID 1471807905-11323-1-git-send-email-ayaka@soulik.info (mailing list archive)
State New, archived
Headers show

Commit Message

ayaka Aug. 21, 2016, 7:31 p.m. UTC
On the rk3288 USB host-only port (the one that's not the OTG-enabled
port) the PHY can get into a bad state when a wakeup is asserted (not
just a wakeup from full system suspend but also a wakeup from
autosuspend).

We can get the PHY out of its bad state by asserting its "port reset",
but unfortunately that seems to assert a reset onto the USB bus so it
could confuse things if we don't actually deenumerate / reenumerate the
device.

We can also get the PHY out of its bad state by fully resetting it using
the reset from the CRU (clock reset unit) in chip, which does a more full
reset.  The CRU-based reset appears to actually cause devices on the bus
to be removed and reinserted, which fixes the problem (albeit in a hacky
way).

It's unfortunate that we need to do a full re-enumeration of devices at
wakeup time, but this is better than alternative of letting the bus get
wedged.

Signed-off-by: Randy Li <ayaka@soulik.info>
---
 drivers/usb/dwc2/core_intr.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

Comments

John Youn Aug. 23, 2016, 8:46 p.m. UTC | #1
On 8/21/2016 12:32 PM, Randy Li wrote:
> On the rk3288 USB host-only port (the one that's not the OTG-enabled
> port) the PHY can get into a bad state when a wakeup is asserted (not
> just a wakeup from full system suspend but also a wakeup from
> autosuspend).
> 
> We can get the PHY out of its bad state by asserting its "port reset",
> but unfortunately that seems to assert a reset onto the USB bus so it
> could confuse things if we don't actually deenumerate / reenumerate the
> device.
> 
> We can also get the PHY out of its bad state by fully resetting it using
> the reset from the CRU (clock reset unit) in chip, which does a more full
> reset.  The CRU-based reset appears to actually cause devices on the bus
> to be removed and reinserted, which fixes the problem (albeit in a hacky
> way).
> 
> It's unfortunate that we need to do a full re-enumeration of devices at
> wakeup time, but this is better than alternative of letting the bus get
> wedged.
> 
> Signed-off-by: Randy Li <ayaka@soulik.info>
> ---
>  drivers/usb/dwc2/core_intr.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
> index d85c5c9..f57c48a 100644
> --- a/drivers/usb/dwc2/core_intr.c
> +++ b/drivers/usb/dwc2/core_intr.c
> @@ -345,6 +345,7 @@ static void dwc2_handle_session_req_intr(struct dwc2_hsotg *hsotg)
>  static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
>  {
>  	int ret;
> +	struct device_node *np = hsotg->dev->of_node;
>  
>  	/* Clear interrupt */
>  	dwc2_writel(GINTSTS_WKUPINT, hsotg->regs + GINTSTS);
> @@ -379,6 +380,16 @@ static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
>  			/* Restart the Phy Clock */
>  			pcgcctl &= ~PCGCTL_STOPPCLK;
>  			dwc2_writel(pcgcctl, hsotg->regs + PCGCTL);
> +
> +			/* 
> +			 * It is a quirk in Rockchip RK3288, causing by
> +			 * a hardware bug. This will propagate out and
> +			 * eventually we'll re-enumerate the device. 
> +			 * Not great but the best we can do 

Remove the trailing whitespaces in this comment.

Run scripts/checkpatch.pl to catch these.

> +			 */
> +			if (of_device_is_compatible(np, "rockchip,rk3288-usb"))
> +				hsotg->phy->ops->reset(hsotg->phy);
> +

You should probably check for NULL before calling the reset()
callback.

Also, I'd rather see a generic quirk property that you set for your
platform.

Something like "phy_reset_on_wakeup_quirk".

Also, try to preserve the version tag in your subject for all the
patches so that we can easily identify the latest version of the
series, like:

[PATCH v5 3/4] ...

And, typically "RESEND" means there are no code change.

Regards,
John
Randy Li Aug. 24, 2016, 8:54 a.m. UTC | #2
On 08/24/2016 04:46 AM, John Youn wrote:
> On 8/21/2016 12:32 PM, Randy Li wrote:
>> On the rk3288 USB host-only port (the one that's not the OTG-enabled
>> port) the PHY can get into a bad state when a wakeup is asserted (not
>> just a wakeup from full system suspend but also a wakeup from
>> autosuspend).
>>
>> We can get the PHY out of its bad state by asserting its "port reset",
>> but unfortunately that seems to assert a reset onto the USB bus so it
>> could confuse things if we don't actually deenumerate / reenumerate the
>> device.
>>
>> We can also get the PHY out of its bad state by fully resetting it using
>> the reset from the CRU (clock reset unit) in chip, which does a more full
>> reset.  The CRU-based reset appears to actually cause devices on the bus
>> to be removed and reinserted, which fixes the problem (albeit in a hacky
>> way).
>>
>> It's unfortunate that we need to do a full re-enumeration of devices at
>> wakeup time, but this is better than alternative of letting the bus get
>> wedged.
>>
>> Signed-off-by: Randy Li <ayaka@soulik.info>
>> ---
>>  drivers/usb/dwc2/core_intr.c | 11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
>> index d85c5c9..f57c48a 100644
>> --- a/drivers/usb/dwc2/core_intr.c
>> +++ b/drivers/usb/dwc2/core_intr.c
>> @@ -345,6 +345,7 @@ static void dwc2_handle_session_req_intr(struct dwc2_hsotg *hsotg)
>>  static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
>>  {
>>  	int ret;
>> +	struct device_node *np = hsotg->dev->of_node;
>>
>>  	/* Clear interrupt */
>>  	dwc2_writel(GINTSTS_WKUPINT, hsotg->regs + GINTSTS);
>> @@ -379,6 +380,16 @@ static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
>>  			/* Restart the Phy Clock */
>>  			pcgcctl &= ~PCGCTL_STOPPCLK;
>>  			dwc2_writel(pcgcctl, hsotg->regs + PCGCTL);
>> +
>> +			/*
>> +			 * It is a quirk in Rockchip RK3288, causing by
>> +			 * a hardware bug. This will propagate out and
>> +			 * eventually we'll re-enumerate the device.
>> +			 * Not great but the best we can do
>
> Remove the trailing whitespaces in this comment.
>
> Run scripts/checkpatch.pl to catch these.
I see.
>
>> +			 */
>> +			if (of_device_is_compatible(np, "rockchip,rk3288-usb"))
>> +				hsotg->phy->ops->reset(hsotg->phy);
>> +
>
> You should probably check for NULL before calling the reset()
> callback.
Sure.
>
> Also, I'd rather see a generic quirk property that you set for your
> platform.
>
> Something like "phy_reset_on_wakeup_quirk".
But Rob Herring want me to implied by the SoC specific compatible 
string. I agree with him. It is certainly bug in RK3288 platform.
It is no found no the other platform.
>
> Also, try to preserve the version tag in your subject for all the
> patches so that we can easily identify the latest version of the
> series, like:
>
> [PATCH v5 3/4] ...
>
> And, typically "RESEND" means there are no code change.
I see, I just make up my mind whether code style is new version
before. I won't again.

Thank you very much.
>
> Regards,
> John
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
John Youn Aug. 25, 2016, 6:23 p.m. UTC | #3
On 8/24/2016 1:54 AM, Randy Li wrote:
> 
> 
> On 08/24/2016 04:46 AM, John Youn wrote:
>> On 8/21/2016 12:32 PM, Randy Li wrote:
>>> On the rk3288 USB host-only port (the one that's not the OTG-enabled
>>> port) the PHY can get into a bad state when a wakeup is asserted (not
>>> just a wakeup from full system suspend but also a wakeup from
>>> autosuspend).
>>>
>>> We can get the PHY out of its bad state by asserting its "port reset",
>>> but unfortunately that seems to assert a reset onto the USB bus so it
>>> could confuse things if we don't actually deenumerate / reenumerate the
>>> device.
>>>
>>> We can also get the PHY out of its bad state by fully resetting it using
>>> the reset from the CRU (clock reset unit) in chip, which does a more full
>>> reset.  The CRU-based reset appears to actually cause devices on the bus
>>> to be removed and reinserted, which fixes the problem (albeit in a hacky
>>> way).
>>>
>>> It's unfortunate that we need to do a full re-enumeration of devices at
>>> wakeup time, but this is better than alternative of letting the bus get
>>> wedged.
>>>
>>> Signed-off-by: Randy Li <ayaka@soulik.info>
>>> ---
>>>  drivers/usb/dwc2/core_intr.c | 11 +++++++++++
>>>  1 file changed, 11 insertions(+)
>>>
>>> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
>>> index d85c5c9..f57c48a 100644
>>> --- a/drivers/usb/dwc2/core_intr.c
>>> +++ b/drivers/usb/dwc2/core_intr.c
>>> @@ -345,6 +345,7 @@ static void dwc2_handle_session_req_intr(struct dwc2_hsotg *hsotg)
>>>  static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
>>>  {
>>>  	int ret;
>>> +	struct device_node *np = hsotg->dev->of_node;
>>>
>>>  	/* Clear interrupt */
>>>  	dwc2_writel(GINTSTS_WKUPINT, hsotg->regs + GINTSTS);
>>> @@ -379,6 +380,16 @@ static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
>>>  			/* Restart the Phy Clock */
>>>  			pcgcctl &= ~PCGCTL_STOPPCLK;
>>>  			dwc2_writel(pcgcctl, hsotg->regs + PCGCTL);
>>> +
>>> +			/*
>>> +			 * It is a quirk in Rockchip RK3288, causing by
>>> +			 * a hardware bug. This will propagate out and
>>> +			 * eventually we'll re-enumerate the device.
>>> +			 * Not great but the best we can do
>>
>> Remove the trailing whitespaces in this comment.
>>
>> Run scripts/checkpatch.pl to catch these.
> I see.
>>
>>> +			 */
>>> +			if (of_device_is_compatible(np, "rockchip,rk3288-usb"))
>>> +				hsotg->phy->ops->reset(hsotg->phy);
>>> +
>>
>> You should probably check for NULL before calling the reset()
>> callback.
> Sure.
>>
>> Also, I'd rather see a generic quirk property that you set for your
>> platform.
>>
>> Something like "phy_reset_on_wakeup_quirk".
> But Rob Herring want me to implied by the SoC specific compatible 
> string. I agree with him. It is certainly bug in RK3288 platform.
> It is no found no the other platform.

Ok, I missed that before.

Based on the drivers I'm familiar with (like dwc3), you would typically add a
"quirk" anyways.

Felipe,

Do you have some policy or preference on this?

Regards,
John
Felipe Balbi Aug. 29, 2016, 7:51 a.m. UTC | #4
Hi,

John Youn <John.Youn@synopsys.com> writes:

[...]

>>>> +			 */
>>>> +			if (of_device_is_compatible(np, "rockchip,rk3288-usb"))
>>>> +				hsotg->phy->ops->reset(hsotg->phy);
>>>> +
>>>
>>> You should probably check for NULL before calling the reset()
>>> callback.
>> Sure.
>>>
>>> Also, I'd rather see a generic quirk property that you set for your
>>> platform.
>>>
>>> Something like "phy_reset_on_wakeup_quirk".
>> But Rob Herring want me to implied by the SoC specific compatible 
>> string. I agree with him. It is certainly bug in RK3288 platform.
>> It is no found no the other platform.
>
> Ok, I missed that before.
>
> Based on the drivers I'm familiar with (like dwc3), you would
> typically add a "quirk" anyways.
>
> Felipe,
>
> Do you have some policy or preference on this?

if it's not a dwc2-generic feature, then let's do it via compatible
flag, sure. What we don't want is for things like:

if (is_compatible('synopsys') || is_compatible('rockchip') ||
	is_compatible('foobar') ... )

For that, we'd be better of adding a generic quirk flag which several
can use.
John Youn Aug. 29, 2016, 6:24 p.m. UTC | #5
On 8/29/2016 12:51 AM, Felipe Balbi wrote:
> 
> Hi,
> 
> John Youn <John.Youn@synopsys.com> writes:
> 
> [...]
> 
>>>>> +			 */
>>>>> +			if (of_device_is_compatible(np, "rockchip,rk3288-usb"))
>>>>> +				hsotg->phy->ops->reset(hsotg->phy);
>>>>> +
>>>>
>>>> You should probably check for NULL before calling the reset()
>>>> callback.
>>> Sure.
>>>>
>>>> Also, I'd rather see a generic quirk property that you set for your
>>>> platform.
>>>>
>>>> Something like "phy_reset_on_wakeup_quirk".
>>> But Rob Herring want me to implied by the SoC specific compatible 
>>> string. I agree with him. It is certainly bug in RK3288 platform.
>>> It is no found no the other platform.
>>
>> Ok, I missed that before.
>>
>> Based on the drivers I'm familiar with (like dwc3), you would
>> typically add a "quirk" anyways.
>>
>> Felipe,
>>
>> Do you have some policy or preference on this?
> 
> if it's not a dwc2-generic feature, then let's do it via compatible
> flag, sure. What we don't want is for things like:
> 
> if (is_compatible('synopsys') || is_compatible('rockchip') ||
> 	is_compatible('foobar') ... )
> 
> For that, we'd be better of adding a generic quirk flag which several
> can use.
> 

Alright sounds reasonable.

Randy, could you respin with the other feedback? There's no need to
add a quirk.

Regards,
John
diff mbox

Patch

diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
index d85c5c9..f57c48a 100644
--- a/drivers/usb/dwc2/core_intr.c
+++ b/drivers/usb/dwc2/core_intr.c
@@ -345,6 +345,7 @@  static void dwc2_handle_session_req_intr(struct dwc2_hsotg *hsotg)
 static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
 {
 	int ret;
+	struct device_node *np = hsotg->dev->of_node;
 
 	/* Clear interrupt */
 	dwc2_writel(GINTSTS_WKUPINT, hsotg->regs + GINTSTS);
@@ -379,6 +380,16 @@  static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
 			/* Restart the Phy Clock */
 			pcgcctl &= ~PCGCTL_STOPPCLK;
 			dwc2_writel(pcgcctl, hsotg->regs + PCGCTL);
+
+			/* 
+			 * It is a quirk in Rockchip RK3288, causing by
+			 * a hardware bug. This will propagate out and
+			 * eventually we'll re-enumerate the device. 
+			 * Not great but the best we can do 
+			 */
+			if (of_device_is_compatible(np, "rockchip,rk3288-usb"))
+				hsotg->phy->ops->reset(hsotg->phy);
+
 			mod_timer(&hsotg->wkp_timer,
 				  jiffies + msecs_to_jiffies(71));
 		} else {