search for: iommu_attach_device

...that is a topic outside the scope of this fix and isn't > currently supported. An implementation will want to explicitly create > these large pages in the Nouveau driver, so detaching from a DMA/IOMMU > mapping would still be required. I wonder if it might make sense to have a hook in iommu_attach_device() to notify the arch DMA API code when moving devices between unmanaged and DMA ops domains? That seems like it might be the most low-impact way to address the overall problem long-term. > Signed-off-by: Thierry Reding <treding at nvidia.com> > --- > Changes in v3: > - clarify...

...fix and isn't >>> currently supported. An implementation will want to explicitly create >>> these large pages in the Nouveau driver, so detaching from a DMA/IOMMU >>> mapping would still be required. >> >> I wonder if it might make sense to have a hook in iommu_attach_device() to >> notify the arch DMA API code when moving devices between unmanaged and DMA >> ops domains? That seems like it might be the most low-impact way to address >> the overall problem long-term. >> >>> Signed-off-by: Thierry Reding <treding at nvidia.com> &gt...

...708] x3 : 0000000000000004 x2 : 0000000000000000 > [ 12.050710] x1 : ffff8001c915b800 x0 : 0000000000000000 > [ 12.050713] Process systemd-udevd (pid: 261, stack limit = > 0x00000000247b2b64) > [ 12.050714] Call trace: > [ 12.050717] mutex_lock+0x28/0x58 > [ 12.050721] iommu_attach_device+0xac/0xf8 > [ 12.050948] nvkm_device_tegra_new+0x260/0x510 [nouveau] > [ 12.051166] nouveau_platform_device_create+0x48/0xa8 [nouveau] > [ 12.051364] nouveau_platform_probe+0x34/0x80 [nouveau] > [ 12.051368] platform_drv_probe+0x60/0xc0 > [ 12.051372] driver_probe_devi...

...he scope of this fix and isn't > > currently supported. An implementation will want to explicitly create > > these large pages in the Nouveau driver, so detaching from a DMA/IOMMU > > mapping would still be required. > > I wonder if it might make sense to have a hook in iommu_attach_device() to > notify the arch DMA API code when moving devices between unmanaged and DMA > ops domains? That seems like it might be the most low-impact way to address > the overall problem long-term. > > > Signed-off-by: Thierry Reding <treding at nvidia.com> > > --- > &g...

From: Thierry Reding <treding at nvidia.com> The nouveau_fence_get_get_driver_name() function has a redundant _get in its name. Remove it. Signed-off-by: Thierry Reding <treding at nvidia.com> --- drivers/gpu/drm/nouveau/nouveau_fence.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c

.... It helps to simplify the future bug fixing and enhancement. > + > static int vhost_vdpa_alloc_domain(struct vhost_vdpa *v) > { > struct vdpa_device *vdpa = v->vdpa; > @@ -1128,11 +1174,16 @@ static int vhost_vdpa_alloc_domain(struct vhost_vdpa *v) > > ret = iommu_attach_device(v->domain, dma_dev); > if (ret) > - goto err_attach; > + goto err_alloc_domain; > > - return 0; > + ret = vhost_vdpa_resv_iommu_region(v->domain, dma_dev, &v->resv_iotlb); > + if (ret) > + goto err_attach_device; > > -err_attach: > + return...

...> currently supported. An implementation will want to explicitly create > > > > these large pages in the Nouveau driver, so detaching from a DMA/IOMMU > > > > mapping would still be required. > > > > > > I wonder if it might make sense to have a hook in iommu_attach_device() to > > > notify the arch DMA API code when moving devices between unmanaged and DMA > > > ops domains? That seems like it might be the most low-impact way to address > > > the overall problem long-term. > > > > > > > Signed-off-by: Thierry Reding &...

...: 0000000000000000 [ 12.050708] x3 : 0000000000000004 x2 : 0000000000000000 [ 12.050710] x1 : ffff8001c915b800 x0 : 0000000000000000 [ 12.050713] Process systemd-udevd (pid: 261, stack limit = 0x00000000247b2b64) [ 12.050714] Call trace: [ 12.050717] mutex_lock+0x28/0x58 [ 12.050721] iommu_attach_device+0xac/0xf8 [ 12.050948] nvkm_device_tegra_new+0x260/0x510 [nouveau] [ 12.051166] nouveau_platform_device_create+0x48/0xa8 [nouveau] [ 12.051364] nouveau_platform_probe+0x34/0x80 [nouveau] [ 12.051368] platform_drv_probe+0x60/0xc0 [ 12.051372] driver_probe_device+0x33c/0x4a0 [ 12.051...

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

From: Thierry Reding <treding at nvidia.com> Hi, the GPU on Jetson TX2 (GP10B) does not work properly on all devices. Why exactly is not clear, but there are slight differences between the SKUs that were tested. It turns out that the biggest issue is that on some devices (e.g. the one that I have), pulsing the GPU reset twice as is done in the current code (once as part of the power-ungate

Changes since v3: - Use a single dma_attr for all DMA-API allocations in instmem instead of one per allocation - Use device.info.ram_size instead of pfb->ram to check whether VRAM is present outside of nvkm Changes since v2: - Cleaner changes for ltc - Fixed typos in gk20a instmem IOMMU comments Changes since v1: - Add missing else condition in ltc - Remove extra flags that slipped into

Convert the AMD iommu driver to the dma-iommu api. Remove the iova handling and reserve region code from the AMD iommu driver. Change-log: V6: -add more details to the description of patch 001-iommu-amd-Remove-unnecessary-locking-from-AMD-iommu-.patch -rename handle_deferred_device to iommu_dma_deferred_attach -fix double tabs in 0003-iommu-dma-iommu-Handle-deferred-devices.patch V5: -Rebase on

Convert the AMD iommu driver to the dma-iommu api. Remove the iova handling and reserve region code from the AMD iommu driver. Change-log: V4: -Rebase on top of linux-next -Split the removing of the unnecessary locking in the amd iommu driver into a seperate patch -refactor the "iommu/dma-iommu: Handle deferred devices" patch and address comments v3: -rename dma_limit to dma_mask -exit

Convert the AMD iommu driver to the dma-iommu api. Remove the iova handling and reserve region code from the AMD iommu driver. Change-log: V4: -Rebase on top of linux-next -Split the removing of the unnecessary locking in the amd iommu driver into a seperate patch -refactor the "iommu/dma-iommu: Handle deferred devices" patch and address comments v3: -rename dma_limit to dma_mask -exit

Changes since v1: - Add missing else condition in ltc - Remove extra flags that slipped into nouveau_display.c and nv84_fence.c. Original cover letter: Patches 1-3 make the presence of a RAM device optional, and remove GK20A's dummy RAM driver we were using so far. On chips using shared memory, such a device can confuse the driver into moving objects where there is no need to, and can trick

A series I have waited too long to submit, and the recent refactoring made me pay the price of my perfectionism, so here are the features that are at least completed Patches 1-3 make the presence of a RAM device optional, and remove GK20A's dummy RAM driver we were using so far. On chips using shared memory, such a device can confuse the driver into moving objects where there is no need to,

Hi, Generally the the imported buffers which has memory type TTM_PL_TT are mapped as small pages probably due to lack of big page allocation. But the platform device which also use memory type TTM_PL_TT, like GK20A, can *allocate* big page though the IOMMU hardware inside the SoC. This is a try to map the imported buffers as big pages in GMMU by the platform IOMMU. With some preparation work to

Thanks Ilia for the v2 review! Here is the v3 of this IOMMU support for GK20A series. Changes since v2: - Cleaner changes for ltc - Fixed typos in gk20a instmem IOMMU comments Changes since v1: - Add missing else condition in ltc - Remove extra flags that slipped into nouveau_display.c and nv84_fence.c. Original cover letter: Patches 1-3 make the presence of a RAM device optional, and remove

...04 x2 : 0000000000000000 >> [ 12.050710] x1 : ffff8001c915b800 x0 : 0000000000000000 >> [ 12.050713] Process systemd-udevd (pid: 261, stack limit = >> 0x00000000247b2b64) >> [ 12.050714] Call trace: >> [ 12.050717] mutex_lock+0x28/0x58 >> [ 12.050721] iommu_attach_device+0xac/0xf8 >> [ 12.050948] nvkm_device_tegra_new+0x260/0x510 [nouveau] >> [ 12.051166] nouveau_platform_device_create+0x48/0xa8 [nouveau] >> [ 12.051364] nouveau_platform_probe+0x34/0x80 [nouveau] >> [ 12.051368] platform_drv_probe+0x60/0xc0 >> [ 12.051372...