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


Reply via email to