Bug 107168 - Allow to load firmware during run-time (after initialization)
Summary: Allow to load firmware during run-time (after initialization)
Status: RESOLVED WONTFIX
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: DRI git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-07-09 15:49 UTC by Paul Menzel
Modified: 2018-07-09 16:42 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Paul Menzel 2018-07-09 15:49:26 UTC
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.
Comment 1 Alex Deucher 2018-07-09 15:53:01 UTC
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.
Comment 2 Paul Menzel 2018-07-09 16:02:40 UTC
(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.
Comment 3 Alex Deucher 2018-07-09 16:26:47 UTC
(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.
Comment 4 Paul Menzel 2018-07-09 16:33:03 UTC
(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.
Comment 5 Alex Deucher 2018-07-09 16:42:50 UTC
(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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.