Hi, Javier, On Mon, Dec 11, 2023 at 5:17 PM Javier Martinez Canillas <javierm@xxxxxxxxxx> wrote: > > Huacai Chen <chenhuacai@xxxxxxxxxx> writes: > > > Hi, Javier, > > > > On Mon, Dec 11, 2023 at 4:33 PM Javier Martinez Canillas > > <javierm@xxxxxxxxxx> wrote: > >> > >> Huacai Chen <chenhuacai@xxxxxxxxxx> writes: > >> > >> Hello Huacai, > >> > >> > Hi, Javier, > >> > > >> > On Wed, Nov 8, 2023 at 4:24 PM Javier Martinez Canillas > >> > <javierm@xxxxxxxxxx> wrote: > >> >> > >> >> Hello, > >> >> > >> >> On Wed, Nov 8, 2023 at 9:14 AM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: > >> >> > > >> >> > Hi, > >> >> > > >> >> > >> >> [...] > >> >> > >> >> > > >> >> > Relying on linking order is just as unreliable. The usual workaround is > >> >> > to build native drivers as modules. But first, please investigate where > >> >> > the current code fails. > >> >> > > >> >> > >> >> I fully agree with Thomas here. This is just papering over the issue. > >> >> > >> >> I'll read the lengthy thread now to see if I can better understand > >> >> what's going on here. > >> > Have you understood enough now? I really don't want the original patch > >> > to be reverted. > >> > > >> > >> I discussed this with Thomas but we didn't fully understand what was going > >> on. In theory, it should work since the native driver should disable sysfb > >> and remove the registered platform device. But it seems that this does not > >> happen for Jaak and others who reported the same issue. > >> > >> Something that we noticed is that PCI fixups happen in fs_initcall_sync() > >> and since the sysfb_init() should happen after the PCI subsystem for EFI > >> quirks, we think that at least should be moved after that initcall level. > >> > >> That means rootfs_initcall() onwards, and that takes it almost at the same > >> before your patch. The safest would be to move sysfb_init() to initcall > >> device_initcall_sync() and make sure that happens after all the native DRM > >> drivers, since module_init() happens at device_initcall(). > >> > >> I think that Thomas meant to send a patch to do that change. > > Thank you very much. I guess things may be like this: > > i915 init at first, then simpledrm init in parallel and finished > > before i915 call sysfb_disable(), so in my previous reply I provide a > > debug patch for Jaak to see what happens. > > > > Yes, specially with async probing although neither i915 nor simpledrm use > it right now AFAICT. > > Is still unclear to me what's going on in this particular case, although > moving it to device_initcall_sync() seems to be the correct thing to do > regardless of this issue. But that cannot "make the screen display as early as possible". Maybe we can wait for Jaak's result. Huacai > > -- > Best regards, > > Javier Martinez Canillas > Core Platforms > Red Hat >
