[U-Boot] DWC2 driver issues

Stephen Warren swarren at wwwdotorg.org
Fri Feb 20 04:22:58 CET 2015


On 02/19/2015 07:29 AM, Marek Vasut wrote:
> On Monday, February 16, 2015 at 07:28:45 PM, Stephen Warren wrote:
>> Marek,
> ...
>> 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 ?

I expect I'd put at least the split transaction stuff into the USB
controller driver. While I'm not that familiar with anything other than
standard EHCI, I'd guess the need to manually manage split transaction
was unique to DWC2?

The split of transfers into max-packet-sized transfers could plausibly
be useful in the core, but again my guess is that the need to do this is
DWC2-specific?

>> 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 ?

Yes. It's similar to the message about "can't read descriptor" that I
used to get with a LS device on the original RPis, which is why I
started looking at keyboards. Your patch to split up large transactions
didn't affect this, so I believe they're separate issues now.

>> 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.

Yes, both are 2.80a according to what the driver prints.


More information about the U-Boot mailing list