#
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
|
#
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
|
#
e78b1b54 |
|
10-Aug-2021 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50: workaround EFI GOP window channel format differences Should fix some initial modeset failures on (at least) Ampere boards. 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>
|
#
2f819f2b |
|
20-Jun-2020 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50-: convert core head_dither() to new push macros Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
|
#
db2a2069 |
|
20-Jun-2020 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50-: convert core head_ovly() to new push macros Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
|
#
93f7f054 |
|
20-Jun-2020 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50-: convert core head_base() to new push macros Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
|
#
bc5af56a |
|
20-Jun-2020 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50-: convert core head_curs_clr() to new push macros Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
|
#
9549c14b |
|
20-Jun-2020 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50-: convert core head_curs_set() to new push macros Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
|
#
aabe253e |
|
20-Jun-2020 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50-: convert core head_core_clr() to new push macros Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
|
#
a38870a2 |
|
20-Jun-2020 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50-: convert core head_core_set() 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>
|
#
1f772f5a |
|
20-Jun-2020 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50-: convert core head_view() to new push macros Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@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
|
#
5ff0cb1c |
|
13-Sep-2019 |
Lyude Paul <lyude@redhat.com> |
drm/nouveau/kms/nv50-: Use less encoders by making mstos per-head Currently, for every single MST capable DRM connector we create a set of fake encoders, one for each possible head. Unfortunately this ends up being a huge waste of encoders. While this currently isn't causing us any problems, it's extremely close to doing so. The ThinkPad P71 is a good example of this. Originally when trying to figure out why nouveau was failing to load on this laptop, I discovered it was because nouveau was creating too many encoders. This ended up being because we were mistakenly creating MST encoders for the eDP port, however we are still extremely close to hitting the encoder limit on this machine as it exposes 1 eDP port and 5 DP ports, resulting in 31 encoders. So while this fix didn't end up being necessary to fix the P71, we still need to implement this so that we avoid hitting the encoder limit for valid display configurations in the event that some machine with more connectors then this becomes available. Plus, we don't want to let good code go to waste :) So, use less encoders by only creating one MSTO per head. Then, attach each new MSTC to each MSTO which corresponds to a head that it's parent DP port is capable of using. This brings the number of encoders we register on the ThinkPad P71 from 31, down to just 15. Yay! 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>
|
#
cb55cd0c |
|
10-Dec-2018 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50-: allow more flexibility with lut formats Will be required for Turing. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
facaed62 |
|
08-May-2018 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/gv100: initial support Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
01d380ab |
|
08-May-2018 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/gk104-: support additional cursor sizes Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
119608a7 |
|
08-May-2018 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50-: handle degamma LUT from window channels Required to eventually support DRM colour management APIs, and to support Volta. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
09e1b78a |
|
08-May-2018 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50-: split core implementation by hardware class Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
1590700d |
|
08-May-2018 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50-: split each resource type into their own source files There should be no code changes here, just shuffling stuff around. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|