Bug 97182

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.