similar to: [PATCH] instmem/gk20a: add write barrier when releasing DMA object

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

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

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

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

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

From: Thierry Reding <treding at nvidia.com> Fill in BAR2 callbacks for instance memory. There's no BAR2 on Tegra GPUs, but buffers are all in system memory anyway, so just return the plain address. Signed-off-by: Thierry Reding <treding at nvidia.com> --- .../drm/nouveau/nvkm/subdev/instmem/gk20a.c | 30 +++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git

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

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

Due to the lack of implicit synchronization between CPU and GPU on Tegra systems (like what PCI provides for dGPUs), the instmem implementation of GK20A/GM20B relied on the slow, legacy PRAMIN so that CPU accesses used the same path as GPU, making sure we see the same data on both ends. The recent Nouveau refactoring introduced acquire/release functions on instmem that help us understand the

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

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

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.

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 +- nvkm/include/subdev/instmem.h | 1 + nvkm/subdev/instmem/gk20a.c | 70 +++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 73

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

From: Martin Peres <martin.peres at free.fr> Signed-off-by: Karol Herbst <nouveau at karolherbst.de> --- drm/nouveau/include/nvkm/core/device.h | 83 +++++++++---------- drm/nouveau/include/nvkm/subdev/iccsense.h | 10 +++ drm/nouveau/nvkm/core/subdev.c | 83 +++++++++---------- drm/nouveau/nvkm/engine/device/base.c | 124 +++++++++++++++--------------