similar to: [PATCH 10/11] drm/nvc0/fb: Take lock in nvc0_ram_put()

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

--- drivers/gpu/drm/nouveau/core/include/subdev/ltcg.h | 7 + drivers/gpu/drm/nouveau/core/subdev/fb/nvc0.c | 55 +++++---- drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c | 129 +++++++++++++++++++- drivers/gpu/drm/nouveau/core/subdev/vm/nvc0.c | 58 +++++++++- 4 files changed, 220 insertions(+), 29 deletions(-) diff --git

This will allow the nouveau module to only include support for nv04-nv50, nv50-nvc0, nvc0+ cards individually (or in any combination). Only compiling one of the card types at a time reduces the size of the nouveau module, from 1.3M to 700-800K, depending on the type (including symbols/etc). It should also yield a reduction in compile time as a lot fewer files are compiled. Here are the sizes

On Mon, Aug 12, 2013 at 6:43 AM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > Some registers were not initialized in init, this causes them to be > uninitialized after suspend. > > Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> > --- > diff --git a/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c

Some registers were not initialized in init, this causes them to be uninitialized after suspend. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c | 35 ++++++++++++++++++------- 1 file changed, 26 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c

Some registers were not initialized in init, this causes them to be uninitialized after suspend. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c b/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c index bcca883..7288940 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c +++

Allocating type=0 marks the memory as free. This allows the ltcg memory to be allocated twice. Add a BUG_ON in core/mm.c to prevent this ever happening again. Additionally some registers were not initialized in init, this causes them to be uninitialized after suspend. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- 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

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,

v2: read, don't assume.. *puts on brown paper bag* --- drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c b/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c index a529563..e4940fb 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c +++

Allocating type=0 marks the memory as free. This allows the ltcg memory to be allocated twice. Add a BUG_ON in core/mm.c to prevent this ever happening again. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/core/core/mm.c b/drivers/gpu/drm/nouveau/core/core/mm.c index d829172..7a4e089 100644 ---

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

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

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

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

It's my megabyte, I want to use it! At this point in init vbios is copied over already, so there's no reason it cannot used to hold other data now. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/ramnvc0.c b/drivers/gpu/drm/nouveau/core/subdev/fb/ramnvc0.c index cf97c4d..507d35d 100644 ---

From: Tom Rix <trix at redhat.com> A break is not needed if it is preceded by a return or break Signed-off-by: Tom Rix <trix at redhat.com> --- drivers/gpu/drm/mgag200/mgag200_mode.c | 5 ----- drivers/gpu/drm/nouveau/nvkm/subdev/bios/pll.c | 1 - drivers/gpu/drm/nouveau/nvkm/subdev/clk/mcp77.c | 3 --- drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv50.c | 1 -

Op 14-09-14 om 10:31 schreef poma: > 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

lvqcl wrote: > No, FLAC__AVX_SUPPORTED is 0 (initially it's undefined, then inside cpu.h > it's defined as 0). > > MSVC cannot discard unused references in debug builds and when LTCG is on, > for example: <http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-April/193437.html> > > And currently LTCG is enabled for release builds. Ok, thats a problem. A large