similar to: [PATCH] instmem/gk20a: exclusively acquire instobjs

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

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

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

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

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.

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

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

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

When using the DMA-API for instmem, we may obtain a write-combined mapping. For such cases, add a write barrier in gk20a_instobj_release_dma() to make sure that all writes have reached memory at this time. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/subdev/instmem/gk20a.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

On Wed, Nov 11, 2015 at 9:19 AM, Ben Skeggs <skeggsb at gmail.com> wrote: > 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

On Thu, Nov 5, 2015 at 6:19 AM, Ben Skeggs <skeggsb at gmail.com> wrote: > 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

DMA mask is typically set in nouveau_ttm_init(), but this function is called late during initialization and GK20A's instmem will have called DMA functions before this happens. Having a wrongly set DMA mask can result in the use of unneeded bounce buffers. Set it in GK20A's instmem constructor to avoid this. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> ---

On Tue, Dec 23, 2014 at 5:40 AM, Vince Hsu <vinceh at nvidia.com> wrote: > This is a workaround to avoid the instmem backup/restore during the suspend > and resume process in nv50 instemem driver. > > Signed-off-by: Vince Hsu <vinceh at nvidia.com> > --- > drm/Kbuild | 1 + > nvkm/engine/device/nve0.c | 2 +- >

Split out subsystem specific changes for easier reviews. This will be squashed with main commit. Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c

Split out subsystem specific changes for easier reviews. This will be squashed with main commit. Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c

Split out subsystem specific changes for easier reviews. This will be squashed with main commit. Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com> [for drm] Acked-by: Daniel Vetter <daniel.vetter at ffwll.ch> --- drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git

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