* [Bug 107168] Allow to load firmware during run-time (after initialization)
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
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: bugzilla-daemon @ 2018-07-09 15:53 UTC (permalink / raw)
To: dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 652 bytes --]
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.
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 2198 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
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug 107168] Allow to load firmware during run-time (after initialization)
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
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: bugzilla-daemon @ 2018-07-09 16:02 UTC (permalink / raw)
To: dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 544 bytes --]
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.
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1530 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
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug 107168] Allow to load firmware during run-time (after initialization)
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
4 siblings, 0 replies; 6+ messages in thread
From: bugzilla-daemon @ 2018-07-09 16:26 UTC (permalink / raw)
To: dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 1275 bytes --]
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.
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 2266 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug 107168] Allow to load firmware during run-time (after initialization)
2018-07-09 15:49 [Bug 107168] Allow to load firmware during run-time (after initialization) bugzilla-daemon
` (2 preceding siblings ...)
2018-07-09 16:26 ` bugzilla-daemon
@ 2018-07-09 16:33 ` bugzilla-daemon
2018-07-09 16:42 ` bugzilla-daemon
4 siblings, 0 replies; 6+ messages in thread
From: bugzilla-daemon @ 2018-07-09 16:33 UTC (permalink / raw)
To: dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 1386 bytes --]
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.
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 2494 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
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug 107168] Allow to load firmware during run-time (after initialization)
2018-07-09 15:49 [Bug 107168] Allow to load firmware during run-time (after initialization) bugzilla-daemon
` (3 preceding siblings ...)
2018-07-09 16:33 ` bugzilla-daemon
@ 2018-07-09 16:42 ` bugzilla-daemon
4 siblings, 0 replies; 6+ messages in thread
From: bugzilla-daemon @ 2018-07-09 16:42 UTC (permalink / raw)
To: dri-devel
[-- 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
^ permalink raw reply [flat|nested] 6+ messages in thread