similar to: [PATCH 0/2] drm/nouveau: Small CRC fixes for 5.9

Hello, while I debugged an issue in the imx-lcdc driver I was constantly irritated about struct drm_device pointer variables being named "dev" because with that name I usually expect a struct device pointer. I think there is a big benefit when these are all renamed to "drm_dev". I have no strong preference here though, so "drmdev" or "drm" are fine for me,

Hello, while I debugged an issue in the imx-lcdc driver I was constantly irritated about struct drm_device pointer variables being named "dev" because with that name I usually expect a struct device pointer. I think there is a big benefit when these are all renamed to "drm_dev". I have no strong preference here though, so "drmdev" or "drm" are fine for me,

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 008c data 00000000 0000508c 0000102b This is magic nvidia speak for "You need to have the DMA notifier

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 008c data 00000000 0000508c 0000102b This is magic nvidia speak for "You need to have the DMA notifier

These didn't apply cleanly to v5.8, so here's a backported version. Lyude Paul (2): drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps drm/nouveau/kms/nv50-: Log SOR/PIOR caps drivers/gpu/drm/nouveau/dispnv50/core507d.c | 25 ++++++++++++++++----- drivers/gpu/drm/nouveau/dispnv50/disp.c | 10 +++++++++ 2 files changed, 29 insertions(+), 6 deletions(-)

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

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 008c data 00000000 0000508c 0000102b This is magic nvidia speak for "You need to have the DMA notifier

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 008c data 00000000 0000508c 0000102b This is magic nvidia speak for "You need to have the DMA notifier

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

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 008c data 00000000 0000508c 0000102b This is magic nvidia speak for "You need to have the DMA notifier

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

If CONFIG_DRM_NOUVEAU=y,the following errors are seen while building crc.h. In file included from /scratch/linux/drivers/gpu/drm/nouveau/nouveau_display.c:47: /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ?nv50_head_crc_late_register?: /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h:109:47: error: parameter name omitted static inline int

Noticed these in both the disable (which we'll be getting rid of in a moment) and the atomic disable callbacks: both callback types check whether or not there's actually a CRTC assigned to the given encoder. However, as ->atomic_disable and ->disable will never be called without a CRTC assigned to the given encoder there's no point in this check. So just remove it.

Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c b/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c index 6094805fbd63..06b19883a06b 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c +++

On Sat, 18 Apr 2020 at 05:42, Lyude Paul <lyude at redhat.com> wrote: > > 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. > >

The hardware supports either size. Also add checks to ensure that only these two sizes may be used for supplying a LUT. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Only tested on G84 and GK208. The GV100+ is entirely untested. With the fixed modetest tool, setting ilut and olut sizes to different quantities seems to work out OK, across a range of formats (XR24, XB30, XB4H).

This introduces support for CRC readback on gf119+, using the documentation generously provided to us by Nvidia: https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed through a single set of "outp" sources: outp-active/auto for a CRC of the scanout region, outp-complete for a CRC of both