public-mirrors/linux
1
0
Fork 0
mirror of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git synced 2025-08-18 12:30:31 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
linux/drivers/gpu/drm/nouveau/dispnv50/crc.h

133 lines
3.9 KiB
C
Raw Permalink Normal View History

drm/nouveau/kms/nvd9-: Add CRC support 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 the scanout and blanking/sync region combined, and outp-inactive for a CRC of only the blanking/sync region. For each source, nouveau selects the appropriate tap point based on the output path in use. We also expose an "rg" source, which allows for capturing CRCs of the scanout raster before it's encoded into a video signal in the output path. This tap point is referred to as the raster generator. Note that while there's some other neat features that can be used with CRC capture on nvidia hardware, like capturing from two CRC sources simultaneously, I couldn't see any usecase for them and did not implement them. Nvidia only allows for accessing CRCs through a shared DMA region that we program through the core EVO/NvDisplay channel which is referred to as the notifier context. The notifier context is limited to either 255 (for Fermi-Pascal) or 2047 (Volta+) entries to store CRCs in, and unfortunately the hardware simply drops CRCs and reports an overflow once all available entries in the notifier context are filled. Since the DRM CRC API and igt-gpu-tools don't expect there to be a limit on how many CRCs can be captured, we work around this in nouveau by allocating two separate notifier contexts for each head instead of one. We schedule a vblank worker ahead of time so that once we start getting close to filling up all of the available entries in the notifier context, we can swap the currently used notifier context out with another pre-prepared notifier context in a manner similar to page flipping. Unfortunately, the hardware only allows us to this by flushing two separate updates on the core channel: one to release the current notifier context handle, and one to program the next notifier context's handle. When the hardware processes the first update, the CRC for the current frame is lost. However, the second update can be flushed immediately without waiting for the first to complete so that CRC generation resumes on the next frame. According to Nvidia's hardware engineers, there isn't any cleaner way of flipping notifier contexts that would avoid this. Since using vblank workers to swap out the notifier context will ensure we can usually flush both updates to hardware within the timespan of a single frame, we can also ensure that there will only be exactly one frame lost between the first and second update being executed by the hardware. This gives us the guarantee that we're always correctly matching each CRC entry with it's respective frame even after a context flip. And since IGT will retrieve the CRC entry for a frame by waiting until it receives a CRC for any subsequent frames, this doesn't cause an issue with any tests and is much simpler than trying to change the current DRM API to accommodate. In order to facilitate testing of correct handling of this limitation, we also expose a debugfs interface to manually control the threshold for when we start trying to flip the notifier context. We will use this in igt to trigger a context flip for testing purposes without needing to wait for the notifier to completely fill up. This threshold is reset to the default value set by nouveau after each capture, and is exposed in a separate folder within each CRTC's debugfs directory labelled "nv_crc". Changes since v1: * Forgot to finish saving crc.h before saving, whoops. This just adds some corrections to the empty function declarations that we use if CONFIG_DEBUG_FS isn't enabled. Changes since v2: * Don't check return code from debugfs_create_dir() or debugfs_create_file() - Greg K-H Changes since v3: (no functional changes) * Fix SPDX license identifiers (checkpatch) * s/uint32_t/u32/ (checkpatch) * Fix indenting in switch cases (checkpatch) Changes since v4: * Remove unneeded param changes with nv50_head_flush_clr/set * Rebase Changes since v5: * Remove set but unused variable (outp) in nv50_crc_atomic_check() - Kbuild bot Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Acked-by: Dave Airlie <airlied@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-10-lyude@redhat.com
2019-10-07 14:20:12 -04:00
/* SPDX-License-Identifier: MIT */
#ifndef __NV50_CRC_H__
#define __NV50_CRC_H__
#include <linux/mutex.h>
#include <drm/drm_crtc.h>
#include <drm/drm_vblank_work.h>
#include <nvif/mem.h>
#include <nvkm/subdev/bios.h>
#include "nouveau_encoder.h"
drm/nouveau/kms/nvd9-: Fix disabling CRCs alongside OR reprogramming While I had thought I'd tested this before, it looks like this one issue slipped by my original CRC patches. Basically, there seem to be a few rules we need to follow when sending CRC commands to the display controller: * CRCs cannot be both disabled and enabled for a single head in the same flush * If a head with CRC reporting enabled switches from one OR to another, there must be a flush before the OR is re-enabled regardless of the final state of CRC reporting. So, split nv50_crc_atomic_prepare_notifier_contexts() into two functions: * nv_crc_atomic_release_notifier_contexts() - checks whether the CRC notifier contexts were released successfully after the first flush * nv_crc_atomic_init_notifier_contexts() - prepares any CRC notifier contexts for use before enabling reporting Additionally, in order to force a flush when we re-assign ORs with heads that have CRCs enabled we split our atomic check function into two: * nv50_crc_atomic_check_head() - called from our heads' atomic checks, determines whether a state needs to set or clear CRC reporting * nv50_crc_atomic_check_outp() - called at the end of the atomic check after all ORs have been added to the atomic state, and sets nv50_atom->flush_disable if needed Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <skeggsb@gmail.com> Acked-by: Dave Airlie <airlied@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200629223635.103804-1-lyude@redhat.com
2020-06-29 18:36:25 -04:00
struct nv50_atom;
drm/nouveau/kms/nvd9-: Add CRC support 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 the scanout and blanking/sync region combined, and outp-inactive for a CRC of only the blanking/sync region. For each source, nouveau selects the appropriate tap point based on the output path in use. We also expose an "rg" source, which allows for capturing CRCs of the scanout raster before it's encoded into a video signal in the output path. This tap point is referred to as the raster generator. Note that while there's some other neat features that can be used with CRC capture on nvidia hardware, like capturing from two CRC sources simultaneously, I couldn't see any usecase for them and did not implement them. Nvidia only allows for accessing CRCs through a shared DMA region that we program through the core EVO/NvDisplay channel which is referred to as the notifier context. The notifier context is limited to either 255 (for Fermi-Pascal) or 2047 (Volta+) entries to store CRCs in, and unfortunately the hardware simply drops CRCs and reports an overflow once all available entries in the notifier context are filled. Since the DRM CRC API and igt-gpu-tools don't expect there to be a limit on how many CRCs can be captured, we work around this in nouveau by allocating two separate notifier contexts for each head instead of one. We schedule a vblank worker ahead of time so that once we start getting close to filling up all of the available entries in the notifier context, we can swap the currently used notifier context out with another pre-prepared notifier context in a manner similar to page flipping. Unfortunately, the hardware only allows us to this by flushing two separate updates on the core channel: one to release the current notifier context handle, and one to program the next notifier context's handle. When the hardware processes the first update, the CRC for the current frame is lost. However, the second update can be flushed immediately without waiting for the first to complete so that CRC generation resumes on the next frame. According to Nvidia's hardware engineers, there isn't any cleaner way of flipping notifier contexts that would avoid this. Since using vblank workers to swap out the notifier context will ensure we can usually flush both updates to hardware within the timespan of a single frame, we can also ensure that there will only be exactly one frame lost between the first and second update being executed by the hardware. This gives us the guarantee that we're always correctly matching each CRC entry with it's respective frame even after a context flip. And since IGT will retrieve the CRC entry for a frame by waiting until it receives a CRC for any subsequent frames, this doesn't cause an issue with any tests and is much simpler than trying to change the current DRM API to accommodate. In order to facilitate testing of correct handling of this limitation, we also expose a debugfs interface to manually control the threshold for when we start trying to flip the notifier context. We will use this in igt to trigger a context flip for testing purposes without needing to wait for the notifier to completely fill up. This threshold is reset to the default value set by nouveau after each capture, and is exposed in a separate folder within each CRTC's debugfs directory labelled "nv_crc". Changes since v1: * Forgot to finish saving crc.h before saving, whoops. This just adds some corrections to the empty function declarations that we use if CONFIG_DEBUG_FS isn't enabled. Changes since v2: * Don't check return code from debugfs_create_dir() or debugfs_create_file() - Greg K-H Changes since v3: (no functional changes) * Fix SPDX license identifiers (checkpatch) * s/uint32_t/u32/ (checkpatch) * Fix indenting in switch cases (checkpatch) Changes since v4: * Remove unneeded param changes with nv50_head_flush_clr/set * Rebase Changes since v5: * Remove set but unused variable (outp) in nv50_crc_atomic_check() - Kbuild bot Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Acked-by: Dave Airlie <airlied@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-10-lyude@redhat.com
2019-10-07 14:20:12 -04:00
struct nv50_disp;
struct nv50_head;
#if IS_ENABLED(CONFIG_DEBUG_FS)
enum nv50_crc_source {
NV50_CRC_SOURCE_NONE = 0,
NV50_CRC_SOURCE_AUTO,
NV50_CRC_SOURCE_RG,
NV50_CRC_SOURCE_OUTP_ACTIVE,
NV50_CRC_SOURCE_OUTP_COMPLETE,
NV50_CRC_SOURCE_OUTP_INACTIVE,
};
/* RG -> SF (DP only)
* -> SOR
* -> PIOR
* -> DAC
*/
enum nv50_crc_source_type {
NV50_CRC_SOURCE_TYPE_NONE = 0,
NV50_CRC_SOURCE_TYPE_SOR,
NV50_CRC_SOURCE_TYPE_PIOR,
NV50_CRC_SOURCE_TYPE_DAC,
NV50_CRC_SOURCE_TYPE_RG,
NV50_CRC_SOURCE_TYPE_SF,
};
struct nv50_crc_notifier_ctx {
struct nvif_mem mem;
struct nvif_object ntfy;
};
struct nv50_crc_atom {
enum nv50_crc_source src;
};
struct nv50_crc_func {
drm/nouveau/kms/nv140-: Use hard-coded wndws or core channel for CRC channel Originally it was assumed based on Nvidia's open-gpu-docs and testing that NVDisplay required that at least one wndw which belongs to a given head to be used as the controlling channel (NVC37D_HEAD_SET_CRC_CONTROL_CONTROLLING_CHANNEL) in order for CRC capture to function. While this is the case on Volta, Turing actually adds the ability to instead use the core channel as the controlling channel. For Turing this is quite useful, as it means that we can always default to the core channel as the controlling channel and we don't need to be concerned about ensuring we have at least one wndw channel owned by a head with CRC output enabled. While Volta lacks this ability, Volta conveniently also lacks flexible wndw mapping - meaning that we can always rely on each head having four wndw channels mapped to it regardless of the atomic state. So, simply use the hard-coded wndw mappings we're guaranteed to have on Volta as the controlling channel, and use the core channel as the controlling channel for Turing+. As a result this also renders the plane ownership logic in nv50_crc_atomic_check() unnessecary, which gives us one less thing to implement when we get support for flexible wndw mapping. We also can entirely drop the wndw parameter from our set_src callbacks, and the atomic state. v2 (Karol): put prackets around complex macro definition removed spaces before :32 in structs Cc: Martin Peres <martin.peres@free.fr> Cc: Jeremy Cline <jcline@redhat.com> Cc: Simon Ser <contact@emersion.fr> Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/10
2021-01-18 20:48:47 -05:00
int (*set_src)(struct nv50_head *, int or, enum nv50_crc_source_type type,
struct nv50_crc_notifier_ctx *ctx);
drm/nouveau/kms/nv50-: convert core crc_set_ctx() to new push macros Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-18 17:42:27 +10:00
int (*set_ctx)(struct nv50_head *, struct nv50_crc_notifier_ctx *);
drm/nouveau/kms/nvd9-: Add CRC support 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 the scanout and blanking/sync region combined, and outp-inactive for a CRC of only the blanking/sync region. For each source, nouveau selects the appropriate tap point based on the output path in use. We also expose an "rg" source, which allows for capturing CRCs of the scanout raster before it's encoded into a video signal in the output path. This tap point is referred to as the raster generator. Note that while there's some other neat features that can be used with CRC capture on nvidia hardware, like capturing from two CRC sources simultaneously, I couldn't see any usecase for them and did not implement them. Nvidia only allows for accessing CRCs through a shared DMA region that we program through the core EVO/NvDisplay channel which is referred to as the notifier context. The notifier context is limited to either 255 (for Fermi-Pascal) or 2047 (Volta+) entries to store CRCs in, and unfortunately the hardware simply drops CRCs and reports an overflow once all available entries in the notifier context are filled. Since the DRM CRC API and igt-gpu-tools don't expect there to be a limit on how many CRCs can be captured, we work around this in nouveau by allocating two separate notifier contexts for each head instead of one. We schedule a vblank worker ahead of time so that once we start getting close to filling up all of the available entries in the notifier context, we can swap the currently used notifier context out with another pre-prepared notifier context in a manner similar to page flipping. Unfortunately, the hardware only allows us to this by flushing two separate updates on the core channel: one to release the current notifier context handle, and one to program the next notifier context's handle. When the hardware processes the first update, the CRC for the current frame is lost. However, the second update can be flushed immediately without waiting for the first to complete so that CRC generation resumes on the next frame. According to Nvidia's hardware engineers, there isn't any cleaner way of flipping notifier contexts that would avoid this. Since using vblank workers to swap out the notifier context will ensure we can usually flush both updates to hardware within the timespan of a single frame, we can also ensure that there will only be exactly one frame lost between the first and second update being executed by the hardware. This gives us the guarantee that we're always correctly matching each CRC entry with it's respective frame even after a context flip. And since IGT will retrieve the CRC entry for a frame by waiting until it receives a CRC for any subsequent frames, this doesn't cause an issue with any tests and is much simpler than trying to change the current DRM API to accommodate. In order to facilitate testing of correct handling of this limitation, we also expose a debugfs interface to manually control the threshold for when we start trying to flip the notifier context. We will use this in igt to trigger a context flip for testing purposes without needing to wait for the notifier to completely fill up. This threshold is reset to the default value set by nouveau after each capture, and is exposed in a separate folder within each CRTC's debugfs directory labelled "nv_crc". Changes since v1: * Forgot to finish saving crc.h before saving, whoops. This just adds some corrections to the empty function declarations that we use if CONFIG_DEBUG_FS isn't enabled. Changes since v2: * Don't check return code from debugfs_create_dir() or debugfs_create_file() - Greg K-H Changes since v3: (no functional changes) * Fix SPDX license identifiers (checkpatch) * s/uint32_t/u32/ (checkpatch) * Fix indenting in switch cases (checkpatch) Changes since v4: * Remove unneeded param changes with nv50_head_flush_clr/set * Rebase Changes since v5: * Remove set but unused variable (outp) in nv50_crc_atomic_check() - Kbuild bot Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Acked-by: Dave Airlie <airlied@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-10-lyude@redhat.com
2019-10-07 14:20:12 -04:00
u32 (*get_entry)(struct nv50_head *, struct nv50_crc_notifier_ctx *,
enum nv50_crc_source, int idx);
bool (*ctx_finished)(struct nv50_head *,
struct nv50_crc_notifier_ctx *);
short flip_threshold;
short num_entries;
size_t notifier_len;
};
struct nv50_crc {
spinlock_t lock;
struct nv50_crc_notifier_ctx ctx[2];
struct drm_vblank_work flip_work;
enum nv50_crc_source src;
u64 frame;
short entry_idx;
short flip_threshold;
u8 ctx_idx : 1;
bool ctx_changed : 1;
};
void nv50_crc_init(struct drm_device *dev);
int nv50_head_crc_late_register(struct nv50_head *);
void nv50_crc_handle_vblank(struct nv50_head *head);
int nv50_crc_verify_source(struct drm_crtc *, const char *, size_t *);
const char *const *nv50_crc_get_sources(struct drm_crtc *, size_t *);
int nv50_crc_set_source(struct drm_crtc *, const char *);
drm/nouveau/kms/nvd9-: Fix disabling CRCs alongside OR reprogramming While I had thought I'd tested this before, it looks like this one issue slipped by my original CRC patches. Basically, there seem to be a few rules we need to follow when sending CRC commands to the display controller: * CRCs cannot be both disabled and enabled for a single head in the same flush * If a head with CRC reporting enabled switches from one OR to another, there must be a flush before the OR is re-enabled regardless of the final state of CRC reporting. So, split nv50_crc_atomic_prepare_notifier_contexts() into two functions: * nv_crc_atomic_release_notifier_contexts() - checks whether the CRC notifier contexts were released successfully after the first flush * nv_crc_atomic_init_notifier_contexts() - prepares any CRC notifier contexts for use before enabling reporting Additionally, in order to force a flush when we re-assign ORs with heads that have CRCs enabled we split our atomic check function into two: * nv50_crc_atomic_check_head() - called from our heads' atomic checks, determines whether a state needs to set or clear CRC reporting * nv50_crc_atomic_check_outp() - called at the end of the atomic check after all ORs have been added to the atomic state, and sets nv50_atom->flush_disable if needed Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <skeggsb@gmail.com> Acked-by: Dave Airlie <airlied@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200629223635.103804-1-lyude@redhat.com
2020-06-29 18:36:25 -04:00
int nv50_crc_atomic_check_head(struct nv50_head *, struct nv50_head_atom *,
struct nv50_head_atom *);
void nv50_crc_atomic_check_outp(struct nv50_atom *atom);
drm/nouveau/kms/nvd9-: Add CRC support 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 the scanout and blanking/sync region combined, and outp-inactive for a CRC of only the blanking/sync region. For each source, nouveau selects the appropriate tap point based on the output path in use. We also expose an "rg" source, which allows for capturing CRCs of the scanout raster before it's encoded into a video signal in the output path. This tap point is referred to as the raster generator. Note that while there's some other neat features that can be used with CRC capture on nvidia hardware, like capturing from two CRC sources simultaneously, I couldn't see any usecase for them and did not implement them. Nvidia only allows for accessing CRCs through a shared DMA region that we program through the core EVO/NvDisplay channel which is referred to as the notifier context. The notifier context is limited to either 255 (for Fermi-Pascal) or 2047 (Volta+) entries to store CRCs in, and unfortunately the hardware simply drops CRCs and reports an overflow once all available entries in the notifier context are filled. Since the DRM CRC API and igt-gpu-tools don't expect there to be a limit on how many CRCs can be captured, we work around this in nouveau by allocating two separate notifier contexts for each head instead of one. We schedule a vblank worker ahead of time so that once we start getting close to filling up all of the available entries in the notifier context, we can swap the currently used notifier context out with another pre-prepared notifier context in a manner similar to page flipping. Unfortunately, the hardware only allows us to this by flushing two separate updates on the core channel: one to release the current notifier context handle, and one to program the next notifier context's handle. When the hardware processes the first update, the CRC for the current frame is lost. However, the second update can be flushed immediately without waiting for the first to complete so that CRC generation resumes on the next frame. According to Nvidia's hardware engineers, there isn't any cleaner way of flipping notifier contexts that would avoid this. Since using vblank workers to swap out the notifier context will ensure we can usually flush both updates to hardware within the timespan of a single frame, we can also ensure that there will only be exactly one frame lost between the first and second update being executed by the hardware. This gives us the guarantee that we're always correctly matching each CRC entry with it's respective frame even after a context flip. And since IGT will retrieve the CRC entry for a frame by waiting until it receives a CRC for any subsequent frames, this doesn't cause an issue with any tests and is much simpler than trying to change the current DRM API to accommodate. In order to facilitate testing of correct handling of this limitation, we also expose a debugfs interface to manually control the threshold for when we start trying to flip the notifier context. We will use this in igt to trigger a context flip for testing purposes without needing to wait for the notifier to completely fill up. This threshold is reset to the default value set by nouveau after each capture, and is exposed in a separate folder within each CRTC's debugfs directory labelled "nv_crc". Changes since v1: * Forgot to finish saving crc.h before saving, whoops. This just adds some corrections to the empty function declarations that we use if CONFIG_DEBUG_FS isn't enabled. Changes since v2: * Don't check return code from debugfs_create_dir() or debugfs_create_file() - Greg K-H Changes since v3: (no functional changes) * Fix SPDX license identifiers (checkpatch) * s/uint32_t/u32/ (checkpatch) * Fix indenting in switch cases (checkpatch) Changes since v4: * Remove unneeded param changes with nv50_head_flush_clr/set * Rebase Changes since v5: * Remove set but unused variable (outp) in nv50_crc_atomic_check() - Kbuild bot Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Acked-by: Dave Airlie <airlied@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-10-lyude@redhat.com
2019-10-07 14:20:12 -04:00
void nv50_crc_atomic_stop_reporting(struct drm_atomic_state *);
drm/nouveau/kms/nvd9-: Fix disabling CRCs alongside OR reprogramming While I had thought I'd tested this before, it looks like this one issue slipped by my original CRC patches. Basically, there seem to be a few rules we need to follow when sending CRC commands to the display controller: * CRCs cannot be both disabled and enabled for a single head in the same flush * If a head with CRC reporting enabled switches from one OR to another, there must be a flush before the OR is re-enabled regardless of the final state of CRC reporting. So, split nv50_crc_atomic_prepare_notifier_contexts() into two functions: * nv_crc_atomic_release_notifier_contexts() - checks whether the CRC notifier contexts were released successfully after the first flush * nv_crc_atomic_init_notifier_contexts() - prepares any CRC notifier contexts for use before enabling reporting Additionally, in order to force a flush when we re-assign ORs with heads that have CRCs enabled we split our atomic check function into two: * nv50_crc_atomic_check_head() - called from our heads' atomic checks, determines whether a state needs to set or clear CRC reporting * nv50_crc_atomic_check_outp() - called at the end of the atomic check after all ORs have been added to the atomic state, and sets nv50_atom->flush_disable if needed Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <skeggsb@gmail.com> Acked-by: Dave Airlie <airlied@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200629223635.103804-1-lyude@redhat.com
2020-06-29 18:36:25 -04:00
void nv50_crc_atomic_init_notifier_contexts(struct drm_atomic_state *);
void nv50_crc_atomic_release_notifier_contexts(struct drm_atomic_state *);
drm/nouveau/kms/nvd9-: Add CRC support 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 the scanout and blanking/sync region combined, and outp-inactive for a CRC of only the blanking/sync region. For each source, nouveau selects the appropriate tap point based on the output path in use. We also expose an "rg" source, which allows for capturing CRCs of the scanout raster before it's encoded into a video signal in the output path. This tap point is referred to as the raster generator. Note that while there's some other neat features that can be used with CRC capture on nvidia hardware, like capturing from two CRC sources simultaneously, I couldn't see any usecase for them and did not implement them. Nvidia only allows for accessing CRCs through a shared DMA region that we program through the core EVO/NvDisplay channel which is referred to as the notifier context. The notifier context is limited to either 255 (for Fermi-Pascal) or 2047 (Volta+) entries to store CRCs in, and unfortunately the hardware simply drops CRCs and reports an overflow once all available entries in the notifier context are filled. Since the DRM CRC API and igt-gpu-tools don't expect there to be a limit on how many CRCs can be captured, we work around this in nouveau by allocating two separate notifier contexts for each head instead of one. We schedule a vblank worker ahead of time so that once we start getting close to filling up all of the available entries in the notifier context, we can swap the currently used notifier context out with another pre-prepared notifier context in a manner similar to page flipping. Unfortunately, the hardware only allows us to this by flushing two separate updates on the core channel: one to release the current notifier context handle, and one to program the next notifier context's handle. When the hardware processes the first update, the CRC for the current frame is lost. However, the second update can be flushed immediately without waiting for the first to complete so that CRC generation resumes on the next frame. According to Nvidia's hardware engineers, there isn't any cleaner way of flipping notifier contexts that would avoid this. Since using vblank workers to swap out the notifier context will ensure we can usually flush both updates to hardware within the timespan of a single frame, we can also ensure that there will only be exactly one frame lost between the first and second update being executed by the hardware. This gives us the guarantee that we're always correctly matching each CRC entry with it's respective frame even after a context flip. And since IGT will retrieve the CRC entry for a frame by waiting until it receives a CRC for any subsequent frames, this doesn't cause an issue with any tests and is much simpler than trying to change the current DRM API to accommodate. In order to facilitate testing of correct handling of this limitation, we also expose a debugfs interface to manually control the threshold for when we start trying to flip the notifier context. We will use this in igt to trigger a context flip for testing purposes without needing to wait for the notifier to completely fill up. This threshold is reset to the default value set by nouveau after each capture, and is exposed in a separate folder within each CRTC's debugfs directory labelled "nv_crc". Changes since v1: * Forgot to finish saving crc.h before saving, whoops. This just adds some corrections to the empty function declarations that we use if CONFIG_DEBUG_FS isn't enabled. Changes since v2: * Don't check return code from debugfs_create_dir() or debugfs_create_file() - Greg K-H Changes since v3: (no functional changes) * Fix SPDX license identifiers (checkpatch) * s/uint32_t/u32/ (checkpatch) * Fix indenting in switch cases (checkpatch) Changes since v4: * Remove unneeded param changes with nv50_head_flush_clr/set * Rebase Changes since v5: * Remove set but unused variable (outp) in nv50_crc_atomic_check() - Kbuild bot Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Acked-by: Dave Airlie <airlied@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-10-lyude@redhat.com
2019-10-07 14:20:12 -04:00
void nv50_crc_atomic_start_reporting(struct drm_atomic_state *);
void nv50_crc_atomic_set(struct nv50_head *, struct nv50_head_atom *);
void nv50_crc_atomic_clr(struct nv50_head *);
extern const struct nv50_crc_func crc907d;
extern const struct nv50_crc_func crcc37d;
drm/nouveau/kms/nv140-: Use hard-coded wndws or core channel for CRC channel Originally it was assumed based on Nvidia's open-gpu-docs and testing that NVDisplay required that at least one wndw which belongs to a given head to be used as the controlling channel (NVC37D_HEAD_SET_CRC_CONTROL_CONTROLLING_CHANNEL) in order for CRC capture to function. While this is the case on Volta, Turing actually adds the ability to instead use the core channel as the controlling channel. For Turing this is quite useful, as it means that we can always default to the core channel as the controlling channel and we don't need to be concerned about ensuring we have at least one wndw channel owned by a head with CRC output enabled. While Volta lacks this ability, Volta conveniently also lacks flexible wndw mapping - meaning that we can always rely on each head having four wndw channels mapped to it regardless of the atomic state. So, simply use the hard-coded wndw mappings we're guaranteed to have on Volta as the controlling channel, and use the core channel as the controlling channel for Turing+. As a result this also renders the plane ownership logic in nv50_crc_atomic_check() unnessecary, which gives us one less thing to implement when we get support for flexible wndw mapping. We also can entirely drop the wndw parameter from our set_src callbacks, and the atomic state. v2 (Karol): put prackets around complex macro definition removed spaces before :32 in structs Cc: Martin Peres <martin.peres@free.fr> Cc: Jeremy Cline <jcline@redhat.com> Cc: Simon Ser <contact@emersion.fr> Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/10
2021-01-18 20:48:47 -05:00
extern const struct nv50_crc_func crcc57d;
drm/nouveau/kms: add support for GB20x Adds basic support for the new display classes available on GB20x GPUs. Most of the changes here deal with HW method moves, with the only other change of note being tweaks to skip allocation of CTXDMA objects, which aren't required on Blackwell display. Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2025-02-04 08:55:17 +10:00
extern const struct nv50_crc_func crcca7d;
drm/nouveau/kms/nvd9-: Add CRC support 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 the scanout and blanking/sync region combined, and outp-inactive for a CRC of only the blanking/sync region. For each source, nouveau selects the appropriate tap point based on the output path in use. We also expose an "rg" source, which allows for capturing CRCs of the scanout raster before it's encoded into a video signal in the output path. This tap point is referred to as the raster generator. Note that while there's some other neat features that can be used with CRC capture on nvidia hardware, like capturing from two CRC sources simultaneously, I couldn't see any usecase for them and did not implement them. Nvidia only allows for accessing CRCs through a shared DMA region that we program through the core EVO/NvDisplay channel which is referred to as the notifier context. The notifier context is limited to either 255 (for Fermi-Pascal) or 2047 (Volta+) entries to store CRCs in, and unfortunately the hardware simply drops CRCs and reports an overflow once all available entries in the notifier context are filled. Since the DRM CRC API and igt-gpu-tools don't expect there to be a limit on how many CRCs can be captured, we work around this in nouveau by allocating two separate notifier contexts for each head instead of one. We schedule a vblank worker ahead of time so that once we start getting close to filling up all of the available entries in the notifier context, we can swap the currently used notifier context out with another pre-prepared notifier context in a manner similar to page flipping. Unfortunately, the hardware only allows us to this by flushing two separate updates on the core channel: one to release the current notifier context handle, and one to program the next notifier context's handle. When the hardware processes the first update, the CRC for the current frame is lost. However, the second update can be flushed immediately without waiting for the first to complete so that CRC generation resumes on the next frame. According to Nvidia's hardware engineers, there isn't any cleaner way of flipping notifier contexts that would avoid this. Since using vblank workers to swap out the notifier context will ensure we can usually flush both updates to hardware within the timespan of a single frame, we can also ensure that there will only be exactly one frame lost between the first and second update being executed by the hardware. This gives us the guarantee that we're always correctly matching each CRC entry with it's respective frame even after a context flip. And since IGT will retrieve the CRC entry for a frame by waiting until it receives a CRC for any subsequent frames, this doesn't cause an issue with any tests and is much simpler than trying to change the current DRM API to accommodate. In order to facilitate testing of correct handling of this limitation, we also expose a debugfs interface to manually control the threshold for when we start trying to flip the notifier context. We will use this in igt to trigger a context flip for testing purposes without needing to wait for the notifier to completely fill up. This threshold is reset to the default value set by nouveau after each capture, and is exposed in a separate folder within each CRTC's debugfs directory labelled "nv_crc". Changes since v1: * Forgot to finish saving crc.h before saving, whoops. This just adds some corrections to the empty function declarations that we use if CONFIG_DEBUG_FS isn't enabled. Changes since v2: * Don't check return code from debugfs_create_dir() or debugfs_create_file() - Greg K-H Changes since v3: (no functional changes) * Fix SPDX license identifiers (checkpatch) * s/uint32_t/u32/ (checkpatch) * Fix indenting in switch cases (checkpatch) Changes since v4: * Remove unneeded param changes with nv50_head_flush_clr/set * Rebase Changes since v5: * Remove set but unused variable (outp) in nv50_crc_atomic_check() - Kbuild bot Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Acked-by: Dave Airlie <airlied@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-10-lyude@redhat.com
2019-10-07 14:20:12 -04:00
#else /* IS_ENABLED(CONFIG_DEBUG_FS) */
struct nv50_crc {};
struct nv50_crc_func {};
struct nv50_crc_atom {};
#define nv50_crc_verify_source NULL
#define nv50_crc_get_sources NULL
#define nv50_crc_set_source NULL
static inline void nv50_crc_init(struct drm_device *dev) {}
drm/nouveau/kms/nv50-: Fix CRC-related compile errors with debugfs disabled 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 name omitted 106 | static inline int nv50_head_crc_late_register(struct nv50_head *) {} | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:106:54: warning: no return statement in function returning non-void [-Wreturn-type] 106 | static inline int nv50_head_crc_late_register(struct nv50_head *) {} | ^~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_handle_vblank’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:108:57: warning: ‘return’ with a value, in function returning void [-Wreturn-type] 108 | nv50_crc_handle_vblank(struct nv50_head *head) { return 0; } | ^ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:108:1: note: declared here 108 | nv50_crc_handle_vblank(struct nv50_head *head) { return 0; } | ^~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_check’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:111:23: error: parameter name omitted 111 | nv50_crc_atomic_check(struct nv50_head *, struct nv50_head_atom *, | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:111:43: error: parameter name omitted 111 | nv50_crc_atomic_check(struct nv50_head *, struct nv50_head_atom *, | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:112:9: error: parameter name omitted 112 | struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:112:16: warning: no return statement in function returning non-void [-Wreturn-type] 112 | struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_stop_reporting’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:114:32: error: parameter name omitted 114 | nv50_crc_atomic_stop_reporting(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_prepare_notifier_contexts’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:116:43: error: parameter name omitted 116 | nv50_crc_atomic_prepare_notifier_contexts(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_start_reporting’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:118:33: error: parameter name omitted 118 | nv50_crc_atomic_start_reporting(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_set’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:120:21: error: parameter name omitted 120 | nv50_crc_atomic_set(struct nv50_head *, struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:120:41: error: parameter name omitted 120 | nv50_crc_atomic_set(struct nv50_head *, struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_clr’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:122:21: error: parameter name omitted 122 | nv50_crc_atomic_clr(struct nv50_head *) {} | ^~~~~~~~~~~~~~~~~~ drivers/gpu/drm/nouveau/nouveau_display.c: In function ‘nouveau_framebuffer_new’: drivers/gpu/drm/nouveau/nouveau_display.c:286:15: warning: variable ‘width’ set but not used [-Wunused-but-set-variable] 286 | unsigned int width, height, i; | ^~~~~ So, fix the inline function declarations we use in drm/drivers/gpu/drm/nouveau/dispnv50/crc.h when CONFIG_DEBUG_FS is enabled. Fixes: 12885ecbfe62 ("drm/nouveau/kms/nvd9-: Add CRC support") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-07-20 16:56:56 -04:00
static inline int
nv50_head_crc_late_register(struct nv50_head *head) { return 0; }
static inline void nv50_crc_handle_vblank(struct nv50_head *head) {}
drm/nouveau/kms/nvd9-: Add CRC support 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 the scanout and blanking/sync region combined, and outp-inactive for a CRC of only the blanking/sync region. For each source, nouveau selects the appropriate tap point based on the output path in use. We also expose an "rg" source, which allows for capturing CRCs of the scanout raster before it's encoded into a video signal in the output path. This tap point is referred to as the raster generator. Note that while there's some other neat features that can be used with CRC capture on nvidia hardware, like capturing from two CRC sources simultaneously, I couldn't see any usecase for them and did not implement them. Nvidia only allows for accessing CRCs through a shared DMA region that we program through the core EVO/NvDisplay channel which is referred to as the notifier context. The notifier context is limited to either 255 (for Fermi-Pascal) or 2047 (Volta+) entries to store CRCs in, and unfortunately the hardware simply drops CRCs and reports an overflow once all available entries in the notifier context are filled. Since the DRM CRC API and igt-gpu-tools don't expect there to be a limit on how many CRCs can be captured, we work around this in nouveau by allocating two separate notifier contexts for each head instead of one. We schedule a vblank worker ahead of time so that once we start getting close to filling up all of the available entries in the notifier context, we can swap the currently used notifier context out with another pre-prepared notifier context in a manner similar to page flipping. Unfortunately, the hardware only allows us to this by flushing two separate updates on the core channel: one to release the current notifier context handle, and one to program the next notifier context's handle. When the hardware processes the first update, the CRC for the current frame is lost. However, the second update can be flushed immediately without waiting for the first to complete so that CRC generation resumes on the next frame. According to Nvidia's hardware engineers, there isn't any cleaner way of flipping notifier contexts that would avoid this. Since using vblank workers to swap out the notifier context will ensure we can usually flush both updates to hardware within the timespan of a single frame, we can also ensure that there will only be exactly one frame lost between the first and second update being executed by the hardware. This gives us the guarantee that we're always correctly matching each CRC entry with it's respective frame even after a context flip. And since IGT will retrieve the CRC entry for a frame by waiting until it receives a CRC for any subsequent frames, this doesn't cause an issue with any tests and is much simpler than trying to change the current DRM API to accommodate. In order to facilitate testing of correct handling of this limitation, we also expose a debugfs interface to manually control the threshold for when we start trying to flip the notifier context. We will use this in igt to trigger a context flip for testing purposes without needing to wait for the notifier to completely fill up. This threshold is reset to the default value set by nouveau after each capture, and is exposed in a separate folder within each CRTC's debugfs directory labelled "nv_crc". Changes since v1: * Forgot to finish saving crc.h before saving, whoops. This just adds some corrections to the empty function declarations that we use if CONFIG_DEBUG_FS isn't enabled. Changes since v2: * Don't check return code from debugfs_create_dir() or debugfs_create_file() - Greg K-H Changes since v3: (no functional changes) * Fix SPDX license identifiers (checkpatch) * s/uint32_t/u32/ (checkpatch) * Fix indenting in switch cases (checkpatch) Changes since v4: * Remove unneeded param changes with nv50_head_flush_clr/set * Rebase Changes since v5: * Remove set but unused variable (outp) in nv50_crc_atomic_check() - Kbuild bot Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Acked-by: Dave Airlie <airlied@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-10-lyude@redhat.com
2019-10-07 14:20:12 -04:00
static inline int
drm/nouveau/kms/nv50-: Fix CRC-related compile errors with debugfs disabled 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 name omitted 106 | static inline int nv50_head_crc_late_register(struct nv50_head *) {} | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:106:54: warning: no return statement in function returning non-void [-Wreturn-type] 106 | static inline int nv50_head_crc_late_register(struct nv50_head *) {} | ^~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_handle_vblank’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:108:57: warning: ‘return’ with a value, in function returning void [-Wreturn-type] 108 | nv50_crc_handle_vblank(struct nv50_head *head) { return 0; } | ^ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:108:1: note: declared here 108 | nv50_crc_handle_vblank(struct nv50_head *head) { return 0; } | ^~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_check’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:111:23: error: parameter name omitted 111 | nv50_crc_atomic_check(struct nv50_head *, struct nv50_head_atom *, | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:111:43: error: parameter name omitted 111 | nv50_crc_atomic_check(struct nv50_head *, struct nv50_head_atom *, | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:112:9: error: parameter name omitted 112 | struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:112:16: warning: no return statement in function returning non-void [-Wreturn-type] 112 | struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_stop_reporting’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:114:32: error: parameter name omitted 114 | nv50_crc_atomic_stop_reporting(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_prepare_notifier_contexts’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:116:43: error: parameter name omitted 116 | nv50_crc_atomic_prepare_notifier_contexts(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_start_reporting’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:118:33: error: parameter name omitted 118 | nv50_crc_atomic_start_reporting(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_set’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:120:21: error: parameter name omitted 120 | nv50_crc_atomic_set(struct nv50_head *, struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:120:41: error: parameter name omitted 120 | nv50_crc_atomic_set(struct nv50_head *, struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_clr’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:122:21: error: parameter name omitted 122 | nv50_crc_atomic_clr(struct nv50_head *) {} | ^~~~~~~~~~~~~~~~~~ drivers/gpu/drm/nouveau/nouveau_display.c: In function ‘nouveau_framebuffer_new’: drivers/gpu/drm/nouveau/nouveau_display.c:286:15: warning: variable ‘width’ set but not used [-Wunused-but-set-variable] 286 | unsigned int width, height, i; | ^~~~~ So, fix the inline function declarations we use in drm/drivers/gpu/drm/nouveau/dispnv50/crc.h when CONFIG_DEBUG_FS is enabled. Fixes: 12885ecbfe62 ("drm/nouveau/kms/nvd9-: Add CRC support") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-07-20 16:56:56 -04:00
nv50_crc_atomic_check_head(struct nv50_head *head,
struct nv50_head_atom *asyh,
struct nv50_head_atom *armh) { return 0; }
drm/nouveau/kms/nvd9-: Fix disabling CRCs alongside OR reprogramming While I had thought I'd tested this before, it looks like this one issue slipped by my original CRC patches. Basically, there seem to be a few rules we need to follow when sending CRC commands to the display controller: * CRCs cannot be both disabled and enabled for a single head in the same flush * If a head with CRC reporting enabled switches from one OR to another, there must be a flush before the OR is re-enabled regardless of the final state of CRC reporting. So, split nv50_crc_atomic_prepare_notifier_contexts() into two functions: * nv_crc_atomic_release_notifier_contexts() - checks whether the CRC notifier contexts were released successfully after the first flush * nv_crc_atomic_init_notifier_contexts() - prepares any CRC notifier contexts for use before enabling reporting Additionally, in order to force a flush when we re-assign ORs with heads that have CRCs enabled we split our atomic check function into two: * nv50_crc_atomic_check_head() - called from our heads' atomic checks, determines whether a state needs to set or clear CRC reporting * nv50_crc_atomic_check_outp() - called at the end of the atomic check after all ORs have been added to the atomic state, and sets nv50_atom->flush_disable if needed Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <skeggsb@gmail.com> Acked-by: Dave Airlie <airlied@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200629223635.103804-1-lyude@redhat.com
2020-06-29 18:36:25 -04:00
static inline void nv50_crc_atomic_check_outp(struct nv50_atom *atom) {}
drm/nouveau/kms/nvd9-: Add CRC support 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 the scanout and blanking/sync region combined, and outp-inactive for a CRC of only the blanking/sync region. For each source, nouveau selects the appropriate tap point based on the output path in use. We also expose an "rg" source, which allows for capturing CRCs of the scanout raster before it's encoded into a video signal in the output path. This tap point is referred to as the raster generator. Note that while there's some other neat features that can be used with CRC capture on nvidia hardware, like capturing from two CRC sources simultaneously, I couldn't see any usecase for them and did not implement them. Nvidia only allows for accessing CRCs through a shared DMA region that we program through the core EVO/NvDisplay channel which is referred to as the notifier context. The notifier context is limited to either 255 (for Fermi-Pascal) or 2047 (Volta+) entries to store CRCs in, and unfortunately the hardware simply drops CRCs and reports an overflow once all available entries in the notifier context are filled. Since the DRM CRC API and igt-gpu-tools don't expect there to be a limit on how many CRCs can be captured, we work around this in nouveau by allocating two separate notifier contexts for each head instead of one. We schedule a vblank worker ahead of time so that once we start getting close to filling up all of the available entries in the notifier context, we can swap the currently used notifier context out with another pre-prepared notifier context in a manner similar to page flipping. Unfortunately, the hardware only allows us to this by flushing two separate updates on the core channel: one to release the current notifier context handle, and one to program the next notifier context's handle. When the hardware processes the first update, the CRC for the current frame is lost. However, the second update can be flushed immediately without waiting for the first to complete so that CRC generation resumes on the next frame. According to Nvidia's hardware engineers, there isn't any cleaner way of flipping notifier contexts that would avoid this. Since using vblank workers to swap out the notifier context will ensure we can usually flush both updates to hardware within the timespan of a single frame, we can also ensure that there will only be exactly one frame lost between the first and second update being executed by the hardware. This gives us the guarantee that we're always correctly matching each CRC entry with it's respective frame even after a context flip. And since IGT will retrieve the CRC entry for a frame by waiting until it receives a CRC for any subsequent frames, this doesn't cause an issue with any tests and is much simpler than trying to change the current DRM API to accommodate. In order to facilitate testing of correct handling of this limitation, we also expose a debugfs interface to manually control the threshold for when we start trying to flip the notifier context. We will use this in igt to trigger a context flip for testing purposes without needing to wait for the notifier to completely fill up. This threshold is reset to the default value set by nouveau after each capture, and is exposed in a separate folder within each CRTC's debugfs directory labelled "nv_crc". Changes since v1: * Forgot to finish saving crc.h before saving, whoops. This just adds some corrections to the empty function declarations that we use if CONFIG_DEBUG_FS isn't enabled. Changes since v2: * Don't check return code from debugfs_create_dir() or debugfs_create_file() - Greg K-H Changes since v3: (no functional changes) * Fix SPDX license identifiers (checkpatch) * s/uint32_t/u32/ (checkpatch) * Fix indenting in switch cases (checkpatch) Changes since v4: * Remove unneeded param changes with nv50_head_flush_clr/set * Rebase Changes since v5: * Remove set but unused variable (outp) in nv50_crc_atomic_check() - Kbuild bot Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Acked-by: Dave Airlie <airlied@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-10-lyude@redhat.com
2019-10-07 14:20:12 -04:00
static inline void
drm/nouveau/kms/nv50-: Fix CRC-related compile errors with debugfs disabled 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 name omitted 106 | static inline int nv50_head_crc_late_register(struct nv50_head *) {} | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:106:54: warning: no return statement in function returning non-void [-Wreturn-type] 106 | static inline int nv50_head_crc_late_register(struct nv50_head *) {} | ^~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_handle_vblank’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:108:57: warning: ‘return’ with a value, in function returning void [-Wreturn-type] 108 | nv50_crc_handle_vblank(struct nv50_head *head) { return 0; } | ^ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:108:1: note: declared here 108 | nv50_crc_handle_vblank(struct nv50_head *head) { return 0; } | ^~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_check’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:111:23: error: parameter name omitted 111 | nv50_crc_atomic_check(struct nv50_head *, struct nv50_head_atom *, | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:111:43: error: parameter name omitted 111 | nv50_crc_atomic_check(struct nv50_head *, struct nv50_head_atom *, | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:112:9: error: parameter name omitted 112 | struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:112:16: warning: no return statement in function returning non-void [-Wreturn-type] 112 | struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_stop_reporting’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:114:32: error: parameter name omitted 114 | nv50_crc_atomic_stop_reporting(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_prepare_notifier_contexts’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:116:43: error: parameter name omitted 116 | nv50_crc_atomic_prepare_notifier_contexts(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_start_reporting’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:118:33: error: parameter name omitted 118 | nv50_crc_atomic_start_reporting(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_set’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:120:21: error: parameter name omitted 120 | nv50_crc_atomic_set(struct nv50_head *, struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:120:41: error: parameter name omitted 120 | nv50_crc_atomic_set(struct nv50_head *, struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_clr’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:122:21: error: parameter name omitted 122 | nv50_crc_atomic_clr(struct nv50_head *) {} | ^~~~~~~~~~~~~~~~~~ drivers/gpu/drm/nouveau/nouveau_display.c: In function ‘nouveau_framebuffer_new’: drivers/gpu/drm/nouveau/nouveau_display.c:286:15: warning: variable ‘width’ set but not used [-Wunused-but-set-variable] 286 | unsigned int width, height, i; | ^~~~~ So, fix the inline function declarations we use in drm/drivers/gpu/drm/nouveau/dispnv50/crc.h when CONFIG_DEBUG_FS is enabled. Fixes: 12885ecbfe62 ("drm/nouveau/kms/nvd9-: Add CRC support") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-07-20 16:56:56 -04:00
nv50_crc_atomic_stop_reporting(struct drm_atomic_state *state) {}
drm/nouveau/kms/nvd9-: Add CRC support 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 the scanout and blanking/sync region combined, and outp-inactive for a CRC of only the blanking/sync region. For each source, nouveau selects the appropriate tap point based on the output path in use. We also expose an "rg" source, which allows for capturing CRCs of the scanout raster before it's encoded into a video signal in the output path. This tap point is referred to as the raster generator. Note that while there's some other neat features that can be used with CRC capture on nvidia hardware, like capturing from two CRC sources simultaneously, I couldn't see any usecase for them and did not implement them. Nvidia only allows for accessing CRCs through a shared DMA region that we program through the core EVO/NvDisplay channel which is referred to as the notifier context. The notifier context is limited to either 255 (for Fermi-Pascal) or 2047 (Volta+) entries to store CRCs in, and unfortunately the hardware simply drops CRCs and reports an overflow once all available entries in the notifier context are filled. Since the DRM CRC API and igt-gpu-tools don't expect there to be a limit on how many CRCs can be captured, we work around this in nouveau by allocating two separate notifier contexts for each head instead of one. We schedule a vblank worker ahead of time so that once we start getting close to filling up all of the available entries in the notifier context, we can swap the currently used notifier context out with another pre-prepared notifier context in a manner similar to page flipping. Unfortunately, the hardware only allows us to this by flushing two separate updates on the core channel: one to release the current notifier context handle, and one to program the next notifier context's handle. When the hardware processes the first update, the CRC for the current frame is lost. However, the second update can be flushed immediately without waiting for the first to complete so that CRC generation resumes on the next frame. According to Nvidia's hardware engineers, there isn't any cleaner way of flipping notifier contexts that would avoid this. Since using vblank workers to swap out the notifier context will ensure we can usually flush both updates to hardware within the timespan of a single frame, we can also ensure that there will only be exactly one frame lost between the first and second update being executed by the hardware. This gives us the guarantee that we're always correctly matching each CRC entry with it's respective frame even after a context flip. And since IGT will retrieve the CRC entry for a frame by waiting until it receives a CRC for any subsequent frames, this doesn't cause an issue with any tests and is much simpler than trying to change the current DRM API to accommodate. In order to facilitate testing of correct handling of this limitation, we also expose a debugfs interface to manually control the threshold for when we start trying to flip the notifier context. We will use this in igt to trigger a context flip for testing purposes without needing to wait for the notifier to completely fill up. This threshold is reset to the default value set by nouveau after each capture, and is exposed in a separate folder within each CRTC's debugfs directory labelled "nv_crc". Changes since v1: * Forgot to finish saving crc.h before saving, whoops. This just adds some corrections to the empty function declarations that we use if CONFIG_DEBUG_FS isn't enabled. Changes since v2: * Don't check return code from debugfs_create_dir() or debugfs_create_file() - Greg K-H Changes since v3: (no functional changes) * Fix SPDX license identifiers (checkpatch) * s/uint32_t/u32/ (checkpatch) * Fix indenting in switch cases (checkpatch) Changes since v4: * Remove unneeded param changes with nv50_head_flush_clr/set * Rebase Changes since v5: * Remove set but unused variable (outp) in nv50_crc_atomic_check() - Kbuild bot Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Acked-by: Dave Airlie <airlied@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-10-lyude@redhat.com
2019-10-07 14:20:12 -04:00
static inline void
drm/nouveau/kms/nv50-: Fix CRC-related compile errors with debugfs disabled 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 name omitted 106 | static inline int nv50_head_crc_late_register(struct nv50_head *) {} | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:106:54: warning: no return statement in function returning non-void [-Wreturn-type] 106 | static inline int nv50_head_crc_late_register(struct nv50_head *) {} | ^~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_handle_vblank’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:108:57: warning: ‘return’ with a value, in function returning void [-Wreturn-type] 108 | nv50_crc_handle_vblank(struct nv50_head *head) { return 0; } | ^ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:108:1: note: declared here 108 | nv50_crc_handle_vblank(struct nv50_head *head) { return 0; } | ^~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_check’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:111:23: error: parameter name omitted 111 | nv50_crc_atomic_check(struct nv50_head *, struct nv50_head_atom *, | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:111:43: error: parameter name omitted 111 | nv50_crc_atomic_check(struct nv50_head *, struct nv50_head_atom *, | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:112:9: error: parameter name omitted 112 | struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:112:16: warning: no return statement in function returning non-void [-Wreturn-type] 112 | struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_stop_reporting’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:114:32: error: parameter name omitted 114 | nv50_crc_atomic_stop_reporting(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_prepare_notifier_contexts’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:116:43: error: parameter name omitted 116 | nv50_crc_atomic_prepare_notifier_contexts(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_start_reporting’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:118:33: error: parameter name omitted 118 | nv50_crc_atomic_start_reporting(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_set’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:120:21: error: parameter name omitted 120 | nv50_crc_atomic_set(struct nv50_head *, struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:120:41: error: parameter name omitted 120 | nv50_crc_atomic_set(struct nv50_head *, struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_clr’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:122:21: error: parameter name omitted 122 | nv50_crc_atomic_clr(struct nv50_head *) {} | ^~~~~~~~~~~~~~~~~~ drivers/gpu/drm/nouveau/nouveau_display.c: In function ‘nouveau_framebuffer_new’: drivers/gpu/drm/nouveau/nouveau_display.c:286:15: warning: variable ‘width’ set but not used [-Wunused-but-set-variable] 286 | unsigned int width, height, i; | ^~~~~ So, fix the inline function declarations we use in drm/drivers/gpu/drm/nouveau/dispnv50/crc.h when CONFIG_DEBUG_FS is enabled. Fixes: 12885ecbfe62 ("drm/nouveau/kms/nvd9-: Add CRC support") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-07-20 16:56:56 -04:00
nv50_crc_atomic_init_notifier_contexts(struct drm_atomic_state *state) {}
drm/nouveau/kms/nvd9-: Fix disabling CRCs alongside OR reprogramming While I had thought I'd tested this before, it looks like this one issue slipped by my original CRC patches. Basically, there seem to be a few rules we need to follow when sending CRC commands to the display controller: * CRCs cannot be both disabled and enabled for a single head in the same flush * If a head with CRC reporting enabled switches from one OR to another, there must be a flush before the OR is re-enabled regardless of the final state of CRC reporting. So, split nv50_crc_atomic_prepare_notifier_contexts() into two functions: * nv_crc_atomic_release_notifier_contexts() - checks whether the CRC notifier contexts were released successfully after the first flush * nv_crc_atomic_init_notifier_contexts() - prepares any CRC notifier contexts for use before enabling reporting Additionally, in order to force a flush when we re-assign ORs with heads that have CRCs enabled we split our atomic check function into two: * nv50_crc_atomic_check_head() - called from our heads' atomic checks, determines whether a state needs to set or clear CRC reporting * nv50_crc_atomic_check_outp() - called at the end of the atomic check after all ORs have been added to the atomic state, and sets nv50_atom->flush_disable if needed Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <skeggsb@gmail.com> Acked-by: Dave Airlie <airlied@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200629223635.103804-1-lyude@redhat.com
2020-06-29 18:36:25 -04:00
static inline void
drm/nouveau/kms/nv50-: Fix CRC-related compile errors with debugfs disabled 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 name omitted 106 | static inline int nv50_head_crc_late_register(struct nv50_head *) {} | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:106:54: warning: no return statement in function returning non-void [-Wreturn-type] 106 | static inline int nv50_head_crc_late_register(struct nv50_head *) {} | ^~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_handle_vblank’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:108:57: warning: ‘return’ with a value, in function returning void [-Wreturn-type] 108 | nv50_crc_handle_vblank(struct nv50_head *head) { return 0; } | ^ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:108:1: note: declared here 108 | nv50_crc_handle_vblank(struct nv50_head *head) { return 0; } | ^~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_check’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:111:23: error: parameter name omitted 111 | nv50_crc_atomic_check(struct nv50_head *, struct nv50_head_atom *, | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:111:43: error: parameter name omitted 111 | nv50_crc_atomic_check(struct nv50_head *, struct nv50_head_atom *, | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:112:9: error: parameter name omitted 112 | struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:112:16: warning: no return statement in function returning non-void [-Wreturn-type] 112 | struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_stop_reporting’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:114:32: error: parameter name omitted 114 | nv50_crc_atomic_stop_reporting(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_prepare_notifier_contexts’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:116:43: error: parameter name omitted 116 | nv50_crc_atomic_prepare_notifier_contexts(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_start_reporting’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:118:33: error: parameter name omitted 118 | nv50_crc_atomic_start_reporting(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_set’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:120:21: error: parameter name omitted 120 | nv50_crc_atomic_set(struct nv50_head *, struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:120:41: error: parameter name omitted 120 | nv50_crc_atomic_set(struct nv50_head *, struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_clr’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:122:21: error: parameter name omitted 122 | nv50_crc_atomic_clr(struct nv50_head *) {} | ^~~~~~~~~~~~~~~~~~ drivers/gpu/drm/nouveau/nouveau_display.c: In function ‘nouveau_framebuffer_new’: drivers/gpu/drm/nouveau/nouveau_display.c:286:15: warning: variable ‘width’ set but not used [-Wunused-but-set-variable] 286 | unsigned int width, height, i; | ^~~~~ So, fix the inline function declarations we use in drm/drivers/gpu/drm/nouveau/dispnv50/crc.h when CONFIG_DEBUG_FS is enabled. Fixes: 12885ecbfe62 ("drm/nouveau/kms/nvd9-: Add CRC support") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-07-20 16:56:56 -04:00
nv50_crc_atomic_release_notifier_contexts(struct drm_atomic_state *state) {}
drm/nouveau/kms/nvd9-: Add CRC support 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 the scanout and blanking/sync region combined, and outp-inactive for a CRC of only the blanking/sync region. For each source, nouveau selects the appropriate tap point based on the output path in use. We also expose an "rg" source, which allows for capturing CRCs of the scanout raster before it's encoded into a video signal in the output path. This tap point is referred to as the raster generator. Note that while there's some other neat features that can be used with CRC capture on nvidia hardware, like capturing from two CRC sources simultaneously, I couldn't see any usecase for them and did not implement them. Nvidia only allows for accessing CRCs through a shared DMA region that we program through the core EVO/NvDisplay channel which is referred to as the notifier context. The notifier context is limited to either 255 (for Fermi-Pascal) or 2047 (Volta+) entries to store CRCs in, and unfortunately the hardware simply drops CRCs and reports an overflow once all available entries in the notifier context are filled. Since the DRM CRC API and igt-gpu-tools don't expect there to be a limit on how many CRCs can be captured, we work around this in nouveau by allocating two separate notifier contexts for each head instead of one. We schedule a vblank worker ahead of time so that once we start getting close to filling up all of the available entries in the notifier context, we can swap the currently used notifier context out with another pre-prepared notifier context in a manner similar to page flipping. Unfortunately, the hardware only allows us to this by flushing two separate updates on the core channel: one to release the current notifier context handle, and one to program the next notifier context's handle. When the hardware processes the first update, the CRC for the current frame is lost. However, the second update can be flushed immediately without waiting for the first to complete so that CRC generation resumes on the next frame. According to Nvidia's hardware engineers, there isn't any cleaner way of flipping notifier contexts that would avoid this. Since using vblank workers to swap out the notifier context will ensure we can usually flush both updates to hardware within the timespan of a single frame, we can also ensure that there will only be exactly one frame lost between the first and second update being executed by the hardware. This gives us the guarantee that we're always correctly matching each CRC entry with it's respective frame even after a context flip. And since IGT will retrieve the CRC entry for a frame by waiting until it receives a CRC for any subsequent frames, this doesn't cause an issue with any tests and is much simpler than trying to change the current DRM API to accommodate. In order to facilitate testing of correct handling of this limitation, we also expose a debugfs interface to manually control the threshold for when we start trying to flip the notifier context. We will use this in igt to trigger a context flip for testing purposes without needing to wait for the notifier to completely fill up. This threshold is reset to the default value set by nouveau after each capture, and is exposed in a separate folder within each CRTC's debugfs directory labelled "nv_crc". Changes since v1: * Forgot to finish saving crc.h before saving, whoops. This just adds some corrections to the empty function declarations that we use if CONFIG_DEBUG_FS isn't enabled. Changes since v2: * Don't check return code from debugfs_create_dir() or debugfs_create_file() - Greg K-H Changes since v3: (no functional changes) * Fix SPDX license identifiers (checkpatch) * s/uint32_t/u32/ (checkpatch) * Fix indenting in switch cases (checkpatch) Changes since v4: * Remove unneeded param changes with nv50_head_flush_clr/set * Rebase Changes since v5: * Remove set but unused variable (outp) in nv50_crc_atomic_check() - Kbuild bot Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Acked-by: Dave Airlie <airlied@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-10-lyude@redhat.com
2019-10-07 14:20:12 -04:00
static inline void
drm/nouveau/kms/nv50-: Fix CRC-related compile errors with debugfs disabled 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 name omitted 106 | static inline int nv50_head_crc_late_register(struct nv50_head *) {} | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:106:54: warning: no return statement in function returning non-void [-Wreturn-type] 106 | static inline int nv50_head_crc_late_register(struct nv50_head *) {} | ^~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_handle_vblank’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:108:57: warning: ‘return’ with a value, in function returning void [-Wreturn-type] 108 | nv50_crc_handle_vblank(struct nv50_head *head) { return 0; } | ^ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:108:1: note: declared here 108 | nv50_crc_handle_vblank(struct nv50_head *head) { return 0; } | ^~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_check’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:111:23: error: parameter name omitted 111 | nv50_crc_atomic_check(struct nv50_head *, struct nv50_head_atom *, | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:111:43: error: parameter name omitted 111 | nv50_crc_atomic_check(struct nv50_head *, struct nv50_head_atom *, | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:112:9: error: parameter name omitted 112 | struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:112:16: warning: no return statement in function returning non-void [-Wreturn-type] 112 | struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_stop_reporting’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:114:32: error: parameter name omitted 114 | nv50_crc_atomic_stop_reporting(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_prepare_notifier_contexts’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:116:43: error: parameter name omitted 116 | nv50_crc_atomic_prepare_notifier_contexts(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_start_reporting’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:118:33: error: parameter name omitted 118 | nv50_crc_atomic_start_reporting(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_set’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:120:21: error: parameter name omitted 120 | nv50_crc_atomic_set(struct nv50_head *, struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:120:41: error: parameter name omitted 120 | nv50_crc_atomic_set(struct nv50_head *, struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_clr’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:122:21: error: parameter name omitted 122 | nv50_crc_atomic_clr(struct nv50_head *) {} | ^~~~~~~~~~~~~~~~~~ drivers/gpu/drm/nouveau/nouveau_display.c: In function ‘nouveau_framebuffer_new’: drivers/gpu/drm/nouveau/nouveau_display.c:286:15: warning: variable ‘width’ set but not used [-Wunused-but-set-variable] 286 | unsigned int width, height, i; | ^~~~~ So, fix the inline function declarations we use in drm/drivers/gpu/drm/nouveau/dispnv50/crc.h when CONFIG_DEBUG_FS is enabled. Fixes: 12885ecbfe62 ("drm/nouveau/kms/nvd9-: Add CRC support") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-07-20 16:56:56 -04:00
nv50_crc_atomic_start_reporting(struct drm_atomic_state *state) {}
drm/nouveau/kms/nvd9-: Add CRC support 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 the scanout and blanking/sync region combined, and outp-inactive for a CRC of only the blanking/sync region. For each source, nouveau selects the appropriate tap point based on the output path in use. We also expose an "rg" source, which allows for capturing CRCs of the scanout raster before it's encoded into a video signal in the output path. This tap point is referred to as the raster generator. Note that while there's some other neat features that can be used with CRC capture on nvidia hardware, like capturing from two CRC sources simultaneously, I couldn't see any usecase for them and did not implement them. Nvidia only allows for accessing CRCs through a shared DMA region that we program through the core EVO/NvDisplay channel which is referred to as the notifier context. The notifier context is limited to either 255 (for Fermi-Pascal) or 2047 (Volta+) entries to store CRCs in, and unfortunately the hardware simply drops CRCs and reports an overflow once all available entries in the notifier context are filled. Since the DRM CRC API and igt-gpu-tools don't expect there to be a limit on how many CRCs can be captured, we work around this in nouveau by allocating two separate notifier contexts for each head instead of one. We schedule a vblank worker ahead of time so that once we start getting close to filling up all of the available entries in the notifier context, we can swap the currently used notifier context out with another pre-prepared notifier context in a manner similar to page flipping. Unfortunately, the hardware only allows us to this by flushing two separate updates on the core channel: one to release the current notifier context handle, and one to program the next notifier context's handle. When the hardware processes the first update, the CRC for the current frame is lost. However, the second update can be flushed immediately without waiting for the first to complete so that CRC generation resumes on the next frame. According to Nvidia's hardware engineers, there isn't any cleaner way of flipping notifier contexts that would avoid this. Since using vblank workers to swap out the notifier context will ensure we can usually flush both updates to hardware within the timespan of a single frame, we can also ensure that there will only be exactly one frame lost between the first and second update being executed by the hardware. This gives us the guarantee that we're always correctly matching each CRC entry with it's respective frame even after a context flip. And since IGT will retrieve the CRC entry for a frame by waiting until it receives a CRC for any subsequent frames, this doesn't cause an issue with any tests and is much simpler than trying to change the current DRM API to accommodate. In order to facilitate testing of correct handling of this limitation, we also expose a debugfs interface to manually control the threshold for when we start trying to flip the notifier context. We will use this in igt to trigger a context flip for testing purposes without needing to wait for the notifier to completely fill up. This threshold is reset to the default value set by nouveau after each capture, and is exposed in a separate folder within each CRTC's debugfs directory labelled "nv_crc". Changes since v1: * Forgot to finish saving crc.h before saving, whoops. This just adds some corrections to the empty function declarations that we use if CONFIG_DEBUG_FS isn't enabled. Changes since v2: * Don't check return code from debugfs_create_dir() or debugfs_create_file() - Greg K-H Changes since v3: (no functional changes) * Fix SPDX license identifiers (checkpatch) * s/uint32_t/u32/ (checkpatch) * Fix indenting in switch cases (checkpatch) Changes since v4: * Remove unneeded param changes with nv50_head_flush_clr/set * Rebase Changes since v5: * Remove set but unused variable (outp) in nv50_crc_atomic_check() - Kbuild bot Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Acked-by: Dave Airlie <airlied@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-10-lyude@redhat.com
2019-10-07 14:20:12 -04:00
static inline void
drm/nouveau/kms/nv50-: Fix CRC-related compile errors with debugfs disabled 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 name omitted 106 | static inline int nv50_head_crc_late_register(struct nv50_head *) {} | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:106:54: warning: no return statement in function returning non-void [-Wreturn-type] 106 | static inline int nv50_head_crc_late_register(struct nv50_head *) {} | ^~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_handle_vblank’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:108:57: warning: ‘return’ with a value, in function returning void [-Wreturn-type] 108 | nv50_crc_handle_vblank(struct nv50_head *head) { return 0; } | ^ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:108:1: note: declared here 108 | nv50_crc_handle_vblank(struct nv50_head *head) { return 0; } | ^~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_check’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:111:23: error: parameter name omitted 111 | nv50_crc_atomic_check(struct nv50_head *, struct nv50_head_atom *, | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:111:43: error: parameter name omitted 111 | nv50_crc_atomic_check(struct nv50_head *, struct nv50_head_atom *, | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:112:9: error: parameter name omitted 112 | struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:112:16: warning: no return statement in function returning non-void [-Wreturn-type] 112 | struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_stop_reporting’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:114:32: error: parameter name omitted 114 | nv50_crc_atomic_stop_reporting(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_prepare_notifier_contexts’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:116:43: error: parameter name omitted 116 | nv50_crc_atomic_prepare_notifier_contexts(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_start_reporting’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:118:33: error: parameter name omitted 118 | nv50_crc_atomic_start_reporting(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_set’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:120:21: error: parameter name omitted 120 | nv50_crc_atomic_set(struct nv50_head *, struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:120:41: error: parameter name omitted 120 | nv50_crc_atomic_set(struct nv50_head *, struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_clr’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:122:21: error: parameter name omitted 122 | nv50_crc_atomic_clr(struct nv50_head *) {} | ^~~~~~~~~~~~~~~~~~ drivers/gpu/drm/nouveau/nouveau_display.c: In function ‘nouveau_framebuffer_new’: drivers/gpu/drm/nouveau/nouveau_display.c:286:15: warning: variable ‘width’ set but not used [-Wunused-but-set-variable] 286 | unsigned int width, height, i; | ^~~~~ So, fix the inline function declarations we use in drm/drivers/gpu/drm/nouveau/dispnv50/crc.h when CONFIG_DEBUG_FS is enabled. Fixes: 12885ecbfe62 ("drm/nouveau/kms/nvd9-: Add CRC support") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-07-20 16:56:56 -04:00
nv50_crc_atomic_set(struct nv50_head *head, struct nv50_head_atom *state) {}
drm/nouveau/kms/nvd9-: Add CRC support 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 the scanout and blanking/sync region combined, and outp-inactive for a CRC of only the blanking/sync region. For each source, nouveau selects the appropriate tap point based on the output path in use. We also expose an "rg" source, which allows for capturing CRCs of the scanout raster before it's encoded into a video signal in the output path. This tap point is referred to as the raster generator. Note that while there's some other neat features that can be used with CRC capture on nvidia hardware, like capturing from two CRC sources simultaneously, I couldn't see any usecase for them and did not implement them. Nvidia only allows for accessing CRCs through a shared DMA region that we program through the core EVO/NvDisplay channel which is referred to as the notifier context. The notifier context is limited to either 255 (for Fermi-Pascal) or 2047 (Volta+) entries to store CRCs in, and unfortunately the hardware simply drops CRCs and reports an overflow once all available entries in the notifier context are filled. Since the DRM CRC API and igt-gpu-tools don't expect there to be a limit on how many CRCs can be captured, we work around this in nouveau by allocating two separate notifier contexts for each head instead of one. We schedule a vblank worker ahead of time so that once we start getting close to filling up all of the available entries in the notifier context, we can swap the currently used notifier context out with another pre-prepared notifier context in a manner similar to page flipping. Unfortunately, the hardware only allows us to this by flushing two separate updates on the core channel: one to release the current notifier context handle, and one to program the next notifier context's handle. When the hardware processes the first update, the CRC for the current frame is lost. However, the second update can be flushed immediately without waiting for the first to complete so that CRC generation resumes on the next frame. According to Nvidia's hardware engineers, there isn't any cleaner way of flipping notifier contexts that would avoid this. Since using vblank workers to swap out the notifier context will ensure we can usually flush both updates to hardware within the timespan of a single frame, we can also ensure that there will only be exactly one frame lost between the first and second update being executed by the hardware. This gives us the guarantee that we're always correctly matching each CRC entry with it's respective frame even after a context flip. And since IGT will retrieve the CRC entry for a frame by waiting until it receives a CRC for any subsequent frames, this doesn't cause an issue with any tests and is much simpler than trying to change the current DRM API to accommodate. In order to facilitate testing of correct handling of this limitation, we also expose a debugfs interface to manually control the threshold for when we start trying to flip the notifier context. We will use this in igt to trigger a context flip for testing purposes without needing to wait for the notifier to completely fill up. This threshold is reset to the default value set by nouveau after each capture, and is exposed in a separate folder within each CRTC's debugfs directory labelled "nv_crc". Changes since v1: * Forgot to finish saving crc.h before saving, whoops. This just adds some corrections to the empty function declarations that we use if CONFIG_DEBUG_FS isn't enabled. Changes since v2: * Don't check return code from debugfs_create_dir() or debugfs_create_file() - Greg K-H Changes since v3: (no functional changes) * Fix SPDX license identifiers (checkpatch) * s/uint32_t/u32/ (checkpatch) * Fix indenting in switch cases (checkpatch) Changes since v4: * Remove unneeded param changes with nv50_head_flush_clr/set * Rebase Changes since v5: * Remove set but unused variable (outp) in nv50_crc_atomic_check() - Kbuild bot Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Acked-by: Dave Airlie <airlied@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-10-lyude@redhat.com
2019-10-07 14:20:12 -04:00
static inline void
drm/nouveau/kms/nv50-: Fix CRC-related compile errors with debugfs disabled 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 name omitted 106 | static inline int nv50_head_crc_late_register(struct nv50_head *) {} | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:106:54: warning: no return statement in function returning non-void [-Wreturn-type] 106 | static inline int nv50_head_crc_late_register(struct nv50_head *) {} | ^~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_handle_vblank’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:108:57: warning: ‘return’ with a value, in function returning void [-Wreturn-type] 108 | nv50_crc_handle_vblank(struct nv50_head *head) { return 0; } | ^ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:108:1: note: declared here 108 | nv50_crc_handle_vblank(struct nv50_head *head) { return 0; } | ^~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_check’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:111:23: error: parameter name omitted 111 | nv50_crc_atomic_check(struct nv50_head *, struct nv50_head_atom *, | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:111:43: error: parameter name omitted 111 | nv50_crc_atomic_check(struct nv50_head *, struct nv50_head_atom *, | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:112:9: error: parameter name omitted 112 | struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:112:16: warning: no return statement in function returning non-void [-Wreturn-type] 112 | struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_stop_reporting’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:114:32: error: parameter name omitted 114 | nv50_crc_atomic_stop_reporting(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_prepare_notifier_contexts’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:116:43: error: parameter name omitted 116 | nv50_crc_atomic_prepare_notifier_contexts(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_start_reporting’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:118:33: error: parameter name omitted 118 | nv50_crc_atomic_start_reporting(struct drm_atomic_state *) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_set’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:120:21: error: parameter name omitted 120 | nv50_crc_atomic_set(struct nv50_head *, struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h:120:41: error: parameter name omitted 120 | nv50_crc_atomic_set(struct nv50_head *, struct nv50_head_atom *) {} | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ‘nv50_crc_atomic_clr’: ./drivers/gpu/drm/nouveau/dispnv50/crc.h:122:21: error: parameter name omitted 122 | nv50_crc_atomic_clr(struct nv50_head *) {} | ^~~~~~~~~~~~~~~~~~ drivers/gpu/drm/nouveau/nouveau_display.c: In function ‘nouveau_framebuffer_new’: drivers/gpu/drm/nouveau/nouveau_display.c:286:15: warning: variable ‘width’ set but not used [-Wunused-but-set-variable] 286 | unsigned int width, height, i; | ^~~~~ So, fix the inline function declarations we use in drm/drivers/gpu/drm/nouveau/dispnv50/crc.h when CONFIG_DEBUG_FS is enabled. Fixes: 12885ecbfe62 ("drm/nouveau/kms/nvd9-: Add CRC support") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-07-20 16:56:56 -04:00
nv50_crc_atomic_clr(struct nv50_head *head) {}
drm/nouveau/kms/nvd9-: Add CRC support 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 the scanout and blanking/sync region combined, and outp-inactive for a CRC of only the blanking/sync region. For each source, nouveau selects the appropriate tap point based on the output path in use. We also expose an "rg" source, which allows for capturing CRCs of the scanout raster before it's encoded into a video signal in the output path. This tap point is referred to as the raster generator. Note that while there's some other neat features that can be used with CRC capture on nvidia hardware, like capturing from two CRC sources simultaneously, I couldn't see any usecase for them and did not implement them. Nvidia only allows for accessing CRCs through a shared DMA region that we program through the core EVO/NvDisplay channel which is referred to as the notifier context. The notifier context is limited to either 255 (for Fermi-Pascal) or 2047 (Volta+) entries to store CRCs in, and unfortunately the hardware simply drops CRCs and reports an overflow once all available entries in the notifier context are filled. Since the DRM CRC API and igt-gpu-tools don't expect there to be a limit on how many CRCs can be captured, we work around this in nouveau by allocating two separate notifier contexts for each head instead of one. We schedule a vblank worker ahead of time so that once we start getting close to filling up all of the available entries in the notifier context, we can swap the currently used notifier context out with another pre-prepared notifier context in a manner similar to page flipping. Unfortunately, the hardware only allows us to this by flushing two separate updates on the core channel: one to release the current notifier context handle, and one to program the next notifier context's handle. When the hardware processes the first update, the CRC for the current frame is lost. However, the second update can be flushed immediately without waiting for the first to complete so that CRC generation resumes on the next frame. According to Nvidia's hardware engineers, there isn't any cleaner way of flipping notifier contexts that would avoid this. Since using vblank workers to swap out the notifier context will ensure we can usually flush both updates to hardware within the timespan of a single frame, we can also ensure that there will only be exactly one frame lost between the first and second update being executed by the hardware. This gives us the guarantee that we're always correctly matching each CRC entry with it's respective frame even after a context flip. And since IGT will retrieve the CRC entry for a frame by waiting until it receives a CRC for any subsequent frames, this doesn't cause an issue with any tests and is much simpler than trying to change the current DRM API to accommodate. In order to facilitate testing of correct handling of this limitation, we also expose a debugfs interface to manually control the threshold for when we start trying to flip the notifier context. We will use this in igt to trigger a context flip for testing purposes without needing to wait for the notifier to completely fill up. This threshold is reset to the default value set by nouveau after each capture, and is exposed in a separate folder within each CRTC's debugfs directory labelled "nv_crc". Changes since v1: * Forgot to finish saving crc.h before saving, whoops. This just adds some corrections to the empty function declarations that we use if CONFIG_DEBUG_FS isn't enabled. Changes since v2: * Don't check return code from debugfs_create_dir() or debugfs_create_file() - Greg K-H Changes since v3: (no functional changes) * Fix SPDX license identifiers (checkpatch) * s/uint32_t/u32/ (checkpatch) * Fix indenting in switch cases (checkpatch) Changes since v4: * Remove unneeded param changes with nv50_head_flush_clr/set * Rebase Changes since v5: * Remove set but unused variable (outp) in nv50_crc_atomic_check() - Kbuild bot Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Acked-by: Dave Airlie <airlied@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-10-lyude@redhat.com
2019-10-07 14:20:12 -04:00
#endif /* IS_ENABLED(CONFIG_DEBUG_FS) */
#endif /* !__NV50_CRC_H__ */
Reference in a new issue Copy permalink