Re: Use device tree to disable U1/U2 in gadget devices based on DWC3

["Claus H. Stovgaard" <cst@phaseone.com>]

On Wed, 2019-04-24 at 14:33 -0400, Alan Stern wrote:
> On Wed, 24 Apr 2019, Claus H. Stovgaard wrote:
> 
> > 
> > Hi Balbi and other USB developers.
> > 
> > I am developing camera devices based on Xilinx ZynqMP, using the
> > gadget framework and the build-in dwc3 core of the ZynqMP as USB3
> > controller and the build-in Cirrus SERDES as phy.
> > Testing with a number of hosts and Windows 7, has shown sporadic
> > reconnects when leaving U2/U1, caused by failing link training,
> > where
> > the host resets the bus. Sometime it also means it reconnect via
> > USB2.
> > 
> > So to overcome this, I will like to have the option for disabling
> > U1/U2 on the core when working with those hosts.
> > 
> > Currently I have made a hack in ep0.c where I return EINVAL in
> > dwc3_ep0_handle_u1 and dwc3_ep0_handle_u2 together with not setting
> > DWC3_DCTL_ACCEPTU1ENA and DWC3_DCTL_ACCEPTU2ENA in
> > dwc3_ep0_set_config
> > Will though prefer a solution possible to upstream, so was thinking
> > about adding two devicetree bindings.
> > 
> > * snps,u1_disable_as_gadget: When set the core will not enable U1
> > if
> > requested from host, nor initiate U1.
> > * snps,u2_disable_as_gadget: When set the core will not enable U2
> > if
> > requested from host, nor initiate U2.
> > 
> > If you think this might be something which can be upstreamed I will
> > prepare the code and send a patch for discussion.
> > On the other hand, if you think that disabling U1/U2 via device
> > tree
> > as suggested should not be a feature no need for me to try making
> > it
> > a feature.
> Speaking as an interested bystander, I would first wonder why your
> hardware fails during link training.  If it is properly designed,
> that
> should not happen.  The fact that it does happen suggests your
> devices
> might also experience problems during normal data transport.

Unfortunately I don't know the root cause of the failing link training
when leaving U2 yet. I can see the link training fail with a beagle
analyzer, but have not had the possibility for looking at the signals
when it happens. Have tested our hardware with a keysight setup
(DSAV134A) resulting it being compliant according to the keysight USB
3.1 compliance test software (U7243C-1TP/SR).

To set the error rate into perspective, running several of our 100
mega-pixel camera (above 100 MB/s for each) in parallel for a 19 hour
test, resulted in 1 unit having no reconnects, 1 having 2 reconnects
and 1 having 4 reconnects. Here we constant enters and exit U0/U1/U2.

As our industrial cameras often work in pretty noisy environment like
an airplane, means we also is trying to reduce insertion loss and
improve cabling etc. to help if the issue is caused by a signal
integrity element.

In short, I am trying to figure out the root cause for the link
training failing, but as it is very hard to find, I need to pursue the
option for disabling U1/U2, as it works very effective.


> Second, the bindings you suggested would not be accepted by the 
> devicetree maintainers.  The whole idea behind devicetree is that it 
> describes the hardware, not the software.  Things like 
> u1_disable_as_gadget are software concepts and so do not belong in a 
> devicetree description.
> 
> You might be better off creating sysfs attribute files for disabling
> entry into U1 and U2.  Alternatively, if you really want to do it
> through devicetree, you should create a binding that does describe
> your
> hardware properties, such as "u1-and-u2-are-broken", or
> "broken-link-training", or something else along those lines.

Thanks. A very good point, and exactly the kind of input I hoped to
get.
Using a sysfs attribute also fit very nice with the
usb3_hardware_lpm_u1 and usb3_hardware_lpm_u2 sysfs files for enabling
/ disabling u1/u2 from the host side.
Will look into setting it via 2 files inside the configfs / usb_gadget
interface.

/Claus


> 
> Alan Stern
>