Bug 97182

Summary: [REGRESSION][BISECT] Linux 4.8: SKL DMC Version is now 1.23?
Product: DRI Reporter: Greg White <gwhite>
Component: DRM/IntelAssignee: Rodrigo Vivi <rodrigo.vivi>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: blocker    
Priority: highest CC: direx, intel-gfx-bugs, krejzi, mads, mike
Version: XOrg git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: SKL i915 features: display/Other
Bug Depends on:    
Bug Blocks: 97254    

Description Greg White 2016-08-02 09:40:14 UTC
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.)
Comment 1 yann 2016-08-02 10:42:50 UTC
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.
Comment 2 Greg White 2016-08-02 10:45:18 UTC
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;
	}
Comment 3 yann 2016-08-02 12:25:50 UTC
(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
Comment 4 Jani Nikula 2016-08-02 12:40:44 UTC
*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.
Comment 5 Greg White 2016-08-02 13:55:11 UTC
So, that means I should be using 1.23 with kernel 4.8?
Comment 6 cprigent 2016-08-03 12:25:51 UTC
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
Comment 7 Mike Lothian 2016-08-04 21:40:59 UTC
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
Comment 8 Direx 2016-08-09 09:28:33 UTC
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.
Comment 9 Jani Nikula 2016-08-09 10:17:16 UTC
(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.
Comment 10 Direx 2016-08-09 11:16:26 UTC
(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.
Comment 11 Jani Nikula 2016-08-09 12:20:51 UTC
(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.
Comment 12 Rodrigo Vivi 2016-08-10 05:01:38 UTC
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.
Comment 13 Direx 2016-08-10 06:36:10 UTC
(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.
Comment 14 Jani Nikula 2016-08-11 08:08:21 UTC
(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.
Comment 15 Armin K 2016-08-16 18:10:57 UTC
*** Bug 97370 has been marked as a duplicate of this bug. ***
Comment 16 Mohit Keswani 2016-08-25 05:13:53 UTC
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.
Comment 17 Jani Nikula 2016-08-25 08:16:07 UTC
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.
Comment 18 Rodrigo Vivi 2016-09-01 21:08:39 UTC
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.