| Message ID | 20200310073313.21277-1-michael@walle.cc (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 22ee9de1ecfb4459a9b3a959994f6ccb4a3827a4 |
| Headers | show |
| Series | spi: spi-fsl-dspi: fix DMA mapping | expand |
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
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);
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(-)