| Summary: | [regression] The drm-intel-nightly branch no longer loads unversioned firmware | ||
|---|---|---|---|
| Product: | DRI | Reporter: | Mike Lothian <mike> |
| Component: | DRM/Intel | Assignee: | 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 git | Keywords: | 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 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. 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). Ah forget my previous comment about the empty config. You obviously want the blob to be part of kernel image. 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. 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 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.