Only allow USE_MODE1 when the Blackfin part is not affected by anomaly
05000456 (USB Receive Interrupt Is Not Generated in DMA Mode 1) since we
can't support the mode in that case.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Cliff Cai <cliff.cai@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add some helpful notes about how the driver works around different
anomalies that exist in the on-chip host controller.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Cliff Cai <cliff.cai@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Do not allow MUSB driver to be selected on derivatives that don't have the
MUSB controller on them.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Bryan Wu <cooloney@kernel.org>
Signed-off-by: Cliff Cai <cliff.cai@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The Blackfin version of musb_read_target_reg_base() returns a u16 when the
common code expects a (void __iomem *), so update the Blackfin function to
return the right value. This fixes the compile warning:
drivers/usb/musb/musb_core.c: In function 'musb_core_init':
drivers/usb/musb/musb_core.c:1448: warning: assignment makes pointer from
integer without a cast
Signed-off-by: Bryan Wu <cooloney@kernel.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Otherwise gcc will whine about epnum/dma_reg being unused when building
for BF54x parts.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Bryan Wu <cooloney@kernel.org>
Signed-off-by: Cliff Cai <cliff.cai@analog.com>
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Acked-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
On tx channel abort a cppi interrupt is generated for a short time by
setting the lowest bit of the TCPPICOMPPTR register. It is then reset
immediately by clearing the bit. When the interrupt handler is run,
it does not detect an interrupt in the TCPPIMSKSR or RCPPIMSKSR
registers and thus exits early without writing the TCPPIEOIR register.
It appears that this inhibits further cppi interrupts until the handler
is called by chance, f.ex. from davinci_interrupt().
By moving the unmasking of the interrupt below the writes to
TCPPICOMPPTR, no interrupt is generated and no write to TCPPIEOIR is
necessary.
Signed-off-by: Daniel Glöckner <dg@emlix.com>
Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In gadget mode the answer to a control request should be followed by
a zero-length packet if the amount transferred is an exact multiple of
the endpoint's packet size and the requests has its "zero" flag set.
This patch prevents the request from being immediately removed from the
queue when a control IN transfer ends on a full packet and "zero" is set.
The next time ep0_txstate is entered, a zero-length packet is queued and
the request is removed as fifo_count is 0.
Signed-off-by: Daniel Glöckner <dg@emlix.com>
Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Isochronous Tx DMA is getting programmed but never getting started
for CPPI and TUSB DMAs and thus Isochronous Tx doesn't work.
Fixing it by starting DMAs using musb_h_tx_dma_start().
Signed-off-by: Swaminathan S <swami.iyer@ti.com>
Signed-off-by: Babu Ravi <ravibabu@ti.com>
Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The driver incorrectly cancels the mass-storage device CSW request
(which leads to device reset) due to giving back URB at the head of
endpoint's queue after sending each STALL handshake; stop doing that
and start checking for the queue being non-empty before stalling an
endpoint and disallowing stall in such case in musb_gadget_set_halt()
like the other gadget drivers do.
Moreover, the driver starts Rx request despite of the endpoint being
halted -- fix this by moving the SendStall bit check from musb_g_rx()
to rxstate(). And we also sometimes get into rxstate() with DMA still
active after clearing an endpoint's halt (not clear why), so bail out
in this case, similarly to what txstate() does...
While at it, also do the following changes :
- in musb_gadget_set_halt(), remove pointless Tx FIFO flushing (the
driver does not allow stalling with non-empty Tx FIFO anyway);
- in rxstate(), stop pointlessly zeroing the 'csr' variable;
- in musb_gadget_set_halt(), move the 'done' label to a more proper
place;
- in musb_g_rx(), eliminate the 'done' label completely...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Move the remaining headers under plat-omap/include/mach
to plat-omap/include/plat. Also search and replace the
files using these headers to include using the right path.
This was done with:
#!/bin/bash
mach_dir_old="arch/arm/plat-omap/include/mach"
plat_dir_new="arch/arm/plat-omap/include/plat"
headers=$(cd $mach_dir_old && ls *.h)
omap_dirs="arch/arm/*omap*/ \
drivers/video/omap \
sound/soc/omap"
other_files="drivers/leds/leds-ams-delta.c \
drivers/mfd/menelaus.c \
drivers/mfd/twl4030-core.c \
drivers/mtd/nand/ams-delta.c"
for header in $headers; do
old="#include <mach\/$header"
new="#include <plat\/$header"
for dir in $omap_dirs; do
find $dir -type f -name \*.[chS] | \
xargs sed -i "s/$old/$new/"
done
find drivers/ -type f -name \*omap*.[chS] | \
xargs sed -i "s/$old/$new/"
for file in $other_files; do
sed -i "s/$old/$new/" $file
done
done
for header in $(ls $mach_dir_old/*.h); do
git mv $header $plat_dir_new/
done
Signed-off-by: Tony Lindgren <tony@atomide.com>
The MUSB code relies on platform implementations that currently only
exists for Arm and Blackfin processors, so have the MUSB Kconfig depend
upon those arches.
This should prevent other arches from building MUSB via randconfig.
Reported-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The Blackfin port doesn't support HAVE_CLK and the musb driver works fine
with support stubbed out, so take the existing Blackfin clk stubs and move
them to common musb code so we can drop the Kconfig dependency.
Signed-off-by: Bryan Wu <cooloney@kernel.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Invoke put_device(musb->xceiv->dev) before musb_platform_exit()as
xceiv is getting unregistered in musb_platform_exit().
Fixes put_device() panic when module insert/removal is performed
multiple times.
Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
OMAP3EVM uses ISP1504 phy which doesn't require any programming and
thus has to use NOP otg transceiver.
Cleanups being done:
- Remove unwanted code in usb-musb.c file
- Register NOP in OMAP3EVM board file using
usb_nop_xceiv_register().
- Select NOP_USB_XCEIV for OMAP3EVM boards.
- Don't enable TWL4030_USB in omap3_evm_defconfig
Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Eino-Ville Talvala <talvala@stanford.edu>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
INDEX register has to be set to '0' before reading
CONFIGDATA register which is only present in TI musb
platforms.
Currently the default register access mode is set to
FLAT_MODE thus INDEX register is not getting set
properly with musb_ep_select() which is just a nop
operation in FLAT_MODE.This invalid register read is
causing module reinset failure.
Fixing the issue by moving INDEX register write part to
musb_read_configdata() function itself.
Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
musb_otg_timer_func() is defined under #ifdef CONFIG_USB_MUSB_OTG.
Make sure any reference to it is also under the same #ifdef.
Without this fix, the driver failes to compile when USB_OTG is defined
but USB_MUSB_OTG isn't.
Signed-off-by: Amit Kucheria <amit.kucheria@canonical.com>
Cc: Felipe Balbi <felipe.balbi@nokia.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This function uses wrong bit mask to prevent clearing RXCSR status
bits when halting an endpoint -- which results in clearing SentStall
and RxPktRdy bits (that the code actually tries to avoid); must be
a result of cut-and-paste...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch reworks platform driver power management code
for musb from legacy callbacks to dev_pm_ops.
The callbacks are converted for CONFIG_SUSPEND like this:
suspend() -> suspend()
resume_early() -> resume_noirq()
Signed-off-by: Magnus Damm <damm@igel.co.jp>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Commit c9cd06b3d6 (musb_host: refactor
URB giveback) included due to my overlook the change incorrect in the
context of the current kernel -- undo it.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Get rid of some obnoxious and inappropriate messaging, mostly on
DaVinci, when usbcore tries to autosuspend a root hub if just a
mini/micro-A connector is connected. Symptom: endless stream of
messages reading like:
musb_bus_suspend 2221: trying to suspend as a_wait_vrise is_active=1
Improve that musb bus suspend primitive a bit. Take advantage of
this call to update the OTG state machine if appropriate, moving
the device out of the A_WAIT_VRISE state. There's basically no
timer for that state transition just now, except with tusb6010;
that can make trouble.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Numbering for GPIOs on the pcf857x chips on the dm644x EVM board
changed when DaVinci chips with more GPIOs were supported. Update
the GPIO number used for nVBUS_DRV.
Longer term, we need a better abstraction of board-specific setup in
this code so we're not hard-coding board specific GPIOs into the
driver, but for now this at least gets it back to working with
mainline davinci core code.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Finish merging updates for DM355 chips into musb/davinci.c now
that its support is in mainline: kick in new DRVVBUS controls.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Remove smp_lock.h from files which don't need it (including some headers!)
* Add smp_lock.h to files which do need it
* Make smp_lock.h include conditional in hardirq.h
It's needed only for one kernel_locked() usage which is under CONFIG_PREEMPT
This will make hardirq.h inclusion cheaper for every PREEMPT=n config
(which includes allmodconfig/allyesconfig, BTW)
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Omap3 MUSB AUTOIDLE functionality configured through OTG_SYSCONFIG
register prevents the device from going into retention.
This is a workaround (by Richard Woodruff/TI), as his comment :
> A new MUSB bug which is a match to data below was identified very
> recently (on hardware and in simulation).
> This bug is in 3430 and not 3630.
> As a priority test (and as new default) you should have engineers
> disable autoidle for MUSB block.
> This is the workaround which will show up in next errata.
Signed-off-by: Niilo Minkkinen <ext-niilo.1.minkkinen@nokia.com>
Signed-off-by: Richard Woodruff <r-woodruff2@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tested on OMAP3 host side with Creative (Live! Cam Optia) USB camera
which uses high bandwidth isochronous IN endpoints. FIFO mode 4 is
updated to provide the needed 4K endpoint buffer without breaking
the g_nokia composite gadget configuration. (This is the only
gadget driver known to use enough endpoints to notice the change.)
Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Currently, with Inventra DMA, we use Mode 0 if transfer size is less
than or equal to the endpoint's maxpacket size. This requires that
we explicitly set TXPKTRDY for that transfer.
However the musb_g_tx code will not set TXPKTRDY twice if the last
transfer is exactly equal to maxpacket, even if request->zero is set.
Using Mode 1 will solve this; a better fix might be in musb_g_tx().
Without this change, musb will not correctly send out a ZLP if the
last transfer is the maxpacket size and request->zero is set.
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Adjust HNP state machines in MUSB driver so that they handle the
case where the cable is disconnected. The A-side machine was
very wrong (unrecoverable); the B-Side was much less so.
- A_PERIPHERAL ... as usual, the non-observability of the ID
pin through Mentor's registers makes trouble. We can't go
directly to A_WAIT_VFALL to end the session and start the
disconnect processing. We can however sense link suspending,
go to A_WAIT_BCON, and from there use OTG timeouts to finally
trigger that A_WAIT_VFALL transition. (Hoping that nobody
reconnects quickly to that port and notices the wrong state.)
- B_HOST ... actually clear the Host Request (HR) bit as the
messages say, disconnect the peripheral from the root hub,
and don't detour through a suspend state. (In some cases
this would eventually have cleaned up.)
Also adjust the A_SUSPEND transition to respect the A_AIDL_BDIS
timeout, so if HNP doesn't trigger quickly enough the A_WAIT_VFALL
transition happens as it should.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Minor HNP bugfixes, so the initial role switch works:
- A-Device:
* disconnect-during-suspend enters A_PERIPHERAL state
* kill OTG timer after reset as A_PERIPHERAL ...
* ... and also pass that reset to the gadget
* once HNP succeeds, clear the "ignore_disconnect" flag
* from A_PERIPHERAL, disconnect transitions to A_WAIT_BCON
- B-Device:
* kill OTG timer on entry to B_HOST state (HNP succeeded)
* once HNP succeeds, clear "ignore_disconnect" flag
* kick the root hub only _after_ the state is adjusted
Other state transitions are left alone. Notably, exit paths from
the "roles have switched" state ... A_PERIPHERAL handling of that
stays seriously broken.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Minor cleanup of OTG timer handling:
* unify decls for OTG time constants, in the core header
* set up and use that timer in a more normal way
* move to the driver struct, so it's usable outside core
And tighten use and setup of T(a_wait_bcon) so that if it's used,
it's always valid. (If that timer expires, the A-device will
stop powering VBUS. For non-OTG systems, that will be a surprise.)
No behavioral changes, other than more consistency when applying
that core HNP timeout.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Let the otg_transceiver in MUSB be managed by an external driver;
don't assume it's integrated. OMAP3 chips need it to be external,
and there may be ways to interact with the transceiver which add
functionality to the system.
Platform init code is responsible for setting up the transeciver,
probably using the NOP transceiver for integrated transceivers.
External ones will use whatever the board init code provided,
such as twl4030 or something more hands-off.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
As DaVinci DM646x has a dedicated CPPI DMA interrupt, replace
cppi_completion() (which has always been kind of layering
violation) by a complete CPPI interrupt handler.
[ dbrownell@users.sourceforge.net: only cppi_dma.c needs platform
device header, not cppi_dma.h ]
Signed-off-by: Dmitry Krivoschekov <dkrivoschekov@ru.mvista.com>
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
As musb_advance_schedule() is now the only remaning
caller of musb_giveback() (and the only valid context
of such call), just fold the latter into the former
and then rename __musb_giveback() into musb_giveback().
This is a net minor shrink.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The argument for the 'is_in' parameter of musb_cleanup_urb()
is always extracted from an URB that's passed to the function.
So that parameter is superfluous; remove it.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The existance of the scheduling list shouldn't matter in
determining whether there's currectly an URB executing on a
hardware endpoint. What should actually matter is the 'in_qh'
or 'out_qh' fields of the 'struct musb_hw_ep' -- those are
set in musb_start_urb() and cleared in musb_giveback() when
the endpoint's URB list drains. Hence we should be able to
replace the big *switch* statements in musb_urb_dequeue()
and musb_h_disable() with mere musb_ep_get_qh() calls...
While at it, do some more changes:
- add 'is_in' variable to musb_urb_dequeue();
- remove the unnecessary 'epnum' variable from musb_h_disable();
- fix the comment style in the vicinity.
This is a minor shrink of source and object code.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Factor out the often used code to get/set the active 'qh'
pointer for the hardware endpoint. Change the way the case
of a shared FIFO is handled by setting *both* 'in_qh' and
'out_qh' fields of 'struct musb_hw_ep'. That seems more
consistent and makes getting to the current 'qh' easy when
the code knows the direction beforehand.
While at it, turn some assignments into intializers and
fix declaration style in the vicinity.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Refactor musb_save_toggle() as follows:
- replace 'struct musb_hw_ep *ep' parameter by 'struct
musb_qh *qh' to avoid re-calculating this value
- move usb_settogle() call out of the *if* operator.
This is a net minor shrink of source and object code.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Suppress "parasitic" endpoint interrupts in the DMA mode
when using CPPI DMA driver; they're caused by the MUSB gadget
driver using the DMA request mode 0 instead of the mode 1.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The gadget EP0 code routinely ignores an interrupt at end of
the data phase because of musb_g_ep0_giveback() resetting the
state machine to "idle, waiting for SETUP" phase prematurely.
The driver also prematurely leaves the status phase on
receiving the SetupEnd interrupt.
As there were still unhandled endpoint 0 interrupts happening
from time to time after fixing these issues, there turned to
be yet another culprit: two distinct gadget states collapsed
into one.
The (missing) state that comes after STATUS IN/OUT states was
typically indiscernible from them since the corresponding
interrupts tend to happen within too little period of time
(due to only a zero-length status packet in between) and so
they got coalesced; yet this state is not the same as the next
one which is associated with the reception of a SETUP packet.
Adding this extra state seems to have fixed the rest of the
unhandled interrupts that generic_interrupt() and
davinci_interrupt() hid by faking their result and only
emitting a debug message -- so, stop doing that.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fix this build error when CONFIG_PM is not set:
drivers/usb/musb/musb_core.c:2232: error: 'musb_resume_early' undeclared here
Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This email address is going to expire soon and my contribution to musb
is next to zero so remove it.
Signed-off-by: Jarkko Nikula <jarkko.nikula@nokia.com>
Cc: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
During driver resume processing, musb could cause a kernel panic.
Fix by enabling the clock earlier, with the resume_early method.
Signed-off-by: Kim Kyuwon <q1.kim@samsung.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Multi-frame isochronous TX URBs transfers in DMA mode never
complete with CPPI DMA because musb_host_tx() doesn't restart
DMA on the second frame, only emitting a debug message.
With Inventra DMA they complete, but in PIO mode. To fix:
- Factor out programming of the DMA transfer from
musb_ep_program() into musb_tx_dma_program();
- Reorder the code at the end of musb_host_tx() to
facilitate the fallback to PIO iff DMA fails;
- Handle the buffer offset consistently for both
PIO and DMA modes;
- Add an argument to musb_ep_program() for the same
reason (it only worked correctly with non-zero
offset of the first frame in PIO mode);
- Set the completed isochronous frame descriptor's
'actual_length' and 'status' fields correctly in
DMA mode.
Also, since CPPI reportedly doesn't like sending isochronous
packets in the RNDIS mode, change the criterion for this
mode to be used only for multi-packet transfers. (There's
no need for that mode in the single-packet case anyway.)
[ dbrownell@users.sourceforge.net: split comment paragraph
into bullet list, shrink patch delta, style tweaks ]
Signed-off-by: Pavel Kiryukhin <pkiryukhin@ru.mvista.com>
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The MUSB code clears TXCSR_DMAMODE incorrectly in several
places, either asserting that TXCSR_DMAENAB is clear (when
sometimes it isn't) or clearing both bits together. Recent
versions of the programmer's guide require DMAENAB to be
cleared first, although some older ones didn't.
Fix this and while at it:
- In musb_gadget::txstate(), stop clearing the AUTOSET
and DMAMODE bits for the CPPI case since they never
get set anyway (the former bit is reserved on DaVinci);
but do clear the DMAENAB bit on the DMA error path.
- In musb_host::musb_ep_program(), remove the duplicate
DMA controller specific code code clearing the TXCSR
previous state, add the code to clear TXCSR DMA bits
on the Inventra DMA error path, to replace such code
(executed late) on the PIO path.
- In musbhsdma::dma_channel_abort()/dma_controller_irq(),
add/use the 'offset' variable to avoid MUSB_EP_OFFSET()
invocations on every RXCSR/TXCSR access.
[dbrownell@users.sourceforge.net: don't introduce CamelCase,
shrink diff]
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We really want to use DMA mode 1 for all multi-packet transfers;
that's one IRQ on DMA completion, instead of one per packet.
There is an important issue with such transfers, especially on
the host side: when such transfers end with a full-size packet,
we must defer musb_dma_completion() calls until the FIFO empties.
Else we report URB completions too soon, and may clobber data in
the FIFO fifo when writing the next packet (losing data).
The Inventra DMA support uses DMA mode 1, but it ignores that
issue. The CPPI DMA support uses mode 0, but doesn't handle
its TXPKTRDY interrupts quite right either; it can get stale
"packet ready" interrupts, and report transfer completion too
early using slightly different code paths, also losing data.
So I'm solving it in a generic way -- by adding a sort of the
"interrupt filter" into musb_host_tx(), catching these cases
where a DMA completion IRQ doesn't suffice and removing some
needlessly controller-specific logic. When a TXDMA interrupt
happens and DMA request mode 1 is active, that filter resets
to mode 0 and defers URB completion processing until TXPKTRDY,
unless the FIFO is already empty. Related filtering logic in
Inventra and CPPI code gets removed.
Since it should be competely safe now to use the DMA request
mode 1 for host side transfers with the CPPI DMA controller,
set it in musb_h_tx_dma_start() ... now renamed (and shared).
[ dbrownell@users.sourceforge.net: don't introduce more
CamElCase; use more concise explanations ]
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
