@@ -147,6 +147,8 @@ void video_set_default_colors(struct udevice *dev, bool invert)
/* Flush video activity to the caches */
void video_sync(struct udevice *vid, bool force)
{
+ int ret;
+ struct video_ops *ops = video_get_ops(vid);
/*
* flush_dcache_range() is declared in common.h but it seems that some
* architectures do not actually implement it. Is there a way to find
@@ -169,6 +171,18 @@ void video_sync(struct udevice *vid, bool force)
last_sync = get_timer(0);
}
#endif
+ /*
+ * Some devices have their own framebuffer memory that is not
+ * shared directly with the CPU. For said devices, we need to
+ * copy U-boot's framebuffer (priv->fb) to the device's own
+ * framebuffer memory. E.g., via SPI.
+ */
+ if (ops->copy_fb_to_hw) {
+ ret = ops->copy_fb_to_hw(vid);
+ if (ret) {
+ dev_err(vid, "Could not copy frame buffer to hardware: %d\n", ret);
+ }
+ }
}
void video_sync_all(void)
@@ -96,8 +96,14 @@ struct video_priv {
u8 bg_col_idx;
};
-/* Placeholder - there are no video operations at present */
struct video_ops {
+ /**
+ * copy_fb_to_hw() - Copy the current frame buffer to the hardware
+ *
+ * @dev: Video device
+ * @return 0 if OK, -ve on error
+ */
+ int (*copy_fb_to_hw)(struct udevice *dev);
};
#define video_get_ops(dev) ((struct video_ops *)(dev)->driver->ops)
Some devices have their own framebuffer memory that is not shared directly with the CPU. For said devices, we need to copy U-boot's framebuffer (priv->fb) to the device's own framebuffer memory. E.g., via SPI. To support these devices, I've added the copy_fb_to_hw op. It's optional, so existing drivers do not need to define this op. I've used this new op to add support for the SSD2119 display panel driver over 4-wire SPI. I'll add this video driver in a subsequent patch. Signed-off-by: Frederik Aalund <fpa@sbtinstruments.com> Cc: agust@denx.de --- drivers/video/video-uclass.c | 14 ++++++++++++++ include/video.h | 8 +++++++- 2 files changed, 21 insertions(+), 1 deletion(-)