Hi, Javier,
On Fri, May 20, 2022 at 10:23 PM Javier Martinez Canillas
<[email protected]> wrote:
>
> Hello Huacai,
>
> On 5/20/22 16:09, Huacai Chen wrote:
>
> [snip]
>
> >>
> >> In summary, just enable the following to use the firmware framebuffer:
> >>
> >> CONFIG_DRM_SIMPLEDRM=y
> >> CONFIG_DRM_FBDEV_EMULATION=y
> >> CONFIG_SYSFB=y
> >> CONFIG_SYSFB_SIMPLEFB=y
> > Thank you very much, since 5.15 sysfb_init() do all things of
> > register_gop_device(), so register_gop_device() here can be removed.
>
> Correct.
>
> > But there is another small problem: if simpledrm or efifb driver is
> > built-in, there is no display. The reason is both sysfb_init() and
> > display driver are in the same initcall level (device_initcall()).
> > From the comments I know that sysfb_init() should after PCI
> > enumeration which is in subsys_initcall(), so, could we make
> > sysfb_init() to be a subsys_initcall_sync()?
> >
>
> I don't understand why we would need that... it shouldn't matter the order
> in which the driver's init and sysfb_init() are done. If the driver's init
> is executed first, then the driver will be registered and later when the
> sysfb_init() registers the device, it will match the driver and probe.
>
> Conversely, if the sysfb_init() is executed first then the platform device
> will be registered and latter when the driver's init register the driver
> this will match the already registered device.
Yes, you are right, my consideration is too complex. The only real
problem is a harmless error "efifb: a framebuffer is already
registered" when both efifb and the native display driver are
built-in.
Huacai
>
> In other words, it will be handled by the Linux device model and we should
> not attempt to hand pick the initcall level for each. That's quite fragile.
>
> Or am I missing something here ?
>
> --
> Best regards,
>
> Javier Martinez Canillas
> Linux Engineering
> Red Hat
>
On 5/20/22 17:19, Huacai Chen wrote:
> Hi, Javier,
[snip]
>> Conversely, if the sysfb_init() is executed first then the platform device
>> will be registered and latter when the driver's init register the driver
>> this will match the already registered device.
> Yes, you are right, my consideration is too complex. The only real
> problem is a harmless error "efifb: a framebuffer is already
> registered" when both efifb and the native display driver are
> built-in.
>
But this shouldn't be a problem if you drop your register_gop_device() that
registers an "efi-framebuffer", since sysfb would either register a platform
device "simple-framebufer" or "efi-framebuffer", but never both. Those are
mutually exclusive.
I think what's happening now is that sysfb is registering a "simple-framebuffer"
but your register_gop_device() function is also registering an "efi-framebuffer".
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat