similar to: [PATCH] drm/nouveau: mark last megabyte as usable

On Wed, Dec 10, 2014 at 5:53 PM, Pierre Moreau <pierre.morrow at free.fr> wrote: > (This is a v3 of patch "drm/nouveau/fb/nv50: Add PFB writes") > > This fix a GPU lockup on 9400M (NVAC) when using acceleration, see > https://bugs.freedesktop.org/show_bug.cgi?id=27501 > > v2: > - Move code to subdev/fb/nv50.c as suggested by Roy Spliet; > - Remove arbitrary

Hello Ben Skeggs, The patch 97e5268d57bb: "drm/nouveau/fb/gf100-: rework ram detection" from Mar 2, 2017, leads to the following static checker warning: drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c:592 gf100_ram_ctor() warn: should 'size << 20' be a 64 bit type? drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c 572 gf100_ram_ctor(const struct nvkm_ram_func

Kernel panic caused by list corruption in ltcg seems to indicate a concurrency issue. Take mutex of pfb like nv50_ram_put() to eliminate concurrency. V2: Separate critical section into separate function, avoid taking the lock twice on NVC0 Signed-off-by: Roy Spliet <r.spliet at student.tudelft.nl> --- drivers/gpu/drm/nouveau/core/subdev/fb/priv.h | 2 +-

We want to be able to guarantee the location of the allocated buffer object if we're going to be able to reliably allocate the existing framebuffer at startup. Add an argument to do so and pass that through to the ttm core. Signed-off-by: Matthew Garrett <mjg at redhat.com> --- drivers/bcma/main.c | 1 - drivers/gpu/drm/nouveau/nouveau_bo.c | 8 +++++++-

Some newer chips have trouble coming up, and we get bad MMIO reads from them, like 0xbadf100. This ends up translating into crazy amounts of VRAM, which destroys all sorts of other logic down the line. Instead, fail device init. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: stable at kernel.org --- drm/nouveau/nvkm/subdev/fb/ramgf100.c | 6 ++++++ 1 file changed, 6 insertions(+)

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 > managers work on it. > > A better future design would be to allocate objects directly from system > memory without having to suffer from the limitations of a

Here's a quick-but-I-guess-tidy-fix for faulty behaviour someone reported in NVAF. I'm just not sure if the check for nvaa/nvac should still be in nv50_pm_clocks_pre... I believe this is wrong as they can reclock perfectly well (except the non-existing memory). Anyone has a definite answer to that?

Kernel panic caused by list corruption in ltcg seems to indicate a concurrency issue. Take mutex of pfb like nv50_ram_put() to eliminate concurrency. Signed-off-by: Roy Spliet <r.spliet at student.tudelft.nl> --- drivers/gpu/drm/nouveau/core/subdev/fb/ramnvc0.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Hope I understood you correctly wrt the mem exec stuff. nvkm/subdev/fb/ramnv50.c | 2 +- nvkm/subdev/fb/ramnva3.c | 2 +- nvkm/subdev/fb/ramnvc0.c | 2 +- nvkm/subdev/fb/ramnve0.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/nvkm/subdev/fb/ramnv50.c b/nvkm/subdev/fb/ramnv50.c index ef91b6e..e5d12c2 100644

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 managers work on it. A better future design would be to allocate objects directly from system memory without having to suffer from the limitations of a large, contiguous pool. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> ---

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 >> managers work on it. >> >> A better future design would be to

So... I was wondering what the impact of splitting up the card compilation by e.g. generation would be. Depending on the split things would get fairly intertwined, so I thought I'd start small. This just splits NVC0 from everything else. I figure that for the people this matters the most to, NVC0 is the least relevant card -- people with sub-1GB of RAM, older hardware. With my config options

Sometimes boot scripts leave the "DLL reset" bit on, but it shouldn't be set on every MR write. V2 addresses this by forcing DLL reset off in MR generation

V2: Always disable DLL reset Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- drivers/gpu/drm/nouveau/Makefile | 1 + drivers/gpu/drm/nouveau/core/subdev/fb/priv.h | 1 + drivers/gpu/drm/nouveau/core/subdev/fb/sddr2.c | 96 ++++++++++++++++++++++++++ 3 files changed, 98 insertions(+) create mode 100644 drivers/gpu/drm/nouveau/core/subdev/fb/sddr2.c diff --git

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 13.09.2014 23:45, Roy Spliet wrote: > Dear Poma, > > Don't get anyone wrong, your input is greatly valued. The reason why > "we" (nouveau developers) generally ask for a git bisection is because > we don't know or track specific distributions. Although your search has > narrowed the problem down (thanks for that!), we don't know how big the >

On Fri, Feb 14, 2014 at 7:38 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > So... I was wondering what the impact of splitting up the card compilation by > e.g. generation would be. Depending on the split things would get fairly > intertwined, so I thought I'd start small. This just splits NVC0 from > everything else. I figure that for the people this matters the most to,

Add a simple FB device for GK20A, as well as a RAM implementation based on contiguous DMA memory allocations suitable for chips that use system memory as video RAM. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/Makefile | 2 + drivers/gpu/drm/nouveau/core/include/subdev/fb.h | 1 + drivers/gpu/drm/nouveau/core/subdev/fb/gk20a.c

Hi, for my isbn plugin, I''m wishing to incldue generated isbn pages in caller pages (the ones with <isbn value=""> tags). But I want my isbn page to be processed before for its tags to be transformed (like the relocatable or other ones). Besides, i do not want its header to be included. Is there an easy solution for that, or should I do the work myself ? -- Nicolas

Hello, this is my first Xorg/Nouveau bug-report ever so I'll try to explain as good as I can ;) After several years of using the NVIDIA binary driver, I once again tried the latest nouveau driver for my Onboard Geforce 8100 card. Several month ago I couldn' t even get to the kdm screen. But to my surprise everything I needed worked perfectly. Even KWin compositing. Amazing. Although