similar to: [PATCH] nv50/disp: Fix modeset on G94

On Fri, Oct 31, 2014 at 8:00 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > On Thu, Oct 30, 2014 at 5:57 PM, Roy Spliet <rspliet at eclipso.eu> wrote: >> Commit 1dce6264045cd23e9c07574ed0bb31c7dce9354f introduced a regression spotted >> on several G94 (FDObz #85160). This device seems to expect the vblank period to > > I believe that's often done as a >

On Thu, Oct 30, 2014 at 5:57 PM, Roy Spliet <rspliet at eclipso.eu> wrote: > Commit 1dce6264045cd23e9c07574ed0bb31c7dce9354f introduced a regression spotted > on several G94 (FDObz #85160). This device seems to expect the vblank period to I believe that's often done as a Bugzilla: https://bugs.freedesktop.org/bla annotation > be set after setting scale instead of before.

--- Ursprüngliche Nachricht --- Von: Ben Skeggs <skeggsb at gmail.com> Datum: 00:52:05 31-10-2014 An: Ilia Mirkin <imirkin at alum.mit.edu> Betreff: Re: [Nouveau] [PATCH] nv50/disp: Fix modeset on G94 > On Fri, Oct 31, 2014 at 8:00 AM, Ilia Mirkin <imirkin at alum.mit.edu> > wrote: > > On Thu, Oct 30, 2014 at 5:57 PM, Roy Spliet <rspliet at eclipso.eu> >

On Fri, Sep 5, 2014 at 12:58 AM, Roy Spliet <rspliet at eclipso.eu> wrote: > Solves blinking on reclocking memory. The value set is an underestimate, but with non-reduced vblanking this should give us plenty of time Hey Roy, I've merged all (squashed the kepler change into the commit where it's needed too) except this patch, which needs to be rebased on top of 3.17-rc.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst at ubuntu.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index 3ed12a8cfc91..a4a586807903 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -370,6 +370,7 @@ nouveau_fbcon_create(struct drm_fb_helper *helper, ret = -ENOMEM; goto

Patch 1 and 2 implement wait-for-vblank, required to remove flicker when reclocking memory Patch 3 and 4 allow me to do things between waiting for VBLANK and disabling FB, like pause PFIFO and wait for the engines to idle. This minimises the time PFIFO is paused, thus maximises performance. The rest of the patches speak for themselves. As the actual memory reclocking script is still somewhat prone

Patch 1 fixes nva3 bailing due to not finding the right ramcfg Patch 2 is a resend rebased on 3.17.0-rc4 for setting the vblank period Patch 3-5 handle writes to per-partition registers, for which NVA3 does not have special broadcast regs available. Patch 6 removes local structs from NVA3 reclocking in favour of the already existing "ram->base." variables, like in NVE0 As always,

Commit 1dce6264045cd23e9c07574ed0bb31c7dce9354f introduced a regression spotted on several G94 (FDObz #85160). This device seems to expect the vblank period to be set after setting scale instead of before. This is a candidate bug-fix for 3.18 Signed-off-by: Roy Spliet <rspliet at eclipso.eu> Tested-by: Zlatko Calusic <zcalusic at bitsync.net> Tested-by: Michael Riesch <michael at

Solves blinking on reclocking memory. The value set is an underestimate, but with non-reduced vblanking this should give us plenty of time Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- drivers/gpu/drm/nouveau/nv50_display.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv50_display.c b/drivers/gpu/drm/nouveau/nv50_display.c

Solves blinking on reclocking memory. The value set is an underestimate, but with non-reduced vblanking this should give us plenty of time Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- drivers/gpu/drm/nouveau/nv50_display.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv50_display.c b/drivers/gpu/drm/nouveau/nv50_display.c

This is what was done prior to the big refactor in kernel 3.8, and what was done by xf86-video-nv. Experimentally, it seems like there's some sort of issue with the high-res lut to be used there. Tested on G92. This ends up mattering because fbcon/fbdev chooses the C8 fb format for low-vram systems, which can occur with some IGP-based configurations with little "stolen" vram.

On Tue, 25 Aug 2020 at 04:33, Lyude Paul <lyude at redhat.com> wrote: > > Not entirely sure why this never came up when I originally tested this > (maybe some BIOSes already have this setup?) but the ->caps_init vfunc > appears to cause the display engine to throw an exception on driver > init, at least on my ThinkPad P72: > > nouveau 0000:01:00.0: disp: chid 0 mthd

On Wed, 26 Aug 2020 at 02:52, Lyude Paul <lyude at redhat.com> wrote: > > On Tue, 2020-08-25 at 08:28 +1000, Ben Skeggs wrote: > > On Tue, 25 Aug 2020 at 04:33, Lyude Paul <lyude at redhat.com> wrote: > > > Not entirely sure why this never came up when I originally tested this > > > (maybe some BIOSes already have this setup?) but the ->caps_init vfunc

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests that we'll be sending in just a short bit. This additionally adds a feature that Ville Syrj?l? came up with: vblank works. Basically, this is just a generic DRM

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests that we'll be sending in just a short bit. This additionally adds a feature that Ville Syrj?l? came up with: vblank works. Basically, this is just a generic DRM

Currently, nouveau doesn't actually bother to try probing whether or not it can actually handle interlaced modes over DisplayPort. As a result, on volta and later we'll end up trying to set an interlaced mode even when it's not supported and cause the front end for the display engine to hang. So, let's teach nouveau to reject interlaced modes on hardware that can't actually

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up

Currently, nouveau doesn't actually bother to try probing whether or not it can actually handle interlaced modes over DisplayPort. As a result, on volta and later we'll end up trying to set an interlaced mode even when it's not supported and cause the front end for the display engine to hang. So, let's teach nouveau to reject interlaced modes on hardware that can't actually

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up