Re: [RFC PATCH v4 02/11] drm/fb-helper: Set FBINFO_MISC_FIRMWARE flag for DRIVER_FIRMWARE fb

[Javier Martinez Canillas <javierm@redhat.com>]

Hello Thomas,

On 4/29/22 11:14, Thomas Zimmermann wrote:
> Hi
> 
> Am 29.04.22 um 10:42 schrieb Javier Martinez Canillas:
>> The DRIVER_FIRMWARE flag denotes that a DRM driver uses a framebuffer
>> that was initialized and provided by the system firmware for scanout.
>>
>> Indicate to the fbdev subsystem that the registered framebuffer is a
>> FBINFO_MISC_FIRMWARE, so that it can handle accordingly. For example,
>> wold hot-unplug the associated device if asked to remove conflicting
>> framebuffers.
>>
>> Suggested-by: Thomas Zimmermann <tzimmermann@suse.de>
>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>> ---
>>
>> (no changes since v1)
>>
>>   drivers/gpu/drm/drm_fb_helper.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
>> index d265a73313c9..76dd11888621 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -1891,6 +1891,10 @@ __drm_fb_helper_initial_config_and_unlock(struct drm_fb_helper *fb_helper,
>>   		/* don't leak any physical addresses to userspace */
>>   		info->flags |= FBINFO_HIDE_SMEM_START;
>>   
>> +	/* Indicate that the framebuffer is provided by the firmware */
>> +	if (drm_core_check_feature(dev, DRIVER_FIRMWARE))
>> +		info->flags |= FBINFO_MISC_FIRMWARE;
>> +
> 
> Patches 1 to 3 should be squashed into one before landing.
>

I actually considered this but then decided to go with the each change
goes into its own patch approach. But I'll squash it in next revisions.
 
> We can do this with DRIVER_FIRMWARE. Alternatively, I'd suggest to we 
> could also used the existing final parameter of 
> drm_fbdev_generic_setup() to pass a flag that designates a firmware device.
> 

By existing final parameter you mean @preferred_bpp ? That doesn't seem
correct. I also like that by using DRIVER_FIRMWARE it is completely data
driven and transparent to the DRM driver.

Or do you envision a case where a driver would be DRIVER_FIRMWARE but we
wouldn't want the emulated fbdev to also be FBINFO_MISC_FIRMWARE ?

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat