On 03/09/2015 06:46 AM, Marek Vasut wrote:
On Sunday, March 08, 2015 at 06:08:13 PM, Stephen Warren wrote:
The original aligned_buffer usage:
a) Uselessly copied data into the aligned buffer even for IN
transactions. Fix this my making the copy conditional.
b) Always programmed the HW to transfer to/from the start of the aligned
buffer. This worked fine for OUT transactions since the memcpy copied
the OUT data to this location too. However, for large IN transactions,
since the copy from the aligned buffer to the "client" buffer was
deferred until after all chunks were transferred. it resulted in each
chunk's transfer over-writing the data for the first transfer. Fix
this by copying IN data as soon as it's received.
Signed-off-by: Stephen Warren <swar...@wwwdotorg.org>
Applied to u-boot-usb/topic/dwc2, thanks. I would like to see more
testing from others if possible, otherwise this will go in after
2015.04 if you're fine with that.
Yes, that makes sense at this point in the cycle.
BTW, I should have mentioned the result of these on the RPi, although
they're much the same as with the earlier patch you posted to support
>max_packet_size control transfers:
* I can enumerate a USB keyboard directly attached to the SoC, without
intervening hub.
* If I enable USB keyboard support in U-Boot, and configure it to poll
via the control EP or interrupt EP (I implemented the submit_interrupt
function identically to submit_bulk), it will roughly work, except:
** The system usually hangs up very shortly after detecting the USB
keyboard. Sometimes it lasts a long time though. This appears to be a
hard hang; if I force the timer module to generate an IRQ, then
typically I would see U-Boot spew the PC/SP/... when the IRQ fires.
However, if the timer IRQ is scheduled to fire after the USB-related
hang, nothing is printed. I need to try JTAG I guess.
** When polling via the interrupt EP, the character repeat is massively
too fast; much faster than on e.g. NVIDIA Tegra Seaboard with the same
keyboard polling option selected. It seems that USB IN transactions
often repeat without actually writing to the IN data buffer, although I
can't see any status in the registers indicating that the transaction
was NAK'd/NYET'd/failed. I wonder if I need to manually delay
transactions with this controller - do EHCI controllers hold off
interrupt transactions automatically and only submit them to the bus at
a low rate?
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
