On 2022-06-14 14:26, Javier Martinez Canillas wrote:
Hello Robin,
On 6/14/22 15:04, Robin Murphy wrote:
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.
Signed-off-by: Robin Murphy <robin.mur...@arm.com>
---
drivers/gpu/drm/arm/hdlcd_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index af59077a5481..a5d04884658b 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -331,6 +331,8 @@ static int hdlcd_drm_bind(struct device *dev)
goto err_vblank;
}
+ drm_fb_helper_remove_conflicting_framebuffers(NULL, "hdlcd", false);
+
Seems you are using an older base, since this function doesn't exist anymore
after commit 603dc7ed917f ("drm/aperture: Inline fbdev conflict helpers into
aperture helpers").
Ah, you got me! I'm having to work with a 5.10 kernel at the moment, but
the randomly-disappearing console had finally sufficiently annoyed me
into figuring out and fixing it.
Instead, you should use the drm_aperture_remove_framebuffers() function, i.e:
+ drm_aperture_remove_framebuffers(false, &hdlcd_driver);
If you do that and re-spin the patch, feel free to add:
Reviewed-by: Javier Martinez Canillas <javi...@redhat.com>
Thanks for the advice and review - I'll send a v2 later once I've had
time to build and boot test 5.19-rc.
Cheers,
Robin.
