summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/drm_context.c
diff options
context:
space:
mode:
authorLyude Paul <lyude@redhat.com>2020-06-29 18:36:25 -0400
committerLyude Paul <lyude@redhat.com>2020-07-16 18:16:33 -0400
commit2d7865082dd0cff5777bf9c1f075d54f737cc2e3 (patch)
treee74639b40d23c16e975b8bcbcf2d4e97c8b64486 /drivers/gpu/drm/drm_context.c
parent12885ecbfe62df4358d452080d3b8feef54ec8cb (diff)
drm/nouveau/kms/nvd9-: Fix disabling CRCs alongside OR reprogramming
While I had thought I'd tested this before, it looks like this one issue slipped by my original CRC patches. Basically, there seem to be a few rules we need to follow when sending CRC commands to the display controller: * CRCs cannot be both disabled and enabled for a single head in the same flush * If a head with CRC reporting enabled switches from one OR to another, there must be a flush before the OR is re-enabled regardless of the final state of CRC reporting. So, split nv50_crc_atomic_prepare_notifier_contexts() into two functions: * nv_crc_atomic_release_notifier_contexts() - checks whether the CRC notifier contexts were released successfully after the first flush * nv_crc_atomic_init_notifier_contexts() - prepares any CRC notifier contexts for use before enabling reporting Additionally, in order to force a flush when we re-assign ORs with heads that have CRCs enabled we split our atomic check function into two: * nv50_crc_atomic_check_head() - called from our heads' atomic checks, determines whether a state needs to set or clear CRC reporting * nv50_crc_atomic_check_outp() - called at the end of the atomic check after all ORs have been added to the atomic state, and sets nv50_atom->flush_disable if needed Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <skeggsb@gmail.com> Acked-by: Dave Airlie <airlied@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200629223635.103804-1-lyude@redhat.com
Diffstat (limited to 'drivers/gpu/drm/drm_context.c')
0 files changed, 0 insertions, 0 deletions