On 30.12.22 22:12, Heinrich Schuchardt wrote:
On 12/30/22 20:58, Alexander Graf wrote:
Now that we have a damage area tells us which parts of the frame buffer
actually need updating, let's only dcache flush those on video_sync()
calls. With this optimization in place, frame buffer updates -
especially
on large screen such as 4k displays - speed up significantly.
Signed-off-by: Alexander Graf <ag...@csgraf.de>
Reported-by: Da Xue <da@libre.computer>
---
v1 -> v2:
- Fix dcache range; we were flushing too much before
- Remove ifdefs
---
drivers/video/video-uclass.c | 51 ++++++++++++++++++++++++++++++------
1 file changed, 43 insertions(+), 8 deletions(-)
diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index f1fbeaadcb..bf93f524c7 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -297,9 +297,45 @@ int video_damage(struct udevice *vid, int x, int
y, int width, int height)
return 0;
}
+#if defined(CONFIG_ARM) && !CONFIG_IS_ENABLED(SYS_DCACHE_OFF)
ARM isn't the only architecture implementing flush_dcache_range().
So this condition needs to be fixed as well as the one in video_sync.
Why don't you simply rely on priv->flash_dcache irrespective of the
architecture? Let the video drivers decide if they need it.
This is code that already was #ifdef'ed before. The way I understand its
history, we couldn't decisively ensure that flush_dcache_range() exists,
so we couldn't build the code always.
I agree that it looks weird and error prone though. I believe you're
trying to say we should just make sure there's always a
flush_dcache_range() function and keep the rest to the compiler?
Alex
