spi: dw: make DMA working
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]
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
@@ -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]
Mark Brown
AppliedRe: [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 respectbits_per_wordsettings what this patch actually does.
Applied, thanks.
PATCH 2/10 spi: dw-mid: always use duplex transfers when DMA
In reply to a message not in the archiveIn 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
@@ -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
@@ -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]
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]
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]
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_donefrom 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]
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_donefrom 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
PATCH 3/10 spi: dw-mid: terminate ongoing transfers at exit
In reply to a message not in the archiveDo 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
@@ -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]
Mark Brown
AppliedRe: [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.
PATCH 4/10 spi: dw-mid: follow new DMAengine workflow
In reply to a message not in the archiveThough 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
@@ -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]
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]
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]
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_dmacdoes.
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]
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_dmacdoes.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
PATCH 5/10 spi: dw: disable all interrupts first when pump message
In reply to a message not in the archiveAlways 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
@@ -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]
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]
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
PATCH 6/10 spi: dw: introduce support of loopback mode
In reply to a message not in the archiveFor 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
@@ -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]
Mark Brown
AppliedRe: [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.
PATCH 7/10 spi: dw: fix style of code in few places
In reply to a message not in the archiveMake 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
@@ -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]
Mark Brown
AppliedRe: [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.
PATCH 8/10 spi: dw-mid: move to use core SPI DMA mappings
In reply to a message not in the archiveSPI 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
@@ -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
@@ -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
@@ -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
PATCH 9/10 spi: dw-mid: convert to use dw_dmac instead of intel_mid_dma
In reply to a message not in the archiveintel_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
@@ -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
@@ -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
PATCH 10/10 dmaengine: intel-mid-dma: remove the driver
In reply to a message not in the archiveSince 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
@@ -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
@@ -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]
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_dmacwe 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]
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