Created attachment 220014 [details] graphics/gpu-firmware-kmod[-head] patch graphics/gpu-firmware-kmod[-head] 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
bugzilla was too clever overwriting my Assignee.
Comment on attachment 220014 [details] graphics/gpu-firmware-kmod[-head] patch LGTM
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.
(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.
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. Thanks.
(In reply to Emmanuel Vadot from comment #5) re-opened pull request as https://github.com/FreeBSDDesktop/kms-firmware/pull/15 Sorry it took me a few days.
Didn't we solve this another way in the end?
Yup, this can be closed.