Skip to contentSkip to conversation

s3c24xx: fix DMA support for MCI

PATCH Superseded Vasily Khoruzhick 1 participant 6 messages Aug 18, 2010 – Aug 27, 2010

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

cover s3c24xx: fix DMA support for MCI

This series fixes DMA support for s3c24xx SoCs, now it's possible to use DMA with s3cmci driver.

In-Reply-To:

#1 lore raw

PATCH 1/2 s3c24xx: DMA: don't use autoreload feature

Some integrated DMA-capable hardware doesn't like autoreload feature of s3c24xx DMA-engine, that's why s3cmci driver didn't work with DMA transfers enabled.

I rewrote DMA driver not to use autoreload feature and removed all pre-loading features. Buffer re-load is fast enought to perform it in IRQ handler, and anyway I don't see any reason to waste CPU cycles on waiting for buffer load. Driver is much simplier now, it was tested with s3cmci and s3c24xx-i2s drivers on s3c2442 and s3c2410 SoCs and works just nice.

---
 arch/arm/mach-s3c2410/include/mach/dma.h |   13 +-
 arch/arm/plat-s3c24xx/dma.c              |  426 +++++-------------------------
 2 files changed, 68 insertions(+), 371 deletions(-)
arch/arm/mach-s3c2410/include/mach/dma.h +3 -10
index cf68136..198826f 100644
@@ -79,16 +79,9 @@ enum s3c2410_dma_state {
  *
  * There are no buffers loaded (the channel should be inactive)
  *
- * S3C2410_DMA_1LOADED
- *
- * There is one buffer loaded, however it has not been confirmed to be
- * loaded by the DMA engine. This may be because the channel is not
- * yet running, or the DMA driver decided that it was too costly to
- * sit and wait for it to happen.
- *
  * S3C2410_DMA_1RUNNING
  *
- * The buffer has been confirmed running, and not finisged
+ * The buffer has been confirmed running, and not finished
  *
  * S3C2410_DMA_1LOADED_1RUNNING
  *
@@ -98,9 +91,7 @@ enum s3c2410_dma_state {
 
 enum s3c2410_dma_loadst {
 	S3C2410_DMALOAD_NONE,
-	S3C2410_DMALOAD_1LOADED,
 	S3C2410_DMALOAD_1RUNNING,
-	S3C2410_DMALOAD_1LOADED_1RUNNING,
 };
 
 
@@ -129,6 +120,7 @@ struct s3c2410_dma_buf {
 	dma_addr_t		 data;		/* start of DMA data */
 	dma_addr_t		 ptr;		/* where the DMA got to [1] */
 	void			*id;		/* client's id */
+	unsigned int		timestamp;
 };
 
 /* [1] is this updated for both recv/send modes? */
@@ -189,6 +181,7 @@ struct s3c2410_dma_chan {
 	struct s3c2410_dma_buf	*curr;		/* current dma buffer */
 	struct s3c2410_dma_buf	*next;		/* next buffer to load */
 	struct s3c2410_dma_buf	*end;		/* end of queue */
+	spinlock_t				queue_lock;
 
 	/* system device */
 	struct sys_device	dev;
arch/arm/plat-s3c24xx/dma.c +65 -361

572 lines not on this page · raw message

Signature · 1 line
1.7.2
#2 lore raw

PATCH 1/2 s3c24xx: DMA: don't use autoreload feature

? ????????? ?? 18 ??????? 2010 18:04:25 ????? Vasily Khoruzhick ???????:

Quoted 10 lines

Some integrated DMA-capable hardware doesn't like autoreload feature of s3c24xx DMA-engine, that's why s3cmci driver didn't work with DMA transfers enabled.

I rewrote DMA driver not to use autoreload feature and removed all pre-loading features. Buffer re-load is fast enought to perform it in IRQ handler, and anyway I don't see any reason to waste CPU cycles on waiting for buffer load. Driver is much simplier now, it was tested with s3cmci and s3c24xx-i2s drivers on s3c2442 and s3c2410 SoCs and works just nice.

Patch has problem with suspend/resume (chan->dcon is clobbered by dma_sel->select())

Will resend fixed version soon.

Regards
Vasily
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100827/ac1c701a/attachment.sig>

#3 lore raw

PATCH v2 1/2 s3c24xx: DMA: don't use autoreload feature

In reply to Vasily Khoruzhick

Some integrated DMA-capable hardware doesn't like autoreload feature of s3c24xx DMA-engine, that's why s3cmci driver didn't work with DMA transfers enabled.

I rewrote DMA driver not to use autoreload feature and removed all pre-loading features. Buffer re-load is fast enought to perform it in IRQ handler, and anyway I don't see any reason to waste CPU cycles on waiting for buffer load. Driver is much simplier now, it was tested with s3cmci and s3c24xx-i2s drivers on s3c2442 and s3c2410 SoCs and works just nice.

---
 arch/arm/mach-s3c2410/include/mach/dma.h |   13 +-
 arch/arm/plat-s3c24xx/dma.c              |  442 +++++-------------------------
 2 files changed, 75 insertions(+), 380 deletions(-)
arch/arm/mach-s3c2410/include/mach/dma.h +3 -10
index cf68136..198826f 100644
@@ -79,16 +79,9 @@ enum s3c2410_dma_state {
  *
  * There are no buffers loaded (the channel should be inactive)
  *
- * S3C2410_DMA_1LOADED
- *
- * There is one buffer loaded, however it has not been confirmed to be
- * loaded by the DMA engine. This may be because the channel is not
- * yet running, or the DMA driver decided that it was too costly to
- * sit and wait for it to happen.
- *
  * S3C2410_DMA_1RUNNING
  *
- * The buffer has been confirmed running, and not finisged
+ * The buffer has been confirmed running, and not finished
  *
  * S3C2410_DMA_1LOADED_1RUNNING
  *
@@ -98,9 +91,7 @@ enum s3c2410_dma_state {
 
 enum s3c2410_dma_loadst {
 	S3C2410_DMALOAD_NONE,
-	S3C2410_DMALOAD_1LOADED,
 	S3C2410_DMALOAD_1RUNNING,
-	S3C2410_DMALOAD_1LOADED_1RUNNING,
 };
 
 
@@ -129,6 +120,7 @@ struct s3c2410_dma_buf {
 	dma_addr_t		 data;		/* start of DMA data */
 	dma_addr_t		 ptr;		/* where the DMA got to [1] */
 	void			*id;		/* client's id */
+	unsigned int		timestamp;
 };
 
 /* [1] is this updated for both recv/send modes? */
@@ -189,6 +181,7 @@ struct s3c2410_dma_chan {
 	struct s3c2410_dma_buf	*curr;		/* current dma buffer */
 	struct s3c2410_dma_buf	*next;		/* next buffer to load */
 	struct s3c2410_dma_buf	*end;		/* end of queue */
+	spinlock_t				queue_lock;
 
 	/* system device */
 	struct sys_device	dev;
arch/arm/plat-s3c24xx/dma.c +72 -370

606 lines not on this page · raw message

Signature · 1 line
1.7.2
#4 lore raw

PATCH 2/2 s3cmci: minor fixups

In reply to Vasily Khoruzhick

- It's not necessary to start DMA op manually, as we have autostart feature enabled
- Restore prescaler before DMA operation, otherwise it takes ages to complete DMA op.

---
 drivers/mmc/host/s3cmci.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
drivers/mmc/host/s3cmci.c +2 -2
index 2e16e0a..5d1a8ed 100644
@@ -1106,6 +1106,8 @@ static int s3cmci_prepare_dma(struct s3cmci_host *host, struct mmc_data *data)
 		    sg_dma_address(&data->sg[i]),
 		    sg_dma_len(&data->sg[i]));
 
+		/* Restore prescaler value */
+		writel(host->prescaler, host->base + S3C2410_SDIPRE);
 		res = s3c2410_dma_enqueue(host->dma, host,
 					  sg_dma_address(&data->sg[i]),
 					  sg_dma_len(&data->sg[i]));
@@ -1116,8 +1118,6 @@ static int s3cmci_prepare_dma(struct s3cmci_host *host, struct mmc_data *data)
 		}
 	}
 
-	s3c2410_dma_ctrl(host->dma, S3C2410_DMAOP_START);
-
 	return 0;
 }
 
Signature · 1 line
1.7.2
#5 lore raw

cover s3c24xx: fix DMA support for MCI

In reply to Vasily Khoruzhick

? ????????? ?? 18 ??????? 2010 18:04:24 ????? Vasily Khoruzhick ???????:

Quoted 2 lines

This series fixes DMA support for s3c24xx SoCs, now it's possible to use DMA with s3cmci driver.

Ping :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100824/658cc709/attachment.sig>