Skip to contentSkip to conversation

spi: dw: make DMA working

PATCH Applied Andy Shevchenko 4 participants 27 messages Sep 18, 2014 – Oct 16, 2014 17 messages not in the archive

Subsystems (2)

v1 of 3 Applied Latest is v3 →

lore
Share & tools
lore
#0 lore raw

cover spi: dw: make DMA working

This patch series dedicated to make DMA working on Intel Medfield device with SPI DW and DW DMA.

NOTE: the patch 9/10 depends on recent slave-dma.git tree branch for-linus. It would be nice to have a topic branch for that there. Vinod?

Vinod, since the patch 10/10 removes the driver your are author of, please give your Ack or NAck.

The driver was tested in loop back mode. It still has bugs (I don't know is it related to Medfield SoC or generic ones), but now it's in much better shape. Earlier I submit already two fixes of kernel crashes. It looks like there are not so many users of it right now, but I would really appreciate if anyone could test the driver on different hardware platforms.

Mark, the patch 9/10 fixes the bug we discussed earlier (memore leak in probe()).

Andy Shevchenko (10):
spi: dw-mid: respect 8 bit mode
spi: dw-mid: always use duplex transfers when DMA
spi: dw-mid: terminate ongoing transfers at exit
spi: dw-mid: follow new DMAengine workflow
spi: dw: disable all interrupts first when pump message
spi: dw: introduce support of loopback mode
spi: dw: fix style of code in few places
spi: dw-mid: move to use core SPI DMA mappings
spi: dw-mid: convert to use dw_dmac instead of intel_mid_dma
dmaengine: intel-mid-dma: remove the driver

 drivers/dma/Kconfig              |   13 -
 drivers/dma/Makefile             |    1 -
 drivers/dma/intel_mid_dma.c      | 1460 --------------------------------------
 drivers/dma/intel_mid_dma_regs.h |  299 --------
 drivers/spi/Kconfig              |    2 +-
 drivers/spi/spi-dw-mid.c         |   96 +--
 drivers/spi/spi-dw.c             |   55 +-
 drivers/spi/spi-dw.h             |   15 +-
 include/linux/intel_mid_dma.h    |   76 --
 9 files changed, 85 insertions(+), 1932 deletions(-)
 delete mode 100644 drivers/dma/intel_mid_dma.c
 delete mode 100644 drivers/dma/intel_mid_dma_regs.h
 delete mode 100644 include/linux/intel_mid_dma.h
Signature · 6 lines
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 1411060140-2801-1-git-send-email-andriy.shevchenko-VuQAYsv1563Yd54FQh9/[email protected]

#2 lore raw

PATCH 1/10 spi: dw-mid: respect 8 bit mode

In case of 8 bit mode and DMA usage we end up with every second byte written as
0. We have to respect bits_per_word settings what this patch actually does.

---
 drivers/spi/spi-dw-mid.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/spi/spi-dw-mid.c +2 -2
index c4b9f64..f7f0ad2 100644
@@ -136,7 +136,7 @@ static int mid_spi_dma_transfer(struct dw_spi *dws, int cs_change)
 	txconf.dst_addr = dws->dma_addr;
 	txconf.dst_maxburst = LNW_DMA_MSIZE_16;
 	txconf.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
-	txconf.dst_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
+	txconf.dst_addr_width = dws->dma_width;
 	txconf.device_fc = false;
 
 	txchan->device->device_control(txchan, DMA_SLAVE_CONFIG,
@@ -159,7 +159,7 @@ static int mid_spi_dma_transfer(struct dw_spi *dws, int cs_change)
 	rxconf.src_addr = dws->dma_addr;
 	rxconf.src_maxburst = LNW_DMA_MSIZE_16;
 	rxconf.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
-	rxconf.src_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
+	rxconf.src_addr_width = dws->dma_width;
 	rxconf.device_fc = false;
 
 	rxchan->device->device_control(rxchan, DMA_SLAVE_CONFIG,
Signature · 6 lines
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 1411060140-2801-2-git-send-email-andriy.shevchenko-VuQAYsv1563Yd54FQh9/[email protected]

Applied
#4 lore raw

Re: [PATCH 01/10] spi: dw-mid: respect 8 bit mode

Quoted 2 lines · Andy Shevchenko

In case of 8 bit mode and DMA usage we end up with every second byte written as
0. We have to respect bits_per_word settings what this patch actually does.

Applied, thanks.

#5 lore raw

PATCH 2/10 spi: dw-mid: always use duplex transfers when DMA

In reply to a message not in the archive

In case of DMA we never got things done until we enable both channels. In case of receive only or send only mode the user has to provide a dummy buffer.

---
 drivers/spi/spi-dw-mid.c | 6 ++----
 drivers/spi/spi-dw.h     | 4 ++++
 2 files changed, 6 insertions(+), 4 deletions(-)
drivers/spi/spi-dw-mid.c +2 -4
index f7f0ad2..97156e4 100644
@@ -119,10 +119,8 @@ static int mid_spi_dma_transfer(struct dw_spi *dws, int cs_change)
 		spi_enable_chip(dws, 0);
 		dw_writew(dws, DW_SPI_DMARDLR, 0xf);
 		dw_writew(dws, DW_SPI_DMATDLR, 0x10);
-		if (dws->tx_dma)
-			dma_ctrl |= 0x2;
-		if (dws->rx_dma)
-			dma_ctrl |= 0x1;
+		dma_ctrl |= SPI_DMA_TDMAE;
+		dma_ctrl |= SPI_DMA_RDMAE;
 		dw_writew(dws, DW_SPI_DMACR, dma_ctrl);
 		spi_enable_chip(dws, 1);
 	}
drivers/spi/spi-dw.h +4 -0
index 089fc4b..83a103a 100644
@@ -74,6 +74,10 @@
 #define SPI_INT_RXFI			(1 << 4)
 #define SPI_INT_MSTI			(1 << 5)
 
+/* Bit fields in DMACR */
+#define SPI_DMA_RDMAE			(1 << 0)
+#define SPI_DMA_TDMAE			(1 << 1)
+
 /* TX RX interrupt level threshold, max can be 256 */
 #define SPI_INT_THRESHOLD		32
 
Signature · 6 lines
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 1411060140-2801-3-git-send-email-andriy.shevchenko-VuQAYsv1563Yd54FQh9/[email protected]

#7 lore raw

Re: [PATCH 02/10] spi: dw-mid: always use duplex transfers when DMA

Quoted 2 lines · Andy Shevchenko

In case of DMA we never got things done until we enable both channels. In case of receive only or send only mode the user has to provide a dummy buffer.

The driver must never impose such requirements on clients, they shouldn't need to know about the quirks of the controller. There's support in the core providing dummy buffers for transmit and receive, you should use that (possibly extending it so the dummies are only provided for DMA).

A message that is not in the archive (sent off-list or not yet received): [email protected]

#9 lore raw

Re: [PATCH 02/10] spi: dw-mid: always use duplex transfers when DMA

Quoted 9 lines · Mark Brown
Quoted 2 lines · Andy Shevchenko

In case of DMA we never got things done until we enable both channels. In case of receive only or send only mode the user has to provide a dummy buffer.

The driver must never impose such requirements on clients, they shouldn't need to know about the quirks of the controller. There's support in the core providing dummy buffers for transmit and receive, you should use that (possibly extending it so the dummies are only provided for DMA).

Currently driver in case of receiving or sending only will never call the xfer_done from DMA callback since we never will have counter equal to 2. So, the driver already relies on duplex mode. Am I missing something?

Signature · 7 lines
Andy Shevchenko <[email protected]>
Intel Finland Oy

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 1411554747.30231.10.camel-VuQAYsv1563Yd54FQh9/[email protected]

#11 lore raw

Re: [PATCH 02/10] spi: dw-mid: always use duplex transfers when DMA

Quoted 12 lines · Andy Shevchenko
Quoted 10 lines · Mark Brown
Quoted 2 lines · Andy Shevchenko

In case of DMA we never got things done until we enable both channels. In case of receive only or send only mode the user has to provide a dummy buffer.

The driver must never impose such requirements on clients, they shouldn't need to know about the quirks of the controller. There's support in the core providing dummy buffers for transmit and receive, you should use that (possibly extending it so the dummies are only provided for DMA).

Quoted 4 lines

Currently driver in case of receiving or sending only will never call the xfer_done from DMA callback since we never will have counter equal to 2. So, the driver already relies on duplex mode. Am I missing something?

Please re-read what I wrote above, especially the first phrase. You can't require that we rewrite essentialy every SPI driver on the off chance that it's used with this controller.

A message that is not in the archive (sent off-list or not yet received): [email protected]

#13 lore raw

Re: [PATCH 02/10] spi: dw-mid: always use duplex transfers when DMA

Quoted 13 lines · Mark Brown
Quoted 11 lines · Andy Shevchenko
Quoted 10 lines · Mark Brown
Quoted 2 lines · Andy Shevchenko

In case of DMA we never got things done until we enable both channels. In case of receive only or send only mode the user has to provide a dummy buffer.

The driver must never impose such requirements on clients, they shouldn't need to know about the quirks of the controller. There's support in the core providing dummy buffers for transmit and receive, you should use that (possibly extending it so the dummies are only provided for DMA).

Quoted 8 lines
Quoted 4 lines

Currently driver in case of receiving or sending only will never call the xfer_done from DMA callback since we never will have counter equal to 2. So, the driver already relies on duplex mode. Am I missing something?

Please re-read what I wrote above, especially the first phrase. You can't require that we rewrite essentialy every SPI driver on the off chance that it's used with this controller.

I think I know how to satisfy the user and fix the driver. I will remake the approach.

Signature · 7 lines
Andy Shevchenko <[email protected]>
Intel Finland Oy

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#14 lore raw

PATCH 3/10 spi: dw-mid: terminate ongoing transfers at exit

In reply to a message not in the archive

Do full clean up at exit, means terminate all ongoing DMA transfers.

---
 drivers/spi/spi-dw-mid.c | 4 ++++
 1 file changed, 4 insertions(+)
drivers/spi/spi-dw-mid.c +4 -0
index 97156e4..27150c7 100644
@@ -89,7 +89,11 @@ static void mid_spi_dma_exit(struct dw_spi *dws)
 {
 	if (!dws->dma_inited)
 		return;
+
+	dmaengine_terminate_all(dws->txchan);
 	dma_release_channel(dws->txchan);
+
+	dmaengine_terminate_all(dws->rxchan);
 	dma_release_channel(dws->rxchan);
 }
 
Signature · 6 lines
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 1411060140-2801-4-git-send-email-andriy.shevchenko-VuQAYsv1563Yd54FQh9/[email protected]

Applied
#16 lore raw

Re: [PATCH 03/10] spi: dw-mid: terminate ongoing transfers at exit

Quoted 1 line · Andy Shevchenko

Do full clean up at exit, means terminate all ongoing DMA transfers.

Applied, thanks.

#17 lore raw

PATCH 4/10 spi: dw-mid: follow new DMAengine workflow

In reply to a message not in the archive

Though intel-mid-dma does not follow a new DMA workflow let's prepare SPI DW driver for that.

---
 drivers/spi/spi-dw-mid.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/spi/spi-dw-mid.c +6 -2
index 27150c7..a62413d 100644
@@ -152,7 +152,7 @@ static int mid_spi_dma_transfer(struct dw_spi *dws, int cs_change)
 				&dws->tx_sgl,
 				1,
 				DMA_MEM_TO_DEV,
-				DMA_PREP_INTERRUPT);
+				DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
 	txdesc->callback = dw_spi_dma_done;
 	txdesc->callback_param = dws;
 
@@ -175,13 +175,17 @@ static int mid_spi_dma_transfer(struct dw_spi *dws, int cs_change)
 				&dws->rx_sgl,
 				1,
 				DMA_DEV_TO_MEM,
-				DMA_PREP_INTERRUPT);
+				DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
 	rxdesc->callback = dw_spi_dma_done;
 	rxdesc->callback_param = dws;
 
 	/* rx must be started before tx due to spi instinct */
 	rxdesc->tx_submit(rxdesc);
 	txdesc->tx_submit(txdesc);
+
+	dma_async_issue_pending(rxchan);
+	dma_async_issue_pending(txchan);
+
 	return 0;
 }
 
Signature · 6 lines
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 1411060140-2801-5-git-send-email-andriy.shevchenko-VuQAYsv1563Yd54FQh9/[email protected]

#19 lore raw

Re: [PATCH 04/10] spi: dw-mid: follow new DMAengine workflow

Quoted 2 lines · Andy Shevchenko

Though intel-mid-dma does not follow a new DMA workflow let's prepare SPI DW driver for that.

I don't understand what this change is supposed to do - what is "a new DMA workflow"?

A message that is not in the archive (sent off-list or not yet received): [email protected]

#21 lore raw

Re: [PATCH 04/10] spi: dw-mid: follow new DMAengine workflow

Quoted 6 lines · Mark Brown
Quoted 2 lines · Andy Shevchenko

Though intel-mid-dma does not follow a new DMA workflow let's prepare SPI DW driver for that.

I don't understand what this change is supposed to do - what is "a new DMA workflow"?

The client is obliged to call dma_async_issue_pending() which starts the actual transfers. Old DMA drivers do not follow this, since requirement was introduced in 2011 IIRC.

Current DMA driver for spi-dw doesn't follow this, but dw_dmac does.

Signature · 7 lines
Andy Shevchenko <[email protected]>
Intel Finland Oy

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 1411554938.30231.12.camel-VuQAYsv1563Yd54FQh9/[email protected]

#23 lore raw

Re: [PATCH 04/10] spi: dw-mid: follow new DMAengine workflow

Quoted 5 lines · Andy Shevchenko
Quoted 3 lines · Mark Brown
Quoted 2 lines · Andy Shevchenko

Though intel-mid-dma does not follow a new DMA workflow let's prepare SPI DW driver for that.

Quoted 8 lines
Quoted 2 lines

I don't understand what this change is supposed to do - what is "a new DMA workflow"?

The client is obliged to call dma_async_issue_pending() which starts the actual transfers. Old DMA drivers do not follow this, since requirement was introduced in 2011 IIRC.

Current DMA driver for spi-dw doesn't follow this, but dw_dmac does.

So be specific about it missing the call so someone reading the changelog can understand what this is supposed to do.

A message that is not in the archive (sent off-list or not yet received): [email protected]

#25 lore raw

Re: [PATCH 04/10] spi: dw-mid: follow new DMAengine workflow

Quoted 9 lines · Mark Brown
Quoted 7 lines · Andy Shevchenko
Quoted 6 lines · Mark Brown
Quoted 2 lines · Andy Shevchenko

Though intel-mid-dma does not follow a new DMA workflow let's prepare SPI DW driver for that.

I don't understand what this change is supposed to do - what is "a new DMA workflow"?

Quoted 8 lines
Quoted 5 lines

The client is obliged to call dma_async_issue_pending() which starts the actual transfers. Old DMA drivers do not follow this, since requirement was introduced in 2011 IIRC.

Current DMA driver for spi-dw doesn't follow this, but dw_dmac does.

So be specific about it missing the call so someone reading the changelog can understand what this is supposed to do.

Will do.

Signature · 7 lines
Andy Shevchenko <[email protected]>
Intel Finland Oy

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#26 lore raw

PATCH 5/10 spi: dw: disable all interrupts first when pump message

In reply to a message not in the archive

Always disable all interrupts before pump message. Enable them only for PIO mode.

---
 drivers/spi/spi-dw.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)
drivers/spi/spi-dw.c +11 -4
index 0960cc7..d58edfe 100644
@@ -342,6 +342,13 @@ static irqreturn_t dw_spi_irq(int irq, void *dev_id)
 	return dws->transfer_handler(dws);
 }
 
+static void dw_spi_disable_intr(struct dw_spi *dws)
+{
+	spi_enable_chip(dws, 0);
+	spi_mask_intr(dws, 0xff);
+	spi_enable_chip(dws, 1);
+}
+
 /* Must be called inside pump_transfers() */
 static void poll_transfer(struct dw_spi *dws)
 {
@@ -474,6 +481,9 @@ static void pump_transfers(unsigned long data)
 		dws->transfer_handler = interrupt_transfer;
 	}
 
+	/* Disable all interrupts first */
+	dw_spi_disable_intr(dws);
+
 	/*
 	 * Reprogram registers only if
 	 *	1. chip select changes
@@ -490,7 +500,6 @@ static void pump_transfers(unsigned long data)
 		spi_chip_sel(dws, spi, 1);
 
 		/* Set the interrupt mask, for poll mode just disable all int */
-		spi_mask_intr(dws, 0xff);
 		if (imask)
 			spi_umask_intr(dws, imask);
 		if (txint_level)
@@ -611,9 +620,7 @@ static void dw_spi_cleanup(struct spi_device *spi)
 /* Restart the controller, disable all interrupts, clean rx fifo */
 static void spi_hw_init(struct dw_spi *dws)
 {
-	spi_enable_chip(dws, 0);
-	spi_mask_intr(dws, 0xff);
-	spi_enable_chip(dws, 1);
+	dw_spi_disable_intr(dws);
 
 	/*
 	 * Try to detect the FIFO depth if not set by interface driver,
Signature · 6 lines
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 1411060140-2801-6-git-send-email-andriy.shevchenko-VuQAYsv1563Yd54FQh9/[email protected]

#28 lore raw

Re: [PATCH 05/10] spi: dw: disable all interrupts first when pump message

Quoted 2 lines · Andy Shevchenko

Always disable all interrupts before pump message. Enable them only for PIO mode.

Why?

It's also not very obvious looking at the diff how this actually works, the connection between DMA based transfer and interrupt disabling is not clear.

A message that is not in the archive (sent off-list or not yet received): [email protected]

#30 lore raw

Re: [PATCH 05/10] spi: dw: disable all interrupts first when pump message

Quoted 10 lines · Mark Brown
Quoted 2 lines · Andy Shevchenko

Always disable all interrupts before pump message. Enable them only for PIO mode.

Why?

It's also not very obvious looking at the diff how this actually works, the connection between DMA based transfer and interrupt disabling is not clear.

It's a really good question and needs to be investigated more.

If I don't disable interrupts I'm getting sometimes overrun/underrun interrupt. But we have no proper transfer handler in case of DMA.

Perhaps we should carefully handle that case.

Signature · 7 lines
Andy Shevchenko <[email protected]>
Intel Finland Oy

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#31 lore raw

PATCH 6/10 spi: dw: introduce support of loopback mode

In reply to a message not in the archive

For testing purposes it's good to have a loopback mode enabled. The patch adds necessary bits for that.

---
 drivers/spi/spi-dw.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/spi/spi-dw.c +4 -1
index d58edfe..54e195b 100644
@@ -599,6 +599,9 @@ static int dw_spi_setup(struct spi_device *spi)
 			| (spi->mode  << SPI_MODE_OFFSET)
 			| (chip->tmode << SPI_TMOD_OFFSET);
 
+	if (spi->mode & SPI_LOOP)
+		chip->cr0 |= 1 << SPI_SRL_OFFSET;
+
 	if (gpio_is_valid(spi->cs_gpio)) {
 		ret = gpio_direction_output(spi->cs_gpio,
 				!(spi->mode & SPI_CS_HIGH));
@@ -666,7 +669,7 @@ int dw_spi_add_host(struct device *dev, struct dw_spi *dws)
 		goto err_free_master;
 	}
 
-	master->mode_bits = SPI_CPOL | SPI_CPHA;
+	master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_LOOP;
 	master->bits_per_word_mask = SPI_BPW_MASK(8) | SPI_BPW_MASK(16);
 	master->bus_num = dws->bus_num;
 	master->num_chipselect = dws->num_cs;
Signature · 6 lines
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 1411060140-2801-7-git-send-email-andriy.shevchenko-VuQAYsv1563Yd54FQh9/[email protected]

Applied
#33 lore raw

Re: [PATCH 06/10] spi: dw: introduce support of loopback mode

Quoted 2 lines · Andy Shevchenko

For testing purposes it's good to have a loopback mode enabled. The patch adds necessary bits for that.

Applied, thanks.

#34 lore raw

PATCH 7/10 spi: dw: fix style of code in few places

In reply to a message not in the archive

Make comments be surrounded by spaces and move part of code to one line where it suits 80 characters.

There is no functional changes.

---
 drivers/spi/spi-dw.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)
drivers/spi/spi-dw.c +3 -4
index 54e195b..11c7613 100644
@@ -397,7 +397,7 @@ static void pump_transfers(unsigned long data)
 		goto early_exit;
 	}
 
-	/* Delay if requested at end of transfer*/
+	/* Delay if requested at end of transfer */
 	if (message->state == RUNNING_STATE) {
 		previous = list_entry(transfer->transfer_list.prev,
 					struct spi_transfer,
@@ -528,7 +528,7 @@ static int dw_spi_transfer_one_message(struct spi_master *master,
 	struct dw_spi *dws = spi_master_get_devdata(master);
 
 	dws->cur_msg = msg;
-	/* Initial message state*/
+	/* Initial message state */
 	dws->cur_msg->state = START_STATE;
 	dws->cur_transfer = list_entry(dws->cur_msg->transfers.next,
 						struct spi_transfer,
@@ -659,8 +659,7 @@ int dw_spi_add_host(struct device *dev, struct dw_spi *dws)
 	dws->prev_chip = NULL;
 	dws->dma_inited = 0;
 	dws->dma_addr = (dma_addr_t)(dws->paddr + 0x60);
-	snprintf(dws->name, sizeof(dws->name), "dw_spi%d",
-			dws->bus_num);
+	snprintf(dws->name, sizeof(dws->name), "dw_spi%d", dws->bus_num);
 
 	ret = devm_request_irq(dev, dws->irq, dw_spi_irq, IRQF_SHARED,
 			dws->name, dws);
Signature · 6 lines
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 1411060140-2801-8-git-send-email-andriy.shevchenko-VuQAYsv1563Yd54FQh9/[email protected]

Applied
#36 lore raw

Re: [PATCH 07/10] spi: dw: fix style of code in few places

Quoted 2 lines · Andy Shevchenko

Make comments be surrounded by spaces and move part of code to one line where it suits 80 characters.

Applied, thanks.

#37 lore raw

PATCH 8/10 spi: dw-mid: move to use core SPI DMA mappings

In reply to a message not in the archive

SPI core has a comprehensive function set to map and unmap a message when it's needed. This patch converts driver to use that advantage.

---
 drivers/spi/spi-dw-mid.c | 31 +++++++++++++++++++------------
 drivers/spi/spi-dw.c     | 28 +++++-----------------------
 drivers/spi/spi-dw.h     |  6 ++----
 3 files changed, 26 insertions(+), 39 deletions(-)
drivers/spi/spi-dw-mid.c +19 -12
index a62413d..fad7425 100644
@@ -66,6 +66,7 @@ static int mid_spi_dma_init(struct dw_spi *dws)
 	rxs->hs_mode = LNW_DMA_HW_HS;
 	rxs->cfg_mode = LNW_DMA_PER_TO_MEM;
 	dws->rxchan->private = rxs;
+	dws->master->dma_rx = dws->rxchan;
 
 	/* 2. Init tx channel */
 	dws->txchan = dma_request_channel(mask, mid_spi_dma_chan_filter, dws);
@@ -75,6 +76,7 @@ static int mid_spi_dma_init(struct dw_spi *dws)
 	txs->hs_mode = LNW_DMA_HW_HS;
 	txs->cfg_mode = LNW_DMA_MEM_TO_PER;
 	dws->txchan->private = txs;
+	dws->master->dma_tx = dws->txchan;
 
 	dws->dma_inited = 1;
 	return 0;
@@ -97,6 +99,17 @@ static void mid_spi_dma_exit(struct dw_spi *dws)
 	dma_release_channel(dws->rxchan);
 }
 
+static bool mid_spi_can_dma(struct spi_master *master, struct spi_device *spi,
+		struct spi_transfer *xfer)
+{
+	struct dw_spi *dws = spi_master_get_devdata(master);
+
+	if (!dws->dma_inited)
+		return false;
+
+	return xfer->len > dws->fifo_len;
+}
+
 /*
  * dws->dma_chan_done is cleared before the dma transfer starts,
  * callback for rx/tx channel will each increment it by 1.
@@ -113,6 +126,7 @@ static void dw_spi_dma_done(void *arg)
 
 static int mid_spi_dma_transfer(struct dw_spi *dws, int cs_change)
 {
+	struct spi_transfer *xfer = dws->cur_transfer;
 	struct dma_async_tx_descriptor *txdesc = NULL, *rxdesc = NULL;
 	struct dma_chan *txchan, *rxchan;
 	struct dma_slave_config txconf, rxconf;
@@ -144,13 +158,9 @@ static int mid_spi_dma_transfer(struct dw_spi *dws, int cs_change)
 	txchan->device->device_control(txchan, DMA_SLAVE_CONFIG,
 				       (unsigned long) &txconf);
 
-	memset(&dws->tx_sgl, 0, sizeof(dws->tx_sgl));
-	dws->tx_sgl.dma_address = dws->tx_dma;
-	dws->tx_sgl.length = dws->len;
-
 	txdesc = dmaengine_prep_slave_sg(txchan,
-				&dws->tx_sgl,
-				1,
+				xfer->tx_sg.sgl,
+				xfer->tx_sg.nents,
 				DMA_MEM_TO_DEV,
 				DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
 	txdesc->callback = dw_spi_dma_done;
@@ -167,13 +177,9 @@ static int mid_spi_dma_transfer(struct dw_spi *dws, int cs_change)
 	rxchan->device->device_control(rxchan, DMA_SLAVE_CONFIG,
 				       (unsigned long) &rxconf);
 
-	memset(&dws->rx_sgl, 0, sizeof(dws->rx_sgl));
-	dws->rx_sgl.dma_address = dws->rx_dma;
-	dws->rx_sgl.length = dws->len;
-
 	rxdesc = dmaengine_prep_slave_sg(rxchan,
-				&dws->rx_sgl,
-				1,
+				xfer->rx_sg.sgl,
+				xfer->rx_sg.nents,
 				DMA_DEV_TO_MEM,
 				DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
 	rxdesc->callback = dw_spi_dma_done;
@@ -192,6 +198,7 @@ static int mid_spi_dma_transfer(struct dw_spi *dws, int cs_change)
 static struct dw_spi_dma_ops mid_dma_ops = {
 	.dma_init	= mid_spi_dma_init,
 	.dma_exit	= mid_spi_dma_exit,
+	.can_dma	= mid_spi_can_dma,
 	.dma_transfer	= mid_spi_dma_transfer,
 };
 #endif
drivers/spi/spi-dw.c +5 -23
index 11c7613..3379946 100644
@@ -226,28 +226,6 @@ static void *next_transfer(struct dw_spi *dws)
 	return DONE_STATE;
 }
 
-/*
- * Note: first step is the protocol driver prepares
- * a dma-capable memory, and this func just need translate
- * the virt addr to physical
- */
-static int map_dma_buffers(struct dw_spi *dws)
-{
-	if (!dws->cur_msg->is_dma_mapped
-		|| !dws->dma_inited
-		|| !dws->cur_chip->enable_dma
-		|| !dws->dma_ops)
-		return 0;
-
-	if (dws->cur_transfer->tx_dma)
-		dws->tx_dma = dws->cur_transfer->tx_dma;
-
-	if (dws->cur_transfer->rx_dma)
-		dws->rx_dma = dws->cur_transfer->rx_dma;
-
-	return 1;
-}
-
 /* Caller already set message->status; dma and pio irqs are blocked */
 static void giveback(struct dw_spi *dws)
 {
@@ -364,6 +342,7 @@ static void poll_transfer(struct dw_spi *dws)
 static void pump_transfers(unsigned long data)
 {
 	struct dw_spi *dws = (struct dw_spi *)data;
+	struct spi_master *master = dws->master;
 	struct spi_message *message = NULL;
 	struct spi_transfer *transfer = NULL;
 	struct spi_transfer *previous = NULL;
@@ -464,7 +443,8 @@ static void pump_transfers(unsigned long data)
 	}
 
 	/* Check if current transfer is a DMA transaction */
-	dws->dma_mapped = map_dma_buffers(dws);
+	if (master->can_dma && master->can_dma(master, spi, transfer))
+		dws->dma_mapped = master->cur_msg_mapped;
 
 	/*
 	 * Interrupt mode
@@ -685,6 +665,8 @@ int dw_spi_add_host(struct device *dev, struct dw_spi *dws)
 		if (ret) {
 			dev_warn(&master->dev, "DMA init failed\n");
 			dws->dma_inited = 0;
+		} else {
+			master->can_dma = dws->dma_ops->can_dma;
 		}
 	}
 
drivers/spi/spi-dw.h +2 -4
index 83a103a..436678f4 100644
@@ -91,6 +91,8 @@ struct dw_spi;
 struct dw_spi_dma_ops {
 	int (*dma_init)(struct dw_spi *dws);
 	void (*dma_exit)(struct dw_spi *dws);
+	bool (*can_dma)(struct spi_master *master, struct spi_device *spi,
+			struct spi_transfer *xfer);
 	int (*dma_transfer)(struct dw_spi *dws, int cs_change);
 };
 
@@ -125,8 +127,6 @@ struct dw_spi {
 	int			dma_mapped;
 	dma_addr_t		rx_dma;
 	dma_addr_t		tx_dma;
-	size_t			rx_map_len;
-	size_t			tx_map_len;
 	u8			n_bytes;	/* current is a 1/2 bytes op */
 	u8			max_bits_per_word;	/* maxim is 16b */
 	u32			dma_width;
@@ -136,9 +136,7 @@ struct dw_spi {
 	/* Dma info */
 	int			dma_inited;
 	struct dma_chan		*txchan;
-	struct scatterlist	tx_sgl;
 	struct dma_chan		*rxchan;
-	struct scatterlist	rx_sgl;
 	int			dma_chan_done;
 	struct device		*dma_dev;
 	dma_addr_t		dma_addr; /* phy address of the Data register */
Signature · 6 lines
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#38 lore raw

PATCH 9/10 spi: dw-mid: convert to use dw_dmac instead of intel_mid_dma

In reply to a message not in the archive

intel_mid_dma seems to be unmaintained for a long time. Moreover, the IP block of DMA itself is the same in both dw_dmac and intel_mid_dma. This patch moves spi-dw-midpci to use dw_dmac driver.

---
 drivers/spi/Kconfig      |  2 +-
 drivers/spi/spi-dw-mid.c | 43 +++++++++++++++++++------------------------
 drivers/spi/spi-dw.h     |  5 +++--
 3 files changed, 23 insertions(+), 27 deletions(-)
drivers/spi/Kconfig +1 -1
index dc10453..d1b0a33 100644
@@ -601,7 +601,7 @@ config SPI_DW_PCI
 
 config SPI_DW_MID_DMA
 	bool "DMA support for DW SPI controller on Intel MID platform"
-	depends on SPI_DW_PCI && INTEL_MID_DMAC
+	depends on SPI_DW_PCI && DW_DMAC_PCI
 
 config SPI_DW_MMIO
 	tristate "Memory-mapped io interface driver for DW SPI core"
drivers/spi/spi-dw-mid.c +19 -24

91 lines not on this page · raw message

drivers/spi/spi-dw.h +3 -2
index 436678f4..5d3f0d5 100644
@@ -133,7 +133,7 @@ struct dw_spi {
 	irqreturn_t		(*transfer_handler)(struct dw_spi *dws);
 	void			(*cs_control)(u32 command);
 
-	/* Dma info */
+	/* DMA info */
 	int			dma_inited;
 	struct dma_chan		*txchan;
 	struct dma_chan		*rxchan;
@@ -141,7 +141,8 @@ struct dw_spi {
 	struct device		*dma_dev;
 	dma_addr_t		dma_addr; /* phy address of the Data register */
 	struct dw_spi_dma_ops	*dma_ops;
-	void			*dma_priv; /* platform relate info */
+	void			*dma_tx;
+	void			*dma_rx;
 
 	/* Bus interface info */
 	void			*priv;
Signature · 6 lines
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#39 lore raw

PATCH 10/10 dmaengine: intel-mid-dma: remove the driver

In reply to a message not in the archive

Since the last and the only user of this driver is converted to use dw_dmac we can remove driver from the tree.

Moreover, besides the driver is unmaintained a long time, it serves for the DesignWare DMA IP, for which we have already driver in the tree.

---
 drivers/dma/Kconfig              |   13 -
 drivers/dma/Makefile             |    1 -
 drivers/dma/intel_mid_dma.c      | 1460 --------------------------------------
 drivers/dma/intel_mid_dma_regs.h |  299 --------
 include/linux/intel_mid_dma.h    |   76 --
 5 files changed, 1849 deletions(-)
 delete mode 100644 drivers/dma/intel_mid_dma.c
 delete mode 100644 drivers/dma/intel_mid_dma_regs.h
 delete mode 100644 include/linux/intel_mid_dma.h
drivers/dma/Kconfig +0 -13
index 9b1ea0e..ef74b0a 100644
@@ -51,19 +51,6 @@ config INTEL_MIC_X100_DMA
 	  OS and tools for MIC to use with this driver are available from
 	  <http://software.intel.com/en-us/mic-developer>.
 
-config INTEL_MID_DMAC
-	tristate "Intel MID DMA support for Peripheral DMA controllers"
-	depends on PCI && X86
-	select DMA_ENGINE
-	default n
-	help
-	  Enable support for the Intel(R) MID DMA engine present
-	  in Intel MID chipsets.
-
-	  Say Y here if you have such a chipset.
-
-	  If unsure, say N.
-
 config ASYNC_TX_ENABLE_CHANNEL_SWITCH
 	bool
 
drivers/dma/Makefile +0 -1
index c6adb92..2af96e9 100644
@@ -7,7 +7,6 @@ obj-$(CONFIG_DMA_ACPI) += acpi-dma.o
 obj-$(CONFIG_DMA_OF) += of-dma.o
 
 obj-$(CONFIG_NET_DMA) += iovlock.o
-obj-$(CONFIG_INTEL_MID_DMAC) += intel_mid_dma.o
 obj-$(CONFIG_DMATEST) += dmatest.o
 obj-$(CONFIG_INTEL_IOATDMA) += ioat/
 obj-$(CONFIG_INTEL_IOP_ADMA) += iop-adma.o
drivers/dma/intel_mid_dma.c deleted +0 -1460

1,460 lines not on this page · raw message

drivers/dma/intel_mid_dma_regs.h deleted +0 -299

299 lines not on this page · raw message

include/linux/intel_mid_dma.h deleted +0 -76

76 lines not on this page · raw message

Signature · 6 lines
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 1411060140-2801-11-git-send-email-andriy.shevchenko-VuQAYsv1563Yd54FQh9/[email protected]

#41 lore raw

Re: [PATCH 10/10] dmaengine: intel-mid-dma: remove the driver

Quoted 5 lines · Andy Shevchenko

Since the last and the only user of this driver is converted to use dw_dmac we can remove driver from the tree.

Moreover, besides the driver is unmaintained a long time, it serves for the DesignWare DMA IP, for which we have already driver in the tree.

I dont mind, two things:

- were the spi changes merged, if so we cna queue up post rc1
- have you added support for iDMA in DW? I dont think that I have seen stuff on that

Signature · 6 lines
~Vinod

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

#43 lore raw

Re: [PATCH 10/10] dmaengine: intel-mid-dma: remove the driver

T24gV2VkLCAyMDE0LTEwLTE1IGF0IDIwOjM3ICswNTMwLCBWaW5vZCBLb3VsIHdyb3RlOg0KPiBP biBUaHUsIFNlcCAxOCwgMjAxNCBhdCAwODowOTowMFBNICswMzAwLCBBbmR5IFNoZXZjaGVua28g d3JvdGU6DQo+ID4gU2luY2UgdGhlIGxhc3QgYW5kIHRoZSBvbmx5IHVzZXIgb2YgdGhpcyBkcml2 ZXIgaXMgY29udmVydGVkIHRvIHVzZSBkd19kbWFjIHdlDQo+ID4gY2FuIHJlbW92ZSBkcml2ZXIg ZnJvbSB0aGUgdHJlZS4NCj4gPiANCj4gPiBNb3Jlb3ZlciwgYmVzaWRlcyB0aGUgZHJpdmVyIGlz IHVubWFpbnRhaW5lZCBhIGxvbmcgdGltZSwgaXQgc2VydmVzIGZvciB0aGUNCj4gPiBEZXNpZ25X YXJlIERNQSBJUCwgZm9yIHdoaWNoIHdlIGhhdmUgYWxyZWFkeSBkcml2ZXIgaW4gdGhlIHRyZWUu DQo+IEkgZG9udCBtaW5kLCB0d28gdGhpbmdzOg0KPiANCj4gLSB3ZXJlIHRoZSBzcGkgY2hhbmdl cyBtZXJnZWQsIGlmIHNvIHdlIGNuYSBxdWV1ZSB1cCBwb3N0IHJjMQ0KDQpUaGVyZSBhcmUgZmV3 IHBhdGNoZXMgYWdhaW5zdCBzcGkgZHcgdGhhdCBzaG91bGQgYmUgYWRkcmVzc2VkLiBJdCdzDQph cHBhcmVudGx5IGEgbWF0ZXJpYWwgZm9yIHYzLjE5KC1yYzEpLCBzbywgd2UgaGF2ZSB0aW1lLg0K DQo+IC0gaGF2ZSB5b3UgYWRkZWQgc3VwcG9ydCBmb3IgaURNQSBpbiBEVz8gSSBkb250IHRoaW5r IHRoYXQgSSBoYXZlIHNlZW4gc3R1ZmYNCj4gICBvbiB0aGF0DQoNCmludGVsX21pZF9kbWEgZG9l c24ndCBzdXBwb3J0IHRoaXMgaW4gdXBzdHJlYW0gYXMgZmFyIGFzIEkgY2FuIHNlZS4gSQ0KZG9u J3QgdGhpbmsgaXQncyByZWxhdGVkIHRvIHRoZSB0b3BpYy4NCg0KTmV2ZXJ0aGVsZXNzLCBhbnN3 ZXJpbmcgdG8geW91ciBxdWVzdGlvbiB0aGUgaURNQSBzdXBwb3J0IGlzIGluIHBsYW4gZm9yDQp2 My4xOSgtcmMxKS4NCg0KLS0gDQpBbmR5IFNoZXZjaGVua28gPGFuZHJpeS5zaGV2Y2hlbmtvQGlu dGVsLmNvbT4NCkludGVsIEZpbmxhbmQgT3kNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpJbnRlbCBGaW5sYW5kIE95 ClJlZ2lzdGVyZWQgQWRkcmVzczogUEwgMjgxLCAwMDE4MSBIZWxzaW5raSAKQnVzaW5lc3MgSWRl bnRpdHkgQ29kZTogMDM1NzYwNiAtIDQgCkRvbWljaWxlZCBpbiBIZWxzaW5raSAKClRoaXMgZS1t YWlsIGFuZCBhbnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG1hdGVyaWFs IGZvcgp0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmll dyBvciBkaXN0cmlidXRpb24KYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZApyZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzLgo=

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html