PERFORCE change 154573 for review

[Sam Leffler]

Sam Leffler wrote:
> Hans Petter Selasky wrote:
>> On Monday 15 December 2008, Sam Leffler wrote:
>>  
>>> Hans Petter Selasky wrote:
>>>    
>>>> On Saturday 13 December 2008, Sam Leffler wrote:
>>>>      
>>>>> Hans Petter Selasky wrote:
>>>>>        
>>>>>> On Saturday 13 December 2008, Sam Leffler wrote:
>>>>>>           
>>>>> No.  But if you are interested in helping debug the problem I'm 
>>>>> happy to
>>>>> send you debug output.  The controller rejects all cmds setting the
>>>>> ERRINT status bit.  The qTD contents and xfer contents look fine 
>>>>> but I
>>>>> haven't been able to identify the cause given the overlay qTD 
>>>>> contents.
>>>>> I'm in the process of collecting comparative traces from linux 
>>>>> where usb
>>>>> works.
>>>>>         
>>>> Send me the EHCI traces and I will have a look at it. Have you tried
>>>> USB2? The patches which you need to apply should be similar.
>>>>       
>>> This is what I get w/ sysctl hw.usb.ehci.debug=6 for the first cmd
>>> submitted after card insert:
>>>
>>>     
>>
>>  
>>> Subsequent cmds fail similarly.  I don't see the issue and don't
>>> understand how to use the overlay qTD information to pinpoint the 
>>> reason
>>> the controller is rejecting the request.
>>>
>>> This happens w/ either of the 2 USB ports (1 port / controller):
>>>
>>>     
>>
>> Hi Sam,
>>
>> The overlay qTD is a copy of the last processed QTD. You might need 
>> to do a cache invalidate on the memory region before reading it.
>>   
>
> Yes, this is what the docs says about the overlay qTD but what do the 
> 2nd and later words mean?  They went from:
>
> buffer[0]=0x014b8a3c
> buffer[1]=0x00000000
> buffer[2]=0x00000000
> buffer[3]=0x00000000
> buffer[4]=0x00000000
>
> to:
>
> buffer[0]=0x014b8a3c
> buffer[1]=0x00000008
> buffer[2]=0x00000000
> buffer[3]=0x00000000
> buffer[4]=0x00000000
>
> All memory allocated to hold usb data structures are allocated 
> coherent so should not require an invalidate.  I have also inserted 
> explicit dcache invalidates while debugging this issue "just in case".
>
> USB works fine on another xscale platform where the usb controller is 
> on the pci bus so I'd expect any cache coherency issues to already be 
> dealt with (I found the PIO cache invalidate issue I fixed a while 
> back on this other board).
>
>> What I see:
>>
>> - The first TD completed successfully, and that TD had a lower 
>> physical memory adddress than the one that failed.
>>
>>  buffer[0]=0x01091fc8
>>
>> vs:
>>
>>  buffer[0]=0x014b8a3c
>>
>> - Halted usually means that that you had a STALL token sent from the 
>> device to the host, which indicates that the contents of the SETUP 
>> packet (PID=2), in the first TD did not contain valid data, possible 
>> due to a missing cache flush.
>>
>>         return ((status & EHCI_QTD_HALTED) ?
>>             USB_ERR_STALLED : USB_ERR_NORMAL_COMPLETION);
>>
>>   
> So maybe this answers one question I have; is this error from the 
> device or the controller?  Am I actually talking to the device?  It 
> appears the controller is functional as I get interrupts, get status 
> for things like ports, etc.  Remember this is a big-endian host.  On 
> another xscale platform the usb controller is on the pci bus and we 
> setup xfers (dma+pio) to be swizzled by the byte lane hardware so 
> everything just works wrt little-endian-ness.  I've been searching for 
> something byte-order related that is missing.  The linux usb code 
> swizzles descriptor contents on the host but I don't see it doing 
> anything to the data sent to the device; it's still little-endian.
>
Er, scratch the "dma" byte swizzle comment, it's just pio that's handled 
by the byte lane h/w in the pci-ahb bus glue.

    Sam