[PATCH 1/5] musb: save OTG base physical address

[PATCH 1/5] musb: save OTG base physical address

[Ajay Kumar Gupta]

OTG base physical address is required in calculating physical address
of endpoint FIFO which is needed by system dma.

Signed-off-by: Ajay Kumar Gupta <ajay.gupta-l0cyMroinI0@public.gmane.org>
---
 drivers/usb/musb/musb_core.c |    6 ++++--
 drivers/usb/musb/musb_core.h |    1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 4e327f5..adb142d 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1867,7 +1867,8 @@ static void musb_free(struct musb *musb)
  *	not yet corrected for platform-specific offsets
  */
 static int __init
-musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
+musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl,
+			phys_addr_t ctrl_phys_addr)
 {
 	int			status;
 	struct musb		*musb;
@@ -1919,6 +1920,7 @@ bad_config:
 	musb->board_set_power = plat->set_power;
 	musb->set_clock = plat->set_clock;
 	musb->min_power = plat->min_power;
+	musb->ctrl_phys_base = ctrl_phys_addr;
 
 	/* Clock usage is chip-specific ... functional clock (DaVinci,
 	 * OMAP2430), or PHY ref (some TUSB6010 boards).  All this core
@@ -2136,7 +2138,7 @@ static int __init musb_probe(struct platform_device *pdev)
 	/* clobbered by use_dma=n */
 	orig_dma_mask = dev->dma_mask;
 #endif
-	status = musb_init_controller(dev, irq, base);
+	status = musb_init_controller(dev, irq, base, iomem->start);
 	if (status < 0)
 		iounmap(base);
 
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index ac17b00..d001894 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -367,6 +367,7 @@ struct musb {
 
 	struct device		*controller;
 	void __iomem		*ctrl_base;
+	phys_addr_t		ctrl_phys_base;
 	void __iomem		*mregs;
 
 #ifdef CONFIG_USB_TUSB6010
-- 
1.6.2.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/5] musb: use system DMA to fix Inventra DMA issue on RTL-1.4

[Ajay Kumar Gupta]

MUSB RTL version 1.4 has a hardware issue when TX and RX DMA channels are
simultaneously enabled which results in DMA lockup.

Use system DMA for all RX channels as a workaround of this issue as this
will have minimal throughput overhead based on the fact that Rx transfers
are done in DMA mode-0 on OMAP34x/35x platforms.

Another approach to use PIO mode in opposite direction would increase the
cpu loading and thus using system DMA is preferred workaround.

Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
---
Original version of this patch can be found at,
http://marc.info/?l=linux-usb&m=121861118320955&w=2

 drivers/usb/musb/Kconfig     |    9 ++++
 drivers/usb/musb/musbhsdma.c |  101 ++++++++++++++++++++++++++++++++++++++++++
 drivers/usb/musb/musbhsdma.h |   10 ++++
 3 files changed, 120 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 07fe490..f847fe2 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -157,6 +157,15 @@ config USB_INVENTRA_DMA
 	help
 	  Enable DMA transfers using Mentor's engine.
 
+config MUSB_USE_SYSTEM_DMA_WORKAROUND
+	bool 'Use System DMA for Mentor DMA workaround'
+	depends on USB_MUSB_HDRC && USB_INVENTRA_DMA
+	default y
+	help
+          MUSB RTL version 1.4 (OMAP34x/35x) has a hardware issue when TX and RX
+          DMA channels are simultaneously enabled. To work around this issue,
+          you can choose to use System DMA for RX channels.
+
 config USB_TI_CPPI_DMA
 	bool
 	depends on USB_MUSB_HDRC && !MUSB_PIO_ONLY
diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c
index 1008044..70342eb 100644
--- a/drivers/usb/musb/musbhsdma.c
+++ b/drivers/usb/musb/musbhsdma.c
@@ -36,12 +36,47 @@
 #include <linux/slab.h>
 #include "musb_core.h"
 #include "musbhsdma.h"
+#include <plat/dma.h>
 
 static int dma_controller_start(struct dma_controller *c)
 {
 	/* nothing to do */
 	return 0;
 }
+static void musb_sysdma_completion(int lch, u16 ch_status, void *data)
+{
+	u32 addr;
+	unsigned long flags;
+
+	struct dma_channel *channel;
+
+	struct musb_dma_channel *musb_channel =
+					(struct musb_dma_channel *) data;
+	struct musb_dma_controller *controller = musb_channel->controller;
+	struct musb *musb = controller->private_data;
+	channel = &musb_channel->channel;
+
+	DBG(2, "lch = 0x%d, ch_status = 0x%x\n", lch, ch_status);
+	spin_lock_irqsave(&musb->lock, flags);
+
+	addr = (u32) omap_get_dma_dst_pos(musb_channel->sysdma_channel);
+	if (musb_channel->len == 0)
+		channel->actual_len = 0;
+	else
+		channel->actual_len = addr - musb_channel->start_addr;
+
+	DBG(2, "ch %p, 0x%x -> 0x%x (%d / %d) %s\n",
+		channel, musb_channel->start_addr, addr,
+		channel->actual_len, musb_channel->len,
+		(channel->actual_len < musb_channel->len) ?
+		"=> reconfig 0 " : " => complete");
+
+	channel->status = MUSB_DMA_STATUS_FREE;
+	musb_dma_completion(musb, musb_channel->epnum, musb_channel->transmit);
+
+	spin_unlock_irqrestore(&musb->lock, flags);
+	return;
+}
 
 static void dma_channel_release(struct dma_channel *channel);
 
@@ -77,6 +112,7 @@ static struct dma_channel *dma_channel_allocate(struct dma_controller *c,
 	struct musb_dma_controller *controller = container_of(c,
 			struct musb_dma_controller, controller);
 	struct musb_dma_channel *musb_channel = NULL;
+	struct musb *musb = controller->private_data;
 	struct dma_channel *channel = NULL;
 	u8 bit;
 
@@ -95,6 +131,33 @@ static struct dma_channel *dma_channel_allocate(struct dma_controller *c,
 			/* Tx => mode 1; Rx => mode 0 */
 			channel->desired_mode = transmit;
 			channel->actual_len = 0;
+			musb_channel->sysdma_channel = -1;
+
+			/*
+			 * MUSB RTL version 1.4 (OMAP34x/35x) has a hardware
+			 * issue when TX and RX DMA channels are simultaneously
+			 * enabled. To work around this issue, use system DMA
+			 * for all RX channels.
+			 */
+			if (((musb->hwvers == MUSB_HWVERS_1400) && !transmit)
+				&& use_sdma_workaround()) {
+				int ret;
+				ret = omap_request_dma(OMAP24XX_DMA_NO_DEVICE,
+					"MUSB SysDMA", musb_sysdma_completion,
+					(void *) musb_channel,
+					&(musb_channel->sysdma_channel));
+
+				if (ret) {
+					printk(KERN_ERR "request_dma failed:"
+							" %d\n", ret);
+					controller->used_channels &=
+								~(1 << bit);
+					channel->status =
+							MUSB_DMA_STATUS_UNKNOWN;
+					musb_channel->sysdma_channel = -1;
+					channel = NULL;
+				}
+			}
 			break;
 		}
 	}
@@ -114,6 +177,12 @@ static void dma_channel_release(struct dma_channel *channel)
 		~(1 << musb_channel->idx);
 
 	channel->status = MUSB_DMA_STATUS_UNKNOWN;
+
+	if (musb_channel->sysdma_channel != -1) {
+		omap_stop_dma(musb_channel->sysdma_channel);
+		omap_free_dma(musb_channel->sysdma_channel);
+		musb_channel->sysdma_channel = -1;
+	}
 }
 
 static void configure_channel(struct dma_channel *channel,
@@ -122,12 +191,40 @@ static void configure_channel(struct dma_channel *channel,
 {
 	struct musb_dma_channel *musb_channel = channel->private_data;
 	struct musb_dma_controller *controller = musb_channel->controller;
+	struct musb *musb = controller->private_data;
 	void __iomem *mbase = controller->base;
 	u8 bchannel = musb_channel->idx;
 	u16 csr = 0;
 
 	DBG(4, "%p, pkt_sz %d, addr 0x%x, len %d, mode %d\n",
 			channel, packet_sz, dma_addr, len, mode);
+	if (musb_channel->sysdma_channel != -1) {
+		/* System DMA */
+		/* RX: set src = FIFO */
+		omap_set_dma_transfer_params(musb_channel->sysdma_channel,
+					OMAP_DMA_DATA_TYPE_S8,
+					len ? len : 1, 1, /* One frame */
+					OMAP_DMA_SYNC_ELEMENT,
+					OMAP24XX_DMA_NO_DEVICE,
+					0); /* Src Sync */
+
+		omap_set_dma_src_params(musb_channel->sysdma_channel, 0,
+					OMAP_DMA_AMODE_CONSTANT,
+					MUSB_FIFO_ADDRESS(musb->ctrl_phys_base,
+						musb_channel->epnum),
+					0, 0);
+
+		omap_set_dma_dest_params(musb_channel->sysdma_channel, 0,
+					OMAP_DMA_AMODE_POST_INC, dma_addr,
+					0, 0);
+
+		omap_set_dma_dest_data_pack(musb_channel->sysdma_channel, 1);
+		omap_set_dma_dest_burst_mode(musb_channel->sysdma_channel,
+					OMAP_DMA_DATA_BURST_16);
+
+		omap_start_dma(musb_channel->sysdma_channel);
+
+	} else { /* Mentor DMA */
 
 	if (mode) {
 		csr |= 1 << MUSB_HSDMA_MODE1_SHIFT;
@@ -160,6 +257,7 @@ static void configure_channel(struct dma_channel *channel,
 	musb_writew(mbase,
 		MUSB_HSDMA_CHANNEL_OFFSET(bchannel, MUSB_HSDMA_CONTROL),
 		csr);
+	}
 }
 
 static int dma_channel_program(struct dma_channel *channel,
@@ -214,6 +312,9 @@ static int dma_channel_abort(struct dma_channel *channel)
 			csr &= ~MUSB_TXCSR_DMAMODE;
 			musb_writew(mbase, offset, csr);
 		} else {
+			if (musb_channel->sysdma_channel != -1)
+				omap_stop_dma(musb_channel->sysdma_channel);
+
 			offset = MUSB_EP_OFFSET(musb_channel->epnum,
 						MUSB_RXCSR);
 
diff --git a/drivers/usb/musb/musbhsdma.h b/drivers/usb/musb/musbhsdma.h
index 613f95a..effc89a 100644
--- a/drivers/usb/musb/musbhsdma.h
+++ b/drivers/usb/musb/musbhsdma.h
@@ -142,6 +142,15 @@ static inline void musb_write_hsdma_count(void __iomem *mbase,
 
 #define MUSB_HSDMA_CHANNELS		8
 
+#define MUSB_FIFO_ADDRESS(base, epnum)      \
+	((unsigned long) (base + MUSB_FIFO_OFFSET(epnum)))
+
+#ifdef CONFIG_MUSB_USE_SYSTEM_DMA_WORKAROUND
+#define	use_sdma_workaround()	1
+#else
+#define	use_sdma_workaround()	0
+#endif
+
 struct musb_dma_controller;
 
 struct musb_dma_channel {
@@ -153,6 +162,7 @@ struct musb_dma_channel {
 	u8				idx;
 	u8				epnum;
 	u8				transmit;
+	int                             sysdma_channel;
 };
 
 struct musb_dma_controller {
-- 
1.6.2.4

[PATCH 3/5] musb: add function to check if Inventra DMA used

[Ajay Kumar Gupta]

Added is_inventra_dma_enabled() funtion which would be required
for adding workaround for Inventra DMA issues. It can also be
used at other places instead of #ifdefs.

Signed-off-by: Ajay Kumar Gupta <ajay.gupta-l0cyMroinI0@public.gmane.org>
---
 drivers/usb/musb/musb_dma.h |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/musb/musb_dma.h b/drivers/usb/musb/musb_dma.h
index 916065b..b8b385e 100644
--- a/drivers/usb/musb/musb_dma.h
+++ b/drivers/usb/musb/musb_dma.h
@@ -80,6 +80,12 @@ struct musb_hw_ep;
 #define tusb_dma_omap()			0
 #endif
 
+#ifdef CONFIG_USB_INVENTRA_DMA
+#define	is_inventra_dma_enabled()	1
+#else
+#define	is_inventra_dma_enabled()	0
+#endif
+
 /* Anomaly 05000456 - USB Receive Interrupt Is Not Generated in DMA Mode 1
  *	Only allow DMA mode 1 to be used when the USB will actually generate the
  *	interrupts we expect.
-- 
1.6.2.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/5] musb: use system DMA for unaligned buffers on RTL >= 1.8

[Ajay Kumar Gupta]

MUSB RTL version 1.8 onward (OMAP3630, AM/DM37x, OMAP4) DMA requires
the buffers to be aligned on a four byte boundary. This affects USB
CDC/RNDIS class application where buffers are always unaligned.

Use system DMA for unaligned buffers as a workaround of this issue.

Current patch supports device side CDC/RNDIS. Host side would require
change in Tx programming path for mode-0 operation when transfer length
is more than packet size.

Also fixed an issue in device Tx completion path where 'is_dma' is getting
set unconditionally. This would fail the io if Tx transfer is done in
mode-0. Fixed it by updating it based on 'request->actual' length.

Signed-off-by: Ajay Kumar Gupta <ajay.gupta-l0cyMroinI0@public.gmane.org>
---
 drivers/usb/musb/Kconfig       |    6 +++
 drivers/usb/musb/musb_gadget.c |   21 +++++++++++-
 drivers/usb/musb/musbhsdma.c   |   75 ++++++++++++++++++++++++++++++++++++++--
 3 files changed, 98 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index f847fe2..05db0ff 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -166,6 +166,12 @@ config MUSB_USE_SYSTEM_DMA_WORKAROUND
           DMA channels are simultaneously enabled. To work around this issue,
           you can choose to use System DMA for RX channels.
 
+	  Also on Mentor DMA in MUSB RTL version 1.8 (OMAP3630, AM/DM37x)
+	  requires buffers to be aligned on a four byte boundary. This affects
+	  USB CDC/RNDIS class application where buffers are always unaligned.
+	  To work around this issue, you can choose to use System DMA for
+	  unaligned buffers.
+
 config USB_TI_CPPI_DMA
 	bool
 	depends on USB_MUSB_HDRC && !MUSB_PIO_ONLY
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 6fca870..9ac45e4 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -317,6 +317,22 @@ static void txstate(struct musb *musb, struct musb_request *req)
 			else
 				musb_ep->dma->desired_mode = 1;
 
+			/*
+			 * Use system dma for unaligned buffers on RTL >= 1.8
+			 * for Inventra DMA. As system DMA can work only in
+			 * mode-0 so update the desired_mode and request_size.
+			 */
+			if (is_inventra_dma_enabled() &&
+				((request->dma + request->actual) & 0x3) &&
+				(musb->hwvers >= MUSB_HWVERS_1800)) {
+
+				request_size = min_t(size_t,
+					musb_ep->hw_ep->max_packet_sz_tx,
+					request->length - request->actual);
+
+				musb_ep->dma->desired_mode = 0;
+			}
+
 			use_dma = use_dma && c->channel_program(
 					musb_ep->dma, musb_ep->packet_sz,
 					musb_ep->dma->desired_mode,
@@ -463,7 +479,6 @@ void musb_g_tx(struct musb *musb, u8 epnum)
 		u8	is_dma = 0;
 
 		if (dma && (csr & MUSB_TXCSR_DMAENAB)) {
-			is_dma = 1;
 			csr |= MUSB_TXCSR_P_WZC_BITS;
 			csr &= ~(MUSB_TXCSR_DMAENAB | MUSB_TXCSR_P_UNDERRUN |
 				 MUSB_TXCSR_TXPKTRDY);
@@ -471,6 +486,10 @@ void musb_g_tx(struct musb *musb, u8 epnum)
 			/* Ensure writebuffer is empty. */
 			csr = musb_readw(epio, MUSB_TXCSR);
 			request->actual += musb_ep->dma->actual_len;
+
+			if (request->actual == request->length)
+				is_dma = 1;
+
 			DBG(4, "TXCSR%d %04x, DMA off, len %zu, req %p\n",
 				epnum, csr, musb_ep->dma->actual_len, request);
 		}
diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c
index 70342eb..6118d5f 100644
--- a/drivers/usb/musb/musbhsdma.c
+++ b/drivers/usb/musb/musbhsdma.c
@@ -54,12 +54,18 @@ static void musb_sysdma_completion(int lch, u16 ch_status, void *data)
 					(struct musb_dma_channel *) data;
 	struct musb_dma_controller *controller = musb_channel->controller;
 	struct musb *musb = controller->private_data;
+	void __iomem *mbase = controller->base;
+
 	channel = &musb_channel->channel;
 
 	DBG(2, "lch = 0x%d, ch_status = 0x%x\n", lch, ch_status);
 	spin_lock_irqsave(&musb->lock, flags);
 
-	addr = (u32) omap_get_dma_dst_pos(musb_channel->sysdma_channel);
+	if (musb_channel->transmit)
+		addr = (u32) omap_get_dma_src_pos(musb_channel->sysdma_channel);
+	else
+		addr = (u32) omap_get_dma_dst_pos(musb_channel->sysdma_channel);
+
 	if (musb_channel->len == 0)
 		channel->actual_len = 0;
 	else
@@ -72,6 +78,26 @@ static void musb_sysdma_completion(int lch, u16 ch_status, void *data)
 		"=> reconfig 0 " : " => complete");
 
 	channel->status = MUSB_DMA_STATUS_FREE;
+
+	/* completed */
+	if ((musb_channel->transmit) && (channel->desired_mode == 0)
+		&& (channel->actual_len == musb_channel->max_packet_sz)) {
+
+		u8  epnum  = musb_channel->epnum;
+		int offset = MUSB_EP_OFFSET(epnum,
+				    MUSB_TXCSR);
+		u16 txcsr;
+
+		/*
+		 * The programming guide says that we
+		 * must clear DMAENAB before DMAMODE.
+		 */
+		musb_ep_select(mbase, epnum);
+		txcsr = musb_readw(mbase, offset);
+		txcsr |=  MUSB_TXCSR_TXPKTRDY;
+		musb_writew(mbase, offset, txcsr);
+	}
+
 	musb_dma_completion(musb, musb_channel->epnum, musb_channel->transmit);
 
 	spin_unlock_irqrestore(&musb->lock, flags);
@@ -138,8 +164,15 @@ static struct dma_channel *dma_channel_allocate(struct dma_controller *c,
 			 * issue when TX and RX DMA channels are simultaneously
 			 * enabled. To work around this issue, use system DMA
 			 * for all RX channels.
+			 * Also on MUSB RTL version 1.8 onward (OMAP3630, OMAP4
+			 * and AM/DM37x) DMA requires buffers to be aligned on
+			 * a four byte boundary. This affects USB CDC/RNDIS
+			 * class application where buffers are always unaligned.
+			 * Using system DMA for unaligned buffers as a
+			 * workaround for this issue.
 			 */
-			if (((musb->hwvers == MUSB_HWVERS_1400) && !transmit)
+			if ((((musb->hwvers == MUSB_HWVERS_1400) && !transmit)
+				|| (musb->hwvers >= MUSB_HWVERS_1800))
 				&& use_sdma_workaround()) {
 				int ret;
 				ret = omap_request_dma(OMAP24XX_DMA_NO_DEVICE,
@@ -194,11 +227,18 @@ static void configure_channel(struct dma_channel *channel,
 	struct musb *musb = controller->private_data;
 	void __iomem *mbase = controller->base;
 	u8 bchannel = musb_channel->idx;
+	u8 buffer_is_aligned = (dma_addr & 0x3) ? 0 : 1;
+	u8 use_sdma = (musb_channel->sysdma_channel == -1) ? 0 : 1;
 	u16 csr = 0;
 
 	DBG(4, "%p, pkt_sz %d, addr 0x%x, len %d, mode %d\n",
 			channel, packet_sz, dma_addr, len, mode);
-	if (musb_channel->sysdma_channel != -1) {
+
+	if (buffer_is_aligned && (packet_sz >= 512) &&
+			(musb->hwvers >= MUSB_HWVERS_1800))
+		use_sdma = 0;
+
+	if (use_sdma &&	!musb_channel->transmit) {
 		/* System DMA */
 		/* RX: set src = FIFO */
 		omap_set_dma_transfer_params(musb_channel->sysdma_channel,
@@ -224,6 +264,32 @@ static void configure_channel(struct dma_channel *channel,
 
 		omap_start_dma(musb_channel->sysdma_channel);
 
+	} else if (use_sdma && musb_channel->transmit) {
+		/* System DMA */
+		/* TX: set dst = FIFO */
+		omap_set_dma_transfer_params(musb_channel->sysdma_channel,
+					OMAP_DMA_DATA_TYPE_S8,
+					len ? len : 1, 1, /* One frame */
+					OMAP_DMA_SYNC_ELEMENT,
+					OMAP24XX_DMA_NO_DEVICE,
+					0); /* Src Sync */
+
+		omap_set_dma_src_params(musb_channel->sysdma_channel, 0,
+					OMAP_DMA_AMODE_POST_INC, dma_addr,
+					0, 0);
+
+		omap_set_dma_dest_params(musb_channel->sysdma_channel, 0,
+					OMAP_DMA_AMODE_CONSTANT,
+					MUSB_FIFO_ADDRESS(musb->ctrl_phys_base,
+						musb_channel->epnum),
+					0, 0);
+
+		omap_set_dma_dest_data_pack(musb_channel->sysdma_channel, 0);
+		omap_set_dma_dest_burst_mode(musb_channel->sysdma_channel,
+					OMAP_DMA_DATA_BURST_DIS);
+
+		omap_start_dma(musb_channel->sysdma_channel);
+
 	} else { /* Mentor DMA */
 
 	if (mode) {
@@ -299,6 +365,9 @@ static int dma_channel_abort(struct dma_channel *channel)
 
 	if (channel->status == MUSB_DMA_STATUS_BUSY) {
 		if (musb_channel->transmit) {
+			if (musb_channel->sysdma_channel != -1)
+				omap_stop_dma(musb_channel->sysdma_channel);
+
 			offset = MUSB_EP_OFFSET(musb_channel->epnum,
 						MUSB_TXCSR);
 
-- 
1.6.2.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/5] musb: dma: use optimal transfer element for sdma

[Ajay Kumar Gupta]

Use optimal values of transfer element based on buffer address in system
DMA programming. This would improve the performance.

Signed-off-by: Ajay Kumar Gupta <ajay.gupta-l0cyMroinI0@public.gmane.org>
---
 drivers/usb/musb/musbhsdma.c |   39 +++++++++++++++++++++++++++++++++------
 1 files changed, 33 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c
index 6118d5f..a0da178 100644
--- a/drivers/usb/musb/musbhsdma.c
+++ b/drivers/usb/musb/musbhsdma.c
@@ -230,6 +230,8 @@ static void configure_channel(struct dma_channel *channel,
 	u8 buffer_is_aligned = (dma_addr & 0x3) ? 0 : 1;
 	u8 use_sdma = (musb_channel->sysdma_channel == -1) ? 0 : 1;
 	u16 csr = 0;
+	u16 frame = len;
+	int data_type = OMAP_DMA_DATA_TYPE_S8;
 
 	DBG(4, "%p, pkt_sz %d, addr 0x%x, len %d, mode %d\n",
 			channel, packet_sz, dma_addr, len, mode);
@@ -238,13 +240,38 @@ static void configure_channel(struct dma_channel *channel,
 			(musb->hwvers >= MUSB_HWVERS_1800))
 		use_sdma = 0;
 
+	if (use_sdma) {
+		switch (dma_addr & 0x3) {
+		case 0:
+			if ((len % 4) == 0) {
+				data_type = OMAP_DMA_DATA_TYPE_S32;
+				frame = len / 4;
+				break;
+			}
+			/* FALLTHROUGH */
+		case 2:
+			if ((len % 2) == 0) {
+				data_type = OMAP_DMA_DATA_TYPE_S16;
+				frame = len / 2;
+				break;
+			}
+			/* FALLTHROUGH */
+		case 1:
+		case 3:
+		default:
+			data_type = OMAP_DMA_DATA_TYPE_S8;
+			frame = len;
+			break;
+		}
+	}
+
 	if (use_sdma &&	!musb_channel->transmit) {
 		/* System DMA */
 		/* RX: set src = FIFO */
 		omap_set_dma_transfer_params(musb_channel->sysdma_channel,
-					OMAP_DMA_DATA_TYPE_S8,
-					len ? len : 1, 1, /* One frame */
-					OMAP_DMA_SYNC_ELEMENT,
+					data_type,
+					len ? frame : 1, 1, /* One frame */
+					OMAP_DMA_SYNC_FRAME,
 					OMAP24XX_DMA_NO_DEVICE,
 					0); /* Src Sync */
 
@@ -268,9 +295,9 @@ static void configure_channel(struct dma_channel *channel,
 		/* System DMA */
 		/* TX: set dst = FIFO */
 		omap_set_dma_transfer_params(musb_channel->sysdma_channel,
-					OMAP_DMA_DATA_TYPE_S8,
-					len ? len : 1, 1, /* One frame */
-					OMAP_DMA_SYNC_ELEMENT,
+					data_type,
+					len ? frame : 1, 1, /* One frame */
+					OMAP_DMA_SYNC_FRAME,
 					OMAP24XX_DMA_NO_DEVICE,
 					0); /* Src Sync */
 
-- 
1.6.2.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/5] musb: use system DMA for unaligned buffers on RTL >= 1.8

[Sergei Shtylyov]

Hello.

Ajay Kumar Gupta wrote:

> MUSB RTL version 1.8 onward (OMAP3630, AM/DM37x, OMAP4) DMA requires
> the buffers to be aligned on a four byte boundary. This affects USB
> CDC/RNDIS class application where buffers are always unaligned.
>
> Use system DMA for unaligned buffers as a workaround of this issue.
>
> Current patch supports device side CDC/RNDIS. Host side would require
> change in Tx programming path for mode-0 operation when transfer length
> is more than packet size.
>
> Also fixed an issue in device Tx completion path where 'is_dma' is getting
> set unconditionally. This would fail the io if Tx transfer is done in
> mode-0. Fixed it by updating it based on 'request->actual' length.
>
> Signed-off-by: Ajay Kumar Gupta <ajay.gupta-l0cyMroinI0@public.gmane.org>
>   
[...]
> diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c
> index 70342eb..6118d5f 100644
> --- a/drivers/usb/musb/musbhsdma.c
> +++ b/drivers/usb/musb/musbhsdma.c
> @@ -54,12 +54,18 @@ static void musb_sysdma_completion(int lch, u16 ch_status, void *data)
>  					(struct musb_dma_channel *) data;
>  	struct musb_dma_controller *controller = musb_channel->controller;
>  	struct musb *musb = controller->private_data;
> +	void __iomem *mbase = controller->base;
> +
>  	channel = &musb_channel->channel;
>  
>  	DBG(2, "lch = 0x%d, ch_status = 0x%x\n", lch, ch_status);
>  	spin_lock_irqsave(&musb->lock, flags);
>  
> -	addr = (u32) omap_get_dma_dst_pos(musb_channel->sysdma_channel);
> +	if (musb_channel->transmit)
> +		addr = (u32) omap_get_dma_src_pos(musb_channel->sysdma_channel);
> +	else
> +		addr = (u32) omap_get_dma_dst_pos(musb_channel->sysdma_channel);
> +
>  	if (musb_channel->len == 0)
>  		channel->actual_len = 0;
>  	else
> @@ -72,6 +78,26 @@ static void musb_sysdma_completion(int lch, u16 ch_status, void *data)
>  		"=> reconfig 0 " : " => complete");
>  
>  	channel->status = MUSB_DMA_STATUS_FREE;
> +
> +	/* completed */
> +	if ((musb_channel->transmit) && (channel->desired_mode == 0)
> +		&& (channel->actual_len == musb_channel->max_packet_sz)) {
> +
> +		u8  epnum  = musb_channel->epnum;
> +		int offset = MUSB_EP_OFFSET(epnum,
> +				    MUSB_TXCSR);
> +		u16 txcsr;
> +
> +		/*
> +		 * The programming guide says that we
> +		 * must clear DMAENAB before DMAMODE.
> +		 */
> +		musb_ep_select(mbase, epnum);
> +		txcsr = musb_readw(mbase, offset);
> +		txcsr |=  MUSB_TXCSR_TXPKTRDY;
> +		musb_writew(mbase, offset, txcsr);
> +	}
> +
>  	musb_dma_completion(musb, musb_channel->epnum, musb_channel->transmit);
>  
>  	spin_unlock_irqrestore(&musb->lock, flags);
> @@ -138,8 +164,15 @@ static struct dma_channel *dma_channel_allocate(struct dma_controller *c,
>  			 * issue when TX and RX DMA channels are simultaneously
>  			 * enabled. To work around this issue, use system DMA
>  			 * for all RX channels.
> +			 * Also on MUSB RTL version 1.8 onward (OMAP3630, OMAP4
> +			 * and AM/DM37x) DMA requires buffers to be aligned on
> +			 * a four byte boundary. This affects USB CDC/RNDIS
> +			 * class application where buffers are always unaligned.
> +			 * Using system DMA for unaligned buffers as a
> +			 * workaround for this issue.
>  			 */
> -			if (((musb->hwvers == MUSB_HWVERS_1400) && !transmit)
> +			if ((((musb->hwvers == MUSB_HWVERS_1400) && !transmit)
> +				|| (musb->hwvers >= MUSB_HWVERS_1800))
>  				&& use_sdma_workaround()) {
>  				int ret;
>  				ret = omap_request_dma(OMAP24XX_DMA_NO_DEVICE,
> @@ -194,11 +227,18 @@ static void configure_channel(struct dma_channel *channel,
>  	struct musb *musb = controller->private_data;
>  	void __iomem *mbase = controller->base;
>  	u8 bchannel = musb_channel->idx;
> +	u8 buffer_is_aligned = (dma_addr & 0x3) ? 0 : 1;
> +	u8 use_sdma = (musb_channel->sysdma_channel == -1) ? 0 : 1;
>  	u16 csr = 0;
>  
>  	DBG(4, "%p, pkt_sz %d, addr 0x%x, len %d, mode %d\n",
>  			channel, packet_sz, dma_addr, len, mode);
> -	if (musb_channel->sysdma_channel != -1) {
> +
> +	if (buffer_is_aligned && (packet_sz >= 512) &&
> +			(musb->hwvers >= MUSB_HWVERS_1800))
> +		use_sdma = 0;
> +
> +	if (use_sdma &&	!musb_channel->transmit) {
>  		/* System DMA */
>  		/* RX: set src = FIFO */
>  		omap_set_dma_transfer_params(musb_channel->sysdma_channel,
> @@ -224,6 +264,32 @@ static void configure_channel(struct dma_channel *channel,
>  
>  		omap_start_dma(musb_channel->sysdma_channel);
>  
> +	} else if (use_sdma && musb_channel->transmit) {
> +		/* System DMA */
> +		/* TX: set dst = FIFO */
> +		omap_set_dma_transfer_params(musb_channel->sysdma_channel,
> +					OMAP_DMA_DATA_TYPE_S8,
> +					len ? len : 1, 1, /* One frame */
> +					OMAP_DMA_SYNC_ELEMENT,
> +					OMAP24XX_DMA_NO_DEVICE,
> +					0); /* Src Sync */
> +
> +		omap_set_dma_src_params(musb_channel->sysdma_channel, 0,
> +					OMAP_DMA_AMODE_POST_INC, dma_addr,
> +					0, 0);
> +
> +		omap_set_dma_dest_params(musb_channel->sysdma_channel, 0,
> +					OMAP_DMA_AMODE_CONSTANT,
> +					MUSB_FIFO_ADDRESS(musb->ctrl_phys_base,
> +						musb_channel->epnum),
> +					0, 0);
> +
> +		omap_set_dma_dest_data_pack(musb_channel->sysdma_channel, 0);
> +		omap_set_dma_dest_burst_mode(musb_channel->sysdma_channel,
> +					OMAP_DMA_DATA_BURST_DIS);
> +
> +		omap_start_dma(musb_channel->sysdma_channel);
> +
>  	} else { /* Mentor DMA */
>  
>  	if (mode) {
> @@ -299,6 +365,9 @@ static int dma_channel_abort(struct dma_channel *channel)
>  
>  	if (channel->status == MUSB_DMA_STATUS_BUSY) {
>  		if (musb_channel->transmit) {
> +			if (musb_channel->sysdma_channel != -1)
> +				omap_stop_dma(musb_channel->sysdma_channel);
> +
>   

   Have you thought about e.g. Blackfin? How this is going to compile 
there, without omap_*() functions even existing? Or did you think that 
OMAP is the only user of this driver?

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 4/5] musb: use system DMA for unaligned buffers on RTL >= 1.8

[Gupta, Ajay Kumar]

Hi,
> >  	if (channel->status == MUSB_DMA_STATUS_BUSY) {
> >  		if (musb_channel->transmit) {
> > +			if (musb_channel->sysdma_channel != -1)
> > +				omap_stop_dma(musb_channel->sysdma_channel);
> > +
> >
> 
>    Have you thought about e.g. Blackfin? How this is going to compile
> there, without omap_*() functions even existing? Or did you think that
> OMAP is the only user of this driver?
Thanks for pointing this. It would require adding wrapper functions for
Blckfin's.

-Ajay
> 
> WBR, Sergei

Re: [PATCH 4/5] musb: use system DMA for unaligned buffers on RTL >= 1.8

[Sergei Shtylyov]

Hello.

Gupta, Ajay Kumar wrote:

> Hi,
>   
>>>  	if (channel->status == MUSB_DMA_STATUS_BUSY) {
>>>  		if (musb_channel->transmit) {
>>> +			if (musb_channel->sysdma_channel != -1)
>>> +				omap_stop_dma(musb_channel->sysdma_channel);
>>> +
>>>
>>>       
>>    Have you thought about e.g. Blackfin? How this is going to compile
>> there, without omap_*() functions even existing? Or did you think that
>> OMAP is the only user of this driver?
>>     
> Thanks for pointing this. It would require adding wrapper functions for
> Blckfin's.
>   

   Better wrap your stuff into #ifdef OMAP, I think...

> -Ajay
>   
WBR, Sergei

Re: [PATCH 2/5] musb: use system DMA to fix Inventra DMA issue on RTL-1.4

[Felipe Balbi]

On Wed, May 12, 2010 at 05:19:36PM +0530, Ajay Kumar Gupta wrote:
> MUSB RTL version 1.4 has a hardware issue when TX and RX DMA channels are
> simultaneously enabled which results in DMA lockup.

I've seen it on rtl1.8 also if I remember correctly.

> Use system DMA for all RX channels as a workaround of this issue as this
> will have minimal throughput overhead based on the fact that Rx transfers
> are done in DMA mode-0 on OMAP34x/35x platforms.
> 
> Another approach to use PIO mode in opposite direction would increase the
> cpu loading and thus using system DMA is preferred workaround.
> 
> Signed-off-by: Anand Gadiyar <gadiyar-l0cyMroinI0@public.gmane.org>
> Signed-off-by: Ajay Kumar Gupta <ajay.gupta-l0cyMroinI0@public.gmane.org>

I think falling back to pio is better than this patch. It will most
likely be only one transfer. Another approach is to allocate dma
channels on a transfer basis. This is way too big of a problem.

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] musb: add function to check if Inventra DMA used

[Felipe Balbi]

On Wed, May 12, 2010 at 05:19:37PM +0530, Ajay Kumar Gupta wrote:
> Added is_inventra_dma_enabled() funtion which would be required
> for adding workaround for Inventra DMA issues. It can also be
> used at other places instead of #ifdefs.
> 
> Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>

[..]

> +#ifdef CONFIG_USB_INVENTRA_DMA
> +#define	is_inventra_dma_enabled()	1
> +#else
> +#define	is_inventra_dma_enabled()	0
> +#endif

actually I wanted to get rid of those...

-- 
balbi

Re: [PATCH 4/5] musb: use system DMA for unaligned buffers on RTL >= 1.8

[Felipe Balbi]

On Wed, May 12, 2010 at 05:19:38PM +0530, Ajay Kumar Gupta wrote:
> MUSB RTL version 1.8 onward (OMAP3630, AM/DM37x, OMAP4) DMA requires
> the buffers to be aligned on a four byte boundary. This affects USB
> CDC/RNDIS class application where buffers are always unaligned.
> 
> Use system DMA for unaligned buffers as a workaround of this issue.
> 
> Current patch supports device side CDC/RNDIS. Host side would require
> change in Tx programming path for mode-0 operation when transfer length
> is more than packet size.
> 
> Also fixed an issue in device Tx completion path where 'is_dma' is getting
> set unconditionally. This would fail the io if Tx transfer is done in
> mode-0. Fixed it by updating it based on 'request->actual' length.
> 
> Signed-off-by: Ajay Kumar Gupta <ajay.gupta-l0cyMroinI0@public.gmane.org>

[..]

> @@ -166,6 +166,12 @@ config MUSB_USE_SYSTEM_DMA_WORKAROUND
>            DMA channels are simultaneously enabled. To work around this issue,
>            you can choose to use System DMA for RX channels.
>  
> +	  Also on Mentor DMA in MUSB RTL version 1.8 (OMAP3630, AM/DM37x)
> +	  requires buffers to be aligned on a four byte boundary. This affects
> +	  USB CDC/RNDIS class application where buffers are always unaligned.
> +	  To work around this issue, you can choose to use System DMA for
> +	  unaligned buffers.

instead of this patch, it's a whole lot easier to simply use a bounce
buffer:

if (unaligned) {
	bounce = dma_alloc_coherent(......);
	memcpy(request->buf, bounce, request->length);
}

and use that buffer on channel_program();

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/5] musb: use system DMA for unaligned buffers on RTL >= 1.8

[Felipe Balbi]

On Wed, May 12, 2010 at 06:59:52PM +0400, Sergei Shtylyov wrote:
>    Better wrap your stuff into #ifdef OMAP, I think...

please don't, better to use the bounce buffer... It would work on
blackfin, davinci and omap...

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/5] musb: use system DMA to fix Inventra DMA issue on RTL-1.4

[Gadiyar, Anand]

Felipe Balbi wrote:
> On Wed, May 12, 2010 at 05:19:36PM +0530, Ajay Kumar Gupta wrote:
> > MUSB RTL version 1.4 has a hardware issue when TX and RX DMA channels are
> > simultaneously enabled which results in DMA lockup.
> 
> I've seen it on rtl1.8 also if I remember correctly.
> 

I'm fairly certain that this is not the case with RTL1.8, and if it is I'm very
much interested in getting to the bottom of it. Do you have a test case
that reproduces the lockup? Or a description of your use-case, or
a register dump at failure, or any other clues?

> > Use system DMA for all RX channels as a workaround of this issue as this
> > will have minimal throughput overhead based on the fact that Rx transfers
> > are done in DMA mode-0 on OMAP34x/35x platforms.
> >
> > Another approach to use PIO mode in opposite direction would increase the
> > cpu loading and thus using system DMA is preferred workaround.
> >
> > Signed-off-by: Anand Gadiyar <gadiyar-l0cyMroinI0@public.gmane.org>
> > Signed-off-by: Ajay Kumar Gupta <ajay.gupta-l0cyMroinI0@public.gmane.org>
> 
> I think falling back to pio is better than this patch. It will most
> likely be only one transfer. Another approach is to allocate dma
> channels on a transfer basis. This is way too big of a problem.

Which one is better depends on how many endpoints are doing,
transfers in parallel, I suppose.

I did post the a patch for the other approach (to fall back to PIO).
I haven't received a response to that yet. I'm okay with either approach.


- Anand--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 4/5] musb: use system DMA for unaligned buffers on RTL >= 1.8

[Gupta, Ajay Kumar]

Hi,
> On Wed, May 12, 2010 at 05:19:38PM +0530, Ajay Kumar Gupta wrote:
> > MUSB RTL version 1.8 onward (OMAP3630, AM/DM37x, OMAP4) DMA requires
> > the buffers to be aligned on a four byte boundary. This affects USB
> > CDC/RNDIS class application where buffers are always unaligned.
> >
> > Use system DMA for unaligned buffers as a workaround of this issue.
> >
> > Current patch supports device side CDC/RNDIS. Host side would require
> > change in Tx programming path for mode-0 operation when transfer length
> > is more than packet size.
> >
> > Also fixed an issue in device Tx completion path where 'is_dma' is
> getting
> > set unconditionally. This would fail the io if Tx transfer is done in
> > mode-0. Fixed it by updating it based on 'request->actual' length.
> >
> > Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
> 
> [..]
> 
> > @@ -166,6 +166,12 @@ config MUSB_USE_SYSTEM_DMA_WORKAROUND
> >            DMA channels are simultaneously enabled. To work around this
> issue,
> >            you can choose to use System DMA for RX channels.
> >
> > +	  Also on Mentor DMA in MUSB RTL version 1.8 (OMAP3630, AM/DM37x)
> > +	  requires buffers to be aligned on a four byte boundary. This
> affects
> > +	  USB CDC/RNDIS class application where buffers are always
> unaligned.
> > +	  To work around this issue, you can choose to use System DMA for
> > +	  unaligned buffers.
> 
> instead of this patch, it's a whole lot easier to simply use a bounce
> buffer:
> 
> if (unaligned) {
> 	bounce = dma_alloc_coherent(......);
> 	memcpy(request->buf, bounce, request->length);
> }

How about this 'memcpy', this would affect both cpu loading
and performance. That's why using system dma would be a better
approach.

-Ajay 
> 
> and use that buffer on channel_program();
> 
> --
> balbi

RE: [PATCH 4/5] musb: use system DMA for unaligned buffers on RTL >= 1.8

[Gupta, Ajay Kumar]

Hi,
> -----Original Message-----
> From: Felipe Balbi [mailto:me-uiRdBs8odbtmTBlB0Cgj/Q@public.gmane.org]
> Sent: Wednesday, May 12, 2010 11:26 PM
> To: Sergei Shtylyov
> Cc: Gupta, Ajay Kumar; linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-
> omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: Re: [PATCH 4/5] musb: use system DMA for unaligned buffers on RTL
> >= 1.8
> 
> On Wed, May 12, 2010 at 06:59:52PM +0400, Sergei Shtylyov wrote:
> >    Better wrap your stuff into #ifdef OMAP, I think...
> 
> please don't, better to use the bounce buffer... It would work on
> blackfin, davinci and omap...

Just working is not enough. We need to think of performance and cpu
loading as well.

-Ajay
> 
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/5] musb: use system DMA to fix Inventra DMA issue on RTL-1.4

[Gupta, Ajay Kumar]

Hi,
>Subject: RE: [PATCH 2/5] musb: use system DMA to fix Inventra DMA issue on
> RTL-1.4
> 
> Felipe Balbi wrote:
> > On Wed, May 12, 2010 at 05:19:36PM +0530, Ajay Kumar Gupta wrote:
> > > MUSB RTL version 1.4 has a hardware issue when TX and RX DMA channels
> are
> > > simultaneously enabled which results in DMA lockup.
> >
> > I've seen it on rtl1.8 also if I remember correctly.
> >
> 
> I'm fairly certain that this is not the case with RTL1.8, and if it is I'm
> very
> much interested in getting to the bottom of it. Do you have a test case
> that reproduces the lockup? Or a description of your use-case, or
> a register dump at failure, or any other clues?
> 

Felipe,

I have also not seen lockup issue on rtl1.8. Can you provide more detail
on your test case as Anand asked?

> > > Use system DMA for all RX channels as a workaround of this issue as
> this
> > > will have minimal throughput overhead based on the fact that Rx
> transfers
> > > are done in DMA mode-0 on OMAP34x/35x platforms.
> > >
> > > Another approach to use PIO mode in opposite direction would increase
> the
> > > cpu loading and thus using system DMA is preferred workaround.
> > >
> > > Signed-off-by: Anand Gadiyar <gadiyar-l0cyMroinI0@public.gmane.org>
> > > Signed-off-by: Ajay Kumar Gupta <ajay.gupta-l0cyMroinI0@public.gmane.org>
> >
> > I think falling back to pio is better than this patch.
At the cost of cpu, which certainly is not preferred.

>> It will most likely be only one transfer.

How about host mode with multiple devices connected and doing transfers?
Falling back to PIO would kill the cpu.

>> Another approach is to allocate dma channels on a transfer basis.

Can you elaborate this?

>> This is way too big of a problem.


If we think of the scenarios in host mode then certainly using system DMA is
best approach.

-Ajay
> Which one is better depends on how many endpoints are doing,
> transfers in parallel, I suppose.
> 
> I did post the a patch for the other approach (to fall back to PIO).
> I haven't received a response to that yet. I'm okay with either approach.
> 
> 
> - Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/5] musb: use system DMA to fix Inventra DMA issue on RTL-1.4

[Kalliguddi, Hema]

Hi,

>-----Original Message-----
>From: linux-usb-owner@vger.kernel.org 
>[mailto:linux-usb-owner@vger.kernel.org] On Behalf Of Gupta, Ajay Kumar
>Sent: Thursday, May 13, 2010 9:53 AM
>To: Gadiyar, Anand; me@felipebalbi.com
>Cc: linux-usb@vger.kernel.org; linux-omap@vger.kernel.org
>Subject: RE: [PATCH 2/5] musb: use system DMA to fix Inventra 
>DMA issue on RTL-1.4
>
>Hi,
>>Subject: RE: [PATCH 2/5] musb: use system DMA to fix Inventra 
>DMA issue 
>>on
>> RTL-1.4

>
>Felipe,
>
>> > > Another approach to use PIO mode in opposite direction would 
>> > > increase
>> the
>> > > cpu loading and thus using system DMA is preferred workaround.
>> > >
>> > > Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
>> > > Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
>> >
>> > I think falling back to pio is better than this patch.
>At the cost of cpu, which certainly is not preferred.
>
>>> It will most likely be only one transfer.
>
>How about host mode with multiple devices connected and doing 
>transfers?
>Falling back to PIO would kill the cpu.
>
>>> Another approach is to allocate dma channels on a transfer basis.
>
>Can you elaborate this?

It might be good idea to allocate the dma channels on tarnsfer basis as Felipe
Suggested. The musb driver allocates dma channels for the first 8 enabled 
endpoints and  higher endpoints works in PIO mode. 
For system dma if there are more nummber of Rx endpoints enabled but not used for data 
Transfer you might end up having many sdma channles allocated biut not used which will
Impact in the system of not utilizing the sdma channels effectively.

~Hema

>>> This is way too big of a problem.
>
>
>If we think of the scenarios in host mode then certainly using 
>system DMA is best approach.
>
>-Ajay
>> Which one is better depends on how many endpoints are doing, 
>transfers 
>> in parallel, I suppose.
>> 
>> I did post the a patch for the other approach (to fall back to PIO).
>> I haven't received a response to that yet. I'm okay with 
>either approach.
>> 
>> 
>> - Anand
>--
>To unsubscribe from this list: send the line "unsubscribe 
>linux-usb" in the body of a message to 
>majordomo@vger.kernel.org More majordomo info at  
>http://vger.kernel.org/majordomo-info.html
>

RE: [PATCH 2/5] musb: use system DMA to fix Inventra DMA issue on RTL-1.4

[Gupta, Ajay Kumar]

Hi,
> >> > > Another approach to use PIO mode in opposite direction would
> >> > > increase
> >> the
> >> > > cpu loading and thus using system DMA is preferred workaround.
> >> > >
> >> > > Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
> >> > > Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
> >> >
> >> > I think falling back to pio is better than this patch.
> >At the cost of cpu, which certainly is not preferred.
> >
> >>> It will most likely be only one transfer.
> >
> >How about host mode with multiple devices connected and doing
> >transfers?
> >Falling back to PIO would kill the cpu.
> >
> >>> Another approach is to allocate dma channels on a transfer basis.
> >
> >Can you elaborate this?
> 
> It might be good idea to allocate the dma channels on tarnsfer basis as
> Felipe
> Suggested. The musb driver allocates dma channels for the first 8 enabled
> endpoints and  higher endpoints works in PIO mode.
> For system dma if there are more nummber of Rx endpoints enabled but not
> used for data
> Transfer you might end up having many sdma channles allocated biut not
> used which will
> Impact in the system of not utilizing the sdma channels effectively.

Felipe, Is this what you meant? If so then I have a patch (copied below)
to fix this and I can post this one along with others.

-------------- cut here -----------------
Currently DMA channels are allocated and they remain allocated
even if there is no active data transfer. Added channel_release()
whenever there is no pending request.

Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
---
 drivers/usb/musb/musb_gadget.c |   27 +++++++++++++++++++++------
 drivers/usb/musb/musb_host.c   |   14 ++++++++++++--
 2 files changed, 33 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index fd842af..477a009 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -297,9 +297,13 @@ static void txstate(struct musb *musb, struct musb_request *req)
 			csr);
 
 #ifndef	CONFIG_MUSB_PIO_ONLY
-	if (is_dma_capable() && musb_ep->dma) {
+
+	if (is_dma_capable() && musb->dma_controller) {
 		struct dma_controller	*c = musb->dma_controller;
 
+		if (!musb_ep->dma)
+			musb_ep->dma = c->channel_alloc(c, musb_ep->hw_ep, 1);
+
 		use_dma = (request->dma != DMA_ADDR_INVALID);
 
 		/* MUSB_TXCSR_P_ISO is still set correctly */
@@ -433,6 +437,7 @@ void musb_g_tx(struct musb *musb, u8 epnum)
 	u8 __iomem		*mbase = musb->mregs;
 	struct musb_ep		*musb_ep = &musb->endpoints[epnum].ep_in;
 	void __iomem		*epio = musb->endpoints[epnum].regs;
+	struct dma_controller	*c = musb->dma_controller;
 	struct dma_channel	*dma;
 
 	musb_ep_select(mbase, epnum);
@@ -535,6 +540,10 @@ void musb_g_tx(struct musb *musb, u8 epnum)
 			if (!request) {
 				DBG(4, "%s idle now\n",
 					musb_ep->end_point.name);
+				if (musb_ep->dma) {
+					c->channel_release(musb_ep->dma);
+					musb_ep->dma = NULL;
+				}
 				return;
 			}
 		}
@@ -585,6 +594,7 @@ static void rxstate(struct musb *musb, struct musb_request *req)
 	struct usb_request	*request = &req->request;
 	struct musb_ep		*musb_ep = &musb->endpoints[epnum].ep_out;
 	void __iomem		*epio = musb->endpoints[epnum].regs;
+	struct dma_controller	*c = musb->dma_controller;
 	unsigned		fifo_count = 0;
 	u16			len = musb_ep->packet_sz;
 	u16			csr = musb_readw(epio, MUSB_RXCSR);
@@ -601,8 +611,10 @@ static void rxstate(struct musb *musb, struct musb_request *req)
 		return;
 	}
 
+	if (is_dma_capable() && musb->dma_controller && !musb_ep->dma)
+		musb_ep->dma = c->channel_alloc(c, musb_ep->hw_ep, 0);
+
 	if ((is_cppi_enabled() || is_cppi41_enabled()) && musb_ep->dma) {
-		struct dma_controller	*c = musb->dma_controller;
 		struct dma_channel	*channel = musb_ep->dma;
 
 		/* NOTE:  CPPI won't actually stop advancing the DMA
@@ -633,11 +645,9 @@ static void rxstate(struct musb *musb, struct musb_request *req)
 		if (request->actual < request->length) {
 #ifdef CONFIG_USB_INVENTRA_DMA
 			if (is_dma_capable() && musb_ep->dma) {
-				struct dma_controller	*c;
 				struct dma_channel	*channel;
 				int			use_dma = 0;
 
-				c = musb->dma_controller;
 				channel = musb_ep->dma;
 
 	/* We use DMA Req mode 0 in rx_csr, and DMA controller operates in
@@ -719,7 +729,6 @@ static void rxstate(struct musb *musb, struct musb_request *req)
 
 #ifdef	CONFIG_USB_TUSB_OMAP_DMA
 			if (tusb_dma_omap() && musb_ep->dma) {
-				struct dma_controller *c = musb->dma_controller;
 				struct dma_channel *channel = musb_ep->dma;
 				u32 dma_addr = request->dma + request->actual;
 				int ret;
@@ -764,6 +773,7 @@ void musb_g_rx(struct musb *musb, u8 epnum)
 	void __iomem		*mbase = musb->mregs;
 	struct musb_ep		*musb_ep = &musb->endpoints[epnum].ep_out;
 	void __iomem		*epio = musb->endpoints[epnum].regs;
+	struct dma_controller	*c = musb->dma_controller;
 	struct dma_channel	*dma;
 
 	musb_ep_select(mbase, epnum);
@@ -838,8 +848,13 @@ void musb_g_rx(struct musb *musb, u8 epnum)
 		musb_g_giveback(musb_ep, request, 0);
 
 		request = next_request(musb_ep);
-		if (!request)
+		if (!request) {
+			if (musb_ep->dma) {
+				c->channel_release(musb_ep->dma);
+				musb_ep->dma = NULL;
+			}
 			return;
+		}
 	}
 
 	/* analyze request if the ep is hot */
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 89c8c35..001a1d6 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -460,11 +460,21 @@ static void musb_advance_schedule(struct musb *musb, struct urb *urb,
 	 */
 	if (list_empty(&qh->hep->urb_list)) {
 		struct list_head	*head;
+		struct dma_controller	*dma = musb->dma_controller;
 
-		if (is_in)
+		if (is_in) {
 			ep->rx_reinit = 1;
-		else
+			if (ep->rx_channel) {
+				dma->channel_release(ep->rx_channel);
+				ep->rx_channel = NULL;
+			}
+		} else {
 			ep->tx_reinit = 1;
+			if (ep->tx_channel) {
+				dma->channel_release(ep->tx_channel);
+				ep->tx_channel = NULL;
+			}
+		}
 
 		/* Clobber old pointers to this qh */
 		musb_ep_set_qh(ep, is_in, NULL);
-- 
1.6.2.4


-----------------------------------------
-Ajay
> 

RE: [PATCH 2/5] musb: use system DMA to fix Inventra DMA issue on RTL-1.4

[Kalliguddi, Hema]

Hi,
 

>-----Original Message-----
>From: Gupta, Ajay Kumar 
>Sent: Thursday, May 13, 2010 3:41 PM
>To: Kalliguddi, Hema; Gadiyar, Anand; me@felipebalbi.com
>Cc: linux-usb@vger.kernel.org; linux-omap@vger.kernel.org
>Subject: RE: [PATCH 2/5] musb: use system DMA to fix Inventra 
>DMA issue on RTL-1.4
>
>Hi,
>> >> > > Another approach to use PIO mode in opposite direction would
>> >> > > increase
>> >> the
>> >> > > cpu loading and thus using system DMA is preferred workaround.
>> >> > >
>> >> > > Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
>> >> > > Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
>> >> >
>> >> > I think falling back to pio is better than this patch.
>> >At the cost of cpu, which certainly is not preferred.
>> >
>> >>> It will most likely be only one transfer.
>> >
>> >How about host mode with multiple devices connected and doing
>> >transfers?
>> >Falling back to PIO would kill the cpu.
>> >
>> >>> Another approach is to allocate dma channels on a transfer basis.
>> >
>> >Can you elaborate this?
>> 
>> It might be good idea to allocate the dma channels on 
>tarnsfer basis as
>> Felipe
>> Suggested. The musb driver allocates dma channels for the 
>first 8 enabled
>> endpoints and  higher endpoints works in PIO mode.
>> For system dma if there are more nummber of Rx endpoints 
>enabled but not
>> used for data
>> Transfer you might end up having many sdma channles 
>allocated biut not
>> used which will
>> Impact in the system of not utilizing the sdma channels effectively.
>
>Felipe, Is this what you meant? If so then I have a patch 
>(copied below)
>to fix this and I can post this one along with others.
>
>-------------- cut here -----------------
>Currently DMA channels are allocated and they remain allocated
>even if there is no active data transfer. Added channel_release()
>whenever there is no pending request.
>
>Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
>---
> drivers/usb/musb/musb_gadget.c |   27 +++++++++++++++++++++------
> drivers/usb/musb/musb_host.c   |   14 ++++++++++++--
> 2 files changed, 33 insertions(+), 8 deletions(-)
>
>diff --git a/drivers/usb/musb/musb_gadget.c 
>b/drivers/usb/musb/musb_gadget.c
>index fd842af..477a009 100644
>--- a/drivers/usb/musb/musb_gadget.c
>+++ b/drivers/usb/musb/musb_gadget.c
>@@ -297,9 +297,13 @@ static void txstate(struct musb *musb, 
>struct musb_request *req)
> 			csr);
> 
> #ifndef	CONFIG_MUSB_PIO_ONLY
>-	if (is_dma_capable() && musb_ep->dma) {
>+
>+	if (is_dma_capable() && musb->dma_controller) {
> 		struct dma_controller	*c = musb->dma_controller;
> 
>+		if (!musb_ep->dma)
>+			musb_ep->dma = c->channel_alloc(c, 
>musb_ep->hw_ep, 1);

If the channel_alloc returns failure then there should be a way to fallback to PIO mode.
I am posting a patch for dynamic dma channel allocation for mentor dma for gadget driver.

~Hema
>+
> 		use_dma = (request->dma != DMA_ADDR_INVALID);
> 
> 		/* MUSB_TXCSR_P_ISO is still set correctly */
>@@ -433,6 +437,7 @@ void musb_g_tx(struct musb *musb, u8 epnum)
> 	u8 __iomem		*mbase = musb->mregs;
> 	struct musb_ep		*musb_ep = 
>&musb->endpoints[epnum].ep_in;
> 	void __iomem		*epio = musb->endpoints[epnum].regs;
>+	struct dma_controller	*c = musb->dma_controller;
> 	struct dma_channel	*dma;
> 
> 	musb_ep_select(mbase, epnum);
>@@ -535,6 +540,10 @@ void musb_g_tx(struct musb *musb, u8 epnum)
> 			if (!request) {
> 				DBG(4, "%s idle now\n",
> 					musb_ep->end_point.name);
>+				if (musb_ep->dma) {
>+					
>c->channel_release(musb_ep->dma);
>+					musb_ep->dma = NULL;
>+				}
> 				return;
> 			}
> 		}
>@@ -585,6 +594,7 @@ static void rxstate(struct musb *musb, 
>struct musb_request *req)
> 	struct usb_request	*request = &req->request;
> 	struct musb_ep		*musb_ep = 
>&musb->endpoints[epnum].ep_out;
> 	void __iomem		*epio = musb->endpoints[epnum].regs;
>+	struct dma_controller	*c = musb->dma_controller;
> 	unsigned		fifo_count = 0;
> 	u16			len = musb_ep->packet_sz;
> 	u16			csr = musb_readw(epio, MUSB_RXCSR);
>@@ -601,8 +611,10 @@ static void rxstate(struct musb *musb, 
>struct musb_request *req)
> 		return;
> 	}
> 
>+	if (is_dma_capable() && musb->dma_controller && !musb_ep->dma)
>+		musb_ep->dma = c->channel_alloc(c, musb_ep->hw_ep, 0);
>+
> 	if ((is_cppi_enabled() || is_cppi41_enabled()) && 
>musb_ep->dma) {
>-		struct dma_controller	*c = musb->dma_controller;
> 		struct dma_channel	*channel = musb_ep->dma;
> 
> 		/* NOTE:  CPPI won't actually stop advancing the DMA
>@@ -633,11 +645,9 @@ static void rxstate(struct musb *musb, 
>struct musb_request *req)
> 		if (request->actual < request->length) {
> #ifdef CONFIG_USB_INVENTRA_DMA
> 			if (is_dma_capable() && musb_ep->dma) {
>-				struct dma_controller	*c;
> 				struct dma_channel	*channel;
> 				int			use_dma = 0;
> 
>-				c = musb->dma_controller;
> 				channel = musb_ep->dma;
> 
> 	/* We use DMA Req mode 0 in rx_csr, and DMA controller 
>operates in
>@@ -719,7 +729,6 @@ static void rxstate(struct musb *musb, 
>struct musb_request *req)
> 
> #ifdef	CONFIG_USB_TUSB_OMAP_DMA
> 			if (tusb_dma_omap() && musb_ep->dma) {
>-				struct dma_controller *c = 
>musb->dma_controller;
> 				struct dma_channel *channel = 
>musb_ep->dma;
> 				u32 dma_addr = request->dma + 
>request->actual;
> 				int ret;
>@@ -764,6 +773,7 @@ void musb_g_rx(struct musb *musb, u8 epnum)
> 	void __iomem		*mbase = musb->mregs;
> 	struct musb_ep		*musb_ep = 
>&musb->endpoints[epnum].ep_out;
> 	void __iomem		*epio = musb->endpoints[epnum].regs;
>+	struct dma_controller	*c = musb->dma_controller;
> 	struct dma_channel	*dma;
> 
> 	musb_ep_select(mbase, epnum);
>@@ -838,8 +848,13 @@ void musb_g_rx(struct musb *musb, u8 epnum)
> 		musb_g_giveback(musb_ep, request, 0);
> 
> 		request = next_request(musb_ep);
>-		if (!request)
>+		if (!request) {
>+			if (musb_ep->dma) {
>+				c->channel_release(musb_ep->dma);
>+				musb_ep->dma = NULL;
>+			}
> 			return;
>+		}
> 	}
> 
> 	/* analyze request if the ep is hot */
>diff --git a/drivers/usb/musb/musb_host.c 
>b/drivers/usb/musb/musb_host.c
>index 89c8c35..001a1d6 100644
>--- a/drivers/usb/musb/musb_host.c
>+++ b/drivers/usb/musb/musb_host.c
>@@ -460,11 +460,21 @@ static void musb_advance_schedule(struct 
>musb *musb, struct urb *urb,
> 	 */
> 	if (list_empty(&qh->hep->urb_list)) {
> 		struct list_head	*head;
>+		struct dma_controller	*dma = musb->dma_controller;
> 
>-		if (is_in)
>+		if (is_in) {
> 			ep->rx_reinit = 1;
>-		else
>+			if (ep->rx_channel) {
>+				dma->channel_release(ep->rx_channel);
>+				ep->rx_channel = NULL;
>+			}
>+		} else {
> 			ep->tx_reinit = 1;
>+			if (ep->tx_channel) {
>+				dma->channel_release(ep->tx_channel);
>+				ep->tx_channel = NULL;
>+			}
>+		}
> 
> 		/* Clobber old pointers to this qh */
> 		musb_ep_set_qh(ep, is_in, NULL);
>-- 
>1.6.2.4
>
>
>-----------------------------------------
>-Ajay
>> 
>

Re: [PATCH 4/5] musb: use system DMA for unaligned buffers on RTL >= 1.8

[Felipe Balbi]

On Thu, May 13, 2010 at 09:44:11AM +0530, Gupta, Ajay Kumar wrote:
> Hi,
> > -----Original Message-----
> > From: Felipe Balbi [mailto:me-uiRdBs8odbtmTBlB0Cgj/Q@public.gmane.org]
> > Sent: Wednesday, May 12, 2010 11:26 PM
> > To: Sergei Shtylyov
> > Cc: Gupta, Ajay Kumar; linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-
> > omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Subject: Re: [PATCH 4/5] musb: use system DMA for unaligned buffers on RTL
> > >= 1.8
> > 
> > On Wed, May 12, 2010 at 06:59:52PM +0400, Sergei Shtylyov wrote:
> > >    Better wrap your stuff into #ifdef OMAP, I think...
> > 
> > please don't, better to use the bounce buffer... It would work on
> > blackfin, davinci and omap...
> 
> Just working is not enough. We need to think of performance and cpu
> loading as well.

allocating a bounce buffer doesn't take long and you can still use
mentor DMA to transfer the data.

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 4/5] musb: use system DMA for unaligned buffers on RTL >= 1.8

[Gupta, Ajay Kumar]

Hi,
> On Thu, May 13, 2010 at 09:44:11AM +0530, Gupta, Ajay Kumar wrote:
> > Hi,
> > > -----Original Message-----
> > > From: Felipe Balbi [mailto:me@felipebalbi.com]
> > > Sent: Wednesday, May 12, 2010 11:26 PM
> > > To: Sergei Shtylyov
> > > Cc: Gupta, Ajay Kumar; linux-usb@vger.kernel.org; linux-
> > > omap@vger.kernel.org
> > > Subject: Re: [PATCH 4/5] musb: use system DMA for unaligned buffers on
> RTL
> > > >= 1.8
> > >
> > > On Wed, May 12, 2010 at 06:59:52PM +0400, Sergei Shtylyov wrote:
> > > >    Better wrap your stuff into #ifdef OMAP, I think...
> > >
> > > please don't, better to use the bounce buffer... It would work on
> > > blackfin, davinci and omap...
> >
> > Just working is not enough. We need to think of performance and cpu
> > loading as well.
> 
> allocating a bounce buffer doesn't take long and you can still use
> mentor DMA to transfer the data.

But there is a memcpy involved right? It will use cpu and thus would be
hitting on performance, cpu loading and power consumption. Instead why
not use other available system resources (system dma)to do this job.

I understand, some platform may not support/have system dma then they can surely use bounce buffer or use PIO mode.

There was another workaround proposed earlier which was using 'memmove'
(similar to memcpy) that was badly affecting cpu loading. I was hardly getting 50Mbits/sec of throughput with 100% loading. Instead when I tried system DMA, numbers went up to 90Mbits/sec  with a cpu loading of 50%.

I think we must use system DMA for this issue and also have bounce buffer
Or PIO fallback mechanism in place for platforms not supporting system DMA.

Regards,
Ajay
> 
> --
> balbi

Re: [PATCH 4/5] musb: use system DMA for unaligned buffers on RTL >= 1.8

[Felipe Balbi]

On Thu, May 13, 2010 at 06:13:00AM +0200, ext Gupta, Ajay Kumar wrote:
>How about this 'memcpy', this would affect both cpu loading
>and performance. That's why using system dma would be a better
>approach.

but that's not portable. Even if you come up with nice wrappers for 
system dma usage (which is already ugly, more exported functions) you 
might end up on a board where system dma has same alignment constraints 
as mentor dma. Either fall back to pio or use a bounce buffer. That'll 
work always.

Besides, the only offending gadget driver we have is g_ether and that's 
already 'fixed' by the alignment patch to g_ether. Any other gadget 
driver causing that, should be fixed too...

-- 
balbi

DefectiveByDesign.org
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 4/5] musb: use system DMA for unaligned buffers on RTL >= 1.8

[Gupta, Ajay Kumar]

Hi,
> -----Original Message-----
> From: Felipe Balbi [mailto:felipe.balbi@nokia.com]
> Sent: Friday, May 14, 2010 4:37 PM
> To: Gupta, Ajay Kumar
> Cc: me@felipebalbi.com; linux-usb@vger.kernel.org; linux-
> omap@vger.kernel.org
> Subject: Re: [PATCH 4/5] musb: use system DMA for unaligned buffers on RTL
> >= 1.8
> 
> On Thu, May 13, 2010 at 06:13:00AM +0200, ext Gupta, Ajay Kumar wrote:
> >How about this 'memcpy', this would affect both cpu loading
> >and performance. That's why using system dma would be a better
> >approach.
> 
> but that's not portable.
> Even if you come up with nice wrappers for
> system dma usage (which is already ugly, more exported functions) you
> might end up on a board where system dma has same alignment constraints
> as mentor dma.

It can't be an OMAP3 based board but yes, future platform could have
such limitations but they should not restrict other platforms
to use system dma which can handle unaligned buffers.

> Either fall back to pio or use a bounce buffer. That'll
> work always.

Agreed but performance we should allow system dma approach also.

> 
> Besides, the only offending gadget driver we have is g_ether and that's
> already 'fixed' by the alignment patch to g_ether.

No, it's not fixed. It had two issues,
1. 	Cache coherency as we observed iperf failing and after using
	Cache_flush_all() things started working.
2. 	High cpu loading of 100% and bit rate of only 30Mbits/sec due
	To memmove and cache_flush..

-Ajay
> Any other gadget
> driver causing that, should be fixed too...
> 
> --
> balbi
> 
> DefectiveByDesign.org