Use the correct device to request the DMA mapping. Otherwise the IOMMU doesn't get the mapping and it will generate a page fault.
The error messages look like: [ 3.008452] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xf9800000, fsynr=0x3f0022, cbfrsynra=0x828, cb=8 [ 3.020123] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xf9800000, fsynr=0x3f0022, cbfrsynra=0x828, cb=8
This was tested on a custom board with a LS1028A SoC.
Signed-off-by: Michael Walle michael@walle.cc --- drivers/spi/spi-fsl-dspi.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c index cf8a141bbaf2..ad63804ef690 100644 --- a/drivers/spi/spi-fsl-dspi.c +++ b/drivers/spi/spi-fsl-dspi.c @@ -510,14 +510,16 @@ static int dspi_request_dma(struct fsl_dspi *dspi, phys_addr_t phy_addr) goto err_tx_channel; }
- dma->tx_dma_buf = dma_alloc_coherent(dev, dspi->devtype_data->dma_bufsize, + dma->tx_dma_buf = dma_alloc_coherent(dma->chan_tx->device->dev, + dspi->devtype_data->dma_bufsize, &dma->tx_dma_phys, GFP_KERNEL); if (!dma->tx_dma_buf) { ret = -ENOMEM; goto err_tx_dma_buf; }
- dma->rx_dma_buf = dma_alloc_coherent(dev, dspi->devtype_data->dma_bufsize, + dma->rx_dma_buf = dma_alloc_coherent(dma->chan_rx->device->dev, + dspi->devtype_data->dma_bufsize, &dma->rx_dma_phys, GFP_KERNEL); if (!dma->rx_dma_buf) { ret = -ENOMEM; @@ -554,10 +556,12 @@ static int dspi_request_dma(struct fsl_dspi *dspi, phys_addr_t phy_addr) return 0;
err_slave_config: - dma_free_coherent(dev, dspi->devtype_data->dma_bufsize, + dma_free_coherent(dma->chan_rx->device->dev, + dspi->devtype_data->dma_bufsize, dma->rx_dma_buf, dma->rx_dma_phys); err_rx_dma_buf: - dma_free_coherent(dev, dspi->devtype_data->dma_bufsize, + dma_free_coherent(dma->chan_tx->device->dev, + dspi->devtype_data->dma_bufsize, dma->tx_dma_buf, dma->tx_dma_phys); err_tx_dma_buf: dma_release_channel(dma->chan_tx); @@ -573,20 +577,19 @@ static int dspi_request_dma(struct fsl_dspi *dspi, phys_addr_t phy_addr) static void dspi_release_dma(struct fsl_dspi *dspi) { struct fsl_dspi_dma *dma = dspi->dma; - struct device *dev = &dspi->pdev->dev;
if (!dma) return;
if (dma->chan_tx) { - dma_unmap_single(dev, dma->tx_dma_phys, + dma_unmap_single(dma->chan_tx->device->dev, dma->tx_dma_phys, dspi->devtype_data->dma_bufsize, DMA_TO_DEVICE); dma_release_channel(dma->chan_tx); }
if (dma->chan_rx) { - dma_unmap_single(dev, dma->rx_dma_phys, + dma_unmap_single(dma->chan_rx->device->dev, dma->rx_dma_phys, dspi->devtype_data->dma_bufsize, DMA_FROM_DEVICE); dma_release_channel(dma->chan_rx);
Am 2020-03-10 08:33, schrieb Michael Walle:
Use the correct device to request the DMA mapping. Otherwise the IOMMU doesn't get the mapping and it will generate a page fault.
The error messages look like: [ 3.008452] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xf9800000, fsynr=0x3f0022, cbfrsynra=0x828, cb=8 [ 3.020123] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xf9800000, fsynr=0x3f0022, cbfrsynra=0x828, cb=8
This was tested on a custom board with a LS1028A SoC.
Oh fu.. please disregard this patch. DMA mapping still isn't working. Somehow I missed that the transfer mode was turned back to its default XSPI mode.
-michael
Am 2020-03-10 08:40, schrieb Michael Walle:
Am 2020-03-10 08:33, schrieb Michael Walle:
Use the correct device to request the DMA mapping. Otherwise the IOMMU doesn't get the mapping and it will generate a page fault.
The error messages look like: [ 3.008452] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xf9800000, fsynr=0x3f0022, cbfrsynra=0x828, cb=8 [ 3.020123] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xf9800000, fsynr=0x3f0022, cbfrsynra=0x828, cb=8
This was tested on a custom board with a LS1028A SoC.
Oh fu.. please disregard this patch. DMA mapping still isn't working. Somehow I missed that the transfer mode was turned back to its default XSPI mode.
Damn. I need more coffee.. this patch IS working. Only the first probe fails due to EPROBE_DEFER.
[ 2.539706] fsl-dspi 2120000.spi: rx dma channel not available (-517) [ 2.546200] fsl-dspi 2120000.spi: can't get dma channels [ 3.622774] spi-nor spi1.0: w25q128fw (16384 Kbytes)
-michael
On Tue, 10 Mar 2020 at 10:12, Michael Walle michael@walle.cc wrote:
Am 2020-03-10 08:40, schrieb Michael Walle:
Am 2020-03-10 08:33, schrieb Michael Walle:
Use the correct device to request the DMA mapping. Otherwise the IOMMU doesn't get the mapping and it will generate a page fault.
The error messages look like: [ 3.008452] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xf9800000, fsynr=0x3f0022, cbfrsynra=0x828, cb=8 [ 3.020123] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xf9800000, fsynr=0x3f0022, cbfrsynra=0x828, cb=8
This was tested on a custom board with a LS1028A SoC.
Oh fu.. please disregard this patch. DMA mapping still isn't working. Somehow I missed that the transfer mode was turned back to its default XSPI mode.
Damn. I need more coffee.. this patch IS working. Only the first probe fails due to EPROBE_DEFER.
[ 2.539706] fsl-dspi 2120000.spi: rx dma channel not available (-517) [ 2.546200] fsl-dspi 2120000.spi: can't get dma channels [ 3.622774] spi-nor spi1.0: w25q128fw (16384 Kbytes)
-michael
I'm testing LS1028A with IOMMU_DEFAULT_PASSTHROUGH=y and I didn't have time to change my setup now. I've also sent a v3 to my patch series which is going to conflict with this one, sorry. I would have picked your patch up with my series but I didn't have the right environment to test it.
Thanks, -Vladimir
Am 2020-03-10 14:02, schrieb Vladimir Oltean:
On Tue, 10 Mar 2020 at 10:12, Michael Walle michael@walle.cc wrote:
Am 2020-03-10 08:40, schrieb Michael Walle:
Am 2020-03-10 08:33, schrieb Michael Walle:
Use the correct device to request the DMA mapping. Otherwise the IOMMU doesn't get the mapping and it will generate a page fault.
The error messages look like: [ 3.008452] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xf9800000, fsynr=0x3f0022, cbfrsynra=0x828, cb=8 [ 3.020123] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xf9800000, fsynr=0x3f0022, cbfrsynra=0x828, cb=8
This was tested on a custom board with a LS1028A SoC.
Oh fu.. please disregard this patch. DMA mapping still isn't working. Somehow I missed that the transfer mode was turned back to its default XSPI mode.
Damn. I need more coffee.. this patch IS working. Only the first probe fails due to EPROBE_DEFER.
[ 2.539706] fsl-dspi 2120000.spi: rx dma channel not available (-517) [ 2.546200] fsl-dspi 2120000.spi: can't get dma channels [ 3.622774] spi-nor spi1.0: w25q128fw (16384 Kbytes)
-michael
I'm testing LS1028A with IOMMU_DEFAULT_PASSTHROUGH=y and I didn't have time to change my setup now. I've also sent a v3 to my patch series which is going to conflict with this one, sorry.
No worries, its easy enough to rebase.
I would have picked your patch up with my series but I didn't have the right environment to test it.
I'll resend a v2 once your series is working.
-michael
On Tue, Mar 10, 2020 at 03:12:45PM +0100, Michael Walle wrote:
Am 2020-03-10 14:02, schrieb Vladimir Oltean:
I'm testing LS1028A with IOMMU_DEFAULT_PASSTHROUGH=y and I didn't have time to change my setup now. I've also sent a v3 to my patch series which is going to conflict with this one, sorry.
No worries, its easy enough to rebase.
I would have picked your patch up with my series but I didn't have the right environment to test it.
I'll resend a v2 once your series is working.
Since it looks like your series might need another spin anyway I'm thinking it's sensible to apply this now and you rebase instead? Cuts down on the number of pending patches if nothing else (unless the testing stuff gets sorted out of course).
On Tue, 10 Mar 2020 at 19:14, Mark Brown broonie@kernel.org wrote:
On Tue, Mar 10, 2020 at 03:12:45PM +0100, Michael Walle wrote:
Am 2020-03-10 14:02, schrieb Vladimir Oltean:
I'm testing LS1028A with IOMMU_DEFAULT_PASSTHROUGH=y and I didn't have time to change my setup now. I've also sent a v3 to my patch series which is going to conflict with this one, sorry.
No worries, its easy enough to rebase.
I would have picked your patch up with my series but I didn't have the right environment to test it.
I'll resend a v2 once your series is working.
Since it looks like your series might need another spin anyway I'm thinking it's sensible to apply this now and you rebase instead? Cuts down on the number of pending patches if nothing else (unless the testing stuff gets sorted out of course).
Sure, go ahead.
Thanks, -Vladimir
The patch
spi: spi-fsl-dspi: fix DMA mapping
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
From 22ee9de1ecfb4459a9b3a959994f6ccb4a3827a4 Mon Sep 17 00:00:00 2001
From: Michael Walle michael@walle.cc Date: Tue, 10 Mar 2020 08:33:13 +0100 Subject: [PATCH] spi: spi-fsl-dspi: fix DMA mapping
Use the correct device to request the DMA mapping. Otherwise the IOMMU doesn't get the mapping and it will generate a page fault.
The error messages look like: [ 3.008452] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xf9800000, fsynr=0x3f0022, cbfrsynra=0x828, cb=8 [ 3.020123] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xf9800000, fsynr=0x3f0022, cbfrsynra=0x828, cb=8
This was tested on a custom board with a LS1028A SoC.
Signed-off-by: Michael Walle michael@walle.cc Link: https://lore.kernel.org/r/20200310073313.21277-1-michael@walle.cc Signed-off-by: Mark Brown broonie@kernel.org --- drivers/spi/spi-fsl-dspi.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c index 0683a3fbd48c..50e3382f0c50 100644 --- a/drivers/spi/spi-fsl-dspi.c +++ b/drivers/spi/spi-fsl-dspi.c @@ -497,14 +497,16 @@ static int dspi_request_dma(struct fsl_dspi *dspi, phys_addr_t phy_addr) goto err_tx_channel; }
- dma->tx_dma_buf = dma_alloc_coherent(dev, dspi->devtype_data->dma_bufsize, + dma->tx_dma_buf = dma_alloc_coherent(dma->chan_tx->device->dev, + dspi->devtype_data->dma_bufsize, &dma->tx_dma_phys, GFP_KERNEL); if (!dma->tx_dma_buf) { ret = -ENOMEM; goto err_tx_dma_buf; }
- dma->rx_dma_buf = dma_alloc_coherent(dev, dspi->devtype_data->dma_bufsize, + dma->rx_dma_buf = dma_alloc_coherent(dma->chan_rx->device->dev, + dspi->devtype_data->dma_bufsize, &dma->rx_dma_phys, GFP_KERNEL); if (!dma->rx_dma_buf) { ret = -ENOMEM; @@ -541,10 +543,12 @@ static int dspi_request_dma(struct fsl_dspi *dspi, phys_addr_t phy_addr) return 0;
err_slave_config: - dma_free_coherent(dev, dspi->devtype_data->dma_bufsize, + dma_free_coherent(dma->chan_rx->device->dev, + dspi->devtype_data->dma_bufsize, dma->rx_dma_buf, dma->rx_dma_phys); err_rx_dma_buf: - dma_free_coherent(dev, dspi->devtype_data->dma_bufsize, + dma_free_coherent(dma->chan_tx->device->dev, + dspi->devtype_data->dma_bufsize, dma->tx_dma_buf, dma->tx_dma_phys); err_tx_dma_buf: dma_release_channel(dma->chan_tx); @@ -560,20 +564,19 @@ static int dspi_request_dma(struct fsl_dspi *dspi, phys_addr_t phy_addr) static void dspi_release_dma(struct fsl_dspi *dspi) { struct fsl_dspi_dma *dma = dspi->dma; - struct device *dev = &dspi->pdev->dev;
if (!dma) return;
if (dma->chan_tx) { - dma_unmap_single(dev, dma->tx_dma_phys, + dma_unmap_single(dma->chan_tx->device->dev, dma->tx_dma_phys, dspi->devtype_data->dma_bufsize, DMA_TO_DEVICE); dma_release_channel(dma->chan_tx); }
if (dma->chan_rx) { - dma_unmap_single(dev, dma->rx_dma_phys, + dma_unmap_single(dma->chan_rx->device->dev, dma->rx_dma_phys, dspi->devtype_data->dma_bufsize, DMA_FROM_DEVICE); dma_release_channel(dma->chan_rx);
dri-devel@lists.freedesktop.org