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@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);
> +
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@xxxxxxxxxx>
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
