[PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

[PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

[Richard Genoud]

Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
the USB ports on odroid-XU4 don't work anymore.

Inserting an usb key (USB2.0) on the USB3.0 port result in:
[   64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than 20000 msec, port status = 0xc400fe3
[   74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to stop endpoint command.
[   74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting host.
[   74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
[   74.606276] usb 3-1: USB disconnect, device number 2
[   74.613565] usb 4-1: USB disconnect, device number 2
[   74.621208] usb usb3-port1: couldn't allocate usb_device
NB: it's not related to USB2.0 devices, I get the same result with an USB3.0 device (SATA to USB3 for instance).
NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the realtek RTL8153 chip.

If the lines:
	if (dwc->revision > DWC3_REVISION_194A)
		reg |= DWC3_GUSB3PIPECTL_SUSPHY;
are commented out, the USB3.0 start working.

For a full analyse: https://lkml.org/lkml/2017/1/18/678

Felipe suggested that suspend should be disabled temporarily while
what's wrong with DCW3 is figured out.

Tested on Odroid XU4

Suggested-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Tested-by: Richard Genoud <richard.genoud@gmail.com>
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Cc: stable@vger.kernel.org # 4.4+
Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
---
 arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
index 2faf88627a48..f62dbd9b5ad3 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
@@ -43,6 +43,15 @@
 	status = "okay";
 };
 
+&usbdrd_dwc3_0 {
+	/*
+	 * without that, usb devices are not recognized when
+	 * they are plugged.
+	 * cf: https://lkml.org/lkml/2017/1/18/678
+	 */
+	snps,dis_u3_susphy_quirk;
+};
+
 &usbdrd_dwc3_1 {
 	dr_mode = "host";
 };

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

[Krzysztof Kozlowski]

On Tue, Jan 24, 2017 at 02:48:09PM +0100, Richard Genoud wrote:
> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
> the USB ports on odroid-XU4 don't work anymore.

Hi,

Thanks for the patch. Please:
1. Use recent kernel to test it, which could be one of: mainline
   (Linus'), recent linux-next or my for-next branch. Why am I thinking
   that you did not test it on thse? Because you sent the patch to
   k.kozlowski@samsung.com. The guy disappeared four months ago and
   recent kernel has all addresses updated (including mailmap).
2. Fix the title to match subsystem (git log --oneline arch/arm/boot/dts/exynos*).


> 
> Inserting an usb key (USB2.0) on the USB3.0 port result in:
> [   64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than 20000 msec, port status = 0xc400fe3
> [   74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to stop endpoint command.
> [   74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting host.
> [   74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
> [   74.606276] usb 3-1: USB disconnect, device number 2
> [   74.613565] usb 4-1: USB disconnect, device number 2
> [   74.621208] usb usb3-port1: couldn't allocate usb_device
> NB: it's not related to USB2.0 devices, I get the same result with an USB3.0 device (SATA to USB3 for instance).
> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the realtek RTL8153 chip.

Odroid-XU3
s/realtek/Realtek/

However I do not think that Realtek matters here. The USB3 ports are
directly accessible on XU3. On XU4 on the other hand, the port USB3-0 is
connected to USB hub. I think the sentence about Realtek is then
misleading, so just mention the XU3.

> 
> If the lines:
> 	if (dwc->revision > DWC3_REVISION_194A)
> 		reg |= DWC3_GUSB3PIPECTL_SUSPHY;
> are commented out, the USB3.0 start working.

s/start/starts/

> 
> For a full analyse: https://lkml.org/lkml/2017/1/18/678

Documentation/process/submitting-patches.rst
Instead of this above (lkml.org is highly discouraged) use proper
https://lkml.kernel.org/ in "Link:" put next to other tags (look at
recent commits), however I do not find this link as necessary.  Just
describe here what is wrong and how you are going to fix it.

> 
> Felipe suggested that suspend should be disabled temporarily while
> what's wrong with DCW3 is figured out.
> 
> Tested on Odroid XU4
> 
> Suggested-by: Felipe Balbi <felipe.balbi@linux.intel.com>
> Tested-by: Richard Genoud <richard.genoud@gmail.com>

Being an author implies testing. Please remove the tag.

> Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
> Cc: stable@vger.kernel.org # 4.4+

Malformed tag - missing <>.

> Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")

No need for such long hash (2164a476205c).

I wonder about pointing the commit which introduced the issue. Usually
the fixes directly indicates how far we want the patch to be backported.
In this case this should be backported to kernel bringing XU4 DTS. The
commit which was not valid, was the commit adding DTS without this
property. 2164a476205c was innocent for XU4 because XU4 did not exist
that time.

Definitely something is wrong if Fixes tag does not match indicated
backport version.

> ---
>  arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> index 2faf88627a48..f62dbd9b5ad3 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> @@ -43,6 +43,15 @@
>  	status = "okay";
>  };
>  
> +&usbdrd_dwc3_0 {
> +	/*
> +	 * without that, usb devices are not recognized when
> +	 * they are plugged.

s/without/Without/
s/usb/USB.

> +	 * cf: https://lkml.org/lkml/2017/1/18/678

No external resources. You can extend a little bit the sentence above to
two sentences. Combined with "git log" this would be sufficient.

Best regards,
Krzysztof

> +	 */
> +	snps,dis_u3_susphy_quirk;
> +};
> +
>  &usbdrd_dwc3_1 {
>  	dr_mode = "host";
>  };
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

[Richard Genoud]

On 24/01/2017 19:22, Krzysztof Kozlowski wrote:
> On Tue, Jan 24, 2017 at 02:48:09PM +0100, Richard Genoud wrote:
>> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
>> the USB ports on odroid-XU4 don't work anymore.
> 
> Hi,
> 
> Thanks for the patch. Please:
> 1. Use recent kernel to test it, which could be one of: mainline
>    (Linus'), recent linux-next or my for-next branch. Why am I thinking
>    that you did not test it on thse? Because you sent the patch to
>    k.kozlowski-Sze3O3UU22LowKkBSvOlow@public.gmane.org The guy disappeared four months ago and
>    recent kernel has all addresses updated (including mailmap).
My bad, I took the email from the commit 6658356014cb ("ARM: dts: Add
support Odroid XU4 board for exynos5422-odroidxu4") instead of taking it
from get_maintainer (That was clearly a bad idea).
I actually ran my tests on 4.4.44 / 4.8.5 / 4.9.5 4.10-rc4
I'll also run them on -next

> 2. Fix the title to match subsystem (git log --oneline arch/arm/boot/dts/exynos*).
Ok

> 
>>
>> Inserting an usb key (USB2.0) on the USB3.0 port result in:
>> [   64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than 20000 msec, port status = 0xc400fe3
>> [   74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to stop endpoint command.
>> [   74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting host.
>> [   74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
>> [   74.606276] usb 3-1: USB disconnect, device number 2
>> [   74.613565] usb 4-1: USB disconnect, device number 2
>> [   74.621208] usb usb3-port1: couldn't allocate usb_device
>> NB: it's not related to USB2.0 devices, I get the same result with an USB3.0 device (SATA to USB3 for instance).
>> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the realtek RTL8153 chip.
> 
> Odroid-XU3
> s/realtek/Realtek/
> However I do not think that Realtek matters here. The USB3 ports are
> directly accessible on XU3. On XU4 on the other hand, the port USB3-0 is
> connected to USB hub. I think the sentence about Realtek is then
> misleading, so just mention the XU3.
Ok

> 
>>
>> If the lines:
>> 	if (dwc->revision > DWC3_REVISION_194A)
>> 		reg |= DWC3_GUSB3PIPECTL_SUSPHY;
>> are commented out, the USB3.0 start working.
> 
> s/start/starts/
Ok

>>
>> For a full analyse: https://lkml.org/lkml/2017/1/18/678
> 
> Documentation/process/submitting-patches.rst
> Instead of this above (lkml.org is highly discouraged) use proper
> https://lkml.kernel.org/ in "Link:" put next to other tags (look at
> recent commits), however I do not find this link as necessary.  Just
> describe here what is wrong and how you are going to fix it.
Ok

>>
>> Felipe suggested that suspend should be disabled temporarily while
>> what's wrong with DCW3 is figured out.
>>
>> Tested on Odroid XU4
>>
>> Suggested-by: Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> Tested-by: Richard Genoud <richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 
> Being an author implies testing. Please remove the tag.
Ok

>> Signed-off-by: Richard Genoud <richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org # 4.4+
> 
> Malformed tag - missing <>.
Ok

>> Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
> 
> No need for such long hash (2164a405762c).
> 
> I wonder about pointing the commit which introduced the issue. Usually
> the fixes directly indicates how far we want the patch to be backported.
> In this case this should be backported to kernel bringing XU4 DTS. The
> commit which was not valid, was the commit adding DTS without this
> property. 2164a476205c was innocent for XU4 because XU4 did not exist
> that time.
> 
> Definitely something is wrong if Fixes tag does not match indicated
> backport version.

Yes, I see what you mean. We can't say that 2164a476205ccc ("usb: dwc3:
set SUSPHY bit for all cores") broke XU4 because it predates it !
I'll simply remove that.

>> ---
>>  arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +++++++++
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> index 2faf88627a48..f62dbd9b5ad3 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> @@ -43,6 +43,15 @@
>>  	status = "okay";
>>  };
>>  
>> +&usbdrd_dwc3_0 {
>> +	/*
>> +	 * without that, usb devices are not recognized when
>> +	 * they are plugged.
> 
> s/without/Without/
> s/usb/USB.
> 
>> +	 * cf: https://lkml.org/lkml/2017/1/18/678
> 
> No external resources. You can extend a little bit the sentence above to
> two sentences. Combined with "git log" this would be sufficient.

Ok
> Best regards,
> Krzysztof

Thanks !

>> +	 */
>> +	snps,dis_u3_susphy_quirk;
>> +};
>> +
>>  &usbdrd_dwc3_1 {
>>  	dr_mode = "host";
>>  };
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

[Anand Moon]

Hi Richard,

On 24 January 2017 at 19:18, Richard Genoud <richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
> the USB ports on odroid-XU4 don't work anymore.
>
> Inserting an usb key (USB2.0) on the USB3.0 port result in:
> [   64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than 20000 msec, port status = 0xc400fe3
> [   74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to stop endpoint command.
> [   74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting host.
> [   74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
> [   74.606276] usb 3-1: USB disconnect, device number 2
> [   74.613565] usb 4-1: USB disconnect, device number 2
> [   74.621208] usb usb3-port1: couldn't allocate usb_device
> NB: it's not related to USB2.0 devices, I get the same result with an USB3.0 device (SATA to USB3 for instance).
> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the realtek RTL8153 chip.
>
> If the lines:
>         if (dwc->revision > DWC3_REVISION_194A)
>                 reg |= DWC3_GUSB3PIPECTL_SUSPHY;
> are commented out, the USB3.0 start working.
>
> For a full analyse: https://lkml.org/lkml/2017/1/18/678
>
> Felipe suggested that suspend should be disabled temporarily while
> what's wrong with DCW3 is figured out.
>
> Tested on Odroid XU4
>
> Suggested-by: Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Tested-by: Richard Genoud <richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Richard Genoud <richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org # 4.4+
> Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
> ---
>  arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> index 2faf88627a48..f62dbd9b5ad3 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> @@ -43,6 +43,15 @@
>         status = "okay";
>  };
>
> +&usbdrd_dwc3_0 {
> +       /*
> +        * without that, usb devices are not recognized when
> +        * they are plugged.
> +        * cf: https://lkml.org/lkml/2017/1/18/678
> +        */
> +       snps,dis_u3_susphy_quirk;
> +};
> +
>  &usbdrd_dwc3_1 {
>         dr_mode = "host";
>  };
> --

Thanks for this patch.
But could you consider moving this changes as below.

https://lkml.org/lkml/2015/3/18/400

Best Regards
-Anand

> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

[Krzysztof Kozlowski]

On Wed, Jan 25, 2017 at 7:51 AM, Anand Moon <linux.amoon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi Richard,
>
> On 24 January 2017 at 19:18, Richard Genoud <richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
>> the USB ports on odroid-XU4 don't work anymore.
>>
>> Inserting an usb key (USB2.0) on the USB3.0 port result in:
>> [   64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than 20000 msec, port status = 0xc400fe3
>> [   74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to stop endpoint command.
>> [   74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting host.
>> [   74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
>> [   74.606276] usb 3-1: USB disconnect, device number 2
>> [   74.613565] usb 4-1: USB disconnect, device number 2
>> [   74.621208] usb usb3-port1: couldn't allocate usb_device
>> NB: it's not related to USB2.0 devices, I get the same result with an USB3.0 device (SATA to USB3 for instance).
>> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the realtek RTL8153 chip.
>>
>> If the lines:
>>         if (dwc->revision > DWC3_REVISION_194A)
>>                 reg |= DWC3_GUSB3PIPECTL_SUSPHY;
>> are commented out, the USB3.0 start working.
>>
>> For a full analyse: https://lkml.org/lkml/2017/1/18/678
>>
>> Felipe suggested that suspend should be disabled temporarily while
>> what's wrong with DCW3 is figured out.
>>
>> Tested on Odroid XU4
>>
>> Suggested-by: Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> Tested-by: Richard Genoud <richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Signed-off-by: Richard Genoud <richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org # 4.4+
>> Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
>> ---
>>  arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +++++++++
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> index 2faf88627a48..f62dbd9b5ad3 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> @@ -43,6 +43,15 @@
>>         status = "okay";
>>  };
>>
>> +&usbdrd_dwc3_0 {
>> +       /*
>> +        * without that, usb devices are not recognized when
>> +        * they are plugged.
>> +        * cf: https://lkml.org/lkml/2017/1/18/678
>> +        */
>> +       snps,dis_u3_susphy_quirk;
>> +};
>> +
>>  &usbdrd_dwc3_1 {
>>         dr_mode = "host";
>>  };
>> --
>
> Thanks for this patch.
> But could you consider moving this changes as below.
>
> https://lkml.org/lkml/2015/3/18/400

The patch above (and other DTS patches from the set) was not even sent
to linux-samsung-soc nor to me... It is sad how easily one's work can
disappear. Also, it is really worthless to solve the same problem
twice.

Cc Marek and Bartlomiej,
Guys, do you want to continue with Robert's patch (linked above by
Anand)? If yes, please take the ownership (Robert's address is not
valid anymore). If not, I will take Richard's patch after
resubmission.

Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

[Marek Szyprowski]

Hi Krzysztof,

On 2017-01-25 08:55, Krzysztof Kozlowski wrote:
> On Wed, Jan 25, 2017 at 7:51 AM, Anand Moon <linux.amoon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On 24 January 2017 at 19:18, Richard Genoud <richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
>>> the USB ports on odroid-XU4 don't work anymore.
>>>
>>> Inserting an usb key (USB2.0) on the USB3.0 port result in:
>>> [   64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than 20000 msec, port status = 0xc400fe3
>>> [   74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to stop endpoint command.
>>> [   74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting host.
>>> [   74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
>>> [   74.606276] usb 3-1: USB disconnect, device number 2
>>> [   74.613565] usb 4-1: USB disconnect, device number 2
>>> [   74.621208] usb usb3-port1: couldn't allocate usb_device
>>> NB: it's not related to USB2.0 devices, I get the same result with an USB3.0 device (SATA to USB3 for instance).
>>> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the realtek RTL8153 chip.
>>>
>>> If the lines:
>>>          if (dwc->revision > DWC3_REVISION_194A)
>>>                  reg |= DWC3_GUSB3PIPECTL_SUSPHY;
>>> are commented out, the USB3.0 start working.
>>>
>>> For a full analyse: https://lkml.org/lkml/2017/1/18/678
>>>
>>> Felipe suggested that suspend should be disabled temporarily while
>>> what's wrong with DCW3 is figured out.
>>>
>>> Tested on Odroid XU4
>>>
>>> Suggested-by: Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>>> Tested-by: Richard Genoud <richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> Signed-off-by: Richard Genoud <richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org # 4.4+
>>> Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
>>> ---
>>>   arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +++++++++
>>>   1 file changed, 9 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>> index 2faf88627a48..f62dbd9b5ad3 100644
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>> @@ -43,6 +43,15 @@
>>>          status = "okay";
>>>   };
>>>
>>> +&usbdrd_dwc3_0 {
>>> +       /*
>>> +        * without that, usb devices are not recognized when
>>> +        * they are plugged.
>>> +        * cf: https://lkml.org/lkml/2017/1/18/678
>>> +        */
>>> +       snps,dis_u3_susphy_quirk;
>>> +};
>>> +
>>>   &usbdrd_dwc3_1 {
>>>          dr_mode = "host";
>>>   };
>>> --
>> Thanks for this patch.
>> But could you consider moving this changes as below.
>>
>> https://lkml.org/lkml/2015/3/18/400
> The patch above (and other DTS patches from the set) was not even sent
> to linux-samsung-soc nor to me... It is sad how easily one's work can
> disappear. Also, it is really worthless to solve the same problem
> twice.

Well, they were sent about 2 years ago... and you were also working on this
topic. ;)

> Cc Marek and Bartlomiej,
> Guys, do you want to continue with Robert's patch (linked above by
> Anand)? If yes, please take the ownership (Robert's address is not
> valid anymore). If not, I will take Richard's patch after
> resubmission.

Take Richard's patch because it has a bit more details describing why 
such quirk
is needed.

Richard: in Roberts patch there is also a quirk for USB 2.0 mode
(snps,dis_u2_susphy_quirk). Could you check if it really needed?

Maybe it would make sense to set those quirks for both DWC3 controllers, 
as this
issue with PHY suspend seems to be a Exynos specific thing.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

[Krzysztof Kozlowski]

On Wed, Jan 25, 2017 at 3:48 PM, Marek Szyprowski
<m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
> Hi Krzysztof,
>
> On 2017-01-25 08:55, Krzysztof Kozlowski wrote:
>>
>> On Wed, Jan 25, 2017 at 7:51 AM, Anand Moon <linux.amoon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>
>>> On 24 January 2017 at 19:18, Richard Genoud <richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> wrote:
>>>>
>>>> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
>>>> the USB ports on odroid-XU4 don't work anymore.
>>>>
>>>> Inserting an usb key (USB2.0) on the USB3.0 port result in:
>>>> [ 64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than
>>>> 20000 msec, port status = 0xc400fe3
>>>> [   74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to
>>>> stop endpoint command.
>>>> [   74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting
>>>> host.
>>>> [   74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
>>>> [   74.606276] usb 3-1: USB disconnect, device number 2
>>>> [   74.613565] usb 4-1: USB disconnect, device number 2
>>>> [   74.621208] usb usb3-port1: couldn't allocate usb_device
>>>> NB: it's not related to USB2.0 devices, I get the same result with an
>>>> USB3.0 device (SATA to USB3 for instance).
>>>> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the
>>>> realtek RTL8153 chip.
>>>>
>>>> If the lines:
>>>>          if (dwc->revision > DWC3_REVISION_194A)
>>>>                  reg |= DWC3_GUSB3PIPECTL_SUSPHY;
>>>> are commented out, the USB3.0 start working.
>>>>
>>>> For a full analyse: https://lkml.org/lkml/2017/1/18/678
>>>>
>>>> Felipe suggested that suspend should be disabled temporarily while
>>>> what's wrong with DCW3 is figured out.
>>>>
>>>> Tested on Odroid XU4
>>>>
>>>> Suggested-by: Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>>>> Tested-by: Richard Genoud <richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> Signed-off-by: Richard Genoud <richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org # 4.4+
>>>> Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
>>>> ---
>>>>   arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +++++++++
>>>>   1 file changed, 9 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>> b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>> index 2faf88627a48..f62dbd9b5ad3 100644
>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>> @@ -43,6 +43,15 @@
>>>>          status = "okay";
>>>>   };
>>>>
>>>> +&usbdrd_dwc3_0 {
>>>> +       /*
>>>> +        * without that, usb devices are not recognized when
>>>> +        * they are plugged.
>>>> +        * cf: https://lkml.org/lkml/2017/1/18/678
>>>> +        */
>>>> +       snps,dis_u3_susphy_quirk;
>>>> +};
>>>> +
>>>>   &usbdrd_dwc3_1 {
>>>>          dr_mode = "host";
>>>>   };
>>>> --
>>>
>>> Thanks for this patch.
>>> But could you consider moving this changes as below.
>>>
>>> https://lkml.org/lkml/2015/3/18/400
>>
>> The patch above (and other DTS patches from the set) was not even sent
>> to linux-samsung-soc nor to me... It is sad how easily one's work can
>> disappear. Also, it is really worthless to solve the same problem
>> twice.
>
>
> Well, they were sent about 2 years ago... and you were also working on this
> topic. ;)

Nope, I have never worked on this. That time I was in Korea so my
tasks were completely different. Later when I got back, I took for a
second U3 OTG which was not involving this thing.

>> Cc Marek and Bartlomiej,
>> Guys, do you want to continue with Robert's patch (linked above by
>> Anand)? If yes, please take the ownership (Robert's address is not
>> valid anymore). If not, I will take Richard's patch after
>> resubmission.
>
>
> Take Richard's patch because it has a bit more details describing why such
> quirk
> is needed.
>
> Richard: in Roberts patch there is also a quirk for USB 2.0 mode
> (snps,dis_u2_susphy_quirk). Could you check if it really needed?
>
> Maybe it would make sense to set those quirks for both DWC3 controllers, as
> this
> issue with PHY suspend seems to be a Exynos specific thing.

Okay,
Richard, please continue with your patch.

Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

[Anand Moon]

Hi Krzysztof,

On 25 January 2017 at 19:47, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Wed, Jan 25, 2017 at 3:48 PM, Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
>> Hi Krzysztof,
>>
>> On 2017-01-25 08:55, Krzysztof Kozlowski wrote:
>>>
>>> On Wed, Jan 25, 2017 at 7:51 AM, Anand Moon <linux.amoon@gmail.com> wrote:
>>>>
>>>> On 24 January 2017 at 19:18, Richard Genoud <richard.genoud@gmail.com>
>>>> wrote:
>>>>>
>>>>> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
>>>>> the USB ports on odroid-XU4 don't work anymore.
>>>>>
>>>>> Inserting an usb key (USB2.0) on the USB3.0 port result in:
>>>>> [ 64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than
>>>>> 20000 msec, port status = 0xc400fe3
>>>>> [   74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to
>>>>> stop endpoint command.
>>>>> [   74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting
>>>>> host.
>>>>> [   74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
>>>>> [   74.606276] usb 3-1: USB disconnect, device number 2
>>>>> [   74.613565] usb 4-1: USB disconnect, device number 2
>>>>> [   74.621208] usb usb3-port1: couldn't allocate usb_device
>>>>> NB: it's not related to USB2.0 devices, I get the same result with an
>>>>> USB3.0 device (SATA to USB3 for instance).
>>>>> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the
>>>>> realtek RTL8153 chip.
>>>>>
>>>>> If the lines:
>>>>>          if (dwc->revision > DWC3_REVISION_194A)
>>>>>                  reg |= DWC3_GUSB3PIPECTL_SUSPHY;
>>>>> are commented out, the USB3.0 start working.
>>>>>
>>>>> For a full analyse: https://lkml.org/lkml/2017/1/18/678
>>>>>
>>>>> Felipe suggested that suspend should be disabled temporarily while
>>>>> what's wrong with DCW3 is figured out.
>>>>>
>>>>> Tested on Odroid XU4
>>>>>
>>>>> Suggested-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>>>>> Tested-by: Richard Genoud <richard.genoud@gmail.com>
>>>>> Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
>>>>> Cc: stable@vger.kernel.org # 4.4+
>>>>> Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
>>>>> ---
>>>>>   arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +++++++++
>>>>>   1 file changed, 9 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>>> b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>>> index 2faf88627a48..f62dbd9b5ad3 100644
>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>>> @@ -43,6 +43,15 @@
>>>>>          status = "okay";
>>>>>   };
>>>>>
>>>>> +&usbdrd_dwc3_0 {
>>>>> +       /*
>>>>> +        * without that, usb devices are not recognized when
>>>>> +        * they are plugged.
>>>>> +        * cf: https://lkml.org/lkml/2017/1/18/678
>>>>> +        */
>>>>> +       snps,dis_u3_susphy_quirk;
>>>>> +};
>>>>> +
>>>>>   &usbdrd_dwc3_1 {
>>>>>          dr_mode = "host";
>>>>>   };
>>>>> --
>>>>
>>>> Thanks for this patch.
>>>> But could you consider moving this changes as below.
>>>>
>>>> https://lkml.org/lkml/2015/3/18/400
>>>
>>> The patch above (and other DTS patches from the set) was not even sent
>>> to linux-samsung-soc nor to me... It is sad how easily one's work can
>>> disappear. Also, it is really worthless to solve the same problem
>>> twice.
>>
>>
>> Well, they were sent about 2 years ago... and you were also working on this
>> topic. ;)
>
> Nope, I have never worked on this. That time I was in Korea so my
> tasks were completely different. Later when I got back, I took for a
> second U3 OTG which was not involving this thing.
>
>>> Cc Marek and Bartlomiej,
>>> Guys, do you want to continue with Robert's patch (linked above by
>>> Anand)? If yes, please take the ownership (Robert's address is not
>>> valid anymore). If not, I will take Richard's patch after
>>> resubmission.
>>
>>
>> Take Richard's patch because it has a bit more details describing why such
>> quirk
>> is needed.
>>
>> Richard: in Roberts patch there is also a quirk for USB 2.0 mode
>> (snps,dis_u2_susphy_quirk). Could you check if it really needed?
>>
>> Maybe it would make sense to set those quirks for both DWC3 controllers, as
>> this
>> issue with PHY suspend seems to be a Exynos specific thing.
>
> Okay,
> Richard, please continue with your patch.
>
> Best regards,
> Krzysztof

Their is certainly some issue with respect PHY in phy-exynos5-usbdrd
or dwc3-exynos.c

odroid@odroidxu4n:~$ lsusb -v|egrep "^Bus|MaxPower"
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    MaxPower                0mA
Bus 005 Device 002: ID 0bda:8153 Realtek Semiconductor Corp.
    MaxPower              180mA
    MaxPower              180mA
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    MaxPower                0mA
Bus 004 Device 099: ID 174c:5106 ASMedia Technology Inc. ASM1051 SATA
3Gb/s bridge
    MaxPower                0mA
Bus 004 Device 002: ID 05e3:0616 Genesys Logic, Inc. hub
    MaxPower                0mA
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    MaxPower                0mA
Bus 003 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
    MaxPower              100mA
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    MaxPower                0mA
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    MaxPower                0mA
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    MaxPower                0mA

1 When the board boot cold boot these two dwc3 controller initializes correctly.
     usbdrd_dwc3_0 ------> usb 3.0 port1
     usbdrd_dwc3_0-------> usb 3.0 port2

     usbdrd_dwc3_1 ------> usb 3.0 ethernet port

None of the usb 3.0 host port get powered via usb .
    ie these port are not mapped to phy.
what is the correct way to enable power on the ports ?

2 When we remove the usb device it dose not disconnect in correct way.
   port or phy poweroff is not happening correctly.

3 But on warm boot their is no reset of port.
   the reset of port is not happening, the power on the port remain on.

I have tried to debug the some of these issues but I was not able to
solve this complete.

do you think some similar fix is needed to power enable ports on exynos dwc3

commit 1c17675d6c733232f10afceec0bcd016ad3849f0 (usb: ehci-exynos:
Change to use phy provided by the generic phy framework)
commit 366126d5c6a5d9381a5f6a4e061ad0aba33e789e (ARM: dts: add port
sub-nodes to exynos usb host modules for exynos4)

Best Regards
-Anand

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

[Richard Genoud]

On 25/01/2017 15:17, Krzysztof Kozlowski wrote:
> On Wed, Jan 25, 2017 at 3:48 PM, Marek Szyprowski
> <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
>> Hi Krzysztof,
>>
>> On 2017-01-25 08:55, Krzysztof Kozlowski wrote:
>>>
>>> On Wed, Jan 25, 2017 at 7:51 AM, Anand Moon <linux.amoon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>
>>>> On 24 January 2017 at 19:18, Richard Genoud <richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> wrote:
>>>>>
>>>>> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
>>>>> the USB ports on odroid-XU4 don't work anymore.
>>>>>
>>>>> Inserting an usb key (USB2.0) on the USB3.0 port result in:
>>>>> [ 64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than
>>>>> 20000 msec, port status = 0xc400fe3
>>>>> [   74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to
>>>>> stop endpoint command.
>>>>> [   74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting
>>>>> host.
>>>>> [   74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
>>>>> [   74.606276] usb 3-1: USB disconnect, device number 2
>>>>> [   74.613565] usb 4-1: USB disconnect, device number 2
>>>>> [   74.621208] usb usb3-port1: couldn't allocate usb_device
>>>>> NB: it's not related to USB2.0 devices, I get the same result with an
>>>>> USB3.0 device (SATA to USB3 for instance).
>>>>> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the
>>>>> realtek RTL8153 chip.
>>>>>
>>>>> If the lines:
>>>>>          if (dwc->revision > DWC3_REVISION_194A)
>>>>>                  reg |= DWC3_GUSB3PIPECTL_SUSPHY;
>>>>> are commented out, the USB3.0 start working.
>>>>>
>>>>> For a full analyse: https://lkml.org/lkml/2017/1/18/678
>>>>>
>>>>> Felipe suggested that suspend should be disabled temporarily while
>>>>> what's wrong with DCW3 is figured out.
>>>>>
>>>>> Tested on Odroid XU4
>>>>>
>>>>> Suggested-by: Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>>>>> Tested-by: Richard Genoud <richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>>> Signed-off-by: Richard Genoud <richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>>> Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org # 4.4+
>>>>> Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
>>>>> ---
>>>>>   arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +++++++++
>>>>>   1 file changed, 9 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>>> b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>>> index 2faf88627a48..f62dbd9b5ad3 100644
>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>>> @@ -43,6 +43,15 @@
>>>>>          status = "okay";
>>>>>   };
>>>>>
>>>>> +&usbdrd_dwc3_0 {
>>>>> +       /*
>>>>> +        * without that, usb devices are not recognized when
>>>>> +        * they are plugged.
>>>>> +        * cf: https://lkml.org/lkml/2017/1/18/678
>>>>> +        */
>>>>> +       snps,dis_u3_susphy_quirk;
>>>>> +};
>>>>> +
>>>>>   &usbdrd_dwc3_1 {
>>>>>          dr_mode = "host";
>>>>>   };
>>>>> --
>>>>
>>>> Thanks for this patch.
>>>> But could you consider moving this changes as below.
>>>>
>>>> https://lkml.org/lkml/2015/3/18/400
>>>
>>> The patch above (and other DTS patches from the set) was not even sent
>>> to linux-samsung-soc nor to me... It is sad how easily one's work can
>>> disappear. Also, it is really worthless to solve the same problem
>>> twice.
>>
>>
>> Well, they were sent about 2 years ago... and you were also working on this
>> topic. ;)
> 
> Nope, I have never worked on this. That time I was in Korea so my
> tasks were completely different. Later when I got back, I took for a
> second U3 OTG which was not involving this thing.
> 
>>> Cc Marek and Bartlomiej,
>>> Guys, do you want to continue with Robert's patch (linked above by
>>> Anand)? If yes, please take the ownership (Robert's address is not
>>> valid anymore). If not, I will take Richard's patch after
>>> resubmission.
>>
>>
>> Take Richard's patch because it has a bit more details describing why such
>> quirk
>> is needed.
>>
>> Richard: in Roberts patch there is also a quirk for USB 2.0 mode
>> (snps,dis_u2_susphy_quirk). Could you check if it really needed?
>>
>> Maybe it would make sense to set those quirks for both DWC3 controllers, as
>> this
>> issue with PHY suspend seems to be a Exynos specific thing.
> 
> Okay,
> Richard, please continue with your patch.
Ok, I'll grab a XU3 & XU4 and do some more tests.
But I didn't recall having problems with the XU3 board. I'll try to add
a hub or something.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

[Richard Genoud]

2017-01-27 8:29 GMT+01:00 Richard Genoud <richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> On 25/01/2017 15:17, Krzysztof Kozlowski wrote:
>> On Wed, Jan 25, 2017 at 3:48 PM, Marek Szyprowski
>> <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
>>> Hi Krzysztof,
>>>
>>> On 2017-01-25 08:55, Krzysztof Kozlowski wrote:
>>>>
>>>> On Wed, Jan 25, 2017 at 7:51 AM, Anand Moon <linux.amoon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>>
>>>>> On 24 January 2017 at 19:18, Richard Genoud <richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>>> wrote:
>>>>>>
>>>>>> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
>>>>>> the USB ports on odroid-XU4 don't work anymore.
>>>>>>
>>>>>> Inserting an usb key (USB2.0) on the USB3.0 port result in:
>>>>>> [ 64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than
>>>>>> 20000 msec, port status = 0xc400fe3
>>>>>> [   74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to
>>>>>> stop endpoint command.
>>>>>> [   74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting
>>>>>> host.
>>>>>> [   74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
>>>>>> [   74.606276] usb 3-1: USB disconnect, device number 2
>>>>>> [   74.613565] usb 4-1: USB disconnect, device number 2
>>>>>> [   74.621208] usb usb3-port1: couldn't allocate usb_device
>>>>>> NB: it's not related to USB2.0 devices, I get the same result with an
>>>>>> USB3.0 device (SATA to USB3 for instance).
>>>>>> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the
>>>>>> realtek RTL8153 chip.
>>>>>>
>>>>>> If the lines:
>>>>>>          if (dwc->revision > DWC3_REVISION_194A)
>>>>>>                  reg |= DWC3_GUSB3PIPECTL_SUSPHY;
>>>>>> are commented out, the USB3.0 start working.
>>>>>>
>>>>>> For a full analyse: https://lkml.org/lkml/2017/1/18/678
>>>>>>
>>>>>> Felipe suggested that suspend should be disabled temporarily while
>>>>>> what's wrong with DCW3 is figured out.
>>>>>>
>>>>>> Tested on Odroid XU4
>>>>>>
>>>>>> Suggested-by: Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>>>>>> Tested-by: Richard Genoud <richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>>>> Signed-off-by: Richard Genoud <richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>>>> Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org # 4.4+
>>>>>> Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
>>>>>> ---
>>>>>>   arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +++++++++
>>>>>>   1 file changed, 9 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>>>> b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>>>> index 2faf88627a48..f62dbd9b5ad3 100644
>>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>>>> @@ -43,6 +43,15 @@
>>>>>>          status = "okay";
>>>>>>   };
>>>>>>
>>>>>> +&usbdrd_dwc3_0 {
>>>>>> +       /*
>>>>>> +        * without that, usb devices are not recognized when
>>>>>> +        * they are plugged.
>>>>>> +        * cf: https://lkml.org/lkml/2017/1/18/678
>>>>>> +        */
>>>>>> +       snps,dis_u3_susphy_quirk;
>>>>>> +};
>>>>>> +
>>>>>>   &usbdrd_dwc3_1 {
>>>>>>          dr_mode = "host";
>>>>>>   };
>>>>>> --
>>>>>
>>>>> Thanks for this patch.
>>>>> But could you consider moving this changes as below.
>>>>>
>>>>> https://lkml.org/lkml/2015/3/18/400
>>>>
>>>> The patch above (and other DTS patches from the set) was not even sent
>>>> to linux-samsung-soc nor to me... It is sad how easily one's work can
>>>> disappear. Also, it is really worthless to solve the same problem
>>>> twice.
>>>
>>>
>>> Well, they were sent about 2 years ago... and you were also working on this
>>> topic. ;)
>>
>> Nope, I have never worked on this. That time I was in Korea so my
>> tasks were completely different. Later when I got back, I took for a
>> second U3 OTG which was not involving this thing.
>>
>>>> Cc Marek and Bartlomiej,
>>>> Guys, do you want to continue with Robert's patch (linked above by
>>>> Anand)? If yes, please take the ownership (Robert's address is not
>>>> valid anymore). If not, I will take Richard's patch after
>>>> resubmission.
>>>
>>>
>>> Take Richard's patch because it has a bit more details describing why such
>>> quirk
>>> is needed.
>>>
>>> Richard: in Roberts patch there is also a quirk for USB 2.0 mode
>>> (snps,dis_u2_susphy_quirk). Could you check if it really needed?
>>>
>>> Maybe it would make sense to set those quirks for both DWC3 controllers, as
>>> this
>>> issue with PHY suspend seems to be a Exynos specific thing.
>>
>> Okay,
>> Richard, please continue with your patch.
> Ok, I'll grab a XU3 & XU4 and do some more tests.
> But I didn't recall having problems with the XU3 board. I'll try to add
> a hub or something.
>

I did some tests with XU3 and XU4, playing with USB2 and USB3 quirks
(snps,dis_u{2,3}_susphy_quirk)

kernel for the tests: next-20170206
DTBs: exynos5422-odroidxu3-lite.dtb exynos5422-odroidxu4.dtb

USB devices used for the tests: kingston USB3 key, Akasa sata/USB3
+SSD standard USB2 key
once recognized, a dd if=/dev/sda bs=1M count=100 of=/dev/null is done.


The results are:
- On XU4:
  - adding snps,dis_u2_susphy_quirk doesn't change anything:
    inserting an USB2 or USB3 device gives the error message:
    xhci-hcd xhci-hcd.2.auto: Port resume took longer than 20000 msec,
port status = 0xc400fe3
  - with snps,dis_u3_susphy_quirk, USB2 and USB3 devices are recognized

- On XU3:
  - Without changing XU3 dts, USB2 devices are recognized.
  - With or without the snps,dis_u3_susphy_quirk, USB3 devices are not
recognized/not working properly
  (never seen or disconnected, unable to enumerate, etc.)
  However, adding an external powered USB3 hub in between works. (with
or without the snps,dis_u3_susphy_quirk)
  Anyway, this problem doesn't seems to be related to the other since
  addind the quirks doesn't change anything.

- On XU3 USB3 device port (dr_mode = "peripheral"):
  - acting as an ethernet gadget only works with the snps,dis_u3_susphy_quirk.
    It works well as USB2 or USB3 (tested with ethernet gadget+iperf)

So, at the end, it does seem usefull to add the
snps,dis_u3_susphy_quirk at the exynos5420.dtsi level.
Adding the snps,dis_u2_susphy_quirk doesn't seems to change anything
for XU3/XU4 board,
so I don't know if it is necessary or not.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

[Krzysztof Kozlowski]

On Thu, Feb 09, 2017 at 11:26:48AM +0100, Richard Genoud wrote:
> I did some tests with XU3 and XU4, playing with USB2 and USB3 quirks
> (snps,dis_u{2,3}_susphy_quirk)
> 
> kernel for the tests: next-20170206
> DTBs: exynos5422-odroidxu3-lite.dtb exynos5422-odroidxu4.dtb
> 
> USB devices used for the tests: kingston USB3 key, Akasa sata/USB3
> +SSD standard USB2 key
> once recognized, a dd if=/dev/sda bs=1M count=100 of=/dev/null is done.
> 
> 
> The results are:
> - On XU4:
>   - adding snps,dis_u2_susphy_quirk doesn't change anything:
>     inserting an USB2 or USB3 device gives the error message:
>     xhci-hcd xhci-hcd.2.auto: Port resume took longer than 20000 msec,
> port status = 0xc400fe3
>   - with snps,dis_u3_susphy_quirk, USB2 and USB3 devices are recognized
> 
> - On XU3:
>   - Without changing XU3 dts, USB2 devices are recognized.
>   - With or without the snps,dis_u3_susphy_quirk, USB3 devices are not
> recognized/not working properly
>   (never seen or disconnected, unable to enumerate, etc.)
>   However, adding an external powered USB3 hub in between works. (with
> or without the snps,dis_u3_susphy_quirk)
>   Anyway, this problem doesn't seems to be related to the other since
>   addind the quirks doesn't change anything.

>From this description I am missing where are you inserting the USB
devices.

Both boards have totally different USB port configuration. On XU3 the
hub is on USB 2.0 port. On XU4 the opposite - the hub is on USB 3.0
port.

Best regards,
Krzysztof

> - On XU3 USB3 device port (dr_mode = "peripheral"):
>   - acting as an ethernet gadget only works with the snps,dis_u3_susphy_quirk.
>     It works well as USB2 or USB3 (tested with ethernet gadget+iperf)
> 
> So, at the end, it does seem usefull to add the
> snps,dis_u3_susphy_quirk at the exynos5420.dtsi level.
> Adding the snps,dis_u2_susphy_quirk doesn't seems to change anything
> for XU3/XU4 board,
> so I don't know if it is necessary or not.

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

[Richard Genoud]

2017-02-10 14:34 GMT+01:00 Krzysztof Kozlowski <krzk@kernel.org>:
> On Thu, Feb 09, 2017 at 11:26:48AM +0100, Richard Genoud wrote:
>> I did some tests with XU3 and XU4, playing with USB2 and USB3 quirks
>> (snps,dis_u{2,3}_susphy_quirk)
>>
>> kernel for the tests: next-20170206
>> DTBs: exynos5422-odroidxu3-lite.dtb exynos5422-odroidxu4.dtb
>>
>> USB devices used for the tests: kingston USB3 key, Akasa sata/USB3
>> +SSD standard USB2 key
>> once recognized, a dd if=/dev/sda bs=1M count=100 of=/dev/null is done.
>>
>>
>> The results are:
>> - On XU4:
>>   - adding snps,dis_u2_susphy_quirk doesn't change anything:
>>     inserting an USB2 or USB3 device gives the error message:
>>     xhci-hcd xhci-hcd.2.auto: Port resume took longer than 20000 msec,
>> port status = 0xc400fe3
>>   - with snps,dis_u3_susphy_quirk, USB2 and USB3 devices are recognized
>>
>> - On XU3:
>>   - Without changing XU3 dts, USB2 devices are recognized.
>>   - With or without the snps,dis_u3_susphy_quirk, USB3 devices are not
>> recognized/not working properly
>>   (never seen or disconnected, unable to enumerate, etc.)
>>   However, adding an external powered USB3 hub in between works. (with
>> or without the snps,dis_u3_susphy_quirk)
>>   Anyway, this problem doesn't seems to be related to the other since
>>   addind the quirks doesn't change anything.
>
> From this description I am missing where are you inserting the USB
> devices.
>
> Both boards have totally different USB port configuration. On XU3 the
> hub is on USB 2.0 port. On XU4 the opposite - the hub is on USB 3.0
> port.
Yes, sorry.
All the tests I did were on USB3.0 ports.
So, for the XU4, it was the double USB3.0 connector.
For the XU3, it was the single USB3.0 host port.

(and the XU3 USB3.0 device port for the test bellow)

I didn't do any test on the USB2 ports.

>
> Best regards,
> Krzysztof
>
>> - On XU3 USB3 device port (dr_mode = "peripheral"):
>>   - acting as an ethernet gadget only works with the snps,dis_u3_susphy_quirk.
>>     It works well as USB2 or USB3 (tested with ethernet gadget+iperf)
>>
>> So, at the end, it does seem usefull to add the
>> snps,dis_u3_susphy_quirk at the exynos5420.dtsi level.
>> Adding the snps,dis_u2_susphy_quirk doesn't seems to change anything
>> for XU3/XU4 board,
>> so I don't know if it is necessary or not.

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

[Shuah Khan]

Hi Krzysztof,

On Fri, Feb 10, 2017 at 6:34 AM, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Thu, Feb 09, 2017 at 11:26:48AM +0100, Richard Genoud wrote:
>> I did some tests with XU3 and XU4, playing with USB2 and USB3 quirks
>> (snps,dis_u{2,3}_susphy_quirk)
>>
>> kernel for the tests: next-20170206
>> DTBs: exynos5422-odroidxu3-lite.dtb exynos5422-odroidxu4.dtb
>>
>> USB devices used for the tests: kingston USB3 key, Akasa sata/USB3
>> +SSD standard USB2 key
>> once recognized, a dd if=/dev/sda bs=1M count=100 of=/dev/null is done.
>>
>>
>> The results are:
>> - On XU4:
>>   - adding snps,dis_u2_susphy_quirk doesn't change anything:
>>     inserting an USB2 or USB3 device gives the error message:
>>     xhci-hcd xhci-hcd.2.auto: Port resume took longer than 20000 msec,
>> port status = 0xc400fe3
>>   - with snps,dis_u3_susphy_quirk, USB2 and USB3 devices are recognized
>>
>> - On XU3:
>>   - Without changing XU3 dts, USB2 devices are recognized.
>>   - With or without the snps,dis_u3_susphy_quirk, USB3 devices are not
>> recognized/not working properly
>>   (never seen or disconnected, unable to enumerate, etc.)
>>   However, adding an external powered USB3 hub in between works. (with
>> or without the snps,dis_u3_susphy_quirk)
>>   Anyway, this problem doesn't seems to be related to the other since
>>   addind the quirks doesn't change anything.
>
> From this description I am missing where are you inserting the USB
> devices.
>
> Both boards have totally different USB port configuration. On XU3 the
> hub is on USB 2.0 port. On XU4 the opposite - the hub is on USB 3.0
> port.
>

I am running into this on XU4 USB 3.0 ports. Cold booting with device
present in USB 3.0 port, device is recognized.

Bus 004 Device 003: ID 8564:4000 Transcend Information, Inc. RDF8
    MaxPower              224mA

However, if I were to insert it after boot, it fails to resume the port.

[ 2936.560129] usb 4-1.2: USB disconnect, device number 3
[ 2959.249815] xhci-hcd xhci-hcd.2.auto: Port resume took longer than
20000 msec, port status = 0xc400fe3

and lsusb -v|egrep "^Bus|MaxPower" shows:

Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    MaxPower                0mA

Preventing suspend with this. Looking at this more, could this be
related to GCTL.RAMCLKSEL?

The commnet block below in dwc3_gadget_conndone_interrupt() seems to
indicate a potential problem on platforms when RAMClkSel is reset to 0
after USB reset. Is that the case on Odroid-xu4 that updating
GCTL.RAMCLKSEL is necessary to USB device hotplug to work without the
the quirk?

     /*
         * RAMClkSel is reset to 0 after USB reset, so it must be reprogrammed
         * each time on Connect Done.
         *
         * Currently we always use the reset value. If any platform
         * wants to set this to a different value, we need to add a
         * setting and update GCTL.RAMCLKSEL here.
         */

I can debug this more dumping GCTL.RAMCLKSEL registers in cold boot
vs. hotplig cases to get more information.

thanks,
-- Shuah
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html