From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Thu, 19 Feb 2015 15:29:02 +0100 Subject: [U-Boot] DWC2 driver issues In-Reply-To: <54E236DD.3080204@wwwdotorg.org> References: <54E236DD.3080204@wwwdotorg.org> Message-ID: <201502191529.02337.marex@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.