Hi Bin,
On Tue, Jul 02, 2019 at 09:48:42AM -0500, Bin Liu wrote:
> Hi,
>
> Sorry for the delay getting back on this. I was offline for quite some
> time.
>
> On Thu, Apr 25, 2019 at 03:44:57PM -0700, Jack Pham wrote:
> > Hi Bin,
> >
> > On Mon, Apr 22, 2019 at 08:43:57AM -0500, Bin Liu wrote:
> > > Hi Felipe,
> > >
> > > I am having an issue with dwc3 on TI AM57x device, and would like to ask
> > > for your comments.
> > >
> > > I use configfs to create a multi-function gadget on dwc3, mass_storage
> > > is the last function, it seems if I create 3 functions, the mass_storage
> > > enumeration will fail on the host. It works fine if only create 2
> > > functions.
> > >
> > > The dwc3 tracepoints log shows after all the ep0 transfers for
> > > mass_storage, the very first epXin transfer is not complete - dwc3
> > > programmed the urb, but never generates RX completion event. This also
> > > matches the bus analyzer trace - dwc3 NAKs the very first IN token for
> > > ever.
> > >
> > > I use the attached script to create the gadget, The macro FUNCS in the
> > > beginning of the script defines the functions to be created.
> > >
> > > Any comments are appreciated.
> >
> > A stab in the dark here but what is the value of GTXFIFOSIZ(X)[15:0]
> > for epXin on your device? Is it at least wMaxPacketSize? Depending on
> > the default hardware values it might be deficient as compared to the
> > working endpoint that gets assigned in your 2-function config.
>
> Jack,
>
> thanks for the pointer, it is indeed the issue on AM57x device. The
> reset value of GTXFIFOSIZ for ep1~4 have size of 0x184, but ep5~15 have
> only size of 0x13 (which is 120 bytes), which is not enough for
> high-speed bulk xfers. I manually adjusted the fifo memory allocation,
> now my test case works.
Cool! I'm glad my suggestion was on the right track.
> Felipe,
>
> Is there anything the dwc3 gadget driver can do to better handle this
> kind of devices, which don't have enough fifo buffers for all TX eps?
A long time ago...
commit bc5081617faeb3b2f0c126dc37264b87af7da47f
Author: Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx>
Date: Thu Feb 4 14:18:01 2016 +0200
usb: dwc3: drop FIFO resizing logic
That FIFO resizing logic was added to support OMAP5
ES1.0 which had a bogus default FIFO size. I can't
remember the exact size of default FIFO, but it was
less than one bulk superspeed packet (<1024) which
would prevent USB3 from ever working on OMAP5 ES1.0.
However, OMAP5 ES1.0 support has been dropped by
commit aa2f4b16f830 ("ARM: OMAP5: id: Remove ES1.0
support") which renders FIFO resizing unnecessary.
Tested-by: Kishon Vijay Abraham I <kishon@xxxxxx>
Signed-off-by: Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx>
Prior to this there was a function dwc3_gadget_resize_tx_fifo(),
enabled via DT flag, which enumerated all the endpoints and
recalculated the TX FIFO sizes based on the transfer type of the
EPs' configuration.
Unfortunately some Qualcomm SoCs are still plagued by having
insufficient defaults, so we resort to carrying this function on our
downstream kernels. It seems TI AM57x still has this problem too?
Jack
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
