diff options
author | Lyude Paul <lyude@redhat.com> | 2020-06-29 18:36:25 -0400 |
---|---|---|
committer | Lyude Paul <lyude@redhat.com> | 2020-07-16 18:16:33 -0400 |
commit | 2d7865082dd0cff5777bf9c1f075d54f737cc2e3 (patch) | |
tree | e74639b40d23c16e975b8bcbcf2d4e97c8b64486 /drivers/gpu/drm/drm_context.c | |
parent | 12885ecbfe62df4358d452080d3b8feef54ec8cb (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