Re: [PATCH 5/6 v2] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus

Hi Nipun, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17-rc2 next-20180424] [cannot apply to iommu/next glikely/devicetree/next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 11:35:13PM +0200, Daniel Vetter wrote: > On arm that doesn't work. The iommu api seems like a good fit, except > the dma-api tends to get in the way a bit (drm/msm apparently has > similar problems like tegra), and if you need contiguous memory > dma_alloc_coherent is the

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 08:33:12AM -0700, Christoph Hellwig wrote: > On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote: > > - dma api hides the cache flushing requirements from us. GPUs love > > non-snooped access, and worse give userspace control over that. We want > > a strict

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 5:33 PM, Christoph Hellwig wrote: > On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote: >> > Coordinating the backport of a trivial helper in the arm tree is not >> > the end of the world. Really, this cowboy attitude is a good reason >> >

Re: [PATCH v4 14/22] iommu: handle page response timeout

On Mon, 23 Apr 2018 16:36:23 +0100 Jean-Philippe Brucker wrote: > On Mon, Apr 16, 2018 at 10:49:03PM +0100, Jacob Pan wrote: > > When IO page faults are reported outside IOMMU subsystem, the page > > request handler may fail for various reasons. E.g. a guest

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote: > > Coordinating the backport of a trivial helper in the arm tree is not > > the end of the world. Really, this cowboy attitude is a good reason > > why graphics folks have such a bad rep. You keep poking into random > > kernel

Re: [PATCH v2 1/5] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

On Wed, Apr 25, 2018 at 12:10:47PM +0200, Thierry Reding wrote: > From: Thierry Reding > > Depending on the kernel configuration, early ARM architecture setup code > may have attached the GPU to a DMA/IOMMU mapping that transparently uses > the IOMMU to back the DMA API.

Re: [PATCH v2 3/5] ARM: dma-mapping: Implement arch_iommu_detach_device()

> +void arch_iommu_detach_device(struct device *dev) > +{ > +#ifdef CONFIG_ARM_DMA_USE_IOMMU > + struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev); > + const struct dma_map_ops *dma_ops; > + > + if (!mapping) > + return; > + > +

Re: [PATCH v2 2/5] dma-mapping: Introduce dma_iommu_detach_device() API

On Wed, Apr 25, 2018 at 12:10:48PM +0200, Thierry Reding wrote: > From: Thierry Reding > > The dma_iommu_detach_device() API can be used by drivers to forcibly > detach a device from an IOMMU that architecture code might have attached > to. This is useful for drivers that

Re: [PATCH v2 1/5] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

The series seems to miss a cover letter. Also I really think this patch original patch shouldn't be in the proper series. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v2 5/5] ARM: Unconditionally enable ARM_DMA_USE_IOMMU

On Wed, Apr 25, 2018 at 11:25:11AM +0100, Russell King - ARM Linux wrote: > > config ARM_DMA_USE_IOMMU > > - bool > > + def_bool y > > select ARM_HAS_SG_CHAIN > > select NEED_SG_DMA_LENGTH > > This doesn't work - as has recently been discussed with hch, we can't > globally enable

Re: [PATCH 01/13] iommu-common: move to arch/sparc

From: Christoph Hellwig Date: Wed, 25 Apr 2018 07:15:27 +0200 > This code is only used by sparc, and all new iommu drivers should use the > drivers/iommu/ framework. Also remove the unused exports. > > Signed-off-by: Christoph Hellwig > Reviewed-by: Anshuman Khandual

Re: [PATCH v2 5/5] ARM: Unconditionally enable ARM_DMA_USE_IOMMU

On Wed, Apr 25, 2018 at 12:10:51PM +0200, Thierry Reding wrote: > From: Thierry Reding > > The ARM_DMA_USE_IOMMU Kconfig option has side-effects that drivers can > not opt into but have to explicitly opt out of. This can lead to subtle > bugs that are difficult to track down

[PATCH v2 4/5] drm/nouveau: tegra: Use dma_iommu_detach_device()

From: Thierry Reding Use the new dma_iommu_detach_device() function to replace the open-coded equivalent. Signed-off-by: Thierry Reding --- .../drm/nouveau/nvkm/engine/device/tegra.c| 19 ++- 1 file changed, 2 insertions(+), 17

[PATCH v2 3/5] ARM: dma-mapping: Implement arch_iommu_detach_device()

From: Thierry Reding Implement this function to enable drivers from detaching from any IOMMU domains that architecture code might have attached them to so that they can take exclusive control of the IOMMU via the IOMMU API. Signed-off-by: Thierry Reding

[PATCH v2 1/5] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

From: Thierry Reding Depending on the kernel configuration, early ARM architecture setup code may have attached the GPU to a DMA/IOMMU mapping that transparently uses the IOMMU to back the DMA API. Tegra requires special handling for IOMMU backed buffers (a special bit in the

[PATCH v2 2/5] dma-mapping: Introduce dma_iommu_detach_device() API

From: Thierry Reding The dma_iommu_detach_device() API can be used by drivers to forcibly detach a device from an IOMMU that architecture code might have attached to. This is useful for drivers that need explicit control over the IOMMU using the IOMMU API directly.

[PATCH v2 5/5] ARM: Unconditionally enable ARM_DMA_USE_IOMMU

From: Thierry Reding The ARM_DMA_USE_IOMMU Kconfig option has side-effects that drivers can not opt into but have to explicitly opt out of. This can lead to subtle bugs that are difficult to track down and not immediately obvious to be related to this Kconfig option. To

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 01:54:39AM -0700, Christoph Hellwig wrote: > [discussion about this patch, which should have been cced to the iommu > and linux-arm-kernel lists, but wasn't: > https://www.spinics.net/lists/dri-devel/msg173630.html] > > On Wed, Apr 25, 2018 at 09:41:51AM +0200, Thierry

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 01:54:39AM -0700, Christoph Hellwig wrote: > [discussion about this patch, which should have been cced to the iommu > and linux-arm-kernel lists, but wasn't: > https://www.spinics.net/lists/dri-devel/msg173630.html] > > On Wed, Apr 25, 2018 at 09:41:51AM +0200, Thierry

Re: [PATCH 3/4] ARM: dma-mapping: Implement arch_iommu_detach_device()

On Wed, Apr 25, 2018 at 11:18:14AM +0200, Thierry Reding wrote: [...] > diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c > index 8c398fedbbb6..1957938d8c9c 100644 > --- a/arch/arm/mm/dma-mapping.c > +++ b/arch/arm/mm/dma-mapping.c > @@ -2366,6 +2366,21 @@ static void

[PATCH 3/4] ARM: dma-mapping: Implement arch_iommu_detach_device()

From: Thierry Reding Implement this function to enable drivers from detaching from any IOMMU domains that architecture code might have attached them to so that they can take exclusive control of the IOMMU via the IOMMU API. Signed-off-by: Thierry Reding

[PATCH 2/4] dma-mapping: Introduce dma_iommu_detach_device() API

From: Thierry Reding The dma_iommu_detach_device() API can be used by drivers to forcibly detach a device from an IOMMU that architecture code might have attached to. This is useful for drivers that need explicit control over the IOMMU using the IOMMU API directly.

[PATCH 4/4] drm/nouveau: tegra: Use dma_iommu_detach_device()

From: Thierry Reding Use the new dma_iommu_detach_device() function to replace the open-coded equivalent. Signed-off-by: Thierry Reding --- .../drm/nouveau/nvkm/engine/device/tegra.c| 19 ++- 1 file changed, 2 insertions(+), 17

[PATCH 1/4] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

From: Thierry Reding Depending on the kernel configuration, early ARM architecture setup code may have attached the GPU to a DMA/IOMMU mapping that transparently uses the IOMMU to back the DMA API. Tegra requires special handling for IOMMU backed buffers (a special bit in the

noveau vs arm dma ops

[discussion about this patch, which should have been cced to the iommu and linux-arm-kernel lists, but wasn't: https://www.spinics.net/lists/dri-devel/msg173630.html] On Wed, Apr 25, 2018 at 09:41:51AM +0200, Thierry Reding wrote: > > API from the iommu/dma-mapping code. Drivers have no

Re: [GIT PULL] dma mapping fixes for 4.17-rc3

On Tue, 24 Apr 2018, Christoph Hellwig wrote: > On Tue, Apr 24, 2018 at 11:54:26PM -0700, David Rientjes wrote: > > Shouldn't that test for dev->coherent_dma_mask < DMA_BIT_MASK(32) be more > > accurately <=? > > No, it should really be <. The exactly 32-bit case is already covered > with

Re: [GIT PULL] dma mapping fixes for 4.17-rc3

On Wed, 25 Apr 2018, Christoph Hellwig wrote: > The following changes since commit 6d08b06e67cd117f6992c46611dfb4ce267cd71e: > > Linux 4.17-rc2 (2018-04-22 19:20:09 -0700) > > are available in the Git repository at: > > git://git.infradead.org/users/hch/dma-mapping.git

Re: [PATCH 2/5] ide: kill ide_toggle_bounce

On 4/24/18 12:16 PM, Christoph Hellwig wrote: > ide_toggle_bounce did select various strange block bounce limits, including > not bouncing at all as soon as an iommu is present in the system. Given > that the dma_map routines now handle any required bounce buffering except > for ISA DMA, and the

Re: [GIT PULL] dma mapping fixes for 4.17-rc3

On Tue, Apr 24, 2018 at 11:54:26PM -0700, David Rientjes wrote: > Shouldn't that test for dev->coherent_dma_mask < DMA_BIT_MASK(32) be more > accurately <=? No, it should really be <. The exactly 32-bit case is already covered with GFP_DMA32. Eventualy it should be < 24-bit with a separate