| Message ID | 1463529864-31027-1-git-send-email-agraf@suse.de |
|---|---|
| State | Accepted |
| Delegated to: | Tom Rini |
| Headers | show |
On Wed, May 18, 2016 at 02:04:24AM +0200, Alexander Graf wrote: > Recently Linux is gaining support for efifb on AArch64 and that support actually > tries to make use of the frame buffer address we expose to it via gop. > > While this wouldn't be bad in theory, in practice it means a few bad things > > 1) We expose 16bit frame buffers as 32bit today > 2) Linux can't deal with overlapping non-PCI regions between efifb and > a different frame buffer driver > > For now, let's just disable exposure of the frame buffer address. Most OSs that > get booted will have a native driver for the GPU anyway. > > Signed-off-by: Alexander Graf <agraf@suse.de> Applied to u-boot/master, thanks!
diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c index bdd62bc..6c3115c 100644 --- a/lib/efi_loader/efi_gop.c +++ b/lib/efi_loader/efi_gop.c @@ -136,8 +136,6 @@ int efi_gop_register(void) gopobj->mode.max_mode = 1; gopobj->mode.info = &gopobj->info; gopobj->mode.info_size = sizeof(gopobj->info); - gopobj->mode.fb_base = gd->fb_base; - gopobj->mode.fb_size = lcd_get_size(&line_len); gopobj->info.version = 0; gopobj->info.width = panel_info.vl_col;
Recently Linux is gaining support for efifb on AArch64 and that support actually tries to make use of the frame buffer address we expose to it via gop. While this wouldn't be bad in theory, in practice it means a few bad things 1) We expose 16bit frame buffers as 32bit today 2) Linux can't deal with overlapping non-PCI regions between efifb and a different frame buffer driver For now, let's just disable exposure of the frame buffer address. Most OSs that get booted will have a native driver for the GPU anyway. Signed-off-by: Alexander Graf <agraf@suse.de> --- lib/efi_loader/efi_gop.c | 2 -- 1 file changed, 2 deletions(-)