[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9 (rev2)
== Series Details == Series: drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9 (rev2) URL : https://patchwork.freedesktop.org/series/81764/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9747 -> Patchwork_19638 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19638 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19638, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19638/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19638: ### IGT changes ### Possible regressions * igt@i915_pm_rpm@module-reload: - fi-cfl-8109u: [PASS][1] -> [DMESG-WARN][2] +35 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-cfl-8109u/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19638/fi-cfl-8109u/igt@i915_pm_...@module-reload.html Known issues Here are the changes found in Patchwork_19638 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-gfx0: - fi-cfl-8700k: NOTRUN -> [SKIP][3] ([fdo#109271]) +25 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19638/fi-cfl-8700k/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html * igt@debugfs_test@read_all_entries: - fi-tgl-y: [PASS][4] -> [DMESG-WARN][5] ([i915#402]) +2 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@debugfs_test@read_all_entries.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19638/fi-tgl-y/igt@debugfs_test@read_all_entries.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271]) +23 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19638/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_exec_suspend@basic-s0: - fi-cfl-8109u: [PASS][7] -> [DMESG-WARN][8] ([i915#262]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19638/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#2190]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19638/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html - fi-cfl-8700k: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#2190]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19638/fi-cfl-8700k/igt@gem_huc_c...@huc-copy.html * igt@i915_selftest@live@execlists: - fi-cfl-8109u: [PASS][11] -> [DMESG-WARN][12] ([i915#1037]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19638/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][13] ([i915#1886] / [i915#2291]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19638/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-soraka: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19638/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@vga-edid-read: - fi-cfl-8700k: NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +8 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19638/fi-cfl-8700k/igt@kms_chamel...@vga-edid-read.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-cfl-8700k: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#533]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19638/fi-cfl-8700k/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html - fi-kbl-soraka: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#533]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19638/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html Possible fixes * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [DMESG-WARN][18] ([i915#402]) -> [PASS][19] +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19638/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [fdo#109271]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9 (rev2)
== Series Details == Series: drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9 (rev2) URL : https://patchwork.freedesktop.org/series/81764/ State : warning == Summary == $ dim checkpatch origin/drm-tip 785109fdc964 drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9 -:24: WARNING:BAD_SIGN_OFF: Duplicate signature #24: Reported-by: kernel test robot total: 0 errors, 1 warnings, 0 checks, 29 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/debugfs: HDCP capability enc NULL check
> -Original Message-
> From: Gupta, Anshuman
> Sent: Friday, February 5, 2021 5:43 PM
> To: Deak, Imre
> Cc: intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/debugfs: HDCP capability enc NULL
> check
>
>
>
> > -Original Message-
> > From: Imre Deak
> > Sent: Friday, February 5, 2021 5:35 PM
> > To: Gupta, Anshuman
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/debugfs: HDCP capability enc
> > NULL check
> >
> > On Fri, Feb 05, 2021 at 10:16:30AM +0200, Gupta, Anshuman wrote:
> > > > -Original Message-
> > > > From: Imre Deak
> > > > Sent: Thursday, February 4, 2021 11:58 PM
> > > > To: Gupta, Anshuman
> > > > Cc: intel-gfx@lists.freedesktop.org
> > > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/debugfs: HDCP capability
> > > > enc NULL check
> > > >
> > > > On Fri, Jan 29, 2021 at 01:30:43PM +0530, Anshuman Gupta wrote:
> > > > > DP-MST connector encoder initializes at modeset Adding a
> > > > > connector->encoder NULL check in order to avoid any NULL pointer
> > > > > dereference.
> > > > > intel_hdcp_enable() already handle this but debugfs can also
> > > > > invoke the intel_{hdcp,hdcp2_capable}.
> > > > > Handling it gracefully.
> > > > >
> > > > > Signed-off-by: Anshuman Gupta
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_hdcp.c | 14 --
> > > > > 1 file changed, 12 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > > index ae1371c36a32..58af323d189a 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > > @@ -135,11 +135,16 @@ int intel_hdcp_read_valid_bksv(struct
> > > > > intel_digital_port *dig_port,
> > > > > /* Is HDCP1.4 capable on Platform and Sink */ bool
> > > > > intel_hdcp_capable(struct intel_connector *connector) {
> > > > > - struct intel_digital_port *dig_port =
> > > > intel_attached_dig_port(connector);
> > > > > + struct intel_digital_port *dig_port;
> > > > > const struct intel_hdcp_shim *shim = connector->hdcp.shim;
> > > > > bool capable = false;
> > > > > u8 bksv[5];
> > > > >
> > > > > + if (!connector->encoder)
> > > > > + return -ENODEV;
> > > >
> > > > I assume this is needed when called from i915_hdcp_sink_capability
> > > > debugfs entry. That one is lacking the locking for the connector,
> > > > but is that entry really needed? We print the same info already
> > > > from the i915_display_info entry which has the proper locking and
> > > > encoder check.
> > >
> > > Historically HDCP capability added to i915_display_info later to
> > > debug CI machine as i915_display_info available as CI logs. Now the
> > > plans i915_display_info should only show the monitor capability.
> > > and i915_hdcp_sink_capability will check both sink and platform
> > > capability.
> >
> > Ok, in any case the encoder NULL check and the required locking should
> > be done in i915_hdcp_sink_capability_show().
Need one input, AFAIU we do require
drm_modeset_lock(_priv->drm.mode_config.connection_mutex, NULL) lock
in i915_hdcp_sink_capability ?
Thanks,
Anshuman Gupta.
> Thanks Imre for review I will send a v2 patch.
> Thanks,
> Anshuman Gupta.
> >
> > >
> > > Thanks,
> > > Anshuman Gupta.
> > > >
> > > > > +
> > > > > + dig_port = intel_attached_dig_port(connector);
> > > > > +
> > > > > if (!shim)
> > > > > return capable;
> > > > >
> > > > > @@ -156,11 +161,16 @@ bool intel_hdcp_capable(struct
> > > > > intel_connector
> > > > > *connector)
> > > > > /* Is HDCP2.2 capable on Platform and Sink */ bool
> > > > > intel_hdcp2_capable(struct intel_connector *connector) {
> > > > > - struct intel_digital_port *dig_port =
> > > > intel_attached_dig_port(connector);
> > > > > + struct intel_digital_port *dig_port;
> > > > > struct drm_i915_private *dev_priv =
> > > > > to_i915(connector->base.dev);
> > > > > struct intel_hdcp *hdcp = >hdcp;
> > > > > bool capable = false;
> > > > >
> > > > > + if (!connector->encoder)
> > > > > + return -ENODEV;
> > > > > +
> > > > > + dig_port = intel_attached_dig_port(connector);
> > > > > +
> > > > > /* I915 support for HDCP2.2 */
> > > > > if (!hdcp->hdcp2_supported)
> > > > > return false;
> > > > > --
> > > > > 2.26.2
> > > > >
> > > > > ___
> > > > > Intel-gfx mailing list
> > > > > Intel-gfx@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Extract DPCD backlight helpers from i915, add support in nouveau (rev6)
== Series Details == Series: drm: Extract DPCD backlight helpers from i915, add support in nouveau (rev6) URL : https://patchwork.freedesktop.org/series/84754/ State : success == Summary == CI Bug Log - changes from CI_DRM_9747_full -> Patchwork_19636_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19636_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fair@basic-deadline: - shard-kbl: [PASS][1] -> [FAIL][2] ([i915#2846]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-kbl1/igt@gem_exec_f...@basic-deadline.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/shard-kbl3/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_reloc@basic-parallel: - shard-kbl: NOTRUN -> [TIMEOUT][3] ([i915#1729]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/shard-kbl7/igt@gem_exec_re...@basic-parallel.html * igt@gem_exec_schedule@u-fairslice-all: - shard-skl: [PASS][4] -> [DMESG-WARN][5] ([i915#1610] / [i915#2803]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl8/igt@gem_exec_sched...@u-fairslice-all.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/shard-skl3/igt@gem_exec_sched...@u-fairslice-all.html * igt@gem_exec_schedule@u-fairslice@vecs0: - shard-glk: [PASS][6] -> [DMESG-WARN][7] ([i915#1610] / [i915#2803]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk9/igt@gem_exec_schedule@u-fairsl...@vecs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/shard-glk2/igt@gem_exec_schedule@u-fairsl...@vecs0.html * igt@gem_userptr_blits@process-exit-mmap-busy@uc: - shard-skl: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1699]) +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/shard-skl6/igt@gem_userptr_blits@process-exit-mmap-b...@uc.html * igt@gen9_exec_parse@allowed-all: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([i915#1436] / [i915#716]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk6/igt@gen9_exec_pa...@allowed-all.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/shard-glk6/igt@gen9_exec_pa...@allowed-all.html * igt@kms_big_fb@y-tiled-addfb-size-offset-overflow: - shard-skl: NOTRUN -> [SKIP][11] ([fdo#109271]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/shard-skl4/igt@kms_big...@y-tiled-addfb-size-offset-overflow.html * igt@kms_chamelium@hdmi-audio-edid: - shard-kbl: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +2 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/shard-kbl7/igt@kms_chamel...@hdmi-audio-edid.html * igt@kms_color_chamelium@pipe-c-ctm-max: - shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/shard-apl6/igt@kms_color_chamel...@pipe-c-ctm-max.html * igt@kms_color_chamelium@pipe-d-ctm-0-5: - shard-tglb: NOTRUN -> [SKIP][14] ([fdo#109284] / [fdo#111827]) +2 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/shard-tglb1/igt@kms_color_chamel...@pipe-d-ctm-0-5.html * igt@kms_cursor_crc@pipe-c-cursor-128x42-sliding: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#54]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl2/igt@kms_cursor_...@pipe-c-cursor-128x42-sliding.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/shard-skl5/igt@kms_cursor_...@pipe-c-cursor-128x42-sliding.html * igt@kms_cursor_edge_walk@pipe-c-128x128-left-edge: - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl2/igt@kms_cursor_edge_w...@pipe-c-128x128-left-edge.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/shard-skl5/igt@kms_cursor_edge_w...@pipe-c-128x128-left-edge.html * igt@kms_dp_tiled_display@basic-test-pattern: - shard-tglb: NOTRUN -> [SKIP][19] ([i915#426]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/shard-tglb1/igt@kms_dp_tiled_disp...@basic-test-pattern.html * igt@kms_flip@flip-vs-expired-vblank@a-edp1: - shard-tglb: [PASS][20] -> [FAIL][21] ([i915#2598]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-tglb8/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/shard-tglb7/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html * igt@kms_flip@flip-vs-suspend-interruptible@c-dp1: - shard-apl: NOTRUN -> [DMESG-WARN][22] ([i915#180]) +3
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling
== Series Details == Series: series starting with [1/3] drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling URL : https://patchwork.freedesktop.org/series/86882/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9747 -> Patchwork_19637 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19637 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19637, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19637: ### IGT changes ### Possible regressions * igt@vgem_basic@unload: - fi-kbl-soraka: NOTRUN -> [DMESG-WARN][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-kbl-soraka/igt@vgem_ba...@unload.html Known issues Here are the changes found in Patchwork_19637 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-gfx0: - fi-cfl-8700k: NOTRUN -> [SKIP][2] ([fdo#109271]) +25 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-cfl-8700k/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271]) +23 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [PASS][4] -> [FAIL][5] ([i915#1888]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html - fi-tgl-y: [PASS][6] -> [DMESG-WARN][7] ([i915#2411] / [i915#402]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#2190]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html - fi-cfl-8700k: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#2190]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-cfl-8700k/igt@gem_huc_c...@huc-copy.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][10] ([i915#1886] / [i915#2291]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-soraka: NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@vga-edid-read: - fi-cfl-8700k: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-cfl-8700k/igt@kms_chamel...@vga-edid-read.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-cfl-8700k: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#533]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-cfl-8700k/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html - fi-kbl-soraka: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#533]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@prime_vgem@basic-write: - fi-tgl-y: [PASS][15] -> [DMESG-WARN][16] ([i915#402]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@prime_v...@basic-write.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-tgl-y/igt@prime_v...@basic-write.html * igt@runner@aborted: - fi-bdw-5557u: NOTRUN -> [FAIL][17] ([i915#1602] / [i915#2029] / [i915#2369]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-bdw-5557u/igt@run...@aborted.html Possible fixes * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [DMESG-WARN][18] ([i915#402]) -> [PASS][19] +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [fdo#109271]:
Re: [Intel-gfx] [FYI PATCH] i915: kvmgt: the KVM mmu_lock is now an rwlock
Hi Paolo,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on linux/master drm-tip/drm-tip linus/master v5.11-rc6
next-20210125]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Paolo-Bonzini/i915-kvmgt-the-KVM-mmu_lock-is-now-an-rwlock/20210209-070812
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-rhel-8.3 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/e1625dbf5fa4aea9c53da01a04bfb55443375c30
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Paolo-Bonzini/i915-kvmgt-the-KVM-mmu_lock-is-now-an-rwlock/20210209-070812
git checkout e1625dbf5fa4aea9c53da01a04bfb55443375c30
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from include/linux/spinlock.h:312,
from include/linux/wait.h:9,
from include/linux/pid.h:6,
from include/linux/sched.h:14,
from include/linux/ratelimit.h:6,
from include/linux/dev_printk.h:16,
from include/linux/device.h:15,
from drivers/gpu/drm/i915/gvt/kvmgt.c:32:
drivers/gpu/drm/i915/gvt/kvmgt.c: In function 'kvmgt_page_track_add':
drivers/gpu/drm/i915/gvt/kvmgt.c:1706:13: error: passing argument 1 of
'_raw_write_lock' from incompatible pointer type
[-Werror=incompatible-pointer-types]
1706 | write_lock(>mmu_lock);
| ^~
| |
| spinlock_t * {aka struct spinlock *}
include/linux/rwlock.h:70:42: note: in definition of macro 'write_lock'
70 | #define write_lock(lock) _raw_write_lock(lock)
| ^~~~
In file included from include/linux/spinlock_api_smp.h:190,
from include/linux/spinlock.h:318,
from include/linux/wait.h:9,
from include/linux/pid.h:6,
from include/linux/sched.h:14,
from include/linux/ratelimit.h:6,
from include/linux/dev_printk.h:16,
from include/linux/device.h:15,
from drivers/gpu/drm/i915/gvt/kvmgt.c:32:
include/linux/rwlock_api_smp.h:19:43: note: expected 'rwlock_t *' {aka
'struct *'} but argument is of type 'spinlock_t *' {aka 'struct
spinlock *'}
19 | void __lockfunc _raw_write_lock(rwlock_t *lock) __acquires(lock);
| ~~^~~~
>> drivers/gpu/drm/i915/gvt/kvmgt.c:1715:15: error: passing argument 1 of
>> '__raw_write_unlock' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
1715 | write_unlock(>mmu_lock);
| ^~
| |
| spinlock_t * {aka struct spinlock *}
include/linux/rwlock_api_smp.h:88:52: note: in definition of macro
'_raw_write_unlock'
88 | #define _raw_write_unlock(lock) __raw_write_unlock(lock)
|^~~~
drivers/gpu/drm/i915/gvt/kvmgt.c:1715:2: note: in expansion of macro
'write_unlock'
1715 | write_unlock(>mmu_lock);
| ^~~~
include/linux/rwlock_api_smp.h:216:49: note: expected 'rwlock_t *' {aka
'struct *'} but argument is of type 'spinlock_t *' {aka 'struct
spinlock *'}
216 | static inline void __raw_write_unlock(rwlock_t *lock)
| ~~^~~~
In file included from include/linux/spinlock.h:312,
from include/linux/wait.h:9,
from include/linux/pid.h:6,
from include/linux/sched.h:14,
from include/linux/ratelimit.h:6,
from include/linux/dev_printk.h:16,
from include/linux/device.h:15,
from drivers/gpu/drm/i915/gvt/kvmgt.c:32:
drivers/gpu/drm/i915/gvt/kvmgt.c: In function 'kvmgt_page_track_remove':
drivers/gpu/drm/i915/gvt/kvmgt.c:1740:13: error: passing argument 1 of
'_raw_write_lock' from incompatible pointer type
[-Werror=incompatible-pointer-types]
1740 | write_lock(>mmu_lock);
| ^~
| |
| spinlock_t * {aka struct spinlock *}
include/linux/rwlock.h:70:42: note: in definition of macro 'write_lock'
70 | #define write_lock(lock)
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling
== Series Details == Series: series starting with [1/3] drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling URL : https://patchwork.freedesktop.org/series/86882/ State : warning == Summary == $ dim checkpatch origin/drm-tip d3049184b718 drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling -:16: WARNING:REPEATED_WORD: Possible repeated word: 'just' #16: On ilk/snb/ivb it looks like the accesses just just wrap total: 0 errors, 1 warnings, 0 checks, 33 lines checked 16380d000219 drm/i915: Fix overlay frontbuffer tracking 17d615fa2b9d drm/i915: Warn when releasing a frontbuffer while in use ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Warn when releasing a frontbuffer while in use
From: Ville Syrjälä
Let's scream if we are about to release a frontbuffer which
is still in use.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_frontbuffer.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
index 7b38eee9980f..6fc6965b6133 100644
--- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
@@ -224,6 +224,8 @@ static void frontbuffer_release(struct kref *ref)
struct drm_i915_gem_object *obj = front->obj;
struct i915_vma *vma;
+ drm_WARN_ON(obj->base.dev, atomic_read(>bits));
+
spin_lock(>vma.lock);
for_each_ggtt_vma(vma, obj) {
i915_vma_clear_scanout(vma);
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Fix overlay frontbuffer tracking
From: Ville Syrjälä
We don't have a persistent fb holding a reference to the frontbuffer
object, so every time we do the get+put we throw the frontbuffer object
immediately away. And so the next time around we get a pristine
frontbuffer object with bits==0 even for the old vma. This confuses
the frontbuffer tracking code which understandably expects the old
frontbuffer to have the overlay's bit set.
Fix this by hanging on to the frontbuffer reference until the next
flip. And just to make this a bit more clear let's track the frontbuffer
explicitly instead of just grabbing it via the old vma.
Cc: sta...@vger.kernel.org
Cc: Chris Wilson
Cc: Joonas Lahtinen
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1136
Fixes: da42104f589d ("drm/i915: Hold reference to intel_frontbuffer as we track
activity")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_overlay.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
b/drivers/gpu/drm/i915/display/intel_overlay.c
index 9c0113f15b58..ef8f44f5e751 100644
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -183,6 +183,7 @@ struct intel_overlay {
struct intel_crtc *crtc;
struct i915_vma *vma;
struct i915_vma *old_vma;
+ struct intel_frontbuffer *frontbuffer;
bool active;
bool pfit_active;
u32 pfit_vscale_ratio; /* shifted-point number, (1<<12) == 1.0 */
@@ -283,21 +284,19 @@ static void intel_overlay_flip_prepare(struct
intel_overlay *overlay,
struct i915_vma *vma)
{
enum pipe pipe = overlay->crtc->pipe;
- struct intel_frontbuffer *from = NULL, *to = NULL;
+ struct intel_frontbuffer *frontbuffer = NULL;
drm_WARN_ON(>i915->drm, overlay->old_vma);
- if (overlay->vma)
- from = intel_frontbuffer_get(overlay->vma->obj);
if (vma)
- to = intel_frontbuffer_get(vma->obj);
+ frontbuffer = intel_frontbuffer_get(vma->obj);
- intel_frontbuffer_track(from, to, INTEL_FRONTBUFFER_OVERLAY(pipe));
+ intel_frontbuffer_track(overlay->frontbuffer, frontbuffer,
+ INTEL_FRONTBUFFER_OVERLAY(pipe));
- if (to)
- intel_frontbuffer_put(to);
- if (from)
- intel_frontbuffer_put(from);
+ if (overlay->frontbuffer)
+ intel_frontbuffer_put(overlay->frontbuffer);
+ overlay->frontbuffer = frontbuffer;
intel_frontbuffer_flip_prepare(overlay->i915,
INTEL_FRONTBUFFER_OVERLAY(pipe));
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling
From: Ville Syrjälä
ilk+ planes get notably unhappy when the plane x+w exceeds
the stride. This wasn't a problem previously because we
always aligned SURF to the closest tile boundary so the
x offset never got particularly large. But now with async
flips we have to align to 256KiB instead and thus this
becomes a real issue.
On ilk/snb/ivb it looks like the accesses just just wrap
early to the next tile row when scanout goes past the
SURF+n*stride boundary, hsw/bdw suffer more heavily and
start to underrun constantly. i965/g4x appear to be immune.
vlv/chv I've not yet checked.
Let's borrow another trick from the skl+ code and search
backwards for a better SURF offset in the hopes of getting the
x offset below the limit. IIRC when I ran into a similar issue
on skl years ago it was causing the hardware to fall over
pretty hard as well.
And let's be consistent and include i965/g4x in the check
as well, just in case I just got super lucky somehow when
I wasn't able to reproduce the issue. Not that it really
matters since we still use 4k SURF alignment for i965/g4x
anyway.
Fixes: 6ede6b0616b2 ("drm/i915: Implement async flips for vlv/chv")
Fixes: 4bb18054adc4 ("drm/i915: Implement async flip for ilk/snb")
Fixes: 2a636e240c77 ("drm/i915: Implement async flip for ivb/hsw")
Fixes: cda195f13abd ("drm/i915: Implement async flips for bdw")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_plane.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c
b/drivers/gpu/drm/i915/display/i9xx_plane.c
index 0523e2c79d16..8a52beaed2da 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.c
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
@@ -255,6 +255,33 @@ int i9xx_check_plane_surface(struct intel_plane_state
*plane_state)
else
offset = 0;
+ /*
+* When using an X-tiled surface the plane starts to
+* misbehave if the x offset + width exceeds the stride.
+* hsw/bdw: underrun galore
+* ilk/snb/ivb: wrap to the next tile row mid scanout
+* i965/g4x: so far appear immune to this
+* vlv/chv: TODO check
+*
+* Linear surfaces seem to work just fine, even on hsw/bdw
+* despite them not using the linear offset anymore.
+*/
+ if (INTEL_GEN(dev_priv) >= 4 && fb->modifier ==
I915_FORMAT_MOD_X_TILED) {
+ u32 alignment = intel_surf_alignment(fb, 0);
+ int cpp = fb->format->cpp[0];
+
+ while ((src_x + src_w) * cpp >
plane_state->color_plane[0].stride) {
+ if (offset == 0) {
+ drm_dbg_kms(_priv->drm,
+ "Unable to find suitable display
surface offset due to X-tiling\n");
+ return -EINVAL;
+ }
+
+ offset = intel_plane_adjust_aligned_offset(_x,
_y, plane_state, 0,
+ offset,
offset - alignment);
+ }
+ }
+
/*
* Put the final coordinates back so that the src
* coordinate checks will see the right values.
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gvt/kvmgt: Fix the build failure in kvmgt.
On 2021.02.09 02:52:10 +0800, Yu Zhang wrote:
> Previously, commit 531810caa9f4 ("KVM: x86/mmu: Use
> an rwlock for the x86 MMU") replaced KVM's mmu_lock
> with type rwlock_t. This will cause a build failure
> in kvmgt, which uses the same lock when trying to add/
> remove some GFNs to/from the page tracker. Fix it with
> write_lock/unlocks in kvmgt.
Thanks for the fix! I saw Paolo has already carried one
in -next, so we are fine.
>
> Reported-by: Stephen Rothwell
> Signed-off-by: Yu Zhang
> ---
> drivers/gpu/drm/i915/gvt/kvmgt.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 60f1a386dd06..b4348256ae95 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -1703,7 +1703,7 @@ static int kvmgt_page_track_add(unsigned long handle,
> u64 gfn)
> return -EINVAL;
> }
>
> - spin_lock(>mmu_lock);
> + write_lock(>mmu_lock);
>
> if (kvmgt_gfn_is_write_protected(info, gfn))
> goto out;
> @@ -1712,7 +1712,7 @@ static int kvmgt_page_track_add(unsigned long handle,
> u64 gfn)
> kvmgt_protect_table_add(info, gfn);
>
> out:
> - spin_unlock(>mmu_lock);
> + write_unlock(>mmu_lock);
> srcu_read_unlock(>srcu, idx);
> return 0;
> }
> @@ -1737,7 +1737,7 @@ static int kvmgt_page_track_remove(unsigned long
> handle, u64 gfn)
> return -EINVAL;
> }
>
> - spin_lock(>mmu_lock);
> + write_lock(>mmu_lock);
>
> if (!kvmgt_gfn_is_write_protected(info, gfn))
> goto out;
> @@ -1746,7 +1746,7 @@ static int kvmgt_page_track_remove(unsigned long
> handle, u64 gfn)
> kvmgt_protect_table_del(info, gfn);
>
> out:
> - spin_unlock(>mmu_lock);
> + write_unlock(>mmu_lock);
> srcu_read_unlock(>srcu, idx);
> return 0;
> }
> @@ -1772,7 +1772,7 @@ static void kvmgt_page_track_flush_slot(struct kvm *kvm,
> struct kvmgt_guest_info *info = container_of(node,
> struct kvmgt_guest_info, track_node);
>
> - spin_lock(>mmu_lock);
> + write_lock(>mmu_lock);
> for (i = 0; i < slot->npages; i++) {
> gfn = slot->base_gfn + i;
> if (kvmgt_gfn_is_write_protected(info, gfn)) {
> @@ -1781,7 +1781,7 @@ static void kvmgt_page_track_flush_slot(struct kvm *kvm,
> kvmgt_protect_table_del(info, gfn);
> }
> }
> - spin_unlock(>mmu_lock);
> + write_unlock(>mmu_lock);
> }
>
> static bool __kvmgt_vgpu_exist(struct intel_vgpu *vgpu, struct kvm *kvm)
> --
> 2.17.1
>
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [FYI PATCH] i915: kvmgt: the KVM mmu_lock is now an rwlock
On 2021.02.08 06:34:37 -0500, Paolo Bonzini wrote:
> Adjust the KVMGT page tracking callbacks.
>
> Cc: Zhenyu Wang
> Cc: Zhi Wang
> Cc: intel-gvt-...@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org
> Signed-off-by: Paolo Bonzini
> ---
Thanks for that!
Acked-by: Zhenyu Wang
> drivers/gpu/drm/i915/gvt/kvmgt.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 60f1a386dd06..b4348256ae95 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -1703,7 +1703,7 @@ static int kvmgt_page_track_add(unsigned long handle,
> u64 gfn)
> return -EINVAL;
> }
>
> - spin_lock(>mmu_lock);
> + write_lock(>mmu_lock);
>
> if (kvmgt_gfn_is_write_protected(info, gfn))
> goto out;
> @@ -1712,7 +1712,7 @@ static int kvmgt_page_track_add(unsigned long handle,
> u64 gfn)
> kvmgt_protect_table_add(info, gfn);
>
> out:
> - spin_unlock(>mmu_lock);
> + write_unlock(>mmu_lock);
> srcu_read_unlock(>srcu, idx);
> return 0;
> }
> @@ -1737,7 +1737,7 @@ static int kvmgt_page_track_remove(unsigned long
> handle, u64 gfn)
> return -EINVAL;
> }
>
> - spin_lock(>mmu_lock);
> + write_lock(>mmu_lock);
>
> if (!kvmgt_gfn_is_write_protected(info, gfn))
> goto out;
> @@ -1746,7 +1746,7 @@ static int kvmgt_page_track_remove(unsigned long
> handle, u64 gfn)
> kvmgt_protect_table_del(info, gfn);
>
> out:
> - spin_unlock(>mmu_lock);
> + write_unlock(>mmu_lock);
> srcu_read_unlock(>srcu, idx);
> return 0;
> }
> @@ -1772,7 +1772,7 @@ static void kvmgt_page_track_flush_slot(struct kvm *kvm,
> struct kvmgt_guest_info *info = container_of(node,
> struct kvmgt_guest_info, track_node);
>
> - spin_lock(>mmu_lock);
> + write_lock(>mmu_lock);
> for (i = 0; i < slot->npages; i++) {
> gfn = slot->base_gfn + i;
> if (kvmgt_gfn_is_write_protected(info, gfn)) {
> @@ -1781,7 +1781,7 @@ static void kvmgt_page_track_flush_slot(struct kvm *kvm,
> kvmgt_protect_table_del(info, gfn);
> }
> }
> - spin_unlock(>mmu_lock);
> + write_unlock(>mmu_lock);
> }
>
> static bool __kvmgt_vgpu_exist(struct intel_vgpu *vgpu, struct kvm *kvm)
> --
> 2.26.2
>
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: rework gem_create flow for upcoming extensions
== Series Details == Series: series starting with [1/2] drm/i915: rework gem_create flow for upcoming extensions URL : https://patchwork.freedesktop.org/series/86866/ State : success == Summary == CI Bug Log - changes from CI_DRM_9747_full -> Patchwork_19635_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19635_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][1] -> [TIMEOUT][2] ([i915#1037] / [i915#3063]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-tglb5/igt@gem_...@unwedge-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/shard-tglb6/igt@gem_...@unwedge-stress.html - shard-skl: [PASS][3] -> [TIMEOUT][4] ([i915#1037] / [i915#2771]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl5/igt@gem_...@unwedge-stress.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/shard-skl3/igt@gem_...@unwedge-stress.html - shard-iclb: [PASS][5] -> [TIMEOUT][6] ([i915#1037] / [i915#2481]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-iclb8/igt@gem_...@unwedge-stress.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/shard-iclb5/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][7] -> [FAIL][8] ([i915#2842]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_reloc@basic-parallel: - shard-apl: NOTRUN -> [TIMEOUT][11] ([i915#1729]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/shard-apl7/igt@gem_exec_re...@basic-parallel.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][12] ([i915#2389]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/shard-iclb2/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_userptr_blits@process-exit-mmap-busy@uc: - shard-skl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#1699]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/shard-skl10/igt@gem_userptr_blits@process-exit-mmap-b...@uc.html * igt@gem_userptr_blits@process-exit-mmap-busy@wc: - shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#1699]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/shard-apl6/igt@gem_userptr_blits@process-exit-mmap-b...@wc.html * igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-dp: - shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#1937]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/shard-apl6/igt@i915_pm_lpsp@kms-l...@kms-lpsp-dp.html * igt@i915_pm_rpm@modeset-lpsp-stress: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271]) +113 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/shard-apl6/igt@i915_pm_...@modeset-lpsp-stress.html * igt@kms_atomic_transition@plane-all-modeset-transition@dp-1-pipe-b: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#165] / [i915#180] / [i915#78]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-kbl4/igt@kms_atomic_transition@plane-all-modeset-transit...@dp-1-pipe-b.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/shard-kbl2/igt@kms_atomic_transition@plane-all-modeset-transit...@dp-1-pipe-b.html * igt@kms_chamelium@hdmi-edid-change-during-suspend: - shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827]) +9 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/shard-apl1/igt@kms_chamel...@hdmi-edid-change-during-suspend.html * igt@kms_color@pipe-b-ctm-0-25: - shard-skl: [PASS][20] -> [DMESG-WARN][21] ([i915#1982]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl10/igt@kms_co...@pipe-b-ctm-0-25.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/shard-skl6/igt@kms_co...@pipe-b-ctm-0-25.html * igt@kms_color_chamelium@pipe-d-ctm-0-5: - shard-tglb: NOTRUN -> [SKIP][22] ([fdo#109284] / [fdo#111827]) +2 similar issues [22]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] i915/perf: Store a mask of valid OA formats for a platform
== Series Details == Series: series starting with [1/3] i915/perf: Store a mask of valid OA formats for a platform URL : https://patchwork.freedesktop.org/series/86865/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9747_full -> Patchwork_19634_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19634_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19634_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19634_full: ### IGT changes ### Possible regressions * igt@kms_cursor_legacy@short-flip-after-cursor-atomic-transitions-varying-size: - shard-hsw: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-hsw6/igt@kms_cursor_leg...@short-flip-after-cursor-atomic-transitions-varying-size.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/shard-hsw1/igt@kms_cursor_leg...@short-flip-after-cursor-atomic-transitions-varying-size.html Known issues Here are the changes found in Patchwork_19634_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@smoketest: - shard-iclb: [PASS][3] -> [FAIL][4] ([i915#2896]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-iclb2/igt@gem_ctx_persiste...@smoketest.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/shard-iclb6/igt@gem_ctx_persiste...@smoketest.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][5] -> [TIMEOUT][6] ([i915#1037] / [i915#3063]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-tglb5/igt@gem_...@unwedge-stress.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/shard-tglb3/igt@gem_...@unwedge-stress.html * igt@gem_exec_balancer@hang: - shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([i915#1895] / [i915#2295] / [i915#3031]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-iclb8/igt@gem_exec_balan...@hang.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/shard-iclb1/igt@gem_exec_balan...@hang.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2846]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-kbl1/igt@gem_exec_f...@basic-deadline.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/shard-kbl4/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none@vecs0: - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-kbl6/igt@gem_exec_fair@basic-n...@vecs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/shard-kbl6/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_reloc@basic-parallel: - shard-kbl: NOTRUN -> [TIMEOUT][13] ([i915#1729]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/shard-kbl7/igt@gem_exec_re...@basic-parallel.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][14] ([i915#2389]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/shard-iclb2/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_exec_schedule@u-fairslice@bcs0: - shard-tglb: [PASS][15] -> [DMESG-WARN][16] ([i915#2803]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-tglb7/igt@gem_exec_schedule@u-fairsl...@bcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/shard-tglb1/igt@gem_exec_schedule@u-fairsl...@bcs0.html * igt@gem_exec_schedule@u-fairslice@rcs0: - shard-iclb: [PASS][17] -> [DMESG-WARN][18] ([i915#2803]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-iclb4/igt@gem_exec_schedule@u-fairsl...@rcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/shard-iclb3/igt@gem_exec_schedule@u-fairsl...@rcs0.html * igt@gem_exec_schedule@u-fairslice@vcs0: - shard-skl: [PASS][19] -> [DMESG-WARN][20] ([i915#1610] / [i915#2803]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl7/igt@gem_exec_schedule@u-fairsl...@vcs0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/shard-skl7/igt@gem_exec_schedule@u-fairsl...@vcs0.html * igt@gem_render_copy@linear-to-vebox-y-tiled: - shard-apl: NOTRUN -> [SKIP][21] ([fdo#109271]) +74 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/shard-apl7/igt@gem_render_c...@linear-to-vebox-y-tiled.html *
[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Extract DPCD backlight helpers from i915, add support in nouveau (rev6)
== Series Details == Series: drm: Extract DPCD backlight helpers from i915, add support in nouveau (rev6) URL : https://patchwork.freedesktop.org/series/84754/ State : success == Summary == CI Bug Log - changes from CI_DRM_9747 -> Patchwork_19636 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/index.html Known issues Here are the changes found in Patchwork_19636 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-gfx0: - fi-cfl-8700k: NOTRUN -> [SKIP][1] ([fdo#109271]) +25 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/fi-cfl-8700k/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html * igt@debugfs_test@read_all_entries: - fi-tgl-y: [PASS][2] -> [DMESG-WARN][3] ([i915#402]) +2 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@debugfs_test@read_all_entries.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/fi-tgl-y/igt@debugfs_test@read_all_entries.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271]) +23 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_exec_suspend@basic-s0: - fi-glk-dsi: [PASS][5] -> [DMESG-WARN][6] ([i915#2943]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-glk-dsi/igt@gem_exec_susp...@basic-s0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/fi-glk-dsi/igt@gem_exec_susp...@basic-s0.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html - fi-cfl-8700k: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#2190]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/fi-cfl-8700k/igt@gem_huc_c...@huc-copy.html * igt@i915_pm_rpm@module-reload: - fi-byt-j1900: [PASS][9] -> [INCOMPLETE][10] ([i915#142] / [i915#2405]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-byt-j1900/igt@i915_pm_...@module-reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/fi-byt-j1900/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][11] ([i915#1886] / [i915#2291]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-soraka: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@vga-edid-read: - fi-cfl-8700k: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/fi-cfl-8700k/igt@kms_chamel...@vga-edid-read.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-cfl-8700k: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#533]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/fi-cfl-8700k/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html - fi-kbl-soraka: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#533]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@runner@aborted: - fi-bdw-5557u: NOTRUN -> [FAIL][16] ([i915#1602] / [i915#2029] / [i915#2369]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/fi-bdw-5557u/igt@run...@aborted.html - fi-byt-j1900: NOTRUN -> [FAIL][17] ([i915#1814] / [i915#2505]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/fi-byt-j1900/igt@run...@aborted.html Possible fixes * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [DMESG-WARN][18] ([i915#402]) -> [PASS][19] +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19636/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#142]: https://gitlab.freedesktop.org/drm/intel/issues/142 [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602 [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814 [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886 [i915#2029]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm: Extract DPCD backlight helpers from i915, add support in nouveau (rev6)
== Series Details == Series: drm: Extract DPCD backlight helpers from i915, add support in nouveau (rev6) URL : https://patchwork.freedesktop.org/series/84754/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Extract DPCD backlight helpers from i915, add support in nouveau (rev6)
== Series Details ==
Series: drm: Extract DPCD backlight helpers from i915, add support in nouveau
(rev6)
URL : https://patchwork.freedesktop.org/series/84754/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
745f01c7a14e drm/nouveau/kms/nv40-/backlight: Assign prop type once
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
total: 0 errors, 1 warnings, 0 checks, 22 lines checked
66de908f9ecf drm/nouveau/kms: Don't probe eDP connectors more then once
-:6: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#6:
eDP doesn't do hotplugging, so there's no reason for us to reprobe it (unless a
-:23: CHECK:CAMELCASE: Avoid CamelCase:
#23: FILE: drivers/gpu/drm/nouveau/nouveau_connector.c:560:
+ if (nv_connector->type == DCB_CONNECTOR_eDP &&
total: 0 errors, 1 warnings, 1 checks, 12 lines checked
49dd6cc82539 drm/i915/dpcd_bl: Remove redundant AUX backlight frequency
calculations
56508fe0bb5b drm/i915/dpcd_bl: Handle drm_dpcd_read/write() return values
correctly
38874d7f1d48 drm/i915/dpcd_bl: Cleanup intel_dp_aux_vesa_enable_backlight() a
bit
38cd83dcce26 drm/i915/dpcd_bl: Cache some backlight capabilities in
intel_panel.backlight
cebc38174e92 drm/i915/dpcd_bl: Move VESA backlight enabling code closer together
2be662fd3ce4 drm/i915/dpcd_bl: Return early in vesa_calc_max_backlight if we
can't read PWMGEN_BIT_COUNT
95bad7e9d9c8 drm/i915/dpcd_bl: Print return codes for VESA backlight failures
4c1c85984fc2 drm/dp: Extract i915's eDP backlight code into DRM helpers
b9309219525b drm/nouveau/kms/nv50-: Add basic DPCD backlight support for nouveau
-:238: CHECK:CAMELCASE: Avoid CamelCase:
#238: FILE: drivers/gpu/drm/nouveau/nouveau_backlight.c:299:
+ if (nv_conn->type == DCB_CONNECTOR_eDP) {
total: 0 errors, 0 warnings, 1 checks, 302 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v4 11/11] drm/nouveau/kms/nv50-: Add basic DPCD backlight support for nouveau
This adds support for controlling panel backlights over eDP using VESA's
standard backlight control interface. Luckily, Nvidia was cool enough to
never come up with their own proprietary backlight control interface (at
least, not any that I or the laptop manufacturers I've talked to are aware
of), so this should work for any laptop panels which support the VESA
backlight control interface.
Note that we don't yet provide the panel backlight frequency to the DRM DP
backlight helpers. This should be fine for the time being, since it's not
required to get basic backlight controls working.
For reference: there's some mentions of PWM backlight values in
nouveau_reg.h, but I'm not sure these are the values we would want to use.
If we figure out how to get this information in the future, we'll have the
benefit of more granular backlight control.
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 28
drivers/gpu/drm/nouveau/nouveau_backlight.c | 166 ++--
drivers/gpu/drm/nouveau/nouveau_connector.h | 9 +-
drivers/gpu/drm/nouveau/nouveau_encoder.h | 1 +
4 files changed, 186 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 196612addfd6..4a1819b02084 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1647,15 +1648,30 @@ nv50_sor_update(struct nouveau_encoder *nv_encoder, u8
head,
core->func->sor->ctrl(core, nv_encoder->or, nv_encoder->ctrl, asyh);
}
+/* TODO: Should we extend this to PWM-only backlights?
+ * As well, should we add a DRM helper for waiting for the backlight to
acknowledge
+ * the panel backlight has been shut off? Intel doesn't seem to do this, and
uses a
+ * fixed time delay from the vbios…
+ */
static void
nv50_sor_atomic_disable(struct drm_encoder *encoder, struct drm_atomic_state
*state)
{
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
+ struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc);
struct nouveau_connector *nv_connector =
nv50_outp_get_old_connector(state, nv_encoder);
+ struct nouveau_backlight *backlight = nv_connector->backlight;
struct drm_dp_aux *aux = _connector->aux;
+ int ret;
u8 pwr;
+ if (backlight && backlight->uses_dpcd) {
+ ret = drm_edp_backlight_disable(aux, >edp_info);
+ if (ret < 0)
+ NV_ERROR(drm, "Failed to disable backlight on
[CONNECTOR:%d:%s]: %d\n",
+nv_connector->base.base.id,
nv_connector->base.name, ret);
+ }
+
if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
int ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, );
@@ -1694,6 +1710,9 @@ nv50_sor_atomic_enable(struct drm_encoder *encoder,
struct drm_atomic_state *sta
struct drm_device *dev = encoder->dev;
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_connector *nv_connector;
+#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
+ struct nouveau_backlight *backlight;
+#endif
struct nvbios *bios = >vbios;
bool hda = false;
u8 proto = NV507D_SOR_SET_CONTROL_PROTOCOL_CUSTOM;
@@ -1768,6 +1787,14 @@ nv50_sor_atomic_enable(struct drm_encoder *encoder,
struct drm_atomic_state *sta
proto = NV887D_SOR_SET_CONTROL_PROTOCOL_DP_B;
nv50_audio_enable(encoder, nv_crtc, nv_connector, state, mode);
+
+#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
+ backlight = nv_connector->backlight;
+ if (backlight && backlight->uses_dpcd)
+ drm_edp_backlight_enable(_connector->aux,
>edp_info,
+
(u16)backlight->dev->props.brightness);
+#endif
+
break;
default:
BUG();
@@ -2293,6 +2320,7 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state
*state)
nv50_crc_atomic_start_reporting(state);
if (!flushed)
nv50_crc_atomic_release_notifier_contexts(state);
+
drm_atomic_helper_commit_hw_done(state);
drm_atomic_helper_cleanup_planes(dev, state);
drm_atomic_helper_commit_cleanup_done(state);
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 42b498e7e2bf..a11811b5e63e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -42,11 +42,6 @@
static struct ida bl_ida;
#define BL_NAME_SIZE 15 // 12 for name + 2 for digits + 1 for '\0'
-struct nouveau_backlight {
- struct backlight_device *dev;
- int id;
-};
-
static bool
[Intel-gfx] [RFC v4 10/11] drm/dp: Extract i915's eDP backlight code into DRM helpers
Since we're about to implement eDP backlight support in nouveau using the
standard protocol from VESA, we might as well just take the code that's
already written for this and move it into a set of shared DRM helpers.
Note that these helpers are intended to handle DPCD related backlight
control bits such as setting the brightness level over AUX, probing the
backlight's TCON, enabling/disabling the backlight over AUX if supported,
etc. Any PWM-related portions of backlight control are explicitly left up
to the driver, as these will vary from platform to platform.
The only exception to this is the calculation of the PWM frequency
pre-divider value. This is because the only platform-specific information
required for this is the PWM frequency of the panel, which the driver is
expected to provide if available. The actual algorithm for calculating this
value is standard and is defined in the eDP specification from VESA.
Note that these helpers do not yet implement the full range of features
the VESA backlight interface provides, and only provide the following
functionality (all of which was already present in i915's DPCD backlight
support):
* Basic control of brightness levels
* Basic probing of backlight capabilities
* Helpers for enabling and disabling the backlight
v3:
* Split out changes to i915's backlight code to separate patches to make it
easier to review
v4:
* Style/spelling changes from Thomas Zimmermann
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
drivers/gpu/drm/drm_dp_helper.c | 332 ++
.../drm/i915/display/intel_display_types.h| 5 +-
.../drm/i915/display/intel_dp_aux_backlight.c | 285 ++-
include/drm/drm_dp_helper.h | 48 +++
4 files changed, 412 insertions(+), 258 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index eedbb48815b7..1a3d4679d720 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -3082,3 +3082,335 @@ int drm_dp_pcon_convert_rgb_to_ycbcr(struct drm_dp_aux
*aux, u8 color_spc)
return 0;
}
EXPORT_SYMBOL(drm_dp_pcon_convert_rgb_to_ycbcr);
+
+/**
+ * drm_edp_backlight_set_level() - Set the backlight level of an eDP panel via
AUX
+ * @aux: The DP AUX channel to use
+ * @bl: Backlight capability info from drm_edp_backlight_init()
+ * @level: The brightness level to set
+ *
+ * Sets the brightness level of an eDP panel's backlight. Note that the
panel's backlight must
+ * already have been enabled by the driver by calling
drm_edp_backlight_enable().
+ *
+ * Returns: %0 on success, negative error code on failure
+ */
+int drm_edp_backlight_set_level(struct drm_dp_aux *aux, const struct
drm_edp_backlight_info *bl,
+ u16 level)
+{
+ int ret;
+ u8 buf[2] = { 0 };
+
+ if (bl->lsb_reg_used) {
+ buf[0] = (level & 0xff00) >> 8;
+ buf[1] = (level & 0x00ff);
+ } else {
+ buf[0] = level;
+ }
+
+ ret = drm_dp_dpcd_write(aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB, buf,
sizeof(buf));
+ if (ret != sizeof(buf)) {
+ DRM_ERROR("%s: Failed to write aux backlight level: %d\n",
aux->name, ret);
+ return ret < 0 ? ret : -EIO;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_edp_backlight_set_level);
+
+static int
+drm_edp_backlight_set_enable(struct drm_dp_aux *aux, const struct
drm_edp_backlight_info *bl,
+bool enable)
+{
+ int ret;
+ u8 buf;
+
+ /* The panel uses something other then DPCD for enabling its backlight
*/
+ if (!bl->aux_enable)
+ return 0;
+
+ ret = drm_dp_dpcd_readb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, );
+ if (ret != 1) {
+ DRM_ERROR("%s: Failed to read eDP display control register:
%d\n", aux->name, ret);
+ return ret < 0 ? ret : -EIO;
+ }
+ if (enable)
+ buf |= DP_EDP_BACKLIGHT_ENABLE;
+ else
+ buf &= ~DP_EDP_BACKLIGHT_ENABLE;
+
+ ret = drm_dp_dpcd_writeb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, buf);
+ if (ret != 1) {
+ DRM_ERROR("%s: Failed to write eDP display control register:
%d\n", aux->name, ret);
+ return ret < 0 ? ret : -EIO;
+ }
+
+ return 0;
+}
+
+/**
+ * drm_edp_backlight_enable() - Enable an eDP panel's backlight using DPCD
+ * @aux: The DP AUX channel to use
+ * @bl: Backlight capability info from drm_edp_backlight_init()
+ * @level: The initial backlight level to set via AUX, if there is one
+ *
+ * This function handles enabling DPCD backlight controls on a panel over
DPCD, while additionally
+ * restoring any important backlight state such as the given backlight level,
the brightness byte
+ * count, backlight frequency, etc.
+ *
+ * Note that certain panels, while supporting brightness level controls over
DPCD, may not
[Intel-gfx] [RFC v4 09/11] drm/i915/dpcd_bl: Print return codes for VESA backlight failures
Also, stop printing the DPCD register that failed, and just describe it
instead. Saves us from having to look up each register offset when reading
through kernel logs (plus, DPCD dumping with drm.debug |= 0x100 will give
us that anyway).
Signed-off-by: Lyude Paul
---
.../drm/i915/display/intel_dp_aux_backlight.c | 101 +-
1 file changed, 52 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index a139f0e08839..a98d9bd4b0ed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -274,14 +274,12 @@ static bool intel_dp_aux_vesa_backlight_dpcd_mode(struct
intel_connector *connec
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ int ret;
u8 mode_reg;
- if (drm_dp_dpcd_readb(_dp->aux,
- DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
- _reg) != 1) {
- drm_dbg_kms(>drm,
- "Failed to read the DPCD register 0x%x\n",
- DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
+ ret = drm_dp_dpcd_readb(_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _reg);
+ if (ret != 1) {
+ drm_dbg_kms(>drm, "Failed to read backlight mode: %d\n",
ret);
return false;
}
@@ -297,6 +295,7 @@ static u32 intel_dp_aux_vesa_get_backlight(struct
intel_connector *connector, en
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ int ret;
u8 read_val[2] = { 0x0 };
u16 level = 0;
@@ -307,10 +306,10 @@ static u32 intel_dp_aux_vesa_get_backlight(struct
intel_connector *connector, en
if (!intel_dp_aux_vesa_backlight_dpcd_mode(connector))
return connector->panel.backlight.max;
- if (drm_dp_dpcd_read(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
_val,
-sizeof(read_val)) != sizeof(read_val)) {
- drm_dbg_kms(>drm, "Failed to read DPCD register 0x%x\n",
- DP_EDP_BACKLIGHT_BRIGHTNESS_MSB);
+ ret = drm_dp_dpcd_read(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
_val,
+ sizeof(read_val));
+ if (ret != sizeof(read_val)) {
+ drm_dbg_kms(>drm, "Failed to read brightness level:
%d\n", ret);
return 0;
}
@@ -333,6 +332,7 @@ intel_dp_aux_vesa_set_backlight(const struct
drm_connector_state *conn_state,
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ int ret;
u8 vals[2] = { 0x0 };
/* Write the MSB and/or LSB */
@@ -343,10 +343,10 @@ intel_dp_aux_vesa_set_backlight(const struct
drm_connector_state *conn_state,
vals[0] = level;
}
- if (drm_dp_dpcd_write(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
vals,
- sizeof(vals)) != sizeof(vals)) {
- drm_dbg_kms(>drm,
- "Failed to write aux backlight level\n");
+ ret = drm_dp_dpcd_write(_dp->aux,
DP_EDP_BACKLIGHT_BRIGHTNESS_MSB, vals,
+ sizeof(vals));
+ if (ret != sizeof(vals)) {
+ drm_dbg_kms(>drm, "Failed to write aux backlight level:
%d\n", ret);
return;
}
}
@@ -355,26 +355,28 @@ static void set_vesa_backlight_enable(struct
intel_connector *connector, bool en
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ int ret;
u8 reg_val = 0;
/* Early return when display use other mechanism to enable backlight. */
if (!connector->panel.backlight.edp.vesa.aux_enable)
return;
- if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
_val) != 1) {
- drm_dbg_kms(>drm, "Failed to read DPCD register 0x%x\n",
- DP_EDP_DISPLAY_CONTROL_REGISTER);
+ ret = drm_dp_dpcd_readb(_dp->aux,
DP_EDP_DISPLAY_CONTROL_REGISTER, _val);
+ if (ret != 1) {
+ drm_dbg_kms(>drm, "Failed to read eDP display control
register: %d\n", ret);
return;
}
+
if (enable)
reg_val |= DP_EDP_BACKLIGHT_ENABLE;
else
reg_val &= ~(DP_EDP_BACKLIGHT_ENABLE);
- if (drm_dp_dpcd_writeb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
- reg_val) != 1) {
- drm_dbg_kms(>drm, "Failed to %s aux backlight\n",
- enable ? "enable" : "disable");
+
[Intel-gfx] [RFC v4 05/11] drm/i915/dpcd_bl: Cleanup intel_dp_aux_vesa_enable_backlight() a bit
Get rid of the extraneous switch case in here, and just open code
edp_backlight_mode as we only ever use it once.
v4:
* Check that backlight mode is DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD, not
DP_EDP_BACKLIGHT_CONTROL_MODE_MASK - imirkin
Signed-off-by: Lyude Paul
---
.../gpu/drm/i915/display/intel_dp_aux_backlight.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index c37ccc8538cb..57218faed4a3 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -382,7 +382,7 @@ intel_dp_aux_vesa_enable_backlight(const struct
intel_crtc_state *crtc_state,
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_panel *panel = >panel;
- u8 dpcd_buf, new_dpcd_buf, edp_backlight_mode;
+ u8 dpcd_buf, new_dpcd_buf;
u8 pwmgen_bit_count = panel->backlight.edp.vesa.pwmgen_bit_count;
if (drm_dp_dpcd_readb(_dp->aux,
@@ -393,12 +393,8 @@ intel_dp_aux_vesa_enable_backlight(const struct
intel_crtc_state *crtc_state,
}
new_dpcd_buf = dpcd_buf;
- edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
- switch (edp_backlight_mode) {
- case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
- case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
- case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
+ if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) !=
DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
@@ -406,13 +402,6 @@ intel_dp_aux_vesa_enable_backlight(const struct
intel_crtc_state *crtc_state,
pwmgen_bit_count) != 1)
drm_dbg_kms(>drm,
"Failed to write aux pwmgen bit count\n");
-
- break;
-
- /* Do nothing when it is already DPCD mode */
- case DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD:
- default:
- break;
}
if (panel->backlight.edp.vesa.pwm_freq_pre_divider) {
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v4 08/11] drm/i915/dpcd_bl: Return early in vesa_calc_max_backlight if we can't read PWMGEN_BIT_COUNT
If we can't read DP_EDP_PWMGEN_BIT_COUNT in
intel_dp_aux_vesa_calc_max_backlight() but do have a valid PWM frequency
defined in the VBT, we'll keep going in the function until we inevitably
fail on reading DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN. There's not much point in
doing this, so just return early.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 611eb3a7cc08..a139f0e08839 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -449,11 +449,14 @@ static u32 intel_dp_aux_vesa_calc_max_backlight(struct
intel_connector *connecto
int freq, fxp, fxp_min, fxp_max, fxp_actual, f = 1;
u8 pn, pn_min, pn_max;
- if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_PWMGEN_BIT_COUNT, ) ==
1) {
- pn &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
- max_backlight = (1 << pn) - 1;
+ if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_PWMGEN_BIT_COUNT, ) !=
1) {
+ drm_dbg_kms(>drm, "Failed to read pwmgen bit count
cap\n");
+ return 0;
}
+ pn &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
+ max_backlight = (1 << pn) - 1;
+
/* Find desired value of (F x P)
* Note that, if F x P is out of supported range, the maximum value or
* minimum value will applied automatically. So no need to check that.
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v4 03/11] drm/i915/dpcd_bl: Remove redundant AUX backlight frequency calculations
Noticed this while moving all of the VESA backlight code in i915 over to
DRM helpers: it would appear that we calculate the frequency value we want
to write to DP_EDP_BACKLIGHT_FREQ_SET twice even though this value never
actually changes during runtime. So, let's simplify things by just caching
this value in intel_panel.backlight, and re-writing it as-needed.
Changes since v1:
* Wrap panel->backlight.edp.vesa.pwm_freq_pre_divider in
DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP check - Jani
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
.../drm/i915/display/intel_display_types.h| 1 +
.../drm/i915/display/intel_dp_aux_backlight.c | 65 ++-
2 files changed, 20 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ebaa9d0ed376..1217cde04f0b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -265,6 +265,7 @@ struct intel_panel {
union {
struct {
u8 pwmgen_bit_count;
+ u8 pwm_freq_pre_divider;
} vesa;
struct {
bool sdr_uses_aux;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 651884390137..62294967f430 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -373,50 +373,6 @@ intel_dp_aux_vesa_set_backlight(const struct
drm_connector_state *conn_state,
}
}
-/*
- * Set PWM Frequency divider to match desired frequency in vbt.
- * The PWM Frequency is calculated as 27Mhz / (F x P).
- * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
- * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
- * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
- * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
- */
-static bool intel_dp_aux_vesa_set_pwm_freq(struct intel_connector *connector)
-{
- struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
- struct intel_dp *intel_dp = intel_attached_dp(connector);
- const u8 pn = connector->panel.backlight.edp.vesa.pwmgen_bit_count;
- int freq, fxp, f, fxp_actual, fxp_min, fxp_max;
-
- freq = dev_priv->vbt.backlight.pwm_freq_hz;
- if (!freq) {
- drm_dbg_kms(_priv->drm,
- "Use panel default backlight frequency\n");
- return false;
- }
-
- fxp = DIV_ROUND_CLOSEST(KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ), freq);
- f = clamp(DIV_ROUND_CLOSEST(fxp, 1 << pn), 1, 255);
- fxp_actual = f << pn;
-
- /* Ensure frequency is within 25% of desired value */
- fxp_min = DIV_ROUND_CLOSEST(fxp * 3, 4);
- fxp_max = DIV_ROUND_CLOSEST(fxp * 5, 4);
-
- if (fxp_min > fxp_actual || fxp_actual > fxp_max) {
- drm_dbg_kms(_priv->drm, "Actual frequency out of range\n");
- return false;
- }
-
- if (drm_dp_dpcd_writeb(_dp->aux,
- DP_EDP_BACKLIGHT_FREQ_SET, (u8) f) < 0) {
- drm_dbg_kms(_priv->drm,
- "Failed to write aux backlight freq\n");
- return false;
- }
- return true;
-}
-
static void
intel_dp_aux_vesa_enable_backlight(const struct intel_crtc_state *crtc_state,
const struct drm_connector_state
*conn_state, u32 level)
@@ -459,9 +415,13 @@ intel_dp_aux_vesa_enable_backlight(const struct
intel_crtc_state *crtc_state,
break;
}
- if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP)
- if (intel_dp_aux_vesa_set_pwm_freq(connector))
+ if (panel->backlight.edp.vesa.pwm_freq_pre_divider) {
+ if (drm_dp_dpcd_writeb(_dp->aux,
DP_EDP_BACKLIGHT_FREQ_SET,
+
panel->backlight.edp.vesa.pwm_freq_pre_divider) == 1)
new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
+ else
+ drm_dbg_kms(>drm, "Failed to write aux backlight
frequency\n");
+ }
if (new_dpcd_buf != dpcd_buf) {
if (drm_dp_dpcd_writeb(_dp->aux,
@@ -482,6 +442,14 @@ static void intel_dp_aux_vesa_disable_backlight(const
struct drm_connector_state
false);
}
+/*
+ * Compute PWM frequency divider value based off the frequency provided to us
by the vbt.
+ * The PWM Frequency is calculated as 27Mhz / (F x P).
+ * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
+ * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
+ * - Where P =
[Intel-gfx] [RFC v4 07/11] drm/i915/dpcd_bl: Move VESA backlight enabling code closer together
No functional changes, just move set_vesa_backlight_enable() closer to it's
only caller: intel_dp_aux_vesa_enable_backlight().
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
.../drm/i915/display/intel_dp_aux_backlight.c | 54 +--
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 74001b479d80..611eb3a7cc08 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -270,33 +270,6 @@ intel_dp_aux_hdr_setup_backlight(struct intel_connector
*connector, enum pipe pi
}
/* VESA backlight callbacks */
-static void set_vesa_backlight_enable(struct intel_connector *connector, bool
enable)
-{
- struct intel_dp *intel_dp = intel_attached_dp(connector);
- struct drm_i915_private *i915 = dp_to_i915(intel_dp);
- u8 reg_val = 0;
-
- /* Early return when display use other mechanism to enable backlight. */
- if (!connector->panel.backlight.edp.vesa.aux_enable)
- return;
-
- if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
_val) != 1) {
- drm_dbg_kms(>drm, "Failed to read DPCD register 0x%x\n",
- DP_EDP_DISPLAY_CONTROL_REGISTER);
- return;
- }
- if (enable)
- reg_val |= DP_EDP_BACKLIGHT_ENABLE;
- else
- reg_val &= ~(DP_EDP_BACKLIGHT_ENABLE);
-
- if (drm_dp_dpcd_writeb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
- reg_val) != 1) {
- drm_dbg_kms(>drm, "Failed to %s aux backlight\n",
- enable ? "enable" : "disable");
- }
-}
-
static bool intel_dp_aux_vesa_backlight_dpcd_mode(struct intel_connector
*connector)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -378,6 +351,33 @@ intel_dp_aux_vesa_set_backlight(const struct
drm_connector_state *conn_state,
}
}
+static void set_vesa_backlight_enable(struct intel_connector *connector, bool
enable)
+{
+ struct intel_dp *intel_dp = intel_attached_dp(connector);
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ u8 reg_val = 0;
+
+ /* Early return when display use other mechanism to enable backlight. */
+ if (!connector->panel.backlight.edp.vesa.aux_enable)
+ return;
+
+ if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
_val) != 1) {
+ drm_dbg_kms(>drm, "Failed to read DPCD register 0x%x\n",
+ DP_EDP_DISPLAY_CONTROL_REGISTER);
+ return;
+ }
+ if (enable)
+ reg_val |= DP_EDP_BACKLIGHT_ENABLE;
+ else
+ reg_val &= ~(DP_EDP_BACKLIGHT_ENABLE);
+
+ if (drm_dp_dpcd_writeb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
+ reg_val) != 1) {
+ drm_dbg_kms(>drm, "Failed to %s aux backlight\n",
+ enable ? "enable" : "disable");
+ }
+}
+
static void
intel_dp_aux_vesa_enable_backlight(const struct intel_crtc_state *crtc_state,
const struct drm_connector_state
*conn_state, u32 level)
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v4 06/11] drm/i915/dpcd_bl: Cache some backlight capabilities in intel_panel.backlight
Since we're about to be moving this code into shared DRM helpers, we might
as well start to cache certain backlight capabilities that can be
determined from the EDP DPCD, and are likely to be relevant to the majority
of drivers using said helpers. The main purpose of this is just to prevent
every driver from having to check everything against the eDP DPCD using DP
macros, which makes the code slightly easier to read (especially since the
names of some of the eDP capabilities don't exactly match up with what we
actually need to use them for, like DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT
for instance).
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
.../drm/i915/display/intel_display_types.h| 2 ++
.../drm/i915/display/intel_dp_aux_backlight.c | 29 ---
2 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 1217cde04f0b..1d8984077e8a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -266,6 +266,8 @@ struct intel_panel {
struct {
u8 pwmgen_bit_count;
u8 pwm_freq_pre_divider;
+ bool lsb_reg_used;
+ bool aux_enable;
} vesa;
struct {
bool sdr_uses_aux;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 57218faed4a3..74001b479d80 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -270,13 +270,14 @@ intel_dp_aux_hdr_setup_backlight(struct intel_connector
*connector, enum pipe pi
}
/* VESA backlight callbacks */
-static void set_vesa_backlight_enable(struct intel_dp *intel_dp, bool enable)
+static void set_vesa_backlight_enable(struct intel_connector *connector, bool
enable)
{
+ struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 reg_val = 0;
/* Early return when display use other mechanism to enable backlight. */
- if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
+ if (!connector->panel.backlight.edp.vesa.aux_enable)
return;
if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
_val) != 1) {
@@ -339,9 +340,11 @@ static u32 intel_dp_aux_vesa_get_backlight(struct
intel_connector *connector, en
DP_EDP_BACKLIGHT_BRIGHTNESS_MSB);
return 0;
}
- level = read_val[0];
- if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
+
+ if (connector->panel.backlight.edp.vesa.lsb_reg_used)
level = (read_val[0] << 8 | read_val[1]);
+ else
+ level = read_val[0];
return level;
}
@@ -359,13 +362,14 @@ intel_dp_aux_vesa_set_backlight(const struct
drm_connector_state *conn_state,
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 vals[2] = { 0x0 };
- vals[0] = level;
-
/* Write the MSB and/or LSB */
- if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT) {
+ if (connector->panel.backlight.edp.vesa.lsb_reg_used) {
vals[0] = (level & 0xFF00) >> 8;
vals[1] = (level & 0xFF);
+ } else {
+ vals[0] = level;
}
+
if (drm_dp_dpcd_write(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
vals,
sizeof(vals)) != sizeof(vals)) {
drm_dbg_kms(>drm,
@@ -419,14 +423,13 @@ intel_dp_aux_vesa_enable_backlight(const struct
intel_crtc_state *crtc_state,
}
intel_dp_aux_vesa_set_backlight(conn_state, level);
- set_vesa_backlight_enable(intel_dp, true);
+ set_vesa_backlight_enable(connector, true);
}
static void intel_dp_aux_vesa_disable_backlight(const struct
drm_connector_state *old_conn_state,
u32 level)
{
-
set_vesa_backlight_enable(enc_to_intel_dp(to_intel_encoder(old_conn_state->best_encoder)),
- false);
+
set_vesa_backlight_enable(to_intel_connector(old_conn_state->connector), false);
}
/*
@@ -524,8 +527,14 @@ static u32 intel_dp_aux_vesa_calc_max_backlight(struct
intel_connector *connecto
static int intel_dp_aux_vesa_setup_backlight(struct intel_connector *connector,
enum pipe pipe)
{
+ struct intel_dp *intel_dp = intel_attached_dp(connector);
struct intel_panel *panel = >panel;
+ if (intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP)
+ panel->backlight.edp.vesa.aux_enable
[Intel-gfx] [RFC v4 04/11] drm/i915/dpcd_bl: Handle drm_dpcd_read/write() return values correctly
This is kind of an annoying aspect of DRM's DP helpers:
drm_dp_dpcd_readb/writeb() return the size of bytes read/written on
success, thus we want to check against that instead of checking if the
return value is less than 0.
I'll probably be fixing this in the near future once I start doing DP work
again, also because I'd rather not mix a tree-wide refactor like that in
with a patch series intended to be around introducing DP backlight helpers.
So, for now let's just handle the return values from each function
correctly.
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
.../drm/i915/display/intel_dp_aux_backlight.c | 41 +--
1 file changed, 19 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 62294967f430..c37ccc8538cb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -107,7 +107,7 @@ intel_dp_aux_supports_hdr_backlight(struct intel_connector
*connector)
u8 tcon_cap[4];
ret = drm_dp_dpcd_read(aux, INTEL_EDP_HDR_TCON_CAP0, tcon_cap,
sizeof(tcon_cap));
- if (ret < 0)
+ if (ret != sizeof(tcon_cap))
return false;
if (!(tcon_cap[1] & INTEL_EDP_HDR_TCON_BRIGHTNESS_NITS_CAP))
@@ -137,7 +137,7 @@ intel_dp_aux_hdr_get_backlight(struct intel_connector
*connector, enum pipe pipe
u8 tmp;
u8 buf[2] = { 0 };
- if (drm_dp_dpcd_readb(_dp->aux, INTEL_EDP_HDR_GETSET_CTRL_PARAMS,
) < 0) {
+ if (drm_dp_dpcd_readb(_dp->aux, INTEL_EDP_HDR_GETSET_CTRL_PARAMS,
) != 1) {
drm_err(>drm, "Failed to read current backlight mode from
DPCD\n");
return 0;
}
@@ -153,7 +153,8 @@ intel_dp_aux_hdr_get_backlight(struct intel_connector
*connector, enum pipe pipe
return panel->backlight.max;
}
- if (drm_dp_dpcd_read(_dp->aux, INTEL_EDP_BRIGHTNESS_NITS_LSB,
buf, sizeof(buf)) < 0) {
+ if (drm_dp_dpcd_read(_dp->aux, INTEL_EDP_BRIGHTNESS_NITS_LSB, buf,
+sizeof(buf)) != sizeof(buf)) {
drm_err(>drm, "Failed to read brightness from DPCD\n");
return 0;
}
@@ -172,7 +173,8 @@ intel_dp_aux_hdr_set_aux_backlight(const struct
drm_connector_state *conn_state,
buf[0] = level & 0xFF;
buf[1] = (level & 0xFF00) >> 8;
- if (drm_dp_dpcd_write(_dp->aux, INTEL_EDP_BRIGHTNESS_NITS_LSB,
buf, 4) < 0)
+ if (drm_dp_dpcd_write(_dp->aux, INTEL_EDP_BRIGHTNESS_NITS_LSB,
buf,
+ sizeof(buf)) != sizeof(buf))
drm_err(dev, "Failed to write brightness level to DPCD\n");
}
@@ -203,7 +205,7 @@ intel_dp_aux_hdr_enable_backlight(const struct
intel_crtc_state *crtc_state,
u8 old_ctrl, ctrl;
ret = drm_dp_dpcd_readb(_dp->aux,
INTEL_EDP_HDR_GETSET_CTRL_PARAMS, _ctrl);
- if (ret < 0) {
+ if (ret != 1) {
drm_err(>drm, "Failed to read current backlight control
mode: %d\n", ret);
return;
}
@@ -221,7 +223,7 @@ intel_dp_aux_hdr_enable_backlight(const struct
intel_crtc_state *crtc_state,
}
if (ctrl != old_ctrl)
- if (drm_dp_dpcd_writeb(_dp->aux,
INTEL_EDP_HDR_GETSET_CTRL_PARAMS, ctrl) < 0)
+ if (drm_dp_dpcd_writeb(_dp->aux,
INTEL_EDP_HDR_GETSET_CTRL_PARAMS, ctrl) != 1)
drm_err(>drm, "Failed to configure DPCD
brightness controls\n");
}
@@ -277,8 +279,7 @@ static void set_vesa_backlight_enable(struct intel_dp
*intel_dp, bool enable)
if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
return;
- if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
- _val) < 0) {
+ if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
_val) != 1) {
drm_dbg_kms(>drm, "Failed to read DPCD register 0x%x\n",
DP_EDP_DISPLAY_CONTROL_REGISTER);
return;
@@ -332,8 +333,8 @@ static u32 intel_dp_aux_vesa_get_backlight(struct
intel_connector *connector, en
if (!intel_dp_aux_vesa_backlight_dpcd_mode(connector))
return connector->panel.backlight.max;
- if (drm_dp_dpcd_read(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
-_val, sizeof(read_val)) < 0) {
+ if (drm_dp_dpcd_read(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
_val,
+sizeof(read_val)) != sizeof(read_val)) {
drm_dbg_kms(>drm, "Failed to read DPCD register 0x%x\n",
DP_EDP_BACKLIGHT_BRIGHTNESS_MSB);
return 0;
@@ -365,8 +366,8 @@ intel_dp_aux_vesa_set_backlight(const struct
drm_connector_state *conn_state,
vals[0] = (level & 0xFF00) >> 8;
vals[1] = (level & 0xFF);
[Intel-gfx] [RFC v4 02/11] drm/nouveau/kms: Don't probe eDP connectors more then once
eDP doesn't do hotplugging, so there's no reason for us to reprobe it (unless a connection status change is being forced, of course). Signed-off-by: Lyude Paul Cc: Jani Nikula Cc: Dave Airlie Cc: greg.depo...@gmail.com --- drivers/gpu/drm/nouveau/nouveau_connector.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c index 61e6d7412505..55e986b3cad9 100644 --- a/drivers/gpu/drm/nouveau/nouveau_connector.c +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c @@ -556,6 +556,12 @@ nouveau_connector_detect(struct drm_connector *connector, bool force) int ret; enum drm_connector_status conn_status = connector_status_disconnected; + /* eDP doesn't do hotplugging, never probe more then once */ + if (nv_connector->type == DCB_CONNECTOR_eDP && + connector->force == DRM_FORCE_UNSPECIFIED && + connector->status != connector_status_unknown) + return connector->status; + /* Outputs are only polled while runtime active, so resuming the * device here is unnecessary (and would deadlock upon runtime suspend * because it waits for polling to finish). We do however, want to -- 2.29.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v4 00/11] drm: Extract DPCD backlight helpers from i915, add support in nouveau
This series: * Cleans up i915's DPCD backlight code a little bit * Extracts i915's DPCD backlight code into a set of shared DRM helpers * Starts using those helpers in nouveau to add support to nouveau for DPCD backlight control v2 series-wide changes: * Rebase v3 series-wide changes: * Split up the changes to intel's backlight code into separate patches v4 series-wide changes: * Don't forget to actually include the patch that starts using these helpers in nouveau Cc: Jani Nikula Cc: Dave Airlie Cc: greg.depo...@gmail.com Lyude Paul (11): drm/nouveau/kms/nv40-/backlight: Assign prop type once drm/nouveau/kms: Don't probe eDP connectors more then once drm/i915/dpcd_bl: Remove redundant AUX backlight frequency calculations drm/i915/dpcd_bl: Handle drm_dpcd_read/write() return values correctly drm/i915/dpcd_bl: Cleanup intel_dp_aux_vesa_enable_backlight() a bit drm/i915/dpcd_bl: Cache some backlight capabilities in intel_panel.backlight drm/i915/dpcd_bl: Move VESA backlight enabling code closer together drm/i915/dpcd_bl: Return early in vesa_calc_max_backlight if we can't read PWMGEN_BIT_COUNT drm/i915/dpcd_bl: Print return codes for VESA backlight failures drm/dp: Extract i915's eDP backlight code into DRM helpers drm/nouveau/kms/nv50-: Add basic DPCD backlight support for nouveau drivers/gpu/drm/drm_dp_helper.c | 332 ++ .../drm/i915/display/intel_display_types.h| 2 +- .../drm/i915/display/intel_dp_aux_backlight.c | 329 +++-- drivers/gpu/drm/nouveau/dispnv50/disp.c | 28 ++ drivers/gpu/drm/nouveau/nouveau_backlight.c | 170 +++-- drivers/gpu/drm/nouveau/nouveau_connector.c | 6 + drivers/gpu/drm/nouveau/nouveau_connector.h | 9 +- drivers/gpu/drm/nouveau/nouveau_encoder.h | 1 + include/drm/drm_dp_helper.h | 48 +++ 9 files changed, 614 insertions(+), 311 deletions(-) -- 2.29.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v4 01/11] drm/nouveau/kms/nv40-/backlight: Assign prop type once
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 72f35a2babcb..42b498e7e2bf 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -106,7 +106,6 @@ nv40_backlight_init(struct nouveau_encoder *encoder,
if (!(nvif_rd32(device, NV40_PMC_BACKLIGHT) & NV40_PMC_BACKLIGHT_MASK))
return -ENODEV;
- props->type = BACKLIGHT_RAW;
props->max_brightness = 31;
*ops = _bl_ops;
return 0;
@@ -212,7 +211,6 @@ nv50_backlight_init(struct nouveau_encoder *nv_encoder,
else
*ops = _bl_ops;
- props->type = BACKLIGHT_RAW;
props->max_brightness = 100;
return 0;
@@ -226,7 +224,7 @@ nouveau_backlight_init(struct drm_connector *connector)
struct nouveau_encoder *nv_encoder = NULL;
struct nvif_device *device = >client.device;
char backlight_name[BL_NAME_SIZE];
- struct backlight_properties props = {0};
+ struct backlight_properties props = { .type = BACKLIGHT_RAW, 0 };
const struct backlight_ops *ops;
int ret;
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [5.10.y regression] i915 clear-residuals mitigation is causing gfx issues
Quoting Hans de Goede (2021-02-08 20:38:58) > Hi All, > > We (Fedora) have been receiving reports from multiple users about gfx issues > / glitches > stating with 5.10.9. All reporters are users of Ivy Bridge / Haswell iGPUs > and all > reporters report that adding i915.mitigations=off to the cmdline fixes > things, see: I tried to reproduce this on the w/e on hsw-gt1, to no avail; and piglit did not report any differences with and without mitigations. I have yet to test other platforms. So I don't yet have an alternative. Though note that v5.11 and v5.12 will behave similarly, so we need to urgently find a fix for Linus's tree anyway. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/4] drm/i915: Create stolen memory region from local memory
== Series Details == Series: series starting with [1/4] drm/i915: Create stolen memory region from local memory URL : https://patchwork.freedesktop.org/series/86861/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9747_full -> Patchwork_19633_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19633_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19633_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19633_full: ### IGT changes ### Possible regressions * igt@kms_3d: - shard-glk: [PASS][1] -> [DMESG-WARN][2] +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk2/igt@kms_3d.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/shard-glk3/igt@kms_3d.html - shard-tglb: [PASS][3] -> [DMESG-WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-tglb6/igt@kms_3d.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/shard-tglb7/igt@kms_3d.html * igt@kms_big_fb@y-tiled-64bpp-rotate-0: - shard-iclb: [PASS][5] -> [DMESG-WARN][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-iclb8/igt@kms_big...@y-tiled-64bpp-rotate-0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/shard-iclb5/igt@kms_big...@y-tiled-64bpp-rotate-0.html * igt@kms_plane_lowres@pipe-b-tiling-none: - shard-snb: [PASS][7] -> [DMESG-WARN][8] +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-snb6/igt@kms_plane_low...@pipe-b-tiling-none.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/shard-snb7/igt@kms_plane_low...@pipe-b-tiling-none.html * igt@kms_plane_scaling@scaler-with-rotation@pipe-a-scaler-with-rotation: - shard-apl: [PASS][9] -> [DMESG-WARN][10] +4 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-apl1/igt@kms_plane_scaling@scaler-with-rotat...@pipe-a-scaler-with-rotation.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/shard-apl3/igt@kms_plane_scaling@scaler-with-rotat...@pipe-a-scaler-with-rotation.html * igt@kms_universal_plane@universal-plane-gen9-features-pipe-a: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] +8 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-kbl4/igt@kms_universal_pl...@universal-plane-gen9-features-pipe-a.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/shard-kbl1/igt@kms_universal_pl...@universal-plane-gen9-features-pipe-a.html * igt@testdisplay: - shard-apl: NOTRUN -> [DMESG-FAIL][13] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/shard-apl1/i...@testdisplay.html - shard-glk: [PASS][14] -> [DMESG-FAIL][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk4/i...@testdisplay.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/shard-glk7/i...@testdisplay.html Known issues Here are the changes found in Patchwork_19633_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-kbl: [PASS][16] -> [FAIL][17] ([i915#2842]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-kbl3/igt@gem_exec_fair@basic-none-...@rcs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/shard-kbl3/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-apl: [PASS][18] -> [FAIL][19] ([i915#2842]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-apl4/igt@gem_exec_fair@basic-n...@vcs0.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/shard-apl7/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][20] -> [FAIL][21] ([i915#2842]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_schedule@u-fairslice@vecs0: - shard-skl: [PASS][22] -> [DMESG-WARN][23] ([i915#1610] / [i915#2803]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl7/igt@gem_exec_schedule@u-fairsl...@vecs0.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/shard-skl7/igt@gem_exec_schedule@u-fairsl...@vecs0.html *
Re: [Intel-gfx] [RFC v3 10/10] drm/dp: Extract i915's eDP backlight code into DRM helpers
On Mon, 2021-02-08 at 09:46 +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 06.02.21 um 00:45 schrieb Lyude Paul:
> > Since we're about to implement eDP backlight support in nouveau using the
> > standard protocol from VESA, we might as well just take the code that's
> > already written for this and move it into a set of shared DRM helpers.
> >
> > Note that these helpers are intended to handle DPCD related backlight
> > control bits such as setting the brightness level over AUX, probing the
> > backlight's TCON, enabling/disabling the backlight over AUX if supported,
> > etc. Any PWM-related portions of backlight control are explicitly left up
> > to the driver, as these will vary from platform to platform.
> >
> > The only exception to this is the calculation of the PWM frequency
> > pre-divider value. This is because the only platform-specific information
> > required for this is the PWM frequency of the panel, which the driver is
> > expected to provide if available. The actual algorithm for calculating this
> > value is standard and is defined in the eDP specification from VESA.
> >
> > Note that these helpers do not yet implement the full range of features
> > the VESA backlight interface provides, and only provide the following
> > functionality (all of which was already present in i915's DPCD backlight
> > support):
> >
> > * Basic control of brightness levels
> > * Basic probing of backlight capabilities
> > * Helpers for enabling and disabling the backlight
> >
> > v3:
> > * Split out changes to i915's backlight code to separate patches to make it
> > easier to review
> >
> > Signed-off-by: Lyude Paul
> > Cc: Jani Nikula
> > Cc: Dave Airlie
> > Cc: greg.depo...@gmail.com
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 332 ++
> > .../drm/i915/display/intel_display_types.h | 5 +-
> > .../drm/i915/display/intel_dp_aux_backlight.c | 285 ++-
> > include/drm/drm_dp_helper.h | 48 +++
> > 4 files changed, 412 insertions(+), 258 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index eedbb48815b7..04cb2b6970a8 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -3082,3 +3082,335 @@ int drm_dp_pcon_convert_rgb_to_ycbcr(struct
> > drm_dp_aux *aux, u8 color_spc)
> > return 0;
> > }
> > EXPORT_SYMBOL(drm_dp_pcon_convert_rgb_to_ycbcr);
> > +
> > +/**
> > + * drm_edp_backlight_set_level() - Set the backlight level of an eDP panel
> > via AUX
> > + * @aux: The DP AUX channel to use
> > + * @bl: Backlight capability info from drm_edp_backlight_init()
> > + * @level: The brightness level to set
> > + *
> > + * Sets the brightness level of an eDP panel's backlight. Note that the
> > panel's backlight must
> > + * already have been enabled by the driver by calling
> > drm_edp_backlight_enable().
> > + *
> > + * Returns: %0 on success, negative error code on failure
> > + */
> > +int drm_edp_backlight_set_level(struct drm_dp_aux *aux, const struct
> > drm_edp_backlight_info *bl,
> > + u16 level)
> > +{
> > + int ret;
> > + u8 buf[2] = { 0 };
> > +
> > + if (bl->lsb_reg_used) {
> > + buf[0] = (level & 0xFF00) >> 8;
> > + buf[1] = (level & 0x00FF);
>
> Maybe 0x00ff and 0xff00 for aesthetic reasons.
>
> > + } else {
> > + buf[0] = level;
> > + }
> > +
> > + ret = drm_dp_dpcd_write(aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB, buf,
> > sizeof(buf));
> > + if (ret != sizeof(buf)) {
> > + DRM_ERROR("%s: Failed to write aux backlight level: %d\n",
> > aux->name, ret);
>
> Since you're adding this code, you should probably convert to drm_err()
> helpers as well. Here and elsewhere.
this is next up on my todo list JFYI-I don't do it right now because there isn't
actually any backpointer to the drm driver (and you can't just use the parent of
the aux device, since that technically doesn't need to be the drm driver).
I'd add it in this series, but that's going to involve updating functions across
the tree like drm_dp_aux_init() so I'd like to do it in a different patch series
>
> > + return ret < 0 ? ret : -EIO;
> > + }
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(drm_edp_backlight_set_level);
> > +
> > +static int
> > +drm_edp_backlight_set_enable(struct drm_dp_aux *aux, const struct
> > drm_edp_backlight_info *bl,
> > + bool enable)
> > +{
> > + int ret;
> > + u8 buf;
> > +
> > + /* The panel uses something other then DPCD for enabling it's
> > backlight */
>
> 'its'
>
> Best regards
> Thomas
>
> > + if (!bl->aux_enable)
> > + return 0;
> > +
> > + ret = drm_dp_dpcd_readb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, );
> > + if (ret != 1) {
> > + DRM_ERROR("%s: Failed to read eDP display
Re: [Intel-gfx] [RFC v3 00/10] drm: Extract DPCD backlight helpers from i915, add support in nouveau
thanks for the review comments everyone! I'm going through them now but realized I should probably point out that I somehow sent this patch series and did not realize I did so in the middle of a rebase, and as such completely forgot the parts here that actually started using these helpers in nouveau. lol anyway-will fix when I sent out the respin today On Fri, 2021-02-05 at 18:45 -0500, Lyude Paul wrote: > This series: > * Cleans up i915's DPCD backlight code a little bit > * Extracts i915's DPCD backlight code into a set of shared DRM helpers > * Starts using those helpers in nouveau to add support to nouveau for > DPCD backlight control > > v2 series-wide changes: > * Rebase > v3 series-wide changes: > * Split up the changes to intel's backlight code into separate patches > > Cc: Jani Nikula > Cc: Dave Airlie > Cc: greg.depo...@gmail.com > > Lyude Paul (10): > drm/nouveau/kms/nv40-/backlight: Assign prop type once > drm/nouveau/kms: Don't probe eDP connectors more then once > drm/i915/dpcd_bl: Remove redundant AUX backlight frequency > calculations > drm/i915/dpcd_bl: Handle drm_dpcd_read/write() return values correctly > drm/i915/dpcd_bl: Cleanup intel_dp_aux_vesa_enable_backlight() a bit > drm/i915/dpcd_bl: Cache some backlight capabilities in > intel_panel.backlight > drm/i915/dpcd_bl: Move VESA backlight enabling code closer together > drm/i915/dpcd_bl: Return early in vesa_calc_max_backlight if we can't > read PWMGEN_BIT_COUNT > drm/i915/dpcd_bl: Print return codes for VESA backlight failures > drm/dp: Extract i915's eDP backlight code into DRM helpers > > drivers/gpu/drm/drm_dp_helper.c | 332 ++ > .../drm/i915/display/intel_display_types.h | 2 +- > .../drm/i915/display/intel_dp_aux_backlight.c | 329 +++-- > drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 +- > drivers/gpu/drm/nouveau/nouveau_connector.c | 6 + > include/drm/drm_dp_helper.h | 48 +++ > 6 files changed, 428 insertions(+), 293 deletions(-) > -- Sincerely, Lyude Paul (she/her) Software Engineer at Red Hat Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've asked me a question, are waiting for a review/merge on a patch, etc. and I haven't responded in a while, please feel free to send me another email to check on my status. I don't bite! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove unused debug functions
== Series Details == Series: drm/i915: Remove unused debug functions URL : https://patchwork.freedesktop.org/series/86859/ State : success == Summary == CI Bug Log - changes from CI_DRM_9747_full -> Patchwork_19632_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19632_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][1] -> [TIMEOUT][2] ([i915#1037] / [i915#3063]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-tglb5/igt@gem_...@unwedge-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/shard-tglb1/igt@gem_...@unwedge-stress.html - shard-skl: [PASS][3] -> [TIMEOUT][4] ([i915#1037] / [i915#2771]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl5/igt@gem_...@unwedge-stress.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/shard-skl4/igt@gem_...@unwedge-stress.html - shard-iclb: [PASS][5] -> [TIMEOUT][6] ([i915#1037] / [i915#2481]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-iclb8/igt@gem_...@unwedge-stress.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/shard-iclb8/igt@gem_...@unwedge-stress.html * igt@gem_exec_balancer@hang: - shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([i915#1895] / [i915#2295]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-iclb8/igt@gem_exec_balan...@hang.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/shard-iclb2/igt@gem_exec_balan...@hang.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-kbl4/igt@gem_exec_fair@basic-pace-s...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/shard-kbl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_schedule@u-fairslice@vecs0: - shard-tglb: [PASS][13] -> [DMESG-WARN][14] ([i915#2803]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-tglb7/igt@gem_exec_schedule@u-fairsl...@vecs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/shard-tglb7/igt@gem_exec_schedule@u-fairsl...@vecs0.html * igt@gem_exec_whisper@basic-contexts-priority-all: - shard-glk: [PASS][15] -> [DMESG-WARN][16] ([i915#118] / [i915#95]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk6/igt@gem_exec_whis...@basic-contexts-priority-all.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/shard-glk4/igt@gem_exec_whis...@basic-contexts-priority-all.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][17] -> [SKIP][18] ([i915#2190]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-tglb7/igt@gem_huc_c...@huc-copy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/shard-tglb6/igt@gem_huc_c...@huc-copy.html * igt@gem_userptr_blits@process-exit-mmap-busy@uc: - shard-skl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#1699]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/shard-skl4/igt@gem_userptr_blits@process-exit-mmap-b...@uc.html * igt@gem_userptr_blits@process-exit-mmap-busy@wc: - shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#1699]) +3 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/shard-apl2/igt@gem_userptr_blits@process-exit-mmap-b...@wc.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][21] -> [DMESG-WARN][22] ([i915#1436] / [i915#716]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl4/igt@gen9_exec_pa...@allowed-single.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/shard-skl10/igt@gen9_exec_pa...@allowed-single.html * igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-dp: - shard-apl: NOTRUN -> [SKIP][23] ([fdo#109271] / [i915#1937]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/shard-apl2/igt@i915_pm_lpsp@kms-l...@kms-lpsp-dp.html * igt@i915_pm_rpm@modeset-lpsp-stress: - shard-apl: NOTRUN -> [SKIP][24] ([fdo#109271]) +91 similar issues [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/shard-apl2/igt@i915_pm_...@modeset-lpsp-stress.html * igt@i915_suspend@forcewake: - shard-apl: [PASS][25] ->
Re: [Intel-gfx] [PATCH 30/31] drm/i915: Support secure dispatch on gen6/gen7
Quoting Dave Airlie (2021-02-08 20:55:19) > On Mon, 8 Feb 2021 at 20:53, Chris Wilson wrote: > > > > Re-enable secure dispatch for gen6/gen7, primarily to workaround the > > command parser and overly zealous command validation on Haswell. For > > example this prevents making accurate measurements using a journal for > > store results from the GPU without CPU intervention. > > There's 31 patches in this series, and I can't find any 00/31 or > justification for any of this work. You don't agree with the overview in 11? Or the test design to reproduce the reported problems with multiple clients? There's some code motion to align with upstreaming guc patches later on; a bug fix for an iterative depth-first-search not being a depth-first-search; the change in sort key for scheduling policy; switching the late greedy virtual engine to work on the same interface as execlists/guc; the CS emitters to switch off absolute addressing for breadcrumbs; and finally request reordering for the ringbuffer. > I see patches like this which seem to undo work done for security > reasons under CVE patches with no oversight. Seems to remove clear_residuals? The same clear_residuals between contexts on gen7 is there. > Again, the GT team is not doing the right thing here, stop focusing on > individual pieces of Chris's work, push back for high level > architectural reviews and I want them on the list in public. The architectural bit here is the code motion; getting the backend agnostic list management all into a common layer. Trying to align that with what drm_sched offers, with the optimistic view that one day drm_sched may offer enough to start replacing it. > All I want from the GT team in the next pull request is dma_resv > locking work and restoring the hangcheck timers that seems like a > regression that Chris found acceptable and nobody has pushed back on. The choice here in sort key is still entirely orthogonal to dma-resv. The hangcheck is still driven off a timer. The behaviour of the current code is still the same as the much older global seqno hangcheck around preemption (hangcheck being postponed whenever the seqno changed and/or RING_START changed). The direction to use periodic pulses for both issuing resets (which is actually much faster in detecting hangs than the older seqno hangchecking allowed for), power management and tracking of GPU resource was not mine alone, but yes I did find it acceptable. > For like the 500th time, if you want DG1 and stuff in the tree, stop > this shit already, real reviewers, high-level architectural reviews, > NAK the bullshit in public on the list. I do not understand the hostility to fixing user issues, and improving both existing and future products when it does not interfere with anything else. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it
== Series Details == Series: drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it URL : https://patchwork.freedesktop.org/series/86858/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9747_full -> Patchwork_19631_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19631_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19631_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19631_full: ### IGT changes ### Possible regressions * igt@kms_universal_plane@cursor-fb-leak-pipe-a: - shard-iclb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-iclb1/igt@kms_universal_pl...@cursor-fb-leak-pipe-a.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-iclb4/igt@kms_universal_pl...@cursor-fb-leak-pipe-a.html Known issues Here are the changes found in Patchwork_19631_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@unwedge-stress: - shard-skl: [PASS][3] -> [TIMEOUT][4] ([i915#1037] / [i915#2771]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl5/igt@gem_...@unwedge-stress.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-skl4/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][5] -> [FAIL][6] ([i915#2842]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_schedule@u-fairslice@rcs0: - shard-skl: [PASS][7] -> [DMESG-WARN][8] ([i915#1610] / [i915#2803]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl7/igt@gem_exec_schedule@u-fairsl...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-skl7/igt@gem_exec_schedule@u-fairsl...@rcs0.html * igt@gem_exec_whisper@basic-contexts-forked-all: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([i915#118] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk3/igt@gem_exec_whis...@basic-contexts-forked-all.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-glk3/igt@gem_exec_whis...@basic-contexts-forked-all.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][11] -> [SKIP][12] ([i915#2190]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-tglb7/igt@gem_huc_c...@huc-copy.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-tglb6/igt@gem_huc_c...@huc-copy.html * igt@gem_render_copy@linear-to-vebox-y-tiled: - shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271]) +74 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-apl7/igt@gem_render_c...@linear-to-vebox-y-tiled.html * igt@gem_userptr_blits@huge-split: - shard-glk: [PASS][14] -> [INCOMPLETE][15] ([i915#2502]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk4/igt@gem_userptr_bl...@huge-split.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-glk3/igt@gem_userptr_bl...@huge-split.html * igt@gem_userptr_blits@process-exit-mmap-busy@uc: - shard-skl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#1699]) +3 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-skl6/igt@gem_userptr_blits@process-exit-mmap-b...@uc.html * igt@gen9_exec_parse@allowed-all: - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1436] / [i915#716]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl10/igt@gen9_exec_pa...@allowed-all.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-skl10/igt@gen9_exec_pa...@allowed-all.html * igt@i915_selftest@live@client: - shard-glk: [PASS][19] -> [DMESG-FAIL][20] ([i915#3047]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk1/igt@i915_selftest@l...@client.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-glk2/igt@i915_selftest@l...@client.html * igt@i915_suspend@forcewake: - shard-skl: [PASS][21] -> [INCOMPLETE][22] ([i915#636]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl6/igt@i915_susp...@forcewake.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-skl8/igt@i915_susp...@forcewake.html *
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Allow the module to load even if live selftests fail
== Series Details == Series: drm/i915/selftests: Allow the module to load even if live selftests fail URL : https://patchwork.freedesktop.org/series/86851/ State : success == Summary == CI Bug Log - changes from CI_DRM_9747_full -> Patchwork_19630_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19630_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@unwedge-stress: - shard-skl: [PASS][1] -> [TIMEOUT][2] ([i915#1037] / [i915#2771]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl5/igt@gem_...@unwedge-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/shard-skl7/igt@gem_...@unwedge-stress.html - shard-iclb: [PASS][3] -> [TIMEOUT][4] ([i915#1037] / [i915#2481]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-iclb8/igt@gem_...@unwedge-stress.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/shard-iclb8/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_schedule@u-fairslice@rcs0: - shard-tglb: [PASS][11] -> [DMESG-WARN][12] ([i915#2803]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-tglb7/igt@gem_exec_schedule@u-fairsl...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/shard-tglb7/igt@gem_exec_schedule@u-fairsl...@rcs0.html * igt@gem_exec_schedule@u-fairslice@vcs0: - shard-skl: [PASS][13] -> [DMESG-WARN][14] ([i915#1610] / [i915#2803]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl7/igt@gem_exec_schedule@u-fairsl...@vcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/shard-skl10/igt@gem_exec_schedule@u-fairsl...@vcs0.html * igt@gem_exec_schedule@u-fairslice@vcs1: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#1610] / [i915#2803]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-kbl4/igt@gem_exec_schedule@u-fairsl...@vcs1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/shard-kbl2/igt@gem_exec_schedule@u-fairsl...@vcs1.html * igt@gem_userptr_blits@process-exit-mmap-busy@uc: - shard-skl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#1699]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/shard-skl6/igt@gem_userptr_blits@process-exit-mmap-b...@uc.html * igt@gem_userptr_blits@process-exit-mmap-busy@wc: - shard-apl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#1699]) +3 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/shard-apl6/igt@gem_userptr_blits@process-exit-mmap-b...@wc.html * igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-dp: - shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#1937]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/shard-apl6/igt@i915_pm_lpsp@kms-l...@kms-lpsp-dp.html * igt@i915_pm_rpm@modeset-lpsp-stress: - shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271]) +89 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/shard-apl6/igt@i915_pm_...@modeset-lpsp-stress.html * igt@kms_chamelium@hdmi-edid-change-during-suspend: - shard-apl: NOTRUN -> [SKIP][21] ([fdo#109271] / [fdo#111827]) +7 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/shard-apl3/igt@kms_chamel...@hdmi-edid-change-during-suspend.html * igt@kms_color_chamelium@pipe-d-ctm-0-5: - shard-tglb: NOTRUN -> [SKIP][22] ([fdo#109284] / [fdo#111827]) +2 similar issues [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/shard-tglb1/igt@kms_color_chamel...@pipe-d-ctm-0-5.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-apl: [PASS][23] -> [DMESG-WARN][24] ([i915#180]) +1
[Intel-gfx] ✗ Fi.CI.IGT: failure for i915: kvmgt: the KVM mmu_lock is now an rwlock
== Series Details == Series: i915: kvmgt: the KVM mmu_lock is now an rwlock URL : https://patchwork.freedesktop.org/series/86847/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9747_full -> Patchwork_19629_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19629_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19629_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19629_full: ### IGT changes ### Possible regressions * igt@gem_exec_capture@capture@vecs0: - shard-iclb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-iclb1/igt@gem_exec_capture@capt...@vecs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/shard-iclb7/igt@gem_exec_capture@capt...@vecs0.html Known issues Here are the changes found in Patchwork_19629_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][3] -> [TIMEOUT][4] ([i915#1037] / [i915#3063]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-tglb5/igt@gem_...@unwedge-stress.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/shard-tglb7/igt@gem_...@unwedge-stress.html - shard-iclb: [PASS][5] -> [TIMEOUT][6] ([i915#1037] / [i915#2481]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-iclb8/igt@gem_...@unwedge-stress.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/shard-iclb8/igt@gem_...@unwedge-stress.html * igt@gem_exec_reloc@basic-parallel: - shard-apl: NOTRUN -> [TIMEOUT][7] ([i915#1729]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/shard-apl1/igt@gem_exec_re...@basic-parallel.html * igt@gem_exec_schedule@u-fairslice@vcs0: - shard-skl: [PASS][8] -> [DMESG-WARN][9] ([i915#1610] / [i915#2803]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl7/igt@gem_exec_schedule@u-fairsl...@vcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/shard-skl10/igt@gem_exec_schedule@u-fairsl...@vcs0.html * igt@gem_exec_whisper@basic-queues-all: - shard-glk: [PASS][10] -> [DMESG-WARN][11] ([i915#118] / [i915#95]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk8/igt@gem_exec_whis...@basic-queues-all.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/shard-glk2/igt@gem_exec_whis...@basic-queues-all.html * igt@gem_render_copy@linear-to-vebox-y-tiled: - shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271]) +97 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/shard-apl6/igt@gem_render_c...@linear-to-vebox-y-tiled.html * igt@gem_userptr_blits@process-exit-mmap-busy@uc: - shard-skl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#1699]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/shard-skl8/igt@gem_userptr_blits@process-exit-mmap-b...@uc.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][14] -> [DMESG-WARN][15] ([i915#1436] / [i915#716]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl4/igt@gen9_exec_pa...@allowed-single.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/shard-skl3/igt@gen9_exec_pa...@allowed-single.html * igt@kms_chamelium@hdmi-edid-change-during-suspend: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +8 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/shard-apl6/igt@kms_chamel...@hdmi-edid-change-during-suspend.html * igt@kms_chamelium@vga-hpd-enable-disable-mode: - shard-kbl: NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/shard-kbl3/igt@kms_chamel...@vga-hpd-enable-disable-mode.html * igt@kms_color@pipe-a-ctm-green-to-red: - shard-skl: [PASS][18] -> [DMESG-WARN][19] ([i915#1982]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl10/igt@kms_co...@pipe-a-ctm-green-to-red.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/shard-skl7/igt@kms_co...@pipe-a-ctm-green-to-red.html * igt@kms_color_chamelium@pipe-d-ctm-0-5: - shard-tglb: NOTRUN -> [SKIP][20] ([fdo#109284] / [fdo#111827]) +2 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/shard-tglb5/igt@kms_color_chamel...@pipe-d-ctm-0-5.html * igt@kms_cursor_crc@pipe-a-cursor-suspend:
Re: [Intel-gfx] [PATCH] drm/i915/rkl: Remove require_force_probe protection
On Wed, Feb 03, 2021 at 11:43:13AM +, Chris Wilson wrote: > Quoting Tejas Upadhyay (2020-11-30 12:48:55) > > Removing force probe protection from RKL platform. Did > > not observe warnings, errors, flickering or any visual > > defects while doing ordinary tasks like browsing and > > editing documents in a two monitor setup. > > > > Signed-off-by: Tejas Upadhyay > > We now have a system in CI and that appears quite promising, > Acked-by: Chris Wilson Indeed. Pulled, thanks! > -Chris > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE
On Fri, Feb 05, 2021 at 10:00:12PM +, Chris Wilson wrote:
> Userspace has discovered the functionality offered by SYS_kcmp and has
> started to depend upon it. In particular, Mesa uses SYS_kcmp for
> os_same_file_description() in order to identify when two fd (e.g. device
> or dmabuf) point to the same struct file. Since they depend on it for
> core functionality, lift SYS_kcmp out of the non-default
> CONFIG_CHECKPOINT_RESTORE into the selectable syscall category.
>
> Rasmus Villemoes also pointed out that systemd uses SYS_kcmp to
> deduplicate the per-service file descriptor store.
>
> Note that some distributions such as Ubuntu are already enabling
> CHECKPOINT_RESTORE in their configs and so, by extension, SYS_kcmp.
>
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/3046
> Signed-off-by: Chris Wilson
Thanks!
Reviewed-by: Kees Cook
-Kees
> Cc: Kees Cook
> Cc: Andy Lutomirski
> Cc: Will Drewry
> Cc: Andrew Morton
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Lucas Stach
> Cc: Rasmus Villemoes
> Cc: Cyrill Gorcunov
> Cc: sta...@vger.kernel.org
> Acked-by: Daniel Vetter # DRM depends on kcmp
> Acked-by: Rasmus Villemoes # systemd uses kcmp
>
> ---
> v2:
> - Default n.
> - Borrrow help message from man kcmp.
> - Export get_epoll_tfile_raw_ptr() for CONFIG_KCMP
> v3:
> - Select KCMP for CONFIG_DRM
> ---
> drivers/gpu/drm/Kconfig | 3 +++
> fs/eventpoll.c| 4 ++--
> include/linux/eventpoll.h | 2 +-
> init/Kconfig | 11 +++
> kernel/Makefile | 2 +-
> tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +-
> 6 files changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 0973f408d75f..af6c6d214d91 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -15,6 +15,9 @@ menuconfig DRM
> select I2C_ALGOBIT
> select DMA_SHARED_BUFFER
> select SYNC_FILE
> +# gallium uses SYS_kcmp for os_same_file_description() to de-duplicate
> +# device and dmabuf fd. Let's make sure that is available for our userspace.
> + select KCMP
> help
> Kernel-level support for the Direct Rendering Infrastructure (DRI)
> introduced in XFree86 4.0. If you say Y here, you need to select
> diff --git a/fs/eventpoll.c b/fs/eventpoll.c
> index a829af074eb5..3196474cbe24 100644
> --- a/fs/eventpoll.c
> +++ b/fs/eventpoll.c
> @@ -979,7 +979,7 @@ static struct epitem *ep_find(struct eventpoll *ep,
> struct file *file, int fd)
> return epir;
> }
>
> -#ifdef CONFIG_CHECKPOINT_RESTORE
> +#ifdef CONFIG_KCMP
> static struct epitem *ep_find_tfd(struct eventpoll *ep, int tfd, unsigned
> long toff)
> {
> struct rb_node *rbp;
> @@ -1021,7 +1021,7 @@ struct file *get_epoll_tfile_raw_ptr(struct file *file,
> int tfd,
>
> return file_raw;
> }
> -#endif /* CONFIG_CHECKPOINT_RESTORE */
> +#endif /* CONFIG_KCMP */
>
> /**
> * Adds a new entry to the tail of the list in a lockless way, i.e.
> diff --git a/include/linux/eventpoll.h b/include/linux/eventpoll.h
> index 0350393465d4..593322c946e6 100644
> --- a/include/linux/eventpoll.h
> +++ b/include/linux/eventpoll.h
> @@ -18,7 +18,7 @@ struct file;
>
> #ifdef CONFIG_EPOLL
>
> -#ifdef CONFIG_CHECKPOINT_RESTORE
> +#ifdef CONFIG_KCMP
> struct file *get_epoll_tfile_raw_ptr(struct file *file, int tfd, unsigned
> long toff);
> #endif
>
> diff --git a/init/Kconfig b/init/Kconfig
> index b77c60f8b963..9cc7436b2f73 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1194,6 +1194,7 @@ endif # NAMESPACES
> config CHECKPOINT_RESTORE
> bool "Checkpoint/restore support"
> select PROC_CHILDREN
> + select KCMP
> default n
> help
> Enables additional kernel features in a sake of checkpoint/restore.
> @@ -1737,6 +1738,16 @@ config ARCH_HAS_MEMBARRIER_CALLBACKS
> config ARCH_HAS_MEMBARRIER_SYNC_CORE
> bool
>
> +config KCMP
> + bool "Enable kcmp() system call" if EXPERT
> + help
> + Enable the kernel resource comparison system call. It provides
> + user-space with the ability to compare two processes to see if they
> + share a common resource, such as a file descriptor or even virtual
> + memory space.
> +
> + If unsure, say N.
> +
> config RSEQ
> bool "Enable rseq() system call" if EXPERT
> default y
> diff --git a/kernel/Makefile b/kernel/Makefile
> index aa7368c7eabf..320f1f3941b7 100644
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -51,7 +51,7 @@ obj-y += livepatch/
> obj-y += dma/
> obj-y += entry/
>
> -obj-$(CONFIG_CHECKPOINT_RESTORE) += kcmp.o
> +obj-$(CONFIG_KCMP) += kcmp.o
> obj-$(CONFIG_FREEZER) += freezer.o
> obj-$(CONFIG_PROFILING) += profile.o
> obj-$(CONFIG_STACKTRACE) += stacktrace.o
> diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
>
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gvt/kvmgt: Fix the build failure in kvmgt.
== Series Details == Series: drm/i915/gvt/kvmgt: Fix the build failure in kvmgt. URL : https://patchwork.freedesktop.org/series/86845/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9747_full -> Patchwork_19628_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19628_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19628_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19628_full: ### IGT changes ### Possible regressions * igt@gem_exec_capture@capture@vcs0: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl8/igt@gem_exec_capture@capt...@vcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/shard-skl2/igt@gem_exec_capture@capt...@vcs0.html Known issues Here are the changes found in Patchwork_19628_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][3] -> [TIMEOUT][4] ([i915#1037] / [i915#3063]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-tglb5/igt@gem_...@unwedge-stress.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/shard-tglb7/igt@gem_...@unwedge-stress.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][5] ([i915#2389]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/shard-iclb4/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_exec_schedule@u-fairslice@rcs0: - shard-iclb: [PASS][6] -> [DMESG-WARN][7] ([i915#2803]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-iclb4/igt@gem_exec_schedule@u-fairsl...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/shard-iclb8/igt@gem_exec_schedule@u-fairsl...@rcs0.html * igt@gem_exec_whisper@basic-contexts-priority-all: - shard-glk: [PASS][8] -> [DMESG-WARN][9] ([i915#118] / [i915#95]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk6/igt@gem_exec_whis...@basic-contexts-priority-all.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/shard-glk7/igt@gem_exec_whis...@basic-contexts-priority-all.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][10] -> [SKIP][11] ([i915#2190]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-tglb7/igt@gem_huc_c...@huc-copy.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/shard-tglb6/igt@gem_huc_c...@huc-copy.html * igt@gem_render_copy@linear-to-vebox-y-tiled: - shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271]) +74 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/shard-apl1/igt@gem_render_c...@linear-to-vebox-y-tiled.html * igt@i915_module_load@reload-with-fault-injection: - shard-skl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl10/igt@i915_module_l...@reload-with-fault-injection.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/shard-skl10/igt@i915_module_l...@reload-with-fault-injection.html * igt@i915_suspend@forcewake: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-apl4/igt@i915_susp...@forcewake.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/shard-apl3/igt@i915_susp...@forcewake.html - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([i915#146] / [i915#636]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl6/igt@i915_susp...@forcewake.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/shard-skl5/igt@i915_susp...@forcewake.html * igt@kms_big_fb@y-tiled-addfb-size-offset-overflow: - shard-skl: NOTRUN -> [SKIP][19] ([fdo#109271]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/shard-skl7/igt@kms_big...@y-tiled-addfb-size-offset-overflow.html * igt@kms_chamelium@hdmi-edid-change-during-suspend: - shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271] / [fdo#111827]) +5 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/shard-apl1/igt@kms_chamel...@hdmi-edid-change-during-suspend.html * igt@kms_chamelium@vga-hpd-enable-disable-mode: - shard-kbl: NOTRUN -> [SKIP][21] ([fdo#109271] / [fdo#111827]) [21]:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: rework gem_create flow for upcoming extensions
== Series Details == Series: series starting with [1/2] drm/i915: rework gem_create flow for upcoming extensions URL : https://patchwork.freedesktop.org/series/86866/ State : success == Summary == CI Bug Log - changes from CI_DRM_9747 -> Patchwork_19635 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/index.html Known issues Here are the changes found in Patchwork_19635 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-gfx0: - fi-cfl-8700k: NOTRUN -> [SKIP][1] ([fdo#109271]) +25 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/fi-cfl-8700k/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html * igt@fbdev@write: - fi-tgl-y: [PASS][2] -> [DMESG-WARN][3] ([i915#402]) +1 similar issue [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@fb...@write.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/fi-tgl-y/igt@fb...@write.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271]) +23 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html - fi-cfl-8700k: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/fi-cfl-8700k/igt@gem_huc_c...@huc-copy.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][7] ([i915#1886] / [i915#2291]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-soraka: NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@vga-edid-read: - fi-cfl-8700k: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/fi-cfl-8700k/igt@kms_chamel...@vga-edid-read.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-cfl-8700k: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#533]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/fi-cfl-8700k/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html - fi-kbl-soraka: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#533]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html Possible fixes * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [DMESG-WARN][12] ([i915#402]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533 Participating hosts (42 -> 38) -- Additional (2): fi-kbl-soraka fi-cfl-8700k Missing(6): fi-jsl-1 fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_9747 -> Patchwork_19635 CI-20190529: 20190529 CI_DRM_9747: 65d67e70f9f78c7f8c2796956fdbdb69cffc7c98 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5998: b0160aad9e547d2205341e0b6783e12aa143566e @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19635: 4bd834f7238f36c0526c4ab3a721b971da8dfca8 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4bd834f7238f drm/i915/uapi: introduce drm_i915_gem_create_ext 2da1a8f2c4e3 drm/i915: rework gem_create flow for upcoming extensions == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19635/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 30/31] drm/i915: Support secure dispatch on gen6/gen7
On Mon, 8 Feb 2021 at 20:53, Chris Wilson wrote: > > Re-enable secure dispatch for gen6/gen7, primarily to workaround the > command parser and overly zealous command validation on Haswell. For > example this prevents making accurate measurements using a journal for > store results from the GPU without CPU intervention. There's 31 patches in this series, and I can't find any 00/31 or justification for any of this work. I see patches like this which seem to undo work done for security reasons under CVE patches with no oversight. Again, the GT team is not doing the right thing here, stop focusing on individual pieces of Chris's work, push back for high level architectural reviews and I want them on the list in public. All I want from the GT team in the next pull request is dma_resv locking work and restoring the hangcheck timers that seems like a regression that Chris found acceptable and nobody has pushed back on. For like the 500th time, if you want DG1 and stuff in the tree, stop this shit already, real reviewers, high-level architectural reviews, NAK the bullshit in public on the list. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: rework gem_create flow for upcoming extensions
== Series Details == Series: series starting with [1/2] drm/i915: rework gem_create flow for upcoming extensions URL : https://patchwork.freedesktop.org/series/86866/ State : warning == Summary == $ dim checkpatch origin/drm-tip 2da1a8f2c4e3 drm/i915: rework gem_create flow for upcoming extensions -:115: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #115: FILE: drivers/gpu/drm/i915/gem/i915_gem_create.c:107: +intel_memory_region_by_type(to_i915(dev), + mem_type), total: 0 errors, 0 warnings, 1 checks, 137 lines checked 4bd834f7238f drm/i915/uapi: introduce drm_i915_gem_create_ext -:161: WARNING:LONG_LINE: line length of 124 exceeds 100 columns #161: FILE: include/uapi/drm/i915_drm.h:396: +#define DRM_IOCTL_I915_GEM_CREATE_EXT DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_CREATE_EXT, struct drm_i915_gem_create_ext) -:212: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #212: FILE: include/uapi/drm/i915_drm.h:1740: +#define I915_OBJECT_PARAM (1ull<<32) ^ total: 0 errors, 1 warnings, 1 checks, 180 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] i915/perf: Store a mask of valid OA formats for a platform
== Series Details == Series: series starting with [1/3] i915/perf: Store a mask of valid OA formats for a platform URL : https://patchwork.freedesktop.org/series/86865/ State : success == Summary == CI Bug Log - changes from CI_DRM_9747 -> Patchwork_19634 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/index.html Known issues Here are the changes found in Patchwork_19634 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-gfx0: - fi-cfl-8700k: NOTRUN -> [SKIP][1] ([fdo#109271]) +25 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/fi-cfl-8700k/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271]) +23 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [PASS][3] -> [FAIL][4] ([i915#1888]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html - fi-cfl-8700k: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/fi-cfl-8700k/igt@gem_huc_c...@huc-copy.html * igt@gem_sync@basic-all: - fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@gem_s...@basic-all.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/fi-tgl-y/igt@gem_s...@basic-all.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][9] ([i915#1886] / [i915#2291]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-soraka: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@vga-edid-read: - fi-cfl-8700k: NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/fi-cfl-8700k/igt@kms_chamel...@vga-edid-read.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-cfl-8700k: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#533]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/fi-cfl-8700k/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html - fi-kbl-soraka: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#533]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html Possible fixes * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [DMESG-WARN][14] ([i915#402]) -> [PASS][15] +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19634/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886 [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533 Participating hosts (42 -> 37) -- Additional (2): fi-kbl-soraka fi-cfl-8700k Missing(7): fi-jsl-1 fi-cml-u2 fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_9747 -> Patchwork_19634 CI-20190529: 20190529 CI_DRM_9747: 65d67e70f9f78c7f8c2796956fdbdb69cffc7c98 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5998: b0160aad9e547d2205341e0b6783e12aa143566e @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19634: 13bd345396790dda0de3b4e232dadc24a2c1bcd8 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 13bd34539679 i915/perf:
Re: [Intel-gfx] [RFC 08/14] drm/i915/pxp: Implement arb session teardown
Quoting Daniele Ceraolo Spurio (2021-02-08 19:43:23) > > > On 2/6/2021 4:59 AM, Chris Wilson wrote: > > Is there any reason at all to use the batch and not just emit directly > > into the ring? The command sequence is short. And you probably want to > > disable arbitration. > > Future proofing - with multiple sessions in place we'd need to emit a > termination for each of them (pxp_emit_session_selection + > pxp_emit_inline_termination), so the sequence would be longer. It'd > still be below a page, so it should still be possible to fit it in the > ring if you believe that works better. In terms of complexity and assurance (pre-allocated space), emitting from the ring buffer is far simpler. You can make the ring upto 512KiB, but if a single page is all that is needed for the most complicated invalidate command, 8/16KiB should be plenty. (Number of pages then equals number of invalidates that can in flight at any time, which realistically is going to be a small number.) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [5.10.y regression] i915 clear-residuals mitigation is causing gfx issues
Hi All,
We (Fedora) have been receiving reports from multiple users about gfx issues /
glitches
stating with 5.10.9. All reporters are users of Ivy Bridge / Haswell iGPUs and
all
reporters report that adding i915.mitigations=off to the cmdline fixes things,
see:
https://bugzilla.redhat.com/show_bug.cgi?id=1925346
Which should be fully visible without a bugzilla account.
I noticed that 5.10.13 had one more related i915 patch, so I've asked the
reporters
to retest with 5.10.13, 5.10.13 is better, but things are not fixed there, it
just
takes longer for the problems to show up.
Greg, I can prepare a Fedora test-kernel build for the reporters to test with
the following 3 commits reverted:
520d05a77b2866eb ("drm/i915/gt: Clear CACHE_MODE prior to clearing residuals")
ecca0c675bdecebd ("drm/i915/gt: Restore clear-residual mitigations for
Ivybridge, Baytrail")
48b8c6689efa7cd6 ("drm/i915/gt: Limit VFE threads based on GT")
(Note this are the 5.10.y hashes)
Reverting these 3 is not ideal, but it is probably the fastest way to get
this resolved for the 5.10.y series.
Greg, do you want me to have the reporters test a 5.10.y series kernel
with these 3 reverts ?
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] i915/perf: Store a mask of valid OA formats for a platform
== Series Details == Series: series starting with [1/3] i915/perf: Store a mask of valid OA formats for a platform URL : https://patchwork.freedesktop.org/series/86865/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/i915/gt/intel_reset.c:1323:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gvt/mmio.c:295:23: warning: memcpy with byte count of 279040 +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' - different lock contexts for basic block ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI 6/6] drm/i915/gem: Drop lru bumping on display unpinning
On Wed, 20 Jan 2021 at 07:43, Chris Wilson wrote:
>
> Simplify the frontbuffer unpin by removing the lock requirement. The LRU
> bumping was primarily to protect the GTT from being evicted and from
> frontbuffers being eagerly shrunk. Now we protect frontbuffers from the
> shrinker, and we avoid accidentally evicting from the GTT, so the
> benefit from bumping LRU is no more, and we can save more time by not.
>
> Signed-off-by: Chris Wilson
> Reviewed-by: Matthew Auld
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 7 +--
> drivers/gpu/drm/i915/display/intel_overlay.c | 4 +-
> drivers/gpu/drm/i915/gem/i915_gem_domain.c | 45
> drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 -
> 4 files changed, 4 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 32ff9d201aeb..2bd04e631eaa 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1430,7 +1430,7 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
> */
> ret = i915_vma_pin_fence(vma);
> if (ret != 0 && INTEL_GEN(dev_priv) < 4) {
> - i915_gem_object_unpin_from_display_plane(vma);
> + i915_vma_unpin(vma);
> vma = ERR_PTR(ret);
> goto err;
> }
> @@ -1448,12 +1448,9 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
>
> void intel_unpin_fb_vma(struct i915_vma *vma, unsigned long flags)
> {
> - i915_gem_object_lock(vma->obj, NULL);
> if (flags & PLANE_HAS_FENCE)
> i915_vma_unpin_fence(vma);
> - i915_gem_object_unpin_from_display_plane(vma);
> - i915_gem_object_unlock(vma->obj);
> -
Why does this drop the locking here without explanation and without
reviewer comments?
Any patches from Chris that touch locking need vastly more review than
rubberstamps.
Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Create stolen memory region from local memory
== Series Details == Series: series starting with [1/4] drm/i915: Create stolen memory region from local memory URL : https://patchwork.freedesktop.org/series/86861/ State : success == Summary == CI Bug Log - changes from CI_DRM_9747 -> Patchwork_19633 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/index.html Known issues Here are the changes found in Patchwork_19633 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fence@basic-busy@bcs0: - fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +23 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@i915_module_load@reload: - fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#1982] / [k.org#205379]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@i915_module_l...@reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/fi-tgl-y/igt@i915_module_l...@reload.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][5] ([i915#1886] / [i915#2291]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#533]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@prime_self_import@basic-with_one_bo_two_files: - fi-tgl-y: [PASS][8] -> [DMESG-WARN][9] ([i915#402]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html * igt@runner@aborted: - fi-cfl-8700k: NOTRUN -> [FAIL][10] ([i915#2295] / [k.org#202107] / [k.org#202109]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/fi-cfl-8700k/igt@run...@aborted.html - fi-kbl-7500u: NOTRUN -> [FAIL][11] ([i915#1569] / [i915#192] / [i915#193] / [i915#194] / [i915#2295]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/fi-kbl-7500u/igt@run...@aborted.html - fi-cfl-guc: NOTRUN -> [FAIL][12] ([i915#2295] / [k.org#202107] / [k.org#202109]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/fi-cfl-guc/igt@run...@aborted.html Possible fixes * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [DMESG-WARN][13] ([i915#402]) -> [PASS][14] +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19633/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1569]: https://gitlab.freedesktop.org/drm/intel/issues/1569 [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886 [i915#192]: https://gitlab.freedesktop.org/drm/intel/issues/192 [i915#193]: https://gitlab.freedesktop.org/drm/intel/issues/193 [i915#194]: https://gitlab.freedesktop.org/drm/intel/issues/194 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291 [i915#2295]: https://gitlab.freedesktop.org/drm/intel/issues/2295 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533 [k.org#202107]: https://bugzilla.kernel.org/show_bug.cgi?id=202107 [k.org#202109]: https://bugzilla.kernel.org/show_bug.cgi?id=202109 [k.org#205379]: https://bugzilla.kernel.org/show_bug.cgi?id=205379 Participating hosts (42 -> 37) -- Additional (2): fi-kbl-soraka fi-cfl-8700k Missing(7): fi-jsl-1 fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_9747 -> Patchwork_19633
Re: [Intel-gfx] [RFC 08/14] drm/i915/pxp: Implement arb session teardown
On 2/6/2021 4:59 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2021-02-06 02:09:19)
From: "Huang, Sean Z"
Teardown is triggered when the display topology changes and no
long meets the secure playback requirement, and hardware trashes
all the encryption keys for display. Additionally, we want to emit a
teardown operation to make sure we're clean on boot and resume
Signed-off-by: Huang, Sean Z
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c | 227 +++
drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h | 15 ++
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 40
drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 5 +-
6 files changed, 288 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 8519abcf6515..9698fec810ae 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -271,6 +271,7 @@ i915-y += i915_perf.o
# Protected execution platform (PXP) support
i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp.o \
+ pxp/intel_pxp_cmd.o \
pxp/intel_pxp_session.o \
pxp/intel_pxp_tee.o
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
new file mode 100644
index ..3e2c3580cb1b
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
@@ -0,0 +1,227 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2020, Intel Corporation. All rights reserved.
+ */
+
+#include "intel_pxp.h"
+#include "intel_pxp_session.h"
+#include "gt/intel_context.h"
+#include "gt/intel_engine_pm.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt_buffer_pool.h"
+
+/* PXP GPU command definitions */
+
+/* MI_SET_APPID */
+#define MI_SET_APPID_SESSION_ID(x)((x) << 0)
+
+/* MI_FLUSH_DW */
+#define MI_FLUSH_DW_DW0_PROTECTED_MEMORY_ENABLE BIT(22)
+
+/* MI_WAIT */
+#define MFX_WAIT_DW0_PXP_SYNC_CONTROL_FLAG BIT(9)
+#define MFX_WAIT_DW0_MFX_SYNC_CONTROL_FLAG BIT(8)
+
+/* CRYPTO_KEY_EXCHANGE */
+#define CRYPTO_KEY_EXCHANGE ((0x3 << 29) | (0x01609 << 16))
+
+static struct i915_vma *intel_pxp_get_batch(struct intel_context *ce,
+ struct i915_gem_ww_ctx *ww,
+ u32 size)
+{
+ struct intel_gt_buffer_pool_node *pool;
+ struct i915_vma *batch;
+ int err;
+
+ intel_engine_pm_get(ce->engine);
+
+retry:
+ err = intel_context_pin_ww(ce, ww);
+ if (err)
+ goto out;
+
+ pool = intel_gt_get_buffer_pool(ce->engine->gt, size, I915_MAP_WC);
+ if (IS_ERR(pool)) {
+ err = PTR_ERR(pool);
+ goto out_ctx;
+ }
+
+ batch = i915_vma_instance(pool->obj, ce->vm, NULL);
+ if (IS_ERR(batch)) {
+ err = PTR_ERR(batch);
+ goto out_put;
+ }
+
+ err = i915_vma_pin_ww(batch, ww, 0, 0, PIN_USER);
+ if (unlikely(err))
+ goto out_put;
+
+ err = i915_gem_object_lock(pool->obj, ww);
+ if (err)
+ goto out_unpin;
+
+ batch->private = pool;
+
+ return batch;
+
+out_unpin:
+ i915_vma_unpin(batch);
+out_put:
+ intel_gt_buffer_pool_put(pool);
+out_ctx:
+ intel_context_unpin(ce);
+out:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(ww);
+ if (!err)
+ goto retry;
+ }
+ intel_engine_pm_put(ce->engine);
+ return ERR_PTR(err);
+}
+
+static void intel_pxp_put_batch(struct intel_context *ce,
+ struct i915_vma *batch)
+{
+ i915_vma_unpin(batch);
+ intel_gt_buffer_pool_put(batch->private);
+ intel_context_unpin(ce);
+ intel_engine_pm_put(ce->engine);
+}
+
+static int intel_pxp_submit_batch(struct intel_context *ce,
+ struct i915_vma *batch)
+{
+ struct i915_request *rq;
+ int err;
+
+ rq = i915_request_create(ce);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ err = i915_request_await_object(rq, batch->obj, false);
+ if (!err)
+ err = i915_vma_move_to_active(batch, rq, 0);
+ if (err)
+ goto out_rq;
+
+ err = intel_gt_buffer_pool_mark_active(batch->private, rq);
+ if (err)
+ goto out_rq;
+
+ if (ce->engine->emit_init_breadcrumb) {
+ err = ce->engine->emit_init_breadcrumb(rq);
+ if (err)
+ goto out_rq;
+ }
+
+ err = ce->engine->emit_bb_start(rq, batch->node.start,
+ batch->node.size, 0);
+ if (err)
+
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm/i915: Create stolen memory region from local memory
== Series Details == Series: series starting with [1/4] drm/i915: Create stolen memory region from local memory URL : https://patchwork.freedesktop.org/series/86861/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_reset.c:1323:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gvt/mmio.c:295:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1450:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1504:15: warning: memset with byte count of 16777216 +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' - different lock contexts for basic block ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915: Create stolen memory region from local memory
== Series Details == Series: series starting with [1/4] drm/i915: Create stolen memory region from local memory URL : https://patchwork.freedesktop.org/series/86861/ State : warning == Summary == $ dim checkpatch origin/drm-tip 016b7066311e drm/i915: Create stolen memory region from local memory -:13: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #13: as stolen-local or stolen-system based on this value won't work. Split -:220: WARNING:PREFER_FALLTHROUGH: Prefer 'fallthrough;' over fallthrough comment #220: FILE: drivers/gpu/drm/i915/intel_memory_region.c:285: + case INTEL_MEMORY_STOLEN_LOCAL: /* fallthrough */ total: 0 errors, 2 warnings, 0 checks, 201 lines checked 68cc67feb544 drm/i915/stolen: treat stolen local as normal local memory d9a90dbdf46c drm/i915/stolen: enforce the min_page_size contract ac735024977c drm/i915/stolen: pass the allocation flags ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove unused debug functions
== Series Details == Series: drm/i915: Remove unused debug functions URL : https://patchwork.freedesktop.org/series/86859/ State : success == Summary == CI Bug Log - changes from CI_DRM_9747 -> Patchwork_19632 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/index.html Known issues Here are the changes found in Patchwork_19632 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-gfx0: - fi-cfl-8700k: NOTRUN -> [SKIP][1] ([fdo#109271]) +25 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/fi-cfl-8700k/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271]) +23 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_exec_suspend@basic-s3: - fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#2411] / [i915#402]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html * igt@gem_flink_basic@bad-flink: - fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html - fi-cfl-8700k: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#2190]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/fi-cfl-8700k/igt@gem_huc_c...@huc-copy.html * igt@i915_pm_rpm@module-reload: - fi-byt-j1900: [PASS][9] -> [INCOMPLETE][10] ([i915#142] / [i915#2405]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-byt-j1900/igt@i915_pm_...@module-reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/fi-byt-j1900/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@execlists: - fi-bsw-nick:[PASS][11] -> [INCOMPLETE][12] ([i915#2940]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-bsw-nick/igt@i915_selftest@l...@execlists.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/fi-bsw-nick/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][13] ([i915#1886] / [i915#2291]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-soraka: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@vga-edid-read: - fi-cfl-8700k: NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +8 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/fi-cfl-8700k/igt@kms_chamel...@vga-edid-read.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-cfl-8700k: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#533]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/fi-cfl-8700k/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html - fi-kbl-soraka: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#533]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@runner@aborted: - fi-bsw-nick:NOTRUN -> [FAIL][18] ([i915#1436]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/fi-bsw-nick/igt@run...@aborted.html - fi-byt-j1900: NOTRUN -> [FAIL][19] ([i915#1814] / [i915#2505]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/fi-byt-j1900/igt@run...@aborted.html Possible fixes * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [DMESG-WARN][20] ([i915#402]) -> [PASS][21] +1 similar issue [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19632/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#142]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it
== Series Details ==
Series: drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it
URL : https://patchwork.freedesktop.org/series/86858/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9747 -> Patchwork_19631
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/index.html
Known issues
Here are the changes found in Patchwork_19631 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-tgl-y: NOTRUN -> [SKIP][1] ([fdo#109315] / [i915#2575]) +15
similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/fi-tgl-y/igt@amdgpu/amd_cs_...@fork-gfx0.html
* igt@amdgpu/amd_cs_nop@sync-fork-gfx0:
- fi-cfl-8700k: NOTRUN -> [SKIP][2] ([fdo#109271]) +25 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/fi-cfl-8700k/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html
* igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271]) +23 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
- fi-cfl-8700k: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/fi-cfl-8700k/igt@gem_huc_c...@huc-copy.html
* igt@gem_render_tiled_blits@basic:
- fi-tgl-y: [PASS][6] -> [DMESG-WARN][7] ([i915#402])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@gem_render_tiled_bl...@basic.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/fi-tgl-y/igt@gem_render_tiled_bl...@basic.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][8] ([i915#1886] / [i915#2291])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@vga-edid-read:
- fi-cfl-8700k: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/fi-cfl-8700k/igt@kms_chamel...@vga-edid-read.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-cfl-8700k: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#533])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/fi-cfl-8700k/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-kbl-soraka: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#533])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
Possible fixes
* igt@gem_sync@basic-each:
- fi-tgl-y: [DMESG-WARN][13] ([i915#402]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@gem_s...@basic-each.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/fi-tgl-y/igt@gem_s...@basic-each.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
[i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
Participating hosts (42 -> 38)
--
Additional (2): fi-kbl-soraka fi-cfl-8700k
Missing(6): fi-jsl-1 fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600
fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9747 -> Patchwork_19631
CI-20190529: 20190529
CI_DRM_9747: 65d67e70f9f78c7f8c2796956fdbdb69cffc7c98 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5998: b0160aad9e547d2205341e0b6783e12aa143566e @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19631: 9d9108a6b75e06a61e969fd80d2cc4f8fc47d128 @
Re: [Intel-gfx] [RFC 04/14] drm/i915/pxp: allocate a vcs context for pxp usage
On 2/6/2021 4:49 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2021-02-06 02:09:15)
The context is required to send the session termination commands to the
VCS, which will be implemented in a follow-up patch. We can also use the
presence of the context as a check of pxp initialization completion.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/Makefile | 4 ++
drivers/gpu/drm/i915/gt/intel_gt.c | 5 ++
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 ++
drivers/gpu/drm/i915/pxp/intel_pxp.c | 61 ++
drivers/gpu/drm/i915/pxp/intel_pxp.h | 35 +
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 15 ++
6 files changed, 123 insertions(+)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.c
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.h
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_types.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index ce01634d4ea7..e2677e8c03e8 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -268,6 +268,10 @@ i915-y += \
i915-y += i915_perf.o
+# Protected execution platform (PXP) support
+i915-$(CONFIG_DRM_I915_PXP) += \
+ pxp/intel_pxp.o
+
# Post-mortem debug and GPU hang state capture
i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
i915-$(CONFIG_DRM_I915_SELFTEST) += \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index ca76f93bc03d..daf61db620d6 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -20,6 +20,7 @@
#include "intel_uncore.h"
#include "intel_pm.h"
#include "shmem_utils.h"
+#include "pxp/intel_pxp.h"
void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915)
{
@@ -624,6 +625,8 @@ int intel_gt_init(struct intel_gt *gt)
if (err)
goto err_gt;
+ intel_pxp_init(>pxp);
+
goto out_fw;
err_gt:
__intel_gt_disable(gt);
@@ -658,6 +661,8 @@ void intel_gt_driver_unregister(struct intel_gt *gt)
intel_rps_driver_unregister(>rps);
+ intel_pxp_fini(>pxp);
+
/*
* Upon unregistering the device to prevent any new users, cancel
* all in-flight requests so that we can quickly unbind the active
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 626af37c7790..324d267eee15 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -23,6 +23,7 @@
#include "intel_rc6_types.h"
#include "intel_rps_types.h"
#include "intel_wakeref.h"
+#include "pxp/intel_pxp_types.h"
struct drm_i915_private;
struct i915_ggtt;
@@ -145,6 +146,8 @@ struct intel_gt {
/* Slice/subslice/EU info */
struct sseu_dev_info sseu;
} info;
+
+ struct intel_pxp pxp;
};
enum intel_gt_scratch_field {
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
new file mode 100644
index ..4ddc8a71a3e7
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2020 Intel Corporation.
+ */
+#include "intel_pxp.h"
+#include "gt/intel_context.h"
+#include "i915_drv.h"
+
+static int create_vcs_context(struct intel_pxp *pxp)
+{
+ struct intel_gt *gt = pxp_to_gt(pxp);
+ struct intel_context *ce = NULL;
+ int i;
+
+ /*
+* Find the first VCS engine present. We're guaranteed there is one
+* if we're in this function due to the check in has_pxp
+*/
+ for (i = 0; i < I915_MAX_VCS && !ce; i++)
+ if (HAS_ENGINE(gt, _VCS(i)))
+ ce = intel_context_create(gt->engine[_VCS(i)]);
Just wondering if
struct intel_engine_cs **vcs_engines = gt->engine_class[CLASS_VIDEO_DECODE];
for (i = 0; i < ARRAY_SIZE(gt->engine_class[CLASS_VIDEO_DECODE]); i++) {
if (!vcs_engines[i])
continue;
ce = intel_context_create(vcs_engines[i]);
break;
}
is a better iterator as it only checks one place of truth about whether
or not the engine exists.
for_each_engine_class(engine, gt, class, i)
A couple of places could use that.
+ if (IS_ERR(ce)) {
+ drm_err(>i915->drm, "failed to create VCS ctx for PXP\n");
+ return PTR_ERR(ce);
Is the lack of this feature enough to prevent module loading? Surely
userspace will notice and report the lack of the feature?
It's not, and we don't fail the load on this error, it's just used by
intel_pxp_init() to abort PXP enabling.
+ }
+
+ pxp->ce = ce;
Is protected context then implicitly tried to one engine? i.e.
userspace has to use the same engine as we control invalidation?
Otherwise, everytime we use pxp->ce we must impose barriers across all
Re: [Intel-gfx] [RFC 10/14] drm/i915/pxp: Enable PXP power management
On 2/6/2021 5:08 AM, Chris Wilson wrote:
Quoting Chris Wilson (2021-02-06 13:06:05)
Quoting Daniele Ceraolo Spurio (2021-02-06 02:09:21)
+ if (!ret) {
+ ret = wait_for(!pxp->termination_in_progress, 10);
This only works by chance. The compiler doesn't even have to reload the
variable. See struct completion.
This was a last minute addition when I was told that waiting on the
in_play state change was not enough to guarantee full invalidation and I
admit I didn't fully think it through because I want to get the RFC out.
It appears we already have a ready made one with the termination
i915_request. But that will require RCU pointer management...
-Chris
I've tried to keep this decoupled from the request because after the
request completion there is an MMIO write and only after that we start
waiting for the interrupt. I'll go with a struct completion.
Daniele
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Allow the module to load even if live selftests fail
== Series Details == Series: drm/i915/selftests: Allow the module to load even if live selftests fail URL : https://patchwork.freedesktop.org/series/86851/ State : success == Summary == CI Bug Log - changes from CI_DRM_9747 -> Patchwork_19630 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/index.html Known issues Here are the changes found in Patchwork_19630 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-gfx0: - fi-cfl-8700k: NOTRUN -> [SKIP][1] ([fdo#109271]) +25 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/fi-cfl-8700k/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271]) +23 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html - fi-cfl-8700k: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/fi-cfl-8700k/igt@gem_huc_c...@huc-copy.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][5] ([i915#1886] / [i915#2291]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@vga-edid-read: - fi-cfl-8700k: NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/fi-cfl-8700k/igt@kms_chamel...@vga-edid-read.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-cfl-8700k: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#533]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/fi-cfl-8700k/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html - fi-kbl-soraka: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#533]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@vgem_basic@create: - fi-tgl-y: [PASS][10] -> [DMESG-WARN][11] ([i915#402]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@vgem_ba...@create.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/fi-tgl-y/igt@vgem_ba...@create.html Possible fixes * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [DMESG-WARN][12] ([i915#402]) -> [PASS][13] +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533 Participating hosts (42 -> 38) -- Additional (2): fi-kbl-soraka fi-cfl-8700k Missing(6): fi-jsl-1 fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_9747 -> Patchwork_19630 CI-20190529: 20190529 CI_DRM_9747: 65d67e70f9f78c7f8c2796956fdbdb69cffc7c98 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5998: b0160aad9e547d2205341e0b6783e12aa143566e @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19630: 936b5936e3fccc8da80b05e3c0dacf159b2743b9 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 936b5936e3fc drm/i915/selftests: Allow the module to load even if live selftests fail == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19630/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 12/14] drm/i915/pxp: User interface for Protected buffer
On 2/6/2021 4:25 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2021-02-06 02:09:23)
From: Bommu Krishnaiah
This api allow user mode to create Protected buffer and context creation.
Only contexts created with the flag set are allowed to operate on
protected buffers.
We only allow setting the flags at creation time; the context flag also
requires the context to be marked as unrecoverable.
This is a rework + squash of the original code by Bommu Krishnaiah. I've
authorship unchanged since significant chunks have not been modified.
Signed-off-by: Bommu Krishnaiah
Signed-off-by: Daniele Ceraolo Spurio
Cc: Telukuntla Sreedhar
Cc: Kondapally Kalyan
Cc: Gupta Anshuman
Cc: Huang Sean Z
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 34 +++
drivers/gpu/drm/i915/gem/i915_gem_context.h | 6
.../gpu/drm/i915/gem/i915_gem_context_types.h | 1 +
drivers/gpu/drm/i915/gem/i915_gem_create.c| 27 +--
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 9 +
.../gpu/drm/i915/gem/i915_gem_object_types.h | 5 +++
drivers/gpu/drm/i915/pxp/intel_pxp.h | 10 ++
include/uapi/drm/i915_drm.h | 19 +++
8 files changed, 108 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ecacfae8412d..d3d9b4578ba8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -76,6 +76,8 @@
#include "gt/intel_gpu_commands.h"
#include "gt/intel_ring.h"
+#include "pxp/intel_pxp.h"
+
#include "i915_drm_client.h"
#include "i915_gem_context.h"
#include "i915_globals.h"
@@ -2006,6 +2008,27 @@ static int set_priority(struct i915_gem_context *ctx,
return 0;
}
+static int set_protected(struct i915_gem_context *ctx,
+const struct drm_i915_gem_context_param *args)
+{
+ int ret = 0;
+
+ if (ctx->client) /* can't change this after creation! */
+ ret = -EEXIST;
+ else if (args->size)
+ ret = -EINVAL;
+ else if (i915_gem_context_is_recoverable(ctx))
+ ret = -EPERM;
+ else if (!intel_pxp_is_enabled(>i915->gt.pxp))
+ ret = -ENODEV;
I like HW validity checks early. I think that gives a more consistent
response.
Ok, will do it first.
+ else if (args->value)
+ set_bit(UCONTEXT_PROTECTED, >user_flags);
+ else
+ clear_bit(UCONTEXT_PROTECTED, >user_flags);
+
+ return ret;
+}
+
static int ctx_setparam(struct drm_i915_file_private *fpriv,
struct i915_gem_context *ctx,
struct drm_i915_gem_context_param *args)
@@ -2045,6 +2068,8 @@ static int ctx_setparam(struct drm_i915_file_private
*fpriv,
case I915_CONTEXT_PARAM_RECOVERABLE:
if (args->size)
ret = -EINVAL;
+ else if (i915_gem_context_can_use_protected_content(ctx))
+ ret = -EPERM;
else if (args->value)
i915_gem_context_set_recoverable(ctx);
else
@@ -2075,6 +2100,10 @@ static int ctx_setparam(struct drm_i915_file_private
*fpriv,
ret = set_ringsize(ctx, args);
break;
+ case I915_CONTEXT_PARAM_PROTECTED_CONTENT:
+ ret = set_protected(ctx, args);
+ break;
+
case I915_CONTEXT_PARAM_BAN_PERIOD:
default:
ret = -EINVAL;
@@ -2532,6 +2561,11 @@ int i915_gem_context_getparam_ioctl(struct drm_device
*dev, void *data,
ret = get_ringsize(ctx, args);
break;
+ case I915_CONTEXT_PARAM_PROTECTED_CONTENT:
+ args->size = 0;
+ args->value = i915_gem_context_can_use_protected_content(ctx);
The getter should also report feature availability, i.e.
if (!intel_pxp_is_enabled(>i915->gt.pxp))
ret = -ENODEV;
else
args->value = i915_gem_context_can_use_protected_content(ctx);
Stick it in a get_protected_content() so it can sit next to the setter.
This allows userspace to do a feature query on an existing context (i.e.
the default context) without having to create anything [else]. For
example, that's useful for probing features sets once during screen setup.
ok
+ break;
+
case I915_CONTEXT_PARAM_BAN_PERIOD:
default:
ret = -EINVAL;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index b5c908f3f4f2..473bce972bb2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -108,6 +108,12 @@ i915_gem_context_clear_user_engines(struct
i915_gem_context *ctx)
clear_bit(CONTEXT_USER_ENGINES, >flags);
}
+static inline bool
Re: [Intel-gfx] [PATCH] drm/vblank: Avoid storing a timestamp for the same frame twice
On Mon, Feb 08, 2021 at 06:43:53PM +0100, Daniel Vetter wrote: > On Mon, Feb 8, 2021 at 5:58 PM Ville Syrjälä > wrote: > > > > On Mon, Feb 08, 2021 at 10:56:36AM +0100, Daniel Vetter wrote: > > > On Fri, Feb 05, 2021 at 11:19:19PM +0200, Ville Syrjälä wrote: > > > > On Fri, Feb 05, 2021 at 06:24:08PM +0200, Ville Syrjälä wrote: > > > > > On Fri, Feb 05, 2021 at 04:46:27PM +0100, Daniel Vetter wrote: > > > > > > On Thu, Feb 04, 2021 at 05:55:28PM +0200, Ville Syrjälä wrote: > > > > > > > On Thu, Feb 04, 2021 at 04:32:16PM +0100, Daniel Vetter wrote: > > > > > > > > On Thu, Feb 04, 2021 at 04:04:00AM +0200, Ville Syrjala wrote: > > > > > > > > > From: Ville Syrjälä > > > > > > > > > > > > > > > > > > drm_vblank_restore() exists because certain power saving > > > > > > > > > states > > > > > > > > > can clobber the hardware frame counter. The way it does this > > > > > > > > > is > > > > > > > > > by guesstimating how many frames were missed purely based on > > > > > > > > > the difference between the last stored timestamp vs. a newly > > > > > > > > > sampled timestamp. > > > > > > > > > > > > > > > > > > If we should call this function before a full frame has > > > > > > > > > elapsed since we sampled the last timestamp we would end up > > > > > > > > > with a possibly slightly different timestamp value for the > > > > > > > > > same frame. Currently we will happily overwrite the already > > > > > > > > > stored timestamp for the frame with the new value. This > > > > > > > > > could cause userspace to observe two different timestamps > > > > > > > > > for the same frame (and the timestamp could even go > > > > > > > > > backwards depending on how much error we introduce when > > > > > > > > > correcting the timestamp based on the scanout position). > > > > > > > > > > > > > > > > > > To avoid that let's not update the stored timestamp unless > > > > > > > > > we're > > > > > > > > > also incrementing the sequence counter. We do still want to > > > > > > > > > update > > > > > > > > > vblank->last with the freshly sampled hw frame counter value > > > > > > > > > so > > > > > > > > > that subsequent vblank irqs/queries can actually use the hw > > > > > > > > > frame > > > > > > > > > counter to determine how many frames have elapsed. > > > > > > > > > > > > > > > > Hm I'm not getting the reason for why we store the updated hw > > > > > > > > vblank > > > > > > > > counter? > > > > > > > > > > > > > > Because next time a vblank irq happens the code will do: > > > > > > > diff = current_hw_counter - vblank->last > > > > > > > > > > > > > > which won't work very well if vblank->last is garbage. > > > > > > > > > > > > > > Updating vblank->last is pretty much why drm_vblank_restore() > > > > > > > exists at all. > > > > > > > > > > > > Oh sure, _restore has to update this, together with the timestamp. > > > > > > > > > > > > But your code adds such an update where we update the hw vblank > > > > > > counter, > > > > > > but not the timestamp, and that feels buggy. Either we're still in > > > > > > the > > > > > > same frame, and then we should story nothing. Or we advanced, and > > > > > > then we > > > > > > probably want a new timestampt for that frame too. > > > > > > > > > > Even if we're still in the same frame the hw frame counter may already > > > > > have been reset due to the power well having been turned off. That is > > > > > what I'm trying to fix here. > > > > > > > > > > Now I suppose that's fairly unlikely, at least with PSR which probably > > > > > does impose some extra delays before the power gets yanked. But at > > > > > least > > > > > theoretically possible. > > > > > > > > Pondering about this a bit further. I think the fact that the current > > > > code takes the round-to-closest approach I used for the vblank handler > > > > is perhaps a bit bad. It could push the seq counter forward if we're > > > > past the halfway point of a frame. I think that rounding behaviour > > > > makes sense for the irq since those tick steadily and so allowing a bit > > > > of error either way seems correct to me. Perhaps round-down might be > > > > the better option for _restore(). Not quites sure, need more thinking > > > > probably. > > > > > > Yes this is the rounding I'm worried about. > > > > Actually I don't think this is really an issue since we are working > > with the corrected timestamps here. Those always line up with > > frames, so unless the correction is really buggy or the hw somehow > > skips a partial frame it should work rather well. At least when > > operating with small timescales. For large gaps the error might > > creep up, but I don't think a small error in the predicted seq > > number over a long timespan is really a problem. > > That corrected timestamp is what can go wrong I think: There's no > guarantee that drm_crtc_vblank_helper_get_vblank_timestamp_internal() > flips to top-of-frame at the exact same time than when the hw vblank > counter flips. Or at least I'm not
[Intel-gfx] [PATCH stable-5.10 2/2] drm/i915: Skip vswing programming for TBT
From: Ville Syrjälä
commit eaf5bfe37db871031232d2bf2535b6ca92afbad8 upstream.
In thunderbolt mode the PHY is owned by the thunderbolt controller.
We are not supposed to touch it. So skip the vswing programming
as well (we already skipped the other steps not applicable to TBT).
Touching this stuff could supposedly interfere with the PHY
programming done by the thunderbolt controller.
Cc: sta...@vger.kernel.org
Signed-off-by: Ville Syrjälä
Link:
https://patchwork.freedesktop.org/patch/msgid/20210128155948.13678-1-ville.syrj...@linux.intel.com
Reviewed-by: Imre Deak
(cherry picked from commit f8c6b615b921d8a1bcd74870f9105e62b0bceff3)
Signed-off-by: Jani Nikula
(cherry picked from commit eaf5bfe37db871031232d2bf2535b6ca92afbad8)
---
drivers/gpu/drm/i915/display/intel_ddi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 51f4f4374dea..cdb19ec66890 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2597,6 +2597,9 @@ static void icl_mg_phy_ddi_vswing_sequence(struct
intel_encoder *encoder,
u32 n_entries, val;
int ln, rate = 0;
+ if (enc_to_dig_port(encoder)->tc_mode == TC_PORT_TBT_ALT)
+ return;
+
if (type != INTEL_OUTPUT_HDMI) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
@@ -2741,6 +2744,9 @@ tgl_dkl_phy_ddi_vswing_sequence(struct intel_encoder
*encoder, int link_clock,
u32 n_entries, val, ln, dpcnt_mask, dpcnt_val;
int rate = 0;
+ if (enc_to_dig_port(encoder)->tc_mode == TC_PORT_TBT_ALT)
+ return;
+
if (type != INTEL_OUTPUT_HDMI) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH stable-5.10 1/2] drm/i915: Fix ICL MG PHY vswing handling
From: Ville Syrjälä
commit a2a5f5628e5494ca9353f761f7fe783dfa82fb9a upstream.
The MH PHY vswing table does have all the entries these days. Get
rid of the old hacks in the code which claim otherwise.
This hack was totally bogus anyway. The correct way to handle the
lack of those two entries would have been to declare our max
vswing and pre-emph to both be level 2.
Cc: José Roberto de Souza
Cc: Clinton Taylor
Fixes: 9f7ffa297978 ("drm/i915/tc/icl: Update TC vswing tables")
Signed-off-by: Ville Syrjälä
Link:
https://patchwork.freedesktop.org/patch/msgid/20201207203512.1718-1-ville.syrj...@linux.intel.com
Reviewed-by: Imre Deak
Reviewed-by: José Roberto de Souza
(cherry picked from commit 5ec346476e795089b7dac8ab9dcee30c8d80ad84)
Signed-off-by: Jani Nikula
(cherry picked from commit a2a5f5628e5494ca9353f761f7fe783dfa82fb9a)
---
drivers/gpu/drm/i915/display/intel_ddi.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 3f2bbd9370a8..51f4f4374dea 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2605,12 +2605,11 @@ static void icl_mg_phy_ddi_vswing_sequence(struct
intel_encoder *encoder,
ddi_translations = icl_get_mg_buf_trans(encoder, type, rate,
_entries);
- /* The table does not have values for level 3 and level 9. */
- if (level >= n_entries || level == 3 || level == 9) {
+ if (level >= n_entries) {
drm_dbg_kms(_priv->drm,
"DDI translation not found for level %d. Using %d
instead.",
- level, n_entries - 2);
- level = n_entries - 2;
+ level, n_entries - 1);
+ level = n_entries - 1;
}
/* Set MG_TX_LINK_PARAMS cri_use_fs32 to 0. */
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for i915: kvmgt: the KVM mmu_lock is now an rwlock
== Series Details == Series: i915: kvmgt: the KVM mmu_lock is now an rwlock URL : https://patchwork.freedesktop.org/series/86847/ State : success == Summary == CI Bug Log - changes from CI_DRM_9747 -> Patchwork_19629 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/index.html Known issues Here are the changes found in Patchwork_19629 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-gfx0: - fi-cfl-8700k: NOTRUN -> [SKIP][1] ([fdo#109271]) +25 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/fi-cfl-8700k/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html * igt@debugfs_test@read_all_entries: - fi-tgl-y: [PASS][2] -> [DMESG-WARN][3] ([i915#1982] / [i915#402]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@debugfs_test@read_all_entries.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/fi-tgl-y/igt@debugfs_test@read_all_entries.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271]) +23 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html - fi-cfl-8700k: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/fi-cfl-8700k/igt@gem_huc_c...@huc-copy.html * igt@gem_tiled_blits@basic: - fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@gem_tiled_bl...@basic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/fi-tgl-y/igt@gem_tiled_bl...@basic.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][9] ([i915#1886] / [i915#2291]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-soraka: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@vga-edid-read: - fi-cfl-8700k: NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/fi-cfl-8700k/igt@kms_chamel...@vga-edid-read.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-cfl-8700k: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#533]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/fi-cfl-8700k/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html - fi-kbl-soraka: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#533]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@runner@aborted: - fi-bdw-5557u: NOTRUN -> [FAIL][14] ([i915#1602] / [i915#2029] / [i915#2369]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/fi-bdw-5557u/igt@run...@aborted.html Possible fixes * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16] +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19629/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602 [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291 [i915#2369]: https://gitlab.freedesktop.org/drm/intel/issues/2369 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533 Participating hosts (42 -> 37) -- Additional (2): fi-kbl-soraka fi-cfl-8700k Missing(7): fi-jsl-1 fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux:
Re: [Intel-gfx] [PATCH] drm/vblank: Avoid storing a timestamp for the same frame twice
On Mon, Feb 8, 2021 at 5:58 PM Ville Syrjälä wrote: > > On Mon, Feb 08, 2021 at 10:56:36AM +0100, Daniel Vetter wrote: > > On Fri, Feb 05, 2021 at 11:19:19PM +0200, Ville Syrjälä wrote: > > > On Fri, Feb 05, 2021 at 06:24:08PM +0200, Ville Syrjälä wrote: > > > > On Fri, Feb 05, 2021 at 04:46:27PM +0100, Daniel Vetter wrote: > > > > > On Thu, Feb 04, 2021 at 05:55:28PM +0200, Ville Syrjälä wrote: > > > > > > On Thu, Feb 04, 2021 at 04:32:16PM +0100, Daniel Vetter wrote: > > > > > > > On Thu, Feb 04, 2021 at 04:04:00AM +0200, Ville Syrjala wrote: > > > > > > > > From: Ville Syrjälä > > > > > > > > > > > > > > > > drm_vblank_restore() exists because certain power saving states > > > > > > > > can clobber the hardware frame counter. The way it does this is > > > > > > > > by guesstimating how many frames were missed purely based on > > > > > > > > the difference between the last stored timestamp vs. a newly > > > > > > > > sampled timestamp. > > > > > > > > > > > > > > > > If we should call this function before a full frame has > > > > > > > > elapsed since we sampled the last timestamp we would end up > > > > > > > > with a possibly slightly different timestamp value for the > > > > > > > > same frame. Currently we will happily overwrite the already > > > > > > > > stored timestamp for the frame with the new value. This > > > > > > > > could cause userspace to observe two different timestamps > > > > > > > > for the same frame (and the timestamp could even go > > > > > > > > backwards depending on how much error we introduce when > > > > > > > > correcting the timestamp based on the scanout position). > > > > > > > > > > > > > > > > To avoid that let's not update the stored timestamp unless we're > > > > > > > > also incrementing the sequence counter. We do still want to > > > > > > > > update > > > > > > > > vblank->last with the freshly sampled hw frame counter value so > > > > > > > > that subsequent vblank irqs/queries can actually use the hw > > > > > > > > frame > > > > > > > > counter to determine how many frames have elapsed. > > > > > > > > > > > > > > Hm I'm not getting the reason for why we store the updated hw > > > > > > > vblank > > > > > > > counter? > > > > > > > > > > > > Because next time a vblank irq happens the code will do: > > > > > > diff = current_hw_counter - vblank->last > > > > > > > > > > > > which won't work very well if vblank->last is garbage. > > > > > > > > > > > > Updating vblank->last is pretty much why drm_vblank_restore() > > > > > > exists at all. > > > > > > > > > > Oh sure, _restore has to update this, together with the timestamp. > > > > > > > > > > But your code adds such an update where we update the hw vblank > > > > > counter, > > > > > but not the timestamp, and that feels buggy. Either we're still in the > > > > > same frame, and then we should story nothing. Or we advanced, and > > > > > then we > > > > > probably want a new timestampt for that frame too. > > > > > > > > Even if we're still in the same frame the hw frame counter may already > > > > have been reset due to the power well having been turned off. That is > > > > what I'm trying to fix here. > > > > > > > > Now I suppose that's fairly unlikely, at least with PSR which probably > > > > does impose some extra delays before the power gets yanked. But at least > > > > theoretically possible. > > > > > > Pondering about this a bit further. I think the fact that the current > > > code takes the round-to-closest approach I used for the vblank handler > > > is perhaps a bit bad. It could push the seq counter forward if we're > > > past the halfway point of a frame. I think that rounding behaviour > > > makes sense for the irq since those tick steadily and so allowing a bit > > > of error either way seems correct to me. Perhaps round-down might be > > > the better option for _restore(). Not quites sure, need more thinking > > > probably. > > > > Yes this is the rounding I'm worried about. > > Actually I don't think this is really an issue since we are working > with the corrected timestamps here. Those always line up with > frames, so unless the correction is really buggy or the hw somehow > skips a partial frame it should work rather well. At least when > operating with small timescales. For large gaps the error might > creep up, but I don't think a small error in the predicted seq > number over a long timespan is really a problem. That corrected timestamp is what can go wrong I think: There's no guarantee that drm_crtc_vblank_helper_get_vblank_timestamp_internal() flips to top-of-frame at the exact same time than when the hw vblank counter flips. Or at least I'm not seeing where we correct them both together. > > But your point above that the hw might reset the counter again is also > > valid. I'm assuming what you're worried about is that we first do a > > _restore (and the hw vblank counter hasn't been trashed yet), and then in > > the same frame we do another restore, but now the hw frame
[Intel-gfx] [PATCH 2/2] drm/i915/uapi: introduce drm_i915_gem_create_ext
Same old gem_create but with now with extensions support. This is needed
to support various upcoming usecases.
v2:(Chris)
- Use separate ioctl number for gem_create_ext, instead of hijacking
the existing gem_create ioctl, otherwise we run into the issue
with being unable to detect if the kernel supports the new extension
behaviour.
- We now have gem_create_ext.flags, which should be zeroed.
- I915_GEM_CREATE_EXT_SETPARAM value is now zero, since this is the
index into our array of extensions.
- Setup a "vanilla" object which we can directly apply our extensions
to.
Signed-off-by: Matthew Auld
Signed-off-by: CQ Tang
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 78 ++
drivers/gpu/drm/i915/gem/i915_gem_ioctls.h | 2 +
drivers/gpu/drm/i915/i915_drv.c| 1 +
include/uapi/drm/i915_drm.h| 51 ++
4 files changed, 132 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 6eee4b8bd0c2..bed5c13615d6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -8,6 +8,7 @@
#include "i915_drv.h"
#include "i915_trace.h"
+#include "i915_user_extensions.h"
static int i915_gem_publish(struct drm_i915_gem_object *obj,
struct drm_file *file,
@@ -116,6 +117,83 @@ i915_gem_dumb_create(struct drm_file *file,
return ret;
}
+struct create_ext {
+ struct drm_i915_private *i915;
+ struct drm_i915_gem_object *vanilla_object;
+};
+
+static int __create_setparam(struct drm_i915_gem_object_param *args,
+struct create_ext *ext_data)
+{
+ if (!(args->param & I915_OBJECT_PARAM)) {
+ DRM_DEBUG("Missing I915_OBJECT_PARAM namespace\n");
+ return -EINVAL;
+ }
+
+ return -EINVAL;
+}
+
+static int create_setparam(struct i915_user_extension __user *base, void *data)
+{
+ struct drm_i915_gem_create_ext_setparam ext;
+
+ if (copy_from_user(, base, sizeof(ext)))
+ return -EFAULT;
+
+ return __create_setparam(, data);
+}
+
+static const i915_user_extension_fn create_extensions[] = {
+ [I915_GEM_CREATE_EXT_SETPARAM] = create_setparam,
+};
+
+/**
+ * Creates a new mm object and returns a handle to it.
+ * @dev: drm device pointer
+ * @data: ioctl data blob
+ * @file: drm file pointer
+ */
+int
+i915_gem_create_ext_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file)
+{
+ struct drm_i915_private *i915 = to_i915(dev);
+ struct drm_i915_gem_create_ext *args = data;
+ struct create_ext ext_data = { .i915 = i915 };
+ struct drm_i915_gem_object *obj;
+ int ret;
+
+ if (args->flags)
+ return -EINVAL;
+
+ i915_gem_flush_free_objects(i915);
+
+ obj = i915_gem_object_alloc();
+ if (!obj)
+ return -ENOMEM;
+
+ ext_data.vanilla_object = obj;
+ ret = i915_user_extensions(u64_to_user_ptr(args->extensions),
+ create_extensions,
+ ARRAY_SIZE(create_extensions),
+ _data);
+ if (ret)
+ goto object_free;
+
+ ret = i915_gem_setup(obj,
+intel_memory_region_by_type(i915,
+INTEL_MEMORY_SYSTEM),
+args->size);
+ if (ret)
+ goto object_free;
+
+ return i915_gem_publish(obj, file, >size, >handle);
+
+object_free:
+ i915_gem_object_free(obj);
+ return ret;
+}
+
/**
* Creates a new mm object and returns a handle to it.
* @dev: drm device pointer
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ioctls.h
b/drivers/gpu/drm/i915/gem/i915_gem_ioctls.h
index 87d8b27f426d..3ee0e96f23f4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ioctls.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ioctls.h
@@ -14,6 +14,8 @@ int i915_gem_busy_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
int i915_gem_create_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
+int i915_gem_create_ext_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file);
int i915_gem_execbuffer_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
int i915_gem_execbuffer2_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b708517d3972..a0329e914ebf 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1749,6 +1749,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, drm_noop,
[Intel-gfx] [PATCH 1/2] drm/i915: rework gem_create flow for upcoming extensions
With the upcoming gem_create_ext we want to be able create a "vanilla"
object upfront and pass that directly to the extensions, before actually
initialising the object. Functionally this should be the same expect we
now feed the object into the lower-level region specific init_object.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 93 +++---
1 file changed, 66 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 45d60e3d98e3..6eee4b8bd0c2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -7,41 +7,52 @@
#include "gem/i915_gem_region.h"
#include "i915_drv.h"
+#include "i915_trace.h"
-static int
-i915_gem_create(struct drm_file *file,
- struct intel_memory_region *mr,
- u64 *size_p,
- u32 *handle_p)
+static int i915_gem_publish(struct drm_i915_gem_object *obj,
+ struct drm_file *file,
+ u64 *size_p,
+ u32 *handle_p)
{
- struct drm_i915_gem_object *obj;
u32 handle;
- u64 size;
+ int ret;
+
+ ret = drm_gem_handle_create(file, >base, );
+ /* drop reference from allocate - handle holds it now */
+ i915_gem_object_put(obj);
+ if (ret)
+ return ret;
+
+ *handle_p = handle;
+ *size_p = obj->base.size;
+ return 0;
+}
+
+static int
+i915_gem_setup(struct drm_i915_gem_object *obj,
+ struct intel_memory_region *mr,
+ u64 size)
+{
int ret;
GEM_BUG_ON(!is_power_of_2(mr->min_page_size));
- size = round_up(*size_p, mr->min_page_size);
+ size = round_up(size, mr->min_page_size);
if (size == 0)
return -EINVAL;
/* For most of the ABI (e.g. mmap) we think in system pages */
GEM_BUG_ON(!IS_ALIGNED(size, PAGE_SIZE));
- /* Allocate the new object */
- obj = i915_gem_object_create_region(mr, size, 0);
- if (IS_ERR(obj))
- return PTR_ERR(obj);
-
- GEM_BUG_ON(size != obj->base.size);
+ if (i915_gem_object_size_2big(size))
+ return -E2BIG;
- ret = drm_gem_handle_create(file, >base, );
- /* drop reference from allocate - handle holds it now */
- i915_gem_object_put(obj);
+ ret = mr->ops->init_object(mr, obj, size, 0);
if (ret)
return ret;
- *handle_p = handle;
- *size_p = size;
+ GEM_BUG_ON(size != obj->base.size);
+
+ trace_i915_gem_object_create(obj);
return 0;
}
@@ -50,9 +61,11 @@ i915_gem_dumb_create(struct drm_file *file,
struct drm_device *dev,
struct drm_mode_create_dumb *args)
{
+ struct drm_i915_gem_object *obj;
enum intel_memory_type mem_type;
int cpp = DIV_ROUND_UP(args->bpp, 8);
u32 format;
+ int ret;
switch (cpp) {
case 1:
@@ -85,10 +98,22 @@ i915_gem_dumb_create(struct drm_file *file,
if (HAS_LMEM(to_i915(dev)))
mem_type = INTEL_MEMORY_LOCAL;
- return i915_gem_create(file,
- intel_memory_region_by_type(to_i915(dev),
- mem_type),
- >size, >handle);
+ obj = i915_gem_object_alloc();
+ if (!obj)
+ return -ENOMEM;
+
+ ret = i915_gem_setup(obj,
+intel_memory_region_by_type(to_i915(dev),
+ mem_type),
+args->size);
+ if (ret)
+ goto object_free;
+
+ return i915_gem_publish(obj, file, >size, >handle);
+
+object_free:
+ i915_gem_object_free(obj);
+ return ret;
}
/**
@@ -103,11 +128,25 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data,
{
struct drm_i915_private *i915 = to_i915(dev);
struct drm_i915_gem_create *args = data;
+ struct drm_i915_gem_object *obj;
+ int ret;
i915_gem_flush_free_objects(i915);
- return i915_gem_create(file,
- intel_memory_region_by_type(i915,
- INTEL_MEMORY_SYSTEM),
- >size, >handle);
+ obj = i915_gem_object_alloc();
+ if (!obj)
+ return -ENOMEM;
+
+ ret = i915_gem_setup(obj,
+intel_memory_region_by_type(i915,
+INTEL_MEMORY_SYSTEM),
+args->size);
+ if (ret)
+ goto object_free;
+
+ return i915_gem_publish(obj, file, >size, >handle);
+
+object_free:
+ i915_gem_object_free(obj);
+ return ret;
}
--
[Intel-gfx] [PATCH 1/3] i915/perf: Store a mask of valid OA formats for a platform
Validity of an OA format is checked by using a sparse array of formats
per gen. Instead maintain a mask of supported formats for a platform in
the perf object.
v2: Use set_bit and test_bit style for the format_mask (Chris)
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 63 +-
drivers/gpu/drm/i915/i915_perf_types.h | 8
2 files changed, 70 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 89665e14ab01..7b6aab5f3e46 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3524,6 +3524,18 @@ static u64 oa_exponent_to_ns(struct i915_perf *perf, int
exponent)
2ULL << exponent);
}
+static __always_inline bool
+oa_format_valid(struct i915_perf *perf, enum drm_i915_oa_format format)
+{
+ return test_bit(format, perf->format_mask);
+}
+
+static __always_inline void
+oa_format_add(struct i915_perf *perf, enum drm_i915_oa_format format)
+{
+ __set_bit(format, perf->format_mask);
+}
+
/**
* read_properties_unlocked - validate + copy userspace stream open properties
* @perf: i915 perf instance
@@ -3615,7 +3627,7 @@ static int read_properties_unlocked(struct i915_perf
*perf,
value);
return -EINVAL;
}
- if (!perf->oa_formats[value].size) {
+ if (!oa_format_valid(perf, value)) {
DRM_DEBUG("Unsupported OA report format %llu\n",
value);
return -EINVAL;
@@ -4259,6 +4271,53 @@ static struct ctl_table dev_root[] = {
{}
};
+static void oa_init_supported_formats(struct i915_perf *perf)
+{
+ struct drm_i915_private *i915 = perf->i915;
+ enum intel_platform platform = INTEL_INFO(i915)->platform;
+
+ switch (platform) {
+ case INTEL_HASWELL:
+ oa_format_add(perf, I915_OA_FORMAT_A13);
+ oa_format_add(perf, I915_OA_FORMAT_A13);
+ oa_format_add(perf, I915_OA_FORMAT_A29);
+ oa_format_add(perf, I915_OA_FORMAT_A13_B8_C8);
+ oa_format_add(perf, I915_OA_FORMAT_B4_C8);
+ oa_format_add(perf, I915_OA_FORMAT_A45_B8_C8);
+ oa_format_add(perf, I915_OA_FORMAT_B4_C8_A16);
+ oa_format_add(perf, I915_OA_FORMAT_C4_B8);
+ break;
+
+ case INTEL_BROADWELL:
+ case INTEL_CHERRYVIEW:
+ case INTEL_SKYLAKE:
+ case INTEL_BROXTON:
+ case INTEL_KABYLAKE:
+ case INTEL_GEMINILAKE:
+ case INTEL_COFFEELAKE:
+ case INTEL_COMETLAKE:
+ case INTEL_CANNONLAKE:
+ case INTEL_ICELAKE:
+ case INTEL_ELKHARTLAKE:
+ case INTEL_JASPERLAKE:
+ oa_format_add(perf, I915_OA_FORMAT_A12);
+ oa_format_add(perf, I915_OA_FORMAT_A12_B8_C8);
+ oa_format_add(perf, I915_OA_FORMAT_A32u40_A4u32_B8_C8);
+ oa_format_add(perf, I915_OA_FORMAT_C4_B8);
+ break;
+
+ case INTEL_TIGERLAKE:
+ case INTEL_ROCKETLAKE:
+ case INTEL_DG1:
+ case INTEL_ALDERLAKE_S:
+ oa_format_add(perf, I915_OA_FORMAT_A32u40_A4u32_B8_C8);
+ break;
+
+ default:
+ MISSING_CASE(platform);
+ }
+}
+
/**
* i915_perf_init - initialize i915-perf state on module bind
* @i915: i915 device instance
@@ -4408,6 +4467,8 @@ void i915_perf_init(struct drm_i915_private *i915)
500 * 1000 /* 500us */);
perf->i915 = i915;
+
+ oa_init_supported_formats(perf);
}
}
diff --git a/drivers/gpu/drm/i915/i915_perf_types.h
b/drivers/gpu/drm/i915/i915_perf_types.h
index a36a455ae336..aa14354a5120 100644
--- a/drivers/gpu/drm/i915/i915_perf_types.h
+++ b/drivers/gpu/drm/i915/i915_perf_types.h
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include "gt/intel_sseu.h"
#include "i915_reg.h"
@@ -441,6 +442,13 @@ struct i915_perf {
struct i915_oa_ops ops;
const struct i915_oa_format *oa_formats;
+ /**
+* Use a format mask to store the supported formats
+* for a platform.
+*/
+#define FORMAT_MASK_SIZE DIV_ROUND_UP(I915_OA_FORMAT_MAX - 1, BITS_PER_LONG)
+ unsigned long format_mask[FORMAT_MASK_SIZE];
+
atomic64_t noa_programming_delay;
};
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] i915/perf: Add additional OA formats for gen12
Gen12 supports additional OA formats as compared to what was added earlier. Include the additional OA formats. Signed-off-by: Umesh Nerlige Ramappa Reviewed-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_perf.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c index e7e097ec70e7..93f3e2c5c89a 100644 --- a/drivers/gpu/drm/i915/i915_perf.c +++ b/drivers/gpu/drm/i915/i915_perf.c @@ -4292,17 +4292,14 @@ static void oa_init_supported_formats(struct i915_perf *perf) case INTEL_ICELAKE: case INTEL_ELKHARTLAKE: case INTEL_JASPERLAKE: - oa_format_add(perf, I915_OA_FORMAT_A12); - oa_format_add(perf, I915_OA_FORMAT_A12_B8_C8); - oa_format_add(perf, I915_OA_FORMAT_A32u40_A4u32_B8_C8); - oa_format_add(perf, I915_OA_FORMAT_C4_B8); - break; - case INTEL_TIGERLAKE: case INTEL_ROCKETLAKE: case INTEL_DG1: case INTEL_ALDERLAKE_S: + oa_format_add(perf, I915_OA_FORMAT_A12); + oa_format_add(perf, I915_OA_FORMAT_A12_B8_C8); oa_format_add(perf, I915_OA_FORMAT_A32u40_A4u32_B8_C8); + oa_format_add(perf, I915_OA_FORMAT_C4_B8); break; default: -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] i915/perf: Move OA formats to single array
Variations in OA formats in the different gens has led to creation of
several sparse arrays to store the formats.
Move oa formats into a single array and format_mask to check for
platform specific oa formats.
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 7b6aab5f3e46..e7e097ec70e7 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -302,7 +302,7 @@ static u32 i915_oa_max_sample_rate = 10;
* code assumes all reports have a power-of-two size and ~(size - 1) can
* be used as a mask to align the OA tail pointer.
*/
-static const struct i915_oa_format hsw_oa_formats[I915_OA_FORMAT_MAX] = {
+static const struct i915_oa_format oa_formats[I915_OA_FORMAT_MAX] = {
[I915_OA_FORMAT_A13]= { 0, 64 },
[I915_OA_FORMAT_A29]= { 1, 128 },
[I915_OA_FORMAT_A13_B8_C8] = { 2, 128 },
@@ -311,17 +311,9 @@ static const struct i915_oa_format
hsw_oa_formats[I915_OA_FORMAT_MAX] = {
[I915_OA_FORMAT_A45_B8_C8] = { 5, 256 },
[I915_OA_FORMAT_B4_C8_A16] = { 6, 128 },
[I915_OA_FORMAT_C4_B8] = { 7, 64 },
-};
-
-static const struct i915_oa_format gen8_plus_oa_formats[I915_OA_FORMAT_MAX] = {
[I915_OA_FORMAT_A12]= { 0, 64 },
[I915_OA_FORMAT_A12_B8_C8] = { 2, 128 },
[I915_OA_FORMAT_A32u40_A4u32_B8_C8] = { 5, 256 },
- [I915_OA_FORMAT_C4_B8] = { 7, 64 },
-};
-
-static const struct i915_oa_format gen12_oa_formats[I915_OA_FORMAT_MAX] = {
- [I915_OA_FORMAT_A32u40_A4u32_B8_C8] = { 5, 256 },
};
#define SAMPLE_OA_REPORT (1<<0)
@@ -4333,6 +4325,7 @@ void i915_perf_init(struct drm_i915_private *i915)
/* XXX const struct i915_perf_ops! */
+ perf->oa_formats = oa_formats;
if (IS_HASWELL(i915)) {
perf->ops.is_valid_b_counter_reg = gen7_is_valid_b_counter_addr;
perf->ops.is_valid_mux_reg = hsw_is_valid_mux_addr;
@@ -4343,8 +4336,6 @@ void i915_perf_init(struct drm_i915_private *i915)
perf->ops.oa_disable = gen7_oa_disable;
perf->ops.read = gen7_oa_read;
perf->ops.oa_hw_tail_read = gen7_oa_hw_tail_read;
-
- perf->oa_formats = hsw_oa_formats;
} else if (HAS_LOGICAL_RING_CONTEXTS(i915)) {
/* Note: that although we could theoretically also support the
* legacy ringbuffer mode on BDW (and earlier iterations of
@@ -4355,8 +4346,6 @@ void i915_perf_init(struct drm_i915_private *i915)
perf->ops.read = gen8_oa_read;
if (IS_GEN_RANGE(i915, 8, 9)) {
- perf->oa_formats = gen8_plus_oa_formats;
-
perf->ops.is_valid_b_counter_reg =
gen7_is_valid_b_counter_addr;
perf->ops.is_valid_mux_reg =
@@ -4387,8 +4376,6 @@ void i915_perf_init(struct drm_i915_private *i915)
perf->gen8_valid_ctx_bit = BIT(16);
}
} else if (IS_GEN_RANGE(i915, 10, 11)) {
- perf->oa_formats = gen8_plus_oa_formats;
-
perf->ops.is_valid_b_counter_reg =
gen7_is_valid_b_counter_addr;
perf->ops.is_valid_mux_reg =
@@ -4411,8 +4398,6 @@ void i915_perf_init(struct drm_i915_private *i915)
}
perf->gen8_valid_ctx_bit = BIT(16);
} else if (IS_GEN(i915, 12)) {
- perf->oa_formats = gen12_oa_formats;
-
perf->ops.is_valid_b_counter_reg =
gen12_is_valid_b_counter_addr;
perf->ops.is_valid_mux_reg =
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 05/14] drm/i915/pxp: set KCR reg init during the boot time
On Fri, Feb 05, 2021 at 06:09:16PM -0800, Daniele Ceraolo Spurio wrote:
> Set the KCR init during the boot time, which is required by hardware,
> to allow us doing further protection operation such as sending commands
> to GPU or TEE.
>
> Signed-off-by: Huang, Sean Z
> Signed-off-by: Daniele Ceraolo Spurio
> ---
> drivers/gpu/drm/i915/pxp/intel_pxp.c | 29 +++-
> 1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index 4ddc8a71a3e7..950daee5b907 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -6,6 +6,24 @@
> #include "gt/intel_context.h"
> #include "i915_drv.h"
>
> +/* KCR register definitions */
> +#define KCR_INIT _MMIO(0x320f0)
> +
> +/* Setting KCR Init bit is required after system boot */
> +#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
I still don't like the spread register defines... we will soon have some weird
duplications...
but seems a new trend...
rant aside:
Reviewed-by: Rodrigo Vivi
> +
> +static void kcr_pxp_enable(struct intel_gt *gt)
> +{
> + intel_uncore_write(gt->uncore, KCR_INIT,
> +
> _MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
> +}
> +
> +static void kcr_pxp_disable(struct intel_gt *gt)
> +{
> + intel_uncore_write(gt->uncore, KCR_INIT,
> +
> _MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
> +}
> +
> static int create_vcs_context(struct intel_pxp *pxp)
> {
> struct intel_gt *gt = pxp_to_gt(pxp);
> @@ -43,19 +61,28 @@ void intel_pxp_init(struct intel_pxp *pxp)
> if (!HAS_PXP(gt->i915))
> return;
>
> + kcr_pxp_enable(gt);
> +
> ret = create_vcs_context(pxp);
> if (ret)
> - return;
> + goto out_kcr;
>
> drm_info(>i915->drm, "Protected Xe Path (PXP) protected content
> support initialized\n");
>
> return;
> +
> +out_kcr:
> + kcr_pxp_disable(gt);
> }
>
> void intel_pxp_fini(struct intel_pxp *pxp)
> {
> + struct intel_gt *gt = pxp_to_gt(pxp);
> +
> if (!intel_pxp_is_enabled(pxp))
> return;
>
> destroy_vcs_context(pxp);
> +
> + kcr_pxp_disable(gt);
> }
> --
> 2.29.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/vblank: Avoid storing a timestamp for the same frame twice
On Mon, Feb 08, 2021 at 10:56:36AM +0100, Daniel Vetter wrote: > On Fri, Feb 05, 2021 at 11:19:19PM +0200, Ville Syrjälä wrote: > > On Fri, Feb 05, 2021 at 06:24:08PM +0200, Ville Syrjälä wrote: > > > On Fri, Feb 05, 2021 at 04:46:27PM +0100, Daniel Vetter wrote: > > > > On Thu, Feb 04, 2021 at 05:55:28PM +0200, Ville Syrjälä wrote: > > > > > On Thu, Feb 04, 2021 at 04:32:16PM +0100, Daniel Vetter wrote: > > > > > > On Thu, Feb 04, 2021 at 04:04:00AM +0200, Ville Syrjala wrote: > > > > > > > From: Ville Syrjälä > > > > > > > > > > > > > > drm_vblank_restore() exists because certain power saving states > > > > > > > can clobber the hardware frame counter. The way it does this is > > > > > > > by guesstimating how many frames were missed purely based on > > > > > > > the difference between the last stored timestamp vs. a newly > > > > > > > sampled timestamp. > > > > > > > > > > > > > > If we should call this function before a full frame has > > > > > > > elapsed since we sampled the last timestamp we would end up > > > > > > > with a possibly slightly different timestamp value for the > > > > > > > same frame. Currently we will happily overwrite the already > > > > > > > stored timestamp for the frame with the new value. This > > > > > > > could cause userspace to observe two different timestamps > > > > > > > for the same frame (and the timestamp could even go > > > > > > > backwards depending on how much error we introduce when > > > > > > > correcting the timestamp based on the scanout position). > > > > > > > > > > > > > > To avoid that let's not update the stored timestamp unless we're > > > > > > > also incrementing the sequence counter. We do still want to update > > > > > > > vblank->last with the freshly sampled hw frame counter value so > > > > > > > that subsequent vblank irqs/queries can actually use the hw frame > > > > > > > counter to determine how many frames have elapsed. > > > > > > > > > > > > Hm I'm not getting the reason for why we store the updated hw vblank > > > > > > counter? > > > > > > > > > > Because next time a vblank irq happens the code will do: > > > > > diff = current_hw_counter - vblank->last > > > > > > > > > > which won't work very well if vblank->last is garbage. > > > > > > > > > > Updating vblank->last is pretty much why drm_vblank_restore() > > > > > exists at all. > > > > > > > > Oh sure, _restore has to update this, together with the timestamp. > > > > > > > > But your code adds such an update where we update the hw vblank counter, > > > > but not the timestamp, and that feels buggy. Either we're still in the > > > > same frame, and then we should story nothing. Or we advanced, and then > > > > we > > > > probably want a new timestampt for that frame too. > > > > > > Even if we're still in the same frame the hw frame counter may already > > > have been reset due to the power well having been turned off. That is > > > what I'm trying to fix here. > > > > > > Now I suppose that's fairly unlikely, at least with PSR which probably > > > does impose some extra delays before the power gets yanked. But at least > > > theoretically possible. > > > > Pondering about this a bit further. I think the fact that the current > > code takes the round-to-closest approach I used for the vblank handler > > is perhaps a bit bad. It could push the seq counter forward if we're > > past the halfway point of a frame. I think that rounding behaviour > > makes sense for the irq since those tick steadily and so allowing a bit > > of error either way seems correct to me. Perhaps round-down might be > > the better option for _restore(). Not quites sure, need more thinking > > probably. > > Yes this is the rounding I'm worried about. Actually I don't think this is really an issue since we are working with the corrected timestamps here. Those always line up with frames, so unless the correction is really buggy or the hw somehow skips a partial frame it should work rather well. At least when operating with small timescales. For large gaps the error might creep up, but I don't think a small error in the predicted seq number over a long timespan is really a problem. > > But your point above that the hw might reset the counter again is also > valid. I'm assuming what you're worried about is that we first do a > _restore (and the hw vblank counter hasn't been trashed yet), and then in > the same frame we do another restore, but now the hw frame counter has > been trashe, and we need to update it? Yeah, although the pre-trashing _restore could also just be a vblank irq I think. > > > Another idea that came to me now is that maybe we should actually just > > check if the current hw frame counter value looks sane, as in something > > like: > > > > diff_hw_counter = current_hw_counter-stored_hw_counter > > diff_ts = (current_ts-stored_ts)/framedur > > > > if (diff_hw_counter ~= diff_ts) > > diff = diff_hw_counter; > > else > > diff = diff_ts; > > > > and if they seem to
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt/kvmgt: Fix the build failure in kvmgt.
== Series Details == Series: drm/i915/gvt/kvmgt: Fix the build failure in kvmgt. URL : https://patchwork.freedesktop.org/series/86845/ State : success == Summary == CI Bug Log - changes from CI_DRM_9747 -> Patchwork_19628 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/index.html Known issues Here are the changes found in Patchwork_19628 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-gfx0: - fi-cfl-8700k: NOTRUN -> [SKIP][1] ([fdo#109271]) +25 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/fi-cfl-8700k/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271]) +23 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_exec_suspend@basic-s3: - fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#2411] / [i915#402]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html - fi-cfl-8700k: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/fi-cfl-8700k/igt@gem_huc_c...@huc-copy.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][7] ([i915#1886] / [i915#2291]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-soraka: NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@vga-edid-read: - fi-cfl-8700k: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/fi-cfl-8700k/igt@kms_chamel...@vga-edid-read.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-cfl-8700k: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#533]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/fi-cfl-8700k/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html - fi-kbl-soraka: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#533]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@prime_vgem@basic-gtt: - fi-tgl-y: [PASS][12] -> [DMESG-WARN][13] ([i915#402]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@prime_v...@basic-gtt.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/fi-tgl-y/igt@prime_v...@basic-gtt.html * igt@runner@aborted: - fi-bdw-5557u: NOTRUN -> [FAIL][14] ([i915#1602] / [i915#2029] / [i915#2369]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/fi-bdw-5557u/igt@run...@aborted.html Possible fixes * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16] +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19628/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602 [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886 [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291 [i915#2369]: https://gitlab.freedesktop.org/drm/intel/issues/2369 [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533 Participating hosts (42 -> 38) -- Additional (2): fi-kbl-soraka fi-cfl-8700k Missing(6): fi-jsl-1 fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_9747 ->
[Intel-gfx] [PATCH 3/4] drm/i915/stolen: enforce the min_page_size contract
From: CQ Tang
Since stolen can now be device local-memory underneath, we should try to
enforce any min_page_size restrictions when allocating pages.
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index dfc3076abd0c..0722b909cd09 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -32,6 +32,7 @@ int i915_gem_stolen_insert_node_in_range(struct
drm_i915_private *i915,
struct drm_mm_node *node, u64 size,
unsigned alignment, u64 start, u64 end)
{
+ struct intel_memory_region *mem = i915_stolen_region(i915);
int ret;
if (!drm_mm_initialized(>mm.stolen))
@@ -41,6 +42,10 @@ int i915_gem_stolen_insert_node_in_range(struct
drm_i915_private *i915,
if (INTEL_GEN(i915) >= 8 && start < 4096)
start = 4096;
+ if (GEM_WARN_ON(!IS_ALIGNED(size, mem->min_page_size)) ||
+ GEM_WARN_ON(!IS_ALIGNED(alignment, mem->min_page_size)))
+ return -EINVAL;
+
mutex_lock(>mm.stolen_lock);
ret = drm_mm_insert_node_in_range(>mm.stolen, node,
size, alignment, 0,
@@ -674,7 +679,8 @@ static int _i915_gem_object_stolen_init(struct
intel_memory_region *mem,
if (!stolen)
return -ENOMEM;
- ret = i915_gem_stolen_insert_node(i915, stolen, size, 4096);
+ ret = i915_gem_stolen_insert_node(i915, stolen, size,
+ mem->min_page_size);
if (ret)
goto err_free;
@@ -814,8 +820,8 @@ i915_gem_object_create_stolen_for_preallocated(struct
drm_i915_private *i915,
/* KISS and expect everything to be page-aligned */
if (GEM_WARN_ON(size == 0) ||
- GEM_WARN_ON(!IS_ALIGNED(size, I915_GTT_PAGE_SIZE)) ||
- GEM_WARN_ON(!IS_ALIGNED(stolen_offset, I915_GTT_MIN_ALIGNMENT)))
+ GEM_WARN_ON(!IS_ALIGNED(size, mem->min_page_size)) ||
+ GEM_WARN_ON(!IS_ALIGNED(stolen_offset, mem->min_page_size)))
return ERR_PTR(-EINVAL);
stolen = kzalloc(sizeof(*stolen), GFP_KERNEL);
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915/stolen: pass the allocation flags
From: CQ Tang
Stolen memory is always allocated as physically contiguous pages, mark
the object flags as such.
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 0722b909cd09..b903ba95cf8f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -637,7 +637,8 @@ static const struct drm_i915_gem_object_ops
i915_gem_object_stolen_ops = {
static int __i915_gem_object_create_stolen(struct intel_memory_region *mem,
struct drm_i915_gem_object *obj,
- struct drm_mm_node *stolen)
+ struct drm_mm_node *stolen,
+ unsigned int flags)
{
static struct lock_class_key lock_class;
unsigned int cache_level;
@@ -655,7 +656,7 @@ static int __i915_gem_object_create_stolen(struct
intel_memory_region *mem,
if (err)
return err;
- i915_gem_object_init_memory_region(obj, mem, 0);
+ i915_gem_object_init_memory_region(obj, mem, flags);
return 0;
}
@@ -684,7 +685,7 @@ static int _i915_gem_object_stolen_init(struct
intel_memory_region *mem,
if (ret)
goto err_free;
- ret = __i915_gem_object_create_stolen(mem, obj, stolen);
+ ret = __i915_gem_object_create_stolen(mem, obj, stolen, flags);
if (ret)
goto err_remove;
@@ -842,7 +843,8 @@ i915_gem_object_create_stolen_for_preallocated(struct
drm_i915_private *i915,
goto err_stolen;
}
- ret = __i915_gem_object_create_stolen(mem, obj, stolen);
+ ret = __i915_gem_object_create_stolen(mem, obj, stolen,
+ I915_BO_ALLOC_CONTIGUOUS);
if (ret)
goto err_object_free;
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915/stolen: treat stolen local as normal local memory
Underneath it's the same stuff, so things like the PTE_LM bits for the
GTT should just keep working as-is.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index 194f35342710..078484d5e3f5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -19,7 +19,10 @@ const struct drm_i915_gem_object_ops i915_gem_lmem_obj_ops =
{
bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj)
{
- return obj->ops == _gem_lmem_obj_ops;
+ struct intel_memory_region *mr = obj->mm.region;
+
+ return mr && (mr->type == INTEL_MEMORY_LOCAL ||
+ mr->type == INTEL_MEMORY_STOLEN_LOCAL);
}
struct drm_i915_gem_object *
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: Create stolen memory region from local memory
From: CQ Tang
Add "REGION_STOLEN" device info to dg1, create stolen memory
region from upper portion of local device memory, starting
from DSMBASE.
v2:
- s/drm_info/drm_dbg; userspace likely doesn't care about stolen.
- mem->type is only setup after the region probe, so setting the name
as stolen-local or stolen-system based on this value won't work. Split
system vs local stolen setup to fix this.
- kill all the region->devmem/is_devmem stuff. We already differentiate
the different types of stolen so such things shouldn't be needed
anymore.
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 90 --
drivers/gpu/drm/i915/gem/i915_gem_stolen.h | 3 +
drivers/gpu/drm/i915/i915_pci.c| 2 +-
drivers/gpu/drm/i915/i915_reg.h| 1 +
drivers/gpu/drm/i915/intel_memory_region.c | 5 ++
drivers/gpu/drm/i915/intel_memory_region.h | 5 +-
6 files changed, 96 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index c5f85296a45f..dfc3076abd0c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -10,6 +10,7 @@
#include
#include
+#include "gem/i915_gem_lmem.h"
#include "gem/i915_gem_region.h"
#include "i915_drv.h"
#include "i915_gem_stolen.h"
@@ -121,6 +122,14 @@ static int i915_adjust_stolen(struct drm_i915_private
*i915,
}
}
+ /*
+* With device local memory, we don't need to check the address range,
+* this is device memory physical address, could overlap with system
+* memory.
+*/
+ if (HAS_LMEM(i915))
+ return 0;
+
/*
* Verify that nothing else uses this physical address. Stolen
* memory should be reserved by the BIOS and hidden from the
@@ -682,17 +691,30 @@ static int _i915_gem_object_stolen_init(struct
intel_memory_region *mem,
return ret;
}
+struct intel_memory_region *i915_stolen_region(struct drm_i915_private *i915)
+{
+ if (HAS_LMEM(i915))
+ return i915->mm.regions[INTEL_REGION_STOLEN_LMEM];
+
+ return i915->mm.regions[INTEL_REGION_STOLEN_SMEM];
+}
+
struct drm_i915_gem_object *
i915_gem_object_create_stolen(struct drm_i915_private *i915,
resource_size_t size)
{
- return
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_STOLEN_SMEM],
+ return i915_gem_object_create_region(i915_stolen_region(i915),
size, I915_BO_ALLOC_CONTIGUOUS);
}
static int init_stolen(struct intel_memory_region *mem)
{
- intel_memory_region_set_name(mem, "stolen");
+ if (HAS_LMEM(mem->i915)) {
+ if (!io_mapping_init_wc(>iomap,
+ mem->io_start,
+ resource_size(>region)))
+ return -EIO;
+ }
/*
* Initialise stolen early so that we may reserve preallocated
@@ -712,13 +734,65 @@ static const struct intel_memory_region_ops
i915_region_stolen_ops = {
.init_object = _i915_gem_object_stolen_init,
};
+static struct intel_memory_region *
+setup_lmem_stolen(struct drm_i915_private *i915)
+{
+ struct intel_uncore *uncore = >uncore;
+ struct pci_dev *pdev = i915->drm.pdev;
+ struct intel_memory_region *mem;
+ resource_size_t io_start;
+ resource_size_t lmem_size;
+ u64 lmem_base;
+
+ if (!IS_DGFX(i915))
+ return ERR_PTR(-ENODEV);
+
+ lmem_base = intel_uncore_read64(uncore, GEN12_DSMBASE);
+ lmem_size = pci_resource_len(pdev, 2) - lmem_base;
+ io_start = pci_resource_start(pdev, 2) + lmem_base;
+
+ mem = intel_memory_region_create(i915, lmem_base, lmem_size,
+I915_GTT_PAGE_SIZE_4K, io_start,
+_region_stolen_ops);
+ if (IS_ERR(mem))
+ return mem;
+
+ drm_dbg(>drm, "Stolen Local memory: %pR\n", >region);
+ drm_dbg(>drm, "Stolen Local memory IO start: %pa\n",
+ >io_start);
+
+ intel_memory_region_set_name(mem, "stolen-local");
+
+ return mem;
+}
+
+static struct intel_memory_region*
+setup_smem_stolen(struct drm_i915_private *i915)
+{
+ struct intel_memory_region *mem;
+
+ mem = intel_memory_region_create(i915,
+intel_graphics_stolen_res.start,
+
resource_size(_graphics_stolen_res),
+PAGE_SIZE, 0,
+_region_stolen_ops);
+ if (IS_ERR(mem))
+ return mem;
+
+ intel_memory_region_set_name(mem, "stolen-system");
+
+ return mem;
+}
+
struct intel_memory_region
Re: [Intel-gfx] [PATCH 09/31] drm/i915: Replace priolist rbtree with a skiplist
Quoting Tvrtko Ursulin (2021-02-08 15:23:17)
>
> On 08/02/2021 10:52, Chris Wilson wrote:
> > static struct list_head *
> > lookup_priolist(struct i915_sched *se, int prio)
> > {
> > - struct i915_priolist *p;
> > - struct rb_node **parent, *rb;
> > - bool first = true;
> > + struct i915_priolist *update[I915_PRIOLIST_HEIGHT];
> > + struct i915_priolist_root *const root = >queue;
> > + struct i915_priolist *pl, *tmp;
> > + int lvl;
> >
> > lockdep_assert_held(>lock);
> > - assert_priolists(se);
> > -
> > if (unlikely(se->no_priolist))
> > prio = I915_PRIORITY_NORMAL;
> >
> > + for_each_priolist(pl, root) { /* recycle any empty elements before us
> > */
> > + if (pl->priority <= prio || !list_empty(>requests))
> > + break;
>
> This less part of the less-or-equal condition keeps confusing me as a
> break criteria. If premise is cleaning up, why break on first smaller
> prio? Would the idea be to prune all empty lists up to, not including,
> the lookup prio?
Just parcelling up the work. If we tidy up all the unused nodes before
us, we insert ourselves at the head of the tree, and all the cheap
checks to see if this is the first request, or to find the first
request are happy.
It's not expected to find anything unused with the tweaks to tidy up
empty elements as we move between i915_priolist.requests, but it seems
sensible to keep as then it should be just checking the first
i915_priolist and breaking out.
> > -void __i915_priolist_free(struct i915_priolist *p)
> > +static void __remove_priolist(struct i915_sched *se, struct list_head
> > *plist)
> > {
> > - kmem_cache_free(global.slab_priorities, p);
> > + struct i915_priolist_root *root = >queue;
> > + struct i915_priolist *pl, *tmp;
> > + struct i915_priolist *old =
> > + container_of(plist, struct i915_priolist, requests);
> > + int prio = old->priority;
> > + int lvl;
> > +
> > + lockdep_assert_held(>lock);
> > + GEM_BUG_ON(!list_empty(plist));
> > +
> > + pl = >sentinel;
> > + lvl = pl->level;
> > + GEM_BUG_ON(lvl < 0);
> > +
> > + if (prio != I915_PRIORITY_NORMAL)
> > + pl_push(old, >requests);
> > +
> > + do {
> > + while (tmp = pl->next[lvl], tmp->priority > prio)
> > + pl = tmp;
> > + if (lvl <= old->level) {
> > + pl->next[lvl] = old->next[lvl];
> > + if (pl == >sentinel && old->next[lvl] == pl) {
> > + GEM_BUG_ON(pl->level != lvl);
> > + pl->level--;
> > + }
> > + }
> > + } while (--lvl >= 0);
> > + GEM_BUG_ON(tmp != old);
> > +}
> > +struct i915_priolist *__i915_sched_dequeue_next(struct i915_sched *se)
> > +{
> > + struct i915_priolist * const s = >queue.sentinel;
> > + struct i915_priolist *pl = s->next[0];
> > + int lvl;
> > +
> > + GEM_BUG_ON(!list_empty(>requests));
> > + GEM_BUG_ON(pl == s);
> > +
> > + /* Keep pl->next[0] valid for for_each_priolist iteration */
> > + if (pl->priority != I915_PRIORITY_NORMAL)
> > + pl_push(pl, >requests);
> > +
> > + lvl = pl->level;
> > + GEM_BUG_ON(lvl < 0);
> > + do {
> > + s->next[lvl] = pl->next[lvl];
> > + if (pl->next[lvl] == s) {
> > + GEM_BUG_ON(s->level != lvl);
> > + s->level--;
> > + }
> > + } while (--lvl >= 0);
> > +
> > + return pl->next[0];
> > }
>
> If both __i915_sched_dequeue_next and __remove_priolist are removing an
> empty list from the hieararchy, why can't they shared some code?
The __remove_priolist does the general search and remove, whereas
dequeue_next is trying to keep O(1) remove-from-head. dequeue_next is
meant to be called many, many more times than __remove_priolist.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gvt/kvmgt: Fix the build failure in kvmgt.
== Series Details ==
Series: drm/i915/gvt/kvmgt: Fix the build failure in kvmgt.
URL : https://patchwork.freedesktop.org/series/86845/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a0e31f3d4bbc drm/i915/gvt/kvmgt: Fix the build failure in kvmgt.
-:6: WARNING:UNKNOWN_COMMIT_ID: Unknown commit id '531810caa9f4', maybe rebased
or not pulled?
#6:
Previously, commit 531810caa9f4 ("KVM: x86/mmu: Use
total: 0 errors, 1 warnings, 0 checks, 48 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/31] drm/i915/gt: Ratelimit heartbeat completion probing
== Series Details == Series: series starting with [01/31] drm/i915/gt: Ratelimit heartbeat completion probing URL : https://patchwork.freedesktop.org/series/86841/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9747 -> Patchwork_19626 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19626 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19626, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19626/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19626: ### IGT changes ### Possible regressions * igt@i915_selftest@live@execlists: - fi-bsw-kefka: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19626/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html Known issues Here are the changes found in Patchwork_19626 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-gfx0: - fi-cfl-8700k: NOTRUN -> [SKIP][3] ([fdo#109271]) +25 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19626/fi-cfl-8700k/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271]) +23 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19626/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_exec_suspend@basic-s3: - fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#2411] / [i915#402]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19626/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19626/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html - fi-cfl-8700k: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#2190]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19626/fi-cfl-8700k/igt@gem_huc_c...@huc-copy.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][9] ([i915#1886] / [i915#2291]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19626/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-soraka: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19626/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@hdmi-edid-read: - fi-kbl-7500u: [PASS][11] -> [FAIL][12] ([i915#2128]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19626/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html * igt@kms_chamelium@vga-edid-read: - fi-cfl-8700k: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19626/fi-cfl-8700k/igt@kms_chamel...@vga-edid-read.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-cfl-8700k: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#533]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19626/fi-cfl-8700k/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html - fi-kbl-soraka: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#533]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19626/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@prime_self_import@basic-with_one_bo_two_files: - fi-tgl-y: [PASS][16] -> [DMESG-WARN][17] ([i915#402]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19626/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html Possible fixes * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [DMESG-WARN][18] ([i915#402]) -> [PASS][19] +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [19]:
Re: [Intel-gfx] [PATCH 10/31] drm/i915: Fair low-latency scheduling
Quoting Tvrtko Ursulin (2021-02-08 16:03:03)
>
> On 08/02/2021 15:29, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2021-02-08 14:56:31)
> >> On 08/02/2021 10:52, Chris Wilson wrote:
> >>> +static bool need_preempt(const struct intel_engine_cs *engine,
> >>> const struct i915_request *rq)
> >>>{
> >>>const struct i915_sched *se = >sched;
> >>> - int last_prio;
> >>> + const struct i915_request *first = NULL;
> >>> + const struct i915_request *next;
> >>>
> >>>if (!i915_sched_use_busywait(se))
> >>>return false;
> >>>
> >>>/*
> >>> - * Check if the current priority hint merits a preemption attempt.
> >>> - *
> >>> - * We record the highest value priority we saw during rescheduling
> >>> - * prior to this dequeue, therefore we know that if it is strictly
> >>> - * less than the current tail of ESLP[0], we do not need to force
> >>> - * a preempt-to-idle cycle.
> >>> - *
> >>> - * However, the priority hint is a mere hint that we may need to
> >>> - * preempt. If that hint is stale or we may be trying to preempt
> >>> - * ourselves, ignore the request.
> >>> - *
> >>> - * More naturally we would write
> >>> - * prio >= max(0, last);
> >>> - * except that we wish to prevent triggering preemption at the same
> >>> - * priority level: the task that is running should remain running
> >>> - * to preserve FIFO ordering of dependencies.
> >>> + * If this request is special and must not be interrupted at any
> >>> + * cost, so be it. Note we are only checking the most recent request
> >>> + * in the context and so may be masking an earlier vip request. It
> >>> + * is hoped that under the conditions where nopreempt is used, this
> >>> + * will not matter (i.e. all requests to that context will be
> >>> + * nopreempt for as long as desired).
> >>> */
> >>> - last_prio = max(effective_prio(rq), I915_PRIORITY_NORMAL - 1);
> >>> - if (engine->execlists.queue_priority_hint <= last_prio)
> >>> + if (i915_request_has_nopreempt(rq))
> >>>return false;
> >>>
> >>>/*
> >>> * Check against the first request in ELSP[1], it will, thanks to
> >>> the
> >>> * power of PI, be the highest priority of that context.
> >>> */
> >>> - if (!list_is_last(>sched.link, >requests) &&
> >>> - rq_prio(list_next_entry(rq, sched.link)) > last_prio)
> >>> - return true;
> >>> + next = next_elsp_request(se, rq);
> >>> + if (dl_before(next, first))
> >>
> >> Here first is always NULL so dl_before always returns true, meaning it
> >> appears redundant to call it.
> >
> > I was applying a pattern :)
>
> Yeah, thought so. It's fine.
>
> >
> >>
> >>> + first = next;
> >>>
> >>>/*
> >>> * If the inflight context did not trigger the preemption, then
> >>> maybe
> >>> @@ -356,8 +343,31 @@ static bool need_preempt(struct intel_engine_cs
> >>> *engine,
> >>> * ELSP[0] or ELSP[1] as, thanks again to PI, if it was the same
> >>> * context, it's priority would not exceed ELSP[0] aka last_prio.
> >>> */
> >>> - return max(virtual_prio(>execlists),
> >>> -queue_prio(se)) > last_prio;
> >>> + next = first_request(se);
> >>> + if (dl_before(next, first))
> >>> + first = next; > +
> >>> + next = first_virtual(engine);
> >>> + if (dl_before(next, first))
> >>> + first = next;
> >>> +
> >>> + if (!dl_before(first, rq))
> >>> + return false;
> >>
> >> Ends up earliest deadline between list of picks: elsp[1] (or maybe next
> >> in context, depends on coalescing criteria), first in the priolist,
> >> first virtual.
> >>
> >> Virtual has a separate queue so that's understandable, but can "elsp[1]"
> >> really have an earlier deadling than first_request() (head of thepriolist)?
> >
> > elsp[1] could have been promoted and thus now have an earlier deadline
> > than elsp[0]. Consider the heartbeat as a trivial example that is first
> > submitted at very low priority, but by the end has absolute priority.
>
> The tree is not kept sorted at all times, or at least at the time
> need_preempt peeks at it?
The tree of priorites/deadline itself is sorted. ELSP[] is the HW
runlist, which is a snapshot at the time of submission (and while it
should have been in order, may not now e).
need_preempt() tries to answer the question of "if I were to unwind
everything, would the first request in the resulting priority tree be of
earlier deadline & higher priority than the currently running request?".
So we have to guess the future shape of the tree.
> >>> +static u64 virtual_deadline(u64 kt, int priority)
> >>> +{
> >>> + return i915_sched_to_ticks(kt + prio_slice(priority));
> >>> +}
> >>> +
> >>> +u64
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix HAS_LSPCON macro for platforms between GEN9 and GEN10 (rev2)
== Series Details == Series: drm/i915: Fix HAS_LSPCON macro for platforms between GEN9 and GEN10 (rev2) URL : https://patchwork.freedesktop.org/series/86842/ State : failure == Summary == Applying: drm/i915: Fix HAS_LSPCON macro for platforms between GEN9 and GEN10 Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_drv.h Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_drv.h No changes -- Patch already applied. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/31] drm/i915: Fair low-latency scheduling
On 08/02/2021 15:29, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2021-02-08 14:56:31)
On 08/02/2021 10:52, Chris Wilson wrote:
+static bool need_preempt(const struct intel_engine_cs *engine,
const struct i915_request *rq)
{
const struct i915_sched *se = >sched;
- int last_prio;
+ const struct i915_request *first = NULL;
+ const struct i915_request *next;
if (!i915_sched_use_busywait(se))
return false;
/*
- * Check if the current priority hint merits a preemption attempt.
- *
- * We record the highest value priority we saw during rescheduling
- * prior to this dequeue, therefore we know that if it is strictly
- * less than the current tail of ESLP[0], we do not need to force
- * a preempt-to-idle cycle.
- *
- * However, the priority hint is a mere hint that we may need to
- * preempt. If that hint is stale or we may be trying to preempt
- * ourselves, ignore the request.
- *
- * More naturally we would write
- * prio >= max(0, last);
- * except that we wish to prevent triggering preemption at the same
- * priority level: the task that is running should remain running
- * to preserve FIFO ordering of dependencies.
+ * If this request is special and must not be interrupted at any
+ * cost, so be it. Note we are only checking the most recent request
+ * in the context and so may be masking an earlier vip request. It
+ * is hoped that under the conditions where nopreempt is used, this
+ * will not matter (i.e. all requests to that context will be
+ * nopreempt for as long as desired).
*/
- last_prio = max(effective_prio(rq), I915_PRIORITY_NORMAL - 1);
- if (engine->execlists.queue_priority_hint <= last_prio)
+ if (i915_request_has_nopreempt(rq))
return false;
/*
* Check against the first request in ELSP[1], it will, thanks to the
* power of PI, be the highest priority of that context.
*/
- if (!list_is_last(>sched.link, >requests) &&
- rq_prio(list_next_entry(rq, sched.link)) > last_prio)
- return true;
+ next = next_elsp_request(se, rq);
+ if (dl_before(next, first))
Here first is always NULL so dl_before always returns true, meaning it
appears redundant to call it.
I was applying a pattern :)
Yeah, thought so. It's fine.
+ first = next;
/*
* If the inflight context did not trigger the preemption, then maybe
@@ -356,8 +343,31 @@ static bool need_preempt(struct intel_engine_cs *engine,
* ELSP[0] or ELSP[1] as, thanks again to PI, if it was the same
* context, it's priority would not exceed ELSP[0] aka last_prio.
*/
- return max(virtual_prio(>execlists),
-queue_prio(se)) > last_prio;
+ next = first_request(se);
+ if (dl_before(next, first))
+ first = next; > +
+ next = first_virtual(engine);
+ if (dl_before(next, first))
+ first = next;
+
+ if (!dl_before(first, rq))
+ return false;
Ends up earliest deadline between list of picks: elsp[1] (or maybe next
in context, depends on coalescing criteria), first in the priolist,
first virtual.
Virtual has a separate queue so that's understandable, but can "elsp[1]"
really have an earlier deadling than first_request() (head of thepriolist)?
elsp[1] could have been promoted and thus now have an earlier deadline
than elsp[0]. Consider the heartbeat as a trivial example that is first
submitted at very low priority, but by the end has absolute priority.
The tree is not kept sorted at all times, or at least at the time
need_preempt peeks at it?
+static u64 virtual_deadline(u64 kt, int priority)
+{
+ return i915_sched_to_ticks(kt + prio_slice(priority));
+}
+
+u64 i915_scheduler_next_virtual_deadline(int priority)
+{
+ return virtual_deadline(ktime_get_mono_fast_ns(), priority);
+}
This helpers becomes a bit odd in that the only two callers are rewind
and defer. And it queries ktime, while before deadline was set based on
signalers.
Where is the place which set the ktime based deadline (converted to
ticks) for requests with no signalers?
signal_deadline() with no signalers returns now. So the first request in
a sequence is queued with virtual_deadline(now() + prio_slice()).
Ah ok.
void i915_request_enqueue(struct i915_request *rq)
{
- struct intel_engine_cs *engine = rq->engine;
- struct i915_sched *se = intel_engine_get_scheduler(engine);
+ struct i915_sched *se = i915_request_get_scheduler(rq);
+ u64 dl = earliest_deadline(se, rq);
unsigned long flags;
bool kick = false;
@@ -880,11 +1107,11 @@ void i915_request_enqueue(struct i915_request *rq)
list_add_tail(>sched.link, >hold);
i915_request_set_hold(rq);
} else {
-
[Intel-gfx] [PATCH] drm/i915: Remove unused debug functions
Remove or hide unused debug functions from clang, or else it moans.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_sw_fence.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
b/drivers/gpu/drm/i915/i915_sw_fence.c
index dfabf291e5cd..566bc48e5b0c 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -49,10 +49,12 @@ static inline void debug_fence_init(struct i915_sw_fence
*fence)
debug_object_init(fence, _sw_fence_debug_descr);
}
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
static inline void debug_fence_init_onstack(struct i915_sw_fence *fence)
{
debug_object_init_on_stack(fence, _sw_fence_debug_descr);
}
+#endif
static inline void debug_fence_activate(struct i915_sw_fence *fence)
{
@@ -92,9 +94,11 @@ static inline void debug_fence_init(struct i915_sw_fence
*fence)
{
}
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
static inline void debug_fence_init_onstack(struct i915_sw_fence *fence)
{
}
+#endif
static inline void debug_fence_activate(struct i915_sw_fence *fence)
{
@@ -113,10 +117,6 @@ static inline void debug_fence_destroy(struct
i915_sw_fence *fence)
{
}
-static inline void debug_fence_free(struct i915_sw_fence *fence)
-{
-}
-
static inline void debug_fence_assert(struct i915_sw_fence *fence)
{
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it
On Mon, 2021-02-08 at 17:43 +0200, Imre Deak wrote:
> The TypeC FIA can be powered down if the TC-COLD power state is allowed,
> so block the TC-COLD state when initializing the FIA.
>
> Note that this isn't needed on ICL where the FIA is never modular and
> which has no generic way to block TC-COLD (except for platforms with a
> legacy TypeC port and on those too only via these legacy ports, not via
> a DP-alt/TBT port).
Reviewed-by: José Roberto de Souza
>
> Cc: # v5.10+
> Cc: José Roberto de Souza
> Reported-by: Paul Menzel
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3027
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 67 ++---
> 1 file changed, 37 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 27dc2dad6809c..2cefc13535a0f 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -23,36 +23,6 @@ static const char *tc_port_mode_name(enum tc_port_mode
> mode)
> return names[mode];
> }
>
>
>
>
> -static void
> -tc_port_load_fia_params(struct drm_i915_private *i915,
> - struct intel_digital_port *dig_port)
> -{
> - enum port port = dig_port->base.port;
> - enum tc_port tc_port = intel_port_to_tc(i915, port);
> - u32 modular_fia;
> -
> - if (INTEL_INFO(i915)->display.has_modular_fia) {
> - modular_fia = intel_uncore_read(>uncore,
> - PORT_TX_DFLEXDPSP(FIA1));
> - drm_WARN_ON(>drm, modular_fia == 0x);
> - modular_fia &= MODULAR_FIA_MASK;
> - } else {
> - modular_fia = 0;
> - }
> -
> - /*
> - * Each Modular FIA instance houses 2 TC ports. In SOC that has more
> - * than two TC ports, there are multiple instances of Modular FIA.
> - */
> - if (modular_fia) {
> - dig_port->tc_phy_fia = tc_port / 2;
> - dig_port->tc_phy_fia_idx = tc_port % 2;
> - } else {
> - dig_port->tc_phy_fia = FIA1;
> - dig_port->tc_phy_fia_idx = tc_port;
> - }
> -}
> -
> static enum intel_display_power_domain
> tc_cold_get_power_domain(struct intel_digital_port *dig_port)
> {
> @@ -646,6 +616,43 @@ void intel_tc_port_put_link(struct intel_digital_port
> *dig_port)
> mutex_unlock(_port->tc_lock);
> }
>
>
>
>
> +static bool
> +tc_has_modular_fia(struct drm_i915_private *i915, struct intel_digital_port
> *dig_port)
> +{
> + intel_wakeref_t wakeref;
> + u32 val;
> +
> + if (!INTEL_INFO(i915)->display.has_modular_fia)
> + return false;
> +
> + wakeref = tc_cold_block(dig_port);
> + val = intel_uncore_read(>uncore, PORT_TX_DFLEXDPSP(FIA1));
> + tc_cold_unblock(dig_port, wakeref);
> +
> + drm_WARN_ON(>drm, val == 0x);
> +
> + return val & MODULAR_FIA_MASK;
> +}
> +
> +static void
> +tc_port_load_fia_params(struct drm_i915_private *i915, struct
> intel_digital_port *dig_port)
> +{
> + enum port port = dig_port->base.port;
> + enum tc_port tc_port = intel_port_to_tc(i915, port);
> +
> + /*
> + * Each Modular FIA instance houses 2 TC ports. In SOC that has more
> + * than two TC ports, there are multiple instances of Modular FIA.
> + */
> + if (tc_has_modular_fia(i915, dig_port)) {
> + dig_port->tc_phy_fia = tc_port / 2;
> + dig_port->tc_phy_fia_idx = tc_port % 2;
> + } else {
> + dig_port->tc_phy_fia = FIA1;
> + dig_port->tc_phy_fia_idx = tc_port;
> + }
> +}
> +
> void intel_tc_port_init(struct intel_digital_port *dig_port, bool is_legacy)
> {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/31] drm/i915/gt: Ratelimit heartbeat completion probing
== Series Details == Series: series starting with [01/31] drm/i915/gt: Ratelimit heartbeat completion probing URL : https://patchwork.freedesktop.org/series/86841/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/31] drm/i915/gt: Ratelimit heartbeat completion probing
== Series Details ==
Series: series starting with [01/31] drm/i915/gt: Ratelimit heartbeat
completion probing
URL : https://patchwork.freedesktop.org/series/86841/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
206aa3c9677c drm/i915/gt: Ratelimit heartbeat completion probing
2494ed145240 drm/i915: Move context revocation to scheduler
3dbe5f872455 drm/i915: Introduce the scheduling mode
5b350d2836cf drm/i915: Move timeslicing flag to scheduler
4ab52e53c2c0 drm/i915/gt: Declare when we enabled timeslicing
-:15: WARNING:BAD_SIGN_OFF: Duplicate signature
#15:
Reviewed-by: Tvrtko Ursulin
total: 0 errors, 1 warnings, 0 checks, 14 lines checked
483235989602 drm/i915: Move busywaiting control to the scheduler
7a092999c7b2 drm/i915: Move preempt-reset flag to the scheduler
b5a1080e1523 drm/i915: Fix the iterative dfs for defering requests
029c20aa2d56 drm/i915: Replace priolist rbtree with a skiplist
-:439: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible side-effects?
#439: FILE: drivers/gpu/drm/i915/i915_priolist_types.h:98:
+#define for_each_priolist(p, root) \
+ for ((p) = (root)->sentinel.next[0]; \
+(p) != &(root)->sentinel; \
+(p) = (p)->next[0])
-:439: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'root' - possible
side-effects?
#439: FILE: drivers/gpu/drm/i915/i915_priolist_types.h:98:
+#define for_each_priolist(p, root) \
+ for ((p) = (root)->sentinel.next[0]; \
+(p) != &(root)->sentinel; \
+(p) = (p)->next[0])
-:906: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'se' - possible side-effects?
#906: FILE: drivers/gpu/drm/i915/i915_scheduler.h:167:
+#define i915_sched_dequeue(se, pl, rq, rn) \
+ for ((pl) = (se)->queue.sentinel.next[0]; \
+(pl) != &(se)->queue.sentinel; \
+(pl) = __i915_sched_dequeue_next(se)) \
+ priolist_for_each_request_safe(rq, rn, pl)
-:906: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pl' - possible side-effects?
#906: FILE: drivers/gpu/drm/i915/i915_scheduler.h:167:
+#define i915_sched_dequeue(se, pl, rq, rn) \
+ for ((pl) = (se)->queue.sentinel.next[0]; \
+(pl) != &(se)->queue.sentinel; \
+(pl) = __i915_sched_dequeue_next(se)) \
+ priolist_for_each_request_safe(rq, rn, pl)
-:952: WARNING:LINE_SPACING: Missing a blank line after declarations
#952: FILE: drivers/gpu/drm/i915/selftests/i915_scheduler.c:19:
+ struct i915_priolist *pl =
+ IGT_TIMEOUT(end_time);
total: 0 errors, 1 warnings, 4 checks, 904 lines checked
dbfb352bf7b0 drm/i915: Fair low-latency scheduling
9a611ddd1f7a drm/i915/gt: Specify a deadline for the heartbeat
022c4065c1a9 drm/i915: Extend the priority boosting for the display with a
deadline
d8b43dca33f0 drm/i915/gt: Support virtual engine queues
27f940af2d22 drm/i915: Move saturated workload detection back to the context
-:29: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#29:
References: 44d89409a12e ("drm/i915: Make the semaphore saturation mask global")
-:29: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 44d89409a12e ("drm/i915: Make
the semaphore saturation mask global")'
#29:
References: 44d89409a12e ("drm/i915: Make the semaphore saturation mask global")
total: 1 errors, 1 warnings, 0 checks, 78 lines checked
4109a26f879f drm/i915: Bump default timeslicing quantum to 5ms
2091c45fb062 drm/i915/gt: Delay taking irqoff for execlists submission
8b8ee05f1953 drm/i915/gt: Convert the legacy ring submission to use the
scheduling interface
b8c672225e3d drm/i915/gt: Wrap intel_timeline.has_initial_breadcrumb
186491248d9b drm/i915/gt: Track timeline GGTT offset separately from subpage
offset
cbdded299ad1 drm/i915/gt: Add timeline "mode"
75d076c67057 drm/i915/gt: Use indices for writing into relative timelines
b755887ce2eb drm/i915/selftests: Exercise relative timeline modes
3510121480a9 drm/i915/gt: Use ppHWSP for unshared non-semaphore related
timelines
1f38aec71c0a Restore "drm/i915: drop engine_pin/unpin_breadcrumbs_irq"
681705c8f00d drm/i915/gt: Support creation of 'internal' rings
a1edb8d6fe76 drm/i915/gt: Use client timeline address for seqno writes
d11da5d6110b drm/i915/gt: Infrastructure for ring scheduling
-:79: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#79:
new file mode 100644
total: 0 errors, 1 warnings, 0 checks, 844 lines checked
282aad02df82 drm/i915/gt: Implement ring scheduler for gen4-7
-:70: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#70: FILE: drivers/gpu/drm/i915/gt/intel_ring_scheduler.c:221:
+ *cs++ = i915_mmio_reg_offset(
-:72: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#72: FILE: drivers/gpu/drm/i915/gt/intel_ring_scheduler.c:223:
+ *cs++ = _MASKED_BIT_ENABLE(
-:107:
[Intel-gfx] [PATCH] drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it
The TypeC FIA can be powered down if the TC-COLD power state is allowed,
so block the TC-COLD state when initializing the FIA.
Note that this isn't needed on ICL where the FIA is never modular and
which has no generic way to block TC-COLD (except for platforms with a
legacy TypeC port and on those too only via these legacy ports, not via
a DP-alt/TBT port).
Cc: # v5.10+
Cc: José Roberto de Souza
Reported-by: Paul Menzel
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3027
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_tc.c | 67 ++---
1 file changed, 37 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index 27dc2dad6809c..2cefc13535a0f 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -23,36 +23,6 @@ static const char *tc_port_mode_name(enum tc_port_mode mode)
return names[mode];
}
-static void
-tc_port_load_fia_params(struct drm_i915_private *i915,
- struct intel_digital_port *dig_port)
-{
- enum port port = dig_port->base.port;
- enum tc_port tc_port = intel_port_to_tc(i915, port);
- u32 modular_fia;
-
- if (INTEL_INFO(i915)->display.has_modular_fia) {
- modular_fia = intel_uncore_read(>uncore,
- PORT_TX_DFLEXDPSP(FIA1));
- drm_WARN_ON(>drm, modular_fia == 0x);
- modular_fia &= MODULAR_FIA_MASK;
- } else {
- modular_fia = 0;
- }
-
- /*
-* Each Modular FIA instance houses 2 TC ports. In SOC that has more
-* than two TC ports, there are multiple instances of Modular FIA.
-*/
- if (modular_fia) {
- dig_port->tc_phy_fia = tc_port / 2;
- dig_port->tc_phy_fia_idx = tc_port % 2;
- } else {
- dig_port->tc_phy_fia = FIA1;
- dig_port->tc_phy_fia_idx = tc_port;
- }
-}
-
static enum intel_display_power_domain
tc_cold_get_power_domain(struct intel_digital_port *dig_port)
{
@@ -646,6 +616,43 @@ void intel_tc_port_put_link(struct intel_digital_port
*dig_port)
mutex_unlock(_port->tc_lock);
}
+static bool
+tc_has_modular_fia(struct drm_i915_private *i915, struct intel_digital_port
*dig_port)
+{
+ intel_wakeref_t wakeref;
+ u32 val;
+
+ if (!INTEL_INFO(i915)->display.has_modular_fia)
+ return false;
+
+ wakeref = tc_cold_block(dig_port);
+ val = intel_uncore_read(>uncore, PORT_TX_DFLEXDPSP(FIA1));
+ tc_cold_unblock(dig_port, wakeref);
+
+ drm_WARN_ON(>drm, val == 0x);
+
+ return val & MODULAR_FIA_MASK;
+}
+
+static void
+tc_port_load_fia_params(struct drm_i915_private *i915, struct
intel_digital_port *dig_port)
+{
+ enum port port = dig_port->base.port;
+ enum tc_port tc_port = intel_port_to_tc(i915, port);
+
+ /*
+* Each Modular FIA instance houses 2 TC ports. In SOC that has more
+* than two TC ports, there are multiple instances of Modular FIA.
+*/
+ if (tc_has_modular_fia(i915, dig_port)) {
+ dig_port->tc_phy_fia = tc_port / 2;
+ dig_port->tc_phy_fia_idx = tc_port % 2;
+ } else {
+ dig_port->tc_phy_fia = FIA1;
+ dig_port->tc_phy_fia_idx = tc_port;
+ }
+}
+
void intel_tc_port_init(struct intel_digital_port *dig_port, bool is_legacy)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/31] drm/i915: Fair low-latency scheduling
Quoting Tvrtko Ursulin (2021-02-08 14:56:31)
> On 08/02/2021 10:52, Chris Wilson wrote:
> > +static bool need_preempt(const struct intel_engine_cs *engine,
> >const struct i915_request *rq)
> > {
> > const struct i915_sched *se = >sched;
> > - int last_prio;
> > + const struct i915_request *first = NULL;
> > + const struct i915_request *next;
> >
> > if (!i915_sched_use_busywait(se))
> > return false;
> >
> > /*
> > - * Check if the current priority hint merits a preemption attempt.
> > - *
> > - * We record the highest value priority we saw during rescheduling
> > - * prior to this dequeue, therefore we know that if it is strictly
> > - * less than the current tail of ESLP[0], we do not need to force
> > - * a preempt-to-idle cycle.
> > - *
> > - * However, the priority hint is a mere hint that we may need to
> > - * preempt. If that hint is stale or we may be trying to preempt
> > - * ourselves, ignore the request.
> > - *
> > - * More naturally we would write
> > - * prio >= max(0, last);
> > - * except that we wish to prevent triggering preemption at the same
> > - * priority level: the task that is running should remain running
> > - * to preserve FIFO ordering of dependencies.
> > + * If this request is special and must not be interrupted at any
> > + * cost, so be it. Note we are only checking the most recent request
> > + * in the context and so may be masking an earlier vip request. It
> > + * is hoped that under the conditions where nopreempt is used, this
> > + * will not matter (i.e. all requests to that context will be
> > + * nopreempt for as long as desired).
> >*/
> > - last_prio = max(effective_prio(rq), I915_PRIORITY_NORMAL - 1);
> > - if (engine->execlists.queue_priority_hint <= last_prio)
> > + if (i915_request_has_nopreempt(rq))
> > return false;
> >
> > /*
> >* Check against the first request in ELSP[1], it will, thanks to the
> >* power of PI, be the highest priority of that context.
> >*/
> > - if (!list_is_last(>sched.link, >requests) &&
> > - rq_prio(list_next_entry(rq, sched.link)) > last_prio)
> > - return true;
> > + next = next_elsp_request(se, rq);
> > + if (dl_before(next, first))
>
> Here first is always NULL so dl_before always returns true, meaning it
> appears redundant to call it.
I was applying a pattern :)
>
> > + first = next;
> >
> > /*
> >* If the inflight context did not trigger the preemption, then maybe
> > @@ -356,8 +343,31 @@ static bool need_preempt(struct intel_engine_cs
> > *engine,
> >* ELSP[0] or ELSP[1] as, thanks again to PI, if it was the same
> >* context, it's priority would not exceed ELSP[0] aka last_prio.
> >*/
> > - return max(virtual_prio(>execlists),
> > -queue_prio(se)) > last_prio;
> > + next = first_request(se);
> > + if (dl_before(next, first))
> > + first = next; > +
> > + next = first_virtual(engine);
> > + if (dl_before(next, first))
> > + first = next;
> > +
> > + if (!dl_before(first, rq))
> > + return false;
>
> Ends up earliest deadline between list of picks: elsp[1] (or maybe next
> in context, depends on coalescing criteria), first in the priolist,
> first virtual.
>
> Virtual has a separate queue so that's understandable, but can "elsp[1]"
> really have an earlier deadling than first_request() (head of thepriolist)?
elsp[1] could have been promoted and thus now have an earlier deadline
than elsp[0]. Consider the heartbeat as a trivial example that is first
submitted at very low priority, but by the end has absolute priority.
> > +static u64 virtual_deadline(u64 kt, int priority)
> > +{
> > + return i915_sched_to_ticks(kt + prio_slice(priority));
> > +}
> > +
> > +u64 i915_scheduler_next_virtual_deadline(int priority)
> > +{
> > + return virtual_deadline(ktime_get_mono_fast_ns(), priority);
> > +}
>
> This helpers becomes a bit odd in that the only two callers are rewind
> and defer. And it queries ktime, while before deadline was set based on
> signalers.
>
> Where is the place which set the ktime based deadline (converted to
> ticks) for requests with no signalers?
signal_deadline() with no signalers returns now. So the first request in
a sequence is queued with virtual_deadline(now() + prio_slice()).
> > void i915_request_enqueue(struct i915_request *rq)
> > {
> > - struct intel_engine_cs *engine = rq->engine;
> > - struct i915_sched *se = intel_engine_get_scheduler(engine);
> > + struct i915_sched *se = i915_request_get_scheduler(rq);
> > + u64 dl = earliest_deadline(se, rq);
> > unsigned long flags;
> > bool kick = false;
> >
> > @@ -880,11 +1107,11 @@
Re: [Intel-gfx] [PATCH 09/31] drm/i915: Replace priolist rbtree with a skiplist
On 08/02/2021 10:52, Chris Wilson wrote:
Replace the priolist rbtree with a skiplist. The crucial difference is
that walking and removing the first element of a skiplist is O(1), but
O(lgN) for an rbtree, as we need to rebalance on remove. This is a
hindrance for submission latency as it occurs between picking a request
for the priolist and submitting it to hardware, as well effectively
tripling the number of O(lgN) operations required under the irqoff lock.
This is critical to reducing the latency jitter with multiple clients.
The downsides to skiplists are that lookup/insertion is only
probabilistically O(lgN) and there is a significant memory penalty to
as each skip node is larger than the rbtree equivalent. Furthermore, we
don't use dynamic arrays for the skiplist, so the allocation is fixed,
and imposes an upper bound on the scalability wrt to the number of
inflight requests.
In the following patches, we introduce a new sort key to the scheduler,
a virtual deadline. This imposes a different structure to the tree.
Using a priority sort, we have very few priority levels active at any
time, most likely just the default priority and so the rbtree degenerates
to a single elements containing the list of all ready requests. The
deadlines in contrast are very sparse, and typically each request has a
unique deadline. Instead of being able to simply walk the list during
dequeue, with the deadline scheduler we have to iterate through the bst
on the critical submission path. Skiplists are vastly superior in this
instance due to the O(1) iteration during dequeue, with very similar
characteristics [on average] to the rbtree for insertion.
This means that by using skiplists we can introduce a sparse sort key
without degrading latency on the critical submission path.
As an example, one simple case where we try to do lots of
semi-independent work without any priority management (gem_exec_parallel),
the lock hold times were:
[worst][total][avg]
973.05 6301584.84 0.35 # plain rbtree
559.82 5424915.25 0.33 # best rbtree with pruning
208.21 3898784.09 0.24 # skiplist
34.05 5784106.01 0.32 # rbtree without deadlines
23.35 4152999.80 0.24 # skiplist without deadlines
Based on the skiplist implementation by Dr Con Kolivas for MuQSS.
References: https://en.wikipedia.org/wiki/Skip_list
Signed-off-by: Chris Wilson
---
.../drm/i915/gt/intel_execlists_submission.c | 168 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 41 +--
drivers/gpu/drm/i915/i915_priolist_types.h| 64 +++-
drivers/gpu/drm/i915/i915_scheduler.c | 304 +-
drivers/gpu/drm/i915/i915_scheduler.h | 16 +-
drivers/gpu/drm/i915/i915_scheduler_types.h | 2 +-
.../drm/i915/selftests/i915_mock_selftests.h | 1 +
.../gpu/drm/i915/selftests/i915_scheduler.c | 53 ++-
8 files changed, 454 insertions(+), 195 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 78fda9b4f626..4a0258347c10 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -254,11 +254,6 @@ static void ring_set_paused(const struct intel_engine_cs
*engine, int state)
wmb();
}
-static struct i915_priolist *to_priolist(struct rb_node *rb)
-{
- return rb_entry(rb, struct i915_priolist, node);
-}
-
static int rq_prio(const struct i915_request *rq)
{
return READ_ONCE(rq->sched.attr.priority);
@@ -282,15 +277,27 @@ static int effective_prio(const struct i915_request *rq)
return prio;
}
+static struct i915_request *first_request(const struct i915_sched *se)
+{
+ struct i915_priolist *pl = se->queue.sentinel.next[0];
+
+ if (pl == >queue.sentinel)
+ return NULL;
+
+ return list_first_entry_or_null(>requests,
+ struct i915_request,
+ sched.link);
+}
+
static int queue_prio(const struct i915_sched *se)
{
- struct rb_node *rb;
+ struct i915_request *rq;
- rb = rb_first_cached(>queue);
- if (!rb)
+ rq = first_request(se);
+ if (!rq)
return INT_MIN;
- return to_priolist(rb)->priority;
+ return rq_prio(rq);
}
static int virtual_prio(const struct intel_engine_execlists *el)
@@ -300,7 +307,7 @@ static int virtual_prio(const struct intel_engine_execlists
*el)
return rb ? rb_entry(rb, struct ve_node, rb)->prio : INT_MIN;
}
-static bool need_preempt(const struct intel_engine_cs *engine,
+static bool need_preempt(struct intel_engine_cs *engine,
const struct i915_request *rq)
{
const struct i915_sched *se = >sched;
@@ -1144,7 +1151,9 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
struct i915_request **port =
Re: [Intel-gfx] [PATCH 09/31] drm/i915: Replace priolist rbtree with a skiplist
On 08/02/2021 12:46, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2021-02-08 12:29:14)
On 08/02/2021 10:52, Chris Wilson wrote:
+static void remove_from_priolist(struct i915_sched *se,
+ struct i915_request *rq,
+ struct list_head *list,
+ bool tail)
+{
+ struct list_head *prev = rq->sched.link.prev;
This depends on rq being at the head of it's list?
Not depends. We are testing if the list is singular, that is by removing
this request from the i915_priolist.requests that list becomes empty,
and so the i915_priolist can be removed from the skiplist.
Ah so obvious now, thanks.
+
+ GEM_BUG_ON(!i915_request_in_priority_queue(rq));
+
+ __list_del_entry(>sched.link);
+ if (tail)
+ list_add_tail(>sched.link, list);
+ else
+ list_add(>sched.link, list);
So it is more move than remove(_from_priolist) ?
Yes, we can quite happily just keep the list_move(), except we then end
up with lots of empty levels. At first I thought the walk through those
(during dequeue) would be cheaper than removing. The max lock holdtime
strongly favours the removal as we move requests around (which will
happen in dribs-and-drabs) over doing a bulk remove at dequeue.
Give it a name to reflect it is a move like move_to_priolist?
+ /* If we just removed the last element in the old plist, delete it */
+ if (list_empty(prev))
+ __remove_priolist(se, prev);
+}
+
+struct i915_priolist *__i915_sched_dequeue_next(struct i915_sched *se)
+{
+ struct i915_priolist * const s = >queue.sentinel;
+ struct i915_priolist *pl = s->next[0];
+ int lvl;
+
+ GEM_BUG_ON(!list_empty(>requests));
Lost as to why pl->requests has to be empty at this point. Considering:
+#define i915_sched_dequeue(se, pl, rq, rn) \
+ for ((pl) = (se)->queue.sentinel.next[0]; \
+(pl) != &(se)->queue.sentinel; \
+(pl) = __i915_sched_dequeue_next(se)) \
+ priolist_for_each_request_safe(rq, rn, pl)
+
I also don't understand what it would de-queue. Whole priolist woth of
requests at a time? But it can't be empty to dequeue something. And who
puts any unconsumed requests back on somewhere in this case.
It's a double for-loop. I think the flattening of the logic is worth it.
During dequeue, we always move the very first request onto the next list
(i.e. i915_sched.active). Then when we have finished with all the
requests in one priority level, we move onto the next i915_priolist
(calling __i915_sched_dequeue_next).
So in __i915_sched_dequeue_next, we are always dealing with an empty
i915_priolist and want to advance the start of the skiplist to the next.
Ah yes, __i915_sched_dequeue_next is only if there isn't a "goto done"
from within the inner loop (priolist_for_each_request_safe). Well it's a
bit fragile if someone does a break one day. But I guess bug on will be
hit then so it's okay.
Right, I have some more questions for which I'll start a new sub-thread.
Regards,
Tvrtko
I was thinking that in order to hide the double for-loop, we could
handle the non-empty i915_priolist case causing it to break out of the
outer loop. So we could get rid of the goto done.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/31] drm/i915: Fair low-latency scheduling
On 08/02/2021 10:52, Chris Wilson wrote:
The first "scheduler" was a topographical sorting of requests into
priority order. The execution order was deterministic, the earliest
submitted, highest priority request would be executed first. Priority
inheritance ensured that inversions were kept at bay, and allowed us to
dynamically boost priorities (e.g. for interactive pageflips).
The minimalistic timeslicing scheme was an attempt to introduce fairness
between long running requests, by evicting the active request at the end
of a timeslice and moving it to the back of its priority queue (while
ensuring that dependencies were kept in order). For short running
requests from many clients of equal priority, the scheme is still very
much FIFO submission ordering, and as unfair as before.
To impose fairness, we need an external metric that ensures that clients
are interspersed, so we don't execute one long chain from client A before
executing any of client B. This could be imposed by the clients
themselves by using fences based on an external clock, that is they only
submit work for a "frame" at frame-intervals, instead of submitting as
much work as they are able to. The standard SwapBuffers approach is akin
to double buffering, where as one frame is being executed, the next is
being submitted, such that there is always a maximum of two frames per
client in the pipeline and so ideally maintains consistent input-output
latency. Even this scheme exhibits unfairness under load as a single
client will execute two frames back to back before the next, and with
enough clients, deadlines will be missed.
The idea introduced by BFS/MuQSS is that fairness is introduced by
metering with an external clock. Every request, when it becomes ready to
execute is assigned a virtual deadline, and execution order is then
determined by earliest deadline. Priority is used as a hint, rather than
strict ordering, where high priority requests have earlier deadlines,
but not necessarily earlier than outstanding work. Thus work is executed
in order of 'readiness', with timeslicing to demote long running work.
The Achille's heel of this scheduler is its strong preference for
low-latency and favouring of new queues. Whereas it was easy to dominate
the old scheduler by flooding it with many requests over a short period
of time, the new scheduler can be dominated by a 'synchronous' client
that waits for each of its requests to complete before submitting the
next. As such a client has no history, it is always considered
ready-to-run and receives an earlier deadline than the long running
requests. This is compensated for by refreshing the current execution's
deadline and by disallowing preemption for timeslice shuffling.
In contrast, one key advantage of disconnecting the sort key from the
priority value is that we can freely adjust the deadline to compensate
for other factors. This is used in conjunction with submitting requests
ahead-of-schedule that then busywait on the GPU using semaphores. Since
we don't want to spend a timeslice busywaiting instead of doing real
work when available, we deprioritise work by giving the semaphore waits
a later virtual deadline. The priority deboost is applied to semaphore
workloads after they miss a semaphore wait and a new context is pending.
The request is then restored to its normal priority once the semaphores
are signaled so that it not unfairly penalised under contention by
remaining at a far future deadline. This is a much improved and cleaner
version of commit f9e9e9de58c7 ("drm/i915: Prioritise non-busywait
semaphore workloads").
To check the impact on throughput (often the downfall of latency
sensitive schedulers), we used gem_wsim to simulate various transcode
workloads with different load balancers, and varying the number of
competing [heterogeneous] clients. On Kabylake gt3e running at fixed
cpu/gpu clocks,
+delta%--+
| a|
| a|
| a|
| a|
| aa |
| aaa |
| |
| aa |
| aa |
| aa aa|
| aa aa a a a a aa a a a a a|
||__M__A__| |
++
N Min MaxMedian
Re: [Intel-gfx] [PATCH] kernel: Expose SYS_kcmp by default
On 2021-02-08 2:34 p.m., Daniel Vetter wrote: On Mon, Feb 8, 2021 at 12:49 PM Michel Dänzer wrote: On 2021-02-05 9:53 p.m., Daniel Vetter wrote: On Fri, Feb 5, 2021 at 7:37 PM Kees Cook wrote: On Fri, Feb 05, 2021 at 04:37:52PM +, Chris Wilson wrote: Userspace has discovered the functionality offered by SYS_kcmp and has started to depend upon it. In particular, Mesa uses SYS_kcmp for os_same_file_description() in order to identify when two fd (e.g. device or dmabuf) point to the same struct file. Since they depend on it for core functionality, lift SYS_kcmp out of the non-default CONFIG_CHECKPOINT_RESTORE into the selectable syscall category. Signed-off-by: Chris Wilson Cc: Kees Cook Cc: Andy Lutomirski Cc: Will Drewry Cc: Andrew Morton Cc: Dave Airlie Cc: Daniel Vetter Cc: Lucas Stach --- init/Kconfig | 11 +++ kernel/Makefile | 2 +- tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +- 3 files changed, 13 insertions(+), 2 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index b77c60f8b963..f62fca13ac5b 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1194,6 +1194,7 @@ endif # NAMESPACES config CHECKPOINT_RESTORE bool "Checkpoint/restore support" select PROC_CHILDREN + select KCMP default n help Enables additional kernel features in a sake of checkpoint/restore. @@ -1737,6 +1738,16 @@ config ARCH_HAS_MEMBARRIER_CALLBACKS config ARCH_HAS_MEMBARRIER_SYNC_CORE bool +config KCMP + bool "Enable kcmp() system call" if EXPERT + default y I would expect this to be not default-y, especially if CHECKPOINT_RESTORE does a "select" on it. This is a really powerful syscall, but it is bounded by ptrace access controls, and uses pointer address obfuscation, so it may be okay to expose this. As it is, at least Ubuntu already has CONFIG_CHECKPOINT_RESTORE, so really, there's probably not much difference on exposure. So, if you drop the "default y", I'm fine with this. It was maybe stupid, but our userspace started relying on fd comaprison through sys_kcomp. So for better or worse, if you want to run the mesa3d gl/vk stacks, you need this. That's overstating things somewhat. The vast majority of applications will work fine regardless (as they did before Mesa started using this functionality). Only some special ones will run into issues, because the user-space drivers incorrectly assume two file descriptors reference different descriptions. Was maybe not the brighest ideas, but since enough distros had this enabled by defaults, Right, that (and the above) is why I considered it fair game to use. What should I have done instead? (TBH I was surprised that this functionality isn't generally available) Yeah that one is fine, but I thought we've discussed (irc or something) more uses for de-duping dma-buf and stuff like that. But quick grep says that hasn't landed yet, so I got a bit confused (or just dreamt). Looking at this again I'm kinda surprised the drmfd de-duping blows up on normal linux distros, but I guess it can all happen. One example: GEM handle name-spaces are per file description. If user-space incorrectly assumes two DRM fds are independent, when they actually reference the same file description, closing a GEM handle with one file descriptor will make it unusable with the other file descriptor as well. Ofc we can leave the default n, but the select if CONFIG_DRM is unfortunately needed I think. Per above, not sure this is really true. We seem to be going boom on linux distros now, maybe userspace got more creative in abusing stuff? I don't know what you're referring to. I've only seen maybe two or three reports from people who didn't enable CHECKPOINT_RESTORE in their self-built kernels. The entire thing is small enough that imo we don't really have to care, e.g. we also unconditionally select dma-buf, despite that on most systems there's only 1 gpu, and you're never going to end up with a buffer sharing case that needs any of that code (aside from the "here's an fd" part). But I guess we can limit to just KCMP_FILE like you suggest in another reply. Just feels a bit like overkill. Making KCMP_FILE gated by DRM makes as little sense to me as by CHECKPOINT_RESTORE. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] kernel: Expose SYS_kcmp by default
On Mon, Feb 8, 2021 at 12:49 PM Michel Dänzer wrote: > > On 2021-02-05 9:53 p.m., Daniel Vetter wrote: > > On Fri, Feb 5, 2021 at 7:37 PM Kees Cook wrote: > >> > >> On Fri, Feb 05, 2021 at 04:37:52PM +, Chris Wilson wrote: > >>> Userspace has discovered the functionality offered by SYS_kcmp and has > >>> started to depend upon it. In particular, Mesa uses SYS_kcmp for > >>> os_same_file_description() in order to identify when two fd (e.g. device > >>> or dmabuf) point to the same struct file. Since they depend on it for > >>> core functionality, lift SYS_kcmp out of the non-default > >>> CONFIG_CHECKPOINT_RESTORE into the selectable syscall category. > >>> > >>> Signed-off-by: Chris Wilson > >>> Cc: Kees Cook > >>> Cc: Andy Lutomirski > >>> Cc: Will Drewry > >>> Cc: Andrew Morton > >>> Cc: Dave Airlie > >>> Cc: Daniel Vetter > >>> Cc: Lucas Stach > >>> --- > >>> init/Kconfig | 11 +++ > >>> kernel/Makefile | 2 +- > >>> tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +- > >>> 3 files changed, 13 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/init/Kconfig b/init/Kconfig > >>> index b77c60f8b963..f62fca13ac5b 100644 > >>> --- a/init/Kconfig > >>> +++ b/init/Kconfig > >>> @@ -1194,6 +1194,7 @@ endif # NAMESPACES > >>> config CHECKPOINT_RESTORE > >>>bool "Checkpoint/restore support" > >>>select PROC_CHILDREN > >>> + select KCMP > >>>default n > >>>help > >>> Enables additional kernel features in a sake of > >>> checkpoint/restore. > >>> @@ -1737,6 +1738,16 @@ config ARCH_HAS_MEMBARRIER_CALLBACKS > >>> config ARCH_HAS_MEMBARRIER_SYNC_CORE > >>>bool > >>> > >>> +config KCMP > >>> + bool "Enable kcmp() system call" if EXPERT > >>> + default y > >> > >> I would expect this to be not default-y, especially if > >> CHECKPOINT_RESTORE does a "select" on it. > >> > >> This is a really powerful syscall, but it is bounded by ptrace access > >> controls, and uses pointer address obfuscation, so it may be okay to > >> expose this. As it is, at least Ubuntu already has > >> CONFIG_CHECKPOINT_RESTORE, so really, there's probably not much > >> difference on exposure. > >> > >> So, if you drop the "default y", I'm fine with this. > > > > It was maybe stupid, but our userspace started relying on fd > > comaprison through sys_kcomp. So for better or worse, if you want to > > run the mesa3d gl/vk stacks, you need this. > > That's overstating things somewhat. The vast majority of applications > will work fine regardless (as they did before Mesa started using this > functionality). Only some special ones will run into issues, because the > user-space drivers incorrectly assume two file descriptors reference > different descriptions. > > > > Was maybe not the brighest ideas, but since enough distros had this > > enabled by defaults, > > Right, that (and the above) is why I considered it fair game to use. > What should I have done instead? (TBH I was surprised that this > functionality isn't generally available) Yeah that one is fine, but I thought we've discussed (irc or something) more uses for de-duping dma-buf and stuff like that. But quick grep says that hasn't landed yet, so I got a bit confused (or just dreamt). Looking at this again I'm kinda surprised the drmfd de-duping blows up on normal linux distros, but I guess it can all happen. > > it wasn't really discovered, and now we're > > shipping this everywhere. > > You're making it sound like this snuck in secretly somehow, which is not > true of course. > > > > Ofc we can leave the default n, but the select if CONFIG_DRM is > > unfortunately needed I think. > > Per above, not sure this is really true. We seem to be going boom on linux distros now, maybe userspace got more creative in abusing stuff? The entire thing is small enough that imo we don't really have to care, e.g. we also unconditionally select dma-buf, despite that on most systems there's only 1 gpu, and you're never going to end up with a buffer sharing case that needs any of that code (aside from the "here's an fd" part). But I guess we can limit to just KCMP_FILE like you suggest in another reply. Just feels a bit like overkill. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/vbt: update DP max link rate table
On Fri, Feb 05, 2021, at 8:26 p.m, Ville Syrjälä wrote:
>On Mon, Feb 01, 2021 at 11:02:28PM +0800, Lee Shawn C wrote:
>> According to Bspec #20124, max link rate table for DP was updated at
>> BDB version 230. Max link rate can support upto UHBR.
>>
>> After migrate to BDB v230, the definition for LBR, HBR2 and HBR3 were
>> changed. For backward compatibility. If BDB version was from 216 to
>> 229. Driver have to follow original rule to configure DP max link rate
>> value from VBT.
>>
>> Cc: Ville Syrjala
>> Cc: Imre Deak
>> Cc: Jani Nikula
>> Cc: Cooper Chiou
>> Cc: William Tseng
>> Signed-off-by: Lee Shawn C
>> ---
>> drivers/gpu/drm/i915/display/intel_bios.c | 24 ++-
>> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 14 +++
>> 2 files changed, 32 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
>> b/drivers/gpu/drm/i915/display/intel_bios.c
>> index 04337ac6f8c4..be1f732e6550 100644
>> --- a/drivers/gpu/drm/i915/display/intel_bios.c
>> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
>> @@ -1876,7 +1876,15 @@ static void parse_ddi_port(struct drm_i915_private
>> *dev_priv,
>> /* DP max link rate for CNL+ */
>> if (bdb_version >= 216) {
>> switch (child->dp_max_link_rate) {
>> -default:
>> +case VBT_DP_MAX_LINK_RATE_UHBR20:
>> +info->dp_max_link_rate = 200;
>> +break;
>> +case VBT_DP_MAX_LINK_RATE_UHBR13P5:
>> +info->dp_max_link_rate = 135;
>> +break;
>> +case VBT_DP_MAX_LINK_RATE_UHBR10:
>> +info->dp_max_link_rate = 100;
>> +break;
>> case VBT_DP_MAX_LINK_RATE_HBR3:
>> info->dp_max_link_rate = 81;
>> break;
>> @@ -1889,7 +1897,21 @@ static void parse_ddi_port(struct drm_i915_private
>> *dev_priv,
>> case VBT_DP_MAX_LINK_RATE_LBR:
>> info->dp_max_link_rate = 162000;
>> break;
>> +case VBT_DP_MAX_LINK_RATE_DEFAULT:
>> +default:
>> +info->dp_max_link_rate = 0;
>> +break;
>> +}
>> +
>> +if (bdb_version < 230) {
>> +if (child->dp_max_link_rate ==
>> VBT_DP_MAX_LINK_RATE_DEFAULT)
>> +info->dp_max_link_rate = 81;
>> +else if (child->dp_max_link_rate ==
>> VBT_DP_MAX_LINK_RATE_LBR)
>> +info->dp_max_link_rate = 54;
>> +else if (child->dp_max_link_rate ==
>> VBT_DP_MAX_LINK_RATE_HBR2)
>> +info->dp_max_link_rate = 162000;
>> }
>
>I would split this into two separate functions, one does the new mapping, the
>other the old mapping.
>
I will split this into two separate functions in patch v2.
>> +
>> drm_dbg_kms(_priv->drm,
>> "VBT DP max link rate for port %c: %d\n",
>> port_name(port), info->dp_max_link_rate); diff
>> --git
>> a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
>> b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
>> index 6d10fa037751..578a54b33f32 100644
>> --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
>> +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
>> @@ -343,10 +343,14 @@ enum vbt_gmbus_ddi { #define DP_AUX_H 0x80
>> #define DP_AUX_I 0x90
>>
>> -#define VBT_DP_MAX_LINK_RATE_HBR3 0
>> -#define VBT_DP_MAX_LINK_RATE_HBR2 1
>> +#define VBT_DP_MAX_LINK_RATE_DEFAULT0
>> +#define VBT_DP_MAX_LINK_RATE_LBR1
>> #define VBT_DP_MAX_LINK_RATE_HBR2
>> -#define VBT_DP_MAX_LINK_RATE_LBR3
>> +#define VBT_DP_MAX_LINK_RATE_HBR2 3
>> +#define VBT_DP_MAX_LINK_RATE_HBR3 4
>> +#define VBT_DP_MAX_LINK_RATE_UHBR10 5
>> +#define VBT_DP_MAX_LINK_RATE_UHBR13P5 6
>> +#define VBT_DP_MAX_LINK_RATE_UHBR20 7
>
>And we should keep both old and new names for these.
>
>Sadly I can't right now check the spec since it no longer has the
>old stuff apparently, and the VBT section got moved around so the
>history no longer shows anything either :( I'll have to pull the whole
>thing down I guess so I can double check against the old version.
>
Do you know any kernel doc or suggestion about the naming rule
(for new and old BDB version) to solve the problem like this?
Just want to know how i915 dirver manage the definition issue before.
Best regards,
Shawn
>>
>> /*
>> * The child device config, aka the display device data structure,
>> provides a @@ -445,8 +449,8 @@ struct child_device_config {
>> u16 dp_gpio_pin_num;/* 195 */
>> u8 dp_iboost_level:4; /* 196 */
>> u8 hdmi_iboost_level:4; /* 196 */
>> -u8 dp_max_link_rate:2;
Re: [Intel-gfx] [RFC 03/14] drm/i915/pxp: define PXP device flag and kconfig
On Fri, Feb 05, 2021 at 06:09:14PM -0800, Daniele Ceraolo Spurio wrote:
> Ahead of the PXP implementation, define the relevant define flag and
> kconfig option.
>
> Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/Kconfig | 11 +++
> drivers/gpu/drm/i915/i915_drv.h | 4
> drivers/gpu/drm/i915/intel_device_info.h | 1 +
> 3 files changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 1e1cb245fca7..c55e58bdbe0b 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -130,6 +130,17 @@ config DRM_I915_GVT_KVMGT
> Choose this option if you want to enable KVMGT support for
> Intel GVT-g.
>
> +config DRM_I915_PXP
> + bool "Enable Intel PXP support for Intel Gen12+ platform"
> + depends on DRM_I915
> + depends on INTEL_MEI && INTEL_MEI_PXP
> + default y
> + help
> + PXP (Protected Xe Path) is an i915 component, available on GEN12+
> + GPUs, that helps to establish the hardware protected session and
> + manage the status of the alive software session, as well as its life
> + cycle.
> +
> menu "drm/i915 Debugging"
> depends on DRM_I915
> depends on EXPERT
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a2fd7e5039b3..fe1ff025f961 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1779,6 +1779,10 @@ tgl_stepping_get(struct drm_i915_private *dev_priv)
>
> #define HAS_VRR(i915)(INTEL_GEN(i915) >= 12)
>
> +#define HAS_PXP(dev_priv) (IS_ENABLED(CONFIG_DRM_I915_PXP) && \
> +INTEL_INFO(dev_priv)->has_pxp) && \
> +VDBOX_MASK(_priv->gt)
> +
> /* Only valid when HAS_DISPLAY() is true */
> #define INTEL_DISPLAY_ENABLED(dev_priv) \
> (drm_WARN_ON(&(dev_priv)->drm, !HAS_DISPLAY(dev_priv)),
> !(dev_priv)->params.disable_display)
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> b/drivers/gpu/drm/i915/intel_device_info.h
> index e6ca1023ffcf..54891f7655e4 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -127,6 +127,7 @@ enum intel_ppgtt_type {
> func(has_logical_ring_elsq); \
> func(has_master_unit_irq); \
> func(has_pooled_eu); \
> + func(has_pxp); \
> func(has_rc6); \
> func(has_rc6p); \
> func(has_rps); \
> --
> 2.29.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 02/14] mei: pxp: export pavp client to me client bus
On Fri, Feb 05, 2021 at 06:09:13PM -0800, Daniele Ceraolo Spurio wrote:
> From: Vitaly Lubart
>
> Export PAVP client to work with i915_cp driver,
s/i915_cp driver/i915's pxp
iirc i915_cp was an experiment to have the pxp as a
separated MFD driver.
> for binding it uses kernel component framework.
>
> Signed-off-by: Vitaly Lubart
> Signed-off-by: Tomas Winkler
> ---
> drivers/misc/mei/Kconfig | 2 +
> drivers/misc/mei/Makefile | 1 +
> drivers/misc/mei/pxp/Kconfig | 13 ++
> drivers/misc/mei/pxp/Makefile | 7 +
> drivers/misc/mei/pxp/mei_pxp.c | 230 +
> drivers/misc/mei/pxp/mei_pxp.h | 18 +++
> 6 files changed, 271 insertions(+)
> create mode 100644 drivers/misc/mei/pxp/Kconfig
> create mode 100644 drivers/misc/mei/pxp/Makefile
> create mode 100644 drivers/misc/mei/pxp/mei_pxp.c
> create mode 100644 drivers/misc/mei/pxp/mei_pxp.h
>
> diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig
> index f5fd5b786607..0e0bcd0da852 100644
> --- a/drivers/misc/mei/Kconfig
> +++ b/drivers/misc/mei/Kconfig
> @@ -47,3 +47,5 @@ config INTEL_MEI_TXE
> Intel Bay Trail
>
> source "drivers/misc/mei/hdcp/Kconfig"
> +source "drivers/misc/mei/pxp/Kconfig"
> +
> diff --git a/drivers/misc/mei/Makefile b/drivers/misc/mei/Makefile
> index f1c76f7ee804..d8e5165917f2 100644
> --- a/drivers/misc/mei/Makefile
> +++ b/drivers/misc/mei/Makefile
> @@ -26,3 +26,4 @@ mei-$(CONFIG_EVENT_TRACING) += mei-trace.o
> CFLAGS_mei-trace.o = -I$(src)
>
> obj-$(CONFIG_INTEL_MEI_HDCP) += hdcp/
> +obj-$(CONFIG_INTEL_MEI_PXP) += pxp/
> diff --git a/drivers/misc/mei/pxp/Kconfig b/drivers/misc/mei/pxp/Kconfig
> new file mode 100644
> index ..4029b96afc04
> --- /dev/null
> +++ b/drivers/misc/mei/pxp/Kconfig
> @@ -0,0 +1,13 @@
> +
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (c) 2020, Intel Corporation. All rights reserved.
> +#
> +config INTEL_MEI_PXP
> + tristate "Intel PXP services of ME Interface"
> + select INTEL_MEI_ME
> + depends on DRM_I915
> + help
> + MEI Support for PXP Services on Intel platforms.
> +
> + Enables the ME FW services required for PXP support through
> + I915 display driver of Intel.
> diff --git a/drivers/misc/mei/pxp/Makefile b/drivers/misc/mei/pxp/Makefile
> new file mode 100644
> index ..0329950d5794
> --- /dev/null
> +++ b/drivers/misc/mei/pxp/Makefile
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +# Copyright (c) 2020, Intel Corporation. All rights reserved.
> +#
> +# Makefile - PXP client driver for Intel MEI Bus Driver.
> +
> +obj-$(CONFIG_INTEL_MEI_PXP) += mei_pxp.o
> diff --git a/drivers/misc/mei/pxp/mei_pxp.c b/drivers/misc/mei/pxp/mei_pxp.c
> new file mode 100644
> index ..bd31fce1e6ba
> --- /dev/null
> +++ b/drivers/misc/mei/pxp/mei_pxp.c
> @@ -0,0 +1,230 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright © 2020 Intel Corporation
> + */
> +
> +/**
> + * DOC: MEI_PXP Client Driver
> + *
> + * The mei_pxp driver acts as a translation layer between PXP
> + * protocol implementer (I915) and ME FW by translating PXP
> + * negotiation messages to ME FW command payloads and vice versa.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "mei_pxp.h"
> +
> +/**
> + * mei_pxp_send_message() - Sends a PXP message to ME FW.
> + * @dev: device corresponding to the mei_cl_device
> + * @message: a message buffer to send
> + * @size: size of the message
> + * Return: 0 on Success, <0 on Failure
> + */
> +static int
> +mei_pxp_send_message(struct device *dev, const void *message, size_t size)
> +{
> + struct mei_cl_device *cldev;
> + ssize_t byte;
> +
> + if (!dev || !message)
> + return -EINVAL;
> +
> + cldev = to_mei_cl_device(dev);
> +
> + /* temporary drop const qualifier till the API is fixed */
> + byte = mei_cldev_send(cldev, (u8 *)message, size);
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
> + return byte;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * mei_pxp_receive_message() - Receives a PXP message from ME FW.
> + * @dev: device corresponding to the mei_cl_device
> + * @buffer: a message buffer to contain the received message
> + * @size: size of the buffer
> + * Return: bytes sent on Success, <0 on Failure
> + */
> +static int
> +mei_pxp_receive_message(struct device *dev, void *buffer, size_t size)
> +{
> + struct mei_cl_device *cldev;
> + ssize_t byte;
> +
> + if (!dev || !buffer)
> + return -EINVAL;
> +
> + cldev = to_mei_cl_device(dev);
> +
> + byte = mei_cldev_recv(cldev, buffer, size);
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
> + return byte;
> + }
> +
> + return byte;
> +}
> +
> +static const struct i915_pxp_component_ops mei_pxp_ops = {
Re: [Intel-gfx] [PATCH] kernel: Expose SYS_kcmp by default
On 2021-02-08 12:49 p.m., Michel Dänzer wrote: On 2021-02-05 9:53 p.m., Daniel Vetter wrote: On Fri, Feb 5, 2021 at 7:37 PM Kees Cook wrote: On Fri, Feb 05, 2021 at 04:37:52PM +, Chris Wilson wrote: Userspace has discovered the functionality offered by SYS_kcmp and has started to depend upon it. In particular, Mesa uses SYS_kcmp for os_same_file_description() in order to identify when two fd (e.g. device or dmabuf) point to the same struct file. Since they depend on it for core functionality, lift SYS_kcmp out of the non-default CONFIG_CHECKPOINT_RESTORE into the selectable syscall category. Signed-off-by: Chris Wilson Cc: Kees Cook Cc: Andy Lutomirski Cc: Will Drewry Cc: Andrew Morton Cc: Dave Airlie Cc: Daniel Vetter Cc: Lucas Stach --- init/Kconfig | 11 +++ kernel/Makefile | 2 +- tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +- 3 files changed, 13 insertions(+), 2 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index b77c60f8b963..f62fca13ac5b 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1194,6 +1194,7 @@ endif # NAMESPACES config CHECKPOINT_RESTORE bool "Checkpoint/restore support" select PROC_CHILDREN + select KCMP default n help Enables additional kernel features in a sake of checkpoint/restore. @@ -1737,6 +1738,16 @@ config ARCH_HAS_MEMBARRIER_CALLBACKS config ARCH_HAS_MEMBARRIER_SYNC_CORE bool +config KCMP + bool "Enable kcmp() system call" if EXPERT + default y I would expect this to be not default-y, especially if CHECKPOINT_RESTORE does a "select" on it. This is a really powerful syscall, but it is bounded by ptrace access controls, and uses pointer address obfuscation, so it may be okay to expose this. As it is, at least Ubuntu already has CONFIG_CHECKPOINT_RESTORE, so really, there's probably not much difference on exposure. So, if you drop the "default y", I'm fine with this. It was maybe stupid, but our userspace started relying on fd comaprison through sys_kcomp. So for better or worse, if you want to run the mesa3d gl/vk stacks, you need this. That's overstating things somewhat. The vast majority of applications will work fine regardless (as they did before Mesa started using this functionality). Only some special ones will run into issues, because the user-space drivers incorrectly assume two file descriptors reference different descriptions. Was maybe not the brighest ideas, but since enough distros had this enabled by defaults, Right, that (and the above) is why I considered it fair game to use. What should I have done instead? (TBH I was surprised that this functionality isn't generally available) In that spirit, an alternative might be to make KCMP_FILE available unconditionally, and the rest of SYS_kcmp only with CHECKPOINT_RESTORE as before. (Or maybe other parts of SYS_kcmp are generally useful as well?) -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/31] drm/i915: Replace priolist rbtree with a skiplist
Quoting Tvrtko Ursulin (2021-02-08 12:29:14)
>
> On 08/02/2021 10:52, Chris Wilson wrote:
> > +static void remove_from_priolist(struct i915_sched *se,
> > + struct i915_request *rq,
> > + struct list_head *list,
> > + bool tail)
> > +{
> > + struct list_head *prev = rq->sched.link.prev;
>
> This depends on rq being at the head of it's list?
Not depends. We are testing if the list is singular, that is by removing
this request from the i915_priolist.requests that list becomes empty,
and so the i915_priolist can be removed from the skiplist.
> > +
> > + GEM_BUG_ON(!i915_request_in_priority_queue(rq));
> > +
> > + __list_del_entry(>sched.link);
> > + if (tail)
> > + list_add_tail(>sched.link, list);
> > + else
> > + list_add(>sched.link, list);
>
> So it is more move than remove(_from_priolist) ?
Yes, we can quite happily just keep the list_move(), except we then end
up with lots of empty levels. At first I thought the walk through those
(during dequeue) would be cheaper than removing. The max lock holdtime
strongly favours the removal as we move requests around (which will
happen in dribs-and-drabs) over doing a bulk remove at dequeue.
> > + /* If we just removed the last element in the old plist, delete it */
> > + if (list_empty(prev))
> > + __remove_priolist(se, prev);
> > +}
> > +
> > +struct i915_priolist *__i915_sched_dequeue_next(struct i915_sched *se)
> > +{
> > + struct i915_priolist * const s = >queue.sentinel;
> > + struct i915_priolist *pl = s->next[0];
> > + int lvl;
> > +
> > + GEM_BUG_ON(!list_empty(>requests));
>
> Lost as to why pl->requests has to be empty at this point. Considering:
>
> +#define i915_sched_dequeue(se, pl, rq, rn) \
> + for ((pl) = (se)->queue.sentinel.next[0]; \
> +(pl) != &(se)->queue.sentinel; \
> +(pl) = __i915_sched_dequeue_next(se)) \
> + priolist_for_each_request_safe(rq, rn, pl)
> +
>
> I also don't understand what it would de-queue. Whole priolist woth of
> requests at a time? But it can't be empty to dequeue something. And who
> puts any unconsumed requests back on somewhere in this case.
It's a double for-loop. I think the flattening of the logic is worth it.
During dequeue, we always move the very first request onto the next list
(i.e. i915_sched.active). Then when we have finished with all the
requests in one priority level, we move onto the next i915_priolist
(calling __i915_sched_dequeue_next).
So in __i915_sched_dequeue_next, we are always dealing with an empty
i915_priolist and want to advance the start of the skiplist to the next.
I was thinking that in order to hide the double for-loop, we could
handle the non-empty i915_priolist case causing it to break out of the
outer loop. So we could get rid of the goto done.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: build warning after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (htmldocs)
produced this warning:
include/drm/gpu_scheduler.h:304: warning: Function parameter or member '_score'
not described in 'drm_gpu_scheduler'
Introduced by commit
f2f12eb9c32b ("drm/scheduler: provide scheduler score externally")
--
Cheers,
Stephen Rothwell
pgpuqtj8Rn2oX.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/31] drm/i915: Replace priolist rbtree with a skiplist
On 08/02/2021 10:52, Chris Wilson wrote:
Replace the priolist rbtree with a skiplist. The crucial difference is
that walking and removing the first element of a skiplist is O(1), but
O(lgN) for an rbtree, as we need to rebalance on remove. This is a
hindrance for submission latency as it occurs between picking a request
for the priolist and submitting it to hardware, as well effectively
tripling the number of O(lgN) operations required under the irqoff lock.
This is critical to reducing the latency jitter with multiple clients.
The downsides to skiplists are that lookup/insertion is only
probabilistically O(lgN) and there is a significant memory penalty to
as each skip node is larger than the rbtree equivalent. Furthermore, we
don't use dynamic arrays for the skiplist, so the allocation is fixed,
and imposes an upper bound on the scalability wrt to the number of
inflight requests.
In the following patches, we introduce a new sort key to the scheduler,
a virtual deadline. This imposes a different structure to the tree.
Using a priority sort, we have very few priority levels active at any
time, most likely just the default priority and so the rbtree degenerates
to a single elements containing the list of all ready requests. The
deadlines in contrast are very sparse, and typically each request has a
unique deadline. Instead of being able to simply walk the list during
dequeue, with the deadline scheduler we have to iterate through the bst
on the critical submission path. Skiplists are vastly superior in this
instance due to the O(1) iteration during dequeue, with very similar
characteristics [on average] to the rbtree for insertion.
This means that by using skiplists we can introduce a sparse sort key
without degrading latency on the critical submission path.
As an example, one simple case where we try to do lots of
semi-independent work without any priority management (gem_exec_parallel),
the lock hold times were:
[worst][total][avg]
973.05 6301584.84 0.35 # plain rbtree
559.82 5424915.25 0.33 # best rbtree with pruning
208.21 3898784.09 0.24 # skiplist
34.05 5784106.01 0.32 # rbtree without deadlines
23.35 4152999.80 0.24 # skiplist without deadlines
Based on the skiplist implementation by Dr Con Kolivas for MuQSS.
References: https://en.wikipedia.org/wiki/Skip_list
Signed-off-by: Chris Wilson
---
.../drm/i915/gt/intel_execlists_submission.c | 168 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 41 +--
drivers/gpu/drm/i915/i915_priolist_types.h| 64 +++-
drivers/gpu/drm/i915/i915_scheduler.c | 304 +-
drivers/gpu/drm/i915/i915_scheduler.h | 16 +-
drivers/gpu/drm/i915/i915_scheduler_types.h | 2 +-
.../drm/i915/selftests/i915_mock_selftests.h | 1 +
.../gpu/drm/i915/selftests/i915_scheduler.c | 53 ++-
8 files changed, 454 insertions(+), 195 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 78fda9b4f626..4a0258347c10 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -254,11 +254,6 @@ static void ring_set_paused(const struct intel_engine_cs
*engine, int state)
wmb();
}
-static struct i915_priolist *to_priolist(struct rb_node *rb)
-{
- return rb_entry(rb, struct i915_priolist, node);
-}
-
static int rq_prio(const struct i915_request *rq)
{
return READ_ONCE(rq->sched.attr.priority);
@@ -282,15 +277,27 @@ static int effective_prio(const struct i915_request *rq)
return prio;
}
+static struct i915_request *first_request(const struct i915_sched *se)
+{
+ struct i915_priolist *pl = se->queue.sentinel.next[0];
+
+ if (pl == >queue.sentinel)
+ return NULL;
+
+ return list_first_entry_or_null(>requests,
+ struct i915_request,
+ sched.link);
+}
+
static int queue_prio(const struct i915_sched *se)
{
- struct rb_node *rb;
+ struct i915_request *rq;
- rb = rb_first_cached(>queue);
- if (!rb)
+ rq = first_request(se);
+ if (!rq)
return INT_MIN;
- return to_priolist(rb)->priority;
+ return rq_prio(rq);
}
static int virtual_prio(const struct intel_engine_execlists *el)
@@ -300,7 +307,7 @@ static int virtual_prio(const struct intel_engine_execlists
*el)
return rb ? rb_entry(rb, struct ve_node, rb)->prio : INT_MIN;
}
-static bool need_preempt(const struct intel_engine_cs *engine,
+static bool need_preempt(struct intel_engine_cs *engine,
const struct i915_request *rq)
{
const struct i915_sched *se = >sched;
@@ -1144,7 +1151,9 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
struct i915_request **port =
