similar to: [PATCH v2] disp/nvd0-: allow 540MHz data rate for nvd0+ devices

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

https://bugs.freedesktop.org/show_bug.cgi?id=76319 Priority: medium Bug ID: 76319 Assignee: nouveau at lists.freedesktop.org Summary: [NVE6] MMIO FAULT, black screen on K2100M QA Contact: xorg-team at lists.x.org Severity: blocker Classification: Unclassified OS: Linux (All) Reporter: d-bugzilla at moens.cc

Not as thoroughly tested as I would like. Newer nvd0 and kepler are unsupported, as I don't know the registers yet. Information of the scanout position is based on Lucas Stach's original patch, with a teak to read vline twice, to prevent a race of hline with vline. Cc: Lucas Stach <dev at lynxeye.de> Cc: Mario Kleiner <mario.kleiner at tuebingen.mpg.de> Signed-off-by: Maarten

Hello all, I'm using gentoo, with kernel 3.17.0-p1-pf and at some point, a patch was included in this branch of the gentoo kernel that broke hdmi audio. I've checked with the latest 3.19 vanilla kernel, and I still have the same problem. I cannot output multichannel sound over hdmi. After some investigations, I've narrowed down the issue to the following lines in the file

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

https://bugs.freedesktop.org/show_bug.cgi?id=66650 Priority: medium Bug ID: 66650 Assignee: nouveau at lists.freedesktop.org Summary: [regression][NVD0] 'drm/nve0-/gr: some new gpc registers can have multiple copies' causes lockups QA Contact: xorg-team at lists.x.org Severity: normal Classification:

Hello Ben, The working kernel code I based my investigation was a 1.3.17 + gentoo patch (so yes, pretty old) The new one below, not working is the vanilla 3.19 (from the gentoo repo, should be identical to the latest 3.19 stable) I've narrowed down the issue to the size of the eld. The new patch (that indeed uses drm_eld_size) (with this patch, I have a working 3.19 kernel): I will need to

On Mon, Feb 16, 2015 at 5:03 AM, Farid BENAMROUCHE <fariouche at yahoo.fr> wrote: > Hello all, > > I'm using gentoo, with kernel 3.17.0-p1-pf and at some point, a patch was included in this branch of the gentoo kernel that broke hdmi audio. > > I've checked with the latest 3.19 vanilla kernel, and I still have the same problem. I cannot output multichannel sound over

--- drivers/gpu/drm/nouveau/nvd0_display.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvd0_display.c b/drivers/gpu/drm/nouveau/nvd0_display.c index c486d3c..c50b075 100644 --- a/drivers/gpu/drm/nouveau/nvd0_display.c +++ b/drivers/gpu/drm/nouveau/nvd0_display.c @@ -790,7 +790,7 @@ nvd0_crtc_cursor_move(struct drm_crtc *crtc, int x, int y)

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

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

This makes debugging with DP tracing a lot harder to interpret, so name each i2c based off the name of the encoder that it's for Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +- drivers/gpu/drm/nouveau/nouveau_connector.c | 12 ++++++++++--

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 > Author: Ben Skeggs <bskeggs at redhat.com> > Date: Mon Feb 18

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,

Hello, I have an Asus laptop, U36SD, with Optimus technology. The discrete gpu is an NVIDIA GeForce GT 520M with 1GB DDR3 VRAM Using Fedora 17; up to kernel 3.3.7-1 I was able to use bumblebee and bbswitch and then running optirun command (as I could do in F16). No more with kernel 3.4. Tried 3.4.0-1.fc17.x86_64, 3.4.2-4.fc17.x86_64 and 3.4.3-1.fc17.x86_64. I already opened a bug against F17:

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

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 function) case GM204_DISP_CORE_CHANNEL_DMA: ^

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:

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