On 28/10/2025 15:42, Jocelyn Falempe wrote:
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.
I sent this patch a bit too fast, my mistake below:>
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;
+
Sorry, there is a typo here, it should be:
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
