Re: [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT

On 29/11/2023 12:48 am, Jason Gunthorpe wrote: The arm-smmu driver can COMPILE_TEST on x86, so expand this to also enable the IORT code so it can be COMPILE_TEST'd too. Signed-off-by: Jason Gunthorpe --- drivers/acpi/Kconfig| 2 -- drivers/acpi/Makefile | 2 +-

Re: [Nouveau] [PATCH 06/10] iommu: Replace iommu_device_lock with iommu_probe_device_lock

On 29/11/2023 12:48 am, Jason Gunthorpe wrote: The iommu_device_lock protects the iommu_device_list which is only read by iommu_ops_from_fwnode(). This is now always called under the iommu_probe_device_lock, so we don't need to double lock the linked list. Use the iommu_probe_device_lock on the

Re: [Nouveau] [PATCH v2 04/10] iommu/dma: Use the gfp parameter in __iommu_dma_alloc_noncontiguous()

On 2023-01-18 18:00, Jason Gunthorpe wrote: Change the sg_alloc_table_from_pages() allocation that was hardwired to GFP_KERNEL to use the gfp parameter like the other allocations in this function. Auditing says this is never called from an atomic context, so it is safe as is, but reads wrong.

Re: [Nouveau] [PATCH 1/8] iommu: Add a gfp parameter to iommu_map()

On 2023-01-06 16:42, Jason Gunthorpe wrote: The internal mechanisms support this, but instead of exposting the gfp to the caller it wrappers it into iommu_map() and iommu_map_atomic() Fix this instead of adding more variants for GFP_KERNEL_ACCOUNT. FWIW, since we *do* have two variants

[Nouveau] [PATCH] drm/nouveau/tegra: Stop using iommu_present()

Even if some IOMMU has registered itself on the platform "bus", that doesn't necessarily mean it provides translation for the device we care about. Replace iommu_present() with a more appropriate check. Signed-off-by: Robin Murphy --- drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c

Re: [Nouveau] [PATCH 1/1] drm/nouveau/device: Get right pgsize_bitmap of iommu_domain

e than a year after that commit ;) As an improvement rather than a fix, though, Reviewed-by: Robin Murphy Signed-off-by: Lu Baolu --- drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/

Re: [Nouveau] [PATCH v5 16/16] of: Add plumbing for restricted DMA pool

On 2021-04-22 09:15, Claire Chang wrote: If a device is not behind an IOMMU, we look up the device node and set up the restricted DMA when the restricted-dma-pool is presented. Signed-off-by: Claire Chang --- drivers/of/address.c| 25 + drivers/of/device.c |

Re: [Nouveau] [PATCH v5 14/16] dma-direct: Allocate memory from restricted DMA pool if available

On 2021-04-22 09:15, Claire Chang wrote: The restricted DMA pool is preferred if available. The restricted DMA pools provide a basic level of protection against the DMA overwriting buffer contents at unexpected times. However, to protect against general data leakage and system memory

Re: [Nouveau] [PATCH v5 08/16] swiotlb: Update is_swiotlb_active to add a struct device argument

On 2021-04-22 09:15, Claire Chang wrote: Update is_swiotlb_active to add a struct device argument. This will be useful later to allow for restricted DMA pool. Signed-off-by: Claire Chang --- drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +- drivers/gpu/drm/nouveau/nouveau_ttm.c|

Re: [Nouveau] [PATCH RFC v1 2/6] swiotlb: convert variables to arrays

On 2021-02-04 07:29, Christoph Hellwig wrote: On Wed, Feb 03, 2021 at 03:37:05PM -0800, Dongli Zhang wrote: This patch converts several swiotlb related variables to arrays, in order to maintain stat/status for different swiotlb buffers. Here are variables involved: - io_tlb_start and

Re: [Nouveau] [PATCH 08/18] dma-mapping: add a new dma_alloc_noncoherent API

On 2020-09-15 16:51, Christoph Hellwig wrote: [...] +These APIs allow to allocate pages in the kernel direct mapping that are +guaranteed to be DMA addressable. This means that unlike dma_alloc_coherent, +virt_to_page can be called on the resulting address, and the resulting Nit: if we

Re: [Nouveau] [trivial PATCH] treewide: Convert switch/case fallthrough; to break;

On 2020-09-09 21:06, Joe Perches wrote: fallthrough to a separate case/default label break; isn't very readable. Convert pseudo-keyword fallthrough; statements to a simple break; when the next label is case or default and the only statement in the next label block is break; Found using: $

Re: [Nouveau] [PATCH 05/28] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT

On 2020-08-19 13:49, Tomasz Figa wrote: On Wed, Aug 19, 2020 at 1:51 PM Robin Murphy wrote: Hi Tomasz, On 2020-08-19 12:16, Tomasz Figa wrote: Hi Christoph, On Wed, Aug 19, 2020 at 8:56 AM Christoph Hellwig wrote: The V4L2-FLAG-MEMORY-NON-CONSISTENT flag is entirely unused, Could you

Re: [Nouveau] [PATCH 05/28] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT

Hi Tomasz, On 2020-08-19 12:16, Tomasz Figa wrote: Hi Christoph, On Wed, Aug 19, 2020 at 8:56 AM Christoph Hellwig wrote: The V4L2-FLAG-MEMORY-NON-CONSISTENT flag is entirely unused, Could you explain what makes you think it's unused? It's a feature of the UAPI generally supported by the

Re: [Nouveau] [PATCH 08/11] drm/nouveau: tegra: Skip IOMMU initialization if already attached

On 16/09/2019 16:57, Thierry Reding wrote: On Mon, Sep 16, 2019 at 04:29:18PM +0100, Robin Murphy wrote: Hi Thierry, On 16/09/2019 16:04, Thierry Reding wrote: From: Thierry Reding If the GPU is already attached to an IOMMU, don't detach it and setup an explicit IOMMU domain. Since Nouveau

Re: [Nouveau] [PATCH 08/11] drm/nouveau: tegra: Skip IOMMU initialization if already attached

Hi Thierry, On 16/09/2019 16:04, Thierry Reding wrote: From: Thierry Reding If the GPU is already attached to an IOMMU, don't detach it and setup an explicit IOMMU domain. Since Nouveau can now properly handle the case of the DMA API being backed by an IOMMU, just continue using the DMA API.

Re: DMA-API: cacheline tracking ENOMEM, dma-debug disabled due to nouveau ?

On 15/08/2019 14:35, Christoph Hellwig wrote: On Wed, Aug 14, 2019 at 07:49:27PM +0200, Daniel Vetter wrote: On Wed, Aug 14, 2019 at 04:50:33PM +0200, Corentin Labbe wrote: Hello Since lot of release (at least since 4.19), I hit the following error message: DMA-API: cacheline tracking ENOMEM,

Re: [Nouveau] [RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU

On 15/08/18 20:56, Dmitry Osipenko wrote: On Friday, 3 August 2018 18:43:41 MSK Robin Murphy wrote: On 02/08/18 19:24, Dmitry Osipenko wrote: On Friday, 27 July 2018 20:16:53 MSK Dmitry Osipenko wrote: On Friday, 27 July 2018 20:03:26 MSK Jordan Crouse wrote: On Fri, Jul 27, 2018 at 05:02

Re: [Nouveau] [RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU

On 02/08/18 19:24, Dmitry Osipenko wrote: On Friday, 27 July 2018 20:16:53 MSK Dmitry Osipenko wrote: On Friday, 27 July 2018 20:03:26 MSK Jordan Crouse wrote: On Fri, Jul 27, 2018 at 05:02:37PM +0100, Robin Murphy wrote: On 27/07/18 15:10, Dmitry Osipenko wrote: On Friday, 27 July 2018 12

Re: [Nouveau] [RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU

On 27/07/18 15:10, Dmitry Osipenko wrote: On Friday, 27 July 2018 12:03:28 MSK Will Deacon wrote: On Fri, Jul 27, 2018 at 10:25:13AM +0200, Joerg Roedel wrote: On Fri, Jul 27, 2018 at 02:16:18AM +0300, Dmitry Osipenko wrote: The proposed solution adds a new option to the base device driver

Re: [Nouveau] [PATCH v4 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

gain anyway once the refcounting gets sorted out and the mapping releases itself properly, so: Reviewed-by: Robin Murphy + + arm_iommu_detach_device(dev); + arm_iommu_release_mapping(mapping); + } +#endif + if (!tdev->func->iommu_bit)

Re: [Nouveau] [PATCH v4 1/2] ARM: dma-mapping: Set proper DMA ops in arm_iommu_detach_device()

changing around it, but it's clearly not enough of a problem to consider stable backports :) Reviewed-by: Robin Murphy Signed-off-by: Thierry Reding --- Changes in v4: - new patch to fix existing arm_iommu_detach_device() to do what we need arch/arm/mm/dma-mapping.c | 12 ++-- 1

Re: [Nouveau] [PATCH v3 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

On 30/05/18 14:41, Thierry Reding wrote: On Wed, May 30, 2018 at 02:30:51PM +0100, Robin Murphy wrote: On 30/05/18 14:00, Thierry Reding wrote: On Wed, May 30, 2018 at 11:30:25AM +0100, Robin Murphy wrote: On 30/05/18 09:03, Thierry Reding wrote: From: Thierry Reding Depending

Re: [Nouveau] [PATCH v3 1/2] ARM: dma-mapping: Implement arm_dma_iommu_detach_device()

On 30/05/18 14:12, Thierry Reding wrote: On Wed, May 30, 2018 at 02:54:46PM +0200, Thierry Reding wrote: On Wed, May 30, 2018 at 10:59:30AM +0100, Robin Murphy wrote: On 30/05/18 09:03, Thierry Reding wrote: From: Thierry Reding Implement this function to enable drivers from detaching from

Re: [Nouveau] [PATCH v3 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

On 30/05/18 14:00, Thierry Reding wrote: On Wed, May 30, 2018 at 11:30:25AM +0100, Robin Murphy wrote: On 30/05/18 09:03, 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

Re: [Nouveau] [PATCH v3 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

On 30/05/18 09:03, 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. Tegra requires special handling for IOMMU backed

Re: [Nouveau] [PATCH v3 1/2] ARM: dma-mapping: Implement arm_dma_iommu_detach_device()

On 30/05/18 09:03, Thierry Reding wrote: 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

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

On 30/04/18 13:12, Thierry Reding wrote: On Mon, Apr 30, 2018 at 12:41:52PM +0100, Robin Murphy wrote: On 30/04/18 12:02, Thierry Reding wrote: On Thu, Apr 26, 2018 at 02:11:36PM +0200, Thierry Reding wrote: On Wed, Apr 25, 2018 at 08:19:34AM -0700, Christoph Hellwig wrote: On Wed, Apr 25

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

On 30/04/18 12:02, Thierry Reding wrote: On Thu, Apr 26, 2018 at 02:11:36PM +0200, Thierry Reding wrote: On Wed, Apr 25, 2018 at 08:19:34AM -0700, Christoph Hellwig wrote: On Wed, Apr 25, 2018 at 12:10:48PM +0200, Thierry Reding wrote: From: Thierry Reding The

Re: [Nouveau] [PATCH v2] Revert "drm/nouveau/device/pci: set as non-CPU-coherent on ARM64"

On 06/06/16 08:11, Alexandre Courbot wrote: From: Robin Murphy <robin.mur...@arm.com> This reverts commit 1733a2ad36741b1812cf8b3f3037c28d0af53f50. There is apparently something amiss with the way the TTM code handles DMA buffers, which the above commit was attempting to work around for

[Nouveau] [PATCH] Revert "drm/nouveau/device/pci: set as non-CPU-coherent on ARM64"

precedence, so revert this change until the real underlying problem can be fixed. Signed-off-by: Robin Murphy <robin.mur...@arm.com> --- Alex, Ben, Dave, I know Alex was looking into this, but since we're nearly at -rc6 already it looks like the only thing to do for 4.6 is pick the lesser