2018-05-08 20:39:47 +10:00
|
|
|
#ifndef __NV50_KMS_ATOM_H__
|
|
|
|
#define __NV50_KMS_ATOM_H__
|
|
|
|
#define nv50_atom(p) container_of((p), struct nv50_atom, state)
|
|
|
|
#include <drm/drm_atomic.h>
|
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
|
|
|
#include "crc.h"
|
|
|
|
|
|
|
|
struct nouveau_encoder;
|
2018-05-08 20:39:47 +10:00
|
|
|
|
|
|
|
struct nv50_atom {
|
|
|
|
struct drm_atomic_state state;
|
|
|
|
|
|
|
|
struct list_head outp;
|
|
|
|
bool lock_core;
|
|
|
|
bool flush_disable;
|
|
|
|
};
|
|
|
|
|
|
|
|
#define nv50_head_atom(p) container_of((p), struct nv50_head_atom, state)
|
|
|
|
|
|
|
|
struct nv50_head_atom {
|
|
|
|
struct drm_crtc_state state;
|
|
|
|
|
2018-05-08 20:39:47 +10:00
|
|
|
struct {
|
|
|
|
u32 mask;
|
drm/nouveau/kms/nv140-: Track wndw mappings in nv50_head_atom
While we're not quite ready yet to add support for flexible wndw
mappings, we are going to need to at least keep track of the static wndw
mappings we're currently using in each head's atomic state. We'll likely
use this in the future to implement real flexible window mapping, but
the primary reason we'll need this is for CRC support.
See: on nvidia hardware, each CRC entry in the CRC notifier dma context
has a "tag". This tag corresponds to the nth update on a specific
EVO/NvDisplay channel, which itself is referred to as the "controlling
channel". For gf119+ this can be the core channel, ovly channel, or base
channel. Since we don't expose CRC entry tags to userspace, we simply
ignore this feature and always use the core channel as the controlling
channel. Simple.
Things get a little bit more complicated on gv100+ though. GV100+ only
lets us set the controlling channel to a specific wndw channel, and that
wndw must be owned by the head that we're grabbing CRCs when we enable
CRC generation. Thus, we always need to make sure that each atomic head
state has at least one wndw that is mapped to the head, which will be
used as the controlling channel.
Note that since we don't have flexible wndw mappings yet, we don't
expect to run into any scenarios yet where we'd have a head with no
mapped wndws. When we do add support for flexible wndw mappings however,
we'll need to make sure that we handle reprogramming CRC capture if our
controlling wndw is moved to another head (and potentially reject the
new head state entirely if we can't find another available wndw to
replace it).
With that being said, nouveau currently tracks wndw visibility on heads.
It does not keep track of the actual ownership mappings, which are
(currently) statically programmed. To fix this, we introduce another
bitmask into nv50_head_atom.wndw to keep track of ownership separately
from visibility. We then introduce a nv50_head callback to handle
populating the wndw ownership map, and call it during the atomic check
phase when core->assign_windows is set to true.
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-7-lyude@redhat.com
2020-02-06 14:37:36 -05:00
|
|
|
u32 owned;
|
2018-05-08 20:39:47 +10:00
|
|
|
u32 olut;
|
|
|
|
} wndw;
|
|
|
|
|
2018-05-08 20:39:47 +10:00
|
|
|
struct {
|
|
|
|
u16 iW;
|
|
|
|
u16 iH;
|
|
|
|
u16 oW;
|
|
|
|
u16 oH;
|
|
|
|
} view;
|
|
|
|
|
|
|
|
struct nv50_head_mode {
|
|
|
|
bool interlace;
|
|
|
|
u32 clock;
|
|
|
|
struct {
|
|
|
|
u16 active;
|
|
|
|
u16 synce;
|
|
|
|
u16 blanke;
|
|
|
|
u16 blanks;
|
|
|
|
} h;
|
|
|
|
struct {
|
|
|
|
u32 active;
|
|
|
|
u16 synce;
|
|
|
|
u16 blanke;
|
|
|
|
u16 blanks;
|
|
|
|
u16 blank2s;
|
|
|
|
u16 blank2e;
|
|
|
|
u16 blankus;
|
|
|
|
} v;
|
|
|
|
} mode;
|
|
|
|
|
|
|
|
struct {
|
|
|
|
bool visible;
|
|
|
|
u32 handle;
|
|
|
|
u64 offset:40;
|
2018-05-08 20:39:47 +10:00
|
|
|
u8 buffer:1;
|
|
|
|
u8 mode:4;
|
2018-12-11 14:50:02 +10:00
|
|
|
u16 size:11;
|
2018-05-08 20:39:48 +10:00
|
|
|
u8 range:2;
|
|
|
|
u8 output_mode:2;
|
2018-12-11 14:50:02 +10:00
|
|
|
void (*load)(struct drm_color_lut *, int size, void __iomem *);
|
2018-05-08 20:39:47 +10:00
|
|
|
} olut;
|
2018-05-08 20:39:47 +10:00
|
|
|
|
|
|
|
struct {
|
|
|
|
bool visible;
|
|
|
|
u32 handle;
|
|
|
|
u64 offset:40;
|
|
|
|
u8 format;
|
|
|
|
u8 kind:7;
|
|
|
|
u8 layout:1;
|
2018-05-08 20:39:47 +10:00
|
|
|
u8 blockh:4;
|
|
|
|
u16 blocks:12;
|
2018-05-08 20:39:47 +10:00
|
|
|
u32 pitch:20;
|
|
|
|
u16 x;
|
|
|
|
u16 y;
|
|
|
|
u16 w;
|
|
|
|
u16 h;
|
|
|
|
} core;
|
|
|
|
|
|
|
|
struct {
|
|
|
|
bool visible;
|
|
|
|
u32 handle;
|
|
|
|
u64 offset:40;
|
2018-05-08 20:39:47 +10:00
|
|
|
u8 layout:2;
|
2018-05-08 20:39:48 +10:00
|
|
|
u8 format:8;
|
2018-05-08 20:39:47 +10:00
|
|
|
} curs;
|
|
|
|
|
|
|
|
struct {
|
|
|
|
u8 depth;
|
|
|
|
u8 cpp;
|
|
|
|
u16 x;
|
|
|
|
u16 y;
|
|
|
|
u16 w;
|
|
|
|
u16 h;
|
|
|
|
} base;
|
|
|
|
|
|
|
|
struct {
|
|
|
|
u8 cpp;
|
|
|
|
} ovly;
|
|
|
|
|
|
|
|
struct {
|
|
|
|
bool enable:1;
|
|
|
|
u8 bits:2;
|
|
|
|
u8 mode:4;
|
|
|
|
} dither;
|
|
|
|
|
|
|
|
struct {
|
|
|
|
struct {
|
|
|
|
u16 cos:12;
|
|
|
|
u16 sin:12;
|
|
|
|
} sat;
|
|
|
|
} procamp;
|
|
|
|
|
|
|
|
struct {
|
|
|
|
u8 nhsync:1;
|
|
|
|
u8 nvsync:1;
|
|
|
|
u8 depth:4;
|
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
|
|
|
u8 crc_raster:2;
|
2019-11-15 16:07:19 -05:00
|
|
|
u8 bpc;
|
2018-05-08 20:39:47 +10:00
|
|
|
} or;
|
|
|
|
|
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_crc_atom crc;
|
|
|
|
|
2019-02-01 19:20:04 -05:00
|
|
|
/* Currently only used for MST */
|
|
|
|
struct {
|
|
|
|
int pbn;
|
|
|
|
u8 tu:6;
|
|
|
|
} dp;
|
|
|
|
|
2018-05-08 20:39:47 +10:00
|
|
|
union nv50_head_atom_mask {
|
2018-05-08 20:39:47 +10:00
|
|
|
struct {
|
2018-05-08 20:39:47 +10:00
|
|
|
bool olut:1;
|
2018-05-08 20:39:47 +10:00
|
|
|
bool core:1;
|
|
|
|
bool curs:1;
|
|
|
|
bool view:1;
|
|
|
|
bool mode:1;
|
|
|
|
bool base:1;
|
|
|
|
bool ovly:1;
|
|
|
|
bool dither:1;
|
|
|
|
bool procamp:1;
|
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
|
|
|
bool crc:1;
|
2018-05-08 20:39:47 +10:00
|
|
|
bool or:1;
|
|
|
|
};
|
|
|
|
u16 mask;
|
2018-05-08 20:39:47 +10:00
|
|
|
} set, clr;
|
2018-05-08 20:39:47 +10:00
|
|
|
};
|
|
|
|
|
|
|
|
static inline struct nv50_head_atom *
|
|
|
|
nv50_head_atom_get(struct drm_atomic_state *state, struct drm_crtc *crtc)
|
|
|
|
{
|
|
|
|
struct drm_crtc_state *statec = drm_atomic_get_crtc_state(state, crtc);
|
|
|
|
if (IS_ERR(statec))
|
|
|
|
return (void *)statec;
|
|
|
|
return nv50_head_atom(statec);
|
|
|
|
}
|
|
|
|
|
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 struct drm_encoder *
|
|
|
|
nv50_head_atom_get_encoder(struct nv50_head_atom *atom)
|
|
|
|
{
|
|
|
|
struct drm_encoder *encoder = NULL;
|
|
|
|
|
|
|
|
/* We only ever have a single encoder */
|
|
|
|
drm_for_each_encoder_mask(encoder, atom->state.crtc->dev,
|
|
|
|
atom->state.encoder_mask)
|
|
|
|
break;
|
|
|
|
|
|
|
|
return encoder;
|
|
|
|
}
|
|
|
|
|
2018-05-08 20:39:47 +10:00
|
|
|
#define nv50_wndw_atom(p) container_of((p), struct nv50_wndw_atom, state)
|
|
|
|
|
|
|
|
struct nv50_wndw_atom {
|
|
|
|
struct drm_plane_state state;
|
|
|
|
|
2018-05-08 20:39:47 +10:00
|
|
|
struct drm_property_blob *ilut;
|
2018-05-08 20:39:47 +10:00
|
|
|
bool visible;
|
|
|
|
|
2018-05-08 20:39:47 +10:00
|
|
|
struct {
|
|
|
|
u32 handle;
|
|
|
|
u16 offset:12;
|
|
|
|
bool awaken:1;
|
|
|
|
} ntfy;
|
|
|
|
|
|
|
|
struct {
|
|
|
|
u32 handle;
|
|
|
|
u16 offset:12;
|
|
|
|
u32 acquire;
|
|
|
|
u32 release;
|
|
|
|
} sema;
|
|
|
|
|
|
|
|
struct {
|
2018-05-08 20:39:47 +10:00
|
|
|
u32 handle;
|
|
|
|
struct {
|
|
|
|
u64 offset:40;
|
|
|
|
u8 buffer:1;
|
|
|
|
u8 enable:2;
|
|
|
|
u8 mode:4;
|
2018-12-11 14:50:02 +10:00
|
|
|
u16 size:11;
|
2018-05-08 20:39:48 +10:00
|
|
|
u8 range:2;
|
|
|
|
u8 output_mode:2;
|
2018-12-11 14:50:02 +10:00
|
|
|
void (*load)(struct drm_color_lut *, int size,
|
|
|
|
void __iomem *);
|
2018-05-08 20:39:47 +10:00
|
|
|
} i;
|
|
|
|
} xlut;
|
2018-05-08 20:39:47 +10:00
|
|
|
|
2019-06-11 22:40:36 -04:00
|
|
|
struct {
|
|
|
|
u32 matrix[12];
|
|
|
|
bool valid;
|
|
|
|
} csc;
|
|
|
|
|
2018-05-08 20:39:47 +10:00
|
|
|
struct {
|
|
|
|
u8 mode:2;
|
|
|
|
u8 interval:4;
|
|
|
|
|
2018-05-08 20:39:47 +10:00
|
|
|
u8 colorspace:2;
|
2018-05-08 20:39:47 +10:00
|
|
|
u8 format;
|
|
|
|
u8 kind:7;
|
|
|
|
u8 layout:1;
|
2018-05-08 20:39:47 +10:00
|
|
|
u8 blockh:4;
|
|
|
|
u16 blocks[3];
|
2018-05-08 20:39:47 +10:00
|
|
|
u32 pitch[3];
|
2018-05-08 20:39:47 +10:00
|
|
|
u16 w;
|
|
|
|
u16 h;
|
|
|
|
|
2018-05-08 20:39:47 +10:00
|
|
|
u32 handle[6];
|
|
|
|
u64 offset[6];
|
2018-05-08 20:39:47 +10:00
|
|
|
} image;
|
|
|
|
|
2018-05-08 20:39:47 +10:00
|
|
|
struct {
|
|
|
|
u16 sx;
|
|
|
|
u16 sy;
|
|
|
|
u16 sw;
|
|
|
|
u16 sh;
|
|
|
|
u16 dw;
|
|
|
|
u16 dh;
|
|
|
|
} scale;
|
|
|
|
|
2018-05-08 20:39:47 +10:00
|
|
|
struct {
|
|
|
|
u16 x;
|
|
|
|
u16 y;
|
|
|
|
} point;
|
|
|
|
|
2019-06-11 16:46:13 +10:00
|
|
|
struct {
|
|
|
|
u8 depth;
|
2019-06-11 17:13:04 +10:00
|
|
|
u8 k1;
|
2019-06-12 17:37:23 +10:00
|
|
|
u8 src_color:4;
|
|
|
|
u8 dst_color:4;
|
2019-06-11 16:46:13 +10:00
|
|
|
} blend;
|
|
|
|
|
2018-05-08 20:39:47 +10:00
|
|
|
union nv50_wndw_atom_mask {
|
2018-05-08 20:39:47 +10:00
|
|
|
struct {
|
|
|
|
bool ntfy:1;
|
|
|
|
bool sema:1;
|
2018-05-08 20:39:47 +10:00
|
|
|
bool xlut:1;
|
2019-06-11 22:40:36 -04:00
|
|
|
bool csc:1;
|
2018-05-08 20:39:47 +10:00
|
|
|
bool image:1;
|
2018-05-08 20:39:47 +10:00
|
|
|
bool scale:1;
|
2018-05-08 20:39:47 +10:00
|
|
|
bool point:1;
|
2019-06-11 16:46:13 +10:00
|
|
|
bool blend:1;
|
2018-05-08 20:39:47 +10:00
|
|
|
};
|
|
|
|
u8 mask;
|
2018-05-08 20:39:47 +10:00
|
|
|
} set, clr;
|
2018-05-08 20:39:47 +10:00
|
|
|
};
|
|
|
|
#endif
|