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

Javier Martinez Canillas javierm at redhat.com
Mon Dec 11 08:33:11 UTC 2023


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.

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat



More information about the dri-devel mailing list