Comment # 5
on bug 107168
from Alex Deucher
(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. > > 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. 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.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
