[U-Boot] DWC2 driver issues

[Marek Vasut]

On Monday, February 16, 2015 at 07:28:45 PM, Stephen Warren wrote:
> Marek,

Hello Stephen,

> Following on from my Google+ post about DWC2/RPi USB host controller
> issues in U-Boot.
> 
> There are 3 issues I've identified so far:

so far :)

> 1)
> 
> On an RPi with the DWC2 controller connected directly to a single
> external USB connector (i.e model A, A+), a LS (and perhaps FS) device
> pluged directly into the board doesn't work due to the small max packet
> size limit.
> 
> Your patch 9b1161af8c51 "usb: dwc2: Add support for multi-packet control
> xfers" in u-boot-usb.git topic/dwc2 addresses this issue for control
> transfers at least. With your patch, I can now enumerate a USB kbd on a
> model A+. That's a great improvement; thanks for the quick response with
> a patch.

Jeroen was complaining about the same thing, so I cooked this preliminary
patch. I'm CCing him. Glad it helped, but I think the patch needs further
work.

> However, when I enable CONFIG_USB_KEYBOARD, I see errors when the USB
> 
> keyboard input driver initializes:
> > starting USB...
> > USB0:   Core Release: 2.80a
> > scanning bus 0 for devices... 3 USB Device(s) found
> > 
> >        scanning usb for storage devices... 0 Storage Device(s) found
> >        scanning usb for ethernet devices... 0 Ethernet Device(s) found
> > 
> > dev = 0df92ac0 pipe = 0x40408380 buf = 0db4a780 size = 8 int = 10
> > Failed to get keyboard state from device 413c:2010
> 
> I haven't investigated this further yet.

Wow, this error is new, I have not seen this one on SoCFPGA.

> 2)
> 
> On any RPi with a HS USB hub connected between the DWC2 controller and
> an LS/FS device (e.g. model A/A+ with external hub, model B/B+ with
> on-board hub), LS/FS devices don't work since the driver needs to issue
> USB "split transactions".

Yep. CCing Hans, the USB Guru.

> This involves communicating with the
> Transaction Translator in the USB hub nearest to the LS/FS device.
> Namely, performing each transaction first with DWC2_HCSPLT_SPLTENA, then
> repeating (perhaps polling until we get the final response?) it with
> DWC2_HCSPLT_COMPSPLT to pick up the response.
> 
> Reference:
> 
> http://www.usbmadesimple.co.uk/ums_7.htm#split_trans
> 
> http://am.renesas.com/applications/key_technology/connectivity/usb/about_us
> b/usb2_0/usb2_8/index.jsp
> 
> To fully cover both (1) and (2) for all types of transfer, I think we
> should create a couple functions to do the low-level handling of USB
> transfers:
> 
> a) Perform a large transfer by splitting it up into smaller
> transactions, each as large as the max packet size. This is what your
> patch does, but perhaps it'd be better as a separate function so the
> logic can be shared with transfer types other than control; I assume
> this size-based splitting is relevant everywhere?

Yes, and in case you look closely, the functions for doing control and
bulk transfers are almost identical in their "core" mechanics.

> b) Perform an individual transfer on the wire. This will optionally
> perform split transactions when necessary. I'm sure this will be needed
> by all transaction types.

Yes.

> Existing code that invokes USB transfers will call (a) once. (a) will
> call (b) as many times as needed to break up the packet into small
> chunks. (b) will either send the transaction to the HW (HS devices or
> directly attached LS/FS devices), or perform the split transaction
> handling (remotely attached LS/FS devices).
> 
> Does that sound like a reasonable approach?
> 
> I can start looking into getting split transactions going; I just
> couldn't motivate myself last Friday night.

Do you plan to do this on the USB stack level or USB controller driver
level please ?

> 3)
> 
> On the RPI 2, even directly attached HS devices (i.e. the on-board USB
> hub, Ethernet) don't work correctly. I haven't tracked down the cause
> yet, since I got side-tracked on the two issues above, initially
> thinking they might have the same/similar root-cause. However, I don't
> think this issue is related, since the RPi2 on-board devices don't fall
> into either of the categories above.

Do you get some kind of an error message ?

> In theory, the HW should work the same since both the BCM2835/2836 have
> the same rev of the DWC2 controller. The only difference is the CPUs and
> perhaps some bus logic. I vaguely wonder about memory barrier or timing
> issues, but who knows yet.

Which controller version is that, 2.80a in both ? I recall SoCFPGA has 2.93,
just for reference. I also recall there was some bug in the DWC2 lower than
2.90 (?), I don't remember the exact details, but this should be documented
in the DWC2 driver source code.