[PATCH] drm/Makefile: Move tiny drivers before native drivers

Javier Martinez Canillas javierm at redhat.com
Mon Dec 11 09:16:55 UTC 2023


Huacai Chen <chenhuacai at kernel.org> writes:

> Hi, Javier,
>
> On Mon, Dec 11, 2023 at 4:33 PM Javier Martinez Canillas
> <javierm at redhat.com> wrote:
>>
>> Huacai Chen <chenhuacai at kernel.org> writes:
>>
>> Hello Huacai,
>>
>> > Hi, Javier,
>> >
>> > On Wed, Nov 8, 2023 at 4:24 PM Javier Martinez Canillas
>> > <javierm at redhat.com> wrote:
>> >>
>> >> Hello,
>> >>
>> >> On Wed, Nov 8, 2023 at 9:14 AM Thomas Zimmermann <tzimmermann at suse.de> 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.

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat



More information about the dri-devel mailing list