similar to: [PATCH 0/4] tegra: DMA mask and IOMMU bit fixes

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

Commit 69c4938249fb ("drm/nouveau/instmem/gk20a: use direct CPU access") tried to be smart while using the DMA-API by managing the CPU mappings of buffers allocated with the DMA-API by itself. In doing so, it relied on dma_to_phys() which is an architecture-private function not available everywhere. This broke the build on several architectures. Since there is no reliable and portable

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

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,

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

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

Hello, There is a trouble on ARM with DMA allocations made by device drivers, the trouble is that DMA allocations are getting implicitly backed with IOMMU mapping by the driver core if IOMMU presents in a system and IOMMU could handle device. This is an undesired behaviour for drivers that manage IOMMU by themselves, like NVIDIA Tegra GPU driver. On arm32 the implicit backing happens if

GP10B is the chip used in Tegra X2 SoCs. This patchset adds support for its base engines after reworking secboot a bit to accomodate its calling convention better. This patchset has been tested rendering simple off-screen buffers using Mesa and yielded the expected result. Alexandre Courbot (15): secboot: allow to boot multiple falcons secboot: pass instance to LS firmware loaders secboot:

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

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> 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

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

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

GM20B requires an extra clock compared to GK20A. Add that information into the platform data and acquire and enable this clock if necessary. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- Hi Ben, The DT bindings for this have been approved but not merged yet. This means that for 4.6 GM20B will fail to probe unless the DT is patched - but this is better than the current

This patch series came about after a _long_ discussion between me and Maxime Ripard in response to a different patch I sent out [1]. As part of that discussion, we realized that it would be good if DRM drivers consistently called drm_atomic_helper_shutdown() properly at shutdown and driver remove time as it's documented that they should do. The eventual goal of this would be to enable removing

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 being backed by an IOMMU, just continue using the DMA API. > > Signed-off-by: Thierry Reding

Hi, This series includes some pieces of fixes to complete the GK20A power on/off sequences and add the suspend/resume support. The patches 1/11 - 4/11 are based on the linux-next-20141219. The patches 5/11 - 11/11 are based on the branch "linux-3.19" of Ben Skeggs's tree (http://cgit.freedesktop.org/~darktama/nouveau). Thanks, Vince Vince Hsu (4): (linux-next-20141219) 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

nvkm_device_fini is never called if a failure occurs in nvkm_device_init, even when unloading the module. This can lead to a resources leak (one example is the Tegra interrupt which would never be freed in that case). Fix this by calling nvkm_device_fini in nvkm_device_init's failure path. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> ---

Once DMA API usage is enabled, it becomes apparent that virtio-mmio is inadvertently relying on the default 32-bit DMA mask, which leads to problems like rapidly exhausting SWIOTLB bounce buffers. Ensure that we set the appropriate 64-bit DMA mask whenever possible, with the coherent mask suitably limited for the legacy vring as per a0be1db4304f ("virtio_pci: Limit DMA mask to 44 bits for