This has been tested to the extent that I can enumerate
a asix usb networking adapter and boot a kernel over usb
on the 96boards hikey u-boot port I'm currently doing.
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
IIUC, interrupt transfers are NAK'd by devices until they wish to trigger
an interrupt, and e.g. EHCI controllers retry these in HW until they are
ACK'd. However, DWC2 doesn't seem to retry, so we need to do this in SW.
In practice, I've seen DWC2_HCINT_FRMOVRUN happen too. I'm not quite sure
what this error implies; perhaps it's related to how near the end of a
USB frame we're at when the interrupt transfer is initiated? Anyway,
retrying this temporary error seems to be necessary too.
With all these commits applied, both my USB keyboards (one LS Lenovo and
one FS Dell) work correctly when there is no USB hub between the SoC and
the keyboard; We still need split transactions to be implemented for hubs
to work.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
As best I can tell, there's no difference between bulk and interrupt
transfers in terms of how the HW should be programmed, at least given
that we're executing one transaction at a time rather than scheduling
them into frames for maximum throughput.
This patch ends up sharing the toggle bit state between bulk and
interrupt transfers on a particular EP. However I believe this is fine;
AFAIK a given EP either uses bulk or interrupt transfers and doesn't mix
them.
This patch doesn't do anything with the "interval" parameter for
interrupt transfers, but then most other USB controller drivers in U-Boot
don't either.
It turns out that one of my keyboards is happy to work using control
transfers but the other only gives non-zero "HID reports" via interrupt
transfers.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
A bit must be set in HCCHAR when communicating with low-speed devices.
I have no idea why there's no corresponding bit to distinguish between
full-speed and high-speed devices, but no matter; they all work now!
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
This doesn't make my LS keyboard work any better, but it does at least
report the correct speed in "usb tree".
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Use of these APIs is required on the Raspberry Pi. With this change, USB
on RPi1 should be more reliable, and USB on the RPi2 will start working.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
When I created wait_for_chhltd(), I noticed that some instances of the
code it replaced expected the ACK bit to be set and others didn't. I
assumed this was an accidental inconsistency in the code, so wrote
wait_for_chhltd() to always expect ACK to be set. This code appeared to
work correctly for both enumeration of USB keyboards and operation of
USB Ethernet devices. However, this change broke USB Mass Storage (at
least my USB SD card reader). This change reverts to exactly the
original behaviour. I'm not sure why the ACK bit isn't always set
(perhaps a quirk in the USB HW or DWC2 controller), but the code works
this way!
Fixes: 5be4ca7d6ac8 ("usb: dwc2: unify waiting for transfer completion")
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Each USB transfer is split up into chunks that are held in an aligned
buffer. This imposes a limit on the size of each chunk, but no limit on
the total size of transferred data. Fix the logic in chunk_msg() not to
reject large transfers, but simply take the size of the aligned buffer
into account when calculating the chunk size.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
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 <swarren@wwwdotorg.org>
The control data toggle resets to DATA1 at the start of the data phase
of every setup transaction. We don't need a global variable to store
the value; we can just store it on the stack.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Move the body of submit_bulk_msg() into new function chunk_msg(). This
can be shared with submit_control_msg() to reduce code duplication, and
allow control messages larger than maxpacket.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
U-Boot has never cared about the type when we get max/min of two
values, but Linux Kernel does. This commit gets min, max, min3, max3
macros synced with the kernel introducing type checks.
Many of references of those macros must be fixed to suppress warnings.
We have two options:
- Use min, max, min3, max3 only when the arguments have the same type
(or add casts to the arguments)
- Use min_t/max_t instead with the appropriate type for the first
argument
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Pavel Machek <pavel@denx.de>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
[trini: Fixup arch/blackfin/lib/string.c]
Signed-off-by: Tom Rini <trini@ti.com>
This is the USB host controller used on the Altera SoCFPGA and Raspbery Pi.
This code has three checkpatch warnings, but to make sure it stays at least
readable and clear, these are not fixed. These bugs are in the USB request
handling combinatorial logic, so any abstracting of those is out of question.
Tested on DENX MCV (Altera SoCFPGA 5CSFXC6C6U23C8N) and RPi B+ (BCM2835).
Signed-off-by: Oleksandr Tymoshenko <gonzo@bluezbox.com>
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chin Liang See <clsee@altera.com>
Cc: Dinh Nguyen <dinguyen@altera.com>
Acked-by: Pavel Machek <pavel@denx.de>
Cc: Vince Bridgers <vbridger@altera.com>
Tested-by: Dinh Nguyen <dinguyen@opensource.altera.com>
