Date: Tue, 16 Dec 2008 10:44:23 -0800 From: Sam Leffler <sam@freebsd.org> To: Hans Petter Selasky <hselasky@c2i.net> Cc: Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 154573 for review Message-ID: <4947F707.4090309@freebsd.org> In-Reply-To: <4947F310.5050403@freebsd.org> References: <200812122326.mBCNQX6w024511@repoman.freebsd.org> <200812141623.51473.hselasky@c2i.net> <494598B0.9090501@freebsd.org> <200812161722.06337.hselasky@c2i.net> <4947F310.5050403@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4947F707.4090309>