| Message ID | 20240517-virtio_gpu-v1-2-6353b87472c7@flygoat.com |
|---|---|
| State | Superseded |
| Delegated to: | Anatolij Gustschin |
| Headers | show |
| Series | virtio_gpu driver and relevant fix | expand |
Am 17. Mai 2024 01:03:25 MESZ schrieb Jiaxun Yang <jiaxun.yang@flygoat.com>: >If a video device has a video_sync hook, it means some software >intervene is required to scanout framebuffer up on change. > >That means EFI application can't just use it as raw framebuffer, >it should call BLT operation to let U-Boot help with scanout. > >Mark pixel format as BLTONLY as per UEFI spec to reflect this >nature. > >Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> >--- > include/efi_api.h | 1 + > lib/efi_loader/efi_gop.c | 9 ++++++++- > 2 files changed, 9 insertions(+), 1 deletion(-) > >diff --git a/include/efi_api.h b/include/efi_api.h >index ab40b1b5ddf6..3eaefb322878 100644 >--- a/include/efi_api.h >+++ b/include/efi_api.h >@@ -1399,6 +1399,7 @@ struct efi_hii_config_access_protocol { > #define EFI_GOT_RGBA8 0 > #define EFI_GOT_BGRA8 1 > #define EFI_GOT_BITMASK 2 >+#define EFI_GOT_BLTONLY 3 > > struct efi_gop_mode_info { > u32 version; >diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c >index 41e12fa72460..784d43d3d39b 100644 >--- a/lib/efi_loader/efi_gop.c >+++ b/lib/efi_loader/efi_gop.c >@@ -467,10 +467,12 @@ efi_status_t efi_gop_register(void) > struct efi_gop_obj *gopobj; > u32 bpix, format, col, row; > u64 fb_base, fb_size; >+ bool needs_sync; > efi_status_t ret; > struct udevice *vdev; > struct video_priv *priv; > struct video_uc_plat *plat; >+ struct video_ops *ops; > > /* We only support a single video output device for now */ > if (uclass_first_device_err(UCLASS_VIDEO, &vdev)) { >@@ -485,6 +487,7 @@ efi_status_t efi_gop_register(void) > row = video_get_ysize(vdev); > > plat = dev_get_uclass_plat(vdev); >+ ops = video_get_ops(vid); > fb_base = IS_ENABLED(CONFIG_VIDEO_COPY) ? plat->copy_base : plat->base; Wasn't this line introduced to handle the video sync case by pointing the EFI application to target framebuffer? Best regards Heinrich > fb_size = plat->size; > >@@ -529,7 +532,11 @@ efi_status_t efi_gop_register(void) > gopobj->info.version = 0; > gopobj->info.width = col; > gopobj->info.height = row; >- if (bpix == VIDEO_BPP32) >+ >+ if (ops && ops->video_sync) { >+ /* Applications can't really use it as framebuffer */ >+ gopobj->info.pixel_format = EFI_GOT_BLTONLY; >+ } else if (bpix == VIDEO_BPP32) > { > if (format == VIDEO_X2R10G10B10) { > gopobj->info.pixel_format = EFI_GOT_BITMASK; >
在2024年5月17日五月 上午2:44，Heinrich Schuchardt写道： [...] Hi Heinrich, >> >> plat = dev_get_uclass_plat(vdev); >>+ ops = video_get_ops(vid); >> fb_base = IS_ENABLED(CONFIG_VIDEO_COPY) ? plat->copy_base : plat->base; > > Wasn't this line introduced to handle the video sync case by pointing > the EFI application to target framebuffer? This is used to handle the case that U-Boot itself is performing a copy from U-Boot's shadow buffer to the target buffer. However, in virtio-gpu (and some other driver like syncoam,seps525, ste,mcde) cases hardware needs to be notified for any update to the framebuffer. For those hardwares if application just write to target framebuffer the display won't be updated. Hence we must direct applications to call BLT to allow hardware being notified when framebuffer is changed. Thanks > > Best regards > > Heinrich >
diff --git a/include/efi_api.h b/include/efi_api.h index ab40b1b5ddf6..3eaefb322878 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -1399,6 +1399,7 @@ struct efi_hii_config_access_protocol { #define EFI_GOT_RGBA8 0 #define EFI_GOT_BGRA8 1 #define EFI_GOT_BITMASK 2 +#define EFI_GOT_BLTONLY 3 struct efi_gop_mode_info { u32 version; diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c index 41e12fa72460..784d43d3d39b 100644 --- a/lib/efi_loader/efi_gop.c +++ b/lib/efi_loader/efi_gop.c @@ -467,10 +467,12 @@ efi_status_t efi_gop_register(void) struct efi_gop_obj *gopobj; u32 bpix, format, col, row; u64 fb_base, fb_size; + bool needs_sync; efi_status_t ret; struct udevice *vdev; struct video_priv *priv; struct video_uc_plat *plat; + struct video_ops *ops; /* We only support a single video output device for now */ if (uclass_first_device_err(UCLASS_VIDEO, &vdev)) { @@ -485,6 +487,7 @@ efi_status_t efi_gop_register(void) row = video_get_ysize(vdev); plat = dev_get_uclass_plat(vdev); + ops = video_get_ops(vid); fb_base = IS_ENABLED(CONFIG_VIDEO_COPY) ? plat->copy_base : plat->base; fb_size = plat->size; @@ -529,7 +532,11 @@ efi_status_t efi_gop_register(void) gopobj->info.version = 0; gopobj->info.width = col; gopobj->info.height = row; - if (bpix == VIDEO_BPP32) + + if (ops && ops->video_sync) { + /* Applications can't really use it as framebuffer */ + gopobj->info.pixel_format = EFI_GOT_BLTONLY; + } else if (bpix == VIDEO_BPP32) { if (format == VIDEO_X2R10G10B10) { gopobj->info.pixel_format = EFI_GOT_BITMASK;
If a video device has a video_sync hook, it means some software intervene is required to scanout framebuffer up on change. That means EFI application can't just use it as raw framebuffer, it should call BLT operation to let U-Boot help with scanout. Mark pixel format as BLTONLY as per UEFI spec to reflect this nature. Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> --- include/efi_api.h | 1 + lib/efi_loader/efi_gop.c | 9 ++++++++- 2 files changed, 9 insertions(+), 1 deletion(-)