Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1495221 > unrolled thread
| Started by | Vivek Gautam <vivek.gautam@codeaurora.org> |
|---|---|
| First post | 2016-10-04 08:10 +0200 |
| Last post | 2016-10-07 22:30 +0200 |
| Articles | 7 — 4 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 Vivek Gautam <vivek.gautam@codeaurora.org> - 2016-10-04 08:10 +0200
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 Vivek Gautam <vivek.gautam@codeaurora.org> - 2016-10-04 14:10 +0200
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 Anand Moon <linux.amoon@gmail.com> - 2016-10-04 17:20 +0200
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 Vivek Gautam <vivek.gautam@codeaurora.org> - 2016-10-05 06:50 +0200
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 Michael Niewöhner <linux@mniewoehner.de> - 2016-10-06 18:40 +0200
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 Felipe Balbi <balbi@kernel.org> - 2016-10-07 09:50 +0200
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 Michael Niewöhner <linux@mniewoehner.de> - 2016-10-07 22:30 +0200
| From | Vivek Gautam <vivek.gautam@codeaurora.org> |
|---|---|
| Date | 2016-10-04 08:10 +0200 |
| Subject | Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 |
| Message-ID | <sor5n-70H-7@gated-at.bofh.it> |
Hi Michael, On Tue, Aug 30, 2016 at 10:32 AM, Anand Moon <linux.amoon@gmail.com> wrote: > Hi All > > Adding Vivek Gautam. Sorry for missing out this conversation. I am no longer part of Samsung. > > On 29 August 2016 at 16:35, Michael Niewöhner <linux@mniewoehner.de> wrote: >> Hi Mathias, >> On Mo, 2016-08-29 at 13:59 +0300, Mathias Nyman wrote: >>> On 29.08.2016 10:28, Felipe Balbi wrote: >>> > >>> > >>> > Hi, >>> > >>> > Michael Niewöhner <linux@mniewoehner.de> writes: >>> > > >>> > > [1.] One line summary of the problem: >>> > > DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 >>> > > >>> > > [2.] Full description of the problem/report: >>> > > No usb 3.0 devices are being detected when attached while USB 2.0 >>> > > devices work on the same port. >>> > > USB 3.0 works after applying patches [9.1] and [9.2], but seems >>> > > to be >>> > > buggy. The usb hub is redetected every time an usb device is >>> > > attached. [snip] >>> > >>> > > >>> > > [9.] Other notes, patches, fixes, workarounds: >>> > > [9.1] https://lkml.org/lkml/2014/4/28/234 >>> > > [9.2] https://lkml.org/lkml/2015/2/2/259 These patches are required to get USB super-speed working on Exynos5420/5800. But they did not make to upstream. There was resistance on adding new phy_calibrate() callback. Without these patches the Exynos5420/5800 will enumerate all super-speed capable devices as high-speed devices. Last time we checked with exynos542x smdk boards and peach-* boards, we could get the Super - speed devices working. I have not tested odroid anytime so don't have much idea about the its intricacies. I guess Anand was able to use these patches to get his kernel working in past. When you have a downstream on-board usb hub, ideally it should be able to detect the devices and not reset everytime you connect a new device (like you mentioned earlier). There can be two possible reasons why the hub keeps getting reset ever after applying the above mentioned patches: 1) the clock rates are not proper. 2) the regulator load setting is not enough to drive the hub. Anand, can you please point Michael to an older kernel with which you could test usb on odroid successfully ? You can compare the clocks with an older version and see if there'a any difference. Any possibility of any other framework (such as, bus-freq) trimming down the clock - rates ? [snip] > > There are two dwc3 ports in the SoC : one for Gbit Ethernet another > one for on-board GL3521 USB 3.0 hub controller. > > 3.10.x kernel > odroid@odroid:~$ lsusb -t > /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M > /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M > /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=s5p-ehci/3p, 480M > > 4.x kernel > odroid@odroid:~$ lsusb -t > /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 480M > /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M > |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M > |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M > /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M [snip] Michael, please paste the output of lsusb -t and/or lsusb -v as well. Best regards Vivek -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[toc] | [next] | [standalone]
| From | Vivek Gautam <vivek.gautam@codeaurora.org> |
|---|---|
| Date | 2016-10-04 14:10 +0200 |
| Message-ID | <sowHL-2uG-15@gated-at.bofh.it> |
| In reply to | #1495221 |
Hi Michael, On Tue, Oct 4, 2016 at 4:28 PM, Michael Niewöhner <linux@mniewoehner.de> wrote: > > > > > > [1.] One line summary of the problem: > > > > > > DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 > > > > > > > > > > > > [2.] Full description of the problem/report: > > > > > > No usb 3.0 devices are being detected when attached while USB 2.0 > > > > > > devices work on the same port. > > > > > > USB 3.0 works after applying patches [9.1] and [9.2], but seems > > > > > > to be > > > > > > buggy. The usb hub is redetected every time an usb device is > > > > > > attached. [snip] >> > > > > > [9.] Other notes, patches, fixes, workarounds: >> > > > > > [9.1] https://lkml.org/lkml/2014/4/28/234 >> > > > > > [9.2] https://lkml.org/lkml/2015/2/2/259 >> >> These patches are required to get USB super-speed working on Exynos5420/5800. >> But they did not make to upstream. There was resistance on adding new >> phy_calibrate() >> callback. >> >> Without these patches the Exynos5420/5800 will enumerate all >> super-speed capable devices >> as high-speed devices. >> Last time we checked with exynos542x smdk boards and peach-* boards, >> we could get the >> Super - speed devices working. I have not tested odroid anytime so >> don't have much idea about the >> its intricacies. >> I guess Anand was able to use these patches to get his kernel working in past. > > > The patches don't work anymore with 4.8-rc* / 4.8. They worked - but very > unstable - with 4.7. > > One more problem appeared since one of the 4.8-RCs: reboot hangs when the dwc3 > module is loaded. If I unload it before reboot / shutdown everything is fine. > > >> >> When you have a downstream on-board usb hub, ideally it should be able >> to detect the devices >> and not reset everytime you connect a new device (like you mentioned earlier). >> There can be two possible reasons why the hub keeps getting reset ever >> after applying the above >> mentioned patches: >> 1) the clock rates are not proper. >> 2) the regulator load setting is not enough to drive the hub. >> >> Anand, can you please point Michael to an older kernel with which you >> could test usb on odroid successfully ? >> You can compare the clocks with an older version and see if there'a >> any difference. >> >> Any possibility of any other framework (such as, bus-freq) trimming >> down the clock - rates ? > > > ################################ > # v4.7.5 > ################################ > > $ cat /sys/kernel/debug/clk/clk_summary | grep usb > sclk_usbh20_scan_clk 0 0 480000000 0 > sclk_usbh20 0 0 48000 > 000 0 > mout_usbd300 1 1 24000000 0 > dout_usbd300 0 0 24000000 0 > sclk_usbd300 > 0 0 24000000 0 > dout_usbphy300 1 1 24000000 0 > sclk_usbphy300 4 4 24000 > 000 0 > mout_usbd301 1 1 24000000 0 > dout_usbd301 0 0 24000000 0 > sclk_usbd301 > 0 0 24000000 0 > dout_usbphy301 1 1 24000000 0 > sclk_usbphy301 3 3 24000 > 000 0 > usbd301 1 1 100000000 > usbd300 1 1 100000000 > > usbh20 3 3 100000000 0 > > ################################ > # v4.8.0 > ################################ > > $ cat /sys/kernel/debug/clk/clk_summary | grep usb > sclk_usbh20_scan_clk 0 0 480000000 0 > sclk_usbh20 0 0 48000000 > 0 > mout_usbd300 1 1 24000000 0 > dout_usbd300 0 0 24000000 0 > sclk_usbd300 > 0 0 24000000 0 > dout_usbphy300 1 1 24000000 0 > sclk_usbphy300 4 4 24000000 > 0 > mout_usbd301 1 1 24000000 0 > dout_usbd301 0 0 24000000 0 > sclk_usbd301 > 0 0 24000000 0 > dout_usbphy301 1 1 24000000 0 > sclk_usbphy301 3 3 24000000 > 0 > usbd301 1 1 100000000 This clock should have been 200MHz. > usbd300 1 1 100000000 > usbh2 > 0 3 3 100000000 0 > > $ cat /sys/kernel/debug/usb/devices > <<system hangs>> > The clocks are same across working/non-working. Is it possible to bisect the commit that's causing hang for 4.8x ? Adding few of the folks from Samsung who can test dwc3 usb on smdk/peach boards. +Alim, Pankaj Hi Alim, Pankaj, can you please give a try with 4.8 kernel on peach/smdk542x board and see if dwc3 usb works or not. You may need to the patches mentioned in [9.1] and [9.2] mentioned above. [snip] Thanks Vivek -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[toc] | [prev] | [next] | [standalone]
| From | Anand Moon <linux.amoon@gmail.com> |
|---|---|
| Date | 2016-10-04 17:20 +0200 |
| Message-ID | <sozFE-4xt-7@gated-at.bofh.it> |
| In reply to | #1495393 |
Hi Vivek,
On 4 October 2016 at 17:32, Vivek Gautam <vivek.gautam@codeaurora.org> wrote:
> Hi Michael,
>
>
> On Tue, Oct 4, 2016 at 4:28 PM, Michael Niewöhner <linux@mniewoehner.de> wrote:
>
>> > > > > > [1.] One line summary of the problem:
>> > > > > > DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
>> > > > > >
>> > > > > > [2.] Full description of the problem/report:
>> > > > > > No usb 3.0 devices are being detected when attached while USB 2.0
>> > > > > > devices work on the same port.
>> > > > > > USB 3.0 works after applying patches [9.1] and [9.2], but seems
>> > > > > > to be
>> > > > > > buggy. The usb hub is redetected every time an usb device is
>> > > > > > attached.
>
> [snip]
>
>>> > > > > > [9.] Other notes, patches, fixes, workarounds:
>>> > > > > > [9.1] https://lkml.org/lkml/2014/4/28/234
>>> > > > > > [9.2] https://lkml.org/lkml/2015/2/2/259
>>>
>>> These patches are required to get USB super-speed working on Exynos5420/5800.
>>> But they did not make to upstream. There was resistance on adding new
>>> phy_calibrate()
>>> callback.
>>>
>>> Without these patches the Exynos5420/5800 will enumerate all
>>> super-speed capable devices
>>> as high-speed devices.
>>> Last time we checked with exynos542x smdk boards and peach-* boards,
>>> we could get the
>>> Super - speed devices working. I have not tested odroid anytime so
>>> don't have much idea about the
>>> its intricacies.
>>> I guess Anand was able to use these patches to get his kernel working in past.
>>
>>
>> The patches don't work anymore with 4.8-rc* / 4.8. They worked - but very
>> unstable - with 4.7.
>>
>> One more problem appeared since one of the 4.8-RCs: reboot hangs when the dwc3
>> module is loaded. If I unload it before reboot / shutdown everything is fine.
>>
>>
>>>
>>> When you have a downstream on-board usb hub, ideally it should be able
>>> to detect the devices
>>> and not reset everytime you connect a new device (like you mentioned earlier).
>>> There can be two possible reasons why the hub keeps getting reset ever
>>> after applying the above
>>> mentioned patches:
>>> 1) the clock rates are not proper.
>>> 2) the regulator load setting is not enough to drive the hub.
>>>
>>> Anand, can you please point Michael to an older kernel with which you
>>> could test usb on odroid successfully ?
>>> You can compare the clocks with an older version and see if there'a
>>> any difference.
>>>
>>> Any possibility of any other framework (such as, bus-freq) trimming
>>> down the clock - rates ?
>>
>>
>> ################################
>> # v4.7.5
>> ################################
>>
>> $ cat /sys/kernel/debug/clk/clk_summary | grep usb
>> sclk_usbh20_scan_clk 0 0 480000000 0
>> sclk_usbh20 0 0 48000
>> 000 0
>> mout_usbd300 1 1 24000000 0
>> dout_usbd300 0 0 24000000 0
>> sclk_usbd300
>> 0 0 24000000 0
>> dout_usbphy300 1 1 24000000 0
>> sclk_usbphy300 4 4 24000
>> 000 0
>> mout_usbd301 1 1 24000000 0
>> dout_usbd301 0 0 24000000 0
>> sclk_usbd301
>> 0 0 24000000 0
>> dout_usbphy301 1 1 24000000 0
>> sclk_usbphy301 3 3 24000
>> 000 0
>> usbd301 1 1 100000000
>> usbd300 1 1 100000000
>>
>> usbh20 3 3 100000000 0
>
>>
>> ################################
>> # v4.8.0
>> ################################
>>
>> $ cat /sys/kernel/debug/clk/clk_summary | grep usb
>> sclk_usbh20_scan_clk 0 0 480000000 0
>> sclk_usbh20 0 0 48000000
>> 0
>> mout_usbd300 1 1 24000000 0
>> dout_usbd300 0 0 24000000 0
>> sclk_usbd300
>> 0 0 24000000 0
>> dout_usbphy300 1 1 24000000 0
>> sclk_usbphy300 4 4 24000000
>> 0
>> mout_usbd301 1 1 24000000 0
>> dout_usbd301 0 0 24000000 0
>> sclk_usbd301
>> 0 0 24000000 0
>> dout_usbphy301 1 1 24000000 0
>> sclk_usbphy301 3 3 24000000
>> 0
>> usbd301 1 1 100000000
>
> This clock should have been 200MHz.
>
>> usbd300 1 1 100000000
>> usbh2
>> 0 3 3 100000000 0
>>
>> $ cat /sys/kernel/debug/usb/devices
>> <<system hangs>>
>>
>
> The clocks are same across working/non-working.
> Is it possible to bisect the commit that's causing hang for 4.8x ?
>
> Adding few of the folks from Samsung who can test dwc3 usb on smdk/peach boards.
> +Alim, Pankaj
>
> Hi Alim, Pankaj,
> can you please give a try with 4.8 kernel on peach/smdk542x board and
> see if dwc3 usb works or not.
> You may need to the patches mentioned in [9.1] and [9.2] mentioned above.
>
>
[9.1] https://lkml.org/lkml/2014/4/28/234 base: platform: name the
device already during allocation
Dose not help. it's not useful at all.
What I feel is that their need to be some reset of usb phy so that
device are assigned to respective bus ports.
odroid@odroid:~$ lsusb -t
/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=r8152, 480M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M
|__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
|__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M
|__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
Bus 06.Port should register the Realtek Ethernet r8153 device.
But I am not able to trace out how it's should happen.
-Best Regards
Anand Moon
> [snip]
>
>
> Thanks
> Vivek
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
[toc] | [prev] | [next] | [standalone]
| From | Vivek Gautam <vivek.gautam@codeaurora.org> |
|---|---|
| Date | 2016-10-05 06:50 +0200 |
| Message-ID | <soMjv-4ib-5@gated-at.bofh.it> |
| In reply to | #1495473 |
Hi Anand,
On Tue, Oct 4, 2016 at 8:39 PM, Anand Moon <linux.amoon@gmail.com> wrote:
> Hi Vivek,
>
[snip]
>
> What I feel is that their need to be some reset of usb phy so that
> device are assigned to respective bus ports.
The phy resets are what we do in the phy-exynos5-usbdrd driver. In
addition to what we
have currently in this phy driver, we just need the phy calibration
patch [1] for phy configurations.
[1] https://lkml.org/lkml/2015/2/2/259
> odroid@odroid:~$ lsusb -t
> /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
> /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
> |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=r8152, 480M
This shows the ethernet device gets detected on the high-speed port of one
of the controller.
The lsusb output for kernel v4.7.x posted by Michael show that the
ethernet device got detected on super-speed port of the controller.
So, there seems to be a difference between the two.
Or, is this how it is behaving ?
Is this lsusb output on 4.8 kernel with the patch [1] ?
> /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M
> |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
> |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
> /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M
> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M
> |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
>
>
> Bus 06.Port should register the Realtek Ethernet r8153 device.
> But I am not able to trace out how it's should happen.
If i understand, below is how the configuration looks like on the board?
+-----------------------+
+------>| |
| | Bus 6 |-------+
+-----------+ | (super-speed) | |
| | +-----------------------+ |
|Controller | | --------> Ethernet device
| 2 | |
| | +-----------------------+ |
+-----------+ | | |
| | Bus 5 |-------+
+------>| (high-speed) |
+-----------------------+
+-----------------------+
+------>| |
| | Bus 4 |-------+
+-----------+ | (super-speed) | |
| | +-----------------------+ |
|Controller | | --------> (On board
hub ?? _OR_ external hub with downstream devices) ???
| 1 | |
| | +-----------------------+ |
+-----------+ | | |
| | Bus 3 |-------+
+------>| (high-speed) |
+-----------------------+
Thanks
Vivek
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
[toc] | [prev] | [next] | [standalone]
| From | Michael Niewöhner <linux@mniewoehner.de> |
|---|---|
| Date | 2016-10-06 18:40 +0200 |
| Subject | Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 |
| Message-ID | <spjSa-2Un-21@gated-at.bofh.it> |
| In reply to | #1495393 |
Hi Vivek, On Di, 2016-10-04 at 17:32 +0530, Vivek Gautam wrote: > Hi Michael, > > > On Tue, Oct 4, 2016 at 4:28 PM, Michael Niewöhner <linux@mniewoehner.de> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1.] One line summary of the problem: > > > > > > > DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 > > > > > > > > > > > > > > [2.] Full description of the problem/report: > > > > > > > No usb 3.0 devices are being detected when attached while USB 2.0 > > > > > > > devices work on the same port. > > > > > > > USB 3.0 works after applying patches [9.1] and [9.2], but seems > > > > > > > to be > > > > > > > buggy. The usb hub is redetected every time an usb device is > > > > > > > attached. > > [snip] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [9.] Other notes, patches, fixes, workarounds: > > > > > > > > [9.1] https://lkml.org/lkml/2014/4/28/234 > > > > > > > > [9.2] https://lkml.org/lkml/2015/2/2/259 > > > > > > These patches are required to get USB super-speed working on Exynos5420/5800. > > > But they did not make to upstream. There was resistance on adding new > > > phy_calibrate() > > > callback. > > > > > > Without these patches the Exynos5420/5800 will enumerate all > > > super-speed capable devices > > > as high-speed devices. > > > Last time we checked with exynos542x smdk boards and peach-* boards, > > > we could get the > > > Super - speed devices working. I have not tested odroid anytime so > > > don't have much idea about the > > > its intricacies. > > > I guess Anand was able to use these patches to get his kernel working in past. > > > > > > The patches don't work anymore with 4.8-rc* / 4.8. They worked - but very > > unstable - with 4.7. > > > > One more problem appeared since one of the 4.8-RCs: reboot hangs when the dwc3 > > module is loaded. If I unload it before reboot / shutdown everything is fine. > > > > > > > > > > > > > When you have a downstream on-board usb hub, ideally it should be able > > > to detect the devices > > > and not reset everytime you connect a new device (like you mentioned earlier). > > > There can be two possible reasons why the hub keeps getting reset ever > > > after applying the above > > > mentioned patches: > > > 1) the clock rates are not proper. > > > 2) the regulator load setting is not enough to drive the hub. > > > > > > Anand, can you please point Michael to an older kernel with which you > > > could test usb on odroid successfully ? > > > You can compare the clocks with an older version and see if there'a > > > any difference. > > > > > > Any possibility of any other framework (such as, bus-freq) trimming > > > down the clock - rates ? > > > > > > ################################ > > # v4.7.5 > > ################################ > > > > $ cat /sys/kernel/debug/clk/clk_summary | grep usb > > sclk_usbh20_scan_clk 0 0 480000000 0 > > sclk_usbh20 0 0 48000 > > 000 0 > > mout_usbd300 1 1 24000000 0 > > dout_usbd300 0 0 24000000 0 > > sclk_usbd300 > > 0 0 24000000 0 > > dout_usbphy300 1 1 24000000 0 > > sclk_usbphy300 4 4 24000 > > 000 0 > > mout_usbd301 1 1 24000000 0 > > dout_usbd301 0 0 24000000 0 > > sclk_usbd301 > > 0 0 24000000 0 > > dout_usbphy301 1 1 24000000 0 > > sclk_usbphy301 3 3 24000 > > 000 0 > > usbd301 1 1 100000000 > > usbd300 1 1 100000000 > > > > usbh20 3 3 100000000 0 > > > > > > > ################################ > > # v4.8.0 > > ################################ > > > > $ cat /sys/kernel/debug/clk/clk_summary | grep usb > > sclk_usbh20_scan_clk 0 0 480000000 0 > > sclk_usbh20 0 0 48000000 > > 0 > > mout_usbd300 1 1 24000000 0 > > dout_usbd300 0 0 24000000 0 > > sclk_usbd300 > > 0 0 24000000 0 > > dout_usbphy300 1 1 24000000 0 > > sclk_usbphy300 4 4 24000000 > > 0 > > mout_usbd301 1 1 24000000 0 > > dout_usbd301 0 0 24000000 0 > > sclk_usbd301 > > 0 0 24000000 0 > > dout_usbphy301 1 1 24000000 0 > > sclk_usbphy301 3 3 24000000 > > 0 > > usbd301 1 1 100000000 > > This clock should have been 200MHz. > > > > > usbd300 1 1 100000000 > > usbh2 > > 0 3 3 100000000 0 > > > > $ cat /sys/kernel/debug/usb/devices > > <<system hangs>> > > > > The clocks are same across working/non-working. > Is it possible to bisect the commit that's causing hang for 4.8x ? [c499ff71ff2a281366c6ec7a904c547d806cbcd1] usb: dwc3: core: re-factor init and exit paths This patch causes both the hang on reboot and the lsusb hang. > > Adding few of the folks from Samsung who can test dwc3 usb on smdk/peach boards. > +Alim, Pankaj > > Hi Alim, Pankaj, > can you please give a try with 4.8 kernel on peach/smdk542x board and > see if dwc3 usb works or not. > You may need to the patches mentioned in [9.1] and [9.2] mentioned above. > > > [snip] > > > Thanks > Vivek > Best regards Michael
[toc] | [prev] | [next] | [standalone]
| From | Felipe Balbi <balbi@kernel.org> |
|---|---|
| Date | 2016-10-07 09:50 +0200 |
| Message-ID | <spy4O-5oY-17@gated-at.bofh.it> |
| In reply to | #1496759 |
[Multipart message — attachments visible in raw view] — view raw
Hi, Michael Niewöhner <linux@mniewoehner.de> writes: >> The clocks are same across working/non-working. >> Is it possible to bisect the commit that's causing hang for 4.8x ? > > > [c499ff71ff2a281366c6ec7a904c547d806cbcd1] usb: dwc3: core: re-factor init and exit paths > This patch causes both the hang on reboot and the lsusb hang. How to reproduce? Why don't we see this on x86 and TI boards? I'm guessing this is failed bisection, as I can't see anything in that commit that would cause reboot hang. Also, that code path is *NOT* executed when you run lsusb. -- balbi
[toc] | [prev] | [next] | [standalone]
| From | Michael Niewöhner <linux@mniewoehner.de> |
|---|---|
| Date | 2016-10-07 22:30 +0200 |
| Subject | Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 |
| Message-ID | <spJWi-5BJ-7@gated-at.bofh.it> |
| In reply to | #1497049 |
Hi Felipe, On Fr, 2016-10-07 at 10:42 +0300, Felipe Balbi wrote: > Hi, > > Michael Niewöhner <linux@mniewoehner.de> writes: > > > > > > > > The clocks are same across working/non-working. > > > Is it possible to bisect the commit that's causing hang for 4.8x ? > > > > > > [c499ff71ff2a281366c6ec7a904c547d806cbcd1] usb: dwc3: core: re-factor init and exit paths > > This patch causes both the hang on reboot and the lsusb hang. > > How to reproduce? Why don't we see this on x86 and TI boards? I'm > guessing this is failed bisection, as I can't see anything in that > commit that would cause reboot hang. Also, that code path is *NOT* > executed when you run lsusb. > I've tested this procedure multiple times to be sure: - checkout c499ff71, compile, boot the odroid - run lsusb -v => lsusb hangs, can't terminate with ctrl-c - hard reset, after boot run poweroff or reboot => board does not completely power off / reboot (see log below) - revert c499ff71, mrproper, compile, boot the odroid - run lsusb -v => shows full output, not hanging - run reboot or poweroff => board powers off / reboots just fine dmesg poweroff not working: ... [ 120.733519] systemd-journald[144]: systemd-journald stopped as pid 144 [ 120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes... [ 120.769212] systemd-shutdown[1]: Unmounting file systems. [ 120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug. [ 120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue. [ 121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.101014] systemd-shutdown[1]: All filesystems unmounted. [ 121.106523] systemd-shutdown[1]: Deactivating swaps. [ 121.111585] systemd-shutdown[1]: All swaps deactivated. [ 121.116661] systemd-shutdown[1]: Detaching loop devices. [ 121.126395] systemd-shutdown[1]: All loop devices detached. [ 121.130525] systemd-shutdown[1]: Detaching DM devices. [ 121.135824] systemd-shutdown[1]: All DM devices detached. [ 121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded. [ 121.171739] systemd-shutdown[1]: Powering off. => at this point removing the sd card would show a message "removed mmc0" (not sure what the real message was...) so the board is not completely off. dmesg poweroff working: ... [ 120.733519] systemd-journald[144]: systemd-journald stopped as pid 144 [ 120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes... [ 120.769212] systemd-shutdown[1]: Unmounting file systems. [ 120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug. [ 120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue. [ 121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 121.101014] systemd-shutdown[1]: All filesystems unmounted. [ 121.106523] systemd-shutdown[1]: Deactivating swaps. [ 121.111585] systemd-shutdown[1]: All swaps deactivated. [ 121.116661] systemd-shutdown[1]: Detaching loop devices. [ 121.126395] systemd-shutdown[1]: All loop devices detached. [ 121.130525] systemd-shutdown[1]: Detaching DM devices. [ 121.135824] systemd-shutdown[1]: All DM devices detached. [ 121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded. [ 121.171739] systemd-shutdown[1]: Powering off. [ 121.182331] rebo� Best regards Michael
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web