| Message ID | 1483673177-31516-1-git-send-email-david@lechnology.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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).
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/ -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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;
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(+)