similar to: 3.19.0-rc1 nouvea build failure on GeForce GT 610 only

On Mon, 2014-12-22 at 14:37 +0100, Paul Bolle wrote: > On Mon, 2014-12-22 at 13:01 +0000, Sid Boyce wrote: > > CHK kernel/config_data.h > > CC [M] drivers/gpu/drm/nouveau/core/engine/dmaobj/nvd0.o > > drivers/gpu/drm/nouveau/core/engine/dmaobj/nvd0.c: In function > > ‘nvd0_dmaobj_bind’: > > drivers/gpu/drm/nouveau/core/engine/dmaobj/nvd0.c:54:8: error:

Hi Sid, On Mon, 2014-12-22 at 13:01 +0000, Sid Boyce wrote: > CHK kernel/config_data.h > CC [M] drivers/gpu/drm/nouveau/core/engine/dmaobj/nvd0.o > drivers/gpu/drm/nouveau/core/engine/dmaobj/nvd0.c: In function > ‘nvd0_dmaobj_bind’: > drivers/gpu/drm/nouveau/core/engine/dmaobj/nvd0.c:54:8: error: > ‘GM204_DISP_CORE_CHANNEL_DMA’ undeclared (first use in this

On 22/12/14 13:54, Paul Bolle wrote: > On Mon, 2014-12-22 at 14:37 +0100, Paul Bolle wrote: >> On Mon, 2014-12-22 at 13:01 +0000, Sid Boyce wrote: >>> CHK kernel/config_data.h >>> CC [M] drivers/gpu/drm/nouveau/core/engine/dmaobj/nvd0.o >>> drivers/gpu/drm/nouveau/core/engine/dmaobj/nvd0.c: In function >>> ‘nvd0_dmaobj_bind’:

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

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,

To make the code clearer, use rb_entry() instead of container_of() to deal with rbtree. Signed-off-by: Geliang Tang <geliangtang at gmail.com> --- drivers/gpu/drm/nouveau/nvkm/engine/dma/base.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/dma/base.c b/drivers/gpu/drm/nouveau/nvkm/engine/dma/base.c index f11ebdd..4655d17 100644

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

From: Martin Peres <martin.peres at labri.fr> This is safe because ptherm hasn't been configured yet and will be a little further down the initialization path. Ptherm should be safe regarding to runtime reconfiguration. v2: - do not limit this patch to nv84-a3 and make it nv84+ Signed-off-by: Martin Peres <martin.peres at labri.fr> ---

From: Martin Peres <martin.peres at labri.fr> This is safe because ptherm hasn't been configured yet and will be a little further down the initialization path. Ptherm should be safe regarding to runtime reconfiguration. v2: - do not limit this patch to nv84-a3 and make it nv84+ v3: - move the ack to fini() - disable IRQs on fini() - silently ignore un-requested IRQs

Sort of fixes mmiotrace for me again, I could sear I sent a similar patch before the rework to event interface, so I guess it got reintroduced. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c index 7e3875d..35e526b 100644 ---

The following commit from about a year ago removed nouveau_dp_dpms() which did steps required to suspend and resume a monitor connected via DisplayPort. commit 0a0afd282fd715dd63d64b243299a64da14f8e8d Author: Ben Skeggs <bskeggs at redhat.com> Date: Mon Feb 18 23:17:53 2013 -0500 drm/nv50-/disp: move DP link training to core and train from supervisor My computer with

On 5 May 2014 01:43, Ben Skeggs <skeggsb at gmail.com> wrote: > On Mon, May 5, 2014 at 4:48 AM, Sergei Antonov <saproj at gmail.com> wrote: >> The following commit from about a year ago removed nouveau_dp_dpms() which >> did steps required to suspend and resume a monitor connected via DisplayPort. >> >> commit 0a0afd282fd715dd63d64b243299a64da14f8e8d

i2c_bit_add_bus can call the pre_xfer function, which expects the func pointer to be set. Pass in func to the port creation logic so that it is set before i2c_bit_add_bus. See https://bugs.freedesktop.org/show_bug.cgi?id=68456 Reported-by: Hans-Peter Deifel <hpdeifel at gmx.de> Tested-by: Hans-Peter Deifel <hpdeifel at gmx.de> Signed-off-by: Ilia Mirkin <imirkin at

nv92 hardware has only 16 interrupt lines, while nv94 and later has 32. Accessing 0xe0c{0,4} registers on nv92 can lead to incorrect PDISP setup. This is a regression introduced with commit 9d0f5ec9ee0fd5dc5fc1cc2cf559286431e406e3 Author: Ben Skeggs <bskeggs at redhat.com> Date: Mon May 12 15:22:42 2014 +1000 gpio: split g92 class from nv50 Reported-by: estece on #nouveau Cc: stable

https://bugs.freedesktop.org/show_bug.cgi?id=50571 Bug #: 50571 Summary: nouveau crashes with GeForce GT 520 Classification: Unclassified Product: xorg Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component:

> On Tue, Apr 01, 2014 at 02:53:02PM -0400, Ilia Mirkin wrote: >I believe that ch7006 is the only external encoder that's supposed to >work, so you're in luck. It sounds like it passes the nv04_tv_identify >stage of nv04_tv_create -- perhaps it fails later? Although based on >the prints, it's even doing dpms stuff (but it hits _detect a second >time... odd). Try

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76319 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- It's unclear to me whether GF11x devices actually support this, but the disp "split" is at nvd0, so I went with that. The marketing docs are fairly unclear. However most of them don't actually have DP in the first place, so it may not be a huge issue. I

After analyzing verbose nouveau & drm dmesg, I have found seemingly no more useful details pertaining to having no TV-1 device. The TV-1 device might be getting lost within DRM, by setting the TV-1 (SVIDEO, Composite) device into DPMS mode or Full Power Down mode, and the ch7006 datasheet does say in this mode, all but the i2c circuits are disabled! Looking at

Hey, This patch causes a regression on my display-less nvd7. Commenting out the aux, aux_stat and aux_mask members in nvd0_i2c_oclass fixes boot, and makes things work normally again. broken dmesg: [ 40.314470] ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140424/nsarguments-95) [ 40.314729] ACPI Warning: \_SB_.PCI0.GFX0._DSM:

https://bugs.freedesktop.org/show_bug.cgi?id=70566 Priority: medium Bug ID: 70566 Assignee: nouveau at lists.freedesktop.org Summary: NVD0 card hard lock-ups entire system at random moments QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: All