similar to: [PATCH 08/13] drm/nouveau/imem/gk20a: Use sychronized interface of the IOMMU-API

On 11/11/2015 06:07 PM, Alexandre Courbot wrote: > 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

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

Let GK20A's instmem take advantage of the IOMMU if it is present. Having an IOMMU means that instmem is no longer allocated using the DMA API, but instead obtained through page_alloc and made contiguous to the GPU by IOMMU mappings. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/subdev/instmem/gk20a.c | 272 ++++++++++++++++++++++++++++---- 1 file

[ No idea why it's only complaining about this a year later... -dan ] Hello Ben Skeggs, This is a semi-automatic email about new static checker warnings. The patch b7a2bc1886d0: "drm/nouveau/imem: convert to new-style nvkm_subdev" from Aug 20, 2015, leads to the following Smatch complaint: drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c:536 gk20a_instobj_new() error: we

On 8 December 2017 at 19:30, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote: > Commit be55287aa5b ("drm/nouveau/imem/nv50: embed nvkm_instobj directly > into nv04_instobj") introduced some new calls to the refcount api to > the nv50 mapping code. In one particular instance, it does the > following: > > if (!refcount_inc_not_zero(&iobj->maps)) {

Hey Ard, It seems that Ben already committed a similar patch to his tree (see [0]). I do not know whether he is planning to have it part of a pull request of fixes for 4.15. Best regards, Pierre [0]: https://github.com/skeggsb/nouveau/commit/9068f1df2394f0e4ab2b2a28cac06b462fe0a0aa On 2017-12-18 — 09:27, Ard Biesheuvel wrote: > On 8 December 2017 at 19:30, Ard Biesheuvel <ard.biesheuvel

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. Signed-off-by: Jason Gunthorpe <jgg at nvidia.com> --- arch/arm/mm/dma-mapping.c | 11 +++++++---- .../gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c | 3 ++-

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. Signed-off-by: Jason Gunthorpe <jgg at nvidia.com> --- arch/arm/mm/dma-mapping.c | 11 +++++++---- .../gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c | 3 ++-

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. Signed-off-by: Jason Gunthorpe <jgg at nvidia.com> --- arch/arm/mm/dma-mapping.c | 11 +++++++---- .../gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c | 3 ++-

Commit be55287aa5b ("drm/nouveau/imem/nv50: embed nvkm_instobj directly into nv04_instobj") introduced some new calls to the refcount api to the nv50 mapping code. In one particular instance, it does the following: if (!refcount_inc_not_zero(&iobj->maps)) { ... refcount_inc(&iobj->maps); } i.e., it calls refcount_inc() to increment the

From: Thierry Reding <treding at nvidia.com> Commit 12c9b05da918 ("drm/nouveau/imem: support allocations not preserved across suspend") uses container_of() to cast from struct nvkm_memory to struct nvkm_instobj, assuming that all instance objects are derived from struct nvkm_instobj. For the gk20a family that's not the case and they are derived from struct nvkm_memory instead.

On 08/12/2023 10:46, Thierry Reding wrote: > From: Thierry Reding <treding at nvidia.com> > > Commit 12c9b05da918 ("drm/nouveau/imem: support allocations not > preserved across suspend") uses container_of() to cast from struct > nvkm_memory to struct nvkm_instobj, assuming that all instance objects > are derived from struct nvkm_instobj. For the gk20a family

On Thu, Apr 16, 2015 at 8:06 PM, Vince Hsu <vinceh at nvidia.com> wrote: > Instead of hard-coding the translation bit in subdev driver, we refer to > the platform data. > > Signed-off-by: Vince Hsu <vinceh at nvidia.com> > --- > drm/nouveau/nvkm/subdev/instmem/gk20a.c | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git

On 11/09/2015 05:37 PM, Alexandre Courbot wrote: > The LRU list used for recycling CPU mappings was handling concurrency > very poorly. For instance, if an instobj was acquired twice before being > released once, it would end up into the LRU list even though there is > still a client accessing it. > > This patch fixes this by properly counting how many clients are > currently

On Mon, Jan 30, 2017 at 09:03:07PM +0100, Thierry Reding wrote: > From: Thierry Reding <treding at nvidia.com> > > The gk20a implementation of instance memory uses vmap()/vunmap() to map > memory regions into the kernel's virtual address space. These functions > may sleep, so protecting them by a spin lock is not safe. This triggers > a warning if the

The LRU list used for recycling CPU mappings was handling concurrency very poorly. For instance, if an instobj was acquired twice before being released once, it would end up into the LRU list even though there is still a client accessing it. This patch fixes this by properly counting how many clients are currently using a given instobj. While at it, we also raise errors when inconsistencies are

On 02/24/2017 01:20 AM, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Mon, Jan 30, 2017 at 09:03:07PM +0100, Thierry Reding wrote: >> From: Thierry Reding <treding at nvidia.com> >> >> The gk20a implementation of instance memory uses vmap()/vunmap() to map >> memory regions into the kernel's virtual address space. These functions >>

From: Thierry Reding <treding at nvidia.com> The gk20a implementation of instance memory uses vmap()/vunmap() to map memory regions into the kernel's virtual address space. These functions may sleep, so protecting them by a spin lock is not safe. This triggers a warning if the DEBUG_ATOMIC_SLEEP Kconfig option is enabled. Fix this by using a mutex instead. Signed-off-by: Thierry Reding

Although I would not have expected this to happen, we seem to run into race conditions if instobjs are accessed concurrently. Use a global lock for safety. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/subdev/instmem/gk20a.c | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/instmem/gk20a.c

On 10/26/2015 03:54 PM, Alexandre Courbot wrote: > Although I would not have expected this to happen, we seem to run into > race conditions if instobjs are accessed concurrently. Use a global lock > for safety. I wouldn't expect this to be an issue either. Before merging such a large hammer of a fix, I'd strongly prefer to see at least a better justification for why this is