[PATCH] drm/arm/hdlcd: Take over EFI framebuffer properly

[Robin Murphy]

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.murphy at 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 <javierm at 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.