]> git.baikalelectronics.ru Git - kernel.git/commit
drm/arm/hdlcd: Take over EFI framebuffer properly
authorRobin Murphy <robin.murphy@arm.com>
Wed, 15 Jun 2022 16:09:15 +0000 (17:09 +0100)
committerLiviu Dudau <liviu.dudau@arm.com>
Fri, 22 Jul 2022 12:04:13 +0000 (13:04 +0100)
commite8b8174fa8f07baa6d839ca4408682ea47a101ec
tree64ddef0c8abfc4b5a435e75318bbcf284130b395
parent5d3027916677e4b8de95702296d15bfc50f33c79
drm/arm/hdlcd: Take over EFI framebuffer properly

The Arm Juno board EDK2 port has provided an EFI GOP display via HDLCD0
for some time now, which works nicely as an early framebuffer. However,
once the HDLCD driver probes and takes over the hardware, it should
take over the logical framebuffer as well, otherwise the now-defunct GOP
device hangs about and virtual console output inevitably disappears into
the wrong place most of the time.

We'll do this after binding the HDMI encoder, since that's the most
likely thing to fail, and the EFI console is still better than nothing
when that happens. However, the two HDLCD controllers on Juno are
independent, and many users will still be using older firmware without
any display support, so we'll only bother if we find that the HDLCD
we're probing is already enabled. And if it is, then we'll also stop it,
since otherwise the display can end up shifted if it's still scanning
out while the rest of the registers are subsequently reconfigured.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/31acd57f4aa8a4d02877026fa3a8c8d035e15a0d.1655309004.git.robin.murphy@arm.com
drivers/gpu/drm/arm/hdlcd_drv.c