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.murphy@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").
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 javierm@redhat.com