When File Storage gadget receives SET CONFIGURATION request it tries
to cancel all pending transfers. If some request is in progress,
gadget waits for its completion. This commit allows gadget to dequeue
invalid requests in progress left after reset.
Signed-off-by: Anton Tikhomirov <av.tikhomirov@samsung.com>
Reviewed-by: Kyoungil Kim<ki0351.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The following should be done for requests after endpoint stall
condition is cleared:
1) 'in progress' request (if any) should be completed since
Tx FIFO was flushed;
2) next request from queue (if any) should be started.
This commit does that.
Additionally set/clear stall condition code is fixed.
Signed-off-by: Anton Tikhomirov <av.tikhomirov@samsung.com>
Reviewed-by: Kyoungil Kim<ki0351.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
UDC driver does not need to generate reply to host if request is
delivered to gadget. This is gadget's responsibility. This commit
fixes that.
Signed-off-by: Anton Tikhomirov <av.tikhomirov@samsung.com>
Reviewed-by: Kyoungil Kim<ki0351.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This commit does the following:
1) clears all pending interrupts before unmasking;
2) clears interrupts as soon as possible to avoid missing
next coming that may occur during handling;
3) removes ineffective interrupt cleaning code.
Signed-off-by: Anton Tikhomirov <av.tikhomirov@samsung.com>
Reviewed-by: Kyoungil Kim<ki0351.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
To accomplish this the function to register a gadget driver takes the bind
function as a second argument. To make things clearer rename the function
to resemble platform_driver_probe.
This fixes many section mismatches like
WARNING: drivers/usb/gadget/g_printer.o(.data+0xc): Section mismatch in
reference from the variable printer_driver to the function
.init.text:printer_bind()
The variable printer_driver references
the function __init printer_bind()
All callers are fixed.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
[m.nazarewicz@samsung.com: added dbgp]
Signed-off-by: Michał Nazarewicz <m.nazarewicz@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
DEBUG is defined unconditionally, remove it as this clutters the message log.
Signed-off-by: Maurus Cuelenaere <mcuelenaere@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds support for clock gating of the HS/OTG block. On S5PV210
otg gating clock is initally disabled so the driver needs to get and
enable it before it can access its registers.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
S5PV210 SoCs has 2 USB PHY interfaces, both enabled by writing zero to
S3C_PHYPWR register. HS/OTG driver uses only PHY0, so do not touch bits
related to PHY1.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drivers/usb/gadget/s3c-hsotg.c: In function ‘s3c_hsotg_otgreset’:
drivers/usb/gadget/s3c-hsotg.c:2816: error: ‘MHZ’ undeclared (first use in this function)
drivers/usb/gadget/s3c-hsotg.c:2816: error: (Each undeclared identifier is reported only once
drivers/usb/gadget/s3c-hsotg.c:2816: error: for each function it appears in.)
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The PLL that drives the USB clock supports 3 input clocks: 12, 24 and 48Mhz.
This patch adds support to the USB driver for setting the correct register bit
according to the given clock.
This depends on the following patch:
[PATCH] ARM: S3C64XX: Add USB external clock definition
Signed-off-by: Maurus Cuelenaere <mcuelenaere@gmail.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If there is more data in the request than we could fit into a single
hardware request, then check when the OutDone event is received if
we have more data, and if so, schedule the new data instead of trying
to complete the request (and in the case of EP0, sending a 0 packet
in the middle of a transfer).
Also, move the debug message about the current transfer state before
the warning about a bad transfer.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The EP0 out limit is the same as the IN limit, so make them the same.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The maximum length for any EP0 IN request on EP0 is 127 bytes, not 128
as the driver currently has it.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Before trying a new setup transaction after getting an EP0 in complete
interrupt, check that the driver did not try and send more EP0 IN data
before enqueing a new setup transaction.
This fixes a bug where we cannot send all of the IN data in one go
so split the transfer, but then fail to send all the data as we start
waiting for a new OUT transaction
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Limit the IN FIFO write to a single packet per attempt at writing,
as per the specifications and ensure that we don't return fifo-full
so that we can continue writing packets if we have the space.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add support for the dedicated FIFO mode on newer SoCs such as the S5PV210
partly to improve support and to fix the bug where any non-EP0 IN endpoint
requires its own FIFO allocation.
To fix this, we ensure that any non-zero IN endpoint is given a TXFIFO
using the same allocation method as the periodic case (all our current
hardware has enough FIFOs and FIFO memory for a 1:1 mapping) and ensure
that the necessary transmission done interrupt is enabled.
The default settings from reset for the core point all EPs at FIFO0,
used for the control endpoint. However, the controller documentation
states that all IN endpoints _must_ have a unique FIFO to avoid any
contention during transmission.
Note, this leaves us with a large IN FIFO for EP0 (which re-uses the
old NPTXFIFO) for an endpoint which cannot shift more than a pair of
packets at a time... this is a waste, but it looks like we cannot
re-allocate space to the individual IN FIFOs as they are already
maxed out (to be confirmed).
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The USB documentation suggest that the FIFOs should be reset when a
bus reset event happens. Use the s3c_hsotg_init_fifo() to ensure that
the FIFO layout is correct and that the FIFOs are flushed before
acknowledging the reset.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In shared fifo mode (used on older SoCs) the periodic in fifo beahves
much more like a packet buffer, discarding old data when writing new
data. Avoid this by ensuring that we do not load new transactions in
when there is data sitting already in the FIFO.
Note, this may not be an observed bug, we are fixing the case that this
may happen.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fix a problem where we have been underestimating the space available in
the IN PTX/NPTX FIFOs by assuming that they where simply word aligned
instead of in number-of-words. This means all length calculations need
to be multiplied-by-4.
Note, we do not change the information about fifo size or start addresses
available to userspace as we assume the user can multiply by four easily
and is already knows these values are in words.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Up the FIFO size for the TX to 1024 entries, as this now seems to work
with all the cores. This fixes a problem when using large packets on
a core with MPS set to 512 can hang due to insufficient space for the
writes.
The hang arises due to getting the non-periodic FIFO empty IRQ but
not being able to satisfy any requests since there is never enough
space to write 512 bytes into the buffer. This means we end up with
a stream of interrupt requests.
It is easier to up the TX FIFO to fill the space we left for it
than to try and fix the positions in the code where we should have
limited the max-packet size to < TXFIFOSIZE, since the TXFIFOSIZE
depends on how the TX FIFOs have been setup.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
According to the design guide, if the FIFO layout is changed, then the
FIFOs must be flushed to ensure all FIFO pointers are correct.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The shortest period SoftDisconnect can be asserted for is 3 milliseconds
according to the V210 datasheet, so ensure that we add an msleep() to
the registration code to enforce this.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Some versions of the S3C HS OtG block startup with overlapping TX FIFO
information, so change the fifo_init code to ensure that known values
are set into the FIFO registers at initialisation/reset time.
This also ensures that the FIFO RAM pointers are in a known state
before use.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Enable soft disconnect bit the OTG core during initialization. Without this,
the host sees that a gadget is connected and tries to enumerate. The
soft disconnect should be enabled until the USB gadget driver is
registered with this otg driver.
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In an error handling case the lock is not unlocked. The return is
converted to a goto, to share the unlock at the end of the function.
A simplified version of the semantic patch that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@r exists@
expression E1;
identifier f;
@@
f (...) { <+...
* spin_lock_irqsave (E1,...);
... when != E1
* return ...;
...+> }
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Fix a reference to regs-sys.h got missed in the reorganisation of
the Samsung platform headers targetted for 2.6.34.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
This replaces deprecated dma_sync_single() with dma_sync_single_for_cpu().
There is no functional change because dma_sync_single() simply calls
dma_sync_single_for_cpu():
static inline void __deprecated dma_sync_single(struct device *dev,
dma_addr_t addr, size_t size,
enum dma_data_direction dir)
{
dma_sync_single_for_cpu(dev, addr, size, dir);
}
This fixes the following compile warnings:
drivers/usb/gadget/s3c-hsotg.c: In function 's3c_hsotg_unmap_dma':
drivers/usb/gadget/s3c-hsotg.c:376: warning: 'dma_sync_single' is deprecated (declared at /home/fujita/git/linux-2.6/include/linux/dma-mapping.h:109)
drivers/usb/gadget/s3c-hsotg.c: In function 's3c_hsotg_map_dma':
drivers/usb/gadget/s3c-hsotg.c:758: warning: 'dma_sync_single' is deprecated (declared at /home/fujita/git/linux-2.6/include/linux/dma-mapping.h:109)
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Acked-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB gadget controller drivers normally export their driver registration
function, allowing modular builds of the individual gadget drivers so
do so for s3c-hsotg, fixing builds.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Driver support for the new high-speed/OtG block that is
in the newer line of Samsung SoC devices such as the
S3C64XX series.
This driver does not currntly have DMA support enabled due
to issues with buffer alignment which need to be sorted out.
Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
