On 07/13/2013 04:34 PM, Paul Zimmerman wrote: >> From: Stephen Warren [mailto:swarren@xxxxxxxxxxxxx] >> Sent: Monday, July 08, 2013 8:41 PM >> >> On 07/08/2013 03:40 PM, Paul Zimmerman wrote: >>>> From: Stephen Warren [mailto:swarren@xxxxxxxxxxxxx] >>>> Sent: Tuesday, July 02, 2013 7:41 PM >>>> >>>> On 07/02/2013 07:47 PM, Stephen Warren wrote: >>>>> On 06/26/2013 02:20 PM, Paul Zimmerman wrote: >>>> ... >>>>>> I hope whoever is supporting the Pi in the mainline kernel will try adding >>>>>> dwc2 support now that it seems to be working. I'm not sure who that would >>>>>> be, though. >>>>> >>>>> Well, it appears to work! I tested it on both a model A and B (rev 2) >>>>> and devices enumerate on the bus OK now. I haven't actually tested data >>>>> transfer yet though. >>>> >>>> ... although unfortunately, pretty much any use of the USB devices >>>> crashes or hangs the kernel:-( I guess due to the wildly varying >>>> symptoms, there is some random memory corruption going on. >>>> >>>> I did manage to dd about 1MiB off an SD card in a USB->SD card adapter >>>> (with powered hub between the adapter and the Pi), but often just >>>> plugging in the card or having it plugged in during boot causes hangs >>>> and crashes. Similarly, I have a ZD1211 WiFi USB adapter, and having >>>> that plugged during boot in causes all kinds of oops within a few or >>>> tens of seconds after booting, in code unrelated to USB or networking. >>>> >>>> Paul, are you able to try out upstream Linux and see what the issue >>>> might be? The following G+ post should outline the steps required: >>>> >>>> https://plus.google.com/101715070573995136397/posts/gWkwrfNfYVm >>>> >>>> although these days you might want to use u-boot.git not u-boot-arm.git >>>> (or perhaps git://github.com/swarren/u-boot.git rpi_dev), and >>>> git://github.com/swarren/linux-rpi.git rpi_dev to get the USB enabled. > > ... > >>> I suspect the majority of the issues you saw are due to missing dt >>> support for several of the module parameters that need to be set to >>> non-default values for the pi, like the DMA mode and the FIFO sizes. >> >> Hmm. I thought the HW config registers reflected exactly how the USB HW >> was synthesized? It'd be odd to have registers that attempt to reflect >> that, but actually have incorrect data! I vaguely recall an earlier >> version of the DWC2 driver complaining, or perhaps even outright >> refusing to initialize(?), if the parameters provided to th driver >> didn't match up with the values in the HW registers. > > Hi Stephen, > > I just sent out a patch series with a number of fixes for the dwc2 > driver. With that, plus the hack patch below to add all the driver > parameters from the downstream Pi kernel, the driver is working > pretty well. Yes, it looks mostly pretty good. I've downloaded over 100MB of package updates over the built-in USB wired Ethernet, dd'd a fair number of GB off a USB SD card reader to /dev/null, and used a USB keyboard/touchpad to control X. This all worked mostly just fine. I did see the network connection randomly drop out a couple of times early on, and occasionally get hangs accessing lots of data on the USB SD card reader, and I still can't get the SD card reader to notice card plug/unplug. But as I said, it's all mostly fine. Thanks for fixing it up! > However, I am seeing an issue that I don't think is caused by the > driver. If I copy a large file from a thumb drive to the SD card, the > mmcqd process starts taking 90%+ of the CPU, and the whole system > slows to a crawl. After several seconds of that, it returns to > normal. I believe there's no DMA support enabled in the SDHCI host controller driver right now, so that might explain that. > I'm not sure how many of the below driver parameters are actually > required. I think as least the three fifo size parameters, plus > max_transfer_size and max_packet_count, are needed. I'm curious why any of them are required; why aren't the values embedded in the HW registers correct? -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
