#
1958d69f |
|
19-Sep-2023 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/disp: add dp mst id get/put methods - preparation for GSP-RM Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Danilo Krummrich <me@dakr.org> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919220442.202488-36-lyude@redhat.com
|
#
f9325afc |
|
03-Mar-2021 |
Lee Jones <lee.jones@linaro.org> |
drm/nouveau/dispnv50/headc57d: Make local function 'headc57d_olut' static Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/dispnv50/headc57d.c:173:1: warning: no previous prototype for ‘headc57d_olut’ [-Wmissing-prototypes] Cc: Ben Skeggs <bskeggs@redhat.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Reviewed-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
|
#
79af598a |
|
17-Mar-2021 |
Lyude Paul <lyude@redhat.com> |
drm/nouveau/kms/nv50-: Always validate LUTs in nv50_head_atomic_check_lut() When it comes to gamma or degamma luts, nouveau will actually skip the calculation of certain LUTs depending on the head and plane states. For instance, when the head is disabled we don't perform any error checking on the gamma LUT, and likewise if no planes are present and enabled in our atomic state we will skip error checking the degamma LUT. This is a bit of a problem though, since the per-head gamma and degamma props in DRM can be changed even while a head is disabled - a situation which can be triggered by the igt testcase mentioned down below. Originally I thought this was a bit silly and was tempted to just fix the igt test to only set gamma/degamma with the head enabled. After a bit of thinking though I realized we should fix this in nouveau. This is because if a program decides to set an invalid LUT for a head before enabling the head, such a property change would succeed while also making it impossible to turn the head back on until the LUT is removed or corrected - something that could be painful for a user to figure out. So, fix this checking both degamma and gamma LUTs unconditionally during atomic checks. We start by calling nv50_head_atomic_check_lut() regardless of whether the head is active or not in nv50_head_atomic_check(). Then we move the ilut error checking into nv50_head_atomic_check_lut() and add a per-head hook for it, primarily because as a per-CRTC property DRM we want the LUT to be error checked by the head any time it's included in an atomic state. Of course though, actual programming of the degamma lut to hardware is still handled in each plane's atomic check and commit. Signed-off-by: Lyude Paul <lyude@redhat.com> Testcase: igt/kms_color/pipe-invalid-*-lut-sizes 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
|
#
c854bf94 |
|
20-Jun-2020 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50-: use NVIDIA's headers for core head_or() Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
|
#
29ace860 |
|
20-Jun-2020 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50-: use NVIDIA's headers for core head_procamp() Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
|
#
a66a096d |
|
20-Jun-2020 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50-: use NVIDIA's headers for core head_olut_clr() Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
|
#
a41ef363 |
|
20-Jun-2020 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50-: use NVIDIA's headers for core head_olut_set() Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
|
#
c4c75188 |
|
20-Jun-2020 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50-: use NVIDIA's headers for core head_mode() Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
|
#
ff37116e |
|
20-Jun-2020 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50-: convert core head_or() to new push macros Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
|
#
246db5fd |
|
20-Jun-2020 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50-: convert core head_procamp() to new push macros Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
|
#
4fbf03a3 |
|
20-Jun-2020 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50-: convert core head_olut_clr() to new push macros Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
|
#
a5df7630 |
|
20-Jun-2020 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50-: convert core head_olut_set() to new push macros Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
|
#
caa966a7 |
|
20-Jun-2020 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50-: convert core head_mode() to new push macros Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
|
#
188e905c |
|
23-Jul-2020 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/tu102: set NVC57D_HEAD_SET_HEAD_USAGE_BOUNDS_UPSCALING_ALLOWED to TRUE Fixes issues when switching between scaling modes. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
12885ecb |
|
07-Oct-2019 |
Lyude Paul <lyude@redhat.com> |
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
|
#
dbdaf719 |
|
06-Feb-2020 |
Lyude Paul <lyude@redhat.com> |
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
|
#
9c8e9b79 |
|
13-Dec-2019 |
Lyude Paul <lyude@redhat.com> |
drm/nouveau/kms/nv140-: Don't modify depth in state during atomic commit Currently, we modify the depth value stored in the atomic state when performing a commit in order to workaround the fact we haven't implemented support for depths higher then 10 yet. This isn't idempotent though, as it will happen every atomic commit where we modify the OR state even if the head's depth in the atomic state hasn't been modified. Normally this wouldn't matter, since we don't modify OR state outside of modesets, but since the CRC capture region is implemented as part of the OR state in hardware we'll want to make sure all commits modifying OR state are idempotent so as to avoid changing the depth unexpectedly. So, fix this by simply not writing the reduced depth value we come up with to the atomic state. 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-5-lyude@redhat.com
|
#
af620cf0 |
|
11-May-2020 |
Lyude Paul <lyude@redhat.com> |
drm/nouveau/kms/gv100-: Add support for interlaced modes We advertise being able to set interlaced modes, so let's actually make sure to do that. Otherwise, we'll end up hanging the display engine due to trying to set a mode with timings adjusted for interlacing without telling the hardware it's actually an interlaced mode. Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
13199270 |
|
05-Sep-2019 |
Ilia Mirkin <imirkin@alum.mit.edu> |
drm/nouveau/kms/gf119-: allow both 256- and 1024-sized LUTs to be used The hardware supports either size. Also add checks to ensure that only these two sizes may be used for supplying a LUT. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
563737c5 |
|
10-Dec-2018 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/tu104: initial support Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|