Sarah Sharp [Thu, 5 Jan 2012 00:54:12 +0000 (16:54 -0800)]
xhci: Clean up 32-bit build warnings.
Randy Dunlap points out that commit 9258c0b2 "xhci: Better debugging for
critical host errors." introduces some new build warnings on 32-bit
builds:
drivers/usb/host/xhci-ring.c:1936:3: warning: format '%016llx' expects type 'long long unsigned int', but argument 3 has type 'dma_addr_t'
drivers/usb/host/xhci-ring.c:1958:3: warning: format '%016llx' expects type 'long long unsigned int', but argument 3 has type 'dma_addr_t'
Cast the results of xhci_trb_virt_to_dma() from a dma_addr_t to an
unsigned long long.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Hans de Goede [Wed, 4 Jan 2012 22:29:18 +0000 (23:29 +0100)]
xhci: Properly handle COMP_2ND_BW_ERR
I encountered a result of COMP_2ND_BW_ERR while improving how the pwc
webcam driver handles not having the full usb1 bandwidth available to
itself.
I created the following test setup, a NEC xhci controller with a
single TT USB 2 hub plugged into it, with a usb keyboard and a pwc webcam
plugged into the usb2 hub. This caused the following to show up in dmesg
when trying to stream from the pwc camera at its highest alt setting:
xhci_hcd 0000:01:00.0: ERROR: unexpected command completion code 0x23.
usb 6-2.1: Not enough bandwidth for altsetting 9
And usb_set_interface returned -EINVAL, which caused my pwc code to not
do the right thing as it expected -ENOSPC.
This patch makes the xhci driver properly handle COMP_2ND_BW_ERR and makes
usb_set_interface return -ENOSPC as expected.
This should be backported to stable kernels as old as 2.6.32.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
Oliver Neukum [Mon, 2 Jan 2012 14:11:48 +0000 (15:11 +0100)]
USB: remove dead code from suspend/resume path
If a driver does not support the suspend/resume callbacks
it will be forcibly disconnected. There is no reason to check
for support of the callbacks after that.
Signed-off-by: Oliver Neukum <oneukum@suse.de> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sarah Sharp [Thu, 1 Dec 2011 22:50:30 +0000 (14:50 -0800)]
xhci: Better debugging for critical host errors.
When a host controller gives a bad event TRB, we should print out the
contents of the TRB as a warning so that users don't have to recompile
their kernel to get information about what went wrong. Also, print out
the event ring if they have xHCI debugging turned on, since previous
events can often explain what happened before the bad TRB occurred.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Sarah Sharp [Tue, 20 Dec 2011 00:56:04 +0000 (16:56 -0800)]
xhci: Be less verbose during URB cancellation.
With devices that can need up to 128 segments (with 64 TRBs per
segment), we can't afford to print out the entire endpoint ring every
time an URB is canceled. Instead, print the offset of the TRB, along
with device pathname and endpoint number.
Only print DMA addresses, since virtual addresses of internal structures
are not useful. Change the cancellation code to be more clear about
what steps of the cancellation it is in the process of doing (queueing
the request, handling the stop endpoint command, turning the TDs into
no-ops, or moving the dequeue pointers).
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Sarah Sharp [Thu, 1 Dec 2011 22:41:46 +0000 (14:41 -0800)]
xhci: Remove debugging about ring structure allocation.
Debuggers only really care what the xHCI driver sets the ring dequeue
pointer to, so make the driver stop babbling about the memory addresses
of internal ring structures. This makes wading through the output of
allocating and freeing 256 stream rings much easier by reducing the
number of output lines per ring from 9 to 1.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Sarah Sharp [Fri, 16 Dec 2011 01:30:45 +0000 (17:30 -0800)]
xhci: Remove debugging about toggling cycle bits.
The code for toggling the cycle bits when the ring wraps around has
worked for years. The print statement alone is not enough to indicate
there's something wrong with that code. Now that full transfer tracing
has been ripped out, the print statement or lack thereof won't help
without context of where the enqueue pointer is.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Sarah Sharp [Tue, 25 Oct 2011 11:55:30 +0000 (13:55 +0200)]
xhci: Remove useless sg-list debugging.
Remove verbose debugging about scatter-gather lists, as we haven't had
an issue with scatter gather list math for about a year now. The
debugging didn't help before, and just clutters up the log file when
trying to debug other issues.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Sarah Sharp [Thu, 22 Dec 2011 23:02:13 +0000 (15:02 -0800)]
xhci: Remove warnings about MSI and MSI-X capabilities.
xHCI host controllers may not be capable of MSI, but they should be able
to be used in legacy PCI interrupt mode. Similarly, some xHCI host
controllers will have MSI support but not MSI-X support. Lower the
dmesg log level from an error to debug. The message won't appear unless
CONFIG_USB_XHCI_HCD_DEBUGGING is turned on.
If we need to find out whether the device can support MSI or MSI-X and
it's not being enabled by the driver, it's easy to ask the user to run
lspci.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Sarah Sharp [Tue, 25 Oct 2011 11:55:30 +0000 (13:55 +0200)]
xhci: Remove scary warnings about transfer issues.
Getting a short packet or a babble error is usually a recoverable error,
so stop scaring users with warnings in dmesg when xHCI debugging is turned
off.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Sarah Sharp [Fri, 16 Dec 2011 19:26:30 +0000 (11:26 -0800)]
usbfs: Fix oops related to user namespace conversion.
When running the Point Grey "flycap" program for their USB 3.0 camera
(which was running as a USB 2.0 device for some reason), I trigger this
oops whenever I try to open a video stream:
Felipe Balbi [Mon, 28 Nov 2011 10:46:59 +0000 (12:46 +0200)]
usb: dwc3: gadget: add support for SG lists
add support for SG lists on dwc3 driver. With
this we can e.g. use VFS layer's SG lists on
storage gadgets so that we can start bigger
transfers and improve throughput.
Felipe Balbi [Mon, 28 Nov 2011 10:27:17 +0000 (12:27 +0200)]
usb: dwc3: gadget: don't force 'LST' always
the LST bit is to be set on the last of a series
of consecutive TRBs. We had a workaround for a
problem where data would get corrupted but that
doesn't happen anymore. It's likely that it was
caused by some FPGA instability during development
phase.
Felipe Balbi [Tue, 22 Nov 2011 09:11:50 +0000 (11:11 +0200)]
usb: gadget: introduce support for sg lists
Some controllers support scatter/gather transfers
and that might be very useful for some gadget drivers.
This means that we can make use of larger buffer
allocations which means we will have less completion
IRQs overtime, thus improving the perceived performance.
Heiko Stübner [Mon, 19 Dec 2011 18:42:52 +0000 (19:42 +0100)]
usb: gadget: s3c-hsudc: use release_mem_region instead of release_resource
As the memory region is requested through request_mem_region
use the correct paired method to release it in the error path
and don't go "beneath the API".
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
Heiko Stübner [Mon, 19 Dec 2011 18:42:19 +0000 (19:42 +0100)]
usb: gadget: s3c-hsudc: Add regulator handling
The udc has three supplies: vdda (3.3V), vddi (1.2V) and vddosc (1.8-3.3V).
Turn these on and off on start and stop calls.
Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Heiko Stübner [Mon, 19 Dec 2011 18:41:45 +0000 (19:41 +0100)]
usb: gadget: s3c-hsudc: use udc_start and udc_stop functions
udc_start and udc_stop reduce code duplication in comparison to
start and stop generalising calls done by all drivers
(i.e. bind and unbind) and moving these calls to common code.
Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
Heiko Stübner [Mon, 19 Dec 2011 18:41:05 +0000 (19:41 +0100)]
usb: gadget: s3c-hsudc: move device registration to probe
Instead of adding and deleting the gadget device in the start and stop
invocations. Use device_register in the probe method to initialize
and add the gadget device.
Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
Felipe Contreras [Mon, 19 Dec 2011 20:01:54 +0000 (22:01 +0200)]
usb: musb: fix pm_runtime mismatch
In musb_init_controller() there's a pm_runtime_put(), but there's no
pm_runtime_get(), which creates a mismatch that causes the driver to
sleep when it shouldn't.
This was introduced in 7acc619[1], but it wasn't triggered in my setup
until 18a2689[2] was merged to Linus' branch at point df0914[3]. IOW;
when PM is working as it was supposed to.
However, it seems most of the time this is used in a way that keeps the
counter above 0, so nobody noticed. Also, it seems to depend on the
configuration used in versions before 3.1, but not later (or in it).
I found the problem by loading isp1704_charger before any usb gadgets:
http://article.gmane.org/gmane.linux.kernel/1226122
All versions after 2.6.39 are affected.
[1] usb: musb: Idle path retention and offmode support for OMAP3
[2] OMAP2+: musb: hwmod adaptation for musb registration
[3] Merge branch 'omap-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6
Cc: stable@vger.kernel.org Cc: Hema HK <hemahk@ti.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Neil Zhang [Tue, 20 Dec 2011 05:20:21 +0000 (13:20 +0800)]
usb: gadget: mv_udc: drop ARCH dependency
This patch do the following things:
1. Change the Kconfig information.
2. Rename the driver name.
3. Don't do any type cast to io memory.
4. Add dummy stub for clk framework.
Signed-off-by: Neil Zhang <zhangwm@marvell.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Dan Carpenter [Thu, 15 Dec 2011 11:31:37 +0000 (14:31 +0300)]
usb: renesas_usbhs: silence a gcc warning
Gcc complains about this printk:
drivers/usb/renesas_usbhs/mod_gadget.c:188:3: warning: format ‘%x’
expects argument of type ‘unsigned int’, but argument 3 has type
‘dma_addr_t’ [-Wformat]
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
usb: renesas_usbhs: disable attch irq after device attached
attch interrupt might happen infinitely on some USB hub (self power?).
This patch disable attch irq after device attached,
and enable it again when detach irq happen.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
driver has to re-use the limited pipe for each device/endpoint
when it is USB host hub mode, since number of pipe has limitation.
This patch adds usbhsh_pipe_attach/detach() functions for it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Current renesas_usbhs had been assigning udev to each urb.
It was executed even though it was device0.
For this reason, the device0 had to set the new device address
which has still not been assigned. (it will be assigned on next step).
Current renesas_usbhs used fixed address for it.
but it is not good for USB hub support.
This patch modifies this issue.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Qinglin Ye [Sun, 11 Dec 2011 08:40:22 +0000 (16:40 +0800)]
USB: Remove the duplicate definition of HUB_SET_DEPTH
The macro HUB_SET_DEPTH is defined twice in ch11.h (introduced by
commit 0eadcc0 "usb: USB3.0 ch11 definitions" and dbe79bb "USB 3.0
Hub Changes"), so remove the duplicate one in the USB 2.0 part.
Signed-off-by: Qinglin Ye <yestyle@gmail.com> Cc: John Youn <John.Youn@synopsys.com> Cc: Sergei Shtylyov <sshtylyov@mvista.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Felipe Balbi [Thu, 24 Nov 2011 13:42:10 +0000 (15:42 +0200)]
usb: musb: omap2430: fix compile warning
fix the following compile warning:
drivers/usb/musb/omap2430.c: In function 'musb_otg_notifier_work':
drivers/usb/musb/omap2430.c:279:3: warning: 'return' with a value, in
function returning void
drivers/usb/musb/omap2430.c:282:2: warning: 'return' with a value, in
function returning void
Vikram Pandita [Fri, 12 Aug 2011 14:38:51 +0000 (07:38 -0700)]
usb: musb: fix pm_runtime calls while atomic
musb pm_runtime_get_sync call happens in intrrupt context on cable attach case
That can result in re-enabling the interrupts and cause side affects.
So move the code to a work queue.
Following is the error path hit on cable attach:
BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:802
in_atomic(): 0, irqs_disabled(): 0, pid: 18, name: irq/378-twl6030
Backtrace:
[<c00520f0>] (dump_backtrace+0x0/0x110) from [<c054f454>] (dump_stack+0x18/0x1c)
[<c054f43c>] (dump_stack+0x0/0x1c) from [<c007f59c>] (__might_sleep+0x130/0x134)
[<c007f46c>] (__might_sleep+0x0/0x134) from [<c02c2794>] (__pm_runtime_resume+0x94/0x98)
[<c02c2700>] (__pm_runtime_resume+0x0/0x98) from [<c033e7e4>] (musb_otg_notifications+0x9c/0x164)
[<c033e748>] (musb_otg_notifications+0x0/0x164) from [<c00b3df0>] (notifier_call_chain+0x4c/0x8c)
[<c00b3da4>] (notifier_call_chain+0x0/0x8c) from [<c00b44a8>] (__atomic_notifier_call_chain+0x40/0x54)
[<c00b4468>] (__atomic_notifier_call_chain+0x0/0x54) from [<c00b44dc>] (atomic_notifier_call_chain+0x20/0x28)
[<c00b44bc>] (atomic_notifier_call_chain+0x0/0x28) from [<c033f124>] (twl6030_usb_irq+0xc8/0xdc)
[<c033f05c>] (twl6030_usb_irq+0x0/0xdc) from [<c00d79f8>] (irq_thread_fn+0x24/0x40)
[<c00d79d4>] (irq_thread_fn+0x0/0x40) from [<c00d7b64>] (irq_thread+0x150/0x1d8)
[<c00d7a14>] (irq_thread+0x0/0x1d8) from [<c00adf70>] (kthread+0x94/0x98)
[<c00adedc>] (kthread+0x0/0x98) from [<c0094388>] (do_exit+0x0/0x720)
Tested with:
MUSB Device mode: Cold boot / Hot plug
MUSB Host mode: Cold boot / Hot plug
Felipe Balbi [Fri, 14 Oct 2011 07:22:29 +0000 (10:22 +0300)]
usb: musb: drop ARCH dependency
musb core driver and tusb6010 glue layer don't
depend on anything which is ARCH-specific. It
builds fine on x86 and ARM. Dropping the dependency
so we can compile-test on linux-next.
Arnd Bergmann [Sun, 2 Oct 2011 14:45:47 +0000 (16:45 +0200)]
usb: musb: allow building USB_MUSB_TUSB6010 as a module
Commit 1376d92f9 "usb: musb: allow musb and glue layers to be modules"
made the USB_MUSB_TUSB6010 option modular, but actually building
the driver as a module does not work, so various randconfig builds
actually fail. This changes all code that depends on the
option to also check for modular builds, and exports the necessary
symbols.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Arnd Bergmann [Sun, 2 Oct 2011 14:45:45 +0000 (16:45 +0200)]
usb: musb: use a Kconfig choice to pick the right DMA method
The logic to allow only one DMA driver in MUSB is currently
flawed, because it also allows picking no DMA driver at all
and also not selecting PIO mode.
Using a choice statement makes this foolproof for now and
also simplifies the Makefile.
Unfortunately, we will have to revisit this when we start
supporting multiple ARM platforms in a single kernel binary,
because at that point we will actually need to select
multiple DMA drivers and pick the right one at run-time.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Hema HK [Wed, 7 Sep 2011 16:19:24 +0000 (09:19 -0700)]
usb: musb: omap2+: save and restore OTG_INTERFSEL
we need to save and restore OTG_INTERFSEL register
else we will be unable to function on resume after
OFF mode.
Reported-by: Devaraj Rangasamy <dev@ti.com> Signed-off-by: Hema HK <hemahk@ti.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Vikram Pandita <vikram.pandita@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Felipe Balbi [Thu, 8 Dec 2011 11:56:27 +0000 (13:56 +0200)]
usb: dwc3: ep0: fix for possible early delayed_status
There is a very small possibility (previously unimagined
by us) that the whole Mass Storage delayed status happens
rather early, before we even get our XferNotReady event.
In that case, we will be queueing a request to ep0 while
we're still on Setup Phase and we would be waiting for
another usb_ep_queue() forever.
Handle such cases by clearing dwc->delayed_status so that
we start control status from the next XferNotReady like
there was no wait for Delayed Status.
Tested against Linux 3.2-rc3 and USB30CV tool from USB-IF
(on a Windows XP with USB3 PCIe card).
Felipe Balbi [Tue, 29 Nov 2011 11:11:21 +0000 (13:11 +0200)]
usb: dwc3: gadget: fix stream enable bit
ep->max_streams is a mere hint to the gadget
driver that 'ep' supports stream handling. Using
that as a decision variable for enabling streams
was my worst brain-fart to date.
Instead, we should check from the Superspeed
Endpoint Companion Descriptor if the endpoint
has requested streams. For that we need a little
re-factoring but it is now correct.
Debugged-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
Felipe Balbi [Tue, 29 Nov 2011 08:35:47 +0000 (10:35 +0200)]
usb: dwc3: ep0: fix GetStatus handling (again)
previous commit fixed part of it but it was still
calling usb_ep_queue() from IRQ context without
loosing locks. That cannot be done otherwise we will
have a recursive locking.
Also, we need to assign the 'dep' pointer on
dwc->ep0_usb_req otherwise we will have a NULL
pointer dereference on dwc3_map_buffer_to_dma().
usb: dwc3: ep0: use dwc3_request for ep0 requsts instead of usb_request
Instead of special functions and shortcuts for sending our internal
answers to the host we started doing what the gadget does and used the
public API for this. Since we only were using a few fields the
usb_request was enough. Later added the list handling in order to
synchronize the host / gadget events and now we require to have the
dwc3_request struct around our usb_request or else we touch memory that
does not belong to us. So this patch does this.
Reported-by: Partha Basak <p-basak2@ti.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
usb: dwc3: use correct hwparam register for power mgm check
We mask the correct bits within the wrong register. The power
optimization mode is stored hwparam1 register and not in hwparam0.
Reported-by: Partha Basak <p-basak2@ti.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
Felipe Balbi [Fri, 18 Nov 2011 19:31:14 +0000 (21:31 +0200)]
usb: dwc3: omap: move to module_platform_driver
the new module_platform_driver macro is a helper
for modules which just register and unregister the
platform_driver. It allows us to delete a few
duplicated lines.
Felipe Balbi [Fri, 14 Oct 2011 12:11:49 +0000 (15:11 +0300)]
usb: dwc3: workaround: missing disconnect event
DWC3 revisions <1.88a have an issue which would
case a missing Disconnect event if cable is
disconnected while there's a Setup packet
pending the FIFO.
Felipe Balbi [Fri, 14 Oct 2011 11:51:38 +0000 (14:51 +0300)]
usb: dwc3: workaround: missing USB3 Reset event
DWC3 revisions <1.90a have an issue which would cause
a missing USB3 Reset event. In such cases, it's
suggested that we follow the steps of a normal
USB3 Reset on Connection Done Event.
Felipe Balbi [Fri, 14 Oct 2011 10:00:30 +0000 (13:00 +0300)]
usb: dwc3: workaround: U1/U2 -> U0 transiton
RTL revisions <1.83a have an issue where, depending
on the link partner, the USB link might do multiple
entry/exit of low power states before a transfer
takes place causing degraded throughput.
The suggested workaround is to clear bits
12:9 of DCTL register if we see a transition
from U1|U2 to U0 and only re-enable that on
a transfer complete IRQ and we have no pending
transfers on any of the enabled endpoints.
usb: dwc3: gadget: return early in dwc3_cleanup_done_reqs()
This patch avoids the compiler spitting out the following warning:
|drivers/usb/dwc3/gadget.c:1304: warning: 'trb' is used uninitialized \
in this function
This is only uninitialized if the list of to-cleanup TRBs is empty which
should not be the case because we call this functions once a transfer
completed so it should be on list.
In order to make the warning disappear we return early. This should
never happen and the WARN_ON_ONCE(1) is there in case it happens
so we can investigate what went wrong.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
Since the re-worked ep0 handling (which uses HW's hints to recognize the ep0
status) we lost the delayed status handling. This is used by the file and mass
storage gadget to gain some extra time so setup its internal status before it
can proceed further requests.
In particular the storage gadget does nothing on USB_REQ_SET_CONFIGURATION but
wakes up a thread which handles the request. If the udc driver continues ep0
handling before the thread did its work then then endpoint is not yet
configured and further requests will fail. Once the gadget is ready, it will
enqueue an empty packet which is used for synchronization.
In order to fix this issue, the patch does the following:
Set ->delayed_status once the delayed_status has been notices and do not
continue on the next XferNotReady event. We will continues ep0 processing once
the gadget enqueued the zero packet for synchronization.
A cleaner approach would be to enforce the gadget to enqueue an empty
(zero) request even for the status phase but this would do for now.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
usb: dwc3: ep0: push ep0state into xfernotready processing
We wait for the XferNotReady before we start the transfer and by then we
know ep0 state in which we supposed to be.
This is some cleanup work for the following patch in which we require to
know the ep0 state before the transfer completes.
While here, also change the argument to dwc3_ep0_do_control_status() so
we don't require the complete event structure but only the required
piece of information.
Inspired-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
Felipe Balbi [Fri, 4 Nov 2011 10:40:05 +0000 (12:40 +0200)]
usb: dwc3: fix sparse errors
sparse caught three mistakes on this driver,
fix them:
drivers/usb/dwc3/ep0.c:806:29: warning: duplicate const
drivers/usb/dwc3/debugfs.c:481:15: warning: symbol 'dwc3_debugfs_init' \
was not declared. Should it be static?
drivers/usb/dwc3/debugfs.c:518:16: warning: symbol 'dwc3_debugfs_exit' \
was not declared. Should it be static?
Felipe Balbi [Fri, 4 Nov 2011 10:32:47 +0000 (12:32 +0200)]
usb: dwc3: fix few coding style problems
There were a few coding style issues with this driver
which are now fixed:
drivers/usb/dwc3/debugfs.c:48: WARNING: Use #include \
<linux/uaccess.h> instead of <asm/uaccess.h>
drivers/usb/dwc3/debugfs.c:484: ERROR: space required \
before the open brace '{'
drivers/usb/dwc3/ep0.c:261: WARNING: line over 80 characters
drivers/usb/dwc3/ep0.c:287: WARNING: suspect code indent \
for conditional statements (16, 23)
drivers/usb/dwc3/gadget.c:749: WARNING: line over 80 characters
drivers/usb/dwc3/gadget.c:1267: WARNING: line over 80 characters
drivers/usb/dwc3/gadget.h:116: WARNING: line over 80 characters
drivers/usb/dwc3/io.h:42: WARNING: Use #include \
<linux/io.h> instead of <asm/io.h>
usb: dwc3: move generic dwc3 code from gadget into core
A few inits like the scale value or the removal of the DISSCRAMBLE is
done in the gadget code however it touches a general register.
Move this piece to the core.c file since it is likely to be requied by
both, parts of the core (device and host).
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
usb: dwc3: use a helper function for operation mode setting
There are two where need to set operational mode:
- during initialization while we decide to run in host,device or DRD
mode
- at runtime via the debugfs interface.
This patch provides a new function which sets the operational mode and
moves its initialiation to the mode switch instead in the gadget code
itself.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
In "usb: dwc3: remove special status request handling in ep0" I simplied
a few things and used the generic API for the status transfers. The bug
I introcuded here is that we queue now requests to dep[1] but we don't
clear that list in the stall+start case.
Actually we don't need to use dep[1] at all. We only did in the past to
talk to the correct endpoint (i.e. in or out). This is now take care of
in a diffent place within the ep0 code. So we could queue the in
transfers to dep[0] and don't use dep[1] at all.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
Felipe Balbi [Tue, 18 Oct 2011 10:58:30 +0000 (13:58 +0300)]
usb: dwc3: omap: add multiple instances support to OMAP
if we ever have an omap with multiple instances of
the DWC3 IP, we need unique names for them. In order
to achieve that, let's use the dwc3_get/put_device_id()
calls to give us an unique device identifier.
Felipe Balbi [Tue, 18 Oct 2011 10:54:01 +0000 (13:54 +0300)]
usb: dwc3: move dwc3 device ID bitmap to core.c
if we want to support situations where we have
both SoC and PCIe versions of the IP on the same
platform, we need to have sequential numbers between
them, otherwise we will still have name collisions.
Because of that, we need to move dwc3_get/put_device_id()
to core.c and export that symbol to be used by glue
layers.
usb: dwc3: remove special status request handling in ep0
The GetStatus (STD)-request is handled the driver and uses a tiny hack
to send the two bytes long answer. This patch removes the custom hack
uses the normal usb_ep_queue() for that.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>