similar to: [PATCH] drm/nouveau/kms/nvd9-: Fix disabling CRCs alongside OR reprogramming

Looks like I made the mistake of forgetting to check whether or not this would build without CONFIG_DEBUG_FS, as the Kbuild bot reported some issues building with tegra_defconfig: In file included from drivers/gpu/drm/nouveau/nouveau_display.c:47: ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ?nv50_head_crc_late_register?: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:106:47: error: parameter

Hi, I actually already sent a patch for this: https://patchwork.freedesktop.org/patch/378202/ I'm guessing it hasn't gotten picked up upstream yet? On Mon, 2020-07-27 at 12:00 +0800, Peng Wu wrote: > 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: >

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

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

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

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

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

On Wed, Jul 12, 2017 at 10:13:43AM +0200, Maarten Lankhorst wrote: > Use the new atomic iterator macros, the old ones are about to be > removed. With the new macros, it's more easy to get old and new state so > get them from the macros instead of from obj->state. > > Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com> > Cc: Ben Skeggs <bskeggs

Use the new atomic iterator macros, the old ones are about to be removed. With the new macros, it's more easy to get old and new state so get them from the macros instead of from obj->state. Changes since v1: - Don't mix up old and new state. (danvet) - Rebase on top of interruptible swap_state changes. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com> Cc:

While we're not quite ready yet to add support for flexible wndw mappings, we are going to need to at least keep track of the static wndw mappings we're currently using in each head's atomic state. We'll likely use this in the future to implement real flexible window mapping, but the primary reason we'll need this is for CRC support. See: on nvidia hardware, each CRC entry in

While we're not quite ready yet to add support for flexible wndw mappings, we are going to need to at least keep track of the static wndw mappings we're currently using in each head's atomic state. We'll likely use this in the future to implement real flexible window mapping, but the primary reason we'll need this is for CRC support. See: on nvidia hardware, each CRC entry in

While we're not quite ready yet to add support for flexible wndw mappings, we are going to need to at least keep track of the static wndw mappings we're currently using in each head's atomic state. We'll likely use this in the future to implement real flexible window mapping, but the primary reason we'll need this is for CRC support. See: on nvidia hardware, each CRC entry in

Use the new atomic iterator macros, the old ones are about to be removed. With the new macros, it's more easy to get old and new state so get them from the macros instead of from obj->state. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org ---

This is not complete documentation, but covers the pieces I read through while reviewing the IGT CRC tests for nouveau. It covers the nouveau-specific debugfs file, an overview of why the code is more complicated than the DRM display CRC support documentation would lead one to expect, and the nv50_crc_func vtable. Many of the details were gleaned from Lyude's commit message, but I think

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

I have a strange dejavu feeling that I tried to submit a patch for this in the past, but that it was rejected. I can't remember though, but I'm further convinced this patch is the right thing to do anyway. We label the to-be-committed head state in nv50_msto_atomic_enable() as armh. Normally armh implies a state which is currently armed in hardware. nv50_msto_atomic_enable() is called