| Message ID | 20170124134809.23315-1-richard.genoud@gmail.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Richard, 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 Best Regards -Anand > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jan 25, 2017 at 7:51 AM, Anand Moon <linux.amoon@gmail.com> wrote: > Hi Richard, > > 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. 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-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@samsung.com. 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@linux.intel.com> >> Tested-by: Richard Genoud <richard.genoud@gmail.com> > > Being an author implies testing. Please remove the tag. Ok >> Signed-off-by: Richard Genoud <richard.genoud@gmail.com> >> Cc: stable@vger.kernel.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@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. ;) > 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
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 25/01/2017 15:17, Krzysztof Kozlowski 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. 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 linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2017-01-27 8:29 GMT+01:00 Richard Genoud <richard.genoud@gmail.com>: > On 25/01/2017 15:17, Krzysztof Kozlowski 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. > 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 linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Krzysztof, On Fri, Feb 10, 2017 at 6:34 AM, Krzysztof Kozlowski <krzk@kernel.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 linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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"; };
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(+) -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html