[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v6,01/11] HAX to make DSC work on the icelake test system
== Series Details == Series: series starting with [v6,01/11] HAX to make DSC work on the icelake test system URL : https://patchwork.freedesktop.org/series/79534/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8752_full -> Patchwork_18184_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18184_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18184_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_18184_full: ### IGT changes ### Possible regressions * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/shard-tglb2/igt@kms_dp_...@basic-dsc-enable-edp.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18184/shard-tglb6/igt@kms_dp_...@basic-dsc-enable-edp.html Warnings * igt@runner@aborted: - shard-tglb: ([FAIL][3], [FAIL][4], [FAIL][5]) ([i915#1764] / [i915#2110]) -> [FAIL][6] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/shard-tglb7/igt@run...@aborted.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/shard-tglb3/igt@run...@aborted.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/shard-tglb7/igt@run...@aborted.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18184/shard-tglb6/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_18184_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@bonded-early: - shard-kbl: [PASS][7] -> [FAIL][8] ([i915#2079]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/shard-kbl2/igt@gem_exec_balan...@bonded-early.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18184/shard-kbl3/igt@gem_exec_balan...@bonded-early.html * igt@gem_exec_reloc@basic-concurrent0: - shard-glk: [PASS][9] -> [FAIL][10] ([i915#1930]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/shard-glk8/igt@gem_exec_re...@basic-concurrent0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18184/shard-glk7/igt@gem_exec_re...@basic-concurrent0.html * igt@gem_exec_whisper@basic-contexts-priority-all: - shard-glk: [PASS][11] -> [DMESG-WARN][12] ([i915#118] / [i915#95]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/shard-glk2/igt@gem_exec_whis...@basic-contexts-priority-all.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18184/shard-glk6/igt@gem_exec_whis...@basic-contexts-priority-all.html * igt@gem_workarounds@suspend-resume-context: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([CI#80] / [i915#69]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/shard-skl1/igt@gem_workarou...@suspend-resume-context.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18184/shard-skl9/igt@gem_workarou...@suspend-resume-context.html * igt@kms_big_fb@x-tiled-64bpp-rotate-180: - shard-glk: [PASS][15] -> [DMESG-FAIL][16] ([i915#118] / [i915#95]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/shard-glk2/igt@kms_big...@x-tiled-64bpp-rotate-180.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18184/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-180.html * igt@kms_color@pipe-c-ctm-green-to-red: - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +10 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/shard-skl9/igt@kms_co...@pipe-c-ctm-green-to-red.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18184/shard-skl1/igt@kms_co...@pipe-c-ctm-green-to-red.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([i915#300]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/shard-skl2/igt@kms_cursor_...@pipe-b-cursor-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18184/shard-skl3/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_cursor_legacy@short-flip-after-cursor-atomic-transitions-varying-size: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#1635] / [i915#1982]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/shard-apl8/igt@kms_cursor_leg...@short-flip-after-cursor-atomic-transitions-varying-size.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18184/shard-apl6/igt@kms_cursor_leg...@short-flip-after-cursor-atomic-transitions-varying-size.html *
Re: [Intel-gfx] [PATCH] drm/i915/display: Ensure that ret is always initialized in icl_combo_phy_verify_state
On Wed, Jul 15, 2020 at 09:27:42PM -0700, Nathan Chancellor wrote:
> Clang warns:
>
> drivers/gpu/drm/i915/display/intel_combo_phy.c:268:3: warning: variable
> 'ret' is uninitialized when used here [-Wuninitialized]
> ret &= check_phy_reg(dev_priv, phy, ICL_PORT_TX_DW8_LN0(phy),
> ^~~
> drivers/gpu/drm/i915/display/intel_combo_phy.c:261:10: note: initialize
> the variable 'ret' to silence this warning
> bool ret;
> ^
> = 0
> 1 warning generated.
>
> In practice, the bug this warning appears to be concerned with would not
> actually matter because ret gets initialized to the return value of
> cnl_verify_procmon_ref_values. However, that does appear to be a bug
> since it means the first hunk of the patch this fixes won't actually do
> anything (since the values of check_phy_reg won't factor into the final
> ret value). Initialize ret to true then make all of the assignments a
> bitwise AND with itself so that the function always does what it should
> do.
>
> Fixes: 239bef676d8e ("drm/i915/display: Implement new combo phy
> initialization step")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1094
> Signed-off-by: Nathan Chancellor
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_combo_phy.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> index eccaa79cb4a9..a4b8aa6d0a9e 100644
> --- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> @@ -258,7 +258,7 @@ static bool phy_is_master(struct drm_i915_private
> *dev_priv, enum phy phy)
> static bool icl_combo_phy_verify_state(struct drm_i915_private *dev_priv,
> enum phy phy)
> {
> - bool ret;
> + bool ret = true;
> u32 expected_val = 0;
>
> if (!icl_combo_phy_enabled(dev_priv, phy))
> @@ -276,7 +276,7 @@ static bool icl_combo_phy_verify_state(struct
> drm_i915_private *dev_priv,
>DCC_MODE_SELECT_CONTINUOSLY);
> }
>
> - ret = cnl_verify_procmon_ref_values(dev_priv, phy);
> + ret &= cnl_verify_procmon_ref_values(dev_priv, phy);
>
> if (phy_is_master(dev_priv, phy)) {
> ret &= check_phy_reg(dev_priv, phy, ICL_PORT_COMP_DW8(phy),
>
> base-commit: ca0e494af5edb59002665bf12871e94b4163a257
> --
> 2.28.0.rc0
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display: Ensure that ret is always initialized in icl_combo_phy_verify_state
== Series Details ==
Series: drm/i915/display: Ensure that ret is always initialized in
icl_combo_phy_verify_state
URL : https://patchwork.freedesktop.org/series/79536/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8753 -> Patchwork_18185
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18185 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18185, 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_18185/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18185:
### IGT changes ###
Possible regressions
* igt@i915_pm_rpm@module-reload:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] +4 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8753/fi-tgl-y/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18185/fi-tgl-y/igt@i915_pm_...@module-reload.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@basic-pci-d3-state:
- {fi-tgl-dsi}: [DMESG-WARN][3] ([i915#1982]) -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8753/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18185/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- {fi-tgl-dsi}: [PASS][5] -> [DMESG-WARN][6] +4 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8753/fi-tgl-dsi/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18185/fi-tgl-dsi/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
Known issues
Here are the changes found in Patchwork_18185 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [PASS][7] -> [FAIL][8] ([i915#1888])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8753/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18185/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@kms_addfb_basic@bo-too-small:
- fi-tgl-y: [PASS][9] -> [DMESG-WARN][10] ([i915#402]) +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8753/fi-tgl-y/igt@kms_addfb_ba...@bo-too-small.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18185/fi-tgl-y/igt@kms_addfb_ba...@bo-too-small.html
Possible fixes
* igt@debugfs_test@read_all_entries:
- fi-bsw-nick:[INCOMPLETE][11] ([i915#1250] / [i915#1436]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8753/fi-bsw-nick/igt@debugfs_test@read_all_entries.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18185/fi-bsw-nick/igt@debugfs_test@read_all_entries.html
* igt@gem_exec_store@basic:
- fi-tgl-y: [DMESG-WARN][13] ([i915#402]) -> [PASS][14] +2
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8753/fi-tgl-y/igt@gem_exec_st...@basic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18185/fi-tgl-y/igt@gem_exec_st...@basic.html
* igt@i915_module_load@reload:
- fi-byt-j1900: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8753/fi-byt-j1900/igt@i915_module_l...@reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18185/fi-byt-j1900/igt@i915_module_l...@reload.html
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8753/fi-kbl-x1275/igt@i915_module_l...@reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18185/fi-kbl-x1275/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8753/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18185/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@execlists:
- fi-kbl-r: [INCOMPLETE][21] ([i915#794]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8753/fi-kbl-r/igt@i915_selftest@l...@execlists.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18185/fi-kbl-r/igt@i915_selftest@l...@execlists.html
*
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Ensure that ret is always initialized in icl_combo_phy_verify_state
== Series Details == Series: drm/i915/display: Ensure that ret is always initialized in icl_combo_phy_verify_state URL : https://patchwork.freedesktop.org/series/79536/ State : warning == Summary == $ dim checkpatch origin/drm-tip b0efac00fd8c drm/i915/display: Ensure that ret is always initialized in icl_combo_phy_verify_state -:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #11: ret &= check_phy_reg(dev_priv, phy, ICL_PORT_TX_DW8_LN0(phy), total: 0 errors, 1 warnings, 0 checks, 16 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/display: Ensure that ret is always initialized in icl_combo_phy_verify_state
Clang warns:
drivers/gpu/drm/i915/display/intel_combo_phy.c:268:3: warning: variable
'ret' is uninitialized when used here [-Wuninitialized]
ret &= check_phy_reg(dev_priv, phy, ICL_PORT_TX_DW8_LN0(phy),
^~~
drivers/gpu/drm/i915/display/intel_combo_phy.c:261:10: note: initialize
the variable 'ret' to silence this warning
bool ret;
^
= 0
1 warning generated.
In practice, the bug this warning appears to be concerned with would not
actually matter because ret gets initialized to the return value of
cnl_verify_procmon_ref_values. However, that does appear to be a bug
since it means the first hunk of the patch this fixes won't actually do
anything (since the values of check_phy_reg won't factor into the final
ret value). Initialize ret to true then make all of the assignments a
bitwise AND with itself so that the function always does what it should
do.
Fixes: 239bef676d8e ("drm/i915/display: Implement new combo phy initialization
step")
Link: https://github.com/ClangBuiltLinux/linux/issues/1094
Signed-off-by: Nathan Chancellor
---
drivers/gpu/drm/i915/display/intel_combo_phy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
b/drivers/gpu/drm/i915/display/intel_combo_phy.c
index eccaa79cb4a9..a4b8aa6d0a9e 100644
--- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
@@ -258,7 +258,7 @@ static bool phy_is_master(struct drm_i915_private
*dev_priv, enum phy phy)
static bool icl_combo_phy_verify_state(struct drm_i915_private *dev_priv,
enum phy phy)
{
- bool ret;
+ bool ret = true;
u32 expected_val = 0;
if (!icl_combo_phy_enabled(dev_priv, phy))
@@ -276,7 +276,7 @@ static bool icl_combo_phy_verify_state(struct
drm_i915_private *dev_priv,
DCC_MODE_SELECT_CONTINUOSLY);
}
- ret = cnl_verify_procmon_ref_values(dev_priv, phy);
+ ret &= cnl_verify_procmon_ref_values(dev_priv, phy);
if (phy_is_master(dev_priv, phy)) {
ret &= check_phy_reg(dev_priv, phy, ICL_PORT_COMP_DW8(phy),
base-commit: ca0e494af5edb59002665bf12871e94b4163a257
--
2.28.0.rc0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 33/60] drm/i915/lmem: support pwrite
On Wed, 15 Jul 2020 at 00:35, Matthew Auld wrote: > > On 13/07/2020 06:09, Dave Airlie wrote: > > On Fri, 10 Jul 2020 at 22:00, Matthew Auld wrote: > >> > >> We need to add support for pwrite'ing an LMEM object. > > > > why? DG1 is a discrete GPU, these interfaces we already gross and > > overly hacky for integrated, I'd prefer not to drag them across into > > discrete land. > > > > same goes for pread. > > > > You have no legacy userspace here, userspace needs change to support > > LMEM, it can be fixed to avoid legacy ioctls paths. > > Ok, there have also been similar discussions internally in the past. I > think one of the reasons was around IGT, and how keeping the > pread/pwrite interface meant slightly less pain, also it's not much > effort to implement for LMEM. If this is a NACK, then I guess the other > idea was to somehow fallback to mmap and update IGT accordingly. I just don't think we should have internal kernel interfaces for mapping ram in the kernel address space, seems pointless, makes less sense with a discrete GPU in the mix, so yes I think NAK for pread/pwrite at least at this time. I'd also like to see a hard no relocs policy for DG1 enforced in the kernel. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Implement HOBL
== Series Details == Series: drm/i915/display: Implement HOBL URL : https://patchwork.freedesktop.org/series/79525/ State : success == Summary == CI Bug Log - changes from CI_DRM_8751_full -> Patchwork_18183_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18183_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@bonded-early: - shard-kbl: [PASS][1] -> [FAIL][2] ([i915#2079]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-kbl6/igt@gem_exec_balan...@bonded-early.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18183/shard-kbl6/igt@gem_exec_balan...@bonded-early.html * igt@gem_exec_gttfill@all: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-glk7/igt@gem_exec_gttf...@all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18183/shard-glk6/igt@gem_exec_gttf...@all.html * igt@gem_exec_reloc@basic-concurrent0: - shard-glk: [PASS][5] -> [FAIL][6] ([i915#1930]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-glk3/igt@gem_exec_re...@basic-concurrent0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18183/shard-glk1/igt@gem_exec_re...@basic-concurrent0.html * igt@kms_big_fb@linear-64bpp-rotate-0: - shard-glk: [PASS][7] -> [DMESG-FAIL][8] ([i915#118] / [i915#95]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-glk3/igt@kms_big...@linear-64bpp-rotate-0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18183/shard-glk8/igt@kms_big...@linear-64bpp-rotate-0.html * igt@kms_flip@2x-flip-vs-absolute-wf_vblank@ab-hdmi-a1-hdmi-a2: - shard-glk: [PASS][9] -> [FAIL][10] ([i915#2122]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-glk7/igt@kms_flip@2x-flip-vs-absolute-wf_vbl...@ab-hdmi-a1-hdmi-a2.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18183/shard-glk1/igt@kms_flip@2x-flip-vs-absolute-wf_vbl...@ab-hdmi-a1-hdmi-a2.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu: - shard-tglb: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-tglb2/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18183/shard-tglb7/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-kbl1/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18183/shard-kbl7/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@kms_plane@plane-position-hole-pipe-a-planes: - shard-tglb: [PASS][15] -> [DMESG-WARN][16] ([i915#402]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-tglb1/igt@kms_pl...@plane-position-hole-pipe-a-planes.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18183/shard-tglb7/igt@kms_pl...@plane-position-hole-pipe-a-planes.html * igt@kms_plane_cursor@pipe-a-viewport-size-128: - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +10 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-skl8/igt@kms_plane_cur...@pipe-a-viewport-size-128.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18183/shard-skl4/igt@kms_plane_cur...@pipe-a-viewport-size-128.html * igt@kms_psr@psr2_dpms: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-iclb2/igt@kms_psr@psr2_dpms.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18183/shard-iclb5/igt@kms_psr@psr2_dpms.html Possible fixes * igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox: - shard-skl: [FAIL][21] ([i915#1528]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-skl5/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18183/shard-skl7/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html * igt@gem_exec_whisper@basic-contexts-priority-all: - shard-glk: [DMESG-WARN][23] ([i915#118] / [i915#95]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-glk3/igt@gem_exec_whis...@basic-contexts-priority-all.html [24]:
Re: [Intel-gfx] [PATCH] Revert "Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+""
On Wed, Jul 15, 2020 at 04:16:09PM -0700, Matt Atwood wrote:
> On Wed, Jul 15, 2020 at 11:27:15PM +0300, Imre Deak wrote:
> > On Wed, Jul 15, 2020 at 12:15:35PM -0700, Manasi Navare wrote:
> > > On Wed, Jul 15, 2020 at 07:29:31PM +0300, Imre Deak wrote:
> > > > The problem the reverted patch revealed could've been fixed by commit
> > > > 619ad4874585 ("drm/i915/ddi: Don't frob the DP link scramble disabling
> > > > flag")
> > > > in particular because the revealed problem (at least in one case)
> > > > happened
> > > > when switching to the TPS4 training pattern, which needs scrambling.
> > > >
> > > > Let's try applying the HBR3 fix again.
> >
> > The link training failure still happens the same way on fi-icl-u2.
> Previously this only failed on a specific TGL CI system, did you get
> failures on both this go around? ICL passed last time.
Arg, it's fi-tgl-u2, sorry for the mixup. For instance:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/fi-tgl-u2/dmesg0.txt
https://patchwork.freedesktop.org/series/79486/ would be another thing
to try.
> >
> > > >
> > > > This reverts commit d3913019602e32ef6fbba8eb0167e83250cdab22.
> > > >
> > > > Cc: Matt Atwood
> > > > Cc: Ville Syrjälä
> > > > Cc: Manasi Navare
> > > > Cc: José Roberto de Souza
> > > > Signed-off-by: Imre Deak
> > >
> > > Makes sense since the problem occured only in CI, not on
> > > the local testing done by Matt on his eDP panel.
> > >
> > > Reviewed-by: Manasi Navare
> > >
> > > Manasi
> > >
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_dp.c | 28 ++---
> > > > 1 file changed, 11 insertions(+), 17 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > index d6295eb20b63..a5ab405d3a12 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > @@ -137,6 +137,8 @@ static const u8 valid_dsc_slicecount[] = {1, 2, 4};
> > > > *
> > > > * If a CPU or PCH DP output is attached to an eDP panel, this function
> > > > * will return true, and false otherwise.
> > > > + *
> > > > + * This function is not safe to use prior to encoder type being set.
> > > > */
> > > > bool intel_dp_is_edp(struct intel_dp *intel_dp)
> > > > {
> > > > @@ -8157,8 +8159,6 @@ intel_dp_init_connector(struct intel_digital_port
> > > > *dig_port,
> > > > intel_encoder->base.name))
> > > > return false;
> > > >
> > > > - intel_dp_set_source_rates(intel_dp);
> > > > -
> > > > intel_dp->reset_link_params = true;
> > > > intel_dp->pps_pipe = INVALID_PIPE;
> > > > intel_dp->active_pipe = INVALID_PIPE;
> > > > @@ -8174,28 +8174,22 @@ intel_dp_init_connector(struct
> > > > intel_digital_port *dig_port,
> > > > */
> > > > drm_WARN_ON(dev, intel_phy_is_tc(dev_priv, phy));
> > > > type = DRM_MODE_CONNECTOR_eDP;
> > > > + intel_encoder->type = INTEL_OUTPUT_EDP;
> > > > +
> > > > + /* eDP only on port B and/or C on vlv/chv */
> > > > + if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
> > > > + IS_CHERRYVIEW(dev_priv)) &&
> > > > + port != PORT_B && port != PORT_C))
> > > > + return false;
> > > > } else {
> > > > type = DRM_MODE_CONNECTOR_DisplayPort;
> > > > }
> > > >
> > > > + intel_dp_set_source_rates(intel_dp);
> > > > +
> > > > if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > > > intel_dp->active_pipe = vlv_active_pipe(intel_dp);
> > > >
> > > > - /*
> > > > -* For eDP we always set the encoder type to INTEL_OUTPUT_EDP,
> > > > but
> > > > -* for DP the encoder type can be set by the caller to
> > > > -* INTEL_OUTPUT_UNKNOWN for DDI, so don't rewrite it.
> > > > -*/
> > > > - if (type == DRM_MODE_CONNECTOR_eDP)
> > > > - intel_encoder->type = INTEL_OUTPUT_EDP;
> > > > -
> > > > - /* eDP only on port B and/or C on vlv/chv */
> > > > - if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
> > > > - IS_CHERRYVIEW(dev_priv)) &&
> > > > - intel_dp_is_edp(intel_dp) &&
> > > > - port != PORT_B && port != PORT_C))
> > > > - return false;
> > > > -
> > > > drm_dbg_kms(_priv->drm,
> > > > "Adding %s connector on [ENCODER:%d:%s]\n",
> > > > type == DRM_MODE_CONNECTOR_eDP ? "eDP" : "DP",
> > > > --
> > > > 2.23.1
> > > >
___
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/gt: Only transfer the virtual context to the new engine if active
== Series Details == Series: drm/i915/gt: Only transfer the virtual context to the new engine if active URL : https://patchwork.freedesktop.org/series/79524/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8751_full -> Patchwork_18182_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18182_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18182_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_18182_full: ### IGT changes ### Possible regressions * igt@gem_exec_whisper@basic-fds-priority-all: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-iclb1/igt@gem_exec_whis...@basic-fds-priority-all.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18182/shard-iclb7/igt@gem_exec_whis...@basic-fds-priority-all.html Known issues Here are the changes found in Patchwork_18182_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_sync@basic-all: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-glk6/igt@gem_s...@basic-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18182/shard-glk9/igt@gem_s...@basic-all.html * igt@gen9_exec_parse@allowed-all: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#1436] / [i915#1635] / [i915#716]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-apl6/igt@gen9_exec_pa...@allowed-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18182/shard-apl8/igt@gen9_exec_pa...@allowed-all.html * igt@i915_suspend@forcewake: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([i915#636] / [i915#69]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-skl7/igt@i915_susp...@forcewake.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18182/shard-skl1/igt@i915_susp...@forcewake.html * igt@kms_big_fb@linear-64bpp-rotate-0: - shard-glk: [PASS][9] -> [DMESG-FAIL][10] ([i915#118] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-glk3/igt@kms_big...@linear-64bpp-rotate-0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18182/shard-glk8/igt@kms_big...@linear-64bpp-rotate-0.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-snb: [PASS][11] -> [DMESG-WARN][12] ([i915#42]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-snb5/igt@kms_cursor_...@pipe-b-cursor-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18182/shard-snb2/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-untiled: - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#1635] / [i915#1982]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-apl3/igt@kms_draw_...@draw-method-xrgb2101010-mmap-gtt-untiled.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18182/shard-apl8/igt@kms_draw_...@draw-method-xrgb2101010-mmap-gtt-untiled.html * igt@kms_flip@basic-plain-flip@a-edp1: - shard-skl: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +7 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-skl9/igt@kms_flip@basic-plain-f...@a-edp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18182/shard-skl5/igt@kms_flip@basic-plain-f...@a-edp1.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_8751/shard-skl10/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18182/shard-skl10/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-blt: - shard-iclb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-iclb8/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-blt.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18182/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-blt.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +3 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-kbl7/igt@kms_frontbuffer_track...@fbc-suspend.html [22]:
Re: [Intel-gfx] [PATCH] Revert "Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+""
On Wed, Jul 15, 2020 at 11:27:15PM +0300, Imre Deak wrote:
> On Wed, Jul 15, 2020 at 12:15:35PM -0700, Manasi Navare wrote:
> > On Wed, Jul 15, 2020 at 07:29:31PM +0300, Imre Deak wrote:
> > > The problem the reverted patch revealed could've been fixed by commit
> > > 619ad4874585 ("drm/i915/ddi: Don't frob the DP link scramble disabling
> > > flag")
> > > in particular because the revealed problem (at least in one case) happened
> > > when switching to the TPS4 training pattern, which needs scrambling.
> > >
> > > Let's try applying the HBR3 fix again.
>
> The link training failure still happens the same way on fi-icl-u2.
Previously this only failed on a specific TGL CI system, did you get
failures on both this go around? ICL passed last time.
>
> > >
> > > This reverts commit d3913019602e32ef6fbba8eb0167e83250cdab22.
> > >
> > > Cc: Matt Atwood
> > > Cc: Ville Syrjälä
> > > Cc: Manasi Navare
> > > Cc: José Roberto de Souza
> > > Signed-off-by: Imre Deak
> >
> > Makes sense since the problem occured only in CI, not on
> > the local testing done by Matt on his eDP panel.
> >
> > Reviewed-by: Manasi Navare
> >
> > Manasi
> >
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp.c | 28 ++---
> > > 1 file changed, 11 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index d6295eb20b63..a5ab405d3a12 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -137,6 +137,8 @@ static const u8 valid_dsc_slicecount[] = {1, 2, 4};
> > > *
> > > * If a CPU or PCH DP output is attached to an eDP panel, this function
> > > * will return true, and false otherwise.
> > > + *
> > > + * This function is not safe to use prior to encoder type being set.
> > > */
> > > bool intel_dp_is_edp(struct intel_dp *intel_dp)
> > > {
> > > @@ -8157,8 +8159,6 @@ intel_dp_init_connector(struct intel_digital_port
> > > *dig_port,
> > >intel_encoder->base.name))
> > > return false;
> > >
> > > - intel_dp_set_source_rates(intel_dp);
> > > -
> > > intel_dp->reset_link_params = true;
> > > intel_dp->pps_pipe = INVALID_PIPE;
> > > intel_dp->active_pipe = INVALID_PIPE;
> > > @@ -8174,28 +8174,22 @@ intel_dp_init_connector(struct intel_digital_port
> > > *dig_port,
> > >*/
> > > drm_WARN_ON(dev, intel_phy_is_tc(dev_priv, phy));
> > > type = DRM_MODE_CONNECTOR_eDP;
> > > + intel_encoder->type = INTEL_OUTPUT_EDP;
> > > +
> > > + /* eDP only on port B and/or C on vlv/chv */
> > > + if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
> > > + IS_CHERRYVIEW(dev_priv)) &&
> > > + port != PORT_B && port != PORT_C))
> > > + return false;
> > > } else {
> > > type = DRM_MODE_CONNECTOR_DisplayPort;
> > > }
> > >
> > > + intel_dp_set_source_rates(intel_dp);
> > > +
> > > if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > > intel_dp->active_pipe = vlv_active_pipe(intel_dp);
> > >
> > > - /*
> > > - * For eDP we always set the encoder type to INTEL_OUTPUT_EDP, but
> > > - * for DP the encoder type can be set by the caller to
> > > - * INTEL_OUTPUT_UNKNOWN for DDI, so don't rewrite it.
> > > - */
> > > - if (type == DRM_MODE_CONNECTOR_eDP)
> > > - intel_encoder->type = INTEL_OUTPUT_EDP;
> > > -
> > > - /* eDP only on port B and/or C on vlv/chv */
> > > - if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
> > > - IS_CHERRYVIEW(dev_priv)) &&
> > > - intel_dp_is_edp(intel_dp) &&
> > > - port != PORT_B && port != PORT_C))
> > > - return false;
> > > -
> > > drm_dbg_kms(_priv->drm,
> > > "Adding %s connector on [ENCODER:%d:%s]\n",
> > > type == DRM_MODE_CONNECTOR_eDP ? "eDP" : "DP",
> > > --
> > > 2.23.1
> > >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 3/5] drm/i915/rkl: Handle HTI
On Tue, Jul 07, 2020 at 05:39:14PM -0700, Souza, Jose wrote:
> On Tue, 2020-06-16 at 20:30 -0700, Matt Roper wrote:
> > If HTI (also sometimes called HDPORT) is enabled at startup, it may be
> > using some of the PHYs and DPLLs making them unavailable for general
> > usage. Let's read out the HDPORT_STATE register and avoid making use of
> > resources that HTI is already using.
> >
> > v2:
> > - Fix minor checkpatch warnings
> >
> > Bspec: 49189
> > Bspec: 53707
> > Cc: Lucas De Marchi
> > Signed-off-by: Matt Roper
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 30 ---
> > drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 21 +
> > drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 1 +
> > drivers/gpu/drm/i915/i915_drv.h | 3 ++
> > drivers/gpu/drm/i915/i915_reg.h | 6
> > 5 files changed, 57 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 6c2bb3354b86..f16512eddc58 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -46,6 +46,7 @@
> > #include "display/intel_ddi.h"
> > #include "display/intel_dp.h"
> > #include "display/intel_dp_mst.h"
> > +#include "display/intel_dpll_mgr.h"
> > #include "display/intel_dsi.h"
> > #include "display/intel_dvo.h"
> > #include "display/intel_gmbus.h"
> > @@ -16814,6 +16815,13 @@ static void intel_pps_init(struct drm_i915_private
> > *dev_priv)
> > intel_pps_unlock_regs_wa(dev_priv);
> > }
> >
> > +static bool hti_uses_phy(u32 hdport_state, enum phy phy)
> > +{
> > + return hdport_state & HDPORT_ENABLED &&
> > + (hdport_state & HDPORT_PHY_USED_DP(phy) ||
> > +hdport_state & HDPORT_PHY_USED_HDMI(phy));
> > +}
> > +
> > static void intel_setup_outputs(struct drm_i915_private *dev_priv)
> > {
> > struct intel_encoder *encoder;
> > @@ -16825,10 +16833,22 @@ static void intel_setup_outputs(struct
> > drm_i915_private *dev_priv)
> > return;
> >
> > if (IS_ROCKETLAKE(dev_priv)) {
> > - intel_ddi_init(dev_priv, PORT_A);
> > - intel_ddi_init(dev_priv, PORT_B);
> > - intel_ddi_init(dev_priv, PORT_D); /* DDI TC1 */
> > - intel_ddi_init(dev_priv, PORT_E); /* DDI TC2 */
> > + /*
> > +* If HTI (aka HDPORT) is enabled at boot, it may have taken
> > +* over some of the PHYs and made them unavailable to the
> > +* driver. In that case we should skip initializing the
> > +* corresponding outputs.
> > +*/
> > + u32 hdport_state = intel_de_read(dev_priv, HDPORT_STATE);
> > +
> > + if (!hti_uses_phy(hdport_state, PHY_A))
> > + intel_ddi_init(dev_priv, PORT_A);
> > + if (!hti_uses_phy(hdport_state, PHY_B))
> > + intel_ddi_init(dev_priv, PORT_B);
> > + if (!hti_uses_phy(hdport_state, PHY_C))
> > + intel_ddi_init(dev_priv, PORT_D); /* DDI TC1 */
> > + if (!hti_uses_phy(hdport_state, PHY_D))
> > + intel_ddi_init(dev_priv, PORT_E); /* DDI TC2 */
> > } else if (INTEL_GEN(dev_priv) >= 12) {
> > intel_ddi_init(dev_priv, PORT_A);
> > intel_ddi_init(dev_priv, PORT_B);
> > @@ -18376,6 +18396,8 @@ static void intel_modeset_readout_hw_state(struct
> > drm_device *dev)
> >
> > intel_dpll_readout_hw_state(dev_priv);
> >
> > + dev_priv->hti_pll_mask = intel_get_hti_plls(dev_priv);
>
> Why not do this in intel_shared_dpll_init()?
I think I had it that way initially, but that failed because we don't
have the runtime PM references so the hardware is powered down. I could
grab the necessary references and wake up the hardware, but it probably
makes more sense to read this out at the same time we're reading out
everything else from the registers.
But it doesn't really make sense to read the register twice (once here
and then again in intel_setup_outputs). I'll just readout the whole
register once and have it parsed in the two spots in the next version.
Matt
>
> > +
> > for_each_intel_encoder(dev, encoder) {
> > pipe = 0;
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > index b5f4d4cef682..6f59f9ec453b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > @@ -265,6 +265,24 @@ void intel_disable_shared_dpll(const struct
> > intel_crtc_state *crtc_state)
> > mutex_unlock(_priv->dpll.lock);
> > }
> >
> > +/*
> > + * HTI (aka HDPORT) may be using some of the platform's PLL's, making them
> > + * unavailable for use.
> > + */
> > +u32 intel_get_hti_plls(struct drm_i915_private *dev_priv)
>
> No need to export this function, check
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v6,01/11] HAX to make DSC work on the icelake test system
== Series Details == Series: series starting with [v6,01/11] HAX to make DSC work on the icelake test system URL : https://patchwork.freedesktop.org/series/79534/ State : success == Summary == CI Bug Log - changes from CI_DRM_8752 -> Patchwork_18184 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18184/index.html Known issues Here are the changes found in Patchwork_18184 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload: - fi-kbl-soraka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/fi-kbl-soraka/igt@i915_module_l...@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18184/fi-kbl-soraka/igt@i915_module_l...@reload.html - fi-tgl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/fi-tgl-u2/igt@i915_module_l...@reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18184/fi-tgl-u2/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18184/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-icl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18184/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@vgem_basic@sysfs: - fi-tgl-y: [PASS][9] -> [DMESG-WARN][10] ([i915#402]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/fi-tgl-y/igt@vgem_ba...@sysfs.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18184/fi-tgl-y/igt@vgem_ba...@sysfs.html Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-ilk-650: [DMESG-WARN][11] ([i915#164]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/fi-ilk-650/igt@gem_exec_susp...@basic-s3.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18184/fi-ilk-650/igt@gem_exec_susp...@basic-s3.html * igt@i915_selftest@live@execlists: - fi-cfl-8109u: [INCOMPLETE][13] -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18184/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gem_contexts: - fi-tgl-u2: [INCOMPLETE][15] ([i915#2045]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18184/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-bsw-n3050: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18184/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html - fi-bsw-kefka: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18184/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@vgem_basic@setversion: - fi-tgl-y: [DMESG-WARN][21] ([i915#402]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/fi-tgl-y/igt@vgem_ba...@setversion.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18184/fi-tgl-y/igt@vgem_ba...@setversion.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][24] ([i915#62] / [i915#92]) +5 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8752/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18184/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@kms_cursor_legacy@basic-flip-before-cursor-atomic: - fi-kbl-x1275: [DMESG-WARN][25] ([i915#62] / [i915#92]) -> [DMESG-WARN][26] ([i915#62] /
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v6,01/11] HAX to make DSC work on the icelake test system
== Series Details == Series: series starting with [v6,01/11] HAX to make DSC work on the icelake test system URL : https://patchwork.freedesktop.org/series/79534/ 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 [v6,01/11] HAX to make DSC work on the icelake test system
== Series Details ==
Series: series starting with [v6,01/11] HAX to make DSC work on the icelake
test system
URL : https://patchwork.freedesktop.org/series/79534/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
97213337456c HAX to make DSC work on the icelake test system
c5f13f63734e drm/i915: Remove hw.mode
06b1c3fee1b8 drm/i915: Add hw.pipe_mode to allow bigjoiner pipe/transcoder split
-:216: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#216: FILE: drivers/gpu/drm/i915/display/intel_display.c:13219:
+ crtc_state->hw.pipe_mode = crtc_state->hw.adjusted_mode =
crtc_state->uapi.adjusted_mode;
total: 0 errors, 0 warnings, 1 checks, 445 lines checked
7f531ea79d54 drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.
dd3180f28a31 drm/i915: Try to make bigjoiner work in atomic check
-:143: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#143: FILE: drivers/gpu/drm/i915/display/intel_display.c:13232:
+
crtc_state->bigjoiner_linked_crtc);
-:202: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#202: FILE: drivers/gpu/drm/i915/display/intel_display.c:13303:
+ crtc_state->nv12_planes = crtc_state->c8_planes =
crtc_state->update_planes = 0;
-:296: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#296: FILE: drivers/gpu/drm/i915/display/intel_display.c:14920:
+ slave = new_crtc_state->bigjoiner_linked_crtc =
-:330: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#330: FILE: drivers/gpu/drm/i915/display/intel_display.c:14954:
+ slave_crtc_state->bigjoiner = master_crtc_state->bigjoiner =
false;
-:331: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#331: FILE: drivers/gpu/drm/i915/display/intel_display.c:14955:
+ slave_crtc_state->bigjoiner_slave =
master_crtc_state->bigjoiner_slave = false;
-:332: WARNING:LONG_LINE: line length of 106 exceeds 100 columns
#332: FILE: drivers/gpu/drm/i915/display/intel_display.c:14956:
+ slave_crtc_state->bigjoiner_linked_crtc =
master_crtc_state->bigjoiner_linked_crtc = NULL;
-:332: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#332: FILE: drivers/gpu/drm/i915/display/intel_display.c:14956:
+ slave_crtc_state->bigjoiner_linked_crtc =
master_crtc_state->bigjoiner_linked_crtc = NULL;
-:387: WARNING:BRACES: braces {} are not necessary for any arm of this statement
#387: FILE: drivers/gpu/drm/i915/display/intel_display.c:15351:
+ if (new_crtc_state->bigjoiner) {
[...]
+ } else if (INTEL_GEN(dev_priv) >= 9)
[...]
else
[...]
total: 0 errors, 3 warnings, 5 checks, 401 lines checked
e1bdcad4337a drm/i915: Enable big joiner support in enable and disable
sequences.
-:172: WARNING:LONG_LINE_COMMENT: line length of 106 exceeds 100 columns
#172: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:4353:
+ /* Our own transcoder needs to be disabled when reading it in
intel_ddi_read_func_ctl() */
-:174: WARNING:LONG_LINE: line length of 104 exceeds 100 columns
#174: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:4355:
+ pipe_config->cpu_transcoder = (enum
transcoder)pipe_config->bigjoiner_linked_crtc->pipe;
-:785: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#785: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:829:
+#define PIPE_CONFIG_QUIRK_BIGJOINER_SLAVE (1<<1) /* bigjoiner slave,
partial readout */
^
total: 0 errors, 2 warnings, 1 checks, 996 lines checked
90d6f402f5d0 drm/i915: Make hardware readout work on i915.
-:33: WARNING:TABSTOP: Statements should start on a tabstop
#33: FILE: drivers/gpu/drm/i915/display/intel_display.c:3609:
+struct intel_crtc_state *crtc_state =
-:76: WARNING:LONG_LINE: line length of 111 exceeds 100 columns
#76: FILE: drivers/gpu/drm/i915/display/intel_display.c:10694:
+ (intel_de_read(dev_priv, PLANE_SURF(pipe, plane_id)) &
0xf000) == plane_config->base) {
total: 0 errors, 2 warnings, 0 checks, 118 lines checked
7298e6626786 drm/i915: Link planes in a bigjoiner configuration, v3.
-:203: ERROR:CODE_INDENT: code indent should use tabs where possible
#203: FILE: drivers/gpu/drm/i915/display/intel_display.c:12626:
+ * Setup and teardown the new bigjoiner plane mappings.$
-:204: ERROR:CODE_INDENT: code indent should use tabs where possible
#204: FILE: drivers/gpu/drm/i915/display/intel_display.c:12627:
+ */$
-:289: ERROR:CODE_INDENT: code indent should use tabs where possible
#289: FILE: drivers/gpu/drm/i915/display/intel_display.c:12708:
+ *$
-:305: WARNING:LONG_LINE: line length of 105 exceeds 100 columns
#305: FILE: drivers/gpu/drm/i915/display/intel_display.c:12722:
+ for_each_oldnew_intel_plane_in_state(state, plane,
old_plane_state, new_plane_state, i) {
[Intel-gfx] [PATCH v6 03/11] drm/i915: Add hw.pipe_mode to allow bigjoiner pipe/transcoder split
From: Maarten Lankhorst
v4:
* Manual rebase (Manasi)
v3:
* Change state to crtc_state, fix rebase err (Manasi)
v2:
* Manual Rebase (Manasi)
Signed-off-by: Maarten Lankhorst
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_display.c | 61 ---
.../drm/i915/display/intel_display_types.h| 11 ++-
drivers/gpu/drm/i915/intel_pm.c | 76 +--
3 files changed, 79 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 8652a7c6bf11..78cbfefbfa62 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -152,7 +152,7 @@ static void ilk_pch_clock_get(struct intel_crtc *crtc,
static int intel_framebuffer_init(struct intel_framebuffer *ifb,
struct drm_i915_gem_object *obj,
struct drm_mode_fb_cmd2 *mode_cmd);
-static void intel_set_pipe_timings(const struct intel_crtc_state *crtc_state);
+static void intel_set_transcoder_timings(const struct intel_crtc_state
*crtc_state);
static void intel_set_pipe_src_size(const struct intel_crtc_state *crtc_state);
static void intel_cpu_transcoder_set_m_n(const struct intel_crtc_state
*crtc_state,
const struct intel_link_m_n *m_n,
@@ -6110,18 +6110,16 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
static int skl_update_scaler_crtc(struct intel_crtc_state *crtc_state)
{
- const struct drm_display_mode *adjusted_mode =
- _state->hw.adjusted_mode;
+ const struct drm_display_mode *pipe_mode = _state->hw.pipe_mode;
int width, height;
if (crtc_state->pch_pfit.enabled) {
width = drm_rect_width(_state->pch_pfit.dst);
height = drm_rect_height(_state->pch_pfit.dst);
} else {
- width = adjusted_mode->crtc_hdisplay;
- height = adjusted_mode->crtc_vdisplay;
+ width = pipe_mode->crtc_hdisplay;
+ height = pipe_mode->crtc_vdisplay;
}
-
return skl_update_scaler(crtc_state, !crtc_state->hw.active,
SKL_CRTC_INDEX,
_state->scaler_state.scaler_id,
@@ -6901,7 +6899,7 @@ static void ilk_crtc_enable(struct intel_atomic_state
*state,
if (intel_crtc_has_dp_encoder(new_crtc_state))
intel_dp_set_m_n(new_crtc_state, M1_N1);
- intel_set_pipe_timings(new_crtc_state);
+ intel_set_transcoder_timings(new_crtc_state);
intel_set_pipe_src_size(new_crtc_state);
if (new_crtc_state->has_pch_encoder)
@@ -7046,7 +7044,7 @@ static void hsw_crtc_enable(struct intel_atomic_state
*state,
intel_encoders_pre_enable(state, crtc);
if (!transcoder_is_dsi(cpu_transcoder))
- intel_set_pipe_timings(new_crtc_state);
+ intel_set_transcoder_timings(new_crtc_state);
intel_set_pipe_src_size(new_crtc_state);
@@ -7429,7 +7427,7 @@ static void valleyview_crtc_enable(struct
intel_atomic_state *state,
if (intel_crtc_has_dp_encoder(new_crtc_state))
intel_dp_set_m_n(new_crtc_state, M1_N1);
- intel_set_pipe_timings(new_crtc_state);
+ intel_set_transcoder_timings(new_crtc_state);
intel_set_pipe_src_size(new_crtc_state);
if (IS_CHERRYVIEW(dev_priv) && pipe == PIPE_B) {
@@ -7497,7 +7495,7 @@ static void i9xx_crtc_enable(struct intel_atomic_state
*state,
if (intel_crtc_has_dp_encoder(new_crtc_state))
intel_dp_set_m_n(new_crtc_state, M1_N1);
- intel_set_pipe_timings(new_crtc_state);
+ intel_set_transcoder_timings(new_crtc_state);
intel_set_pipe_src_size(new_crtc_state);
i9xx_set_pipeconf(new_crtc_state);
@@ -7971,7 +7969,7 @@ static bool intel_crtc_supports_double_wide(const struct
intel_crtc *crtc)
static u32 ilk_pipe_pixel_rate(const struct intel_crtc_state *crtc_state)
{
- u32 pixel_rate = crtc_state->hw.adjusted_mode.crtc_clock;
+ u32 pixel_rate = crtc_state->hw.pipe_mode.crtc_clock;
unsigned int pipe_w, pipe_h, pfit_w, pfit_h;
/*
@@ -8008,7 +8006,7 @@ static void intel_crtc_compute_pixel_rate(struct
intel_crtc_state *crtc_state)
if (HAS_GMCH(dev_priv))
/* FIXME calculate proper pipe pixel rate for GMCH pfit */
crtc_state->pixel_rate =
- crtc_state->hw.adjusted_mode.crtc_clock;
+ crtc_state->hw.pipe_mode.crtc_clock;
else
crtc_state->pixel_rate =
ilk_pipe_pixel_rate(crtc_state);
@@ -8018,7 +8016,7 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
struct intel_crtc_state *pipe_config)
{
struct drm_i915_private *dev_priv =
[Intel-gfx] [PATCH v6 09/11] drm/i915: Add bigjoiner aware plane clipping checks
From: Maarten Lankhorst
We need to look at hw.fb for the framebuffer, and add the translation
for the slave_plane_state. With these changes we set the correct
rectangle on the bigjoiner slave, and don't set incorrect
src/dst/visibility on the slave plane.
v2:
* Manual rebase (Manasi)
Signed-off-by: Maarten Lankhorst
Signed-off-by: Manasi Navare
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 60 +++
.../gpu/drm/i915/display/intel_atomic_plane.h | 4 ++
drivers/gpu/drm/i915/display/intel_display.c | 19 +++---
drivers/gpu/drm/i915/display/intel_sprite.c | 21 +++
4 files changed, 80 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 5c6e72063fac..fe19cbaa83b0 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -268,6 +268,9 @@ void intel_plane_copy_uapi_to_hw_state(const struct
intel_crtc_state *crtc_state
plane_state->hw.rotation = from_plane_state->uapi.rotation;
plane_state->hw.color_encoding = from_plane_state->uapi.color_encoding;
plane_state->hw.color_range = from_plane_state->uapi.color_range;
+
+ plane_state->uapi.src = drm_plane_state_src(_plane_state->uapi);
+ plane_state->uapi.dst = drm_plane_state_dest(_plane_state->uapi);
}
void intel_plane_set_invisible(struct intel_crtc_state *crtc_state,
@@ -516,6 +519,63 @@ void i9xx_update_planes_on_crtc(struct intel_atomic_state
*state,
}
}
+int intel_atomic_plane_check_clipping(struct intel_plane_state *plane_state,
+ struct intel_crtc_state *crtc_state,
+ int min_scale, int max_scale,
+ bool can_position)
+{
+ struct drm_framebuffer *fb = plane_state->hw.fb;
+ struct drm_rect *src = _state->uapi.src;
+ struct drm_rect *dst = _state->uapi.dst;
+ unsigned int rotation = plane_state->uapi.rotation;
+ struct drm_rect clip = {};
+ int hscale, vscale;
+
+ if (!fb) {
+ plane_state->uapi.visible = false;
+ return 0;
+ }
+
+ drm_rect_rotate(src, fb->width << 16, fb->height << 16, rotation);
+
+ /* Check scaling */
+ hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
+ vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
+ if (hscale < 0 || vscale < 0) {
+ DRM_DEBUG_KMS("Invalid scaling of plane\n");
+ drm_rect_debug_print("src: ", src, true);
+ drm_rect_debug_print("dst: ", dst, false);
+ return -ERANGE;
+ }
+
+ if (crtc_state->hw.enable) {
+ clip.x2 = crtc_state->pipe_src_w;
+ clip.y2 = crtc_state->pipe_src_h;
+ }
+
+ /* right side of the image is on the slave crtc, adjust dst to match */
+ if (crtc_state->bigjoiner_slave)
+ drm_rect_translate(dst, -crtc_state->pipe_src_w, 0);
+
+ /*
+* FIXME: This might need further adjustment for seamless scaling
+* with phase information, for the 2p2 and 2p1 scenarios.
+*/
+ plane_state->uapi.visible = drm_rect_clip_scaled(src, dst, );
+
+ drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16, rotation);
+
+ if (!can_position && plane_state->uapi.visible &&
+ !drm_rect_equals(dst, )) {
+ DRM_DEBUG_KMS("Plane must cover entire CRTC\n");
+ drm_rect_debug_print("dst: ", dst, false);
+ drm_rect_debug_print("clip: ", , false);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
const struct drm_plane_helper_funcs intel_plane_helper_funcs = {
.prepare_fb = intel_prepare_plane_fb,
.cleanup_fb = intel_cleanup_plane_fb,
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
index c2a1e7c86e6c..d0a599d00ecd 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
@@ -53,6 +53,10 @@ int intel_plane_atomic_calc_changes(const struct
intel_crtc_state *old_crtc_stat
int intel_plane_calc_min_cdclk(struct intel_atomic_state *state,
struct intel_plane *plane,
bool *need_cdclk_calc);
+int intel_atomic_plane_check_clipping(struct intel_plane_state *plane_state,
+ struct intel_crtc_state *crtc_state,
+ int min_scale, int max_scale,
+ bool can_position);
void intel_plane_set_invisible(struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index
[Intel-gfx] [PATCH v6 10/11] drm/i915: Add intel_update_bigjoiner handling.
From: Maarten Lankhorst
Enabling is done in a special sequence and so should plane updates
be. Ideally the end user never notices the second pipe is used,
so use the vblank evasion to cover both pipes.
This way ideally everything will be tear free, and updates are
really atomic as userspace expects it.
This needs to be checked if it still works since lot of refactoring
in skl_commit_modeset_enables
v2:
* Manual Rebase (Manasi)
* Refactoring on intel_update_crtc and enable_crtc and removing
special trans_port_sync_update (Manasi)
Signed-off-by: Maarten Lankhorst
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_display.c | 120 +--
drivers/gpu/drm/i915/display/intel_sprite.c | 25 +++-
drivers/gpu/drm/i915/display/intel_sprite.h | 3 +-
3 files changed, 129 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index a1011414da6d..00b26863ffc6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15656,7 +15656,7 @@ static void intel_update_crtc(struct intel_atomic_state
*state,
else
i9xx_update_planes_on_crtc(state, crtc);
- intel_pipe_update_end(new_crtc_state);
+ intel_pipe_update_end(new_crtc_state, NULL);
/*
* We usually enable FIFO underrun interrupts as part of the
@@ -15754,6 +15754,52 @@ static void intel_commit_modeset_disables(struct
intel_atomic_state *state)
}
}
+static void intel_update_bigjoiner(struct intel_crtc *crtc,
+ struct intel_atomic_state *state,
+ struct intel_crtc_state *old_crtc_state,
+ struct intel_crtc_state *new_crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ bool modeset = needs_modeset(new_crtc_state);
+ struct intel_crtc *slave = new_crtc_state->bigjoiner_linked_crtc;
+ struct intel_crtc_state *new_slave_crtc_state =
+ intel_atomic_get_new_crtc_state(state, slave);
+
+ if (modeset) {
+ /* Enable slave first */
+ intel_crtc_update_active_timings(new_slave_crtc_state);
+ dev_priv->display.crtc_enable(state, slave);
+
+ /* Then master */
+ intel_crtc_update_active_timings(new_crtc_state);
+ dev_priv->display.crtc_enable(state, crtc);
+
+ /* vblanks work again, re-enable pipe CRC. */
+ intel_crtc_enable_pipe_crc(crtc);
+
+ } else {
+ intel_pre_plane_update(state, crtc);
+ intel_pre_plane_update(state, slave);
+
+ if (new_crtc_state->update_pipe)
+ intel_encoders_update_pipe(state, crtc);
+ }
+
+ /*
+* Perform vblank evasion around commit operation, and make sure to
+* commit both planes simultaneously for best results.
+*/
+ intel_pipe_update_start(new_crtc_state);
+
+ commit_pipe_config(state, crtc);
+ commit_pipe_config(state, slave);
+
+ skl_update_planes_on_crtc(state, crtc);
+ skl_update_planes_on_crtc(state, slave);
+
+ intel_pipe_update_end(new_crtc_state, new_slave_crtc_state);
+}
+
static void intel_commit_modeset_enables(struct intel_atomic_state *state)
{
struct intel_crtc_state *new_crtc_state;
@@ -15772,15 +15818,22 @@ static void intel_commit_modeset_enables(struct
intel_atomic_state *state)
static void skl_commit_modeset_enables(struct intel_atomic_state *state)
{
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
- struct intel_crtc *crtc;
+ struct intel_crtc *crtc, *slave;
struct intel_crtc_state *old_crtc_state, *new_crtc_state;
struct skl_ddb_entry entries[I915_MAX_PIPES] = {};
+ struct skl_ddb_entry new_entries[I915_MAX_PIPES] = {};
u8 update_pipes = 0, modeset_pipes = 0;
+ const struct intel_crtc_state *slave_crtc_state;
int i;
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
enum pipe pipe = crtc->pipe;
+ if (new_crtc_state->bigjoiner_slave) {
+ /* We're updated from master */
+ continue;
+ }
+
if (!new_crtc_state->hw.active)
continue;
@@ -15791,6 +15844,34 @@ static void skl_commit_modeset_enables(struct
intel_atomic_state *state)
} else {
modeset_pipes |= BIT(pipe);
}
+
+ if (new_crtc_state->bigjoiner) {
+ slave = new_crtc_state->bigjoiner_linked_crtc;
+ slave_crtc_state =
+ intel_atomic_get_new_crtc_state(state,
+
[Intel-gfx] [PATCH v6 05/11] drm/i915: Try to make bigjoiner work in atomic check
From: Maarten Lankhorst
When the clock is higher than the dotclock, try with 2 pipes enabled.
If we can enable 2, then we will go into big joiner mode, and steal
the adjacent crtc.
This only links the crtc's in software, no hardware or plane
programming is done yet. Blobs are also copied from the master's
crtc_state, so it doesn't depend at commit time on the other
crtc_state.
v3:
* Manual Rebase (Manasi)
Changes since v1:
- Rename pipe timings to transcoder timings, as they are now different.
Changes since v2:
- Rework bigjoiner checks; always disable slave when recalculating
master. No need to have a separate bigjoiner pass any more.
- Use pipe_mode instead of transcoder_mode, to clean up the code.
Signed-off-by: Maarten Lankhorst
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_atomic.c | 9 +-
drivers/gpu/drm/i915/display/intel_atomic.h | 3 +-
drivers/gpu/drm/i915/display/intel_display.c | 201 --
.../drm/i915/display/intel_display_types.h| 9 +
drivers/gpu/drm/i915/display/intel_dp.c | 22 +-
5 files changed, 211 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 630f49b7aa01..b9dcdc74a10d 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -270,14 +270,15 @@ void intel_crtc_free_hw_state(struct intel_crtc_state
*crtc_state)
intel_crtc_put_color_blobs(crtc_state);
}
-void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state)
+void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state,
+const struct intel_crtc_state *from_crtc_state)
{
drm_property_replace_blob(_state->hw.degamma_lut,
- crtc_state->uapi.degamma_lut);
+ from_crtc_state->uapi.degamma_lut);
drm_property_replace_blob(_state->hw.gamma_lut,
- crtc_state->uapi.gamma_lut);
+ from_crtc_state->uapi.gamma_lut);
drm_property_replace_blob(_state->hw.ctm,
- crtc_state->uapi.ctm);
+ from_crtc_state->uapi.ctm);
}
/**
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.h
b/drivers/gpu/drm/i915/display/intel_atomic.h
index 11146292b06f..fc556c032c8f 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic.h
@@ -43,7 +43,8 @@ struct drm_crtc_state *intel_crtc_duplicate_state(struct
drm_crtc *crtc);
void intel_crtc_destroy_state(struct drm_crtc *crtc,
struct drm_crtc_state *state);
void intel_crtc_free_hw_state(struct intel_crtc_state *crtc_state);
-void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state);
+void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state,
+const struct intel_crtc_state
*from_crtc_state);
struct drm_atomic_state *intel_atomic_state_alloc(struct drm_device *dev);
void intel_atomic_state_free(struct drm_atomic_state *state);
void intel_atomic_state_clear(struct drm_atomic_state *state);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 3ecb642805a6..955e19abb563 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8016,9 +8016,24 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
struct intel_crtc_state *pipe_config)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- const struct drm_display_mode *pipe_mode = _config->hw.pipe_mode;
+ struct drm_display_mode *pipe_mode = _config->hw.pipe_mode;
int clock_limit = dev_priv->max_dotclk_freq;
+ *pipe_mode = pipe_config->hw.adjusted_mode;
+
+ /* Adjust pipe_mode for bigjoiner, with half the horizontal mode */
+ if (pipe_config->bigjoiner) {
+ pipe_mode->crtc_clock /= 2;
+ pipe_mode->crtc_hdisplay /= 2;
+ pipe_mode->crtc_hblank_start /= 2;
+ pipe_mode->crtc_hblank_end /= 2;
+ pipe_mode->crtc_hsync_start /= 2;
+ pipe_mode->crtc_hsync_end /= 2;
+ pipe_mode->crtc_htotal /= 2;
+ pipe_mode->crtc_hskew /= 2;
+ pipe_config->pipe_src_w /= 2;
+ }
+
if (INTEL_GEN(dev_priv) < 4) {
clock_limit = dev_priv->max_cdclk_freq * 9 / 10;
@@ -8079,7 +8094,7 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
* WaPruneModeWithIncorrectHsyncOffset:ctg,elk,ilk,snb,ivb,vlv,hsw.
*/
if ((INTEL_GEN(dev_priv) > 4 || IS_G4X(dev_priv)) &&
- pipe_mode->crtc_hsync_start == pipe_mode->crtc_hdisplay)
+
[Intel-gfx] [PATCH v6 06/11] drm/i915: Enable big joiner support in enable and disable sequences.
From: Maarten Lankhorst
Make vdsc work when no output is enabled. The big joiner needs VDSC
on the slave, so enable it and set the appropriate bits.
Also update timestamping constants, because slave crtc's are not
updated in drm_atomic_helper_update_legacy_modeset_state().
This should be enough to bring up CRTC's in a big joiner configuration,
without any plane configuration on the second pipe yet.
HOWEVER, we still bring up the crtc's in the wrong order. We need to
make sure that the master crtc is brought up after the slave crtc.
This is done correctly later in this series.
The next steps are to enable planes correctly, and make sure we enable
and update both master and slave in the correct order.
v2:
* Manual rebase (Manasi)
v3:
* Rebase (Manasi)
v4:
* Rebase (Manasi)
Signed-off-by: Maarten Lankhorst
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/icl_dsi.c| 2 -
drivers/gpu/drm/i915/display/intel_ddi.c | 68 +++-
drivers/gpu/drm/i915/display/intel_display.c | 377 --
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 6 +-
drivers/gpu/drm/i915/display/intel_vdsc.c | 199 -
drivers/gpu/drm/i915/display/intel_vdsc.h | 7 +-
7 files changed, 414 insertions(+), 246 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 8c55f5bee9ab..26f7372b4c25 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1454,8 +1454,6 @@ static void gen11_dsi_get_config(struct intel_encoder
*encoder,
struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
- intel_dsc_get_config(encoder, pipe_config);
-
/* FIXME: adapt icl_ddi_clock_get() for DSI and use that? */
pipe_config->port_clock = intel_dpll_get_freq(i915,
pipe_config->shared_dpll);
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 424d59671561..dd97d725ae65 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -28,6 +28,7 @@
#include
#include "i915_drv.h"
+#include "i915_trace.h"
#include "intel_audio.h"
#include "intel_combo_phy.h"
#include "intel_connector.h"
@@ -2040,12 +2041,6 @@ static void intel_ddi_get_power_domains(struct
intel_encoder *encoder,
intel_display_power_get(dev_priv,
intel_ddi_main_link_aux_domain(dig_port));
- /*
-* VDSC power is needed when DSC is enabled
-*/
- if (crtc_state->dsc.compression_enable)
- intel_display_power_get(dev_priv,
- intel_dsc_power_domain(crtc_state));
}
void intel_ddi_enable_pipe_clock(struct intel_encoder *encoder,
@@ -3313,7 +3308,8 @@ static void tgl_ddi_pre_enable_dp(struct
intel_atomic_state *state,
/* 7.l Configure and enable FEC if needed */
intel_ddi_enable_fec(encoder, crtc_state);
- intel_dsc_enable(encoder, crtc_state);
+ if (!crtc_state->bigjoiner)
+ intel_dsc_enable(encoder, crtc_state);
}
static void hsw_ddi_pre_enable_dp(struct intel_atomic_state *state,
@@ -3384,7 +3380,8 @@ static void hsw_ddi_pre_enable_dp(struct
intel_atomic_state *state,
if (!is_mst)
intel_ddi_enable_pipe_clock(encoder, crtc_state);
- intel_dsc_enable(encoder, crtc_state);
+ if (!crtc_state->bigjoiner)
+ intel_dsc_enable(encoder, crtc_state);
}
static void intel_ddi_pre_enable_dp(struct intel_atomic_state *state,
@@ -3639,6 +3636,21 @@ static void intel_ddi_post_disable(struct
intel_atomic_state *state,
ilk_pfit_disable(old_crtc_state);
}
+ if (old_crtc_state->bigjoiner_linked_crtc) {
+ struct intel_atomic_state *state =
+ to_intel_atomic_state(old_crtc_state->uapi.state);
+ struct intel_crtc *slave =
+ old_crtc_state->bigjoiner_linked_crtc;
+ const struct intel_crtc_state *old_slave_crtc_state =
+ intel_atomic_get_old_crtc_state(state, slave);
+
+ intel_crtc_vblank_off(old_slave_crtc_state);
+ trace_intel_pipe_disable(slave);
+
+ intel_dsc_disable(old_slave_crtc_state);
+ skl_scaler_disable(old_slave_crtc_state);
+ }
+
/*
* When called from DP MST code:
* - old_conn_state will be NULL
@@ -3853,7 +3865,8 @@ static void intel_enable_ddi(struct intel_atomic_state
*state,
{
drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
- intel_ddi_enable_transcoder_func(encoder, crtc_state);
+ if (!crtc_state->bigjoiner_slave)
+
[Intel-gfx] [PATCH v6 02/11] drm/i915: Remove hw.mode
From: Maarten Lankhorst
The members in hw.mode can be used from adjusted_mode as well,
use that when available.
Some places that use hw.mode can be converted to use adjusted_mode
as well.
v2:
* Manual rebase (Manasi)
* remove the use of pipe_mode defined in patch 3 (Manasi)
v3:
* Rebase on drm-tip (Manasi)
Signed-off-by: Maarten Lankhorst
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_display.c | 29 ++-
.../drm/i915/display/intel_display_types.h| 2 +-
drivers/gpu/drm/i915/display/intel_dvo.c | 2 +-
drivers/gpu/drm/i915/display/intel_sdvo.c | 16 --
4 files changed, 23 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 729ec6e0d43a..8652a7c6bf11 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8892,9 +8892,6 @@ static void intel_get_pipe_src_size(struct intel_crtc
*crtc,
tmp = intel_de_read(dev_priv, PIPESRC(crtc->pipe));
pipe_config->pipe_src_h = (tmp & 0x) + 1;
pipe_config->pipe_src_w = ((tmp >> 16) & 0x) + 1;
-
- pipe_config->hw.mode.vdisplay = pipe_config->pipe_src_h;
- pipe_config->hw.mode.hdisplay = pipe_config->pipe_src_w;
}
void intel_mode_from_pipe_config(struct drm_display_mode *mode,
@@ -13079,7 +13076,7 @@ static void intel_dump_pipe_config(const struct
intel_crtc_state *pipe_config,
intel_dump_dp_vsc_sdp(dev_priv, _config->infoframes.vsc);
drm_dbg_kms(_priv->drm, "requested mode:\n");
- drm_mode_debug_printmodeline(_config->hw.mode);
+ drm_mode_debug_printmodeline(_config->uapi.mode);
drm_dbg_kms(_priv->drm, "adjusted mode:\n");
drm_mode_debug_printmodeline(_config->hw.adjusted_mode);
intel_dump_crtc_timings(dev_priv, _config->hw.adjusted_mode);
@@ -13221,17 +13218,17 @@ intel_crtc_copy_uapi_to_hw_state(struct
intel_crtc_state *crtc_state)
{
crtc_state->hw.enable = crtc_state->uapi.enable;
crtc_state->hw.active = crtc_state->uapi.active;
- crtc_state->hw.mode = crtc_state->uapi.mode;
crtc_state->hw.adjusted_mode = crtc_state->uapi.adjusted_mode;
intel_crtc_copy_uapi_to_hw_state_nomodeset(crtc_state);
}
-static void intel_crtc_copy_hw_to_uapi_state(struct intel_crtc_state
*crtc_state)
+static void intel_crtc_copy_hw_to_uapi_state(struct intel_crtc_state
*crtc_state,
+struct drm_display_mode *user_mode)
{
crtc_state->uapi.enable = crtc_state->hw.enable;
crtc_state->uapi.active = crtc_state->hw.active;
drm_WARN_ON(crtc_state->uapi.crtc->dev,
- drm_atomic_set_mode_for_crtc(_state->uapi,
_state->hw.mode) < 0);
+ drm_atomic_set_mode_for_crtc(_state->uapi, user_mode)
< 0);
crtc_state->uapi.adjusted_mode = crtc_state->hw.adjusted_mode;
@@ -13277,6 +13274,10 @@ intel_crtc_prepare_cleared_state(struct
intel_crtc_state *crtc_state)
memcpy(crtc_state, saved_state, sizeof(*crtc_state));
kfree(saved_state);
+ /* Clear I915_MODE_FLAG_INHERITED */
+ crtc_state->uapi.mode.private_flags = 0;
+ crtc_state->uapi.adjusted_mode.private_flags = 0;
+
intel_crtc_copy_uapi_to_hw_state(crtc_state);
return 0;
@@ -13324,7 +13325,7 @@ intel_modeset_pipe_config(struct intel_crtc_state
*pipe_config)
* computation to clearly distinguish it from the adjusted mode, which
* can be changed by the connectors in the below retry loop.
*/
- drm_mode_get_hv_timing(_config->hw.mode,
+ drm_mode_get_hv_timing(_config->hw.adjusted_mode,
_config->pipe_src_w,
_config->pipe_src_h);
@@ -18461,15 +18462,11 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
int min_cdclk = 0;
if (crtc_state->hw.active) {
- struct drm_display_mode *mode = _state->hw.mode;
+ struct drm_display_mode mode;
intel_mode_from_pipe_config(_state->hw.adjusted_mode,
crtc_state);
- *mode = crtc_state->hw.adjusted_mode;
- mode->hdisplay = crtc_state->pipe_src_w;
- mode->vdisplay = crtc_state->pipe_src_h;
-
/*
* The initial mode needs to be set in order to keep
* the atomic core happy. It wants a valid mode if the
@@ -18481,11 +18478,15 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
*/
crtc_state->inherited = true;
+ mode = crtc_state->hw.adjusted_mode;
+ mode.hdisplay =
[Intel-gfx] [PATCH v6 07/11] drm/i915: Make hardware readout work on i915.
From: Maarten Lankhorst
Unfortunately I have no way to test this, but it should be correct
if the bios sets up bigjoiner in a sane way.
Skip iterating over bigjoiner slaves, only the master has the state we
care about.
Add the width of the bigjoiner slave to the reconstructed fb.
Hide the bigjoiner slave to userspace, and double the mode on bigjoiner
master.
And last, disable bigjoiner slave from primary if reconstruction fails.
v2:
* Manual Rebase (Manasi)
Signed-off-by: Maarten Lankhorst
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_display.c | 64 +++-
1 file changed, 62 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 1cda8900d8f5..bfc5c890ab4e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3606,6 +3606,8 @@ intel_find_initial_plane_obj(struct intel_crtc
*intel_crtc,
struct intel_plane *intel_plane = to_intel_plane(primary);
struct intel_plane_state *intel_state =
to_intel_plane_state(plane_state);
+struct intel_crtc_state *crtc_state =
+to_intel_crtc_state(intel_crtc->base.state);
struct drm_framebuffer *fb;
struct i915_vma *vma;
@@ -3628,7 +3630,7 @@ intel_find_initial_plane_obj(struct intel_crtc
*intel_crtc,
if (c == _crtc->base)
continue;
- if (!to_intel_crtc(c)->active)
+ if (!to_intel_crtc_state(c->state)->uapi.active)
continue;
state = to_intel_plane_state(c->primary->state);
@@ -3650,6 +3652,11 @@ intel_find_initial_plane_obj(struct intel_crtc
*intel_crtc,
* pretend the BIOS never had it enabled.
*/
intel_plane_disable_noatomic(intel_crtc, intel_plane);
+ if (crtc_state->bigjoiner) {
+ struct intel_crtc *slave =
+ crtc_state->bigjoiner_linked_crtc;
+ intel_plane_disable_noatomic(slave,
to_intel_plane(slave->base.primary));
+ }
return;
@@ -10570,6 +10577,7 @@ static void
skl_get_initial_plane_config(struct intel_crtc *crtc,
struct intel_initial_plane_config *plane_config)
{
+ struct intel_crtc_state *crtc_state =
to_intel_crtc_state(crtc->base.state);
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_plane *plane = to_intel_plane(crtc->base.primary);
@@ -10678,6 +10686,18 @@ skl_get_initial_plane_config(struct intel_crtc *crtc,
fb->height = ((val >> 16) & 0x) + 1;
fb->width = ((val >> 0) & 0x) + 1;
+ /* add bigjoiner slave as well, if the fb stretches both */
+ if (crtc_state->bigjoiner) {
+ enum pipe bigjoiner_pipe =
crtc_state->bigjoiner_linked_crtc->pipe;
+
+ if (fb->width == crtc_state->pipe_src_w &&
+ (intel_de_read(dev_priv, PLANE_SURF(pipe, plane_id)) &
0xf000) == plane_config->base) {
+ val = intel_de_read(dev_priv,
PLANE_SIZE(bigjoiner_pipe, plane_id));
+ fb->height += ((val >> 16) & 0xfff) + 1;
+ fb->width += ((val >> 0) & 0x1fff) + 1;
+ }
+ }
+
val = intel_de_read(dev_priv, PLANE_STRIDE(pipe, plane_id));
stride_mult = skl_plane_stride_mult(fb, 0, DRM_MODE_ROTATE_0);
fb->pitches[0] = (val & 0x3ff) * stride_mult;
@@ -18474,7 +18494,8 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc,
/* Adjust the state of the output pipe according to whether we
* have active connectors/encoders. */
- if (crtc_state->hw.active && !intel_crtc_has_encoders(crtc))
+ if (crtc_state->hw.active && !intel_crtc_has_encoders(crtc) &&
+ !crtc_state->bigjoiner_slave)
intel_crtc_disable_noatomic(crtc, ctx);
if (crtc_state->hw.active || HAS_GMCH(dev_priv)) {
@@ -18751,6 +18772,9 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
struct intel_plane *plane;
int min_cdclk = 0;
+ if (crtc_state->bigjoiner_slave)
+ continue;
+
if (crtc_state->hw.active) {
struct drm_display_mode mode;
@@ -18775,6 +18799,9 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
mode.hdisplay = crtc_state->pipe_src_w;
mode.vdisplay = crtc_state->pipe_src_h;
+ if (crtc_state->bigjoiner)
+ mode.hdisplay *= 2;
+
intel_crtc_compute_pixel_rate(crtc_state);
intel_crtc_update_active_timings(crtc_state);
@@ -18825,6 +18852,39 @@ static void intel_modeset_readout_hw_state(struct
[Intel-gfx] [PATCH v6 11/11] drm/i915: Add debugfs dumping for bigjoiner, v3.
From: Maarten Lankhorst
Dump debugfs and planar links as well, this will make it easier to debug
when things go wrong.
v4:
* Rebase
Changes since v1:
- Report planar slaves as such, now that we have the plane_state switch.
Changes since v2:
- Rebase on top of the new plane format dumping
Signed-off-by: Maarten Lankhorst
Signed-off-by: Manasi Navare
---
.../drm/i915/display/intel_display_debugfs.c | 29 ++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 3644752cc5ec..5576f79f84ab 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -745,6 +745,17 @@ static void plane_rotation(char *buf, size_t bufsize,
unsigned int rotation)
rotation);
}
+static const char *plane_visibility(const struct intel_plane_state
*plane_state)
+{
+ if (plane_state->uapi.visible)
+ return "visible";
+
+ if (plane_state->planar_slave)
+ return "planar-slave";
+
+ return "hidden";
+}
+
static void intel_plane_uapi_info(struct seq_file *m, struct intel_plane
*plane)
{
const struct intel_plane_state *plane_state =
@@ -763,12 +774,22 @@ static void intel_plane_uapi_info(struct seq_file *m,
struct intel_plane *plane)
plane_rotation(rot_str, sizeof(rot_str),
plane_state->uapi.rotation);
- seq_printf(m, "\t\tuapi: fb=%d,%s,%dx%d, src=" DRM_RECT_FP_FMT ", dst="
DRM_RECT_FMT ", rotation=%s\n",
+ seq_printf(m, "\t\tuapi: fb=%d,%s,%dx%d, visible=%s, src="
DRM_RECT_FP_FMT ", dst=" DRM_RECT_FMT ", rotation=%s\n",
fb ? fb->base.id : 0, fb ? format_name.str : "n/a",
fb ? fb->width : 0, fb ? fb->height : 0,
+ plane_visibility(plane_state),
DRM_RECT_FP_ARG(),
DRM_RECT_ARG(),
rot_str);
+
+ if (plane_state->planar_linked_plane)
+ seq_printf(m, "\t\tplanar: Linked to [PLANE:%d:%s] as a %s\n",
+ plane_state->planar_linked_plane->base.base.id,
plane_state->planar_linked_plane->base.name,
+ plane_state->planar_slave ? "slave" : "master");
+ if (plane_state->bigjoiner_plane)
+ seq_printf(m, "\t\tbigjoiner: Linked to [PLANE:%d:%s] as a
%s\n",
+ plane_state->bigjoiner_plane->base.base.id,
plane_state->bigjoiner_plane->base.name,
+ plane_state->bigjoiner_slave ? "slave" : "master");
}
static void intel_plane_hw_info(struct seq_file *m, struct intel_plane *plane)
@@ -864,6 +885,12 @@ static void intel_crtc_info(struct seq_file *m, struct
intel_crtc *crtc)
intel_scaler_info(m, crtc);
}
+ if (crtc_state->bigjoiner)
+ seq_printf(m, "\tLinked to [CRTC:%d:%s] as a %s\n",
+ crtc_state->bigjoiner_linked_crtc->base.base.id,
+ crtc_state->bigjoiner_linked_crtc->base.name,
+ crtc_state->bigjoiner_slave ? "slave" : "master");
+
for_each_intel_encoder_mask(_priv->drm, encoder,
crtc_state->uapi.encoder_mask)
intel_encoder_info(m, crtc, encoder);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 04/11] drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.
From: Maarten Lankhorst
Small changes to intel_dp_mode_valid(), allow listing modes that
can only be supported in the bigjoiner configuration, which is
not supported yet.
eDP does not support bigjoiner, so do not expose bigjoiner only
modes on the eDP port.
v5:
* Increase max plane width to support 8K with bigjoiner (Maarten)
v4:
* Rebase (Manasi)
Changes since v1:
- Disallow bigjoiner on eDP.
Changes since v2:
- Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock,
and split off the downstream and source checking to its own function.
(Ville)
v3:
* Rebase (Manasi)
Signed-off-by: Manasi Navare
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/display/intel_dp.c | 119 ++-
2 files changed, 91 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 78cbfefbfa62..3ecb642805a6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -17400,7 +17400,7 @@ intel_mode_valid_max_plane_size(struct drm_i915_private
*dev_priv,
* too big for that.
*/
if (INTEL_GEN(dev_priv) >= 11) {
- plane_width_max = 5120;
+ plane_width_max = 7680;
plane_height_max = 4320;
} else {
plane_width_max = 5120;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index d6295eb20b63..fbfea99fd804 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -248,25 +248,37 @@ intel_dp_max_data_rate(int max_link_clock, int max_lanes)
return max_link_clock * max_lanes;
}
-static int
-intel_dp_downstream_max_dotclock(struct intel_dp *intel_dp)
+static int source_max_dotclock(struct intel_dp *intel_dp, bool allow_bigjoiner)
{
- struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
- struct intel_encoder *encoder = _port->base;
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct intel_encoder *encoder = _dig_port->base;
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
- int max_dotclk = dev_priv->max_dotclk_freq;
- int ds_max_dotclk;
+ if (allow_bigjoiner && INTEL_GEN(dev_priv) >= 11 &&
!intel_dp_is_edp(intel_dp))
+ return 2 * dev_priv->max_dotclk_freq;
+
+ return dev_priv->max_dotclk_freq;
+}
+
+static int downstream_max_dotclock(struct intel_dp *intel_dp)
+{
int type = intel_dp->downstream_ports[0] & DP_DS_PORT_TYPE_MASK;
if (type != DP_DS_PORT_TYPE_VGA)
- return max_dotclk;
+ return 0;
- ds_max_dotclk = drm_dp_downstream_max_clock(intel_dp->dpcd,
- intel_dp->downstream_ports);
+ return drm_dp_downstream_max_clock(intel_dp->dpcd,
+ intel_dp->downstream_ports);
+}
+
+static int
+intel_dp_max_dotclock(struct intel_dp *intel_dp, bool allow_bigjoiner)
+{
+ int max_dotclk = source_max_dotclock(intel_dp, allow_bigjoiner);
+ int ds_max_dotclk = downstream_max_dotclock(intel_dp);
if (ds_max_dotclk != 0)
- max_dotclk = min(max_dotclk, ds_max_dotclk);
+ return min(max_dotclk, ds_max_dotclk);
return max_dotclk;
}
@@ -527,7 +539,8 @@ small_joiner_ram_size_bits(struct drm_i915_private *i915)
static u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
u32 link_clock, u32 lane_count,
- u32 mode_clock, u32 mode_hdisplay)
+ u32 mode_clock, u32 mode_hdisplay,
+ bool bigjoiner)
{
u32 bits_per_pixel, max_bpp_small_joiner_ram;
int i;
@@ -545,6 +558,10 @@ static u16 intel_dp_dsc_get_output_bpp(struct
drm_i915_private *i915,
/* Small Joiner Check: output bpp <= joiner RAM (bits) / Horiz. width */
max_bpp_small_joiner_ram = small_joiner_ram_size_bits(i915) /
mode_hdisplay;
+
+ if (bigjoiner)
+ max_bpp_small_joiner_ram *= 2;
+
drm_dbg_kms(>drm, "Max small joiner bpp: %u\n",
max_bpp_small_joiner_ram);
@@ -554,6 +571,15 @@ static u16 intel_dp_dsc_get_output_bpp(struct
drm_i915_private *i915,
*/
bits_per_pixel = min(bits_per_pixel, max_bpp_small_joiner_ram);
+ if (bigjoiner) {
+ u32 max_bpp_bigjoiner =
+ i915->max_cdclk_freq * 48 /
+ intel_dp_mode_to_fec_clock(mode_clock);
+
+ DRM_DEBUG_KMS("Max big joiner bpp: %u\n", max_bpp_bigjoiner);
+ bits_per_pixel = min(bits_per_pixel, max_bpp_bigjoiner);
+ }
+
/* Error out if the
[Intel-gfx] [PATCH v6 08/11] drm/i915: Link planes in a bigjoiner configuration, v3.
From: Maarten Lankhorst
Make sure that when a plane is set in a bigjoiner mode, we will add
their counterpart to the atomic state as well. This will allow us to
make sure all state is available when planes are checked.
Because of the funny interactions with bigjoiner and planar YUV
formats, we may end up adding a lot of planes, so we have to keep
iterating until we no longer add any planes.
Also fix the atomic intel plane iterator, so things watermarks start
working automagically.
v5:
* Rebase after adding sagv support (Manasi)
v4:
* Manual rebase (Manasi)
Changes since v1:
- Rebase on top of plane_state split, cleaning up the code a lot.
- Make intel_atomic_crtc_state_for_each_plane_state() bigjoiner capable.
- Add iter macro to intel_atomic_crtc_state_for_each_plane_state() to
keep iteration working.
Changes since v2:
- Add icl_(un)set_bigjoiner_plane_links, to make it more clear where
links are made and broken.
Signed-off-by: Maarten Lankhorst
Signed-off-by: Manasi Navare
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 52 -
.../gpu/drm/i915/display/intel_atomic_plane.h | 3 +-
drivers/gpu/drm/i915/display/intel_display.c | 207 --
drivers/gpu/drm/i915/display/intel_display.h | 20 +-
.../drm/i915/display/intel_display_types.h| 11 +
drivers/gpu/drm/i915/intel_pm.c | 20 +-
6 files changed, 274 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 79032701873a..5c6e72063fac 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -246,11 +246,17 @@ static void intel_plane_clear_hw_state(struct
intel_plane_state *plane_state)
memset(_state->hw, 0, sizeof(plane_state->hw));
}
-void intel_plane_copy_uapi_to_hw_state(struct intel_plane_state *plane_state,
+void intel_plane_copy_uapi_to_hw_state(const struct intel_crtc_state
*crtc_state,
+ struct intel_plane_state *plane_state,
const struct intel_plane_state
*from_plane_state)
{
intel_plane_clear_hw_state(plane_state);
+ if (from_plane_state->uapi.crtc)
+ plane_state->hw.crtc = crtc_state->uapi.crtc;
+ else
+ plane_state->hw.crtc = NULL;
+
plane_state->hw.crtc = from_plane_state->uapi.crtc;
plane_state->hw.fb = from_plane_state->uapi.fb;
if (plane_state->hw.fb)
@@ -319,15 +325,36 @@ int intel_plane_atomic_check_with_state(const struct
intel_crtc_state *old_crtc_
}
static struct intel_crtc *
-get_crtc_from_states(const struct intel_plane_state *old_plane_state,
+get_crtc_from_states(struct intel_atomic_state *state,
+const struct intel_plane_state *old_plane_state,
const struct intel_plane_state *new_plane_state)
{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ struct intel_plane *plane = to_intel_plane(new_plane_state->uapi.plane);
+
if (new_plane_state->uapi.crtc)
return to_intel_crtc(new_plane_state->uapi.crtc);
if (old_plane_state->uapi.crtc)
return to_intel_crtc(old_plane_state->uapi.crtc);
+ if (new_plane_state->bigjoiner_slave) {
+ const struct intel_plane_state *new_master_plane_state =
+ intel_atomic_get_new_plane_state(state,
new_plane_state->bigjoiner_plane);
+
+ /* need to use uapi here, new_master_plane_state might not be
copied to hw yet */
+ if (new_master_plane_state->uapi.crtc)
+ return intel_get_crtc_for_pipe(dev_priv, plane->pipe);
+ }
+
+ if (old_plane_state->bigjoiner_slave) {
+ const struct intel_plane_state *old_master_plane_state =
+ intel_atomic_get_old_plane_state(state,
old_plane_state->bigjoiner_plane);
+
+ if (old_master_plane_state->uapi.crtc)
+ return intel_get_crtc_for_pipe(dev_priv, plane->pipe);
+ }
+
return NULL;
}
@@ -338,18 +365,33 @@ int intel_plane_atomic_check(struct intel_atomic_state
*state,
intel_atomic_get_new_plane_state(state, plane);
const struct intel_plane_state *old_plane_state =
intel_atomic_get_old_plane_state(state, plane);
+ const struct intel_plane_state *new_master_plane_state;
struct intel_crtc *crtc =
- get_crtc_from_states(old_plane_state, new_plane_state);
+ get_crtc_from_states(state, old_plane_state,
+new_plane_state);
const struct intel_crtc_state *old_crtc_state;
struct intel_crtc_state *new_crtc_state;
- intel_plane_copy_uapi_to_hw_state(new_plane_state, new_plane_state);
+ if (crtc)
+ new_crtc_state =
[Intel-gfx] [PATCH v6 01/11] HAX to make DSC work on the icelake test system
From: Maarten Lankhorst
DSC is available on the display emulator, but not set in DPCD.
Override the entries to allow bigjoiner testing.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_dp_helper.c | 4 ++--
include/drm/drm_dp_helper.h | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index a3c82e726057..d3aa9b696e31 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1434,7 +1434,7 @@ u8 drm_dp_dsc_sink_max_slice_count(const u8
dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
if (slice_cap1 & DP_DSC_4_PER_DP_DSC_SINK)
return 4;
if (slice_cap1 & DP_DSC_2_PER_DP_DSC_SINK)
- return 2;
+ return 4;
if (slice_cap1 & DP_DSC_1_PER_DP_DSC_SINK)
return 1;
} else {
@@ -1458,7 +1458,7 @@ u8 drm_dp_dsc_sink_max_slice_count(const u8
dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
if (slice_cap1 & DP_DSC_4_PER_DP_DSC_SINK)
return 4;
if (slice_cap1 & DP_DSC_2_PER_DP_DSC_SINK)
- return 2;
+ return 4;
if (slice_cap1 & DP_DSC_1_PER_DP_DSC_SINK)
return 1;
}
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index e47dc22ebf50..2cce09a37e95 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1416,6 +1416,7 @@ int drm_dp_dsc_sink_supported_input_bpcs(const u8
dsc_dpc[DP_DSC_RECEIVER_CAP_SI
static inline bool
drm_dp_sink_supports_dsc(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
{
+ return dsc_dpcd[DP_DSC_REV - DP_DSC_SUPPORT];
return dsc_dpcd[DP_DSC_SUPPORT - DP_DSC_SUPPORT] &
DP_DSC_DECOMPRESSION_IS_SUPPORTED;
}
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Revert "Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+""
== Series Details == Series: Revert "Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+"" URL : https://patchwork.freedesktop.org/series/79522/ State : success == Summary == CI Bug Log - changes from CI_DRM_8751_full -> Patchwork_18181_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18181_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@bonded-early: - shard-iclb: [PASS][1] -> [FAIL][2] ([i915#926]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-iclb1/igt@gem_exec_balan...@bonded-early.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/shard-iclb2/igt@gem_exec_balan...@bonded-early.html * igt@gem_exec_fence@parallel@vcs0: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-glk5/igt@gem_exec_fence@paral...@vcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/shard-glk3/igt@gem_exec_fence@paral...@vcs0.html * igt@i915_pm_rpm@system-suspend-execbuf: - shard-tglb: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-tglb2/igt@i915_pm_...@system-suspend-execbuf.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/shard-tglb5/igt@i915_pm_...@system-suspend-execbuf.html * igt@i915_pm_rpm@system-suspend-modeset: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([i915#151] / [i915#69]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-skl10/igt@i915_pm_...@system-suspend-modeset.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/shard-skl2/igt@i915_pm_...@system-suspend-modeset.html * igt@i915_selftest@live@execlists: - shard-apl: [PASS][9] -> [INCOMPLETE][10] ([i915#1635]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-apl8/igt@i915_selftest@l...@execlists.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/shard-apl7/igt@i915_selftest@l...@execlists.html * igt@kms_big_fb@linear-64bpp-rotate-0: - shard-glk: [PASS][11] -> [DMESG-FAIL][12] ([i915#118] / [i915#95]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-glk3/igt@kms_big...@linear-64bpp-rotate-0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/shard-glk8/igt@kms_big...@linear-64bpp-rotate-0.html * igt@kms_flip@basic-plain-flip@a-edp1: - shard-skl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +7 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-skl9/igt@kms_flip@basic-plain-f...@a-edp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/shard-skl7/igt@kms_flip@basic-plain-f...@a-edp1.html * igt@kms_flip@flip-vs-expired-vblank@c-edp1: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#79]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-skl10/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/shard-skl8/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html * igt@kms_frontbuffer_tracking@basic: - shard-iclb: [PASS][17] -> [FAIL][18] ([i915#49]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-iclb2/igt@kms_frontbuffer_track...@basic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/shard-iclb4/igt@kms_frontbuffer_track...@basic.html * igt@kms_plane@plane-position-covered-pipe-c-planes: - shard-iclb: [PASS][19] -> [FAIL][20] ([i915#247]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-iclb2/igt@kms_pl...@plane-position-covered-pipe-c-planes.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/shard-iclb4/igt@kms_pl...@plane-position-covered-pipe-c-planes.html * igt@kms_psr@psr2_dpms: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-iclb2/igt@kms_psr@psr2_dpms.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/shard-iclb3/igt@kms_psr@psr2_dpms.html * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-kbl: [PASS][23] -> [DMESG-WARN][24] ([i915#180]) +6 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/shard-kbl2/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/shard-kbl7/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html Possible fixes * igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox: - shard-skl: [FAIL][25] ([i915#1528]) -> [PASS][26] [25]:
Re: [Intel-gfx] [PATCH] Revert "Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+""
On Wed, Jul 15, 2020 at 12:15:35PM -0700, Manasi Navare wrote:
> On Wed, Jul 15, 2020 at 07:29:31PM +0300, Imre Deak wrote:
> > The problem the reverted patch revealed could've been fixed by commit
> > 619ad4874585 ("drm/i915/ddi: Don't frob the DP link scramble disabling
> > flag")
> > in particular because the revealed problem (at least in one case) happened
> > when switching to the TPS4 training pattern, which needs scrambling.
> >
> > Let's try applying the HBR3 fix again.
The link training failure still happens the same way on fi-icl-u2.
> >
> > This reverts commit d3913019602e32ef6fbba8eb0167e83250cdab22.
> >
> > Cc: Matt Atwood
> > Cc: Ville Syrjälä
> > Cc: Manasi Navare
> > Cc: José Roberto de Souza
> > Signed-off-by: Imre Deak
>
> Makes sense since the problem occured only in CI, not on
> the local testing done by Matt on his eDP panel.
>
> Reviewed-by: Manasi Navare
>
> Manasi
>
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 28 ++---
> > 1 file changed, 11 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index d6295eb20b63..a5ab405d3a12 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -137,6 +137,8 @@ static const u8 valid_dsc_slicecount[] = {1, 2, 4};
> > *
> > * If a CPU or PCH DP output is attached to an eDP panel, this function
> > * will return true, and false otherwise.
> > + *
> > + * This function is not safe to use prior to encoder type being set.
> > */
> > bool intel_dp_is_edp(struct intel_dp *intel_dp)
> > {
> > @@ -8157,8 +8159,6 @@ intel_dp_init_connector(struct intel_digital_port
> > *dig_port,
> > intel_encoder->base.name))
> > return false;
> >
> > - intel_dp_set_source_rates(intel_dp);
> > -
> > intel_dp->reset_link_params = true;
> > intel_dp->pps_pipe = INVALID_PIPE;
> > intel_dp->active_pipe = INVALID_PIPE;
> > @@ -8174,28 +8174,22 @@ intel_dp_init_connector(struct intel_digital_port
> > *dig_port,
> > */
> > drm_WARN_ON(dev, intel_phy_is_tc(dev_priv, phy));
> > type = DRM_MODE_CONNECTOR_eDP;
> > + intel_encoder->type = INTEL_OUTPUT_EDP;
> > +
> > + /* eDP only on port B and/or C on vlv/chv */
> > + if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
> > + IS_CHERRYVIEW(dev_priv)) &&
> > + port != PORT_B && port != PORT_C))
> > + return false;
> > } else {
> > type = DRM_MODE_CONNECTOR_DisplayPort;
> > }
> >
> > + intel_dp_set_source_rates(intel_dp);
> > +
> > if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > intel_dp->active_pipe = vlv_active_pipe(intel_dp);
> >
> > - /*
> > -* For eDP we always set the encoder type to INTEL_OUTPUT_EDP, but
> > -* for DP the encoder type can be set by the caller to
> > -* INTEL_OUTPUT_UNKNOWN for DDI, so don't rewrite it.
> > -*/
> > - if (type == DRM_MODE_CONNECTOR_eDP)
> > - intel_encoder->type = INTEL_OUTPUT_EDP;
> > -
> > - /* eDP only on port B and/or C on vlv/chv */
> > - if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
> > - IS_CHERRYVIEW(dev_priv)) &&
> > - intel_dp_is_edp(intel_dp) &&
> > - port != PORT_B && port != PORT_C))
> > - return false;
> > -
> > drm_dbg_kms(_priv->drm,
> > "Adding %s connector on [ENCODER:%d:%s]\n",
> > type == DRM_MODE_CONNECTOR_eDP ? "eDP" : "DP",
> > --
> > 2.23.1
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Mock the status_page.vma for the kernel_context
== Series Details == Series: drm/i915/selftests: Mock the status_page.vma for the kernel_context URL : https://patchwork.freedesktop.org/series/79521/ State : success == Summary == CI Bug Log - changes from CI_DRM_8750_full -> Patchwork_18180_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18180_full that come from known issues: ### IGT changes ### Issues hit * igt@core_setmaster@master-drop-set-user: - shard-tglb: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-tglb6/igt@core_setmas...@master-drop-set-user.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/shard-tglb8/igt@core_setmas...@master-drop-set-user.html * igt@gem_exec_fence@parallel@bcs0: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-glk1/igt@gem_exec_fence@paral...@bcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/shard-glk5/igt@gem_exec_fence@paral...@bcs0.html * igt@gen9_exec_parse@allowed-all: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#1436] / [i915#1635] / [i915#716]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-apl2/igt@gen9_exec_pa...@allowed-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/shard-apl7/igt@gen9_exec_pa...@allowed-all.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][7] -> [FAIL][8] ([i915#454]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-iclb3/igt@i915_pm...@dc6-psr.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/shard-iclb6/igt@i915_pm...@dc6-psr.html * igt@kms_cursor_edge_walk@pipe-b-128x128-left-edge: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-glk7/igt@kms_cursor_edge_w...@pipe-b-128x128-left-edge.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/shard-glk8/igt@kms_cursor_edge_w...@pipe-b-128x128-left-edge.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic: - shard-skl: [PASS][11] -> [FAIL][12] ([IGT#5]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-skl4/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/shard-skl10/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html * igt@kms_flip@basic-plain-flip@a-edp1: - shard-skl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +9 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-skl8/igt@kms_flip@basic-plain-f...@a-edp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/shard-skl2/igt@kms_flip@basic-plain-f...@a-edp1.html * igt@kms_flip@flip-vs-suspend-interruptible@b-edp1: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([i915#198]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-skl3/igt@kms_flip@flip-vs-suspend-interrupti...@b-edp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/shard-skl5/igt@kms_flip@flip-vs-suspend-interrupti...@b-edp1.html * igt@kms_flip@flip-vs-suspend@c-dp1: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +5 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-kbl4/igt@kms_flip@flip-vs-susp...@c-dp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/shard-kbl1/igt@kms_flip@flip-vs-susp...@c-dp1.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite: - shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-tglb2/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/shard-tglb2/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html * igt@kms_frontbuffer_tracking@psr-suspend: - shard-skl: [PASS][21] -> [INCOMPLETE][22] ([i915#123] / [i915#69]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-skl9/igt@kms_frontbuffer_track...@psr-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/shard-skl4/igt@kms_frontbuffer_track...@psr-suspend.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#1188]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-skl4/igt@kms_...@bpc-switch-dpms.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/shard-skl10/igt@kms_...@bpc-switch-dpms.html * igt@kms_psr@psr2_cursor_mmap_gtt: - shard-iclb: [PASS][25] -> [SKIP][26]
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/66] drm/i915: Reduce i915_request.lock contention for i915_request_wait (rev2)
== Series Details == Series: series starting with [01/66] drm/i915: Reduce i915_request.lock contention for i915_request_wait (rev2) URL : https://patchwork.freedesktop.org/series/79517/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8750_full -> Patchwork_18179_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18179_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18179_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_18179_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_8750/shard-tglb7/igt@gem_ctx_e...@basic-nohangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18179/shard-tglb5/igt@gem_ctx_e...@basic-nohangcheck.html * igt@gem_ctx_persistence@engines-queued@vecs0: - shard-iclb: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-iclb1/igt@gem_ctx_persistence@engines-que...@vecs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18179/shard-iclb3/igt@gem_ctx_persistence@engines-que...@vecs0.html Known issues Here are the changes found in Patchwork_18179_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_param@set-priority-not-supported: - shard-snb: [PASS][5] -> [SKIP][6] ([fdo#109271]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-snb4/igt@gem_ctx_pa...@set-priority-not-supported.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18179/shard-snb1/igt@gem_ctx_pa...@set-priority-not-supported.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][7] -> [FAIL][8] ([i915#454]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-iclb3/igt@i915_pm...@dc6-psr.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18179/shard-iclb6/igt@i915_pm...@dc6-psr.html * igt@kms_big_fb@x-tiled-64bpp-rotate-180: - shard-glk: [PASS][9] -> [DMESG-FAIL][10] ([i915#118] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-glk4/igt@kms_big...@x-tiled-64bpp-rotate-180.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18179/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-180.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +6 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18179/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-legacy: - shard-skl: [PASS][13] -> [FAIL][14] ([IGT#5]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-skl5/igt@kms_cursor_leg...@flip-vs-cursor-busy-crc-legacy.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18179/shard-skl6/igt@kms_cursor_leg...@flip-vs-cursor-busy-crc-legacy.html * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-ytiled: - shard-glk: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-glk5/igt@kms_draw_...@draw-method-xrgb2101010-mmap-gtt-ytiled.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18179/shard-glk3/igt@kms_draw_...@draw-method-xrgb2101010-mmap-gtt-ytiled.html * igt@kms_flip@basic-plain-flip@a-edp1: - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +9 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-skl8/igt@kms_flip@basic-plain-f...@a-edp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18179/shard-skl5/igt@kms_flip@basic-plain-f...@a-edp1.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#79]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-skl5/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18179/shard-skl6/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@c-dp1: - shard-apl: [PASS][21] -> [FAIL][22] ([i915#1635] / [i915#79]) [21]:
Re: [Intel-gfx] [PATCH] drm/i915: Be wary of data races when reading the active execlists
Quoting Chris Wilson (2020-07-10 18:10:01)
> [ 1413.563200] BUG: KCSAN: data-race in __await_execution+0x217/0x370 [i915]
> [ 1413.563221]
> [ 1413.563236] race at unknown origin, with read to 0x5bb6c478 of 8
> bytes by task 9654 on cpu 1:
> [ 1413.563548] __await_execution+0x217/0x370 [i915]
> [ 1413.563891] i915_request_await_dma_fence+0x4eb/0x6a0 [i915]
> [ 1413.564235] i915_request_await_object+0x421/0x490 [i915]
> [ 1413.564577] i915_gem_do_execbuffer+0x29b7/0x3c40 [i915]
> [ 1413.564967] i915_gem_execbuffer2_ioctl+0x22f/0x5c0 [i915]
> [ 1413.564998] drm_ioctl_kernel+0x156/0x1b0
> [ 1413.565022] drm_ioctl+0x2ff/0x480
> [ 1413.565046] __x64_sys_ioctl+0x87/0xd0
> [ 1413.565069] do_syscall_64+0x4d/0x80
> [ 1413.565094] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> To complicate matters, we have to both avoid the read tearing of *active
> and avoid any write tearing as perform the pending[] -> inflight[]
> promotion of the execlists.
>
> Fixes: b55230e5e800 ("drm/i915: Check for awaits on still currently executing
> requests")
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
KCSAN reminds me this is still possible.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+""
On Wed, Jul 15, 2020 at 07:29:31PM +0300, Imre Deak wrote:
> The problem the reverted patch revealed could've been fixed by commit
> 619ad4874585 ("drm/i915/ddi: Don't frob the DP link scramble disabling flag")
> in particular because the revealed problem (at least in one case) happened
> when switching to the TPS4 training pattern, which needs scrambling.
>
> Let's try applying the HBR3 fix again.
>
> This reverts commit d3913019602e32ef6fbba8eb0167e83250cdab22.
>
> Cc: Matt Atwood
> Cc: Ville Syrjälä
> Cc: Manasi Navare
> Cc: José Roberto de Souza
> Signed-off-by: Imre Deak
Makes sense since the problem occured only in CI, not on
the local testing done by Matt on his eDP panel.
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 28 ++---
> 1 file changed, 11 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index d6295eb20b63..a5ab405d3a12 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -137,6 +137,8 @@ static const u8 valid_dsc_slicecount[] = {1, 2, 4};
> *
> * If a CPU or PCH DP output is attached to an eDP panel, this function
> * will return true, and false otherwise.
> + *
> + * This function is not safe to use prior to encoder type being set.
> */
> bool intel_dp_is_edp(struct intel_dp *intel_dp)
> {
> @@ -8157,8 +8159,6 @@ intel_dp_init_connector(struct intel_digital_port
> *dig_port,
>intel_encoder->base.name))
> return false;
>
> - intel_dp_set_source_rates(intel_dp);
> -
> intel_dp->reset_link_params = true;
> intel_dp->pps_pipe = INVALID_PIPE;
> intel_dp->active_pipe = INVALID_PIPE;
> @@ -8174,28 +8174,22 @@ intel_dp_init_connector(struct intel_digital_port
> *dig_port,
>*/
> drm_WARN_ON(dev, intel_phy_is_tc(dev_priv, phy));
> type = DRM_MODE_CONNECTOR_eDP;
> + intel_encoder->type = INTEL_OUTPUT_EDP;
> +
> + /* eDP only on port B and/or C on vlv/chv */
> + if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
> + IS_CHERRYVIEW(dev_priv)) &&
> + port != PORT_B && port != PORT_C))
> + return false;
> } else {
> type = DRM_MODE_CONNECTOR_DisplayPort;
> }
>
> + intel_dp_set_source_rates(intel_dp);
> +
> if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> intel_dp->active_pipe = vlv_active_pipe(intel_dp);
>
> - /*
> - * For eDP we always set the encoder type to INTEL_OUTPUT_EDP, but
> - * for DP the encoder type can be set by the caller to
> - * INTEL_OUTPUT_UNKNOWN for DDI, so don't rewrite it.
> - */
> - if (type == DRM_MODE_CONNECTOR_eDP)
> - intel_encoder->type = INTEL_OUTPUT_EDP;
> -
> - /* eDP only on port B and/or C on vlv/chv */
> - if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
> - IS_CHERRYVIEW(dev_priv)) &&
> - intel_dp_is_edp(intel_dp) &&
> - port != PORT_B && port != PORT_C))
> - return false;
> -
> drm_dbg_kms(_priv->drm,
> "Adding %s connector on [ENCODER:%d:%s]\n",
> type == DRM_MODE_CONNECTOR_eDP ? "eDP" : "DP",
> --
> 2.23.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2] drm/i915: Remove i915_request.lock requirement for execution callbacks (rev2)
== Series Details == Series: series starting with [v2] drm/i915: Remove i915_request.lock requirement for execution callbacks (rev2) URL : https://patchwork.freedesktop.org/series/79467/ State : success == Summary == CI Bug Log - changes from CI_DRM_8750_full -> Patchwork_18178_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18178_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_gttfill@all: - shard-glk: [PASS][1] -> [DMESG-WARN][2] ([i915#118] / [i915#95]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-glk9/igt@gem_exec_gttf...@all.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/shard-glk1/igt@gem_exec_gttf...@all.html * igt@gen9_exec_parse@allowed-all: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#1436] / [i915#1635] / [i915#716]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-apl2/igt@gen9_exec_pa...@allowed-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/shard-apl8/igt@gen9_exec_pa...@allowed-all.html * igt@i915_module_load@reload: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#1635] / [i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-apl1/igt@i915_module_l...@reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/shard-apl8/igt@i915_module_l...@reload.html * igt@kms_atomic_interruptible@universal-setplane-primary: - shard-snb: [PASS][7] -> [SKIP][8] ([fdo#109271]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-snb2/igt@kms_atomic_interrupti...@universal-setplane-primary.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/shard-snb6/igt@kms_atomic_interrupti...@universal-setplane-primary.html * igt@kms_big_fb@y-tiled-64bpp-rotate-180: - shard-glk: [PASS][9] -> [DMESG-FAIL][10] ([i915#118] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-glk7/igt@kms_big...@y-tiled-64bpp-rotate-180.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-180.html * igt@kms_flip@basic-plain-flip@a-edp1: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +11 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-skl8/igt@kms_flip@basic-plain-f...@a-edp1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/shard-skl4/igt@kms_flip@basic-plain-f...@a-edp1.html * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-kbl6/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/shard-kbl7/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html * igt@kms_flip@plain-flip-fb-recreate@c-edp1: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#2122]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-skl4/igt@kms_flip@plain-flip-fb-recre...@c-edp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/shard-skl4/igt@kms_flip@plain-flip-fb-recre...@c-edp1.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-blt: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-kbl6/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-blt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/shard-kbl7/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-blt.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#1188]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-skl4/igt@kms_...@bpc-switch-dpms.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/shard-skl9/igt@kms_...@bpc-switch-dpms.html * igt@kms_plane_cursor@pipe-b-overlay-size-128: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#78]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-kbl3/igt@kms_plane_cur...@pipe-b-overlay-size-128.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/shard-kbl2/igt@kms_plane_cur...@pipe-b-overlay-size-128.html * igt@kms_psr@psr2_cursor_mmap_gtt: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_gtt.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/shard-iclb3/igt@kms_psr@psr2_cursor_mmap_gtt.html *
Re: [Intel-gfx] [PATCH v2 00/59] Add support for KeemBay DRM driver
Hi Sam and Daniel, Thank you very much for reviewing the code. I will squish all the commits and send version 3, so it will be easier for you to review. Anitha > -Original Message- > From: Sam Ravnborg > Sent: Wednesday, July 15, 2020 10:07 AM > To: Daniel Vetter > Cc: Chrisanthus, Anitha ; Vetter, Daniel > ; intel-gfx@lists.freedesktop.org; Dea, Edmund J > ; dri-de...@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH v2 00/59] Add support for KeemBay DRM driver > > On Wed, Jul 15, 2020 at 05:05:49PM +0200, Daniel Vetter wrote: > > Hi Anitha > > > > On Tue, Jul 14, 2020 at 01:56:46PM -0700, Anitha Chrisanthus wrote: > > > 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/ > > > > Cool, new driver, thanks a lot for submitting. > > > > > 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 (will be updated to use > > > devm_drm_dev_alloc() in a separate patch later as kmb driver is > > > currently > > > developed on 5.4 kernel) > > > > drm moves fairly quickly, please develop the upstream submission on top of > > linux-next or similar. We constantly add new helpers to simplify drivers, > > and we expect new driver submissions to be up to date with all that. > Seconded! > > > > > Another thing: From your description it sounds like it's a very simple > > driver, just a single plane/crtc, nothing fancy, plus adv bridge output. > > Is the driver already using simple display pipeline helpers? I think that > > would be an ideal fit and probably greatly simplifies the code. > > > > > - minor cleanups > > > > The patch series looks like it contains the entire development history, or > > at least large chunks of it. That's useful for you, but for upstreaming > > the main focues (especially for smaller drivers) is whether your driver > > uses all the available helpers and integrations correctly. And for that > > it's much easier if the history is cleaned up, and all intermediate steps > > removed. > And also agree on this point. > The submission could be split up in a few patches where the split is > file based. So only with the latest patch, containing Makefile + > Kconfig,the driver i buildable. > This would ease review as one looses focus when trying to review 1000+ > lines in one mail. > > You will loose some of the internal history - but if important keep > relevant parts in sensible comments. > > Sam ___ 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/display: Implement HOBL
== Series Details == Series: drm/i915/display: Implement HOBL URL : https://patchwork.freedesktop.org/series/79525/ State : success == Summary == CI Bug Log - changes from CI_DRM_8751 -> Patchwork_18183 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18183/index.html Known issues Here are the changes found in Patchwork_18183 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0: - fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18183/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html * igt@i915_selftest@live@execlists: - fi-kbl-guc: [PASS][3] -> [INCOMPLETE][4] ([i915#794]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-kbl-guc/igt@i915_selftest@l...@execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18183/fi-kbl-guc/igt@i915_selftest@l...@execlists.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-bsw-n3050: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18183/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_cursor_legacy@basic-flip-after-cursor-legacy: - fi-icl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18183/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-tgl-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#402]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18183/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html * igt@vgem_basic@setversion: - fi-tgl-y: [PASS][11] -> [DMESG-WARN][12] ([i915#402]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-tgl-y/igt@vgem_ba...@setversion.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18183/fi-tgl-y/igt@vgem_ba...@setversion.html Possible fixes * igt@i915_module_load@reload: - fi-tgl-u2: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-tgl-u2/igt@i915_module_l...@reload.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18183/fi-tgl-u2/igt@i915_module_l...@reload.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18183/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html * igt@kms_frontbuffer_tracking@basic: - fi-tgl-y: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18183/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html * igt@vgem_basic@dmabuf-export: - fi-tgl-y: [DMESG-WARN][19] ([i915#402]) -> [PASS][20] +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-tgl-y/igt@vgem_ba...@dmabuf-export.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18183/fi-tgl-y/igt@vgem_ba...@dmabuf-export.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][21] ([i915#1982] / [i915#62] / [i915#92]) -> [DMESG-WARN][22] ([i915#62] / [i915#92]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18183/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@kms_force_connector_basic@force-connector-state: - fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][24] ([i915#62] / [i915#92]) +3 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html [24]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/display: Implement HOBL
== Series Details == Series: drm/i915/display: Implement HOBL URL : https://patchwork.freedesktop.org/series/79525/ 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.BAT: success for drm/i915/gt: Only transfer the virtual context to the new engine if active
== Series Details ==
Series: drm/i915/gt: Only transfer the virtual context to the new engine if
active
URL : https://patchwork.freedesktop.org/series/79524/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8751 -> Patchwork_18182
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18182/index.html
Known issues
Here are the changes found in Patchwork_18182 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18182/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@gem_flink_basic@flink-lifetime:
- fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18182/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18182/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Possible fixes
* igt@i915_module_load@reload:
- fi-tgl-u2: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-tgl-u2/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18182/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18182/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- 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_8751/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18182/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
* igt@kms_frontbuffer_tracking@basic:
- fi-tgl-y: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18182/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html
* igt@vgem_basic@dmabuf-export:
- fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16] +2
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-tgl-y/igt@vgem_ba...@dmabuf-export.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18182/fi-tgl-y/igt@vgem_ba...@dmabuf-export.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#1982] / [i915#62] /
[i915#92]) -> [DMESG-WARN][18] ([i915#62] / [i915#92])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18182/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- 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_8751/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18182/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) ->
[DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18182/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1982]:
[Intel-gfx] [PATCH CI] drm/i915/display: Implement HOBL
Hours Of Battery Life is a new GEN12+ power-saving feature that allows
supported motherboards to use a special voltage swing table for eDP
panels that uses less power.
So here if supported by HW, OEM will set it in VBT and i915 will try
to train link with HOBL vswing table if link training fails it fall
back to the original table.
intel_ddi_dp_preemph_max() was optimized to only check the HOBL flag
instead of do something like is done in intel_ddi_dp_voltage_max()
because it is only called after the first entry of the voltage swing
table was loaded so the HOBL flag is valid at that point.
v3:
- removed a few parameters of icl_ddi_combo_vswing_program() that
can be taken from encoder
v4:
- using the HOBL vswing table until training fails completely (Ville)
v5:
- not reducing lane or link rate when link training fails with HOBL
active
- duplicated the HOBL voltage swing entry to match DP spec requirement
v6:
- removed the optional VS 3 & pre-emp 0 from HOBL table
- changed from u8:1 to bool to store hobl_failed/active
BSpec: 49291
BSpec: 49399
Reviewed-by: Ville Syrjälä
Cc: Ville Syrjälä
Cc: Animesh Manna
Cc: Manasi Navare
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 43 +++
.../drm/i915/display/intel_display_types.h| 3 ++
.../drm/i915/display/intel_dp_link_training.c | 19 +---
drivers/gpu/drm/i915/i915_reg.h | 2 +
4 files changed, 61 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 424d59671561..c52ad5ecb645 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -706,6 +706,28 @@ static const struct cnl_ddi_buf_trans
tgl_combo_phy_ddi_translations_dp_hbr2[] =
{ 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
};
+/*
+ * Cloned the HOBL entry to comply with the voltage and pre-emphasis entries
+ * that DisplayPort specification requires
+ */
+static const struct cnl_ddi_buf_trans
tgl_combo_phy_ddi_translations_edp_hbr2_hobl[] = {
+ /* VS pre-emp */
+ { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 00 */
+ { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 01 */
+ { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 02 */
+ { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 03 */
+ { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 10 */
+ { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 11 */
+ { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 12 */
+ { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 20 */
+ { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 21 */
+};
+
+static bool is_hobl_buf_trans(const struct cnl_ddi_buf_trans *table)
+{
+ return table == tgl_combo_phy_ddi_translations_edp_hbr2_hobl;
+}
+
static const struct ddi_buf_trans *
bdw_get_buf_trans_edp(struct intel_encoder *encoder, int *n_entries)
{
@@ -1050,6 +1072,18 @@ static const struct cnl_ddi_buf_trans *
tgl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
int *n_entries)
{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+
+ if (type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp.hobl) {
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+ if (!intel_dp->hobl_failed && rate <= 54) {
+ /* Same table applies to TGL, RKL and DG1 */
+ *n_entries =
ARRAY_SIZE(tgl_combo_phy_ddi_translations_edp_hbr2_hobl);
+ return tgl_combo_phy_ddi_translations_edp_hbr2_hobl;
+ }
+ }
+
if (type == INTEL_OUTPUT_HDMI || type == INTEL_OUTPUT_EDP) {
return icl_get_combo_buf_trans(encoder, type, rate, n_entries);
} else if (rate > 27) {
@@ -2392,6 +2426,15 @@ static void icl_ddi_combo_vswing_program(struct
intel_encoder *encoder,
level = n_entries - 1;
}
+ if (type == INTEL_OUTPUT_EDP) {
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+ val = EDP4K2K_MODE_OVRD_EN | EDP4K2K_MODE_OVRD_OPTIMIZED;
+ intel_dp->hobl_active = is_hobl_buf_trans(ddi_translations);
+ intel_de_rmw(dev_priv, ICL_PORT_CL_DW10(phy), val,
+intel_dp->hobl_active ? val : 0);
+ }
+
/* Set PORT_TX_DW5 */
val = intel_de_read(dev_priv, ICL_PORT_TX_DW5_LN0(phy));
val &= ~(SCALING_MODE_SEL_MASK | RTERM_SELECT_MASK |
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index e8f809161c75..f581260e8dbf 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1375,6 +1375,9 @@ struct intel_dp {
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Only transfer the virtual context to the new engine if active
== Series Details ==
Series: drm/i915/gt: Only transfer the virtual context to the new engine if
active
URL : https://patchwork.freedesktop.org/series/79524/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f736e550c1ab drm/i915/gt: Only transfer the virtual context to the new engine
if active
-:30: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#30:
References: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine"
-:30: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 6d06779e8672 ("drm/i915: Load
balancing across a virtual engine")'
#30:
References: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine"
total: 1 errors, 1 warnings, 0 checks, 92 lines checked
___
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/gt: Only transfer the virtual context to the new engine if active
== Series Details == Series: drm/i915/gt: Only transfer the virtual context to the new engine if active URL : https://patchwork.freedesktop.org/series/79524/ 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.BAT: success for Revert "Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+""
== Series Details == Series: Revert "Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+"" URL : https://patchwork.freedesktop.org/series/79522/ State : success == Summary == CI Bug Log - changes from CI_DRM_8751 -> Patchwork_18181 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/index.html Known issues Here are the changes found in Patchwork_18181 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 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html * igt@i915_module_load@reload: - fi-byt-j1900: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-byt-j1900/igt@i915_module_l...@reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/fi-byt-j1900/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@module-reload: - fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-tgl-y/igt@i915_pm_...@module-reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/fi-tgl-y/igt@i915_pm_...@module-reload.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-bsw-n3050: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@vgem_basic@setversion: - fi-tgl-y: [PASS][9] -> [DMESG-WARN][10] ([i915#402]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-tgl-y/igt@vgem_ba...@setversion.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/fi-tgl-y/igt@vgem_ba...@setversion.html Possible fixes * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_frontbuffer_tracking@basic: - fi-tgl-y: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html * igt@vgem_basic@dmabuf-export: - fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16] +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-tgl-y/igt@vgem_ba...@dmabuf-export.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/fi-tgl-y/igt@vgem_ba...@dmabuf-export.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][17] ([i915#1982] / [i915#62] / [i915#92]) -> [DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [SKIP][19] ([fdo#109271]) -> [DMESG-FAIL][20] ([i915#62] / [i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/fi-kbl-x1275/igt@i915_pm_...@module-reload.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][22] ([i915#62] / [i915#92]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18181/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@prime_vgem@basic-fence-flip: - fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) -> [DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8751/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html [24]:
[Intel-gfx] [PATCH] drm/i915/gt: Only transfer the virtual context to the new engine if active
One more complication of preempt-to-busy with respect to the virtual
engine is that we may have retired the last request along the virtual
engine at the same time as preparing to submit the completed request to
a new engine. That submit will be shortcircuited, but not before we have
updated the context with the new register offsets and marked the virtual
engine as bound to the new engine (by calling swap on ve->siblings[]).
As we may have just retired the completed request, we may also be in the
middle of calling intel_context_exit() to turn off the power management
associated with the virtual engine, and that in turn walks the
ve->siblings[]. If we happen to call swap() on the array as we walk, we
will call intel_engine_pm_put() twice on the same engine.
In this patch, we prevent this by only updating the bound engine after a
successful submission which weeds out the already completed requests.
A simple method for handling the breadcrumbs across engine switches is
left as an exercise for the reader.
Alternatively, we could walk a non-volatile array for the pm, such as
using the engine->mask. The small advantage to performing the update
after the submit is that we then only have to do a swap for active
requests.
Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
References: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine"
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: "Nayana, Venkata Ramana"
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 70 -
1 file changed, 38 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e0280a672f1d..d9ea13fbf1f7 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1819,8 +1819,12 @@ static bool virtual_matches(const struct virtual_engine
*ve,
return true;
}
-static void virtual_xfer_breadcrumbs(struct virtual_engine *ve)
+static void virtual_xfer_breadcrumbs(struct virtual_engine *ve,
+struct intel_engine_cs *engine)
{
+ if (likely(engine == ve->siblings[0]))
+ return;
+
/*
* All the outstanding signals on ve->siblings[0] must have
* been completed, just pending the interrupt handler. As those
@@ -1828,7 +1832,36 @@ static void virtual_xfer_breadcrumbs(struct
virtual_engine *ve)
* transfer those to the old irq_worker to keep our locking
* consistent.
*/
- intel_engine_transfer_stale_breadcrumbs(ve->siblings[0], >context);
+ if (!list_empty(>context.signals))
+ intel_engine_transfer_stale_breadcrumbs(ve->siblings[0],
+ >context);
+}
+
+static void virtual_xfer_context(struct virtual_engine *ve,
+struct intel_engine_cs *engine)
+{
+ unsigned int n;
+
+ if (likely(engine == ve->siblings[0]))
+ return;
+
+ GEM_BUG_ON(READ_ONCE(ve->context.inflight));
+ if (!intel_engine_has_relative_mmio(engine))
+ virtual_update_register_offsets(ve->context.lrc_reg_state,
+ engine);
+
+ /*
+* Move the bound engine to the top of the list for
+* future execution. We then kick this tasklet first
+* before checking others, so that we preferentially
+* reuse this set of bound registers.
+*/
+ for (n = 1; n < ve->num_siblings; n++) {
+ if (ve->siblings[n] == engine) {
+ swap(ve->siblings[n], ve->siblings[0]);
+ break;
+ }
+ }
}
#define for_each_waiter(p__, rq__) \
@@ -2270,39 +2303,12 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
GEM_BUG_ON(!(rq->execution_mask & engine->mask));
WRITE_ONCE(rq->engine, engine);
+ virtual_xfer_breadcrumbs(ve, engine);
- if (engine != ve->siblings[0]) {
- u32 *regs = ve->context.lrc_reg_state;
- unsigned int n;
-
- GEM_BUG_ON(READ_ONCE(ve->context.inflight));
-
- if (!intel_engine_has_relative_mmio(engine))
- virtual_update_register_offsets(regs,
- engine);
-
- if (!list_empty(>context.signals))
- virtual_xfer_breadcrumbs(ve);
-
- /*
-* Move the bound engine to the top of the list
-* for future execution. We then kick this
-* tasklet first before checking others, so that
-* we
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Revert "Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+""
== Series Details == Series: Revert "Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+"" URL : https://patchwork.freedesktop.org/series/79522/ 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 Revert "Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+""
== Series Details ==
Series: Revert "Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+""
URL : https://patchwork.freedesktop.org/series/79522/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
16afab03b437 Revert "Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+""
-:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#11:
619ad4874585 ("drm/i915/ddi: Don't frob the DP link scramble disabling flag")
total: 0 errors, 1 warnings, 0 checks, 53 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-fixes
Hi Dave and Daniel, here is the PR for the current drm-misc-fixes. The aspeed fix is only about dmesg noise. The dmabuf locking appears to be a real bug. Best regards Thomas drm-misc-fixes-2020-07-15: * aspeed: setup fbdev console after registering device; avoids warning and stacktrace in dmesg log * dmabuf: protect dmabuf->name with a spinlock; avoids sleeping in atomic context The following changes since commit 00debf8109e5fad3db31375be2a3c515e1461b4a: drm/hisilicon/hibmc: Move drm_fbdev_generic_setup() down to avoid the splat (2020-07-08 09:08:22 +) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2020-07-15 for you to fetch changes up to 6348dd291e3653534a9e28e6917569bc9967b35b: dmabuf: use spinlock to access dmabuf->name (2020-07-10 15:39:29 +0530) * aspeed: setup fbdev console after registering device; avoids warning and stacktrace in dmesg log * dmabuf: protect dmabuf->name with a spinlock; avoids sleeping in atomic context Charan Teja Kalla (1): dmabuf: use spinlock to access dmabuf->name Guenter Roeck (1): drm/aspeed: Call drm_fbdev_generic_setup after drm_dev_register drivers/dma-buf/dma-buf.c | 11 +++ drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 3 +-- include/linux/dma-buf.h | 1 + 3 files changed, 9 insertions(+), 6 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 00/59] Add support for KeemBay DRM driver
On Wed, Jul 15, 2020 at 05:05:49PM +0200, Daniel Vetter wrote: > Hi Anitha > > On Tue, Jul 14, 2020 at 01:56:46PM -0700, Anitha Chrisanthus wrote: > > 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/ > > Cool, new driver, thanks a lot for submitting. > > > 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 (will be updated to use > > devm_drm_dev_alloc() in a separate patch later as kmb driver is currently > > developed on 5.4 kernel) > > drm moves fairly quickly, please develop the upstream submission on top of > linux-next or similar. We constantly add new helpers to simplify drivers, > and we expect new driver submissions to be up to date with all that. Seconded! > > Another thing: From your description it sounds like it's a very simple > driver, just a single plane/crtc, nothing fancy, plus adv bridge output. > Is the driver already using simple display pipeline helpers? I think that > would be an ideal fit and probably greatly simplifies the code. > > > - minor cleanups > > The patch series looks like it contains the entire development history, or > at least large chunks of it. That's useful for you, but for upstreaming > the main focues (especially for smaller drivers) is whether your driver > uses all the available helpers and integrations correctly. And for that > it's much easier if the history is cleaned up, and all intermediate steps > removed. And also agree on this point. The submission could be split up in a few patches where the split is file based. So only with the latest patch, containing Makefile + Kconfig,the driver i buildable. This would ease review as one looses focus when trying to review 1000+ lines in one mail. You will loose some of the internal history - but if important keep relevant parts in sensible comments. Sam ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 00/59] Add support for KeemBay DRM driver
Hi Anitha. On Tue, Jul 14, 2020 at 01:56:46PM -0700, Anitha Chrisanthus wrote: > 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 (will be updated to use > devm_drm_dev_alloc() in a separate patch later as kmb driver is currently > developed on 5.4 kernel) > - minor cleanups Could you please include a TODO or something. It is not obvious if some points from last review are pending or they were skipped. From a quick look maybe half of the poitns were addressed which is good. But some points are yet to be done. Sam > > Anitha Chrisanthus (52): > drm/kmb: Add support for KeemBay Display > drm/kmb: Added id to kmb_plane > drm/kmb: Set correct values in the LAYERn_CFG register > drm/kmb: Use biwise operators for register definitions > drm/kmb: Updated kmb_plane_atomic_check > drm/kmb: Initial check-in for Mipi DSI > drm/kmb: Set OUT_FORMAT_CFG register > drm/kmb: Added mipi_dsi_host initialization > drm/kmb: Part 1 of Mipi Tx Initialization > drm/kmb: Part 2 of Mipi Tx Initialization > drm/kmb: Use correct mmio offset from data book > drm/kmb: Part3 of Mipi Tx initialization > drm/kmb: Part4 of Mipi Tx Initialization > drm/kmb: Correct address offsets for mipi registers > drm/kmb: Part5 of Mipi Tx Intitialization > drm/kmb: Part6 of Mipi Tx Initialization > drm/kmb: Part7 of Mipi Tx Initialization > drm/kmb: Part8 of Mipi Tx Initialization > drm/kmb: Added ioremap/iounmap for register access > drm/kmb: Register IRQ for LCD > drm/kmb: IRQ handlers for LCD and mipi dsi > drm/kmb: Set hardcoded values to LCD_VSYNC_START > drm/kmb: Additional register programming to update_plane > drm/kmb: Add ADV7535 bridge > drm/kmb: Display clock enable/disable > drm/kmb: rebase to newer kernel version > drm/kmb: minor name change to match device tree > drm/kmb: Changed MMIO size > drm/kmb: Defer Probe > drm/kmb: call bridge init in the very beginning > drm/kmb: Enable MSS_CAM_CLK_CTRL for LCD and MIPI > drm/kmb: Set MSS_CAM_RSTN_CTRL along with enable > drm/kmb: Mipi DPHY initialization changes > drm/kmb: Fixed driver unload > drm/kmb: Added LCD_TEST config > drm/kmb: Changes for LCD to Mipi > drm/kmb: Update LCD programming to match MIPI > drm/kmb: Changed name of driver to kmb-drm > drm/kmb: Mipi settings from input timings > drm/kmb: Enable LCD interrupts > drm/kmb: Enable LCD interrupts during modeset > drm/kmb: Don’t inadvertantly disable LCD controller > drm/kmb: SWAP R and B LCD Layer order > drm/kmb: Disable ping pong mode > drm/kmb: Do the layer initializations only once > drm/kmb: disable the LCD layer in EOF irq handler > drm/kmb: Initialize uninitialized variables > drm/kmb: Added useful messages in LCD ISR > kmb/drm: Prune unsupported modes > drm/kmb: workaround for dma undeflow issue > drm/kmb: Get System Clock from SCMI > drm/kmb: work around for planar formats > > Edmund Dea (7): > drm/kmb: Cleanup probe functions > drm/kmb: Revert dsi_host back to a static variable > drm/kmb: Initialize clocks for clk_msscam, clk_mipi_ecfg, & > clk_mipi_cfg. > drm/kmb: Remove declaration of irq_lcd/irq_mipi > drm/kmb: Enable MIPI TX HS Test Pattern Generation > drm/kmb: Write to LCD_LAYERn_CFG only once > drm/kmb: Cleaned up code > > drivers/gpu/drm/Kconfig |2 + > drivers/gpu/drm/Makefile|1 + > drivers/gpu/drm/kmb/Kconfig | 12 + > drivers/gpu/drm/kmb/Makefile|2 + > drivers/gpu/drm/kmb/kmb_crtc.c | 226 + > drivers/gpu/drm/kmb/kmb_crtc.h | 41 + > drivers/gpu/drm/kmb/kmb_drv.c | 809 > drivers/gpu/drm/kmb/kmb_drv.h | 176 > drivers/gpu/drm/kmb/kmb_dsi.c | 1927 > +++ >
[Intel-gfx] [PATCH] Revert "Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+""
The problem the reverted patch revealed could've been fixed by commit
619ad4874585 ("drm/i915/ddi: Don't frob the DP link scramble disabling flag")
in particular because the revealed problem (at least in one case) happened
when switching to the TPS4 training pattern, which needs scrambling.
Let's try applying the HBR3 fix again.
This reverts commit d3913019602e32ef6fbba8eb0167e83250cdab22.
Cc: Matt Atwood
Cc: Ville Syrjälä
Cc: Manasi Navare
Cc: José Roberto de Souza
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 28 ++---
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index d6295eb20b63..a5ab405d3a12 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -137,6 +137,8 @@ static const u8 valid_dsc_slicecount[] = {1, 2, 4};
*
* If a CPU or PCH DP output is attached to an eDP panel, this function
* will return true, and false otherwise.
+ *
+ * This function is not safe to use prior to encoder type being set.
*/
bool intel_dp_is_edp(struct intel_dp *intel_dp)
{
@@ -8157,8 +8159,6 @@ intel_dp_init_connector(struct intel_digital_port
*dig_port,
intel_encoder->base.name))
return false;
- intel_dp_set_source_rates(intel_dp);
-
intel_dp->reset_link_params = true;
intel_dp->pps_pipe = INVALID_PIPE;
intel_dp->active_pipe = INVALID_PIPE;
@@ -8174,28 +8174,22 @@ intel_dp_init_connector(struct intel_digital_port
*dig_port,
*/
drm_WARN_ON(dev, intel_phy_is_tc(dev_priv, phy));
type = DRM_MODE_CONNECTOR_eDP;
+ intel_encoder->type = INTEL_OUTPUT_EDP;
+
+ /* eDP only on port B and/or C on vlv/chv */
+ if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
+ IS_CHERRYVIEW(dev_priv)) &&
+ port != PORT_B && port != PORT_C))
+ return false;
} else {
type = DRM_MODE_CONNECTOR_DisplayPort;
}
+ intel_dp_set_source_rates(intel_dp);
+
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
intel_dp->active_pipe = vlv_active_pipe(intel_dp);
- /*
-* For eDP we always set the encoder type to INTEL_OUTPUT_EDP, but
-* for DP the encoder type can be set by the caller to
-* INTEL_OUTPUT_UNKNOWN for DDI, so don't rewrite it.
-*/
- if (type == DRM_MODE_CONNECTOR_eDP)
- intel_encoder->type = INTEL_OUTPUT_EDP;
-
- /* eDP only on port B and/or C on vlv/chv */
- if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
- IS_CHERRYVIEW(dev_priv)) &&
- intel_dp_is_edp(intel_dp) &&
- port != PORT_B && port != PORT_C))
- return false;
-
drm_dbg_kms(_priv->drm,
"Adding %s connector on [ENCODER:%d:%s]\n",
type == DRM_MODE_CONNECTOR_eDP ? "eDP" : "DP",
--
2.23.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Mock the status_page.vma for the kernel_context
== Series Details ==
Series: drm/i915/selftests: Mock the status_page.vma for the kernel_context
URL : https://patchwork.freedesktop.org/series/79521/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8750 -> Patchwork_18180
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/index.html
Known issues
Here are the changes found in Patchwork_18180 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-bsw-kefka/igt@gem_exec_susp...@basic-s0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/fi-bsw-kefka/igt@gem_exec_susp...@basic-s0.html
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][3] -> [FAIL][4] ([i915#1888])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@gem_flink_basic@bad-flink:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-icl-y: [PASS][9] -> [DMESG-FAIL][10] ([i915#541])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-icl-y/igt@i915_selftest@live@gt_heartbeat.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/fi-icl-y/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-tgl-u2: [PASS][13] -> [DMESG-WARN][14] ([i915#402])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
Possible fixes
* igt@i915_module_load@reload:
- fi-byt-j1900: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-byt-j1900/igt@i915_module_l...@reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/fi-byt-j1900/igt@i915_module_l...@reload.html
- fi-bxt-dsi: [DMESG-WARN][17] ([i915#1635] / [i915#1982]) ->
[PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-bxt-dsi/igt@i915_module_l...@reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/fi-bxt-dsi/igt@i915_module_l...@reload.html
- fi-tgl-y: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-y/igt@i915_module_l...@reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/fi-tgl-y/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- {fi-tgl-dsi}: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][23] ([i915#1982]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18180/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][25] ([i915#62]) -> [SKIP][26]
([fdo#109271])
[25]:
Re: [Intel-gfx] [PATCH i-g-t 2/2] test/kms_cursor_crc: align the start of the CRC capture to a vblank
On 07/15, Arkadiusz Hiler wrote: > On Mon, Jun 22, 2020 at 01:38:26PM -0300, Melissa Wen wrote: > > When running subtests in sequence using vkms, the beginning of CRC capture > > process does not match the simulated vblank timing. This mismatch leads to > > an endless busy wait and, consequently, timeout failures for the remaining > > subtests in the test sequence. This patch sets the pace by waiting for > > vblank before starting the CRC capture. > > > > Signed-off-by: Melissa Wen > > This one is quite interetesing. The test seems to be working just fine > on the real hardware and causes the endless busy wait on VKMS only... > > DRM is bad at describing usage sequences and what's defined and what's > undefined when it comes to behavior. We just try not to break any of the > existing users. On top of that CRC capture is a testing/debug feature > that doesn't have have to be stable - it's not really obvious what's the > correct course of action here. > > The vblank wait won't harm anyone, especially in the context presented > above. You have to keep in mind that other implementations of CRC > caputring doesn't have that requirement and you will likely find more > similar instances of this usage pattern. There may be even more of them > introduced over time - there's no CI on VKMS (fingers crossed that this > is going to change). > > Have you thought about what's easier here - making the current code work > on the VKMS side or fixing the test? I would like to know your thoughts > on this. Hi, Thank you very much for the review! I've been investigating more about this with the community help and, in fact, the problem seems to be more linked to vkms. I mean, this problem of waiting for a vblank before starting to capture the CRC seems to affect vkms in other igt tests too. So the most accurate thing is to treat it over there. I will send a v2 only with the other patch that releases the pipe_crc before creating a new one. Thanks again, Melissa > > -- > Cheers, > Arek > > > > > > --- > > tests/kms_cursor_crc.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/tests/kms_cursor_crc.c b/tests/kms_cursor_crc.c > > index 5976df5f..755c34ed 100644 > > --- a/tests/kms_cursor_crc.c > > +++ b/tests/kms_cursor_crc.c > > @@ -474,6 +474,7 @@ static void prepare_crtc(data_t *data, igt_output_t > > *output, > > igt_assert(data->batch); > > } > > > > + igt_wait_for_vblank(data->drm_fd, data->pipe); > > igt_pipe_crc_start(data->pipe_crc); > > } > > > > -- > > 2.27.0 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Reduce i915_request.lock contention for i915_request_wait
== Series Details == Series: drm/i915: Reduce i915_request.lock contention for i915_request_wait URL : https://patchwork.freedesktop.org/series/79514/ State : success == Summary == CI Bug Log - changes from CI_DRM_8749_full -> Patchwork_18176_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18176_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@bonded-early: - shard-kbl: [PASS][1] -> [FAIL][2] ([i915#2079]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/shard-kbl3/igt@gem_exec_balan...@bonded-early.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/shard-kbl7/igt@gem_exec_balan...@bonded-early.html * igt@gem_exec_whisper@basic-queues-priority-all: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/shard-glk7/igt@gem_exec_whis...@basic-queues-priority-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/shard-glk5/igt@gem_exec_whis...@basic-queues-priority-all.html * igt@gem_softpin@evict-active: - shard-tglb: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/shard-tglb5/igt@gem_soft...@evict-active.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/shard-tglb8/igt@gem_soft...@evict-active.html * igt@kms_big_fb@y-tiled-64bpp-rotate-180: - shard-glk: [PASS][7] -> [DMESG-FAIL][8] ([i915#118] / [i915#95]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/shard-glk9/igt@kms_big...@y-tiled-64bpp-rotate-180.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-180.html * igt@kms_cursor_crc@pipe-b-cursor-64x64-sliding: - shard-skl: [PASS][9] -> [FAIL][10] ([i915#54]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/shard-skl8/igt@kms_cursor_...@pipe-b-cursor-64x64-sliding.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/shard-skl1/igt@kms_cursor_...@pipe-b-cursor-64x64-sliding.html * igt@kms_flip@2x-flip-vs-expired-vblank@ab-hdmi-a1-hdmi-a2: - shard-glk: [PASS][11] -> [FAIL][12] ([i915#79]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vbl...@ab-hdmi-a1-hdmi-a2.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/shard-glk7/igt@kms_flip@2x-flip-vs-expired-vbl...@ab-hdmi-a1-hdmi-a2.html * igt@kms_flip@basic-plain-flip@a-edp1: - shard-skl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +11 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/shard-skl7/igt@kms_flip@basic-plain-f...@a-edp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/shard-skl4/igt@kms_flip@basic-plain-f...@a-edp1.html * igt@kms_flip@flip-vs-suspend-interruptible@c-dp1: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#165]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/shard-kbl2/igt@kms_flip@flip-vs-suspend-interrupti...@c-dp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/shard-kbl6/igt@kms_flip@flip-vs-suspend-interrupti...@c-dp1.html * igt@kms_frontbuffer_tracking@fbcpsr-stridechange: - shard-tglb: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/shard-tglb7/igt@kms_frontbuffer_track...@fbcpsr-stridechange.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/shard-tglb2/igt@kms_frontbuffer_track...@fbcpsr-stridechange.html * igt@kms_hdr@bpc-switch-suspend: - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/shard-kbl3/igt@kms_...@bpc-switch-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/shard-kbl7/igt@kms_...@bpc-switch-suspend.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [i915#265]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/shard-skl5/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/shard-skl9/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_psr@psr2_primary_page_flip: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/shard-iclb3/igt@kms_psr@psr2_primary_page_flip.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/selftests: Mock the status_page.vma for the kernel_context
== Series Details == Series: drm/i915/selftests: Mock the status_page.vma for the kernel_context URL : https://patchwork.freedesktop.org/series/79521/ 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.BAT: success for series starting with [01/66] drm/i915: Reduce i915_request.lock contention for i915_request_wait (rev2)
== Series Details ==
Series: series starting with [01/66] drm/i915: Reduce i915_request.lock
contention for i915_request_wait (rev2)
URL : https://patchwork.freedesktop.org/series/79517/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8750 -> Patchwork_18179
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18179/index.html
Known issues
Here are the changes found in Patchwork_18179 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 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18179/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@gem_flink_basic@flink-lifetime:
- fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18179/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18179/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18179/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.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_8750/fi-byt-j1900/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18179/fi-byt-j1900/igt@i915_module_l...@reload.html
- fi-bxt-dsi: [DMESG-WARN][11] ([i915#1635] / [i915#1982]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-bxt-dsi/igt@i915_module_l...@reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18179/fi-bxt-dsi/igt@i915_module_l...@reload.html
- fi-tgl-u2: [DMESG-WARN][13] ([i915#402]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-u2/igt@i915_module_l...@reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18179/fi-tgl-u2/igt@i915_module_l...@reload.html
- fi-tgl-y: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-y/igt@i915_module_l...@reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18179/fi-tgl-y/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- {fi-tgl-dsi}: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18179/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@gt_lrc:
- fi-tgl-u2: [DMESG-FAIL][19] ([i915#1233]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18179/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18179/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-bsw-kefka: [DMESG-WARN][23] ([i915#1982]) -> [PASS][24] +1
similar issue
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18179/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@vgem_basic@setversion:
- fi-tgl-y: [DMESG-WARN][25] ([i915#402]) -> [PASS][26]
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-y/igt@vgem_ba...@setversion.html
[26]:
[Intel-gfx] [PATCH] drm/i915/selftests: Mock the status_page.vma for the kernel_context
Since we assert that the kernel_context is using the perma-pinned HWSP, make it so. Signed-off-by: Chris Wilson Cc: Mika Kuoppala --- drivers/gpu/drm/i915/gt/mock_engine.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/mock_engine.c b/drivers/gpu/drm/i915/gt/mock_engine.c index b8dd3cbc8696..06303ba98c19 100644 --- a/drivers/gpu/drm/i915/gt/mock_engine.c +++ b/drivers/gpu/drm/i915/gt/mock_engine.c @@ -332,6 +332,9 @@ int mock_engine_init(struct intel_engine_cs *engine) if (IS_ERR(ce)) goto err_breadcrumbs; + /* We insist the kernel context is using the status_page */ + engine->status_page.vma = ce->timeline->hwsp_ggtt; + engine->kernel_context = ce; return 0; -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 28/66] drm/i915/gem: Replace i915_gem_object.mm.mutex with reservation_ww_class
Op 15-07-2020 om 13:51 schreef Chris Wilson:
> Our goal is to pull all memory reservations (next iteration
> obj->ops->get_pages()) under a ww_mutex, and to align those reservations
> with other drivers, i.e. control all such allocations with the
> reservation_ww_class. Currently, this is under the purview of the
> obj->mm.mutex, and while obj->mm remains an embedded struct we can
> "simply" switch to using the reservation_ww_class obj->base.resv->lock
>
> The major consequence is the impact on the shrinker paths as the
> reservation_ww_class is used to wrap allocations, and a ww_mutex does
> not support subclassing so we cannot do our usual trick of knowing that
> we never recurse inside the shrinker and instead have to finish the
> reclaim with a trylock. This may result in us failing to release the
> pages after having released the vma. This will have to do until a better
> idea comes along.
>
> However, this step only converts the mutex over and continues to treat
> everything as a single allocation and pinning the pages. With the
> ww_mutex in place we can remove the temporary pinning, as we can then
> reserve all storage en masse.
>
> One last thing to do: kill the implict page pinning for active vma.
> This will require us to invalidate the vma->pages when the backing store
> is removed (and we expect that while the vma is active, we mark the
> backing store as active so that it cannot be removed while the HW is
> busy.)
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 20 +-
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 18 +-
> drivers/gpu/drm/i915/gem/i915_gem_domain.c| 65 ++
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 40 +++-
> drivers/gpu/drm/i915/gem/i915_gem_object.c| 8 +-
> drivers/gpu/drm/i915/gem/i915_gem_object.h| 37 +--
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 1 -
> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 134 ++-
> drivers/gpu/drm/i915/gem/i915_gem_phys.c | 8 +-
> drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 13 +-
> drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 2 -
> drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 15 +-
> .../gpu/drm/i915/gem/selftests/huge_pages.c | 32 ++-
> .../i915/gem/selftests/i915_gem_coherency.c | 14 +-
> .../drm/i915/gem/selftests/i915_gem_context.c | 10 +-
> .../drm/i915/gem/selftests/i915_gem_mman.c| 2 +
> drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 -
> drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 1 -
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 5 +-
> drivers/gpu/drm/i915/gt/intel_gtt.h | 2 -
> drivers/gpu/drm/i915/gt/intel_ppgtt.c | 1 +
> drivers/gpu/drm/i915/i915_gem.c | 16 +-
> drivers/gpu/drm/i915/i915_vma.c | 217 +++---
> drivers/gpu/drm/i915/i915_vma_types.h | 6 -
> drivers/gpu/drm/i915/mm/i915_acquire_ctx.c| 12 +-
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +-
> .../drm/i915/selftests/intel_memory_region.c | 17 +-
> 27 files changed, 313 insertions(+), 389 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> index bc0223716906..a32fd0d5570b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> @@ -27,16 +27,8 @@ static void __do_clflush(struct drm_i915_gem_object *obj)
> static int clflush_work(struct dma_fence_work *base)
> {
> struct clflush *clflush = container_of(base, typeof(*clflush), base);
> - struct drm_i915_gem_object *obj = clflush->obj;
> - int err;
> -
> - err = i915_gem_object_pin_pages(obj);
> - if (err)
> - return err;
> -
> - __do_clflush(obj);
> - i915_gem_object_unpin_pages(obj);
>
> + __do_clflush(clflush->obj);
> return 0;
> }
>
> @@ -44,7 +36,7 @@ static void clflush_release(struct dma_fence_work *base)
> {
> struct clflush *clflush = container_of(base, typeof(*clflush), base);
>
> - i915_gem_object_put(clflush->obj);
> + i915_gem_object_unpin_pages(clflush->obj);
> }
>
> static const struct dma_fence_work_ops clflush_ops = {
> @@ -63,8 +55,14 @@ static struct clflush *clflush_work_create(struct
> drm_i915_gem_object *obj)
> if (!clflush)
> return NULL;
>
> + if (__i915_gem_object_get_pages_locked(obj)) {
> + kfree(clflush);
> + return NULL;
> + }
> +
> dma_fence_work_init(>base, _ops);
> - clflush->obj = i915_gem_object_get(obj); /* obj <-> clflush cycle */
> + __i915_gem_object_pin_pages(obj);
> + clflush->obj = obj; /* Beware the obj.resv <-> clflush fence cycle */
>
> return clflush;
> }
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> index 2679380159fc..049a15e6b496 100644
> ---
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/66] drm/i915: Reduce i915_request.lock contention for i915_request_wait (rev2)
== Series Details == Series: series starting with [01/66] drm/i915: Reduce i915_request.lock contention for i915_request_wait (rev2) URL : https://patchwork.freedesktop.org/series/79517/ State : warning == Summary == $ dim checkpatch origin/drm-tip 130497fc98af drm/i915: Reduce i915_request.lock contention for i915_request_wait 78b2b4227c1a drm/i915: Remove i915_request.lock requirement for execution callbacks c0b29c38984e drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs 96f54f935986 drm/i915: Add a couple of missing i915_active_fini() e0279073e5d3 drm/i915: Skip taking acquire mutex for no ref->active callback 74f1c669d951 drm/i915: Export a preallocate variant of i915_active_acquire() db2f42ce7206 drm/i915: Keep the most recently used active-fence upon discard 3bfed8a701e1 drm/i915: Make the stale cached active node available for any timeline 8d7b14253127 drm/i915: Provide a fastpath for waiting on vma bindings 638a715d2c30 drm/i915: Soften the tasklet flush frequency before waits 5250859a3025 drm/i915: Preallocate stashes for vma page-directories 2747217ec2ad drm/i915: Switch to object allocations for page directories 6bdab21d6597 drm/i915/gem: Don't drop the timeline lock during execbuf f3c8a75f8f0d drm/i915/gem: Rename execbuf.bind_link to unbound_link 1608dda568ca drm/i915/gem: Break apart the early i915_vma_pin from execbuf object lookup 63d098780e45 drm/i915/gem: Remove the call for no-evict i915_vma_pin 6ac79cc3b262 drm/i915: Add list_for_each_entry_safe_continue_reverse -:21: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pos' - possible side-effects? #21: FILE: drivers/gpu/drm/i915/i915_utils.h:269: +#define list_for_each_entry_safe_continue_reverse(pos, n, head, member) \ + for (pos = list_prev_entry(pos, member),\ +n = list_prev_entry(pos, member); \ +>member != (head);\ +pos = n, n = list_prev_entry(n, member)) -:21: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'n' - possible side-effects? #21: FILE: drivers/gpu/drm/i915/i915_utils.h:269: +#define list_for_each_entry_safe_continue_reverse(pos, n, head, member) \ + for (pos = list_prev_entry(pos, member),\ +n = list_prev_entry(pos, member); \ +>member != (head);\ +pos = n, n = list_prev_entry(n, member)) -:21: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'member' - possible side-effects? #21: FILE: drivers/gpu/drm/i915/i915_utils.h:269: +#define list_for_each_entry_safe_continue_reverse(pos, n, head, member) \ + for (pos = list_prev_entry(pos, member),\ +n = list_prev_entry(pos, member); \ +>member != (head);\ +pos = n, n = list_prev_entry(n, member)) total: 0 errors, 0 warnings, 3 checks, 12 lines checked 69b95b2f1b58 drm/i915: Always defer fenced work to the worker 339dd5f35caf drm/i915/gem: Assign context id for async work dbe18ef2f769 drm/i915/gem: Separate the ww_mutex walker into its own list d6442826e675 drm/i915/gem: Asynchronous GTT unbinding 2ee5a36ee1d9 drm/i915/gem: Bind the fence async for execbuf 2d3e21b38717 drm/i915/gem: Include cmdparser in common execbuf pinning c180ca0649ab drm/i915/gem: Include secure batch in common execbuf pinning 9040f3b37f3b drm/i915/gem: Reintroduce multiple passes for reloc processing -:1512: WARNING:MEMORY_BARRIER: memory barrier without comment #1512: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_execbuffer.c:161: + wmb(); total: 0 errors, 1 warnings, 0 checks, 1502 lines checked d3fe2f8baa11 drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2. -:59: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #59: new file mode 100644 -:354: WARNING:LINE_SPACING: Missing a blank line after declarations #354: FILE: drivers/gpu/drm/i915/mm/st_acquire_ctx.c:106: + const unsigned int total = ARRAY_SIZE(dl->obj); + I915_RND_STATE(prng); -:450: WARNING:YIELD: Using yield() is generally wrong. See yield() kernel-doc (sched/core.c) #450: FILE: drivers/gpu/drm/i915/mm/st_acquire_ctx.c:202: + yield(); /* start all threads before we begin */ total: 0 errors, 3 warnings, 0 checks, 446 lines checked 90ec819f7195 drm/i915/gem: Pull execbuf dma resv under a single critical section 69013a1a8c42 drm/i915/gem: Replace i915_gem_object.mm.mutex with reservation_ww_class 6cb053b52a1e drm/i915: Hold wakeref for the duration of the vma GGTT binding 22e6c1fa7455 drm/i915: Specialise GGTT binding f89d50b33136 drm/i915/gt: Acquire backing storage for the context cd9d5d1c7e79 drm/i915/gt: Push the wait for the context to bound to the request -:198: WARNING:FILE_PATH_CHANGES: added, moved or deleted
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/66] drm/i915: Reduce i915_request.lock contention for i915_request_wait (rev2)
== Series Details == Series: series starting with [01/66] drm/i915: Reduce i915_request.lock contention for i915_request_wait (rev2) URL : https://patchwork.freedesktop.org/series/79517/ 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: Fair low-latency scheduling
The first "scheduler" was a topographical sorting of requests into priority order. The execution order was deterministic, the earliest submitted, highest priority request would be executed first. Priority inherited ensured that inversions were kept at bay, and allowed us to dynamically boost priorities (e.g. for interactive pageflips). The minimalistic timeslicing scheme was an attempt to introduce fairness between long running requests, by evicting the active request at the end of a timeslice and moving it to the back of its priority queue (while ensuring that dependencies were kept in order). For short running requests from many clients of equal priority, the scheme is still very much FIFO submission ordering, and as unfair as before. To impose fairness, we need an external metric that ensures that clients are interpersed, we don't execute one long chain from client A before executing any of client B. This could be imposed by the clients by using a fences based on an external clock, that is they only submit work for a "frame" at frame-interval, instead of submitting as much work as they are able to. The standard SwapBuffers approach is akin to double bufferring, where as one frame is being executed, the next is being submitted, such that there is always a maximum of two frames per client in the pipeline. Even this scheme exhibits unfairness under load as a single client will execute two frames back to back before the next, and with enough clients, deadlines will be missed. The idea introduced by BFS/MuQSS is that fairness is introduced by metering with an external clock. Every request, when it becomes ready to execute is assigned a virtual deadline, and execution order is then determined by earliest deadline. Priority is used as a hint, rather than strict ordering, where high priority requests have earlier deadlines, but not necessarily earlier than outstanding work. Thus work is executed in order of 'readiness', with timeslicing to demote long running work. The Achille's heel of this scheduler is its strong preference for low-latency and favouring of new queues. Whereas it was easy to dominate the old scheduler by flooding it with many requests over a short period of time, the new scheduler can be dominated by a 'synchronous' client that waits for each of its requests to complete before submitting the next. As such a client has no history, it is always considered ready-to-run and receives an earlier deadline than the long running requests. To check the impact on throughput (often the downfall of latency sensitive schedulers), we used gem_wsim to simulate various transcode workloads with different load balancers, and varying the number of competing [heterogenous] clients. +mB+ | a | | cda | | c.a | | ..aa | | ..---. | | -.--+-.| |.c.-.-+++. b | | bbb.d-c-+--+++.aab aab b | |b b b b b. b ..---+++-+a. b. b b b bb b| 1 A| | 2 |___AM| | 3|A__| | 4|MA_| | +--+ Clients Min Max Median AvgStddev 1 -8.20 5.4 -0.045 -0.02375 0.094722134 2 -15.96 19.28 -0.64 -1.05 2.2428076 4 -5.11 2.95 -1.15-1.0680.72382651 8 -5.63 1.85 -0.905 -0.871224490.73390971 The impact was on average 1% under contention due to the change in context execution order and number of context switches. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 12 +- .../gpu/drm/i915/gt/intel_engine_heartbeat.c | 1 + drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 +- drivers/gpu/drm/i915/gt/intel_engine_types.h | 14 - drivers/gpu/drm/i915/gt/intel_lrc.c | 230 +--- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 5 +- drivers/gpu/drm/i915/gt/selftest_lrc.c| 41 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 6 +- drivers/gpu/drm/i915/i915_priolist_types.h| 7 +- drivers/gpu/drm/i915/i915_request.c | 1 + drivers/gpu/drm/i915/i915_scheduler.c | 351 +- drivers/gpu/drm/i915/i915_scheduler.h | 24 +-
Re: [Intel-gfx] [PATCH v2] drm/i915/fbc: Limit cfb to the first 256MiB of stolen on g4x+
Quoting Ville Syrjälä (2020-07-15 15:22:24)
> On Tue, Jul 14, 2020 at 09:32:54PM +0100, Chris Wilson wrote:
> > Quoting Ville Syrjala (2020-07-14 21:19:45)
> > > From: Ville Syrjälä
> > >
> > > Since g4x the CFB base only takes a 28bit offset into stolen.
> > > Not sure if the CFB is allowed to start below that limit but
> > > then extend beyond it. Let's assume not and just restrict the
> > > allocation to the first 256MiB (in the unlikely case
> > > we have more stolen than that).
> > >
> > > v2: s/BIT/BIT_ULL/ (Chris)
> > >
> > > Cc: Chris Wilson
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/display/intel_fbc.c | 10 ++
> > > 1 file changed, 10 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > index 85723fba6002..3a4f980788a6 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > @@ -424,6 +424,14 @@ static void intel_fbc_deactivate(struct
> > > drm_i915_private *dev_priv,
> > > fbc->no_fbc_reason = reason;
> > > }
> > >
> > > +static u64 intel_fbc_cfb_base_max(struct drm_i915_private *i915)
> > > +{
> > > + if (INTEL_GEN(i915) >= 5 || IS_G4X(i915))
> > > + return BIT_ULL(28);
> > > + else
> > > + return BIT_ULL(32);
> > > +}
> >
> > Confirmed that ilk uses 23:12. I trust g4x is the same.
>
> I guess you mean 27:12? Or did you find a some docs saying it's only
> 24 bits? All the docs I have say 27:12.
Typo, 27:12 from DPFC_CB_BASE.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 00/59] Add support for KeemBay DRM driver
On Wed, Jul 15, 2020 at 05:05:49PM +0200, Daniel Vetter wrote: > Hi Anitha > > On Tue, Jul 14, 2020 at 01:56:46PM -0700, Anitha Chrisanthus wrote: > > 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/ > > Cool, new driver, thanks a lot for submitting. > > > 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 (will be updated to use > > devm_drm_dev_alloc() in a separate patch later as kmb driver is currently > > developed on 5.4 kernel) > > drm moves fairly quickly, please develop the upstream submission on top of > linux-next or similar. We constantly add new helpers to simplify drivers, > and we expect new driver submissions to be up to date with all that. > > Another thing: From your description it sounds like it's a very simple > driver, just a single plane/crtc, nothing fancy, plus adv bridge output. > Is the driver already using simple display pipeline helpers? I think that > would be an ideal fit and probably greatly simplifies the code. > > > - minor cleanups > > The patch series looks like it contains the entire development history, or > at least large chunks of it. That's useful for you, but for upstreaming > the main focues (especially for smaller drivers) is whether your driver > uses all the available helpers and integrations correctly. And for that > it's much easier if the history is cleaned up, and all intermediate steps > removed. > > I think once that's done I can do a quick pass and drop suggestions for > cleanup and stuff like that, and then we should (usually at least) be able > to pull in the driver fairly quickly. > > Another thing to consider is where/how this driver will be maintained. > Preferred option is as part of drm-misc so that we have redudancy and all > that in a fairly big group. Works with commit rights, so maybe check out > some of our docs about that too. > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html > > The committer model comes with a full set of scripts and docs to avoid > oopsies in maintainership. Generally works really well. Oh if you have a git branch of this all somewhere I could do a quick high-level pass and see whether there's anything big. -Daniel > > Cheers, Daniel > > > > > > Anitha Chrisanthus (52): > > drm/kmb: Add support for KeemBay Display > > drm/kmb: Added id to kmb_plane > > drm/kmb: Set correct values in the LAYERn_CFG register > > drm/kmb: Use biwise operators for register definitions > > drm/kmb: Updated kmb_plane_atomic_check > > drm/kmb: Initial check-in for Mipi DSI > > drm/kmb: Set OUT_FORMAT_CFG register > > drm/kmb: Added mipi_dsi_host initialization > > drm/kmb: Part 1 of Mipi Tx Initialization > > drm/kmb: Part 2 of Mipi Tx Initialization > > drm/kmb: Use correct mmio offset from data book > > drm/kmb: Part3 of Mipi Tx initialization > > drm/kmb: Part4 of Mipi Tx Initialization > > drm/kmb: Correct address offsets for mipi registers > > drm/kmb: Part5 of Mipi Tx Intitialization > > drm/kmb: Part6 of Mipi Tx Initialization > > drm/kmb: Part7 of Mipi Tx Initialization > > drm/kmb: Part8 of Mipi Tx Initialization > > drm/kmb: Added ioremap/iounmap for register access > > drm/kmb: Register IRQ for LCD > > drm/kmb: IRQ handlers for LCD and mipi dsi > > drm/kmb: Set hardcoded values to LCD_VSYNC_START > > drm/kmb: Additional register programming to update_plane > > drm/kmb: Add ADV7535 bridge > > drm/kmb: Display clock enable/disable > > drm/kmb: rebase to newer kernel version > > drm/kmb: minor name change to match device tree > > drm/kmb: Changed MMIO size > > drm/kmb: Defer Probe > > drm/kmb: call bridge init in the very beginning > > drm/kmb: Enable MSS_CAM_CLK_CTRL for LCD and MIPI > > drm/kmb: Set MSS_CAM_RSTN_CTRL along with enable > > drm/kmb: Mipi
Re: [Intel-gfx] [PATCH v2 00/59] Add support for KeemBay DRM driver
Hi Anitha On Tue, Jul 14, 2020 at 01:56:46PM -0700, Anitha Chrisanthus wrote: > 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/ Cool, new driver, thanks a lot for submitting. > 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 (will be updated to use > devm_drm_dev_alloc() in a separate patch later as kmb driver is currently > developed on 5.4 kernel) drm moves fairly quickly, please develop the upstream submission on top of linux-next or similar. We constantly add new helpers to simplify drivers, and we expect new driver submissions to be up to date with all that. Another thing: From your description it sounds like it's a very simple driver, just a single plane/crtc, nothing fancy, plus adv bridge output. Is the driver already using simple display pipeline helpers? I think that would be an ideal fit and probably greatly simplifies the code. > - minor cleanups The patch series looks like it contains the entire development history, or at least large chunks of it. That's useful for you, but for upstreaming the main focues (especially for smaller drivers) is whether your driver uses all the available helpers and integrations correctly. And for that it's much easier if the history is cleaned up, and all intermediate steps removed. I think once that's done I can do a quick pass and drop suggestions for cleanup and stuff like that, and then we should (usually at least) be able to pull in the driver fairly quickly. Another thing to consider is where/how this driver will be maintained. Preferred option is as part of drm-misc so that we have redudancy and all that in a fairly big group. Works with commit rights, so maybe check out some of our docs about that too. https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html The committer model comes with a full set of scripts and docs to avoid oopsies in maintainership. Generally works really well. Cheers, Daniel > > Anitha Chrisanthus (52): > drm/kmb: Add support for KeemBay Display > drm/kmb: Added id to kmb_plane > drm/kmb: Set correct values in the LAYERn_CFG register > drm/kmb: Use biwise operators for register definitions > drm/kmb: Updated kmb_plane_atomic_check > drm/kmb: Initial check-in for Mipi DSI > drm/kmb: Set OUT_FORMAT_CFG register > drm/kmb: Added mipi_dsi_host initialization > drm/kmb: Part 1 of Mipi Tx Initialization > drm/kmb: Part 2 of Mipi Tx Initialization > drm/kmb: Use correct mmio offset from data book > drm/kmb: Part3 of Mipi Tx initialization > drm/kmb: Part4 of Mipi Tx Initialization > drm/kmb: Correct address offsets for mipi registers > drm/kmb: Part5 of Mipi Tx Intitialization > drm/kmb: Part6 of Mipi Tx Initialization > drm/kmb: Part7 of Mipi Tx Initialization > drm/kmb: Part8 of Mipi Tx Initialization > drm/kmb: Added ioremap/iounmap for register access > drm/kmb: Register IRQ for LCD > drm/kmb: IRQ handlers for LCD and mipi dsi > drm/kmb: Set hardcoded values to LCD_VSYNC_START > drm/kmb: Additional register programming to update_plane > drm/kmb: Add ADV7535 bridge > drm/kmb: Display clock enable/disable > drm/kmb: rebase to newer kernel version > drm/kmb: minor name change to match device tree > drm/kmb: Changed MMIO size > drm/kmb: Defer Probe > drm/kmb: call bridge init in the very beginning > drm/kmb: Enable MSS_CAM_CLK_CTRL for LCD and MIPI > drm/kmb: Set MSS_CAM_RSTN_CTRL along with enable > drm/kmb: Mipi DPHY initialization changes > drm/kmb: Fixed driver unload > drm/kmb: Added LCD_TEST config > drm/kmb: Changes for LCD to Mipi > drm/kmb: Update LCD programming to match MIPI > drm/kmb: Changed name of driver to kmb-drm > drm/kmb: Mipi settings from input timings > drm/kmb: Enable LCD interrupts > drm/kmb: Enable LCD interrupts during modeset > drm/kmb: Don’t inadvertantly disable LCD
Re: [Intel-gfx] [PATCH] drm/i915: Reduce i915_request.lock contention for i915_request_wait
Quoting Chris Wilson (2020-07-15 15:47:15)
> Quoting Tvrtko Ursulin (2020-07-15 13:26:23)
> >
> > On 15/07/2020 13:06, Tvrtko Ursulin wrote:
> > >
> > > On 15/07/2020 11:50, Chris Wilson wrote:
> > >> Currently, we use i915_request_completed() directly in
> > >> i915_request_wait() and follow up with a manual invocation of
> > >> dma_fence_signal(). This appears to cause a large number of contentions
> > >> on i915_request.lock as when the process is woken up after the fence is
> > >> signaled by an interrupt, we will then try and call dma_fence_signal()
> > >> ourselves while the signaler is still holding the lock.
> > >> dma_fence_is_signaled() has the benefit of checking the
> > >> DMA_FENCE_FLAG_SIGNALED_BIT prior to calling dma_fence_signal() and so
> > >> avoids most of that contention.
> > >>
> > >> Signed-off-by: Chris Wilson
> > >> Cc: Matthew Auld
> > >> Cc: Tvrtko Ursulin
> > >> ---
> > >> drivers/gpu/drm/i915/i915_request.c | 12
> > >> 1 file changed, 4 insertions(+), 8 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/i915_request.c
> > >> b/drivers/gpu/drm/i915/i915_request.c
> > >> index 0b2fe55e6194..bb4eb1a8780e 100644
> > >> --- a/drivers/gpu/drm/i915/i915_request.c
> > >> +++ b/drivers/gpu/drm/i915/i915_request.c
> > >> @@ -1640,7 +1640,7 @@ static bool busywait_stop(unsigned long timeout,
> > >> unsigned int cpu)
> > >> return this_cpu != cpu;
> > >> }
> > >> -static bool __i915_spin_request(const struct i915_request * const rq,
> > >> int state)
> > >> +static bool __i915_spin_request(struct i915_request * const rq, int
> > >> state)
> > >> {
> > >> unsigned long timeout_ns;
> > >> unsigned int cpu;
> > >> @@ -1673,7 +1673,7 @@ static bool __i915_spin_request(const struct
> > >> i915_request * const rq, int state)
> > >> timeout_ns = READ_ONCE(rq->engine->props.max_busywait_duration_ns);
> > >> timeout_ns += local_clock_ns();
> > >> do {
> > >> - if (i915_request_completed(rq))
> > >> + if (dma_fence_is_signaled(>fence))
> > >> return true;
> > >> if (signal_pending_state(state, current))
> > >> @@ -1766,10 +1766,8 @@ long i915_request_wait(struct i915_request *rq,
> > >> * duration, which we currently lack.
> > >> */
> > >> if (IS_ACTIVE(CONFIG_DRM_I915_MAX_REQUEST_BUSYWAIT) &&
> > >> - __i915_spin_request(rq, state)) {
> > >> - dma_fence_signal(>fence);
> > >> + __i915_spin_request(rq, state))
> > >> goto out;
> > >> - }
> > >> /*
> > >> * This client is about to stall waiting for the GPU. In many cases
> > >> @@ -1796,10 +1794,8 @@ long i915_request_wait(struct i915_request *rq,
> > >> for (;;) {
> > >> set_current_state(state);
> > >> - if (i915_request_completed(rq)) {
> > >> - dma_fence_signal(>fence);
> > >> + if (dma_fence_is_signaled(>fence))
> > >> break;
> > >> - }
> > >> intel_engine_flush_submission(rq->engine);
> > >>
> > >
> > > In other words putting some latency back into the waiters, which is
> > > probably okay, since sync waits is not our primary model.
> > >
> > > I have a slight concern about the remaining value of busy spinning if
> > > i915_request_completed check is removed from there as well. Of course it
> > > doesn't make sense to have different completion criteria between the
> > > two.. We could wait a bit longer if real check in busyspin said request
> > > is actually completed, just not signal it but wait for the breadcrumbs
> > > to do it.
> >
> > What a load of nonsense.. :)
> >
> > Okay, I think the only real question is i915_request_completed vs
> > dma_fence_signaled in __i915_spin_request. Do we want to burn CPU cycles
> > waiting on GPU and breadcrumb irq work, or just the GPU.
>
> dma_fence_is_signaled() {
> if (test_bit(SIGNALED_BIT))
> return true;
>
> if (i915_request_completed()) {
> dma_fence_signal();
> return true;
> }
>
> return false;
> }
>
> with the indirection. So the question is whether the indirection is
> worth the extra test bit. Just purely looking at the i915_request.lock
> contention suggests that it probably is. For the spinner, burning a few
> extra CPU cycles for *vfunc is not an issue, it's the wakeup latency,
> and since we are calling dma_fence_signal() upon wakeup we do take the
> spinlock without checking for an early return from the SIGNALED_BIT.
> So I think it's a net positive. The alternative was to write
>
> if (i915_request_completed()) {
> if (!i915_request_is_signaled())
> dma_fence_signal();
> break;
> }
>
> but
>
> if (dma_fence_is_signaled())
> break;
>
> does appear simpler, if only by virtue of hiding the details in an
> inline.
Or a patch to add
Re: [Intel-gfx] [PATCH] drm/i915: Reduce i915_request.lock contention for i915_request_wait
Quoting Tvrtko Ursulin (2020-07-15 13:26:23)
>
> On 15/07/2020 13:06, Tvrtko Ursulin wrote:
> >
> > On 15/07/2020 11:50, Chris Wilson wrote:
> >> Currently, we use i915_request_completed() directly in
> >> i915_request_wait() and follow up with a manual invocation of
> >> dma_fence_signal(). This appears to cause a large number of contentions
> >> on i915_request.lock as when the process is woken up after the fence is
> >> signaled by an interrupt, we will then try and call dma_fence_signal()
> >> ourselves while the signaler is still holding the lock.
> >> dma_fence_is_signaled() has the benefit of checking the
> >> DMA_FENCE_FLAG_SIGNALED_BIT prior to calling dma_fence_signal() and so
> >> avoids most of that contention.
> >>
> >> Signed-off-by: Chris Wilson
> >> Cc: Matthew Auld
> >> Cc: Tvrtko Ursulin
> >> ---
> >> drivers/gpu/drm/i915/i915_request.c | 12
> >> 1 file changed, 4 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_request.c
> >> b/drivers/gpu/drm/i915/i915_request.c
> >> index 0b2fe55e6194..bb4eb1a8780e 100644
> >> --- a/drivers/gpu/drm/i915/i915_request.c
> >> +++ b/drivers/gpu/drm/i915/i915_request.c
> >> @@ -1640,7 +1640,7 @@ static bool busywait_stop(unsigned long timeout,
> >> unsigned int cpu)
> >> return this_cpu != cpu;
> >> }
> >> -static bool __i915_spin_request(const struct i915_request * const rq,
> >> int state)
> >> +static bool __i915_spin_request(struct i915_request * const rq, int
> >> state)
> >> {
> >> unsigned long timeout_ns;
> >> unsigned int cpu;
> >> @@ -1673,7 +1673,7 @@ static bool __i915_spin_request(const struct
> >> i915_request * const rq, int state)
> >> timeout_ns = READ_ONCE(rq->engine->props.max_busywait_duration_ns);
> >> timeout_ns += local_clock_ns();
> >> do {
> >> - if (i915_request_completed(rq))
> >> + if (dma_fence_is_signaled(>fence))
> >> return true;
> >> if (signal_pending_state(state, current))
> >> @@ -1766,10 +1766,8 @@ long i915_request_wait(struct i915_request *rq,
> >> * duration, which we currently lack.
> >> */
> >> if (IS_ACTIVE(CONFIG_DRM_I915_MAX_REQUEST_BUSYWAIT) &&
> >> - __i915_spin_request(rq, state)) {
> >> - dma_fence_signal(>fence);
> >> + __i915_spin_request(rq, state))
> >> goto out;
> >> - }
> >> /*
> >> * This client is about to stall waiting for the GPU. In many cases
> >> @@ -1796,10 +1794,8 @@ long i915_request_wait(struct i915_request *rq,
> >> for (;;) {
> >> set_current_state(state);
> >> - if (i915_request_completed(rq)) {
> >> - dma_fence_signal(>fence);
> >> + if (dma_fence_is_signaled(>fence))
> >> break;
> >> - }
> >> intel_engine_flush_submission(rq->engine);
> >>
> >
> > In other words putting some latency back into the waiters, which is
> > probably okay, since sync waits is not our primary model.
> >
> > I have a slight concern about the remaining value of busy spinning if
> > i915_request_completed check is removed from there as well. Of course it
> > doesn't make sense to have different completion criteria between the
> > two.. We could wait a bit longer if real check in busyspin said request
> > is actually completed, just not signal it but wait for the breadcrumbs
> > to do it.
>
> What a load of nonsense.. :)
>
> Okay, I think the only real question is i915_request_completed vs
> dma_fence_signaled in __i915_spin_request. Do we want to burn CPU cycles
> waiting on GPU and breadcrumb irq work, or just the GPU.
dma_fence_is_signaled() {
if (test_bit(SIGNALED_BIT))
return true;
if (i915_request_completed()) {
dma_fence_signal();
return true;
}
return false;
}
with the indirection. So the question is whether the indirection is
worth the extra test bit. Just purely looking at the i915_request.lock
contention suggests that it probably is. For the spinner, burning a few
extra CPU cycles for *vfunc is not an issue, it's the wakeup latency,
and since we are calling dma_fence_signal() upon wakeup we do take the
spinlock without checking for an early return from the SIGNALED_BIT.
So I think it's a net positive. The alternative was to write
if (i915_request_completed()) {
if (!i915_request_is_signaled())
dma_fence_signal();
break;
}
but
if (dma_fence_is_signaled())
break;
does appear simpler, if only by virtue of hiding the details in an
inline.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] dma-buf/dma-fence: Add quick tests before dma_fence_remove_callback
On Wed, Jul 15, 2020 at 4:37 PM Chris Wilson wrote:
>
> Quoting Daniel Vetter (2020-07-15 15:03:34)
> > On Wed, Jul 15, 2020 at 2:40 PM Chris Wilson
> > wrote:
> > > There's a further problem in that we call INIT_LIST_HEAD on the
> > > dma_fence_cb before the signal callback. So even if list_empty_careful()
> > > confirms the dma_fence_cb to be completely decoupled, the containing
> > > struct may still be inuse.
> >
> > The kerneldoc of dma_fence_remove_callback() already has a very stern
> > warning that this will blow up if you don't hold a full reference or
> > otherwise control the lifetime of this stuff. So I don't think we have
> > to worry about any of that. Or do you mean something else?
>
> It's the struct dma_fence_cb itself that may be freed/reused. Consider
> dma_fence_default_wait(). That uses struct default_wait_cb on the stack,
> so in order to ensure that the callback is completed the list_empty
> check has to remain under the spinlock, or else
> dma_fence_default_wait_cb() can still be dereferencing wait->task as the
> function returns.
The current implementation of remove_callback doesn't work if you
don't own the callback structure. Or control its lifetime through some
other means.
So if we have callers removing other callback structures, that just
doesn't work, you can only remove your own.
>From a quick spot check across a few callers we don't seem to have a
problem here, all current callers for this function are in various
wait functions (driver specific, or multi fence waits, stuff like
that).
-Daniel
> So currently it is:
>
> signed long
> dma_fence_default_wait(struct dma_fence *fence, bool intr, signed long
> timeout)
> {
> struct default_wait_cb cb;
> unsigned long flags;
> signed long ret = timeout ? timeout : 1;
>
> spin_lock_irqsave(fence->lock, flags);
>
> if (intr && signal_pending(current)) {
> ret = -ERESTARTSYS;
> goto out;
> }
>
> if (!__dma_fence_enable_signaling(fence))
> goto out;
>
> if (!timeout) {
> ret = 0;
> goto out;
> }
>
> cb.base.func = dma_fence_default_wait_cb;
> cb.task = current;
> list_add(, >cb_list);
>
> while (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags) && ret >
> 0) {
> if (intr)
> __set_current_state(TASK_INTERRUPTIBLE);
> else
> __set_current_state(TASK_UNINTERRUPTIBLE);
> spin_unlock_irqrestore(fence->lock, flags);
>
> ret = schedule_timeout(ret);
>
> spin_lock_irqsave(fence->lock, flags);
> if (ret > 0 && intr && signal_pending(current))
> ret = -ERESTARTSYS;
> }
>
> if (!list_empty())
> list_del();
> __set_current_state(TASK_RUNNING);
>
> out:
> spin_unlock_irqrestore(fence->lock, flags);
> return ret;
> }
>
> but it could be written as:
>
> signed long
> dma_fence_default_wait(struct dma_fence *fence, bool intr, signed long
> timeout)
> {
> struct default_wait_cb cb;
> int state = intr ? TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE;
>
> cb.task = current;
> if (dma_fence_add_callback(fence, ,
> dma_fence_default_wait_cb))
> return timeout ? timeout : 1;
>
> for (;;) {
> set_current_state(state);
>
> if (dma_fence_is_signaled(fence)) {
> timeout = timeout ? timeout : 1;
> break;
> }
>
> if (signal_pending_state(state, current)) {
> timeout = -ERESTARTSYS;
> break;
> }
>
> if (!timeout)
> break;
>
> timeout = schedule_timeout(timeout);
> }
> __set_current_state(TASK_RUNNING);
>
> dma_fence_remove_callback(fence, );
>
> return timeout;
> }
> -Chris
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] dma-buf/dma-fence: Add quick tests before dma_fence_remove_callback
Quoting Daniel Vetter (2020-07-15 15:03:34)
> On Wed, Jul 15, 2020 at 2:40 PM Chris Wilson wrote:
> > There's a further problem in that we call INIT_LIST_HEAD on the
> > dma_fence_cb before the signal callback. So even if list_empty_careful()
> > confirms the dma_fence_cb to be completely decoupled, the containing
> > struct may still be inuse.
>
> The kerneldoc of dma_fence_remove_callback() already has a very stern
> warning that this will blow up if you don't hold a full reference or
> otherwise control the lifetime of this stuff. So I don't think we have
> to worry about any of that. Or do you mean something else?
It's the struct dma_fence_cb itself that may be freed/reused. Consider
dma_fence_default_wait(). That uses struct default_wait_cb on the stack,
so in order to ensure that the callback is completed the list_empty
check has to remain under the spinlock, or else
dma_fence_default_wait_cb() can still be dereferencing wait->task as the
function returns.
So currently it is:
signed long
dma_fence_default_wait(struct dma_fence *fence, bool intr, signed long timeout)
{
struct default_wait_cb cb;
unsigned long flags;
signed long ret = timeout ? timeout : 1;
spin_lock_irqsave(fence->lock, flags);
if (intr && signal_pending(current)) {
ret = -ERESTARTSYS;
goto out;
}
if (!__dma_fence_enable_signaling(fence))
goto out;
if (!timeout) {
ret = 0;
goto out;
}
cb.base.func = dma_fence_default_wait_cb;
cb.task = current;
list_add(, >cb_list);
while (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags) && ret >
0) {
if (intr)
__set_current_state(TASK_INTERRUPTIBLE);
else
__set_current_state(TASK_UNINTERRUPTIBLE);
spin_unlock_irqrestore(fence->lock, flags);
ret = schedule_timeout(ret);
spin_lock_irqsave(fence->lock, flags);
if (ret > 0 && intr && signal_pending(current))
ret = -ERESTARTSYS;
}
if (!list_empty())
list_del();
__set_current_state(TASK_RUNNING);
out:
spin_unlock_irqrestore(fence->lock, flags);
return ret;
}
but it could be written as:
signed long
dma_fence_default_wait(struct dma_fence *fence, bool intr, signed long timeout)
{
struct default_wait_cb cb;
int state = intr ? TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE;
cb.task = current;
if (dma_fence_add_callback(fence, , dma_fence_default_wait_cb))
return timeout ? timeout : 1;
for (;;) {
set_current_state(state);
if (dma_fence_is_signaled(fence)) {
timeout = timeout ? timeout : 1;
break;
}
if (signal_pending_state(state, current)) {
timeout = -ERESTARTSYS;
break;
}
if (!timeout)
break;
timeout = schedule_timeout(timeout);
}
__set_current_state(TASK_RUNNING);
dma_fence_remove_callback(fence, );
return timeout;
}
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2] drm/i915: Remove i915_request.lock requirement for execution callbacks (rev2)
== Series Details ==
Series: series starting with [v2] drm/i915: Remove i915_request.lock
requirement for execution callbacks (rev2)
URL : https://patchwork.freedesktop.org/series/79467/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8750 -> Patchwork_18178
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/index.html
Known issues
Here are the changes found in Patchwork_18178 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar
issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-y/igt@gem_ctx_cre...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/fi-tgl-y/igt@gem_ctx_cre...@basic.html
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][3] -> [FAIL][4] ([i915#1888])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@coherency:
- fi-gdg-551: [PASS][7] -> [DMESG-FAIL][8] ([i915#1748])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-gdg-551/igt@i915_selftest@l...@coherency.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/fi-gdg-551/igt@i915_selftest@l...@coherency.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
Possible fixes
* igt@i915_module_load@reload:
- fi-byt-j1900: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-byt-j1900/igt@i915_module_l...@reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/fi-byt-j1900/igt@i915_module_l...@reload.html
- fi-bxt-dsi: [DMESG-WARN][13] ([i915#1635] / [i915#1982]) ->
[PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-bxt-dsi/igt@i915_module_l...@reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/fi-bxt-dsi/igt@i915_module_l...@reload.html
- fi-tgl-u2: [DMESG-WARN][15] ([i915#402]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-u2/igt@i915_module_l...@reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-y: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-y/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/fi-tgl-y/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- {fi-kbl-7560u}: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- {fi-tgl-dsi}: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22] +1
similar issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-dsi/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/fi-tgl-dsi/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-bsw-kefka: [DMESG-WARN][23] ([i915#1982]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18178/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][25] ([i915#62]) -> [SKIP][26]
([fdo#109271])
[25]:
Re: [Intel-gfx] [PATCH v2] drm/i915/fbc: Limit cfb to the first 256MiB of stolen on g4x+
On Tue, Jul 14, 2020 at 09:32:54PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2020-07-14 21:19:45)
> > From: Ville Syrjälä
> >
> > Since g4x the CFB base only takes a 28bit offset into stolen.
> > Not sure if the CFB is allowed to start below that limit but
> > then extend beyond it. Let's assume not and just restrict the
> > allocation to the first 256MiB (in the unlikely case
> > we have more stolen than that).
> >
> > v2: s/BIT/BIT_ULL/ (Chris)
> >
> > Cc: Chris Wilson
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_fbc.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > index 85723fba6002..3a4f980788a6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > @@ -424,6 +424,14 @@ static void intel_fbc_deactivate(struct
> > drm_i915_private *dev_priv,
> > fbc->no_fbc_reason = reason;
> > }
> >
> > +static u64 intel_fbc_cfb_base_max(struct drm_i915_private *i915)
> > +{
> > + if (INTEL_GEN(i915) >= 5 || IS_G4X(i915))
> > + return BIT_ULL(28);
> > + else
> > + return BIT_ULL(32);
> > +}
>
> Confirmed that ilk uses 23:12. I trust g4x is the same.
I guess you mean 27:12? Or did you find a some docs saying it's only
24 bits? All the docs I have say 27:12.
And just for the heck of it I tested on real hw by writing ~0
to the register. This gave me the following results:
snb/ivb/kbl: 0x0000 -> agrees with the docs
g4x/ilk: 0xf0f0 -> kinda looks like it's trying to be a 36bit address
cl: 0x -> can't make any real conclusions
So the g4x/ilk case is a bit strange. Maybe they initially planned to
make it take 36bit physical addresses and then changed their minds and
just made it an offset into stolen. Would need actual testing to confirm
whether >28bit offsets work. Too lazy to do that atm so limiting to
28bits as per the docs is the safe route. Also >32bits would seem
rather pointless anyway as I don't think stolen can live above 4GiB on
these platforms.
> Reviewed-by: Chris Wilson
>
> I didn't find the others quickly, but it's not going to harm.
> -Chris
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/66] drm/i915: Reduce i915_request.lock contention for i915_request_wait
== Series Details ==
Series: series starting with [01/66] drm/i915: Reduce i915_request.lock
contention for i915_request_wait
URL : https://patchwork.freedesktop.org/series/79517/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8750 -> Patchwork_18177
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18177 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18177, 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_18177/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18177:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@execlists:
- fi-cfl-8109u: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18177/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
- fi-icl-u2: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-icl-u2/igt@i915_selftest@l...@execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18177/fi-icl-u2/igt@i915_selftest@l...@execlists.html
- fi-tgl-y: [PASS][5] -> [INCOMPLETE][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-y/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18177/fi-tgl-y/igt@i915_selftest@l...@execlists.html
- fi-cfl-8700k: [PASS][7] -> [INCOMPLETE][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-cfl-8700k/igt@i915_selftest@l...@execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18177/fi-cfl-8700k/igt@i915_selftest@l...@execlists.html
- fi-tgl-u2: [PASS][9] -> [INCOMPLETE][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-u2/igt@i915_selftest@l...@execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18177/fi-tgl-u2/igt@i915_selftest@l...@execlists.html
- fi-cml-s: [PASS][11] -> [INCOMPLETE][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-cml-s/igt@i915_selftest@l...@execlists.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18177/fi-cml-s/igt@i915_selftest@l...@execlists.html
- fi-cfl-guc: [PASS][13] -> [INCOMPLETE][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-cfl-guc/igt@i915_selftest@l...@execlists.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18177/fi-cfl-guc/igt@i915_selftest@l...@execlists.html
- fi-icl-y: [PASS][15] -> [INCOMPLETE][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-icl-y/igt@i915_selftest@l...@execlists.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18177/fi-icl-y/igt@i915_selftest@l...@execlists.html
- fi-whl-u: [PASS][17] -> [INCOMPLETE][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-whl-u/igt@i915_selftest@l...@execlists.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18177/fi-whl-u/igt@i915_selftest@l...@execlists.html
- fi-cml-u2: [PASS][19] -> [INCOMPLETE][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-cml-u2/igt@i915_selftest@l...@execlists.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18177/fi-cml-u2/igt@i915_selftest@l...@execlists.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@execlists:
- {fi-ehl-1}: [PASS][21] -> [INCOMPLETE][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-ehl-1/igt@i915_selftest@l...@execlists.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18177/fi-ehl-1/igt@i915_selftest@l...@execlists.html
- {fi-tgl-dsi}: [PASS][23] -> [INCOMPLETE][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18177/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
Known issues
Here are the changes found in Patchwork_18177 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][25] -> [FAIL][26] ([i915#1888]) +1 similar
issue
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8750/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[26]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2] drm/i915: Remove i915_request.lock requirement for execution callbacks (rev2)
== Series Details == Series: series starting with [v2] drm/i915: Remove i915_request.lock requirement for execution callbacks (rev2) URL : https://patchwork.freedesktop.org/series/79467/ 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.IGT: failure for series starting with [01/23] Revert "drm/i915/gem: Async GPU relocations only" (rev3)
== Series Details == Series: series starting with [01/23] Revert "drm/i915/gem: Async GPU relocations only" (rev3) URL : https://patchwork.freedesktop.org/series/79470/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8748_full -> Patchwork_18175_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18175_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18175_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_18175_full: ### IGT changes ### Possible regressions * igt@gem_exec_reloc@basic-many-active@rcs0: - shard-tglb: [PASS][1] -> [FAIL][2] +9 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-tglb7/igt@gem_exec_reloc@basic-many-act...@rcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18175/shard-tglb6/igt@gem_exec_reloc@basic-many-act...@rcs0.html - shard-glk: [PASS][3] -> [FAIL][4] +7 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-glk6/igt@gem_exec_reloc@basic-many-act...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18175/shard-glk3/igt@gem_exec_reloc@basic-many-act...@rcs0.html * igt@gem_exec_reloc@basic-many-active@vcs0: - shard-kbl: [PASS][5] -> [FAIL][6] +9 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-kbl2/igt@gem_exec_reloc@basic-many-act...@vcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18175/shard-kbl3/igt@gem_exec_reloc@basic-many-act...@vcs0.html * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-skl: [PASS][7] -> [FAIL][8] +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-skl1/igt@gem_exec_reloc@basic-wide-act...@bcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18175/shard-skl7/igt@gem_exec_reloc@basic-wide-act...@bcs0.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-snb: [PASS][9] -> [FAIL][10] +5 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-snb4/igt@gem_exec_reloc@basic-wide-act...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18175/shard-snb2/igt@gem_exec_reloc@basic-wide-act...@rcs0.html - shard-iclb: [PASS][11] -> [FAIL][12] +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-iclb7/igt@gem_exec_reloc@basic-wide-act...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18175/shard-iclb1/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][13] +5 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18175/shard-iclb1/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@kms_cursor_legacy@long-nonblocking-modeset-vs-cursor-atomic: - shard-tglb: [PASS][14] -> [INCOMPLETE][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-tglb6/igt@kms_cursor_leg...@long-nonblocking-modeset-vs-cursor-atomic.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18175/shard-tglb6/igt@kms_cursor_leg...@long-nonblocking-modeset-vs-cursor-atomic.html Known issues Here are the changes found in Patchwork_18175_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-contexts-10ms: - shard-snb: [PASS][16] -> [TIMEOUT][17] ([i915#1958] / [i915#2119]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-snb6/igt@gem_...@in-flight-contexts-10ms.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18175/shard-snb2/igt@gem_...@in-flight-contexts-10ms.html * igt@gem_exec_reloc@basic-many-active@rcs0: - shard-apl: [PASS][18] -> [FAIL][19] ([i915#1635]) +5 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-apl8/igt@gem_exec_reloc@basic-many-act...@rcs0.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18175/shard-apl2/igt@gem_exec_reloc@basic-many-act...@rcs0.html * igt@gem_exec_reloc@basic-parallel: - shard-kbl: [PASS][20] -> [TIMEOUT][21] ([i915#1958] / [i915#2119]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-kbl3/igt@gem_exec_re...@basic-parallel.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18175/shard-kbl6/igt@gem_exec_re...@basic-parallel.html - shard-tglb: [PASS][22] -> [TIMEOUT][23] ([i915#1958] / [i915#2119]) [22]:
Re: [Intel-gfx] [PULL] drm-intel-next
On Wed, Jul 15, 2020 at 3:34 PM Jani Nikula wrote: > > > Argh, failed to mention: > > On Wed, 15 Jul 2020, Jani Nikula wrote: > > Lee Shawn C (1): > > drm/i915/mst: filter out the display mode exceed sink's capability > > The above depends on: > > > Lyude Paul (1): > > drm/probe_helper: Add drm_connector_helper_funcs.mode_valid_ctx > > Which has changes outside of i915: > > > drivers/gpu/drm/drm_crtc_helper_internal.h | 7 +- > > drivers/gpu/drm/drm_probe_helper.c | 97 +-- > > and does not have an explicit ack recorded, though drm-misc maintainers > have been Cc'd. :( > > I decided they were benign enough, but needed to be mentioned. Yeah looks all fine, adding Lyude just as fyi. -Daniel > > BR, > Jani. > > > -- > Jani Nikula, Intel Open Source Graphics Center -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] dma-buf/dma-fence: Add quick tests before dma_fence_remove_callback
On Wed, Jul 15, 2020 at 2:40 PM Chris Wilson wrote: > Quoting Chris Wilson (2020-07-15 13:21:43) > > Quoting Daniel Vetter (2020-07-15 13:10:22) > > > On Wed, Jul 15, 2020 at 11:49:05AM +0100, Chris Wilson wrote: > > > > When waiting with a callback on the stack, we must remove the callback > > > > upon wait completion. Since this will be notified by the fence signal > > > > callback, the removal often contends with the fence->lock being held by > > > > the signaler. We can look at the list entry to see if the callback was > > > > already signaled before we take the contended lock. > > > > > > > > Signed-off-by: Chris Wilson > > > > --- > > > > drivers/dma-buf/dma-fence.c | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > > > > index 8d5bdfce638e..b910d7bc0854 100644 > > > > --- a/drivers/dma-buf/dma-fence.c > > > > +++ b/drivers/dma-buf/dma-fence.c > > > > @@ -420,6 +420,9 @@ dma_fence_remove_callback(struct dma_fence *fence, > > > > struct dma_fence_cb *cb) > > > > unsigned long flags; > > > > bool ret; > > > > > > > > + if (list_empty(>node)) > > > > > > I was about to say "but the races" but then noticed that Paul fixed > > > list_empty to use READ_ONCE like 5 years ago :-) > > > > I'm always going "when exactly do we need list_empty_careful()"? > > > > We can rule out a concurrent dma_fence_add_callback() for the same > > dma_fence_cb, as that is a lost cause. So we only have to worry about > > the concurrent list_del_init() from dma_fence_signal_locked(). So it's > > the timing of > > list_del_init(): WRITE_ONCE(list->next, list) > > vs > > READ_ONCE(list->next) == list > > and we don't need to care about the trailing instructions in > > list_del_init()... > > > > Wait that trailing instruction is actually important here if the > > dma_fence_cb is on the stack, or other imminent free. > > > > Ok, this does need to be list_empty_careful! Hm, tbh I'm not really clear what list_empty_careful does on top. Seems to lack READ_ONCE, so either some really big trickery with dependencies is going on, or I'm not even sure how this works without locks. I've now stared at list_empty_careful and a bunch of users quite a bit, and I have now idea when you'd want to use it. Lockless you want a READ_ONCE I think and a simple check, so list_empty. And just accept that any time you race you'll go into the locked slowpath for "list isn't empty". Also only works if the list_empty case is the "nothing to do, job already done" case, since the other one just isn't guaranteed to be accurate. list_empty_careful just wraps a bunch more magic around that will make this both worse, and more racy (if the compiler feels creative) because no READ_ONCE or anything like that. I don't get what that thing is for ... > There's a further problem in that we call INIT_LIST_HEAD on the > dma_fence_cb before the signal callback. So even if list_empty_careful() > confirms the dma_fence_cb to be completely decoupled, the containing > struct may still be inuse. The kerneldoc of dma_fence_remove_callback() already has a very stern warning that this will blow up if you don't hold a full reference or otherwise control the lifetime of this stuff. So I don't think we have to worry about any of that. Or do you mean something else? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Remove i915_request.lock requirement for execution callbacks
We are using the i915_request.lock to serialise adding an execution
callback with __i915_request_submit. However, if we use an atomic
llist_add to serialise multiple waiters and then check to see if the
request is already executing, we can remove the irq-spinlock.
v2: Avoid using the irq_work when outside of the irq-spinlocks, where we
can execute the callbacks immediately.
Fixes: 1d9221e9d395 ("drm/i915: Skip signaling a signaled request")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 74 -
1 file changed, 31 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index bb4eb1a8780e..9481e54d695e 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -186,30 +186,34 @@ static void irq_execute_cb_hook(struct irq_work *wrk)
irq_execute_cb(wrk);
}
-static void __notify_execute_cb(struct i915_request *rq)
+static __always_inline void
+__notify_execute_cb(struct i915_request *rq, bool (*fn)(struct irq_work *wrk))
{
struct execute_cb *cb, *cn;
- lockdep_assert_held(>lock);
-
- GEM_BUG_ON(!i915_request_is_active(rq));
if (llist_empty(>execute_cb))
return;
- llist_for_each_entry_safe(cb, cn, rq->execute_cb.first, work.llnode)
- irq_work_queue(>work);
+ llist_for_each_entry_safe(cb, cn,
+ llist_del_all(>execute_cb),
+ work.llnode)
+ fn(>work);
+}
- /*
-* XXX Rollback on __i915_request_unsubmit()
-*
-* In the future, perhaps when we have an active time-slicing scheduler,
-* it will be interesting to unsubmit parallel execution and remove
-* busywaits from the GPU until their master is restarted. This is
-* quite hairy, we have to carefully rollback the fence and do a
-* preempt-to-idle cycle on the target engine, all the while the
-* master execute_cb may refire.
-*/
- init_llist_head(>execute_cb);
+static void __notify_execute_cb_irq(struct i915_request *rq)
+{
+ __notify_execute_cb(rq, irq_work_queue);
+}
+
+static bool irq_work_imm(struct irq_work *wrk)
+{
+ wrk->func(wrk);
+ return false;
+}
+
+static void __notify_execute_cb_imm(struct i915_request *rq)
+{
+ __notify_execute_cb(rq, irq_work_imm);
}
static inline void
@@ -274,9 +278,11 @@ static void remove_from_engine(struct i915_request *rq)
locked = engine;
}
list_del_init(>sched.link);
+ spin_unlock_irq(>active.lock);
+
clear_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
clear_bit(I915_FENCE_FLAG_HOLD, >fence.flags);
- spin_unlock_irq(>active.lock);
+ set_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags);
}
bool i915_request_retire(struct i915_request *rq)
@@ -288,6 +294,7 @@ bool i915_request_retire(struct i915_request *rq)
GEM_BUG_ON(!i915_sw_fence_signaled(>submit));
trace_i915_request_retire(rq);
+ i915_request_mark_complete(rq);
/*
* We know the GPU must have read the request to have
@@ -314,7 +321,6 @@ bool i915_request_retire(struct i915_request *rq)
remove_from_engine(rq);
spin_lock_irq(>lock);
- i915_request_mark_complete(rq);
if (!i915_request_signaled(rq))
dma_fence_signal_locked(>fence);
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
@@ -323,12 +329,8 @@ bool i915_request_retire(struct i915_request *rq)
GEM_BUG_ON(!atomic_read(>engine->gt->rps.num_waiters));
atomic_dec(>engine->gt->rps.num_waiters);
}
- if (!test_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags)) {
- set_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags);
- __notify_execute_cb(rq);
- }
- GEM_BUG_ON(!llist_empty(>execute_cb));
spin_unlock_irq(>lock);
+ __notify_execute_cb_imm(rq);
remove_from_client(rq);
__list_del_entry(>link); /* poison neither prev/next (RCU walks) */
@@ -357,12 +359,6 @@ void i915_request_retire_upto(struct i915_request *rq)
} while (i915_request_retire(tmp) && tmp != rq);
}
-static void __llist_add(struct llist_node *node, struct llist_head *head)
-{
- node->next = head->first;
- head->first = node;
-}
-
static struct i915_request * const *
__engine_active(struct intel_engine_cs *engine)
{
@@ -439,18 +435,11 @@ __await_execution(struct i915_request *rq,
cb->work.func = irq_execute_cb_hook;
}
- spin_lock_irq(>lock);
- if (i915_request_is_active(signal) || __request_in_flight(signal)) {
- if (hook) {
- hook(rq, >fence);
- i915_request_put(signal);
- }
- i915_sw_fence_complete(cb->fence);
-
Re: [Intel-gfx] [PATCH 08/25] drm/malidp: Annotate dma-fence critical section in commit path
On Wed, Jul 15, 2020 at 2:53 PM Liviu Dudau wrote: > > On Tue, Jul 07, 2020 at 10:12:12PM +0200, Daniel Vetter wrote: > > Again needs to be put right after the call to > > drm_atomic_helper_commit_hw_done(), since that's the last thing which > > can hold up a subsequent atomic commit. > > > > No surprises here. > > I was (still am) hoping to do a testing for this patch but when I dug out the > series > from the ML it looked like it has extra dependencies, so I was waiting for > the dust > to settle. > > Otherwise, LGTM. I should all just apply I think, it's based on drm-tip. Branch with bunch of other random stuff is here: https://cgit.freedesktop.org/~danvet/drm/log/ If that doesn't cherry-pick cleanly I'm confused about something. -Daniel > > Best regards, > Liviu > > > > > Signed-off-by: Daniel Vetter > > Cc: "James (Qian) Wang" > > Cc: Liviu Dudau > > Cc: Mihail Atanassov > > --- > > drivers/gpu/drm/arm/malidp_drv.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/gpu/drm/arm/malidp_drv.c > > b/drivers/gpu/drm/arm/malidp_drv.c > > index 69fee05c256c..26e60401a8e1 100644 > > --- a/drivers/gpu/drm/arm/malidp_drv.c > > +++ b/drivers/gpu/drm/arm/malidp_drv.c > > @@ -234,6 +234,7 @@ static void malidp_atomic_commit_tail(struct > > drm_atomic_state *state) > > struct drm_crtc *crtc; > > struct drm_crtc_state *old_crtc_state; > > int i; > > + bool fence_cookie = dma_fence_begin_signalling(); > > > > pm_runtime_get_sync(drm->dev); > > > > @@ -260,6 +261,8 @@ static void malidp_atomic_commit_tail(struct > > drm_atomic_state *state) > > > > malidp_atomic_commit_hw_done(state); > > > > + dma_fence_end_signalling(fence_cookie); > > + > > pm_runtime_put(drm->dev); > > > > drm_atomic_helper_cleanup_planes(drm, state); > > -- > > 2.27.0 > > > > -- > > | I would like to | > | fix the world, | > | but they're not | > | giving me the | > \ source code! / > --- > ¯\_(ツ)_/¯ -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] dma-buf/dma-fence: Trim dma_fence_add_callback()
== Series Details == Series: series starting with [1/2] dma-buf/dma-fence: Trim dma_fence_add_callback() URL : https://patchwork.freedesktop.org/series/79513/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8748_full -> Patchwork_18174_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18174_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18174_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_18174_full: ### IGT changes ### Possible regressions * igt@gem_exec_fence@parallel@rcs0: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-iclb7/igt@gem_exec_fence@paral...@rcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18174/shard-iclb2/igt@gem_exec_fence@paral...@rcs0.html Known issues Here are the changes found in Patchwork_18174_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fence@concurrent@rcs0: - shard-apl: [PASS][3] -> [INCOMPLETE][4] ([i915#1635]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-apl1/igt@gem_exec_fence@concurr...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18174/shard-apl8/igt@gem_exec_fence@concurr...@rcs0.html * igt@gem_exec_gttfill@all: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-glk7/igt@gem_exec_gttf...@all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18174/shard-glk1/igt@gem_exec_gttf...@all.html * igt@i915_module_load@reload: - shard-tglb: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-tglb1/igt@i915_module_l...@reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18174/shard-tglb2/igt@i915_module_l...@reload.html * igt@kms_big_fb@y-tiled-64bpp-rotate-0: - shard-glk: [PASS][9] -> [DMESG-FAIL][10] ([i915#118] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-glk2/igt@kms_big...@y-tiled-64bpp-rotate-0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18174/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-0.html * igt@kms_flip@basic-plain-flip@a-edp1: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +8 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-skl6/igt@kms_flip@basic-plain-f...@a-edp1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18174/shard-skl8/igt@kms_flip@basic-plain-f...@a-edp1.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#79]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-skl2/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-edp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18174/shard-skl10/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-edp1.html * igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a2: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#79]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-glk6/igt@kms_flip@flip-vs-expired-vbl...@b-hdmi-a2.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18174/shard-glk9/igt@kms_flip@flip-vs-expired-vbl...@b-hdmi-a2.html * igt@kms_frontbuffer_tracking@fbcpsr-stridechange: - shard-tglb: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-tglb2/igt@kms_frontbuffer_track...@fbcpsr-stridechange.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18174/shard-tglb2/igt@kms_frontbuffer_track...@fbcpsr-stridechange.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#1188]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-skl10/igt@kms_...@bpc-switch-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18174/shard-skl6/igt@kms_...@bpc-switch-suspend.html * igt@kms_plane@plane-panning-top-left-pipe-a-planes: - shard-iclb: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-iclb8/igt@kms_pl...@plane-panning-top-left-pipe-a-planes.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18174/shard-iclb3/igt@kms_pl...@plane-panning-top-left-pipe-a-planes.html
Re: [Intel-gfx] [PATCH v5 1/2] drm/i915/display: Implement HOBL
On Mon, Jul 13, 2020 at 04:53:33PM -0700, José Roberto de Souza wrote:
> Hours Of Battery Life is a new GEN12+ power-saving feature that allows
> supported motherboards to use a special voltage swing table for eDP
> panels that uses less power.
>
> So here if supported by HW, OEM will set it in VBT and i915 will try
> to train link with HOBL vswing table if link training fails it fall
> back to the original table.
>
> intel_ddi_dp_preemph_max() was optimized to only check the HOBL flag
> instead of do something like is done in intel_ddi_dp_voltage_max()
> because it is only called after the first entry of the voltage swing
> table was loaded so the HOBL flag is valid at that point.
>
> v3:
> - removed a few parameters of icl_ddi_combo_vswing_program() that
> can be taken from encoder
>
> v4:
> - using the HOBL vswing table until training fails completely (Ville)
>
> v5:
> - not reducing lane or link rate when link training fails with HOBL
> active
> - duplicated the HOBL voltage swing entry to match DP spec requirement
>
> BSpec: 49291
> BSpec: 49399
> Cc: Ville Syrjälä
> Cc: Animesh Manna
> Cc: Manasi Navare
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 42 +++
> .../drm/i915/display/intel_display_types.h| 2 +
> .../drm/i915/display/intel_dp_link_training.c | 19 ++---
> drivers/gpu/drm/i915/i915_reg.h | 2 +
> 4 files changed, 59 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 2c484b55bcdf..92ae036440fa 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -706,6 +706,29 @@ static const struct cnl_ddi_buf_trans
> tgl_combo_phy_ddi_translations_dp_hbr2[] =
> { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
> };
>
> +/*
> + * Cloned the HOBL entry to comply with the voltage and pre-emphasis entries
> + * that DisplayPort specification requires
> + */
> +static const struct cnl_ddi_buf_trans
> tgl_combo_phy_ddi_translations_edp_hbr2_hobl[] = {
> + /* VS pre-emp */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 00 */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 01 */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 02 */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 03 */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 10 */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 11 */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 12 */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 20 */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 21 */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 30 */
> +};
> +
> +static bool is_hobl_buf_trans(const struct cnl_ddi_buf_trans *table)
> +{
> + return table == tgl_combo_phy_ddi_translations_edp_hbr2_hobl;
> +}
OK, so after further thought I guess the double boolean is the least
annoying apporach atm. Slight concerns about this function becoming a
bit of maintenance nightmare, but if we want to improve it then I
suspect we want to revamp the overall buf trans stuff. Eg. I had
one idea to declare the capabilities in each buf trans table. But
not sure if that's viable. Anyway more long term idea.
> +
> static const struct ddi_buf_trans *
> bdw_get_buf_trans_edp(struct intel_encoder *encoder, int *n_entries)
> {
> @@ -1050,6 +1073,16 @@ static const struct cnl_ddi_buf_trans *
> tgl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
> int *n_entries)
> {
> + if (type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp.hobl) {
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> +
> + if (!intel_dp->hobl_failed && rate <= 54) {
> + /* Same table applies to TGL, RKL and DG1 */
> + *n_entries =
> ARRAY_SIZE(tgl_combo_phy_ddi_translations_edp_hbr2_hobl);
> + return tgl_combo_phy_ddi_translations_edp_hbr2_hobl;
> + }
> + }
> +
> if (type == INTEL_OUTPUT_HDMI || type == INTEL_OUTPUT_EDP) {
> return icl_get_combo_buf_trans(encoder, type, rate, n_entries);
> } else if (rate > 27) {
> @@ -2392,6 +2425,15 @@ static void icl_ddi_combo_vswing_program(struct
> intel_encoder *encoder,
> level = n_entries - 1;
> }
>
> + if (type == INTEL_OUTPUT_EDP) {
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> +
> + val = EDP4K2K_MODE_OVRD_EN | EDP4K2K_MODE_OVRD_OPTIMIZED;
> + intel_dp->hobl_active = is_hobl_buf_trans(ddi_translations);
Slightly irks me that we basically now compute this piece of state in
the middle here. But not sure if there's a better way. Anything else
might require yet
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Remove i915_request.lock requirement for execution callbacks
On 15/07/2020 13:48, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-07-15 13:39:56)
On 14/07/2020 10:47, Chris Wilson wrote:
We are using the i915_request.lock to serialise adding an execution
callback with __i915_request_submit. However, if we use an atomic
llist_add to serialise multiple waiters and then check to see if the
request is already executing, we can remove the irq-spinlock.
Fixes: 1d9221e9d395 ("drm/i915: Skip signaling a signaled request")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 38 +++--
1 file changed, 9 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 0b2fe55e6194..c59315def07d 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -190,13 +190,11 @@ static void __notify_execute_cb(struct i915_request *rq)
{
struct execute_cb *cb, *cn;
- lockdep_assert_held(>lock);
-
- GEM_BUG_ON(!i915_request_is_active(rq));
if (llist_empty(>execute_cb))
return;
- llist_for_each_entry_safe(cb, cn, rq->execute_cb.first, work.llnode)
+ llist_for_each_entry_safe(cb, cn,
+ llist_del_all(>execute_cb), work.llnode)
irq_work_queue(>work);
/*
@@ -209,7 +207,6 @@ static void __notify_execute_cb(struct i915_request *rq)
* preempt-to-idle cycle on the target engine, all the while the
* master execute_cb may refire.
*/
- init_llist_head(>execute_cb);
}
static inline void
@@ -276,6 +273,7 @@ static void remove_from_engine(struct i915_request *rq)
list_del_init(>sched.link);
clear_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
clear_bit(I915_FENCE_FLAG_HOLD, >fence.flags);
+ set_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags);
spin_unlock_irq(>active.lock);
}
@@ -323,12 +321,8 @@ bool i915_request_retire(struct i915_request *rq)
GEM_BUG_ON(!atomic_read(>engine->gt->rps.num_waiters));
atomic_dec(>engine->gt->rps.num_waiters);
}
- if (!test_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags)) {
- set_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags);
- __notify_execute_cb(rq);
- }
- GEM_BUG_ON(!llist_empty(>execute_cb));
spin_unlock_irq(>lock);
+ __notify_execute_cb(rq);
remove_from_client(rq);
__list_del_entry(>link); /* poison neither prev/next (RCU walks) */
@@ -357,12 +351,6 @@ void i915_request_retire_upto(struct i915_request *rq)
} while (i915_request_retire(tmp) && tmp != rq);
}
-static void __llist_add(struct llist_node *node, struct llist_head *head)
-{
- node->next = head->first;
- head->first = node;
-}
-
static struct i915_request * const *
__engine_active(struct intel_engine_cs *engine)
{
@@ -439,18 +427,11 @@ __await_execution(struct i915_request *rq,
cb->work.func = irq_execute_cb_hook;
}
- spin_lock_irq(>lock);
- if (i915_request_is_active(signal) || __request_in_flight(signal)) {
- if (hook) {
- hook(rq, >fence);
- i915_request_put(signal);
- }
- i915_sw_fence_complete(cb->fence);
- kmem_cache_free(global.slab_execute_cbs, cb);
- } else {
- __llist_add(>work.llnode, >execute_cb);
+ if (llist_add(>work.llnode, >execute_cb)) {
+ if (i915_request_is_active(signal) ||
+ __request_in_flight(signal))
+ __notify_execute_cb(signal);
Any reason why the hook couldn't be called straight away but needs to
always go through the worker now?
Maybe it would be easier to figure out if it is race free that way..
if (llist_add(..)) {
llist_for_each_entry_safe(.., llist_del_all(..), .)
Then you would tell me off for open coding __notify_execute_cb for the
benefit of not going through the irq_work. Something like
@@ -186,7 +186,7 @@ static void irq_execute_cb_hook(struct irq_work *wrk)
irq_execute_cb(wrk);
}
-static void __notify_execute_cb(struct i915_request *rq)
+static void __execute_cb_irq(struct i915_request *rq)
{
struct execute_cb *cb, *cn;
@@ -209,6 +209,15 @@ static void __notify_execute_cb(struct i915_request *rq)
*/
}
+static void __execute_cb_imm(struct i915_request *rq)
+{
+ struct execute_cb *cb, *cn;
+
+ llist_for_each_entry_safe(cb, cn,
+ llist_del_all(>execute_cb), work.llnode)
+ cb->work.func(>work);
+}
+
static inline void
remove_from_client(struct i915_request *request)
{
@@ -323,7 +332,7 @@ bool i915_request_retire(struct i915_request *rq)
atomic_dec(>engine->gt->rps.num_waiters);
}
spin_unlock_irq(>lock);
- __notify_execute_cb(rq);
+ __execute_cb_imm(rq);
Re: [Intel-gfx] [PULL] drm-intel-next
Argh, failed to mention: On Wed, 15 Jul 2020, Jani Nikula wrote: > Lee Shawn C (1): > drm/i915/mst: filter out the display mode exceed sink's capability The above depends on: > Lyude Paul (1): > drm/probe_helper: Add drm_connector_helper_funcs.mode_valid_ctx Which has changes outside of i915: > drivers/gpu/drm/drm_crtc_helper_internal.h | 7 +- > drivers/gpu/drm/drm_probe_helper.c | 97 +-- and does not have an explicit ack recorded, though drm-misc maintainers have been Cc'd. :( I decided they were benign enough, but needed to be mentioned. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/66] drm/i915: Reduce i915_request.lock contention for i915_request_wait
== Series Details == Series: series starting with [01/66] drm/i915: Reduce i915_request.lock contention for i915_request_wait URL : https://patchwork.freedesktop.org/series/79517/ 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 [01/66] drm/i915: Reduce i915_request.lock contention for i915_request_wait
== Series Details == Series: series starting with [01/66] drm/i915: Reduce i915_request.lock contention for i915_request_wait URL : https://patchwork.freedesktop.org/series/79517/ State : warning == Summary == $ dim checkpatch origin/drm-tip 91bde1c5e935 drm/i915: Reduce i915_request.lock contention for i915_request_wait 13de08637a53 drm/i915: Remove i915_request.lock requirement for execution callbacks 6fa430293a65 drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs e919aa95911c drm/i915: Add a couple of missing i915_active_fini() 379852a0d374 drm/i915: Skip taking acquire mutex for no ref->active callback 8628c1a1b800 drm/i915: Export a preallocate variant of i915_active_acquire() 383c7cbfc8d5 drm/i915: Keep the most recently used active-fence upon discard 00c92cc2c921 drm/i915: Make the stale cached active node available for any timeline a938c15b20b3 drm/i915: Provide a fastpath for waiting on vma bindings 63c73191100c drm/i915: Soften the tasklet flush frequency before waits 7c20ceade654 drm/i915: Preallocate stashes for vma page-directories f62b56fc3c3f drm/i915: Switch to object allocations for page directories d9e5a405669b drm/i915/gem: Don't drop the timeline lock during execbuf a488eb2ac0c6 drm/i915/gem: Rename execbuf.bind_link to unbound_link bf7156efc5fe drm/i915/gem: Break apart the early i915_vma_pin from execbuf object lookup b336351c77f1 drm/i915/gem: Remove the call for no-evict i915_vma_pin 482c12431055 drm/i915: Add list_for_each_entry_safe_continue_reverse -:21: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pos' - possible side-effects? #21: FILE: drivers/gpu/drm/i915/i915_utils.h:269: +#define list_for_each_entry_safe_continue_reverse(pos, n, head, member) \ + for (pos = list_prev_entry(pos, member),\ +n = list_prev_entry(pos, member); \ +>member != (head);\ +pos = n, n = list_prev_entry(n, member)) -:21: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'n' - possible side-effects? #21: FILE: drivers/gpu/drm/i915/i915_utils.h:269: +#define list_for_each_entry_safe_continue_reverse(pos, n, head, member) \ + for (pos = list_prev_entry(pos, member),\ +n = list_prev_entry(pos, member); \ +>member != (head);\ +pos = n, n = list_prev_entry(n, member)) -:21: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'member' - possible side-effects? #21: FILE: drivers/gpu/drm/i915/i915_utils.h:269: +#define list_for_each_entry_safe_continue_reverse(pos, n, head, member) \ + for (pos = list_prev_entry(pos, member),\ +n = list_prev_entry(pos, member); \ +>member != (head);\ +pos = n, n = list_prev_entry(n, member)) total: 0 errors, 0 warnings, 3 checks, 12 lines checked 03f0ac6d0aa7 drm/i915: Always defer fenced work to the worker 0ffcc361f56b drm/i915/gem: Assign context id for async work 82ed2ac041bb drm/i915/gem: Separate the ww_mutex walker into its own list 8ed473e9ebb5 drm/i915/gem: Asynchronous GTT unbinding 289e4f21e37d drm/i915/gem: Bind the fence async for execbuf 3994c1315802 drm/i915/gem: Include cmdparser in common execbuf pinning d59dcbda945a drm/i915/gem: Include secure batch in common execbuf pinning a2d67581b7cc drm/i915/gem: Reintroduce multiple passes for reloc processing -:1512: WARNING:MEMORY_BARRIER: memory barrier without comment #1512: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_execbuffer.c:161: + wmb(); total: 0 errors, 1 warnings, 0 checks, 1502 lines checked 34f8c8b06fb1 drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2. -:59: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #59: new file mode 100644 -:354: WARNING:LINE_SPACING: Missing a blank line after declarations #354: FILE: drivers/gpu/drm/i915/mm/st_acquire_ctx.c:106: + const unsigned int total = ARRAY_SIZE(dl->obj); + I915_RND_STATE(prng); -:450: WARNING:YIELD: Using yield() is generally wrong. See yield() kernel-doc (sched/core.c) #450: FILE: drivers/gpu/drm/i915/mm/st_acquire_ctx.c:202: + yield(); /* start all threads before we begin */ total: 0 errors, 3 warnings, 0 checks, 446 lines checked fe0b2e8f9867 drm/i915/gem: Pull execbuf dma resv under a single critical section 0ca5333286a3 drm/i915/gem: Replace i915_gem_object.mm.mutex with reservation_ww_class 009379133a04 drm/i915: Hold wakeref for the duration of the vma GGTT binding 30196b1778f2 drm/i915: Specialise GGTT binding 7ef75aca0d57 drm/i915/gt: Acquire backing storage for the context 0e4a431e2f5e drm/i915/gt: Push the wait for the context to bound to the request -:198: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
[Intel-gfx] [PULL] drm-intel-next
Hi Dave & Daniel - The 2nd and presumably the last i915 feature pull for v5.9. drm-intel-next-2020-07-15: drm/i915 features for v5.9, batch #2 Highlights: - Very early DG1 enabling (Abdiel, Lucas, Anusha) Gem/GT: - Fix spinlock recursion on signaling a signaled request (Chris) - Perf: Use GTT when saving/restoring engine GPR (Umesh Nerlige Ramappa) - SSEU refactoring, debugfs move under gt/ (Daniele, Venkata Sandeep Dhanalakota) - Various GT refactoring and cleanup, preparation for future changes (Daniele) - Adjust HuC state accordingly after GuC fetch error (Michał Winiarski) - UC debugfs updates (Michał Winiarski) - Only revoke the GGTT mmappings on aperture detiling changes (Chris) - Only revoke mmap handlers if active (Chris) - Split the context's obj:vma lut into its own mutex (Chris) - Various memory, mmap and performance optimisations (Chris) - Improve system stability in case of false CS events (Chris) - Various refactorings and cleanup (Chris) - Always reset the engine on execlist failures (Chris) - Trace placement of timeline HWSP (Chris) - Update dma-attributes for our sg DMA (Chris) Display: - TGL CDCLK workaround tweaks to unbreak 8K display support (Stanislav) - A number of FBC fixes, along with i865 FBC enabling (Ville) - Validate MST modes against PBN limits (Lyude, Shawn Lee) - Do not access non-existing swizzle registers (Lucas) - Revert GEN11+ HBR3 rate fix that caused issues on TGL (Matt Atwood) - Update TGL+ combo phy initialization to match spec update (José) - Fix HDCP Content Protection property state machine (Anshuman) - Fix HDCP revoked keys handling (Ram) - Improve DDI BUF status checks and waits (Manasi) - Various SDVO+HDMI+DVI fixes around colorimetry, clocking, pixel repeat etc. (Ville) - DP voltage swing function refactoring (José) - WARN if max vswing/pre-emphasis violates the DP spec (Ville) Other: - Add new EHL PCI IDs (José) - Unify struct intel_digital_port variable naming (Lucas) - Various taint updates to aid debugging and improve CI (Michał Winiarski) - Straggler conversions to new mmio register accessors (Daniele) BR, Jani. The following changes since commit d524b87f77364db096855d7eb714ffacec974ddf: drm/i915: Update DRIVER_DATE to 20200702 (2020-07-02 21:25:28 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2020-07-15 for you to fetch changes up to e57bd05ec0d2d82d63725dedf9f5a063f879de25: drm/i915: Update DRIVER_DATE to 20200715 (2020-07-15 14:18:02 +0300) drm/i915 features for v5.9, batch #2 Highlights: - Very early DG1 enabling (Abdiel, Lucas, Anusha) Gem/GT: - Fix spinlock recursion on signaling a signaled request (Chris) - Perf: Use GTT when saving/restoring engine GPR (Umesh Nerlige Ramappa) - SSEU refactoring, debugfs move under gt/ (Daniele, Venkata Sandeep Dhanalakota) - Various GT refactoring and cleanup, preparation for future changes (Daniele) - Adjust HuC state accordingly after GuC fetch error (Michał Winiarski) - UC debugfs updates (Michał Winiarski) - Only revoke the GGTT mmappings on aperture detiling changes (Chris) - Only revoke mmap handlers if active (Chris) - Split the context's obj:vma lut into its own mutex (Chris) - Various memory, mmap and performance optimisations (Chris) - Improve system stability in case of false CS events (Chris) - Various refactorings and cleanup (Chris) - Always reset the engine on execlist failures (Chris) - Trace placement of timeline HWSP (Chris) - Update dma-attributes for our sg DMA (Chris) Display: - TGL CDCLK workaround tweaks to unbreak 8K display support (Stanislav) - A number of FBC fixes, along with i865 FBC enabling (Ville) - Validate MST modes against PBN limits (Lyude, Shawn Lee) - Do not access non-existing swizzle registers (Lucas) - Revert GEN11+ HBR3 rate fix that caused issues on TGL (Matt Atwood) - Update TGL+ combo phy initialization to match spec update (José) - Fix HDCP Content Protection property state machine (Anshuman) - Fix HDCP revoked keys handling (Ram) - Improve DDI BUF status checks and waits (Manasi) - Various SDVO+HDMI+DVI fixes around colorimetry, clocking, pixel repeat etc. (Ville) - DP voltage swing function refactoring (José) - WARN if max vswing/pre-emphasis violates the DP spec (Ville) Other: - Add new EHL PCI IDs (José) - Unify struct intel_digital_port variable naming (Lucas) - Various taint updates to aid debugging and improve CI (Michał Winiarski) - Straggler conversions to new mmio register accessors (Daniele) Abdiel Janulgue (2): drm/i915/dg1: add initial DG-1 definitions drm/i915/dg1: Add DG1 PCI IDs Anshuman Gupta (1): drm/i915/hdcp: Update CP as per the kernel internal state Anusha Srivatsa (1): drm/i915/dg1: Remove SHPD_FILTER_CNT register programming Chris Wilson (22): drm/i915/gem: Only revoke the GGTT mmapp
[Intel-gfx] Fixes that failed to apply to v5.8-rc5
Hi all -
The following commits have been marked as Cc: stable or fixing something
in v5.8-rc5 or earlier, but failed to cherry-pick to
drm-intel-fixes. Please see if they are worth backporting, and please do
so if they are.
Failed to cherry-pick:
e5ec1f954869 ("drm/i915/fbc: Use the correct plane stride")
1d9221e9d395 ("drm/i915: Skip signaling a signaled request")
I've already sent the pull request for -rc6 [1], I presume Joonas will
take over the backports, if any, next week.
BR,
Jani.
[1] http://lore.kernel.org/r/87ft9t0vtt@intel.com
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 0/2] minor improvements to the kms_cursor_crc doc and some comments cleanup
On Wed, Jun 24, 2020 at 06:54:00AM -0300, Melissa Wen wrote: > Hi, > > I was studying the code of kms_cursor_crc test, and I just adjusted some > comments > and added descriptions for subtests. > > Melissa Wen (2): > lib/igt_fb: change comments with fd description > test/kms_cursor_crc: update subtests descriptions and some comments Seems like there's a conflict caused by your patch removing unused parameters from igt_put_cairo_ctx(). Can you an send updated version and CC me on it? In case of false positives please comment on the CI results with a short explanation and CC Lakshmi Thanks for the cleanup! -- Cheers, Arek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave & Daniel - drm-intel-fixes-2020-07-15: drm/i915 fixes for v5.8-rc6: - FBC w/a stride fix - Fix use-after-free fix on module reload - Ignore irq enabling on the virtual engines to fix device sleep - Use GTT when saving/restoring engine GPR - Fix selftest sort function BR, Jani. The following changes since commit 11ba468877bb23f28956a35e896356252d63c983: Linux 5.8-rc5 (2020-07-12 16:34:50 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2020-07-15 for you to fetch changes up to 92e0575b99835b5b3aaab2132dd551e0e04eb96a: drm/i915: Recalculate FBC w/a stride when needed (2020-07-14 20:31:45 +0300) drm/i915 fixes for v5.8-rc6: - FBC w/a stride fix - Fix use-after-free fix on module reload - Ignore irq enabling on the virtual engines to fix device sleep - Use GTT when saving/restoring engine GPR - Fix selftest sort function Chris Wilson (2): drm/i915/gt: Ignore irq enabling on the virtual engines drm/i915/gt: Only swap to a random sibling once upon creation Maarten Lankhorst (1): drm/i915: Move cec_notifier to intel_hdmi_connector_unregister, v2. Sudeep Holla (1): drm/i915/selftests: Fix compare functions provided for sorting Umesh Nerlige Ramappa (1): drm/i915/perf: Use GTT when saving/restoring engine GPR Ville Syrjälä (1): drm/i915: Recalculate FBC w/a stride when needed drivers/gpu/drm/i915/display/intel_fbc.c | 33 --- drivers/gpu/drm/i915/display/intel_hdmi.c | 10 ++ drivers/gpu/drm/i915/gt/intel_lrc.c | 19 +- drivers/gpu/drm/i915/gt/selftest_rps.c| 8 drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_perf.c | 1 + 6 files changed, 39 insertions(+), 33 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/2] test/kms_cursor_crc: align the start of the CRC capture to a vblank
On Mon, Jun 22, 2020 at 01:38:26PM -0300, Melissa Wen wrote: > When running subtests in sequence using vkms, the beginning of CRC capture > process does not match the simulated vblank timing. This mismatch leads to > an endless busy wait and, consequently, timeout failures for the remaining > subtests in the test sequence. This patch sets the pace by waiting for > vblank before starting the CRC capture. > > Signed-off-by: Melissa Wen This one is quite interetesing. The test seems to be working just fine on the real hardware and causes the endless busy wait on VKMS only... DRM is bad at describing usage sequences and what's defined and what's undefined when it comes to behavior. We just try not to break any of the existing users. On top of that CRC capture is a testing/debug feature that doesn't have have to be stable - it's not really obvious what's the correct course of action here. The vblank wait won't harm anyone, especially in the context presented above. You have to keep in mind that other implementations of CRC caputring doesn't have that requirement and you will likely find more similar instances of this usage pattern. There may be even more of them introduced over time - there's no CI on VKMS (fingers crossed that this is going to change). Have you thought about what's easier here - making the current code work on the VKMS side or fixing the test? I would like to know your thoughts on this. -- Cheers, Arek > --- > tests/kms_cursor_crc.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tests/kms_cursor_crc.c b/tests/kms_cursor_crc.c > index 5976df5f..755c34ed 100644 > --- a/tests/kms_cursor_crc.c > +++ b/tests/kms_cursor_crc.c > @@ -474,6 +474,7 @@ static void prepare_crtc(data_t *data, igt_output_t > *output, > igt_assert(data->batch); > } > > + igt_wait_for_vblank(data->drm_fd, data->pipe); > igt_pipe_crc_start(data->pipe_crc); > } > > -- > 2.27.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/25] drm/malidp: Annotate dma-fence critical section in commit path
On Tue, Jul 07, 2020 at 10:12:12PM +0200, Daniel Vetter wrote: > Again needs to be put right after the call to > drm_atomic_helper_commit_hw_done(), since that's the last thing which > can hold up a subsequent atomic commit. > > No surprises here. I was (still am) hoping to do a testing for this patch but when I dug out the series from the ML it looked like it has extra dependencies, so I was waiting for the dust to settle. Otherwise, LGTM. Best regards, Liviu > > Signed-off-by: Daniel Vetter > Cc: "James (Qian) Wang" > Cc: Liviu Dudau > Cc: Mihail Atanassov > --- > drivers/gpu/drm/arm/malidp_drv.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/arm/malidp_drv.c > b/drivers/gpu/drm/arm/malidp_drv.c > index 69fee05c256c..26e60401a8e1 100644 > --- a/drivers/gpu/drm/arm/malidp_drv.c > +++ b/drivers/gpu/drm/arm/malidp_drv.c > @@ -234,6 +234,7 @@ static void malidp_atomic_commit_tail(struct > drm_atomic_state *state) > struct drm_crtc *crtc; > struct drm_crtc_state *old_crtc_state; > int i; > + bool fence_cookie = dma_fence_begin_signalling(); > > pm_runtime_get_sync(drm->dev); > > @@ -260,6 +261,8 @@ static void malidp_atomic_commit_tail(struct > drm_atomic_state *state) > > malidp_atomic_commit_hw_done(state); > > + dma_fence_end_signalling(fence_cookie); > + > pm_runtime_put(drm->dev); > > drm_atomic_helper_cleanup_planes(drm, state); > -- > 2.27.0 > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Remove i915_request.lock requirement for execution callbacks
Quoting Tvrtko Ursulin (2020-07-15 13:39:56)
>
> On 14/07/2020 10:47, Chris Wilson wrote:
> > We are using the i915_request.lock to serialise adding an execution
> > callback with __i915_request_submit. However, if we use an atomic
> > llist_add to serialise multiple waiters and then check to see if the
> > request is already executing, we can remove the irq-spinlock.
> >
> > Fixes: 1d9221e9d395 ("drm/i915: Skip signaling a signaled request")
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/i915_request.c | 38 +++--
> > 1 file changed, 9 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_request.c
> > b/drivers/gpu/drm/i915/i915_request.c
> > index 0b2fe55e6194..c59315def07d 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -190,13 +190,11 @@ static void __notify_execute_cb(struct i915_request
> > *rq)
> > {
> > struct execute_cb *cb, *cn;
> >
> > - lockdep_assert_held(>lock);
> > -
> > - GEM_BUG_ON(!i915_request_is_active(rq));
> > if (llist_empty(>execute_cb))
> > return;
> >
> > - llist_for_each_entry_safe(cb, cn, rq->execute_cb.first, work.llnode)
> > + llist_for_each_entry_safe(cb, cn,
> > + llist_del_all(>execute_cb), work.llnode)
> > irq_work_queue(>work);
> >
> > /*
> > @@ -209,7 +207,6 @@ static void __notify_execute_cb(struct i915_request *rq)
> >* preempt-to-idle cycle on the target engine, all the while the
> >* master execute_cb may refire.
> >*/
> > - init_llist_head(>execute_cb);
> > }
> >
> > static inline void
> > @@ -276,6 +273,7 @@ static void remove_from_engine(struct i915_request *rq)
> > list_del_init(>sched.link);
> > clear_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
> > clear_bit(I915_FENCE_FLAG_HOLD, >fence.flags);
> > + set_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags);
> > spin_unlock_irq(>active.lock);
> > }
> >
> > @@ -323,12 +321,8 @@ bool i915_request_retire(struct i915_request *rq)
> > GEM_BUG_ON(!atomic_read(>engine->gt->rps.num_waiters));
> > atomic_dec(>engine->gt->rps.num_waiters);
> > }
> > - if (!test_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags)) {
> > - set_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags);
> > - __notify_execute_cb(rq);
> > - }
> > - GEM_BUG_ON(!llist_empty(>execute_cb));
> > spin_unlock_irq(>lock);
> > + __notify_execute_cb(rq);
> >
> > remove_from_client(rq);
> > __list_del_entry(>link); /* poison neither prev/next (RCU walks)
> > */
> > @@ -357,12 +351,6 @@ void i915_request_retire_upto(struct i915_request *rq)
> > } while (i915_request_retire(tmp) && tmp != rq);
> > }
> >
> > -static void __llist_add(struct llist_node *node, struct llist_head *head)
> > -{
> > - node->next = head->first;
> > - head->first = node;
> > -}
> > -
> > static struct i915_request * const *
> > __engine_active(struct intel_engine_cs *engine)
> > {
> > @@ -439,18 +427,11 @@ __await_execution(struct i915_request *rq,
> > cb->work.func = irq_execute_cb_hook;
> > }
> >
> > - spin_lock_irq(>lock);
> > - if (i915_request_is_active(signal) || __request_in_flight(signal)) {
> > - if (hook) {
> > - hook(rq, >fence);
> > - i915_request_put(signal);
> > - }
> > - i915_sw_fence_complete(cb->fence);
> > - kmem_cache_free(global.slab_execute_cbs, cb);
> > - } else {
> > - __llist_add(>work.llnode, >execute_cb);
> > + if (llist_add(>work.llnode, >execute_cb)) {
> > + if (i915_request_is_active(signal) ||
> > + __request_in_flight(signal))
> > + __notify_execute_cb(signal);
>
> Any reason why the hook couldn't be called straight away but needs to
> always go through the worker now?
>
> Maybe it would be easier to figure out if it is race free that way..
>
> if (llist_add(..)) {
> llist_for_each_entry_safe(.., llist_del_all(..), .)
Then you would tell me off for open coding __notify_execute_cb for the
benefit of not going through the irq_work. Something like
@@ -186,7 +186,7 @@ static void irq_execute_cb_hook(struct irq_work *wrk)
irq_execute_cb(wrk);
}
-static void __notify_execute_cb(struct i915_request *rq)
+static void __execute_cb_irq(struct i915_request *rq)
{
struct execute_cb *cb, *cn;
@@ -209,6 +209,15 @@ static void __notify_execute_cb(struct i915_request *rq)
*/
}
+static void __execute_cb_imm(struct i915_request *rq)
+{
+ struct execute_cb *cb, *cn;
+
+ llist_for_each_entry_safe(cb, cn,
+ llist_del_all(>execute_cb), work.llnode)
+ cb->work.func(>work);
+}
+
static
Re: [Intel-gfx] [PATCH i-g-t 1/2] test/kms_cursor_crc: release old pipe_crc before create a new one
On Mon, Jun 22, 2020 at 01:37:55PM -0300, Melissa Wen wrote:
> When a subtest fails, it skips the cleanup, and its pipe_crc remains
> allocated.
> As a consequence, the following subtest also fails (timeout) when trying to
> create a new one. This patch releases any remaining pipe_crc to enable the
> creation of a new one for the next subtest.
>
> Signed-off-by: Melissa Wen
> ---
> tests/kms_cursor_crc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/tests/kms_cursor_crc.c b/tests/kms_cursor_crc.c
> index f105e295..5976df5f 100644
> --- a/tests/kms_cursor_crc.c
> +++ b/tests/kms_cursor_crc.c
> @@ -423,6 +423,8 @@ static void prepare_crtc(data_t *data, igt_output_t
> *output,
> igt_display_commit(display);
>
> /* create the pipe_crc object for this pipe */
> + if (data->pipe_crc)
> + igt_pipe_crc_free(data->pipe_crc);
That's a welcome improvement, but you may want to also look at
06333955bf3d ("tests/kms_cursor_crc: start crc only once per test")
for some extra inspiration for future work on this.
It should be possible to initiate pipe crc to be initalized only once
per each tested pipe in run_tests_on_pipe() - igt_pipe_crc_new() can be
costly on some real panels.
Anyway,
Reviewed-by: Arkadiusz Hiler
> data->pipe_crc = igt_pipe_crc_new(data->drm_fd, data->pipe,
> INTEL_PIPE_CRC_SOURCE_AUTO);
>
> --
> 2.27.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] dma-buf/dma-fence: Add quick tests before dma_fence_remove_callback
Quoting Chris Wilson (2020-07-15 13:21:43) > Quoting Daniel Vetter (2020-07-15 13:10:22) > > On Wed, Jul 15, 2020 at 11:49:05AM +0100, Chris Wilson wrote: > > > When waiting with a callback on the stack, we must remove the callback > > > upon wait completion. Since this will be notified by the fence signal > > > callback, the removal often contends with the fence->lock being held by > > > the signaler. We can look at the list entry to see if the callback was > > > already signaled before we take the contended lock. > > > > > > Signed-off-by: Chris Wilson > > > --- > > > drivers/dma-buf/dma-fence.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > > > index 8d5bdfce638e..b910d7bc0854 100644 > > > --- a/drivers/dma-buf/dma-fence.c > > > +++ b/drivers/dma-buf/dma-fence.c > > > @@ -420,6 +420,9 @@ dma_fence_remove_callback(struct dma_fence *fence, > > > struct dma_fence_cb *cb) > > > unsigned long flags; > > > bool ret; > > > > > > + if (list_empty(>node)) > > > > I was about to say "but the races" but then noticed that Paul fixed > > list_empty to use READ_ONCE like 5 years ago :-) > > I'm always going "when exactly do we need list_empty_careful()"? > > We can rule out a concurrent dma_fence_add_callback() for the same > dma_fence_cb, as that is a lost cause. So we only have to worry about > the concurrent list_del_init() from dma_fence_signal_locked(). So it's > the timing of > list_del_init(): WRITE_ONCE(list->next, list) > vs > READ_ONCE(list->next) == list > and we don't need to care about the trailing instructions in > list_del_init()... > > Wait that trailing instruction is actually important here if the > dma_fence_cb is on the stack, or other imminent free. > > Ok, this does need to be list_empty_careful! There's a further problem in that we call INIT_LIST_HEAD on the dma_fence_cb before the signal callback. So even if list_empty_careful() confirms the dma_fence_cb to be completely decoupled, the containing struct may still be inuse. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Remove i915_request.lock requirement for execution callbacks
On 14/07/2020 10:47, Chris Wilson wrote:
We are using the i915_request.lock to serialise adding an execution
callback with __i915_request_submit. However, if we use an atomic
llist_add to serialise multiple waiters and then check to see if the
request is already executing, we can remove the irq-spinlock.
Fixes: 1d9221e9d395 ("drm/i915: Skip signaling a signaled request")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 38 +++--
1 file changed, 9 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 0b2fe55e6194..c59315def07d 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -190,13 +190,11 @@ static void __notify_execute_cb(struct i915_request *rq)
{
struct execute_cb *cb, *cn;
- lockdep_assert_held(>lock);
-
- GEM_BUG_ON(!i915_request_is_active(rq));
if (llist_empty(>execute_cb))
return;
- llist_for_each_entry_safe(cb, cn, rq->execute_cb.first, work.llnode)
+ llist_for_each_entry_safe(cb, cn,
+ llist_del_all(>execute_cb), work.llnode)
irq_work_queue(>work);
/*
@@ -209,7 +207,6 @@ static void __notify_execute_cb(struct i915_request *rq)
* preempt-to-idle cycle on the target engine, all the while the
* master execute_cb may refire.
*/
- init_llist_head(>execute_cb);
}
static inline void
@@ -276,6 +273,7 @@ static void remove_from_engine(struct i915_request *rq)
list_del_init(>sched.link);
clear_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
clear_bit(I915_FENCE_FLAG_HOLD, >fence.flags);
+ set_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags);
spin_unlock_irq(>active.lock);
}
@@ -323,12 +321,8 @@ bool i915_request_retire(struct i915_request *rq)
GEM_BUG_ON(!atomic_read(>engine->gt->rps.num_waiters));
atomic_dec(>engine->gt->rps.num_waiters);
}
- if (!test_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags)) {
- set_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags);
- __notify_execute_cb(rq);
- }
- GEM_BUG_ON(!llist_empty(>execute_cb));
spin_unlock_irq(>lock);
+ __notify_execute_cb(rq);
remove_from_client(rq);
__list_del_entry(>link); /* poison neither prev/next (RCU walks) */
@@ -357,12 +351,6 @@ void i915_request_retire_upto(struct i915_request *rq)
} while (i915_request_retire(tmp) && tmp != rq);
}
-static void __llist_add(struct llist_node *node, struct llist_head *head)
-{
- node->next = head->first;
- head->first = node;
-}
-
static struct i915_request * const *
__engine_active(struct intel_engine_cs *engine)
{
@@ -439,18 +427,11 @@ __await_execution(struct i915_request *rq,
cb->work.func = irq_execute_cb_hook;
}
- spin_lock_irq(>lock);
- if (i915_request_is_active(signal) || __request_in_flight(signal)) {
- if (hook) {
- hook(rq, >fence);
- i915_request_put(signal);
- }
- i915_sw_fence_complete(cb->fence);
- kmem_cache_free(global.slab_execute_cbs, cb);
- } else {
- __llist_add(>work.llnode, >execute_cb);
+ if (llist_add(>work.llnode, >execute_cb)) {
+ if (i915_request_is_active(signal) ||
+ __request_in_flight(signal))
+ __notify_execute_cb(signal);
Any reason why the hook couldn't be called straight away but needs to
always go through the worker now?
Maybe it would be easier to figure out if it is race free that way..
if (llist_add(..)) {
llist_for_each_entry_safe(.., llist_del_all(..), .)
Looks safe, worker or not.
Regards,
Tvrtko
}
- spin_unlock_irq(>lock);
return 0;
}
@@ -565,19 +546,18 @@ bool __i915_request_submit(struct i915_request *request)
list_move_tail(>sched.link, >active.requests);
clear_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
}
+ __notify_execute_cb(request);
/* We may be recursing from the signal callback of another i915 fence */
if (!i915_request_signaled(request)) {
spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
- __notify_execute_cb(request);
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
>fence.flags) &&
!i915_request_enable_breadcrumb(request))
intel_engine_signal_breadcrumbs(engine);
spin_unlock(>lock);
- GEM_BUG_ON(!llist_empty(>execute_cb));
}
return result;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] dma-buf/sw_sync: Avoid recursive lock during fence signal
== Series Details == Series: series starting with [1/2] dma-buf/sw_sync: Avoid recursive lock during fence signal URL : https://patchwork.freedesktop.org/series/79510/ State : success == Summary == CI Bug Log - changes from CI_DRM_8748_full -> Patchwork_18173_full Summary --- **SUCCESS** No regressions found. New tests - New tests have been introduced between CI_DRM_8748_full and Patchwork_18173_full: ### New IGT tests (1) ### * igt@dmabuf@all@sw_sync: - Statuses : 8 pass(s) - Exec time: [0.02, 0.05] s Known issues Here are the changes found in Patchwork_18173_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_whisper@basic-queues-priority: - shard-glk: [PASS][1] -> [DMESG-WARN][2] ([i915#118] / [i915#95]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-glk9/igt@gem_exec_whis...@basic-queues-priority.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18173/shard-glk4/igt@gem_exec_whis...@basic-queues-priority.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-suspend.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18173/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-untiled: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#1635] / [i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-apl8/igt@kms_draw_...@draw-method-xrgb2101010-mmap-gtt-untiled.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18173/shard-apl4/igt@kms_draw_...@draw-method-xrgb2101010-mmap-gtt-untiled.html * igt@kms_flip@plain-flip-ts-check@c-edp1: - shard-skl: [PASS][7] -> [FAIL][8] ([i915#2122]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-skl5/igt@kms_flip@plain-flip-ts-ch...@c-edp1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18173/shard-skl4/igt@kms_flip@plain-flip-ts-ch...@c-edp1.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-mmap-wc: - shard-tglb: [PASS][9] -> [DMESG-WARN][10] ([i915#402]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-tglb6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-mmap-wc.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18173/shard-tglb6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-mmap-wc.html * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-render: - shard-tglb: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-tglb1/igt@kms_frontbuffer_track...@fbcpsr-rgb101010-draw-render.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18173/shard-tglb5/igt@kms_frontbuffer_track...@fbcpsr-rgb101010-draw-render.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145] / [i915#265]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-skl10/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18173/shard-skl3/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_plane_cursor@pipe-a-viewport-size-128: - shard-skl: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +11 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-skl9/igt@kms_plane_cur...@pipe-a-viewport-size-128.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18173/shard-skl7/igt@kms_plane_cur...@pipe-a-viewport-size-128.html * igt@kms_psr@psr2_sprite_plane_move: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18173/shard-iclb3/igt@kms_psr@psr2_sprite_plane_move.html * igt@perf@blocking-parameterized: - shard-tglb: [PASS][19] -> [FAIL][20] ([i915#1542]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-tglb1/igt@p...@blocking-parameterized.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18173/shard-tglb8/igt@p...@blocking-parameterized.html Possible fixes * igt@gem_ctx_isolation@preservation-s3@vecs0: - shard-iclb: [INCOMPLETE][21] -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8748/shard-iclb3/igt@gem_ctx_isolation@preservation...@vecs0.html [22]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Reduce i915_request.lock contention for i915_request_wait
== Series Details ==
Series: drm/i915: Reduce i915_request.lock contention for i915_request_wait
URL : https://patchwork.freedesktop.org/series/79514/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8749 -> Patchwork_18176
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/index.html
Known issues
Here are the changes found in Patchwork_18176 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [PASS][3] -> [SKIP][4] ([fdo#109271])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/fi-kbl-guc/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/fi-kbl-guc/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gt_contexts:
- fi-snb-2520m: [PASS][5] -> [DMESG-FAIL][6] ([i915#541])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/fi-snb-2520m/igt@i915_selftest@live@gt_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/fi-snb-2520m/igt@i915_selftest@live@gt_contexts.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/fi-tgl-y/igt@kms_force_connector_ba...@force-connector-state.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/fi-tgl-y/igt@kms_force_connector_ba...@force-connector-state.html
* igt@prime_vgem@basic-write:
- fi-tgl-y: [PASS][9] -> [DMESG-WARN][10] ([i915#402]) +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/fi-tgl-y/igt@prime_v...@basic-write.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/fi-tgl-y/igt@prime_v...@basic-write.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/fi-byt-j1900/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-bsw-kefka: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-plain-flip@d-dsi1:
- {fi-tgl-dsi}: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/fi-tgl-dsi/igt@kms_flip@basic-plain-f...@d-dsi1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/fi-tgl-dsi/igt@kms_flip@basic-plain-f...@d-dsi1.html
* igt@vgem_basic@create:
- fi-tgl-y: [DMESG-WARN][19] ([i915#402]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/fi-tgl-y/igt@vgem_ba...@create.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/fi-tgl-y/igt@vgem_ba...@create.html
Warnings
* igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) ->
[DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +5 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18176/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][23] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][24] ([i915#62] / [i915#92]) +1 similar issue
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8749/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[24]:
Re: [Intel-gfx] [PATCH] drm/i915: Reduce i915_request.lock contention for i915_request_wait
On 15/07/2020 13:06, Tvrtko Ursulin wrote:
On 15/07/2020 11:50, Chris Wilson wrote:
Currently, we use i915_request_completed() directly in
i915_request_wait() and follow up with a manual invocation of
dma_fence_signal(). This appears to cause a large number of contentions
on i915_request.lock as when the process is woken up after the fence is
signaled by an interrupt, we will then try and call dma_fence_signal()
ourselves while the signaler is still holding the lock.
dma_fence_is_signaled() has the benefit of checking the
DMA_FENCE_FLAG_SIGNALED_BIT prior to calling dma_fence_signal() and so
avoids most of that contention.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 0b2fe55e6194..bb4eb1a8780e 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1640,7 +1640,7 @@ static bool busywait_stop(unsigned long timeout,
unsigned int cpu)
return this_cpu != cpu;
}
-static bool __i915_spin_request(const struct i915_request * const rq,
int state)
+static bool __i915_spin_request(struct i915_request * const rq, int
state)
{
unsigned long timeout_ns;
unsigned int cpu;
@@ -1673,7 +1673,7 @@ static bool __i915_spin_request(const struct
i915_request * const rq, int state)
timeout_ns = READ_ONCE(rq->engine->props.max_busywait_duration_ns);
timeout_ns += local_clock_ns();
do {
- if (i915_request_completed(rq))
+ if (dma_fence_is_signaled(>fence))
return true;
if (signal_pending_state(state, current))
@@ -1766,10 +1766,8 @@ long i915_request_wait(struct i915_request *rq,
* duration, which we currently lack.
*/
if (IS_ACTIVE(CONFIG_DRM_I915_MAX_REQUEST_BUSYWAIT) &&
- __i915_spin_request(rq, state)) {
- dma_fence_signal(>fence);
+ __i915_spin_request(rq, state))
goto out;
- }
/*
* This client is about to stall waiting for the GPU. In many cases
@@ -1796,10 +1794,8 @@ long i915_request_wait(struct i915_request *rq,
for (;;) {
set_current_state(state);
- if (i915_request_completed(rq)) {
- dma_fence_signal(>fence);
+ if (dma_fence_is_signaled(>fence))
break;
- }
intel_engine_flush_submission(rq->engine);
In other words putting some latency back into the waiters, which is
probably okay, since sync waits is not our primary model.
I have a slight concern about the remaining value of busy spinning if
i915_request_completed check is removed from there as well. Of course it
doesn't make sense to have different completion criteria between the
two.. We could wait a bit longer if real check in busyspin said request
is actually completed, just not signal it but wait for the breadcrumbs
to do it.
What a load of nonsense.. :)
Okay, I think the only real question is i915_request_completed vs
dma_fence_signaled in __i915_spin_request. Do we want to burn CPU cycles
waiting on GPU and breadcrumb irq work, or just the GPU.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] dma-buf/dma-fence: Add quick tests before dma_fence_remove_callback
Quoting Daniel Vetter (2020-07-15 13:10:22) > On Wed, Jul 15, 2020 at 11:49:05AM +0100, Chris Wilson wrote: > > When waiting with a callback on the stack, we must remove the callback > > upon wait completion. Since this will be notified by the fence signal > > callback, the removal often contends with the fence->lock being held by > > the signaler. We can look at the list entry to see if the callback was > > already signaled before we take the contended lock. > > > > Signed-off-by: Chris Wilson > > --- > > drivers/dma-buf/dma-fence.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > > index 8d5bdfce638e..b910d7bc0854 100644 > > --- a/drivers/dma-buf/dma-fence.c > > +++ b/drivers/dma-buf/dma-fence.c > > @@ -420,6 +420,9 @@ dma_fence_remove_callback(struct dma_fence *fence, > > struct dma_fence_cb *cb) > > unsigned long flags; > > bool ret; > > > > + if (list_empty(>node)) > > I was about to say "but the races" but then noticed that Paul fixed > list_empty to use READ_ONCE like 5 years ago :-) I'm always going "when exactly do we need list_empty_careful()"? We can rule out a concurrent dma_fence_add_callback() for the same dma_fence_cb, as that is a lost cause. So we only have to worry about the concurrent list_del_init() from dma_fence_signal_locked(). So it's the timing of list_del_init(): WRITE_ONCE(list->next, list) vs READ_ONCE(list->next) == list and we don't need to care about the trailing instructions in list_del_init()... Wait that trailing instruction is actually important here if the dma_fence_cb is on the stack, or other imminent free. Ok, this does need to be list_empty_careful! -Chris ___ 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: Reduce i915_request.lock contention for i915_request_wait
== Series Details == Series: drm/i915: Reduce i915_request.lock contention for i915_request_wait URL : https://patchwork.freedesktop.org/series/79514/ 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
Re: [Intel-gfx] [PATCH 2/2] dma-buf/dma-fence: Add quick tests before dma_fence_remove_callback
On Wed, Jul 15, 2020 at 11:49:05AM +0100, Chris Wilson wrote: > When waiting with a callback on the stack, we must remove the callback > upon wait completion. Since this will be notified by the fence signal > callback, the removal often contends with the fence->lock being held by > the signaler. We can look at the list entry to see if the callback was > already signaled before we take the contended lock. > > Signed-off-by: Chris Wilson > --- > drivers/dma-buf/dma-fence.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > index 8d5bdfce638e..b910d7bc0854 100644 > --- a/drivers/dma-buf/dma-fence.c > +++ b/drivers/dma-buf/dma-fence.c > @@ -420,6 +420,9 @@ dma_fence_remove_callback(struct dma_fence *fence, struct > dma_fence_cb *cb) > unsigned long flags; > bool ret; > > + if (list_empty(>node)) I was about to say "but the races" but then noticed that Paul fixed list_empty to use READ_ONCE like 5 years ago :-) Reviewed-by: Daniel Vetter > + return false; > + > spin_lock_irqsave(fence->lock, flags); > > ret = !list_empty(>node); > -- > 2.20.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Reduce i915_request.lock contention for i915_request_wait
On 15/07/2020 11:50, Chris Wilson wrote:
Currently, we use i915_request_completed() directly in
i915_request_wait() and follow up with a manual invocation of
dma_fence_signal(). This appears to cause a large number of contentions
on i915_request.lock as when the process is woken up after the fence is
signaled by an interrupt, we will then try and call dma_fence_signal()
ourselves while the signaler is still holding the lock.
dma_fence_is_signaled() has the benefit of checking the
DMA_FENCE_FLAG_SIGNALED_BIT prior to calling dma_fence_signal() and so
avoids most of that contention.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 0b2fe55e6194..bb4eb1a8780e 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1640,7 +1640,7 @@ static bool busywait_stop(unsigned long timeout, unsigned
int cpu)
return this_cpu != cpu;
}
-static bool __i915_spin_request(const struct i915_request * const rq, int state)
+static bool __i915_spin_request(struct i915_request * const rq, int state)
{
unsigned long timeout_ns;
unsigned int cpu;
@@ -1673,7 +1673,7 @@ static bool __i915_spin_request(const struct i915_request
* const rq, int state)
timeout_ns = READ_ONCE(rq->engine->props.max_busywait_duration_ns);
timeout_ns += local_clock_ns();
do {
- if (i915_request_completed(rq))
+ if (dma_fence_is_signaled(>fence))
return true;
if (signal_pending_state(state, current))
@@ -1766,10 +1766,8 @@ long i915_request_wait(struct i915_request *rq,
* duration, which we currently lack.
*/
if (IS_ACTIVE(CONFIG_DRM_I915_MAX_REQUEST_BUSYWAIT) &&
- __i915_spin_request(rq, state)) {
- dma_fence_signal(>fence);
+ __i915_spin_request(rq, state))
goto out;
- }
/*
* This client is about to stall waiting for the GPU. In many cases
@@ -1796,10 +1794,8 @@ long i915_request_wait(struct i915_request *rq,
for (;;) {
set_current_state(state);
- if (i915_request_completed(rq)) {
- dma_fence_signal(>fence);
+ if (dma_fence_is_signaled(>fence))
break;
- }
intel_engine_flush_submission(rq->engine);
In other words putting some latency back into the waiters, which is
probably okay, since sync waits is not our primary model.
I have a slight concern about the remaining value of busy spinning if
i915_request_completed check is removed from there as well. Of course it
doesn't make sense to have different completion criteria between the
two.. We could wait a bit longer if real check in busyspin said request
is actually completed, just not signal it but wait for the breadcrumbs
to do it.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] sw_sync deadlock avoidance, take 3
On Wed, Jul 15, 2020 at 1:47 PM Daniel Stone wrote: > > Hi, > > On Wed, 15 Jul 2020 at 12:05, Bas Nieuwenhuizen > wrote: > > On Wed, Jul 15, 2020 at 12:34 PM Chris Wilson > > wrote: > > > Maybe now is the time to ask: are you using sw_sync outside of > > > validation? > > > > Yes, this is used as part of the Android stack on Chrome OS (need to > > see if ChromeOS specific, but > > https://source.android.com/devices/graphics/sync#sync_timeline > > suggests not) > > Android used to mandate it for their earlier iteration of release > fences, which was an empty/future fence having no guarantee of > eventual forward progress until someone committed work later on. For > example, when you committed a buffer to SF, it would give you an empty > 'release fence' for that buffer which would only be tied to work to > signal it when you committed your _next_ buffer, which might never > happen. They removed that because a) future fences were a bad idea, > and b) it was only ever useful if you assumed strictly > FIFO/round-robin return order which wasn't always true. > > So now it's been watered down to 'use this if you don't have a > hardware timeline', but why don't we work with Android people to get > that removed entirely? I think there's some testcases still using these, but most real fence testcases use vgem nowadays. So from an upstream pov there's indeed not much if anything holding us back from just deleting this all. And would probably be a good idea. Adding Rob and John for more of the android pov. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/66] drm/i915: Skip taking acquire mutex for no ref->active callback
If no active callback is defined for i915_active, we do not need to
serialise its enabling with the mutex. We still do only want to call the
debug activate once, and must still serialise with a concurrent retire.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index d960d0be5bd2..841b5c30950a 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -416,6 +416,14 @@ bool i915_active_acquire_if_busy(struct i915_active *ref)
return atomic_add_unless(>count, 1, 0);
}
+static void __i915_active_activate(struct i915_active *ref)
+{
+ spin_lock_irq(>tree_lock); /* __active_retire() */
+ if (!atomic_fetch_inc(>count))
+ debug_active_activate(ref);
+ spin_unlock_irq(>tree_lock);
+}
+
int i915_active_acquire(struct i915_active *ref)
{
int err;
@@ -423,23 +431,22 @@ int i915_active_acquire(struct i915_active *ref)
if (i915_active_acquire_if_busy(ref))
return 0;
+ if (!ref->active) {
+ __i915_active_activate(ref);
+ return 0;
+ }
+
err = mutex_lock_interruptible(>mutex);
if (err)
return err;
if (likely(!i915_active_acquire_if_busy(ref))) {
- if (ref->active)
- err = ref->active(ref);
- if (!err) {
- spin_lock_irq(>tree_lock); /* __active_retire() */
- debug_active_activate(ref);
- atomic_inc(>count);
- spin_unlock_irq(>tree_lock);
- }
+ err = ref->active(ref);
+ if (!err)
+ __i915_active_activate(ref);
}
mutex_unlock(>mutex);
-
return err;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/66] drm/i915: Provide a fastpath for waiting on vma bindings
Before we can execute a request, we must wait for all of its vma to be
bound. This is a frequent operation for which we can optimise away a
few atomic operations (notably a cmpxchg) in lieu of the RCU protection.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.h | 15 +++
drivers/gpu/drm/i915/i915_vma.c| 9 +++--
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.h
b/drivers/gpu/drm/i915/i915_active.h
index b9e0394e2975..fb165d3f01cf 100644
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -231,4 +231,19 @@ struct i915_active *i915_active_create(void);
struct i915_active *i915_active_get(struct i915_active *ref);
void i915_active_put(struct i915_active *ref);
+static inline int __i915_request_await_exclusive(struct i915_request *rq,
+struct i915_active *active)
+{
+ struct dma_fence *fence;
+ int err = 0;
+
+ fence = i915_active_fence_get(>excl);
+ if (fence) {
+ err = i915_request_await_dma_fence(rq, fence);
+ dma_fence_put(fence);
+ }
+
+ return err;
+}
+
#endif /* _I915_ACTIVE_H_ */
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index bc64f773dcdb..cd12047c7791 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1167,6 +1167,12 @@ void i915_vma_revoke_mmap(struct i915_vma *vma)
list_del(>obj->userfault_link);
}
+static int
+__i915_request_await_bind(struct i915_request *rq, struct i915_vma *vma)
+{
+ return __i915_request_await_exclusive(rq, >active);
+}
+
int __i915_vma_move_to_active(struct i915_vma *vma, struct i915_request *rq)
{
int err;
@@ -1174,8 +1180,7 @@ int __i915_vma_move_to_active(struct i915_vma *vma,
struct i915_request *rq)
GEM_BUG_ON(!i915_vma_is_pinned(vma));
/* Wait for the vma to be bound before we start! */
- err = i915_request_await_active(rq, >active,
- I915_ACTIVE_AWAIT_EXCL);
+ err = __i915_request_await_bind(rq, vma);
if (err)
return err;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 52/66] drm/i915: Teach the i915_dependency to use a double-lock
Currently, we construct and teardown the i915_dependency chains using a
global spinlock. As the lists are entirely local, it should be possible
to use an double-lock with an explicit nesting [signaler -> waiter,
always] and so avoid the costly convenience of a global spinlock.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 6 +--
drivers/gpu/drm/i915/i915_request.c | 2 +-
drivers/gpu/drm/i915/i915_scheduler.c | 44 +
drivers/gpu/drm/i915/i915_scheduler.h | 2 +-
drivers/gpu/drm/i915/i915_scheduler_types.h | 1 +
5 files changed, 34 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index fdeeed8b45d5..2dd116c0d2a1 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1831,7 +1831,7 @@ static void defer_request(struct i915_request *rq, struct
list_head * const pl)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
- if (p->flags & I915_DEPENDENCY_WEAK)
+ if (!p->waiter || p->flags & I915_DEPENDENCY_WEAK)
continue;
/* Leave semaphores spinning on the other engines */
@@ -2683,7 +2683,7 @@ static void __execlists_hold(struct i915_request *rq)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
- if (p->flags & I915_DEPENDENCY_WEAK)
+ if (!p->waiter || p->flags & I915_DEPENDENCY_WEAK)
continue;
/* Leave semaphores spinning on the other engines */
@@ -2781,7 +2781,7 @@ static void __execlists_unhold(struct i915_request *rq)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
- if (p->flags & I915_DEPENDENCY_WEAK)
+ if (!p->waiter || p->flags & I915_DEPENDENCY_WEAK)
continue;
/* Propagate any change in error status */
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 1c00edf427f0..6528ace4c0b7 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -334,7 +334,7 @@ bool i915_request_retire(struct i915_request *rq)
intel_context_unpin(rq->context);
free_capture_list(rq);
- i915_sched_node_fini(>sched);
+ i915_sched_node_retire(>sched);
i915_request_put(rq);
return true;
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 9f744f470556..2e4d512e61d8 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -353,6 +353,8 @@ void i915_request_set_priority(struct i915_request *rq, int
prio)
void i915_sched_node_init(struct i915_sched_node *node)
{
+ spin_lock_init(>lock);
+
INIT_LIST_HEAD(>signalers_list);
INIT_LIST_HEAD(>waiters_list);
INIT_LIST_HEAD(>link);
@@ -390,7 +392,8 @@ bool __i915_sched_node_add_dependency(struct
i915_sched_node *node,
{
bool ret = false;
- spin_lock_irq(_lock);
+ /* The signal->lock is always the outer lock in this double-lock. */
+ spin_lock_irq(>lock);
if (!node_signaled(signal)) {
INIT_LIST_HEAD(>dfs_link);
@@ -399,15 +402,17 @@ bool __i915_sched_node_add_dependency(struct
i915_sched_node *node,
dep->flags = flags;
/* All set, now publish. Beware the lockless walkers. */
+ spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
list_add_rcu(>signal_link, >signalers_list);
list_add_rcu(>wait_link, >waiters_list);
+ spin_unlock(>lock);
/* Propagate the chains */
node->flags |= signal->flags;
ret = true;
}
- spin_unlock_irq(_lock);
+ spin_unlock_irq(>lock);
return ret;
}
@@ -433,39 +438,46 @@ int i915_sched_node_add_dependency(struct i915_sched_node
*node,
return 0;
}
-void i915_sched_node_fini(struct i915_sched_node *node)
+void i915_sched_node_retire(struct i915_sched_node *node)
{
struct i915_dependency *dep, *tmp;
- spin_lock_irq(_lock);
+ spin_lock_irq(>lock);
/*
* Everyone we depended upon (the fences we wait to be signaled)
* should retire before us and remove themselves from our list.
* However, retirement is run independently on each timeline and
-* so we may be called out-of-order.
+* so we may be called out-of-order. As we need to avoid taking
+* the signaler's lock, just mark up our completion and be wary
+
