Hi Am 14.06.22 um 15:04 schrieb Robin Murphy:
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@xxxxxxx> --- 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);+
In addition to what Javier said, it appears to be too late to call this function. If anything her etouches hardware, you might accidentally interfere with the EFI-related driver. Rather call it at the top of ldlcd_drm_bind().
Best regards Thomas
drm_mode_config_reset(drm); drm_kms_helper_poll_init(drm);
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
