search for: instobjs

...s 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. > Out of curiosity, which instobjs are being accessed concurrently? PGTs it seems - at least this is what dumping a stack when detecting a concurrent usage on an instobj indicates: [ 270.547052] [<bf0618dc>] (gk20a_instobj_acquire [nouveau]) from [<bf066358>] (gf100_vm_map_sg+0x58/0x124 [nouveau]) [ 270.557568] [<...

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 a large hammer of a fix, I'd strongly prefer to see > at least a better justification for why this is happening rather than > potentially...

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 b/drm/no...

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 happening rather than potentially papering over a larger issue...

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

This should fix some unaligned access warnings. This is also likely to fix non-descript issues on nv30/nv34 as a result of incorrect channel setup. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96836 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drm/nouveau/nvkm/engine/gr/nv30.c | 4 ++-- drm/nouveau/nvkm/engine/gr/nv34.c | 4 ++-- 2 files changed, 4 insertions(+), 4

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.

...stance, 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. Out of curiosity, which instobjs are being accessed concurrently? > > While at it, we also raise errors when inconsistencies are detected, and > factorize some code. > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > --- > drm/nouveau/nvkm/subdev/instmem/gk20a.c | 66 ++++++++++++++++++--...

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

Am Samstag, den 01.02.2014, 18:28 -0500 schrieb Ilia Mirkin: > On Sat, Feb 1, 2014 at 8:40 AM, Lucas Stach <dev at lynxeye.de> wrote: > > Am Samstag, den 01.02.2014, 12:16 +0900 schrieb Alexandre Courbot: > >> Add a clumsy-but-working FB support for GK20A. This chip only uses system > >> memory, so we allocate a big chunk using CMA and let the existing memory >

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

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

...he 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 bounds of accesses to instobjs. We can now use these to perform any needed synchronization, and use direct CPU accesses. For Tegra, provided that we use a write-combined CPU mapping, we just need to make sure the GPU L2 cache is flushed before we access instobjs and invalidated after. This patch series first introduces flush/in...

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

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

GK20A does not have dedicated RAM, thus having a RAM device for it does not make sense. Move the contiguous physical memory allocation to instmem. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/include/nvkm/subdev/instmem.h | 1 + drm/nouveau/nvkm/engine/device/gk104.c | 2 +- drm/nouveau/nvkm/subdev/fb/ramgk20a.c | 86 +-----------

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

https://bugs.freedesktop.org/show_bug.cgi?id=96836 Bug ID: 96836 Summary: Kernel unaligned access at TPC[105d9fb4] nvkm_instobj_wr32+0x14/0x20 [nouveau] Product: xorg Version: unspecified Hardware: SPARC OS: Linux (All) Status: NEW Severity: normal Priority: medium

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: