[PATCH] spi: spi-fsl-dspi: fix DMA mapping

[PATCH] spi: spi-fsl-dspi: fix DMA mapping

[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.

Signed-off-by: Michael Walle <michael-QKn5cuLxLXY@public.gmane.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 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);
-- 
2.20.1

Re: [PATCH] spi: spi-fsl-dspi: fix DMA mapping

[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.

-michael

Re: [PATCH] spi: spi-fsl-dspi: fix DMA mapping

[Michael Walle]

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

Re: [PATCH] spi: spi-fsl-dspi: fix DMA mapping

[Vladimir Oltean]

On Tue, 10 Mar 2020 at 10:12, Michael Walle <michael-QKn5cuLxLXY@public.gmane.org> 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

Re: [PATCH] spi: spi-fsl-dspi: fix DMA mapping

[Michael Walle]

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

Re: [PATCH] spi: spi-fsl-dspi: fix DMA mapping

[Mark Brown]

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

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).

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

Re: [PATCH] spi: spi-fsl-dspi: fix DMA mapping

[Vladimir Oltean]

On Tue, 10 Mar 2020 at 19:14, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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

Applied "spi: spi-fsl-dspi: fix DMA mapping" to the spi tree

[Mark Brown]

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-QKn5cuLxLXY@public.gmane.org>
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-QKn5cuLxLXY@public.gmane.org>
Link: https://lore.kernel.org/r/20200310073313.21277-1-michael-QKn5cuLxLXY@public.gmane.org
Signed-off-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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);
-- 
2.20.1