summaryrefslogtreecommitdiff
path: root/Documentation/gpu
diff options
context:
space:
mode:
authorAndré Almeida <andrealmeid@igalia.com>2022-07-14 22:17:44 +0300
committerAlex Deucher <alexander.deucher@amd.com>2022-07-25 16:31:02 +0300
commit4686177f7d2140cdd9d031702c2b53ac4c89340a (patch)
tree2577aeeec13a03140ddea279c7fe34269d6914fd /Documentation/gpu
parentfbcc38811fcb47335899a3776b4fd5670db4e228 (diff)
downloadlinux-4686177f7d2140cdd9d031702c2b53ac4c89340a.tar.xz
drm/amd/debugfs: Expose GFXOFF state to userspace
GFXOFF has two different "state" values: one to define if the GPU is allowed/disallowed to enter GFXOFF, usually called state; and another one to define if currently GFXOFF is being used, usually called status. Even when GFXOFF is allowed, GPU firmware can decide to not used it accordingly to the GPU load. Userspace can allow/disallow GPUs to enter into GFXOFF via debugfs. The kernel maintains a counter of requests for GFXOFF (gfx_off_req_count) that should be decreased to allow GFXOFF and increased to disallow. The issue with this interface is that userspace can't be sure if GFXOFF is currently allowed. Even by checking amdgpu_gfxoff file, one might get an ambiguous 2, that means that GPU is currently out of GFXOFF, but that can be either because it's currently disallowed or because it's allowed but given the current GPU load it's enabled. Then, userspace needs to rely on the fact that GFXOFF is enabled by default on boot and to track this information. To make userspace life easier and GFXOFF more reliable, return the current state of GFXOFF to userspace when reading amdgpu_gfxoff with the same semantics of writing: 0 means not allowed, not 0 means allowed. Expose the current status of GFXOFF through a new file, amdgpu_gfxoff_status. Signed-off-by: André Almeida <andrealmeid@igalia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Diffstat (limited to 'Documentation/gpu')
0 files changed, 0 insertions, 0 deletions