Re: [Intel-gfx] [PATCH v5 0/5] Asynchronous flip implementation for i915
> -Original Message- > From: Michel Dänzer > Sent: Wednesday, July 29, 2020 1:04 PM > To: Kulkarni, Vandita ; Zanoni, Paulo R > ; Vetter, Daniel ; B S, > Karthik ; intel-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org; Shankar, Uma > ; nicholas.kazlaus...@amd.com > Subject: Re: [PATCH v5 0/5] Asynchronous flip implementation for i915 > > On 2020-07-29 9:23 a.m., Kulkarni, Vandita wrote: > > > > On async flips, there needs to be some clarity/guideline on the > > behaviour and event expectation from the driver by user space. > > Here are few assumptions that we have, 1. Our understanding is that > > the user space doesn’t expect the timestamp for async flips (but still > > expects vblank timestamp) , or doesn’t do anything with that, same is the > assumption wrt the flip sequence, please correct us if we are wrong. > > 2. In the sequence the user space still expects the counter that marks > vblanks. > > 3. The user space can use different event types like DRM_EVENT_VBLANK > > or DRM_EVENT_FLIP_COMPLETE for getting the corresponding event. And > their designs are still aligned to this even in case of async. > > > > If there are any more expectations from the user space wrt to the > > event that is being sent from the driver in case of async flip, please let > > us > know. > > > > If the user space doesn’t care much about the flip sequence then, we > > can just not do anything like returning the flip counter like this version > > is > doing and just stick to returning of the frame counter value(which marks > vblanks). > > There's no such thing as a "flip sequence" in the KMS API. There's only the > per-CRTC vblank counter. Each flip completion event needs to contain the > value of that counter when the hardware completed the flip, regardless of > whether it was an async flip or not. > > As for the timestamp in the event, I'm not sure what the expectations are for > async flips, but I suspect it may not really matter. E.g. the timestamp > calculated to correspond to the end of the previous vertical blank period > might be fine. Thanks Michel, Paulo, Daniel, Nicholas, Ville for your inputs. After all the discussions, looks like the async flip time stamp is not of much use to the userspace and the async flip sequence; hence we will stick to the approach of sending vblank time stamp itself and have a test case in the igt to cover the async flips cases in a slightly different way. And update the documentation. Thanks, Vandita > > > -- > 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
[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "drm/i915/rkl: Add Wa_14011224835 for PHY B initialization"
== Series Details ==
Series: Revert "drm/i915/rkl: Add Wa_14011224835 for PHY B initialization"
URL : https://patchwork.freedesktop.org/series/80235/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8836 -> Patchwork_18305
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18305/index.html
Known issues
Here are the changes found in Patchwork_18305 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18305/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
- fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18305/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- {fi-kbl-7560u}: [CRASH][5] -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/fi-kbl-7560u/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18305/fi-kbl-7560u/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@execlists:
- {fi-tgl-dsi}: [INCOMPLETE][7] -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18305/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18305/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18305/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18305/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
* igt@kms_setmode@basic-clone-single-crtc:
- {fi-kbl-7560u}: [WARN][15] ([i915#2100]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/fi-kbl-7560u/igt@kms_setm...@basic-clone-single-crtc.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18305/fi-kbl-7560u/igt@kms_setm...@basic-clone-single-crtc.html
Warnings
* igt@kms_force_connector_basic@force-connector-state:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92]) ->
[DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18305/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][20] ([i915#62] / [i915#92]) +5 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18305/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2100]: https://gitlab.freedesktop.org/drm/intel/issues/2100
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (43 -> 36)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Revert "drm/i915/rkl: Add Wa_14011224835 for PHY B initialization"
== Series Details == Series: Revert "drm/i915/rkl: Add Wa_14011224835 for PHY B initialization" URL : https://patchwork.freedesktop.org/series/80235/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Revert "drm/i915/rkl: Add Wa_14011224835 for PHY B initialization"
The hardware team has dropped this workaround from the bspec; it is no
longer needed.
This reverts commit 111822b21be995a3a4a731066db3d820523c57f7.
Bspec: 49291
Cc: José Roberto de Souza
Signed-off-by: Matt Roper
---
.../gpu/drm/i915/display/intel_combo_phy.c| 50 ---
drivers/gpu/drm/i915/i915_reg.h | 13 +
2 files changed, 1 insertion(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
b/drivers/gpu/drm/i915/display/intel_combo_phy.c
index d88f91038428..eccaa79cb4a9 100644
--- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
@@ -255,26 +255,6 @@ static bool phy_is_master(struct drm_i915_private
*dev_priv, enum phy phy)
return phy == PHY_A;
}
-static bool verify_wa14011224835(struct drm_i915_private *i915)
-{
- u32 grccode, val;
- bool ret = true;
-
- grccode = REG_FIELD_GET(GRCCODE,
- intel_de_read(i915, ICL_PORT_COMP_DW6(PHY_A)));
- val = REG_FIELD_PREP(IREF_RCAL_ORD, grccode);
- ret &= check_phy_reg(i915, PHY_B, ICL_PORT_COMP_DW2(PHY_B),
-IREF_RCAL_ORD, val);
-
- grccode = REG_FIELD_GET(GRCCODE_LDO,
- intel_de_read(i915, ICL_PORT_COMP_DW0(PHY_A)));
- val = REG_FIELD_PREP(RCOMPCODE_LD_CAP_OV, grccode);
- ret &= check_phy_reg(i915, PHY_B, ICL_PORT_COMP_DW2(PHY_B),
-IREF_RCAL_ORD, val);
-
- return ret;
-}
-
static bool icl_combo_phy_verify_state(struct drm_i915_private *dev_priv,
enum phy phy)
{
@@ -315,11 +295,6 @@ static bool icl_combo_phy_verify_state(struct
drm_i915_private *dev_priv,
ret &= check_phy_reg(dev_priv, phy, ICL_PORT_CL_DW5(phy),
CL_POWER_DOWN_ENABLE, CL_POWER_DOWN_ENABLE);
- /* Wa_14011224835:rkl[a0..b0] */
- if (IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_B0) &&
- phy == PHY_B)
- ret &= verify_wa14011224835(dev_priv);
-
return ret;
}
@@ -375,26 +350,6 @@ void intel_combo_phy_power_up_lanes(struct
drm_i915_private *dev_priv,
intel_de_write(dev_priv, ICL_PORT_CL_DW10(phy), val);
}
-static void rkl_combo_phy_b_init_wa(struct drm_i915_private *i915)
-{
- u32 grccode, val;
-
- wait_for_us(intel_de_read(i915, ICL_PORT_COMP_DW3(PHY_A)) &
- FIRST_COMP_DONE, 100);
-
- grccode = REG_FIELD_GET(GRCCODE,
- intel_de_read(i915, ICL_PORT_COMP_DW6(PHY_A)));
- val = REG_FIELD_PREP(IREF_RCAL_ORD, grccode);
- intel_de_rmw(i915, ICL_PORT_COMP_DW2(PHY_B), IREF_RCAL_ORD,
-val | IREF_RCAL_ORD_EN);
-
- grccode = REG_FIELD_GET(GRCCODE_LDO,
- intel_de_read(i915, ICL_PORT_COMP_DW0(PHY_A)));
- val = REG_FIELD_PREP(RCOMPCODE_LD_CAP_OV, grccode);
- intel_de_rmw(i915, ICL_PORT_COMP_DW6(PHY_B), RCOMPCODE_LD_CAP_OV,
-val | RCOMPCODEOVEN_LDO_SYNC);
-}
-
static void icl_combo_phys_init(struct drm_i915_private *dev_priv)
{
enum phy phy;
@@ -460,11 +415,6 @@ static void icl_combo_phys_init(struct drm_i915_private
*dev_priv)
val = intel_de_read(dev_priv, ICL_PORT_CL_DW5(phy));
val |= CL_POWER_DOWN_ENABLE;
intel_de_write(dev_priv, ICL_PORT_CL_DW5(phy), val);
-
- if (IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_B0) &&
- phy == PHY_B)
- /* Wa_14011224835:rkl[a0..b0] */
- rkl_combo_phy_b_init_wa(dev_priv);
}
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5eae593ee784..2b403df03404 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1911,16 +1911,11 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define CNL_PORT_COMP_DW0 _MMIO(0x162100)
#define ICL_PORT_COMP_DW0(phy) _MMIO(_ICL_PORT_COMP_DW(0, phy))
-#define COMP_INITREG_BIT(31)
-#define GRCCODE_LDO REG_GENMASK(7, 0)
+#define COMP_INIT(1 << 31)
#define CNL_PORT_COMP_DW1 _MMIO(0x162104)
#define ICL_PORT_COMP_DW1(phy) _MMIO(_ICL_PORT_COMP_DW(1, phy))
-#define ICL_PORT_COMP_DW2(phy) _MMIO(_ICL_PORT_COMP_DW(2, phy))
-#define IREF_RCAL_ORD_EN REG_BIT(7)
-#define IREF_RCAL_ORDREG_GENMASK(6, 0)
-
#define CNL_PORT_COMP_DW3 _MMIO(0x16210c)
#define ICL_PORT_COMP_DW3(phy) _MMIO(_ICL_PORT_COMP_DW(3, phy))
#define PROCESS_INFO_DOT_0 (0 << 26)
@@ -1933,12 +1928,6 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define VOLTAGE_INFO_1_05V (2 << 24)
#define VOLTAGE_INFO_MASK(3 << 24)
#define VOLTAGE_INFO_SHIFT 24
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/kmb: Add support for KeemBay Display (rev3)
== Series Details == Series: drm/kmb: Add support for KeemBay Display (rev3) URL : https://patchwork.freedesktop.org/series/79615/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8836_full -> Patchwork_18304_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18304_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18304_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_18304_full: ### IGT changes ### Possible regressions * igt@kms_flip@flip-vs-suspend@b-edp1: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/shard-skl1/igt@kms_flip@flip-vs-susp...@b-edp1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18304/shard-skl1/igt@kms_flip@flip-vs-susp...@b-edp1.html * igt@kms_mmap_write_crc@main: - shard-glk: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/shard-glk6/igt@kms_mmap_write_...@main.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18304/shard-glk8/igt@kms_mmap_write_...@main.html Warnings * igt@runner@aborted: - shard-hsw: [FAIL][5] -> ([FAIL][6], [FAIL][7]) ([fdo#109271]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/shard-hsw6/igt@run...@aborted.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18304/shard-hsw6/igt@run...@aborted.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18304/shard-hsw1/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_18304_full that come from known issues: ### IGT changes ### Issues hit * igt@gen9_exec_parse@allowed-all: - shard-apl: [PASS][8] -> [DMESG-WARN][9] ([i915#1436] / [i915#1635] / [i915#716]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/shard-apl2/igt@gen9_exec_pa...@allowed-all.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18304/shard-apl4/igt@gen9_exec_pa...@allowed-all.html * igt@kms_big_fb@x-tiled-64bpp-rotate-0: - shard-glk: [PASS][10] -> [DMESG-FAIL][11] ([i915#118] / [i915#95]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/shard-glk2/igt@kms_big...@x-tiled-64bpp-rotate-0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18304/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-0.html * igt@kms_cursor_edge_walk@pipe-c-256x256-bottom-edge: - shard-skl: [PASS][12] -> [DMESG-WARN][13] ([i915#1982]) +9 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/shard-skl7/igt@kms_cursor_edge_w...@pipe-c-256x256-bottom-edge.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18304/shard-skl7/igt@kms_cursor_edge_w...@pipe-c-256x256-bottom-edge.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic: - shard-skl: [PASS][14] -> [FAIL][15] ([IGT#5]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/shard-skl5/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18304/shard-skl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html * igt@kms_flip@2x-plain-flip-fb-recreate-interruptible@bc-hdmi-a1-hdmi-a2: - shard-glk: [PASS][16] -> [FAIL][17] ([i915#2122]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/shard-glk3/igt@kms_flip@2x-plain-flip-fb-recreate-interrupti...@bc-hdmi-a1-hdmi-a2.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18304/shard-glk7/igt@kms_flip@2x-plain-flip-fb-recreate-interrupti...@bc-hdmi-a1-hdmi-a2.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-mmap-gtt: - shard-iclb: [PASS][18] -> [DMESG-WARN][19] ([i915#1982]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-mmap-gtt.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18304/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-mmap-gtt.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][20] -> [DMESG-WARN][21] ([i915#180]) +3 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/shard-kbl6/igt@kms_frontbuffer_track...@fbc-suspend.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18304/shard-kbl2/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-blt: - shard-tglb: [PASS][22] -> [DMESG-WARN][23] ([i915#1982]) +5 similar issues [22]:
Re: [Intel-gfx] [PATCH v5 15/22] drm/i915/dg1: Update voltage swing tables for DP
On Fri, 2020-07-24 at 14:39 -0700, Lucas De Marchi wrote:
> From: Matt Roper <
> matthew.d.ro...@intel.com
> >
>
> DG1's vswing tables are the same for eDP and HDMI but have slight
> differences from ICL/TGL for DP.
Reviewed-by: José Roberto de Souza
>
> Bspec: 49291
> Cc: Clinton Taylor <
> clinton.a.tay...@intel.com
> >
> Cc: José Roberto de Souza <
> jose.so...@intel.com
> >
> Cc: Radhakrishna Sripada <
> radhakrishna.srip...@intel.com
> >
> Signed-off-by: Matt Roper <
> matthew.d.ro...@intel.com
> >
> Signed-off-by: Lucas De Marchi <
> lucas.demar...@intel.com
> >
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 34
> 1 file changed, 34 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 714b2bc96f23..c19d5a375eba 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -582,6 +582,34 @@ static const struct cnl_ddi_buf_trans
> ehl_combo_phy_ddi_translations_dp[] = {
> { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
> };
>
> +static const struct cnl_ddi_buf_trans
> dg1_combo_phy_ddi_translations_dp_hbr[] = {
> + /* NT mV Trans mV db*/
> + { 0xA, 0x32, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> + { 0xA, 0x48, 0x35, 0x00, 0x0A },/* 350 500 3.1 */
> + { 0xC, 0x63, 0x2F, 0x00, 0x10 },/* 350 700 6.0 */
> + { 0x6, 0x7F, 0x2C, 0x00, 0x13 },/* 350 900 8.2 */
> + { 0xA, 0x43, 0x3F, 0x00, 0x00 },/* 500 500 0.0 */
> + { 0xC, 0x60, 0x36, 0x00, 0x09 },/* 500 700 2.9 */
> + { 0x6, 0x7F, 0x30, 0x00, 0x0F },/* 500 900 5.1 */
> + { 0xC, 0x60, 0x3F, 0x00, 0x00 },/* 650 700 0.6 */
> + { 0x6, 0x7F, 0x37, 0x00, 0x08 },/* 600 900 3.5 */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
> +};
> +
> +static const struct cnl_ddi_buf_trans
> dg1_combo_phy_ddi_translations_dp_hbr2[] = {
> + /* NT mV Trans mV db*/
> + { 0xA, 0x32, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> + { 0xA, 0x48, 0x35, 0x00, 0x0A },/* 350 500 3.1 */
> + { 0xC, 0x63, 0x2F, 0x00, 0x10 },/* 350 700 6.0 */
> + { 0x6, 0x7F, 0x2C, 0x00, 0x13 },/* 350 900 8.2 */
> + { 0xA, 0x43, 0x3F, 0x00, 0x00 },/* 500 500 0.0 */
> + { 0xC, 0x60, 0x36, 0x00, 0x09 },/* 500 700 2.9 */
> + { 0x6, 0x7F, 0x30, 0x00, 0x0F },/* 500 900 5.1 */
> + { 0xC, 0x58, 0x3F, 0x00, 0x00 },/* 650 700 0.6 */
> + { 0x6, 0x7F, 0x35, 0x00, 0x0A },/* 600 900 3.5 */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
> +};
> +
> struct icl_mg_phy_ddi_buf_trans {
> u32 cri_txdeemph_override_11_6;
> u32 cri_txdeemph_override_5_0;
> @@ -1034,6 +1062,12 @@ icl_get_combo_buf_trans(struct intel_encoder *encoder,
> int type, int rate,
> } else if (type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp.low_vswing) {
> *n_entries =
> ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr2);
> return icl_combo_phy_ddi_translations_edp_hbr2;
> + } else if (IS_DG1(dev_priv) && rate > 27) {
> + *n_entries = ARRAY_SIZE(dg1_combo_phy_ddi_translations_dp_hbr2);
> + return dg1_combo_phy_ddi_translations_dp_hbr2;
> + } else if (IS_DG1(dev_priv)) {
> + *n_entries = ARRAY_SIZE(dg1_combo_phy_ddi_translations_dp_hbr);
> + return dg1_combo_phy_ddi_translations_dp_hbr;
> }
>
> *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hbr2);
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 21/22] drm/i915/dg1: DG1 does not support DC6
On Fri, 2020-07-24 at 14:39 -0700, Lucas De Marchi wrote:
> From: Anshuman Gupta <
> anshuman.gu...@intel.com
> >
>
> DC6 is not supported on DG1, so change the allowed DC mask for DG1.
>
> Cc: Uma Shankar <
> uma.shan...@intel.com
> >
> Signed-off-by: Anshuman Gupta <
> anshuman.gu...@intel.com
> >
> ---
> drivers/gpu/drm/i915/display/intel_display_power.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 21f39c94056e..389a0f2d3a14 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -4689,7 +4689,10 @@ static u32 get_allowed_dc_mask(const struct
> drm_i915_private *dev_priv,
> int max_dc;
>
> if (INTEL_GEN(dev_priv) >= 12) {
> - max_dc = 4;
> + if (IS_DG1(dev_priv))
Better change to IS_DGFX() as DC6 is a SOC power-saving state, no discrete card
will enter it.
With this change:
Reviewed-by: José Roberto de Souza
> + max_dc = 3;
> + else
> + max_dc = 4;
> /*
>* DC9 has a separate HW flow from the rest of the DC states,
>* not depending on the DMC firmware. It's needed by system
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 22/22] drm/i915/dg1: Change DMC_DEBUG{1, 2} registers
On Fri, 2020-07-24 at 14:39 -0700, Lucas De Marchi wrote:
> From: Anshuman Gupta <
> anshuman.gu...@intel.com
> >
>
> DGFX devices have different DMC_DEBUG* counter MMIO address
> offset. Incorporate these changes in i915_reg.h for DG1 DC5/DC6
> counter and handle i915_dmc_info accordingly.
>
> Cc: Uma Shankar <
> uma.shan...@intel.com
> >
> Signed-off-by: Anshuman Gupta <
> anshuman.gu...@intel.com
> >
> Signed-off-by: Lucas De Marchi <
> lucas.demar...@intel.com
> >
> ---
> drivers/gpu/drm/i915/display/intel_display_debugfs.c | 9 +++--
> drivers/gpu/drm/i915/i915_reg.h | 2 ++
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 3644752cc5ec..e3536edcb394 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -515,8 +515,13 @@ static int i915_dmc_info(struct seq_file *m, void
> *unused)
> CSR_VERSION_MINOR(csr->version));
>
> if (INTEL_GEN(dev_priv) >= 12) {
> - dc5_reg = TGL_DMC_DEBUG_DC5_COUNT;
> - dc6_reg = TGL_DMC_DEBUG_DC6_COUNT;
> + if (IS_DG1(dev_priv)) {
> + dc5_reg = DG1_DMC_DEBUG_DC5_COUNT;
> + } else {
> + dc5_reg = TGL_DMC_DEBUG_DC5_COUNT;
> + dc6_reg = TGL_DMC_DEBUG_DC6_COUNT;
> + }
> +
> /*
>* NOTE: DMC_DEBUG3 is a general purpose reg.
>* According to B.Specs:49196 DMC f/w reuses DC5/6 counter
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4e95312eba24..78bdce67da08 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7549,6 +7549,8 @@ enum {
> #define BXT_CSR_DC3_DC5_COUNT_MMIO(0x80038)
> #define TGL_DMC_DEBUG_DC5_COUNT _MMIO(0x101084)
> #define TGL_DMC_DEBUG_DC6_COUNT _MMIO(0x101088)
> +#define DG1_DMC_DEBUG_DC5_COUNT _MMIO(0x134154)
> +#define DG1_DMC_DEBUG_DC6_COUNT _MMIO(0x134158)
DG1_DMC_DEBUG_DC6_COUNT is not used as DG1 do not support DC6.
Removing it:
Reviewed-by: José Roberto de Souza
>
> #define DMC_DEBUG3 _MMIO(0x101090)
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 19/22] drm/i915/dg1: Load DMC
On Fri, 2020-07-24 at 14:39 -0700, Lucas De Marchi wrote:
> From: Matt Atwood <
> matthew.s.atw...@intel.com
> >
>
> Add support to load DMC v2.0.2 on DG1
>
> While we're at it, tweak the TGL and RKL firmware size definition to
> follow the convention used in previous platforms. Remove obsolete
> commenting.
>
> Bpec: 49230
>
> Cc: Matt Roper <
> matthew.d.ro...@intel.com
> >
> Signed-off-by: Matt Atwood <
> matthew.s.atw...@intel.com
> >
> Signed-off-by: Lucas De Marchi <
> lucas.demar...@intel.com
> >
> ---
> drivers/gpu/drm/i915/display/intel_csr.c | 19 +--
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_csr.c
> b/drivers/gpu/drm/i915/display/intel_csr.c
> index f22a7645c249..ccf13ea627d7 100644
> --- a/drivers/gpu/drm/i915/display/intel_csr.c
> +++ b/drivers/gpu/drm/i915/display/intel_csr.c
> @@ -38,15 +38,19 @@
> * low-power state and comes back to normal.
> */
>
> -#define GEN12_CSR_MAX_FW_SIZEICL_CSR_MAX_FW_SIZE
> +#define DG1_CSR_PATH "i915/dg1_dmc_ver2_02.bin"
> +#define DG1_CSR_VERSION_REQUIRED CSR_VERSION(2, 2)
> +#define DG1_CSR_MAX_FW_SIZE ICL_CSR_MAX_FW_SIZE
> +MODULE_FIRMWARE(DG1_CSR_PATH);
>
> #define RKL_CSR_PATH "i915/rkl_dmc_ver2_01.bin"
> #define RKL_CSR_VERSION_REQUIRED CSR_VERSION(2, 1)
> +#define RKL_CSR_MAX_FW_SIZE ICL_CSR_MAX_FW_SIZE
> MODULE_FIRMWARE(RKL_CSR_PATH);
>
> #define TGL_CSR_PATH "i915/tgl_dmc_ver2_06.bin"
> #define TGL_CSR_VERSION_REQUIRED CSR_VERSION(2, 6)
> -#define TGL_CSR_MAX_FW_SIZE 0x6000
> +#define TGL_CSR_MAX_FW_SIZE ICL_CSR_MAX_FW_SIZE
Until CSR_MAX_FW_SIZE of a GEN12 platform is different I don't see a reason why
to define a per-platform CSR_MAX_FW_SIZE.
The rest looks good.
> MODULE_FIRMWARE(TGL_CSR_PATH);
>
> #define ICL_CSR_PATH "i915/icl_dmc_ver1_09.bin"
> @@ -686,15 +690,18 @@ void intel_csr_ucode_init(struct drm_i915_private
> *dev_priv)
>*/
> intel_csr_runtime_pm_get(dev_priv);
>
> - if (IS_ROCKETLAKE(dev_priv)) {
> + if (IS_DG1(dev_priv)) {
> + csr->fw_path = DG1_CSR_PATH;
> + csr->required_version = DG1_CSR_VERSION_REQUIRED;
> + csr->max_fw_size = DG1_CSR_MAX_FW_SIZE;
> + } else if (IS_ROCKETLAKE(dev_priv)) {
> csr->fw_path = RKL_CSR_PATH;
> csr->required_version = RKL_CSR_VERSION_REQUIRED;
> - csr->max_fw_size = GEN12_CSR_MAX_FW_SIZE;
> + csr->max_fw_size = RKL_CSR_MAX_FW_SIZE;
> } else if (INTEL_GEN(dev_priv) >= 12) {
> csr->fw_path = TGL_CSR_PATH;
> csr->required_version = TGL_CSR_VERSION_REQUIRED;
> - /* Allow to load fw via parameter using the last known size */
> - csr->max_fw_size = GEN12_CSR_MAX_FW_SIZE;
> + csr->max_fw_size = TGL_CSR_MAX_FW_SIZE;
> } else if (IS_GEN(dev_priv, 11)) {
> csr->fw_path = ICL_CSR_PATH;
> csr->required_version = ICL_CSR_VERSION_REQUIRED;
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 05/22] drm/i915/dg1: Wait for pcode/uncore handshake at startup
On Fri, 2020-07-24 at 14:39 -0700, Lucas De Marchi wrote:
> From: Matt Roper <
> matthew.d.ro...@intel.com
> >
>
> DG1 does some additional pcode/uncore handshaking at
> boot time; this handshaking must complete before various other pcode
> commands are effective and before general work is submitted to the GPU.
> We need to poll a new pcode mailbox during startup until it reports that
> this handshaking is complete.
>
> The bspec doesn't give guidance on how long we may need to wait for this
> handshaking to complete. For now, let's just set a really long timeout;
> if we still don't get a completion status by the end of that timeout,
> we'll just continue on and hope for the best.
>
> Bspec: 52065
> Cc: Clinton Taylor <
> clinton.a.tay...@intel.com
> >
> Cc: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
> Cc: Radhakrishna Sripada <
> radhakrishna.srip...@intel.com
> >
> Signed-off-by: Matt Roper <
> matthew.d.ro...@intel.com
> >
> Signed-off-by: Lucas De Marchi <
> lucas.demar...@intel.com
> >
> ---
> drivers/gpu/drm/i915/i915_drv.c | 3 +++
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> drivers/gpu/drm/i915/intel_sideband.c | 15 +++
> drivers/gpu/drm/i915/intel_sideband.h | 2 ++
> 4 files changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 5fd5af4bc855..5473bfe9126c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -85,6 +85,7 @@
> #include "intel_gvt.h"
> #include "intel_memory_region.h"
> #include "intel_pm.h"
> +#include "intel_sideband.h"
> #include "vlv_suspend.h"
>
> static struct drm_driver driver;
> @@ -737,6 +738,8 @@ static int i915_driver_hw_probe(struct drm_i915_private
> *dev_priv)
>*/
> intel_dram_detect(dev_priv);
>
> + intel_pcode_init(dev_priv);
> +
> intel_bw_init_hw(dev_priv);
>
> return 0;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index a0d31f3bf634..3767b32127da 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9245,6 +9245,9 @@ enum {
> #define GEN9_SAGV_DISABLE0x0
> #define GEN9_SAGV_IS_DISABLED0x1
> #define GEN9_SAGV_ENABLE 0x3
> +#define DG1_PCODE_STATUS 0x7E
> +#define DG1_CHECK_UNCORE_INIT_STATUS 0x0
> +#define DG1_UNCORE_INIT_COMPLETE 0x1
With s/DG1_CHECK_UNCORE_INIT_STATUS/DG1_CHECK_UNCORE_INIT_STATUS_COMPLETE or
something similar that makes easy to understand that 0x1 is the response
of the DG1_CHECK_UNCORE_INIT_STATUS sub-command.
Reviewed-by: José Roberto de Souza
> #define GEN12_PCODE_READ_SAGV_BLOCK_TIME_US 0x23
> #define GEN6_PCODE_DATA _MMIO(0x138128)
> #define GEN6_PCODE_FREQ_IA_RATIO_SHIFT 8
> diff --git a/drivers/gpu/drm/i915/intel_sideband.c
> b/drivers/gpu/drm/i915/intel_sideband.c
> index 916ccd1c0e96..8b093525240d 100644
> --- a/drivers/gpu/drm/i915/intel_sideband.c
> +++ b/drivers/gpu/drm/i915/intel_sideband.c
> @@ -543,3 +543,18 @@ int skl_pcode_request(struct drm_i915_private *i915, u32
> mbox, u32 request,
> return ret ? ret : status;
> #undef COND
> }
> +
> +void intel_pcode_init(struct drm_i915_private *i915)
> +{
> + int ret;
> +
> + if (!IS_DGFX(i915))
> + return;
> +
> + ret = skl_pcode_request(i915, DG1_PCODE_STATUS,
> + DG1_CHECK_UNCORE_INIT_STATUS,
> + DG1_UNCORE_INIT_COMPLETE,
> + DG1_UNCORE_INIT_COMPLETE, 50);
> + if (ret)
> + drm_err(>drm, "Pcode did not report uncore initialization
> completion!\n");
> +}
> diff --git a/drivers/gpu/drm/i915/intel_sideband.h
> b/drivers/gpu/drm/i915/intel_sideband.h
> index 7fb95745a444..094c7b19c5d4 100644
> --- a/drivers/gpu/drm/i915/intel_sideband.h
> +++ b/drivers/gpu/drm/i915/intel_sideband.h
> @@ -138,4 +138,6 @@ int sandybridge_pcode_write_timeout(struct
> drm_i915_private *i915, u32 mbox,
> int skl_pcode_request(struct drm_i915_private *i915, u32 mbox, u32 request,
> u32 reply_mask, u32 reply, int timeout_base_ms);
>
> +void intel_pcode_init(struct drm_i915_private *i915);
> +
> #endif /* _INTEL_SIDEBAND_H */
>
___
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/kmb: Add support for KeemBay Display (rev3)
== Series Details ==
Series: drm/kmb: Add support for KeemBay Display (rev3)
URL : https://patchwork.freedesktop.org/series/79615/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8836 -> Patchwork_18304
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18304/index.html
Known issues
Here are the changes found in Patchwork_18304 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [PASS][1] -> [INCOMPLETE][2] ([i915#456])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18304/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18304/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- {fi-kbl-7560u}: [CRASH][5] -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/fi-kbl-7560u/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18304/fi-kbl-7560u/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@execlists:
- fi-icl-y: [INCOMPLETE][7] -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/fi-icl-y/igt@i915_selftest@l...@execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18304/fi-icl-y/igt@i915_selftest@l...@execlists.html
- {fi-tgl-dsi}: [INCOMPLETE][9] -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18304/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18304/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18304/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
* igt@kms_setmode@basic-clone-single-crtc:
- {fi-kbl-7560u}: [WARN][15] ([i915#2100]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/fi-kbl-7560u/igt@kms_setm...@basic-clone-single-crtc.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18304/fi-kbl-7560u/igt@kms_setm...@basic-clone-single-crtc.html
Warnings
* igt@kms_force_connector_basic@force-connector-state:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92]) ->
[DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95]) +7 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18304/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][20] ([i915#62] / [i915#92]) +3 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8836/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18304/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2100]: https://gitlab.freedesktop.org/drm/intel/issues/2100
[i915#456]: https://gitlab.freedesktop.org/drm/intel/issues/456
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (43 -> 36)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/kmb: Add support for KeemBay Display (rev3)
== Series Details ==
Series: drm/kmb: Add support for KeemBay Display (rev3)
URL : https://patchwork.freedesktop.org/series/79615/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e5e28d2e25e4 drm/kmb: Add support for KeemBay Display
-:57: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#57:
new file mode 100644
-:146: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#146: FILE: drivers/gpu/drm/kmb/kmb_crtc.c:58:
+ kmb_clr_bitmask_lcd(kmb, LCD_INT_ENABLE,
+ LCD_INT_VERT_COMP);
-:173: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#173: FILE: drivers/gpu/drm/kmb/kmb_crtc.c:85:
+ drm_info(dev,
+ "vfp= %d vbp= %d vsyc_len=%d hfp=%d hbp=%d hsync_len=%d\n",
-:194: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#194: FILE: drivers/gpu/drm/kmb/kmb_crtc.c:106:
+ drm_dbg(dev, "%s : %dactive height= %d vbp=%d vfp=%d vsync-w=%d
h-active=%d h-bp=%d h-fp=%d hysnc-l=%d",
+ __func__, __LINE__,
-:199: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#199: FILE: drivers/gpu/drm/kmb/kmb_crtc.c:111:
+ kmb_write_lcd(kmb, LCD_V_ACTIVEHEIGHT,
+ m->crtc_vdisplay - 1);
-:204: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#204: FILE: drivers/gpu/drm/kmb/kmb_crtc.c:116:
+ kmb_write_lcd(kmb, LCD_H_ACTIVEWIDTH,
+ m->crtc_hdisplay - 1);
-:217: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#217: FILE: drivers/gpu/drm/kmb/kmb_crtc.c:129:
+ kmb_write_lcd(kmb,
+ LCD_V_BACKPORCH_EVEN, vm.vback_porch);
-:219: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#219: FILE: drivers/gpu/drm/kmb/kmb_crtc.c:131:
+ kmb_write_lcd(kmb,
+ LCD_V_FRONTPORCH_EVEN, vm.vfront_porch);
-:413: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#413: FILE: drivers/gpu/drm/kmb/kmb_drv.c:60:
+ drm_err(>drm,
+ "Failed to enable MIPI_ECFG clock: %d\n", ret);
-:420: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#420: FILE: drivers/gpu/drm/kmb/kmb_drv.c:67:
+ drm_err(>drm,
+ "Failed to enable MIPI_CFG clock: %d\n", ret);
-:427: CHECK:LINE_SPACING: Please don't use multiple blank lines
#427: FILE: drivers/gpu/drm/kmb/kmb_drv.c:74:
+
+
-:463: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#463: FILE: drivers/gpu/drm/kmb/kmb_drv.c:110:
+ kmb->sys_clk_mhz = clk_get_rate(kmb_clk.clk_pll0)/100;
^
-:470: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#470: FILE: drivers/gpu/drm/kmb/kmb_drv.c:117:
+ drm_err(>drm, "failed to set to clk_lcd to %d\n",
+ KMB_LCD_DEFAULT_CLK);
-:479: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#479: FILE: drivers/gpu/drm/kmb/kmb_drv.c:126:
+ drm_err(>drm, "failed to set to clk_mipi to %d\n",
+ KMB_MIPI_DEFAULT_CLK);
-:506: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#506: FILE: drivers/gpu/drm/kmb/kmb_drv.c:153:
+ drm_err(>drm,
+ "failed to set clk_mipi_cfg to %d\n",
-:511: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#511: FILE: drivers/gpu/drm/kmb/kmb_drv.c:158:
+ drm_info(>drm,
+ "Get clk_mipi_cfg after set = %ld\n", clk);
-:561: CHECK:LINE_SPACING: Please don't use multiple blank lines
#561: FILE: drivers/gpu/drm/kmb/kmb_drv.c:208:
+
+
-:688: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#688: FILE: drivers/gpu/drm/kmb/kmb_drv.c:335:
+ if (status & LCD_INT_EOF) {
+
-:701: CHECK:CAMELCASE: Avoid CamelCase:
#701: FILE: drivers/gpu/drm/kmb/kmb_drv.c:348:
+ LCD_LAYERn_DMA_CFG
-:706: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#706: FILE: drivers/gpu/drm/kmb/kmb_drv.c:353:
+ kmb_clr_bitmask_lcd(kmb, LCD_CONTROL,
+ plane_status[plane_id].ctrl);
-:733: CHECK:BRACES: Blank lines aren't necessary before a close brace '}'
#733: FILE: drivers/gpu/drm/kmb/kmb_drv.c:380:
+
+ }
-:774: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#774: FILE: drivers/gpu/drm/kmb/kmb_drv.c:421:
+ drm_info(>drm,
+ "!LAYER0:VL0 DMA UNDERFLOW val =
0x%lx,under_flow=%d",
-:787: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#787: FILE: drivers/gpu/drm/kmb/kmb_drv.c:434:
+
[Intel-gfx] [PATCH v5] Add support for KeemBay DRM driver
This is a new DRM driver for Intel's KeemBay SOC. The SoC couples an ARM Cortex A53 CPU with an Intel Movidius VPU. This driver is tested with the KMB EVM board which is the refernce baord for Keem Bay SOC. The SOC's display pipeline is as follows +--++-++---+ |LCD controller| -> |Mipi DSI | -> |Mipi to HDMI Converter | +--++-++---+ LCD controller and Mipi DSI transmitter are part of the SOC and mipi to HDMI converter is ADV7535 for KMB EVM board. The DRM driver is a basic KMS atomic modesetting display driver and has no 2D or 3D graphics.It calls into the ADV bridge driver at the connector level. Only 1080p resolution and single plane is supported at this time. The usecase is for debugging video and camera outputs. Device tree patches are under review here https://lore.kernel.org/linux-arm-kernel/20200708175020.194436-1-daniele.alessandre...@linux.intel.com/T / Changes since v1: - Removed redundant license text, updated license - Rearranged include blocks - renamed global vars and removed extern in c - Used upclassing for dev_private - Used drm_dev_init in drm device create - minor cleanups Changes since v2: - squashed all commits to a single commit - logging changed to drm_info, drm_dbg etc. - used devm_drm_dev_alloc() - removed commented out sections and general cleanup Changes since v3: - renamed dev_p to kmb - moved clocks under kmb_clock, consolidated clk initializations - use drmm functions - use DRM_GEM_CMA_DRIVER_OPS_VMAP - more cleanups Changes since v4: - corrected spellings Anitha Chrisanthus (1): drm/kmb: Add support for KeemBay Display drivers/gpu/drm/Kconfig |2 + drivers/gpu/drm/Makefile|1 + drivers/gpu/drm/kmb/Kconfig | 13 + drivers/gpu/drm/kmb/Makefile|2 + drivers/gpu/drm/kmb/kmb_crtc.c | 217 + drivers/gpu/drm/kmb/kmb_crtc.h | 36 + drivers/gpu/drm/kmb/kmb_drv.c | 728 drivers/gpu/drm/kmb/kmb_drv.h | 172 drivers/gpu/drm/kmb/kmb_dsi.c | 1834 +++ drivers/gpu/drm/kmb/kmb_dsi.h | 370 drivers/gpu/drm/kmb/kmb_plane.c | 518 +++ drivers/gpu/drm/kmb/kmb_plane.h | 124 +++ drivers/gpu/drm/kmb/kmb_regs.h | 738 13 files changed, 4755 insertions(+) create mode 100644 drivers/gpu/drm/kmb/Kconfig create mode 100644 drivers/gpu/drm/kmb/Makefile create mode 100644 drivers/gpu/drm/kmb/kmb_crtc.c create mode 100644 drivers/gpu/drm/kmb/kmb_crtc.h create mode 100644 drivers/gpu/drm/kmb/kmb_drv.c create mode 100644 drivers/gpu/drm/kmb/kmb_drv.h create mode 100644 drivers/gpu/drm/kmb/kmb_dsi.c create mode 100644 drivers/gpu/drm/kmb/kmb_dsi.h create mode 100644 drivers/gpu/drm/kmb/kmb_plane.c create mode 100644 drivers/gpu/drm/kmb/kmb_plane.h create mode 100644 drivers/gpu/drm/kmb/kmb_regs.h -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 34/60] drm/i915: introduce kernel blitter_context
+Chris Wilson
On Mon, Aug 3, 2020 at 12:59 PM Lucas De Marchi
wrote:
>
> On Fri, Jul 10, 2020 at 5:00 AM Matthew Auld wrote:
> >
> > We may be without a context to perform various internal blitter
> > operations, for example when performing object migration. Piggybacking
> > off the kernel_context is probably a bad idea, since it has other uses.
> >
> > Signed-off-by: Matthew Auld
> > Cc: Joonas Lahtinen
> > Cc: Abdiel Janulgue
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine_cs.c| 30 +---
> > drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
> > 2 files changed, 27 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index dd1a42c4d344..1df94e82550f 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -792,6 +792,7 @@ create_kernel_context(struct intel_engine_cs *engine)
> > int err;
> >
> > ce = intel_context_create(engine);
> > +
> > if (IS_ERR(ce))
> > return ce;
> >
> > @@ -845,16 +846,32 @@ static int engine_init_common(struct intel_engine_cs
> > *engine)
> > return PTR_ERR(ce);
> >
> > ret = measure_breadcrumb_dw(ce);
> > - if (ret < 0)
> > - goto err_context;
> > + if (ret < 0) {
> > + intel_context_put(ce);
>
> I think it's easier to follow the code if the error handling is in one
> place. Since you have to put the context.
> And since create_kernel_context() pins it, don't we have to
> intel_context_unpin() like we are doing
> in intel_engine_cleanup_common()? Which would also mean to probably
> factor out a `destroy_kernel_context()`
> to always do it, and call from here and from intel_engine_cleanup_common().
We actually had a destroy_kernel_context() and the unpin, but that got dropped
by e6ba76480299 ("drm/i915: Remove i915->kernel_context") .
Wouldn't we hit a GEM_BUG_ON() in the destroy function if we don't unpin it ?
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 34/60] drm/i915: introduce kernel blitter_context
On Fri, Jul 10, 2020 at 5:00 AM Matthew Auld wrote:
>
> We may be without a context to perform various internal blitter
> operations, for example when performing object migration. Piggybacking
> off the kernel_context is probably a bad idea, since it has other uses.
>
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Abdiel Janulgue
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c| 30 +---
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
> 2 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index dd1a42c4d344..1df94e82550f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -792,6 +792,7 @@ create_kernel_context(struct intel_engine_cs *engine)
> int err;
>
> ce = intel_context_create(engine);
> +
> if (IS_ERR(ce))
> return ce;
>
> @@ -845,16 +846,32 @@ static int engine_init_common(struct intel_engine_cs
> *engine)
> return PTR_ERR(ce);
>
> ret = measure_breadcrumb_dw(ce);
> - if (ret < 0)
> - goto err_context;
> + if (ret < 0) {
> + intel_context_put(ce);
I think it's easier to follow the code if the error handling is in one
place. Since you have to put the context.
And since create_kernel_context() pins it, don't we have to
intel_context_unpin() like we are doing
in intel_engine_cleanup_common()? Which would also mean to probably
factor out a `destroy_kernel_context()`
to always do it, and call from here and from intel_engine_cleanup_common().
Lucas De Marchi
> + return ret;
> + }
>
> engine->emit_fini_breadcrumb_dw = ret;
> engine->kernel_context = ce;
>
> + /*
> +* The blitter context is used to quickly memset or migrate objects
> +* in local memory, so it has to always be available.
> +*/
> + if (engine->class == COPY_ENGINE_CLASS) {
> + ce = create_kernel_context(engine);
> + if (IS_ERR(ce)) {
> + ret = PTR_ERR(ce);
> + goto err_kernel_context;
> + }
> +
> + engine->blitter_context = ce;
> + }
> +
> return 0;
>
> -err_context:
> - intel_context_put(ce);
> +err_kernel_context:
> + intel_context_put(engine->kernel_context);
> return ret;
> }
>
> @@ -910,6 +927,11 @@ void intel_engine_cleanup_common(struct intel_engine_cs
> *engine)
> if (engine->default_state)
> fput(engine->default_state);
>
> + if (engine->blitter_context) {
> + intel_context_unpin(engine->blitter_context);
> + intel_context_put(engine->blitter_context);
> + }
> +
> if (engine->kernel_context) {
> intel_context_unpin(engine->kernel_context);
> intel_context_put(engine->kernel_context);
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> index 490af81bd6f3..3b2d9ed7670f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -342,6 +342,7 @@ struct intel_engine_cs {
> struct llist_head barrier_tasks;
>
> struct intel_context *kernel_context; /* pinned */
> + struct intel_context *blitter_context; /* pinned; exists for BCS only
> */
>
> intel_engine_mask_t saturated; /* submitting semaphores too late? */
>
> --
> 2.26.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix wrong return value in intel_atomic_check()
On Mon, 2020-08-03 at 16:38 +, Patchwork wrote:
> Patch Details
> Series: drm/i915: Fix wrong return value in intel_atomic_check()
> URL: https://patchwork.freedesktop.org/series/80208/
> State:failure
> Details:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/index.html
> CI Bug Log - changes from CI_DRM_8834_full -> Patchwork_18299_full
> Summary
> FAILURE
>
> Serious unknown changes coming with Patchwork_18299_full absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_18299_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_18299_full:
>
> IGT changes
> Possible regressions
> igt@gem_mmap_gtt@fault-concurrent:
>
This regression is not related with this changes.Pushed to dinq, thanks for the
patch.
> shard-snb: PASS -> DMESG-WARN
> igt@runner@aborted:
>
> shard-snb: NOTRUN -> FAIL
> Known issues
> Here are the changes found in Patchwork_18299_full that come from known
> issues:
>
> IGT changes
> Issues hit
> igt@gen9_exec_parse@allowed-all:
>
> shard-apl: PASS -> DMESG-WARN (i915#1436 / i915#1635 / i915#716)
> igt@gen9_exec_parse@allowed-single:
>
> shard-skl: PASS -> INCOMPLETE (i915#1436 / i915#716)
> igt@i915_selftest@mock@contexts:
>
> shard-apl: PASS -> INCOMPLETE (i915#1635)
> igt@kms_big_fb@y-tiled-64bpp-rotate-0:
>
> shard-glk: PASS -> DMESG-FAIL (i915#118 / i915#95)
> igt@kms_cursor_edge_walk@pipe-c-256x256-bottom-edge:
>
> shard-skl: PASS -> DMESG-WARN (i915#1982) +14 similar issues
> igt@kms_flip@2x-plain-flip-ts-check@ab-hdmi-a1-hdmi-a2:
>
> shard-glk: PASS -> FAIL (i915#2122)
> igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible@a-dp1:
>
> shard-kbl: PASS -> DMESG-WARN (i915#1982)
> igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1:
>
> shard-skl: PASS -> FAIL (i915#2122)
> igt@kms_flip@flip-vs-suspend-interruptible@a-dp1:
>
> shard-kbl: PASS -> DMESG-WARN (i915#180) +5 similar issues
> igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-pwrite:
>
> shard-tglb: PASS -> DMESG-WARN (i915#1982) +4 similar issues
> igt@kms_hdr@bpc-switch:
>
> shard-skl: PASS -> FAIL (i915#1188)
> igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
>
> shard-iclb: PASS -> INCOMPLETE (i915#1185)
> igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
>
> shard-skl: PASS -> FAIL (fdo#108145 / i915#265) +1 similar issue
> igt@kms_psr2_su@frontbuffer:
>
> shard-iclb: PASS -> SKIP (fdo#109642 / fdo#111068) +1 similar issue
> igt@kms_psr@psr2_cursor_render:
>
> shard-iclb: PASS -> SKIP (fdo#109441) +3 similar issues
> igt@perf_pmu@module-unload:
>
> shard-iclb: PASS -> DMESG-WARN (i915#1982)
> Possible fixes
> {igt@feature_discovery@psr2}:
>
> shard-iclb: SKIP (i915#658) -> PASS
> igt@gem_exec_suspend@basic-s3:
>
> shard-skl: INCOMPLETE -> PASS
> igt@gem_mmap_gtt@fault-concurrent:
>
> shard-glk: DMESG-WARN (i915#2165) -> PASS
> igt@gem_partial_pwrite_pread@writes-after-reads-uncached:
>
> shard-apl: FAIL (i915#1635) -> PASS
> igt@gen9_exec_parse@allowed-all:
>
> shard-kbl: DMESG-WARN (i915#1436 / i915#716) -> PASS
> igt@i915_selftest@mock@requests:
>
> shard-skl: INCOMPLETE (i915#198) -> PASS
> igt@kms_big_fb@y-tiled-64bpp-rotate-180:
>
> shard-glk: DMESG-FAIL (i915#118 / i915#95) -> PASS
> igt@kms_big_fb@y-tiled-8bpp-rotate-180:
>
> shard-kbl: DMESG-WARN (i915#1982) -> PASS
> igt@kms_frontbuffer_tracking@fbc-suspend:
>
> shard-kbl: DMESG-WARN (i915#180) -> PASS +3 similar issues
> igt@kms_hdr@bpc-switch-suspend:
>
> shard-skl: FAIL (i915#1188) -> PASS
> igt@kms_plane@plane-panning-bottom-right-pipe-c-planes:
>
> shard-skl: DMESG-WARN (i915#1982) -> PASS +6 similar issues
> igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
>
> shard-glk: DMESG-WARN (i915#1982) -> PASS
> igt@kms_psr@psr2_primary_mmap_gtt:
>
> shard-iclb: SKIP (fdo#109441) -> PASS +1 similar issue
> igt@kms_setmode@basic:
>
> shard-kbl: FAIL (i915#31) -> PASS
> Warnings
> igt@gem_exec_reloc@basic-concurrent0:
>
> shard-apl: INCOMPLETE (i915#1635) -> FAIL (i915#1635 / i915#1930)
> igt@gem_exec_reloc@basic-spin-others@vcs0:
>
> shard-snb: WARN (i915#2021) -> WARN (i915#2036)
> igt@kms_content_protection@lic:
>
> shard-kbl: TIMEOUT (i915#1319) -> TIMEOUT (i915#1319 / i915#1958)
> igt@kms_content_protection@srm:
>
> shard-kbl: TIMEOUT (i915#1319 / i915#1958) -> TIMEOUT (i915#1319)
> igt@kms_dp_dsc@basic-dsc-enable-edp:
>
> shard-iclb: DMESG-WARN (i915#1226) -> SKIP (fdo#109349)
> igt@kms_flip@plain-flip-fb-recreate-interruptible@a-edp1:
>
> shard-skl: DMESG-WARN (i915#1982) -> DMESG-FAIL (i915#1982)
> igt@runner@aborted:
>
> shard-apl: FAIL (i915#1611 / i915#1635) -> (FAIL, FAIL) (fdo#109271 /
> i915#1635 / i915#2110 / i915#716)
> {name}: This element is suppressed. This means it is
Re: [Intel-gfx] [PATCH] drm/i915: Fix wrong return value in intel_atomic_check()
On Sun, 2020-08-02 at 19:15 +0800, Tianjia Zhang wrote:
> In the case of calling check_digital_port_conflicts() failed, a
> negative error code -EINVAL should be returned.
Reviewed-by: José Roberto de Souza
>
> Fixes: bf5da83e4bd80 ("drm/i915: Move check_digital_port_conflicts() earier")
> Cc: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
> Signed-off-by: Tianjia Zhang <
> tianjia.zh...@linux.alibaba.com
> >
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 26996e1839e2..9f3a7ef58aba 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14872,7 +14872,7 @@ static int intel_atomic_check(struct drm_device *dev,
> if (any_ms && !check_digital_port_conflicts(state)) {
> drm_dbg_kms(_priv->drm,
> "rejecting conflicting digital port
> configuration\n");
> - ret = EINVAL;
> + ret = -EINVAL;
> goto fail;
> }
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: add syncobj timeline support
On 03/08/2020 17:23, Chris Wilson wrote:
-enum drm_i915_gem_execbuffer_ext {
- /**
-* See drm_i915_gem_execbuf_ext_timeline_fences.
-*/
- DRM_I915_GEM_EXECBUFFER_EXT_TIMELINE_FENCES = 1,
-
- DRM_I915_GEM_EXECBUFFER_EXT_MAX /* non-ABI */
-};
+/**
+ * See drm_i915_gem_execbuffer_ext_timeline_fences.
+ */
+#define DRM_I915_GEM_EXECBUFFER_EXT_TIMELINE_FENCES 0
I was made to switch this from 0 to 1 just to make sure it's not a
inadvertently left to 0.
I can't remember if it was Jason or Daniel's suggestion.
-Lionel
___
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: Wa_1607138340
== Series Details == Series: drm/i915/tgl: Wa_1607138340 URL : https://patchwork.freedesktop.org/series/80210/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8834_full -> Patchwork_18301_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18301_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18301_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_18301_full: ### IGT changes ### Possible regressions * igt@gem_ctx_exec@basic-nohangcheck: - shard-tglb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/shard-tglb3/igt@gem_ctx_e...@basic-nohangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18301/shard-tglb7/igt@gem_ctx_e...@basic-nohangcheck.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: - shard-skl: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/shard-skl10/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-c.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18301/shard-skl2/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-c.html Known issues Here are the changes found in Patchwork_18301_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed-process@bsd: - shard-apl: [PASS][5] -> [FAIL][6] ([i915#1528] / [i915#1635]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/shard-apl3/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18301/shard-apl2/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd.html * igt@i915_pm_dc@dc6-psr: - shard-skl: [PASS][7] -> [FAIL][8] ([i915#454]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/shard-skl9/igt@i915_pm...@dc6-psr.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18301/shard-skl7/igt@i915_pm...@dc6-psr.html * igt@i915_selftest@mock@contexts: - shard-apl: [PASS][9] -> [INCOMPLETE][10] ([i915#1635]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/shard-apl3/igt@i915_selftest@m...@contexts.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18301/shard-apl4/igt@i915_selftest@m...@contexts.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-iclb: [PASS][11] -> [INCOMPLETE][12] ([i915#1185]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/shard-iclb2/igt@kms_cursor_...@pipe-a-cursor-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18301/shard-iclb3/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_edge_walk@pipe-c-256x256-bottom-edge: - shard-skl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +10 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/shard-skl3/igt@kms_cursor_edge_w...@pipe-c-256x256-bottom-edge.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18301/shard-skl6/igt@kms_cursor_edge_w...@pipe-c-256x256-bottom-edge.html * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-ytiled: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#1635] / [i915#1982]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/shard-apl2/igt@kms_draw_...@draw-method-xrgb2101010-mmap-wc-ytiled.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18301/shard-apl6/igt@kms_draw_...@draw-method-xrgb2101010-mmap-wc-ytiled.html * igt@kms_flip@flip-vs-expired-vblank@c-edp1: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#79]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/shard-skl8/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18301/shard-skl2/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1: - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +12 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/shard-kbl6/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18301/shard-kbl7/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-pwrite: - shard-tglb: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) +3 similar issues [21]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix wrong return value in intel_atomic_check()
== Series Details == Series: drm/i915: Fix wrong return value in intel_atomic_check() URL : https://patchwork.freedesktop.org/series/80208/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8834_full -> Patchwork_18299_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18299_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18299_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_18299_full: ### IGT changes ### Possible regressions * igt@gem_mmap_gtt@fault-concurrent: - shard-snb: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/shard-snb2/igt@gem_mmap_...@fault-concurrent.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/shard-snb2/igt@gem_mmap_...@fault-concurrent.html * igt@runner@aborted: - shard-snb: NOTRUN -> [FAIL][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/shard-snb2/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_18299_full that come from known issues: ### IGT changes ### Issues hit * igt@gen9_exec_parse@allowed-all: - shard-apl: [PASS][4] -> [DMESG-WARN][5] ([i915#1436] / [i915#1635] / [i915#716]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/shard-apl7/igt@gen9_exec_pa...@allowed-all.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/shard-apl6/igt@gen9_exec_pa...@allowed-all.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][6] -> [INCOMPLETE][7] ([i915#1436] / [i915#716]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/shard-skl9/igt@gen9_exec_pa...@allowed-single.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/shard-skl9/igt@gen9_exec_pa...@allowed-single.html * igt@i915_selftest@mock@contexts: - shard-apl: [PASS][8] -> [INCOMPLETE][9] ([i915#1635]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/shard-apl3/igt@i915_selftest@m...@contexts.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/shard-apl1/igt@i915_selftest@m...@contexts.html * igt@kms_big_fb@y-tiled-64bpp-rotate-0: - shard-glk: [PASS][10] -> [DMESG-FAIL][11] ([i915#118] / [i915#95]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/shard-glk9/igt@kms_big...@y-tiled-64bpp-rotate-0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-0.html * igt@kms_cursor_edge_walk@pipe-c-256x256-bottom-edge: - shard-skl: [PASS][12] -> [DMESG-WARN][13] ([i915#1982]) +14 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/shard-skl3/igt@kms_cursor_edge_w...@pipe-c-256x256-bottom-edge.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/shard-skl10/igt@kms_cursor_edge_w...@pipe-c-256x256-bottom-edge.html * igt@kms_flip@2x-plain-flip-ts-check@ab-hdmi-a1-hdmi-a2: - shard-glk: [PASS][14] -> [FAIL][15] ([i915#2122]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/shard-glk4/igt@kms_flip@2x-plain-flip-ts-ch...@ab-hdmi-a1-hdmi-a2.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/shard-glk4/igt@kms_flip@2x-plain-flip-ts-ch...@ab-hdmi-a1-hdmi-a2.html * igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible@a-dp1: - shard-kbl: [PASS][16] -> [DMESG-WARN][17] ([i915#1982]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/shard-kbl2/igt@kms_flip@flip-vs-absolute-wf_vblank-interrupti...@a-dp1.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/shard-kbl4/igt@kms_flip@flip-vs-absolute-wf_vblank-interrupti...@a-dp1.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1: - shard-skl: [PASS][18] -> [FAIL][19] ([i915#2122]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/shard-skl1/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/shard-skl5/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1: - shard-kbl: [PASS][20] -> [DMESG-WARN][21] ([i915#180]) +5 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/shard-kbl6/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/shard-kbl2/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html *
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/7] drm/i915/gem: Reduce context termination list iteration guard to RCU
== Series Details ==
Series: series starting with [1/7] drm/i915/gem: Reduce context termination
list iteration guard to RCU
URL : https://patchwork.freedesktop.org/series/80219/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8834 -> Patchwork_18303
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18303/index.html
Known issues
Here are the changes found in Patchwork_18303 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gem_contexts:
- fi-tgl-u2: [PASS][1] -> [INCOMPLETE][2] ([i915#2045])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18303/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][3] -> [DMESG-WARN][4] ([i915#62] / [i915#92] /
[i915#95])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18303/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
Possible fixes
* igt@i915_module_load@reload:
- fi-byt-j1900: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-byt-j1900/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18303/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18303/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@gt_lrc:
- fi-tgl-u2: [DMESG-FAIL][9] ([i915#1233]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18303/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18303/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [SKIP][13] ([fdo#109271]) -> [DMESG-FAIL][14]
([i915#62])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18303/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92]) ->
[DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95]) +8 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18303/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18303/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.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
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2045]: https://gitlab.freedesktop.org/drm/intel/issues/2045
[i915#2100]: https://gitlab.freedesktop.org/drm/intel/issues/2100
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (42 -> 37)
--
Additional (2): fi-ilk-650 fi-kbl-8809g
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8834 ->
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/7] drm/i915/gem: Reduce context termination list iteration guard to RCU
== Series Details == Series: series starting with [1/7] drm/i915/gem: Reduce context termination list iteration guard to RCU URL : https://patchwork.freedesktop.org/series/80219/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. ___ 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/7] drm/i915/gem: Reduce context termination list iteration guard to RCU
== Series Details ==
Series: series starting with [1/7] drm/i915/gem: Reduce context termination
list iteration guard to RCU
URL : https://patchwork.freedesktop.org/series/80219/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
378bbbd633f5 drm/i915/gem: Reduce context termination list iteration guard to
RCU
-:20: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#20:
References: d22d2d073ef8 ("drm/i915: Protect i915_request_await_start from
early waits") # rcu protection of timeline->requests
-:20: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit d22d2d073ef8 ("drm/i915: Protect
i915_request_await_start from early waits")'
#20:
References: d22d2d073ef8 ("drm/i915: Protect i915_request_await_start from
early waits") # rcu protection of timeline->requests
total: 1 errors, 1 warnings, 0 checks, 65 lines checked
0907f130be2f drm/i915/gt: Protect context lifetime with RCU
a85d94cf5fd3 drm/i915/gt: Free stale request on destroying the virtual engine
dca44c37f510 drm/i915/gt: Defer enabling the breadcrumb interrupt to after
submission
bcc8f0e9fe28 drm/i915/gt: Track signaled breadcrumbs outside of the breadcrumb
spinlock
ed0f0ed98c89 drm/i915/gt: Don't cancel the interrupt shadow too early
0c72915a565b drm/i915/gt: Split the breadcrumb spinlock between global and
contexts
-:339: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#339: FILE: drivers/gpu/drm/i915/gt/intel_context_types.h:54:
+ spinlock_t signal_lock;
total: 0 errors, 0 warnings, 1 checks, 293 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: timeline semaphore support (rev2)
== Series Details == Series: drm/i915: timeline semaphore support (rev2) URL : https://patchwork.freedesktop.org/series/80214/ State : failure == Summary == Applying: drm/i915: introduce a mechanism to extend execbuf2 Applying: drm/i915: add syncobj timeline support Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c M include/uapi/drm/i915_drm.h Falling back to patching base and 3-way merge... Auto-merging include/uapi/drm/i915_drm.h CONFLICT (content): Merge conflict in include/uapi/drm/i915_drm.h Auto-merging drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0002 drm/i915: add syncobj timeline support When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/7] drm/i915/gt: Track signaled breadcrumbs outside of the breadcrumb spinlock
Make b->signaled_requests a lockless-list so that we can manipulate it
outside of the b->irq_lock.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 28 +++
.../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 2 +-
drivers/gpu/drm/i915/i915_request.h | 6 +++-
3 files changed, 22 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index dee6d5c9b413..9710d09e7670 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -169,16 +169,13 @@ static void add_retire(struct intel_breadcrumbs *b,
struct intel_timeline *tl)
intel_engine_add_retire(b->irq_engine, tl);
}
-static bool __signal_request(struct i915_request *rq, struct list_head
*signals)
+static bool __signal_request(struct i915_request *rq)
{
- clear_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags);
-
if (!__dma_fence_signal(>fence)) {
i915_request_put(rq);
return false;
}
- list_add_tail(>signal_link, signals);
return true;
}
@@ -186,9 +183,13 @@ static void signal_irq_work(struct irq_work *work)
{
struct intel_breadcrumbs *b = container_of(work, typeof(*b), irq_work);
const ktime_t timestamp = ktime_get();
+ struct llist_node *signal, *sn;
struct intel_context *ce, *cn;
struct list_head *pos, *next;
- LIST_HEAD(signal);
+
+ signal = NULL;
+ if (unlikely(!llist_empty(>signaled_requests)))
+ signal = llist_del_all(>signaled_requests);
spin_lock(>irq_lock);
@@ -218,8 +219,6 @@ static void signal_irq_work(struct irq_work *work)
if (b->irq_armed && list_empty(>signalers))
__intel_breadcrumbs_disarm_irq(b);
- list_splice_init(>signaled_requests, );
-
list_for_each_entry_safe(ce, cn, >signalers, signal_link) {
GEM_BUG_ON(list_empty(>signals));
@@ -236,7 +235,11 @@ static void signal_irq_work(struct irq_work *work)
* spinlock as the callback chain may end up adding
* more signalers to the same context or engine.
*/
- __signal_request(rq, );
+ clear_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags);
+ if (__signal_request(rq)) {
+ rq->signal_node.next = signal;
+ signal = >signal_node;
+ }
}
/*
@@ -256,9 +259,9 @@ static void signal_irq_work(struct irq_work *work)
spin_unlock(>irq_lock);
- list_for_each_safe(pos, next, ) {
+ llist_for_each_safe(signal, sn, signal) {
struct i915_request *rq =
- list_entry(pos, typeof(*rq), signal_link);
+ llist_entry(signal, typeof(*rq), signal_node);
struct list_head cb_list;
spin_lock(>lock);
@@ -291,7 +294,7 @@ intel_breadcrumbs_create(struct intel_engine_cs *irq_engine)
spin_lock_init(>irq_lock);
INIT_LIST_HEAD(>signalers);
- INIT_LIST_HEAD(>signaled_requests);
+ init_llist_head(>signaled_requests);
init_irq_work(>irq_work, signal_irq_work);
@@ -346,7 +349,8 @@ static void insert_breadcrumb(struct i915_request *rq,
* its signal completion.
*/
if (__request_completed(rq)) {
- if (__signal_request(rq, >signaled_requests))
+ if (__signal_request(rq) &&
+ llist_add(>signal_node, >signaled_requests))
irq_work_queue(>irq_work);
return;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
index 8e53b9942695..3fa19820b37a 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
@@ -35,7 +35,7 @@ struct intel_breadcrumbs {
struct intel_engine_cs *irq_engine;
struct list_head signalers;
- struct list_head signaled_requests;
+ struct llist_head signaled_requests;
struct irq_work irq_work; /* for use from inside irq_lock */
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index 16b721080195..874af6db6103 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -176,7 +176,11 @@ struct i915_request {
struct intel_context *context;
struct intel_ring *ring;
struct intel_timeline __rcu *timeline;
- struct list_head signal_link;
+
+ union {
+ struct list_head signal_link;
+ struct llist_node signal_node;
+ };
/*
* The rcu epoch of when this request was allocated. Used to
[Intel-gfx] [PATCH 6/7] drm/i915/gt: Don't cancel the interrupt shadow too early
We currently want to keep the interrupt enabled until the interrupt after
which we have no more work to do. This heuristic was broken by us
kicking the irq-work on adding a completed request without attaching a
signaler -- hence it appearing to the irq-worker that an interrupt had
fired when we were idle.
Fixes: bda4d4db6dd6 ("drm/i915/gt: Replace
intel_engine_transfer_stale_breadcrumbs")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 9710d09e7670..ae8895b48eca 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -216,7 +216,7 @@ static void signal_irq_work(struct irq_work *work)
* interrupt draw less ire from other users of the system and tools
* like powertop.
*/
- if (b->irq_armed && list_empty(>signalers))
+ if (!signal && b->irq_armed && list_empty(>signalers))
__intel_breadcrumbs_disarm_irq(b);
list_for_each_entry_safe(ce, cn, >signalers, signal_link) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/7] drm/i915/gt: Free stale request on destroying the virtual engine
Since preempt-to-busy, we may unsubmit a request while it is still on
the HW and completes asynchronously. That means it may be retired and in
the process destroy the virtual engine (as the user has closed their
context), but that engine may still be holding onto the unsubmitted
compelted request. Therefore we need to potentially cleanup the old
request on destroying the virtual engine. We also have to keep the
virtual_engine alive until after the sibling's execlists_dequeue() have
finished peeking into the virtual engines, for which we serialise with
RCU.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 417f6b0c6c61..cb04bc5474be 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -180,6 +180,7 @@
#define EXECLISTS_REQUEST_SIZE 64 /* bytes */
struct virtual_engine {
+ struct rcu_head rcu;
struct intel_engine_cs base;
struct intel_context context;
@@ -5393,10 +5394,25 @@ static void virtual_context_destroy(struct kref *kref)
container_of(kref, typeof(*ve), context.ref);
unsigned int n;
- GEM_BUG_ON(!list_empty(virtual_queue(ve)));
- GEM_BUG_ON(ve->request);
GEM_BUG_ON(ve->context.inflight);
+ if (unlikely(ve->request)) {
+ struct i915_request *old;
+ unsigned long flags;
+
+ spin_lock_irqsave(>base.active.lock, flags);
+
+ old = fetch_and_zero(>request);
+ if (old) {
+ GEM_BUG_ON(!i915_request_completed(old));
+ __i915_request_submit(old);
+ i915_request_put(old);
+ }
+
+ spin_unlock_irqrestore(>base.active.lock, flags);
+ }
+ GEM_BUG_ON(!list_empty(virtual_queue(ve)));
+
for (n = 0; n < ve->num_siblings; n++) {
struct intel_engine_cs *sibling = ve->siblings[n];
struct rb_node *node = >nodes[sibling->id].rb;
@@ -5422,7 +5438,7 @@ static void virtual_context_destroy(struct kref *kref)
intel_engine_free_request_pool(>base);
kfree(ve->bonds);
- kfree(ve);
+ kfree_rcu(ve, rcu);
}
static void virtual_engine_initial_hint(struct virtual_engine *ve)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/7] drm/i915/gt: Protect context lifetime with RCU
Allow a brief period for continued access to a dead intel_context by
deferring the release of the struct until after an RCU grace period.
As we are using a dedicated slab cache for the contexts, we can defer
the release of the slab pages via RCU, with the caveat that individual
structs may be reused from the freelist within an RCU grace period. To
handle that, we have to avoid clearing members of the zombie struct.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.c | 330 +---
drivers/gpu/drm/i915/i915_active.c | 10 +
drivers/gpu/drm/i915/i915_active.h | 2 +
drivers/gpu/drm/i915/i915_utils.h | 7 +
4 files changed, 202 insertions(+), 147 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 52db2bde44a3..4e7924640ffa 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -22,7 +22,7 @@ static struct i915_global_context {
static struct intel_context *intel_context_alloc(void)
{
- return kmem_cache_zalloc(global.slab_ce, GFP_KERNEL);
+ return kmem_cache_alloc(global.slab_ce, GFP_KERNEL);
}
void intel_context_free(struct intel_context *ce)
@@ -30,6 +30,177 @@ void intel_context_free(struct intel_context *ce)
kmem_cache_free(global.slab_ce, ce);
}
+static int __context_pin_state(struct i915_vma *vma)
+{
+ unsigned int bias = i915_ggtt_pin_bias(vma) | PIN_OFFSET_BIAS;
+ int err;
+
+ err = i915_ggtt_pin(vma, 0, bias | PIN_HIGH);
+ if (err)
+ return err;
+
+ err = i915_active_acquire(>active);
+ if (err)
+ goto err_unpin;
+
+ /*
+* And mark it as a globally pinned object to let the shrinker know
+* it cannot reclaim the object until we release it.
+*/
+ i915_vma_make_unshrinkable(vma);
+ vma->obj->mm.dirty = true;
+
+ return 0;
+
+err_unpin:
+ i915_vma_unpin(vma);
+ return err;
+}
+
+static void __context_unpin_state(struct i915_vma *vma)
+{
+ i915_vma_make_shrinkable(vma);
+ i915_active_release(>active);
+ __i915_vma_unpin(vma);
+}
+
+static int __ring_active(struct intel_ring *ring)
+{
+ int err;
+
+ err = intel_ring_pin(ring);
+ if (err)
+ return err;
+
+ err = i915_active_acquire(>vma->active);
+ if (err)
+ goto err_pin;
+
+ return 0;
+
+err_pin:
+ intel_ring_unpin(ring);
+ return err;
+}
+
+static void __ring_retire(struct intel_ring *ring)
+{
+ i915_active_release(>vma->active);
+ intel_ring_unpin(ring);
+}
+
+__i915_active_call
+static void __intel_context_retire(struct i915_active *active)
+{
+ struct intel_context *ce = container_of(active, typeof(*ce), active);
+
+ CE_TRACE(ce, "retire runtime: { total:%lluns, avg:%lluns }\n",
+intel_context_get_total_runtime_ns(ce),
+intel_context_get_avg_runtime_ns(ce));
+
+ set_bit(CONTEXT_VALID_BIT, >flags);
+ if (ce->state)
+ __context_unpin_state(ce->state);
+
+ intel_timeline_unpin(ce->timeline);
+ __ring_retire(ce->ring);
+
+ intel_context_put(ce);
+}
+
+static int __intel_context_active(struct i915_active *active)
+{
+ struct intel_context *ce = container_of(active, typeof(*ce), active);
+ int err;
+
+ CE_TRACE(ce, "active\n");
+
+ intel_context_get(ce);
+
+ err = __ring_active(ce->ring);
+ if (err)
+ goto err_put;
+
+ err = intel_timeline_pin(ce->timeline);
+ if (err)
+ goto err_ring;
+
+ if (!ce->state)
+ return 0;
+
+ err = __context_pin_state(ce->state);
+ if (err)
+ goto err_timeline;
+
+ return 0;
+
+err_timeline:
+ intel_timeline_unpin(ce->timeline);
+err_ring:
+ __ring_retire(ce->ring);
+err_put:
+ intel_context_put(ce);
+ return err;
+}
+
+static void __intel_context_ctor(void *arg)
+{
+ struct intel_context *ce = arg;
+
+ INIT_LIST_HEAD(>signal_link);
+ INIT_LIST_HEAD(>signals);
+
+ atomic_set(>pin_count, 0);
+ mutex_init(>pin_mutex);
+
+ ce->active_count = 0;
+ i915_active_init(>active,
+__intel_context_active, __intel_context_retire);
+
+ ce->inflight = NULL;
+ ce->lrc_reg_state = NULL;
+ ce->lrc.desc = 0;
+}
+
+static void
+__intel_context_init(struct intel_context *ce, struct intel_engine_cs *engine)
+{
+ GEM_BUG_ON(!engine->cops);
+ GEM_BUG_ON(!engine->gt->vm);
+
+ kref_init(>ref);
+ i915_active_reinit(>active);
+ mutex_reinit(>pin_mutex);
+
+ ce->engine = engine;
+ ce->ops = engine->cops;
+ ce->sseu = engine->sseu;
+
+ ce->wa_bb_page = 0;
+ ce->flags = 0;
+ ce->tag = 0;
+
+ memset(>runtime, 0, sizeof(ce->runtime));
+
+
[Intel-gfx] [PATCH 7/7] drm/i915/gt: Split the breadcrumb spinlock between global and contexts
As we funnel more and more contexts into the breadcrumbs on an engine,
the hold time of b->irq_lock grows. As we may then contend with the
b->irq_lock during request submission, this increases the burden upon
the engine->active.lock and so directly impacts both our execution
latency and client latency. If we split the b->irq_lock by introducing a
per-context spinlock to manage the signalers within a context, we then
only need the b->irq_lock for enabling/disabling the interrupt and can
avoid taking the lock for walking the list of contexts within the signal
worker. Even with the current setup, this greatly reduces the number of
times we have to take and fight for b->irq_lock.
Fixes: bda4d4db6dd6 ("drm/i915/gt: Replace
intel_engine_transfer_stale_breadcrumbs")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 157 ++
.../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 6 +-
drivers/gpu/drm/i915/gt/intel_context.c | 1 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 1 +
4 files changed, 89 insertions(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index ae8895b48eca..8802b47fbd8f 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -100,15 +100,16 @@ static void __intel_breadcrumbs_disarm_irq(struct
intel_breadcrumbs *b)
static void add_signaling_context(struct intel_breadcrumbs *b,
struct intel_context *ce)
{
- intel_context_get(ce);
- list_add_tail(>signal_link, >signalers);
+ lockdep_assert_held(>signalers_lock);
+ list_add_rcu(>signal_link, >signalers);
}
static void remove_signaling_context(struct intel_breadcrumbs *b,
struct intel_context *ce)
{
- list_del(>signal_link);
- intel_context_put(ce);
+ spin_lock(>signalers_lock);
+ list_del_rcu(>signal_link);
+ spin_unlock(>signalers_lock);
}
static inline bool __request_completed(const struct i915_request *rq)
@@ -184,15 +185,12 @@ static void signal_irq_work(struct irq_work *work)
struct intel_breadcrumbs *b = container_of(work, typeof(*b), irq_work);
const ktime_t timestamp = ktime_get();
struct llist_node *signal, *sn;
- struct intel_context *ce, *cn;
- struct list_head *pos, *next;
+ struct intel_context *ce;
signal = NULL;
if (unlikely(!llist_empty(>signaled_requests)))
signal = llist_del_all(>signaled_requests);
- spin_lock(>irq_lock);
-
/*
* Keep the irq armed until the interrupt after all listeners are gone.
*
@@ -216,11 +214,23 @@ static void signal_irq_work(struct irq_work *work)
* interrupt draw less ire from other users of the system and tools
* like powertop.
*/
- if (!signal && b->irq_armed && list_empty(>signalers))
- __intel_breadcrumbs_disarm_irq(b);
+ if (!signal && READ_ONCE(b->irq_armed) && list_empty(>signalers)) {
+ spin_lock(>irq_lock);
+ if (b->irq_armed)
+ __intel_breadcrumbs_disarm_irq(b);
+ spin_unlock(>irq_lock);
+ }
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(ce, >signalers, signal_link) {
+ struct list_head *pos, *next;
+ bool release = false;
- list_for_each_entry_safe(ce, cn, >signalers, signal_link) {
- GEM_BUG_ON(list_empty(>signals));
+ if (!spin_trylock(>signal_lock))
+ continue;
+
+ if (list_empty(>signals))
+ goto unlock;
list_for_each_safe(pos, next, >signals) {
struct i915_request *rq =
@@ -253,11 +263,16 @@ static void signal_irq_work(struct irq_work *work)
if (>signals == pos) { /* now empty */
add_retire(b, ce->timeline);
remove_signaling_context(b, ce);
+ release = true;
}
}
- }
- spin_unlock(>irq_lock);
+unlock:
+ spin_unlock(>signal_lock);
+ if (release)
+ intel_context_put(ce);
+ }
+ rcu_read_unlock();
llist_for_each_safe(signal, sn, signal) {
struct i915_request *rq =
@@ -292,14 +307,15 @@ intel_breadcrumbs_create(struct intel_engine_cs
*irq_engine)
if (!b)
return NULL;
- spin_lock_init(>irq_lock);
+ b->irq_engine = irq_engine;
+
+ spin_lock_init(>signalers_lock);
INIT_LIST_HEAD(>signalers);
init_llist_head(>signaled_requests);
+ spin_lock_init(>irq_lock);
init_irq_work(>irq_work, signal_irq_work);
- b->irq_engine = irq_engine;
-
[Intel-gfx] [PATCH 4/7] drm/i915/gt: Defer enabling the breadcrumb interrupt to after submission
Move the register slow register write and readback from out of the
critical path for execlists submission and delay it until the following
worker, shaving off around 200us. Note that the same signal_irq_work() is
allowed to run concurrently on each CPU (but it will only be queued once,
once running though it can be requeued and reexecuted) so we have to
remember to lock the global interactions as we cannot rely on the
signal_irq_work() itself providing the serialisation (in constrast to a
tasklet).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 72 ++---
drivers/gpu/drm/i915/gt/intel_engine_pm.h | 5 ++
2 files changed, 52 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index d8b206e53660..dee6d5c9b413 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -30,6 +30,7 @@
#include "i915_trace.h"
#include "intel_breadcrumbs.h"
#include "intel_context.h"
+#include "intel_engine_pm.h"
#include "intel_gt_pm.h"
#include "intel_gt_requests.h"
@@ -57,12 +58,10 @@ static void irq_disable(struct intel_engine_cs *engine)
static void __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
{
- lockdep_assert_held(>irq_lock);
-
- if (!b->irq_engine || b->irq_armed)
+ if (!b->irq_engine)
return;
- if (!intel_gt_pm_get_if_awake(b->irq_engine->gt))
+ if (GEM_WARN_ON(!intel_gt_pm_get_if_awake(b->irq_engine->gt)))
return;
/*
@@ -83,15 +82,13 @@ static void __intel_breadcrumbs_arm_irq(struct
intel_breadcrumbs *b)
if (!b->irq_enabled++)
irq_enable(b->irq_engine);
+
+ /* Requests may have completed before we could enable the interrupt. */
+ irq_work_queue(>irq_work);
}
static void __intel_breadcrumbs_disarm_irq(struct intel_breadcrumbs *b)
{
- lockdep_assert_held(>irq_lock);
-
- if (!b->irq_engine || !b->irq_armed)
- return;
-
GEM_BUG_ON(!b->irq_enabled);
if (!--b->irq_enabled)
irq_disable(b->irq_engine);
@@ -105,8 +102,6 @@ static void add_signaling_context(struct intel_breadcrumbs
*b,
{
intel_context_get(ce);
list_add_tail(>signal_link, >signalers);
- if (list_is_first(>signal_link, >signalers))
- __intel_breadcrumbs_arm_irq(b);
}
static void remove_signaling_context(struct intel_breadcrumbs *b,
@@ -197,7 +192,30 @@ static void signal_irq_work(struct irq_work *work)
spin_lock(>irq_lock);
- if (list_empty(>signalers))
+ /*
+* Keep the irq armed until the interrupt after all listeners are gone.
+*
+* Enabling/disabling the interrupt is rather costly, roughly a couple
+* of hundred microseconds. If we are proactive and enable/disable
+* the interrupt around every request that wants a breadcrumb, we
+* quickly drown in the extra orders of magnitude of latency imposed
+* on request submission.
+*
+* So we try to be lazy, and keep the interrupts enabled until no
+* more listeners appear within a breadcrumb interrupt interval (that
+* is until a request completes that no one cares about). The
+* observation is that listeners come in batches, and will often
+* listen to a bunch of requests in succession.
+*
+* We also try to avoid raising too many interrupts, as they may
+* be generated by userspace batches and it is unfortunately rather
+* too easy to drown the CPU under a flood of GPU interrupts. Thus
+* whenever no one appears to be listening, we turn off the interrupts.
+* Fewer interrupts should conserve power -- at the very least, fewer
+* interrupt draw less ire from other users of the system and tools
+* like powertop.
+*/
+ if (b->irq_armed && list_empty(>signalers))
__intel_breadcrumbs_disarm_irq(b);
list_splice_init(>signaled_requests, );
@@ -251,6 +269,15 @@ static void signal_irq_work(struct irq_work *work)
i915_request_put(rq);
}
+
+ if (!READ_ONCE(b->irq_armed) && !list_empty(>signalers)) {
+ spin_lock(>irq_lock);
+ if (!b->irq_armed)
+ __intel_breadcrumbs_arm_irq(b);
+ spin_unlock(>irq_lock);
+ }
+ if (READ_ONCE(b->irq_armed) && intel_engine_is_parking(b->irq_engine))
+ irq_work_queue(>irq_work); /* flush the signalers */
}
struct intel_breadcrumbs *
@@ -292,16 +319,8 @@ void intel_breadcrumbs_reset(struct intel_breadcrumbs *b)
void intel_breadcrumbs_park(struct intel_breadcrumbs *b)
{
- unsigned long flags;
-
- if (!READ_ONCE(b->irq_armed))
- return;
-
- spin_lock_irqsave(>irq_lock, flags);
-
[Intel-gfx] [PATCH 1/7] drm/i915/gem: Reduce context termination list iteration guard to RCU
As we now protect the timeline list using RCU, we can drop the
timeline->mutex for guarding the list iteration during context close, as
we are searching for an inflight request. Any new request will see the
context is banned and not be submitted. In doing so, pull the checks for
a concurrent submission of the request (notably the
i915_request_completed()) under the engine spinlock, to fully serialise
with __i915_request_submit()). That is in the case of preempt-to-busy
where the request may be completed during the __i915_request_submit(),
we need to be careful that we sample the request status after
serialising so that we don't miss the request the engine is actually
submitting.
Fixes: 4a3174152147 ("drm/i915/gem: Refine occupancy test in kill_context()")
References: d22d2d073ef8 ("drm/i915: Protect i915_request_await_start from
early waits") # rcu protection of timeline->requests
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1622
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 32 -
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index d8cccbab7a51..db893f6c516b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -439,29 +439,36 @@ static bool __cancel_engine(struct intel_engine_cs
*engine)
return __reset_engine(engine);
}
-static struct intel_engine_cs *__active_engine(struct i915_request *rq)
+static bool
+__active_engine(struct i915_request *rq, struct intel_engine_cs **active)
{
struct intel_engine_cs *engine, *locked;
+ bool ret = false;
/*
* Serialise with __i915_request_submit() so that it sees
* is-banned?, or we know the request is already inflight.
+*
+* Note that rq->engine is unstable, and so we double
+* check that we have acquired the lock on the final engine.
*/
locked = READ_ONCE(rq->engine);
spin_lock_irq(>active.lock);
while (unlikely(locked != (engine = READ_ONCE(rq->engine {
spin_unlock(>active.lock);
- spin_lock(>active.lock);
locked = engine;
+ spin_lock(>active.lock);
}
- engine = NULL;
- if (i915_request_is_active(rq) && rq->fence.error != -EIO)
- engine = rq->engine;
+ if (!i915_request_completed(rq)) {
+ if (i915_request_is_active(rq) && rq->fence.error != -EIO)
+ *active = locked;
+ ret = true;
+ }
spin_unlock_irq(>active.lock);
- return engine;
+ return ret;
}
static struct intel_engine_cs *active_engine(struct intel_context *ce)
@@ -472,17 +479,16 @@ static struct intel_engine_cs *active_engine(struct
intel_context *ce)
if (!ce->timeline)
return NULL;
- mutex_lock(>timeline->mutex);
- list_for_each_entry_reverse(rq, >timeline->requests, link) {
- if (i915_request_completed(rq))
- break;
+ rcu_read_lock();
+ list_for_each_entry_rcu(rq, >timeline->requests, link) {
+ if (i915_request_is_active(rq) && i915_request_completed(rq))
+ continue;
/* Check with the backend if the request is inflight */
- engine = __active_engine(rq);
- if (engine)
+ if (__active_engine(rq, ))
break;
}
- mutex_unlock(>timeline->mutex);
+ rcu_read_unlock();
return engine;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: add syncobj timeline support
This is the bunch of trivial changes that I had wanted.
- stop arbitrarily limiting the uABI to a single extension block
- handle timeline syncobj as an extension of binary syncobj
- num_fences to appease Tvrtko who objects to me calling things nobject
- the only way not to have ABI values is never to expose them in the uABI
- fix cross-reference
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 337 +-
include/uapi/drm/i915_drm.h | 15 +-
2 files changed, 180 insertions(+), 172 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 1f766431f3a3..9ce114d67288 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -223,6 +223,13 @@ struct eb_vma_array {
* the batchbuffer in trusted mode, otherwise the ioctl is rejected.
*/
+struct eb_fence {
+ struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
+ struct dma_fence *dma_fence;
+ u64 value;
+ struct dma_fence_chain *chain_fence;
+};
+
struct i915_execbuffer {
struct drm_i915_private *i915; /** i915 backpointer */
struct drm_file *file; /** per-file lookup tables and limits */
@@ -283,14 +290,8 @@ struct i915_execbuffer {
struct hlist_head *buckets; /** ht for relocation handles */
struct eb_vma_array *array;
- struct i915_eb_fence {
- struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
- u64 value;
- struct dma_fence_chain *chain_fence;
- } *fences;
- u32 n_fences;
-
- u64 extension_flags; /** Available extensions parameters */
+ struct eb_fence *fences;
+ unsigned long num_fences;
};
static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
@@ -2200,186 +2201,222 @@ eb_pin_engine(struct i915_execbuffer *eb,
}
static void
-__free_fence_array(struct i915_eb_fence *fences, unsigned int n)
+__free_fence_array(struct eb_fence *fences, unsigned int n)
{
while (n--) {
drm_syncobj_put(ptr_mask_bits(fences[n].syncobj, 2));
+ dma_fence_put(fences[n].dma_fence);
kfree(fences[n].chain_fence);
}
kvfree(fences);
}
static int
-get_timeline_fence_array(const struct
drm_i915_gem_execbuffer_ext_timeline_fences *timeline_fences,
-struct i915_execbuffer *eb)
+add_timeline_fence_array(struct i915_execbuffer *eb,
+const struct
drm_i915_gem_execbuffer_ext_timeline_fences *timeline_fences)
{
struct drm_i915_gem_exec_fence __user *user_fences;
- struct i915_eb_fence *fences;
u64 __user *user_values;
- u64 num_fences, num_user_fences = timeline_fences->fence_count;
- unsigned long n;
- int err;
+ struct eb_fence *f;
+ u64 nfences;
+ int err = 0;
+
+ nfences = timeline_fences->fence_count;
+ if (!nfences)
+ return 0;
/* Check multiplication overflow for access_ok() and kvmalloc_array() */
BUILD_BUG_ON(sizeof(size_t) > sizeof(unsigned long));
- if (num_user_fences > min_t(unsigned long,
- ULONG_MAX / sizeof(*user_fences),
- SIZE_MAX / sizeof(*fences)))
+ if (nfences > min_t(unsigned long,
+ ULONG_MAX / sizeof(*user_fences),
+ SIZE_MAX / sizeof(*f)) - eb->num_fences)
return -EINVAL;
user_fences = u64_to_user_ptr(timeline_fences->handles_ptr);
- if (!access_ok(user_fences, num_user_fences * sizeof(*user_fences)))
+ if (!access_ok(user_fences, nfences * sizeof(*user_fences)))
return -EFAULT;
user_values = u64_to_user_ptr(timeline_fences->values_ptr);
- if (!access_ok(user_values, num_user_fences * sizeof(*user_values)))
+ if (!access_ok(user_values, nfences * sizeof(*user_values)))
return -EFAULT;
- fences = kvmalloc_array(num_user_fences, sizeof(*fences),
- __GFP_NOWARN | GFP_KERNEL);
- if (!fences)
+ f = krealloc(eb->fences,
+(eb->num_fences + nfences) * sizeof(*f),
+__GFP_NOWARN | GFP_KERNEL);
+ if (!f)
return -ENOMEM;
+ eb->fences = f;
+ f += eb->num_fences;
+
BUILD_BUG_ON(~(ARCH_KMALLOC_MINALIGN - 1) &
~__I915_EXEC_FENCE_UNKNOWN_FLAGS);
- for (n = 0, num_fences = 0; n < timeline_fences->fence_count; n++) {
- struct drm_i915_gem_exec_fence fence;
+ while (nfences--) {
+ struct drm_i915_gem_exec_fence user_fence;
struct drm_syncobj *syncobj;
+ struct dma_fence *fence = NULL;
u64 point;
- if (__copy_from_user(, user_fences++,
Re: [Intel-gfx] [PATCH 3/3] drm/i915: peel dma-fence-chains wait fences
On 03/08/2020 17:08, Chris Wilson wrote: Quoting Lionel Landwerlin (2020-08-03 15:01:47) To allow faster engine to engine synchronization, peel the layer of dma-fence-chain to expose potential i915 fences so that the i915-request code can emit HW semaphore wait/signal operations in the ring which is faster than waking up the host to submit unblocked workloads after interrupt notification. v2: Also deal with chains where the last node is not a dma-fence-chain This is already done by i915_request_await_dma_fence. -Chris Cool, we can drop this then. -Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: peel dma-fence-chains wait fences
Quoting Lionel Landwerlin (2020-08-03 15:01:47) > To allow faster engine to engine synchronization, peel the layer of > dma-fence-chain to expose potential i915 fences so that the > i915-request code can emit HW semaphore wait/signal operations in the > ring which is faster than waking up the host to submit unblocked > workloads after interrupt notification. > > v2: Also deal with chains where the last node is not a dma-fence-chain This is already done by i915_request_await_dma_fence. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: introduce a mechanism to extend execbuf2
We're planning to use this for a couple of new feature where we need
to provide additional parameters to execbuf.
v2: Check for invalid flags in execbuffer2 (Lionel)
v3: Rename I915_EXEC_EXT -> I915_EXEC_USE_EXTENSIONS (Chris)
v4: Rebase
Move array fence parsing in i915_gem_do_execbuffer()
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson (v1)
Reviewed-by: Daniel Vetter
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 131 +++---
include/uapi/drm/i915_drm.h | 26 +++-
2 files changed, 103 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 07cb2dd0f795..ed8d1c2517f6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -26,6 +26,7 @@
#include "i915_gem_ioctls.h"
#include "i915_sw_fence_work.h"
#include "i915_trace.h"
+#include "i915_user_extensions.h"
struct eb_vma {
struct i915_vma *vma;
@@ -281,6 +282,13 @@ struct i915_execbuffer {
int lut_size;
struct hlist_head *buckets; /** ht for relocation handles */
struct eb_vma_array *array;
+
+ struct i915_eb_fence {
+ struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
+ } *fences;
+ u32 n_fences;
+
+ u64 extension_flags; /** Available extensions parameters */
};
static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
@@ -1622,7 +1630,8 @@ static int i915_gem_check_execbuffer(struct
drm_i915_gem_execbuffer2 *exec)
return -EINVAL;
/* Kernel clipping was a DRI1 misfeature */
- if (!(exec->flags & I915_EXEC_FENCE_ARRAY)) {
+ if (!(exec->flags & (I915_EXEC_FENCE_ARRAY |
+I915_EXEC_USE_EXTENSIONS))) {
if (exec->num_cliprects || exec->cliprects_ptr)
return -EINVAL;
}
@@ -2189,41 +2198,41 @@ eb_pin_engine(struct i915_execbuffer *eb,
}
static void
-__free_fence_array(struct drm_syncobj **fences, unsigned int n)
+__free_fence_array(struct i915_eb_fence *fences, unsigned int n)
{
while (n--)
- drm_syncobj_put(ptr_mask_bits(fences[n], 2));
+ drm_syncobj_put(ptr_mask_bits(fences[n].syncobj, 2));
kvfree(fences);
}
-static struct drm_syncobj **
+static int
get_fence_array(struct drm_i915_gem_execbuffer2 *args,
- struct drm_file *file)
+ struct i915_execbuffer *eb)
{
const unsigned long nfences = args->num_cliprects;
struct drm_i915_gem_exec_fence __user *user;
- struct drm_syncobj **fences;
+ struct i915_eb_fence *fences;
unsigned long n;
int err;
if (!(args->flags & I915_EXEC_FENCE_ARRAY))
- return NULL;
+ return 0;
/* Check multiplication overflow for access_ok() and kvmalloc_array() */
BUILD_BUG_ON(sizeof(size_t) > sizeof(unsigned long));
if (nfences > min_t(unsigned long,
ULONG_MAX / sizeof(*user),
SIZE_MAX / sizeof(*fences)))
- return ERR_PTR(-EINVAL);
+ return -EINVAL;
user = u64_to_user_ptr(args->cliprects_ptr);
if (!access_ok(user, nfences * sizeof(*user)))
- return ERR_PTR(-EFAULT);
+ return -EFAULT;
fences = kvmalloc_array(nfences, sizeof(*fences),
__GFP_NOWARN | GFP_KERNEL);
if (!fences)
- return ERR_PTR(-ENOMEM);
+ return -ENOMEM;
for (n = 0; n < nfences; n++) {
struct drm_i915_gem_exec_fence fence;
@@ -2239,7 +2248,7 @@ get_fence_array(struct drm_i915_gem_execbuffer2 *args,
goto err;
}
- syncobj = drm_syncobj_find(file, fence.handle);
+ syncobj = drm_syncobj_find(eb->file, fence.handle);
if (!syncobj) {
DRM_DEBUG("Invalid syncobj handle provided\n");
err = -ENOENT;
@@ -2249,38 +2258,31 @@ get_fence_array(struct drm_i915_gem_execbuffer2 *args,
BUILD_BUG_ON(~(ARCH_KMALLOC_MINALIGN - 1) &
~__I915_EXEC_FENCE_UNKNOWN_FLAGS);
- fences[n] = ptr_pack_bits(syncobj, fence.flags, 2);
+ fences[n].syncobj = ptr_pack_bits(syncobj, fence.flags, 2);
}
- return fences;
+ eb->fences = fences;
+ eb->n_fences = nfences;
+
+ return 0;
err:
__free_fence_array(fences, n);
- return ERR_PTR(err);
-}
-
-static void
-put_fence_array(struct drm_i915_gem_execbuffer2 *args,
- struct drm_syncobj **fences)
-{
- if (fences)
- __free_fence_array(fences, args->num_cliprects);
+ return err;
}
static int
-await_fence_array(struct i915_execbuffer *eb,
-
[Intel-gfx] [PATCH 3/3] drm/i915: peel dma-fence-chains wait fences
To allow faster engine to engine synchronization, peel the layer of
dma-fence-chain to expose potential i915 fences so that the
i915-request code can emit HW semaphore wait/signal operations in the
ring which is faster than waking up the host to submit unblocked
workloads after interrupt notification.
v2: Also deal with chains where the last node is not a dma-fence-chain
Signed-off-by: Lionel Landwerlin
Reviewed-by: Daniel Vetter
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 39 ++-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 1f766431f3a3..dbd7f03c2187 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2390,6 +2390,7 @@ await_fence_array(struct i915_execbuffer *eb)
for (n = 0; n < eb->n_fences; n++) {
struct drm_syncobj *syncobj;
+ struct dma_fence_chain *chain;
struct dma_fence *fence;
unsigned int flags;
@@ -2410,7 +2411,43 @@ await_fence_array(struct i915_execbuffer *eb)
continue;
}
- err = i915_request_await_dma_fence(eb->request, fence);
+ chain = to_dma_fence_chain(fence);
+ if (chain) {
+ struct dma_fence *iter;
+
+ /*
+* If we're dealing with a dma-fence-chain, peel the
+* chain by adding all of the unsignaled fences
+* (dma_fence_chain_for_each does that for us) the
+* chain points to.
+*
+* This enables us to identify waits on i915 fences
+* and allows for faster engine-to-engine
+* synchronization using HW semaphores.
+*/
+ dma_fence_chain_for_each(iter, fence) {
+ struct dma_fence_chain *iter_chain =
+ to_dma_fence_chain(iter);
+
+ /*
+* It is possible that the last item in the
+* chain is not a dma_fence_chain.
+*/
+ if (iter_chain) {
+ err =
i915_request_await_dma_fence(eb->request,
+
iter_chain->fence);
+ } else {
+ err =
i915_request_await_dma_fence(eb->request, iter);
+ }
+ if (err < 0) {
+ dma_fence_put(iter);
+ break;
+ }
+ }
+ } else {
+ err = i915_request_await_dma_fence(eb->request, fence);
+ }
+
dma_fence_put(fence);
if (err < 0)
return err;
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] drm/i915: timeline semaphore support
Hi all, Hopefully last CI run with the IGT tests :) Test-with: 20200803135851.316355-1-lionel.g.landwer...@intel.com Cheers, Lionel Landwerlin (3): drm/i915: introduce a mechanism to extend execbuf2 drm/i915: add syncobj timeline support drm/i915: peel dma-fence-chains wait fences .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 333 +++--- drivers/gpu/drm/i915/i915_drv.c | 3 +- drivers/gpu/drm/i915/i915_getparam.c | 1 + include/uapi/drm/i915_drm.h | 65 +++- 4 files changed, 342 insertions(+), 60 deletions(-) -- 2.28.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: add syncobj timeline support
Introduces a new parameters to execbuf so that we can specify syncobj
handles as well as timeline points.
v2: Reuse i915_user_extension_fn
v3: Check that the chained extension is only present once (Chris)
v4: Check that dma_fence_chain_find_seqno returns a non NULL fence (Lionel)
v5: Use BIT_ULL (Chris)
v6: Fix issue with already signaled timeline points,
dma_fence_chain_find_seqno() setting fence to NULL (Chris)
v7: Report ENOENT with invalid syncobj handle (Lionel)
v8: Check for out of order timeline point insertion (Chris)
v9: After explanations on
https://lists.freedesktop.org/archives/dri-devel/2019-August/229287.html
drop the ordering check from v8 (Lionel)
v10: Set first extension enum item to 1 (Jason)
v11: Rebase
Signed-off-by: Lionel Landwerlin
Reviewed-by: Daniel Vetter
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 167 +-
drivers/gpu/drm/i915/i915_drv.c | 3 +-
drivers/gpu/drm/i915/i915_getparam.c | 1 +
include/uapi/drm/i915_drm.h | 39
4 files changed, 203 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index ed8d1c2517f6..1f766431f3a3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -285,6 +285,8 @@ struct i915_execbuffer {
struct i915_eb_fence {
struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
+ u64 value;
+ struct dma_fence_chain *chain_fence;
} *fences;
u32 n_fences;
@@ -2200,14 +2202,121 @@ eb_pin_engine(struct i915_execbuffer *eb,
static void
__free_fence_array(struct i915_eb_fence *fences, unsigned int n)
{
- while (n--)
+ while (n--) {
drm_syncobj_put(ptr_mask_bits(fences[n].syncobj, 2));
+ kfree(fences[n].chain_fence);
+ }
kvfree(fences);
}
static int
-get_fence_array(struct drm_i915_gem_execbuffer2 *args,
- struct i915_execbuffer *eb)
+get_timeline_fence_array(const struct
drm_i915_gem_execbuffer_ext_timeline_fences *timeline_fences,
+struct i915_execbuffer *eb)
+{
+ struct drm_i915_gem_exec_fence __user *user_fences;
+ struct i915_eb_fence *fences;
+ u64 __user *user_values;
+ u64 num_fences, num_user_fences = timeline_fences->fence_count;
+ unsigned long n;
+ int err;
+
+ /* Check multiplication overflow for access_ok() and kvmalloc_array() */
+ BUILD_BUG_ON(sizeof(size_t) > sizeof(unsigned long));
+ if (num_user_fences > min_t(unsigned long,
+ ULONG_MAX / sizeof(*user_fences),
+ SIZE_MAX / sizeof(*fences)))
+ return -EINVAL;
+
+ user_fences = u64_to_user_ptr(timeline_fences->handles_ptr);
+ if (!access_ok(user_fences, num_user_fences * sizeof(*user_fences)))
+ return -EFAULT;
+
+ user_values = u64_to_user_ptr(timeline_fences->values_ptr);
+ if (!access_ok(user_values, num_user_fences * sizeof(*user_values)))
+ return -EFAULT;
+
+ fences = kvmalloc_array(num_user_fences, sizeof(*fences),
+ __GFP_NOWARN | GFP_KERNEL);
+ if (!fences)
+ return -ENOMEM;
+
+ BUILD_BUG_ON(~(ARCH_KMALLOC_MINALIGN - 1) &
+~__I915_EXEC_FENCE_UNKNOWN_FLAGS);
+
+ for (n = 0, num_fences = 0; n < timeline_fences->fence_count; n++) {
+ struct drm_i915_gem_exec_fence fence;
+ struct drm_syncobj *syncobj;
+ u64 point;
+
+ if (__copy_from_user(, user_fences++, sizeof(fence))) {
+ err = -EFAULT;
+ goto err;
+ }
+
+ if (fence.flags & __I915_EXEC_FENCE_UNKNOWN_FLAGS) {
+ err = -EINVAL;
+ goto err;
+ }
+
+ if (__get_user(point, user_values++)) {
+ err = -EFAULT;
+ goto err;
+ }
+
+ syncobj = drm_syncobj_find(eb->file, fence.handle);
+ if (!syncobj) {
+ DRM_DEBUG("Invalid syncobj handle provided\n");
+ err = -ENOENT;
+ goto err;
+ }
+
+ /*
+* For timeline syncobjs we need to preallocate chains for
+* later signaling.
+*/
+ if (point != 0 && fence.flags & I915_EXEC_FENCE_SIGNAL) {
+ /*
+* Waiting and signaling the same point (when point !=
+* 0) would break the timeline.
+*/
+ if (fence.flags & I915_EXEC_FENCE_WAIT) {
+ DRM_DEBUG("Tring
[Intel-gfx] [PATCH i-g-t] i915/gem_exec_schedule: Try to spot unfairness
An important property for multi-client systems is that each client gets
a 'fair' allotment of system time. (Where fairness is at the whim of the
context properties, such as priorities.) This test forks N independent
clients (albeit they happen to share a single vm), and does an equal
amount of work in client and asserts that they take an equal amount of
time.
Though we have never claimed to have a completely fair scheduler, that
is what is expected.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Ramalingam C
---
tests/i915/gem_exec_schedule.c | 816 +
1 file changed, 816 insertions(+)
diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 488d93511..7c8ea6d70 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2503,6 +2504,800 @@ static void measure_semaphore_power(int i915)
rapl_close();
}
+static int read_timestamp_frequency(int i915)
+{
+ int value = 0;
+ drm_i915_getparam_t gp = {
+ .value = ,
+ .param = I915_PARAM_CS_TIMESTAMP_FREQUENCY,
+ };
+ ioctl(i915, DRM_IOCTL_I915_GETPARAM, );
+ return value;
+}
+
+static uint64_t div64_u64_round_up(uint64_t x, uint64_t y)
+{
+ return (x + y - 1) / y;
+}
+
+static uint64_t ns_to_ticks(int i915, uint64_t ns)
+{
+ return div64_u64_round_up(ns * read_timestamp_frequency(i915),
+ NSEC_PER_SEC);
+}
+
+static uint64_t ticks_to_ns(int i915, uint64_t ticks)
+{
+ return div64_u64_round_up(ticks * NSEC_PER_SEC,
+ read_timestamp_frequency(i915));
+}
+
+#define MI_INSTR(opcode, flags) (((opcode) << 23) | (flags))
+
+#define MI_MATH(x) MI_INSTR(0x1a, (x) - 1)
+#define MI_MATH_INSTR(opcode, op1, op2) ((opcode) << 20 | (op1) << 10 | (op2))
+/* Opcodes for MI_MATH_INSTR */
+#define MI_MATH_NOOP MI_MATH_INSTR(0x000, 0x0, 0x0)
+#define MI_MATH_LOAD(op1, op2)MI_MATH_INSTR(0x080, op1, op2)
+#define MI_MATH_LOADINV(op1, op2) MI_MATH_INSTR(0x480, op1, op2)
+#define MI_MATH_LOAD0(op1)MI_MATH_INSTR(0x081, op1)
+#define MI_MATH_LOAD1(op1)MI_MATH_INSTR(0x481, op1)
+#define MI_MATH_ADD MI_MATH_INSTR(0x100, 0x0, 0x0)
+#define MI_MATH_SUB MI_MATH_INSTR(0x101, 0x0, 0x0)
+#define MI_MATH_AND MI_MATH_INSTR(0x102, 0x0, 0x0)
+#define MI_MATH_ORMI_MATH_INSTR(0x103, 0x0, 0x0)
+#define MI_MATH_XOR MI_MATH_INSTR(0x104, 0x0, 0x0)
+#define MI_MATH_STORE(op1, op2) MI_MATH_INSTR(0x180, op1, op2)
+#define MI_MATH_STOREINV(op1, op2)MI_MATH_INSTR(0x580, op1, op2)
+/* Registers used as operands in MI_MATH_INSTR */
+#define MI_MATH_REG(x)(x)
+#define MI_MATH_REG_SRCA 0x20
+#define MI_MATH_REG_SRCB 0x21
+#define MI_MATH_REG_ACCU 0x31
+#define MI_MATH_REG_ZF0x32
+#define MI_MATH_REG_CF0x33
+
+#define MI_LOAD_REGISTER_REGMI_INSTR(0x2A, 1)
+
+static void delay(int i915,
+ const struct intel_execution_engine2 *e,
+ uint32_t handle,
+ uint64_t addr,
+ uint64_t ns)
+{
+ const int use_64b = intel_gen(intel_get_drm_devid(i915)) >= 8;
+ const uint32_t base = gem_engine_mmio_base(i915, e->name);
+#define CS_GPR(x) (base + 0x600 + 8 * (x))
+#define RUNTIME (base + 0x3a8)
+ enum { START_TS, NOW_TS };
+ uint32_t *map, *cs, *jmp;
+
+ igt_require(base);
+
+ /* Loop until CTX_TIMESTAMP - initial > @ns */
+
+ cs = map = gem_mmap__device_coherent(i915, handle, 0, 4096, PROT_WRITE);
+
+ *cs++ = MI_LOAD_REGISTER_IMM;
+ *cs++ = CS_GPR(START_TS) + 4;
+ *cs++ = 0;
+ *cs++ = MI_LOAD_REGISTER_REG;
+ *cs++ = RUNTIME;
+ *cs++ = CS_GPR(START_TS);
+
+ while (offset_in_page(cs) & 63)
+ *cs++ = 0;
+ jmp = cs;
+
+ *cs++ = 0x5 << 23; /* MI_ARB_CHECK */
+
+ *cs++ = MI_LOAD_REGISTER_IMM;
+ *cs++ = CS_GPR(NOW_TS) + 4;
+ *cs++ = 0;
+ *cs++ = MI_LOAD_REGISTER_REG;
+ *cs++ = RUNTIME;
+ *cs++ = CS_GPR(NOW_TS);
+
+ /* delta = now - start; inverted to match COND_BBE */
+ *cs++ = MI_MATH(4);
+ *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCA, MI_MATH_REG(NOW_TS));
+ *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCB, MI_MATH_REG(START_TS));
+ *cs++ = MI_MATH_SUB;
+ *cs++ = MI_MATH_STOREINV(MI_MATH_REG(NOW_TS), MI_MATH_REG_ACCU);
+
+ /* Save delta for reading by COND_BBE */
+ *cs++ = 0x24 << 23 | (1 + use_64b); /* SRM */
+ *cs++ = CS_GPR(NOW_TS);
+ *cs++ = addr + 4000;
+ *cs++ = addr >> 32;
+
+ /* Delay between SRM and COND_BBE to post the writes */
+
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl: Wa_1607138340
== Series Details ==
Series: drm/i915/tgl: Wa_1607138340
URL : https://patchwork.freedesktop.org/series/80210/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8834 -> Patchwork_18301
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18301/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18301:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@execlists:
- {fi-tgl-dsi}: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18301/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
Known issues
Here are the changes found in Patchwork_18301 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-apl-guc: [PASS][3] -> [DMESG-WARN][4] ([i915#1635] /
[i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-apl-guc/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18301/fi-apl-guc/igt@i915_module_l...@reload.html
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18301/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [PASS][7] -> [DMESG-WARN][8] ([i915#2203])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18301/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-j1900: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-byt-j1900/igt@kms_frontbuffer_track...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18301/fi-byt-j1900/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@i915_selftest@live@gt_lrc:
- fi-tgl-u2: [DMESG-FAIL][11] ([i915#1233]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18301/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] +2
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18301/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [SKIP][15] ([fdo#109271]) -> [DMESG-FAIL][16]
([i915#62])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18301/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_flip@basic-flip-vs-modeset@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92]) ->
[DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95]) +5 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18301/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][20] ([i915#62] / [i915#92]) +1 similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18301/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.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
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
[i915#1982]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/tgl: Wa_1607138340
== Series Details == Series: drm/i915/tgl: Wa_1607138340 URL : https://patchwork.freedesktop.org/series/80210/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. ___ 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/tgl: Wa_1607138340
== Series Details ==
Series: drm/i915/tgl: Wa_1607138340
URL : https://patchwork.freedesktop.org/series/80210/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cfeda9f90aed drm/i915/tgl: Wa_1607138340
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 921f0c47f228 ("drm/i915: Revert
"drm/i915/tgl: Wa_1607138340"")'
#8:
References: 921f0c47f228 ("drm/i915: Revert "drm/i915/tgl: Wa_1607138340"")
total: 1 errors, 0 warnings, 0 checks, 10 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 drm/i915: Fix wrong return value in intel_atomic_check()
== Series Details ==
Series: drm/i915: Fix wrong return value in intel_atomic_check()
URL : https://patchwork.freedesktop.org/series/80208/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8834 -> Patchwork_18299
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/index.html
Known issues
Here are the changes found in Patchwork_18299 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@i915_module_load@reload:
- fi-apl-guc: [PASS][3] -> [DMESG-WARN][4] ([i915#1635] /
[i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-apl-guc/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/fi-apl-guc/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@gem_contexts:
- fi-tgl-u2: [PASS][5] -> [INCOMPLETE][6] ([i915#2045])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Possible fixes
* igt@i915_module_load@reload:
- fi-byt-j1900: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-byt-j1900/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-tgl-dsi}: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-tgl-dsi/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/fi-tgl-dsi/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] +2
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92]) ->
[DMESG-WARN][16] ([i915#1982] / [i915#62] / [i915#92])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92]) ->
[DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][20] ([i915#62] / [i915#92]) +1 similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2045]: https://gitlab.freedesktop.org/drm/intel/issues/2045
[i915#2100]:
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Wa_1607138340
Quoting Chris Wilson (2020-08-03 14:20:17)
> From: Mika Kuoppala
>
> Avoid possible cs hang with semaphores by disabling lite restore.
>
> References: 921f0c47f228 ("drm/i915: Revert "drm/i915/tgl: Wa_1607138340"")
> Signed-off-by: Mika Kuoppala
> Cc: Tvrtko Ursulin
> Cc: Tony Ye
> Cc: Chris Wilson
> ---
> Let's give this another spin. The hangs are still occuring on tgl-b0.
Ok, scratch this idea. Got a similar hang with this w/a inplace.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Fix wrong return value (rev2)
== Series Details == Series: drm/i915: Fix wrong return value (rev2) URL : https://patchwork.freedesktop.org/series/80175/ State : failure == Summary == Applying: drm/i915: Fix wrong return value Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_active.c M drivers/gpu/drm/i915/selftests/i915_request.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/selftests/i915_request.c Auto-merging drivers/gpu/drm/i915/i915_active.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_active.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/i915: Fix wrong return value When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/tgl: Wa_1607138340
From: Mika Kuoppala
Avoid possible cs hang with semaphores by disabling lite restore.
References: 921f0c47f228 ("drm/i915: Revert "drm/i915/tgl: Wa_1607138340"")
Signed-off-by: Mika Kuoppala
Cc: Tvrtko Ursulin
Cc: Tony Ye
Cc: Chris Wilson
---
Let's give this another spin. The hangs are still occuring on tgl-b0.
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index f1067806e8d8..80dae2f298ba 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1504,6 +1504,10 @@ static u64 execlists_update_context(struct i915_request
*rq)
*/
wmb();
+ /* Wa_1607138340:tgl */
+ if (IS_TGL_REVID(rq->engine->i915, TGL_REVID_A0, TGL_REVID_B0))
+ desc |= CTX_DESC_FORCE_RESTORE;
+
ce->lrc.desc &= ~CTX_DESC_FORCE_RESTORE;
return desc;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Fix wrong return value in intel_atomic_check()
== Series Details == Series: drm/i915: Fix wrong return value in intel_atomic_check() URL : https://patchwork.freedesktop.org/series/80208/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix wrong return value in intel_atomic_check()
In the case of calling check_digital_port_conflicts() failed, a
negative error code -EINVAL should be returned.
Fixes: bf5da83e4bd80 ("drm/i915: Move check_digital_port_conflicts() earier")
Cc: Ville Syrjälä
Signed-off-by: Tianjia Zhang
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 26996e1839e2..9f3a7ef58aba 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14872,7 +14872,7 @@ static int intel_atomic_check(struct drm_device *dev,
if (any_ms && !check_digital_port_conflicts(state)) {
drm_dbg_kms(_priv->drm,
"rejecting conflicting digital port
configuration\n");
- ret = EINVAL;
+ ret = -EINVAL;
goto fail;
}
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
The return value of pci_read_config_*() may not indicate a device error. However, the value read by these functions is more likely to indicate this kind of error. This presents two overlapping ways of reporting errors and complicates error checking. It is possible to move to one single way of checking for error if the dependencies on the return value of these functions are removed, then it can later be made to return void. Remove all uses of the return value of pci_read_config_*(). Check the actual value read for ~0. In this case, ~0 is an invalid value thus it indicates some kind of error. In some cases it madkes sence to make the calling function return void without causing any bug. Future callers can use the value obtained from these functions for validation. This case pertain to cs5536_read() and edac_pci_read_dword() MERGE: There is no dependency. Merge individually Saheed O. Bolarinwa (17): ata: Drop uses of pci_read_config_*() return value atm: Drop uses of pci_read_config_*() return value bcma: Drop uses of pci_read_config_*() return value hwrng: Drop uses of pci_read_config_*() return value dmaengine: ioat: Drop uses of pci_read_config_*() return value edac: Drop uses of pci_read_config_*() return value fpga: altera-cvp: Drop uses of pci_read_config_*() return value gpio: Drop uses of pci_read_config_*() return value drm/i915/vga: Drop uses of pci_read_config_*() return value hwmon: Drop uses of pci_read_config_*() return value intel_th: pci: Drop uses of pci_read_config_*() return value i2c: Drop uses of pci_read_config_*() return value ide: Drop uses of pci_read_config_*() return value IB: Drop uses of pci_read_config_*() return value iommu/vt-d: Drop uses of pci_read_config_*() return value mtd: Drop uses of pci_read_config_*() return value net: Drop uses of pci_read_config_*() return value drivers/ata/pata_cs5536.c | 6 +-- drivers/ata/pata_rz1000.c | 3 +- drivers/atm/eni.c | 3 +- drivers/atm/he.c | 12 +++-- drivers/atm/idt77252.c| 9 ++-- drivers/atm/iphase.c | 46 ++- drivers/atm/lanai.c | 4 +- drivers/atm/nicstar.c | 3 +- drivers/atm/zatm.c| 9 ++-- drivers/bcma/host_pci.c | 6 ++- drivers/char/hw_random/amd-rng.c | 6 +-- drivers/dma/ioat/dma.c| 6 +-- drivers/edac/amd64_edac.c | 8 ++-- drivers/edac/amd8111_edac.c | 16 ++- drivers/edac/amd8131_edac.c | 6 +-- drivers/edac/i82443bxgx_edac.c| 3 +- drivers/edac/sb_edac.c| 12 +++-- drivers/edac/skx_common.c | 18 +--- drivers/fpga/altera-cvp.c | 8 ++-- drivers/gpio/gpio-amd8111.c | 7 ++- drivers/gpio/gpio-rdc321x.c | 21 + drivers/gpu/drm/i915/display/intel_vga.c | 3 +- drivers/hwmon/i5k_amb.c | 12 +++-- drivers/hwmon/vt8231.c| 8 ++-- drivers/hwtracing/intel_th/pci.c | 12 ++--- drivers/i2c/busses/i2c-ali15x3.c | 6 ++- drivers/i2c/busses/i2c-elektor.c | 3 +- drivers/i2c/busses/i2c-nforce2.c | 4 +- drivers/i2c/busses/i2c-sis5595.c | 17 --- drivers/i2c/busses/i2c-sis630.c | 7 +-- drivers/i2c/busses/i2c-viapro.c | 11 +++-- drivers/ide/cs5536.c | 6 +-- drivers/ide/rz1000.c | 3 +- drivers/ide/setup-pci.c | 26 +++ drivers/infiniband/hw/hfi1/pcie.c | 38 +++ drivers/infiniband/hw/mthca/mthca_reset.c | 19 drivers/iommu/intel/iommu.c | 6 ++- drivers/mtd/maps/ichxrom.c| 4 +- drivers/net/can/peak_canfd/peak_pciefd_main.c | 6 ++- drivers/net/can/sja1000/peak_pci.c| 6 ++- drivers/net/ethernet/agere/et131x.c | 11 +++-- .../ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 5 +- .../cavium/liquidio/cn23xx_pf_device.c| 4 +- drivers/net/ethernet/marvell/sky2.c | 5 +- drivers/net/ethernet/mellanox/mlx4/catas.c| 7 +-- drivers/net/ethernet/mellanox/mlx4/reset.c| 10 ++-- .../net/ethernet/myricom/myri10ge/myri10ge.c | 4 +- drivers/net/wan/farsync.c | 5 +- .../broadcom/brcm80211/brcmfmac/pcie.c| 4 +- .../net/wireless/intel/iwlwifi/pcie/trans.c | 15 -- 50 files changed, 270 insertions(+), 209 deletions(-) -- 2.18.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
On Sun, Aug 02, 2020 at 02:14:06PM -0500, Bjorn Helgaas wrote: > But what guarantees that a PCI config register cannot contain ~0? > If there's something about that in the spec I'd love to know where it > is because it would simplify a lot of things. There isn't. An we even have cases like the NVMe controller memory buffer and persistent memory region, which are BARs that store abritrary values for later retreival, so it can't. (now those features have a major issue with error detection, but that is another issue) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix wrong return value
In function i915_active_acquire_preallocate_barrier(), not all
paths have the return value set correctly, and in case of memory
allocation failure, a negative error code should be returned.
Cc: Chris Wilson
Signed-off-by: Tianjia Zhang
---
drivers/gpu/drm/i915/i915_active.c| 4 ++--
drivers/gpu/drm/i915/selftests/i915_request.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index d960d0be5bd2..cc017e3cc9c5 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -758,7 +758,7 @@ int i915_active_acquire_preallocate_barrier(struct
i915_active *ref,
intel_engine_mask_t tmp, mask = engine->mask;
struct llist_node *first = NULL, *last = NULL;
struct intel_gt *gt = engine->gt;
- int err;
+ int err = 0;
GEM_BUG_ON(i915_active_is_idle(ref));
@@ -782,7 +782,7 @@ int i915_active_acquire_preallocate_barrier(struct
i915_active *ref,
if (!node) {
node = kmem_cache_alloc(global.slab_cache, GFP_KERNEL);
if (!node) {
- err = ENOMEM;
+ err = -ENOMEM;
goto unwind;
}
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests/i915_request.c
index 6014e8dfcbb1..dda801a87b8a 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -326,7 +326,7 @@ static int __igt_breadcrumbs_smoketest(void *arg)
if (!wait) {
i915_sw_fence_commit(submit);
heap_fence_put(submit);
- err = ENOMEM;
+ err = -ENOMEM;
break;
}
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 09/17] drm/i915/vga: Drop uses of pci_read_config_*() return value
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.
It is possible to move to one single way of checking for error if the
dependency on the return value of these functions is removed, then it
can later be made to return void.
Remove all uses of the return value of pci_read_config_*().
Check the actual value read for ~0. In this case, ~0 is an invalid
value thus it indicates some kind of error.
Suggested-by: Bjorn Helgaas
Signed-off-by: Saheed O. Bolarinwa
---
drivers/gpu/drm/i915/display/intel_vga.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vga.c
b/drivers/gpu/drm/i915/display/intel_vga.c
index be333699c515..6f9406699c9d 100644
--- a/drivers/gpu/drm/i915/display/intel_vga.c
+++ b/drivers/gpu/drm/i915/display/intel_vga.c
@@ -99,7 +99,8 @@ intel_vga_set_state(struct drm_i915_private *i915, bool
enable_decode)
unsigned int reg = INTEL_GEN(i915) >= 6 ? SNB_GMCH_CTRL :
INTEL_GMCH_CTRL;
u16 gmch_ctrl;
- if (pci_read_config_word(i915->bridge_dev, reg, _ctrl)) {
+ pci_read_config_word(i915->bridge_dev, reg, _ctrl);
+ if (gmch_ctrl == (u16)~0) {
drm_err(>drm, "failed to read control word\n");
return -EIO;
}
--
2.18.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value
On 8/1/20 2:56 PM, Borislav Petkov wrote:
On Sat, Aug 01, 2020 at 01:24:29PM +0200, Saheed O. Bolarinwa wrote:
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.
So why isn't the *value check done in the pci_read_config_* functions
instead of touching gazillion callers?
Because the value ~0 has a meaning to some drivers and only
drivers have this knowledge. For those cases more checks will
be needed to ensure that it is an error that has actually
happened.
For example, pci_conf{1,2}_read() could check whether the u32 *value it
just read depending on the access method, whether that value is ~0 and
return proper PCIBIOS_ error in that case.
The primary goal is to make pci_config_read*() return void, so
that there is *only* one way to check for error i.e. through the
obtained value.
Again, only the drivers can determine if ~0 is a valid value. This
information is not available inside pci_config_read*().
- Saheed
___
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: timeline semaphore support
== Series Details ==
Series: drm/i915: timeline semaphore support
URL : https://patchwork.freedesktop.org/series/80201/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8834_full -> Patchwork_18297_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18297_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18297_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_18297_full:
### IGT changes ###
Possible regressions
* igt@gem_exec_balancer@nop:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/shard-iclb8/igt@gem_exec_balan...@nop.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18297/shard-iclb2/igt@gem_exec_balan...@nop.html
* {igt@gem_exec_fence@syncobj-timeline-wait} (NEW):
- shard-snb: NOTRUN -> [FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18297/shard-snb5/igt@gem_exec_fe...@syncobj-timeline-wait.html
- shard-hsw: NOTRUN -> [FAIL][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18297/shard-hsw2/igt@gem_exec_fe...@syncobj-timeline-wait.html
* igt@kms_flip@flip-vs-suspend@a-edp1:
- shard-skl: NOTRUN -> [INCOMPLETE][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18297/shard-skl4/igt@kms_flip@flip-vs-susp...@a-edp1.html
* igt@kms_psr@primary_mmap_cpu:
- shard-skl: [PASS][6] -> [CRASH][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/shard-skl8/igt@kms_psr@primary_mmap_cpu.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18297/shard-skl5/igt@kms_psr@primary_mmap_cpu.html
New tests
-
New tests have been introduced between CI_DRM_8834_full and
Patchwork_18297_full:
### New IGT tests (132) ###
* igt@gem_exec_fence@invalid-timeline-fence-array:
- Statuses : 8 pass(s)
- Exec time: [0.00, 0.01] s
* igt@gem_exec_fence@syncobj-backward-timeline-chain-engines:
- Statuses : 6 pass(s) 2 skip(s)
- Exec time: [0.0, 0.41] s
* igt@gem_exec_fence@syncobj-stationary-timeline-chain-engines:
- Statuses : 6 pass(s) 2 skip(s)
- Exec time: [0.0, 0.42] s
* igt@gem_exec_fence@syncobj-timeline-chain-engines:
- Statuses : 6 pass(s) 2 skip(s)
- Exec time: [0.0, 0.42] s
* igt@gem_exec_fence@syncobj-timeline-export:
- Statuses : 8 pass(s)
- Exec time: [0.00, 0.03] s
* igt@gem_exec_fence@syncobj-timeline-invalid-flags:
- Statuses : 8 pass(s)
- Exec time: [0.0, 0.00] s
* igt@gem_exec_fence@syncobj-timeline-invalid-wait:
- Statuses : 8 pass(s)
- Exec time: [0.00, 0.01] s
* igt@gem_exec_fence@syncobj-timeline-repeat:
- Statuses : 8 pass(s)
- Exec time: [0.23, 2.90] s
* igt@gem_exec_fence@syncobj-timeline-signal:
- Statuses : 8 pass(s)
- Exec time: [0.00, 0.04] s
* igt@gem_exec_fence@syncobj-timeline-unused-fence:
- Statuses : 8 pass(s)
- Exec time: [0.00, 0.02] s
* igt@gem_exec_fence@syncobj-timeline-wait:
- Statuses : 2 fail(s) 6 pass(s)
- Exec time: [0.02, 0.16] s
* igt@syncobj_timeline@32bits-limit:
- Statuses : 8 timeout(s)
- Exec time: [120.50, 122.64] s
* igt@syncobj_timeline@device-signal-unordered:
- Statuses : 7 pass(s)
- Exec time: [0.0, 0.01] s
* igt@syncobj_timeline@device-submit-unordered:
- Statuses : 8 pass(s)
- Exec time: [0.0, 0.01] s
* igt@syncobj_timeline@etime-multi-wait-all-for-submit-available-unsubmitted:
- Statuses : 8 pass(s)
- Exec time: [0.10, 0.11] s
*
igt@syncobj_timeline@etime-multi-wait-all-for-submit-available-unsubmitted-signaled:
- Statuses : 7 pass(s)
- Exec time: [0.10, 0.11] s
*
igt@syncobj_timeline@etime-multi-wait-all-for-submit-available-unsubmitted-submitted:
- Statuses : 8 pass(s)
- Exec time: [0.10, 0.11] s
* igt@syncobj_timeline@etime-multi-wait-all-for-submit-submitted:
- Statuses : 8 pass(s)
- Exec time: [0.10, 0.11] s
* igt@syncobj_timeline@etime-multi-wait-all-for-submit-submitted-signaled:
- Statuses : 8 pass(s)
- Exec time: [0.10, 0.11] s
* igt@syncobj_timeline@etime-multi-wait-all-for-submit-unsubmitted:
- Statuses : 7 pass(s)
- Exec time: [0.10, 0.11] s
* igt@syncobj_timeline@etime-multi-wait-all-for-submit-unsubmitted-signaled:
- Statuses : 8 pass(s)
- Exec time: [0.10, 0.11] s
* igt@syncobj_timeline@etime-multi-wait-all-for-submit-unsubmitted-submitted:
- Statuses : 8 pass(s)
- Exec time: [0.10, 0.11] s
*
igt@syncobj_timeline@etime-multi-wait-all-for-submit-unsubmitted-submitted-signaled:
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/7] drm/i915/gem: Reduce context termination list iteration guard to RCU
== Series Details ==
Series: series starting with [1/7] drm/i915/gem: Reduce context termination
list iteration guard to RCU
URL : https://patchwork.freedesktop.org/series/80203/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8834 -> Patchwork_18298
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18298 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18298, 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_18298/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18298:
### IGT changes ###
Possible regressions
* igt@gem_sync@basic-all:
- fi-bsw-kefka: [PASS][1] -> [TIMEOUT][2] +3 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-bsw-kefka/igt@gem_s...@basic-all.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18298/fi-bsw-kefka/igt@gem_s...@basic-all.html
* igt@i915_selftest@live@gt_pm:
- fi-ivb-3770:[PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-ivb-3770/igt@i915_selftest@live@gt_pm.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18298/fi-ivb-3770/igt@i915_selftest@live@gt_pm.html
Warnings
* igt@gem_tiled_blits@basic:
- fi-bsw-kefka: [SKIP][5] ([fdo#109271]) -> [TIMEOUT][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-bsw-kefka/igt@gem_tiled_bl...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18298/fi-bsw-kefka/igt@gem_tiled_bl...@basic.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ctx_exec@basic:
- {fi-tgl-dsi}: [PASS][7] -> [TIMEOUT][8] +3 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-tgl-dsi/igt@gem_ctx_e...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18298/fi-tgl-dsi/igt@gem_ctx_e...@basic.html
* igt@gem_exec_basic@basic:
- {fi-tgl-dsi}: NOTRUN -> [TIMEOUT][9]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18298/fi-tgl-dsi/igt@gem_exec_ba...@basic.html
Known issues
Here are the changes found in Patchwork_18298 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [PASS][10] -> [FAIL][11] ([i915#1888])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18298/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@gem_tiled_fence_blits@basic:
- fi-apl-guc: [PASS][12] -> [TIMEOUT][13] ([i915#1635]) +4 similar
issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-apl-guc/igt@gem_tiled_fence_bl...@basic.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18298/fi-apl-guc/igt@gem_tiled_fence_bl...@basic.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [PASS][14] -> [DMESG-WARN][15] ([i915#1982])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18298/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-bsw-n3050: [PASS][16] -> [DMESG-WARN][17] ([i915#1982])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18298/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
- fi-icl-y: [PASS][18] -> [FAIL][19] ([i915#579])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-icl-y/igt@i915_pm_...@module-reload.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18298/fi-icl-y/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gem_contexts:
- fi-tgl-u2: [PASS][20] -> [INCOMPLETE][21] ([i915#2045])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18298/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
* igt@i915_selftest@live@hangcheck:
- fi-icl-u2: [PASS][22] -> [INCOMPLETE][23] ([i915#926])
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-icl-u2/igt@i915_selftest@l...@hangcheck.html
[23]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/7] drm/i915/gem: Reduce context termination list iteration guard to RCU
== Series Details == Series: series starting with [1/7] drm/i915/gem: Reduce context termination list iteration guard to RCU URL : https://patchwork.freedesktop.org/series/80203/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. ___ 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/7] drm/i915/gem: Reduce context termination list iteration guard to RCU
== Series Details ==
Series: series starting with [1/7] drm/i915/gem: Reduce context termination
list iteration guard to RCU
URL : https://patchwork.freedesktop.org/series/80203/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4421ede59e7d drm/i915/gem: Reduce context termination list iteration guard to
RCU
-:20: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#20:
References: d22d2d073ef8 ("drm/i915: Protect i915_request_await_start from
early waits") # rcu protection of timeline->requests
-:20: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit d22d2d073ef8 ("drm/i915: Protect
i915_request_await_start from early waits")'
#20:
References: d22d2d073ef8 ("drm/i915: Protect i915_request_await_start from
early waits") # rcu protection of timeline->requests
total: 1 errors, 1 warnings, 0 checks, 65 lines checked
ec9af2d61290 drm/i915/gt: Protect context lifetime with RCU
ee3eeddcd833 drm/i915/gt: Free stale request on destroying the virtual engine
ece8f60ae6af drm/i915/gt: Defer enabling the breadcrumb interrupt to after
submission
f13281e3e17d drm/i915/gt: Track signaled breadcrumbs outside of the breadcrumb
spinlock
f2ce274b32c7 drm/i915/gt: Don't cancel the interrupt shadow too early
14bb8af2a6f4 drm/i915/gt: Split the breadcrumb spinlock between global and
contexts
-:296: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#296: FILE: drivers/gpu/drm/i915/gt/intel_context_types.h:54:
+ spinlock_t signal_lock;
total: 0 errors, 0 warnings, 1 checks, 256 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 drm/i915: timeline semaphore support
== Series Details ==
Series: drm/i915: timeline semaphore support
URL : https://patchwork.freedesktop.org/series/80201/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8834 -> Patchwork_18297
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18297/index.html
Known issues
Here are the changes found in Patchwork_18297 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-apl-guc: [PASS][1] -> [DMESG-WARN][2] ([i915#1635] /
[i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-apl-guc/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18297/fi-apl-guc/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@gem_contexts:
- fi-tgl-u2: [PASS][3] -> [INCOMPLETE][4] ([i915#2045])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18297/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][5] -> [DMESG-WARN][6] ([i915#62] / [i915#92] /
[i915#95])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18297/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u: [PASS][7] -> [DMESG-WARN][8] ([i915#2203])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18297/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-cml-s: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-cml-s/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18297/fi-cml-s/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
Possible fixes
* igt@i915_selftest@live@gt_lrc:
- fi-tgl-u2: [DMESG-FAIL][11] ([i915#1233]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18297/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18297/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92]) ->
[DMESG-WARN][16] ([i915#1982] / [i915#62] / [i915#92])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18297/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@kms_flip@basic-flip-vs-modeset@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92]) ->
[DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95]) +6 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18297/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][20] ([i915#62] / [i915#92])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8834/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18297/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#138]: https://gitlab.freedesktop.org/drm/intel/issues/138
[i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2045]: https://gitlab.freedesktop.org/drm/intel/issues/2045
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]:
[Intel-gfx] [PATCH i-g-t] i915/gem_exec_parallel: Add basic userptr thrashing
Mix in a modicum of generic userptr thrashing for a quick (1s) BAT pass,
as we have currently no coverage of userptr at all in BAT.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_parallel.c | 31 +--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/tests/i915/gem_exec_parallel.c b/tests/i915/gem_exec_parallel.c
index bf94b93d4..96feb8250 100644
--- a/tests/i915/gem_exec_parallel.c
+++ b/tests/i915/gem_exec_parallel.c
@@ -45,6 +45,7 @@ static inline uint32_t hash32(uint32_t val)
#define CONTEXTS 0x1
#define FDS 0x2
+#define USERPTR 0x4
#define NUMOBJ 16
@@ -164,6 +165,30 @@ static void check_bo(int fd, uint32_t handle, int pass,
struct thread *threads)
igt_assert_eq_u32(result, x);
}
+static uint32_t handle_create(int fd, unsigned int flags, void **data)
+{
+ if (flags & USERPTR) {
+ uint32_t handle;
+ void *ptr;
+
+ posix_memalign(, 4096, 4096);
+ gem_userptr(fd, ptr, 4096, 0, 0, );
+ *data = ptr;
+
+ return handle;
+ }
+
+ return gem_create(fd, 4096);
+}
+
+static void handle_close(int fd, unsigned int flags, uint32_t handle, void
*data)
+{
+ if (flags & USERPTR)
+ free(data);
+
+ gem_close(fd, handle);
+}
+
static void all(int fd, struct intel_execution_engine2 *engine, unsigned flags)
{
const int gen = intel_gen(intel_get_drm_devid(fd));
@@ -172,6 +197,7 @@ static void all(int fd, struct intel_execution_engine2
*engine, unsigned flags)
struct thread *threads;
uint32_t scratch[NUMOBJ], handle[NUMOBJ];
unsigned engines[16], nengine;
+ void *arg[NUMOBJ];
int go;
int i;
@@ -196,7 +222,7 @@ static void all(int fd, struct intel_execution_engine2
*engine, unsigned flags)
igt_require(nengine);
for (i = 0; i < NUMOBJ; i++) {
- scratch[i] = handle[i] = gem_create(fd, 4096);
+ scratch[i] = handle[i] = handle_create(fd, flags, [i]);
if (flags & FDS)
scratch[i] = gem_flink(fd, handle[i]);
}
@@ -233,7 +259,7 @@ static void all(int fd, struct intel_execution_engine2
*engine, unsigned flags)
for (i = 0; i < NUMOBJ; i++) {
check_bo(fd, handle[i], i, threads);
- gem_close(fd, handle[i]);
+ handle_close(fd, flags, handle[i], arg[i]);
}
igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
@@ -251,6 +277,7 @@ igt_main
{ "basic", 0 },
{ "contexts", CONTEXTS },
{ "fds", FDS },
+ { "userptr", USERPTR },
{ NULL }
};
int fd;
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: timeline semaphore support
== Series Details == Series: drm/i915: timeline semaphore support URL : https://patchwork.freedesktop.org/series/80201/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. ___ 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: timeline semaphore support
== Series Details == Series: drm/i915: timeline semaphore support URL : https://patchwork.freedesktop.org/series/80201/ State : warning == Summary == $ dim checkpatch origin/drm-tip d38db3114f74 drm/i915: introduce a mechanism to extend execbuf2 -:377: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #377: FILE: include/uapi/drm/i915_drm.h:1204: +#define __I915_EXEC_UNKNOWN_FLAGS (-(I915_EXEC_USE_EXTENSIONS<<1)) ^ total: 0 errors, 0 warnings, 1 checks, 333 lines checked c93fd82a57f8 drm/i915: add syncobj timeline support -:25: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #25: https://lists.freedesktop.org/archives/dri-devel/2019-August/229287.html -:308: CHECK:LINE_SPACING: Please don't use multiple blank lines #308: FILE: include/uapi/drm/i915_drm.h:628: + + total: 0 errors, 1 warnings, 1 checks, 291 lines checked c245506d0af1 drm/i915: peel dma-fence-chains wait fences ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/7] drm/i915/gt: Protect context lifetime with RCU
Allow a brief period for continued access to a dead intel_context by
deferring the release of the struct until after an RCU grace period.
As we are using a dedicated slab cache for the contexts, we can defer
the release of the slab pages via RCU, with the caveat that individual
structs may be reused from the freelist within an RCU grace period. To
handle that, we have to avoid clearing members of the zombie struct.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.c | 330 +---
drivers/gpu/drm/i915/i915_active.c | 10 +
drivers/gpu/drm/i915/i915_active.h | 2 +
drivers/gpu/drm/i915/i915_utils.h | 7 +
4 files changed, 202 insertions(+), 147 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 52db2bde44a3..4e7924640ffa 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -22,7 +22,7 @@ static struct i915_global_context {
static struct intel_context *intel_context_alloc(void)
{
- return kmem_cache_zalloc(global.slab_ce, GFP_KERNEL);
+ return kmem_cache_alloc(global.slab_ce, GFP_KERNEL);
}
void intel_context_free(struct intel_context *ce)
@@ -30,6 +30,177 @@ void intel_context_free(struct intel_context *ce)
kmem_cache_free(global.slab_ce, ce);
}
+static int __context_pin_state(struct i915_vma *vma)
+{
+ unsigned int bias = i915_ggtt_pin_bias(vma) | PIN_OFFSET_BIAS;
+ int err;
+
+ err = i915_ggtt_pin(vma, 0, bias | PIN_HIGH);
+ if (err)
+ return err;
+
+ err = i915_active_acquire(>active);
+ if (err)
+ goto err_unpin;
+
+ /*
+* And mark it as a globally pinned object to let the shrinker know
+* it cannot reclaim the object until we release it.
+*/
+ i915_vma_make_unshrinkable(vma);
+ vma->obj->mm.dirty = true;
+
+ return 0;
+
+err_unpin:
+ i915_vma_unpin(vma);
+ return err;
+}
+
+static void __context_unpin_state(struct i915_vma *vma)
+{
+ i915_vma_make_shrinkable(vma);
+ i915_active_release(>active);
+ __i915_vma_unpin(vma);
+}
+
+static int __ring_active(struct intel_ring *ring)
+{
+ int err;
+
+ err = intel_ring_pin(ring);
+ if (err)
+ return err;
+
+ err = i915_active_acquire(>vma->active);
+ if (err)
+ goto err_pin;
+
+ return 0;
+
+err_pin:
+ intel_ring_unpin(ring);
+ return err;
+}
+
+static void __ring_retire(struct intel_ring *ring)
+{
+ i915_active_release(>vma->active);
+ intel_ring_unpin(ring);
+}
+
+__i915_active_call
+static void __intel_context_retire(struct i915_active *active)
+{
+ struct intel_context *ce = container_of(active, typeof(*ce), active);
+
+ CE_TRACE(ce, "retire runtime: { total:%lluns, avg:%lluns }\n",
+intel_context_get_total_runtime_ns(ce),
+intel_context_get_avg_runtime_ns(ce));
+
+ set_bit(CONTEXT_VALID_BIT, >flags);
+ if (ce->state)
+ __context_unpin_state(ce->state);
+
+ intel_timeline_unpin(ce->timeline);
+ __ring_retire(ce->ring);
+
+ intel_context_put(ce);
+}
+
+static int __intel_context_active(struct i915_active *active)
+{
+ struct intel_context *ce = container_of(active, typeof(*ce), active);
+ int err;
+
+ CE_TRACE(ce, "active\n");
+
+ intel_context_get(ce);
+
+ err = __ring_active(ce->ring);
+ if (err)
+ goto err_put;
+
+ err = intel_timeline_pin(ce->timeline);
+ if (err)
+ goto err_ring;
+
+ if (!ce->state)
+ return 0;
+
+ err = __context_pin_state(ce->state);
+ if (err)
+ goto err_timeline;
+
+ return 0;
+
+err_timeline:
+ intel_timeline_unpin(ce->timeline);
+err_ring:
+ __ring_retire(ce->ring);
+err_put:
+ intel_context_put(ce);
+ return err;
+}
+
+static void __intel_context_ctor(void *arg)
+{
+ struct intel_context *ce = arg;
+
+ INIT_LIST_HEAD(>signal_link);
+ INIT_LIST_HEAD(>signals);
+
+ atomic_set(>pin_count, 0);
+ mutex_init(>pin_mutex);
+
+ ce->active_count = 0;
+ i915_active_init(>active,
+__intel_context_active, __intel_context_retire);
+
+ ce->inflight = NULL;
+ ce->lrc_reg_state = NULL;
+ ce->lrc.desc = 0;
+}
+
+static void
+__intel_context_init(struct intel_context *ce, struct intel_engine_cs *engine)
+{
+ GEM_BUG_ON(!engine->cops);
+ GEM_BUG_ON(!engine->gt->vm);
+
+ kref_init(>ref);
+ i915_active_reinit(>active);
+ mutex_reinit(>pin_mutex);
+
+ ce->engine = engine;
+ ce->ops = engine->cops;
+ ce->sseu = engine->sseu;
+
+ ce->wa_bb_page = 0;
+ ce->flags = 0;
+ ce->tag = 0;
+
+ memset(>runtime, 0, sizeof(ce->runtime));
+
+
[Intel-gfx] [PATCH 1/7] drm/i915/gem: Reduce context termination list iteration guard to RCU
As we now protect the timeline list using RCU, we can drop the
timeline->mutex for guarding the list iteration during context close, as
we are searching for an inflight request. Any new request will see the
context is banned and not be submitted. In doing so, pull the checks for
a concurrent submission of the request (notably the
i915_request_completed()) under the engine spinlock, to fully serialise
with __i915_request_submit()). That is in the case of preempt-to-busy
where the request may be completed during the __i915_request_submit(),
we need to be careful that we sample the request status after
serialising so that we don't miss the request the engine is actually
submitting.
Fixes: 4a3174152147 ("drm/i915/gem: Refine occupancy test in kill_context()")
References: d22d2d073ef8 ("drm/i915: Protect i915_request_await_start from
early waits") # rcu protection of timeline->requests
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1622
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 32 -
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index d8cccbab7a51..db893f6c516b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -439,29 +439,36 @@ static bool __cancel_engine(struct intel_engine_cs
*engine)
return __reset_engine(engine);
}
-static struct intel_engine_cs *__active_engine(struct i915_request *rq)
+static bool
+__active_engine(struct i915_request *rq, struct intel_engine_cs **active)
{
struct intel_engine_cs *engine, *locked;
+ bool ret = false;
/*
* Serialise with __i915_request_submit() so that it sees
* is-banned?, or we know the request is already inflight.
+*
+* Note that rq->engine is unstable, and so we double
+* check that we have acquired the lock on the final engine.
*/
locked = READ_ONCE(rq->engine);
spin_lock_irq(>active.lock);
while (unlikely(locked != (engine = READ_ONCE(rq->engine {
spin_unlock(>active.lock);
- spin_lock(>active.lock);
locked = engine;
+ spin_lock(>active.lock);
}
- engine = NULL;
- if (i915_request_is_active(rq) && rq->fence.error != -EIO)
- engine = rq->engine;
+ if (!i915_request_completed(rq)) {
+ if (i915_request_is_active(rq) && rq->fence.error != -EIO)
+ *active = locked;
+ ret = true;
+ }
spin_unlock_irq(>active.lock);
- return engine;
+ return ret;
}
static struct intel_engine_cs *active_engine(struct intel_context *ce)
@@ -472,17 +479,16 @@ static struct intel_engine_cs *active_engine(struct
intel_context *ce)
if (!ce->timeline)
return NULL;
- mutex_lock(>timeline->mutex);
- list_for_each_entry_reverse(rq, >timeline->requests, link) {
- if (i915_request_completed(rq))
- break;
+ rcu_read_lock();
+ list_for_each_entry_rcu(rq, >timeline->requests, link) {
+ if (i915_request_is_active(rq) && i915_request_completed(rq))
+ continue;
/* Check with the backend if the request is inflight */
- engine = __active_engine(rq);
- if (engine)
+ if (__active_engine(rq, ))
break;
}
- mutex_unlock(>timeline->mutex);
+ rcu_read_unlock();
return engine;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/7] drm/i915/gt: Free stale request on destroying the virtual engine
Since preempt-to-busy, we may unsubmit a request while it is still on
the HW and completes asynchronously. That means it may be retired and in
the process destroy the virtual engine (as the user has closed their
context), but that engine may still be holding onto the unsubmitted
compelted request. Therefore we need to potentially cleanup the old
request on destroying the virtual engine. We also have to keep the
virtual_engine alive until after the sibling's execlists_dequeue() have
finished peeking into the virtual engines, for which we serialise with
RCU.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 417f6b0c6c61..cb04bc5474be 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -180,6 +180,7 @@
#define EXECLISTS_REQUEST_SIZE 64 /* bytes */
struct virtual_engine {
+ struct rcu_head rcu;
struct intel_engine_cs base;
struct intel_context context;
@@ -5393,10 +5394,25 @@ static void virtual_context_destroy(struct kref *kref)
container_of(kref, typeof(*ve), context.ref);
unsigned int n;
- GEM_BUG_ON(!list_empty(virtual_queue(ve)));
- GEM_BUG_ON(ve->request);
GEM_BUG_ON(ve->context.inflight);
+ if (unlikely(ve->request)) {
+ struct i915_request *old;
+ unsigned long flags;
+
+ spin_lock_irqsave(>base.active.lock, flags);
+
+ old = fetch_and_zero(>request);
+ if (old) {
+ GEM_BUG_ON(!i915_request_completed(old));
+ __i915_request_submit(old);
+ i915_request_put(old);
+ }
+
+ spin_unlock_irqrestore(>base.active.lock, flags);
+ }
+ GEM_BUG_ON(!list_empty(virtual_queue(ve)));
+
for (n = 0; n < ve->num_siblings; n++) {
struct intel_engine_cs *sibling = ve->siblings[n];
struct rb_node *node = >nodes[sibling->id].rb;
@@ -5422,7 +5438,7 @@ static void virtual_context_destroy(struct kref *kref)
intel_engine_free_request_pool(>base);
kfree(ve->bonds);
- kfree(ve);
+ kfree_rcu(ve, rcu);
}
static void virtual_engine_initial_hint(struct virtual_engine *ve)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/7] drm/i915/gt: Defer enabling the breadcrumb interrupt to after submission
Move the register slow register write and readback from out of the
critical path for execlists submission and delay it until the following
worker.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 48 ++---
1 file changed, 41 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index d8b206e53660..1359314f0fd5 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -83,6 +83,9 @@ static void __intel_breadcrumbs_arm_irq(struct
intel_breadcrumbs *b)
if (!b->irq_enabled++)
irq_enable(b->irq_engine);
+
+ /* Requests may have completed before we could enable the interrupt. */
+ irq_work_queue(>irq_work);
}
static void __intel_breadcrumbs_disarm_irq(struct intel_breadcrumbs *b)
@@ -105,8 +108,6 @@ static void add_signaling_context(struct intel_breadcrumbs
*b,
{
intel_context_get(ce);
list_add_tail(>signal_link, >signalers);
- if (list_is_first(>signal_link, >signalers))
- __intel_breadcrumbs_arm_irq(b);
}
static void remove_signaling_context(struct intel_breadcrumbs *b,
@@ -197,6 +198,29 @@ static void signal_irq_work(struct irq_work *work)
spin_lock(>irq_lock);
+ /*
+* Keep the irq armed until the interrupt after all listeners are gone.
+*
+* Enabling/disabling the interrupt is rather costly, roughly a couple
+* of hundred microseconds. If we are proactive and enable/disable
+* the interrupt around every request that wants a breadcrumb, we
+* quickly drown in the extra orders of magnitude of latency imposed
+* on request submission.
+*
+* So we try to be lazy, and keep the interrupts enabled until no
+* more listeners appear within a breadcrumb interrupt interval (that
+* is until a request completes that no one cares about). The
+* observation is that listeners come in batches, and will often
+* listen to a bunch of requests in succession.
+*
+* We also try to avoid raising too many interrupts, as they may
+* be generated by userspace batches and it is unfortunately rather
+* too easy to drown the CPU under a flood of GPU interrupts. Thus
+* whenever no one appears to be listening, we turn off the interrupts.
+* Fewer interrupts should conserve power -- at the very least, fewer
+* interrupt draw less ire from other users of the system and tools
+* like powertop.
+*/
if (list_empty(>signalers))
__intel_breadcrumbs_disarm_irq(b);
@@ -251,6 +275,13 @@ static void signal_irq_work(struct irq_work *work)
i915_request_put(rq);
}
+
+ if (!READ_ONCE(b->irq_armed) && !list_empty(>signalers)) {
+ spin_lock(>irq_lock);
+ if (!list_empty(>signalers))
+ __intel_breadcrumbs_arm_irq(b);
+ spin_unlock(>irq_lock);
+ }
}
struct intel_breadcrumbs *
@@ -301,8 +332,8 @@ void intel_breadcrumbs_park(struct intel_breadcrumbs *b)
__intel_breadcrumbs_disarm_irq(b);
spin_unlock_irqrestore(>irq_lock, flags);
- if (!list_empty(>signalers))
- irq_work_queue(>irq_work);
+ /* Kick the work once more to drain the signalers */
+ irq_work_queue(>irq_work);
}
void intel_breadcrumbs_free(struct intel_breadcrumbs *b)
@@ -362,9 +393,12 @@ static void insert_breadcrumb(struct i915_request *rq,
GEM_BUG_ON(!check_signal_order(ce, rq));
set_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags);
- /* Check after attaching to irq, interrupt may have already fired. */
- if (__request_completed(rq))
- irq_work_queue(>irq_work);
+ /*
+* Defer enabling the interrupt to after HW submission and recheck
+* the request as it may have completed and raised the interrupt as
+* we were attaching it into the lists.
+*/
+ irq_work_queue(>irq_work);
}
bool i915_request_enable_breadcrumb(struct i915_request *rq)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/7] drm/i915/gt: Track signaled breadcrumbs outside of the breadcrumb spinlock
Make b->signaled_requests a lockless-list so that we can manipulate it
outside of the b->irq_lock.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 28 +++
.../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 2 +-
drivers/gpu/drm/i915/i915_request.h | 6 +++-
3 files changed, 22 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 1359314f0fd5..fdf6a77a66cf 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -175,16 +175,13 @@ static void add_retire(struct intel_breadcrumbs *b,
struct intel_timeline *tl)
intel_engine_add_retire(b->irq_engine, tl);
}
-static bool __signal_request(struct i915_request *rq, struct list_head
*signals)
+static bool __signal_request(struct i915_request *rq)
{
- clear_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags);
-
if (!__dma_fence_signal(>fence)) {
i915_request_put(rq);
return false;
}
- list_add_tail(>signal_link, signals);
return true;
}
@@ -192,9 +189,13 @@ static void signal_irq_work(struct irq_work *work)
{
struct intel_breadcrumbs *b = container_of(work, typeof(*b), irq_work);
const ktime_t timestamp = ktime_get();
+ struct llist_node *signal, *sn;
struct intel_context *ce, *cn;
struct list_head *pos, *next;
- LIST_HEAD(signal);
+
+ signal = NULL;
+ if (unlikely(!llist_empty(>signaled_requests)))
+ signal = llist_del_all(>signaled_requests);
spin_lock(>irq_lock);
@@ -224,8 +225,6 @@ static void signal_irq_work(struct irq_work *work)
if (list_empty(>signalers))
__intel_breadcrumbs_disarm_irq(b);
- list_splice_init(>signaled_requests, );
-
list_for_each_entry_safe(ce, cn, >signalers, signal_link) {
GEM_BUG_ON(list_empty(>signals));
@@ -242,7 +241,11 @@ static void signal_irq_work(struct irq_work *work)
* spinlock as the callback chain may end up adding
* more signalers to the same context or engine.
*/
- __signal_request(rq, );
+ clear_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags);
+ if (__signal_request(rq)) {
+ rq->signal_node.next = signal;
+ signal = >signal_node;
+ }
}
/*
@@ -262,9 +265,9 @@ static void signal_irq_work(struct irq_work *work)
spin_unlock(>irq_lock);
- list_for_each_safe(pos, next, ) {
+ llist_for_each_safe(signal, sn, signal) {
struct i915_request *rq =
- list_entry(pos, typeof(*rq), signal_link);
+ llist_entry(signal, typeof(*rq), signal_node);
struct list_head cb_list;
spin_lock(>lock);
@@ -295,7 +298,7 @@ intel_breadcrumbs_create(struct intel_engine_cs *irq_engine)
spin_lock_init(>irq_lock);
INIT_LIST_HEAD(>signalers);
- INIT_LIST_HEAD(>signaled_requests);
+ init_llist_head(>signaled_requests);
init_irq_work(>irq_work, signal_irq_work);
@@ -358,7 +361,8 @@ static void insert_breadcrumb(struct i915_request *rq,
* its signal completion.
*/
if (__request_completed(rq)) {
- if (__signal_request(rq, >signaled_requests))
+ if (__signal_request(rq) &&
+ llist_add(>signal_node, >signaled_requests))
irq_work_queue(>irq_work);
return;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
index 8e53b9942695..3fa19820b37a 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
@@ -35,7 +35,7 @@ struct intel_breadcrumbs {
struct intel_engine_cs *irq_engine;
struct list_head signalers;
- struct list_head signaled_requests;
+ struct llist_head signaled_requests;
struct irq_work irq_work; /* for use from inside irq_lock */
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index 16b721080195..874af6db6103 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -176,7 +176,11 @@ struct i915_request {
struct intel_context *context;
struct intel_ring *ring;
struct intel_timeline __rcu *timeline;
- struct list_head signal_link;
+
+ union {
+ struct list_head signal_link;
+ struct llist_node signal_node;
+ };
/*
* The rcu epoch of when this request was allocated. Used to judiciously
--
2.20.1
[Intel-gfx] [PATCH 7/7] drm/i915/gt: Split the breadcrumb spinlock between global and contexts
As we funnel more and more contexts into the breadcrumbs on an engine,
the hold time of b->irq_lock grows. As we may then contend with the
b->irq_lock during request submission, this increases the burden upon
the engine->active.lock and so directly impacts both our execution
latency and client latency. If we split the b->irq_lock by introducing a
per-context spinlock to manage the signalers within a context, we then
only need the b->irq_lock for enabling/disabling the interrupt and can
avoid taking the lock for walking the list of contexts within the signal
worker. Even with the current setup, this greatly reduces the number of
times we have to take and fight for b->irq_lock.
Fixes: bda4d4db6dd6 ("drm/i915/gt: Replace
intel_engine_transfer_stale_breadcrumbs")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 151 ++
drivers/gpu/drm/i915/gt/intel_context.c | 1 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 1 +
3 files changed, 84 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 62ca0f8b2664..7f7377ad2997 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -106,15 +106,16 @@ static void __intel_breadcrumbs_disarm_irq(struct
intel_breadcrumbs *b)
static void add_signaling_context(struct intel_breadcrumbs *b,
struct intel_context *ce)
{
- intel_context_get(ce);
- list_add_tail(>signal_link, >signalers);
+ lockdep_assert_held(>irq_lock);
+ list_add_rcu(>signal_link, >signalers);
}
static void remove_signaling_context(struct intel_breadcrumbs *b,
struct intel_context *ce)
{
- list_del(>signal_link);
- intel_context_put(ce);
+ spin_lock(>irq_lock);
+ list_del_rcu(>signal_link);
+ spin_unlock(>irq_lock);
}
static inline bool __request_completed(const struct i915_request *rq)
@@ -190,15 +191,12 @@ static void signal_irq_work(struct irq_work *work)
struct intel_breadcrumbs *b = container_of(work, typeof(*b), irq_work);
const ktime_t timestamp = ktime_get();
struct llist_node *signal, *sn;
- struct intel_context *ce, *cn;
- struct list_head *pos, *next;
+ struct intel_context *ce;
signal = NULL;
if (unlikely(!llist_empty(>signaled_requests)))
signal = llist_del_all(>signaled_requests);
- spin_lock(>irq_lock);
-
/*
* Keep the irq armed until the interrupt after all listeners are gone.
*
@@ -222,11 +220,24 @@ static void signal_irq_work(struct irq_work *work)
* interrupt draw less ire from other users of the system and tools
* like powertop.
*/
- if (!signal && list_empty(>signalers))
- __intel_breadcrumbs_disarm_irq(b);
+ if (!signal && READ_ONCE(b->irq_armed) && list_empty(>signalers)) {
+ if (spin_trylock(>irq_lock)) {
+ if (list_empty(>signalers))
+ __intel_breadcrumbs_disarm_irq(b);
+ spin_unlock(>irq_lock);
+ }
+ }
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(ce, >signalers, signal_link) {
+ struct list_head *pos, *next;
+ bool release = false;
+
+ if (!spin_trylock(>signal_lock))
+ continue;
- list_for_each_entry_safe(ce, cn, >signalers, signal_link) {
- GEM_BUG_ON(list_empty(>signals));
+ if (list_empty(>signals))
+ goto unlock;
list_for_each_safe(pos, next, >signals) {
struct i915_request *rq =
@@ -259,11 +270,16 @@ static void signal_irq_work(struct irq_work *work)
if (>signals == pos) { /* now empty */
add_retire(b, ce->timeline);
remove_signaling_context(b, ce);
+ release = true;
}
}
- }
- spin_unlock(>irq_lock);
+unlock:
+ spin_unlock(>signal_lock);
+ if (release)
+ intel_context_put(ce);
+ }
+ rcu_read_unlock();
llist_for_each_safe(signal, sn, signal) {
struct i915_request *rq =
@@ -344,9 +360,9 @@ void intel_breadcrumbs_free(struct intel_breadcrumbs *b)
kfree(b);
}
-static void insert_breadcrumb(struct i915_request *rq,
- struct intel_breadcrumbs *b)
+static void insert_breadcrumb(struct i915_request *rq)
{
+ struct intel_breadcrumbs *b = READ_ONCE(rq->engine)->breadcrumbs;
struct intel_context *ce = rq->context;
struct list_head *pos;
@@ -368,7 +384,33 @@ static void insert_breadcrumb(struct
[Intel-gfx] [PATCH 6/7] drm/i915/gt: Don't cancel the interrupt shadow too early
We currently want to keep the interrupt enabled until the interrupt after
which we have no more work to do. This heuristic was broken by us
kicking the irq-work on adding a completed request without attaching a
signaler -- hence it appearing to the irq-worker that an interrupt had
fired when we were idle.
Fixes: bda4d4db6dd6 ("drm/i915/gt: Replace
intel_engine_transfer_stale_breadcrumbs")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index fdf6a77a66cf..62ca0f8b2664 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -222,7 +222,7 @@ static void signal_irq_work(struct irq_work *work)
* interrupt draw less ire from other users of the system and tools
* like powertop.
*/
- if (list_empty(>signalers))
+ if (!signal && list_empty(>signalers))
__intel_breadcrumbs_disarm_irq(b);
list_for_each_entry_safe(ce, cn, >signalers, signal_link) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_exec_parallel: Add basic userptr thrashing
Mix in a modicum of generic userptr thrashing for a quick (1s) BAT pass,
as we have currently no coverage of userptr at all in BAT.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_parallel.c| 31 +--
tests/intel-ci/fast-feedback.testlist | 5 -
2 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/tests/i915/gem_exec_parallel.c b/tests/i915/gem_exec_parallel.c
index bf94b93d4..96feb8250 100644
--- a/tests/i915/gem_exec_parallel.c
+++ b/tests/i915/gem_exec_parallel.c
@@ -45,6 +45,7 @@ static inline uint32_t hash32(uint32_t val)
#define CONTEXTS 0x1
#define FDS 0x2
+#define USERPTR 0x4
#define NUMOBJ 16
@@ -164,6 +165,30 @@ static void check_bo(int fd, uint32_t handle, int pass,
struct thread *threads)
igt_assert_eq_u32(result, x);
}
+static uint32_t handle_create(int fd, unsigned int flags, void **data)
+{
+ if (flags & USERPTR) {
+ uint32_t handle;
+ void *ptr;
+
+ posix_memalign(, 4096, 4096);
+ gem_userptr(fd, ptr, 4096, 0, 0, );
+ *data = ptr;
+
+ return handle;
+ }
+
+ return gem_create(fd, 4096);
+}
+
+static void handle_close(int fd, unsigned int flags, uint32_t handle, void
*data)
+{
+ if (flags & USERPTR)
+ free(data);
+
+ gem_close(fd, handle);
+}
+
static void all(int fd, struct intel_execution_engine2 *engine, unsigned flags)
{
const int gen = intel_gen(intel_get_drm_devid(fd));
@@ -172,6 +197,7 @@ static void all(int fd, struct intel_execution_engine2
*engine, unsigned flags)
struct thread *threads;
uint32_t scratch[NUMOBJ], handle[NUMOBJ];
unsigned engines[16], nengine;
+ void *arg[NUMOBJ];
int go;
int i;
@@ -196,7 +222,7 @@ static void all(int fd, struct intel_execution_engine2
*engine, unsigned flags)
igt_require(nengine);
for (i = 0; i < NUMOBJ; i++) {
- scratch[i] = handle[i] = gem_create(fd, 4096);
+ scratch[i] = handle[i] = handle_create(fd, flags, [i]);
if (flags & FDS)
scratch[i] = gem_flink(fd, handle[i]);
}
@@ -233,7 +259,7 @@ static void all(int fd, struct intel_execution_engine2
*engine, unsigned flags)
for (i = 0; i < NUMOBJ; i++) {
check_bo(fd, handle[i], i, threads);
- gem_close(fd, handle[i]);
+ handle_close(fd, flags, handle[i], arg[i]);
}
igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
@@ -251,6 +277,7 @@ igt_main
{ "basic", 0 },
{ "contexts", CONTEXTS },
{ "fds", FDS },
+ { "userptr", USERPTR },
{ NULL }
};
int fd;
diff --git a/tests/intel-ci/fast-feedback.testlist
b/tests/intel-ci/fast-feedback.testlist
index b796b2642..ff460e1a6 100644
--- a/tests/intel-ci/fast-feedback.testlist
+++ b/tests/intel-ci/fast-feedback.testlist
@@ -19,7 +19,10 @@ igt@gem_exec_fence@basic-wait
igt@gem_exec_fence@basic-await
igt@gem_exec_fence@nb-await
igt@gem_exec_gttfill@basic
-igt@gem_exec_parallel@engines
+igt@gem_exec_parallel@basic
+igt@gem_exec_parallel@userptr
+igt@gem_exec_parallel@fds
+igt@gem_exec_parallel@contexts
igt@gem_exec_store@basic
igt@gem_exec_suspend@basic-s0
igt@gem_exec_suspend@basic-s3
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: peel dma-fence-chains wait fences
To allow faster engine to engine synchronization, peel the layer of
dma-fence-chain to expose potential i915 fences so that the
i915-request code can emit HW semaphore wait/signal operations in the
ring which is faster than waking up the host to submit unblocked
workloads after interrupt notification.
v2: Also deal with chains where the last node is not a dma-fence-chain
Signed-off-by: Lionel Landwerlin
Reviewed-by: Daniel Vetter
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 39 ++-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 1f766431f3a3..dbd7f03c2187 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2390,6 +2390,7 @@ await_fence_array(struct i915_execbuffer *eb)
for (n = 0; n < eb->n_fences; n++) {
struct drm_syncobj *syncobj;
+ struct dma_fence_chain *chain;
struct dma_fence *fence;
unsigned int flags;
@@ -2410,7 +2411,43 @@ await_fence_array(struct i915_execbuffer *eb)
continue;
}
- err = i915_request_await_dma_fence(eb->request, fence);
+ chain = to_dma_fence_chain(fence);
+ if (chain) {
+ struct dma_fence *iter;
+
+ /*
+* If we're dealing with a dma-fence-chain, peel the
+* chain by adding all of the unsignaled fences
+* (dma_fence_chain_for_each does that for us) the
+* chain points to.
+*
+* This enables us to identify waits on i915 fences
+* and allows for faster engine-to-engine
+* synchronization using HW semaphores.
+*/
+ dma_fence_chain_for_each(iter, fence) {
+ struct dma_fence_chain *iter_chain =
+ to_dma_fence_chain(iter);
+
+ /*
+* It is possible that the last item in the
+* chain is not a dma_fence_chain.
+*/
+ if (iter_chain) {
+ err =
i915_request_await_dma_fence(eb->request,
+
iter_chain->fence);
+ } else {
+ err =
i915_request_await_dma_fence(eb->request, iter);
+ }
+ if (err < 0) {
+ dma_fence_put(iter);
+ break;
+ }
+ }
+ } else {
+ err = i915_request_await_dma_fence(eb->request, fence);
+ }
+
dma_fence_put(fence);
if (err < 0)
return err;
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] drm/i915: timeline semaphore support
Hi all, Hopefully this last run is all clean. No changes in this series, just a rebase on top of Danvet's s/DRM_ERROR/DRM_DEBUG/. Test-with: 20200803090053.260115-1-lionel.g.landwer...@intel.com Cheers, Lionel Landwerlin (3): drm/i915: introduce a mechanism to extend execbuf2 drm/i915: add syncobj timeline support drm/i915: peel dma-fence-chains wait fences .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 333 +++--- drivers/gpu/drm/i915/i915_drv.c | 3 +- drivers/gpu/drm/i915/i915_getparam.c | 1 + include/uapi/drm/i915_drm.h | 65 +++- 4 files changed, 342 insertions(+), 60 deletions(-) -- 2.28.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: add syncobj timeline support
Introduces a new parameters to execbuf so that we can specify syncobj
handles as well as timeline points.
v2: Reuse i915_user_extension_fn
v3: Check that the chained extension is only present once (Chris)
v4: Check that dma_fence_chain_find_seqno returns a non NULL fence (Lionel)
v5: Use BIT_ULL (Chris)
v6: Fix issue with already signaled timeline points,
dma_fence_chain_find_seqno() setting fence to NULL (Chris)
v7: Report ENOENT with invalid syncobj handle (Lionel)
v8: Check for out of order timeline point insertion (Chris)
v9: After explanations on
https://lists.freedesktop.org/archives/dri-devel/2019-August/229287.html
drop the ordering check from v8 (Lionel)
v10: Set first extension enum item to 1 (Jason)
v11: Rebase
Signed-off-by: Lionel Landwerlin
Reviewed-by: Daniel Vetter
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 167 +-
drivers/gpu/drm/i915/i915_drv.c | 3 +-
drivers/gpu/drm/i915/i915_getparam.c | 1 +
include/uapi/drm/i915_drm.h | 39
4 files changed, 203 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index ed8d1c2517f6..1f766431f3a3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -285,6 +285,8 @@ struct i915_execbuffer {
struct i915_eb_fence {
struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
+ u64 value;
+ struct dma_fence_chain *chain_fence;
} *fences;
u32 n_fences;
@@ -2200,14 +2202,121 @@ eb_pin_engine(struct i915_execbuffer *eb,
static void
__free_fence_array(struct i915_eb_fence *fences, unsigned int n)
{
- while (n--)
+ while (n--) {
drm_syncobj_put(ptr_mask_bits(fences[n].syncobj, 2));
+ kfree(fences[n].chain_fence);
+ }
kvfree(fences);
}
static int
-get_fence_array(struct drm_i915_gem_execbuffer2 *args,
- struct i915_execbuffer *eb)
+get_timeline_fence_array(const struct
drm_i915_gem_execbuffer_ext_timeline_fences *timeline_fences,
+struct i915_execbuffer *eb)
+{
+ struct drm_i915_gem_exec_fence __user *user_fences;
+ struct i915_eb_fence *fences;
+ u64 __user *user_values;
+ u64 num_fences, num_user_fences = timeline_fences->fence_count;
+ unsigned long n;
+ int err;
+
+ /* Check multiplication overflow for access_ok() and kvmalloc_array() */
+ BUILD_BUG_ON(sizeof(size_t) > sizeof(unsigned long));
+ if (num_user_fences > min_t(unsigned long,
+ ULONG_MAX / sizeof(*user_fences),
+ SIZE_MAX / sizeof(*fences)))
+ return -EINVAL;
+
+ user_fences = u64_to_user_ptr(timeline_fences->handles_ptr);
+ if (!access_ok(user_fences, num_user_fences * sizeof(*user_fences)))
+ return -EFAULT;
+
+ user_values = u64_to_user_ptr(timeline_fences->values_ptr);
+ if (!access_ok(user_values, num_user_fences * sizeof(*user_values)))
+ return -EFAULT;
+
+ fences = kvmalloc_array(num_user_fences, sizeof(*fences),
+ __GFP_NOWARN | GFP_KERNEL);
+ if (!fences)
+ return -ENOMEM;
+
+ BUILD_BUG_ON(~(ARCH_KMALLOC_MINALIGN - 1) &
+~__I915_EXEC_FENCE_UNKNOWN_FLAGS);
+
+ for (n = 0, num_fences = 0; n < timeline_fences->fence_count; n++) {
+ struct drm_i915_gem_exec_fence fence;
+ struct drm_syncobj *syncobj;
+ u64 point;
+
+ if (__copy_from_user(, user_fences++, sizeof(fence))) {
+ err = -EFAULT;
+ goto err;
+ }
+
+ if (fence.flags & __I915_EXEC_FENCE_UNKNOWN_FLAGS) {
+ err = -EINVAL;
+ goto err;
+ }
+
+ if (__get_user(point, user_values++)) {
+ err = -EFAULT;
+ goto err;
+ }
+
+ syncobj = drm_syncobj_find(eb->file, fence.handle);
+ if (!syncobj) {
+ DRM_DEBUG("Invalid syncobj handle provided\n");
+ err = -ENOENT;
+ goto err;
+ }
+
+ /*
+* For timeline syncobjs we need to preallocate chains for
+* later signaling.
+*/
+ if (point != 0 && fence.flags & I915_EXEC_FENCE_SIGNAL) {
+ /*
+* Waiting and signaling the same point (when point !=
+* 0) would break the timeline.
+*/
+ if (fence.flags & I915_EXEC_FENCE_WAIT) {
+ DRM_DEBUG("Tring
[Intel-gfx] [PATCH 1/3] drm/i915: introduce a mechanism to extend execbuf2
We're planning to use this for a couple of new feature where we need
to provide additional parameters to execbuf.
v2: Check for invalid flags in execbuffer2 (Lionel)
v3: Rename I915_EXEC_EXT -> I915_EXEC_USE_EXTENSIONS (Chris)
v4: Rebase
Move array fence parsing in i915_gem_do_execbuffer()
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson (v1)
Reviewed-by: Daniel Vetter
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 131 +++---
include/uapi/drm/i915_drm.h | 26 +++-
2 files changed, 103 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 07cb2dd0f795..ed8d1c2517f6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -26,6 +26,7 @@
#include "i915_gem_ioctls.h"
#include "i915_sw_fence_work.h"
#include "i915_trace.h"
+#include "i915_user_extensions.h"
struct eb_vma {
struct i915_vma *vma;
@@ -281,6 +282,13 @@ struct i915_execbuffer {
int lut_size;
struct hlist_head *buckets; /** ht for relocation handles */
struct eb_vma_array *array;
+
+ struct i915_eb_fence {
+ struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
+ } *fences;
+ u32 n_fences;
+
+ u64 extension_flags; /** Available extensions parameters */
};
static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
@@ -1622,7 +1630,8 @@ static int i915_gem_check_execbuffer(struct
drm_i915_gem_execbuffer2 *exec)
return -EINVAL;
/* Kernel clipping was a DRI1 misfeature */
- if (!(exec->flags & I915_EXEC_FENCE_ARRAY)) {
+ if (!(exec->flags & (I915_EXEC_FENCE_ARRAY |
+I915_EXEC_USE_EXTENSIONS))) {
if (exec->num_cliprects || exec->cliprects_ptr)
return -EINVAL;
}
@@ -2189,41 +2198,41 @@ eb_pin_engine(struct i915_execbuffer *eb,
}
static void
-__free_fence_array(struct drm_syncobj **fences, unsigned int n)
+__free_fence_array(struct i915_eb_fence *fences, unsigned int n)
{
while (n--)
- drm_syncobj_put(ptr_mask_bits(fences[n], 2));
+ drm_syncobj_put(ptr_mask_bits(fences[n].syncobj, 2));
kvfree(fences);
}
-static struct drm_syncobj **
+static int
get_fence_array(struct drm_i915_gem_execbuffer2 *args,
- struct drm_file *file)
+ struct i915_execbuffer *eb)
{
const unsigned long nfences = args->num_cliprects;
struct drm_i915_gem_exec_fence __user *user;
- struct drm_syncobj **fences;
+ struct i915_eb_fence *fences;
unsigned long n;
int err;
if (!(args->flags & I915_EXEC_FENCE_ARRAY))
- return NULL;
+ return 0;
/* Check multiplication overflow for access_ok() and kvmalloc_array() */
BUILD_BUG_ON(sizeof(size_t) > sizeof(unsigned long));
if (nfences > min_t(unsigned long,
ULONG_MAX / sizeof(*user),
SIZE_MAX / sizeof(*fences)))
- return ERR_PTR(-EINVAL);
+ return -EINVAL;
user = u64_to_user_ptr(args->cliprects_ptr);
if (!access_ok(user, nfences * sizeof(*user)))
- return ERR_PTR(-EFAULT);
+ return -EFAULT;
fences = kvmalloc_array(nfences, sizeof(*fences),
__GFP_NOWARN | GFP_KERNEL);
if (!fences)
- return ERR_PTR(-ENOMEM);
+ return -ENOMEM;
for (n = 0; n < nfences; n++) {
struct drm_i915_gem_exec_fence fence;
@@ -2239,7 +2248,7 @@ get_fence_array(struct drm_i915_gem_execbuffer2 *args,
goto err;
}
- syncobj = drm_syncobj_find(file, fence.handle);
+ syncobj = drm_syncobj_find(eb->file, fence.handle);
if (!syncobj) {
DRM_DEBUG("Invalid syncobj handle provided\n");
err = -ENOENT;
@@ -2249,38 +2258,31 @@ get_fence_array(struct drm_i915_gem_execbuffer2 *args,
BUILD_BUG_ON(~(ARCH_KMALLOC_MINALIGN - 1) &
~__I915_EXEC_FENCE_UNKNOWN_FLAGS);
- fences[n] = ptr_pack_bits(syncobj, fence.flags, 2);
+ fences[n].syncobj = ptr_pack_bits(syncobj, fence.flags, 2);
}
- return fences;
+ eb->fences = fences;
+ eb->n_fences = nfences;
+
+ return 0;
err:
__free_fence_array(fences, n);
- return ERR_PTR(err);
-}
-
-static void
-put_fence_array(struct drm_i915_gem_execbuffer2 *args,
- struct drm_syncobj **fences)
-{
- if (fences)
- __free_fence_array(fences, args->num_cliprects);
+ return err;
}
static int
-await_fence_array(struct i915_execbuffer *eb,
-
Re: [Intel-gfx] [PATCH v5 06/16] pwm: lpss: Use pwm_lpss_apply() when restoring state on resume
On Sun, Aug 02, 2020 at 10:51:34PM +0200, Hans de Goede wrote: > On 7/29/20 10:12 AM, Andy Shevchenko wrote: ... > Ok, I've added the suggested/discussed helper in my personal tree. Is it ok > if I add your Reviewed-by with that change in place. Yes, go ahead! > This is the last unreviewed > bit, so I would rather not respin the series just for this (there will be one > more respin when I rebase it on 5.9-rc1). > > If you want to check out what the patch looks like now, the new version from > my personal tree is here: > > https://github.com/jwrdegoede/linux-sunxi/commit/e4869830d88bb8cb8251718e0086ac189abc0f56 Thanks, looks good to me. -- With Best Regards, Andy Shevchenko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI] drm/i915: Filter wake_flags passed to default_wake_function
On Wed, 29 Jul 2020 at 01:21, Chris Wilson wrote:
>
> The flags passed to the wait_entry.func are passed onwards to
> try_to_wake_up(), which has a very particular interpretation for its
> wake_flags. In particular, beyond the published WF_SYNC, it has a few
> internal flags as well. Since we passed the fence->error down the chain
> via the flags argument, these ended up in the default_wake_function
> confusing the kernel/sched.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2110
> Fixes: ef4688497512 ("drm/i915: Propagate fence errors")
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
> Cc: # v5.4+
> Reviewed-by: Matthew Auld
> ---
> drivers/gpu/drm/i915/i915_sw_fence.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
> b/drivers/gpu/drm/i915/i915_sw_fence.c
> index 295b9829e2da..4cd2038cbe35 100644
> --- a/drivers/gpu/drm/i915/i915_sw_fence.c
> +++ b/drivers/gpu/drm/i915/i915_sw_fence.c
> @@ -164,9 +164,13 @@ static void __i915_sw_fence_wake_up_all(struct
> i915_sw_fence *fence,
>
> do {
> list_for_each_entry_safe(pos, next, >head, entry) {
> - pos->func(pos,
> - TASK_NORMAL, fence->error,
> - );
> + int wake_flags;
> +
> + wake_flags = fence->error;
> + if (pos->func == autoremove_wake_function)
> + wake_flags = 0;
> +
> + pos->func(pos, TASK_NORMAL, wake_flags,
> );
> }
>
> if (list_empty())
This seems to be heading for my tree at the moment, there is only one
place in the kernel where someone compares pos->func with
autoremove_wake_function, and it's in this file.
This seems horribly brittle, can we at least make this better in -next
even if we have to have this fix in fixes?
I also have to question the whole raison d'etre for i915_sw_fence,
it's initial commit says it was meant to be a core kernel struct, but
I haven't seen any effort on behalf of i915 team to make that happen,
I expect when that is attempted the whole thing will get shredded for
layering violations like the above.
Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Introduce drm scaling filter property (rev7)
== Series Details == Series: Introduce drm scaling filter property (rev7) URL : https://patchwork.freedesktop.org/series/73883/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8832_full -> Patchwork_18296_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18296_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18296_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_18296_full: ### IGT changes ### Possible regressions * igt@kms_mmap_write_crc@main: - shard-glk: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8832/shard-glk2/igt@kms_mmap_write_...@main.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18296/shard-glk3/igt@kms_mmap_write_...@main.html Known issues Here are the changes found in Patchwork_18296_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_dc@dc6-psr: - shard-skl: [PASS][3] -> [FAIL][4] ([i915#454]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8832/shard-skl5/igt@i915_pm...@dc6-psr.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18296/shard-skl10/igt@i915_pm...@dc6-psr.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8832/shard-kbl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18296/shard-kbl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_edge_walk@pipe-c-256x256-bottom-edge: - shard-skl: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +9 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8832/shard-skl6/igt@kms_cursor_edge_w...@pipe-c-256x256-bottom-edge.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18296/shard-skl2/igt@kms_cursor_edge_w...@pipe-c-256x256-bottom-edge.html * igt@kms_cursor_legacy@long-nonblocking-modeset-vs-cursor-atomic: - shard-apl: [PASS][9] -> [FAIL][10] ([i915#1181] / [i915#1635]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8832/shard-apl6/igt@kms_cursor_leg...@long-nonblocking-modeset-vs-cursor-atomic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18296/shard-apl6/igt@kms_cursor_leg...@long-nonblocking-modeset-vs-cursor-atomic.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1: - shard-skl: [PASS][11] -> [FAIL][12] ([i915#79]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8832/shard-skl6/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18296/shard-skl10/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@c-hdmi-a1: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#79]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8832/shard-glk3/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-hdmi-a1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18296/shard-glk5/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-hdmi-a1.html * igt@kms_flip@flip-vs-suspend@c-hdmi-a1: - shard-hsw: [PASS][15] -> [INCOMPLETE][16] ([i915#2055]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8832/shard-hsw1/igt@kms_flip@flip-vs-susp...@c-hdmi-a1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18296/shard-hsw2/igt@kms_flip@flip-vs-susp...@c-hdmi-a1.html * igt@kms_flip@plain-flip-ts-check-interruptible@c-edp1: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#2122]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8832/shard-skl5/igt@kms_flip@plain-flip-ts-check-interrupti...@c-edp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18296/shard-skl10/igt@kms_flip@plain-flip-ts-check-interrupti...@c-edp1.html * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-move: - shard-glk: [PASS][19] -> [FAIL][20] ([i915#49]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8832/shard-glk2/igt@kms_frontbuffer_track...@fbc-2p-primscrn-spr-indfb-move.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18296/shard-glk3/igt@kms_frontbuffer_track...@fbc-2p-primscrn-spr-indfb-move.html * igt@kms_frontbuffer_tracking@fbcpsr-modesetfrombusy: - shard-tglb: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) [21]:
