[RESEND] spi: davinci: Allow device tree devices to use DMA

[RESEND] spi: davinci: Allow device tree devices to use DMA

[David Lechner]

This allows SPI devices specified in a device tree to use DMA when the
master controller.

Since device tree is supposed to only describe the hardware, adding such
a configuration option to device tree would not be acceptable. So, this
is the best we can do for now to get SPI devices working with DMA.

Unfortunately, this excludes the possibility of using one SPI device with
DMA and one without on the same master.

Signed-off-by: David Lechner <david@lechnology.com>
---

When I originally submitted this patch, there was some discussion as to whether
dspi->dma_rx should be changed to return an error rather than being null.

However, I prefer it the way it is and don't see a compelling reason to change
it.

 drivers/spi/spi-davinci.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
index d36c11b..c6cf73a 100644
--- a/drivers/spi/spi-davinci.c
+++ b/drivers/spi/spi-davinci.c
@@ -388,6 +388,7 @@ static int davinci_spi_setup_transfer(struct spi_device *spi,
 static int davinci_spi_of_setup(struct spi_device *spi)
 {
 	struct davinci_spi_config *spicfg = spi->controller_data;
+	struct davinci_spi *dspi = spi_master_get_devdata(spi->master);
 	struct device_node *np = spi->dev.of_node;
 	u32 prop;
 
@@ -400,6 +401,9 @@ static int davinci_spi_of_setup(struct spi_device *spi)
 		if (!of_property_read_u32(np, "ti,spi-wdelay", &prop))
 			spicfg->wdelay = (u8)prop;
 		spi->controller_data = spicfg;
+		/* Use DMA for device if master supports it */
+		if (dspi->dma_rx)
+			spicfg->io_type = SPI_IO_TYPE_DMA;
 	}
 
 	return 0;
-- 
2.7.4

Re: [RESEND] spi: davinci: Allow device tree devices to use DMA

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]

On Thu, Jan 05, 2017 at 09:26:17PM -0600, David Lechner wrote:

> This allows SPI devices specified in a device tree to use DMA when the
> master controller.

> Since device tree is supposed to only describe the hardware, adding such
> a configuration option to device tree would not be acceptable. So, this
> is the best we can do for now to get SPI devices working with DMA.

> Unfortunately, this excludes the possibility of using one SPI device with
> DMA and one without on the same master.

Why would you ever want to do that?  What would ever make sense about
not using DMA if it's available and the transfer is suitably large, or
conversely why would one want to force DMA even if PIO would be more
performant?

> When I originally submitted this patch, there was some discussion as to whether
> dspi->dma_rx should be changed to return an error rather than being null.

> However, I prefer it the way it is and don't see a compelling reason to change
> it.

I don't know what the above comment means, sorry (and don't recall
having seen any earlier versions of this).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RESEND] spi: davinci: Allow device tree devices to use DMA

[David Lechner]

On 01/09/2017 01:48 PM, Mark Brown wrote:
> On Thu, Jan 05, 2017 at 09:26:17PM -0600, David Lechner wrote:
>
>> This allows SPI devices specified in a device tree to use DMA when the
>> master controller.
>
>> Since device tree is supposed to only describe the hardware, adding such
>> a configuration option to device tree would not be acceptable. So, this
>> is the best we can do for now to get SPI devices working with DMA.
>
>> Unfortunately, this excludes the possibility of using one SPI device with
>> DMA and one without on the same master.
>
> Why would you ever want to do that?  What would ever make sense about
> not using DMA if it's available and the transfer is suitably large, or
> conversely why would one want to force DMA even if PIO would be more
> performant?

I don't particularly want to do that, but that is the way the 
spi-davinci driver currently works. The choice between DMA or PIO is 
specified in the platform data on a per-device basis.

What I get from your remarks is that this is wrong and it needs to be 
fixed. If that is so, could someone please point out a driver that does 
it the right way and I will try to fix it.


>
>> When I originally submitted this patch, there was some discussion as to whether
>> dspi->dma_rx should be changed to return an error rather than being null.
>
>> However, I prefer it the way it is and don't see a compelling reason to change
>> it.
>
> I don't know what the above comment means, sorry (and don't recall
> having seen any earlier versions of this).
>

FWIW, you can find the previous conversation at 
https://patchwork.kernel.org/patch/9437901/

Re: [RESEND] spi: davinci: Allow device tree devices to use DMA

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2073 bytes --]

On Mon, Jan 09, 2017 at 02:40:50PM -0600, David Lechner wrote:
> On 01/09/2017 01:48 PM, Mark Brown wrote:
> > On Thu, Jan 05, 2017 at 09:26:17PM -0600, David Lechner wrote:

> > > Unfortunately, this excludes the possibility of using one SPI device with
> > > DMA and one without on the same master.

> > Why would you ever want to do that?  What would ever make sense about
> > not using DMA if it's available and the transfer is suitably large, or
> > conversely why would one want to force DMA even if PIO would be more
> > performant?

> I don't particularly want to do that, but that is the way the spi-davinci
> driver currently works. The choice between DMA or PIO is specified in the
> platform data on a per-device basis.

> What I get from your remarks is that this is wrong and it needs to be fixed.
> If that is so, could someone please point out a driver that does it the
> right way and I will try to fix it.

Pretty much any driver doing DMA...  off the top of my head the i.MX and
Samsung drivers ought to be reasonable examples.  If you've got time to
look at fixing the driver the other thing that jumps out with it is the
use of a threaded interrupt handler with no actual handling in the
thread, that looks like some magic timing based hack which seems risky
(or completely unneeded which would be better).

> > > When I originally submitted this patch, there was some discussion as to whether
> > > dspi->dma_rx should be changed to return an error rather than being null.
> > 
> > > However, I prefer it the way it is and don't see a compelling reason to change
> > > it.

> > I don't know what the above comment means, sorry (and don't recall
> > having seen any earlier versions of this).

> FWIW, you can find the previous conversation at
> https://patchwork.kernel.org/patch/9437901/

What Sekhar is saying there is right, it is better style to use an error
pointer rather than NULL as someone could potentially come up with a way
to make NULL a valid pointer in the API.  But it doesn't matter greatly.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RESEND] spi: davinci: Allow device tree devices to use DMA

[Kevin Hilman]

David Lechner <david@lechnology.com> writes:

> This allows SPI devices specified in a device tree to use DMA when the
> master controller.

Enabling DMA for spi-davinci isn't quite ready yet since this driver is
blindly using dma_map_single() on addresses passed in.  MTD seems to use
vmalloc'd buffers, which cannot be passed direclty to dma_map_single().

I thinks this driver needs an update to use spi_map_buf() to be able to
handle vmalloc'd buffers before always enabling DMA.

Kevin

Re: [RESEND] spi: davinci: Allow device tree devices to use DMA

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 319 bytes --]

On Thu, Jan 12, 2017 at 01:34:10PM -0800, Kevin Hilman wrote:

> I thinks this driver needs an update to use spi_map_buf() to be able to
> handle vmalloc'd buffers before always enabling DMA.

Right.  As I said elsewhere in the thread the driver looks like it needs
some very serious TLC based on a quick scan through.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]