Just built the latest pre-release kernel with the new DRM code. SKL (at least...) DMC version is now 1.23, not what appears to be current (1.26)? Also, DMC version checking seems to have warped from looking for anything equal to or newer than the supplied version check to only allowing the exact version specified in the source. The current version for my distro (and 01.org) is 1.26, the driver is looking for 1.23 (October 2015.)
Greg, I don't think that DMC version switched back to 1.23, this is only the minimum version it is looking for to work properly. Since 1.26 is only the one available, it should be neither a regression nor causing issue.
That's not what the code says: if (csr->version != required_version) { DRM_INFO("Refusing to load DMC firmware v%u.%u," " please use v%u.%u [" FIRMWARE_URL "].\n", CSR_VERSION_MAJOR(csr->version), CSR_VERSION_MINOR(csr->version), CSR_VERSION_MAJOR(required_version), CSR_VERSION_MINOR(required_version)); return NULL; }
(In reply to Greg White from comment #2) > That's not what the code says: > > if (csr->version != required_version) { > DRM_INFO("Refusing to load DMC firmware v%u.%u," > " please use v%u.%u [" FIRMWARE_URL "].\n", > CSR_VERSION_MAJOR(csr->version), > CSR_VERSION_MINOR(csr->version), > CSR_VERSION_MAJOR(required_version), > CSR_VERSION_MINOR(required_version)); > return NULL; > } You are right, I didn't pull latest one, policy changed by 4aa7fb9c3c4fa04eca4e6e6020aaca7b34170381 Regression on SKL_CSR_VERSION_REQUIRED was introduced by 5e580523d9128a4d8364fe89d36c38fc7819c8dd
*sigh* The regression is that 1.23 has apparently been removed from linux-firmware and your distro. The firmware version is intimately related to your kernel version, and you are not supposed to be using any latest version.
So, that means I should be using 1.23 with kernel 4.8?
Just to confirm I have the same behavior: $ dmesg |grep DMC [ 2.910480] [drm] Refusing to load DMC firmware v1.26, please use v1.23 [https://01.org/linuxgraphics/intel-linux-graphics-firmwares]. [ 2.910488] i915 0000:00:02.0: Failed to load DMC firmware [https://01.org/linuxgraphics/intel-linux-graphics-firmwares], disabling runtime power management. # cat /sys/kernel/debug/dri/0/i915_dmc_info fw loaded: no path: i915/skl_dmc_ver1.bin program base: 0xeffbfa27 ssp base: 0x00000000 htp: 0x00000000 Platform: NUC6i3SYB CPU: Intel(R) Core(TM) i3-6100U CPU @ 2.30GHZ (family 6, model 78, stepping 3) Motherboard version: H81132-502 GPU: Intel® HD Graphics 520 - Intel Corporation Sky Lake Integrated Graphics (rev 07) Memory: one 8GB card Kingston KVR21S15D8/8 SSD: Samsung 850 EVO M.2 120 Go Software Bios: SYSKLi35.86A.0045.2016.0527.1055 Kernel: 4.7.0 6f87e85 from http://cgit.freedesktop.org/drm-intel/ commit 6f87e85fa302ffdb4cb9f4cd712691165923c7a2 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Aug 1 15:53:41 2016 +0100 drm-intel-nightly: 2016y-08m-01d-14h-53m-17s UTC integration manifest drm: libdrm-2.4.70 f19cd3a from git://anongit.freedesktop.org/mesa/drm mesa: mesa-11.2.2 3a9f628from git://anongit.freedesktop.org/mesa/mesa cairo: 1.15.2 db8a7f1 from git://anongit.freedesktop.org/cairo xserver: xorg-server-1.18.0-502 c833c08 from git://git.freedesktop.org/git/xorg/xserver xf86-video-intel: 2.99.917-688 49daf5d from git://git.freedesktop.org/git/xorg/driver/xf86-video-intel libva: libva-1.7.0-40 f7e2263 from git://git.freedesktop.org/git/vaapi/libva vaapi-intel-driver: 1.7.0-64 1cd6795 from git://git.freedesktop.org/git/vaapi/intel-driver DMC 1.26 from https://01.org/sites/default/files/downloads/intelr-graphics-linux/skldmcver126.tar_1.bz2 GUC 6.1 from https://01.org/sites/default/files/downloads/intelr-graphics-linux/sklgucver61.tar.bz2
I updated drivers/gpu/drm/i915/intel_csr.c from: #define SKL_CSR_VERSION_REQUIRED CSR_VERSION(1, 23) to #define SKL_CSR_VERSION_REQUIRED CSR_VERSION(1, 26) which fixes things for me
Well, from what I can say is that 1.23 does not work on 4.8-rc1 for me and causes a black screen whenever X loads. See bug 97254. So 1.26 might actually be required for 4.8.
(In reply to Direx from comment #8) > Well, from what I can say is that 1.23 does not work on 4.8-rc1 for me and > causes a black screen whenever X loads. See bug 97254. So 1.26 might > actually be required for 4.8. Perhaps. But the point is, that change has to happen via a kernel change rather than arbitrarily on the linux-firmware update. Also, when there are kernels out there that expect 1.23, we can't just drop 1.23 from linux-firmware.
(In reply to Jani Nikula from comment #9) > Perhaps. But the point is, that change has to happen via a kernel change > rather than arbitrarily on the linux-firmware update. > > Also, when there are kernels out there that expect 1.23, we can't just drop > 1.23 from linux-firmware. Fair enough. But the latest firmware is symlinked via skl_dmc_ver1.bin anyway, so a later firmware version should not be rejected by the kernel. 4aa7fb9c, which also introduced the version pinning, got rid of loading by symlink and forced firmware loading via real filename. In this case all firmware files should be present in linux-firmware. But if the kernel loads the firmware by the skl_dmc_ver1 symlink (which is the case right now again), then there is no point in keeping multiple FW releases in linux-firmware.
(In reply to Direx from comment #10) > (In reply to Jani Nikula from comment #9) > > Perhaps. But the point is, that change has to happen via a kernel change > > rather than arbitrarily on the linux-firmware update. > > > > Also, when there are kernels out there that expect 1.23, we can't just drop > > 1.23 from linux-firmware. > Fair enough. But the latest firmware is symlinked via skl_dmc_ver1.bin > anyway, so a later firmware version should not be rejected by the kernel. > > 4aa7fb9c, which also introduced the version pinning, got rid of loading by > symlink and forced firmware loading via real filename. In this case all > firmware files should be present in linux-firmware. But if the kernel loads > the firmware by the skl_dmc_ver1 symlink (which is the case right now > again), then there is no point in keeping multiple FW releases in > linux-firmware. The symlink should also be removed.
Nope, we cannot remove the symbolic link for the same reason that we cannot remove the 1.23, because there are stable kernel out there that loads that directly.
(In reply to Rodrigo Vivi from comment #12) > Nope, we cannot remove the symbolic link for the same reason that we cannot > remove the 1.23, because there are stable kernel out there that loads that > directly. Most (if not all) recent kernels load the Skylake FW by symlink, so yes, the symlink needs to stay. The kernel code needs to be fixed anyway. I think there are two possibilities: 1. Fully revert 4aa7fb9c and keep loading the FW by symlink. In this case the check for "required_min_version" would be restored, instead of checking "required_version". 2. Fully restore the behavior introduced by 4aa7fb9c, including the version pinning, and load the FW by direct name. #2 would mean that the firmware needs to stay forever in linux-firmware.git. The current behavior "i915/skl_dmc_ver1.bin is too new, go away" does not make sense, though. Especially if the same FW loaded just fine on *older* kernels. But surely the actual developers have the last word on this.
(In reply to Rodrigo Vivi from comment #12) > Nope, we cannot remove the symbolic link for the same reason that we cannot > remove the 1.23, because there are stable kernel out there that loads that > directly. Indeed. The symlink must point at a fixed version instead of being updated. The update must come from kernel.
*** Bug 97370 has been marked as a duplicate of this bug. ***
Still same behavior on 4.8.0-rc3. Is someone fixing this issue. I've a Skylake and if i link to either firmware 1.23 or 1.26 it is giving me the same issue.
Please try drm-intel-fixes branch of http://cgit.freedesktop.org/drm-intel. The pull request has been sent upstream http://marc.info/?i=87k2f5tgfe.fsf@intel.com.
skl_dmc_1.23 per maintainers request was added back to linux-firmware.git. In case it start causing bugs, please open a different bug report.
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.