USB: Add MUSB and TUSB support

This patch adds support for MUSB and TUSB controllers
integrated into omap2430 and davinci. It also adds support
for external tusb6010 controller.

Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

28 files changed, 15688 insertions, 0 deletions

diff --git a/drivers/Makefile b/drivers/Makefile
index a280ab3d083..2735bde7347 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_ATA_OVER_ETH)	+= block/aoe/
 obj-$(CONFIG_PARIDE) 		+= block/paride/
 obj-$(CONFIG_TC)		+= tc/
 obj-$(CONFIG_USB)		+= usb/
+obj-$(CONFIG_USB_MUSB_HDRC)	+= usb/musb/
 obj-$(CONFIG_PCI)		+= usb/
 obj-$(CONFIG_USB_GADGET)	+= usb/gadget/
 obj-$(CONFIG_SERIO)		+= input/serio/
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 4f9b5ecfb72..bcefbddeba5 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -99,6 +99,8 @@ source "drivers/usb/mon/Kconfig"
 
 source "drivers/usb/host/Kconfig"
 
+source "drivers/usb/musb/Kconfig"
+
 source "drivers/usb/class/Kconfig"
 
 source "drivers/usb/storage/Kconfig"
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index c6a8c6b1116..acc95b2ac6f 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -284,6 +284,16 @@ config USB_LH7A40X
 	default USB_GADGET
 	select USB_GADGET_SELECTED
 
+# built in ../musb along with host support
+config USB_GADGET_MUSB_HDRC
+	boolean "Inventra HDRC USB Peripheral (TI, ...)"
+	depends on USB_MUSB_HDRC && (USB_MUSB_PERIPHERAL || USB_MUSB_OTG)
+	select USB_GADGET_DUALSPEED
+	select USB_GADGET_SELECTED
+	help
+	  This OTG-capable silicon IP is used in dual designs including
+	  the TI DaVinci, OMAP 243x, OMAP 343x, and TUSB 6010.
+
 config USB_GADGET_OMAP
 	boolean "OMAP USB Device Controller"
 	depends on ARCH_OMAP
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
new file mode 100644
index 00000000000..faca4333f27
--- /dev/null
+++ b/drivers/usb/musb/Kconfig
@@ -0,0 +1,176 @@
+#
+# USB Dual Role (OTG-ready) Controller Drivers
+# for silicon based on Mentor Graphics INVENTRA designs
+#
+
+comment "Enable Host or Gadget support to see Inventra options"
+	depends on !USB && USB_GADGET=n
+
+# (M)HDRC = (Multipoint) Highspeed Dual-Role Controller
+config USB_MUSB_HDRC
+	depends on (USB || USB_GADGET) && HAVE_CLK
+	select TWL4030_USB if MACH_OMAP_3430SDP
+	tristate 'Inventra Highspeed Dual Role Controller (TI, ...)'
+	help
+	  Say Y here if your system has a dual role high speed USB
+	  controller based on the Mentor Graphics silicon IP.  Then
+	  configure options to match your silicon and the board
+	  it's being used with, including the USB peripheral role,
+	  or the USB host role, or both.
+
+	  Texas Instruments parts using this IP include DaVinci 644x,
+	  OMAP 243x, OMAP 343x, and TUSB 6010.
+
+	  If you do not know what this is, please say N.
+
+	  To compile this driver as a module, choose M here; the
+	  module will be called "musb_hdrc".
+
+config USB_MUSB_SOC
+	boolean
+	depends on USB_MUSB_HDRC
+	default y if ARCH_DAVINCI
+	default y if ARCH_OMAP2430
+	default y if ARCH_OMAP34XX
+	help
+	  Use a static <asm/arch/hdrc_cnf.h> file to describe how the
+	  controller is configured (endpoints, mechanisms, etc) on the
+	  current iteration of a given system-on-chip.
+
+comment "DaVinci 644x USB support"
+	depends on USB_MUSB_HDRC && ARCH_DAVINCI
+
+comment "OMAP 243x high speed USB support"
+	depends on USB_MUSB_HDRC && ARCH_OMAP2430
+
+comment "OMAP 343x high speed USB support"
+	depends on USB_MUSB_HDRC && ARCH_OMAP34XX
+
+config USB_TUSB6010
+	boolean "TUSB 6010 support"
+	depends on USB_MUSB_HDRC && !USB_MUSB_SOC
+	default y
+	help
+	  The TUSB 6010 chip, from Texas Instruments, connects a discrete
+	  HDRC core using a 16-bit parallel bus (NOR flash style) or VLYNQ
+	  (a high speed serial link).  It can use system-specific external
+	  DMA controllers.
+
+choice
+	prompt "Driver Mode"
+	depends on USB_MUSB_HDRC
+	help
+	  Dual-Role devices can support both host and peripheral roles,
+	  as well as a the special "OTG Device" role which can switch
+	  between both roles as needed.
+
+# use USB_MUSB_HDRC_HCD not USB_MUSB_HOST to #ifdef host side support;
+# OTG needs both roles, not just USB_MUSB_HOST.
+config USB_MUSB_HOST
+	depends on USB
+	bool "USB Host"
+	help
+	  Say Y here if your system supports the USB host role.
+	  If it has a USB "A" (rectangular), "Mini-A" (uncommon),
+	  or "Mini-AB" connector, it supports the host role.
+	  (With a "Mini-AB" connector, you should enable USB OTG.)
+
+# use USB_GADGET_MUSB_HDRC not USB_MUSB_PERIPHERAL to #ifdef peripheral
+# side support ... OTG needs both roles
+config USB_MUSB_PERIPHERAL
+	depends on USB_GADGET
+	bool "USB Peripheral (gadget stack)"
+	select USB_GADGET_MUSB_HDRC
+	help
+	  Say Y here if your system supports the USB peripheral role.
+	  If it has a USB "B" (squarish), "Mini-B", or "Mini-AB"
+	  connector, it supports the peripheral role.
+	  (With a "Mini-AB" connector, you should enable USB OTG.)
+
+config USB_MUSB_OTG
+	depends on USB && USB_GADGET && PM && EXPERIMENTAL
+	bool "Both host and peripheral:  USB OTG (On The Go) Device"
+	select USB_GADGET_MUSB_HDRC
+	select USB_OTG
+	help
+	   The most notable feature of USB OTG is support for a
+	   "Dual-Role" device, which can act as either a device
+	   or a host.  The initial role choice can be changed
+	   later, when two dual-role devices talk to each other.
+
+	   At this writing, the OTG support in this driver is incomplete,
+	   omitting the mandatory HNP or SRP protocols.  However, some
+	   of the cable based role switching works.  (That is, grounding
+	   the ID pin switches the controller to host mode, while leaving
+	   it floating leaves it in peripheral mode.)
+
+	   Select this if your system has a Mini-AB connector, or
+	   to simplify certain kinds of configuration.
+
+	   To implement your OTG Targeted Peripherals List (TPL), enable
+	   USB_OTG_WHITELIST and update "drivers/usb/core/otg_whitelist.h"
+	   to match your requirements.
+
+endchoice
+
+# enable peripheral support (including with OTG)
+config USB_GADGET_MUSB_HDRC
+	bool
+	depends on USB_MUSB_HDRC && (USB_MUSB_PERIPHERAL || USB_MUSB_OTG)
+#	default y
+#	select USB_GADGET_DUALSPEED
+#	select USB_GADGET_SELECTED
+
+# enables host support (including with OTG)
+config USB_MUSB_HDRC_HCD
+	bool
+	depends on USB_MUSB_HDRC && (USB_MUSB_HOST || USB_MUSB_OTG)
+	select USB_OTG if USB_GADGET_MUSB_HDRC
+	default y
+
+
+config MUSB_PIO_ONLY
+	bool 'Disable DMA (always use PIO)'
+	depends on USB_MUSB_HDRC
+	default y if USB_TUSB6010
+	help
+	  All data is copied between memory and FIFO by the CPU.
+	  DMA controllers are ignored.
+
+	  Do not select 'n' here unless DMA support for your SOC or board
+	  is unavailable (or unstable).  When DMA is enabled at compile time,
+	  you can still disable it at run time using the "use_dma=n" module
+	  parameter.
+
+config USB_INVENTRA_DMA
+	bool
+	depends on USB_MUSB_HDRC && !MUSB_PIO_ONLY
+	default ARCH_OMAP2430 || ARCH_OMAP34XX
+	help
+	  Enable DMA transfers using Mentor's engine.
+
+config USB_TI_CPPI_DMA
+	bool
+	depends on USB_MUSB_HDRC && !MUSB_PIO_ONLY
+	default ARCH_DAVINCI
+	help
+	  Enable DMA transfers when TI CPPI DMA is available.
+
+config USB_TUSB_OMAP_DMA
+	bool
+	depends on USB_MUSB_HDRC && !MUSB_PIO_ONLY
+	depends on USB_TUSB6010
+	depends on ARCH_OMAP
+	default y
+	help
+	  Enable DMA transfers on TUSB 6010 when OMAP DMA is available.
+
+config	USB_MUSB_LOGLEVEL
+	depends on USB_MUSB_HDRC
+	int  'Logging Level (0 - none / 3 - annoying / ... )'
+	default 0
+	help
+	  Set the logging level. 0 disables the debugging altogether,
+	  although when USB_DEBUG is set the value is at least 1.
+	  Starting at level 3, per-transfer (urb, usb_request, packet,
+	  or dma transfer) tracing may kick in.
diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile
new file mode 100644
index 00000000000..88eb67de08a
--- /dev/null
+++ b/drivers/usb/musb/Makefile
@@ -0,0 +1,86 @@
+#
+# for USB OTG silicon based on Mentor Graphics INVENTRA designs
+#
+
+musb_hdrc-objs := musb_core.o
+
+obj-$(CONFIG_USB_MUSB_HDRC)	+= musb_hdrc.o
+
+ifeq ($(CONFIG_ARCH_DAVINCI),y)
+	musb_hdrc-objs	+= davinci.o
+endif
+
+ifeq ($(CONFIG_USB_TUSB6010),y)
+	musb_hdrc-objs	+= tusb6010.o
+endif
+
+ifeq ($(CONFIG_ARCH_OMAP2430),y)
+	musb_hdrc-objs	+= omap2430.o
+endif
+
+ifeq ($(CONFIG_ARCH_OMAP3430),y)
+	musb_hdrc-objs	+= omap2430.o
+endif
+
+ifeq ($(CONFIG_USB_GADGET_MUSB_HDRC),y)
+	musb_hdrc-objs		+= musb_gadget_ep0.o musb_gadget.o
+endif
+
+ifeq ($(CONFIG_USB_MUSB_HDRC_HCD),y)
+	musb_hdrc-objs		+= musb_virthub.o musb_host.o
+endif
+
+# the kconfig must guarantee that only one of the
+# possible I/O schemes will be enabled at a time ...
+# PIO only, or DMA (several potential schemes).
+# though PIO is always there to back up DMA, and for ep0
+
+ifneq ($(CONFIG_MUSB_PIO_ONLY),y)
+
+  ifeq ($(CONFIG_USB_INVENTRA_DMA),y)
+    musb_hdrc-objs		+= musbhsdma.o
+
+  else
+    ifeq ($(CONFIG_USB_TI_CPPI_DMA),y)
+      musb_hdrc-objs		+= cppi_dma.o
+
+    else
+      ifeq ($(CONFIG_USB_TUSB_OMAP_DMA),y)
+        musb_hdrc-objs		+= tusb6010_omap.o
+
+      endif
+    endif
+  endif
+endif
+
+
+################################################################################
+
+# FIXME remove all these extra "-DMUSB_* things, stick to CONFIG_*
+
+ifeq ($(CONFIG_USB_INVENTRA_MUSB_HAS_AHB_ID),y)
+	EXTRA_CFLAGS += -DMUSB_AHB_ID
+endif
+
+# Debugging
+
+MUSB_DEBUG:=$(CONFIG_USB_MUSB_LOGLEVEL)
+
+ifeq ("$(strip $(MUSB_DEBUG))","")
+    ifdef CONFIG_USB_DEBUG
+	MUSB_DEBUG:=1
+    else
+	MUSB_DEBUG:=0
+    endif
+endif
+
+ifneq ($(MUSB_DEBUG),0)
+    EXTRA_CFLAGS += -DDEBUG
+
+    ifeq ($(CONFIG_PROC_FS),y)
+	musb_hdrc-objs		+= musb_procfs.o
+    endif
+
+endif
+
+EXTRA_CFLAGS += -DMUSB_DEBUG=$(MUSB_DEBUG)
diff --git a/drivers/usb/musb/cppi_dma.c b/drivers/usb/musb/cppi_dma.c
new file mode 100644
index 00000000000..5ad6d0893cb
--- /dev/null
+++ b/drivers/usb/musb/cppi_dma.c
@@ -0,0 +1,1540 @@
+/*
+ * Copyright (C) 2005-2006 by Texas Instruments
+ *
+ * This file implements a DMA  interface using TI's CPPI DMA.
+ * For now it's DaVinci-only, but CPPI isn't specific to DaVinci or USB.
+ * The TUSB6020, using VLYNQ, has CPPI that looks much like DaVinci.
+ */
+
+#include <linux/usb.h>
+
+#include "musb_core.h"
+#include "cppi_dma.h"
+
+
+/* CPPI DMA status 7-mar-2006:
+ *
+ * - See musb_{host,gadget}.c for more info
+ *
+ * - Correct RX DMA generally forces the engine into irq-per-packet mode,
+ *   which can easily saturate the CPU under non-mass-storage loads.
+ *
+ * NOTES 24-aug-2006 (2.6.18-rc4):
+ *
+ * - peripheral RXDMA wedged in a test with packets of length 512/512/1.
+ *   evidently after the 1 byte packet was received and acked, the queue
+ *   of BDs got garbaged so it wouldn't empty the fifo.  (rxcsr 0x2003,
+ *   and RX DMA0: 4 left, 80000000 8feff880, 8feff860 8feff860; 8f321401
+ *   004001ff 00000001 .. 8feff860)  Host was just getting NAKed on tx
+ *   of its next (512 byte) packet.  IRQ issues?
+ *
+ * REVISIT:  the "transfer DMA" glue between CPPI and USB fifos will
+ * evidently also directly update the RX and TX CSRs ... so audit all
+ * host and peripheral side DMA code to avoid CSR access after DMA has
+ * been started.
+ */
+
+/* REVISIT now we can avoid preallocating these descriptors; or
+ * more simply, switch to a global freelist not per-channel ones.
+ * Note: at full speed, 64 descriptors == 4K bulk data.
+ */
+#define NUM_TXCHAN_BD       64
+#define NUM_RXCHAN_BD       64
+
+static inline void cpu_drain_writebuffer(void)
+{
+	wmb();
+#ifdef	CONFIG_CPU_ARM926T
+	/* REVISIT this "should not be needed",
+	 * but lack of it sure seemed to hurt ...
+	 */
+	asm("mcr p15, 0, r0, c7, c10, 4 @ drain write buffer\n");
+#endif
+}
+
+static inline struct cppi_descriptor *cppi_bd_alloc(struct cppi_channel *c)
+{
+	struct cppi_descriptor	*bd = c->freelist;
+
+	if (bd)
+		c->freelist = bd->next;
+	return bd;
+}
+
+static inline void
+cppi_bd_free(struct cppi_channel *c, struct cppi_descriptor *bd)
+{
+	if (!bd)
+		return;
+	bd->next = c->freelist;
+	c->freelist = bd;
+}
+
+/*
+ *  Start DMA controller
+ *
+ *  Initialize the DMA controller as necessary.
+ */
+
+/* zero out entire rx state RAM entry for the channel */
+static void cppi_reset_rx(struct cppi_rx_stateram __iomem *rx)
+{
+	musb_writel(&rx->rx_skipbytes, 0, 0);
+	musb_writel(&rx->rx_head, 0, 0);
+	musb_writel(&rx->rx_sop, 0, 0);
+	musb_writel(&rx->rx_current, 0, 0);
+	musb_writel(&rx->rx_buf_current, 0, 0);
+	musb_writel(&rx->rx_len_len, 0, 0);
+	musb_writel(&rx->rx_cnt_cnt, 0, 0);
+}
+
+/* zero out entire tx state RAM entry for the channel */
+static void cppi_reset_tx(struct cppi_tx_stateram __iomem *tx, u32 ptr)
+{
+	musb_writel(&tx->tx_head, 0, 0);
+	musb_writel(&tx->tx_buf, 0, 0);
+	musb_writel(&tx->tx_current, 0, 0);
+	musb_writel(&tx->tx_buf_current, 0, 0);
+	musb_writel(&tx->tx_info, 0, 0);
+	musb_writel(&tx->tx_rem_len, 0, 0);
+	/* musb_writel(&tx->tx_dummy, 0, 0); */
+	musb_writel(&tx->tx_complete, 0, ptr);
+}
+
+static void __init cppi_pool_init(struct cppi *cppi, struct cppi_channel *c)
+{
+	int	j;
+
+	/* initialize channel fields */
+	c->head = NULL;
+	c->tail = NULL;
+	c->last_processed = NULL;
+	c->channel.status = MUSB_DMA_STATUS_UNKNOWN;
+	c->controller = cppi;
+	c->is_rndis = 0;
+	c->freelist = NULL;
+
+	/* build the BD Free list for the channel */
+	for (j = 0; j < NUM_TXCHAN_BD + 1; j++) {
+		struct cppi_descriptor	*bd;
+		dma_addr_t		dma;
+
+		bd = dma_pool_alloc(cppi->pool, GFP_KERNEL, &dma);
+		bd->dma = dma;
+		cppi_bd_free(c, bd);
+	}
+}
+
+static int cppi_channel_abort(struct dma_channel *);
+
+static void cppi_pool_free(struct cppi_channel *c)
+{
+	struct cppi		*cppi = c->controller;
+	struct cppi_descriptor	*bd;
+
+	(void) cppi_channel_abort(&c->channel);
+	c->channel.status = MUSB_DMA_STATUS_UNKNOWN;
+	c->controller = NULL;
+
+	/* free all its bds */
+	bd = c->last_processed;
+	do {
+		if (bd)
+			dma_pool_free(cppi->pool, bd, bd->dma);
+		bd = cppi_bd_alloc(c);
+	} while (bd);
+	c->last_processed = NULL;
+}
+
+static int __init cppi_controller_start(struct dma_controller *c)
+{
+	struct cppi	*controller;
+	void __iomem	*tibase;
+	int		i;
+
+	controller = container_of(c, struct cppi, controller);
+
+	/* do whatever is necessary to start controller */
+	for (i = 0; i < ARRAY_SIZE(controller->tx); i++) {
+		controller->tx[i].transmit = true;
+		controller->tx[i].index = i;
+	}
+	for (i = 0; i < ARRAY_SIZE(controller->rx); i++) {
+		controller->rx[i].transmit = false;
+		controller->rx[i].index = i;
+	}
+
+	/* setup BD list on a per channel basis */
+	for (i = 0; i < ARRAY_SIZE(controller->tx); i++)
+		cppi_pool_init(controller, controller->tx + i);
+	for (i = 0; i < ARRAY_SIZE(controller->rx); i++)
+		cppi_pool_init(controller, controller->rx + i);
+
+	tibase =  controller->tibase;
+	INIT_LIST_HEAD(&controller->tx_complete);
+
+	/* initialise tx/rx channel head pointers to zero */
+	for (i = 0; i < ARRAY_SIZE(controller->tx); i++) {
+		struct cppi_channel	*tx_ch = controller->tx + i;
+		struct cppi_tx_stateram __iomem *tx;
+
+		INIT_LIST_HEAD(&tx_ch->tx_complete);
+
+		tx = tibase + DAVINCI_TXCPPI_STATERAM_OFFSET(i);
+		tx_ch->state_ram = tx;
+		cppi_reset_tx(tx, 0);
+	}
+	for (i = 0; i < ARRAY_SIZE(controller->rx); i++) {
+		struct cppi_channel	*rx_ch = controller->rx + i;
+		struct cppi_rx_stateram __iomem *rx;
+
+		INIT_LIST_HEAD(&rx_ch->tx_complete);
+
+		rx = tibase + DAVINCI_RXCPPI_STATERAM_OFFSET(i);
+		rx_ch->state_ram = rx;
+		cppi_reset_rx(rx);
+	}
+
+	/* enable individual cppi channels */
+	musb_writel(tibase, DAVINCI_TXCPPI_INTENAB_REG,
+			DAVINCI_DMA_ALL_CHANNELS_ENABLE);
+	musb_writel(tibase, DAVINCI_RXCPPI_INTENAB_REG,
+			DAVINCI_DMA_ALL_CHANNELS_ENABLE);
+
+	/* enable tx/rx CPPI control */
+	musb_writel(tibase, DAVINCI_TXCPPI_CTRL_REG, DAVINCI_DMA_CTRL_ENABLE);
+	musb_writel(tibase, DAVINCI_RXCPPI_CTRL_REG, DAVINCI_DMA_CTRL_ENABLE);
+
+	/* disable RNDIS mode, also host rx RNDIS autorequest */
+	musb_writel(tibase, DAVINCI_RNDIS_REG, 0);
+	musb_writel(tibase, DAVINCI_AUTOREQ_REG, 0);
+
+	return 0;
+}
+
+/*
+ *  Stop DMA controller
+ *
+ *  De-Init the DMA controller as necessary.
+ */
+
+static int cppi_controller_stop(struct dma_controller *c)
+{
+	struct cppi		*controller;
+	void __iomem		*tibase;
+	int			i;
+
+	controller = container_of(c, struct cppi, controller);
+
+	tibase = controller->tibase;
+	/* DISABLE INDIVIDUAL CHANNEL Interrupts */
+	musb_writel(tibase, DAVINCI_TXCPPI_INTCLR_REG,
+			DAVINCI_DMA_ALL_CHANNELS_ENABLE);
+	musb_writel(tibase, DAVINCI_RXCPPI_INTCLR_REG,
+			DAVINCI_DMA_ALL_CHANNELS_ENABLE);
+
+	DBG(1, "Tearing down RX and TX Channels\n");
+	for (i = 0; i < ARRAY_SIZE(controller->tx); i++) {
+		/* FIXME restructure of txdma to use bds like rxdma */
+		controller->tx[i].last_processed = NULL;
+		cppi_pool_free(controller->tx + i);
+	}
+	for (i = 0; i < ARRAY_SIZE(controller->rx); i++)
+		cppi_pool_free(controller->rx + i);
+
+	/* in Tx Case proper teardown is supported. We resort to disabling
+	 * Tx/Rx CPPI after cleanup of Tx channels. Before TX teardown is
+	 * complete TX CPPI cannot be disabled.
+	 */
+	/*disable tx/rx cppi */
+	musb_writel(tibase, DAVINCI_TXCPPI_CTRL_REG, DAVINCI_DMA_CTRL_DISABLE);
+	musb_writel(tibase, DAVINCI_RXCPPI_CTRL_REG, DAVINCI_DMA_CTRL_DISABLE);
+
+	return 0;
+}
+
+/* While dma channel is allocated, we only want the core irqs active
+ * for fault reports, otherwise we'd get irqs that we don't care about.
+ * Except for TX irqs, where dma done != fifo empty and reusable ...
+ *
+ * NOTE: docs don't say either way, but irq masking **enables** irqs.
+ *
+ * REVISIT same issue applies to pure PIO usage too, and non-cppi dma...
+ */
+static inline void core_rxirq_disable(void __iomem *tibase, unsigned epnum)
+{
+	musb_writel(tibase, DAVINCI_USB_INT_MASK_CLR_REG, 1 << (epnum + 8));
+}
+
+static inline void core_rxirq_enable(void __iomem *tibase, unsigned epnum)
+{
+	musb_writel(tibase, DAVINCI_USB_INT_MASK_SET_REG, 1 << (epnum + 8));
+}
+
+
+/*
+ * Allocate a CPPI Channel for DMA.  With CPPI, channels are bound to
+ * each transfer direction of a non-control endpoint, so allocating
+ * (and deallocating) is mostly a way to notice bad housekeeping on
+ * the software side.  We assume the irqs are always active.
+ */
+static struct dma_channel *
+cppi_channel_allocate(struct dma_controller *c,
+		struct musb_hw_ep *ep, u8 transmit)
+{
+	struct cppi		*controller;
+	u8			index;
+	struct cppi_channel	*cppi_ch;
+	void __iomem		*tibase;
+
+	controller = container_of(c, struct cppi, controller);
+	tibase = controller->tibase;
+
+	/* ep0 doesn't use DMA; remember cppi indices are 0..N-1 */
+	index = ep->epnum - 1;
+
+	/* return the corresponding CPPI Channel Handle, and
+	 * probably disable the non-CPPI irq until we need it.
+	 */
+	if (transmit) {
+		if (index >= ARRAY_SIZE(controller->tx)) {
+			DBG(1, "no %cX%d CPPI channel\n", 'T', index);
+			return NULL;
+		}
+		cppi_ch = controller->tx + index;
+	} else {
+		if (index >= ARRAY_SIZE(controller->rx)) {
+			DBG(1, "no %cX%d CPPI channel\n", 'R', index);
+			return NULL;
+		}
+		cppi_ch = controller->rx + index;
+		core_rxirq_disable(tibase, ep->epnum);
+	}
+
+	/* REVISIT make this an error later once the same driver code works
+	 * with the other DMA engine too
+	 */
+	if (cppi_ch->hw_ep)
+		DBG(1, "re-allocating DMA%d %cX channel %p\n",
+				index, transmit ? 'T' : 'R', cppi_ch);
+	cppi_ch->hw_ep = ep;
+	cppi_ch->channel.status = MUSB_DMA_STATUS_FREE;
+
+	DBG(4, "Allocate CPPI%d %cX\n", index, transmit ? 'T' : 'R');
+	return &cppi_ch->channel;
+}
+
+/* Release a CPPI Channel.  */
+static void cppi_channel_release(struct dma_channel *channel)
+{
+	struct cppi_channel	*c;
+	void __iomem		*tibase;
+
+	/* REVISIT:  for paranoia, check state and abort if needed... */
+
+	c = container_of(channel, struct cppi_channel, channel);
+	tibase = c->controller->tibase;
+	if (!c->hw_ep)
+		DBG(1, "releasing idle DMA channel %p\n", c);
+	else if (!c->transmit)
+		core_rxirq_enable(tibase, c->index + 1);
+
+	/* for now, leave its cppi IRQ enabled (we won't trigger it) */
+	c->hw_ep = NULL;
+	channel->status = MUSB_DMA_STATUS_UNKNOWN;
+}
+
+/* Context: controller irqlocked */
+static void
+cppi_dump_rx(int level, struct cppi_channel *c, const char *tag)
+{
+	void __iomem			*base = c->controller->mregs;
+	struct cppi_rx_stateram __iomem	*rx = c->state_ram;
+
+	musb_ep_select(base, c->index + 1);
+
+	DBG(level, "RX DMA%d%s: %d left, csr %04x, "
+			"%08x H%08x S%08x C%08x, "
+			"B%08x L%08x %08x .. %08x"
+			"\n",
+		c->index, tag,
+		musb_readl(c->controller->tibase,
+			DAVINCI_RXCPPI_BUFCNT0_REG + 4 * c->index),
+		musb_readw(c->hw_ep->regs, MUSB_RXCSR),
+
+		musb_readl(&rx->rx_skipbytes, 0),
+		musb_readl(&rx->rx_head, 0),
+		musb_readl(&rx->rx_sop, 0),
+		musb_readl(&rx->rx_current, 0),
+
+		musb_readl(&rx->rx_buf_current, 0),
+		musb_readl(&rx->rx_len_len, 0),
+		musb_readl(&rx->rx_cnt_cnt, 0),
+		musb_readl(&rx->rx_complete, 0)
+		);
+}
+
+/* Context: controller irqlocked */
+static void
+cppi_dump_tx(int level, struct cppi_channel *c, const char *tag)
+{
+	void __iomem			*base = c->controller->mregs;
+	struct cppi_tx_stateram __iomem	*tx = c->state_ram;
+
+	musb_ep_select(base, c->index + 1);
+
+	DBG(level, "TX DMA%d%s: csr %04x, "
+			"H%08x S%08x C%08x %08x, "
+			"F%08x L%08x .. %08x"
+			"\n",
+		c->index, tag,
+		musb_readw(c->hw_ep->regs, MUSB_TXCSR),
+
+		musb_readl(&tx->tx_head, 0),
+		musb_readl(&tx->tx_buf, 0),
+		musb_readl(&tx->tx_current, 0),
+		musb_readl(&tx->tx_buf_current, 0),
+
+		musb_readl(&tx->tx_info, 0),
+		musb_readl(&tx->tx_rem_len, 0),
+		/* dummy/unused word 6 */
+		musb_readl(&tx->tx_complete, 0)
+		);
+}
+
+/* Context: controller irqlocked */
+static inline void
+cppi_rndis_update(struct cppi_channel *c, int is_rx,
+		void __iomem *tibase, int is_rndis)
+{
+	/* we may need to change the rndis flag for this cppi channel */
+	if (c->is_rndis != is_rndis) {
+		u32	value = musb_readl(tibase, DAVINCI_RNDIS_REG);
+		u32	temp = 1 << (c->index);
+
+		if (is_rx)
+			temp <<= 16;
+		if (is_rndis)
+			value |= temp;
+		else
+			value &= ~temp;
+		musb_writel(tibase, DAVINCI_RNDIS_REG, value);
+		c->is_rndis = is_rndis;
+	}
+}
+
+static void cppi_dump_rxbd(const char *tag, struct cppi_descriptor *bd)
+{
+	pr_debug("RXBD/%s %08x: "
+			"nxt %08x buf %08x off.blen %08x opt.plen %08x\n",
+			tag, bd->dma,
+			bd->hw_next, bd->hw_bufp, bd->hw_off_len,
+			bd->hw_options);
+}
+
+static void cppi_dump_rxq(int level, const char *tag, struct cppi_channel *rx)
+{
+#if MUSB_DEBUG > 0
+	struct cppi_descriptor	*bd;
+
+	if (!_dbg_level(level))
+		return;
+	cppi_dump_rx(level, rx, tag);
+	if (rx->last_processed)
+		cppi_dump_rxbd("last", rx->last_processed);
+	for (bd = rx->head; bd; bd = bd->next)
+		cppi_dump_rxbd("active", bd);
+#endif
+}
+
+
+/* NOTE:  DaVinci autoreq is ignored except for host side "RNDIS" mode RX;
+ * so we won't ever use it (see "CPPI RX Woes" below).
+ */
+static inline int cppi_autoreq_update(struct cppi_channel *rx,
+		void __iomem *tibase, int onepacket, unsigned n_bds)
+{
+	u32	val;
+
+#ifdef	RNDIS_RX_IS_USABLE
+	u32	tmp;
+	/* assert(is_host_active(musb)) */
+
+	/* start from "AutoReq never" */
+	tmp = musb_readl(tibase, DAVINCI_AUTOREQ_REG);
+	val = tmp & ~((0x3) << (rx->index * 2));
+
+	/* HCD arranged reqpkt for packet #1.  we arrange int
+	 * for all but the last one, maybe in two segments.
+	 */
+	if (!onepacket) {
+#if 0
+		/* use two segments, autoreq "all" then the last "never" */
+		val |= ((0x3) << (rx->index * 2));
+		n_bds--;
+#else
+		/* one segment, autoreq "all-but-last" */
+		val |= ((0x1) << (rx->index * 2));
+#endif
+	}
+
+	if (val != tmp) {
+		int n = 100;
+
+		/* make sure that autoreq is updated before continuing */
+		musb_writel(tibase, DAVINCI_AUTOREQ_REG, val);
+		do {
+			tmp = musb_readl(tibase, DAVINCI_AUTOREQ_REG);
+			if (tmp == val)
+				break;
+			cpu_relax();
+		} while (n-- > 0);
+	}
+#endif
+
+	/* REQPKT is turned off after each segment */
+	if (n_bds && rx->channel.actual_len) {
+		void __iomem	*regs = rx->hw_ep->regs;
+
+		val = musb_readw(regs, MUSB_RXCSR);
+		if (!(val & MUSB_RXCSR_H_REQPKT)) {
+			val |= MUSB_RXCSR_H_REQPKT | MUSB_RXCSR_H_WZC_BITS;
+			musb_writew(regs, MUSB_RXCSR, val);
+			/* flush writebufer */
+			val = musb_readw(regs, MUSB_RXCSR);
+		}
+	}
+	return n_bds;
+}
+
+
+/* Buffer enqueuing Logic:
+ *
+ *  - RX builds new queues each time, to help handle routine "early
+ *    termination" cases (faults, including errors and short reads)
+ *    more correctly.
+ *
+ *  - for now, TX reuses the same queue of BDs every time
+ *
+ * REVISIT long term, we want a normal dynamic model.
+ * ... the goal will be to append to the
+ * existing queue, processing completed "dma buffers" (segments) on the fly.
+ *
+ * Otherwise we force an IRQ latency between requests, which slows us a lot
+ * (especially in "transparent" dma).  Unfortunately that model seems to be
+ * inherent in the DMA model from the Mentor code, except in the rare case
+ * of transfers big enough (~128+ KB) that we could append "middle" segments
+ * in the TX paths.  (RX can't do this, see below.)
+ *
+ * That's true even in the CPPI- friendly iso case, where most urbs have
+ * several small segments provided in a group and where the "packet at a time"
+ * "transparent" DMA model is always correct, even on the RX side.
+ */
+
+/*
+ * CPPI TX:
+ * ========
+ * TX is a lot more reasonable than RX; it doesn't need to run in
+ * irq-per-packet mode very often.  RNDIS mode seems to behave too
+ * (except how it handles the exactly-N-packets case).  Building a
+ * txdma queue with multiple requests (urb or usb_request) looks
+ * like it would work ... but fault handling would need much testing.
+ *
+ * The main issue with TX mode RNDIS relates to transfer lengths that
+ * are an exact multiple of the packet length.  It appears that there's
+ * a hiccup in that case (maybe the DMA completes before the ZLP gets
+ * written?) boiling down to not being able to rely on CPPI writing any
+ * terminating zero length packet before the next transfer is written.
+ * So that's punted to PIO; better yet, gadget drivers can avoid it.
+ *
+ * Plus, there's allegedly an undocumented constraint that rndis transfer
+ * length be a multiple of 64 bytes ... but the chip doesn't act that
+ * way, and we really don't _want_ that behavior anyway.
+ *
+ * On TX, "transparent" mode works ... although experiments have shown
+ * problems trying to use the SOP/EOP bits in different USB packets.
+ *
+ * REVISIT try to handle terminating zero length packets using CPPI
+ * instead of doing it by PIO after an IRQ.  (Meanwhile, make Ethernet
+ * links avoid that issue by forcing them to avoid zlps.