From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 107168] Allow to load firmware during run-time (after initialization)
Date: Mon, 09 Jul 2018 16:42:50 +0000 [thread overview]
Message-ID: <bug-107168-502-bpxOEL96lQ@http.bugs.freedesktop.org/> (raw)
In-Reply-To: <bug-107168-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 1785 bytes --]
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.
>
> 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.
[-- Attachment #1.2: Type: text/html, Size: 2967 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
prev parent reply other threads:[~2018-07-09 16:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-09 15:49 [Bug 107168] Allow to load firmware during run-time (after initialization) bugzilla-daemon
2018-07-09 15:53 ` bugzilla-daemon
2018-07-09 16:02 ` bugzilla-daemon
2018-07-09 16:26 ` bugzilla-daemon
2018-07-09 16:33 ` bugzilla-daemon
2018-07-09 16:42 ` bugzilla-daemon [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-107168-502-bpxOEL96lQ@http.bugs.freedesktop.org/ \
--to=bugzilla-daemon@freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).