[Bug 107168] Allow to load firmware during run-time (after initialization)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=107168

--- Comment #5 from Alex Deucher <alexdeucher at 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.
> 
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20180709/0e3bef0d/attachment-0001.html>