OMAP34xx EHCI bulk OUT CRC16 complementing

OMAP34xx EHCI bulk OUT CRC16 complementing

[Pandita, Vikram]

USB EHCI/OHCI experts

On omap-git v2.6.25-rc2, TI OMAP34xx EHCI controller, we are seeing a strange behavior on a bulk OUT 512 byte transfer.

We can see through the CATC that the 512 byte goes out successfully but there are many Turnaround/Timeout Errors and retries before the packet goes out successfully. 
The retries could range from 0 to 10 or more.

The error packets have 'CRC16 complemented' as per Section 8.6.4 page 234-235 that says for probably a data under-run condition:
"An error for high-speed must be forced by taking the currently calculated CRC and complementing it before transmitting it."

We have confirmed that our Memory (SDRAM) access have a much higher bandwidth available "not" to cause data under-run condition.

Where in EHCI stack should I debug for this issue? 

I am checking: qh_append_tds()
Not sure how this "Dummy" qtd is implemented. Anything to do with this? 

Is there a way to slow-down the OUT transfers on EHCI if that helps in debugging? 

Regards

Re: OMAP34xx EHCI bulk OUT CRC16 complementing

[David Brownell]

On Tuesday 19 February 2008, Pandita, Vikram wrote:
> USB EHCI/OHCI experts
> 
> On omap-git v2.6.25-rc2, TI OMAP34xx EHCI controller, we are seeing a
> strange behavior on a bulk OUT 512 byte transfer. 
> 
> We can see through the CATC that the 512 byte goes out successfully
> but there are many Turnaround/Timeout Errors and retries before the
> packet goes out successfully.   
> The retries could range from 0 to 10 or more.
> 
> The error packets have 'CRC16 complemented' as per Section 8.6.4
> page 234-235 that says for probably a data under-run condition: 
> "An error for high-speed must be forced by taking the currently
> calculated CRC and complementing it before transmitting it." 
> 
> We have confirmed that our Memory (SDRAM) access have a much higher
> bandwidth available "not" to cause data under-run condition. 
> 
> Where in EHCI stack should I debug for this issue? 

Doesn't sound like an EHCI driver issue.  I'd want to track
what's going on deeper inside the silicon than ARM instruction
set handling ... ;)


> Is there a way to slow-down the OUT transfers on EHCI if that
> helps in debugging?  

You could issue URBs with single packets.  If you're not using
the "usbtest" framework, you should start ... that command line
tool lets you send a variety of packet sequences.  You'll want
some high speed source/sink device, like another board running
the "Gadget Zero" firmware.

- Dave

[1] http://www.linux-usb.org/usbtest/