Bug 96800

Summary: [regression] The drm-intel-nightly branch no longer loads unversioned firmware
Product: DRI Reporter: Mike Lothian <mike>
Component: DRM/IntelAssignee: Intel GFX Bugs mailing list <intel-gfx-bugs>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: medium CC: intel-gfx-bugs, mike
Version: DRI gitKeywords: regression
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: SKL i915 features: power/Other

Description Mike Lothian 2016-07-04 12:29:37 UTC
Hi

I used to load the firmware into my kernel:

CONFIG_EXTRA_FIRMWARE="i915/skl_dmc_ver1.bin i915/skl_guc_ver6.bin amdgpu/tonga_ce.bin amdgpu/tonga_mc.bin amdgpu/tonga_me.bin amdgpu/tonga_mec2.bin amdgpu/tonga_mec.bin amdgpu/tonga_pfp.bin amdgpu/tonga_rlc.bin amdgpu/tonga_sdma1.bin amdgpu/tonga_sdma.bin amdgpu/tonga_smc.bin amdgpu/tonga_uvd.bin amdgpu/tonga_vce.bin qca/nvm_usb_00000302.bin qca/rampatch_usb_00000302.bin ath10k/QCA6174/hw3.0/board-2.bin ath10k/QCA6174/hw3.0/firmware-5.bin ctefx.bin ctspeq.bin"

Since testing out the drm-intel-nightly branch this results in errors and I had to change it to use the versioned files rather than the symlinks to the latest version

CONFIG_EXTRA_FIRMWARE="i915/skl_dmc_ver1_26.bin i915/skl_guc_ver6_1.bin amdgpu/tonga_ce.bin amdgpu/tonga_mc.bin amdgpu/tonga_me.bin amdgpu/tonga_mec2.bin amdgpu/tonga_mec.bin amdgpu/tonga_pfp.bin amdgpu/tonga_rlc.bin amdgpu/tonga_sdma1.bin amdgpu/tonga_sdma.bin amdgpu/tonga_smc.bin amdgpu/tonga_uvd.bin amdgpu/tonga_vce.bin qca/nvm_usb_00000302.bin qca/rampatch_usb_00000302.bin ath10k/QCA6174/hw3.0/board-2.bin ath10k/QCA6174/hw3.0/firmware-5.bin ctefx.bin ctspeq.bin"

Without this change i915 didn't load correctly, complaining about power management and switching back to execlist from guc
Comment 1 Mika Kuoppala 2016-07-05 08:48:23 UTC
Hi Mike,

The driver should be clever enough to load the correct/supported firmware
without the CONFIG_EXTRA_FIRMWARE specified.

Could you try with empty CONFIG_EXTRA_FIRMWARE and report back if it does the right thing? Thanks.
Comment 2 Chris Wilson 2016-07-05 08:54:28 UTC
The issue is that one needs to specify the firmware to build into the kernel because i915.ko does not support deferred loading. Embedding versioning into the filename is silly for this reason (over and above requiring dumb firmware in the first place).
Comment 3 Mika Kuoppala 2016-07-05 08:55:43 UTC
Ah forget my previous comment about the empty config. You obviously want the blob to be part of kernel image.
Comment 5 Rodrigo Vivi 2016-07-06 20:09:50 UTC
Oh, now I see why that patch. However I don't believe it helps... It was never un-versioned anyways.

I mean, How did you get the name i915/skl_dmc_ver1.bin in order to add this string name to the CONFIG_EXTRA_FIRMWARE in the first place? 

Note this also has a version in the string and if the new kernel was changing the abi and using the i915/skl_dmc_ver2.bin you would still face this issue here.


Unfortunately I don't see a reliable solution here since we need to support firmware but be flexible giving people the opportunity to avoid it. 

I'm attempted to close this as wont-fix.
Comment 6 Mike Lothian 2016-07-07 00:15:30 UTC
This is the way it's versioned in the firmware repo, there is a symlink that points to the latest version of the firmware, the driver used to load that, now it doesn't.

If you're going to change how the driver works it might be a good idea to remove the symlinks to people see errors at compile time if the firmware is missing rather than at run time.

I'd still prefer if the driver loaded the symlink version first however 

I don't know why each firmware had 2 versions in its name
Comment 7 Rodrigo Vivi 2016-07-07 23:43:13 UTC
There are kernels out there that still loads the old names with only the major version. So we cannot remove the symbolic links from there, unless we copy the last files known as sym links but this would increase our fw directory in ~ 25%.

Major versions are for ABI/API changes. In case the interaction between the firmware and the driver changes we bump the major. If it is only a bug fix or small change in the firmware we bump the minor.

So, in case we had a ABI/API change you would face this issue here anyway right?

Or we could create a really unversioned symbolic link poiting to the very latest/newest firmware, but this would be totally broken if there was any change in the ABI/API.

So I don't see a point of getting the symbolic links back when we only load a very specific firmware version anyways in the driver.

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.