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