similar to: [PATCH 0/5] iommu: Implement iommu_put_resv_regions_simple()

From: Thierry Reding <treding at nvidia.com> Most IOMMU drivers only need to free the memory allocated for each reserved region. Instead of open-coding the loop to do this in each driver, extract the code into a common function that can be used by all these drivers. Changes in v2: - change subject prefix to "iommu: virtio: " for virtio-iommu.c driver Thierry Thierry Reding (5):

From: Thierry Reding <treding at nvidia.com> Use the new standard function instead of open-coding it. Cc: Will Deacon <will at kernel.org> Cc: Robin Murphy <robin.murphy at arm.com> Signed-off-by: Thierry Reding <treding at nvidia.com> --- drivers/iommu/arm-smmu-v3.c | 11 +---------- drivers/iommu/arm-smmu.c | 11 +---------- 2 files changed, 2 insertions(+), 20

On Thu, Aug 29, 2019 at 01:17:48PM +0200, Thierry Reding wrote: > From: Thierry Reding <treding at nvidia.com> > > Implement a generic function for removing reserved regions. This can be > used by drivers that don't do anything fancy with these regions other > than allocating memory for them. > > Signed-off-by: Thierry Reding <treding at nvidia.com> > ---

From: Thierry Reding <treding at nvidia.com> Use the new standard function instead of open-coding it. Cc: Jean-Philippe Brucker <jean-philippe at linaro.org> Cc: virtualization at lists.linux-foundation.org Signed-off-by: Thierry Reding <treding at nvidia.com> --- Changes in v2: - change subject prefix to 'iommu: virt:' to 'iommu: virtio:'

From: Thierry Reding <treding at nvidia.com> Most IOMMU drivers only need to free the memory allocated for each reserved region. Instead of open-coding the loop to do this in each driver, extract the code into a common function that can be used by all these drivers. Changes in v3: - add Reviewed-by from Jean-Philippe Brucker on virtio patch - add Acked-by from Will Deacon on ARM SMMU patch

On 26.04.2018 15:41, Thierry Reding wrote: > On Wed, Apr 25, 2018 at 09:28:49AM -0600, Jordan Crouse wrote: >> On Wed, Apr 25, 2018 at 12:10:47PM +0200, Thierry Reding wrote: >>> From: Thierry Reding <treding at nvidia.com> >>> >>> Depending on the kernel configuration, early ARM architecture setup code >>> may have attached the GPU to a DMA/IOMMU

On Wed, Apr 25, 2018 at 09:28:49AM -0600, Jordan Crouse wrote: > On Wed, Apr 25, 2018 at 12:10:47PM +0200, Thierry Reding wrote: > > From: Thierry Reding <treding at nvidia.com> > > > > 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

On Wed, Apr 25, 2018 at 12:10:47PM +0200, Thierry Reding wrote: > From: Thierry Reding <treding at nvidia.com> > > 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

From: Thierry Reding <treding at nvidia.com> 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 GPU's MMU page tables indicates the memory path to take: via the SMMU or directly to the

From: Thierry Reding <treding at nvidia.com> An unfortunate interaction between the 32-bit ARM DMA/IOMMU mapping code and Tegra SMMU driver changes to support IOMMU groups introduced a boot- time regression on Tegra124. This was caught very late because none of the standard configurations that are tested on Tegra enable the ARM DMA/ IOMMU mapping code since it is not needed. The reason for

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 <treding at nvidia.com> > > > > 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

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 <treding at nvidia.com> > > > > > > > > Depending on the kernel configuration, early ARM

From: Thierry Reding <treding at nvidia.com> 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 GPU's MMU page tables indicates the memory path to take: via the SMMU or directly to the

From: Thierry Reding <treding at nvidia.com> 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 GPU's MMU page tables indicates the memory path to take: via the SMMU or directly to the

From: Thierry Reding <treding at nvidia.com> An unfortunate interaction between the 32-bit ARM DMA/IOMMU mapping code and Tegra SMMU driver changes to support IOMMU groups introduced a boot- time regression on Tegra124. This was caught very late because none of the standard configurations that are tested on Tegra enable the ARM DMA/ IOMMU mapping code since it is not needed. The reason for

On 30/05/18 09:03, Thierry Reding wrote: > From: Thierry Reding <treding at nvidia.com> > > 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 GPU's MMU page

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 <treding at nvidia.com> >>> >>> Depending on the kernel configuration, early ARM architecture setup code >>> may have attached the GPU to a DMA/IOMMU mapping that

From: Thierry Reding <treding at nvidia.com> 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 GPU's MMU page tables indicates the memory path to take: via the SMMU or directly to the

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 <treding at nvidia.com> >>> >>> If the GPU is already attached to an IOMMU, don't detach it and setup an >>> explicit IOMMU domain. Since

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 <treding at nvidia.com> > > > > 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