diff options
| author | Lyude Paul <lyude@redhat.com> | 2026-08-14 15:43:49 -0400 |
|---|---|---|
| committer | Lyude Paul <lyude@redhat.com> | 2026-09-11 13:25:47 -0400 |
| commit | 12f6eff11ccf9cad3b2dfcdd94184fdb9ffface2 (patch) | |
| tree | d45d86859f88c1dccc60ac291d1c39636cc2ee74 /tools/perf/scripts/python/bin/stackcollapse-record | |
| parent | a5c41fa7f925fda2db394329fa0b26243fa63a81 (diff) | |
| download | linux-next-12f6eff11ccf9cad3b2dfcdd94184fdb9ffface2.tar.gz linux-next-12f6eff11ccf9cad3b2dfcdd94184fdb9ffface2.zip | |
drm/nouveau/gsp/r570: Set GcOff = 0 in fbsr
Previously, it looked as if we were able to fix suspend/resume on some
desktops by setting Gcoff based on whether or not we were entering runtime
PM. This was a mistake though - the only time suspend/resume would end up
actually working was if Gcoff = 0.
It seems like it's likely the main reason for this is the FBSR GcOff
argument actually controls GSP's behavior with regards to which buffers it
decides to save across suspend/resume. When GcOff = 1, RM reserved regions
are saved unless they are marked as LOST_ON_SUSPEND, and RM channel-context
and kernel-client buffers are also saved -including- when they are
LOST_ON_SUSPEND. This means with GcOff = 1, we end up having GSP save and
restore buffers that actually need to be reinitialized on resume - causing
the failures we're setting.
Thanks to John Hubbard from Nvidia for providing some background on what
these options do in the GSP firmware do!
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 53dac0623853 ("drm/nouveau/gsp: add support for 570.144")
Cc: <stable@vger.kernel.org> # v6.16+
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260814194542.781955-3-lyude@redhat.com
(cherry picked from commit c7abe771e013848970421e5ca29c6b2f05c31965)
Signed-off-by: Lyude Paul <lyude@redhat.com>
Diffstat (limited to 'tools/perf/scripts/python/bin/stackcollapse-record')
0 files changed, 0 insertions, 0 deletions
