Skip to contentSkip to conversation

dmaengine: sh: Add Support SuperH DMA Engine driver

PATCH In review Nobuhiro Iwamatsu 3 participants 3 messages Sep 7, 2009 – Nov 10, 2009

Subsystems (2)
SuperH dmaengine
lore
Share & tools
lore

Nobuhiro Iwamatsu

author
#0 lore raw

PATCH v7 1/1 dmaengine: sh: Add Support SuperH DMA Engine driver

Hi,

Quoted 6 lines · Dan Williams

Yes, the locking looks better in this version. Can you respin this patch against async_tx.git/next [1]? The 'tx_list' field of struct dma_async_tx_descriptor is set to be removed in 2.6.32, so you need to define it locally in struct sh_desc. Once that is done and you get an ack from Paul I will add this to the queue for 2.6.32.

I remove tx_list from source and check working. This work fine. I resend patch.

Paul, could you check and ack this patch?

Best regards,
Nobuhiro

-----

This supported all DMA channels, and it was tested in SH7722, SH7780, SH7785 and SH7763.
This can not use with SH DMA API.

Signed-off-by Nobuhiro Iwamatsu <[email protected]>
Reviewed-by Matt Fleming <[email protected]>
Reviewed-by Dan Williams <[email protected]>
Acked-by Maciej Sosnowski <[email protected]>

---
v7: Remove tx_list.

 arch/sh/drivers/dma/Kconfig  |   12 +-
 arch/sh/drivers/dma/Makefile |    3 +-
 arch/sh/include/asm/dma-sh.h |   13 +
 drivers/dma/Kconfig          |    8 +
 drivers/dma/Makefile         |    1 +
 drivers/dma/shdma.c          |  786 ++++++++++++++++++++++++++++++++++++++++++
 drivers/dma/shdma.h          |   64 ++++
 7 files changed, 882 insertions(+), 5 deletions(-)
 create mode 100644 drivers/dma/shdma.c
 create mode 100644 drivers/dma/shdma.h
arch/sh/drivers/dma/Kconfig +9 -3
index 63e9dd3..f935a7e 100644
@@ -1,12 +1,9 @@
 menu "DMA support"
 
-config SH_DMA_API
-	bool
 
 config SH_DMA
 	bool "SuperH on-chip DMA controller (DMAC) support"
 	depends on CPU_SH3 || CPU_SH4
-	select SH_DMA_API
 	default n
 
 config SH_DMA_IRQ_MULTI

@@ -19,6 +16,15 @@ config SH_DMA_IRQ_MULTI
 		     CPU_SUBTYPE_SH7780  || CPU_SUBTYPE_SH7785  || \
 		     CPU_SUBTYPE_SH7760
 
+config SH_DMA_API
+	depends on SH_DMA
+	bool "SuperH DMA API support"
+	default n
+	help
+	  SH_DMA_API always enabled DMA API of used SuperH.
+	  If you want to use DMA ENGINE, you must not enable this.
+	  Please enable DMA_ENGINE and SH_DMAE.
+
 config NR_ONCHIP_DMA_CHANNELS
 	int
 	depends on SH_DMA
arch/sh/drivers/dma/Makefile +1 -2
index c606813..d88c948 100644
@@ -2,8 +2,7 @@
 # Makefile for the SuperH DMA specific kernel interface routines under Linux.
 #
 
-obj-$(CONFIG_SH_DMA_API)	+= dma-api.o dma-sysfs.o
-obj-$(CONFIG_SH_DMA)		+= dma-sh.o
+obj-$(CONFIG_SH_DMA_API)	+= dma-sh.o dma-api.o dma-sysfs.o
 obj-$(CONFIG_PVR2_DMA)		+= dma-pvr2.o
 obj-$(CONFIG_G2_DMA)		+= dma-g2.o
 obj-$(CONFIG_SH_DMABRG)		+= dmabrg.o
arch/sh/include/asm/dma-sh.h +13 -0
index 0c8f8e1..89bdac5 100644
@@ -115,4 +115,17 @@ static u32 dma_base_addr[] __maybe_unused = {
 #define CHCR    0x0C
 #define DMAOR	0x40
 
+/*
+ * for dma engine
+ *
+ * SuperH DMA mode
+ */
+#define SHDMA_MIX_IRQ	(1 << 1)
+#define SHDMA_DMAOR1	(1 << 2)
+#define SHDMA_DMAE1		(1 << 3)
+
+struct sh_dmae_pdata {
+	unsigned int mode;
+};
+
 #endif /* __DMA_SH_H */
drivers/dma/Kconfig +8 -0
index fe1f371..3230a78 100644
@@ -101,6 +101,14 @@ config TXX9_DMAC
 	  Support the TXx9 SoC internal DMA controller.  This can be
 	  integrated in chips such as the Toshiba TX4927/38/39.
 
+config SH_DMAE
+	tristate "Renesas SuperH DMAC support"
+	depends on SUPERH && SH_DMA
+	depends on !SH_DMA_API
+	select DMA_ENGINE
+	help
+	  Enable support for the Renesas SuperH DMA controllers.
+
 config DMA_ENGINE
 	bool
drivers/dma/Makefile +1 -0
index 8f115e9..eca71ba 100644
@@ -9,3 +9,4 @@ obj-$(CONFIG_DW_DMAC) += dw_dmac.o
 obj-$(CONFIG_AT_HDMAC) += at_hdmac.o
 obj-$(CONFIG_MX3_IPU) += ipu/
 obj-$(CONFIG_TXX9_DMAC) += txx9dmac.o
+obj-$(CONFIG_SH_DMAE) += shdma.o
drivers/dma/shdma.c new file +784 -0

784 lines not on this page · raw message

drivers/dma/shdma.h new file +64 -0

64 lines not on this page · raw message

Signature · 1 line
1.6.3.3
Acked-by on v7 1/1
#1 lore raw
Quoted 9 lines · Nobuhiro Iwamatsu
Quoted 6 lines · Dan Williams

Yes, the locking looks better in this version. Can you respin this patch against async_tx.git/next [1]? The 'tx_list' field of struct dma_async_tx_descriptor is set to be removed in 2.6.32, so you need to define it locally in struct sh_desc. Once that is done and you get an ack from Paul I will add this to the queue for 2.6.32.

Quoted 5 lines

I remove tx_list from source and check working. This work fine. I resend patch.

Paul, could you check and ack this patch?

Acked-by Paul Mundt <[email protected]>
#2 lore raw
In reply to Nobuhiro Iwamatsu

Hi all

Quoted 11 lines · Nobuhiro Iwamatsu

Hi,

Quoted 6 lines · Dan Williams

Yes, the locking looks better in this version. Can you respin this patch against async_tx.git/next [1]? The 'tx_list' field of struct dma_async_tx_descriptor is set to be removed in 2.6.32, so you need to define it locally in struct sh_desc. Once that is done and you get an ack from Paul I will add this to the queue for 2.6.32.

Quoted 4 lines

I remove tx_list from source and check working. This work fine. I resend patch.

Paul, could you check and ack this patch?

got a question to this driver: so far it only exports the DMA_MEMCPY capability. But the DMAC is also serving various onboard and external peripherals, which is normally done using the DMA_SLAVE capability. Is this what is supported by this driver using the .set_chcr() and .set_dmars() API extensions? Wouldn't it be better to switch to DMA_SLAVE and replace those callbacks with just some static channel parameters, provided by the board? Isn't providing those callbacks also dangerous, because you don't know in what context the user is calling them so, you cannot ensure proper locking?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/