dwc3 gadget breaks on system suspend/resume

dwc3 gadget breaks on system suspend/resume

[Roger Quadros]

Hi Felipe,

We have system suspend resume working on dra7-evm in v4.10-rc but
dwc3 gadget breaks after system suspend resume.

Any hints how to fix it? Full backtrace below.

Another message that looks worry-some is
"[   61.495313] omap-dwc3 48880000.omap_dwc3_1: runtime PM trying to suspend device but active child"

If I unload gadget, then suspend/resume system then load gadget everything works fine.

cheers,
-roger

rtcwake: wakeup from "mem" using /dev/rtc0 at Sat Jan  1 00:01:01 2000
[   61.434863] PM: Syncing filesystems ... done.
[   61.439563] PM: Preparing system for sleep (mem)
[   61.445966] Freezing user space processes ... (elapsed 0.001 seconds) done.
[   61.455285] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[   61.464617] PM: Suspending system (mem)
[   61.468641] Suspending console(s) (use no_console_suspend to debug)
[   61.490595] PM: suspend of devices complete after 13.582 msecs
[   61.494404] PM: late suspend of devices complete after 3.799 msecs
[   61.495313] omap-dwc3 48880000.omap_dwc3_1: runtime PM trying to suspend device but active child
[   61.495348] omap-dwc3 488c0000.omap_dwc3_2: runtime PM trying to suspend device but active child
[   61.497601] omap-ocp2scp 4a080000.ocp2scp: runtime PM trying to suspend device but active child
[   61.497634] ahci 4a140000.sata: runtime PM trying to suspend device but active child
[   61.497660] omap-ocp2scp 4a090000.ocp2scp: runtime PM trying to suspend device but active child
[   61.498454] PM: noirq suspend of devices complete after 4.042 msecs
[   61.498458] Disabling non-boot CPUs ...
[   61.499492] CPU1: shutdown
[   61.554081] Successfully put all powerdomains to target state
[   61.554081] Suspended for 3.833 seconds
[   61.554094] Enabling non-boot CPUs ...
[   61.583410] CPU1: smp_ops.cpu_die() returned, trying to resuscitate
[   61.583753] CPU1 is up
[   61.585775] PM: noirq resume of devices complete after 2.013 msecs
[   61.588224] PM: early resume of devices complete after 1.981 msecs
[   61.590256] net eth0: initializing cpsw version 1.15 (0)
[   61.696078] Generic PHY 48485000.mdio:02: attached PHY driver [Generic PHY] (mii_bus:phy_addr=48485000.mdio:02, irq=-1)
[   61.707591] PM: resume of devices complete after 119.358 msecs
[   61.816446] zero gadget: suspend
[   61.816450] zero gadget: zero_suspend
[   61.846681] PM: Finishing wakeup.
[   61.850156] Restarting tasks ... done.
root@rockdesk:~# [   61.925469] ata1: SATA link down (SStatus 0 SControl 300)
[   61.945352] zero gadget: reset config
[   61.949199] ------------[ cut here ]------------
[   61.954065] WARNING: CPU: 1 PID: 2127 at drivers/usb/dwc3/gadget.c:2384 dwc3_stop_active_transfer.constprop.4+0xc4/0xe4 [dwc3]
[   61.966015] Modules linked in: usb_f_ss_lb g_zero libcomposite xhci_plat_hcd xhci_hcd usbcore dwc3 udc_core snd_soc_tlv320aic3x snd_soc_simple_card snd_soc_davinci_mcasp evdev snd_soc_simple_card_utils m25p8e
[   62.013916] CPU: 1 PID: 2127 Comm: irq/457-dwc3 Tainted: G        W       4.10.0-rc4-00108-gfb1d8e0 #1084
[   62.023951] Hardware name: Generic DRA74X (Flattened Device Tree)
[   62.030357] [<c0110194>] (unwind_backtrace) from [<c010c300>] (show_stack+0x10/0x14)
[   62.038483] [<c010c300>] (show_stack) from [<c04a0758>] (dump_stack+0xac/0xe0)
[   62.046068] [<c04a0758>] (dump_stack) from [<c013706c>] (__warn+0xd8/0x104)
[   62.053376] [<c013706c>] (__warn) from [<c0137144>] (warn_slowpath_null+0x20/0x28)
[   62.061347] [<c0137144>] (warn_slowpath_null) from [<bf2b684c>] (dwc3_stop_active_transfer.constprop.4+0xc4/0xe4 [dwc3])
[   62.072800] [<bf2b684c>] (dwc3_stop_active_transfer.constprop.4 [dwc3]) from [<bf2b9b14>] (__dwc3_gadget_ep_disable+0x64/0x528 [dwc3])
[   62.085516] [<bf2b9b14>] (__dwc3_gadget_ep_disable [dwc3]) from [<bf2bb27c>] (dwc3_gadget_ep_disable+0x3c/0xc8 [dwc3])
[   62.096779] [<bf2bb27c>] (dwc3_gadget_ep_disable [dwc3]) from [<bf280428>] (usb_ep_disable+0x11c/0x18c [udc_core])
[   62.107665] [<bf280428>] (usb_ep_disable [udc_core]) from [<bf386774>] (disable_ep+0x18/0x54 [usb_f_ss_lb])
[   62.117907] [<bf386774>] (disable_ep [usb_f_ss_lb]) from [<bf3877b0>] (disable_endpoints+0x18/0x50 [usb_f_ss_lb])
[   62.128681] [<bf3877b0>] (disable_endpoints [usb_f_ss_lb]) from [<bf387814>] (disable_source_sink+0x2c/0x34 [usb_f_ss_lb])
[   62.140291] [<bf387814>] (disable_source_sink [usb_f_ss_lb]) from [<bf36ca9c>] (reset_config+0x48/0x7c [libcomposite])
[   62.151552] [<bf36ca9c>] (reset_config [libcomposite]) from [<bf36cafc>] (composite_disconnect+0x2c/0x54 [libcomposite])
[   62.162980] [<bf36cafc>] (composite_disconnect [libcomposite]) from [<bf2827dc>] (usb_gadget_udc_reset+0x10/0x34 [udc_core])
[   62.174778] [<bf2827dc>] (usb_gadget_udc_reset [udc_core]) from [<bf2b5d70>] (dwc3_gadget_reset_interrupt+0x64/0x698 [dwc3])
[   62.186580] [<bf2b5d70>] (dwc3_gadget_reset_interrupt [dwc3]) from [<bf2b852c>] (dwc3_thread_interrupt+0x618/0x1a3c [dwc3])
[   62.198284] [<bf2b852c>] (dwc3_thread_interrupt [dwc3]) from [<c01a7cd8>] (irq_thread_fn+0x1c/0x54)
[   62.207777] [<c01a7cd8>] (irq_thread_fn) from [<c01a7fac>] (irq_thread+0x120/0x1f0)
[   62.215817] [<c01a7fac>] (irq_thread) from [<c015ba08>] (kthread+0xf8/0x138)
[   62.223221] [<c015ba08>] (kthread) from [<c01078f0>] (ret_from_fork+0x14/0x24)
[   62.230792] ---[ end trace bf9da8b9a4f9b671 ]---
[   63.759582] cpsw 48484000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
--
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: dwc3 gadget breaks on system suspend/resume

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]


Hi,

Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> writes:
> Hi Felipe,
>
> We have system suspend resume working on dra7-evm in v4.10-rc but
> dwc3 gadget breaks after system suspend resume.
>
> Any hints how to fix it? Full backtrace below.

from a quick look. END_TRANSFER is timing out, most likely. Tracepoints
should give better hints.

We might have a bug in dwc3_gadget_suspend(). No idea what's really
going on.

> Another message that looks worry-some is
> "[   61.495313] omap-dwc3 48880000.omap_dwc3_1: runtime PM trying to suspend device but active child"

did you implement runtime PM on dwc3-omap.c? Look at dwc3-pci.c for reference.

> If I unload gadget, then suspend/resume system then load gadget everything works fine.

right, dwc3 UDC will already have been toredown. Unfortunately I can't
spend a lot of time on this, so you're gonna have to try to fix it and
provide a patch :-s Quite busy looking at some f_fs weirdness.

cheers

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: dwc3 gadget breaks on system suspend/resume

[Roger Quadros]

On 19/01/17 13:59, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> writes:
>> Hi Felipe,
>>
>> We have system suspend resume working on dra7-evm in v4.10-rc but
>> dwc3 gadget breaks after system suspend resume.
>>
>> Any hints how to fix it? Full backtrace below.
> 
> from a quick look. END_TRANSFER is timing out, most likely. Tracepoints
> should give better hints.
> 
> We might have a bug in dwc3_gadget_suspend(). No idea what's really
> going on.
> 
>> Another message that looks worry-some is
>> "[   61.495313] omap-dwc3 48880000.omap_dwc3_1: runtime PM trying to suspend device but active child"
> 
> did you implement runtime PM on dwc3-omap.c? Look at dwc3-pci.c for reference.
> 
>> If I unload gadget, then suspend/resume system then load gadget everything works fine.
> 
> right, dwc3 UDC will already have been toredown. Unfortunately I can't
> spend a lot of time on this, so you're gonna have to try to fix it and
> provide a patch :-s Quite busy looking at some f_fs weirdness.

No problem. I'll debug this issue.

cheers,
-roger
--
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: dwc3 gadget breaks on system suspend/resume

[Roger Quadros]

Felipe,

On 19/01/17 14:16, Roger Quadros wrote:
> On 19/01/17 13:59, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> writes:
>>> Hi Felipe,
>>>
>>> We have system suspend resume working on dra7-evm in v4.10-rc but
>>> dwc3 gadget breaks after system suspend resume.
>>>
>>> Any hints how to fix it? Full backtrace below.
>>
>> from a quick look. END_TRANSFER is timing out, most likely. Tracepoints
>> should give better hints.
>>
>> We might have a bug in dwc3_gadget_suspend(). No idea what's really
>> going on.
>>
>>> Another message that looks worry-some is
>>> "[   61.495313] omap-dwc3 48880000.omap_dwc3_1: runtime PM trying to suspend device but active child"
>>
>> did you implement runtime PM on dwc3-omap.c? Look at dwc3-pci.c for reference.
>>
>>> If I unload gadget, then suspend/resume system then load gadget everything works fine.
>>
>> right, dwc3 UDC will already have been toredown. Unfortunately I can't
>> spend a lot of time on this, so you're gonna have to try to fix it and
>> provide a patch :-s Quite busy looking at some f_fs weirdness.
> 
> No problem. I'll debug this issue.

Bisected to bad commit 4eb3d981e7344ded9e5a8725ed934dd8f8056daf "usb: dwc3: core: simplify suspend/resume operations".

cheers,
-roger
--
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: dwc3 gadget breaks on system suspend/resume

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]


Hi,

Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> writes:

> Felipe,
>
> On 19/01/17 14:16, Roger Quadros wrote:
>> On 19/01/17 13:59, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> writes:
>>>> Hi Felipe,
>>>>
>>>> We have system suspend resume working on dra7-evm in v4.10-rc but
>>>> dwc3 gadget breaks after system suspend resume.
>>>>
>>>> Any hints how to fix it? Full backtrace below.
>>>
>>> from a quick look. END_TRANSFER is timing out, most likely. Tracepoints
>>> should give better hints.
>>>
>>> We might have a bug in dwc3_gadget_suspend(). No idea what's really
>>> going on.
>>>
>>>> Another message that looks worry-some is
>>>> "[   61.495313] omap-dwc3 48880000.omap_dwc3_1: runtime PM trying to suspend device but active child"
>>>
>>> did you implement runtime PM on dwc3-omap.c? Look at dwc3-pci.c for reference.
>>>
>>>> If I unload gadget, then suspend/resume system then load gadget everything works fine.
>>>
>>> right, dwc3 UDC will already have been toredown. Unfortunately I can't
>>> spend a lot of time on this, so you're gonna have to try to fix it and
>>> provide a patch :-s Quite busy looking at some f_fs weirdness.
>> 
>> No problem. I'll debug this issue.
>
> Bisected to bad commit 4eb3d981e7344ded9e5a8725ed934dd8f8056daf "usb: dwc3: core: simplify suspend/resume operations".

$ git show 4eb3d981e7344ded9e5a8725ed934dd8f8056daf
fatal: bad object 4eb3d981e7344ded9e5a8725ed934dd8f8056daf

That commit to me is:

commit 51f5d49ad6f011ee380b866ea617fd90584189a2
Author: Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Date:   Mon May 16 10:52:58 2016 +0300

    usb: dwc3: core: simplify suspend/resume operations
    
    now that we have re-factored dwc3_core_init() and
    dwc3_core_exit() we can use them for suspend/resume
    operations.
    
    This will help us avoid some common mistakes when
    patching code when we have duplicated pieces of code
    doing the same thing.
    
    Signed-off-by: Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>

Can you please try actual mainline and not some tree where you
cherry-picked patches on top? ;-)

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: dwc3 gadget breaks on system suspend/resume

[Roger Quadros]

On 27/01/17 16:17, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> writes:
> 
>> Felipe,
>>
>> On 19/01/17 14:16, Roger Quadros wrote:
>>> On 19/01/17 13:59, Felipe Balbi wrote:
>>>>
>>>> Hi,
>>>>
>>>> Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> writes:
>>>>> Hi Felipe,
>>>>>
>>>>> We have system suspend resume working on dra7-evm in v4.10-rc but
>>>>> dwc3 gadget breaks after system suspend resume.
>>>>>
>>>>> Any hints how to fix it? Full backtrace below.
>>>>
>>>> from a quick look. END_TRANSFER is timing out, most likely. Tracepoints
>>>> should give better hints.
>>>>
>>>> We might have a bug in dwc3_gadget_suspend(). No idea what's really
>>>> going on.
>>>>
>>>>> Another message that looks worry-some is
>>>>> "[   61.495313] omap-dwc3 48880000.omap_dwc3_1: runtime PM trying to suspend device but active child"
>>>>
>>>> did you implement runtime PM on dwc3-omap.c? Look at dwc3-pci.c for reference.
>>>>
>>>>> If I unload gadget, then suspend/resume system then load gadget everything works fine.
>>>>
>>>> right, dwc3 UDC will already have been toredown. Unfortunately I can't
>>>> spend a lot of time on this, so you're gonna have to try to fix it and
>>>> provide a patch :-s Quite busy looking at some f_fs weirdness.
>>>
>>> No problem. I'll debug this issue.
>>
>> Bisected to bad commit 4eb3d981e7344ded9e5a8725ed934dd8f8056daf "usb: dwc3: core: simplify suspend/resume operations".
> 
> $ git show 4eb3d981e7344ded9e5a8725ed934dd8f8056daf
> fatal: bad object 4eb3d981e7344ded9e5a8725ed934dd8f8056daf
> 
> That commit to me is:
> 
> commit 51f5d49ad6f011ee380b866ea617fd90584189a2
> Author: Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Date:   Mon May 16 10:52:58 2016 +0300
> 
>     usb: dwc3: core: simplify suspend/resume operations
>     
>     now that we have re-factored dwc3_core_init() and
>     dwc3_core_exit() we can use them for suspend/resume
>     operations.
>     
>     This will help us avoid some common mistakes when
>     patching code when we have duplicated pieces of code
>     doing the same thing.
>     
>     Signed-off-by: Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> 
> Can you please try actual mainline and not some tree where you
> cherry-picked patches on top? ;-)
> 
Sorry about the wrong commit ID.
I reset my tree to 51f5d49ad6f011ee380b866ea617fd90584189a2 and can reproduce the issue.
The previous commit c499ff71ff2a281366c6ec7a904c547d806cbcd1 is fine.

cheers,
-roger
--
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: dwc3 gadget breaks on system suspend/resume

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2659 bytes --]


Hi,

Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> writes:
>>>>>> We have system suspend resume working on dra7-evm in v4.10-rc but
>>>>>> dwc3 gadget breaks after system suspend resume.
>>>>>>
>>>>>> Any hints how to fix it? Full backtrace below.
>>>>>
>>>>> from a quick look. END_TRANSFER is timing out, most likely. Tracepoints
>>>>> should give better hints.
>>>>>
>>>>> We might have a bug in dwc3_gadget_suspend(). No idea what's really
>>>>> going on.
>>>>>
>>>>>> Another message that looks worry-some is
>>>>>> "[   61.495313] omap-dwc3 48880000.omap_dwc3_1: runtime PM trying to suspend device but active child"
>>>>>
>>>>> did you implement runtime PM on dwc3-omap.c? Look at dwc3-pci.c for reference.
>>>>>
>>>>>> If I unload gadget, then suspend/resume system then load gadget everything works fine.
>>>>>
>>>>> right, dwc3 UDC will already have been toredown. Unfortunately I can't
>>>>> spend a lot of time on this, so you're gonna have to try to fix it and
>>>>> provide a patch :-s Quite busy looking at some f_fs weirdness.
>>>>
>>>> No problem. I'll debug this issue.
>>>
>>> Bisected to bad commit 4eb3d981e7344ded9e5a8725ed934dd8f8056daf "usb: dwc3: core: simplify suspend/resume operations".
>> 
>> $ git show 4eb3d981e7344ded9e5a8725ed934dd8f8056daf
>> fatal: bad object 4eb3d981e7344ded9e5a8725ed934dd8f8056daf
>> 
>> That commit to me is:
>> 
>> commit 51f5d49ad6f011ee380b866ea617fd90584189a2
>> Author: Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> Date:   Mon May 16 10:52:58 2016 +0300
>> 
>>     usb: dwc3: core: simplify suspend/resume operations
>>     
>>     now that we have re-factored dwc3_core_init() and
>>     dwc3_core_exit() we can use them for suspend/resume
>>     operations.
>>     
>>     This will help us avoid some common mistakes when
>>     patching code when we have duplicated pieces of code
>>     doing the same thing.
>>     
>>     Signed-off-by: Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> 
>> Can you please try actual mainline and not some tree where you
>> cherry-picked patches on top? ;-)
>> 
> Sorry about the wrong commit ID.

np

> I reset my tree to 51f5d49ad6f011ee380b866ea617fd90584189a2 and can reproduce the issue.

okay

> The previous commit c499ff71ff2a281366c6ec7a904c547d806cbcd1 is fine.

okay. Then let's try to figure out what's going on. A diff of regdump
before and after suspend/resume might start to give some clue about
what's going on. DWC3 tracepoints should help too. Care to get those?
BTW, is this dwc3 as host or peripheral?

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: dwc3 gadget breaks on system suspend/resume

[Roger Quadros]

On 27/01/17 17:03, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> writes:
>>>>>>> We have system suspend resume working on dra7-evm in v4.10-rc but
>>>>>>> dwc3 gadget breaks after system suspend resume.
>>>>>>>
>>>>>>> Any hints how to fix it? Full backtrace below.
>>>>>>
>>>>>> from a quick look. END_TRANSFER is timing out, most likely. Tracepoints
>>>>>> should give better hints.
>>>>>>
>>>>>> We might have a bug in dwc3_gadget_suspend(). No idea what's really
>>>>>> going on.
>>>>>>
>>>>>>> Another message that looks worry-some is
>>>>>>> "[   61.495313] omap-dwc3 48880000.omap_dwc3_1: runtime PM trying to suspend device but active child"
>>>>>>
>>>>>> did you implement runtime PM on dwc3-omap.c? Look at dwc3-pci.c for reference.
>>>>>>
>>>>>>> If I unload gadget, then suspend/resume system then load gadget everything works fine.
>>>>>>
>>>>>> right, dwc3 UDC will already have been toredown. Unfortunately I can't
>>>>>> spend a lot of time on this, so you're gonna have to try to fix it and
>>>>>> provide a patch :-s Quite busy looking at some f_fs weirdness.
>>>>>
>>>>> No problem. I'll debug this issue.
>>>>
>>>> Bisected to bad commit 4eb3d981e7344ded9e5a8725ed934dd8f8056daf "usb: dwc3: core: simplify suspend/resume operations".
>>>
>>> $ git show 4eb3d981e7344ded9e5a8725ed934dd8f8056daf
>>> fatal: bad object 4eb3d981e7344ded9e5a8725ed934dd8f8056daf
>>>
>>> That commit to me is:
>>>
>>> commit 51f5d49ad6f011ee380b866ea617fd90584189a2
>>> Author: Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>>> Date:   Mon May 16 10:52:58 2016 +0300
>>>
>>>     usb: dwc3: core: simplify suspend/resume operations
>>>     
>>>     now that we have re-factored dwc3_core_init() and
>>>     dwc3_core_exit() we can use them for suspend/resume
>>>     operations.
>>>     
>>>     This will help us avoid some common mistakes when
>>>     patching code when we have duplicated pieces of code
>>>     doing the same thing.
>>>     
>>>     Signed-off-by: Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>>>
>>> Can you please try actual mainline and not some tree where you
>>> cherry-picked patches on top? ;-)
>>>
>> Sorry about the wrong commit ID.
> 
> np
> 
>> I reset my tree to 51f5d49ad6f011ee380b866ea617fd90584189a2 and can reproduce the issue.
> 
> okay
> 
>> The previous commit c499ff71ff2a281366c6ec7a904c547d806cbcd1 is fine.
> 
> okay. Then let's try to figure out what's going on. A diff of regdump
> before and after suspend/resume might start to give some clue about
> what's going on. DWC3 tracepoints should help too. Care to get those?
> BTW, is this dwc3 as host or peripheral?
> 

It is for peripheral mode.

regdump pre-suspend
http://pastebin.ubuntu.com/23875213/

regdump post-resume
http://pastebin.ubuntu.com/23875211/

tracing during suspend/resume. NOTE: gadget zero had enumerated successfully
before I enabled the tracing.
http://pastebin.ubuntu.com/23875233/

cheers,
-roger
--
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: dwc3 gadget breaks on system suspend/resume

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 12163 bytes --]


Hi,

(hmm, I didn't receive your reply in my intel inbox, only
gmail. Odd. Replying to myself here, but it should be on your reply,
rater).

Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> writes:
>> The previous commit c499ff71ff2a281366c6ec7a904c547d806cbcd1 is fine.
>
> okay. Then let's try to figure out what's going on. A diff of regdump
> before and after suspend/resume might start to give some clue about
> what's going on. DWC3 tracepoints should help too. Care to get those?
> BTW, is this dwc3 as host or peripheral?

You don't have any endpoints enabled:

-DALEPENA = 0x0000000f
+DALEPENA = 0x00000000

Your traces are peculiar:

    > irq/451-dwc3-2082  [000] d...   108.215104: dwc3_gadget: Disabling ep1in-bulk

okay, let's disable ep1in-bulk

    > irq/451-dwc3-2082  [000] d...   108.215106: dwc3_gadget_ep_cmd: ep1in-bulk: cmd 'End Transfer' [198920] params 00000000 00000000 00000000
    > irq/451-dwc3-2082  [000] d...   108.215109: dwc3_readl: addr fa89c200 value 00002500
    > irq/451-dwc3-2082  [000] d...   108.215114: dwc3_writel: addr fa89c838 value 00000000
    > irq/451-dwc3-2082  [000] d...   108.215116: dwc3_writel: addr fa89c834 value 00000000
    > irq/451-dwc3-2082  [000] d...   108.215118: dwc3_writel: addr fa89c830 value 00000000
    > irq/451-dwc3-2082  [000] d...   108.215120: dwc3_writel: addr fa89c83c value 00030d08
    > irq/451-dwc3-2082  [000] d...   108.215123: dwc3_readl: addr fa89c83c value 00031908
    > irq/451-dwc3-2082  [000] d...   108.215125: dwc3_gadget: Command Complete --> 1
    > irq/451-dwc3-2082  [000] d...   108.215127: dwc3_gadget: (null): no resource available
    > irq/451-dwc3-2082  [000] d...   108.495119: dwc3_gadget_giveback: ep1in-bulk: req ed5cae80 length 0/4096 zsI ==> -108
    > irq/451-dwc3-2082  [000] d...   108.495123: dwc3_free_request: ep1in-bulk: req ed5cae80 length 0/4096 zsI ==> -108
    > irq/451-dwc3-2082  [000] d...   108.495127: dwc3_readl: addr fa89c720 value 00000000

read DALEPENA, already 0x00. How was ep1in-bulk even enabled???

    > irq/451-dwc3-2082  [000] d...   108.495130: dwc3_writel: addr fa89c720 value 00000000

clear bit for ep1in-bulk and write back the 0x00 you read. What gives??
Why is DALEPENA already zero here???? 

    > irq/451-dwc3-2082  [000] d...   108.495135: dwc3_gadget: Disabling ep1out-bulk
    > irq/451-dwc3-2082  [000] d...   108.495137: dwc3_gadget_ep_cmd: ep1out-bulk: cmd 'End Transfer' [133384] params 00000000 00000000 00000000
    > irq/451-dwc3-2082  [000] d...   108.495139: dwc3_readl: addr fa89c200 value 00002500
    > irq/451-dwc3-2082  [000] d...   108.495143: dwc3_writel: addr fa89c828 value 00000000
    > irq/451-dwc3-2082  [000] d...   108.495145: dwc3_writel: addr fa89c824 value 00000000
    > irq/451-dwc3-2082  [000] d...   108.495146: dwc3_writel: addr fa89c820 value 00000000
    > irq/451-dwc3-2082  [000] d...   108.495148: dwc3_writel: addr fa89c82c value 00020d08
    > irq/451-dwc3-2082  [000] d...   108.495151: dwc3_readl: addr fa89c82c value 00021908
    > irq/451-dwc3-2082  [000] d...   108.495153: dwc3_gadget: Command Complete --> 1
    > irq/451-dwc3-2082  [000] d...   108.495154: dwc3_gadget: (null): no resource available
    > irq/451-dwc3-2082  [000] d...   108.495258: dwc3_gadget_giveback: ep1out-bulk: req ed76d080 length 0/4096 zsI ==> -108
    > irq/451-dwc3-2082  [000] d...   108.495261: dwc3_free_request: ep1out-bulk: req ed76d080 length 0/4096 zsI ==> -108
    > irq/451-dwc3-2082  [000] d...   108.495264: dwc3_readl: addr fa89c720 value 00000000
    > irq/451-dwc3-2082  [000] d...   108.495266: dwc3_writel: addr fa89c720 value 00000000

same thing for ep1out-bulk. When you get a "Disabling epxxxx" message,
we not only clear DALEPENA (which shouldn't be zero, btw!), but we
also clear dep->flags unconditionally. Here's a blame of v4.7 for that
function:

72246da40f371 (Felipe Balbi              2011-08-19 18:10:58 +0300  669) static int __dwc3_gadget_ep_disable(struct dwc3_ep *dep)
72246da40f371 (Felipe Balbi              2011-08-19 18:10:58 +0300  670) {
72246da40f371 (Felipe Balbi              2011-08-19 18:10:58 +0300  671)        struct dwc3             *dwc = dep->dwc;
72246da40f371 (Felipe Balbi              2011-08-19 18:10:58 +0300  672)        u32                     reg;
72246da40f371 (Felipe Balbi              2011-08-19 18:10:58 +0300  673) 
7eaeac5c0e449 (Felipe Balbi              2015-07-20 14:46:15 -0500  674)        dwc3_trace(trace_dwc3_gadget, "Disabling %s", dep->name);
7eaeac5c0e449 (Felipe Balbi              2015-07-20 14:46:15 -0500  675) 
624407f96f134 (Sebastian Andrzej Siewior 2011-08-29 13:56:37 +0200  676)        dwc3_remove_requests(dwc, dep);
72246da40f371 (Felipe Balbi              2011-08-19 18:10:58 +0300  677) 
687ef9817df7e (Felipe Balbi              2014-04-16 10:30:33 -0500  678)        /* make sure HW endpoint isn't stalled */
687ef9817df7e (Felipe Balbi              2014-04-16 10:30:33 -0500  679)        if (dep->flags & DWC3_EP_STALL)
7a60855972f0d (Felipe Balbi              2014-09-24 14:19:52 -0500  680)                __dwc3_gadget_ep_set_halt(dep, 0, false);
687ef9817df7e (Felipe Balbi              2014-04-16 10:30:33 -0500  681) 
72246da40f371 (Felipe Balbi              2011-08-19 18:10:58 +0300  682)        reg = dwc3_readl(dwc->regs, DWC3_DALEPENA);
72246da40f371 (Felipe Balbi              2011-08-19 18:10:58 +0300  683)        reg &= ~DWC3_DALEPENA_EP(dep->number);
72246da40f371 (Felipe Balbi              2011-08-19 18:10:58 +0300  684)        dwc3_writel(dwc->regs, DWC3_DALEPENA, reg);
72246da40f371 (Felipe Balbi              2011-08-19 18:10:58 +0300  685) 
879631aa658be (Felipe Balbi              2011-09-30 10:58:47 +0300  686)        dep->stream_capable = false;
f9c56cdd3905c (Ido Shayevitz             2012-02-08 13:56:48 +0200  687)        dep->endpoint.desc = NULL;
c90bfaece97c1 (Felipe Balbi              2011-11-29 13:11:21 +0200  688)        dep->comp_desc = NULL;
72246da40f371 (Felipe Balbi              2011-08-19 18:10:58 +0300  689)        dep->type = 0;
879631aa658be (Felipe Balbi              2011-09-30 10:58:47 +0300  690)        dep->flags = 0;
72246da40f371 (Felipe Balbi              2011-08-19 18:10:58 +0300  691) 
aa7399744dd02 (Felipe Balbi              2015-07-20 14:48:13 -0500  692)        snprintf(dep->name, sizeof(dep->name), "ep%d%s",
aa7399744dd02 (Felipe Balbi              2015-07-20 14:48:13 -0500  693)                        dep->number >> 1,
aa7399744dd02 (Felipe Balbi              2015-07-20 14:48:13 -0500  694)                        (dep->number & 1) ? "in" : "out");
aa7399744dd02 (Felipe Balbi              2015-07-20 14:48:13 -0500  695) 
72246da40f371 (Felipe Balbi              2011-08-19 18:10:58 +0300  696)        return 0;
72246da40f371 (Felipe Balbi              2011-08-19 18:10:58 +0300  697) }


let's keep going, there's more...

    > irq/451-dwc3-2082  [000] d...   108.495280: dwc3_readl: addr fa89c704 value 80000000
    > irq/451-dwc3-2082  [000] d...   108.495283: dwc3_writel: addr fa89c704 value 80000000
    > irq/451-dwc3-2082  [000] d...   108.495287: dwc3_readl: addr fa89c700 value 004c098c
    > irq/451-dwc3-2082  [000] d...   108.495290: dwc3_writel: addr fa89c700 value 004c0804
    > irq/451-dwc3-2082  [000] d...   108.495292: dwc3_writel: addr fa89c40c value 00000004
    > irq/451-dwc3-2082  [000] d...   108.495295: dwc3_readl: addr fa89c408 value 80000100
    > irq/451-dwc3-2082  [000] d...   108.495297: dwc3_writel: addr fa89c408 value 00000100
    > irq/451-dwc3-2082  [000] d.H.   108.495342: dwc3_readl: addr fa89c40c value 00000010
    > irq/451-dwc3-2082  [000] d.H.   108.495347: dwc3_readl: addr fa89c408 value 00000100
    > irq/451-dwc3-2082  [000] d.H.   108.495349: dwc3_writel: addr fa89c408 value 80000100
    > irq/451-dwc3-2082  [000] d...   108.495374: dwc3_event: event 080311c6
    > irq/451-dwc3-2082  [000] d...   108.495378: dwc3_writel: addr fa89c40c value 00000004
    > irq/451-dwc3-2082  [000] d...   108.495381: dwc3_event: event 00000201
    > irq/451-dwc3-2082  [000] d...   108.495383: dwc3_readl: addr fa89c70c value 00006838
    > irq/451-dwc3-2082  [000] d...   108.495385: dwc3_readl: addr fa89c700 value 004c0804
    > irq/451-dwc3-2082  [000] d...   108.495388: dwc3_writel: addr fa89c700 value 004c0804
    > irq/451-dwc3-2082  [000] d...   108.495390: dwc3_readl: addr fa89c704 value 80000000
    > irq/451-dwc3-2082  [000] d...   108.495392: dwc3_writel: addr fa89c704 value 8c000000
    > irq/451-dwc3-2082  [000] d...   108.495394: dwc3_gadget: Enabling ep0out

... Enabling ep0out.

    > irq/451-dwc3-2082  [000] d...   108.495397: dwc3_gadget_ep_cmd: ep0out: cmd 'Set Endpoint Configuration' [1] params 80000200 00000500 00000000
    > irq/451-dwc3-2082  [000] d...   108.495399: dwc3_readl: addr fa89c200 value 00002500
    > irq/451-dwc3-2082  [000] d...   108.495401: dwc3_writel: addr fa89c808 value 80000200
    > irq/451-dwc3-2082  [000] d...   108.495403: dwc3_writel: addr fa89c804 value 00000500
    > irq/451-dwc3-2082  [000] d...   108.495405: dwc3_writel: addr fa89c800 value 00000000
    > irq/451-dwc3-2082  [000] d...   108.495406: dwc3_writel: addr fa89c80c value 00000401
    > irq/451-dwc3-2082  [000] d...   108.495409: dwc3_readl: addr fa89c80c value 00000001
    > irq/451-dwc3-2082  [000] d...   108.495411: dwc3_gadget: Command Complete --> 0

no writes to DALEPENA!

    > irq/451-dwc3-2082  [000] d...   108.495413: dwc3_gadget: Enabling ep0in
    > irq/451-dwc3-2082  [000] d...   108.495415: dwc3_gadget_ep_cmd: ep0in: cmd 'Set Endpoint Configuration' [1] params 80000200 02000500 00000000
    > irq/451-dwc3-2082  [000] d...   108.495416: dwc3_readl: addr fa89c200 value 00002500
    > irq/451-dwc3-2082  [000] d...   108.495419: dwc3_writel: addr fa89c818 value 80000200
    > irq/451-dwc3-2082  [000] d...   108.495420: dwc3_writel: addr fa89c814 value 02000500
    > irq/451-dwc3-2082  [000] d...   108.495423: dwc3_writel: addr fa89c810 value 00000000
    > irq/451-dwc3-2082  [000] d...   108.495425: dwc3_writel: addr fa89c81c value 00000401
    > irq/451-dwc3-2082  [000] d...   108.495428: dwc3_readl: addr fa89c81c value 00000001
    > irq/451-dwc3-2082  [000] d...   108.495429: dwc3_gadget: Command Complete --> 0

nor here! however we disabled ep0/1 on gadget_suspend:

0b0231aa246cb (Felipe Balbi              2014-10-07 10:19:23 -0500 2936) int dwc3_gadget_suspend(struct dwc3 *dwc)
7415f17c9560c (Felipe Balbi              2012-04-30 14:56:33 +0300 2937) {
9772b47a4c291 (Roger Quadros             2016-04-12 11:33:29 +0300 2938)        if (!dwc->gadget_driver)
9772b47a4c291 (Roger Quadros             2016-04-12 11:33:29 +0300 2939)                return 0;
9772b47a4c291 (Roger Quadros             2016-04-12 11:33:29 +0300 2940) 
7b2a0368bbc9b (Felipe Balbi              2013-12-19 13:43:19 -0600 2941)        if (dwc->pullups_connected) {
7415f17c9560c (Felipe Balbi              2012-04-30 14:56:33 +0300 2942)                dwc3_gadget_disable_irq(dwc);
7b2a0368bbc9b (Felipe Balbi              2013-12-19 13:43:19 -0600 2943)                dwc3_gadget_run_stop(dwc, true, true);
7b2a0368bbc9b (Felipe Balbi              2013-12-19 13:43:19 -0600 2944)        }
7415f17c9560c (Felipe Balbi              2012-04-30 14:56:33 +0300 2945) 
7415f17c9560c (Felipe Balbi              2012-04-30 14:56:33 +0300 2946)        __dwc3_gadget_ep_disable(dwc->eps[0]);
7415f17c9560c (Felipe Balbi              2012-04-30 14:56:33 +0300 2947)        __dwc3_gadget_ep_disable(dwc->eps[1]);
7415f17c9560c (Felipe Balbi              2012-04-30 14:56:33 +0300 2948) 
7415f17c9560c (Felipe Balbi              2012-04-30 14:56:33 +0300 2949)        dwc->dcfg = dwc3_readl(dwc->regs, DWC3_DCFG);
7415f17c9560c (Felipe Balbi              2012-04-30 14:56:33 +0300 2950) 
7415f17c9560c (Felipe Balbi              2012-04-30 14:56:33 +0300 2951)        return 0;
7415f17c9560c (Felipe Balbi              2012-04-30 14:56:33 +0300 2952) }

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: dwc3 gadget breaks on system suspend/resume

[Roger Quadros]

Hi,

On 27/01/17 17:47, Felipe Balbi wrote:
> 
> Hi,
> 
> (hmm, I didn't receive your reply in my intel inbox, only
> gmail. Odd. Replying to myself here, but it should be on your reply,
> rater).
> 
> Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> writes:
>>> The previous commit c499ff71ff2a281366c6ec7a904c547d806cbcd1 is fine.
>>
>> okay. Then let's try to figure out what's going on. A diff of regdump
>> before and after suspend/resume might start to give some clue about
>> what's going on. DWC3 tracepoints should help too. Care to get those?
>> BTW, is this dwc3 as host or peripheral?
> 
> You don't have any endpoints enabled:
> 
> -DALEPENA = 0x0000000f
> +DALEPENA = 0x00000000

Thanks for the hints.

This problem is because reason dwc3_gadget_run_stop() is timing out
during the suspend sequence and so dwc3_disconnect_gadget() and
__dwc3_gadget_stop() are not being called.

dwc3_suspend() does not consider dwc3_gadget_suspend()'s return value
and happily continues suspending the machine.

If I force dwc3_gadget_run_stop() to return 0 then everything works fine.

Any ideas why DWC3_DSTS_DEVCTRLHLT is not getting set?
I checked that DWC3_GEVNTCOUNT(0) is zero.

cheers,
-roger
--
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: dwc3 gadget breaks on system suspend/resume

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]


Hi,

Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> writes:
>> (hmm, I didn't receive your reply in my intel inbox, only
>> gmail. Odd. Replying to myself here, but it should be on your reply,
>> rater).
>> 
>> Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> writes:
>>>> The previous commit c499ff71ff2a281366c6ec7a904c547d806cbcd1 is fine.
>>>
>>> okay. Then let's try to figure out what's going on. A diff of regdump
>>> before and after suspend/resume might start to give some clue about
>>> what's going on. DWC3 tracepoints should help too. Care to get those?
>>> BTW, is this dwc3 as host or peripheral?
>> 
>> You don't have any endpoints enabled:
>> 
>> -DALEPENA = 0x0000000f
>> +DALEPENA = 0x00000000
>
> Thanks for the hints.
>
> This problem is because reason dwc3_gadget_run_stop() is timing out
> during the suspend sequence and so dwc3_disconnect_gadget() and
> __dwc3_gadget_stop() are not being called.

I see

> dwc3_suspend() does not consider dwc3_gadget_suspend()'s return value
> and happily continues suspending the machine.
>
> If I force dwc3_gadget_run_stop() to return 0 then everything works fine.
>
> Any ideas why DWC3_DSTS_DEVCTRLHLT is not getting set?

no idea. It should always get set when run_stop is cleared. Can you
check if suspending with cable detached has any difference?

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: dwc3 gadget breaks on system suspend/resume

[Roger Quadros]

On 30/01/17 14:59, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> writes:
>>> (hmm, I didn't receive your reply in my intel inbox, only
>>> gmail. Odd. Replying to myself here, but it should be on your reply,
>>> rater).
>>>
>>> Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> writes:
>>>>> The previous commit c499ff71ff2a281366c6ec7a904c547d806cbcd1 is fine.
>>>>
>>>> okay. Then let's try to figure out what's going on. A diff of regdump
>>>> before and after suspend/resume might start to give some clue about
>>>> what's going on. DWC3 tracepoints should help too. Care to get those?
>>>> BTW, is this dwc3 as host or peripheral?
>>>
>>> You don't have any endpoints enabled:
>>>
>>> -DALEPENA = 0x0000000f
>>> +DALEPENA = 0x00000000
>>
>> Thanks for the hints.
>>
>> This problem is because reason dwc3_gadget_run_stop() is timing out
>> during the suspend sequence and so dwc3_disconnect_gadget() and
>> __dwc3_gadget_stop() are not being called.
> 
> I see
> 
>> dwc3_suspend() does not consider dwc3_gadget_suspend()'s return value
>> and happily continues suspending the machine.
>>
>> If I force dwc3_gadget_run_stop() to return 0 then everything works fine.
>>
>> Any ideas why DWC3_DSTS_DEVCTRLHLT is not getting set?
> 
> no idea. It should always get set when run_stop is cleared. Can you
> check if suspending with cable detached has any difference?
> 

After cable detach, it still timed out the next suspend. But on
subsequent suspends there were no timeouts. (I didn't plug the cable back at all)

This behaviour is on dra7. I will test the behaviour on am43x as well.

cheers,
-roger
--
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: dwc3 gadget breaks on system suspend/resume

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]


Hi,

Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> writes:
>> Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> writes:
>>>> (hmm, I didn't receive your reply in my intel inbox, only
>>>> gmail. Odd. Replying to myself here, but it should be on your reply,
>>>> rater).
>>>>
>>>> Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> writes:
>>>>>> The previous commit c499ff71ff2a281366c6ec7a904c547d806cbcd1 is fine.
>>>>>
>>>>> okay. Then let's try to figure out what's going on. A diff of regdump
>>>>> before and after suspend/resume might start to give some clue about
>>>>> what's going on. DWC3 tracepoints should help too. Care to get those?
>>>>> BTW, is this dwc3 as host or peripheral?
>>>>
>>>> You don't have any endpoints enabled:
>>>>
>>>> -DALEPENA = 0x0000000f
>>>> +DALEPENA = 0x00000000
>>>
>>> Thanks for the hints.
>>>
>>> This problem is because reason dwc3_gadget_run_stop() is timing out
>>> during the suspend sequence and so dwc3_disconnect_gadget() and
>>> __dwc3_gadget_stop() are not being called.
>> 
>> I see
>> 
>>> dwc3_suspend() does not consider dwc3_gadget_suspend()'s return value
>>> and happily continues suspending the machine.
>>>
>>> If I force dwc3_gadget_run_stop() to return 0 then everything works fine.
>>>
>>> Any ideas why DWC3_DSTS_DEVCTRLHLT is not getting set?
>> 
>> no idea. It should always get set when run_stop is cleared. Can you
>> check if suspending with cable detached has any difference?
>
> After cable detach, it still timed out the next suspend. But on
> subsequent suspends there were no timeouts. (I didn't plug the cable
> back at all)
>
> This behaviour is on dra7. I will test the behaviour on am43x as well.

wonder if there's something odd with 2.02a. AM437x is 2.40a IIRC,
testing that is, indeed, a good idea.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: dwc3 gadget breaks on system suspend/resume

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2611 bytes --]


Hi,

Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> writes:
> Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> writes:
>>> Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> writes:
>>>>> (hmm, I didn't receive your reply in my intel inbox, only
>>>>> gmail. Odd. Replying to myself here, but it should be on your reply,
>>>>> rater).
>>>>>
>>>>> Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> writes:
>>>>>>> The previous commit c499ff71ff2a281366c6ec7a904c547d806cbcd1 is fine.
>>>>>>
>>>>>> okay. Then let's try to figure out what's going on. A diff of regdump
>>>>>> before and after suspend/resume might start to give some clue about
>>>>>> what's going on. DWC3 tracepoints should help too. Care to get those?
>>>>>> BTW, is this dwc3 as host or peripheral?
>>>>>
>>>>> You don't have any endpoints enabled:
>>>>>
>>>>> -DALEPENA = 0x0000000f
>>>>> +DALEPENA = 0x00000000
>>>>
>>>> Thanks for the hints.
>>>>
>>>> This problem is because reason dwc3_gadget_run_stop() is timing out
>>>> during the suspend sequence and so dwc3_disconnect_gadget() and
>>>> __dwc3_gadget_stop() are not being called.
>>> 
>>> I see
>>> 
>>>> dwc3_suspend() does not consider dwc3_gadget_suspend()'s return value
>>>> and happily continues suspending the machine.
>>>>
>>>> If I force dwc3_gadget_run_stop() to return 0 then everything works fine.
>>>>
>>>> Any ideas why DWC3_DSTS_DEVCTRLHLT is not getting set?
>>> 
>>> no idea. It should always get set when run_stop is cleared. Can you
>>> check if suspending with cable detached has any difference?
>>
>> After cable detach, it still timed out the next suspend. But on
>> subsequent suspends there were no timeouts. (I didn't plug the cable
>> back at all)
>>
>> This behaviour is on dra7. I will test the behaviour on am43x as well.
>
> wonder if there's something odd with 2.02a. AM437x is 2.40a IIRC,
> testing that is, indeed, a good idea.

What if your platform just takes longer to halt?

Can you try below?

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 4db97ecae885..d2e405793b1f 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1586,7 +1586,7 @@ static int dwc3_gadget_set_selfpowered(struct usb_gadget *g,
 static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on, int suspend)
 {
        u32                     reg;
-       u32                     timeout = 500;
+       u32                     timeout = 500000;
 
        if (pm_runtime_suspended(dwc->dev))
                return 0;


-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: dwc3 gadget breaks on system suspend/resume

[Roger Quadros]

Hi,

On 30/01/17 15:47, Felipe Balbi wrote:
> 
> Hi,
> 
> Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> writes:
>> Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> writes:
>>>> Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> writes:
>>>>>> (hmm, I didn't receive your reply in my intel inbox, only
>>>>>> gmail. Odd. Replying to myself here, but it should be on your reply,
>>>>>> rater).
>>>>>>
>>>>>> Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> writes:
>>>>>>>> The previous commit c499ff71ff2a281366c6ec7a904c547d806cbcd1 is fine.
>>>>>>>
>>>>>>> okay. Then let's try to figure out what's going on. A diff of regdump
>>>>>>> before and after suspend/resume might start to give some clue about
>>>>>>> what's going on. DWC3 tracepoints should help too. Care to get those?
>>>>>>> BTW, is this dwc3 as host or peripheral?
>>>>>>
>>>>>> You don't have any endpoints enabled:
>>>>>>
>>>>>> -DALEPENA = 0x0000000f
>>>>>> +DALEPENA = 0x00000000
>>>>>
>>>>> Thanks for the hints.
>>>>>
>>>>> This problem is because reason dwc3_gadget_run_stop() is timing out
>>>>> during the suspend sequence and so dwc3_disconnect_gadget() and
>>>>> __dwc3_gadget_stop() are not being called.
>>>>
>>>> I see
>>>>
>>>>> dwc3_suspend() does not consider dwc3_gadget_suspend()'s return value
>>>>> and happily continues suspending the machine.
>>>>>
>>>>> If I force dwc3_gadget_run_stop() to return 0 then everything works fine.
>>>>>
>>>>> Any ideas why DWC3_DSTS_DEVCTRLHLT is not getting set?
>>>>
>>>> no idea. It should always get set when run_stop is cleared. Can you
>>>> check if suspending with cable detached has any difference?
>>>
>>> After cable detach, it still timed out the next suspend. But on
>>> subsequent suspends there were no timeouts. (I didn't plug the cable
>>> back at all)
>>>
>>> This behaviour is on dra7. I will test the behaviour on am43x as well.
>>
>> wonder if there's something odd with 2.02a. AM437x is 2.40a IIRC,
>> testing that is, indeed, a good idea.

Tried on am437x which is 2.40a but same timeout problem there as well.

> 
> What if your platform just takes longer to halt?
> 
> Can you try below?
> 
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 4db97ecae885..d2e405793b1f 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1586,7 +1586,7 @@ static int dwc3_gadget_set_selfpowered(struct usb_gadget *g,
>  static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on, int suspend)
>  {
>         u32                     reg;
> -       u32                     timeout = 500;
> +       u32                     timeout = 500000;
>  
>         if (pm_runtime_suspended(dwc->dev))
>                 return 0;
> 
> 

Tried this but it doesn't resolve the issue.

-- 
cheers,
-roger
--
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: dwc3 gadget breaks on system suspend/resume

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2226 bytes --]


Hi,

Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> writes:
>>>>>>> -DALEPENA = 0x0000000f
>>>>>>> +DALEPENA = 0x00000000
>>>>>>
>>>>>> Thanks for the hints.
>>>>>>
>>>>>> This problem is because reason dwc3_gadget_run_stop() is timing out
>>>>>> during the suspend sequence and so dwc3_disconnect_gadget() and
>>>>>> __dwc3_gadget_stop() are not being called.
>>>>>
>>>>> I see
>>>>>
>>>>>> dwc3_suspend() does not consider dwc3_gadget_suspend()'s return value
>>>>>> and happily continues suspending the machine.
>>>>>>
>>>>>> If I force dwc3_gadget_run_stop() to return 0 then everything works fine.
>>>>>>
>>>>>> Any ideas why DWC3_DSTS_DEVCTRLHLT is not getting set?
>>>>>
>>>>> no idea. It should always get set when run_stop is cleared. Can you
>>>>> check if suspending with cable detached has any difference?
>>>>
>>>> After cable detach, it still timed out the next suspend. But on
>>>> subsequent suspends there were no timeouts. (I didn't plug the cable
>>>> back at all)
>>>>
>>>> This behaviour is on dra7. I will test the behaviour on am43x as well.
>>>
>>> wonder if there's something odd with 2.02a. AM437x is 2.40a IIRC,
>>> testing that is, indeed, a good idea.
>
> Tried on am437x which is 2.40a but same timeout problem there as well.
>
>> 
>> What if your platform just takes longer to halt?
>> 
>> Can you try below?
>> 
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index 4db97ecae885..d2e405793b1f 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -1586,7 +1586,7 @@ static int dwc3_gadget_set_selfpowered(struct usb_gadget *g,
>>  static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on, int suspend)
>>  {
>>         u32                     reg;
>> -       u32                     timeout = 500;
>> +       u32                     timeout = 500000;
>>  
>>         if (pm_runtime_suspended(dwc->dev))
>>                 return 0;
>> 
>> 
>
> Tried this but it doesn't resolve the issue.

Interesting. I have no idea what to try now. How about checking if that
susphy quirk flags help? Maybe your platform can't accept PHY being
suspended, or something.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: dwc3 gadget breaks on system suspend/resume

[Roger Quadros]

On 31/01/17 14:03, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> writes:
>>>>>>>> -DALEPENA = 0x0000000f
>>>>>>>> +DALEPENA = 0x00000000
>>>>>>>
>>>>>>> Thanks for the hints.
>>>>>>>
>>>>>>> This problem is because reason dwc3_gadget_run_stop() is timing out
>>>>>>> during the suspend sequence and so dwc3_disconnect_gadget() and
>>>>>>> __dwc3_gadget_stop() are not being called.
>>>>>>
>>>>>> I see
>>>>>>
>>>>>>> dwc3_suspend() does not consider dwc3_gadget_suspend()'s return value
>>>>>>> and happily continues suspending the machine.
>>>>>>>
>>>>>>> If I force dwc3_gadget_run_stop() to return 0 then everything works fine.
>>>>>>>
>>>>>>> Any ideas why DWC3_DSTS_DEVCTRLHLT is not getting set?
>>>>>>
>>>>>> no idea. It should always get set when run_stop is cleared. Can you
>>>>>> check if suspending with cable detached has any difference?
>>>>>
>>>>> After cable detach, it still timed out the next suspend. But on
>>>>> subsequent suspends there were no timeouts. (I didn't plug the cable
>>>>> back at all)
>>>>>
>>>>> This behaviour is on dra7. I will test the behaviour on am43x as well.
>>>>
>>>> wonder if there's something odd with 2.02a. AM437x is 2.40a IIRC,
>>>> testing that is, indeed, a good idea.
>>
>> Tried on am437x which is 2.40a but same timeout problem there as well.
>>
>>>
>>> What if your platform just takes longer to halt?
>>>
>>> Can you try below?
>>>
>>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>>> index 4db97ecae885..d2e405793b1f 100644
>>> --- a/drivers/usb/dwc3/gadget.c
>>> +++ b/drivers/usb/dwc3/gadget.c
>>> @@ -1586,7 +1586,7 @@ static int dwc3_gadget_set_selfpowered(struct usb_gadget *g,
>>>  static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on, int suspend)
>>>  {
>>>         u32                     reg;
>>> -       u32                     timeout = 500;
>>> +       u32                     timeout = 500000;
>>>  
>>>         if (pm_runtime_suspended(dwc->dev))
>>>                 return 0;
>>>
>>>
>>
>> Tried this but it doesn't resolve the issue.
> 
> Interesting. I have no idea what to try now. How about checking if that
> susphy quirk flags help? Maybe your platform can't accept PHY being
> suspended, or something.
> 

The susphy quirks are already enabled for both dra7 and am43 platforms.
I too don't have any clues as to what's going on. :(

-- 
cheers,
-roger
--
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