In the atomic update callback, ast should call drm_gem_fb_begin_cpu_access() to make sure it can read the framebuffer from the CPU, otherwise the data might not be there due to cache, and synchronization.
Tested on a Lenovo SE100, while rendering on the ArrowLake GPU with i915 driver, and using ast for display. Suggested-by: Thomas Zimmermann <[email protected]> Signed-off-by: Jocelyn Falempe <[email protected]> --- drivers/gpu/drm/ast/ast_mode.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c index 9ce874dba69c..68da4544d92d 100644 --- a/drivers/gpu/drm/ast/ast_mode.c +++ b/drivers/gpu/drm/ast/ast_mode.c @@ -556,11 +556,17 @@ static void ast_primary_plane_helper_atomic_update(struct drm_plane *plane, ast_set_vbios_color_reg(ast, fb->format, ast_crtc_state->vmode); } + /* if the buffer comes from another device */ + if (!drm_gem_fb_begin_cpu_access(fb, DMA_FROM_DEVICE)) + return; + drm_atomic_helper_damage_iter_init(&iter, old_plane_state, plane_state); drm_atomic_for_each_plane_damage(&iter, &damage) { ast_handle_damage(ast_plane, shadow_plane_state->data, fb, &damage); } + drm_gem_fb_end_cpu_access(fb, DMA_FROM_DEVICE); + /* * Some BMCs stop scanning out the video signal after the driver * reprogrammed the offset. This stalls display output for several base-commit: 4f9ffd2c80a2fa09dcc8dfa0482cb7e0fb6fcf6c -- 2.51.0
