[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/rkl: Program BW_BUDDY0 registers instead of BW_BUDDY1/2
== Series Details == Series: series starting with [1/2] drm/i915/rkl: Program BW_BUDDY0 registers instead of BW_BUDDY1/2 URL : https://patchwork.freedesktop.org/series/78018/ State : success == Summary == CI Bug Log - changes from CI_DRM_8588_full -> Patchwork_17879_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17879_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_param@basic: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([i915#95]) +18 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-apl3/igt@gem_ctx_pa...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17879/shard-apl7/igt@gem_ctx_pa...@basic.html * igt@gem_exec_params@control: - shard-tglb: [PASS][3] -> [DMESG-WARN][4] ([i915#402]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-tglb2/igt@gem_exec_par...@control.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17879/shard-tglb1/igt@gem_exec_par...@control.html * igt@gem_exec_whisper@basic-contexts-priority: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-glk9/igt@gem_exec_whis...@basic-contexts-priority.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17879/shard-glk2/igt@gem_exec_whis...@basic-contexts-priority.html * igt@i915_suspend@debugfs-reader: - shard-kbl: [PASS][7] -> [INCOMPLETE][8] ([i915#155]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-kbl6/igt@i915_susp...@debugfs-reader.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17879/shard-kbl1/igt@i915_susp...@debugfs-reader.html * igt@i915_suspend@forcewake: - shard-glk: [PASS][9] -> [INCOMPLETE][10] ([i915#58] / [k.org#198133]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-glk4/igt@i915_susp...@forcewake.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17879/shard-glk6/igt@i915_susp...@forcewake.html - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([i915#636] / [i915#69]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-skl1/igt@i915_susp...@forcewake.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17879/shard-skl5/igt@i915_susp...@forcewake.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-apl8/igt@i915_susp...@sysfs-reader.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17879/shard-apl4/igt@i915_susp...@sysfs-reader.html * igt@kms_big_fb@x-tiled-8bpp-rotate-0: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-apl2/igt@kms_big...@x-tiled-8bpp-rotate-0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17879/shard-apl1/igt@kms_big...@x-tiled-8bpp-rotate-0.html * igt@kms_color@pipe-c-ctm-0-25: - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +6 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-skl10/igt@kms_co...@pipe-c-ctm-0-25.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17879/shard-skl10/igt@kms_co...@pipe-c-ctm-0-25.html * igt@kms_color@pipe-d-ctm-0-5: - shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#1149] / [i915#402]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-tglb1/igt@kms_co...@pipe-d-ctm-0-5.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17879/shard-tglb2/igt@kms_co...@pipe-d-ctm-0-5.html * igt@kms_cursor_crc@pipe-a-cursor-128x128-offscreen: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#54]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-skl8/igt@kms_cursor_...@pipe-a-cursor-128x128-offscreen.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17879/shard-skl9/igt@kms_cursor_...@pipe-a-cursor-128x128-offscreen.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][23] -> [DMESG-WARN][24] ([i915#180]) +8 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17879/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_crc@pipe-b-cursor-256x256-sliding: - shard-snb: [PASS][25] -> [SKIP][26] ([fdo#109271]) +1 similar issue [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-snb2/igt@kms_cursor_...@pipe-b-cursor-256x256-sliding.html [26]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gem: Async GPU relocations only
== Series Details ==
Series: drm/i915/gem: Async GPU relocations only
URL : https://patchwork.freedesktop.org/series/78016/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8588_full -> Patchwork_17878_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17878_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17878_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_17878_full:
### IGT changes ###
Possible regressions
* igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-xtiled:
- shard-snb: [PASS][1] -> [TIMEOUT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-snb6/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-xtiled.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17878/shard-snb2/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-xtiled.html
- shard-hsw: [PASS][3] -> [TIMEOUT][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-hsw7/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-xtiled.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17878/shard-hsw5/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-xtiled.html
Warnings
* igt@kms_ccs@pipe-c-crc-primary-basic:
- shard-hsw: [SKIP][5] ([fdo#109271]) -> [TIMEOUT][6] +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-hsw7/igt@kms_...@pipe-c-crc-primary-basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17878/shard-hsw5/igt@kms_...@pipe-c-crc-primary-basic.html
* igt@kms_plane_scaling@pipe-b-scaler-with-clipping-clamping:
- shard-snb: [SKIP][7] ([fdo#109271]) -> [TIMEOUT][8] +2 similar
issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-snb6/igt@kms_plane_scal...@pipe-b-scaler-with-clipping-clamping.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17878/shard-snb2/igt@kms_plane_scal...@pipe-b-scaler-with-clipping-clamping.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_exec_reloc@basic-concurrent16}:
- shard-snb: [FAIL][9] ([i915#1930]) -> [TIMEOUT][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-snb6/igt@gem_exec_re...@basic-concurrent16.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17878/shard-snb2/igt@gem_exec_re...@basic-concurrent16.html
- shard-iclb: [FAIL][11] ([i915#1930]) -> [INCOMPLETE][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-iclb8/igt@gem_exec_re...@basic-concurrent16.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17878/shard-iclb3/igt@gem_exec_re...@basic-concurrent16.html
- shard-hsw: [FAIL][13] ([i915#1930]) -> [TIMEOUT][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-hsw7/igt@gem_exec_re...@basic-concurrent16.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17878/shard-hsw5/igt@gem_exec_re...@basic-concurrent16.html
- shard-tglb: [FAIL][15] ([i915#1930]) -> [INCOMPLETE][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-tglb6/igt@gem_exec_re...@basic-concurrent16.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17878/shard-tglb2/igt@gem_exec_re...@basic-concurrent16.html
* {igt@kms_chamelium@vga-hpd-enable-disable-mode}:
- shard-hsw: [SKIP][17] ([fdo#109271] / [fdo#111827]) ->
[TIMEOUT][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-hsw7/igt@kms_chamel...@vga-hpd-enable-disable-mode.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17878/shard-hsw5/igt@kms_chamel...@vga-hpd-enable-disable-mode.html
- shard-snb: [SKIP][19] ([fdo#109271] / [fdo#111827]) ->
[TIMEOUT][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-snb6/igt@kms_chamel...@vga-hpd-enable-disable-mode.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17878/shard-snb2/igt@kms_chamel...@vga-hpd-enable-disable-mode.html
Known issues
Here are the changes found in Patchwork_17878_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_whisper@basic-normal:
- shard-glk: [PASS][21] -> [DMESG-WARN][22] ([i915#118] /
[i915#95]) +1 similar issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/shard-glk1/igt@gem_exec_whis...@basic-normal.html
[22]:
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add psr_safest_params
On Thu, 2020-05-21 at 16:04 +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Add psr_safest_params > URL : https://patchwork.freedesktop.org/series/77491/ > State : success Pushed to dinq, thanks for the review GG. > > == Summary == > > CI Bug Log - changes from CI_DRM_8515_full -> Patchwork_17738_full > > > Summary > --- > > **WARNING** > > Minor unknown changes coming with Patchwork_17738_full need to be verified > manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_17738_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_17738_full: > > ### IGT changes ### > > Warnings > > * igt@i915_pm_dc@dc3co-vpb-simulation: > - shard-iclb: [SKIP][1] ([i915#588]) -> [SKIP][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8515/shard-iclb2/igt@i915_pm...@dc3co-vpb-simulation.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17738/shard-iclb3/igt@i915_pm...@dc3co-vpb-simulation.html > > > New tests > - > > New tests have been introduced between CI_DRM_8515_full and > Patchwork_17738_full: > > ### New IGT tests (74) ### > > * igt@kms_big_fb@linear-16bpp-rotate-0: > - Statuses : 7 pass(s) > - Exec time: [1.51, 7.43] s > > * igt@kms_big_fb@linear-16bpp-rotate-180: > - Statuses : 7 pass(s) > - Exec time: [1.61, 7.23] s > > * igt@kms_big_fb@linear-16bpp-rotate-270: > - Statuses : 7 skip(s) > - Exec time: [0.01, 0.19] s > > * igt@kms_big_fb@linear-16bpp-rotate-90: > - Statuses : 7 skip(s) > - Exec time: [0.02, 0.19] s > > * igt@kms_big_fb@linear-32bpp-rotate-0: > - Statuses : 7 pass(s) > - Exec time: [1.65, 11.03] s > > * igt@kms_big_fb@linear-32bpp-rotate-180: > - Statuses : 7 pass(s) > - Exec time: [1.63, 10.83] s > > * igt@kms_big_fb@linear-32bpp-rotate-270: > - Statuses : 7 skip(s) > - Exec time: [0.01, 0.20] s > > * igt@kms_big_fb@linear-32bpp-rotate-90: > - Statuses : 7 skip(s) > - Exec time: [0.01, 0.19] s > > * igt@kms_big_fb@linear-64bpp-rotate-0: > - Statuses : 6 pass(s) > - Exec time: [1.91, 10.99] s > > * igt@kms_big_fb@linear-64bpp-rotate-180: > - Statuses : 7 pass(s) > - Exec time: [1.92, 10.95] s > > * igt@kms_big_fb@linear-64bpp-rotate-270: > - Statuses : 7 skip(s) > - Exec time: [0.04, 0.78] s > > * igt@kms_big_fb@linear-64bpp-rotate-90: > - Statuses : 7 skip(s) > - Exec time: [0.06, 0.85] s > > * igt@kms_big_fb@linear-8bpp-rotate-0: > - Statuses : 7 pass(s) > - Exec time: [1.46, 6.00] s > > * igt@kms_big_fb@linear-8bpp-rotate-180: > - Statuses : 7 pass(s) > - Exec time: [1.48, 5.51] s > > * igt@kms_big_fb@linear-8bpp-rotate-270: > - Statuses : 6 skip(s) > - Exec time: [0.02, 0.21] s > > * igt@kms_big_fb@linear-8bpp-rotate-90: > - Statuses : 7 skip(s) > - Exec time: [0.02, 0.30] s > > * igt@kms_big_fb@linear-addfb: > - Statuses : 7 pass(s) > - Exec time: [0.0, 0.00] s > > * igt@kms_big_fb@x-tiled-16bpp-rotate-0: > - Statuses : 7 pass(s) > - Exec time: [1.46, 7.09] s > > * igt@kms_big_fb@x-tiled-16bpp-rotate-180: > - Statuses : 7 pass(s) > - Exec time: [1.58, 7.07] s > > * igt@kms_big_fb@x-tiled-16bpp-rotate-270: > - Statuses : 7 skip(s) > - Exec time: [0.01, 0.19] s > > * igt@kms_big_fb@x-tiled-16bpp-rotate-90: > - Statuses : 6 skip(s) > - Exec time: [0.01, 0.20] s > > * igt@kms_big_fb@x-tiled-32bpp-rotate-0: > - Statuses : 7 pass(s) > - Exec time: [1.56, 10.64] s > > * igt@kms_big_fb@x-tiled-32bpp-rotate-180: > - Statuses : 7 pass(s) > - Exec time: [1.59, 10.58] s > > * igt@kms_big_fb@x-tiled-32bpp-rotate-270: > - Statuses : 7 skip(s) > - Exec time: [0.01, 0.21] s > > * igt@kms_big_fb@x-tiled-32bpp-rotate-90: > - Statuses : 7 skip(s) > - Exec time: [0.02, 0.21] s > > * igt@kms_big_fb@x-tiled-64bpp-rotate-0: > - Statuses : 7 pass(s) > - Exec time: [1.87, 11.61] s > > * igt@kms_big_fb@x-tiled-64bpp-rotate-180: > - Statuses : 7 pass(s) > - Exec time: [1.97, 10.64] s > > * igt@kms_big_fb@x-tiled-64bpp-rotate-270: > - Statuses : 7 skip(s) > - Exec time: [0.04, 0.87] s > > * igt@kms_big_fb@x-tiled-64bpp-rotate-90: > - Statuses : 6 skip(s) > - Exec time: [0.05, 0.76] s > > * igt@kms_big_fb@x-tiled-8bpp-rotate-0: > - Statuses : 7 pass(s) > - Exec time: [1.28, 5.08] s > > * igt@kms_big_fb@x-tiled-8bpp-rotate-180: > - Statuses : 7 pass(s) > - Exec time: [1.40, 5.49] s > > * igt@kms_big_fb@x-tiled-8bpp-rotate-270: > - Statuses : 7
Re: [Intel-gfx] [PATCH] drm/i915/psr: Program default IO buffer Wake and Fast Wake
On Fri, 2020-06-05 at 03:23 +0300, Gwan-gyeong Mun wrote:
> The IO buffer Wake and Fast Wake bit size and value have been changed from
> Gen12+.
> It programs default value of IO buffer Wake and Fast Wake on Gen12+.
>
> - Pre Gen12
> Bit location: IO buffer Wake: Register_PSR2_CTL[14:13]
> Fast Wake: Register_PSR2_CTL[12:11]
>
> Value: 0x0: 8 lines
> 0x1: 7 lines
> 0x2: 6 lines
> 0x3: 5 lines
>
> - Gen12+
> Bit location: IO buffer Wake: Register_PSR2_CTL[15:13]
> Fast Wake: Register_PSR2_CTL[12:10]
>
> Value: 0x0: 5 lines
> 0x1: 6 lines
> 0x2: 7 lines
> 0x3: 8 lines
> 0x4: 9 lines
> 0x5: 10 lines
> 0x6: 11 lines
> 0x7: 12 lines
If you define the macro like bellow you don't need to add this information to
the commit description.
>
> Cc: José Roberto de Souza
> Signed-off-by: Gwan-gyeong Mun
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 19 +++
> drivers/gpu/drm/i915/i915_reg.h | 6 ++
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index b7a2c102648a..de2a17fe8860 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -518,6 +518,25 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
> else
> val |= EDP_PSR2_TP2_TIME_2500us;
>
> + if (INTEL_GEN(dev_priv) >= 12) {
> + /*
> + * TODO: In order to setting an optimal power consumption,
> + * lower than 4k resoluition mode needs to decrese
> IO_BUFFER_WAKE
> + * and FAST_WAKE. And higher than 4K resolution mode needs
> + * to increase IO_BUFFER_WAKE and FAST_WAKE.
> + */
> + u32 io_buffer_wake = 0x2; /* default BSpec value, 7 lines */
> + u32 fast_wake = 0x2; /* default BSpec value, 7 lines */
> +
> + /*
> + * To program line 9 to 12 on IO_BUFFER_WAKE and FAST_WAKE,
> + * EDP_PSR2_CTL should be set EDP_PSR2_BLOCK_COUNT_NUM_3.
> + */
> + val |= EDP_PSR2_BLOCK_COUNT_NUM_2;
> + val |= EDP_PSR2_IO_BUFFER_WAKE(io_buffer_wake);
> + val |= EDP_PSR2_FAST_WAKE(fast_wake);
The parameter for this 2 macros should be the number of the lines not the bit
value.
As you are at it, please set the GEN9+ default values, the TGL macros will need
a "TGL_" prefix.
> +
> /*
>* PSR2 HW is incorrectly using EDP_PSR_TP1_TP3_SEL and BSpec is
>* recommending keep this bit unset while PSR2 is enabled.
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 96d351fbeebb..d055b7d93a5d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4514,10 +4514,16 @@ enum {
> #define EDP_PSR2_CTL(tran) _MMIO_TRANS2(tran, _PSR2_CTL_A)
> #define EDP_PSR2_ENABLE(1 << 31)
> #define EDP_SU_TRACK_ENABLE(1 << 30)
> +#define EDP_PSR2_BLOCK_COUNT_NUM_2 (0 << 28) /* TGL+ */
> +#define EDP_PSR2_BLOCK_COUNT_NUM_3 (1 << 28) /* TGL+ */
> #define EDP_Y_COORDINATE_VALID (1 << 26) /* GLK and CNL+ */
> #define EDP_Y_COORDINATE_ENABLE(1 << 25) /* GLK and CNL+ */
> #define EDP_MAX_SU_DISABLE_TIME(t) ((t) << 20)
> #define EDP_MAX_SU_DISABLE_TIME_MASK (0x1f << 20)
> +#define EDP_PSR2_IO_BUFFER_WAKE(a) ((a) << 13)
> +#define EDP_PSR2_IO_BUFFER_WAKE_MASK (0x7 << 13) /* TGL+ */
> +#define EDP_PSR2_FAST_WAKE(a) ((a) << 10) /* TGL+ */
> +#define EDP_PSR2_FAST_WAKE_MASK(0x7 << 10) /* TGL+ */
> #define EDP_PSR2_TP2_TIME_500us(0 << 8)
> #define EDP_PSR2_TP2_TIME_100us(1 << 8)
> #define EDP_PSR2_TP2_TIME_2500us (2 << 8)
___
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/psr: Program default IO buffer Wake and Fast Wake
== Series Details ==
Series: drm/i915/psr: Program default IO buffer Wake and Fast Wake
URL : https://patchwork.freedesktop.org/series/78019/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8588 -> Patchwork_17880
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17880/index.html
Known issues
Here are the changes found in Patchwork_17880 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17880/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][3] -> [DMESG-WARN][4] ([i915#62] / [i915#92] /
[i915#95])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17880/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-tgl-y/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17880/fi-tgl-y/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_8588/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17880/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17880/fi-byt-j1900/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17880/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* {igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1}:
- fi-icl-u2: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17880/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-tgl-y: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17880/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17880/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][20] ([i915#62] / [i915#92]) +3 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17880/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* 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]) +3 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/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_17880/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/rkl: Program BW_BUDDY0 registers instead of BW_BUDDY1/2
== Series Details ==
Series: series starting with [1/2] drm/i915/rkl: Program BW_BUDDY0 registers
instead of BW_BUDDY1/2
URL : https://patchwork.freedesktop.org/series/78018/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8588 -> Patchwork_17879
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17879/index.html
Known issues
Here are the changes found in Patchwork_17879 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-tgl-y/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17879/fi-tgl-y/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-guc: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17879/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
Possible fixes
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [DMESG-WARN][5] ([i915#95]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17879/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- {fi-tgl-dsi}: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17879/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17879/fi-byt-j1900/igt@i915_pm_...@module-reload.html
- fi-glk-dsi: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17879/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* {igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1}:
- fi-icl-u2: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17879/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-tgl-y: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17879/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [SKIP][17] ([fdo#109271]) -> [DMESG-FAIL][18]
([i915#62] / [i915#95])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17879/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][20] ([i915#62] / [i915#92]) +4 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17879/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- 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_8588/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_17879/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[Intel-gfx] [PATCH] drm/i915/psr: Program default IO buffer Wake and Fast Wake
The IO buffer Wake and Fast Wake bit size and value have been changed from
Gen12+.
It programs default value of IO buffer Wake and Fast Wake on Gen12+.
- Pre Gen12
Bit location: IO buffer Wake: Register_PSR2_CTL[14:13]
Fast Wake: Register_PSR2_CTL[12:11]
Value: 0x0: 8 lines
0x1: 7 lines
0x2: 6 lines
0x3: 5 lines
- Gen12+
Bit location: IO buffer Wake: Register_PSR2_CTL[15:13]
Fast Wake: Register_PSR2_CTL[12:10]
Value: 0x0: 5 lines
0x1: 6 lines
0x2: 7 lines
0x3: 8 lines
0x4: 9 lines
0x5: 10 lines
0x6: 11 lines
0x7: 12 lines
Cc: José Roberto de Souza
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_psr.c | 19 +++
drivers/gpu/drm/i915/i915_reg.h | 6 ++
2 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index b7a2c102648a..de2a17fe8860 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -518,6 +518,25 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
else
val |= EDP_PSR2_TP2_TIME_2500us;
+ if (INTEL_GEN(dev_priv) >= 12) {
+ /*
+* TODO: In order to setting an optimal power consumption,
+* lower than 4k resoluition mode needs to decrese
IO_BUFFER_WAKE
+* and FAST_WAKE. And higher than 4K resolution mode needs
+* to increase IO_BUFFER_WAKE and FAST_WAKE.
+*/
+ u32 io_buffer_wake = 0x2; /* default BSpec value, 7 lines */
+ u32 fast_wake = 0x2; /* default BSpec value, 7 lines */
+
+ /*
+* To program line 9 to 12 on IO_BUFFER_WAKE and FAST_WAKE,
+* EDP_PSR2_CTL should be set EDP_PSR2_BLOCK_COUNT_NUM_3.
+*/
+ val |= EDP_PSR2_BLOCK_COUNT_NUM_2;
+ val |= EDP_PSR2_IO_BUFFER_WAKE(io_buffer_wake);
+ val |= EDP_PSR2_FAST_WAKE(fast_wake);
+ }
+
/*
* PSR2 HW is incorrectly using EDP_PSR_TP1_TP3_SEL and BSpec is
* recommending keep this bit unset while PSR2 is enabled.
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 96d351fbeebb..d055b7d93a5d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4514,10 +4514,16 @@ enum {
#define EDP_PSR2_CTL(tran) _MMIO_TRANS2(tran, _PSR2_CTL_A)
#define EDP_PSR2_ENABLE (1 << 31)
#define EDP_SU_TRACK_ENABLE (1 << 30)
+#define EDP_PSR2_BLOCK_COUNT_NUM_2 (0 << 28) /* TGL+ */
+#define EDP_PSR2_BLOCK_COUNT_NUM_3 (1 << 28) /* TGL+ */
#define EDP_Y_COORDINATE_VALID (1 << 26) /* GLK and CNL+ */
#define EDP_Y_COORDINATE_ENABLE (1 << 25) /* GLK and CNL+ */
#define EDP_MAX_SU_DISABLE_TIME(t) ((t) << 20)
#define EDP_MAX_SU_DISABLE_TIME_MASK (0x1f << 20)
+#define EDP_PSR2_IO_BUFFER_WAKE(a) ((a) << 13)
+#define EDP_PSR2_IO_BUFFER_WAKE_MASK (0x7 << 13) /* TGL+ */
+#define EDP_PSR2_FAST_WAKE(a)((a) << 10) /* TGL+ */
+#define EDP_PSR2_FAST_WAKE_MASK (0x7 << 10) /* TGL+ */
#define EDP_PSR2_TP2_TIME_500us (0 << 8)
#define EDP_PSR2_TP2_TIME_100us (1 << 8)
#define EDP_PSR2_TP2_TIME_2500us (2 << 8)
--
2.25.0
___
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,1/3] drm/i915/dp_mst: Fix disabling MST on a port (rev4)
== Series Details == Series: series starting with [v2,1/3] drm/i915/dp_mst: Fix disabling MST on a port (rev4) URL : https://patchwork.freedesktop.org/series/77969/ State : success == Summary == CI Bug Log - changes from CI_DRM_8585_full -> Patchwork_17876_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17876_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_param@basic: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([i915#95]) +13 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/shard-apl2/igt@gem_ctx_pa...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17876/shard-apl1/igt@gem_ctx_pa...@basic.html * igt@gem_exec_nop@basic-series: - shard-hsw: [PASS][3] -> [INCOMPLETE][4] ([i915#61]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/shard-hsw8/igt@gem_exec_...@basic-series.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17876/shard-hsw6/igt@gem_exec_...@basic-series.html * igt@gem_exec_whisper@basic-queues-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_8585/shard-glk8/igt@gem_exec_whis...@basic-queues-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17876/shard-glk8/igt@gem_exec_whis...@basic-queues-all.html * igt@i915_selftest@mock@requests: - shard-glk: [PASS][7] -> [INCOMPLETE][8] ([i915#58] / [k.org#198133]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/shard-glk1/igt@i915_selftest@m...@requests.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17876/shard-glk8/igt@i915_selftest@m...@requests.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17876/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_legacy@all-pipes-torture-bo: - shard-hsw: [PASS][11] -> [DMESG-WARN][12] ([i915#128]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/shard-hsw4/igt@kms_cursor_leg...@all-pipes-torture-bo.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17876/shard-hsw5/igt@kms_cursor_leg...@all-pipes-torture-bo.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-move: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#93] / [i915#95]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/shard-kbl2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-move.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17876/shard-kbl6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-move.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/shard-apl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17876/shard-apl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#265]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/shard-skl10/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17876/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_plane_scaling@pipe-c-plane-scaling: - shard-skl: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +7 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/shard-skl8/igt@kms_plane_scal...@pipe-c-plane-scaling.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17876/shard-skl1/igt@kms_plane_scal...@pipe-c-plane-scaling.html * igt@kms_psr@psr2_primary_mmap_gtt: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/shard-iclb2/igt@kms_psr@psr2_primary_mmap_gtt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17876/shard-iclb3/igt@kms_psr@psr2_primary_mmap_gtt.html * igt@kms_universal_plane@universal-plane-gen9-features-pipe-c: - shard-tglb: [PASS][23] -> [DMESG-WARN][24] ([i915#1982]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/shard-tglb6/igt@kms_universal_pl...@universal-plane-gen9-features-pipe-c.html [24]:
[Intel-gfx] [PATCH 1/2] drm/i915/rkl: Program BW_BUDDY0 registers instead of BW_BUDDY1/2
RKL uses the same BW_BUDDY programming table as TGL, but programs the
values into a single set BUDDY0 set of registers rather than the
BUDDY1/BUDDY2 sets used by TGL and DG1.
v2:
- Store the mask of platform-specific buddy registers in the device
info structure.
- Add a TLB_REQ_TIMER() helper macro. (Aditya)
Bspec: 49218
Cc: Ville Syrjälä
Cc: Aditya Swarup
Signed-off-by: Matt Roper
---
.../drm/i915/display/intel_display_power.c| 43 ++-
drivers/gpu/drm/i915/i915_pci.c | 2 +
drivers/gpu/drm/i915/i915_reg.h | 15 +--
drivers/gpu/drm/i915/intel_device_info.h | 2 +
4 files changed, 37 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 72312b67b57a..5a324d5c9fe4 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -5254,7 +5254,11 @@ static void tgl_bw_buddy_init(struct drm_i915_private
*dev_priv)
enum intel_dram_type type = dev_priv->dram_info.type;
u8 num_channels = dev_priv->dram_info.num_channels;
const struct buddy_page_mask *table;
- int i;
+ unsigned long buddy_regs = INTEL_INFO(dev_priv)->bw_buddy_mask;
+ int config, i;
+
+ if (!buddy_regs)
+ return;
if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_B0))
/* Wa_1409767108: tgl */
@@ -5262,29 +5266,27 @@ static void tgl_bw_buddy_init(struct drm_i915_private
*dev_priv)
else
table = tgl_buddy_page_masks;
- for (i = 0; table[i].page_mask != 0; i++)
- if (table[i].num_channels == num_channels &&
- table[i].type == type)
+ for (config = 0; table[config].page_mask != 0; config++)
+ if (table[config].num_channels == num_channels &&
+ table[config].type == type)
break;
- if (table[i].page_mask == 0) {
+ if (table[config].page_mask == 0) {
drm_dbg(_priv->drm,
"Unknown memory configuration; disabling address buddy
logic.\n");
- intel_de_write(dev_priv, BW_BUDDY1_CTL, BW_BUDDY_DISABLE);
- intel_de_write(dev_priv, BW_BUDDY2_CTL, BW_BUDDY_DISABLE);
+ for_each_set_bit(i, _regs, sizeof(buddy_regs))
+ intel_de_write(dev_priv, BW_BUDDY_CTL(i),
+ BW_BUDDY_DISABLE);
} else {
- intel_de_write(dev_priv, BW_BUDDY1_PAGE_MASK,
- table[i].page_mask);
- intel_de_write(dev_priv, BW_BUDDY2_PAGE_MASK,
- table[i].page_mask);
-
- /* Wa_22010178259:tgl */
- intel_de_rmw(dev_priv, BW_BUDDY1_CTL,
-BW_BUDDY_TLB_REQ_TIMER_MASK,
-REG_FIELD_PREP(BW_BUDDY_TLB_REQ_TIMER_MASK, 0x8));
- intel_de_rmw(dev_priv, BW_BUDDY2_CTL,
-BW_BUDDY_TLB_REQ_TIMER_MASK,
-REG_FIELD_PREP(BW_BUDDY_TLB_REQ_TIMER_MASK, 0x8));
+ for_each_set_bit(i, _regs, sizeof(buddy_regs)) {
+ intel_de_write(dev_priv, BW_BUDDY_PAGE_MASK(i),
+ table[config].page_mask);
+
+ /* Wa_22010178259:tgl,rkl */
+ intel_de_rmw(dev_priv, BW_BUDDY_CTL(i),
+BW_BUDDY_TLB_REQ_TIMER_MASK,
+BW_BUDDY_TLB_REQ_TIMER(0x8));
+ }
}
}
@@ -5321,8 +5323,7 @@ static void icl_display_core_init(struct drm_i915_private
*dev_priv,
icl_mbus_init(dev_priv);
/* 7. Program arbiter BW_BUDDY registers */
- if (INTEL_GEN(dev_priv) >= 12)
- tgl_bw_buddy_init(dev_priv);
+ tgl_bw_buddy_init(dev_priv);
if (resume && dev_priv->csr.dmc_payload)
intel_csr_load_program(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 192f1cd172b8..3f1ccd899f4b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -847,6 +847,7 @@ static const struct intel_device_info ehl_info = {
#define GEN12_FEATURES \
GEN11_FEATURES, \
GEN(12), \
+ .bw_buddy_mask = GENMASK(2, 1), \
.pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | BIT(PIPE_D), \
.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) | \
BIT(TRANSCODER_C) | BIT(TRANSCODER_D) | \
@@ -882,6 +883,7 @@ static const struct intel_device_info tgl_info = {
static const struct intel_device_info rkl_info = {
GEN12_FEATURES,
PLATFORM(INTEL_ROCKETLAKE),
+ .bw_buddy_mask = BIT(0),
.pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C),
[Intel-gfx] [PATCH 2/2] drm/i915/rkl: RKL has no MBUS_ABOX_CTL{1, 2}
Although RKL is a gen12 platform, it doesn't have the two extra
instances of the ABOX control register; we should only program
the single MBUS_ABOX_CTL on this platform.
Note that the bspec tagging for this is a bit misleading/inconsistent;
the details that ABOX1/2 don't exist exists in the bspec, but is tagged
in a strange limbo state such that it doesn't take effect when a RKL
filter view is applied; we've confirmed experimentally that these two
extra register instances don't exist on the platform (and trigger
unclaimed register errors when accessed).
v2:
- Store the mask of platform-specific abox registers in the device
info structure.
Bspec: 50096
Bspec: 49218
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_display_power.c | 10 --
drivers/gpu/drm/i915/i915_pci.c| 3 +++
drivers/gpu/drm/i915/i915_reg.h| 9 ++---
drivers/gpu/drm/i915/intel_device_info.h | 1 +
4 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 5a324d5c9fe4..a2b9f1fe3bc7 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -4760,7 +4760,8 @@ static void gen9_dbuf_disable(struct drm_i915_private
*dev_priv)
static void icl_mbus_init(struct drm_i915_private *dev_priv)
{
- u32 mask, val;
+ unsigned long abox_regs = INTEL_INFO(dev_priv)->abox_mask;
+ u32 mask, val, i;
mask = MBUS_ABOX_BT_CREDIT_POOL1_MASK |
MBUS_ABOX_BT_CREDIT_POOL2_MASK |
@@ -4771,11 +4772,8 @@ static void icl_mbus_init(struct drm_i915_private
*dev_priv)
MBUS_ABOX_B_CREDIT(1) |
MBUS_ABOX_BW_CREDIT(1);
- intel_de_rmw(dev_priv, MBUS_ABOX_CTL, mask, val);
- if (INTEL_GEN(dev_priv) >= 12) {
- intel_de_rmw(dev_priv, MBUS_ABOX1_CTL, mask, val);
- intel_de_rmw(dev_priv, MBUS_ABOX2_CTL, mask, val);
- }
+ for_each_set_bit(i, _regs, sizeof(abox_regs))
+ intel_de_rmw(dev_priv, MBUS_ABOX_CTL(i), mask, val);
}
static void hsw_assert_cdclk(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 3f1ccd899f4b..49651f60113b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -804,6 +804,7 @@ static const struct intel_device_info cnl_info = {
#define GEN11_FEATURES \
GEN10_FEATURES, \
GEN11_DEFAULT_PAGE_SIZES, \
+ .abox_mask = BIT(0), \
.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) | \
BIT(TRANSCODER_C) | BIT(TRANSCODER_EDP) | \
BIT(TRANSCODER_DSI_0) | BIT(TRANSCODER_DSI_1), \
@@ -848,6 +849,7 @@ static const struct intel_device_info ehl_info = {
GEN11_FEATURES, \
GEN(12), \
.bw_buddy_mask = GENMASK(2, 1), \
+ .abox_mask = GENMASK(2, 0), \
.pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | BIT(PIPE_D), \
.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) | \
BIT(TRANSCODER_C) | BIT(TRANSCODER_D) | \
@@ -884,6 +886,7 @@ static const struct intel_device_info rkl_info = {
GEN12_FEATURES,
PLATFORM(INTEL_ROCKETLAKE),
.bw_buddy_mask = BIT(0),
+ .abox_mask = BIT(0),
.pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C),
.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) |
BIT(TRANSCODER_C),
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fe2aefc12141..4c3e822e1024 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2879,9 +2879,12 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define LM_FIFO_WATERMARK 0x001F
#define MI_ARB_STATE _MMIO(0x20e4) /* 915+ only */
-#define MBUS_ABOX_CTL _MMIO(0x45038)
-#define MBUS_ABOX1_CTL _MMIO(0x45048)
-#define MBUS_ABOX2_CTL _MMIO(0x4504C)
+#define _MBUS_ABOX0_CTL0x45038
+#define _MBUS_ABOX1_CTL0x45048
+#define _MBUS_ABOX2_CTL0x4504C
+#define MBUS_ABOX_CTL(x) _MMIO(_PICK(x, _MBUS_ABOX0_CTL, \
+ _MBUS_ABOX1_CTL, \
+ _MBUS_ABOX2_CTL))
#define MBUS_ABOX_BW_CREDIT_MASK (3 << 20)
#define MBUS_ABOX_BW_CREDIT(x) ((x) << 20)
#define MBUS_ABOX_B_CREDIT_MASK(0xF << 16)
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 73da4f1b8e2e..363f62e2d361 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -176,6 +176,7 @@ struct intel_device_info {
Re: [Intel-gfx] [PATCH] drm/i915: Add psr_safest_params
Looks good to me.
Reviewed-by: Gwan-gyeong Mun
On Wed, 2020-05-20 at 14:27 -0700, José Roberto de Souza wrote:
> This parameter is meant to be used when PSR issues are found as some
> issues in the past was due wrong values set in VBT so this would be
> a quick and easy way to ask users or for us to check if the issue is
> due VBT values.
>
> Cc: Gwan-gyeong Mun
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 37 ++--
>
> drivers/gpu/drm/i915/i915_params.c | 5
> drivers/gpu/drm/i915/i915_params.h | 1 +
> 3 files changed, 34 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index b7a2c102648a..859780853f42 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -426,6 +426,12 @@ static u32 intel_psr1_get_tp_time(struct
> intel_dp *intel_dp)
> if (INTEL_GEN(dev_priv) >= 11)
> val |= EDP_PSR_TP4_TIME_0US;
>
> + if (i915_modparams.psr_safest_params) {
> + val |= EDP_PSR_TP1_TIME_2500us;
> + val |= EDP_PSR_TP2_TP3_TIME_2500us;
> + goto check_tp3_sel;
> + }
> +
> if (dev_priv->vbt.psr.tp1_wakeup_time_us == 0)
> val |= EDP_PSR_TP1_TIME_0us;
> else if (dev_priv->vbt.psr.tp1_wakeup_time_us <= 100)
> @@ -444,6 +450,7 @@ static u32 intel_psr1_get_tp_time(struct intel_dp
> *intel_dp)
> else
> val |= EDP_PSR_TP2_TP3_TIME_2500us;
>
> +check_tp3_sel:
> if (intel_dp_source_supports_hbr2(intel_dp) &&
> drm_dp_tps3_supported(intel_dp->dpcd))
> val |= EDP_PSR_TP1_TP3_SEL;
> @@ -495,18 +502,13 @@ static void hsw_activate_psr1(struct intel_dp
> *intel_dp)
> intel_de_write(dev_priv, EDP_PSR_CTL(dev_priv->psr.transcoder),
> val);
> }
>
> -static void hsw_activate_psr2(struct intel_dp *intel_dp)
> +static u32 intel_psr2_get_tp_time(struct intel_dp *intel_dp)
> {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> - u32 val;
> -
> - val = psr_compute_idle_frames(intel_dp) <<
> EDP_PSR2_IDLE_FRAME_SHIFT;
> -
> - val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> - if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> - val |= EDP_Y_COORDINATE_ENABLE;
> + u32 val = 0;
>
> - val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv->psr.sink_sync_latency
> + 1);
> + if (i915_modparams.psr_safest_params)
> + return EDP_PSR2_TP2_TIME_2500us;
>
> if (dev_priv->vbt.psr.psr2_tp2_tp3_wakeup_time_us >= 0 &&
> dev_priv->vbt.psr.psr2_tp2_tp3_wakeup_time_us <= 50)
> @@ -518,6 +520,23 @@ static void hsw_activate_psr2(struct intel_dp
> *intel_dp)
> else
> val |= EDP_PSR2_TP2_TIME_2500us;
>
> + return val;
> +}
> +
> +static void hsw_activate_psr2(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> + u32 val;
> +
> + val = psr_compute_idle_frames(intel_dp) <<
> EDP_PSR2_IDLE_FRAME_SHIFT;
> +
> + val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> + val |= EDP_Y_COORDINATE_ENABLE;
> +
> + val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv->psr.sink_sync_latency
> + 1);
> + val |= intel_psr2_get_tp_time(intel_dp);
> +
> /*
>* PSR2 HW is incorrectly using EDP_PSR_TP1_TP3_SEL and BSpec
> is
>* recommending keep this bit unset while PSR2 is enabled.
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index add00ec1f787..307e4667fc62 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -88,6 +88,11 @@ i915_param_named_unsafe(enable_psr, int, 0600,
> "(0=disabled, 1=enabled) "
> "Default: -1 (use per-chip default)");
>
> +i915_param_named(psr_safest_params, bool, 0400,
> + "Replace PSR VBT parameters by the safest and not optimal ones.
> This "
> + "is helpfull to detect if PSR issues are related to bad values
> set in "
> + " VBT. (0=use VBT paramters, 1=use safest parameters)");
> +
> i915_param_named_unsafe(force_probe, charp, 0400,
> "Force probe the driver for specified devices. "
> "See CONFIG_DRM_I915_FORCE_PROBE for details.");
> diff --git a/drivers/gpu/drm/i915/i915_params.h
> b/drivers/gpu/drm/i915/i915_params.h
> index 45323732f099..2a99c908c7c8 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -53,6 +53,7 @@ struct drm_printer;
> param(int, enable_dc, -1, 0400) \
> param(int, enable_fbc, -1, 0600) \
> param(int, enable_psr, -1, 0600) \
> + param(bool, psr_safest_params, false, 0600) \
> param(int, disable_power_well, -1, 0400) \
> param(int, enable_ips, 1, 0600) \
> param(int, invert_brightness, 0,
Re: [Intel-gfx] [PATCH v3 07/15] drm/i915/rkl: Update TGP's pin mapping when paired with RKL
On Thu, Jun 04, 2020 at 09:29:19PM +0300, Ville Syrjälä wrote:
> On Wed, Jun 03, 2020 at 02:15:21PM -0700, Matt Roper wrote:
> > When TGP is paired with RKL it uses a different HPD pin mapping than
> > when paired with TGL.
> >
> > Cc: Ville Syrjälä
> > Signed-off-by: Matt Roper
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 15 ++-
> > 1 file changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 490574669eaa..f3ea81a17352 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -167,6 +167,17 @@ static const u32 hpd_tgp[HPD_NUM_PINS] = {
> > [HPD_PORT_I] = SDE_TC_HOTPLUG_ICP(PORT_TC6),
> > };
> >
> > +/*
> > + * TGP when paired with RKL has different pin mappings than when paired
> > + * with TGL.
> > + */
> > +static const u32 hpd_rkl_tgp[HPD_NUM_PINS] = {
> > + [HPD_PORT_A] = SDE_DDI_HOTPLUG_ICP(PORT_A),
> > + [HPD_PORT_B] = SDE_DDI_HOTPLUG_ICP(PORT_B),
> > + [HPD_PORT_C] = SDE_TC_HOTPLUG_ICP(PORT_TC1),
> > + [HPD_PORT_D] = SDE_TC_HOTPLUG_ICP(PORT_TC2),
> > +};
>
> Hmm. So basically it looks like we'd want to pick the hpd_pin
> based on the DDI rather than the PHY on this platform?
I may be misinterpreting the table on bspec 49181, but I *think* it
looks like we use the DDI when paired with a TGP PCH and the PHY when
paired with CMP PCH. So if I just set the hpd_pin based on the DDI,
then I think that will break the CMP-based systems (although I haven't
tested on one of those, so I'm not 100% sure).
Matt
>
> OK, I guess we need to remap somehow. The question is
> whether we want to do it before or after selecting hpd_pin...
> I think we would want to do it before, as otherwise the
> long_detect() stuff won't work right AFAICS. Or am I
> missing something?
>
> Side note: we should probably convert the long_detect()
> switches to arrays just like we have for the isr bits here.
> Would potentially avoid having to touch that code every time
> they tweak these thinhs in hw.
>
> And in fact it looks like icp already has all the same hpd
> pins as tgp, so I'm thinking we should just s/hpd_tgp/hpd_icp/
> and for icl/jsl we should remap hpd_pin as well. Oh and the
> mcc case would just need a slightly different mapping of
> port C -> HPD_PORT_D (aka. tc1).
>
> This way all the hpd[] arrays and whatnot would just be based
> on the actual pch type and not based on what it happens to be
> paired with.
>
> Anwyays, most of that is out of scope for this rkl stuff, so
> I guess for now just add a bit of logic to remap hpd_pin for rkl?
>
> > +
> > static void intel_hpd_init_pins(struct drm_i915_private *dev_priv)
> > {
> > struct i915_hotplug *hpd = _priv->hotplug;
> > @@ -196,7 +207,9 @@ static void intel_hpd_init_pins(struct drm_i915_private
> > *dev_priv)
> > if (!HAS_PCH_SPLIT(dev_priv) || HAS_PCH_NOP(dev_priv))
> > return;
> >
> > - if (HAS_PCH_TGP(dev_priv) || HAS_PCH_JSP(dev_priv))
> > + if (HAS_PCH_TGP(dev_priv) && IS_ROCKETLAKE(dev_priv))
> > + hpd->pch_hpd = hpd_rkl_tgp;
> > + else if (HAS_PCH_TGP(dev_priv) || HAS_PCH_JSP(dev_priv))
> > hpd->pch_hpd = hpd_tgp;
> > else if (HAS_PCH_ICP(dev_priv) || HAS_PCH_MCC(dev_priv))
> > hpd->pch_hpd = hpd_icp;
> > --
> > 2.24.1
>
> --
> Ville Syrjälä
> Intel
--
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.IGT: success for drm/i915/gt: Initialize reserved and unspecified MOCS indices
== Series Details ==
Series: drm/i915/gt: Initialize reserved and unspecified MOCS indices
URL : https://patchwork.freedesktop.org/series/78012/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8585_full -> Patchwork_17875_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_17875_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_exec_reloc@basic-concurrent16}:
- shard-kbl: [TIMEOUT][1] ([i915#1930]) -> [TIMEOUT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/shard-kbl4/igt@gem_exec_re...@basic-concurrent16.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17875/shard-kbl2/igt@gem_exec_re...@basic-concurrent16.html
Known issues
Here are the changes found in Patchwork_17875_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_whisper@basic-contexts-forked:
- shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/shard-glk9/igt@gem_exec_whis...@basic-contexts-forked.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17875/shard-glk8/igt@gem_exec_whis...@basic-contexts-forked.html
* igt@i915_suspend@debugfs-reader:
- shard-skl: [PASS][5] -> [INCOMPLETE][6] ([i915#69]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/shard-skl7/igt@i915_susp...@debugfs-reader.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17875/shard-skl10/igt@i915_susp...@debugfs-reader.html
* igt@kms_big_fb@x-tiled-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_8585/shard-glk4/igt@kms_big...@x-tiled-64bpp-rotate-0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17875/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-0.html
* igt@kms_big_fb@x-tiled-8bpp-rotate-0:
- shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/shard-apl6/igt@kms_big...@x-tiled-8bpp-rotate-0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17875/shard-apl6/igt@kms_big...@x-tiled-8bpp-rotate-0.html
* igt@kms_big_fb@y-tiled-32bpp-rotate-270:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#1172] / [i915#1897])
+10 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/shard-tglb1/igt@kms_big...@y-tiled-32bpp-rotate-270.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17875/shard-tglb1/igt@kms_big...@y-tiled-32bpp-rotate-270.html
* igt@kms_cursor_crc@pipe-b-cursor-256x85-offscreen:
- shard-skl: [PASS][13] -> [FAIL][14] ([i915#54]) +1 similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/shard-skl6/igt@kms_cursor_...@pipe-b-cursor-256x85-offscreen.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17875/shard-skl4/igt@kms_cursor_...@pipe-b-cursor-256x85-offscreen.html
* igt@kms_flip_tiling@flip-x-tiled:
- shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#95]) +15
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/shard-apl8/igt@kms_flip_til...@flip-x-tiled.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17875/shard-apl4/igt@kms_flip_til...@flip-x-tiled.html
* igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-mmap-wc:
- shard-iclb: [PASS][17] -> [DMESG-WARN][18] ([i915#1982])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/shard-iclb5/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-mmap-wc.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17875/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-mmap-wc.html
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-move:
- shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#93] / [i915#95])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/shard-kbl2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-move.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17875/shard-kbl7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-move.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-blt:
- shard-tglb: [PASS][21] -> [FAIL][22] ([i915#1897]) +139 similar
issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/shard-tglb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-blt.html
[22]:
Re: [Intel-gfx] [PATCH v3 13/15] drm/i915/rkl: Handle HTI
On Thu, Jun 04, 2020 at 07:59:55PM +0300, Ville Syrjälä wrote:
> On Wed, Jun 03, 2020 at 02:15:27PM -0700, Matt Roper wrote:
> > If HTI (also sometimes called HDPORT) is enabled at startup, it may be
>
> whatis HTI?
That's not really clear in the bspec or any other documents I've seen.
It sounds like its something setup by the boot firmware that can
potentially steal PLL and PHYs away. Driver-wise there doesn't seem to
be much we need to do other than avoid using the reserved resources,
sort of like how we avoid using fused off units.
Matt
>
> > 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 bcc6dc4e321b..cdd84a419cf7 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"
> > @@ -16817,6 +16818,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;
> > @@ -16828,10 +16836,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);
> > @@ -18379,6 +18399,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);
> > +
> > 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)
> > +{
> > + u32 hdport_state;
> > +
> > + if (!IS_ROCKETLAKE(dev_priv))
> > + return 0;
> > +
> > + hdport_state = intel_de_read(dev_priv, HDPORT_STATE);
> > + if (!(hdport_state & HDPORT_ENABLED))
> > + return 0;
> > +
> > + return
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Async GPU relocations only
== Series Details ==
Series: drm/i915/gem: Async GPU relocations only
URL : https://patchwork.freedesktop.org/series/78016/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8588 -> Patchwork_17878
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17878/index.html
Known issues
Here are the changes found in Patchwork_17878 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-tgl-y/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17878/fi-tgl-y/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17878/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17878/fi-byt-j1900/igt@i915_pm_...@module-reload.html
- fi-glk-dsi: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17878/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17878/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* {igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1}:
- fi-icl-u2: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/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_17878/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-tgl-y: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17878/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
Warnings
* igt@gem_exec_suspend@basic-s3:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92]) ->
[DMESG-WARN][16] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17878/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +4 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17878/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) ->
[DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8588/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17878/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (51 ->
Re: [Intel-gfx] [PATCH v3 02/15] drm/i915/rkl: Program BW_BUDDY0 registers instead of BW_BUDDY1/2
On Thu, Jun 04, 2020 at 08:01:57PM +0300, Ville Syrjälä wrote:
> On Wed, Jun 03, 2020 at 02:15:16PM -0700, Matt Roper wrote:
> > RKL uses the same BW_BUDDY programming table as TGL, but programs the
> > values into a single set BUDDY0 set of registers rather than the
> > BUDDY1/BUDDY2 sets used by TGL.
>
> Maybe we just want some kind of HAS_ABOX() so we could use the same
> thing here and in the ABOX_CTL programming?
Although these are both related to how the display controller accesses
memory, I don't think they're quite a 1:1 mapping. TGL has
MBUX_ABOX_CTL{0,1,2} (and we're directed to program all three), but only
has BW_BUDDY_CTL{1,2} and no 0 instance.
For now I'll just add separate bw_buddy and abox masks to our platform
device info structure.
Matt
>
> >
> > Bspec: 49218
> > Cc: Aditya Swarup
> > Signed-off-by: Matt Roper
> > ---
> > .../drm/i915/display/intel_display_power.c| 44 +++
> > drivers/gpu/drm/i915/i915_reg.h | 14 --
> > 2 files changed, 35 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > index 72312b67b57a..2c1ce50b572b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > @@ -5254,7 +5254,7 @@ static void tgl_bw_buddy_init(struct drm_i915_private
> > *dev_priv)
> > enum intel_dram_type type = dev_priv->dram_info.type;
> > u8 num_channels = dev_priv->dram_info.num_channels;
> > const struct buddy_page_mask *table;
> > - int i;
> > + int config, min_buddy, max_buddy, i;
> >
> > if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_B0))
> > /* Wa_1409767108: tgl */
> > @@ -5262,29 +5262,35 @@ static void tgl_bw_buddy_init(struct
> > drm_i915_private *dev_priv)
> > else
> > table = tgl_buddy_page_masks;
> >
> > - for (i = 0; table[i].page_mask != 0; i++)
> > - if (table[i].num_channels == num_channels &&
> > - table[i].type == type)
> > + if (IS_ROCKETLAKE(dev_priv)) {
> > + min_buddy = max_buddy = 0;
> > + } else {
> > + min_buddy = 1;
> > + max_buddy = 2;
> > + }
> > +
> > + for (config = 0; table[config].page_mask != 0; config++)
> > + if (table[config].num_channels == num_channels &&
> > + table[config].type == type)
> > break;
> >
> > - if (table[i].page_mask == 0) {
> > + if (table[config].page_mask == 0) {
> > drm_dbg(_priv->drm,
> > "Unknown memory configuration; disabling address buddy
> > logic.\n");
> > - intel_de_write(dev_priv, BW_BUDDY1_CTL, BW_BUDDY_DISABLE);
> > - intel_de_write(dev_priv, BW_BUDDY2_CTL, BW_BUDDY_DISABLE);
> > + for (i = min_buddy; i <= max_buddy; i++)
> > + intel_de_write(dev_priv, BW_BUDDY_CTL(i),
> > + BW_BUDDY_DISABLE);
> > } else {
> > - intel_de_write(dev_priv, BW_BUDDY1_PAGE_MASK,
> > - table[i].page_mask);
> > - intel_de_write(dev_priv, BW_BUDDY2_PAGE_MASK,
> > - table[i].page_mask);
> > -
> > - /* Wa_22010178259:tgl */
> > - intel_de_rmw(dev_priv, BW_BUDDY1_CTL,
> > -BW_BUDDY_TLB_REQ_TIMER_MASK,
> > -REG_FIELD_PREP(BW_BUDDY_TLB_REQ_TIMER_MASK, 0x8));
> > - intel_de_rmw(dev_priv, BW_BUDDY2_CTL,
> > -BW_BUDDY_TLB_REQ_TIMER_MASK,
> > -REG_FIELD_PREP(BW_BUDDY_TLB_REQ_TIMER_MASK, 0x8));
> > + for (i = min_buddy; i <= max_buddy; i++) {
> > + intel_de_write(dev_priv, BW_BUDDY_PAGE_MASK(i),
> > + table[config].page_mask);
> > +
> > + /* Wa_22010178259:tgl,rkl */
> > + intel_de_rmw(dev_priv, BW_BUDDY_CTL(i),
> > +BW_BUDDY_TLB_REQ_TIMER_MASK,
> > +REG_FIELD_PREP(BW_BUDDY_TLB_REQ_TIMER_MASK,
> > + 0x8));
> > + }
> > }
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 578cfe11cbb9..3e79cefc510a 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7837,13 +7837,19 @@ enum {
> > #define WAIT_FOR_PCH_RESET_ACK(1 << 1)
> > #define WAIT_FOR_PCH_FLR_ACK (1 << 0)
> >
> > -#define BW_BUDDY1_CTL _MMIO(0x45140)
> > -#define BW_BUDDY2_CTL _MMIO(0x45150)
> > +#define _BW_BUDDY0_CTL 0x45130
> > +#define _BW_BUDDY1_CTL 0x45140
> > +#define BW_BUDDY_CTL(x)_MMIO(_PICK_EVEN(x, \
> > +
Re: [Intel-gfx] [PATCH v2] drm/i915/gt: Initialize reserved and unspecified MOCS indices
Ayaz A Siddiqui writes:
> In order to avoid functional breakage of mis-programmed applications that
> have grown to depend on unused MOCS entries, we are programming
> those entries to be equal to fully cached ("L3 + LLC") entry as per the
> recommendation from architecture team.
>
> These reserved and unspecified entries should not be used as they may be
> changed to less performant variants with better coherency in the future
> if more entries are needed.
>
This change seems highly questionable to me... If a future kernel
release introduces a new MOCS entry with more strict coherency
semantics, and an application starts relying on it, that application
won't work when run on an older kernel version with this patch is
applied. IOW setting uninitialized entries to the most strict caching
setting available (UC) ensures forwards compatibility with future
userspace, which seems like a more important design principle than
giving full caching to broken userspace that accidentally makes use of
an undefined MOCS entry not part of the kernel ABI.
> Signed-off-by: Ayaz A Siddiqui
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/gt/intel_mocs.c | 93 ++--
> 1 file changed, 89 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
> b/drivers/gpu/drm/i915/gt/intel_mocs.c
> index 632e08a4592b..1089bd5fdba2 100644
> --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> @@ -234,10 +234,6 @@ static const struct drm_i915_mocs_entry
> broxton_mocs_table[] = {
> L3_1_UC)
>
> static const struct drm_i915_mocs_entry tgl_mocs_table[] = {
> - /* Base - Error (Reserved for Non-Use) */
> - MOCS_ENTRY(0, 0x0, 0x0),
> - /* Base - Reserved */
> - MOCS_ENTRY(1, 0x0, 0x0),
>
> GEN11_MOCS_ENTRIES,
>
> @@ -265,6 +261,95 @@ static const struct drm_i915_mocs_entry tgl_mocs_table[]
> = {
> MOCS_ENTRY(61,
> LE_1_UC | LE_TC_1_LLC,
> L3_3_WB),
> +
> + /* NOTE:
> + * Reserved and unspecified MOCS indices have been set to (L3 + LCC).
> + * These reserved entry should never be used, they may be chanaged
> + * to low performant variants with better coherency in the future if
> + * more entries are needed.
> + */
> +
> + /* Reserved index 0 and 1 */
> + MOCS_ENTRY(0, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(1, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> +
> + /* Reserved index 16 and 17 */
> + MOCS_ENTRY(16, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(17, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> +
> + /* Reserved index 24 and 25 */
> + MOCS_ENTRY(24, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(25, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> +
> + /* Unspecified indices 26 to 47 */
> + MOCS_ENTRY(26, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(27, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(28, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(29, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(30, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(31, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(32, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(33, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(34, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(35, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(36, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(37, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(38, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(39, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(40, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(41, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(42, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(43, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(44, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(45, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(46, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> + MOCS_ENTRY(47, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_3_WB),
> +
> + /* Unspecified indices
[Intel-gfx] [CI] drm/i915/gem: Async GPU relocations only
Reduce the 3 relocation paths down to the single path that accommodates
all. The primary motivation for this is to guard the relocations with a
natural fence (derived from the i915_request used to write the
relocation from the GPU).
The tradeoff in using async gpu relocations is that it increases latency
over using direct CPU relocations, for the cases where the target is
idle and accessible by the CPU. The benefit is greatly reduced lock
contention and improved concurrency by pipelining.
Note that forcing the async gpu relocations does reveal a few issues
they have. Firstly, is that they are visible as writes to gem_busy,
causing to mark some buffers are being to written to by the GPU even
though userspace only reads. Secondly is that, in combination with the
cmdparser, they can cause priority inversions. This should be the case
where the work is being put into a common workqueue losing our priority
information and so being executed in FIFO from the worker, denying us
the opportunity to reorder the requests afterwards.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 295 ++
.../i915/gem/selftests/i915_gem_execbuffer.c | 21 +-
2 files changed, 27 insertions(+), 289 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 340e7f108baf..cfe6d2cdbef1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -45,13 +45,6 @@ struct eb_vma_array {
struct eb_vma vma[];
};
-enum {
- FORCE_CPU_RELOC = 1,
- FORCE_GTT_RELOC,
- FORCE_GPU_RELOC,
-#define DBG_FORCE_RELOC 0 /* choose one of the above! */
-};
-
#define __EXEC_OBJECT_HAS_PIN BIT(31)
#define __EXEC_OBJECT_HAS_FENCEBIT(30)
#define __EXEC_OBJECT_NEEDS_MAPBIT(29)
@@ -260,8 +253,6 @@ struct i915_execbuffer {
*/
struct reloc_cache {
struct drm_mm_node node; /** temporary GTT binding */
- unsigned long vaddr; /** Current kmap address */
- unsigned long page; /** Currently mapped page index */
unsigned int gen; /** Cached value of INTEL_GEN */
bool use_64bit_reloc : 1;
bool has_llc : 1;
@@ -605,23 +596,6 @@ eb_add_vma(struct i915_execbuffer *eb,
}
}
-static inline int use_cpu_reloc(const struct reloc_cache *cache,
- const struct drm_i915_gem_object *obj)
-{
- if (!i915_gem_object_has_struct_page(obj))
- return false;
-
- if (DBG_FORCE_RELOC == FORCE_CPU_RELOC)
- return true;
-
- if (DBG_FORCE_RELOC == FORCE_GTT_RELOC)
- return false;
-
- return (cache->has_llc ||
- obj->cache_dirty ||
- obj->cache_level != I915_CACHE_NONE);
-}
-
static int eb_reserve_vma(const struct i915_execbuffer *eb,
struct eb_vma *ev,
u64 pin_flags)
@@ -945,8 +919,6 @@ relocation_target(const struct
drm_i915_gem_relocation_entry *reloc,
static void reloc_cache_init(struct reloc_cache *cache,
struct drm_i915_private *i915)
{
- cache->page = -1;
- cache->vaddr = 0;
/* Must be a variable in the struct to allow GCC to unroll. */
cache->gen = INTEL_GEN(i915);
cache->has_llc = HAS_LLC(i915);
@@ -1089,181 +1061,6 @@ static int reloc_gpu_flush(struct reloc_cache *cache)
return err;
}
-static void reloc_cache_reset(struct reloc_cache *cache)
-{
- void *vaddr;
-
- if (!cache->vaddr)
- return;
-
- vaddr = unmask_page(cache->vaddr);
- if (cache->vaddr & KMAP) {
- if (cache->vaddr & CLFLUSH_AFTER)
- mb();
-
- kunmap_atomic(vaddr);
- i915_gem_object_finish_access((struct drm_i915_gem_object
*)cache->node.mm);
- } else {
- struct i915_ggtt *ggtt = cache_to_ggtt(cache);
-
- intel_gt_flush_ggtt_writes(ggtt->vm.gt);
- io_mapping_unmap_atomic((void __iomem *)vaddr);
-
- if (drm_mm_node_allocated(>node)) {
- ggtt->vm.clear_range(>vm,
-cache->node.start,
-cache->node.size);
- mutex_lock(>vm.mutex);
- drm_mm_remove_node(>node);
- mutex_unlock(>vm.mutex);
- } else {
- i915_vma_unpin((struct i915_vma *)cache->node.mm);
- }
- }
-
- cache->vaddr = 0;
- cache->page = -1;
-}
-
-static void *reloc_kmap(struct drm_i915_gem_object *obj,
- struct reloc_cache *cache,
- unsigned long page)
-{
- void *vaddr;
-
- if
Re: [Intel-gfx] [PATCH] drm/i915/dp: DP PHY compliance for JSL
On Thu, Jun 04, 2020 at 08:01:03PM +, Almahallawy, Khaled wrote:
> On Thu, 2020-06-04 at 22:06 +0300, Ville Syrjälä wrote:
> > On Thu, Jun 04, 2020 at 10:33:48AM +0530, Vidya Srinivas wrote:
> > > Signed-off-by: Khaled Almahallawy
> > > Signed-off-by: Vidya Srinivas
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp.c | 40
> > > ++---
> > > 1 file changed, 32 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 7223367171d1..44663e8ac9a1 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -5470,22 +5470,32 @@ intel_dp_autotest_phy_ddi_disable(struct
> > > intel_dp *intel_dp)
> > > struct drm_i915_private *dev_priv = to_i915(dev);
> > > struct intel_crtc *crtc = to_intel_crtc(intel_dig_port-
> > > >base.base.crtc);
> > > enum pipe pipe = crtc->pipe;
> > > - u32 trans_ddi_func_ctl_value, trans_conf_value,
> > > dp_tp_ctl_value;
> > > + u32 trans_ddi_func_ctl_value, trans_conf_value,
> > > dp_tp_ctl_value, trans_ddi_port_mask;
> > > + enum port port = intel_dig_port->base.port;
> > > + i915_reg_t dp_tp_reg;
> > > +
> > > + if (IS_ELKHARTLAKE(dev_priv)) {
> > > + dp_tp_reg = DP_TP_CTL(port);
> > > + trans_ddi_port_mask = TRANS_DDI_PORT_MASK;
> > > + } else if (IS_TIGERLAKE(dev_priv)) {
> > > + dp_tp_reg = TGL_DP_TP_CTL(pipe);
> > > + trans_ddi_port_mask = TGL_TRANS_DDI_PORT_MASK;
> > > + }
> > >
> > > trans_ddi_func_ctl_value = intel_de_read(dev_priv,
> > >TRANS_DDI_FUNC_CTL(pip
> > > e));
> > > trans_conf_value = intel_de_read(dev_priv, PIPECONF(pipe));
> > > - dp_tp_ctl_value = intel_de_read(dev_priv, TGL_DP_TP_CTL(pipe));
> > >
> > > + dp_tp_ctl_value = intel_de_read(dev_priv, dp_tp_reg);
> > > trans_ddi_func_ctl_value &= ~(TRANS_DDI_FUNC_ENABLE |
> > > - TGL_TRANS_DDI_PORT_MASK);
> > > + trans_ddi_port_mask);
> > > trans_conf_value &= ~PIPECONF_ENABLE;
> > > dp_tp_ctl_value &= ~DP_TP_CTL_ENABLE;
> > >
> > > intel_de_write(dev_priv, PIPECONF(pipe), trans_conf_value);
> > > intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(pipe),
> > > trans_ddi_func_ctl_value);
> > > - intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe), dp_tp_ctl_value);
> > > + intel_de_write(dev_priv, dp_tp_reg, dp_tp_ctl_value);
> >
> > All this ad-hoc modeset code really should not exist. It's going to
> > have different bugs than the norma modeset paths, so compliance
> > testing
> > this special code proves absolutely nothing about the normal modeset
> > code. IMO someone needs to take up the task of rewrtiting all this to
> > just perform normal modesets.
>
> Agree. I've just found that we get kernel NULL pointer dereference and
> panic when we try to access to_intel_crtc(intel_dig_port-
> >base.base.crtc).
Yeah, that's a legacy pointer which should no longer be used at all
with atomic drivers. I'm slowly trying to clear out all this legacy
cruft. The next step I had hoped to take was
https://patchwork.freedesktop.org/series/76993/ but then this
compliacnce stuff landed and threw another wrench into the works.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: Add HBR and HBR2+ voltage swing table
On Wed, 2020-06-03 at 05:55 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/tgl: Add HBR and HBR2+ voltage swing table
> URL : https://patchwork.freedesktop.org/series/77934/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_8573_full -> Patchwork_17847_full
>
>
> Summary
> ---
>
> **SUCCESS**
>
> No regressions found.
Thanks for the review Khaled, pushed to dinq.
>
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_17847_full that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox:
> - shard-skl: [PASS][1] -> [FAIL][2] ([i915#1528])
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-skl7/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17847/shard-skl3/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html
>
> * igt@i915_pm_rpm@system-suspend-execbuf:
> - shard-iclb: [PASS][3] -> [INCOMPLETE][4] ([i915#1185] /
> [i915#189])
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-iclb4/igt@i915_pm_...@system-suspend-execbuf.html
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17847/shard-iclb4/igt@i915_pm_...@system-suspend-execbuf.html
>
> * igt@i915_suspend@forcewake:
> - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#180])
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-kbl3/igt@i915_susp...@forcewake.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17847/shard-kbl4/igt@i915_susp...@forcewake.html
>
> * igt@kms_cursor_crc@pipe-a-cursor-64x64-sliding:
> - shard-kbl: [PASS][7] -> [FAIL][8] ([i915#54] / [i915#93] /
> [i915#95])
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-64x64-sliding.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17847/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-64x64-sliding.html
>
> * igt@kms_cursor_edge_walk@pipe-a-256x256-right-edge:
> - shard-apl: [PASS][9] -> [FAIL][10] ([i915#70] / [i915#95])
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-apl2/igt@kms_cursor_edge_w...@pipe-a-256x256-right-edge.html
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17847/shard-apl8/igt@kms_cursor_edge_w...@pipe-a-256x256-right-edge.html
>
> * igt@kms_fbcon_fbt@fbc-suspend:
> - shard-apl: [PASS][11] -> [FAIL][12] ([i915#1525] / [i915#95])
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-apl6/igt@kms_fbcon_...@fbc-suspend.html
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17847/shard-apl2/igt@kms_fbcon_...@fbc-suspend.html
>
> * igt@kms_hdr@bpc-switch:
> - shard-skl: [PASS][13] -> [FAIL][14] ([i915#1188])
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-skl4/igt@kms_...@bpc-switch.html
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17847/shard-skl8/igt@kms_...@bpc-switch.html
>
> * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
> - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180])
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-apl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17847/shard-apl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
>
> * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
> - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#265])
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-skl2/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html
>[18]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17847/shard-skl6/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html
>
> * igt@kms_psr@psr2_dpms:
> - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +2 similar
> issues
>[19]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-iclb2/igt@kms_psr@psr2_dpms.html
>[20]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17847/shard-iclb7/igt@kms_psr@psr2_dpms.html
>
>
> Possible fixes
>
> * igt@gem_ctx_persistence@legacy-engines-mixed-process@blt:
> - shard-skl: [FAIL][21] ([i915#1528]) -> [PASS][22]
>[21]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-skl7/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html
>[22]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17847/shard-skl3/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html
>
> * {igt@i915_selftest@perf@request}:
> - shard-tglb: [DMESG-FAIL][23]
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Add HBR and HBR2+ voltage swing table
On Tue, 2020-06-02 at 13:54 -0700, José Roberto de Souza wrote:
> As latest update we have now 2 voltage swing tables for DP over DKL
> PHY with only one difference in Level 0 pre-emphasis 3.
> So with 2 tables for DP is time to have one single function to return
> all DKL voltage swing tables.
>
> BSpec: 49292
> Cc: Khaled Almahallawy
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 50
>
> 1 file changed, 42 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index cd211f48c401..763d76056ca9 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -641,6 +641,20 @@ static const struct tgl_dkl_phy_ddi_buf_trans
> tgl_dkl_phy_dp_ddi_trans[] = {
> { 0x7, 0x0, 0x00 }, /* 00 400mV 0 dB
> */
> { 0x5, 0x0, 0x05 }, /* 01 400mV 3.5
> dB */
> { 0x2, 0x0, 0x0B }, /* 02 400mV 6 dB
> */
> + { 0x0, 0x0, 0x18 }, /* 03 400mV 9.5
> dB */
> + { 0x5, 0x0, 0x00 }, /* 10 600mV 0 dB
> */
> + { 0x2, 0x0, 0x08 }, /* 11 600mV 3.5
> dB */
> + { 0x0, 0x0, 0x14 }, /* 12 600mV 6 dB
> */
> + { 0x2, 0x0, 0x00 }, /* 20 800mV 0 dB
> */
> + { 0x0, 0x0, 0x0B }, /* 21 800mV 3.5
> dB */
> + { 0x0, 0x0, 0x00 }, /* 30 1200mV 0 dB
> HDMI default */
> +};
> +
> +static const struct tgl_dkl_phy_ddi_buf_trans
> tgl_dkl_phy_dp_ddi_trans_hbr2[] = {
> + /* VS pre-emp Non-trans mVPre-
> emph dB */
> + { 0x7, 0x0, 0x00 }, /* 00 400mV 0 dB
> */
> + { 0x5, 0x0, 0x05 }, /* 01 400mV 3.5
> dB */
> + { 0x2, 0x0, 0x0B }, /* 02 400mV 6 dB
> */
> { 0x0, 0x0, 0x19 }, /* 03 400mV 9.5
> dB */
> { 0x5, 0x0, 0x00 }, /* 10 600mV 0 dB
> */
> { 0x2, 0x0, 0x08 }, /* 11 600mV 3.5
> dB */
> @@ -1014,6 +1028,22 @@ tgl_get_combo_buf_trans(struct
> drm_i915_private *dev_priv, int type, int rate,
> return tgl_combo_phy_ddi_translations_dp_hbr;
> }
>
> +static const struct tgl_dkl_phy_ddi_buf_trans *
> +tgl_get_dkl_buf_trans(struct drm_i915_private *dev_priv, int type,
> int rate,
> + int *n_entries)
> +{
> + if (type == INTEL_OUTPUT_HDMI) {
> + *n_entries = ARRAY_SIZE(tgl_dkl_phy_hdmi_ddi_trans);
> + return tgl_dkl_phy_hdmi_ddi_trans;
> + } else if (rate > 27) {
> + *n_entries = ARRAY_SIZE(tgl_dkl_phy_dp_ddi_trans_hbr2);
> + return tgl_dkl_phy_dp_ddi_trans_hbr2;
> + }
> +
> + *n_entries = ARRAY_SIZE(tgl_dkl_phy_dp_ddi_trans);
> + return tgl_dkl_phy_dp_ddi_trans;
> +}
> +
> static int intel_ddi_hdmi_level(struct intel_encoder *encoder)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> @@ -1025,7 +1055,8 @@ static int intel_ddi_hdmi_level(struct
> intel_encoder *encoder)
> tgl_get_combo_buf_trans(dev_priv,
> INTEL_OUTPUT_HDMI,
> 0, _entries);
> else
> - n_entries =
> ARRAY_SIZE(tgl_dkl_phy_hdmi_ddi_trans);
> + tgl_get_dkl_buf_trans(dev_priv,
> INTEL_OUTPUT_HDMI, 0,
> + _entries);
> default_entry = n_entries - 1;
> } else if (INTEL_GEN(dev_priv) == 11) {
> if (intel_phy_is_combo(dev_priv, phy))
> @@ -2108,7 +2139,8 @@ u8 intel_ddi_dp_voltage_max(struct
> intel_encoder *encoder)
> tgl_get_combo_buf_trans(dev_priv, encoder-
> >type,
> intel_dp->link_rate,
> _entries);
> else
> - n_entries =
> ARRAY_SIZE(tgl_dkl_phy_dp_ddi_trans);
> + tgl_get_dkl_buf_trans(dev_priv, encoder->type,
> + intel_dp->link_rate,
> _entries);
> } else if (INTEL_GEN(dev_priv) == 11) {
> if (IS_ELKHARTLAKE(dev_priv))
> ehl_get_combo_buf_trans(dev_priv, encoder-
> >type,
> @@ -2585,15 +2617,17 @@ tgl_dkl_phy_ddi_vswing_sequence(struct
> intel_encoder *encoder, int link_clock,
> enum tc_port tc_port = intel_port_to_tc(dev_priv, encoder-
> >port);
> const struct tgl_dkl_phy_ddi_buf_trans *ddi_translations;
> u32 n_entries, val, ln, dpcnt_mask, dpcnt_val;
> + int rate = 0;
>
> - if (encoder->type == INTEL_OUTPUT_HDMI) {
> - n_entries = ARRAY_SIZE(tgl_dkl_phy_hdmi_ddi_trans);
> - ddi_translations = tgl_dkl_phy_hdmi_ddi_trans;
> - } else {
> -
Re: [Intel-gfx] [PATCH] drm/i915/dp: DP PHY compliance for JSL
On Thu, 2020-06-04 at 22:06 +0300, Ville Syrjälä wrote:
> On Thu, Jun 04, 2020 at 10:33:48AM +0530, Vidya Srinivas wrote:
> > Signed-off-by: Khaled Almahallawy
> > Signed-off-by: Vidya Srinivas
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 40
> > ++---
> > 1 file changed, 32 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 7223367171d1..44663e8ac9a1 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -5470,22 +5470,32 @@ intel_dp_autotest_phy_ddi_disable(struct
> > intel_dp *intel_dp)
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > struct intel_crtc *crtc = to_intel_crtc(intel_dig_port-
> > >base.base.crtc);
> > enum pipe pipe = crtc->pipe;
> > - u32 trans_ddi_func_ctl_value, trans_conf_value,
> > dp_tp_ctl_value;
> > + u32 trans_ddi_func_ctl_value, trans_conf_value,
> > dp_tp_ctl_value, trans_ddi_port_mask;
> > + enum port port = intel_dig_port->base.port;
> > + i915_reg_t dp_tp_reg;
> > +
> > + if (IS_ELKHARTLAKE(dev_priv)) {
> > + dp_tp_reg = DP_TP_CTL(port);
> > + trans_ddi_port_mask = TRANS_DDI_PORT_MASK;
> > + } else if (IS_TIGERLAKE(dev_priv)) {
> > + dp_tp_reg = TGL_DP_TP_CTL(pipe);
> > + trans_ddi_port_mask = TGL_TRANS_DDI_PORT_MASK;
> > + }
> >
> > trans_ddi_func_ctl_value = intel_de_read(dev_priv,
> > TRANS_DDI_FUNC_CTL(pip
> > e));
> > trans_conf_value = intel_de_read(dev_priv, PIPECONF(pipe));
> > - dp_tp_ctl_value = intel_de_read(dev_priv, TGL_DP_TP_CTL(pipe));
> >
> > + dp_tp_ctl_value = intel_de_read(dev_priv, dp_tp_reg);
> > trans_ddi_func_ctl_value &= ~(TRANS_DDI_FUNC_ENABLE |
> > - TGL_TRANS_DDI_PORT_MASK);
> > + trans_ddi_port_mask);
> > trans_conf_value &= ~PIPECONF_ENABLE;
> > dp_tp_ctl_value &= ~DP_TP_CTL_ENABLE;
> >
> > intel_de_write(dev_priv, PIPECONF(pipe), trans_conf_value);
> > intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(pipe),
> >trans_ddi_func_ctl_value);
> > - intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe), dp_tp_ctl_value);
> > + intel_de_write(dev_priv, dp_tp_reg, dp_tp_ctl_value);
>
> All this ad-hoc modeset code really should not exist. It's going to
> have different bugs than the norma modeset paths, so compliance
> testing
> this special code proves absolutely nothing about the normal modeset
> code. IMO someone needs to take up the task of rewrtiting all this to
> just perform normal modesets.
Agree. I've just found that we get kernel NULL pointer dereference and
panic when we try to access to_intel_crtc(intel_dig_port-
>base.base.crtc). This is because we didn't realize when we developed
the code that test scope has an option to send PHY test request on Long
HPD. Current desing assume PHY test request on short HPD. Because of
that we got the following error
[ 106.810882] i915 :00:02.0: [drm:intel_hpd_irq_handler [i915]]
digital hpd on [ENCODER:308:DDI F] - long
[ 106.810916] i915 :00:02.0: [drm:intel_hpd_irq_handler [i915]]
Received HPD interrupt on PIN 9 - cnt: 10
[ 106.811026] i915 :00:02.0: [drm:intel_dp_hpd_pulse [i915]] got
hpd irq on [ENCODER:308:DDI F] - long
[ 106.811095] i915 :00:02.0: [drm:i915_hotplug_work_func [i915]]
running encoder hotplug functions
[ 106.811184] i915 :00:02.0: [drm:i915_hotplug_work_func [i915]]
Connector DP-3 (pin 9) received hotplug event. (retry 0)
[ 106.811227] i915 :00:02.0: [drm:intel_dp_detect [i915]]
[CONNECTOR:309:DP-3]
[ 106.811292] i915 :00:02.0: [drm:intel_power_well_enable [i915]]
enabling TC cold off
[ 106.811365] i915 :00:02.0: [drm:tgl_tc_cold_request [i915]] TC
cold block succeeded
[ 106.811489] i915 :00:02.0: [drm:__intel_tc_port_lock [i915]]
Port F/TC#3: TC port mode reset (tbt-alt -> dp-alt)
[ 106.811663] i915 :00:02.0: [drm:intel_power_well_enable [i915]]
enabling AUX F TC3
[ 106.812449] [drm:drm_dp_dpcd_read] AUX F/port F: 0x0 AUX ->
(ret= 15) 12 14 04 80 00 00 01 00 00 00 00 00 00 00 00
[ 106.812484] i915 :00:02.0: [drm:intel_dp_read_dpcd [i915]] DPCD:
12 14 04 80 00 00 01 00 00 00 00 00 00 00 00
[ 106.813266] [drm:drm_dp_dpcd_read] AUX F/port F: 0x00400 AUX ->
(ret= 12) 00 00 00 00 00 00 00 00 00 00 00 00
[ 106.813271] [drm:drm_dp_read_desc] DP sink: OUI 00-00-00 dev-ID HW-
rev 0.0 SW-rev 0.0 quirks 0x
[ 106.813891] [drm:drm_dp_dpcd_read] AUX F/port F: 0x00200 AUX ->
(ret= 1) 01
[ 106.813940] i915 :00:02.0: [drm:intel_dp_print_rates [i915]]
source rates: 162000, 216000, 27, 324000, 432000, 54, 648000,
81
[ 106.813974] i915 :00:02.0: [drm:intel_dp_print_rates [i915]]
sink rates: 162000, 27, 54
[ 106.814007] i915 :00:02.0: [drm:intel_dp_print_rates [i915]]
common
Re: [Intel-gfx] [PATCH] drm/i915/dp: Reset link params on connector disconnect
On Thu, Jun 04, 2020 at 12:40:20PM -0700, Manasi Navare wrote: > On Thu, Jun 04, 2020 at 10:23:40PM +0300, Imre Deak wrote: > > On Thu, Jun 04, 2020 at 10:08:58PM +0300, Imre Deak wrote: > > > On Thu, Jun 04, 2020 at 10:01:40PM +0300, Ville Syrjälä wrote: > > > > [...] > > > > > > Then we get this hpd, in this case if we dont reset the param to > > > > > > max values, prev triggered modeset continues > > > > > > with fallback values but since connector probe doesnt happen again > > > > > > through IGT, it tries the same mode > > > > > > with fallback values and return encoder config failure. > > > > > > > > > > If the link training failed then clearly the sink didn't like us > > > > > anymore > > > > > anyway. So feels like resetting these here is just shifting some race > > > > > window around a bit, but it could still fail if the sink still doesn't > > > > > like us. > > > > > > > > > > Would be good if someone was able to figure out why the sink goes bad > > > > > in > > > > > the first place. > > > > > > > > Oh, and don't we now have Imre's "weird hpd happened in the middle of > > > > the test, don't trust the results" thing in igt? > > > > > > An LG and IIyama monitor this happens on disconnect and reconnect after > > > waking from an idle state when modesetting them, not sure if it's the > > > same case. > > > > Manasi, could you try if a modeset on the monitor after it has been > > disabled for a while always results in a long HPD pulse a few seconds > > after the modeset? If so does this also happen when you just modeset in > > a sequence from one mode to the other not letting the monitor idle? The > > same monitor should be also tested then with the above sequences on > > older platforms if it behaves the same on those too. > > > > This test has been passing on older ICL platforms. But on TGL we do > see these AUX E timeouts once in a while which recover on their own > for the next modeset. Any idea why these spurious AUX timeouts and how > I can possibly rootcause why these timeouts are seen only with AUX E? If the monitor is in a disconnected state as you described, then AUX will fail too. So you need to root cause why the monitor gets disconnected. One possibility for that is what I described above. You can't really make a conclusion on a test passing on ICL and not on TGL, the timing can be different. You'd need to check if a disconnect happens due to long HPD pulse when using the same monitor with the sequences I described above, both on TGL and then also on ICL. > > Manasi > > > > > > > --Imre > > > ___ > > > Intel-gfx mailing list > > > Intel-gfx@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Reset link params on connector disconnect
On Thu, Jun 04, 2020 at 10:23:40PM +0300, Imre Deak wrote: > On Thu, Jun 04, 2020 at 10:08:58PM +0300, Imre Deak wrote: > > On Thu, Jun 04, 2020 at 10:01:40PM +0300, Ville Syrjälä wrote: > > > [...] > > > > > Then we get this hpd, in this case if we dont reset the param to max > > > > > values, prev triggered modeset continues > > > > > with fallback values but since connector probe doesnt happen again > > > > > through IGT, it tries the same mode > > > > > with fallback values and return encoder config failure. > > > > > > > > If the link training failed then clearly the sink didn't like us anymore > > > > anyway. So feels like resetting these here is just shifting some race > > > > window around a bit, but it could still fail if the sink still doesn't > > > > like us. > > > > > > > > Would be good if someone was able to figure out why the sink goes bad in > > > > the first place. > > > > > > Oh, and don't we now have Imre's "weird hpd happened in the middle of > > > the test, don't trust the results" thing in igt? > > > > An LG and IIyama monitor this happens on disconnect and reconnect after > > waking from an idle state when modesetting them, not sure if it's the > > same case. > > Manasi, could you try if a modeset on the monitor after it has been > disabled for a while always results in a long HPD pulse a few seconds > after the modeset? If so does this also happen when you just modeset in > a sequence from one mode to the other not letting the monitor idle? The > same monitor should be also tested then with the above sequences on > older platforms if it behaves the same on those too. > This test has been passing on older ICL platforms. But on TGL we do see these AUX E timeouts once in a while which recover on their own for the next modeset. Any idea why these spurious AUX timeouts and how I can possibly rootcause why these timeouts are seen only with AUX E? Manasi > > > > --Imre > > ___ > > 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.BUILD: failure for devm_drm_dev_alloc, v2 (rev3)
== Series Details == Series: devm_drm_dev_alloc, v2 (rev3) URL : https://patchwork.freedesktop.org/series/75956/ State : failure == Summary == Applying: drm: Add devm_drm_dev_alloc macro error: sha1 information is lacking or useless (drivers/gpu/drm/drm_drv.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm: Add devm_drm_dev_alloc macro When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915/dp_mst: Fix disabling MST on a port (rev4)
== Series Details ==
Series: series starting with [v2,1/3] drm/i915/dp_mst: Fix disabling MST on a
port (rev4)
URL : https://patchwork.freedesktop.org/series/77969/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8585 -> Patchwork_17876
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17876/index.html
Known issues
Here are the changes found in Patchwork_17876 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17876/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17876/fi-glk-dsi/igt@i915_pm_...@module-reload.html
Possible fixes
* igt@i915_selftest@live@execlists:
- fi-icl-y: [DMESG-FAIL][5] ([i915#1993]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/fi-icl-y/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17876/fi-icl-y/igt@i915_selftest@l...@execlists.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][7] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17876/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17876/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a:
- fi-tgl-y: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/fi-tgl-y/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17876/fi-tgl-y/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a.html
* igt@kms_pipe_crc_basic@read-crc-pipe-c:
- {fi-tgl-dsi}: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/fi-tgl-dsi/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17876/fi-tgl-dsi/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92]) ->
[DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95]) +5 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17876/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +4 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17876/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#1993]: https://gitlab.freedesktop.org/drm/intel/issues/1993
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (50 -> 44)
--
Additional (1): fi-kbl-7560u
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8585 -> Patchwork_17876
CI-20190529: 20190529
CI_DRM_8585: 3aef9a510cfe66ba71ed397e91c517402f7c26ac @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5695: 53e8c878a6fb5708e63c99403691e8960b86ea9c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17876:
Re: [Intel-gfx] [PATCH] drm/i915/dp: Reset link params on connector disconnect
On Thu, Jun 04, 2020 at 10:08:58PM +0300, Imre Deak wrote: > On Thu, Jun 04, 2020 at 10:01:40PM +0300, Ville Syrjälä wrote: > > [...] > > > > Then we get this hpd, in this case if we dont reset the param to max > > > > values, prev triggered modeset continues > > > > with fallback values but since connector probe doesnt happen again > > > > through IGT, it tries the same mode > > > > with fallback values and return encoder config failure. > > > > > > If the link training failed then clearly the sink didn't like us anymore > > > anyway. So feels like resetting these here is just shifting some race > > > window around a bit, but it could still fail if the sink still doesn't > > > like us. > > > > > > Would be good if someone was able to figure out why the sink goes bad in > > > the first place. > > > > Oh, and don't we now have Imre's "weird hpd happened in the middle of > > the test, don't trust the results" thing in igt? > > An LG and IIyama monitor this happens on disconnect and reconnect after > waking from an idle state when modesetting them, not sure if it's the > same case. Manasi, could you try if a modeset on the monitor after it has been disabled for a while always results in a long HPD pulse a few seconds after the modeset? If so does this also happen when you just modeset in a sequence from one mode to the other not letting the monitor idle? The same monitor should be also tested then with the above sequences on older platforms if it behaves the same on those too. > > --Imre > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Reset link params on connector disconnect
On Thu, Jun 04, 2020 at 10:08:58PM +0300, Imre Deak wrote: > On Thu, Jun 04, 2020 at 10:01:40PM +0300, Ville Syrjälä wrote: > > [...] > > > > Then we get this hpd, in this case if we dont reset the param to max > > > > values, prev triggered modeset continues > > > > with fallback values but since connector probe doesnt happen again > > > > through IGT, it tries the same mode > > > > with fallback values and return encoder config failure. > > > > > > If the link training failed then clearly the sink didn't like us anymore > > > anyway. So feels like resetting these here is just shifting some race > > > window around a bit, but it could still fail if the sink still doesn't > > > like us. > > > > > > Would be good if someone was able to figure out why the sink goes bad in > > > the first place. > > > > Oh, and don't we now have Imre's "weird hpd happened in the middle of > > the test, don't trust the results" thing in igt? > > An LG and IIyama monitor this happens on disconnect and reconnect after > waking from an idle state when modesetting them, not sure if it's the > same case. Well in this case, it happens just after link training failure due to some AUX timeouts then looks like the panel detects that the link was not enabled and sends this HPD which puts us into connector status changing from connected to disconnected. But in IGT, we dont get any uevent so we dont reprobe and continue with the next igt_display_commit. So should we in IGT in kms_atomic_transitions, plane-all-modeset-transitions subtest, should we check the connector status everytime before back to back commit calls? Like I think in real use case, after a link failure the userspace would get a uevent and respond to it by reprobing a connector, but we dont do that in IGT so these random link failures cause issues like in here. Manasi > > --Imre ___ 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: Initialize reserved and unspecified MOCS indices
== Series Details ==
Series: drm/i915/gt: Initialize reserved and unspecified MOCS indices
URL : https://patchwork.freedesktop.org/series/78012/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8585 -> Patchwork_17875
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17875/index.html
Known issues
Here are the changes found in Patchwork_17875 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-apl-guc: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/fi-apl-guc/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17875/fi-apl-guc/igt@i915_module_l...@reload.html
* igt@kms_frontbuffer_tracking@basic:
- fi-tgl-y: [PASS][3] -> [DMESG-FAIL][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17875/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17875/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
Possible fixes
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [DMESG-WARN][7] ([i915#95]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17875/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@execlists:
- fi-icl-y: [DMESG-FAIL][9] ([i915#1993]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/fi-icl-y/igt@i915_selftest@l...@execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17875/fi-icl-y/igt@i915_selftest@l...@execlists.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17875/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a:
- fi-tgl-y: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/fi-tgl-y/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17875/fi-tgl-y/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a.html
* igt@kms_pipe_crc_basic@read-crc-pipe-c:
- {fi-tgl-dsi}: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/fi-tgl-dsi/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17875/fi-tgl-dsi/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92]) ->
[DMESG-WARN][18] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17875/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) ->
[DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17875/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][22] ([i915#62] / [i915#92])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8585/fi-kbl-x1275/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17875/fi-kbl-x1275/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1897]:
Re: [Intel-gfx] [PATCH] drm/i915/dp: Reset link params on connector disconnect
On Thu, Jun 04, 2020 at 10:01:40PM +0300, Ville Syrjälä wrote: > [...] > > > Then we get this hpd, in this case if we dont reset the param to max > > > values, prev triggered modeset continues > > > with fallback values but since connector probe doesnt happen again > > > through IGT, it tries the same mode > > > with fallback values and return encoder config failure. > > > > If the link training failed then clearly the sink didn't like us anymore > > anyway. So feels like resetting these here is just shifting some race > > window around a bit, but it could still fail if the sink still doesn't > > like us. > > > > Would be good if someone was able to figure out why the sink goes bad in > > the first place. > > Oh, and don't we now have Imre's "weird hpd happened in the middle of > the test, don't trust the results" thing in igt? An LG and IIyama monitor this happens on disconnect and reconnect after waking from an idle state when modesetting them, not sure if it's the same case. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: DP PHY compliance for JSL
On Thu, Jun 04, 2020 at 10:33:48AM +0530, Vidya Srinivas wrote:
> Signed-off-by: Khaled Almahallawy
> Signed-off-by: Vidya Srinivas
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 40
> ++---
> 1 file changed, 32 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 7223367171d1..44663e8ac9a1 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5470,22 +5470,32 @@ intel_dp_autotest_phy_ddi_disable(struct intel_dp
> *intel_dp)
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct intel_crtc *crtc = to_intel_crtc(intel_dig_port->base.base.crtc);
> enum pipe pipe = crtc->pipe;
> - u32 trans_ddi_func_ctl_value, trans_conf_value, dp_tp_ctl_value;
> + u32 trans_ddi_func_ctl_value, trans_conf_value, dp_tp_ctl_value,
> trans_ddi_port_mask;
> + enum port port = intel_dig_port->base.port;
> + i915_reg_t dp_tp_reg;
> +
> + if (IS_ELKHARTLAKE(dev_priv)) {
> + dp_tp_reg = DP_TP_CTL(port);
> + trans_ddi_port_mask = TRANS_DDI_PORT_MASK;
> + } else if (IS_TIGERLAKE(dev_priv)) {
> + dp_tp_reg = TGL_DP_TP_CTL(pipe);
> + trans_ddi_port_mask = TGL_TRANS_DDI_PORT_MASK;
> + }
>
> trans_ddi_func_ctl_value = intel_de_read(dev_priv,
>TRANS_DDI_FUNC_CTL(pipe));
> trans_conf_value = intel_de_read(dev_priv, PIPECONF(pipe));
> - dp_tp_ctl_value = intel_de_read(dev_priv, TGL_DP_TP_CTL(pipe));
>
> + dp_tp_ctl_value = intel_de_read(dev_priv, dp_tp_reg);
> trans_ddi_func_ctl_value &= ~(TRANS_DDI_FUNC_ENABLE |
> - TGL_TRANS_DDI_PORT_MASK);
> + trans_ddi_port_mask);
> trans_conf_value &= ~PIPECONF_ENABLE;
> dp_tp_ctl_value &= ~DP_TP_CTL_ENABLE;
>
> intel_de_write(dev_priv, PIPECONF(pipe), trans_conf_value);
> intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(pipe),
> trans_ddi_func_ctl_value);
> - intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe), dp_tp_ctl_value);
> + intel_de_write(dev_priv, dp_tp_reg, dp_tp_ctl_value);
All this ad-hoc modeset code really should not exist. It's going to
have different bugs than the norma modeset paths, so compliance testing
this special code proves absolutely nothing about the normal modeset
code. IMO someone needs to take up the task of rewrtiting all this to
just perform normal modesets.
> }
>
> static void
> @@ -5497,20 +5507,28 @@ intel_dp_autotest_phy_ddi_enable(struct intel_dp
> *intel_dp, uint8_t lane_cnt)
> enum port port = intel_dig_port->base.port;
> struct intel_crtc *crtc = to_intel_crtc(intel_dig_port->base.base.crtc);
> enum pipe pipe = crtc->pipe;
> - u32 trans_ddi_func_ctl_value, trans_conf_value, dp_tp_ctl_value;
> + u32 trans_ddi_func_ctl_value, trans_conf_value, dp_tp_ctl_value,
> trans_ddi_sel_port;
> + i915_reg_t dp_tp_reg;
> +
> + if (IS_ELKHARTLAKE(dev_priv)) {
> + dp_tp_reg = DP_TP_CTL(port);
> + trans_ddi_sel_port = TRANS_DDI_SELECT_PORT(port);
> + } else if (IS_TIGERLAKE(dev_priv)) {
> + dp_tp_reg = TGL_DP_TP_CTL(pipe);
> + trans_ddi_sel_port = TGL_TRANS_DDI_SELECT_PORT(port);
> + }
>
> trans_ddi_func_ctl_value = intel_de_read(dev_priv,
>TRANS_DDI_FUNC_CTL(pipe));
> trans_conf_value = intel_de_read(dev_priv, PIPECONF(pipe));
> dp_tp_ctl_value = intel_de_read(dev_priv, TGL_DP_TP_CTL(pipe));
> -
> trans_ddi_func_ctl_value |= TRANS_DDI_FUNC_ENABLE |
> - TGL_TRANS_DDI_SELECT_PORT(port);
> + trans_ddi_sel_port;
> trans_conf_value |= PIPECONF_ENABLE;
> dp_tp_ctl_value |= DP_TP_CTL_ENABLE;
>
> intel_de_write(dev_priv, PIPECONF(pipe), trans_conf_value);
> - intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe), dp_tp_ctl_value);
> + intel_de_write(dev_priv, dp_tp_reg, dp_tp_ctl_value);
> intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(pipe),
> trans_ddi_func_ctl_value);
> }
> @@ -5557,6 +5575,7 @@ static u8 intel_dp_autotest_phy_pattern(struct intel_dp
> *intel_dp)
> static void intel_dp_handle_test_request(struct intel_dp *intel_dp)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + struct drm_i915_private *dev_priv = i915;
> u8 response = DP_TEST_NAK;
> u8 request = 0;
> int status;
> @@ -5582,6 +5601,11 @@ static void intel_dp_handle_test_request(struct
> intel_dp *intel_dp)
> response = intel_dp_autotest_edid(intel_dp);
> break;
> case DP_TEST_LINK_PHY_TEST_PATTERN:
> + if (!IS_ELKHARTLAKE(dev_priv) || !IS_TIGERLAKE(dev_priv)) {
> +
Re: [Intel-gfx] [PATCH] drm/i915/dp: Reset link params on connector disconnect
On Thu, Jun 04, 2020 at 09:58:24PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 04, 2020 at 11:52:24AM -0700, Manasi Navare wrote:
> > On Thu, Jun 04, 2020 at 09:38:19PM +0300, Ville Syrjälä wrote:
> > > On Thu, Jun 04, 2020 at 11:35:30AM -0700, Manasi Navare wrote:
> > > > On Thu, Jun 04, 2020 at 06:25:43PM +0300, Ville Syrjälä wrote:
> > > > > On Wed, Jun 03, 2020 at 05:23:59PM -0700, Manasi Navare wrote:
> > > > > > We have noticed that when link training fails the panel
> > > > > > sends a long pulse indicating connector disconnect. In this case
> > > > > > we need to reset the link parameters instead of continuing
> > > > > > to use the fallback parameters since else this long pulse
> > > > > > by the panel followed by a modeset request which was triggered by
> > > > > > the userspace
> > > > > > before getting the connector status as disconnected, will
> > > > > > result into a modeset now using lower link rate/lane count values.
> > > > > >
> > > > > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1385
> > > > > > Cc: Jani Nikula
> > > > > > Cc: Ville Syrjälä
> > > > > > Signed-off-by: Manasi Navare
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/display/intel_dp.c | 28
> > > > > > +
> > > > > > 1 file changed, 19 insertions(+), 9 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > > index 55fda074c0ad..f7af372647dd 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > > @@ -6111,6 +6111,18 @@ intel_dp_unset_edid(struct intel_dp
> > > > > > *intel_dp)
> > > > > > intel_dp->edid_quirks = 0;
> > > > > > }
> > > > > >
> > > > > > +static void
> > > > > > +intel_dp_reset_link_params(struct intel_dp *intel_dp)
> > > > > > +{
> > > > > > + /* Initial max link lane count */
> > > > > > + intel_dp->max_link_lane_count =
> > > > > > intel_dp_max_common_lane_count(intel_dp);
> > > > > > +
> > > > > > + /* Initial max link rate */
> > > > > > + intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> > > > > > +
> > > > > > + intel_dp->reset_link_params = false;
> > > > > > +}
> > > > > > +
> > > > > > static int
> > > > > > intel_dp_detect(struct drm_connector *connector,
> > > > > > struct drm_modeset_acquire_ctx *ctx,
> > > > > > @@ -6139,6 +6151,11 @@ intel_dp_detect(struct drm_connector
> > > > > > *connector,
> > > > > > memset(_dp->compliance, 0,
> > > > > > sizeof(intel_dp->compliance));
> > > > > > memset(intel_dp->dsc_dpcd, 0,
> > > > > > sizeof(intel_dp->dsc_dpcd));
> > > > > >
> > > > > > + /*Reset the immutable VRR Capable property */
> > > > > > + drm_connector_set_vrr_capable_property(connector,
> > > > > > + false);
> > > > > > + intel_dp_reset_link_params(intel_dp);
> > > > > > +
> > > > >
> > > > > Why would we care what those are when the sink is disconnected?
> > > >
> > > > We are noticing this happen in case the panel send this long pulse
> > > > indicating
> > > > status change to disconnected, while the modeset was already triggered
> > > > by userspace
> > > > in this case IGT, so the modeset continues right after
> > > > i915_hotplug_work_fn
> > > > so we need to reset all params which fixes the bug mentioned.
> > >
> > > Why did the link params get out of whack before hpd in the first place?
> > >
> >
> > Most of the failures, we see the link training fails due to AUX timeouts
> > and then link params fallback to lower values
> > Then we get this hpd, in this case if we dont reset the param to max
> > values, prev triggered modeset continues
> > with fallback values but since connector probe doesnt happen again through
> > IGT, it tries the same mode
> > with fallback values and return encoder config failure.
>
> If the link training failed then clearly the sink didn't like us anymore
> anyway. So feels like resetting these here is just shifting some race
> window around a bit, but it could still fail if the sink still doesn't
> like us.
>
> Would be good if someone was able to figure out why the sink goes bad in
> the first place.
Oh, and don't we now have Imre's "weird hpd happened in the middle of
the test, don't trust the results" thing in igt?
>
> >
> > So after reseting the params, the modeset happens with original values and
> > that time link training passes.
> > This is seen in all kms_atomic_transitions IGT tests
> >
> > Manasi
> >
> > > >
> > > > Manasi
> > > >
> > > > >
> > > > > > if (intel_dp->is_mst) {
> > > > > > drm_dbg_kms(_priv->drm,
> > > > > > "MST device may have disappeared %d
> > > > > > vs %d\n",
> > > > > > @@ -6152,15 +6169,8 @@ intel_dp_detect(struct drm_connector
> > > > > > *connector,
> > > > > >
Re: [Intel-gfx] [PATCH 53/59] drm/arc: Move to drm/tiny
I've tested your change and one issue gone. However I still see kernel crash (due to invalid read in kernel mode by 0x0 address) on weston stop: --->8--- Oops Path: (null) CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.7.0-rc6-01594-g4ceda91a4176-dirty #6 Workqueue: events drm_mode_rmfb_work_fn Invalid Read @ 0x by insn @ drm_gem_fb_destroy+0x32/0x130 ECR: 0x00050100 EFA: 0x ERET: 0x813b9a76 STAT32: 0x80080602 [IE K ] BTA: 0x813b9a72 BLK: drm_gem_fb_destroy+0xc0/0x130 SP: 0x9f055ea4 FP: 0x LPS: 0x813560ec LPE: 0x813560f0 LPC: 0x r00: 0x r01: 0x9f6a6100 r02: 0x0001 r03: 0x9fd5dde8 r04: 0x810f5de8 r05: 0x r06: 0x r07: 0x r08: 0x00e1 r09: 0x r10: 0x r11: 0x00e1 r12: 0x813b9b04 Stack Trace: drm_gem_fb_destroy+0x32/0x130 drm_framebuffer_remove+0x1d2/0x358 drm_mode_rmfb_work_fn+0x28/0x38 process_one_work+0x19a/0x358 worker_thread+0x2c4/0x494 kthread+0xec/0x100 ret_from_fork+0x18/0x1c --->8--- The stack traces may vary but always end in drm_gem_fb_destroy: --->8--- Stack Trace: drm_gem_fb_destroy+0x32/0x130 drm_mode_rmfb+0x10e/0x148 drm_ioctl_kernel+0x70/0xa0 drm_ioctl+0x284/0x410 ksys_ioctl+0xea/0xa3c EV_Trap+0xcc/0xd0 --->8--- Stack Trace: drm_gem_fb_destroy+0x32/0x130 drm_fb_release+0x66/0xb0 drm_file_free.part.11+0x112/0x1bc drm_release+0x80/0x120 __fput+0x98/0x1bc task_work_run+0x6e/0xa8 do_exit+0x2b4/0x7fc do_group_exit+0x2a/0x8c get_signal+0x9a/0x5f0 do_signal+0x86/0x23c resume_user_mode_begin+0x88/0xd0 --->8--- --- Eugeniy Paltsev From: Daniel Vetter Sent: Thursday, June 4, 2020 14:19 To: Eugeniy Paltsev Cc: Intel Graphics Development; DRI Development; Daniel Vetter; Sam Ravnborg; Alexey Brodkin Subject: Re: [PATCH 53/59] drm/arc: Move to drm/tiny Hi Eugeniy, Apologies, somehow I missed your mail. I looked at the code again, and I think I fumbled something. Does the below diff help to prevent the issues? Thanks, Daniel diff --git a/drivers/gpu/drm/tiny/arcpgu.c b/drivers/gpu/drm/tiny/arcpgu.c index 857812f25bec..33d812a5ad7f 100644 --- a/drivers/gpu/drm/tiny/arcpgu.c +++ b/drivers/gpu/drm/tiny/arcpgu.c @@ -228,6 +228,9 @@ static void arc_pgu_update(struct drm_simple_display_pipe *pipe, struct arcpgu_drm_private *arcpgu; struct drm_gem_cma_object *gem; + if (!pipe->plane.state->fb) + return; + arcpgu = pipe_to_arcpgu_priv(pipe); gem = drm_fb_cma_get_gem_obj(pipe->plane.state->fb, 0); arc_pgu_write(arcpgu, ARCPGU_REG_BUF0_ADDR, gem->paddr); -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - https://urldefense.com/v3/__http://blog.ffwll.ch__;!!A4F2R9G_pg!P0EvyJfMuDwqbeZmHZM5S9po30QWr4KgGrggRirNfgo7wrRXfnUO-8iq0AA4fQCW2WGPlDc$ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Reset link params on connector disconnect
On Thu, Jun 04, 2020 at 11:52:24AM -0700, Manasi Navare wrote:
> On Thu, Jun 04, 2020 at 09:38:19PM +0300, Ville Syrjälä wrote:
> > On Thu, Jun 04, 2020 at 11:35:30AM -0700, Manasi Navare wrote:
> > > On Thu, Jun 04, 2020 at 06:25:43PM +0300, Ville Syrjälä wrote:
> > > > On Wed, Jun 03, 2020 at 05:23:59PM -0700, Manasi Navare wrote:
> > > > > We have noticed that when link training fails the panel
> > > > > sends a long pulse indicating connector disconnect. In this case
> > > > > we need to reset the link parameters instead of continuing
> > > > > to use the fallback parameters since else this long pulse
> > > > > by the panel followed by a modeset request which was triggered by the
> > > > > userspace
> > > > > before getting the connector status as disconnected, will
> > > > > result into a modeset now using lower link rate/lane count values.
> > > > >
> > > > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1385
> > > > > Cc: Jani Nikula
> > > > > Cc: Ville Syrjälä
> > > > > Signed-off-by: Manasi Navare
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_dp.c | 28
> > > > > +
> > > > > 1 file changed, 19 insertions(+), 9 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > index 55fda074c0ad..f7af372647dd 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > @@ -6111,6 +6111,18 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
> > > > > intel_dp->edid_quirks = 0;
> > > > > }
> > > > >
> > > > > +static void
> > > > > +intel_dp_reset_link_params(struct intel_dp *intel_dp)
> > > > > +{
> > > > > + /* Initial max link lane count */
> > > > > + intel_dp->max_link_lane_count =
> > > > > intel_dp_max_common_lane_count(intel_dp);
> > > > > +
> > > > > + /* Initial max link rate */
> > > > > + intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> > > > > +
> > > > > + intel_dp->reset_link_params = false;
> > > > > +}
> > > > > +
> > > > > static int
> > > > > intel_dp_detect(struct drm_connector *connector,
> > > > > struct drm_modeset_acquire_ctx *ctx,
> > > > > @@ -6139,6 +6151,11 @@ intel_dp_detect(struct drm_connector
> > > > > *connector,
> > > > > memset(_dp->compliance, 0,
> > > > > sizeof(intel_dp->compliance));
> > > > > memset(intel_dp->dsc_dpcd, 0,
> > > > > sizeof(intel_dp->dsc_dpcd));
> > > > >
> > > > > + /*Reset the immutable VRR Capable property */
> > > > > + drm_connector_set_vrr_capable_property(connector,
> > > > > +false);
> > > > > + intel_dp_reset_link_params(intel_dp);
> > > > > +
> > > >
> > > > Why would we care what those are when the sink is disconnected?
> > >
> > > We are noticing this happen in case the panel send this long pulse
> > > indicating
> > > status change to disconnected, while the modeset was already triggered by
> > > userspace
> > > in this case IGT, so the modeset continues right after
> > > i915_hotplug_work_fn
> > > so we need to reset all params which fixes the bug mentioned.
> >
> > Why did the link params get out of whack before hpd in the first place?
> >
>
> Most of the failures, we see the link training fails due to AUX timeouts and
> then link params fallback to lower values
> Then we get this hpd, in this case if we dont reset the param to max values,
> prev triggered modeset continues
> with fallback values but since connector probe doesnt happen again through
> IGT, it tries the same mode
> with fallback values and return encoder config failure.
If the link training failed then clearly the sink didn't like us anymore
anyway. So feels like resetting these here is just shifting some race
window around a bit, but it could still fail if the sink still doesn't
like us.
Would be good if someone was able to figure out why the sink goes bad in
the first place.
>
> So after reseting the params, the modeset happens with original values and
> that time link training passes.
> This is seen in all kms_atomic_transitions IGT tests
>
> Manasi
>
> > >
> > > Manasi
> > >
> > > >
> > > > > if (intel_dp->is_mst) {
> > > > > drm_dbg_kms(_priv->drm,
> > > > > "MST device may have disappeared %d
> > > > > vs %d\n",
> > > > > @@ -6152,15 +6169,8 @@ intel_dp_detect(struct drm_connector
> > > > > *connector,
> > > > > goto out;
> > > > > }
> > > > >
> > > > > - if (intel_dp->reset_link_params) {
> > > > > - /* Initial max link lane count */
> > > > > - intel_dp->max_link_lane_count =
> > > > > intel_dp_max_common_lane_count(intel_dp);
> > > > > -
> > > > > - /* Initial max link rate */
> > > > > - intel_dp->max_link_rate
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915/dp_mst: Work around out-of-spec adapters filtering short pulses
On Thu, Jun 04, 2020 at 09:45:00PM +0300, Imre Deak wrote:
> Some TypeC -> native DP adapters, at least the Club 3D CAC-1557 adapter,
> incorrectly filter out HPD short pulses with a duration less than
> ~540 usec, leading to MST probe failures.
>
> According to the DP Standard 2.0 section 5.1.4:
> - DP sinks should generate short pulses in the 500 usec -> 1 msec range
> - DP sources should detect short pulses in the 250 usec -> 2 msec range
>
> According to the DP Alt Mode on TypeC Standard section 3.9.2, adapters
> should detect and forward short pulses according to how sources should
> detect them as specified in the DP Standard (250 usec -> 2 msec).
>
> Based on the above filtering out short pulses with a duration less than
> 540 usec is incorrect.
>
> To make such adapters work add support for a driver polling on MST
> inerrupt flags, and wire this up in the i915 driver. The sink can clear
> an interrupt it raised after 110 msec if the source doesn't respond, so
> use a 50 msec poll period to avoid missing an interrupt. Polling of the
> MST interrupt flags is explicitly allowed by the DP Standard.
>
> This fixes MST probe failures I saw using this adapter and a DELL U2515H
> monitor.
>
> v2:
> - Fix the wait event timeout for the no-poll case.
> v3 (Ville):
> - Fix the short pulse duration limits in the commit log prescribed by the
> DP Standard.
> - Add code comment explaining why/how polling is used.
> - Factor out a helper to schedule the port's hpd irq handler and move it
> to the rest of hotplug handlers.
> - Document the new MST callback.
> - s/update_hpd_irq_state/poll_hpd_irq/
>
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
lgtm
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c| 32 ++--
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 10 ++
> drivers/gpu/drm/i915/display/intel_hotplug.c | 18 +++
> drivers/gpu/drm/i915/display/intel_hotplug.h | 2 ++
> include/drm/drm_dp_mst_helper.h | 9 ++
> 5 files changed, 68 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 5bc72e800b85..2a309fb2c4cc 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1178,11 +1178,37 @@ static int drm_dp_mst_wait_tx_reply(struct
> drm_dp_mst_branch *mstb,
> struct drm_dp_sideband_msg_tx *txmsg)
> {
> struct drm_dp_mst_topology_mgr *mgr = mstb->mgr;
> + unsigned long wait_timeout = msecs_to_jiffies(4000);
> + unsigned long wait_expires = jiffies + wait_timeout;
> int ret;
>
> - ret = wait_event_timeout(mgr->tx_waitq,
> - check_txmsg_state(mgr, txmsg),
> - (4 * HZ));
> + for (;;) {
> + /*
> + * If the driver provides a way for this, change to
> + * poll-waiting for the MST reply interrupt if we didn't receive
> + * it for 50 msec. This would cater for cases where the HPD
> + * pulse signal got lost somewhere, even though the sink raised
> + * the corresponding MST interrupt correctly. One example is the
> + * Club 3D CAC-1557 TypeC -> DP adapter which for some reason
> + * filters out short pulses with a duration less than ~540 usec.
> + *
> + * The poll period is 50 msec to avoid missing an interrupt
> + * after the sink has cleared it (after a 110msec timeout
> + * since it raised the interrupt).
> + */
> + ret = wait_event_timeout(mgr->tx_waitq,
> + check_txmsg_state(mgr, txmsg),
> + mgr->cbs->poll_hpd_irq ?
> + msecs_to_jiffies(50) :
> + wait_timeout);
> +
> + if (ret || !mgr->cbs->poll_hpd_irq ||
> + time_after(jiffies, wait_expires))
> + break;
> +
> + mgr->cbs->poll_hpd_irq(mgr);
> + }
> +
> mutex_lock(>qlock);
> if (ret > 0) {
> if (txmsg->state == DRM_DP_SIDEBAND_TX_TIMEOUT) {
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index d18b406f2a7d..9be52643205d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -33,6 +33,7 @@
> #include "intel_connector.h"
> #include "intel_ddi.h"
> #include "intel_display_types.h"
> +#include "intel_hotplug.h"
> #include "intel_dp.h"
> #include "intel_dp_mst.h"
> #include "intel_dpio_phy.h"
> @@ -765,8 +766,17 @@ static struct drm_connector
> *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
> return NULL;
> }
>
> +static void
> +intel_dp_mst_poll_hpd_irq(struct
Re: [Intel-gfx] [PATCH] drm/i915/dp: Reset link params on connector disconnect
On Thu, Jun 04, 2020 at 09:38:19PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 04, 2020 at 11:35:30AM -0700, Manasi Navare wrote:
> > On Thu, Jun 04, 2020 at 06:25:43PM +0300, Ville Syrjälä wrote:
> > > On Wed, Jun 03, 2020 at 05:23:59PM -0700, Manasi Navare wrote:
> > > > We have noticed that when link training fails the panel
> > > > sends a long pulse indicating connector disconnect. In this case
> > > > we need to reset the link parameters instead of continuing
> > > > to use the fallback parameters since else this long pulse
> > > > by the panel followed by a modeset request which was triggered by the
> > > > userspace
> > > > before getting the connector status as disconnected, will
> > > > result into a modeset now using lower link rate/lane count values.
> > > >
> > > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1385
> > > > Cc: Jani Nikula
> > > > Cc: Ville Syrjälä
> > > > Signed-off-by: Manasi Navare
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_dp.c | 28 +
> > > > 1 file changed, 19 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > index 55fda074c0ad..f7af372647dd 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > @@ -6111,6 +6111,18 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
> > > > intel_dp->edid_quirks = 0;
> > > > }
> > > >
> > > > +static void
> > > > +intel_dp_reset_link_params(struct intel_dp *intel_dp)
> > > > +{
> > > > + /* Initial max link lane count */
> > > > + intel_dp->max_link_lane_count =
> > > > intel_dp_max_common_lane_count(intel_dp);
> > > > +
> > > > + /* Initial max link rate */
> > > > + intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> > > > +
> > > > + intel_dp->reset_link_params = false;
> > > > +}
> > > > +
> > > > static int
> > > > intel_dp_detect(struct drm_connector *connector,
> > > > struct drm_modeset_acquire_ctx *ctx,
> > > > @@ -6139,6 +6151,11 @@ intel_dp_detect(struct drm_connector *connector,
> > > > memset(_dp->compliance, 0,
> > > > sizeof(intel_dp->compliance));
> > > > memset(intel_dp->dsc_dpcd, 0,
> > > > sizeof(intel_dp->dsc_dpcd));
> > > >
> > > > + /*Reset the immutable VRR Capable property */
> > > > + drm_connector_set_vrr_capable_property(connector,
> > > > + false);
> > > > + intel_dp_reset_link_params(intel_dp);
> > > > +
> > >
> > > Why would we care what those are when the sink is disconnected?
> >
> > We are noticing this happen in case the panel send this long pulse
> > indicating
> > status change to disconnected, while the modeset was already triggered by
> > userspace
> > in this case IGT, so the modeset continues right after i915_hotplug_work_fn
> > so we need to reset all params which fixes the bug mentioned.
>
> Why did the link params get out of whack before hpd in the first place?
>
Most of the failures, we see the link training fails due to AUX timeouts and
then link params fallback to lower values
Then we get this hpd, in this case if we dont reset the param to max values,
prev triggered modeset continues
with fallback values but since connector probe doesnt happen again through IGT,
it tries the same mode
with fallback values and return encoder config failure.
So after reseting the params, the modeset happens with original values and that
time link training passes.
This is seen in all kms_atomic_transitions IGT tests
Manasi
> >
> > Manasi
> >
> > >
> > > > if (intel_dp->is_mst) {
> > > > drm_dbg_kms(_priv->drm,
> > > > "MST device may have disappeared %d
> > > > vs %d\n",
> > > > @@ -6152,15 +6169,8 @@ intel_dp_detect(struct drm_connector *connector,
> > > > goto out;
> > > > }
> > > >
> > > > - if (intel_dp->reset_link_params) {
> > > > - /* Initial max link lane count */
> > > > - intel_dp->max_link_lane_count =
> > > > intel_dp_max_common_lane_count(intel_dp);
> > > > -
> > > > - /* Initial max link rate */
> > > > - intel_dp->max_link_rate =
> > > > intel_dp_max_common_rate(intel_dp);
> > > > -
> > > > - intel_dp->reset_link_params = false;
> > > > - }
> > > > + if (intel_dp->reset_link_params)
> > > > + intel_dp_reset_link_params(intel_dp);
> > > >
> > > > intel_dp_print_rates(intel_dp);
> > > >
> > > > --
> > > > 2.19.1
> > >
> > > --
> > > Ville Syrjälä
> > > Intel
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] [PATCH] drm/i915/dp: Reset link params on connector disconnect
On Thu, Jun 04, 2020 at 11:35:30AM -0700, Manasi Navare wrote:
> On Thu, Jun 04, 2020 at 06:25:43PM +0300, Ville Syrjälä wrote:
> > On Wed, Jun 03, 2020 at 05:23:59PM -0700, Manasi Navare wrote:
> > > We have noticed that when link training fails the panel
> > > sends a long pulse indicating connector disconnect. In this case
> > > we need to reset the link parameters instead of continuing
> > > to use the fallback parameters since else this long pulse
> > > by the panel followed by a modeset request which was triggered by the
> > > userspace
> > > before getting the connector status as disconnected, will
> > > result into a modeset now using lower link rate/lane count values.
> > >
> > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1385
> > > Cc: Jani Nikula
> > > Cc: Ville Syrjälä
> > > Signed-off-by: Manasi Navare
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp.c | 28 +
> > > 1 file changed, 19 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 55fda074c0ad..f7af372647dd 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -6111,6 +6111,18 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
> > > intel_dp->edid_quirks = 0;
> > > }
> > >
> > > +static void
> > > +intel_dp_reset_link_params(struct intel_dp *intel_dp)
> > > +{
> > > + /* Initial max link lane count */
> > > + intel_dp->max_link_lane_count =
> > > intel_dp_max_common_lane_count(intel_dp);
> > > +
> > > + /* Initial max link rate */
> > > + intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> > > +
> > > + intel_dp->reset_link_params = false;
> > > +}
> > > +
> > > static int
> > > intel_dp_detect(struct drm_connector *connector,
> > > struct drm_modeset_acquire_ctx *ctx,
> > > @@ -6139,6 +6151,11 @@ intel_dp_detect(struct drm_connector *connector,
> > > memset(_dp->compliance, 0, sizeof(intel_dp->compliance));
> > > memset(intel_dp->dsc_dpcd, 0, sizeof(intel_dp->dsc_dpcd));
> > >
> > > + /*Reset the immutable VRR Capable property */
> > > + drm_connector_set_vrr_capable_property(connector,
> > > +false);
> > > + intel_dp_reset_link_params(intel_dp);
> > > +
> >
> > Why would we care what those are when the sink is disconnected?
>
> We are noticing this happen in case the panel send this long pulse indicating
> status change to disconnected, while the modeset was already triggered by
> userspace
> in this case IGT, so the modeset continues right after i915_hotplug_work_fn
> so we need to reset all params which fixes the bug mentioned.
Why did the link params get out of whack before hpd in the first place?
>
> Manasi
>
> >
> > > if (intel_dp->is_mst) {
> > > drm_dbg_kms(_priv->drm,
> > > "MST device may have disappeared %d vs
> > > %d\n",
> > > @@ -6152,15 +6169,8 @@ intel_dp_detect(struct drm_connector *connector,
> > > goto out;
> > > }
> > >
> > > - if (intel_dp->reset_link_params) {
> > > - /* Initial max link lane count */
> > > - intel_dp->max_link_lane_count =
> > > intel_dp_max_common_lane_count(intel_dp);
> > > -
> > > - /* Initial max link rate */
> > > - intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> > > -
> > > - intel_dp->reset_link_params = false;
> > > - }
> > > + if (intel_dp->reset_link_params)
> > > + intel_dp_reset_link_params(intel_dp);
> > >
> > > intel_dp_print_rates(intel_dp);
> > >
> > > --
> > > 2.19.1
> >
> > --
> > Ville Syrjälä
> > Intel
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 3/3] drm/i915/dp_mst: Work around out-of-spec adapters filtering short pulses
Some TypeC -> native DP adapters, at least the Club 3D CAC-1557 adapter,
incorrectly filter out HPD short pulses with a duration less than
~540 usec, leading to MST probe failures.
According to the DP Standard 2.0 section 5.1.4:
- DP sinks should generate short pulses in the 500 usec -> 1 msec range
- DP sources should detect short pulses in the 250 usec -> 2 msec range
According to the DP Alt Mode on TypeC Standard section 3.9.2, adapters
should detect and forward short pulses according to how sources should
detect them as specified in the DP Standard (250 usec -> 2 msec).
Based on the above filtering out short pulses with a duration less than
540 usec is incorrect.
To make such adapters work add support for a driver polling on MST
inerrupt flags, and wire this up in the i915 driver. The sink can clear
an interrupt it raised after 110 msec if the source doesn't respond, so
use a 50 msec poll period to avoid missing an interrupt. Polling of the
MST interrupt flags is explicitly allowed by the DP Standard.
This fixes MST probe failures I saw using this adapter and a DELL U2515H
monitor.
v2:
- Fix the wait event timeout for the no-poll case.
v3 (Ville):
- Fix the short pulse duration limits in the commit log prescribed by the
DP Standard.
- Add code comment explaining why/how polling is used.
- Factor out a helper to schedule the port's hpd irq handler and move it
to the rest of hotplug handlers.
- Document the new MST callback.
- s/update_hpd_irq_state/poll_hpd_irq/
Cc: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_dp_mst_topology.c| 32 ++--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 10 ++
drivers/gpu/drm/i915/display/intel_hotplug.c | 18 +++
drivers/gpu/drm/i915/display/intel_hotplug.h | 2 ++
include/drm/drm_dp_mst_helper.h | 9 ++
5 files changed, 68 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 5bc72e800b85..2a309fb2c4cc 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1178,11 +1178,37 @@ static int drm_dp_mst_wait_tx_reply(struct
drm_dp_mst_branch *mstb,
struct drm_dp_sideband_msg_tx *txmsg)
{
struct drm_dp_mst_topology_mgr *mgr = mstb->mgr;
+ unsigned long wait_timeout = msecs_to_jiffies(4000);
+ unsigned long wait_expires = jiffies + wait_timeout;
int ret;
- ret = wait_event_timeout(mgr->tx_waitq,
-check_txmsg_state(mgr, txmsg),
-(4 * HZ));
+ for (;;) {
+ /*
+* If the driver provides a way for this, change to
+* poll-waiting for the MST reply interrupt if we didn't receive
+* it for 50 msec. This would cater for cases where the HPD
+* pulse signal got lost somewhere, even though the sink raised
+* the corresponding MST interrupt correctly. One example is the
+* Club 3D CAC-1557 TypeC -> DP adapter which for some reason
+* filters out short pulses with a duration less than ~540 usec.
+*
+* The poll period is 50 msec to avoid missing an interrupt
+* after the sink has cleared it (after a 110msec timeout
+* since it raised the interrupt).
+*/
+ ret = wait_event_timeout(mgr->tx_waitq,
+check_txmsg_state(mgr, txmsg),
+mgr->cbs->poll_hpd_irq ?
+ msecs_to_jiffies(50) :
+ wait_timeout);
+
+ if (ret || !mgr->cbs->poll_hpd_irq ||
+ time_after(jiffies, wait_expires))
+ break;
+
+ mgr->cbs->poll_hpd_irq(mgr);
+ }
+
mutex_lock(>qlock);
if (ret > 0) {
if (txmsg->state == DRM_DP_SIDEBAND_TX_TIMEOUT) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index d18b406f2a7d..9be52643205d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -33,6 +33,7 @@
#include "intel_connector.h"
#include "intel_ddi.h"
#include "intel_display_types.h"
+#include "intel_hotplug.h"
#include "intel_dp.h"
#include "intel_dp_mst.h"
#include "intel_dpio_phy.h"
@@ -765,8 +766,17 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
return NULL;
}
+static void
+intel_dp_mst_poll_hpd_irq(struct drm_dp_mst_topology_mgr *mgr)
+{
+ struct intel_dp *intel_dp = container_of(mgr, struct intel_dp, mst_mgr);
+
+ intel_hpd_trigger_irq(dp_to_dig_port(intel_dp));
+}
+
static const struct drm_dp_mst_topology_cbs mst_cbs = {
[Intel-gfx] [PATCH v2 1/3] drm/i915/dp_mst: Fix disabling MST on a port
Currently MST on a port can get enabled/disabled from the hotplug work
and get disabled from the short pulse work in a racy way. Fix this by
relying on the MST state checking in the hotplug work and just schedule
a hotplug work from the short pulse handler if some problem happened
during the MST interrupt handling.
This removes the explicit MST disabling in case of an AUX failure, but
if AUX fails, then probably the detection will also fail during the
scheduled hotplug work and it's not guaranteed that we'll see
intermittent errors anyway.
While at it also simplify the error checking of the MST interrupt
handler.
v2:
- Convert intel_dp_check_mst_status() to return bool. (Ville)
- Change the intel_dp->is_mst check to an assert, since after this patch
the condition can't change after we checked it previously.
- Document the return value from intel_dp_check_mst_status().
Cc: José Roberto de Souza
Cc: Ville Syrjälä
Reviewed-by: José Roberto de Souza (v1)
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 67 ++---
1 file changed, 27 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 55fda074c0ad..4b6e7cf577dd 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5556,35 +5556,47 @@ static void intel_dp_handle_test_request(struct
intel_dp *intel_dp)
"Could not write test response to sink\n");
}
-static int
+/**
+ * intel_dp_check_mst_status - service any pending MST interrupts, check link
status
+ * @intel_dp: Intel DP struct
+ *
+ * Read any pending MST interrupts, call MST core to handle these and ack the
+ * interrupts. Check if the main and AUX link state is ok.
+ *
+ * Returns:
+ * - %true if pending interrupts were serviced (or no interrupts were
+ * pending) w/o detecting an error condition.
+ * - %false if an error condition - like AUX failure or a loss of link - is
+ * detected, which needs servicing from the hotplug work.
+ */
+static bool
intel_dp_check_mst_status(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
- bool need_retrain = false;
-
- if (!intel_dp->is_mst)
- return -EINVAL;
+ bool link_ok = true;
+ drm_WARN_ON_ONCE(>drm, !intel_dp->is_mst);
drm_WARN_ON_ONCE(>drm, intel_dp->active_mst_links < 0);
for (;;) {
u8 esi[DP_DPRX_ESI_LEN] = {};
- bool bret, handled;
+ bool handled;
int retry;
- bret = intel_dp_get_sink_irq_esi(intel_dp, esi);
- if (!bret) {
+ if (!intel_dp_get_sink_irq_esi(intel_dp, esi)) {
drm_dbg_kms(>drm,
"failed to get ESI - device may have
failed\n");
- return -EINVAL;
+ link_ok = false;
+
+ break;
}
/* check link status - esi[10] = 0x200c */
- if (intel_dp->active_mst_links > 0 && !need_retrain &&
+ if (intel_dp->active_mst_links > 0 && link_ok &&
!drm_dp_channel_eq_ok([10], intel_dp->lane_count)) {
drm_dbg_kms(>drm,
"channel EQ not ok, retraining\n");
- need_retrain = true;
+ link_ok = false;
}
drm_dbg_kms(>drm, "got esi %3ph\n", esi);
@@ -5604,7 +5616,7 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
}
}
- return need_retrain;
+ return link_ok;
}
static bool
@@ -7255,35 +7267,10 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
}
if (intel_dp->is_mst) {
- switch (intel_dp_check_mst_status(intel_dp)) {
- case -EINVAL:
- /*
-* If we were in MST mode, and device is not
-* there, get out of MST mode
-*/
- drm_dbg_kms(>drm,
- "MST device may have disappeared %d vs
%d\n",
- intel_dp->is_mst,
- intel_dp->mst_mgr.mst_state);
- intel_dp->is_mst = false;
- drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
- intel_dp->is_mst);
-
- return IRQ_NONE;
- case 1:
- return IRQ_NONE;
- default:
- break;
- }
- }
-
- if (!intel_dp->is_mst) {
- bool handled;
-
- handled = intel_dp_short_pulse(intel_dp);
-
- if (!handled)
+ if
Re: [Intel-gfx] [PATCH] drm/i915/dp: Reset link params on connector disconnect
On Thu, Jun 04, 2020 at 06:25:43PM +0300, Ville Syrjälä wrote:
> On Wed, Jun 03, 2020 at 05:23:59PM -0700, Manasi Navare wrote:
> > We have noticed that when link training fails the panel
> > sends a long pulse indicating connector disconnect. In this case
> > we need to reset the link parameters instead of continuing
> > to use the fallback parameters since else this long pulse
> > by the panel followed by a modeset request which was triggered by the
> > userspace
> > before getting the connector status as disconnected, will
> > result into a modeset now using lower link rate/lane count values.
> >
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1385
> > Cc: Jani Nikula
> > Cc: Ville Syrjälä
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 28 +
> > 1 file changed, 19 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 55fda074c0ad..f7af372647dd 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -6111,6 +6111,18 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
> > intel_dp->edid_quirks = 0;
> > }
> >
> > +static void
> > +intel_dp_reset_link_params(struct intel_dp *intel_dp)
> > +{
> > + /* Initial max link lane count */
> > + intel_dp->max_link_lane_count =
> > intel_dp_max_common_lane_count(intel_dp);
> > +
> > + /* Initial max link rate */
> > + intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> > +
> > + intel_dp->reset_link_params = false;
> > +}
> > +
> > static int
> > intel_dp_detect(struct drm_connector *connector,
> > struct drm_modeset_acquire_ctx *ctx,
> > @@ -6139,6 +6151,11 @@ intel_dp_detect(struct drm_connector *connector,
> > memset(_dp->compliance, 0, sizeof(intel_dp->compliance));
> > memset(intel_dp->dsc_dpcd, 0, sizeof(intel_dp->dsc_dpcd));
> >
> > + /*Reset the immutable VRR Capable property */
> > + drm_connector_set_vrr_capable_property(connector,
> > + false);
> > + intel_dp_reset_link_params(intel_dp);
> > +
>
> Why would we care what those are when the sink is disconnected?
We are noticing this happen in case the panel send this long pulse indicating
status change to disconnected, while the modeset was already triggered by
userspace
in this case IGT, so the modeset continues right after i915_hotplug_work_fn
so we need to reset all params which fixes the bug mentioned.
Manasi
>
> > if (intel_dp->is_mst) {
> > drm_dbg_kms(_priv->drm,
> > "MST device may have disappeared %d vs
> > %d\n",
> > @@ -6152,15 +6169,8 @@ intel_dp_detect(struct drm_connector *connector,
> > goto out;
> > }
> >
> > - if (intel_dp->reset_link_params) {
> > - /* Initial max link lane count */
> > - intel_dp->max_link_lane_count =
> > intel_dp_max_common_lane_count(intel_dp);
> > -
> > - /* Initial max link rate */
> > - intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> > -
> > - intel_dp->reset_link_params = false;
> > - }
> > + if (intel_dp->reset_link_params)
> > + intel_dp_reset_link_params(intel_dp);
> >
> > intel_dp_print_rates(intel_dp);
> >
> > --
> > 2.19.1
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 03/15] drm/i915/rkl: RKL has no MBUS_ABOX_CTL{1, 2}
On Wed, Jun 03, 2020 at 02:15:17PM -0700, Matt Roper wrote:
> Although RKL is a gen12 platform, it doesn't have the two extra
> instances of the ABOX control register; we should only program
> the single MBUS_ABOX_CTL on this platform.
>
> Bspec: 50096
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_display_power.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 2c1ce50b572b..37847b3d733c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -4772,7 +4772,7 @@ static void icl_mbus_init(struct drm_i915_private
> *dev_priv)
> MBUS_ABOX_BW_CREDIT(1);
>
> intel_de_rmw(dev_priv, MBUS_ABOX_CTL, mask, val);
> - if (INTEL_GEN(dev_priv) >= 12) {
> + if (INTEL_GEN(dev_priv) >= 12 && !IS_ROCKETLAKE(dev_priv)) {
> intel_de_rmw(dev_priv, MBUS_ABOX1_CTL, mask, val);
> intel_de_rmw(dev_priv, MBUS_ABOX2_CTL, mask, val);
> }
Can't find anyting definitive in bspec, so not 100% sure but
since you say it gives unclaim reg errors it seems correct.
Reviewed-by: Ville Syrjälä
Though I think I'd like to see that HAS_ABOX() thing I suggested
and use it here as well.
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/gt: Initialize reserved and unspecified MOCS indices
In order to avoid functional breakage of mis-programmed applications that
have grown to depend on unused MOCS entries, we are programming
those entries to be equal to fully cached ("L3 + LLC") entry as per the
recommendation from architecture team.
These reserved and unspecified entries should not be used as they may be
changed to less performant variants with better coherency in the future
if more entries are needed.
Signed-off-by: Ayaz A Siddiqui
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/gt/intel_mocs.c | 93 ++--
1 file changed, 89 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 632e08a4592b..1089bd5fdba2 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -234,10 +234,6 @@ static const struct drm_i915_mocs_entry
broxton_mocs_table[] = {
L3_1_UC)
static const struct drm_i915_mocs_entry tgl_mocs_table[] = {
- /* Base - Error (Reserved for Non-Use) */
- MOCS_ENTRY(0, 0x0, 0x0),
- /* Base - Reserved */
- MOCS_ENTRY(1, 0x0, 0x0),
GEN11_MOCS_ENTRIES,
@@ -265,6 +261,95 @@ static const struct drm_i915_mocs_entry tgl_mocs_table[] =
{
MOCS_ENTRY(61,
LE_1_UC | LE_TC_1_LLC,
L3_3_WB),
+
+ /* NOTE:
+* Reserved and unspecified MOCS indices have been set to (L3 + LCC).
+* These reserved entry should never be used, they may be chanaged
+* to low performant variants with better coherency in the future if
+* more entries are needed.
+*/
+
+ /* Reserved index 0 and 1 */
+ MOCS_ENTRY(0, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(1, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+
+ /* Reserved index 16 and 17 */
+ MOCS_ENTRY(16, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(17, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+
+ /* Reserved index 24 and 25 */
+ MOCS_ENTRY(24, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(25, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+
+ /* Unspecified indices 26 to 47 */
+ MOCS_ENTRY(26, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(27, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(28, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(29, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(30, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(31, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(32, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(33, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(34, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(35, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(36, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(37, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(38, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(39, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(40, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(41, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(42, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(43, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(44, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(45, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(46, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(47, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+
+ /* Unspecified indices 52 to 59 */
+ MOCS_ENTRY(52, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(53, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(54, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(55, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(56, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(57, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(58, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(59, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
Re: [Intel-gfx] [PATCH v3 07/15] drm/i915/rkl: Update TGP's pin mapping when paired with RKL
On Wed, Jun 03, 2020 at 02:15:21PM -0700, Matt Roper wrote:
> When TGP is paired with RKL it uses a different HPD pin mapping than
> when paired with TGL.
>
> Cc: Ville Syrjälä
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_irq.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 490574669eaa..f3ea81a17352 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -167,6 +167,17 @@ static const u32 hpd_tgp[HPD_NUM_PINS] = {
> [HPD_PORT_I] = SDE_TC_HOTPLUG_ICP(PORT_TC6),
> };
>
> +/*
> + * TGP when paired with RKL has different pin mappings than when paired
> + * with TGL.
> + */
> +static const u32 hpd_rkl_tgp[HPD_NUM_PINS] = {
> + [HPD_PORT_A] = SDE_DDI_HOTPLUG_ICP(PORT_A),
> + [HPD_PORT_B] = SDE_DDI_HOTPLUG_ICP(PORT_B),
> + [HPD_PORT_C] = SDE_TC_HOTPLUG_ICP(PORT_TC1),
> + [HPD_PORT_D] = SDE_TC_HOTPLUG_ICP(PORT_TC2),
> +};
Hmm. So basically it looks like we'd want to pick the hpd_pin
based on the DDI rather than the PHY on this platform?
OK, I guess we need to remap somehow. The question is
whether we want to do it before or after selecting hpd_pin...
I think we would want to do it before, as otherwise the
long_detect() stuff won't work right AFAICS. Or am I
missing something?
Side note: we should probably convert the long_detect()
switches to arrays just like we have for the isr bits here.
Would potentially avoid having to touch that code every time
they tweak these thinhs in hw.
And in fact it looks like icp already has all the same hpd
pins as tgp, so I'm thinking we should just s/hpd_tgp/hpd_icp/
and for icl/jsl we should remap hpd_pin as well. Oh and the
mcc case would just need a slightly different mapping of
port C -> HPD_PORT_D (aka. tc1).
This way all the hpd[] arrays and whatnot would just be based
on the actual pch type and not based on what it happens to be
paired with.
Anwyays, most of that is out of scope for this rkl stuff, so
I guess for now just add a bit of logic to remap hpd_pin for rkl?
> +
> static void intel_hpd_init_pins(struct drm_i915_private *dev_priv)
> {
> struct i915_hotplug *hpd = _priv->hotplug;
> @@ -196,7 +207,9 @@ static void intel_hpd_init_pins(struct drm_i915_private
> *dev_priv)
> if (!HAS_PCH_SPLIT(dev_priv) || HAS_PCH_NOP(dev_priv))
> return;
>
> - if (HAS_PCH_TGP(dev_priv) || HAS_PCH_JSP(dev_priv))
> + if (HAS_PCH_TGP(dev_priv) && IS_ROCKETLAKE(dev_priv))
> + hpd->pch_hpd = hpd_rkl_tgp;
> + else if (HAS_PCH_TGP(dev_priv) || HAS_PCH_JSP(dev_priv))
> hpd->pch_hpd = hpd_tgp;
> else if (HAS_PCH_ICP(dev_priv) || HAS_PCH_MCC(dev_priv))
> hpd->pch_hpd = hpd_icp;
> --
> 2.24.1
--
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.IGT: success for drm/i915/gt: Track if an engine requires forcewake w/a (rev2)
== Series Details == Series: drm/i915/gt: Track if an engine requires forcewake w/a (rev2) URL : https://patchwork.freedesktop.org/series/78005/ State : success == Summary == CI Bug Log - changes from CI_DRM_8583_full -> Patchwork_17873_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17873_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@engines-mixed-process@vecs0: - shard-kbl: [PASS][1] -> [FAIL][2] ([i915#1528]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-kbl1/igt@gem_ctx_persistence@engines-mixed-proc...@vecs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17873/shard-kbl3/igt@gem_ctx_persistence@engines-mixed-proc...@vecs0.html * igt@gem_exec_whisper@basic-forked-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_8583/shard-glk1/igt@gem_exec_whis...@basic-forked-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17873/shard-glk2/igt@gem_exec_whis...@basic-forked-all.html * igt@gem_tiled_pread_basic: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#95]) +18 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-apl8/igt@gem_tiled_pread_basic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17873/shard-apl4/igt@gem_tiled_pread_basic.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([i915#180]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-apl2/igt@gem_workarou...@suspend-resume-context.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17873/shard-apl6/igt@gem_workarou...@suspend-resume-context.html * igt@i915_module_load@reload-with-fault-injection: - shard-tglb: [PASS][9] -> [DMESG-WARN][10] ([i915#402]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-tglb3/igt@i915_module_l...@reload-with-fault-injection.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17873/shard-tglb3/igt@i915_module_l...@reload-with-fault-injection.html * igt@i915_suspend@debugfs-reader: - shard-kbl: [PASS][11] -> [INCOMPLETE][12] ([i915#155]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-kbl7/igt@i915_susp...@debugfs-reader.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17873/shard-kbl6/igt@i915_susp...@debugfs-reader.html * igt@kms_big_fb@x-tiled-8bpp-rotate-0: - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-apl7/igt@kms_big...@x-tiled-8bpp-rotate-0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17873/shard-apl3/igt@kms_big...@x-tiled-8bpp-rotate-0.html - shard-glk: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-glk2/igt@kms_big...@x-tiled-8bpp-rotate-0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17873/shard-glk8/igt@kms_big...@x-tiled-8bpp-rotate-0.html * igt@kms_color@pipe-c-ctm-0-25: - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +9 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-skl3/igt@kms_co...@pipe-c-ctm-0-25.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17873/shard-skl8/igt@kms_co...@pipe-c-ctm-0-25.html * igt@kms_cursor_crc@pipe-a-cursor-64x21-offscreen: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#54]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-skl4/igt@kms_cursor_...@pipe-a-cursor-64x21-offscreen.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17873/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-64x21-offscreen.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-kbl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17873/shard-kbl4/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_frontbuffer_tracking@psr-rgb101010-draw-mmap-cpu: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#49]) +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-skl8/igt@kms_frontbuffer_track...@psr-rgb101010-draw-mmap-cpu.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17873/shard-skl9/igt@kms_frontbuffer_track...@psr-rgb101010-draw-mmap-cpu.html * igt@kms_hdr@bpc-switch: - shard-skl: [PASS][25] -> [FAIL][26] ([i915#1188]) [25]:
Re: [Intel-gfx] [PATCH v2] drm/i915: Fix wrong CDCLK adjustment changes
Pushed to dinq, thanks for the patch.
Manasi
On Mon, Jun 01, 2020 at 08:30:58PM +0300, Stanislav Lisovskiy wrote:
> Previous patch didn't take into account all pipes
> but only those in state, which could cause wrong
> CDCLK conclcusions and calculations.
> Also there was a severe issue with min_cdclk being
> assigned to 0 every compare cycle.
>
> Too bad this was found by me only after merge.
> This could be also causing the issues in test, however
> not clear - anyway marking this as fixing the
> "Adjust CDCLK accordingly to our DBuf bw needs".
>
> v2: - s/pipe/crtc->pipe/
> - save a bit of instructions by
> skipping inactive pipes, without
> getting 0 DBuf slice mask for it.
>
> Signed-off-by: Stanislav Lisovskiy
> Fixes: cd1915460861 ("Adjust CDCLK accordingly to our DBuf bw needs")
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 52 +---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 19 ---
> drivers/gpu/drm/i915/display/intel_display.c | 26 +-
> 3 files changed, 55 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index a79bd7aeb03b..bd060404d249 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -437,6 +437,7 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state
> *state)
> struct intel_crtc *crtc;
> int max_bw = 0;
> int slice_id;
> + enum pipe pipe;
> int i;
>
> for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
> @@ -447,10 +448,15 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state
> *state)
> if (IS_ERR(new_bw_state))
> return PTR_ERR(new_bw_state);
>
> + old_bw_state = intel_atomic_get_old_bw_state(state);
> +
> crtc_bw = _bw_state->dbuf_bw[crtc->pipe];
>
> memset(_bw->used_bw, 0, sizeof(crtc_bw->used_bw));
>
> + if (!crtc_state->hw.active)
> + continue;
> +
> for_each_plane_id_on_crtc(crtc, plane_id) {
> const struct skl_ddb_entry *plane_alloc =
> _state->wm.skl.plane_ddb_y[plane_id];
> @@ -478,6 +484,15 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state
> *state)
> for_each_dbuf_slice_in_mask(slice_id, dbuf_mask)
> crtc_bw->used_bw[slice_id] += data_rate;
> }
> + }
> +
> + if (!old_bw_state)
> + return 0;
> +
> + for_each_pipe(dev_priv, pipe) {
> + struct intel_dbuf_bw *crtc_bw;
> +
> + crtc_bw = _bw_state->dbuf_bw[pipe];
>
> for_each_dbuf_slice(slice_id) {
> /*
> @@ -490,14 +505,9 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state
> *state)
>*/
> max_bw += crtc_bw->used_bw[slice_id];
> }
> -
> - new_bw_state->min_cdclk = max_bw / 64;
> -
> - old_bw_state = intel_atomic_get_old_bw_state(state);
> }
>
> - if (!old_bw_state)
> - return 0;
> + new_bw_state->min_cdclk = max_bw / 64;
>
> if (new_bw_state->min_cdclk != old_bw_state->min_cdclk) {
> int ret = intel_atomic_lock_global_state(_bw_state->base);
> @@ -511,34 +521,38 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state
> *state)
>
> int intel_bw_calc_min_cdclk(struct intel_atomic_state *state)
> {
> - int i;
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + struct intel_bw_state *new_bw_state = NULL;
> + struct intel_bw_state *old_bw_state = NULL;
> const struct intel_crtc_state *crtc_state;
> struct intel_crtc *crtc;
> int min_cdclk = 0;
> - struct intel_bw_state *new_bw_state = NULL;
> - struct intel_bw_state *old_bw_state = NULL;
> + enum pipe pipe;
> + int i;
>
> for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
> - struct intel_cdclk_state *cdclk_state;
> -
> new_bw_state = intel_atomic_get_bw_state(state);
> if (IS_ERR(new_bw_state))
> return PTR_ERR(new_bw_state);
>
> - cdclk_state = intel_atomic_get_cdclk_state(state);
> - if (IS_ERR(cdclk_state))
> - return PTR_ERR(cdclk_state);
> -
> - min_cdclk = max(cdclk_state->min_cdclk[crtc->pipe], min_cdclk);
> -
> - new_bw_state->min_cdclk = min_cdclk;
> -
> old_bw_state = intel_atomic_get_old_bw_state(state);
> }
>
> if (!old_bw_state)
> return 0;
>
> + for_each_pipe(dev_priv, pipe) {
> + struct intel_cdclk_state *cdclk_state;
> +
> + cdclk_state = intel_atomic_get_new_cdclk_state(state);
> + if (!cdclk_state)
> + return 0;
> +
> +
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Trim set_timer_ms() intervals
== Series Details == Series: drm/i915: Trim set_timer_ms() intervals URL : https://patchwork.freedesktop.org/series/78002/ State : success == Summary == CI Bug Log - changes from CI_DRM_8583_full -> Patchwork_17871_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17871_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_whisper@basic-queues-forked-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_8583/shard-glk1/igt@gem_exec_whis...@basic-queues-forked-all.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17871/shard-glk8/igt@gem_exec_whis...@basic-queues-forked-all.html * igt@i915_suspend@debugfs-reader: - shard-kbl: [PASS][3] -> [INCOMPLETE][4] ([i915#155]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-kbl7/igt@i915_susp...@debugfs-reader.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17871/shard-kbl2/igt@i915_susp...@debugfs-reader.html * igt@kms_big_fb@x-tiled-8bpp-rotate-0: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-apl7/igt@kms_big...@x-tiled-8bpp-rotate-0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17871/shard-apl2/igt@kms_big...@x-tiled-8bpp-rotate-0.html * igt@kms_big_fb@y-tiled-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_8583/shard-glk2/igt@kms_big...@y-tiled-64bpp-rotate-0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17871/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-0.html * igt@kms_cursor_crc@pipe-b-cursor-128x128-sliding: - shard-skl: [PASS][9] -> [FAIL][10] ([i915#54]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-skl5/igt@kms_cursor_...@pipe-b-cursor-128x128-sliding.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17871/shard-skl9/igt@kms_cursor_...@pipe-b-cursor-128x128-sliding.html * igt@kms_cursor_crc@pipe-c-cursor-256x85-offscreen: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#95]) +19 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-apl4/igt@kms_cursor_...@pipe-c-cursor-256x85-offscreen.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17871/shard-apl3/igt@kms_cursor_...@pipe-c-cursor-256x85-offscreen.html * igt@kms_cursor_legacy@cursora-vs-flipb-toggle: - shard-glk: [PASS][13] -> [DMESG-FAIL][14] ([i915#1925] / [i915#1926]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-glk2/igt@kms_cursor_leg...@cursora-vs-flipb-toggle.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17871/shard-glk8/igt@kms_cursor_leg...@cursora-vs-flipb-toggle.html * igt@kms_cursor_legacy@short-flip-after-cursor-toggle: - shard-snb: [PASS][15] -> [SKIP][16] ([fdo#109271]) +5 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-snb5/igt@kms_cursor_leg...@short-flip-after-cursor-toggle.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17871/shard-snb6/igt@kms_cursor_leg...@short-flip-after-cursor-toggle.html * igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-xtiled: - shard-apl: [PASS][17] -> [TIMEOUT][18] ([i915#1635]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-apl3/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-xtiled.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17871/shard-apl1/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-xtiled.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt: - shard-iclb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-iclb5/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17871/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html * igt@kms_frontbuffer_tracking@psr-rgb101010-draw-mmap-cpu: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#49]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-skl8/igt@kms_frontbuffer_track...@psr-rgb101010-draw-mmap-cpu.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17871/shard-skl6/igt@kms_frontbuffer_track...@psr-rgb101010-draw-mmap-cpu.html * igt@kms_hdr@bpc-switch-suspend: - shard-kbl: [PASS][23] -> [FAIL][24] ([i915#1188]) [23]:
Re: [Intel-gfx] [PATCH v3 14/15] drm/i915/rkl: Disable PSR2
On Wed, Jun 03, 2020 at 02:15:28PM -0700, Matt Roper wrote:
> From: José Roberto de Souza
>
> RKL doesn't have PSR2 HW tracking, it was replaced by software/manual
> tracking. The driver is required to track the areas that needs update
> and program hardware to send selective updates.
>
> So until the software tracking is implemented, PSR2 needs to be disabled
> for platforms without PSR2 HW tracking.
>
> BSpec: 50422
> BSpec: 50424
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
> Signed-off-by: Matt Roper
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 15 +++
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/i915_pci.c | 3 +++
> drivers/gpu/drm/i915/intel_device_info.h | 1 +
> 4 files changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index b7a2c102648a..714c590b39f5 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -646,6 +646,21 @@ static bool intel_psr2_config_valid(struct intel_dp
> *intel_dp,
> return false;
> }
>
> + /*
> + * Some platforms lack PSR2 HW tracking and instead require manual
> + * tracking by software. In this case, the driver is required to track
> + * the areas that need updates and program hardware to send selective
> + * updates.
> + *
> + * So until the software tracking is implemented, PSR2 needs to be
> + * disabled for platforms without PSR2 HW tracking.
> + */
> + if (!HAS_PSR_HW_TRACKING(dev_priv)) {
> + drm_dbg_kms(_priv->drm,
> + "No PSR2 HW tracking in the platform\n");
> + return false;
> + }
> +
> /*
>* DSC and PSR2 cannot be enabled simultaneously. If a requested
>* resolution requires DSC to be enabled, priority is given to DSC
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 668b3c9cf3ae..87f4000413f1 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1644,6 +1644,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> #define HAS_DDI(dev_priv) (INTEL_INFO(dev_priv)->display.has_ddi)
> #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) (INTEL_INFO(dev_priv)->has_fpga_dbg)
> #define HAS_PSR(dev_priv) (INTEL_INFO(dev_priv)->display.has_psr)
> +#define HAS_PSR_HW_TRACKING(dev_priv) \
> + (INTEL_INFO(dev_priv)->display.has_psr_hw_tracking)
> #define HAS_TRANSCODER(dev_priv, trans)
> ((INTEL_INFO(dev_priv)->cpu_transcoder_mask & BIT(trans)) != 0)
>
> #define HAS_RC6(dev_priv) (INTEL_INFO(dev_priv)->has_rc6)
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 0ed586ee2047..ef4a457a6c4f 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -536,6 +536,7 @@ static const struct intel_device_info vlv_info = {
> .display.has_ddi = 1, \
> .has_fpga_dbg = 1, \
> .display.has_psr = 1, \
> + .display.has_psr_hw_tracking = 1, \
> .display.has_dp_mst = 1, \
> .has_rc6p = 0 /* RC6p removed-by HSW */, \
> HSW_PIPE_OFFSETS, \
> @@ -690,6 +691,7 @@ static const struct intel_device_info skl_gt4_info = {
> .display.has_fbc = 1, \
> .display.has_hdcp = 1, \
> .display.has_psr = 1, \
> + .display.has_psr_hw_tracking = 1, \
> .has_runtime_pm = 1, \
> .display.has_csr = 1, \
> .has_rc6 = 1, \
> @@ -884,6 +886,7 @@ static const struct intel_device_info rkl_info = {
> .cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) | \
> BIT(TRANSCODER_C),
> .require_force_probe = 1,
> + .display.has_psr_hw_tracking = 0,
> .engine_mask =
> BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0),
> };
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> b/drivers/gpu/drm/i915/intel_device_info.h
> index 3613c04904e0..34dbffd65bad 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -148,6 +148,7 @@ enum intel_ppgtt_type {
> func(has_modular_fia); \
> func(has_overlay); \
> func(has_psr); \
> + func(has_psr_hw_tracking); \
> func(overlay_needs_physical); \
> func(supports_tv);
>
> --
> 2.24.1
>
> ___
> 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.BAT: failure for drm/i915/gt: Extract busy-stats for use in other schedulers
== Series Details ==
Series: drm/i915/gt: Extract busy-stats for use in other schedulers
URL : https://patchwork.freedesktop.org/series/78007/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8584 -> Patchwork_17874
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17874 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17874, 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_17874/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17874:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@gt_engines:
- fi-icl-y: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8584/fi-icl-y/igt@i915_selftest@live@gt_engines.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17874/fi-icl-y/igt@i915_selftest@live@gt_engines.html
- fi-tgl-y: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8584/fi-tgl-y/igt@i915_selftest@live@gt_engines.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17874/fi-tgl-y/igt@i915_selftest@live@gt_engines.html
Known issues
Here are the changes found in Patchwork_17874 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8584/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17874/fi-byt-j1900/igt@i915_pm_...@module-reload.html
Possible fixes
* igt@i915_pm_rpm@basic-rte:
- {fi-tgl-dsi}: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8584/fi-tgl-dsi/igt@i915_pm_...@basic-rte.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17874/fi-tgl-dsi/igt@i915_pm_...@basic-rte.html
Warnings
* igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][10] ([i915#62] / [i915#92]) +1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8584/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17874/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92]) ->
[DMESG-WARN][12] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8584/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17874/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (47 -> 44)
--
Additional (4): fi-bsw-kefka fi-skl-lmem fi-cml-s fi-bsw-n3050
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8584 -> Patchwork_17874
CI-20190529: 20190529
CI_DRM_8584: 2219a8bbaa3c87f07656725f4d2ea6623d1fd09a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5695: 53e8c878a6fb5708e63c99403691e8960b86ea9c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17874: ffa4cc633b498c858ed7646f2c040e0f9f6ee394 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ffa4cc633b49 drm/i915/gt: Extract busy-stats for use in other schedulers
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17874/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Extract busy-stats for use in other schedulers
== Series Details == Series: drm/i915/gt: Extract busy-stats for use in other schedulers URL : https://patchwork.freedesktop.org/series/78007/ State : warning == Summary == $ dim checkpatch origin/drm-tip ffa4cc633b49 drm/i915/gt: Extract busy-stats for use in other schedulers -:14: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #14: new file mode 100644 -:165: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see Documentation/timers/timers-howto.rst #165: FILE: drivers/gpu/drm/i915/gt/selftest_engine_pm.c:47: + udelay(100); -:195: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see Documentation/timers/timers-howto.rst #195: FILE: drivers/gpu/drm/i915/gt/selftest_engine_pm.c:77: + udelay(100); total: 0 errors, 1 warnings, 2 checks, 209 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 05/15] drm/i915/rkl: Setup ports/phys
On Wed, Jun 03, 2020 at 02:15:19PM -0700, Matt Roper wrote:
> RKL uses DDI's A, B, TC1, and TC2 which need to map to combo PHY's A-D.
>
> Bspec: 49181
> Cc: Imre Deak
> Cc: Aditya Swarup
> Cc: Lucas De Marchi
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 34
> drivers/gpu/drm/i915/i915_reg.h | 4 ++-
> 2 files changed, 24 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index b4f8c88c779f..019fef8023ca 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7218,30 +7218,33 @@ bool intel_phy_is_combo(struct drm_i915_private
> *dev_priv, enum phy phy)
> {
> if (phy == PHY_NONE)
> return false;
> -
> - if (IS_ELKHARTLAKE(dev_priv))
> + else if (IS_ROCKETLAKE(dev_priv))
> + return phy <= PHY_D;
Or just 'return true' since combo PHYs is all we have.
/me weeps when looking at these functions.
Reviewed-by: Ville Syrjälä
> + else if (IS_ELKHARTLAKE(dev_priv))
> return phy <= PHY_C;
> -
> - if (INTEL_GEN(dev_priv) >= 11)
> + else if (INTEL_GEN(dev_priv) >= 11)
> return phy <= PHY_B;
> -
> - return false;
> + else
> + return false;
> }
>
> bool intel_phy_is_tc(struct drm_i915_private *dev_priv, enum phy phy)
> {
> - if (INTEL_GEN(dev_priv) >= 12)
> + if (IS_ROCKETLAKE(dev_priv))
> + return false;
> + else if (INTEL_GEN(dev_priv) >= 12)
> return phy >= PHY_D && phy <= PHY_I;
> -
> - if (INTEL_GEN(dev_priv) >= 11 && !IS_ELKHARTLAKE(dev_priv))
> + else if (INTEL_GEN(dev_priv) >= 11 && !IS_ELKHARTLAKE(dev_priv))
> return phy >= PHY_C && phy <= PHY_F;
> -
> - return false;
> + else
> + return false;
> }
>
> enum phy intel_port_to_phy(struct drm_i915_private *i915, enum port port)
> {
> - if (IS_ELKHARTLAKE(i915) && port == PORT_D)
> + if (IS_ROCKETLAKE(i915) && port >= PORT_D)
> + return (enum phy)port - 1;
> + else if (IS_ELKHARTLAKE(i915) && port == PORT_D)
> return PHY_A;
>
> return (enum phy)port;
> @@ -16829,7 +16832,12 @@ static void intel_setup_outputs(struct
> drm_i915_private *dev_priv)
> if (!HAS_DISPLAY(dev_priv) || !INTEL_DISPLAY_ENABLED(dev_priv))
> return;
>
> - if (INTEL_GEN(dev_priv) >= 12) {
> + 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 */
> + } else if (INTEL_GEN(dev_priv) >= 12) {
> intel_ddi_init(dev_priv, PORT_A);
> intel_ddi_init(dev_priv, PORT_B);
> intel_ddi_init(dev_priv, PORT_D);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index db031269a05a..85137d268c4a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1869,9 +1869,11 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
> #define _ICL_COMBOPHY_A 0x162000
> #define _ICL_COMBOPHY_B 0x6C000
> #define _EHL_COMBOPHY_C 0x16
> +#define _RKL_COMBOPHY_D 0x161000
> #define _ICL_COMBOPHY(phy) _PICK(phy, _ICL_COMBOPHY_A, \
> _ICL_COMBOPHY_B, \
> - _EHL_COMBOPHY_C)
> + _EHL_COMBOPHY_C, \
> + _RKL_COMBOPHY_D)
>
> /* CNL/ICL Port CL_DW registers */
> #define _ICL_PORT_CL_DW(dw, phy) (_ICL_COMBOPHY(phy) + \
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 02/15] drm/i915/rkl: Program BW_BUDDY0 registers instead of BW_BUDDY1/2
On Wed, Jun 03, 2020 at 02:15:16PM -0700, Matt Roper wrote:
> RKL uses the same BW_BUDDY programming table as TGL, but programs the
> values into a single set BUDDY0 set of registers rather than the
> BUDDY1/BUDDY2 sets used by TGL.
Maybe we just want some kind of HAS_ABOX() so we could use the same
thing here and in the ABOX_CTL programming?
>
> Bspec: 49218
> Cc: Aditya Swarup
> Signed-off-by: Matt Roper
> ---
> .../drm/i915/display/intel_display_power.c| 44 +++
> drivers/gpu/drm/i915/i915_reg.h | 14 --
> 2 files changed, 35 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 72312b67b57a..2c1ce50b572b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -5254,7 +5254,7 @@ static void tgl_bw_buddy_init(struct drm_i915_private
> *dev_priv)
> enum intel_dram_type type = dev_priv->dram_info.type;
> u8 num_channels = dev_priv->dram_info.num_channels;
> const struct buddy_page_mask *table;
> - int i;
> + int config, min_buddy, max_buddy, i;
>
> if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_B0))
> /* Wa_1409767108: tgl */
> @@ -5262,29 +5262,35 @@ static void tgl_bw_buddy_init(struct drm_i915_private
> *dev_priv)
> else
> table = tgl_buddy_page_masks;
>
> - for (i = 0; table[i].page_mask != 0; i++)
> - if (table[i].num_channels == num_channels &&
> - table[i].type == type)
> + if (IS_ROCKETLAKE(dev_priv)) {
> + min_buddy = max_buddy = 0;
> + } else {
> + min_buddy = 1;
> + max_buddy = 2;
> + }
> +
> + for (config = 0; table[config].page_mask != 0; config++)
> + if (table[config].num_channels == num_channels &&
> + table[config].type == type)
> break;
>
> - if (table[i].page_mask == 0) {
> + if (table[config].page_mask == 0) {
> drm_dbg(_priv->drm,
> "Unknown memory configuration; disabling address buddy
> logic.\n");
> - intel_de_write(dev_priv, BW_BUDDY1_CTL, BW_BUDDY_DISABLE);
> - intel_de_write(dev_priv, BW_BUDDY2_CTL, BW_BUDDY_DISABLE);
> + for (i = min_buddy; i <= max_buddy; i++)
> + intel_de_write(dev_priv, BW_BUDDY_CTL(i),
> +BW_BUDDY_DISABLE);
> } else {
> - intel_de_write(dev_priv, BW_BUDDY1_PAGE_MASK,
> -table[i].page_mask);
> - intel_de_write(dev_priv, BW_BUDDY2_PAGE_MASK,
> -table[i].page_mask);
> -
> - /* Wa_22010178259:tgl */
> - intel_de_rmw(dev_priv, BW_BUDDY1_CTL,
> - BW_BUDDY_TLB_REQ_TIMER_MASK,
> - REG_FIELD_PREP(BW_BUDDY_TLB_REQ_TIMER_MASK, 0x8));
> - intel_de_rmw(dev_priv, BW_BUDDY2_CTL,
> - BW_BUDDY_TLB_REQ_TIMER_MASK,
> - REG_FIELD_PREP(BW_BUDDY_TLB_REQ_TIMER_MASK, 0x8));
> + for (i = min_buddy; i <= max_buddy; i++) {
> + intel_de_write(dev_priv, BW_BUDDY_PAGE_MASK(i),
> +table[config].page_mask);
> +
> + /* Wa_22010178259:tgl,rkl */
> + intel_de_rmw(dev_priv, BW_BUDDY_CTL(i),
> + BW_BUDDY_TLB_REQ_TIMER_MASK,
> + REG_FIELD_PREP(BW_BUDDY_TLB_REQ_TIMER_MASK,
> + 0x8));
> + }
> }
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 578cfe11cbb9..3e79cefc510a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7837,13 +7837,19 @@ enum {
> #define WAIT_FOR_PCH_RESET_ACK (1 << 1)
> #define WAIT_FOR_PCH_FLR_ACK(1 << 0)
>
> -#define BW_BUDDY1_CTL_MMIO(0x45140)
> -#define BW_BUDDY2_CTL_MMIO(0x45150)
> +#define _BW_BUDDY0_CTL 0x45130
> +#define _BW_BUDDY1_CTL 0x45140
> +#define BW_BUDDY_CTL(x) _MMIO(_PICK_EVEN(x, \
> + _BW_BUDDY0_CTL, \
> + _BW_BUDDY1_CTL))
> #define BW_BUDDY_DISABLE REG_BIT(31)
> #define BW_BUDDY_TLB_REQ_TIMER_MASKREG_GENMASK(21, 16)
>
> -#define BW_BUDDY1_PAGE_MASK _MMIO(0x45144)
> -#define BW_BUDDY2_PAGE_MASK _MMIO(0x45154)
> +#define _BW_BUDDY0_PAGE_MASK 0x45134
> +#define _BW_BUDDY1_PAGE_MASK 0x45144
> +#define BW_BUDDY_PAGE_MASK(x)
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Trace HWSP cachelines
== Series Details == Series: drm/i915/gt: Trace HWSP cachelines URL : https://patchwork.freedesktop.org/series/78000/ State : success == Summary == CI Bug Log - changes from CI_DRM_8583_full -> Patchwork_17870_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17870_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_tiled_pread_basic: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([i915#95]) +16 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-apl8/igt@gem_tiled_pread_basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17870/shard-apl4/igt@gem_tiled_pread_basic.html * igt@kms_big_fb@x-tiled-8bpp-rotate-0: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-apl7/igt@kms_big...@x-tiled-8bpp-rotate-0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17870/shard-apl6/igt@kms_big...@x-tiled-8bpp-rotate-0.html * igt@kms_big_fb@y-tiled-64bpp-rotate-0: - shard-glk: [PASS][5] -> [DMESG-FAIL][6] ([i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-glk2/igt@kms_big...@y-tiled-64bpp-rotate-0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17870/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-0.html * igt@kms_cursor_crc@pipe-a-cursor-64x21-offscreen: - shard-skl: [PASS][7] -> [FAIL][8] ([i915#54]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-skl4/igt@kms_cursor_...@pipe-a-cursor-64x21-offscreen.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17870/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-64x21-offscreen.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-kbl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17870/shard-kbl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@all-pipes-torture-bo: - shard-tglb: [PASS][11] -> [DMESG-WARN][12] ([i915#128]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-tglb2/igt@kms_cursor_leg...@all-pipes-torture-bo.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17870/shard-tglb1/igt@kms_cursor_leg...@all-pipes-torture-bo.html * igt@kms_cursor_legacy@cursora-vs-flipb-toggle: - shard-glk: [PASS][13] -> [DMESG-FAIL][14] ([i915#1925] / [i915#1926]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-glk2/igt@kms_cursor_leg...@cursora-vs-flipb-toggle.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17870/shard-glk8/igt@kms_cursor_leg...@cursora-vs-flipb-toggle.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic: - shard-skl: [PASS][15] -> [FAIL][16] ([IGT#5]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-skl10/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17870/shard-skl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html * igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-xtiled: - shard-apl: [PASS][17] -> [TIMEOUT][18] ([i915#1635]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-apl3/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-xtiled.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17870/shard-apl8/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-xtiled.html * igt@kms_frontbuffer_tracking@psr-rgb101010-draw-mmap-cpu: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#49]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-skl8/igt@kms_frontbuffer_track...@psr-rgb101010-draw-mmap-cpu.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17870/shard-skl5/igt@kms_frontbuffer_track...@psr-rgb101010-draw-mmap-cpu.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#1188]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-skl4/igt@kms_...@bpc-switch-dpms.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17870/shard-skl9/igt@kms_...@bpc-switch-dpms.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-skl: [PASS][23] -> [INCOMPLETE][24] ([i915#648] / [i915#69]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/shard-skl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17870/shard-skl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html *
Re: [Intel-gfx] [PATCH v3 13/15] drm/i915/rkl: Handle HTI
On Wed, Jun 03, 2020 at 02:15:27PM -0700, Matt Roper wrote:
> If HTI (also sometimes called HDPORT) is enabled at startup, it may be
whatis HTI?
> 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 bcc6dc4e321b..cdd84a419cf7 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"
> @@ -16817,6 +16818,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;
> @@ -16828,10 +16836,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);
> @@ -18379,6 +18399,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);
> +
> 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)
> +{
> + u32 hdport_state;
> +
> + if (!IS_ROCKETLAKE(dev_priv))
> + return 0;
> +
> + hdport_state = intel_de_read(dev_priv, HDPORT_STATE);
> + if (!(hdport_state & HDPORT_ENABLED))
> + return 0;
> +
> + return REG_FIELD_GET(HDPORT_DPLL_USED_MASK, hdport_state);
> +}
> +
> static struct intel_shared_dpll *
> intel_find_shared_dpll(struct intel_atomic_state *state,
> const struct intel_crtc *crtc,
> @@ -280,6 +298,9 @@ intel_find_shared_dpll(struct intel_atomic_state *state,
>
> drm_WARN_ON(_priv->drm, dpll_mask & ~(BIT(I915_NUM_PLLS) - 1));
>
> + /* Eliminate DPLLs from consideration if reserved by HTI */
> + dpll_mask &= ~dev_priv->hti_pll_mask;
> +
> for_each_set_bit(i, _mask, I915_NUM_PLLS) {
> pll =
Re: [Intel-gfx] [PATCH v3 10/15] drm/i915/rkl: Don't try to read out DSI transcoders
On Wed, Jun 03, 2020 at 02:15:24PM -0700, Matt Roper wrote:
> From: Aditya Swarup
>
> RKL doesn't have DSI outputs, so we shouldn't try to read out the DSI
> transcoder registers.
>
> v2(MattR):
> - Just set the 'extra panel mask' to edp | dsi0 | dsi1 and then mask
>against the platform's cpu_transcoder_mask to filter out the ones
>that don't exist on a given platform. (Ville)
>
> Signed-off-by: Aditya Swarup
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 019fef8023ca..bcc6dc4e321b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -10904,19 +10904,13 @@ static bool hsw_get_transcoder_state(struct
> intel_crtc *crtc,
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> enum intel_display_power_domain power_domain;
> - unsigned long panel_transcoder_mask = 0;
> + unsigned long panel_transcoder_mask = BIT(TRANSCODER_EDP) |
> + BIT(TRANSCODER_DSI_0) | BIT(TRANSCODER_DSI_1);
TRANSCODER_DSI_0/1 alias TRANSCODER_DSI_A/C which we do not
want in this mask.
> unsigned long enabled_panel_transcoders = 0;
> enum transcoder panel_transcoder;
> intel_wakeref_t wf;
> u32 tmp;
>
> - if (INTEL_GEN(dev_priv) >= 11)
> - panel_transcoder_mask |=
> - BIT(TRANSCODER_DSI_0) | BIT(TRANSCODER_DSI_1);
> -
> - if (HAS_TRANSCODER(dev_priv, TRANSCODER_EDP))
> - panel_transcoder_mask |= BIT(TRANSCODER_EDP);
> -
> /*
>* The pipe->transcoder mapping is fixed with the exception of the eDP
>* and DSI transcoders handled below.
> @@ -10927,6 +10921,7 @@ static bool hsw_get_transcoder_state(struct
> intel_crtc *crtc,
>* XXX: Do intel_display_power_get_if_enabled before reading this (for
>* consistency and less surprising code; it's in always on power).
>*/
> + panel_transcoder_mask &= INTEL_INFO(dev_priv)->cpu_transcoder_mask;
> for_each_set_bit(panel_transcoder,
>_transcoder_mask,
>ARRAY_SIZE(INTEL_INFO(dev_priv)->trans_offsets)) {
Can't we just use for_each_cpu_transcoder_masked() ?
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 09/15] drm/i915/rkl: Don't try to access transcoder D
On Wed, Jun 03, 2020 at 02:15:23PM -0700, Matt Roper wrote:
> There are a couple places in our driver that loop over transcoders A..D
> for gen11+; since RKL only has three pipes/transcoders, this can lead to
> unclaimed register reads/writes. We should add checks for transcoder
> existence where appropriate.
>
> v2: Move one transcoder check that wound up in the wrong function after
> conflict resolution. It belongs in bdw_get_trans_port_sync_config
> rather than bxt_get_dsi_transcoder_state.
>
> v3: Switch loops to use for_each_cpu_transcoder_masked() since this
> iterator already checks the platform's transcoder mask for us.
> (Ville)
>
> Cc: Aditya Swarup
> Cc: Ville Syrjälä
> Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_irq.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index f3ea81a17352..40a71c4a1ef5 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2885,13 +2885,15 @@ static void gen11_display_irq_reset(struct
> drm_i915_private *dev_priv)
> {
> struct intel_uncore *uncore = _priv->uncore;
> enum pipe pipe;
> + u32 trans_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) |
> + BIT(TRANSCODER_C) | BIT(TRANSCODER_D);
>
> intel_uncore_write(uncore, GEN11_DISPLAY_INT_CTL, 0);
>
> if (INTEL_GEN(dev_priv) >= 12) {
> enum transcoder trans;
>
> - for (trans = TRANSCODER_A; trans <= TRANSCODER_D; trans++) {
> + for_each_cpu_transcoder_masked(dev_priv, trans, trans_mask) {
> enum intel_display_power_domain domain;
>
> domain = POWER_DOMAIN_TRANSCODER(trans);
> @@ -3413,6 +3415,8 @@ static void gen8_de_irq_postinstall(struct
> drm_i915_private *dev_priv)
> u32 de_port_masked = gen8_de_port_aux_mask(dev_priv);
> u32 de_port_enables;
> u32 de_misc_masked = GEN8_DE_EDP_PSR;
> + u32 trans_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) |
> + BIT(TRANSCODER_C) | BIT(TRANSCODER_D);
> enum pipe pipe;
>
> if (INTEL_GEN(dev_priv) <= 10)
> @@ -3433,7 +3437,7 @@ static void gen8_de_irq_postinstall(struct
> drm_i915_private *dev_priv)
> if (INTEL_GEN(dev_priv) >= 12) {
> enum transcoder trans;
>
> - for (trans = TRANSCODER_A; trans <= TRANSCODER_D; trans++) {
> + for_each_cpu_transcoder_masked(dev_priv, trans, trans_mask) {
> enum intel_display_power_domain domain;
>
> domain = POWER_DOMAIN_TRANSCODER(trans);
> --
> 2.24.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for Remaining RKL patches
On Thu, Jun 04, 2020 at 08:34:04AM +, Patchwork wrote:
> == Series Details ==
>
> Series: Remaining RKL patches
> URL : https://patchwork.freedesktop.org/series/77971/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_8579_full -> Patchwork_17859_full
>
>
> Summary
> ---
>
> **SUCCESS**
>
> No regressions found.
Patches #1, 6, 8, and 11 from this series applied to dinq since they have r-b's.
Matt
>
>
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_17859_full:
>
> ### IGT changes ###
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * {igt@gem_ctx_isolation@preservation-s3@vcs0}:
> - shard-kbl: [INCOMPLETE][1] ([i915#1780]) -> [INCOMPLETE][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8579/shard-kbl6/igt@gem_ctx_isolation@preservation...@vcs0.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17859/shard-kbl2/igt@gem_ctx_isolation@preservation...@vcs0.html
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_17859_full that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_eio@in-flight-internal-10ms:
> - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#95]) +8 similar
> issues
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8579/shard-apl3/igt@gem_...@in-flight-internal-10ms.html
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17859/shard-apl1/igt@gem_...@in-flight-internal-10ms.html
>
> * igt@gem_eio@in-flight-suspend:
> - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([i915#69]) +1 similar
> issue
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8579/shard-skl9/igt@gem_...@in-flight-suspend.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17859/shard-skl10/igt@gem_...@in-flight-suspend.html
>
> * igt@gem_mmap_offset@clear:
> - shard-skl: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +10
> similar issues
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8579/shard-skl4/igt@gem_mmap_off...@clear.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17859/shard-skl9/igt@gem_mmap_off...@clear.html
>
> * igt@i915_module_load@reload:
> - shard-tglb: [PASS][9] -> [DMESG-WARN][10] ([i915#402])
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8579/shard-tglb3/igt@i915_module_l...@reload.html
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17859/shard-tglb2/igt@i915_module_l...@reload.html
>
> * igt@i915_suspend@fence-restore-tiled2untiled:
> - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +1
> similar issue
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8579/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17859/shard-apl6/igt@i915_susp...@fence-restore-tiled2untiled.html
>
> * igt@i915_suspend@forcewake:
> - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180])
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8579/shard-kbl4/igt@i915_susp...@forcewake.html
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17859/shard-kbl4/igt@i915_susp...@forcewake.html
>
> * igt@kms_cursor_crc@pipe-c-cursor-size-change:
> - shard-skl: [PASS][15] -> [FAIL][16] ([i915#54])
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8579/shard-skl2/igt@kms_cursor_...@pipe-c-cursor-size-change.html
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17859/shard-skl4/igt@kms_cursor_...@pipe-c-cursor-size-change.html
>
> * igt@kms_cursor_legacy@all-pipes-torture-move:
> - shard-iclb: [PASS][17] -> [DMESG-WARN][18] ([i915#128])
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8579/shard-iclb6/igt@kms_cursor_leg...@all-pipes-torture-move.html
>[18]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17859/shard-iclb6/igt@kms_cursor_leg...@all-pipes-torture-move.html
> - shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#128])
>[19]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8579/shard-tglb3/igt@kms_cursor_leg...@all-pipes-torture-move.html
>[20]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17859/shard-tglb6/igt@kms_cursor_leg...@all-pipes-torture-move.html
>
> * igt@kms_cursor_legacy@cursorb-vs-flipa-toggle:
> - shard-glk: [PASS][21] -> [DMESG-FAIL][22] ([i915#1925] /
> [i915#1926])
>[21]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8579/shard-glk9/igt@kms_cursor_leg...@cursorb-vs-flipa-toggle.html
>[22]:
>
[Intel-gfx] [PATCH] drm/i915/gt: Extract busy-stats for use in other schedulers
Once again extract the context in/out accounting for use elsewhere, and
add a selftest to check that the busy-stats are being reported
correctly. Other than keep userspace informed, the busy-stats are a
funamental building block for activity tracking such as RPS.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_stats.h | 49 +++
drivers/gpu/drm/i915/gt/intel_lrc.c | 34 +---
drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 91
drivers/gpu/drm/i915/gt/selftest_rps.c | 5 ++
4 files changed, 146 insertions(+), 33 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_stats.h
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_stats.h
b/drivers/gpu/drm/i915/gt/intel_engine_stats.h
new file mode 100644
index ..58491eae3482
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_engine_stats.h
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#ifndef __INTEL_ENGINE_STATS_H__
+#define __INTEL_ENGINE_STATS_H__
+
+#include
+#include
+#include
+
+#include "i915_gem.h" /* GEM_BUG_ON */
+#include "intel_engine.h"
+
+static inline void intel_engine_context_in(struct intel_engine_cs *engine)
+{
+ unsigned long flags;
+
+ if (atomic_add_unless(>stats.active, 1, 0))
+ return;
+
+ write_seqlock_irqsave(>stats.lock, flags);
+ if (!atomic_add_unless(>stats.active, 1, 0)) {
+ engine->stats.start = ktime_get();
+ atomic_inc(>stats.active);
+ }
+ write_sequnlock_irqrestore(>stats.lock, flags);
+}
+
+static inline void intel_engine_context_out(struct intel_engine_cs *engine)
+{
+ unsigned long flags;
+
+ GEM_BUG_ON(!atomic_read(>stats.active));
+
+ if (atomic_add_unless(>stats.active, -1, 1))
+ return;
+
+ write_seqlock_irqsave(>stats.lock, flags);
+ if (atomic_dec_and_test(>stats.active)) {
+ engine->stats.total =
+ ktime_add(engine->stats.total,
+ ktime_sub(ktime_get(), engine->stats.start));
+ }
+ write_sequnlock_irqrestore(>stats.lock, flags);
+}
+
+#endif /* __INTEL_ENGINE_STATS_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index d55a5e0466e5..36e2ce4ac2fa 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -139,6 +139,7 @@
#include "i915_vgpu.h"
#include "intel_context.h"
#include "intel_engine_pm.h"
+#include "intel_engine_stats.h"
#include "intel_gt.h"
#include "intel_gt_pm.h"
#include "intel_gt_requests.h"
@@ -1187,39 +1188,6 @@ execlists_context_status_change(struct i915_request *rq,
unsigned long status)
status, rq);
}
-static void intel_engine_context_in(struct intel_engine_cs *engine)
-{
- unsigned long flags;
-
- if (atomic_add_unless(>stats.active, 1, 0))
- return;
-
- write_seqlock_irqsave(>stats.lock, flags);
- if (!atomic_add_unless(>stats.active, 1, 0)) {
- engine->stats.start = ktime_get();
- atomic_inc(>stats.active);
- }
- write_sequnlock_irqrestore(>stats.lock, flags);
-}
-
-static void intel_engine_context_out(struct intel_engine_cs *engine)
-{
- unsigned long flags;
-
- GEM_BUG_ON(!atomic_read(>stats.active));
-
- if (atomic_add_unless(>stats.active, -1, 1))
- return;
-
- write_seqlock_irqsave(>stats.lock, flags);
- if (atomic_dec_and_test(>stats.active)) {
- engine->stats.total =
- ktime_add(engine->stats.total,
- ktime_sub(ktime_get(), engine->stats.start));
- }
- write_sequnlock_irqrestore(>stats.lock, flags);
-}
-
static void
execlists_check_context(const struct intel_context *ce,
const struct intel_engine_cs *engine)
diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
index cbf6b0735272..a35737958735 100644
--- a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
@@ -7,6 +7,96 @@
#include "i915_selftest.h"
#include "selftest_engine.h"
#include "selftests/igt_atomic.h"
+#include "selftests/igt_flush_test.h"
+#include "selftests/igt_spinner.h"
+
+static int live_engine_busy_stats(void *arg)
+{
+ struct intel_gt *gt = arg;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ struct igt_spinner spin;
+ int err = 0;
+
+ /*
+* Check that if an engine supports busy-stats, they tell the truth.
+*/
+
+ if (igt_spinner_init(, gt))
+ return -ENOMEM;
+
+ GEM_BUG_ON(intel_gt_pm_is_awake(gt));
+ for_each_engine(engine, gt, id) {
+ struct i915_request *rq;
+ ktime_t dt, de;
+
+
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Track if an engine requires forcewake w/a (rev2)
== Series Details ==
Series: drm/i915/gt: Track if an engine requires forcewake w/a (rev2)
URL : https://patchwork.freedesktop.org/series/78005/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8583 -> Patchwork_17873
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17873/index.html
Known issues
Here are the changes found in Patchwork_17873 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-tgl-y/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17873/fi-tgl-y/igt@i915_module_l...@reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-guc: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17873/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17873/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][7] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][8] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17873/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92]) ->
[DMESG-WARN][10] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17873/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][12] ([i915#62] / [i915#92])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17873/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#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (50 -> 43)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8583 -> Patchwork_17873
CI-20190529: 20190529
CI_DRM_8583: e147ef9bced964b97283851a519aea132a5613e6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5695: 53e8c878a6fb5708e63c99403691e8960b86ea9c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17873: 7042716777f39a6e12bbac546bcd4dbe97048bff @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7042716777f3 drm/i915/gt: Track if an engine requires forcewake w/a
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17873/index.html
___
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/params: switch to device specific parameters
== Series Details == Series: drm/i915/params: switch to device specific parameters URL : https://patchwork.freedesktop.org/series/78004/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8583 -> Patchwork_17872 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17872 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17872, 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_17872/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17872: ### CI changes ### Possible regressions * boot: - fi-kbl-8809g: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-kbl-8809g/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17872/fi-kbl-8809g/boot.html - fi-icl-y: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-icl-y/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17872/fi-icl-y/boot.html - fi-icl-u2: [PASS][5] -> [FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-icl-u2/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17872/fi-icl-u2/boot.html - fi-cfl-8109u: [PASS][7] -> [FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-cfl-8109u/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17872/fi-cfl-8109u/boot.html - fi-skl-6600u: [PASS][9] -> [FAIL][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-skl-6600u/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17872/fi-skl-6600u/boot.html - fi-cfl-8700k: [PASS][11] -> [FAIL][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-cfl-8700k/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17872/fi-cfl-8700k/boot.html - fi-bxt-dsi: [PASS][13] -> [FAIL][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-bxt-dsi/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17872/fi-bxt-dsi/boot.html - fi-icl-dsi: [PASS][15] -> [FAIL][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-icl-dsi/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17872/fi-icl-dsi/boot.html - fi-whl-u: [PASS][17] -> [FAIL][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-whl-u/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17872/fi-whl-u/boot.html - fi-cml-u2: [PASS][19] -> [FAIL][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-cml-u2/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17872/fi-cml-u2/boot.html - fi-skl-6700k2: [PASS][21] -> [FAIL][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-skl-6700k2/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17872/fi-skl-6700k2/boot.html - fi-cfl-guc: [PASS][23] -> [FAIL][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-cfl-guc/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17872/fi-cfl-guc/boot.html - fi-kbl-soraka: [PASS][25] -> [FAIL][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-kbl-soraka/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17872/fi-kbl-soraka/boot.html - fi-icl-guc: [PASS][27] -> [FAIL][28] [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-icl-guc/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17872/fi-icl-guc/boot.html - fi-cml-s: [PASS][29] -> [FAIL][30] [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-cml-s/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17872/fi-cml-s/boot.html - fi-skl-lmem:[PASS][31] -> [FAIL][32] [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-skl-lmem/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17872/fi-skl-lmem/boot.html - fi-glk-dsi: [PASS][33] -> [FAIL][34] [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-glk-dsi/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17872/fi-glk-dsi/boot.html - fi-tgl-y: [PASS][35] -> [FAIL][36] [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-tgl-y/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17872/fi-tgl-y/boot.html - fi-kbl-guc: [PASS][37] -> [FAIL][38] [37]:
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/dp_mst: Work around out-of-spec adapters filtering short pulses
On Thu, Jun 04, 2020 at 06:12:27PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 04, 2020 at 01:18:59AM +0300, Imre Deak wrote:
> > Some TypeC -> native DP adapters, at least the Club CAC-1557 adapter,
> > incorrectly filter out HPD short pulses with a duration less than ~540
> > usec, leading to MST probe failures.
> >
> > According to the DP alt mode specification adapters should forward short
> > pulses with a duration greater than 250 usec. According to the DP
> > specificatin DP sources should detect short pulses in the
> > 500 usec -> 2 ms range.
>
> IIRC it was 250 usec -> 2 ms as well in the DP spec.
>
> 500 usec -> 1 ms is the duration of the short hpd
> the signalling side should use.
Ah, correct (and this is what makes actually sense). For reference it's
described under "5.1.4 Source Device Behavior upon HPD Pulse Detection"
> > Based on this filtering out short pulses with a
> > duration less than 540 usec is incorrect.
> >
> > To make such adapters work add support for a driver polling on MST
> > inerrupt flags, and wire this up in the i915 driver. The sink can clear
> > an interrupt it raised after 110 ms if the source doesn't respond, so
> > use a 50 ms poll period to avoid missing an interrupt. Polling of the
> > MST interrupt flags is explicitly allowed by the DP specification.
> >
> > This fixes MST probe failures I saw using this adapter and a DELL U2515H
> > monitor.
> >
> > v2:
> > - Fix the wait event timeout for the no-poll case.
> >
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 19 ---
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 15 +++
> > include/drm/drm_dp_mst_helper.h | 1 +
> > 3 files changed, 32 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 5bc72e800b85..4e987a513df8 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -1178,11 +1178,24 @@ static int drm_dp_mst_wait_tx_reply(struct
> > drm_dp_mst_branch *mstb,
> > struct drm_dp_sideband_msg_tx *txmsg)
> > {
> > struct drm_dp_mst_topology_mgr *mgr = mstb->mgr;
> > + unsigned long wait_timeout = msecs_to_jiffies(4000);
> > + unsigned long wait_expires = jiffies + wait_timeout;
> > int ret;
> >
> > - ret = wait_event_timeout(mgr->tx_waitq,
> > -check_txmsg_state(mgr, txmsg),
> > -(4 * HZ));
> > + for (;;) {
> > + ret = wait_event_timeout(mgr->tx_waitq,
> > +check_txmsg_state(mgr, txmsg),
> > +mgr->cbs->update_hpd_irq_state ?
> > + msecs_to_jiffies(50) :
> > + wait_timeout);
> > +
> > + if (ret || !mgr->cbs->update_hpd_irq_state ||
> > + time_after(jiffies, wait_expires))
> > + break;
>
> First I thought this was changing the behaviour when the callback
> isn't provided, but then I noticed the ?: stuff for the timeout.
>
> I think this stuff deserves a comment to explain why we would
> ever do such a thing instead of simply waiting like we did before.
Ok, will add a compact form of the commit log explanation.
>
> > +
> > + mgr->cbs->update_hpd_irq_state(mgr);
> > + }
> > +
> > mutex_lock(>qlock);
> > if (ret > 0) {
> > if (txmsg->state == DRM_DP_SIDEBAND_TX_TIMEOUT) {
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index d18b406f2a7d..1ff7d0096262 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -765,8 +765,23 @@ static struct drm_connector
> > *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
> > return NULL;
> > }
> >
> > +static void
> > +intel_dp_mst_update_hpd_irq_state(struct drm_dp_mst_topology_mgr *mgr)
> > +{
> > + struct intel_dp *intel_dp = container_of(mgr, struct intel_dp, mst_mgr);
> > + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > + struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> > +
> > + spin_lock_irq(>irq_lock);
> > + i915->hotplug.short_port_mask |= BIT(dig_port->base.port);
> > + spin_unlock_irq(>irq_lock);
> > +
> > + queue_work(i915->hotplug.dp_wq, >hotplug.dig_port_work);
>
> I might suggest putting this code right next to intel_hpd_irq_handler()
> so that people can actually see it when working on the hotplug code.
Ok.
>
> > +}
> > +
> > static const struct drm_dp_mst_topology_cbs mst_cbs = {
> > .add_connector = intel_dp_add_mst_connector,
> > + .update_hpd_irq_state = intel_dp_mst_update_hpd_irq_state,
> > };
> >
> > static struct intel_dp_mst_encoder *
> > diff --git
Re: [Intel-gfx] [PATCH v3 01/15] drm/i915/rkl: Set transcoder mask properly
On Wed, Jun 03, 2020 at 02:15:15PM -0700, Matt Roper wrote:
> Although we properly captured RKL's three pipes in the device info
> structure, we forgot to make the corresponding update to the transcoder
> mask. Set this field so that our transcoder loops will operate
> properly.
>
> Fixes: 123f62de419f ("drm/i915/rkl: Add RKL platform info and PCI ids")
> Signed-off-by: Matt Roper
Matches what I see in the spec.
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_pci.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 07b09af3a9c3..0ed586ee2047 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -881,6 +881,8 @@ static const struct intel_device_info rkl_info = {
> GEN12_FEATURES,
> PLATFORM(INTEL_ROCKETLAKE),
> .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C),
> + .cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) | \
> + BIT(TRANSCODER_C),
> .require_force_probe = 1,
> .engine_mask =
> BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0),
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915/gt: Track if an engine requires forcewake w/a
Sometimes an engine might need to keep forcewake active while it is busy
submitting requests for a particular workaround. Track such nuisance
with engine->fw_domain.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
Cc: Venkata Sandeep Dhanalakota
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 11 +++
drivers/gpu/drm/i915/gt/intel_lrc.c | 4
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 2b6cdf47d428..073c3769e8cc 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -24,6 +24,7 @@
#include "i915_selftest.h"
#include "intel_sseu.h"
#include "intel_timeline_types.h"
+#include "intel_uncore.h"
#include "intel_wakeref.h"
#include "intel_workarounds_types.h"
@@ -313,6 +314,16 @@ struct intel_engine_cs {
u32 context_size;
u32 mmio_base;
+ /*
+* Some w/a require forcewake to be held (which prevents RC6) while
+* a particular engine is active. If so, we set fw_domain to which
+* domains need to be held for the duration of request activity,
+* and 0 if none. We try to limit the duration of the hold as much
+* as possible.
+*/
+ enum forcewake_domains fw_domain;
+ atomic_t fw_active;
+
unsigned long context_tag;
struct rb_node uabi_node;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index aac8da18694f..33b7173b7195 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1373,6 +1373,8 @@ __execlists_schedule_in(struct i915_request *rq)
ce->lrc.ccid |= engine->execlists.ccid;
__intel_gt_pm_get(engine->gt);
+ if (engine->fw_domain && !atomic_fetch_inc(>fw_active))
+ intel_uncore_forcewake_get(engine->uncore, engine->fw_domain);
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
intel_engine_context_in(engine);
@@ -1441,6 +1443,8 @@ __execlists_schedule_out(struct i915_request *rq,
intel_context_update_runtime(ce);
intel_engine_context_out(engine);
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_OUT);
+ if (engine->fw_domain && !atomic_dec_return(>fw_active))
+ intel_uncore_forcewake_put(engine->uncore, engine->fw_domain);
intel_gt_pm_put_async(engine->gt);
/*
--
2.20.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: Trim set_timer_ms() intervals
== Series Details ==
Series: drm/i915: Trim set_timer_ms() intervals
URL : https://patchwork.freedesktop.org/series/78002/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8583 -> Patchwork_17871
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17871/index.html
Known issues
Here are the changes found in Patchwork_17871 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-rte:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-tgl-y/igt@i915_pm_...@basic-rte.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17871/fi-tgl-y/igt@i915_pm_...@basic-rte.html
Possible fixes
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [DMESG-WARN][3] ([i915#95]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17871/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
Warnings
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][5] ([i915#62] / [i915#92]) ->
[DMESG-WARN][6] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17871/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][7] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][8] ([i915#62] / [i915#92]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17871/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (50 -> 44)
--
Additional (1): fi-kbl-7560u
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8583 -> Patchwork_17871
CI-20190529: 20190529
CI_DRM_8583: e147ef9bced964b97283851a519aea132a5613e6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5695: 53e8c878a6fb5708e63c99403691e8960b86ea9c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17871: 5e06d688ea6b95e0bbeaf12390351a259dfb391c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
5e06d688ea6b drm/i915: Trim set_timer_ms() intervals
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17871/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Reset link params on connector disconnect
On Wed, Jun 03, 2020 at 05:23:59PM -0700, Manasi Navare wrote:
> We have noticed that when link training fails the panel
> sends a long pulse indicating connector disconnect. In this case
> we need to reset the link parameters instead of continuing
> to use the fallback parameters since else this long pulse
> by the panel followed by a modeset request which was triggered by the
> userspace
> before getting the connector status as disconnected, will
> result into a modeset now using lower link rate/lane count values.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1385
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 28 +
> 1 file changed, 19 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 55fda074c0ad..f7af372647dd 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6111,6 +6111,18 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
> intel_dp->edid_quirks = 0;
> }
>
> +static void
> +intel_dp_reset_link_params(struct intel_dp *intel_dp)
> +{
> + /* Initial max link lane count */
> + intel_dp->max_link_lane_count =
> intel_dp_max_common_lane_count(intel_dp);
> +
> + /* Initial max link rate */
> + intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> +
> + intel_dp->reset_link_params = false;
> +}
> +
> static int
> intel_dp_detect(struct drm_connector *connector,
> struct drm_modeset_acquire_ctx *ctx,
> @@ -6139,6 +6151,11 @@ intel_dp_detect(struct drm_connector *connector,
> memset(_dp->compliance, 0, sizeof(intel_dp->compliance));
> memset(intel_dp->dsc_dpcd, 0, sizeof(intel_dp->dsc_dpcd));
>
> + /*Reset the immutable VRR Capable property */
> + drm_connector_set_vrr_capable_property(connector,
> +false);
> + intel_dp_reset_link_params(intel_dp);
> +
Why would we care what those are when the sink is disconnected?
> if (intel_dp->is_mst) {
> drm_dbg_kms(_priv->drm,
> "MST device may have disappeared %d vs
> %d\n",
> @@ -6152,15 +6169,8 @@ intel_dp_detect(struct drm_connector *connector,
> goto out;
> }
>
> - if (intel_dp->reset_link_params) {
> - /* Initial max link lane count */
> - intel_dp->max_link_lane_count =
> intel_dp_max_common_lane_count(intel_dp);
> -
> - /* Initial max link rate */
> - intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> -
> - intel_dp->reset_link_params = false;
> - }
> + if (intel_dp->reset_link_params)
> + intel_dp_reset_link_params(intel_dp);
>
> intel_dp_print_rates(intel_dp);
>
> --
> 2.19.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915/gt: Track if an engine requires forcewake w/a
Sometimes an engine might need to keep forcewake active while it is busy
submitting requests for a particular workaround. Track such nuisance
with engine->fw_domain.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
Cc: Venkata Sandeep Dhanalakota
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 10 ++
drivers/gpu/drm/i915/gt/intel_lrc.c | 4
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 2b6cdf47d428..28b70c13d691 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -24,6 +24,7 @@
#include "i915_selftest.h"
#include "intel_sseu.h"
#include "intel_timeline_types.h"
+#include "intel_uncore.h"
#include "intel_wakeref.h"
#include "intel_workarounds_types.h"
@@ -313,6 +314,15 @@ struct intel_engine_cs {
u32 context_size;
u32 mmio_base;
+ /*
+* Some w/a require forcewake to be held (which prevents RC6) while
+* a particular engine is active. If so, we set fw_domain to which
+* domains need to be held for the duration of request activity,
+* and 0 if none.
+*/
+ enum forcewake_domains fw_domain;
+ unsigned int fw_active;
+
unsigned long context_tag;
struct rb_node uabi_node;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index aac8da18694f..3de3a357074e 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1373,6 +1373,8 @@ __execlists_schedule_in(struct i915_request *rq)
ce->lrc.ccid |= engine->execlists.ccid;
__intel_gt_pm_get(engine->gt);
+ if (!engine->fw_active++ && engine->fw_domain)
+ intel_uncore_forcewake_get(engine->uncore, engine->fw_domain);
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
intel_engine_context_in(engine);
@@ -1441,6 +1443,8 @@ __execlists_schedule_out(struct i915_request *rq,
intel_context_update_runtime(ce);
intel_engine_context_out(engine);
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_OUT);
+ if (!--engine->fw_active && engine->fw_domain)
+ intel_uncore_forcewake_put(engine->uncore, engine->fw_domain);
intel_gt_pm_put_async(engine->gt);
/*
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/dp_mst: Work around out-of-spec adapters filtering short pulses
On Thu, Jun 04, 2020 at 01:18:59AM +0300, Imre Deak wrote:
> Some TypeC -> native DP adapters, at least the Club CAC-1557 adapter,
> incorrectly filter out HPD short pulses with a duration less than ~540
> usec, leading to MST probe failures.
>
> According to the DP alt mode specification adapters should forward short
> pulses with a duration greater than 250 usec. According to the DP
> specificatin DP sources should detect short pulses in the
> 500 usec -> 2 ms range.
IIRC it was 250 usec -> 2 ms as well in the DP spec.
500 usec -> 1 ms is the duration of the short hpd
the signalling side should use.
> Based on this filtering out short pulses with a
> duration less than 540 usec is incorrect.
>
> To make such adapters work add support for a driver polling on MST
> inerrupt flags, and wire this up in the i915 driver. The sink can clear
> an interrupt it raised after 110 ms if the source doesn't respond, so
> use a 50 ms poll period to avoid missing an interrupt. Polling of the
> MST interrupt flags is explicitly allowed by the DP specification.
>
> This fixes MST probe failures I saw using this adapter and a DELL U2515H
> monitor.
>
> v2:
> - Fix the wait event timeout for the no-poll case.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 19 ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 15 +++
> include/drm/drm_dp_mst_helper.h | 1 +
> 3 files changed, 32 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 5bc72e800b85..4e987a513df8 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1178,11 +1178,24 @@ static int drm_dp_mst_wait_tx_reply(struct
> drm_dp_mst_branch *mstb,
> struct drm_dp_sideband_msg_tx *txmsg)
> {
> struct drm_dp_mst_topology_mgr *mgr = mstb->mgr;
> + unsigned long wait_timeout = msecs_to_jiffies(4000);
> + unsigned long wait_expires = jiffies + wait_timeout;
> int ret;
>
> - ret = wait_event_timeout(mgr->tx_waitq,
> - check_txmsg_state(mgr, txmsg),
> - (4 * HZ));
> + for (;;) {
> + ret = wait_event_timeout(mgr->tx_waitq,
> + check_txmsg_state(mgr, txmsg),
> + mgr->cbs->update_hpd_irq_state ?
> + msecs_to_jiffies(50) :
> + wait_timeout);
> +
> + if (ret || !mgr->cbs->update_hpd_irq_state ||
> + time_after(jiffies, wait_expires))
> + break;
First I thought this was changing the behaviour when the callback
isn't provided, but then I noticed the ?: stuff for the timeout.
I think this stuff deserves a comment to explain why we would
ever do such a thing instead of simply waiting like we did before.
> +
> + mgr->cbs->update_hpd_irq_state(mgr);
> + }
> +
> mutex_lock(>qlock);
> if (ret > 0) {
> if (txmsg->state == DRM_DP_SIDEBAND_TX_TIMEOUT) {
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index d18b406f2a7d..1ff7d0096262 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -765,8 +765,23 @@ static struct drm_connector
> *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
> return NULL;
> }
>
> +static void
> +intel_dp_mst_update_hpd_irq_state(struct drm_dp_mst_topology_mgr *mgr)
> +{
> + struct intel_dp *intel_dp = container_of(mgr, struct intel_dp, mst_mgr);
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> +
> + spin_lock_irq(>irq_lock);
> + i915->hotplug.short_port_mask |= BIT(dig_port->base.port);
> + spin_unlock_irq(>irq_lock);
> +
> + queue_work(i915->hotplug.dp_wq, >hotplug.dig_port_work);
I might suggest putting this code right next to intel_hpd_irq_handler()
so that people can actually see it when working on the hotplug code.
> +}
> +
> static const struct drm_dp_mst_topology_cbs mst_cbs = {
> .add_connector = intel_dp_add_mst_connector,
> + .update_hpd_irq_state = intel_dp_mst_update_hpd_irq_state,
> };
>
> static struct intel_dp_mst_encoder *
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> index 9e1ffcd7cb68..c902f4380200 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -475,6 +475,7 @@ struct drm_dp_mst_topology_mgr;
> struct drm_dp_mst_topology_cbs {
> /* create a connector for a port */
> struct drm_connector *(*add_connector)(struct drm_dp_mst_topology_mgr
> *mgr, struct drm_dp_mst_port *port, const char
Re: [Intel-gfx] [PATCH 1/3] drm/i915/dp_mst: Fix disabling MST on a port
On Thu, Jun 04, 2020 at 05:55:30PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 04, 2020 at 12:10:38AM +0300, Imre Deak wrote:
> > Currently MST on a port can get enabled/disabled from the hotplug work
> > and get disabled from the short pulse work in a racy way. Fix this by
> > relying on the MST state checking in the hotplug work and just schedule
> > a hotplug work from the short pulse handler if some problem happened
> > during the MST interrupt handling.
> >
> > This removes the explicit MST disabling in case of an AUX failure, but
> > if AUX fails, then probably the detection will also fail during the
> > scheduled hotplug work and it's not guaranteed that we'll see
> > intermittent errors anyway.
> >
> > While at it also simplify the error checking of the MST interrupt
> > handler.
> >
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 33 +++--
> > 1 file changed, 4 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 55fda074c0ad..befbcacddaa1 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -5604,7 +5604,7 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
> > }
> > }
> >
> > - return need_retrain;
> > + return need_retrain ? -EINVAL : 0;
> > }
> >
> > static bool
> > @@ -7255,35 +7255,10 @@ intel_dp_hpd_pulse(struct intel_digital_port
> > *intel_dig_port, bool long_hpd)
> > }
> >
> > if (intel_dp->is_mst) {
> > - switch (intel_dp_check_mst_status(intel_dp)) {
> > - case -EINVAL:
> > - /*
> > -* If we were in MST mode, and device is not
> > -* there, get out of MST mode
> > -*/
> > - drm_dbg_kms(>drm,
> > - "MST device may have disappeared %d vs
> > %d\n",
> > - intel_dp->is_mst,
> > - intel_dp->mst_mgr.mst_state);
> > - intel_dp->is_mst = false;
> > - drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
> > - intel_dp->is_mst);
> > -
> > - return IRQ_NONE;
> > - case 1:
> > - return IRQ_NONE;
> > - default:
> > - break;
> > - }
> > - }
> > -
> > - if (!intel_dp->is_mst) {
> > - bool handled;
> > -
> > - handled = intel_dp_short_pulse(intel_dp);
> > -
> > - if (!handled)
> > + if (intel_dp_check_mst_status(intel_dp) < 0)
> > return IRQ_NONE;
>
> Since we no longer need the tristate return, can you follow up
> with a conversion to bool return? I'd vote to make it match the
> semantics of intel_dp_short_pulse() so we get one step
> closer to unifying the hpd_irq handling across the board.
Ok, makes sense.
>
> > + } else if (!intel_dp_short_pulse(intel_dp)) {
> > + return IRQ_NONE;
> > }
> >
> > return IRQ_HANDLED;
> > --
> > 2.23.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915/params: switch to device specific parameters
Start using device specific parameters instead of module parameters for
most things. The module parameters become the immutable initial values
for i915 parameters. The device specific parameters in i915->params
start life as a copy of i915_modparams. Any later changes are only
reflected in the debugfs.
The stragglers are:
* i915.force_probe and i915.modeset. Needed before dev_priv is
available. This is fine because the parameters are read-only and never
modified.
* i915.verbose_state_checks. Passing dev_priv to I915_STATE_WARN and
I915_STATE_WARN_ON would result in massive and ugly churn. This is
handled by not exposing the parameter via debugfs, and leaving the
parameter writable in sysfs. This may be fixed up in follow-up work.
* i915.inject_probe_failure. Only makes sense in terms of the module,
not the device. This is handled by not exposing the parameter via
debugfs.
Cc: Juha-Pekka Heikkilä
Cc: Venkata Sandeep Dhanalakota
Reviewed-by: Rodrigo Vivi
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_bios.c | 6 ++---
drivers/gpu/drm/i915/display/intel_crt.c | 4 ++--
drivers/gpu/drm/i915/display/intel_csr.c | 6 ++---
drivers/gpu/drm/i915/display/intel_display.c | 12 +-
.../drm/i915/display/intel_display_debugfs.c | 2 +-
.../drm/i915/display/intel_display_power.c| 14 ++--
drivers/gpu/drm/i915/display/intel_dp.c | 8 ---
.../drm/i915/display/intel_dp_aux_backlight.c | 4 ++--
drivers/gpu/drm/i915/display/intel_fbc.c | 12 +-
drivers/gpu/drm/i915/display/intel_lvds.c | 4 ++--
drivers/gpu/drm/i915/display/intel_opregion.c | 2 +-
drivers/gpu/drm/i915/display/intel_panel.c| 4 ++--
drivers/gpu/drm/i915/display/intel_psr.c | 6 ++---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++--
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 3 ++-
drivers/gpu/drm/i915/gt/intel_reset.c | 6 ++---
.../drm/i915/gt/selftest_engine_heartbeat.c | 6 ++---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 15 -
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 +++-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 20 -
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 22 ++-
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_debugfs_params.c| 7 +-
drivers/gpu/drm/i915/i915_drv.c | 9 ++--
drivers/gpu/drm/i915/i915_drv.h | 5 -
drivers/gpu/drm/i915/i915_getparam.c | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 4 ++--
drivers/gpu/drm/i915/intel_gvt.c | 8 +++
drivers/gpu/drm/i915/intel_region_lmem.c | 6 ++---
drivers/gpu/drm/i915/intel_uncore.c | 8 +++
30 files changed, 114 insertions(+), 101 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 839124647202..ec8af2b7bf01 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -479,7 +479,7 @@ parse_sdvo_panel_data(struct drm_i915_private *dev_priv,
struct drm_display_mode *panel_fixed_mode;
int index;
- index = i915_modparams.vbt_sdvo_panel_type;
+ index = dev_priv->params.vbt_sdvo_panel_type;
if (index == -2) {
drm_dbg_kms(_priv->drm,
"Ignore SDVO panel mode from BIOS VBT tables.\n");
@@ -829,9 +829,9 @@ parse_edp(struct drm_i915_private *dev_priv, const struct
bdb_header *bdb)
u8 vswing;
/* Don't read from VBT if module parameter has valid value*/
- if (i915_modparams.edp_vswing) {
+ if (dev_priv->params.edp_vswing) {
dev_priv->vbt.edp.low_vswing =
- i915_modparams.edp_vswing == 1;
+ dev_priv->params.edp_vswing == 1;
} else {
vswing = (edp->edp_vswing_preemph >> (panel_type * 4))
& 0xF;
dev_priv->vbt.edp.low_vswing = vswing == 0;
diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
b/drivers/gpu/drm/i915/display/intel_crt.c
index 2f5b9a4baafd..5b4510ce5693 100644
--- a/drivers/gpu/drm/i915/display/intel_crt.c
+++ b/drivers/gpu/drm/i915/display/intel_crt.c
@@ -833,7 +833,7 @@ intel_crt_detect(struct drm_connector *connector,
connector->base.id, connector->name,
force);
- if (i915_modparams.load_detect_test) {
+ if (dev_priv->params.load_detect_test) {
wakeref = intel_display_power_get(dev_priv,
intel_encoder->power_domain);
goto load_detect;
@@ -889,7 +889,7 @@ intel_crt_detect(struct drm_connector *connector,
else if (INTEL_GEN(dev_priv) < 4)
status =
[Intel-gfx] [PULL] drm-intel-next-fixes
Hi Dave & Daniel, Fixes use-after free on display global state tracking. Then the removal of write bits from sysfs files where changed value is not reflected anywhere. Two scheduler fixes with deps that are Cc: stable. Includes the GVT pull which has two build warning fixes at this time. CI_DINF_194 at https://intel-gfx-ci.01.org/tree/drm-intel-next-fixes/combined-alt.html? Regards, Joonas *** drm-intel-next-fixes-2020-06-04: - Includes gvt-next-fixes-2020-05-28 - Use after free fix for display global state. - Whitelisting context-local timestamp on Gen9 and two scheduler fixes with deps (Cc: stable) - Removal of write flag from sysfs files where ineffective The following changes since commit d96536f0fe699729a0974eb5b65eb0d87cc747e1: drm/i915: Fix AUX power domain toggling across TypeC mode resets (2020-05-19 17:54:07 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2020-06-04 for you to fetch changes up to f8665d797b1ce9bd81f7ed7744ef3a18d6b186ea: Merge tag 'gvt-next-fixes-2020-05-28' of https://github.com/intel/gvt-linux into drm-intel-next-fixes (2020-06-02 16:45:06 +0300) - Includes gvt-next-fixes-2020-05-28 - Use after free fix for display global state. - Whitelisting context-local timestamp on Gen9 and two scheduler fixes with deps (Cc: stable) - Removal of write flag from sysfs files where ineffective Aishwarya Ramakrishnan (1): drm/i915/gvt: Use ARRAY_SIZE for vgpu_types Chris Wilson (9): drm/i915: Don't set queue-priority hint when supressing the reschedule drm/i915/gt: Remove errant assertion in __intel_context_do_pin drm/i915: Disable semaphore inter-engine sync without timeslicing drm/i915: Avoid using rq->engine after free during i915_fence_release drm/i915/gem: Avoid iterating an empty list drm/i915: Reorder await_execution before await_request drm/i915/gt: Do not schedule normal requests immediately along virtual drm/i915: Check for awaits on still currently executing requests drm/i915: Whitelist context-local timestamp in the gen9 cmdparser Jani Nikula (2): drm/i915/params: don't expose inject_probe_failure in debugfs drm/i915/params: fix i915.fake_lmem_start module param sysfs permissions Joonas Lahtinen (1): Merge tag 'gvt-next-fixes-2020-05-28' of https://github.com/intel/gvt-linux into drm-intel-next-fixes Nathan Chancellor (1): drm/i915: Mark check_shadow_context_ppgtt as maybe unused Ville Syrjälä (1): drm/i915: Fix global state use-after-frees with a refcount drivers/gpu/drm/i915/display/intel_global_state.c | 45 ++- drivers/gpu/drm/i915/display/intel_global_state.h | 3 + drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 +- drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 15 +- drivers/gpu/drm/i915/gt/intel_context.c | 2 - drivers/gpu/drm/i915/gvt/vgpu.c | 2 +- drivers/gpu/drm/i915/i915_cmd_parser.c| 4 + drivers/gpu/drm/i915/i915_params.c| 2 +- drivers/gpu/drm/i915/i915_params.h| 2 +- drivers/gpu/drm/i915/i915_request.c | 359 ++ drivers/gpu/drm/i915/i915_scheduler.c | 16 +- 11 files changed, 295 insertions(+), 159 deletions(-) ___ 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: Exercise all copy engines with the blt routines (rev2)
== Series Details == Series: drm/i915/selftests: Exercise all copy engines with the blt routines (rev2) URL : https://patchwork.freedesktop.org/series/77994/ State : success == Summary == CI Bug Log - changes from CI_DRM_8581_full -> Patchwork_17868_full Summary --- **SUCCESS** No regressions found. New tests - New tests have been introduced between CI_DRM_8581_full and Patchwork_17868_full: ### New IGT tests (11) ### * igt@gem_ctx_engines@execute-allforone: - Statuses : 7 pass(s) - Exec time: [0.00, 0.04] s * igt@gem_ctx_engines@execute-one: - Statuses : 6 pass(s) 1 skip(s) - Exec time: [0.20, 4.60] s * igt@gem_ctx_engines@execute-oneforall: - Statuses : 7 pass(s) - Exec time: [0.06, 1.19] s * igt@gem_ctx_engines@idempotent: - Statuses : 6 pass(s) - Exec time: [0.00, 0.01] s * igt@gem_ctx_engines@independent: - Statuses : 1 dmesg-warn(s) 5 pass(s) 1 skip(s) - Exec time: [0.0, 0.32] s * igt@gem_ctx_engines@invalid-engines: - Statuses : 7 pass(s) - Exec time: [0.00, 0.01] s * igt@gem_ctx_shared@create-shared-gtt: - Statuses : 6 pass(s) - Exec time: [2.15, 2.16] s * igt@gem_ctx_shared@detached-shared-gtt: - Statuses : 7 pass(s) - Exec time: [2.15, 2.16] s * igt@gem_ctx_shared@disjoint-timelines: - Statuses : 2 dmesg-warn(s) 4 pass(s) 1 skip(s) - Exec time: [0.0, 0.09] s * igt@gem_ctx_shared@q-smoketest-all: - Statuses : 6 pass(s) 1 skip(s) - Exec time: [0.0, 32.47] s * igt@gem_ctx_shared@single-timeline: - Statuses : 6 pass(s) 1 skip(s) - Exec time: [0.0, 0.03] s Known issues Here are the changes found in Patchwork_17868_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload-with-fault-injection: - shard-tglb: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/shard-tglb8/igt@i915_module_l...@reload-with-fault-injection.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17868/shard-tglb7/igt@i915_module_l...@reload-with-fault-injection.html * igt@kms_big_fb@x-tiled-64bpp-rotate-0: - shard-iclb: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/shard-iclb8/igt@kms_big...@x-tiled-64bpp-rotate-0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17868/shard-iclb3/igt@kms_big...@x-tiled-64bpp-rotate-0.html * igt@kms_big_fb@y-tiled-8bpp-rotate-0: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/shard-apl6/igt@kms_big...@y-tiled-8bpp-rotate-0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17868/shard-apl6/igt@kms_big...@y-tiled-8bpp-rotate-0.html * igt@kms_cursor_edge_walk@pipe-b-256x256-right-edge: - shard-skl: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +6 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/shard-skl5/igt@kms_cursor_edge_w...@pipe-b-256x256-right-edge.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17868/shard-skl9/igt@kms_cursor_edge_w...@pipe-b-256x256-right-edge.html * igt@kms_draw_crc@fill-fb: - shard-snb: [PASS][9] -> [SKIP][10] ([fdo#109271]) +6 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/shard-snb2/igt@kms_draw_...@fill-fb.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17868/shard-snb2/igt@kms_draw_...@fill-fb.html * igt@kms_flip_tiling@flip-yf-tiled: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#108145]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/shard-skl6/igt@kms_flip_til...@flip-yf-tiled.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17868/shard-skl4/igt@kms_flip_til...@flip-yf-tiled.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#93] / [i915#95]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/shard-kbl6/igt@kms_frontbuffer_track...@fbc-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17868/shard-kbl4/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-mmap-cpu: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#49]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/shard-skl6/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-draw-mmap-cpu.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17868/shard-skl4/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-draw-mmap-cpu.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#1188]) [17]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Trace HWSP cachelines
== Series Details ==
Series: drm/i915/gt: Trace HWSP cachelines
URL : https://patchwork.freedesktop.org/series/78000/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8583 -> Patchwork_17870
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17870/index.html
Known issues
Here are the changes found in Patchwork_17870 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [PASS][1] -> [SKIP][2] ([fdo#109271])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-kbl-guc/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17870/fi-kbl-guc/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17870/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
Possible fixes
* {igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1}:
- fi-icl-u2: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17870/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
Warnings
* igt@kms_force_connector_basic@force-connector-state:
- fi-kbl-x1275: [DMESG-WARN][7] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][8] ([i915#62] / [i915#92]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17870/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92]) ->
[DMESG-WARN][10] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8583/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17870/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (50 -> 43)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8583 -> Patchwork_17870
CI-20190529: 20190529
CI_DRM_8583: e147ef9bced964b97283851a519aea132a5613e6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5695: 53e8c878a6fb5708e63c99403691e8960b86ea9c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17870: bb11ec0255995d1b00b7e3b7d4fad4f375d49c6b @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
bb11ec025599 drm/i915/gt: Trace HWSP cachelines
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17870/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/dp_mst: Fix disabling MST on a port
On Thu, Jun 04, 2020 at 12:10:38AM +0300, Imre Deak wrote:
> Currently MST on a port can get enabled/disabled from the hotplug work
> and get disabled from the short pulse work in a racy way. Fix this by
> relying on the MST state checking in the hotplug work and just schedule
> a hotplug work from the short pulse handler if some problem happened
> during the MST interrupt handling.
>
> This removes the explicit MST disabling in case of an AUX failure, but
> if AUX fails, then probably the detection will also fail during the
> scheduled hotplug work and it's not guaranteed that we'll see
> intermittent errors anyway.
>
> While at it also simplify the error checking of the MST interrupt
> handler.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 33 +++--
> 1 file changed, 4 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 55fda074c0ad..befbcacddaa1 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5604,7 +5604,7 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
> }
> }
>
> - return need_retrain;
> + return need_retrain ? -EINVAL : 0;
> }
>
> static bool
> @@ -7255,35 +7255,10 @@ intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port, bool long_hpd)
> }
>
> if (intel_dp->is_mst) {
> - switch (intel_dp_check_mst_status(intel_dp)) {
> - case -EINVAL:
> - /*
> - * If we were in MST mode, and device is not
> - * there, get out of MST mode
> - */
> - drm_dbg_kms(>drm,
> - "MST device may have disappeared %d vs
> %d\n",
> - intel_dp->is_mst,
> - intel_dp->mst_mgr.mst_state);
> - intel_dp->is_mst = false;
> - drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
> - intel_dp->is_mst);
> -
> - return IRQ_NONE;
> - case 1:
> - return IRQ_NONE;
> - default:
> - break;
> - }
> - }
> -
> - if (!intel_dp->is_mst) {
> - bool handled;
> -
> - handled = intel_dp_short_pulse(intel_dp);
> -
> - if (!handled)
> + if (intel_dp_check_mst_status(intel_dp) < 0)
> return IRQ_NONE;
Since we no longer need the tristate return, can you follow up
with a conversion to bool return? I'd vote to make it match the
semantics of intel_dp_short_pulse() so we get one step
closer to unifying the hpd_irq handling across the board.
> + } else if (!intel_dp_short_pulse(intel_dp)) {
> + return IRQ_NONE;
> }
>
> return IRQ_HANDLED;
> --
> 2.23.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915: Trim set_timer_ms() intervals
Use the plain msec_to_jiffies() rather than the _timeout variant so we
round down and do not add an extra jiffy to our interval. For example,
with timeslicing we do not want to err on the longer side as any
fairness depends on catching hogging contexts on the GPU. Bring on
CFS.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 29 +++---
drivers/gpu/drm/i915/i915_utils.c | 2 +-
2 files changed, 13 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 3e35a45d6218..67d74e6432a8 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -1140,9 +1140,17 @@ static struct i915_request *nop_request(struct
intel_engine_cs *engine)
return rq;
}
-static long timeslice_threshold(const struct intel_engine_cs *engine)
+static long slice_timeout(struct intel_engine_cs *engine)
{
- return 2 * msecs_to_jiffies_timeout(timeslice(engine)) + 1;
+ long timeout;
+
+ /* Enough time for a timeslice to kick in, and kick out */
+ timeout = 2 * msecs_to_jiffies_timeout(timeslice(engine));
+
+ /* Enough time for the nop request to complete */
+ timeout += HZ / 5;
+
+ return timeout + 1;
}
static int live_timeslice_queue(void *arg)
@@ -1260,7 +1268,7 @@ static int live_timeslice_queue(void *arg)
}
/* Timeslice every jiffy, so within 2 we should signal */
- if (i915_request_wait(rq, 0, timeslice_threshold(engine)) < 0) {
+ if (i915_request_wait(rq, 0, slice_timeout(engine)) < 0) {
struct drm_printer p =
drm_info_printer(gt->i915->drm.dev);
@@ -1379,7 +1387,7 @@ static int live_timeslice_nopreempt(void *arg)
* allow the maximum priority barrier through. Wait long
* enough to see if it is timesliced in by mistake.
*/
- if (i915_request_wait(rq, 0, timeslice_threshold(engine)) >= 0)
{
+ if (i915_request_wait(rq, 0, slice_timeout(engine)) >= 0) {
pr_err("%s: I915_PRIORITY_BARRIER request completed,
bypassing no-preempt request\n",
engine->name);
err = -EINVAL;
@@ -3890,19 +3898,6 @@ static int live_virtual_mask(void *arg)
return 0;
}
-static long slice_timeout(struct intel_engine_cs *engine)
-{
- long timeout;
-
- /* Enough time for a timeslice to kick in, and kick out */
- timeout = 2 * msecs_to_jiffies_timeout(timeslice(engine));
-
- /* Enough time for the nop request to complete */
- timeout += HZ / 5;
-
- return timeout;
-}
-
static int slicein_virtual_engine(struct intel_gt *gt,
struct intel_engine_cs **siblings,
unsigned int nsibling)
diff --git a/drivers/gpu/drm/i915/i915_utils.c
b/drivers/gpu/drm/i915/i915_utils.c
index e28eae4a8f70..f42a9e9a0b4f 100644
--- a/drivers/gpu/drm/i915/i915_utils.c
+++ b/drivers/gpu/drm/i915/i915_utils.c
@@ -91,7 +91,7 @@ void set_timer_ms(struct timer_list *t, unsigned long timeout)
return;
}
- timeout = msecs_to_jiffies_timeout(timeout);
+ timeout = msecs_to_jiffies(timeout);
/*
* Paranoia to make sure the compiler computes the timeout before
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/22] drm/i915/gem: Async GPU relocations only
Quoting Matthew Auld (2020-06-04 14:37:40) > On Thu, 4 Jun 2020 at 11:38, Chris Wilson wrote: > > > > Reduce the 3 relocation patches down to the single path that accommodates > > all. The primary motivation for this is to guard the relocations with a > > natural fence (derived from the i915_request used to write the > > relocation from the GPU). > > > > The tradeoff in using async gpu relocations is that it increases latency > > over using direct CPU relocations, for the cases where the target is > > idle and accessible by the CPU. The benefit is greatly reduced lock > > contention and improved concurrency by pipelining. > > > > Note that forcing the async gpu relocations does reveal a few issues > > they have. Firstly, is that they are visible as writes to gem_busy, > > causing to mark some buffers are being to written to by the GPU even > > though userspace only reads. Secondly is that, in combination with the > > cmdparser, they can cause priority inversions. This should be the case > > where the work is being put into a common workqueue losing our priority > > information and so being executed in FIFO from the worker, denying us > > the opportunity to reorder the requests afterwards. > > > > Signed-off-by: Chris Wilson > Reviewed-by: Matthew Auld Fwiw, if anyone else is as concerned about the priority inversions via the global system workqueues as am I, we need to teach the CPU scheduler about our priorities. I am considering a per-CPU kthread and plugging them into our scheduling backend. That should be then be applicable to all our async tasks (clflushing, binding, pages, random other tasks). The devil is in the details of course. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/22] drm/i915/gem: Async GPU relocations only
On Thu, 4 Jun 2020 at 11:38, Chris Wilson wrote: > > Reduce the 3 relocation patches down to the single path that accommodates > all. The primary motivation for this is to guard the relocations with a > natural fence (derived from the i915_request used to write the > relocation from the GPU). > > The tradeoff in using async gpu relocations is that it increases latency > over using direct CPU relocations, for the cases where the target is > idle and accessible by the CPU. The benefit is greatly reduced lock > contention and improved concurrency by pipelining. > > Note that forcing the async gpu relocations does reveal a few issues > they have. Firstly, is that they are visible as writes to gem_busy, > causing to mark some buffers are being to written to by the GPU even > though userspace only reads. Secondly is that, in combination with the > cmdparser, they can cause priority inversions. This should be the case > where the work is being put into a common workqueue losing our priority > information and so being executed in FIFO from the worker, denying us > the opportunity to reorder the requests afterwards. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/tgl: Implement WA_16011163337
Quoting clinton.a.tay...@intel.com (2020-06-03 23:11:50) > From: Clint Taylor > > Set GS Timer to 224. Combine with Wa_1604555607 due to register FF_MODE2 > not being able to be read. > > V2: Math issue fixed > > Cc: Chris Wilson > Cc: Caz Yokoyama > Cc: Matt Atwood > Signed-off-by: Clint Taylor Acked-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Trace HWSP cachelines
Trace the acquire/release of individual cachelines within the HWSP, so we can look back in anger. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_timeline.c | 21 + 1 file changed, 21 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c b/drivers/gpu/drm/i915/gt/intel_timeline.c index 4546284fede1..efce02a6d69e 100644 --- a/drivers/gpu/drm/i915/gt/intel_timeline.c +++ b/drivers/gpu/drm/i915/gt/intel_timeline.c @@ -145,6 +145,10 @@ static void __cacheline_retire(struct i915_active *active) struct intel_timeline_cacheline *cl = container_of(active, typeof(*cl), active); + GT_TRACE(cl->hwsp->gt, "cacheline:%08lx retire\n", +i915_ggtt_offset(cl->hwsp->vma) + +ptr_unmask_bits(cl->vaddr, CACHELINE_BITS) * CACHELINE_BYTES); + i915_vma_unpin(cl->hwsp->vma); if (ptr_test_bit(cl->vaddr, CACHELINE_FREE)) __idle_cacheline_free(cl); @@ -156,6 +160,11 @@ static int __cacheline_active(struct i915_active *active) container_of(active, typeof(*cl), active); __i915_vma_pin(cl->hwsp->vma); + + GT_TRACE(cl->hwsp->gt, "cacheline:%08lx active\n", +i915_ggtt_offset(cl->hwsp->vma) + +ptr_unmask_bits(cl->vaddr, CACHELINE_BITS) * CACHELINE_BYTES); + return 0; } @@ -334,6 +343,9 @@ int intel_timeline_pin(struct intel_timeline *tl) __i915_vma_unpin(tl->hwsp_ggtt); } + GT_TRACE(tl->gt, "fence:%llx acquire hwsp:%08x\n", +tl->fence_context, tl->hwsp_offset); + return 0; } @@ -483,6 +495,9 @@ __intel_timeline_get_seqno(struct intel_timeline *tl, if (err) goto err_cacheline; + GT_TRACE(tl->gt, "fence:%llx release hwsp:%08x\n", +tl->fence_context, tl->hwsp_offset); + cacheline_release(tl->hwsp_cacheline); /* ownership now xfered to rq */ cacheline_free(tl->hwsp_cacheline); @@ -501,6 +516,9 @@ __intel_timeline_get_seqno(struct intel_timeline *tl, cacheline_acquire(cl); tl->hwsp_cacheline = cl; + GT_TRACE(tl->gt, "fence:%llx acquire hwsp:%08x\n", +tl->fence_context, tl->hwsp_offset); + *seqno = timeline_advance(tl); GEM_BUG_ON(i915_seqno_passed(*tl->hwsp_seqno, *seqno)); return 0; @@ -576,6 +594,9 @@ void intel_timeline_unpin(struct intel_timeline *tl) if (!atomic_dec_and_test(>pin_count)) return; + GT_TRACE(tl->gt, "fence:%llx release hwsp:%08x\n", +tl->fence_context, tl->hwsp_offset); + cacheline_release(tl->hwsp_cacheline); __i915_vma_unpin(tl->hwsp_ggtt); -- 2.20.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: Exercise all copy engines with the blt routines (rev2)
== Series Details ==
Series: drm/i915/selftests: Exercise all copy engines with the blt routines
(rev2)
URL : https://patchwork.freedesktop.org/series/77994/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8581 -> Patchwork_17868
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17868/index.html
Known issues
Here are the changes found in Patchwork_17868 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17868/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][3] -> [DMESG-WARN][4] ([i915#62] / [i915#92] /
[i915#95])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17868/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
Possible fixes
* {igt@kms_flip@basic-plain-flip@d-dsi1}:
- {fi-tgl-dsi}: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6] +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-tgl-dsi/igt@kms_flip@basic-plain-f...@d-dsi1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17868/fi-tgl-dsi/igt@kms_flip@basic-plain-f...@d-dsi1.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-tgl-y: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17868/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
Warnings
* igt@debugfs_test@read_all_entries:
- fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92]) ->
[DMESG-WARN][10] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-kbl-x1275/igt@debugfs_test@read_all_entries.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17868/fi-kbl-x1275/igt@debugfs_test@read_all_entries.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][12] ([i915#62] / [i915#92]) +8 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17868/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (50 -> 44)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8581 -> Patchwork_17868
CI-20190529: 20190529
CI_DRM_8581: a3ae560b4c2a6dfb0d550cc40471a7b0c7043500 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5694: a9b6c4c74bfddf7d3d2da3be08804fe315945cea @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17868: 9edabff31b225d1b8b4860cf92c7f19a1645c079 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
9edabff31b22 drm/i915/selftests: Exercise all copy engines with the blt routines
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17868/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for sysctl: spring cleaning (rev2)
== Series Details == Series: sysctl: spring cleaning (rev2) URL : https://patchwork.freedesktop.org/series/77780/ State : failure == Summary == Applying: sysctl: add new register_sysctl_subdir() helper error: sha1 information is lacking or useless (include/linux/sysctl.h). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 sysctl: add new register_sysctl_subdir() helper When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/13] fs: move binfmt_misc sysctl to its own file
On 2020/5/29 15:41, Luis Chamberlain wrote:
This moves the binfmt_misc sysctl to its own file to help remove
clutter from kernel/sysctl.c.
Signed-off-by: Luis Chamberlain
---
fs/binfmt_misc.c | 1 +
kernel/sysctl.c | 7 ---
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
index f69a043f562b..656b3f5f3bbf 100644
--- a/fs/binfmt_misc.c
+++ b/fs/binfmt_misc.c
@@ -821,6 +821,7 @@ static int __init init_misc_binfmt(void)
int err = register_filesystem(_fs_type);
if (!err)
insert_binfmt(_format);
+ register_sysctl_empty_subdir("fs", "binfmt_misc");
return err;
}
build error when CONFIG_BINFMT_MISC=m
ERROR: modpost: "register_sysctl_empty_subdir" [fs/binfmt_misc.ko]
undefined!
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 27f0c9ea..4129dfb 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -2853,6 +2853,7 @@ void register_sysctl_empty_subdir(const char *base,
{
register_sysctl_subdir(base, subdir, sysctl_mount_point);
}
+EXPORT_SYMBOL_GPL(register_sysctl_empty_subdir);
#endif /* CONFIG_SYSCTL */
Thanks
Xiaoming Ni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/22] drm/i915: Trim set_timer_ms() intervals
On Thu, 4 Jun 2020 at 11:38, Chris Wilson wrote: > > Use the plain msec_to_jiffies() rather than the _timeout variant so we > round down and do not add an extra jiffy to our interval. For example, > with timeslicing we do not want to err on the longer side as any > fairness depends on catching hogging contexts on the GPU. Bring on > CFS. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Exercise all copy engines with the blt routines (rev2)
== Series Details == Series: drm/i915/selftests: Exercise all copy engines with the blt routines (rev2) URL : https://patchwork.freedesktop.org/series/77994/ State : warning == Summary == $ dim checkpatch origin/drm-tip 9edabff31b22 drm/i915/selftests: Exercise all copy engines with the blt routines -:292: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'engine__' - possible side-effects? #292: FILE: drivers/gpu/drm/i915/i915_drv.h:1267: +#define for_each_uabi_class_engine(engine__, class__, i915__) \ + for ((engine__) = intel_engine_lookup_user((i915__), (class__), 0); \ +(engine__) && (engine__)->uabi_class == (class__); \ +(engine__) = rb_to_uabi_engine(rb_next(&(engine__)->uabi_node))) -:292: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'class__' - possible side-effects? #292: FILE: drivers/gpu/drm/i915/i915_drv.h:1267: +#define for_each_uabi_class_engine(engine__, class__, i915__) \ + for ((engine__) = intel_engine_lookup_user((i915__), (class__), 0); \ +(engine__) && (engine__)->uabi_class == (class__); \ +(engine__) = rb_to_uabi_engine(rb_next(&(engine__)->uabi_node))) total: 0 errors, 0 warnings, 2 checks, 243 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/22] drm/i915/gem: Mark the buffer pool as active for the cmdparser
On Thu, 4 Jun 2020 at 11:38, Chris Wilson wrote:
>
> If the execbuf is interrupted after building the cmdparser pipeline, and
> before we commit to submitting the request to HW, we would attempt to
> clean up the cmdparser early. While we held active references to the vma
> being parsed and constructed, we did not hold an active reference for
> the buffer pool itself. The result was that an interrupted execbuf could
> still have run the cmdparser pipeline, but since the buffer pool was
> idle, its target vma could have been recycled.
>
> Note this problem only occurs if the cmdparser is running async due to
> pipelined waits on busy fences, and the execbuf is interrupted.
>
> Fixes: 686c7c35abc2 ("drm/i915/gem: Asynchronous cmdparser")
> Fixes: 16e87459673a ("drm/i915/gt: Move the batch buffer pool from the engine
> to the gt")
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Exercise all copy engines with the blt routines
Just to remove an obnoxious HAS_ENGINES(), and in the process make the
code agnostic to the availabilty of any particular engine by making it
exercise any and all such engines declared on the system.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Matthew Auld
Cc: Daniele Ceraolo Spurio
Reviewed-by: Matthew Auld
---
.../i915/gem/selftests/i915_gem_client_blt.c | 3 -
.../i915/gem/selftests/i915_gem_object_blt.c | 55 ---
.../gpu/drm/i915/gem/selftests/mock_context.c | 37 +
.../gpu/drm/i915/gem/selftests/mock_context.h | 4 ++
drivers/gpu/drm/i915/i915_drv.h | 5 ++
5 files changed, 80 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
index 8fe3ad2ee34e..299c29e9ad86 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
@@ -702,8 +702,5 @@ int i915_gem_client_blt_live_selftests(struct
drm_i915_private *i915)
if (intel_gt_is_wedged(>gt))
return 0;
- if (!HAS_ENGINE(i915, BCS0))
- return 0;
-
return i915_live_subtests(tests, i915);
}
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
index 31549ad83fa6..23b6e11bbc3e 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
@@ -193,7 +193,7 @@ static int perf_copy_blt(void *arg)
}
struct igt_thread_arg {
- struct drm_i915_private *i915;
+ struct intel_engine_cs *engine;
struct i915_gem_context *ctx;
struct file *file;
struct rnd_state prng;
@@ -203,7 +203,7 @@ struct igt_thread_arg {
static int igt_fill_blt_thread(void *arg)
{
struct igt_thread_arg *thread = arg;
- struct drm_i915_private *i915 = thread->i915;
+ struct intel_engine_cs *engine = thread->engine;
struct rnd_state *prng = >prng;
struct drm_i915_gem_object *obj;
struct i915_gem_context *ctx;
@@ -215,7 +215,7 @@ static int igt_fill_blt_thread(void *arg)
ctx = thread->ctx;
if (!ctx) {
- ctx = live_context(i915, thread->file);
+ ctx = live_context_for_engine(engine, thread->file);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
@@ -223,7 +223,7 @@ static int igt_fill_blt_thread(void *arg)
ctx->sched.priority = I915_USER_PRIORITY(prio);
}
- ce = i915_gem_context_get_engine(ctx, BCS0);
+ ce = i915_gem_context_get_engine(ctx, 0);
GEM_BUG_ON(IS_ERR(ce));
/*
@@ -256,7 +256,7 @@ static int igt_fill_blt_thread(void *arg)
pr_debug("%s with phys_sz= %x, sz=%x, val=%x\n", __func__,
phys_sz, sz, val);
- obj = huge_gem_object(i915, phys_sz, sz);
+ obj = huge_gem_object(engine->i915, phys_sz, sz);
if (IS_ERR(obj)) {
err = PTR_ERR(obj);
goto err_flush;
@@ -321,7 +321,7 @@ static int igt_fill_blt_thread(void *arg)
static int igt_copy_blt_thread(void *arg)
{
struct igt_thread_arg *thread = arg;
- struct drm_i915_private *i915 = thread->i915;
+ struct intel_engine_cs *engine = thread->engine;
struct rnd_state *prng = >prng;
struct drm_i915_gem_object *src, *dst;
struct i915_gem_context *ctx;
@@ -333,7 +333,7 @@ static int igt_copy_blt_thread(void *arg)
ctx = thread->ctx;
if (!ctx) {
- ctx = live_context(i915, thread->file);
+ ctx = live_context_for_engine(engine, thread->file);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
@@ -341,7 +341,7 @@ static int igt_copy_blt_thread(void *arg)
ctx->sched.priority = I915_USER_PRIORITY(prio);
}
- ce = i915_gem_context_get_engine(ctx, BCS0);
+ ce = i915_gem_context_get_engine(ctx, 0);
GEM_BUG_ON(IS_ERR(ce));
/*
@@ -374,7 +374,7 @@ static int igt_copy_blt_thread(void *arg)
pr_debug("%s with phys_sz= %x, sz=%x, val=%x\n", __func__,
phys_sz, sz, val);
- src = huge_gem_object(i915, phys_sz, sz);
+ src = huge_gem_object(engine->i915, phys_sz, sz);
if (IS_ERR(src)) {
err = PTR_ERR(src);
goto err_flush;
@@ -394,7 +394,7 @@ static int igt_copy_blt_thread(void *arg)
if (!(src->cache_coherent & I915_BO_CACHE_COHERENT_FOR_READ))
src->cache_dirty = true;
- dst = huge_gem_object(i915, phys_sz, sz);
+ dst = huge_gem_object(engine->i915, phys_sz, sz);
if (IS_ERR(dst)) {
err =
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/22] drm/i915/gem: Mark the buffer pool as active for the cmdparser
== Series Details ==
Series: series starting with [01/22] drm/i915/gem: Mark the buffer pool as
active for the cmdparser
URL : https://patchwork.freedesktop.org/series/77996/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8581 -> Patchwork_17866
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17866 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17866, 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_17866/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17866:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@gt_engines:
- fi-icl-y: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-icl-y/igt@i915_selftest@live@gt_engines.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17866/fi-icl-y/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2520m: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-snb-2520m/igt@i915_selftest@l...@hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17866/fi-snb-2520m/igt@i915_selftest@l...@hangcheck.html
* igt@runner@aborted:
- fi-snb-2520m: NOTRUN -> [FAIL][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17866/fi-snb-2520m/igt@run...@aborted.html
New tests
-
New tests have been introduced between CI_DRM_8581 and Patchwork_17866:
### New IGT tests (1) ###
* igt@dmabuf@all@dma_fence_proxy:
- Statuses : 41 pass(s)
- Exec time: [0.03, 0.10] s
Known issues
Here are the changes found in Patchwork_17866 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-u2: [PASS][6] -> [DMESG-WARN][7] ([i915#1982])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17866/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-icl-guc: [PASS][8] -> [DMESG-WARN][9] ([i915#1982])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17866/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
Possible fixes
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [DMESG-WARN][10] ([i915#1982]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17866/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][12] ([i915#1982]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-tgl-dsi/igt@kms_flip@basic-plain-f...@d-dsi1.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17866/fi-tgl-dsi/igt@kms_flip@basic-plain-f...@d-dsi1.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-tgl-y: [DMESG-WARN][14] ([i915#1982]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17866/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
Warnings
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][17] ([i915#62] / [i915#92]) +5 similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17866/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-x1275: [DMESG-WARN][18] ([i915#62] / [i915#92]) ->
[DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17866/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
{name}: This element is
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/selftests: Exercise all copy engines with the blt routines
== Series Details == Series: drm/i915/selftests: Exercise all copy engines with the blt routines URL : https://patchwork.freedesktop.org/series/77994/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8581 -> Patchwork_17865 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17865 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17865, 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_17865/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17865: ### IGT changes ### Possible regressions * igt@i915_selftest@live@blt: - fi-cml-u2: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-cml-u2/igt@i915_selftest@l...@blt.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17865/fi-cml-u2/igt@i915_selftest@l...@blt.html - fi-whl-u: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-whl-u/igt@i915_selftest@l...@blt.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17865/fi-whl-u/igt@i915_selftest@l...@blt.html - fi-bxt-dsi: [PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-bxt-dsi/igt@i915_selftest@l...@blt.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17865/fi-bxt-dsi/igt@i915_selftest@l...@blt.html - fi-cfl-8700k: [PASS][7] -> [INCOMPLETE][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-cfl-8700k/igt@i915_selftest@l...@blt.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17865/fi-cfl-8700k/igt@i915_selftest@l...@blt.html - fi-skl-6600u: [PASS][9] -> [INCOMPLETE][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-skl-6600u/igt@i915_selftest@l...@blt.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17865/fi-skl-6600u/igt@i915_selftest@l...@blt.html - fi-cfl-8109u: [PASS][11] -> [INCOMPLETE][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-cfl-8109u/igt@i915_selftest@l...@blt.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17865/fi-cfl-8109u/igt@i915_selftest@l...@blt.html - fi-icl-u2: [PASS][13] -> [INCOMPLETE][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-icl-u2/igt@i915_selftest@l...@blt.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17865/fi-icl-u2/igt@i915_selftest@l...@blt.html - fi-snb-2520m: [PASS][15] -> [INCOMPLETE][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-snb-2520m/igt@i915_selftest@l...@blt.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17865/fi-snb-2520m/igt@i915_selftest@l...@blt.html - fi-icl-y: [PASS][17] -> [INCOMPLETE][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-icl-y/igt@i915_selftest@l...@blt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17865/fi-icl-y/igt@i915_selftest@l...@blt.html - fi-kbl-8809g: [PASS][19] -> [INCOMPLETE][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-kbl-8809g/igt@i915_selftest@l...@blt.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17865/fi-kbl-8809g/igt@i915_selftest@l...@blt.html - fi-apl-guc: [PASS][21] -> [INCOMPLETE][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-apl-guc/igt@i915_selftest@l...@blt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17865/fi-apl-guc/igt@i915_selftest@l...@blt.html - fi-kbl-r: [PASS][23] -> [INCOMPLETE][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-kbl-r/igt@i915_selftest@l...@blt.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17865/fi-kbl-r/igt@i915_selftest@l...@blt.html - fi-skl-guc: [PASS][25] -> [INCOMPLETE][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-skl-guc/igt@i915_selftest@l...@blt.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17865/fi-skl-guc/igt@i915_selftest@l...@blt.html - fi-bdw-5557u: [PASS][27] -> [INCOMPLETE][28] [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-bdw-5557u/igt@i915_selftest@l...@blt.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17865/fi-bdw-5557u/igt@i915_selftest@l...@blt.html - fi-kbl-7500u: [PASS][29] -> [INCOMPLETE][30] [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8581/fi-kbl-7500u/igt@i915_selftest@l...@blt.html [30]:
[Intel-gfx] ✗ Fi.CI.BUILD: failure for devm_drm_dev_alloc, v2 (rev2)
== Series Details == Series: devm_drm_dev_alloc, v2 (rev2) URL : https://patchwork.freedesktop.org/series/75956/ State : failure == Summary == Applying: drm: Add devm_drm_dev_alloc macro error: sha1 information is lacking or useless (drivers/gpu/drm/drm_drv.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm: Add devm_drm_dev_alloc macro When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/22] drm/i915/gem: Mark the buffer pool as active for the cmdparser
== Series Details == Series: series starting with [01/22] drm/i915/gem: Mark the buffer pool as active for the cmdparser URL : https://patchwork.freedesktop.org/series/77996/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1222:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1225:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1228:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1231:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/gem/i915_gem_context.c:2274:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2275:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2276:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2277:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2278:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2279:17: error: bad integer constant expression +drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/sysfs_engines.c:61:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:62:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:66:10: error: bad integer constant expression +drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1425:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1479:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/intel_wakeref.c:137:19: warning: context imbalance in 'wakeref_auto_timeout' - unexpected unlock +drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read16' -
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/22] drm/i915/gem: Mark the buffer pool as active for the cmdparser
== Series Details ==
Series: series starting with [01/22] drm/i915/gem: Mark the buffer pool as
active for the cmdparser
URL : https://patchwork.freedesktop.org/series/77996/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
47e5bfbf30e3 drm/i915/gem: Mark the buffer pool as active for the cmdparser
7ec3c01e7a42 drm/i915: Trim set_timer_ms() intervals
00d105eacda7 drm/i915/gt: Set timeslicing priority from queue
7e77d0a206b9 drm/i915/gt: Always check to enable timeslicing if not submitting
b26c3cc35bd3 Restore "drm/i915: drop engine_pin/unpin_breadcrumbs_irq"
fb7bb70a7283 drm/i915/gt: Couple tasklet scheduling for all CS interrupts
cba96e7cdecf drm/i915/gt: Support creation of 'internal' rings
ce8cae5ec931 drm/i915/gt: Use client timeline address for seqno writes
710e6262e4f4 drm/i915/gt: Infrastructure for ring scheduling
-:79: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#79:
new file mode 100644
total: 0 errors, 1 warnings, 0 checks, 842 lines checked
f5112dc2ae3b drm/i915/gt: Enable busy-stats for ring-scheduler
-:13: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#13:
new file mode 100644
-:200: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.rst
#200: FILE: drivers/gpu/drm/i915/gt/selftest_engine_pm.c:47:
+ udelay(100);
-:230: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.rst
#230: FILE: drivers/gpu/drm/i915/gt/selftest_engine_pm.c:77:
+ udelay(100);
total: 0 errors, 1 warnings, 2 checks, 236 lines checked
d8fa9292586c drm/i915/gt: Track if an engine requires forcewake w/a
2cdc09a8fc16 drm/i915/gt: Implement ring scheduler for gen6/7
-:68: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#68: FILE: drivers/gpu/drm/i915/gt/intel_ring_scheduler.c:324:
+ *cs++ = i915_mmio_reg_offset(
-:70: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#70: FILE: drivers/gpu/drm/i915/gt/intel_ring_scheduler.c:326:
+ *cs++ = _MASKED_BIT_ENABLE(
-:105: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#105: FILE: drivers/gpu/drm/i915/gt/intel_ring_scheduler.c:361:
+ *cs++ = _MASKED_BIT_DISABLE(
total: 0 errors, 0 warnings, 3 checks, 506 lines checked
2ff1bb716df2 drm/i915/gt: Enable ring scheduling for gen6/7
cfed75109fb2 drm/i915/gem: Async GPU relocations only
dd90a9050b61 drm/i915: Add list_for_each_entry_safe_continue_reverse
-:20: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pos' - possible side-effects?
#20: 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))
-:20: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'n' - possible side-effects?
#20: 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))
-:20: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'member' - possible
side-effects?
#20: 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
a5768b96efc5 drm/i915/gem: Separate reloc validation into an earlier step
-:101: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or
return
#101: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1408:
+ return (int)offset;
+ } else {
total: 0 errors, 1 warnings, 0 checks, 217 lines checked
37ab424926eb drm/i915/gem: Lift GPU relocation allocation
38ad7f8804a1 drm/i915/gem: Build the reloc request first
7cb671e36bbd drm/i915/gem: Add all GPU reloc awaits/signals en masse
1f32dc179ff3 dma-buf: Proxy fence, an unsignaled fence placeholder
-:45: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#45:
new file mode 100644
-:438: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#438: FILE:
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/24] Revert "drm/i915/gem: Drop relocation slowpath".
== Series Details == Series: series starting with [01/24] Revert "drm/i915/gem: Drop relocation slowpath". URL : https://patchwork.freedesktop.org/series/77960/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8579_full -> Patchwork_17854_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17854_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17854_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_17854_full: ### IGT changes ### Possible regressions * igt@gem_close@many-handles-one-vma: - shard-glk: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8579/shard-glk7/igt@gem_cl...@many-handles-one-vma.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17854/shard-glk7/igt@gem_cl...@many-handles-one-vma.html - shard-apl: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8579/shard-apl8/igt@gem_cl...@many-handles-one-vma.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17854/shard-apl2/igt@gem_cl...@many-handles-one-vma.html - shard-skl: [PASS][5] -> [FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8579/shard-skl10/igt@gem_cl...@many-handles-one-vma.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17854/shard-skl10/igt@gem_cl...@many-handles-one-vma.html - shard-tglb: [PASS][7] -> [FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8579/shard-tglb2/igt@gem_cl...@many-handles-one-vma.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17854/shard-tglb1/igt@gem_cl...@many-handles-one-vma.html - shard-kbl: [PASS][9] -> [FAIL][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8579/shard-kbl2/igt@gem_cl...@many-handles-one-vma.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17854/shard-kbl4/igt@gem_cl...@many-handles-one-vma.html - shard-iclb: [PASS][11] -> [FAIL][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8579/shard-iclb4/igt@gem_cl...@many-handles-one-vma.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17854/shard-iclb4/igt@gem_cl...@many-handles-one-vma.html * igt@i915_module_load@reload-no-display: - shard-iclb: [PASS][13] -> [INCOMPLETE][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8579/shard-iclb8/igt@i915_module_l...@reload-no-display.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17854/shard-iclb6/igt@i915_module_l...@reload-no-display.html - shard-apl: [PASS][15] -> [INCOMPLETE][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8579/shard-apl2/igt@i915_module_l...@reload-no-display.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17854/shard-apl7/igt@i915_module_l...@reload-no-display.html - shard-tglb: [PASS][17] -> [INCOMPLETE][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8579/shard-tglb6/igt@i915_module_l...@reload-no-display.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17854/shard-tglb3/igt@i915_module_l...@reload-no-display.html - shard-skl: [PASS][19] -> [INCOMPLETE][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8579/shard-skl6/igt@i915_module_l...@reload-no-display.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17854/shard-skl10/igt@i915_module_l...@reload-no-display.html - shard-kbl: [PASS][21] -> [INCOMPLETE][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8579/shard-kbl7/igt@i915_module_l...@reload-no-display.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17854/shard-kbl2/igt@i915_module_l...@reload-no-display.html * igt@i915_selftest@live@gem_contexts: - shard-kbl: [PASS][23] -> [DMESG-WARN][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8579/shard-kbl2/igt@i915_selftest@live@gem_contexts.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17854/shard-kbl4/igt@i915_selftest@live@gem_contexts.html * igt@i915_selftest@mock: - shard-glk: NOTRUN -> [FAIL][25] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17854/shard-glk8/igt@i915_selft...@mock.html - shard-iclb: NOTRUN -> [FAIL][26] [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17854/shard-iclb7/igt@i915_selft...@mock.html - shard-kbl: NOTRUN -> [FAIL][27] [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17854/shard-kbl7/igt@i915_selft...@mock.html - shard-tglb: NOTRUN ->
Re: [Intel-gfx] [PATCH 53/59] drm/arc: Move to drm/tiny
Hi Eugeniy, Apologies, somehow I missed your mail. I looked at the code again, and I think I fumbled something. Does the below diff help to prevent the issues? Thanks, Daniel diff --git a/drivers/gpu/drm/tiny/arcpgu.c b/drivers/gpu/drm/tiny/arcpgu.c index 857812f25bec..33d812a5ad7f 100644 --- a/drivers/gpu/drm/tiny/arcpgu.c +++ b/drivers/gpu/drm/tiny/arcpgu.c @@ -228,6 +228,9 @@ static void arc_pgu_update(struct drm_simple_display_pipe *pipe, struct arcpgu_drm_private *arcpgu; struct drm_gem_cma_object *gem; + if (!pipe->plane.state->fb) + return; + arcpgu = pipe_to_arcpgu_priv(pipe); gem = drm_fb_cma_get_gem_obj(pipe->plane.state->fb, 0); arc_pgu_write(arcpgu, ARCPGU_REG_BUF0_ADDR, gem->paddr); -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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.CHECKPATCH: warning for drm/i915/selftests: Exercise all copy engines with the blt routines
== Series Details == Series: drm/i915/selftests: Exercise all copy engines with the blt routines URL : https://patchwork.freedesktop.org/series/77994/ State : warning == Summary == $ dim checkpatch origin/drm-tip dbd180308199 drm/i915/selftests: Exercise all copy engines with the blt routines -:288: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'engine__' - possible side-effects? #288: FILE: drivers/gpu/drm/i915/i915_drv.h:1267: +#define for_each_uabi_class_engine(engine__, class__, i915__) \ + for ((engine__) = intel_engine_lookup_user((i915__), (class__), 0); \ +(engine__) && (engine__)->uabi_class == (class__); \ +(engine__) = rb_to_uabi_engine(rb_next(&(engine__)->uabi_node))) -:288: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'class__' - possible side-effects? #288: FILE: drivers/gpu/drm/i915/i915_drv.h:1267: +#define for_each_uabi_class_engine(engine__, class__, i915__) \ + for ((engine__) = intel_engine_lookup_user((i915__), (class__), 0); \ +(engine__) && (engine__)->uabi_class == (class__); \ +(engine__) = rb_to_uabi_engine(rb_next(&(engine__)->uabi_node))) total: 0 errors, 0 warnings, 2 checks, 240 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Exercise all copy engines with the blt routines
On 04/06/2020 11:21, Chris Wilson wrote: Just to remove an obnoxious HAS_ENGINES(), and in the process make the code agnostic to the available of any particular engine by making it exercise any and all such engines declared on the system. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Matthew Auld Cc: Daniele Ceraolo Spurio Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 53/59] drm/arc: Move to drm/tiny
Hi Daniel, I've already tested it (and found several issues), so please check my reply here: https://www.mail-archive.com/linux-snps-arc@lists.infradead.org/msg07403.html Not sure why you didn't receive my reply (probably the reason is because it was sent to your @ffwll.ch mail instead of @intel.com one). From: Daniel Vetter Sent: Thursday, June 4, 2020 11:05 To: Alexey Brodkin Cc: Intel Graphics Development; DRI Development; Daniel Vetter; Eugeniy Paltsev; Sam Ravnborg Subject: Re: [PATCH 53/59] drm/arc: Move to drm/tiny On Fri, May 08, 2020 at 08:07:41PM +0200, Daniel Vetter wrote: > On Fri, May 8, 2020 at 3:56 PM Alexey Brodkin > wrote: > > > > Hi Daniel, > > > > > > Looking at this patch series, feels a bit like hand-rolling of bridge > > > > code, badly. We should get away from that. > > > > > > > > Once you have that I think the end result is tiny enough that it can > > > > stay, bridges intergrate quite well into simple display pipe drivers. > > > > > > > > > BTW should I pull that series in my tree and send you a pull-request > > > > > or that kind of change needs to go through another tree? > > > > > > > > > > Also I'd like to test the change we discuss here to make sure stuff > > > > > still works. Once we do that I'll send an update. Any hint on > > > > > when that change needs to be acked/nacked? > > > > > > > > Simplest is if this can all land through drm-misc, is arc not > > > > maintained in there? And there's plenty of time for testing, I'm just > > > > slowly crawling through the tree to get everything polished and > > > > cleaned up in this area. > > > > > > Any updates on testing this pile here? First patch landed now, and I've > > > started to push driver patches. So would be good to get this sorted out > > > too. > > > > Sorry we're in the middle of 2 long weekends so missed this one. > > I guess we'll be able to test it in a week or two from now. > > > > Is that OK? > > This aren't high-priority, so totally ok. As long as you don't land a > driver rewrite and I have to rebase everything :-) Ping for a bit of testing on this stuff ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation https://urldefense.com/v3/__http://blog.ffwll.ch__;!!A4F2R9G_pg!Ncpf9M5g5wUEicELHfzz8syA0c0KogYc2E0tdnXGHGmUwGbROv-vwMDISCh7u6w58Dgs-ws$ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/22] drm/i915/gt: Enable busy-stats for ring-scheduler
Couple up the context in/out accounting to record how long each engine
is busy handling requests. This is exposed to userspace for more accurate
measurements, and also enables our soft-rps timer.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_stats.h | 49 ++
drivers/gpu/drm/i915/gt/intel_lrc.c | 34 +--
.../gpu/drm/i915/gt/intel_ring_scheduler.c| 4 +
drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 90 +++
drivers/gpu/drm/i915/gt/selftest_rps.c| 5 ++
5 files changed, 149 insertions(+), 33 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_stats.h
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_stats.h
b/drivers/gpu/drm/i915/gt/intel_engine_stats.h
new file mode 100644
index ..58491eae3482
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_engine_stats.h
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#ifndef __INTEL_ENGINE_STATS_H__
+#define __INTEL_ENGINE_STATS_H__
+
+#include
+#include
+#include
+
+#include "i915_gem.h" /* GEM_BUG_ON */
+#include "intel_engine.h"
+
+static inline void intel_engine_context_in(struct intel_engine_cs *engine)
+{
+ unsigned long flags;
+
+ if (atomic_add_unless(>stats.active, 1, 0))
+ return;
+
+ write_seqlock_irqsave(>stats.lock, flags);
+ if (!atomic_add_unless(>stats.active, 1, 0)) {
+ engine->stats.start = ktime_get();
+ atomic_inc(>stats.active);
+ }
+ write_sequnlock_irqrestore(>stats.lock, flags);
+}
+
+static inline void intel_engine_context_out(struct intel_engine_cs *engine)
+{
+ unsigned long flags;
+
+ GEM_BUG_ON(!atomic_read(>stats.active));
+
+ if (atomic_add_unless(>stats.active, -1, 1))
+ return;
+
+ write_seqlock_irqsave(>stats.lock, flags);
+ if (atomic_dec_and_test(>stats.active)) {
+ engine->stats.total =
+ ktime_add(engine->stats.total,
+ ktime_sub(ktime_get(), engine->stats.start));
+ }
+ write_sequnlock_irqrestore(>stats.lock, flags);
+}
+
+#endif /* __INTEL_ENGINE_STATS_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index d95b5261f59f..10d83d6327b1 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -139,6 +139,7 @@
#include "i915_vgpu.h"
#include "intel_context.h"
#include "intel_engine_pm.h"
+#include "intel_engine_stats.h"
#include "intel_gt.h"
#include "intel_gt_pm.h"
#include "intel_gt_requests.h"
@@ -1187,39 +1188,6 @@ execlists_context_status_change(struct i915_request *rq,
unsigned long status)
status, rq);
}
-static void intel_engine_context_in(struct intel_engine_cs *engine)
-{
- unsigned long flags;
-
- if (atomic_add_unless(>stats.active, 1, 0))
- return;
-
- write_seqlock_irqsave(>stats.lock, flags);
- if (!atomic_add_unless(>stats.active, 1, 0)) {
- engine->stats.start = ktime_get();
- atomic_inc(>stats.active);
- }
- write_sequnlock_irqrestore(>stats.lock, flags);
-}
-
-static void intel_engine_context_out(struct intel_engine_cs *engine)
-{
- unsigned long flags;
-
- GEM_BUG_ON(!atomic_read(>stats.active));
-
- if (atomic_add_unless(>stats.active, -1, 1))
- return;
-
- write_seqlock_irqsave(>stats.lock, flags);
- if (atomic_dec_and_test(>stats.active)) {
- engine->stats.total =
- ktime_add(engine->stats.total,
- ktime_sub(ktime_get(), engine->stats.start));
- }
- write_sequnlock_irqrestore(>stats.lock, flags);
-}
-
static void
execlists_check_context(const struct intel_context *ce,
const struct intel_engine_cs *engine)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
b/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
index c8cd435d1c51..aaff554865b1 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
@@ -9,6 +9,7 @@
#include "i915_drv.h"
#include "intel_context.h"
+#include "intel_engine_stats.h"
#include "intel_gt.h"
#include "intel_gt_pm.h"
#include "intel_gt_requests.h"
@@ -59,6 +60,7 @@ static struct i915_request *
schedule_in(struct intel_engine_cs *engine, struct i915_request *rq)
{
__intel_gt_pm_get(engine->gt);
+ intel_engine_context_in(engine);
return i915_request_get(rq);
}
@@ -71,6 +73,7 @@ schedule_out(struct intel_engine_cs *engine, struct
i915_request *rq)
intel_engine_add_retire(engine, ce->timeline);
i915_request_put(rq);
+ intel_engine_context_out(engine);
intel_gt_pm_put_async(engine->gt);
}
@@ -747,6 +750,7 @@ int intel_ring_scheduler_setup(struct
[Intel-gfx] [PATCH 19/22] drm/i915/gem: Add all GPU reloc awaits/signals en masse
Asynchronous waits and signaling form a traditional semaphore with all
the usual ordering problems with taking multiple locks. If we want to
add more than one wait on a shared resource by the GPU, we must ensure
that all the associated timelines are advanced atomically, ergo we must
lock all the timelines en masse.
Testcase: igt/gem_exec_reloc/basic-concurrent16
Fixes: 0e97fbb08055 ("drm/i915/gem: Use a single chained reloc batches for a
single execbuf")
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1889
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 114 --
.../i915/gem/selftests/i915_gem_execbuffer.c | 24 ++--
2 files changed, 93 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 4c3461ab8a63..373d5eea7a5a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -259,7 +259,6 @@ struct i915_execbuffer {
bool has_fence : 1;
bool needs_unfenced : 1;
- struct i915_vma *target;
struct i915_request *rq;
struct i915_vma *rq_vma;
u32 *rq_cmd;
@@ -924,7 +923,6 @@ static void reloc_cache_init(struct reloc_cache *cache,
cache->has_fence = cache->gen < 4;
cache->needs_unfenced = INTEL_INFO(i915)->unfenced_needs_alignment;
cache->node.flags = 0;
- cache->target = NULL;
}
static inline void *unmask_page(unsigned long p)
@@ -1057,26 +1055,6 @@ static void reloc_gpu_flush(struct reloc_cache *cache)
i915_request_add(rq);
}
-static int reloc_move_to_gpu(struct i915_request *rq, struct i915_vma *vma)
-{
- struct drm_i915_gem_object *obj = vma->obj;
- int err;
-
- i915_vma_lock(vma);
-
- if (obj->cache_dirty & ~obj->cache_coherent)
- i915_gem_clflush_object(obj, 0);
- obj->write_domain = 0;
-
- err = i915_request_await_object(rq, vma->obj, true);
- if (err == 0)
- err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
-
- i915_vma_unlock(vma);
-
- return err;
-}
-
static int
__reloc_gpu_alloc(struct i915_execbuffer *eb, struct intel_engine_cs *engine)
{
@@ -1166,24 +1144,12 @@ __reloc_gpu_alloc(struct i915_execbuffer *eb, struct
intel_engine_cs *engine)
return err;
}
-static u32 *reloc_batch_grow(struct i915_execbuffer *eb,
-struct i915_vma *vma,
-unsigned int len)
+static u32 *reloc_batch_grow(struct i915_execbuffer *eb, unsigned int len)
{
struct reloc_cache *cache = >reloc_cache;
u32 *cmd;
int err;
- if (vma != cache->target) {
- err = reloc_move_to_gpu(cache->rq, vma);
- if (unlikely(err)) {
- i915_request_set_error_once(cache->rq, err);
- return ERR_PTR(err);
- }
-
- cache->target = vma;
- }
-
if (unlikely(cache->rq_size + len >
PAGE_SIZE / sizeof(u32) - RELOC_TAIL)) {
err = reloc_gpu_chain(cache);
@@ -1229,7 +1195,7 @@ static int __reloc_entry_gpu(struct i915_execbuffer *eb,
else
len = 3;
- batch = reloc_batch_grow(eb, vma, len);
+ batch = reloc_batch_grow(eb, len);
if (IS_ERR(batch))
return PTR_ERR(batch);
@@ -1549,6 +1515,78 @@ static long eb_reloc_vma_validate(struct i915_execbuffer
*eb, struct eb_vma *ev)
return required;
}
+static int reloc_move_to_gpu(struct reloc_cache *cache, struct eb_vma *ev)
+{
+ struct i915_request *rq = cache->rq;
+ struct i915_vma *vma = ev->vma;
+ struct drm_i915_gem_object *obj = vma->obj;
+ int err;
+
+ if (obj->cache_dirty & ~obj->cache_coherent)
+ i915_gem_clflush_object(obj, 0);
+
+ obj->write_domain = I915_GEM_DOMAIN_RENDER;
+ obj->read_domains = I915_GEM_DOMAIN_RENDER;
+
+ err = i915_request_await_object(rq, obj, true);
+ if (err)
+ return err;
+
+ err = __i915_vma_move_to_active(vma, rq);
+ if (err)
+ return err;
+
+ dma_resv_add_excl_fence(vma->resv, >fence);
+
+ return 0;
+}
+
+static int
+lock_relocs(struct i915_execbuffer *eb)
+{
+ struct ww_acquire_ctx acquire;
+ struct eb_vma *ev;
+ int err = 0;
+
+ ww_acquire_init(, _ww_class);
+
+ list_for_each_entry(ev, >relocs, reloc_link) {
+ struct i915_vma *vma = ev->vma;
+
+ err = ww_mutex_lock_interruptible(>resv->lock, );
+ if (err == -EDEADLK) {
+ struct eb_vma *unlock = ev, *en;
+
+ list_for_each_entry_safe_continue_reverse(unlock, en,
+ >relocs,
+
[Intel-gfx] [PATCH 20/22] dma-buf: Proxy fence, an unsignaled fence placeholder
Often we need to create a fence for a future event that has not yet been
associated with a fence. We can store a proxy fence, a placeholder, in
the timeline and replace it later when the real fence is known. Any
listeners that attach to the proxy fence will automatically be signaled
when the real fence completes, and any future listeners will instead be
attach directly to the real fence avoiding any indirection overhead.
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
---
drivers/dma-buf/Makefile | 13 +-
drivers/dma-buf/dma-fence-private.h | 20 +
drivers/dma-buf/dma-fence-proxy.c| 306 +++
drivers/dma-buf/dma-fence.c | 4 +-
drivers/dma-buf/selftests.h | 1 +
drivers/dma-buf/st-dma-fence-proxy.c | 752 +++
include/linux/dma-fence-proxy.h | 38 ++
7 files changed, 1130 insertions(+), 4 deletions(-)
create mode 100644 drivers/dma-buf/dma-fence-private.h
create mode 100644 drivers/dma-buf/dma-fence-proxy.c
create mode 100644 drivers/dma-buf/st-dma-fence-proxy.c
create mode 100644 include/linux/dma-fence-proxy.h
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 995e05f609ff..afaf6dadd9a3 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1,6 +1,12 @@
# SPDX-License-Identifier: GPL-2.0-only
-obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \
-dma-resv.o seqno-fence.o
+obj-y := \
+ dma-buf.o \
+ dma-fence.o \
+ dma-fence-array.o \
+ dma-fence-chain.o \
+ dma-fence-proxy.o \
+ dma-resv.o \
+ seqno-fence.o
obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o
obj-$(CONFIG_DMABUF_HEAPS) += heaps/
obj-$(CONFIG_SYNC_FILE)+= sync_file.o
@@ -10,6 +16,7 @@ obj-$(CONFIG_UDMABUF) += udmabuf.o
dmabuf_selftests-y := \
selftest.o \
st-dma-fence.o \
- st-dma-fence-chain.o
+ st-dma-fence-chain.o \
+ st-dma-fence-proxy.o
obj-$(CONFIG_DMABUF_SELFTESTS) += dmabuf_selftests.o
diff --git a/drivers/dma-buf/dma-fence-private.h
b/drivers/dma-buf/dma-fence-private.h
new file mode 100644
index ..6924d28af0fa
--- /dev/null
+++ b/drivers/dma-buf/dma-fence-private.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Fence mechanism for dma-buf and to allow for asynchronous dma access
+ *
+ * Copyright (C) 2012 Canonical Ltd
+ * Copyright (C) 2012 Texas Instruments
+ *
+ * Authors:
+ * Rob Clark
+ * Maarten Lankhorst
+ */
+
+#ifndef DMA_FENCE_PRIVATE_H
+#define DMA_FENCE_PRIAVTE_H
+
+struct dma_fence;
+
+bool __dma_fence_enable_signaling(struct dma_fence *fence);
+
+#endif /* DMA_FENCE_PRIAVTE_H */
diff --git a/drivers/dma-buf/dma-fence-proxy.c
b/drivers/dma-buf/dma-fence-proxy.c
new file mode 100644
index ..42674e92b0f9
--- /dev/null
+++ b/drivers/dma-buf/dma-fence-proxy.c
@@ -0,0 +1,306 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * dma-fence-proxy: placeholder unsignaled fence
+ *
+ * Copyright (C) 2017-2019 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "dma-fence-private.h"
+
+struct dma_fence_proxy {
+ struct dma_fence base;
+
+ struct dma_fence *real;
+ struct dma_fence_cb cb;
+ struct irq_work work;
+
+ wait_queue_head_t wq;
+};
+
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+#define same_lockclass(A, B) (A)->dep_map.key == (B)->dep_map.key
+#else
+#define same_lockclass(A, B) 0
+#endif
+
+static const char *proxy_get_driver_name(struct dma_fence *fence)
+{
+ struct dma_fence_proxy *p = container_of(fence, typeof(*p), base);
+ struct dma_fence *real = READ_ONCE(p->real);
+
+ return real ? real->ops->get_driver_name(real) : "proxy";
+}
+
+static const char *proxy_get_timeline_name(struct dma_fence *fence)
+{
+ struct dma_fence_proxy *p = container_of(fence, typeof(*p), base);
+ struct dma_fence *real = READ_ONCE(p->real);
+
+ return real ? real->ops->get_timeline_name(real) : "unset";
+}
+
+static void proxy_irq_work(struct irq_work *work)
+{
+ struct dma_fence_proxy *p = container_of(work, typeof(*p), work);
+
+ dma_fence_signal(>base);
+ dma_fence_put(>base);
+}
+
+static void proxy_callback(struct dma_fence *real, struct dma_fence_cb *cb)
+{
+ struct dma_fence_proxy *p = container_of(cb, typeof(*p), cb);
+
+ /* Signaled before enabling signalling callbacks? */
+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >base.flags)) {
+ dma_fence_put(>base);
+ return;
+ }
+
+ if (real->error)
+ dma_fence_set_error(>base, real->error);
+
+ /* Lower the height of the proxy chain -> single stack frame */
+ irq_work_queue(>work);
+}
+
+static bool proxy_enable_signaling(struct dma_fence *fence)
+{
+ struct dma_fence_proxy *p = container_of(fence, typeof(*p), base);
+ struct dma_fence *real = READ_ONCE(p->real);
+ bool ret =
[Intel-gfx] [PATCH 07/22] drm/i915/gt: Support creation of 'internal' rings
To support legacy ring buffer scheduling, we want a virtual ringbuffer
for each client. These rings are purely for holding the requests as they
are being constructed on the CPU and never accessed by the GPU, so they
should not be bound into the GGTT, and we can use plain old WB mapped
pages.
As they are not bound, we need to nerf a few assumptions that a rq->ring
is in the GGTT.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.c| 2 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 17 ++
drivers/gpu/drm/i915/gt/intel_ring.c | 63 ++
drivers/gpu/drm/i915/gt/intel_ring.h | 12 -
drivers/gpu/drm/i915/gt/intel_ring_types.h | 2 +
5 files changed, 57 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index e4aece20bc80..fd71977c010a 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -127,7 +127,7 @@ int __intel_context_do_pin(struct intel_context *ce)
goto err_active;
CE_TRACE(ce, "pin ring:{start:%08x, head:%04x, tail:%04x}\n",
-i915_ggtt_offset(ce->ring->vma),
+intel_ring_address(ce->ring),
ce->ring->head, ce->ring->tail);
smp_mb__before_atomic(); /* flush pin before it is visible */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index e37490d459c2..4b36378af119 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1259,7 +1259,7 @@ static int print_ring(char *buf, int sz, struct
i915_request *rq)
len = scnprintf(buf, sz,
"ring:{start:%08x, hwsp:%08x, seqno:%08x,
runtime:%llums}, ",
- i915_ggtt_offset(rq->ring->vma),
+ intel_ring_address(rq->ring),
tl ? tl->hwsp_offset : 0,
hwsp_seqno(rq),
DIV_ROUND_CLOSEST_ULL(intel_context_get_total_runtime_ns(rq->context),
@@ -1540,7 +1540,7 @@ void intel_engine_dump(struct intel_engine_cs *engine,
print_request(m, rq, "\t\tactive ");
drm_printf(m, "\t\tring->start: 0x%08x\n",
- i915_ggtt_offset(rq->ring->vma));
+ intel_ring_address(rq->ring));
drm_printf(m, "\t\tring->head: 0x%08x\n",
rq->ring->head);
drm_printf(m, "\t\tring->tail: 0x%08x\n",
@@ -1619,13 +1619,6 @@ ktime_t intel_engine_get_busy_time(struct
intel_engine_cs *engine)
return total;
}
-static bool match_ring(struct i915_request *rq)
-{
- u32 ring = ENGINE_READ(rq->engine, RING_START);
-
- return ring == i915_ggtt_offset(rq->ring->vma);
-}
-
struct i915_request *
intel_engine_find_active_request(struct intel_engine_cs *engine)
{
@@ -1665,11 +1658,7 @@ intel_engine_find_active_request(struct intel_engine_cs
*engine)
continue;
if (!i915_request_started(request))
- continue;
-
- /* More than one preemptible request may match! */
- if (!match_ring(request))
- continue;
+ break;
active = request;
break;
diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c
b/drivers/gpu/drm/i915/gt/intel_ring.c
index 8cda1b7e17ba..438637996ab5 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -24,33 +24,42 @@ unsigned int intel_ring_update_space(struct intel_ring
*ring)
int intel_ring_pin(struct intel_ring *ring)
{
struct i915_vma *vma = ring->vma;
- unsigned int flags;
void *addr;
int ret;
if (atomic_fetch_inc(>pin_count))
return 0;
- /* Ring wraparound at offset 0 sometimes hangs. No idea why. */
- flags = PIN_OFFSET_BIAS | i915_ggtt_pin_bias(vma);
+ if (!(ring->flags & INTEL_RING_CREATE_INTERNAL)) {
+ unsigned int pin;
- if (vma->obj->stolen)
- flags |= PIN_MAPPABLE;
- else
- flags |= PIN_HIGH;
+ /* Ring wraparound at offset 0 sometimes hangs. No idea why. */
+ pin |= PIN_OFFSET_BIAS | i915_ggtt_pin_bias(vma);
- ret = i915_ggtt_pin(vma, 0, flags);
- if (unlikely(ret))
- goto err_unpin;
+ if (vma->obj->stolen)
+ pin |= PIN_MAPPABLE;
+ else
+ pin |= PIN_HIGH;
- if (i915_vma_is_map_and_fenceable(vma))
- addr = (void __force *)i915_vma_pin_iomap(vma);
- else
- addr = i915_gem_object_pin_map(vma->obj,
-
[Intel-gfx] [PATCH 16/22] drm/i915/gem: Separate reloc validation into an earlier step
Over the next couple of patches, we will want to lock all the modified
vma for relocation processing under a single ww_mutex. We neither want
to have to include the vma that are skipped (due to no modifications
required) nor do we want those to be marked as written too. So separate
out the reloc validation into an early step, which we can use both to
reject the execbuf before committing to making our changes, and to
filter out the unmodified vma.
This does introduce a second pass through the reloc[], but only if we
need to emit relocations.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 178 +-
1 file changed, 133 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index ae3a3ff3535b..eda770f36b34 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1331,6 +1331,117 @@ static u64
eb_relocate_entry(struct i915_execbuffer *eb,
struct eb_vma *ev,
const struct drm_i915_gem_relocation_entry *reloc)
+{
+ struct eb_vma *target;
+
+ /* we've already hold a reference to all valid objects */
+ target = eb_get_vma(eb, reloc->target_handle);
+ if (unlikely(!target))
+ return -ENOENT;
+
+ /*
+* If the relocation already has the right value in it, no
+* more work needs to be done.
+*/
+ if (gen8_canonical_addr(target->vma->node.start) ==
reloc->presumed_offset)
+ return 0;
+
+ /*
+* If we write into the object, we need to force the synchronisation
+* barrier, either with an asynchronous clflush or if we executed the
+* patching using the GPU (though that should be serialised by the
+* timeline). To be completely sure, and since we are required to
+* do relocations we are already stalling, disable the user's opt
+* out of our synchronisation.
+*/
+ ev->flags &= ~EXEC_OBJECT_ASYNC;
+
+ /* and update the user's relocation entry */
+ return relocate_entry(eb, ev->vma, reloc, target->vma);
+}
+
+static int eb_relocate_vma(struct i915_execbuffer *eb, struct eb_vma *ev)
+{
+#define N_RELOC(x) ((x) / sizeof(struct drm_i915_gem_relocation_entry))
+ struct drm_i915_gem_relocation_entry stack[N_RELOC(512)];
+ const struct drm_i915_gem_exec_object2 *entry = ev->exec;
+ struct drm_i915_gem_relocation_entry __user *urelocs =
+ u64_to_user_ptr(entry->relocs_ptr);
+ unsigned long remain = entry->relocation_count;
+
+ if (unlikely(remain > N_RELOC(ULONG_MAX)))
+ return -EINVAL;
+
+ /*
+* We must check that the entire relocation array is safe
+* to read. However, if the array is not writable the user loses
+* the updated relocation values.
+*/
+ if (unlikely(!access_ok(urelocs, remain * sizeof(*urelocs
+ return -EFAULT;
+
+ do {
+ struct drm_i915_gem_relocation_entry *r = stack;
+ unsigned int count =
+ min_t(unsigned long, remain, ARRAY_SIZE(stack));
+ unsigned int copied;
+
+ /*
+* This is the fast path and we cannot handle a pagefault
+* whilst holding the struct mutex lest the user pass in the
+* relocations contained within a mmaped bo. For in such a case
+* we, the page fault handler would call i915_gem_fault() and
+* we would try to acquire the struct mutex again. Obviously
+* this is bad and so lockdep complains vehemently.
+*/
+ copied = __copy_from_user(r, urelocs, count * sizeof(r[0]));
+ if (unlikely(copied))
+ return -EFAULT;
+
+ remain -= count;
+ do {
+ u64 offset = eb_relocate_entry(eb, ev, r);
+
+ if (likely(offset == 0)) {
+ } else if ((s64)offset < 0) {
+ return (int)offset;
+ } else {
+ /*
+* Note that reporting an error now
+* leaves everything in an inconsistent
+* state as we have *already* changed
+* the relocation value inside the
+* object. As we have not changed the
+* reloc.presumed_offset or will not
+* change the execobject.offset, on the
+* call we may not rewrite the value
+* inside the object, leaving it
+* dangling and causing a GPU hang. Unless
+
[Intel-gfx] [PATCH 13/22] drm/i915/gt: Enable ring scheduling for gen6/7
Switch over from FIFO global submission to the priority-sorted
topographical scheduler. At the cost of more busy work on the CPU to
keep the GPU supplied with the next packet of requests, this allows us
to reorder requests around submission stalls.
This also enables the timer based RPS, with the exception of Valleyview
who's PCU doesn't take kindly to our interference.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 ++
drivers/gpu/drm/i915/gt/intel_rps.c | 6 ++
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index b81978890641..bb57687aea99 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -94,7 +94,7 @@ static int live_nop_switch(void *arg)
rq = i915_request_get(this);
i915_request_add(this);
}
- if (i915_request_wait(rq, 0, HZ / 5) < 0) {
+ if (i915_request_wait(rq, 0, HZ) < 0) {
pr_err("Failed to populated %d contexts\n", nctx);
intel_gt_set_wedged(>gt);
i915_request_put(rq);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 4b36378af119..2312e8313325 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -790,6 +790,8 @@ int intel_engines_init(struct intel_gt *gt)
if (HAS_EXECLISTS(gt->i915))
setup = intel_execlists_submission_setup;
+ else if (INTEL_GEN(gt->i915) >= 6)
+ setup = intel_ring_scheduler_setup;
else
setup = intel_ring_submission_setup;
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 2e4ddc9ca09d..22882c2953da 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -1053,9 +1053,7 @@ static bool gen6_rps_enable(struct intel_rps *rps)
intel_uncore_write_fw(uncore, GEN6_RP_DOWN_TIMEOUT, 5);
intel_uncore_write_fw(uncore, GEN6_RP_IDLE_HYSTERSIS, 10);
- rps->pm_events = (GEN6_PM_RP_UP_THRESHOLD |
- GEN6_PM_RP_DOWN_THRESHOLD |
- GEN6_PM_RP_DOWN_TIMEOUT);
+ rps->pm_events = GEN6_PM_RP_UP_THRESHOLD | GEN6_PM_RP_DOWN_THRESHOLD;
return rps_reset(rps);
}
@@ -1362,7 +1360,7 @@ void intel_rps_enable(struct intel_rps *rps)
GEM_BUG_ON(rps->efficient_freq < rps->min_freq);
GEM_BUG_ON(rps->efficient_freq > rps->max_freq);
- if (has_busy_stats(rps))
+ if (has_busy_stats(rps) && !IS_VALLEYVIEW(i915))
intel_rps_set_timer(rps);
else if (INTEL_GEN(i915) >= 6)
intel_rps_set_interrupts(rps);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
