Message ID | 1423742848-15369-3-git-send-email-a.bouin@gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Thu, Feb 12, 2015 at 01:07:27PM +0100, Aurelien BOUIN wrote: > This patch enable to give a parameter to device tree to set the number of bits per word the DMA uses in transfer > In device tree you can specify fsl,spi-dma-bits-per-word = <16>; in the ecspi section Why would this be a DT property? It seems like something the driver ought to be able to figure out automatically if it matters.
At the moment there is no possibility to change the dma bits per word use ... It is an easy way to be able to do so. Feel free to propose something better 2015-02-21 15:35 GMT+01:00 Mark Brown <broonie@kernel.org>: > On Thu, Feb 12, 2015 at 01:07:27PM +0100, Aurelien BOUIN wrote: >> This patch enable to give a parameter to device tree to set the number of bits per word the DMA uses in transfer >> In device tree you can specify fsl,spi-dma-bits-per-word = <16>; in the ecspi section > > Why would this be a DT property? It seems like something the driver > ought to be able to figure out automatically if it matters. -- 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, Feb 23, 2015 at 09:44:50AM +0100, aurélien bouin wrote: > At the moment there is no possibility to change the dma bits per word use ... > It is an easy way to be able to do so. > Feel free to propose something better Once more don't top post. To repeat what I said: | Why would this be a DT property? It seems like something the driver | ought to be able to figure out automatically if it matters. The above doesn't address my question.
2015-02-23 15:46 GMT+01:00 Mark Brown <broonie@kernel.org>: > On Mon, Feb 23, 2015 at 09:44:50AM +0100, aurélien bouin wrote: >> At the moment there is no possibility to change the dma bits per word use ... >> It is an easy way to be able to do so. >> Feel free to propose something better > > Once more don't top post. To repeat what I said: > > | Why would this be a DT property? It seems like something the driver > | ought to be able to figure out automatically if it matters. > > The above doesn't address my question. Currently the driver does not figure it out automatically, it is a fix 8bits per word DMA use. -- 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, Feb 23, 2015 at 04:25:51PM +0100, aurélien bouin wrote: > 2015-02-23 15:46 GMT+01:00 Mark Brown <broonie@kernel.org>: > > On Mon, Feb 23, 2015 at 09:44:50AM +0100, aurélien bouin wrote: > > Once more don't top post. To repeat what I said: > > | Why would this be a DT property? It seems like something the driver > > | ought to be able to figure out automatically if it matters. > > The above doesn't address my question. > Currently the driver does not figure it out automatically, it is a fix > 8bits per word DMA use. You're still not explaining why it's not a better fix for the driver to figure this out for itself, or why it's not possible for it to do that even if it would be better.
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c index f8400b2..9690d57 100644 --- a/drivers/spi/spi-imx.c +++ b/drivers/spi/spi-imx.c @@ -110,6 +110,7 @@ struct spi_imx_data { u32 rxt_wml; struct completion dma_rx_completion; struct completion dma_tx_completion; + unsigned int dma_bits_per_word; const struct spi_imx_devtype_data *devtype_data; int chipselect[0]; @@ -825,6 +826,7 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx, { struct dma_slave_config slave_config = {}; int ret; + enum dma_slave_buswidth dsb_default = DMA_SLAVE_BUSWIDTH_1_BYTE; /* use pio mode for i.mx6dl chip TKT238285 */ if (of_machine_is_compatible("fsl,imx6dl")) @@ -837,10 +839,20 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx, ret = -EINVAL; goto err; } - + switch (spi_imx->dma_bits_per_word) { + case 32: + dsb_default = DMA_SLAVE_BUSWIDTH_4_BYTES; + break; + case 16: + dsb_default = DMA_SLAVE_BUSWIDTH_2_BYTES; + break; + default: + dsb_default = DMA_SLAVE_BUSWIDTH_1_BYTE; + break; + } slave_config.direction = DMA_MEM_TO_DEV; slave_config.dst_addr = res->start + MXC_CSPITXDATA; - slave_config.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE; + slave_config.dst_addr_width = dsb_default; slave_config.dst_maxburst = spi_imx_get_fifosize(spi_imx) / 2; ret = dmaengine_slave_config(master->dma_tx, &slave_config); if (ret) { @@ -858,7 +870,7 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx, slave_config.direction = DMA_DEV_TO_MEM; slave_config.src_addr = res->start + MXC_CSPIRXDATA; - slave_config.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE; + slave_config.src_addr_width = dsb_default; slave_config.src_maxburst = spi_imx_get_fifosize(spi_imx) / 2; ret = dmaengine_slave_config(master->dma_rx, &slave_config); if (ret) { @@ -1083,7 +1095,7 @@ static int spi_imx_probe(struct platform_device *pdev) struct spi_master *master; struct spi_imx_data *spi_imx; struct resource *res; - int i, ret, num_cs; + int i, ret, num_cs, dma_bits_per_word = 8; if (!np && !mxc_platform_info) { dev_err(&pdev->dev, "can't get the platform data\n"); @@ -1138,6 +1150,11 @@ static int spi_imx_probe(struct platform_device *pdev) spi_imx->bitbang.master->prepare_message = spi_imx_prepare_message; spi_imx->bitbang.master->unprepare_message = spi_imx_unprepare_message; spi_imx->bitbang.master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH; + if (of_property_read_u32(np, "fsl,spi-dma-bits-per-word", + &dma_bits_per_word)) + spi_imx->dma_bits_per_word = dma_bits_per_word; + else + spi_imx->dma_bits_per_word = 8; init_completion(&spi_imx->xfer_done);
This patch enable to give a parameter to device tree to set the number of bits per word the DMA uses in transfer In device tree you can specify fsl,spi-dma-bits-per-word = <16>; in the ecspi section Signed-off-by: Aurelien BOUIN <a.bouin@gmail.com>