dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
* [Bug 107168] Allow to load firmware during run-time (after initialization)
@ 2018-07-09 15:49 bugzilla-daemon
  2018-07-09 15:53 ` bugzilla-daemon
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: bugzilla-daemon @ 2018-07-09 15:49 UTC (permalink / raw)
  To: dri-devel


[-- Attachment #1.1: Type: text/plain, Size: 1175 bytes --]

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2463 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
                   ` (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

end of thread, other threads:[~2018-07-09 16:42 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 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).