Like the helpers, nothing special. Well except not, because we the critical section extends until after hw_done(), since that's the last thing which could hold up a subsequent atomic commit. That means the wait_for_flip_done is included, but that's not a problem, we're allowed to call dma_fence_wait() from signalling critical sections. Even on our own fence (which this does), it's just a bit confusing. But in a way those last 2 function calls are already part of the fence signalling critical section for the next atomic commit.
Reading this I'm wondering why komeda waits for flip_done() before calling hw_done(), which is a bit backwards (but hey hw can be special). Might be good to throw a comment in there that explains why, because the original commit that added this just doesn't.
v2: Small rebase
Reviewed-by: James Qian Wang james.qian.wang@arm.com (v1) Cc: "James (Qian) Wang" james.qian.wang@arm.com Cc: Liviu Dudau liviu.dudau@arm.com Cc: Mihail Atanassov mihail.atanassov@arm.com Signed-off-by: Daniel Vetter daniel.vetter@intel.com --- drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c index 034ee08482e0..aeda4e5ec4f4 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c @@ -73,6 +73,7 @@ static const struct drm_driver komeda_kms_driver = { static void komeda_kms_commit_tail(struct drm_atomic_state *old_state) { struct drm_device *dev = old_state->dev; + bool fence_cookie = dma_fence_begin_signalling();
drm_atomic_helper_commit_modeset_disables(dev, old_state);
@@ -85,6 +86,8 @@ static void komeda_kms_commit_tail(struct drm_atomic_state *old_state)
drm_atomic_helper_wait_for_flip_done(dev, old_state);
+ dma_fence_end_signalling(fence_cookie); + drm_atomic_helper_cleanup_planes(dev, old_state); }