Options for forcing dwc3 gadget to only accept superspeed

Options for forcing dwc3 gadget to only accept superspeed

[Claus Stovgaard]

Hi all

I have a system, using a Xilinx ZynqMP with kernel 4.19, using the
build in dwc3 core as a USB device. (It is a custom device using
ConfigFS / FunctionFS).

In a certain scenario I would like to force the dwc3 to only connect
via superspeed and not fall back to USB2.

What options exist for forcing the dwc3 to keep retry?

I know about the U2RSTECN from GCTL -
https://www.xilinx.com/html_docs/registers/ug1087/usb3_xhci___gctl.html

So was wondering if other options existed, where I can force it to
continue try to connect as SuperSpeed.

Or if it is possible to setup the high speed descriptors for ffs, so
the host automatically will reset the bus / device so it newer will be
reported as connected, unless it is with super speed.

Thanks ahead.

Claus Stovgaard

Re: Options for forcing dwc3 gadget to only accept superspeed

[Alan Stern]

On Tue, May 12, 2020 at 09:25:38PM +0200, Claus Stovgaard wrote:
> Hi all
> 
> I have a system, using a Xilinx ZynqMP with kernel 4.19, using the
> build in dwc3 core as a USB device. (It is a custom device using
> ConfigFS / FunctionFS).
> 
> In a certain scenario I would like to force the dwc3 to only connect
> via superspeed and not fall back to USB2.
> 
> What options exist for forcing the dwc3 to keep retry?

The USB-3 spec forbids devices from operating only at SuperSpeed.  
Devices must be able to connect at high speed, although possibly with 
reduced functionality.

Alan Stern

> I know about the U2RSTECN from GCTL -
> https://www.xilinx.com/html_docs/registers/ug1087/usb3_xhci___gctl.html
> 
> So was wondering if other options existed, where I can force it to
> continue try to connect as SuperSpeed.
> 
> Or if it is possible to setup the high speed descriptors for ffs, so
> the host automatically will reset the bus / device so it newer will be
> reported as connected, unless it is with super speed.

Re: Options for forcing dwc3 gadget to only accept superspeed

[Claus Stovgaard]

On tir, 2020-05-12 at 15:52 -0400, Alan Stern wrote:
> On Tue, May 12, 2020 at 09:25:38PM +0200, Claus Stovgaard wrote:
> > 
> > In a certain scenario I would like to force the dwc3 to only
> > connect
> > via superspeed and not fall back to USB2.
> > 
> > What options exist for forcing the dwc3 to keep retry?
> 
> The USB-3 spec forbids devices from operating only at SuperSpeed.  
> Devices must be able to connect at high speed, although possibly
> with 
> reduced functionality.
> 
> Alan Stern
> 

I understand the requirement from the USB 3 specification. Though in
the scenario for this specific device, it is not about comply with the
USB 3 specification, but my question is rather what options I have for
not comply with the specification here, and then force retry of USB 3,
using the dwc3 as device.

The device is in a fixed mounting with a fixed host. Sometimes when the
host and device is powered up, it ends in high-speed instead of super-
speed. I would like the option for "I will not be compliant with USB,
but rather retry super-speed".

Regards
Claus

Re: Options for forcing dwc3 gadget to only accept superspeed

[Sid Spry]

Have you tried only providing a SS configuration? If that fails for some reason I suspect the next course of action would be to see why, and patch the driver so it does not.

Out of curiosity, which SoC are you using?

On Tue, May 12, 2020, at 3:08 PM, Claus Stovgaard wrote:
> On tir, 2020-05-12 at 15:52 -0400, Alan Stern wrote:
> > On Tue, May 12, 2020 at 09:25:38PM +0200, Claus Stovgaard wrote:
> > > 
> > > In a certain scenario I would like to force the dwc3 to only
> > > connect
> > > via superspeed and not fall back to USB2.
> > > 
> > > What options exist for forcing the dwc3 to keep retry?
> > 
> > The USB-3 spec forbids devices from operating only at SuperSpeed. 
> > Devices must be able to connect at high speed, although possibly
> > with 
> > reduced functionality.
> > 
> > Alan Stern
> > 
> 
> I understand the requirement from the USB 3 specification. Though in
> the scenario for this specific device, it is not about comply with the
> USB 3 specification, but my question is rather what options I have for
> not comply with the specification here, and then force retry of USB 3,
> using the dwc3 as device.
> 
> The device is in a fixed mounting with a fixed host. Sometimes when the
> host and device is powered up, it ends in high-speed instead of super-
> speed. I would like the option for "I will not be compliant with USB,
> but rather retry super-speed".
> 
> Regards
> Claus
> 
> 

Re: Options for forcing dwc3 gadget to only accept superspeed

[Sid Spry]

Hello again, I'm terribly sorry for the double post. Claus, you might try detecting the speed of the connection and re-enumerating if necessary. It would avoid noncompliance with the spec and is probably the easiest option.

Unsure of how this would be done with a C manifestation of functionfs code but echoing "" to the UDC pseudofile under /sys/kernel/config/usb_gadget/${your_gadget} will allow you to set everything up again and reenumerate.

On Tue, May 12, 2020, at 11:43 PM, Sid Spry wrote:
> Have you tried only providing a SS configuration? If that fails for some reason I suspect the next course of action would be to see why, and patch the driver so it does not.
> 
> Out of curiosity, which SoC are you using?
> 
> On Tue, May 12, 2020, at 3:08 PM, Claus Stovgaard wrote:
> > On tir, 2020-05-12 at 15:52 -0400, Alan Stern wrote:
> > > On Tue, May 12, 2020 at 09:25:38PM +0200, Claus Stovgaard wrote:
> > > > 
> > > > In a certain scenario I would like to force the dwc3 to only
> > > > connect
> > > > via superspeed and not fall back to USB2.
> > > > 
> > > > What options exist for forcing the dwc3 to keep retry?
> > > 
> > > The USB-3 spec forbids devices from operating only at SuperSpeed. 
> > > Devices must be able to connect at high speed, although possibly
> > > with 
> > > reduced functionality.
> > > 
> > > Alan Stern
> > > 
> > 
> > I understand the requirement from the USB 3 specification. Though in
> > the scenario for this specific device, it is not about comply with the
> > USB 3 specification, but my question is rather what options I have for
> > not comply with the specification here, and then force retry of USB 3,
> > using the dwc3 as device.
> > 
> > The device is in a fixed mounting with a fixed host. Sometimes when the
> > host and device is powered up, it ends in high-speed instead of super-
> > speed. I would like the option for "I will not be compliant with USB,
> > but rather retry super-speed".
> > 
> > Regards
> > Claus
> > 
> > 

Re: Options for forcing dwc3 gadget to only accept superspeed

[Claus Stovgaard]

On tir, 2020-05-12 at 23:47 -0500, Sid Spry wrote:
> Hello again, I'm terribly sorry for the double post. Claus, you might
> try detecting the speed of the connection and re-enumerating if
> necessary. It would avoid noncompliance with the spec and is probably
> the easiest option.
> 
> Unsure of how this would be done with a C manifestation of functionfs
> code but echoing "" to the UDC pseudofile under
> /sys/kernel/config/usb_gadget/${your_gadget} will allow you to set
> everything up again and reenumerate.
> 
> On Tue, May 12, 2020, at 11:43 PM, Sid Spry wrote:
> > Have you tried only providing a SS configuration? If that fails for
> > some reason I suspect the next course of action would be to see
> > why, and patch the driver so it does not.
> > 
> > Out of curiosity, which SoC are you using?
> > 

Hi Sid.

Thanks for both your replies. Will answer the last question first. It
is the Xilinx Zynq UltraScale+ MPSoC, also just known as ZynqMP.

I remember vaguely testing only SS configuration for an older kernel,
where it got a fault because somewhere the configurations was indexed
by [0], e.g. just indexing the full-speed descriptor directly. This
might changed by now.

Regarding just enumerating. I have thought about it, and it might be
what I end up implementing no matter what. The not so nice part is if
the host side is Windows, my impression from doing it like this, would
be that you get the "device appeared" / "device not safely removed"
style of messages. Can't remember the exact wording.

Just as a background in why I am looking into doing it like this. For
10 years ago I worked on some USB 3 devices. Here the USB2 part was a
hard-block, and the USB3 part was a soft-core in FPGA logic. I
encountered a number of, should we call it implementation differences,
in the USB 3 hosts. E.g. issues like when the device and host did not
agree on link training (Ux exit) etc.
As the link control of switching between the hard-block and the soft-
core was done in firmware, it was pretty easy for me to make an option
for being non-compliment and making the link retry Super-Speed, and by
that hide the "differences" for the end-user, and just have working
system.


Thanks
/Claus

Re: Options for forcing dwc3 gadget to only accept superspeed

[Felipe Balbi]

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


Hi,

Claus Stovgaard <claus.stovgaard@gmail.com> writes:
> On tir, 2020-05-12 at 15:52 -0400, Alan Stern wrote:
>> On Tue, May 12, 2020 at 09:25:38PM +0200, Claus Stovgaard wrote:
>> > 
>> > In a certain scenario I would like to force the dwc3 to only
>> > connect
>> > via superspeed and not fall back to USB2.
>> > 
>> > What options exist for forcing the dwc3 to keep retry?
>> 
>> The USB-3 spec forbids devices from operating only at SuperSpeed.  
>> Devices must be able to connect at high speed, although possibly
>> with 
>> reduced functionality.
>> 
>> Alan Stern
>> 
>
> I understand the requirement from the USB 3 specification. Though in
> the scenario for this specific device, it is not about comply with the
> USB 3 specification, but my question is rather what options I have for
> not comply with the specification here, and then force retry of USB 3,
> using the dwc3 as device.
>
> The device is in a fixed mounting with a fixed host. Sometimes when the
> host and device is powered up, it ends in high-speed instead of super-
> speed. I would like the option for "I will not be compliant with USB,
> but rather retry super-speed".

If it's "ending in super-speed" this means it tried RX.Detect and it
failed, thus falling back to high-speed. It's likely that the signal
quality in your setup has degraded or is, at least, sub-par.

Forcing a SS-only setup would just give you a device that doesn't even
enumerate in some cases.

Could you capture dwc3 tracepoints of the problem?

Also, which kernel version are you running? Which platform?

best

-- 
balbi

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

Re: Options for forcing dwc3 gadget to only accept superspeed

[Claus Stovgaard]

On ons, 2020-05-13 at 10:34 +0300, Felipe Balbi wrote:
> 
> If it's "ending in super-speed" this means it tried RX.Detect and it
> failed, thus falling back to high-speed. It's likely that the signal
> quality in your setup has degraded or is, at least, sub-par.
> 
> Forcing a SS-only setup would just give you a device that doesn't
> even
> enumerate in some cases.
> 
> Could you capture dwc3 tracepoints of the problem?
> 
> Also, which kernel version are you running? Which platform?
> 

Thanks for you reply Balbi.

Will start with from the back. The kernel is 4.19 in the xilinx version
- https://github.com/Xilinx/linux-xlnx
It is running on a ZynqMP from Xilinx, where we are using the build in
Cirrus SERDES as phy. In front of the phy is a tusb1042i redriver/mux
and a Cypress CCG4 as type-c controller for handling the redriver/mux.

Regarding signal integrity - it is on my radar. I know from experience
that noise on the GND in the cable can highly influence signal
integrity on the super speed pair in some situations, even though it is
shielded.

I am currently working on a setup with a Beagle USB analyzer, together
with dwc3 tracepoints, and automatically disconnect and connect the
USB. Would like to have both the USB analyzer version of what happening
on the bus, together with the dwc3 handling.

It just takes some time to create this test setup (need to do some
python code for controlling the Beagle and the device), so it will take
some time before I can have any data. 

So my email is also kind of an brainstorm for what kind of options
there exist in the dwc3 to control how it falls back to high-speed.

Regards
Claus

Re: Options for forcing dwc3 gadget to only accept superspeed

[Felipe Balbi]

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


Hi,

Claus Stovgaard <claus.stovgaard@gmail.com> writes:
> On ons, 2020-05-13 at 10:34 +0300, Felipe Balbi wrote:
>> 
>> If it's "ending in super-speed" this means it tried RX.Detect and it
>> failed, thus falling back to high-speed. It's likely that the signal
>> quality in your setup has degraded or is, at least, sub-par.
>> 
>> Forcing a SS-only setup would just give you a device that doesn't
>> even
>> enumerate in some cases.
>> 
>> Could you capture dwc3 tracepoints of the problem?
>> 
>> Also, which kernel version are you running? Which platform?
>> 
>
> Thanks for you reply Balbi.
>
> Will start with from the back. The kernel is 4.19 in the xilinx version
> - https://github.com/Xilinx/linux-xlnx

4.19 is *really* old. Care to try v5.6 or, better yet, v5.7-rc5?

> It is running on a ZynqMP from Xilinx, where we are using the build in
> Cirrus SERDES as phy. In front of the phy is a tusb1042i redriver/mux
> and a Cypress CCG4 as type-c controller for handling the redriver/mux.
>
> Regarding signal integrity - it is on my radar. I know from experience
> that noise on the GND in the cable can highly influence signal
> integrity on the super speed pair in some situations, even though it is
> shielded.

Yeah, common problem with high-speed signals.

> I am currently working on a setup with a Beagle USB analyzer, together
> with dwc3 tracepoints, and automatically disconnect and connect the
> USB. Would like to have both the USB analyzer version of what happening
> on the bus, together with the dwc3 handling.

That makes sense to me. One thing you can try is disabling PHY suspend
(see our existing quirk flags) and also disabling scrambling for
testing. Do NOT, however, ship your product with scrambling disabled ;-)

> It just takes some time to create this test setup (need to do some
> python code for controlling the Beagle and the device), so it will take
> some time before I can have any data. 
>
> So my email is also kind of an brainstorm for what kind of options
> there exist in the dwc3 to control how it falls back to high-speed.

falling back to high-speed is not something we can control. It's part of
the standard, and as such, implemented entirely in the HW. What we can
do is figure out *why* Rx.Detect fails and causes the link to downgrade.

A look at the tracepoints, even without the sniffer, may give us hints
of what's possibly happening.

-- 
balbi

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