All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ferry Toth <fntoth@gmail.com>
To: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
	John Stultz <john.stultz@linaro.org>
Cc: John Youn <John.Youn@synopsys.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	Wesley Cheng <wcheng@codeaurora.org>,
	Yu Chen <chenyu56@huawei.com>, Felipe Balbi <balbi@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Subject: Re: [PATCH v3] usb: dwc3: core: Do core softreset when switch mode
Date: Sat, 17 Apr 2021 18:32:12 +0200	[thread overview]
Message-ID: <09755742-c73b-f737-01c1-8ecd309de551@gmail.com> (raw)
In-Reply-To: <db5849f7-ba31-8b18-ebb5-f27c4e36de28@gmail.com>

Hi

Op 17-04-2021 om 16:22 schreef Ferry Toth:
> Hi
>
> Op 17-04-2021 om 04:27 schreef Thinh Nguyen:
>> Ferry Toth wrote:
>>> Hi
>>>
>>> Op 16-04-2021 om 00:23 schreef Thinh Nguyen:
>>>> Thinh Nguyen wrote:
>>>>> From: Yu Chen <chenyu56@huawei.com>
>>>>> From: John Stultz <john.stultz@linaro.org>
>>>>>
>>>>> According to the programming guide, to switch mode for DRD 
>>>>> controller,
>>>>> the driver needs to do the following.
>>>>>
>>>>> To switch from device to host:
>>>>> 1. Reset controller with GCTL.CoreSoftReset
>>>>> 2. Set GCTL.PrtCapDir(host mode)
>>>>> 3. Reset the host with USBCMD.HCRESET
>>>>> 4. Then follow up with the initializing host registers sequence
>>>>>
>>>>> To switch from host to device:
>>>>> 1. Reset controller with GCTL.CoreSoftReset
>>>>> 2. Set GCTL.PrtCapDir(device mode)
>>>>> 3. Reset the device with DCTL.CSftRst
>>>>> 4. Then follow up with the initializing registers sequence
>>>>>
>>>>> Currently we're missing step 1) to do GCTL.CoreSoftReset and step 
>>>>> 3) of
>>>>> switching from host to device. John Stult reported a lockup issue 
>>>>> seen
>>>>> with HiKey960 platform without these steps[1]. Similar issue is 
>>>>> observed
>>>>> with Ferry's testing platform[2].
>>>>>
>>>>> So, apply the required steps along with some fixes to Yu Chen's 
>>>>> and John
>>>>> Stultz's version. The main fixes to their versions are the missing 
>>>>> wait
>>>>> for clocks synchronization before clearing GCTL.CoreSoftReset and 
>>>>> only
>>>>> apply DCTL.CSftRst when switching from host to device.
>>>>>
>>>>> [1]
>>>>> https://urldefense.com/v3/__https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/__;!!A4F2R9G_pg!PW9Jbs4wv4a_zKGgZHN0FYrIpfecPX0Ouq9V3d16Yz-9-GSHqZWsfBAF-WkeqLhzN4i3$ 
>>>>>
>>>>>
>>>>> [2]
>>>>> https://urldefense.com/v3/__https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/__;!!A4F2R9G_pg!PW9Jbs4wv4a_zKGgZHN0FYrIpfecPX0Ouq9V3d16Yz-9-GSHqZWsfBAF-WkeqGeZStt4$ 
>>>>>
>>>>>
>>>>>
>>>>> Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
>>>>> Cc: Ferry Toth <fntoth@gmail.com>
>>>>> Cc: Wesley Cheng <wcheng@codeaurora.org>
>>>>> Cc: <stable@vger.kernel.org>
>>>>> Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work
>>>>> properly")
>>>>> Signed-off-by: Yu Chen <chenyu56@huawei.com>
>>>>> Signed-off-by: John Stultz <john.stultz@linaro.org>
>>>>> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
>>>>> ---
>>>>> Changes in v3:
>>>>> - Check if the desired mode is OTG, then keep the old flow
>>>>> - Remove condition for OTG support only since the device can still be
>>>>>     configured DRD host/device mode only
>>>>> - Remove redundant hw_mode check since __dwc3_set_mode() only applies
>>>>> when
>>>>>     hw_mode is DRD
>>>>> Changes in v2:
>>>>> - Initialize mutex per device and not as global mutex.
>>>>> - Add additional checks for DRD only mode
>>>>>
>>>>>    drivers/usb/dwc3/core.c | 27 +++++++++++++++++++++++++++
>>>>>    drivers/usb/dwc3/core.h |  5 +++++
>>>>>    2 files changed, 32 insertions(+)
>>>>>
>>>> Hi John,
>>>>
>>>> If possible, can you run a test with this version on your platform?
>>>>
>>>> Thanks,
>>>> Thinh
>>>>
>>> I tested this on edison-arduino with this patch on top of usb-next
>>> (5.12-rc7 + "increase BESL baseline to 6" to prevent throttling").
>>>
>>> On this platform there is a physical switch to switch roles. With this
>>> patch I find:
>>>
>>> - switch to host mode always works fine
>>>
>>> - switch to gadget mode I need to flip the switch 3x 
>>> (gadget-host-gadget).
>>>
>>> An error message appears on the gadget side "dwc3 dwc3.0.auto: timed 
>>> out
>>> waiting for SETUP phase" appears, but then the device connects to my 
>>> PC,
>>> no throttling.
>>>
>>> - alternatively I can switch to gadget 1x and then unplug/replug the 
>>> cable.
>>>
>>> No error message and connects fine.
>>>
>>> - if I flip the switch only once, on the PC side I get:
>>>
>>>    kernel: usb 1-5: new high-speed USB device number 18 using xhci_hcd
>>>    kernel: usb 1-5: New USB device found, idVendor=1d6b,
>>>    idProduct=0104, bcdDevice= 1.00 kernel: usb 1-5: New USB device
>>>    strings: Mfr=1, Product=2, SerialNumber=3 kernel: usb 1-5: Product:
>>>    USBArmory Gadget kernel: usb 1-5: Manufacturer: USBArmory kernel:
>>>    usb 1-5: SerialNumber: 0123456789abcdef kernel: usb 1-5: can't set
>>>    config #1, error -110
>> The device failed at set_configuration() request and timed out. It
>> probably timed out from the status stage looking at the device err 
>> print.
>>
>>> Then if I wait long enough on the gadget side I get:
>>>
>>>    root@yuna:~# ifconfig
>>>
>>>    usb0: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC> mtu 1500
>>>    inet 169.254.119.239 netmask 255.255.0.0 broadcast 169.254.255.255
>>>    inet6 fe80::a8bb:ccff:fedd:eef1 prefixlen 64 scopeid 0x20<link>
>>>    ether aa:bb:cc:dd:ee:f1 txqueuelen 1000 (Ethernet) RX packets 490424
>>>    bytes 735146578 (701.0 MiB) RX errors 0 dropped 191 overruns 0 frame
>>>    0 TX packets 35279 bytes 2532746 (2.4 MiB) TX errors 0 dropped 0
>>>    overruns 0 carrier 0 collisions 0
>>>
>>> (correct would be: inet 10.42.0.221 netmask 255.255.255.0 broadcast
>>> 10.42.0.255)
>>>
>>> So much improved now, but it seems I am still missing something on 
>>> plug.
>>>
>> That's great! We can look at it further. Can you capture the tracepoints
>> of the issue. Also, can you try with mass_storage gadget to see if the
>> result is the same?
>
> I have already gser, eem, mass_storage and uac2 combo. When eem fails, 
> the mass_storage and uac2 don't appear (on KDE you get all kind of 
> popups when they appear).
>
> So either all works, or all fails.
>
> I'll trace this later today.

Trace capturing switch from host-> gadget  here 
https://github.com/andy-shev/linux/files/6329600/5.12-rc7%2Busb-next.zip

(Issue history: https://github.com/andy-shev/linux/issues/31)

On the PC side this resulted to:

apr 17 18:17:44 delfion kernel: usb 1-5: new high-speed USB device 
number 12 using xhci_hcd
apr 17 18:17:44 delfion kernel: usb 1-5: New USB device found, 
idVendor=1d6b, idProduct=0104, bcdDevice= 1.00
apr 17 18:17:44 delfion kernel: usb 1-5: New USB device strings: Mfr=1, 
Product=2, SerialNumber=3
apr 17 18:17:44 delfion kernel: usb 1-5: Product: USBArmory Gadget
apr 17 18:17:44 delfion kernel: usb 1-5: Manufacturer: USBArmory
apr 17 18:17:44 delfion kernel: usb 1-5: SerialNumber: 0123456789abcdef
apr 17 18:17:49 delfion kernel: usb 1-5: can't set config #1, error -110


Thanks for all your help!

>
>> Thanks,
>> Thinh

  reply	other threads:[~2021-04-17 16:32 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-15  2:23 [PATCH] usb: dwc3: core: Do core softreset when switch mode Thinh Nguyen
2021-04-15  6:23 ` Felipe Balbi
2021-04-15  7:10   ` Thinh Nguyen
2021-04-15  7:53     ` Greg Kroah-Hartman
2021-04-15  8:04       ` Thinh Nguyen
2021-04-15 10:45     ` Felipe Balbi
2021-04-15 14:57       ` Thinh Nguyen
2021-04-15 22:31         ` Thinh Nguyen
2021-04-15 16:29 ` [PATCH v2] " Thinh Nguyen
2021-04-15 19:54   ` John Stultz
2021-04-15 20:11     ` Thinh Nguyen
2021-04-15 22:20   ` [PATCH v3] " Thinh Nguyen
2021-04-15 22:23     ` Thinh Nguyen
2021-04-16 21:17       ` Ferry Toth
2021-04-17  2:27         ` Thinh Nguyen
2021-04-17 14:22           ` Ferry Toth
2021-04-17 16:32             ` Ferry Toth [this message]
2021-04-18 23:03               ` Thinh Nguyen
2021-04-19  8:43                 ` Andy Shevchenko
2021-04-19 20:24                   ` Ferry Toth
2021-04-19  9:47                 ` Felipe Balbi
2021-04-19 20:15                 ` Ferry Toth
2021-04-19 21:23                   ` Thinh Nguyen
2021-04-20 19:55                     ` Ferry Toth
2021-04-21 19:01                       ` Thinh Nguyen
2021-04-21 22:30                         ` Ferry Toth
2021-04-22 20:55                         ` Ferry Toth
2021-04-22 21:58                           ` Thinh Nguyen
2021-04-23  7:18                             ` Ferry Toth
2021-04-16  0:12     ` John Stultz
2021-04-16  3:28       ` John Stultz
2021-04-16  9:10         ` Ferry Toth
2021-04-16 10:47     ` Felipe Balbi
2021-04-16 19:05       ` Wesley Cheng
2021-04-16 19:38       ` John Stultz
2021-04-16 19:49         ` Thinh Nguyen
2021-04-16 21:08           ` John Stultz
2021-04-17  6:25             ` Felipe Balbi
2021-04-19 19:49               ` Thinh Nguyen
2021-04-19 21:26     ` Wesley Cheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=09755742-c73b-f737-01c1-8ecd309de551@gmail.com \
    --to=fntoth@gmail.com \
    --cc=John.Youn@synopsys.com \
    --cc=Thinh.Nguyen@synopsys.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=balbi@kernel.org \
    --cc=chenyu56@huawei.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=john.stultz@linaro.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=wcheng@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.