Bug 251415 - graphics/gpu-firmware-kmod: update and add child port
Summary: graphics/gpu-firmware-kmod: update and add child port
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Niclas Zeising
Depends on:
Blocks: 251416
  Show dependency treegraph
Reported: 2020-11-26 21:17 UTC by Bjoern A. Zeeb
Modified: 2021-04-09 14:20 UTC (History)
4 users (show)

See Also:
jmd: maintainer-feedback+

graphics/gpu-firmware-kmod[-head] patch (4.58 KB, text/plain)
2020-11-26 21:17 UTC, Bjoern A. Zeeb
jmd: maintainer-approval+

Note You need to log in before you can comment on or make changes to this bug.
Description Bjoern A. Zeeb freebsd_committer 2020-11-26 21:17:34 UTC
Created attachment 220014 [details]
graphics/gpu-firmware-kmod[-head] patch


Update the gpu-firmware-kmod port to use the updated github sources
(should be no functional changes at all) and add an extra
gpu-firmware-kmod-head port which will change firmware(9) details,
especially the image name.

The new port can later be used by drm-current-kmod and
drm-devel-kmod as the LinuxKPI firmware compat code gets into head.

Submitted by: bz
Sponsored by: The FreeBSD Foundation
Comment 1 Bjoern A. Zeeb freebsd_committer 2020-11-26 21:18:31 UTC
bugzilla was too clever overwriting my Assignee.
Comment 2 Johannes M Dieterich freebsd_committer 2020-11-30 03:59:26 UTC
Comment on attachment 220014 [details]
graphics/gpu-firmware-kmod[-head] patch

Comment 3 Niclas Zeising freebsd_committer 2020-11-30 08:10:24 UTC
I believe it's better to just add a .if OSVERSION ... EXTRA_PATCHES= to the firmware port, instead of having a completely separate port for head.  This gives more granular OSVERSION checks, and doesn't break the firmware port for people running older head (since the patch is only applicable on the latest head).

In any case, you are missing OSVERSION checks, I don't think the EXTRA_PATCHES=${.CURDIR}/files is needed, i believe it is implied (but I haven't tested myself).

You also need CONFLICTS between the different firmware ports.

If the intention is to pick up patches in both gpu-firmware-kmod/files and gpu-firmware-kmod-head/files, then you probably need to specify both PATCHDIR and EXTRA_PATCHES in gpu-firmware-kmod-head.

You also have to remember to update dependencies in drm-{current,devel}-kmod.
Comment 4 Bjoern A. Zeeb freebsd_committer 2020-11-30 14:44:29 UTC
(In reply to Niclas Zeising from comment #3)

Older head will still work with the new firmware.
Newer HEAD will not run with older firmware one day when DRM will switch to in-kernel.

The dependencies to a new port were updated in PR251416 (see Blocks here).
If I get you right, then an OSVERSION check and not splitting the port would not actually need that?

The current solution is based on what you had suggested in October and basically a copy from an u-boot child port I used to figure out how to do this.

I am sorry but the EXTRA_PATCHES= etc. is beyond my ports foo and I fear I'd need help implementing the single-port solution you are currently envisioning. Could you (or someone else) please do that?
I'd be happy to run a quick test if needed before commit (both with current DRM and new linuxkpi functions)--but we had that done in https://github.com/FreeBSDDesktop/kms-firmware/pull/13 effectively already.
Comment 5 Emmanuel Vadot freebsd_committer 2020-12-02 10:45:37 UTC
So I think this wasn't clear that the changes done to the module will not break anything.
In fact it will fixes things.
Currently we rely on linker.hints to load the correct module, firmware handling in linuxkpi_gplv2 first try loading the module with the mapped name (so any '/' or '.' in the path requested is changed into a '_') and we manage to load the correct one because we load the kernel module directly, we do not load it with the firmware(9) interface, the call to firmware_get just after just check that we currently have the firmware already loaded.
Basically currently the steps done are :
- drm driver do request_firmware("path/with/and.")
- linuxkpigplv2 try the module named "path_with_and_" via linker_reference_module and succeed as the reference is present in linker.hints
- linuxpkigplv2 calls firmware_get("path/with/and.") and the function just confirm that we have a firmware loaded with this name as this is what we compile (just look at any .c in kms-firmware after a make and you will see firmware_register("i915/skl_dmc_ver1_27.bin" ...)

With those changes (and only those changes) what will happen is :
- drm driver do request_firmware("path/with/and.")
- linuxkpigplv2 try the module named "path_with_and_" via linker_reference_module and succeed as the reference is present in linker.hints
- linuxpkigplv2 calls firmware_get("path/with/and.") and this fail as the name is now correct (match the kernel module name)
- linuxpkigplv2 calls firmware_get("path_with_and_") and this succeed, this firmware is already loaded (via linker_reference_module).

So this change should be in the kms-firmware repo directly.
Comment 6 Bjoern A. Zeeb freebsd_committer 2020-12-07 22:59:17 UTC
(In reply to Emmanuel Vadot from comment #5)

re-opened pull request as

Sorry it took me a few days.
Comment 7 Niclas Zeising freebsd_committer 2021-04-09 14:15:48 UTC
Didn't we solve this another way in the end?
Comment 8 Emmanuel Vadot freebsd_committer 2021-04-09 14:20:46 UTC
Yup, this can be closed.