Re: [PATCH V11 09/22] LoongArch: Add boot and setup routines

[Huacai Chen <chenhuacai@gmail.com>]

Hi, Javier,

On Fri, May 20, 2022 at 10:23 PM Javier Martinez Canillas
<javierm@redhat.com> 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
>