https://bugs.freedesktop.org/show_bug.cgi?id=107168
Bug ID: 107168 Summary: Allow to load firmware during run-time (after initialization) Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel@lists.freedesktop.org Reporter: pmenzel+bugs.freedesktop@molgen.mpg.de
Building the radeon driver into the Linux kernel, that means not as a module, *without* an initrd image, the firmware is not loaded.
The firmware is present on the filesystem in `/lib/firmware/`, but it has not been mounted yet.
The firmware can be added using `EXTRA_FIRMWARE`, but that makes it difficult if the Linux kernel should be shared between different systems using different hardware generations.
(The best solution would be to not require firmware at all.)
It’d be great if the driver supported to load firmware after the initialization phase.
https://bugs.freedesktop.org/show_bug.cgi?id=107168
Alex Deucher alexdeucher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX
--- Comment #1 from Alex Deucher alexdeucher@gmail.com --- You need the firmware for initialization. Even if the firmware were open source, it would still needs to be loaded so you'd still need firmware images.
https://bugs.freedesktop.org/show_bug.cgi?id=107168
--- Comment #2 from Paul Menzel pmenzel+bugs.freedesktop@molgen.mpg.de --- (In reply to Alex Deucher from comment #1)
You need the firmware for initialization.
What’s the technical reason for this. Why can’t certain parts of the hardware be initialized later on?
Even if the firmware were open source, it would still needs to be loaded so you'd still need firmware images.
Understood.
https://bugs.freedesktop.org/show_bug.cgi?id=107168
--- Comment #3 from Alex Deucher alexdeucher@gmail.com --- (In reply to Paul Menzel from comment #2)
(In reply to Alex Deucher from comment #1)
You need the firmware for initialization.
What’s the technical reason for this. Why can’t certain parts of the hardware be initialized later on?
You can't do anything other than very limited modesetting until the firmwares are loaded. You might as well just use the efifb driver and then load the driver later after the filesystem is available. There's not really anything you can initialize without firmware. MC and SMC firmware are required to adjust the clocks which is required for performance and for bandwidth requirements for high res display configurations. You can't use the SDMA hardware without firmware so that means no GPU memory management or GPU VM updates and you are limited to 256 MB of vram (PCI BAR size) on most platforms. You can't use the gfx/compute engines without the CP firmware. You can't use the multi-media engines without firmware. Etc. Not to mention you now have multiple code paths to validate at the hw and sw level.
https://bugs.freedesktop.org/show_bug.cgi?id=107168
--- Comment #4 from Paul Menzel pmenzel+bugs.freedesktop@molgen.mpg.de --- (In reply to Alex Deucher from comment #3)
(In reply to Paul Menzel from comment #2)
(In reply to Alex Deucher from comment #1)
You need the firmware for initialization.
What’s the technical reason for this. Why can’t certain parts of the hardware be initialized later on?
You can't do anything other than very limited modesetting until the firmwares are loaded.
That would be enough for me for entering the LUKS password.
You might as well just use the efifb driver and then load the driver later after the filesystem is available.
There are several problems with that.
1. No UEFI based firmware is used, but a coreboot based one. 2. To boot fast, I like to load the Radeon/AMDGPU driver directly, and not spent precious milliseconds loading other display drivers (efifb, corebootfb). Not having to include these makes the Linux kernel image a little smaller and loading it faster. 3. Currently loading `radeon` on an ASRock E350M1 and Asus F2A85-M takes roughly two seconds, which is longer then the OS needs to start. So it’d be great to be able to load the firmware while GDM for example starts.
https://bugs.freedesktop.org/show_bug.cgi?id=107168
--- Comment #5 from Alex Deucher alexdeucher@gmail.com --- (In reply to Paul Menzel from comment #4)
(In reply to Alex Deucher from comment #3)
(In reply to Paul Menzel from comment #2)
(In reply to Alex Deucher from comment #1)
You need the firmware for initialization.
What’s the technical reason for this. Why can’t certain parts of the hardware be initialized later on?
You can't do anything other than very limited modesetting until the firmwares are loaded.
That would be enough for me for entering the LUKS password.
You might as well just use the efifb driver and then load the driver later after the filesystem is available.
There are several problems with that.
- No UEFI based firmware is used, but a coreboot based one.
- To boot fast, I like to load the Radeon/AMDGPU driver directly, and not
spent precious milliseconds loading other display drivers (efifb, corebootfb). Not having to include these makes the Linux kernel image a little smaller and loading it faster. 3. Currently loading `radeon` on an ASRock E350M1 and Asus F2A85-M takes roughly two seconds, which is longer then the OS needs to start. So it’d be great to be able to load the firmware while GDM for example starts.
That's a different problem, nothing to do with when the firmware loads or whether it's available at driver load time. You still have to do the initialization at some point and that takes time. You are just moving the when that init happens. So rather than a delay boot, you'll get a delay when starting gdm.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org