[PATCH] drm/i915/guc: Use major_minor version for filename

[PATCH] drm/i915/guc: Use major_minor version for filename

[tom.orourke]

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.

Issue: VIZ-7713
Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
---
 drivers/gpu/drm/i915/intel_guc_loader.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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 */
-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✗ Fi.CI.BAT: failure for drm/i915/guc: Use major_minor version for filename

[Patchwork]

== 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

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: ✗ Fi.CI.BAT: failure for drm/i915/guc: Use major_minor version for filename

[O'Rourke, Tom]

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

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/guc: Use major_minor version for filename

[David Weinehall]

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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/guc: Use major_minor version for filename

[Jani Nikula]

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.


-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx