The Inventra DMA engine used with the MUSB controller in many
SoCs cannot use DMA for control transfers on EP0, but can use
DMA for all other transfers.
The USB core maps urbs for DMA if hcd->self.uses_dma is true.
(hcd->self.uses_dma is true for MUSB as well).
Split the uses_dma flag into two - one that says if the
controller needs to use PIO for control transfers, and
another which says if the controller uses DMA (for all
other transfers).
Also, populate this flag for all MUSB by default.
(Tested on OMAP3 and OMAP4 boards, with EHCI and MUSB HCDs
simultaneously in use).
Signed-off-by: Maulik Mankad <x0082077@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Cc: Oliver Neukum <oliver@neukum.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Praveena NADAHALLY <praveen.nadahally@stericsson.com>
Cc: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Fixes below compilation warning when musb driver is compiled for
PIO mode:
drivers/usb/musb/musb_gadget.c: In function 'musb_g_rx':
drivers/usb/musb/musb_gadget.c:840:
warning: label 'exit' defined but not used
Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
If RXCSR_AUTOCLEAR flag is not cleard before PIO reading, one packet
may be recieved by musb fifo, but no chance to notify
software, so cause packet loss, follows the detailed process:
- PIO read one packet
- musb fifo auto clear the MUSB_RXCSR_RXPKTRDY
- musb continue to recieve the next packet, and MUSB_RXCSR_RXPKTRDY
is set
- software clear the MUSB_RXCSR_RXPKTRDY, so there is no chance for
musb to notify software that the 2nd recieved packet.
The patch does fix the g_ether issue below:
- use fifo_mode 3 to enable double buffer
- 'ping -s 1024 IP_OF_BEAGLE_XM'
- one usb packet of 512 byte is lost, so ping failed,
which can be observed by wireshark
note:
Beagle xm takes musb rtl1.8 and may fallback to pio mode
for unaligned buffer.
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Buffer is mapped to dma when dma channel is
allocated. If, for some reason, dma channel
programming fails, musb code will fallback
to PIO mode to transfer that request. In
that case, we need to unmap the buffer
back to CPU.
MUSB RTL1.8 and above cannot handle buffers
which are not 32bit aligned. That happens to
every request sent by g_ether gadget
driver. Since the buffer sent was unaligned,
we need to fallback to PIO.
Because of that, g_ether was failing due
to missing buffer unmapping.
With this patch and [1] g_ether works fine
with all MUSB revisions.
Verified with OMAP3630 board, which has
MUSB RTL1.8 using g_ether and g_zero.
[1] http://www.spinics.net/lists/linux-usb/msg38400.html
Signed-off-by: Hema HK <hemahk@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The Inventra DMA engine in version 1.8 and later of the MUSB
controller cannot handle DMA addresses that are not aligned
to a 4 byte boundary. It ends up ignoring the last two bits
programmed in the DMA_ADDR register. This is a deliberate
design change in the controller and is documented in the
programming guide.
Earlier versions of the controller could handle these
accesses just fine.
Fail dma_channel_program if we see an unaligned address when
using the newer controllers, so that the caller can carry out
the transfer using PIO mode.
(Current callers already have this backup path in place).
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Tested-by: Ming Lei <tom.leiming@gmail.com>
Cc: Ajay Kumar Gupta <ajay.gupta@ti.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
musb_gadget_queue() checks for '!req->buf' condition twice:
in the second case the code is both duplicated and unreachable
as the first check returns early.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
In order to not touch the driver file for different xtal usage,
push the clkin value to board file and calculate the register
value instead of hardcoding it.
Signed-off-by: Bob Liu <lliubbo@gmail.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
We need to restart the timer in order to recognize USB devices in
host-only mode.
Signed-off-by: Bob Liu <lliubbo@gmail.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Split the USB MMR init steps out into a helper func that both the platform
init and the resume code may call.
Then while suspending, the gpio_vrsel will change from high to low which
will generate a wakeup event and resume the system immediately, so we need
to manually drive it low before we sleep.
Signed-off-by: Bob Liu <lliubbo@gmail.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Since clock support is optional across processors, don't make the whole
musb pm paths depend upon it. Just conditionalize the clock accesses.
Signed-off-by: Bob Liu <lliubbo@gmail.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The new MUSB power code needs musb_read_txhubport() to
return a value (so stub it as 0 like the other Blackfin
hub funcs).
Signed-off-by: Ian Jeffray <ian@jeffray.co.uk>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Commit 9f445cb29918dc488b7a9a92ef018599cce33df7[USB: musb: disable
double buffering for older RTL versions] tries to disable double
buffer mode by writing endpoint hw max packet size to TXMAP/RXMAP.
First the approach can break full speed and cause overflow problems.
We should always set those registers with the actual max packet size
from endpoint descriptor.
Second, the problem describe by commit 9f445cb299
was caused by musb gadget driver; nothing to do with RTL revision as
originaly suspected.
The real fix to the problem is to always use actual max packet
size from endpoint descriptor to config TXMAP/RXMAP registers.
Cc: Cliff Cai <cliff.cai@analog.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Anand Gadiyar <gadiyar@ti.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: stable@kernel.org
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Some actions like musb_platform_exit are only performed on module
removal and not on shutdown, which results in PHY being left enabled
on reboot at least. This is sometimes causing strange failures after
reboot (observed on OMAP3 pandora board), when DEVCTL does not report
VBUS state correctly due to unknown reasons (possibly because of
communication issues between musb IP and PHY). Running
musb_platform_exit before reset seems to resolve that issue.
Move some exit code from musb_remove() to musb_shutdown() so that it
is performed on both module removal and shutdown/reset. Also convert
the host check so that it doesn't need #ifdef.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
In function musb_gadget_setup() call put_device()
when device_register() fails.
Signed-off-by: Rahul Ruikar <rahul.ruikar@gmail.com>
Acked-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
1, In Rx double buffer case, FIFO may have two packets, so
rxstate should be called to unload fifo if RXPKTRDY is set
even the current request has not been completed.
2, Commit 633ba7876b96ec339ef685357e2f7c60b5a8ce85
introduces autoclear to support double buffer in dma mode 0,
so remove clearing RXPKTRDY manually for dma mode 0.
3, Commit c7af6b29ffeffbeb28caf39e5b2ce29b11807c7d may break
dma mode 1 for non-doublebuffer endpoint, fix it.
With this patch, either usbtest #5 or g_file_storage(writing
file to device in usb host) or g_ether have been tested OK in
double buffer case(using fifo mode 3). Also, this patch has
been verified that single buffer case can't be broken.
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Anand Gadiyar <gadiyar@ti.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
AM35x supports only 32bit read operations so we need to have
workaround for 8bit and 16bit read operations.
Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
AM35x has musb interface and uses CPPI4.1 DMA engine.
Current patch supports only PIO mode. DMA support can be
added later once basic CPPI4.1 DMA patch is accepted.
Also added USB_MUSB_AM35X which is required to differentiate musb ips
between OMAP3x and AM35x. This config would be used to for below
purposes,
- Select am35x.c instead of omap2430.c for compilation
at drivers/usb/musb directory. Please note there are
significant differneces in these two files as musb ip
in quite different on AM35x.
Please note that in multi omap configuration only omap2430.c
file will get compiled and we would require to select only
AM35x based board config to compile am35x.c
- Select workaround codes applicable for AM35x musb issues.
one such workaround is for bytewise read issue on AM35x.
Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
For all modules, change <module>-objs to <module>-y; remove
if-statements and replace with lists using the kbuild idiom; move
flags to the top of the file; and fix alignment while trying to
maintain the original scheme in each file.
None of the dependencies are modified.
Signed-off-by: matt mooney <mfm@muteddisk.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Blackfin's musb_platform_exit() forgets to call usb_nop_xceiv_unregister().
While fixing this, also remove the unneeded blank line there.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Cc: stable <stable@kernel.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Since commit 461972d8a4 (musb_core: don't call
musb_platform_exit() twice), unloading the driver module results in a WARNING
"kobject: '(null)' (c73de788): is not initialized, yet kobject_put() is being
called." (or even kernel oops) on e.g. DaVincis, though only in the OTG mode.
There exists dubious and unbalanced put_device() call in musb_free() which
takes place only in the OTG mode. As this commit caused musb_platform_exit()
to be called (and so unregister the NOP transceiver) before this put_device()
call, this function references already freed memory.
On the other hand, all the glue layers miss the otg_put_transceiver() call,
complementary to the otg_get_transceiver() call that they do. So, I think
the solution is to get rid of the strange put_device() call, and instead
call otg_put_transceiver() in the glue layers...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 633ba7876b96ec339ef685357e2f7c60b5a8ce85 broke
g_file_storage functionality by enabling AUTOCLEAR on
all cases without caring for all gadget drivers.
This patch will only enable AUTOCLEAR if our endpoint's
FIFO was configured with double buffering support. Note
this is not a complete fix, double buffered case still
doesn't work always, but that hasn't been working for
quite some time. Other than reverting the entire commit
and breaking testusb with double buffered case again,
I decided it was better to fix the single buffered case
and spend more time fixing double buffered case properly.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes the problem reported by Sergei:
>how come? we need to send ZLP before giving back the request.
>Well, look at the code ionce again. We need to send ZLP *after*
>request->actual == request->length, but as the check is inserted
>after the ZLP send, ZLP *may* be sent once the first DMA completes,
>not the last.
The patch also has been discussed on the link below:
http://marc.info/?t=128454814900001&r=1&w=2
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Reported-by: Sergei Shtylyov <sshtylyov@mvista.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Anand Gadiyar <gadiyar@ti.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This will ignore any SESSREQ interrupt if musb is B state.
Charger detection may cause spurious SESSREQ interrupts.
Signed-off-by: Heikki Krogerus <ext-heikki.krogerus@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
musb_g_rx() always returns if next_request() call yields NULL, so the DBG()
near the function's end can never be invoked. Remove it along with unneeded
'return'; also remove the duplicate 'request' check...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Wrap flags with uninitialized_var() to suppress this:
drivers/usb/musb/cppi_dma.c:1158: warning: 'flags' may be used uninitialized
in this function
Signed-off-by: Jon Povey <jon.povey@racelogic.co.uk>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add support for MUSB Host DMA transfers greater than max
channel length, so that such transfers won't be truncated.
Signed-off-by: Anil Shetty <anil@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Since not all platforms are using the same offset 0x10 in
musb_save/restore_context() eg Blackfin the offset is 0x40,
Change the indexed address to direct.
Signed-off-by: Bob Liu <lliubbo@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The USB stack maps the buffer for DMA if the controller supports DMA.
MUSB controller can perform DMA as well as PIO transfers.
The buffer needs to be unmapped before CPU can perform
PIO data transfers.
Export unmap_urb_for_dma() so that drivers can perform
the DMA unmapping in a sane way.
Signed-off-by: Maulik Mankad <x0082077@ti.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
MUSB's DMA controller max channel length was set to 64k.
Transfer length greater than this max value is being truncated.
Signed-off-by: Anil Shetty <anil@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch has been tested OK on beagle B5 board and
use usbtest #15 and #16 as testcase.
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Reviewed-by: Sergei Shtylyov <sshtylyov@mvista.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Anand Gadiyar <gadiyar@ti.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Enabling CONFIG_USB_MUSB_DEBUG option causes -DDEBUG to be added to gcc's
command line, however the DBG() macro doesn't depend on DEBUG, so that the
debugging messages get printed regardless of the option, and I don't think
that this was intended. Get rid of otherwise unused xprintk() macro and make
DBG() macro directly call pr_debug() which only results in the actual code
generated if DEBUG is defined.
This change makes musb_hdrc.o ~30% less in size with CONFIG_USB_MUSB_DEBUG
disabled (in host mode).
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.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>
Commit 46034dca51 (USB: musb_gadget_ep0: stop
abusing musb_gadget_set_halt()) forgot to restart a queued request after
clearing the endpoint halt feature. This results in a couple of USB resets
while enumerating the file-backed storage gadget due to CSW packet not being
sent for the MODE SENSE(10) command.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: stable@kernel.org
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes the issue which was observed while transfering
a large file ( > 20MB) over USB (OMAP MUSB controller acts as USB host)
to an attached USB thumb drive.
It was found that CDB field of CBW packet was set to 0x0. This was
due to missing a barrier before DMA engine starts transfer.
This buffer is allocated using dma_alloc_coherent which gives
non-cacheble but bufferable memory and hence needed a write
memory barrier to flush the write buffer.
More info on this thread is here:
http://www.spinics.net/lists/linux-omap/msg33987.html
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Maulik Mankad <x0082077@ti.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
DMA length should not go beyond the availabe space
of request buffer, so fix it.
Also set max_len of cppi dma channel as max size of
int type, so make musb dma handling happier.
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Anand Gadiyar <gadiyar@ti.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Complete the current request only if the data transfer is over.
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Anand Gadiyar <gadiyar@ti.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
DMA length should not go beyond the availabe space of request buffer,
so fix it.
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Acked-by: Anand Gadiyar <gadiyar@ti.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Anand Gadiyar <gadiyar@ti.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes one bugs of OUT transfer in double buffer case:
-the current code only enable autoclear for dma mode 1, and not
for dma mode 0
Without this patch, test #5 of usbtest can't be passed if we
configure musb as g_zero and use fifo mode 3 to enable double
buffer mode.
With this patch and the following patch(fix dma length),
on my beagle B5, test#5(queued bulk out) may go beyond
18Mbyte/s(seems dma mode 0 is quicker in double buffer case)
if musb is configured as g_zero and fifo mode 3 is taken, follows
the test command:
#./testusb -D DEV_NAME -c 1024 -t 5 -s 32768 -g 8 [1]
Also I have tested this patch can't make g_ether broken.
[1],source of testusb : tools/usb/testusb.c under linux kernel;
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Anand Gadiyar <gadiyar@ti.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes one infinite hang of bulk IN transfer in double buffer
case, the hang can be observed easily by test #6 of usbtest if musb is
configured as g_zero and fifo mode 3 is taken to enable double fifo.
In fact, the patch only removes the check for non-empty fifo before
loading data from new request into fifo since the check is not correct:
-in double buffer case, fifo may accommodate more than one packet,
even though it has contained one packet already and is non-empty
-since last DMA is completed before calling musb_g_tx, it is sure
that fifo may accommodate at least one packet
Without applying the patch, new requst enqueued from .complte may not
have a chance to be loaded into fifo, then will never be completed and
cause infinite hangs.
With the patch, on my beagle B5, test#6(queued bulk in) can be passed and
test result may go beyond 33Mbyte/s if musb is configured as g_zero and
fifo mode 3 is taken, follows the test command:
#testusb -D DEV_NAME -c 1024 -t 6 -s 32768 -g 8 [1]
[1],
-source of testusb : tools/usb/testusb.c under linux kernel;
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Acked-by: Anand Gadiyar <gadiyar@ti.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Anand Gadiyar <gadiyar@ti.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
seq_files use the private_data field of a file struct for storing a seq_file structure,
data should be stored in seq_file's own private field (e.g. file->private_data->private)
Otherwise seq_release() will free the private data when the file is closed.
Signed-off-by: Mathias Nyman <mathias.nyman@nokia.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This is a patch for the musb usb controller.
It allows forwarding of the debug mode feature to its gadget in order
to be able to act as an ehci debug device.
This patch has been tested on an IGEPv2 board running a 2.6.35-rc1
kernel.
Signed-off-by: Stephane Duverger <stephane.duverger@gmail.com>
Cc: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There is no reason for the DMA channel program to override the
DMA mode passed down by its caller. Use the passed parameter
directly, and let the caller handle the decision on which mode
is to be used.
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Acked-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This pin-muxing is best done in the board files. The driver should
not do this explicitly.
Also, this code causes a warning to be thrown when OMAP2430 and OMAP3/4
support are enabled in the same kernel.
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Acked-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Anand Gadiyar
Ajay Kumar Gupta
Ming Lei
Hema Kalliguddi
Sergei Shtylyov
Heikki Krogerus
Bob Liu
Ian Jeffray
Grazvydas Ignotas
Rahul Ruikar
matt mooney
Felipe Balbi
Heikki Krogerus
Jon Povey
T. S., Anil Kumar
Maulik Mankad
Uwe Kleine-König
Santosh Shilimkar
Mathias Nyman
stephane duverger