similar to: [PATCH 1/4] nouveau: Allow allocating BOs at specific offsets

On 23 January 2015 at 08:53, Alexandre Courbot <acourbot at nvidia.com> wrote: > Having a RAM device does not make sense for chips like GK20A which have > no dedicated video memory. The dummy RAM device that we used so far > works as a temporary band-aid, but in the long-term it is desirable for > the driver to be able to work without any kind of VRAM. > > This patch adds a

Having a RAM device does not make sense for chips like GK20A which have no dedicated video memory. The dummy RAM device that we used so far works as a temporary band-aid, but in the long-term it is desirable for the driver to be able to work without any kind of VRAM. This patch adds a few conditionals in places where a RAM device was assumed to be present and allows some more objects to be

Having a RAM device does not make sense for chips like GK20A which have no dedicated video memory. The dummy RAM device that we used so far works as a temporary band-aid, but in the long-term it is desirable for the driver to be able to work without any kind of VRAM. This patch adds a few conditionals in places where a RAM device was assumed to be present and allows some more objects to be

Having a RAM device does not make sense for chips like GK20A which have no dedicated video memory. The dummy RAM device that we used so far works as a temporary band-aid, but in the long-term it is desirable for the driver to be able to work without any kind of VRAM. This patch adds a few conditionals in places where a RAM device was assumed to be present and allows some more objects to be

On Tue, Feb 17, 2015 at 5:47 PM, Alexandre Courbot <acourbot at nvidia.com> wrote: > Having a RAM device does not make sense for chips like GK20A which have > no dedicated video memory. The dummy RAM device that we used so far > works as a temporary band-aid, but in the long-term it is desirable for > the driver to be able to work without any kind of VRAM. > > This patch

Dynamically resizing the framebuffer on nv04 was like playing Russian roulette (and it often happened gratuitously) because it seems unable to scan out from buffers above 16MB. This patch splits the mappable VRAM into two chunks when that's the case, and makes the higher one to be used as well when applicable. Signed-off-by: Francisco Jerez <currojerez at riseup.net> ---

Fixes regression introduced in commit 861d2107 "drm/nouveau/fb: merge fb/vram and port to subdev interfaces" nv50_fb_vram_{new,del} functions were changed to use nouveau_subdev->mutex instead of the old nouveau_mm->mutex. nvc0_fb_vram_new still uses the nouveau_mm->mutex, but nvc0 doesn't have its own fb_vram_del function, using nv50_fb_vram_del instead. Because of this, on

> Hi Gerd, > > I've been seeing a regression on Nouveau with recent linux-next releases > and git bisect points at this commit as the first bad one. If I revert > it (there's a tiny conflict with a patch that was merged subsequently), > things are back to normal. > > I think the reason for this issue is that Nouveau doesn't use GEM > objects for all buffer

- Use the "direct" objects that previously only the kernel fifo had. - This avoids corruption on some buffer moves. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 23 ++--------------- drivers/gpu/drm/nouveau/nouveau_object.c | 36 ++++++++++++++++++++++++++++ drivers/gpu/drm/nouveau/nouveau_state.c | 38

Overall idea: Detect lockups by watching for timeouts (vm flush / fence), return -EIOs, handle them at ioctl level, reset the GPU and repeat last ioctl. GPU reset is done by doing suspend / resume cycle with few tweaks: - CPU-only bo eviction - ignoring vm flush / fence timeouts - shortening waits Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> ---

Previously we were filling it the same as "placements", but in some cases there're valid alternatives that we were ignoring completely. Keeping a back-up memory type helps on several low-mem situations. Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 61 ++++++++++++++++++---------------

Do not attach fences automatically to buffers that are marked for explicit synchronization. Signed-off-by: Lauri Peltonen <lpeltonen at nvidia.com> --- drm/nouveau_bo.c | 8 ++++---- drm/nouveau_bo.h | 4 ++-- drm/nouveau_drm.c | 1 + drm/nouveau_gem.c | 47 +++++++++++++++++++++++++++++++++++++++------- drm/nouveau_gem.h | 6 ++++--

On Thu, May 7, 2020 at 12:11 AM Milan Buska <milan.buska at gmail.com> wrote: > > On 20-05-06 18:53:00, Ilia Mirkin wrote: > > On Wed, May 6, 2020 at 5:59 PM Milan Buska <milan.buska at gmail.com> wrote: > > > > > > On 20-05-06 17:12:44, Ilia Mirkin wrote: > > > > You need both VRAM *and* UNCACHED. Separate them with a | > > > >

From: Matt Parnell <mparnell at gmail.com> Sometimes we have DEBUG_FS enabled, but don't want output from certain modules. Most modules make this an option, so I figured that Nouveau needed it too. Signed-off-by: Matt Parnell <mparnell at gmail.com> --- drivers/gpu/drm/Kconfig | 11 +++++++++++ drivers/gpu/drm/nouveau/Makefile | 2 +-

nouveau_bo_wait will make the GPU channel wait for fence if possible, otherwise falling back to waiting with the CPU using ttm_bo_wait. The nouveau_fence_sync function currently returns -ENOSYS, and is the focus of the next patch. Signed-off-by: Luca Barbieri <luca at luca-barbieri.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 68 ++++++++++++++++++++++++++++++-

Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/nouveau/nouveau_drv.h | 23 +++++ drivers/gpu/drm/nouveau/nouveau_reg.h | 16 ++-- drivers/gpu/drm/nouveau/nouveau_state.c | 8 ++ drivers/gpu/drm/nouveau/nv10_fb.c | 32 ++++++-- drivers/gpu/drm/nouveau/nv10_graph.c | 47 ++++++++--- drivers/gpu/drm/nouveau/nv20_graph.c | 80

Changes in v2: - Addressed review comments nouveau_bo_wait will make the GPU channel wait for fence if possible, otherwise falling back to waiting with the CPU using ttm_bo_wait. The nouveau_fence_sync function currently returns -ENOSYS, and is the focus of the next patch. Signed-off-by: Luca Barbieri <luca at luca-barbieri.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 68

On Sun, 2013-08-11 at 10:41 +1000, Benjamin Herrenschmidt wrote: > Now, to do that, I need a better understanding of the various things > in there since I'm not familiar with nouveau at all. What I think I've > figured out is with a few questions, it would be awesome if you could > answer them so I can have a shot at fixing it all :-) Ok, a few more questions :-) - in struct

This adds basic support for driving sensor chips off the nvidia i2c buses, along with basic support for reading the internal GPU sensor on supported chipsets. It's heavily cribbed off nvclock. Having scanned a large number of bioses, I'm pretty convinced that the appropriate i2c bus is always number 2 in the list on <g80 - I'm not sure about later cards yet. There's still a lot

Overall idea: Detect lockups by watching for timeouts (vm flush / fence), return -EIOs, handle them at ioctl level, reset the GPU and repeat last ioctl. GPU reset is done by doing suspend / resume cycle with few tweaks: - CPU-only bo eviction - ignoring vm flush / fence timeouts - shortening waits Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- Tested only on nv92. ---