summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/bin/stackcollapse-record
diff options
context:
space:
mode:
authorLyude Paul <lyude@redhat.com>2026-08-14 15:43:49 -0400
committerLyude Paul <lyude@redhat.com>2026-09-11 13:25:47 -0400
commit12f6eff11ccf9cad3b2dfcdd94184fdb9ffface2 (patch)
treed45d86859f88c1dccc60ac291d1c39636cc2ee74 /tools/perf/scripts/python/bin/stackcollapse-record
parenta5c41fa7f925fda2db394329fa0b26243fa63a81 (diff)
downloadlinux-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