| Message ID | 1461626530-94474-1-git-send-email-tom.orourke@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hello, These errors are unrelated to the major_minor version change. Thanks, Tom >-----Original Message----- >From: Patchwork [mailto:patchwork@emeril.freedesktop.org] >Sent: Monday, April 25, 2016 10:18 PM >To: O'Rourke, Tom <tom.orourke@intel.com> >Cc: intel-gfx@lists.freedesktop.org >Subject: ? Fi.CI.BAT: failure for drm/i915/guc: Use major_minor version for >filename > >== Series Details == > >Series: drm/i915/guc: Use major_minor version for filename >URL : https://patchwork.freedesktop.org/series/6293/ >State : failure > >== Summary == > >Series 6293v1 drm/i915/guc: Use major_minor version for filename >http://patchwork.freedesktop.org/api/1.0/series/6293/revisions/1/mbox/ > >Test drv_hangman: > Subgroup error-state-basic: > incomplete -> PASS (snb-dellxps) >Test gem_busy: > Subgroup basic-bsd1: > pass -> DMESG-WARN (skl-nuci5) >Test gem_sync: > Subgroup basic-bsd: > pass -> DMESG-WARN (skl-nuci5) >Test kms_pipe_crc_basic: > Subgroup hang-read-crc-pipe-a: > pass -> FAIL (skl-nuci5) > Subgroup read-crc-pipe-b-frame-sequence: > skip -> PASS (bdw-nuci7) > Subgroup read-crc-pipe-c-frame-sequence: > pass -> DMESG-WARN (skl-nuci5) > >bdw-nuci7 total:200 pass:188 dwarn:0 dfail:0 fail:0 skip:12 >bsw-nuc-2 total:199 pass:158 dwarn:0 dfail:0 fail:0 skip:41 >hsw-brixbox total:200 pass:174 dwarn:0 dfail:0 fail:0 skip:26 >skl-i7k-2 total:200 pass:173 dwarn:0 dfail:0 fail:0 skip:27 >skl-nuci5 total:200 pass:185 dwarn:3 dfail:0 fail:1 skip:11 >snb-dellxps total:193 pass:155 dwarn:0 dfail:0 fail:0 skip:38 >bdw-ultra failed to connect after reboot ilk-hp8440p failed to connect after >reboot ivb-t430s failed to connect after reboot > >Results at /archive/results/CI_IGT_test/Patchwork_2065/ > >f814551aa7232ed36d71244dd148b48660b53a78 drm-intel-nightly: 2016y-04m- >25d-11h-36m-27s UTC integration manifest >bc7fd31 drm/i915/guc: Use major_minor version for filename
On Mon, Apr 25, 2016 at 04:22:10PM -0700, tom.orourke@intel.com wrote: > From: Tom O'Rourke <Tom.O'Rourke@intel.com> > > Load guc firmware from file with major_minor number > in filename instead of using symolic link with only > major number. What's the justification for this change? Either a release breaks ABI (or has fixes that are so important that they're worth treating as equivalent to an ABI-break) and thus warrants a major-number bump, or it's a minor (non-ABI-breaking) fix, which would then fit fine within a minor number bump. Since the firmware is released separately from the driver this will most likely lead to more cases where the system ends up running without any firmware loaded at all. Is that case better than having an older revision of the same major release of the firmware? Kind regards, David Weinehall
On Thu, 28 Apr 2016, David Weinehall <david.weinehall@linux.intel.com> wrote: > On Mon, Apr 25, 2016 at 04:22:10PM -0700, tom.orourke@intel.com wrote: >> From: Tom O'Rourke <Tom.O'Rourke@intel.com> >> >> Load guc firmware from file with major_minor number >> in filename instead of using symolic link with only >> major number. > > What's the justification for this change? Either a release > breaks ABI (or has fixes that are so important that they're > worth treating as equivalent to an ABI-break) and thus warrants > a major-number bump, or it's a minor (non-ABI-breaking) fix, > which would then fit fine within a minor number bump. > > Since the firmware is released separately from the driver > this will most likely lead to more cases where the system ends up > running without any firmware loaded at all. Is that case better > than having an older revision of the same major release of the > firmware? The patch could use a more detailed commit message. This is what I wrote on the matter previously. On Tue, 22 Mar 2016, Jani Nikula <jani.nikula@linux.intel.com> wrote: > I think we should move to accepting only specific firmware versions in > the driver instead of having an illusion of forward compatible firmware > minor versions. > > By accepting any firmware with minor version greater than required, we > create a huge testing burden on all prior released kernels when we > release a new firmware version. We don't have the resources for > that. But we also can't just go ahead and release firmware versions that > might break stable kernels in distros out there. > > We need to turn this the other way round. We need to make releasing > firmware versions easy, and add the testing burden to the single kernel > commit that accepts a new firmware version. We already have CI in place > for that. > > We (and the distros) can then *choose* to backport the commits that > enable newer firmware versions, instead of having this control (or lack > thereof) in the firmware release process. For clarification, first, I don't reject the possibility of accepting multiple specific firmware versions, and second, the minor versions *should* be forward compatible but we don't know for sure without testing against each and every kernel that might load said firmware version. The combinations just explode. I have not looked into all the details here, but in general this is Acked-by: Jani Nikula <jani.nikula@intel.com> Maybe we should also consider cc: drm-intel-fixes or even cc: stable. BR, Jani.
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c b/drivers/gpu/drm/i915/intel_guc_loader.c index 876e5da..321bdbb 100644 --- a/drivers/gpu/drm/i915/intel_guc_loader.c +++ b/drivers/gpu/drm/i915/intel_guc_loader.c @@ -59,7 +59,7 @@ * */ -#define I915_SKL_GUC_UCODE "i915/skl_guc_ver6.bin" +#define I915_SKL_GUC_UCODE "i915/skl_guc_ver6_1.bin" MODULE_FIRMWARE(I915_SKL_GUC_UCODE); /* User-friendly representation of an enum */