| 7ac1b410 | 11-Jun-2014 |
Stephen Warren <swarren@nvidia.com> |
dfu: allow backend to specify a maximum buffer size
CONFIG_SYS_DFU_DATA_BUF_SIZE may be large to allow for FAT/ext layouts
to transfer large files. However, this means that individual write
operatio
dfu: allow backend to specify a maximum buffer size
CONFIG_SYS_DFU_DATA_BUF_SIZE may be large to allow for FAT/ext layouts
to transfer large files. However, this means that individual write
operations will take a long time. Allow backends to specify a maximum
buffer size, so that each write operation is limited to a smaller data
block. This prevents the DFU protocol from timing out when e.g. writing
to SPI flash. I would guess that NAND might benefit from setting this
value too, but I can't test that.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
show more ...
|
| dcb89b5a | 01-Jul-2014 |
Stephen Warren <swarren@nvidia.com> |
usb: ci_udc: use var name ep/ci_ep consistently
Almost all of ci_udc.c uses variable name "ep" for a struct usb_ep and
"ci_ep" for a struct ci_ep. This is nice and consistent, and helps people
know
usb: ci_udc: use var name ep/ci_ep consistently
Almost all of ci_udc.c uses variable name "ep" for a struct usb_ep and
"ci_ep" for a struct ci_ep. This is nice and consistent, and helps people
know what type a variable is without searching for the declaration.
handle_ep_complete() doesn't do this, so fix it to be consistent.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
show more ...
|
| 369d3c43 | 01-Jul-2014 |
Stephen Warren <swarren@nvidia.com> |
USB: gadget: atmel: zero out allocated requests
A UDC's alloc_request method should zero out the newly allocated request.
Ensure the Atmel driver does so. This issue was found by code inspection,
fo
USB: gadget: atmel: zero out allocated requests
A UDC's alloc_request method should zero out the newly allocated request.
Ensure the Atmel driver does so. This issue was found by code inspection,
following the investigation of an intermittent issue with ci_udc, which
was tracked down to failing to zero out allocated requests following some
of my changes. All other UDC drivers already zero out requests in one
way or another.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
show more ...
|
| 639e9903 | 01-Jul-2014 |
Stephen Warren <swarren@nvidia.com> |
usb: ci_udc: don't memalign() struct ci_req allocations
struct ci_req is a purely software structure, and needs no specific
memory alignment. Hence, allocate it with calloc() rather than
memalign().
usb: ci_udc: don't memalign() struct ci_req allocations
struct ci_req is a purely software structure, and needs no specific
memory alignment. Hence, allocate it with calloc() rather than
memalign(). The use of memalign() was left-over from when struct ci_req
was going to hold the aligned bounce buffer, but this is now dynamically
allocated.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
show more ...
|
| 6ac15fda | 01-Jul-2014 |
Stephen Warren <swarren@nvidia.com> |
usb: ci_udc: remove controller.items array
There's no need to store an array of QTD pointers in the controller.
Since the calculation is so simple, just have ci_get_qtd() perform it
at run-time, rat
usb: ci_udc: remove controller.items array
There's no need to store an array of QTD pointers in the controller.
Since the calculation is so simple, just have ci_get_qtd() perform it
at run-time, rather than pre-calculating everything.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
show more ...
|
| 7e541887 | 01-Jul-2014 |
Stephen Warren <swarren@nvidia.com> |
usb: ci_udc: fix items array size/stride calculation
2 QTDs are allocated for each EP. The current allocation scheme aligns
the first QTD in each pair, but simply adds the struct size to calculate
t
usb: ci_udc: fix items array size/stride calculation
2 QTDs are allocated for each EP. The current allocation scheme aligns
the first QTD in each pair, but simply adds the struct size to calculate
the second QTD's address. This will result in a non-cache-aligned
addresss IF the system's ARCH_DMA_MINALIGN is not 32 bytes (i.e. the
size of struct ept_queue_item).
Similarly, the original ilist_ent_sz calculation aligned the value to
ARCH_DMA_MINALIGN but didn't take the USB HW's 32-byte alignment
requirement into account. This doesn't cause a practical issue unless
ARCH_DMA_MINALIGN < 32 (which I suspect is quite unlikely), but we may
as well fix the code to be explicit, so it's obviously completely
correct.
The new value of ILIST_ENT_SZ takes all alignment requirements into
account, so we can simplify ci_{flush,invalidate}_qtd() by simply using
that macro rather than calling roundup().
Similarly, the calculation of controller.items[i] can be simplified,
since each QTD is evenly spaced at its individual alignment requirement,
rather than each pair being aligned, and entries within the pair being
spaced apart only by structure size.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
show more ...
|
| 06b38fcb | 01-Jul-2014 |
Stephen Warren <swarren@nvidia.com> |
usb: ci_udc: lift ilist size calculations to global scope
This will allow functions other than ci_udc_probe() to make use of the
constants in a future change.
This in turn requires converting the c
usb: ci_udc: lift ilist size calculations to global scope
This will allow functions other than ci_udc_probe() to make use of the
constants in a future change.
This in turn requires converting the const int variables to #defines,
since the initialization of one global const int can't depend on the
value of another const int; the compiler thinks it's non-constant if
that dependency exists.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
show more ...
|
| 8d7c39d3 | 01-Jul-2014 |
Stephen Warren <swarren@nvidia.com> |
usb: ci_udc: don't assume QTDs are adjacent when transmitting ZLPs
Fix ci_ep_submit_next_request()'s ZLP transmission code to explicitly
call ci_get_qtd() to find the address of the other QTD to use
usb: ci_udc: don't assume QTDs are adjacent when transmitting ZLPs
Fix ci_ep_submit_next_request()'s ZLP transmission code to explicitly
call ci_get_qtd() to find the address of the other QTD to use. This
will allow us to correctly align each QTD individually in the future,
which may involve leaving a gap between the QTDs.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
show more ...
|
| d7beeb93 | 01-Jul-2014 |
Stephen Warren <swarren@nvidia.com> |
usb: ci_udc: fix ci_flush_{qh,qtd} calls in ci_udc_probe()
ci_udc_probe() initializes a pair of QHs and QTDs for each EP. After
each pair has been initialized, the pair is cache-flushed. The
convers
usb: ci_udc: fix ci_flush_{qh,qtd} calls in ci_udc_probe()
ci_udc_probe() initializes a pair of QHs and QTDs for each EP. After
each pair has been initialized, the pair is cache-flushed. The
conversion from QH/QTD index [0..2*NUM_END_POINTS) to EP index
[0..NUM_ENDPOINTS] is incorrect; it simply subtracts 1 (which yields
the QH/QTD index of the first entry in the pair) rather than dividing
by two (which scales the range). Fix this.
On my system, this avoids cache debug prints due to requests to flush
unaligned ranges. This is caused because the flush calls happen before
the items[] array entries are initialized for all but EP0.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
show more ...
|
| 29425be4 | 13-Jun-2014 |
Jeroen Hofstee <jeroen@myspectrum.nl> |
usb: fastboot: fix potential buffer overflow
cb_getvar tries to prevent overflowing the response buffer
by using strncat. But strncat takes the number of data bytes
copied as a limit not the total b
usb: fastboot: fix potential buffer overflow
cb_getvar tries to prevent overflowing the response buffer
by using strncat. But strncat takes the number of data bytes
copied as a limit not the total buffer length so it can still
overflow. Pass the correct value instead.
cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
cc: Rob Herring <robh@kernel.org>
Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
show more ...
|
| 19a2a67f | 09-Jun-2014 |
Jeroen Hofstee <jeroen@myspectrum.nl> |
usb:g_dnl:f_thor: remove memset before memcpy
since ALLOC_CACHE_ALIGN_BUFFER defines a pointer and not a
buffer, the memset with sizeof(rqt) likely does something else
then intended. Since there is
usb:g_dnl:f_thor: remove memset before memcpy
since ALLOC_CACHE_ALIGN_BUFFER defines a pointer and not a
buffer, the memset with sizeof(rqt) likely does something else
then intended. Since there is a memcpy directly after it with
the full size, drop the memset completely.
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Marek Vasut <marex@denx.de>
Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
show more ...
|
| 933611f7 | 09-Jun-2014 |
Jeroen Hofstee <jeroen@myspectrum.nl> |
usb:composite: clear the whole common buffer
Since the struct fsg_common is calloced, reset it completely
with zero's when reused. While at it, make checkpatch happy.
cc: Lukasz Majewski <l.majewsk
usb:composite: clear the whole common buffer
Since the struct fsg_common is calloced, reset it completely
with zero's when reused. While at it, make checkpatch happy.
cc: Lukasz Majewski <l.majewski@samsung.com>
cc: Piotr Wilczek <p.wilczek@samsung.com>
cc: Kyungmin Park <kyungmin.park@samsung.com>
cc: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
Acked-by: Marek Vasut <marex@denx.de>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
show more ...
|
| e0672b3c | 10-Jun-2014 |
Stephen Warren <swarren@nvidia.com> |
usb: ci_udc: terminate ep0 INs with a zlp when required
Sometimes, a zero-length packet is required at the end of an IN
transaction so that the host knows the device is done sending data.
Enhance ci
usb: ci_udc: terminate ep0 INs with a zlp when required
Sometimes, a zero-length packet is required at the end of an IN
transaction so that the host knows the device is done sending data.
Enhance ci_udc to send a zlp when necessary. See the comments for
more details.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
show more ...
|
| b7c00516 | 10-Jun-2014 |
Stephen Warren <swarren@nvidia.com> |
usb: ci_udc: clean up all allocations in unregister
usb_gadget_unregister_driver() is called to tear down the USB device mode
stack. Fix the driver to stop the USB HW (which causes any attached host
usb: ci_udc: clean up all allocations in unregister
usb_gadget_unregister_driver() is called to tear down the USB device mode
stack. Fix the driver to stop the USB HW (which causes any attached host
to notice the disappearance of the device), and free all allocations
(which obviously prevents memory leaks).
Signed-off-by: Stephen Warren <swarren@nvidia.com>
show more ...
|
| bdf81611 | 10-Jun-2014 |
Stephen Warren <swarren@nvidia.com> |
usb: ci_udc: fix freeing of ep0 req
ci_ep_alloc_request() avoids allocating multiple request objects for ep0
by keeping a record of the first req allocated for ep0, and always
returning that instead
usb: ci_udc: fix freeing of ep0 req
ci_ep_alloc_request() avoids allocating multiple request objects for ep0
by keeping a record of the first req allocated for ep0, and always
returning that instead of allocating a new req. However, if this req is
ever freed, the record of the previous allocation is not cleared, so
ci_ep_alloc_request() will keep returning this stale pointer. Fix
ci_ep_free_request() to clear the record of the previous allocation.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
show more ...
|
| 43a8f25b | 10-Jun-2014 |
Stephen Warren <swarren@nvidia.com> |
usb: ci_udc: call udc_disconnect() from ci_pullup()
ci_pullup()'s !is_on path contains a cut/paste copy of udc_disconnect().
Remove the duplication by simply calling udc_disconnect() instead.
Signe
usb: ci_udc: call udc_disconnect() from ci_pullup()
ci_pullup()'s !is_on path contains a cut/paste copy of udc_disconnect().
Remove the duplication by simply calling udc_disconnect() instead.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
show more ...
|
| 006c7026 | 29-May-2014 |
Stephen Warren <swarren@nvidia.com> |
usb: ci_udc: complete ep0 direction handling
handle_setup() currently assumes that the response to a Setup transaction
will be an OUT transaction, and any subsequent packet (if any) will be an
IN tr
usb: ci_udc: complete ep0 direction handling
handle_setup() currently assumes that the response to a Setup transaction
will be an OUT transaction, and any subsequent packet (if any) will be an
IN transaction. This appears to be valid in many cases; both USB
enumeration and Mass Storage work OK with this restriction. However, DFU
uses ep0 to transfer data in both directions. This renders the assumption
invalid; when sending data from device to host, the Data Stage is an IN
transaction, and the Status Stage is an OUT transaction. Enhance
handle_setup() to deduce the correct direction for the USB transactions
based on Setup transaction data.
ep0's request object only needs to be automatically re-queued when the
Data Stage completes, in order to implement the Status Stage. Once the
Status Stage transaction is complete, there is no need to re-queue the
USB request, so don't do that.
Don't sent USB request completion callbacks for Status Stage transactions.
These were queued by ci_udc itself, and only serve to confuse the USB
function code. For example, f_dfu attempts to interpret the 0-length data
buffers for Status Stage transactions as DFU packets. These buffers
contain stale data from the previous transaction. This causes f_dfu to
complain about a sequence number mismatch.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
show more ...
|
| a2d8f929 | 29-May-2014 |
Stephen Warren <swarren@nvidia.com> |
usb: ci_udc: pre-allocate ep0 req
Allocate ep0's USB request object when the UDC driver is probed. This
solves a couple of issues in the current code:
a) A request object always exists for ep0. Pri
usb: ci_udc: pre-allocate ep0 req
Allocate ep0's USB request object when the UDC driver is probed. This
solves a couple of issues in the current code:
a) A request object always exists for ep0. Prior to this patch, if setup
transactions arrived in an unexpected order, handle_setup() would need
to reply to a setup transaction before any ep0 usb_req was created.
This issue was introduced in commit 2813006fecda "usb: ci_udc: allow
multiple buffer allocs per ep."
b) handle_ep_complete no longer /has/ to queue the ep0 request again
after every single request completion. This is currently required, since
handle_setup() assumes it can find some request object in ep0's request
queue. This patch doesn't actually stop handle_ep_complete() from always
requeueing the request, but the next patch will.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
show more ...
|