Re: [Intel-gfx] [PATCH 1/2] drm/mxsfb: Call drm_crtc_vblank_on/off
On Wed, May 27, 2020 at 11:47:56AM +0200, Daniel Vetter wrote: > mxsfb has vblank support, is atomic, but doesn't call > drm_crtc_vblank_on/off as it should. Not good. > > With my next patch to add the drm_crtc_vblank_reset to helpers this > means not even the very first crtc enabling will vblanks work anymore, > since they'll just stay off forever. > > Since mxsfb doesn't have any vblank waits of its own in the > enable/disable flow, nor an enable/disable_vblank callback we can do > the on/off as the first respectively last operation, and it should all > work. > > Signed-off-by: Daniel Vetter > Cc: Marek Vasut > Cc: Stefan Agner > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: Pengutronix Kernel Team > Cc: Fabio Estevam > Cc: NXP Linux Team > Cc: linux-arm-ker...@lists.infradead.org Ping for some ack/review on this one here, it's holding up the subsystem wide fix in patch 2. Thanks, Daniel > --- > drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c > b/drivers/gpu/drm/mxsfb/mxsfb_drv.c > index 497cf443a9af..1891cd6deb2f 100644 > --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c > +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c > @@ -124,6 +124,7 @@ static void mxsfb_pipe_enable(struct > drm_simple_display_pipe *pipe, > drm_panel_prepare(mxsfb->panel); > mxsfb_crtc_enable(mxsfb); > drm_panel_enable(mxsfb->panel); > + drm_crtc_vblank_on(>crtc); > } > > static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe) > @@ -133,6 +134,7 @@ static void mxsfb_pipe_disable(struct > drm_simple_display_pipe *pipe) > struct drm_crtc *crtc = >crtc; > struct drm_pending_vblank_event *event; > > + drm_crtc_vblank_off(>crtc); > drm_panel_disable(mxsfb->panel); > mxsfb_crtc_disable(mxsfb); > drm_panel_unprepare(mxsfb->panel); > -- > 2.26.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: use drm_dev_has_vblank more
For historical reasons it's called dev->num_crtcs, which is rather
confusing ever since kms was added. But now we have a nice helper, so
let's use it for better readability!
Only code change is in atomic helpers: vblank support means that
dev->irq_enabled must be set too. Another one of these quirky things
... But since it's implied we can simplify that check.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 2 +-
drivers/gpu/drm/drm_irq.c | 2 +-
drivers/gpu/drm/drm_vblank.c| 14 +++---
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 85d163f16801..a1898c58ae3c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1097,7 +1097,7 @@ disable_outputs(struct drm_device *dev, struct
drm_atomic_state *old_state)
else if (funcs->dpms)
funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
- if (!(dev->irq_enabled && dev->num_crtcs))
+ if (!drm_dev_has_vblank(dev))
continue;
ret = drm_crtc_vblank_get(crtc);
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 588be45abd7a..09d6e9e2e075 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -181,7 +181,7 @@ int drm_irq_uninstall(struct drm_device *dev)
* vblank/irq handling. KMS drivers must ensure that vblanks are all
* disabled when uninstalling the irq handler.
*/
- if (dev->num_crtcs) {
+ if (drm_dev_has_vblank(dev)) {
spin_lock_irqsave(>vbl_lock, irqflags);
for (i = 0; i < dev->num_crtcs; i++) {
struct drm_vblank_crtc *vblank = >vblank[i];
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 8837bebc7e13..e2beacafaa28 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -604,7 +604,7 @@ void drm_calc_timestamping_constants(struct drm_crtc *crtc,
int linedur_ns = 0, framedur_ns = 0;
int dotclock = mode->crtc_clock;
- if (!dev->num_crtcs)
+ if (!drm_dev_has_vblank(dev))
return;
if (WARN_ON(pipe >= dev->num_crtcs))
@@ -1064,7 +1064,7 @@ void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
unsigned int pipe = drm_crtc_index(crtc);
ktime_t now;
- if (dev->num_crtcs > 0) {
+ if (drm_dev_has_vblank(dev)) {
seq = drm_vblank_count_and_time(dev, pipe, );
} else {
seq = 0;
@@ -1136,7 +1136,7 @@ static int drm_vblank_get(struct drm_device *dev,
unsigned int pipe)
unsigned long irqflags;
int ret = 0;
- if (!dev->num_crtcs)
+ if (!drm_dev_has_vblank(dev))
return -EINVAL;
if (WARN_ON(pipe >= dev->num_crtcs))
@@ -1505,7 +1505,7 @@ static void drm_legacy_vblank_pre_modeset(struct
drm_device *dev,
struct drm_vblank_crtc *vblank = >vblank[pipe];
/* vblank is not initialized (IRQ not installed ?), or has been freed */
- if (!dev->num_crtcs)
+ if (!drm_dev_has_vblank(dev))
return;
if (WARN_ON(pipe >= dev->num_crtcs))
@@ -1532,7 +1532,7 @@ static void drm_legacy_vblank_post_modeset(struct
drm_device *dev,
unsigned long irqflags;
/* vblank is not initialized (IRQ not installed ?), or has been freed */
- if (!dev->num_crtcs)
+ if (!drm_dev_has_vblank(dev))
return;
if (WARN_ON(pipe >= dev->num_crtcs))
@@ -1557,7 +1557,7 @@ int drm_legacy_modeset_ctl_ioctl(struct drm_device *dev,
void *data,
unsigned int pipe;
/* If drm_vblank_init() hasn't been called yet, just no-op */
- if (!dev->num_crtcs)
+ if (!drm_dev_has_vblank(dev))
return 0;
/* KMS drivers handle this internally */
@@ -1895,7 +1895,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
int pipe)
unsigned long irqflags;
bool disable_irq;
- if (WARN_ON_ONCE(!dev->num_crtcs))
+ if (WARN_ON_ONCE(!drm_dev_has_vblank(dev)))
return false;
if (WARN_ON(pipe >= dev->num_crtcs))
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] gvt-next-fixes
Hi, Here's two queued warning fixes for gvt-next. One is for clang warning on debug only function and another one from coccicheck to use ARRAY_SIZE. Thanks -- The following changes since commit 3a36aa237e4ed04553c0998cf5f47eda3e206e4f: drm/i915: Update DRIVER_DATE to 20200515 (2020-05-15 14:49:24 +0300) are available in the Git repository at: https://github.com/intel/gvt-linux tags/gvt-next-fixes-2020-05-28 for you to fetch changes up to cb7ee52284a244fd14caec73df0d49e02891aac4: drm/i915/gvt: Use ARRAY_SIZE for vgpu_types (2020-05-19 17:18:50 +0800) gvt-next-fixes-2020-05-28 - Fix one clang warning on debug only function (Nathan) - Use ARRAY_SIZE for coccicheck warn (Aishwarya) Aishwarya Ramakrishnan (1): drm/i915/gvt: Use ARRAY_SIZE for vgpu_types Nathan Chancellor (1): drm/i915: Mark check_shadow_context_ppgtt as maybe unused drivers/gpu/drm/i915/gvt/scheduler.c | 2 +- drivers/gpu/drm/i915/gvt/vgpu.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Minor link training logic fixes for dp_mst
== Series Details ==
Series: drm/i915: Minor link training logic fixes for dp_mst
URL : https://patchwork.freedesktop.org/series/77716/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8544_full -> Patchwork_17797_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17797_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17797_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_17797_full:
### IGT changes ###
Possible regressions
* igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
- shard-glk: NOTRUN -> [TIMEOUT][1] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17797/shard-glk8/igt@kms_plane_alpha_bl...@pipe-b-alpha-basic.html
* igt@runner@aborted:
- shard-hsw: NOTRUN -> [FAIL][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17797/shard-hsw7/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_17797_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][3] -> [FAIL][4] ([i915#454])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-iclb2/igt@i915_pm...@dc6-psr.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17797/shard-iclb6/igt@i915_pm...@dc6-psr.html
* igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-skl: [PASS][5] -> [INCOMPLETE][6] ([i915#300])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-skl9/igt@kms_cursor_...@pipe-b-cursor-suspend.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17797/shard-skl5/igt@kms_cursor_...@pipe-b-cursor-suspend.html
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-hsw: [PASS][7] -> [DMESG-WARN][8] ([i915#1927])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-hsw2/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17797/shard-hsw7/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html
* igt@kms_cursor_legacy@pipe-b-torture-move:
- shard-iclb: [PASS][9] -> [DMESG-WARN][10] ([i915#128])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-iclb7/igt@kms_cursor_leg...@pipe-b-torture-move.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17797/shard-iclb4/igt@kms_cursor_leg...@pipe-b-torture-move.html
* igt@kms_dp_dsc@basic-dsc-enable-edp:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109349])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17797/shard-iclb6/igt@kms_dp_...@basic-dsc-enable-edp.html
* igt@kms_psr@psr2_cursor_render:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441]) +2 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17797/shard-iclb6/igt@kms_psr@psr2_cursor_render.html
* igt@kms_setmode@basic:
- shard-apl: [PASS][15] -> [FAIL][16] ([i915#31])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-apl2/igt@kms_setm...@basic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17797/shard-apl7/igt@kms_setm...@basic.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +2
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-kbl6/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17797/shard-kbl7/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html
* igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-skl: [PASS][19] -> [INCOMPLETE][20] ([i915#69])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-skl8/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17797/shard-skl8/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html
Possible fixes
* {igt@gem_exec_reloc@basic-concurrent0}:
- shard-glk: [FAIL][21] ([i915#1930]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-glk7/igt@gem_exec_re...@basic-concurrent0.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17797/shard-glk6/igt@gem_exec_re...@basic-concurrent0.html
*
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix global state use-after-frees with a refcount
== Series Details == Series: drm/i915: Fix global state use-after-frees with a refcount URL : https://patchwork.freedesktop.org/series/77715/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8544_full -> Patchwork_17796_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17796_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17796_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_17796_full: ### IGT changes ### Possible regressions * igt@kms_plane_alpha_blend@pipe-b-alpha-basic: - shard-glk: NOTRUN -> [TIMEOUT][1] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17796/shard-glk2/igt@kms_plane_alpha_bl...@pipe-b-alpha-basic.html * igt@runner@aborted: - shard-hsw: NOTRUN -> [FAIL][2] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17796/shard-hsw8/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_17796_full that come from known issues: ### IGT changes ### Issues hit * igt@gen9_exec_parse@allowed-all: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#1436] / [i915#716]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-apl4/igt@gen9_exec_pa...@allowed-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17796/shard-apl7/igt@gen9_exec_pa...@allowed-all.html * igt@kms_big_fb@y-tiled-64bpp-rotate-0: - shard-glk: [PASS][5] -> [FAIL][6] ([i915#1119] / [i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-glk2/igt@kms_big...@y-tiled-64bpp-rotate-0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17796/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-0.html * igt@kms_cursor_crc@pipe-c-cursor-64x64-offscreen: - shard-hsw: [PASS][7] -> [INCOMPLETE][8] ([i915#1927] / [i915#61]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-hsw2/igt@kms_cursor_...@pipe-c-cursor-64x64-offscreen.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17796/shard-hsw8/igt@kms_cursor_...@pipe-c-cursor-64x64-offscreen.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([i915#300]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-skl4/igt@kms_cursor_...@pipe-c-cursor-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17796/shard-skl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-kbl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17796/shard-kbl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109349]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17796/shard-iclb7/igt@kms_dp_...@basic-dsc-enable-edp.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180] / [i915#93] / [i915#95]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-kbl2/igt@kms_frontbuffer_track...@fbc-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17796/shard-kbl3/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#265]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17796/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html * igt@kms_psr@psr2_cursor_render: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-iclb2/igt@kms_psr@psr2_cursor_render.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17796/shard-iclb3/igt@kms_psr@psr2_cursor_render.html * igt@kms_setmode@basic: - shard-apl: [PASS][21] -> [FAIL][22] ([i915#31]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-apl2/igt@kms_setm...@basic.html [22]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Remove local entries from GGTT on suspend (rev3)
== Series Details == Series: drm/i915/gt: Remove local entries from GGTT on suspend (rev3) URL : https://patchwork.freedesktop.org/series/77708/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8544_full -> Patchwork_17795_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17795_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17795_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_17795_full: ### IGT changes ### Possible regressions * igt@kms_plane_alpha_blend@pipe-b-alpha-basic: - shard-glk: NOTRUN -> [TIMEOUT][1] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17795/shard-glk9/igt@kms_plane_alpha_bl...@pipe-b-alpha-basic.html Known issues Here are the changes found in Patchwork_17795_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@engines-mixed-process@vecs0: - shard-skl: [PASS][2] -> [FAIL][3] ([i915#1528]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-skl2/igt@gem_ctx_persistence@engines-mixed-proc...@vecs0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17795/shard-skl3/igt@gem_ctx_persistence@engines-mixed-proc...@vecs0.html * igt@i915_pm_rpm@system-suspend: - shard-hsw: [PASS][4] -> [INCOMPLETE][5] ([i915#151] / [i915#61]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-hsw2/igt@i915_pm_...@system-suspend.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17795/shard-hsw7/igt@i915_pm_...@system-suspend.html * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: [PASS][6] -> [SKIP][7] ([fdo#109349]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17795/shard-iclb5/igt@kms_dp_...@basic-dsc-enable-edp.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu: - shard-tglb: [PASS][8] -> [SKIP][9] ([i915#668]) +6 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-tglb3/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17795/shard-tglb6/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][10] -> [FAIL][11] ([i915#1188]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-skl1/igt@kms_...@bpc-switch-suspend.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17795/shard-skl10/igt@kms_...@bpc-switch-suspend.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-hsw: [PASS][12] -> [INCOMPLETE][13] ([i915#61]) +15 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-hsw7/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17795/shard-hsw1/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][14] -> [FAIL][15] ([fdo#108145] / [i915#265]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17795/shard-skl5/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html * igt@kms_psr@psr2_cursor_render: - shard-iclb: [PASS][16] -> [SKIP][17] ([fdo#109441]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-iclb2/igt@kms_psr@psr2_cursor_render.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17795/shard-iclb5/igt@kms_psr@psr2_cursor_render.html * igt@kms_setmode@basic: - shard-apl: [PASS][18] -> [FAIL][19] ([i915#31]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-apl2/igt@kms_setm...@basic.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17795/shard-apl1/igt@kms_setm...@basic.html * igt@kms_vblank@pipe-b-ts-continuation-suspend: - shard-hsw: [PASS][20] -> [INCOMPLETE][21] ([i915#146] / [i915#61]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-hsw2/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17795/shard-hsw2/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html Possible fixes *
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Minor link training logic fixes for dp_mst
== Series Details == Series: drm/i915: Minor link training logic fixes for dp_mst URL : https://patchwork.freedesktop.org/series/77716/ State : success == Summary == CI Bug Log - changes from CI_DRM_8544 -> Patchwork_17797 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17797/index.html Known issues Here are the changes found in Patchwork_17797 that come from known issues: ### IGT changes ### Possible fixes * igt@kms_chamelium@dp-crc-fast: - fi-icl-u2: [FAIL][1] ([i915#262]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17797/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262 Participating hosts (49 -> 43) -- 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_8544 -> Patchwork_17797 CI-20190529: 20190529 CI_DRM_8544: c6c0a18e985d7a3fd4451e0e786e6522371ea9ee @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5680: f7e3772175c53f0c910f4513831791cb5bdcab04 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17797: d865c402a9c66c553cdf73d076f84cc5b9e017af @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == d865c402a9c6 drm/i915: Minor link training logic fixes for dp_mst == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17797/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1] drm/i915: Minor link training logic fixes for dp_mst
On Wed, May 27, 2020 at 11:49:55PM +0300, Imre Deak wrote:
> On Wed, May 27, 2020 at 11:26:49PM +0300, Imre Deak wrote:
> > On Wed, May 27, 2020 at 11:00:22PM +0300, Stanislav Lisovskiy wrote:
> > > First of all *_needs_link_retraining function should return
> > > false is link_train is set to true but not false.
> > >
> > > Also if we detect channel eq problem when checking mst status
> > > we simply bail out, without setting link_train to false again,
> > > which might end up in a situation that we don't do link retraining
> > > when needed.
> > >
> > > There were some issues, when we had several problems with dp mst
> > > and at the same time the log was floode by messages about
> > > "channel eq not ok, need retraining" however the actual training
> > > seems to be never done.
> > >
> > > Signed-off-by: Stanislav Lisovskiy
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 1768731678a1..9288dc1f8914 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -5627,6 +5627,7 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
> > > drm_dbg_kms(>drm,
> > > "channel EQ not ok, retraining\n");
> > > need_retrain = true;
> > > + intel_dp->link_trained = false;
> > > }
> > >
> > > drm_dbg_kms(>drm, "got esi %3ph\n", esi);
> > > @@ -5654,7 +5655,7 @@ intel_dp_needs_link_retrain(struct intel_dp
> > > *intel_dp)
> > > {
> > > u8 link_status[DP_LINK_STATUS_SIZE];
> > >
> > > - if (!intel_dp->link_trained)
> > > + if (intel_dp->link_trained)
> >
> > intel_dp->link_trained is set when we trained the link during a modeset,
> > it doesn't mean that the link status is good, as you seem to interpret
> > it. With this change I don't see how we would retrain the link when this
> > is called from intel_dp_short_pulse(). Could you describe more the
> > failing scenario?
>
> One reason we wouldn't retrain when needed is that the sink is not seen
> as connected in intel_dp_retrain_link().
But mst is always connected. So maybe intel_dp_needs_link_retrain() does
an early return because intel_dp_get_link_status() or
intel_dp_link_params_valid() fails?
>
> >
> > > return false;
> > >
> > > /*
> > > --
> > > 2.24.1.485.gad05a3d8e5
> > >
> > ___
> > 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 mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1] drm/i915: Minor link training logic fixes for dp_mst
On Wed, May 27, 2020 at 11:00:22PM +0300, Stanislav Lisovskiy wrote:
> First of all *_needs_link_retraining function should return
> false is link_train is set to true but not false.
>
> Also if we detect channel eq problem when checking mst status
> we simply bail out, without setting link_train to false again,
> which might end up in a situation that we don't do link retraining
> when needed.
>
> There were some issues, when we had several problems with dp mst
> and at the same time the log was floode by messages about
> "channel eq not ok, need retraining" however the actual training
> seems to be never done.
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 1768731678a1..9288dc1f8914 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5627,6 +5627,7 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
> drm_dbg_kms(>drm,
> "channel EQ not ok, retraining\n");
> need_retrain = true;
> + intel_dp->link_trained = false;
> }
>
> drm_dbg_kms(>drm, "got esi %3ph\n", esi);
> @@ -5654,7 +5655,7 @@ intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
> {
> u8 link_status[DP_LINK_STATUS_SIZE];
>
> - if (!intel_dp->link_trained)
> + if (intel_dp->link_trained)
This is not correct. Since link_trained is set when link training is completed
as part of a
complete modeset. If link training is not done, like at hotplug, then in that
case we should
not retrain since the pipe has not been configured for this new hotplug and
link training
has not been done.
Retraining is expected to happen only in cases where there is a short pulse or
a spurious long pulse
when link training through modeset is already complete and hence the old logic
of returnin a false
when !intel_dp->link_trained is correct.
Regards
Manasi
> return false;
>
> /*
> --
> 2.24.1.485.gad05a3d8e5
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix global state use-after-frees with a refcount
== Series Details == Series: drm/i915: Fix global state use-after-frees with a refcount URL : https://patchwork.freedesktop.org/series/77715/ State : success == Summary == CI Bug Log - changes from CI_DRM_8544 -> Patchwork_17796 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17796/index.html Known issues Here are the changes found in Patchwork_17796 that come from known issues: ### IGT changes ### Possible fixes * igt@kms_chamelium@dp-crc-fast: - fi-icl-u2: [FAIL][1] ([i915#262]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17796/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [SKIP][3] ([fdo#109271]) -> [FAIL][4] ([i915#62]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17796/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 Participating hosts (49 -> 43) -- 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_8544 -> Patchwork_17796 CI-20190529: 20190529 CI_DRM_8544: c6c0a18e985d7a3fd4451e0e786e6522371ea9ee @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5680: f7e3772175c53f0c910f4513831791cb5bdcab04 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17796: 1fac3818bc7097e659306e2db4a082c9e1099dd2 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 1fac3818bc70 drm/i915: Fix global state use-after-frees with a refcount == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17796/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1] drm/i915: Minor link training logic fixes for dp_mst
On Wed, May 27, 2020 at 11:26:49PM +0300, Imre Deak wrote:
> On Wed, May 27, 2020 at 11:00:22PM +0300, Stanislav Lisovskiy wrote:
> > First of all *_needs_link_retraining function should return
> > false is link_train is set to true but not false.
> >
> > Also if we detect channel eq problem when checking mst status
> > we simply bail out, without setting link_train to false again,
> > which might end up in a situation that we don't do link retraining
> > when needed.
> >
> > There were some issues, when we had several problems with dp mst
> > and at the same time the log was floode by messages about
> > "channel eq not ok, need retraining" however the actual training
> > seems to be never done.
> >
> > Signed-off-by: Stanislav Lisovskiy
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 1768731678a1..9288dc1f8914 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -5627,6 +5627,7 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
> > drm_dbg_kms(>drm,
> > "channel EQ not ok, retraining\n");
> > need_retrain = true;
> > + intel_dp->link_trained = false;
> > }
> >
> > drm_dbg_kms(>drm, "got esi %3ph\n", esi);
> > @@ -5654,7 +5655,7 @@ intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
> > {
> > u8 link_status[DP_LINK_STATUS_SIZE];
> >
> > - if (!intel_dp->link_trained)
> > + if (intel_dp->link_trained)
>
> intel_dp->link_trained is set when we trained the link during a modeset,
> it doesn't mean that the link status is good, as you seem to interpret
> it. With this change I don't see how we would retrain the link when this
> is called from intel_dp_short_pulse(). Could you describe more the
> failing scenario?
One reason we wouldn't retrain when needed is that the sink is not seen
as connected in intel_dp_retrain_link().
>
> > return false;
> >
> > /*
> > --
> > 2.24.1.485.gad05a3d8e5
> >
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Prevent timeslicing into unpreemptible requests (rev4)
== Series Details == Series: drm/i915/gt: Prevent timeslicing into unpreemptible requests (rev4) URL : https://patchwork.freedesktop.org/series/77697/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8544_full -> Patchwork_17794_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17794_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17794_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_17794_full: ### IGT changes ### Possible regressions * igt@kms_plane_alpha_blend@pipe-b-alpha-basic: - shard-glk: NOTRUN -> [TIMEOUT][1] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17794/shard-glk1/igt@kms_plane_alpha_bl...@pipe-b-alpha-basic.html * igt@runner@aborted: - shard-hsw: NOTRUN -> [FAIL][2] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17794/shard-hsw4/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_17794_full that come from known issues: ### IGT changes ### Issues hit * igt@gen9_exec_parse@allowed-all: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#1436] / [i915#716]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-apl4/igt@gen9_exec_pa...@allowed-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17794/shard-apl1/igt@gen9_exec_pa...@allowed-all.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][5] -> [FAIL][6] ([i915#454]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-iclb2/igt@i915_pm...@dc6-psr.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17794/shard-iclb6/igt@i915_pm...@dc6-psr.html * igt@kms_cursor_crc@pipe-b-cursor-size-change: - shard-snb: [PASS][7] -> [SKIP][8] ([fdo#109271]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-snb1/igt@kms_cursor_...@pipe-b-cursor-size-change.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17794/shard-snb1/igt@kms_cursor_...@pipe-b-cursor-size-change.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions: - shard-skl: [PASS][9] -> [FAIL][10] ([IGT#5]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-skl9/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17794/shard-skl10/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html * igt@kms_cursor_legacy@pipe-c-torture-move: - shard-tglb: [PASS][11] -> [DMESG-WARN][12] ([i915#128]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-tglb1/igt@kms_cursor_leg...@pipe-c-torture-move.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17794/shard-tglb6/igt@kms_cursor_leg...@pipe-c-torture-move.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-kbl6/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-c.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17794/shard-kbl4/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-c.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145] / [i915#265]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17794/shard-skl5/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html * igt@kms_psr@psr2_cursor_mmap_cpu: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17794/shard-iclb6/igt@kms_psr@psr2_cursor_mmap_cpu.html * igt@kms_setmode@basic: - shard-apl: [PASS][19] -> [FAIL][20] ([i915#31]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-apl2/igt@kms_setm...@basic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17794/shard-apl2/igt@kms_setm...@basic.html * igt@kms_vblank@pipe-c-ts-continuation-suspend: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-apl8/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html [22]:
Re: [Intel-gfx] [PATCH v1] drm/i915: Minor link training logic fixes for dp_mst
On Wed, May 27, 2020 at 11:00:22PM +0300, Stanislav Lisovskiy wrote:
> First of all *_needs_link_retraining function should return
> false is link_train is set to true but not false.
>
> Also if we detect channel eq problem when checking mst status
> we simply bail out, without setting link_train to false again,
> which might end up in a situation that we don't do link retraining
> when needed.
>
> There were some issues, when we had several problems with dp mst
> and at the same time the log was floode by messages about
> "channel eq not ok, need retraining" however the actual training
> seems to be never done.
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 1768731678a1..9288dc1f8914 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5627,6 +5627,7 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
> drm_dbg_kms(>drm,
> "channel EQ not ok, retraining\n");
> need_retrain = true;
> + intel_dp->link_trained = false;
> }
>
> drm_dbg_kms(>drm, "got esi %3ph\n", esi);
> @@ -5654,7 +5655,7 @@ intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
> {
> u8 link_status[DP_LINK_STATUS_SIZE];
>
> - if (!intel_dp->link_trained)
> + if (intel_dp->link_trained)
intel_dp->link_trained is set when we trained the link during a modeset,
it doesn't mean that the link status is good, as you seem to interpret
it. With this change I don't see how we would retrain the link when this
is called from intel_dp_short_pulse(). Could you describe more the
failing scenario?
> return false;
>
> /*
> --
> 2.24.1.485.gad05a3d8e5
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v1] drm/i915: Minor link training logic fixes for dp_mst
First of all *_needs_link_retraining function should return
false is link_train is set to true but not false.
Also if we detect channel eq problem when checking mst status
we simply bail out, without setting link_train to false again,
which might end up in a situation that we don't do link retraining
when needed.
There were some issues, when we had several problems with dp mst
and at the same time the log was floode by messages about
"channel eq not ok, need retraining" however the actual training
seems to be never done.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_dp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 1768731678a1..9288dc1f8914 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5627,6 +5627,7 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
drm_dbg_kms(>drm,
"channel EQ not ok, retraining\n");
need_retrain = true;
+ intel_dp->link_trained = false;
}
drm_dbg_kms(>drm, "got esi %3ph\n", esi);
@@ -5654,7 +5655,7 @@ intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
{
u8 link_status[DP_LINK_STATUS_SIZE];
- if (!intel_dp->link_trained)
+ if (intel_dp->link_trained)
return false;
/*
--
2.24.1.485.gad05a3d8e5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix global state use-after-frees with a refcount
From: Ville Syrjälä
While the current locking/serialization of the global state
suffices for protecting the obj->state access and the actual
hardware reprogramming, we do have a problem with accessing
the old/new states during nonblocking commits.
The state computation and swap will be protected by the crtc
locks, but the commit_tails can finish out of order, thus also
causing the atomic states to be cleaned up out of order. This
would mean the commit that started first but finished last has
had its new state freed as the no-longer-needed old state by the
other commit.
To fix this let's just refcount the states. obj->state amounts
to one reference, and the intel_atomic_state holds extra references
to both its new and old global obj states.
Fixes: 0ef1905ecf2e ("drm/i915: Introduce better global state handling")
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_global_state.c | 45 ---
.../gpu/drm/i915/display/intel_global_state.h | 3 ++
2 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_global_state.c
b/drivers/gpu/drm/i915/display/intel_global_state.c
index 212d4ee68205..7a19215ad844 100644
--- a/drivers/gpu/drm/i915/display/intel_global_state.c
+++ b/drivers/gpu/drm/i915/display/intel_global_state.c
@@ -10,6 +10,28 @@
#include "intel_display_types.h"
#include "intel_global_state.h"
+static void __intel_atomic_global_state_free(struct kref *kref)
+{
+ struct intel_global_state *obj_state =
+ container_of(kref, struct intel_global_state, ref);
+ struct intel_global_obj *obj = obj_state->obj;
+
+ obj->funcs->atomic_destroy_state(obj, obj_state);
+}
+
+static void intel_atomic_global_state_put(struct intel_global_state *obj_state)
+{
+ kref_put(_state->ref, __intel_atomic_global_state_free);
+}
+
+static struct intel_global_state *
+intel_atomic_global_state_get(struct intel_global_state *obj_state)
+{
+ kref_get(_state->ref);
+
+ return obj_state;
+}
+
void intel_atomic_global_obj_init(struct drm_i915_private *dev_priv,
struct intel_global_obj *obj,
struct intel_global_state *state,
@@ -17,6 +39,10 @@ void intel_atomic_global_obj_init(struct drm_i915_private
*dev_priv,
{
memset(obj, 0, sizeof(*obj));
+ state->obj = obj;
+
+ kref_init(>ref);
+
obj->state = state;
obj->funcs = funcs;
list_add_tail(>head, _priv->global_obj_list);
@@ -28,7 +54,9 @@ void intel_atomic_global_obj_cleanup(struct drm_i915_private
*dev_priv)
list_for_each_entry_safe(obj, next, _priv->global_obj_list, head) {
list_del(>head);
- obj->funcs->atomic_destroy_state(obj, obj->state);
+
+ drm_WARN_ON(_priv->drm, kref_read(>state->ref) != 1);
+ intel_atomic_global_state_put(obj->state);
}
}
@@ -97,10 +125,14 @@ intel_atomic_get_global_obj_state(struct
intel_atomic_state *state,
if (!obj_state)
return ERR_PTR(-ENOMEM);
+ obj_state->obj = obj;
obj_state->changed = false;
+ kref_init(_state->ref);
+
state->global_objs[index].state = obj_state;
- state->global_objs[index].old_state = obj->state;
+ state->global_objs[index].old_state =
+ intel_atomic_global_state_get(obj->state);
state->global_objs[index].new_state = obj_state;
state->global_objs[index].ptr = obj;
obj_state->state = state;
@@ -163,7 +195,9 @@ void intel_atomic_swap_global_state(struct
intel_atomic_state *state)
new_obj_state->state = NULL;
state->global_objs[i].state = old_obj_state;
- obj->state = new_obj_state;
+
+ intel_atomic_global_state_put(obj->state);
+ obj->state = intel_atomic_global_state_get(new_obj_state);
}
}
@@ -172,10 +206,9 @@ void intel_atomic_clear_global_state(struct
intel_atomic_state *state)
int i;
for (i = 0; i < state->num_global_objs; i++) {
- struct intel_global_obj *obj = state->global_objs[i].ptr;
+ intel_atomic_global_state_put(state->global_objs[i].old_state);
+ intel_atomic_global_state_put(state->global_objs[i].new_state);
- obj->funcs->atomic_destroy_state(obj,
-state->global_objs[i].state);
state->global_objs[i].ptr = NULL;
state->global_objs[i].state = NULL;
state->global_objs[i].old_state = NULL;
diff --git a/drivers/gpu/drm/i915/display/intel_global_state.h
b/drivers/gpu/drm/i915/display/intel_global_state.h
index e6163a469029..1f16fa3073c9 100644
--- a/drivers/gpu/drm/i915/display/intel_global_state.h
+++ b/drivers/gpu/drm/i915/display/intel_global_state.h
@@ -6,6 +6,7 @@
#ifndef __INTEL_GLOBAL_STATE_H__
#define __INTEL_GLOBAL_STATE_H__
Re: [Intel-gfx] [PATCH 7/9] drm/shmem-helpers: Redirect mmap for imported dma-buf
On Wed, May 27, 2020 at 8:32 PM Thomas Zimmermann wrote: > > Hi Daniel, > > what's your plan for this patch set? I'd need this patch for the udl > shmem cleanup. I was pinging some people for a tested-by, I kinda don't want to push this entirely untested. I think at least one of the rendering drivers using shmem would be nice to run this on, I've pinged Rob Herring a bit. -Daniel > > Best regards > Thomas > > Am 11.05.20 um 11:35 schrieb Daniel Vetter: > > Currently this seems to work by converting the sgt into a pages array, > > and then treating it like a native object. Do the right thing and > > redirect mmap to the exporter. > > > > With this nothing is calling get_pages anymore on imported dma-buf, > > and we can start to remove the use of the ->pages array for that case. > > > > v2: Rebase > > > > Cc: Gerd Hoffmann > > Cc: Rob Herring > > Cc: Noralf Trønnes > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/drm_gem_shmem_helper.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c > > b/drivers/gpu/drm/drm_gem_shmem_helper.c > > index b9cba5cc61c3..117a7841e284 100644 > > --- a/drivers/gpu/drm/drm_gem_shmem_helper.c > > +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c > > @@ -551,6 +551,9 @@ int drm_gem_shmem_mmap(struct drm_gem_object *obj, > > struct vm_area_struct *vma) > > /* Remove the fake offset */ > > vma->vm_pgoff -= drm_vma_node_start(>vma_node); > > > > + if (obj->import_attach) > > + return dma_buf_mmap(obj->dma_buf, vma, 0); > > + > > shmem = to_drm_gem_shmem_obj(obj); > > > > ret = drm_gem_shmem_get_pages(shmem); > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > -- 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
Re: [Intel-gfx] [RFC PATCH 4/4] drm/i915: Move UC firmware cleanup from driver_release to _remove
Quoting Janusz Krzysztofik (2020-05-18 20:17:20) > UC firmware is stored in a GEM object. Clean it up on driver remove to ^ double whitespace > avoid intel-iommu triggered kernel panic on late DMA unmapping or even > an RPM related warning on object late removal in no IOMMU setups. This is no longer the case after: drm/i915/gem: Lazily acquire the device wakeref for freeing objects Right? > > <4> [93.335282] [ cut here ] > <4> [93.335515] pm_runtime_get_sync() failed: -13 > <4> [93.336056] WARNING: CPU: 6 PID: 200 at > drivers/gpu/drm/i915/intel_runtime_pm.c:361 __intel_runtime_pm_get+0x4d/0x60 > [i915] > <4> [93.336104] Modules linked in: snd_hda_codec_hdmi mei_hdcp i915 > x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul > ghash_clmulni_intel snd_hda_intel cdc_ether snd_intel_dspcfg usbnet > snd_hda_codec mii snd_hwdep snd_hda_core e1000e snd_pcm ptp pps_core mei_me > mei intel_lpss_pci prime_numbers > <4> [93.336268] CPU: 6 PID: 200 Comm: kworker/u16:3 Tainted: G U > 5.7.0-rc4-CI-Trybot_6405+ #1 > <4> [93.336289] Hardware name: Intel Corporation Tiger Lake Client > Platform/TigerLake Y LPDDR4x T4 Crb, BIOS TGLSFWI1.R00.2457.A16.1912270059 > 12/27/2019 > <4> [93.336811] Workqueue: i915 __i915_gem_free_work [i915] > <4> [93.337296] RIP: 0010:__intel_runtime_pm_get+0x4d/0x60 [i915] > <4> [93.337332] Code: ff ff 48 89 df 5b 5d e9 a1 fa ff ff 80 3d 4b 7a 2e 00 > 00 75 e1 89 c6 48 c7 c7 a8 2d 40 a0 c6 05 39 7a 2e 00 01 e8 53 fc e9 e0 <0f> > 0b eb c8 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 41 57 41 > <4> [93.337357] RSP: 0018:c9000144bdd8 EFLAGS: 00010282 > <4> [93.337384] RAX: RBX: 88838ee5bc40 RCX: > 0001 > <4> [93.337409] RDX: 8001 RSI: 88839d264928 RDI: > > <4> [93.337440] RBP: 0001 R08: 88839d264928 R09: > > <4> [93.337467] R10: R11: R12: > 88838ee5bc40 > <4> [93.337493] R13: 0006 R14: 82769a30 R15: > 88839376bab0 > <4> [93.337515] FS: () GS:8883a410() > knlGS: > <4> [93.337542] CS: 0010 DS: ES: CR0: 80050033 > <4> [93.337563] CR2: 55bc19b16ff8 CR3: 0003a11c4005 CR4: > 00760ee0 > <4> [93.337583] PKRU: 5554 > <4> [93.337605] Call Trace: > <4> [93.338148] i915_gem_object_release_mmap+0x23/0x70 [i915] > <4> [93.338665] __i915_gem_free_objects.isra.21+0x10a/0x4b0 [i915] > <4> [93.338741] process_one_work+0x268/0x600 > <4> [93.338785] ? __schedule+0x307/0x8d0 > <4> [93.338878] worker_thread+0x37/0x380 > <4> [93.338929] ? process_one_work+0x600/0x600 > <4> [93.338963] kthread+0x140/0x160 > <4> [93.339006] ? kthread_park+0x80/0x80 > <4> [93.339057] ret_from_fork+0x24/0x50 > <4> [93.339181] irq event stamp: 204220 > <4> [93.339219] hardirqs last enabled at (204219): [] > console_unlock+0x4cd/0x5a0 > <4> [93.339250] hardirqs last disabled at (204220): [] > trace_hardirqs_off_thunk+0x1a/0x1c > <4> [93.339277] softirqs last enabled at (204208): [] > __do_softirq+0x395/0x49e > <4> [93.339307] softirqs last disabled at (204197): [] > irq_exit+0xba/0xc0 > <4> [93.339330] ---[ end trace f066187622b8c484 ]--- > > Signed-off-by: Janusz Krzysztofik Reviewed-by: Michał Winiarski -Michał > --- > drivers/gpu/drm/i915/i915_gem.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 87d3c4f5b6c6..f9d37c7e6d6f 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -1191,6 +1191,8 @@ void i915_gem_driver_remove(struct drm_i915_private > *dev_priv) > > i915_gem_driver_remove__contexts(dev_priv); > > + intel_uc_cleanup_firmwares(_priv->gt.uc); > + > i915_gem_drain_freed_objects(dev_priv); > } > > @@ -1202,7 +1204,6 @@ void i915_gem_driver_release(struct drm_i915_private > *dev_priv) > > intel_wa_list_free(_priv->gt_wa_list); > > - intel_uc_cleanup_firmwares(_priv->gt.uc); > i915_gem_cleanup_userptr(dev_priv); > > i915_gem_drain_freed_objects(dev_priv); > -- > 2.21.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
Re: [Intel-gfx] [RFC PATCH 3/4] drm/i915: Move GGTT cleanup from driver_release to _remove
Quoting Janusz Krzysztofik (2020-05-18 20:17:19)
> GGTT including its scratch page is not cleaned up until driver release.
> Since DMA mappings still exist before scratch page cleanup, unmapping
> them on last device close after the driver has been already removed may
> be judged by intel-iommu code as a bug and result in kernel panic.
>
> Since we abort requests and block user access to hardware on device
> removal, there seems not much sense in still keeping GGTT. Clean it up
> on driver remove. However, skip GGTT address space cleanup as its
> mutext may still be needed if there are objects to be freed. That
> cleanup is always called on address space release after all.
>
> [ 81.290284] [ cut here ]
> [ 81.291602] kernel BUG at drivers/iommu/intel-iommu.c:3591!
> [ 81.293558] invalid opcode: [#1] PREEMPT SMP
> [ 81.294695] CPU: 0 PID: 207 Comm: core_hotunplug Tainted: G U
> 5.4.17 #2
> [ 81.296579] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
> [ 81.297959] RIP: 0010:intel_unmap+0x200/0x230
> [ 81.299015] Code: 00 e8 e4 45 c5 ff 85 c0 74 09 80 3d 2b 84 c0 00 00 74 19
> 65 ff 0d 78 9a b2 7e 0f 85 fa fe ff ff e8 95 57 b1 ff e9 f0 fe ff ff <0f> 0b
> e8 19 4c c5 ff 85 c0 75 de 48 c7 c2 48 d2 e1 81 be 57 00 00
> [ 81.303425] RSP: 0018:c913fda0 EFLAGS: 00010246
> [ 81.304683] RAX: RBX: 8882228dd0b0 RCX:
>
> [ 81.306384] RDX: 1000 RSI: af801000 RDI:
> 8882228dd0b0
> [ 81.308086] RBP: R08: R09:
>
> [ 81.309788] R10: R11: R12:
> af801000
> [ 81.311489] R13: 888223a0 R14: 1000 R15:
> 888223a0a2e8
> [ 81.313191] FS: 7f5408e3c940() GS:88822860()
> knlGS:
> [ 81.315116] CS: 0010 DS: ES: CR0: 80050033
> [ 81.316495] CR2: 01fc0048 CR3: 00022464a000 CR4:
> 06b0
> [ 81.318196] Call Trace:
> [ 81.318967] cleanup_scratch_page+0x44/0x80 [i915]
> [ 81.320281] i915_ggtt_driver_release+0x15b/0x220 [i915]
> [ 81.321717] i915_driver_release+0x33/0x90 [i915]
> [ 81.322856] drm_release+0xbc/0xd0
> [ 81.323691] __fput+0xcd/0x260
> [ 81.324447] task_work_run+0x90/0xc0
> [ 81.325323] do_syscall_64+0x3da/0x560
> [ 81.326240] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 81.327457] RIP: 0033:0x7f54096ecba3
> [ 81.328332] Code: 00 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80
> 00 00 00 00 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 03 00 00 00 0f 05 <48> 3d
> 00 f0 ff ff 77 45 c3 0f 1f 40 00 48 83 ec 18 89 7c 24 0c e8
> [ 81.332741] RSP: 002b:7ffcc5165698 EFLAGS: 0246 ORIG_RAX:
> 0003
> [ 81.334546] RAX: RBX: RCX:
> 7f54096ecba3
> [ 81.336247] RDX: 005cc5d0 RSI: 0005 RDI:
> 0004
> [ 81.337949] RBP: 0003 R08: 005b8014 R09:
> 0004
> [ 81.339650] R10: 005cc650 R11: 0246 R12:
> 004022f0
> [ 81.341352] R13: 7ffcc5165850 R14: R15:
>
> [ 81.343059] Modules linked in: i915 mfd_core intel_gtt prime_numbers
> [ 81.345015] ---[ end trace 010aae55e56f8998 ]---
>
> Signed-off-by: Janusz Krzysztofik
>
> drm/i915: Defer GGTT vm address space fini to vm release
Hum?
>
> Signed-off-by: Janusz Krzysztofik
> ---
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 13 +
> drivers/gpu/drm/i915/gt/intel_gtt.h | 1 +
> drivers/gpu/drm/i915/i915_drv.c | 2 ++
> 3 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index 66165b10256e..ff2b4f74149a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -701,7 +701,6 @@ static void ggtt_cleanup_hw(struct i915_ggtt *ggtt)
> ggtt->vm.cleanup(>vm);
>
> mutex_unlock(>vm.mutex);
> - i915_address_space_fini(>vm);
Ok, so this was defered to release. Where are we going to drop the final ref?
And also - I can see that we have a:
GEM_BUG_ON(i915_is_ggtt(vm));
in i915_vm_release().
Which means that we probably don't drop the final ref and don't ever call
i915_address_space_fini for ggtt.
-Michał
>
> arch_phys_wc_del(ggtt->mtrr);
>
> @@ -709,6 +708,15 @@ static void ggtt_cleanup_hw(struct i915_ggtt *ggtt)
> io_mapping_fini(>iomap);
> }
>
> +void i915_ggtt_driver_remove(struct drm_i915_private *i915)
> +{
> + struct i915_ggtt *ggtt = >ggtt;
> +
> + fini_aliasing_ppgtt(ggtt);
> +
> + ggtt_cleanup_hw(ggtt);
> +}
> +
> /**
> * i915_ggtt_driver_release - Clean up GGTT hardware initialization
> * @i915: i915 device
> @@ -718,10 +726,7 @@ void i915_ggtt_driver_release(struct
Re: [Intel-gfx] [RFC PATCH 2/4] drm/i915: Release GT resources on driver remove
Quoting Janusz Krzysztofik (2020-05-18 20:17:18) > GT scratch page is now released and its DMA mappings revoked on driver > release. If a device is removed while its file descriptor is still > open, the driver is not released until last device file descriptor > closure. In that case intel-iommu code may judge late DMA unmapping as > a bug and kernel panic may occur. > > Since DMA mapped address space may be no longer usable after device > removal, release GT resources including scratch page as well as a > reference to its address space on driver remove. Implement that by > just calling intel_gt_driver_release() on GT remove as that function > has been already made safe to be called again on driver release even if > already called before, e.g. on GEM initialization failure. Do you mean: if (vm) /* FIXME being called twice on error paths :( */ i915_vm_put(vm); ? We're not fixing that... We're adding more :( Unfortunately I don't have a clear answer on how to rework our init / cleanup to be unplug friendly, and this fixes a bug, so... Reviewed-by: Michał Winiarski -Michał > > <4> [39.201062] [ cut here ] > <2> [39.201074] kernel BUG at drivers/iommu/intel-iommu.c:3717! > <4> [39.201154] invalid opcode: [#1] PREEMPT SMP NOPTI > <4> [39.201162] CPU: 6 PID: 7 Comm: kworker/u16:0 Tainted: G U W > 5.7.0-rc5-CI-CI_DRM_8485+ #1 > <4> [39.201172] Hardware name: Intel Corporation Ice Lake Client > Platform/IceLake U DDR4 SODIMM PD RVP, BIOS ICLSFWR1.R00.3175.A00.1904261428 > 04/26/2019 > <4> [39.201243] Workqueue: i915 __i915_gem_free_work [i915] > <4> [39.201252] RIP: 0010:intel_unmap+0x1f5/0x230 > <4> [39.201260] Code: 01 e8 9f bc a9 ff 85 c0 74 09 80 3d df 60 09 01 00 74 > 19 65 ff 0d 13 12 97 7e 0f 85 fc fe ff ff e8 82 b0 95 ff e9 f2 fe ff ff <0f> > 0b e8 d4 bd a9 ff 85 c0 75 de 48 c7 c2 10 84 2c 82 be 54 00 00 > <4> [39.201278] RSP: 0018:c90dbc98 EFLAGS: 00010246 > <4> [39.201285] RAX: RBX: RCX: > ea0021d3 > <4> [39.201293] RDX: 0005f000 RSI: fed0 RDI: > 89eec000 > <4> [39.201301] RBP: 89eec0b0 R08: R09: > fffe > <4> [39.201309] R10: 458139fc R11: f6c6d8b2 R12: > 0025 > <4> [39.201318] R13: fed0 R14: 0005f000 R15: > 0025 > <4> [39.201326] FS: () GS:9010() > knlGS: > <4> [39.201335] CS: 0010 DS: ES: CR0: 80050033 > <4> [39.201342] CR2: 560f1308e148 CR3: 000881972002 CR4: > 00760ee0 > <4> [39.201350] PKRU: 5554 > <4> [39.201355] Call Trace: > <4> [39.201361] intel_unmap_sg+0x7b/0x180 > <4> [39.201412] shmem_put_pages+0x43/0x250 [i915] > <4> [39.201472] ? __i915_gem_object_unset_pages.part.12+0x11b/0x1d0 [i915] > <4> [39.201531] ? __i915_gem_object_unset_pages.part.12+0x133/0x1d0 [i915] > <4> [39.201590] __i915_gem_object_put_pages+0x81/0xc0 [i915] > <4> [39.201646] __i915_gem_free_objects.isra.21+0x1a7/0x4b0 [i915] > <4> [39.201658] process_one_work+0x268/0x600 > <4> [39.201666] ? __schedule+0x307/0x8d0 > <4> [39.201675] worker_thread+0x1d0/0x380 > <4> [39.201682] ? process_one_work+0x600/0x600 > <4> [39.201689] kthread+0x140/0x160 > <4> [39.201695] ? kthread_park+0x80/0x80 > <4> [39.201703] ret_from_fork+0x24/0x50 > <4> [39.201712] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek > snd_hda_codec_generic i915 mei_hdcp x86_pkg_temp_thermal coretemp > crct10dif_pclmul crc32_pclmul snd_hda_intel snd_intel_dspcfg snd_hda_codec > e1000e ax88179_178a usbnet snd_hwdep mii snd_hda_core ghash_clmulni_intel > snd_pcm ptp pps_core mei_me mei intel_lpss_pci prime_numbers > <4> [39.201764] ---[ end trace f3ec1bae3de04509 ]--- > > Signed-off-by: Janusz Krzysztofik > --- > drivers/gpu/drm/i915/gt/intel_gt.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c > b/drivers/gpu/drm/i915/gt/intel_gt.c > index f069551e412f..5771e80e85a6 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt.c > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c > @@ -599,6 +599,8 @@ void intel_gt_driver_remove(struct intel_gt *gt) > intel_uc_driver_remove(>uc); > > intel_engines_release(gt); > + > + intel_gt_driver_release(gt); > } > > void intel_gt_driver_unregister(struct intel_gt *gt) > -- > 2.21.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
Re: [Intel-gfx] [PATCH 7/9] drm/shmem-helpers: Redirect mmap for imported dma-buf
Hi Daniel, what's your plan for this patch set? I'd need this patch for the udl shmem cleanup. Best regards Thomas Am 11.05.20 um 11:35 schrieb Daniel Vetter: > Currently this seems to work by converting the sgt into a pages array, > and then treating it like a native object. Do the right thing and > redirect mmap to the exporter. > > With this nothing is calling get_pages anymore on imported dma-buf, > and we can start to remove the use of the ->pages array for that case. > > v2: Rebase > > Cc: Gerd Hoffmann > Cc: Rob Herring > Cc: Noralf Trønnes > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/drm_gem_shmem_helper.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c > b/drivers/gpu/drm/drm_gem_shmem_helper.c > index b9cba5cc61c3..117a7841e284 100644 > --- a/drivers/gpu/drm/drm_gem_shmem_helper.c > +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c > @@ -551,6 +551,9 @@ int drm_gem_shmem_mmap(struct drm_gem_object *obj, struct > vm_area_struct *vma) > /* Remove the fake offset */ > vma->vm_pgoff -= drm_vma_node_start(>vma_node); > > + if (obj->import_attach) > + return dma_buf_mmap(obj->dma_buf, vma, 0); > + > shmem = to_drm_gem_shmem_obj(obj); > > ret = drm_gem_shmem_get_pages(shmem); > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer signature.asc Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915/pmu: avoid an maybe-uninitialized warning
== Series Details == Series: series starting with [1/3] drm/i915/pmu: avoid an maybe-uninitialized warning URL : https://patchwork.freedesktop.org/series/77706/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8543_full -> Patchwork_17791_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17791_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17791_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_17791_full: ### CI changes ### Possible regressions * boot: - shard-tglb: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [FAIL][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb8/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb8/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb8/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb8/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb7/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb7/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb7/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb7/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb6/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb6/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb5/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb3/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb3/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb3/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb2/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb2/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb2/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb2/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb1/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb1/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb1/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17791/shard-tglb8/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17791/shard-tglb8/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17791/shard-tglb8/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17791/shard-tglb8/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17791/shard-tglb7/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17791/shard-tglb7/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17791/shard-tglb7/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17791/shard-tglb6/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17791/shard-tglb6/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17791/shard-tglb6/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17791/shard-tglb6/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17791/shard-tglb5/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17791/shard-tglb5/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17791/shard-tglb5/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17791/shard-tglb3/boot.html [41]:
Re: [Intel-gfx] [PATCH] drm: use drm_dev_has_vblank more
On Wed, May 27, 2020 at 01:11:34PM +0200, Daniel Vetter wrote:
> For historical reasons it's called dev->num_crtcs, which is rather
> confusing ever since kms was added. But now we have a nice helper, so
> let's use it for better readability!
>
> Only code change is in atomic helpers: vblank support means that
> dev->irq_enabled must be set too. Another one of these quirky things
> ... But since it's implied we can simplify that check.
>
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 2 +-
> drivers/gpu/drm/drm_irq.c | 2 +-
> drivers/gpu/drm/drm_vblank.c| 14 +++---
> 3 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 0a541368246e..bfcc7857a9a1 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1097,7 +1097,7 @@ disable_outputs(struct drm_device *dev, struct
> drm_atomic_state *old_state)
> else if (funcs->dpms)
> funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
>
> - if (!(dev->irq_enabled && dev->num_crtcs))
> + if (!drm_dev_has_vblank(dev))
> continue;
>
> ret = drm_crtc_vblank_get(crtc);
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 588be45abd7a..09d6e9e2e075 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -181,7 +181,7 @@ int drm_irq_uninstall(struct drm_device *dev)
>* vblank/irq handling. KMS drivers must ensure that vblanks are all
>* disabled when uninstalling the irq handler.
>*/
> - if (dev->num_crtcs) {
> + if (drm_dev_has_vblank(dev)) {
> spin_lock_irqsave(>vbl_lock, irqflags);
> for (i = 0; i < dev->num_crtcs; i++) {
> struct drm_vblank_crtc *vblank = >vblank[i];
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index e278d6407f8e..162d9f7e692a 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -605,7 +605,7 @@ void drm_calc_timestamping_constants(struct drm_crtc
> *crtc,
> int linedur_ns = 0, framedur_ns = 0;
> int dotclock = mode->crtc_clock;
>
> - if (!dev->num_crtcs)
> + if (!drm_dev_has_vblank(dev))
> return;
>
> if (WARN_ON(pipe >= dev->num_crtcs))
> @@ -1065,7 +1065,7 @@ void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
> unsigned int pipe = drm_crtc_index(crtc);
> ktime_t now;
>
> - if (dev->num_crtcs > 0) {
> + if (drm_dev_has_vblank(dev)) {
> seq = drm_vblank_count_and_time(dev, pipe, );
> } else {
> seq = 0;
> @@ -1137,7 +1137,7 @@ static int drm_vblank_get(struct drm_device *dev,
> unsigned int pipe)
> unsigned long irqflags;
> int ret = 0;
>
> - if (!dev->num_crtcs)
> + if (!drm_dev_has_vblank(dev))
> return -EINVAL;
>
> if (WARN_ON(pipe >= dev->num_crtcs))
> @@ -1506,7 +1506,7 @@ static void drm_legacy_vblank_pre_modeset(struct
> drm_device *dev,
> struct drm_vblank_crtc *vblank = >vblank[pipe];
>
> /* vblank is not initialized (IRQ not installed ?), or has been freed */
> - if (!dev->num_crtcs)
> + if (!drm_dev_has_vblank(dev))
> return;
>
> if (WARN_ON(pipe >= dev->num_crtcs))
> @@ -1533,7 +1533,7 @@ static void drm_legacy_vblank_post_modeset(struct
> drm_device *dev,
> unsigned long irqflags;
>
> /* vblank is not initialized (IRQ not installed ?), or has been freed */
> - if (!dev->num_crtcs)
> + if (!drm_dev_has_vblank(dev))
> return;
>
> if (WARN_ON(pipe >= dev->num_crtcs))
> @@ -1558,7 +1558,7 @@ int drm_legacy_modeset_ctl_ioctl(struct drm_device
> *dev, void *data,
> unsigned int pipe;
>
> /* If drm_vblank_init() hasn't been called yet, just no-op */
> - if (!dev->num_crtcs)
> + if (!drm_dev_has_vblank(dev))
> return 0;
>
> /* KMS drivers handle this internally */
> @@ -1896,7 +1896,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
> int pipe)
> unsigned long irqflags;
> bool disable_irq, fence_cookie;
>
> - if (WARN_ON_ONCE(!dev->num_crtcs))
> + if (WARN_ON_ONCE(!drm_dev_has_vblank(dev)))
> return false;
>
> if (WARN_ON(pipe >= dev->num_crtcs))
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
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: Remove local entries from GGTT on suspend (rev3)
== Series Details == Series: drm/i915/gt: Remove local entries from GGTT on suspend (rev3) URL : https://patchwork.freedesktop.org/series/77708/ State : success == Summary == CI Bug Log - changes from CI_DRM_8544 -> Patchwork_17795 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17795/index.html Known issues Here are the changes found in Patchwork_17795 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0: - fi-hsw-4770:[PASS][1] -> [INCOMPLETE][2] ([i915#1242]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/fi-hsw-4770/igt@gem_exec_susp...@basic-s0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17795/fi-hsw-4770/igt@gem_exec_susp...@basic-s0.html Possible fixes * igt@kms_chamelium@dp-crc-fast: - fi-icl-u2: [FAIL][3] ([i915#262]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17795/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [SKIP][5] ([fdo#109271]) -> [FAIL][6] ([i915#62]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17795/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1242]: https://gitlab.freedesktop.org/drm/intel/issues/1242 [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 Participating hosts (49 -> 43) -- 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_8544 -> Patchwork_17795 CI-20190529: 20190529 CI_DRM_8544: c6c0a18e985d7a3fd4451e0e786e6522371ea9ee @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5680: f7e3772175c53f0c910f4513831791cb5bdcab04 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17795: 3c30dfc380bfcf268228645cf7cc68f9734067f1 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 3c30dfc380bf drm/i915/gt: Remove local entries from GGTT on suspend == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17795/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Prevent timeslicing into unpreemptible requests (rev3)
== Series Details == Series: drm/i915/gt: Prevent timeslicing into unpreemptible requests (rev3) URL : https://patchwork.freedesktop.org/series/77697/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8543_full -> Patchwork_17790_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17790_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17790_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_17790_full: ### IGT changes ### Possible regressions * igt@runner@aborted: - shard-hsw: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17790/shard-hsw2/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_17790_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed-process@bsd1: - shard-tglb: [PASS][2] -> [FAIL][3] ([i915#1528]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-tglb8/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd1.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17790/shard-tglb3/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd1.html * igt@gem_eio@in-flight-suspend: - shard-kbl: [PASS][4] -> [DMESG-WARN][5] ([i915#180]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-kbl4/igt@gem_...@in-flight-suspend.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17790/shard-kbl7/igt@gem_...@in-flight-suspend.html * igt@i915_pm_backlight@fade_with_suspend: - shard-skl: [PASS][6] -> [INCOMPLETE][7] ([i915#69]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-skl3/igt@i915_pm_backlight@fade_with_suspend.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17790/shard-skl8/igt@i915_pm_backlight@fade_with_suspend.html * igt@kms_cursor_legacy@cursora-vs-flipb-toggle: - shard-glk: [PASS][8] -> [DMESG-WARN][9] ([i915#1926]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-glk9/igt@kms_cursor_leg...@cursora-vs-flipb-toggle.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17790/shard-glk5/igt@kms_cursor_leg...@cursora-vs-flipb-toggle.html * igt@kms_cursor_legacy@long-nonblocking-modeset-vs-cursor-atomic: - shard-apl: [PASS][10] -> [FAIL][11] ([i915#1181] / [i915#95]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-apl1/igt@kms_cursor_leg...@long-nonblocking-modeset-vs-cursor-atomic.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17790/shard-apl6/igt@kms_cursor_leg...@long-nonblocking-modeset-vs-cursor-atomic.html * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-untiled: - shard-hsw: [PASS][12] -> [DMESG-WARN][13] ([i915#1927]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-hsw7/igt@kms_draw_...@draw-method-xrgb2101010-mmap-wc-untiled.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17790/shard-hsw2/igt@kms_draw_...@draw-method-xrgb2101010-mmap-wc-untiled.html * igt@kms_hdr@bpc-switch-suspend: - shard-apl: [PASS][14] -> [DMESG-WARN][15] ([i915#180]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-apl1/igt@kms_...@bpc-switch-suspend.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17790/shard-apl4/igt@kms_...@bpc-switch-suspend.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][16] -> [FAIL][17] ([fdo#108145] / [i915#265]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-skl9/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17790/shard-skl7/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_setmode@basic: - shard-apl: [PASS][18] -> [FAIL][19] ([i915#31]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-apl8/igt@kms_setm...@basic.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17790/shard-apl2/igt@kms_setm...@basic.html Possible fixes * igt@kms_cursor_crc@pipe-c-cursor-128x42-onscreen: - shard-skl: [FAIL][20] ([i915#54]) -> [PASS][21] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-skl4/igt@kms_cursor_...@pipe-c-cursor-128x42-onscreen.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17790/shard-skl2/igt@kms_cursor_...@pipe-c-cursor-128x42-onscreen.html * igt@kms_cursor_legacy@pipe-b-torture-bo: - shard-tglb:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Prevent timeslicing into unpreemptible requests (rev4)
== Series Details == Series: drm/i915/gt: Prevent timeslicing into unpreemptible requests (rev4) URL : https://patchwork.freedesktop.org/series/77697/ State : success == Summary == CI Bug Log - changes from CI_DRM_8544 -> Patchwork_17794 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17794/index.html Known issues Here are the changes found in Patchwork_17794 that come from known issues: ### IGT changes ### Possible fixes * igt@kms_chamelium@dp-crc-fast: - fi-icl-u2: [FAIL][1] ([i915#262]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17794/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262 Participating hosts (49 -> 42) -- 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_8544 -> Patchwork_17794 CI-20190529: 20190529 CI_DRM_8544: c6c0a18e985d7a3fd4451e0e786e6522371ea9ee @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5680: f7e3772175c53f0c910f4513831791cb5bdcab04 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17794: eefae5ef00b565b58b7f7f2d769be3a015832017 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == eefae5ef00b5 drm/i915/gt: Prevent timeslicing into unpreemptable requests == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17794/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Remove local entries from GGTT on suspend
Across suspend/resume, we clear the entire GGTT and rebuild from
scratch. In particular, we only preserve the global entries for use by
the HW, and delay reinstating the local binds until required by the
user. This means that we can evict and recover any local binds in the
global GTT, saving any time in preserving their state.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1947
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 18 -
drivers/gpu/drm/i915/i915_vma.c | 59 +++-
drivers/gpu/drm/i915/i915_vma.h | 1 +
3 files changed, 49 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 317172ad5ef3..1dbec2676648 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -108,13 +108,27 @@ static bool needs_idle_maps(struct drm_i915_private *i915)
void i915_ggtt_suspend(struct i915_ggtt *ggtt)
{
- struct i915_vma *vma;
+ struct i915_vma *vma, *vn;
+ int open;
- list_for_each_entry(vma, >vm.bound_list, vm_link)
+ mutex_lock(>vm.mutex);
+
+ /* Skip rewriting PTE on VMA unbind. */
+ open = atomic_xchg(>vm.open, 0);
+
+ list_for_each_entry_safe(vma, vn, >vm.bound_list, vm_link) {
i915_vma_wait_for_bind(vma);
+ if (!i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND)) {
+ __i915_vma_evict(vma);
+ drm_mm_remove_node(>node);
+ }
+ }
ggtt->vm.clear_range(>vm, 0, ggtt->vm.total);
ggtt->invalidate(ggtt);
+ atomic_set(>vm.open, open);
+
+ mutex_unlock(>vm.mutex);
intel_gt_check_and_clear_faults(ggtt->vm.gt);
}
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 22198b758459..9b30ddc49e4b 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1229,31 +1229,9 @@ int i915_vma_move_to_active(struct i915_vma *vma,
return 0;
}
-int __i915_vma_unbind(struct i915_vma *vma)
+void __i915_vma_evict(struct i915_vma *vma)
{
- int ret;
-
- lockdep_assert_held(>vm->mutex);
-
- if (i915_vma_is_pinned(vma)) {
- vma_print_allocator(vma, "is pinned");
- return -EAGAIN;
- }
-
- /*
-* After confirming that no one else is pinning this vma, wait for
-* any laggards who may have crept in during the wait (through
-* a residual pin skipping the vm->mutex) to complete.
-*/
- ret = i915_vma_sync(vma);
- if (ret)
- return ret;
-
- if (!drm_mm_node_allocated(>node))
- return 0;
-
GEM_BUG_ON(i915_vma_is_pinned(vma));
- GEM_BUG_ON(i915_vma_is_active(vma));
if (i915_vma_is_map_and_fenceable(vma)) {
/* Force a pagefault for domain tracking on next user access */
@@ -1292,6 +1270,33 @@ int __i915_vma_unbind(struct i915_vma *vma)
i915_vma_detach(vma);
vma_unbind_pages(vma);
+}
+
+int __i915_vma_unbind(struct i915_vma *vma)
+{
+ int ret;
+
+ lockdep_assert_held(>vm->mutex);
+
+ if (!drm_mm_node_allocated(>node))
+ return 0;
+
+ if (i915_vma_is_pinned(vma)) {
+ vma_print_allocator(vma, "is pinned");
+ return -EAGAIN;
+ }
+
+ /*
+* After confirming that no one else is pinning this vma, wait for
+* any laggards who may have crept in during the wait (through
+* a residual pin skipping the vm->mutex) to complete.
+*/
+ ret = i915_vma_sync(vma);
+ if (ret)
+ return ret;
+
+ GEM_BUG_ON(i915_vma_is_active(vma));
+ __i915_vma_evict(vma);
drm_mm_remove_node(>node); /* pairs with i915_vma_release() */
return 0;
@@ -1303,13 +1308,13 @@ int i915_vma_unbind(struct i915_vma *vma)
intel_wakeref_t wakeref = 0;
int err;
- if (!drm_mm_node_allocated(>node))
- return 0;
-
/* Optimistic wait before taking the mutex */
err = i915_vma_sync(vma);
if (err)
- goto out_rpm;
+ return err;
+
+ if (!drm_mm_node_allocated(>node))
+ return 0;
if (i915_vma_is_pinned(vma)) {
vma_print_allocator(vma, "is pinned");
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 8ad1daabcd58..d0d01f909548 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -203,6 +203,7 @@ bool i915_vma_misplaced(const struct i915_vma *vma,
u64 size, u64 alignment, u64 flags);
void __i915_vma_set_map_and_fenceable(struct i915_vma *vma);
void i915_vma_revoke_mmap(struct i915_vma *vma);
+void __i915_vma_evict(struct i915_vma *vma);
int __i915_vma_unbind(struct i915_vma *vma);
int __must_check
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gt: Remove local entries from GGTT on suspend (rev2)
== Series Details == Series: drm/i915/gt: Remove local entries from GGTT on suspend (rev2) URL : https://patchwork.freedesktop.org/series/77708/ State : failure == Summary == Applying: drm/i915/pmu: avoid an maybe-uninitialized warning Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/gt/intel_ggtt.c M drivers/gpu/drm/i915/i915_pmu.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/gt/intel_ggtt.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gt/intel_ggtt.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/i915/pmu: avoid an maybe-uninitialized warning 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.IGT: failure for series starting with [1/3] drm/edid: Allow looking for ext blocks starting from a specified index
== Series Details == Series: series starting with [1/3] drm/edid: Allow looking for ext blocks starting from a specified index URL : https://patchwork.freedesktop.org/series/77699/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8543_full -> Patchwork_17789_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17789_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17789_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_17789_full: ### IGT changes ### Possible regressions * igt@kms_plane_alpha_blend@pipe-b-alpha-basic: - shard-glk: NOTRUN -> [TIMEOUT][1] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17789/shard-glk9/igt@kms_plane_alpha_bl...@pipe-b-alpha-basic.html * igt@runner@aborted: - shard-hsw: NOTRUN -> [FAIL][2] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17789/shard-hsw4/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_17789_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_suspend@forcewake: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-kbl2/igt@i915_susp...@forcewake.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17789/shard-kbl6/igt@i915_susp...@forcewake.html * igt@kms_cursor_edge_walk@pipe-a-128x128-bottom-edge: - shard-hsw: [PASS][5] -> [DMESG-WARN][6] ([i915#1927]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-hsw4/igt@kms_cursor_edge_w...@pipe-a-128x128-bottom-edge.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17789/shard-hsw4/igt@kms_cursor_edge_w...@pipe-a-128x128-bottom-edge.html * igt@kms_cursor_legacy@cursora-vs-flipb-toggle: - shard-glk: [PASS][7] -> [DMESG-WARN][8] ([i915#1926]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-glk9/igt@kms_cursor_leg...@cursora-vs-flipb-toggle.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17789/shard-glk7/igt@kms_cursor_leg...@cursora-vs-flipb-toggle.html * igt@kms_cursor_legacy@cursorb-vs-flipb-atomic-transitions: - shard-hsw: [PASS][9] -> [SKIP][10] ([fdo#109271]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-hsw6/igt@kms_cursor_leg...@cursorb-vs-flipb-atomic-transitions.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17789/shard-hsw1/igt@kms_cursor_leg...@cursorb-vs-flipb-atomic-transitions.html * igt@kms_hdr@bpc-switch: - shard-skl: [PASS][11] -> [FAIL][12] ([i915#1188]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-skl5/igt@kms_...@bpc-switch.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17789/shard-skl10/igt@kms_...@bpc-switch.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180] / [i915#93] / [i915#95]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-kbl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17789/shard-kbl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([i915#648] / [i915#69]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-skl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17789/shard-skl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#265]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-skl9/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17789/shard-skl7/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17789/shard-iclb3/igt@kms_psr@psr2_sprite_mmap_gtt.html * igt@kms_setmode@basic: - shard-apl: [PASS][21] -> [FAIL][22] ([i915#31]) [21]:
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Randomise bonded submission
Quoting Chris Wilson (2020-05-27 17:00:55) > Quoting Tvrtko Ursulin (2020-05-27 16:51:50) > > > > On 27/05/2020 14:14, Chris Wilson wrote: > > > + > > > + if (rand() % 1) > > > + igt_swap(a, b); > > > + > > > + batch.handle = create_semaphore_to_spinner(i915, a); > > > > These will be preemptible right? More so they schedule out on semaphore > > interrupt straight away? So I don't see how slaves can be prevented from > > running because they always are on a different physical engine. > > Right, as I understood your description the masters could only be on one > engine with the bonded requests on the other. > > And I don't know how to wait from the GPU other than with the > preemptible semaphore spin. A non preemptible wait would be another > spinner, but that would not coordinate across the bond. To reproduce the > non-preemptible HW might require the actual instruction flow. The most obvious way is the same igt_spin_t submitted to both engines with a submit fence. But that still requires the CPU to terminate the spinner. And has similarities to the existing tests. Now we could have one spinner that counted or watched the timestamp, looping back on itself with a predicated jump, and on completion terminated the bonded spinner. That way we could have two non-preemptible spinner of finite duration. But the coupling via memory is still very loose and doesn't require both requests to be running concurrently. Slightly better than would be to rewrite the jump target from A and then go in another spin on A waiting for a similar update from B. It still does not explode if either is preempted out, but more likely to be caught spinning forever. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/gt: Prevent timeslicing into unpreemptable requests
We have a I915_REQUEST_NOPREEMPT flag that we set when we must prevent
the HW from preempting during the course of this request. We need to
honour this flag and protect the HW even if we have a heartbeat request,
or other maximum priority barrier, pending. As such, restrict the
timeslicing check to avoid preempting into the topmost priority band,
leaving the unpreemptable requests in blissful peace running
uninterrupted on the HW.
v2: Set the I915_PRIORITY_BARRIER to be less than
I915_PRIORITY_UNPREEMPTABLE so that we never submit a request
(heartbeat or barrier) that can legitimately preempt the current
non-premptable request.
Fixes: 2a98f4e65bba ("drm/i915: add infrastructure to hold off preemption on a
request")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c| 1 +
drivers/gpu/drm/i915/gt/selftest_lrc.c | 118 -
drivers/gpu/drm/i915/i915_priolist_types.h | 2 +-
3 files changed, 119 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 3214a4ecc31a..197efd9ea1e9 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1928,6 +1928,7 @@ need_timeslice(const struct intel_engine_cs *engine,
if (!list_is_last(>sched.link, >active.requests))
hint = max(hint, rq_prio(list_next_entry(rq, sched.link)));
+ GEM_BUG_ON(hint == I915_PRIORITY_UNPREEMPTABLE);
return hint >= effective_prio(rq);
}
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 66f710b1b61e..3e35a45d6218 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -823,7 +823,7 @@ slice_semaphore_queue(struct intel_engine_cs *outer,
}
}
- err = release_queue(outer, vma, n, INT_MAX);
+ err = release_queue(outer, vma, n, I915_PRIORITY_BARRIER);
if (err)
goto out;
@@ -1289,6 +1289,121 @@ static int live_timeslice_queue(void *arg)
return err;
}
+static int live_timeslice_nopreempt(void *arg)
+{
+ struct intel_gt *gt = arg;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ struct igt_spinner spin;
+ int err = 0;
+
+ /*
+* We should not timeslice into a request that is marked with
+* I915_REQUEST_NOPREEMPT.
+*/
+ if (!IS_ACTIVE(CONFIG_DRM_I915_TIMESLICE_DURATION))
+ return 0;
+
+ if (igt_spinner_init(, gt))
+ return -ENOMEM;
+
+ for_each_engine(engine, gt, id) {
+ struct intel_context *ce;
+ struct i915_request *rq;
+ unsigned long timeslice;
+
+ if (!intel_engine_has_preemption(engine))
+ continue;
+
+ ce = intel_context_create(engine);
+ if (IS_ERR(ce)) {
+ err = PTR_ERR(ce);
+ break;
+ }
+
+ engine_heartbeat_disable(engine);
+ timeslice = xchg(>props.timeslice_duration_ms, 1);
+
+ /* Create an unpreemptible spinner */
+
+ rq = igt_spinner_create_request(, ce, MI_ARB_CHECK);
+ intel_context_put(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto out_heartbeat;
+ }
+
+ i915_request_get(rq);
+ i915_request_add(rq);
+
+ if (!igt_wait_for_spinner(, rq)) {
+ i915_request_put(rq);
+ err = -ETIME;
+ goto out_spin;
+ }
+
+ set_bit(I915_FENCE_FLAG_NOPREEMPT, >fence.flags);
+ i915_request_put(rq);
+
+ /* Followed by a maximum priority barrier (heartbeat) */
+
+ ce = intel_context_create(engine);
+ if (IS_ERR(ce)) {
+ err = PTR_ERR(rq);
+ goto out_spin;
+ }
+
+ rq = intel_context_create_request(ce);
+ intel_context_put(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto out_spin;
+ }
+
+ rq->sched.attr.priority = I915_PRIORITY_BARRIER;
+ i915_request_get(rq);
+ i915_request_add(rq);
+
+ /*
+* Wait until the barrier is in ELSP, and we know timeslicing
+* will have been activated.
+*/
+ if (wait_for_submit(engine, rq, HZ / 2)) {
+ i915_request_put(rq);
+ err = -ETIME;
+ goto out_spin;
+ }
+
+ /*
+* Since the ELSP[0] request is unpreemptible, it should not
+* allow the maximum
Re: [Intel-gfx] [PATCH] drm/i915/gt: Prevent timeslicing into unpreemptible requests
Quoting Tvrtko Ursulin (2020-05-27 17:13:50)
>
> On 27/05/2020 15:07, Chris Wilson wrote:
> > We have a I915_REQUEST_NOPREEMPT flag that we set when we must prevent
> > the HW from preempting during the course of this request. We need to
> > honour this flag and protect the HW even if we have a heartbeat request,
> > or other maximum priority barrier, pending. As such, restrict the
> > timeslicing check to avoid preempting into the topmost priority band,
> > leaving the unpreemptable requests in blissful peace running
> > uninterrupted on the HW.
> >
> > Fixes: 2a98f4e65bba ("drm/i915: add infrastructure to hold off preemption
> > on a request")
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/gt/intel_lrc.c| 11 +++
> > drivers/gpu/drm/i915/gt/selftest_lrc.c | 116 +
> > 2 files changed, 127 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index 3214a4ecc31a..012afb9e0324 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -1896,6 +1896,15 @@ static void defer_active(struct intel_engine_cs
> > *engine)
> > defer_request(rq, i915_sched_lookup_priolist(engine, rq_prio(rq)));
> > }
> >
> > +static inline int never_timeslice(int prio)
> > +{
> > + /* Don't allow timeslicing of the 'unpreemptible' requests */
> > + if (prio == I915_PRIORITY_UNPREEMPTABLE)
> > + prio--;
> > +
> > + return prio;
> > +}
> > +
> > static bool
> > need_timeslice(const struct intel_engine_cs *engine,
> > const struct i915_request *rq,
> > @@ -1927,6 +1936,7 @@ need_timeslice(const struct intel_engine_cs *engine,
> >
> > if (!list_is_last(>sched.link, >active.requests))
> > hint = max(hint, rq_prio(list_next_entry(rq, sched.link)));
> > + hint = never_timeslice(hint);
> >
> > return hint >= effective_prio(rq);
>
> Can INT_MAX ever end up in the queue? I am thinking if we limit it to
> effective_prio it may be more obvious what's happening. Or is it
> heartbeats? Should they be INT_MAX - 1 then?
Yes, we insert barriers into the queue with INT_MAX.
I liked #define I915_PRIORITY_BARRIER INT_MAX! But yes, that would be a
cleaner way to solve it.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Prevent timeslicing into unpreemptible requests
On 27/05/2020 15:07, Chris Wilson wrote:
We have a I915_REQUEST_NOPREEMPT flag that we set when we must prevent
the HW from preempting during the course of this request. We need to
honour this flag and protect the HW even if we have a heartbeat request,
or other maximum priority barrier, pending. As such, restrict the
timeslicing check to avoid preempting into the topmost priority band,
leaving the unpreemptable requests in blissful peace running
uninterrupted on the HW.
Fixes: 2a98f4e65bba ("drm/i915: add infrastructure to hold off preemption on a
request")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c| 11 +++
drivers/gpu/drm/i915/gt/selftest_lrc.c | 116 +
2 files changed, 127 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 3214a4ecc31a..012afb9e0324 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1896,6 +1896,15 @@ static void defer_active(struct intel_engine_cs *engine)
defer_request(rq, i915_sched_lookup_priolist(engine, rq_prio(rq)));
}
+static inline int never_timeslice(int prio)
+{
+ /* Don't allow timeslicing of the 'unpreemptible' requests */
+ if (prio == I915_PRIORITY_UNPREEMPTABLE)
+ prio--;
+
+ return prio;
+}
+
static bool
need_timeslice(const struct intel_engine_cs *engine,
const struct i915_request *rq,
@@ -1927,6 +1936,7 @@ need_timeslice(const struct intel_engine_cs *engine,
if (!list_is_last(>sched.link, >active.requests))
hint = max(hint, rq_prio(list_next_entry(rq, sched.link)));
+ hint = never_timeslice(hint);
return hint >= effective_prio(rq);
Can INT_MAX ever end up in the queue? I am thinking if we limit it to
effective_prio it may be more obvious what's happening. Or is it
heartbeats? Should they be INT_MAX - 1 then?
Regards,
Tvrtko
}
@@ -2007,6 +2017,7 @@ static void start_timeslice(struct intel_engine_cs
*engine, int prio)
if (!intel_engine_has_timeslices(engine))
return;
+ prio = never_timeslice(prio);
WRITE_ONCE(execlists->switch_priority_hint, prio);
if (prio == INT_MIN)
return;
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 66f710b1b61e..0c32afbdb644 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -1289,6 +1289,121 @@ static int live_timeslice_queue(void *arg)
return err;
}
+static int live_timeslice_nopreempt(void *arg)
+{
+ struct intel_gt *gt = arg;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ struct igt_spinner spin;
+ int err = 0;
+
+ /*
+* We should not timeslice into a request that is marked with
+* I915_REQUEST_NOPREEMPT.
+*/
+ if (!IS_ACTIVE(CONFIG_DRM_I915_TIMESLICE_DURATION))
+ return 0;
+
+ if (igt_spinner_init(, gt))
+ return -ENOMEM;
+
+ for_each_engine(engine, gt, id) {
+ struct intel_context *ce;
+ struct i915_request *rq;
+ unsigned long timeslice;
+
+ if (!intel_engine_has_preemption(engine))
+ continue;
+
+ ce = intel_context_create(engine);
+ if (IS_ERR(ce)) {
+ err = PTR_ERR(ce);
+ break;
+ }
+
+ engine_heartbeat_disable(engine);
+ timeslice = xchg(>props.timeslice_duration_ms, 1);
+
+ /* Create an unpreemptible spinner */
+
+ rq = igt_spinner_create_request(, ce, MI_ARB_CHECK);
+ intel_context_put(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto out_heartbeat;
+ }
+
+ i915_request_get(rq);
+ i915_request_add(rq);
+
+ if (!igt_wait_for_spinner(, rq)) {
+ i915_request_put(rq);
+ err = -ETIME;
+ goto out_spin;
+ }
+
+ set_bit(I915_FENCE_FLAG_NOPREEMPT, >fence.flags);
+ i915_request_put(rq);
+
+ /* Followed by a maximum priority barrier (heartbeat) */
+
+ ce = intel_context_create(engine);
+ if (IS_ERR(ce)) {
+ err = PTR_ERR(rq);
+ goto out_spin;
+ }
+
+ rq = intel_context_create_request(ce);
+ intel_context_put(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto out_spin;
+ }
+
+ rq->sched.attr.priority = I915_PRIORITY_BARRIER;
+ i915_request_get(rq);
+
[Intel-gfx] [PATCH] drm/i915/pmu: avoid an maybe-uninitialized warning
From: Arnd Bergmann
Conditional spinlocks make it hard for gcc and for lockdep to
follow the code flow. This one causes a warning with at least
gcc-9 and higher:
In file included from include/linux/irq.h:14,
from drivers/gpu/drm/i915/i915_pmu.c:7:
drivers/gpu/drm/i915/i915_pmu.c: In function 'i915_sample':
include/linux/spinlock.h:289:3: error: 'flags' may be used uninitialized in
this function [-Werror=maybe-uninitialized]
289 | _raw_spin_unlock_irqrestore(lock, flags); \
| ^~~
drivers/gpu/drm/i915/i915_pmu.c:288:17: note: 'flags' was declared here
288 | unsigned long flags;
| ^
Split out the part between the locks into a separate function
for readability and to let the compiler figure out what the
logic actually is.
Fixes: d79e1bd676f0 ("drm/i915/pmu: Only use exclusive mmio access for gen7")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 5 ++
drivers/gpu/drm/i915/i915_pmu.c | 84 ++--
2 files changed, 47 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 3b8d7f830a2c..d8128448cef7 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -111,6 +111,8 @@ void i915_ggtt_suspend(struct i915_ggtt *ggtt)
struct i915_vma *vma, *vn;
int open;
+ mutex_lock(>vm.mutex);
+
/* Skip rewriting PTE on VMA unbind. */
open = atomic_xchg(>vm.open, 0);
@@ -121,10 +123,13 @@ void i915_ggtt_suspend(struct i915_ggtt *ggtt)
drm_mm_remove_node(>node);
}
}
+
ggtt->vm.clear_range(>vm, 0, ggtt->vm.total);
ggtt->invalidate(ggtt);
atomic_set(>vm.open, open);
+ mutex_lunock(>vm.mutex);
+
intel_gt_check_and_clear_faults(ggtt->vm.gt);
}
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index f6f44ad5e335..802837de1767 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -269,12 +269,48 @@ static bool exclusive_mmio_access(const struct
drm_i915_private *i915)
return IS_GEN(i915, 7);
}
+static void engine_sample(struct intel_engine_cs *engine, unsigned int
period_ns)
+{
+ struct intel_engine_pmu *pmu = >pmu;
+ bool busy;
+ u32 val;
+
+ val = ENGINE_READ_FW(engine, RING_CTL);
+ if (val == 0) /* powerwell off => engine idle */
+ return;
+
+ if (val & RING_WAIT)
+ add_sample(>sample[I915_SAMPLE_WAIT], period_ns);
+ if (val & RING_WAIT_SEMAPHORE)
+ add_sample(>sample[I915_SAMPLE_SEMA], period_ns);
+
+ /* No need to sample when busy stats are supported. */
+ if (intel_engine_supports_stats(engine))
+ return;
+
+ /*
+* While waiting on a semaphore or event, MI_MODE reports the
+* ring as idle. However, previously using the seqno, and with
+* execlists sampling, we account for the ring waiting as the
+* engine being busy. Therefore, we record the sample as being
+* busy if either waiting or !idle.
+*/
+ busy = val & (RING_WAIT_SEMAPHORE | RING_WAIT);
+ if (!busy) {
+ val = ENGINE_READ_FW(engine, RING_MI_MODE);
+ busy = !(val & MODE_IDLE);
+ }
+ if (busy)
+ add_sample(>sample[I915_SAMPLE_BUSY], period_ns);
+}
+
static void
engines_sample(struct intel_gt *gt, unsigned int period_ns)
{
struct drm_i915_private *i915 = gt->i915;
struct intel_engine_cs *engine;
enum intel_engine_id id;
+ unsigned long flags;
if ((i915->pmu.enable & ENGINE_SAMPLE_MASK) == 0)
return;
@@ -283,53 +319,17 @@ engines_sample(struct intel_gt *gt, unsigned int
period_ns)
return;
for_each_engine(engine, gt, id) {
- struct intel_engine_pmu *pmu = >pmu;
- spinlock_t *mmio_lock;
- unsigned long flags;
- bool busy;
- u32 val;
-
if (!intel_engine_pm_get_if_awake(engine))
continue;
- mmio_lock = NULL;
- if (exclusive_mmio_access(i915))
- mmio_lock = >uncore->lock;
-
- if (unlikely(mmio_lock))
- spin_lock_irqsave(mmio_lock, flags);
-
- val = ENGINE_READ_FW(engine, RING_CTL);
- if (val == 0) /* powerwell off => engine idle */
- goto skip;
-
- if (val & RING_WAIT)
- add_sample(>sample[I915_SAMPLE_WAIT], period_ns);
- if (val & RING_WAIT_SEMAPHORE)
- add_sample(>sample[I915_SAMPLE_SEMA], period_ns);
-
- /* No need to sample when busy stats are supported. */
- if
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Randomise bonded submission
Quoting Tvrtko Ursulin (2020-05-27 16:51:50)
>
> On 27/05/2020 14:14, Chris Wilson wrote:
> > Randomly submit a paired spinner and its cancellation as a bonded
> > (submit fence) pair. Apply congestion to the engine with more bonded
> > pairs to see if the execution order fails. If we prevent a cancellation
> > from running, then the spinner will remain spinning forever.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > tests/i915/gem_exec_balancer.c | 108 +
> > 1 file changed, 108 insertions(+)
> >
> > diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
> > index 80ae82416..98715d726 100644
> > --- a/tests/i915/gem_exec_balancer.c
> > +++ b/tests/i915/gem_exec_balancer.c
> > @@ -1154,6 +1154,111 @@ static void bonded_semaphore(int i915)
> > gem_context_destroy(i915, ctx);
> > }
> >
> > +static void __bonded_dual(int i915,
> > + const struct i915_engine_class_instance *siblings,
> > + unsigned int count)
> > +{
> > + struct drm_i915_gem_exec_object2 batch = {};
> > + struct drm_i915_gem_execbuffer2 execbuf = {
> > + .buffers_ptr = to_user_pointer(),
> > + .buffer_count = 1,
> > + };
> > + unsigned long cycles = 0;
> > + uint32_t A, B;
> > +
> > + A = gem_context_create(i915);
> > + set_load_balancer(i915, A, siblings, count, NULL);
> > +
> > + B = gem_context_create(i915);
> > + set_load_balancer(i915, B, siblings, count, NULL);
> > +
> > + igt_until_timeout(5) {
> > + unsigned int master = rand() % count + 1;
> > + int timeline, fence;
> > + igt_spin_t *a, *b;
> > +
> > + timeline = sw_sync_timeline_create();
> > + fence = sw_sync_timeline_create_fence(timeline, 1);
> > +
> > + a = igt_spin_new(i915, A,
> > + .engine = master,
> > + .fence = fence,
> > + .flags = (IGT_SPIN_FENCE_IN |
> > +IGT_SPIN_POLL_RUN |
> > +IGT_SPIN_NO_PREEMPTION |
> > +IGT_SPIN_FENCE_OUT));
> > + b = igt_spin_new(i915, B,
> > + .engine = master,
> > + .fence = fence,
> > + .flags = (IGT_SPIN_FENCE_IN |
> > +IGT_SPIN_POLL_RUN |
> > +IGT_SPIN_NO_PREEMPTION |
> > +IGT_SPIN_FENCE_OUT));
> > +
> > + close(fence);
>
> Does this or close(timeline) releases the submissions?
The timeline is the release.
> I suggest a variant without the fence anyway for a slightly different
> profile.
It didn't make any difference. But yes I contemplated the variant.
> > +
> > + if (rand() % 1)
> > + igt_swap(a, b);
> > +
> > + batch.handle = create_semaphore_to_spinner(i915, a);
>
> These will be preemptible right? More so they schedule out on semaphore
> interrupt straight away? So I don't see how slaves can be prevented from
> running because they always are on a different physical engine.
Right, as I understood your description the masters could only be on one
engine with the bonded requests on the other.
And I don't know how to wait from the GPU other than with the
preemptible semaphore spin. A non preemptible wait would be another
spinner, but that would not coordinate across the bond. To reproduce the
non-preemptible HW might require the actual instruction flow.
> We would need a test flavour where slave spins non-preemptively until
> either the master or CPU signals to stop. Coming up with the exact
> scheme to achieve this might be challenging. I can think about this more
> tomorrow.
>
> And also I don't know why this would fail with my patch! I'll want to
> have a experiment with that tomorrow as well.
That was indeed mysterious :) I don't have an explanation either yet.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Randomise bonded submission
On 27/05/2020 14:14, Chris Wilson wrote:
Randomly submit a paired spinner and its cancellation as a bonded
(submit fence) pair. Apply congestion to the engine with more bonded
pairs to see if the execution order fails. If we prevent a cancellation
from running, then the spinner will remain spinning forever.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_exec_balancer.c | 108 +
1 file changed, 108 insertions(+)
diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
index 80ae82416..98715d726 100644
--- a/tests/i915/gem_exec_balancer.c
+++ b/tests/i915/gem_exec_balancer.c
@@ -1154,6 +1154,111 @@ static void bonded_semaphore(int i915)
gem_context_destroy(i915, ctx);
}
+static void __bonded_dual(int i915,
+ const struct i915_engine_class_instance *siblings,
+ unsigned int count)
+{
+ struct drm_i915_gem_exec_object2 batch = {};
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(),
+ .buffer_count = 1,
+ };
+ unsigned long cycles = 0;
+ uint32_t A, B;
+
+ A = gem_context_create(i915);
+ set_load_balancer(i915, A, siblings, count, NULL);
+
+ B = gem_context_create(i915);
+ set_load_balancer(i915, B, siblings, count, NULL);
+
+ igt_until_timeout(5) {
+ unsigned int master = rand() % count + 1;
+ int timeline, fence;
+ igt_spin_t *a, *b;
+
+ timeline = sw_sync_timeline_create();
+ fence = sw_sync_timeline_create_fence(timeline, 1);
+
+ a = igt_spin_new(i915, A,
+.engine = master,
+.fence = fence,
+.flags = (IGT_SPIN_FENCE_IN |
+ IGT_SPIN_POLL_RUN |
+ IGT_SPIN_NO_PREEMPTION |
+ IGT_SPIN_FENCE_OUT));
+ b = igt_spin_new(i915, B,
+.engine = master,
+.fence = fence,
+.flags = (IGT_SPIN_FENCE_IN |
+ IGT_SPIN_POLL_RUN |
+ IGT_SPIN_NO_PREEMPTION |
+ IGT_SPIN_FENCE_OUT));
+
+ close(fence);
Does this or close(timeline) releases the submissions?
I suggest a variant without the fence anyway for a slightly different
profile.
+
+ if (rand() % 1)
+ igt_swap(a, b);
+
+ batch.handle = create_semaphore_to_spinner(i915, a);
These will be preemptible right? More so they schedule out on semaphore
interrupt straight away? So I don't see how slaves can be prevented from
running because they always are on a different physical engine.
We would need a test flavour where slave spins non-preemptively until
either the master or CPU signals to stop. Coming up with the exact
scheme to achieve this might be challenging. I can think about this more
tomorrow.
And also I don't know why this would fail with my patch! I'll want to
have a experiment with that tomorrow as well.
Regards,
Tvrtko
+ execbuf.rsvd1 = a->execbuf.rsvd1;
+ execbuf.rsvd2 = a->out_fence;
+ do {
+ execbuf.flags = rand() % count + 1;
+ } while (execbuf.flags == master);
+ execbuf.flags |= I915_EXEC_FENCE_SUBMIT;
+ gem_execbuf(i915, );
+ gem_close(i915, batch.handle);
+
+ batch.handle = create_semaphore_to_spinner(i915, b);
+ execbuf.rsvd1 = b->execbuf.rsvd1;
+ execbuf.rsvd2 = b->out_fence;
+ do {
+ execbuf.flags = rand() % count + 1;
+ } while (execbuf.flags == master);
+ execbuf.flags |= I915_EXEC_FENCE_SUBMIT;
+ gem_execbuf(i915, );
+ gem_close(i915, batch.handle);
+
+ close(timeline);
+
+ gem_sync(i915, a->handle);
+ gem_sync(i915, b->handle);
+
+ igt_spin_free(i915, a);
+ igt_spin_free(i915, b);
+ cycles++;
+ }
+
+ igt_info("%lu cycles\n", cycles);
+
+ gem_context_destroy(i915, A);
+ gem_context_destroy(i915, B);
+}
+
+static void bonded_dual(int i915)
+{
+ /*
+* The purpose of bonded submission is to execute one or more requests
+* concurrently. However, the very nature of that requires coordinated
+* submission across multiple engines.
+*/
+ igt_require(gem_scheduler_has_preemption(i915));
+
+ for (int class = 1; class < 32; class++) {
+ struct i915_engine_class_instance *siblings;
+
Re: [Intel-gfx] [PATCH 3/3] drm/i915/selftests: avoid bogus maybe-uninitialized warning
Quoting Arnd Bergmann (2020-05-27 15:05:10)
> gcc has a problem following values through IS_ERR/PTR_ERR macros,
> leading to a false-positive warning in allmodconfig, with any
> compiler version:
>
> In file included from drivers/gpu/drm/i915/gt/intel_lrc.c:5892:
> drivers/gpu/drm/i915/gt/selftest_lrc.c: In function
> 'create_gpr_client.isra.0':
> drivers/gpu/drm/i915/gt/selftest_lrc.c:2902:23: error: 'rq' may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
>
> This one is hard to avoid without impairing readability or adding a
> bugus NULL pointer.
>
> Fixes: c92724de6db1 ("drm/i915/selftests: Try to detect rollback during
> batchbuffer preemption")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/gpu/drm/i915/gt/selftest_lrc.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> index 824f99c4cc7c..933c3f5adf0a 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> @@ -2908,23 +2908,25 @@ create_gpr_client(struct intel_engine_cs *engine,
>
> vma = i915_vma_instance(global->obj, ce->vm, NULL);
> if (IS_ERR(vma)) {
> - err = PTR_ERR(vma);
> + rq = ERR_CAST(vma);
> goto out_ce;
> }
>
> err = i915_vma_pin(vma, 0, 0, PIN_USER);
> - if (err)
> + if (err) {
> + rq = ERR_PTR(err);
> goto out_ce;
> + }
>
> batch = create_gpr_user(engine, vma, offset);
> if (IS_ERR(batch)) {
> - err = PTR_ERR(batch);
> + rq = ERR_CAST(batch);
> goto out_vma;
> }
>
> rq = intel_context_create_request(ce);
> if (IS_ERR(rq)) {
> - err = PTR_ERR(rq);
> + rq = ERR_CAST(rq);
> goto out_batch;
> }
>
> @@ -2946,17 +2948,20 @@ create_gpr_client(struct intel_engine_cs *engine,
> i915_vma_unlock(batch);
> i915_vma_unpin(batch);
>
> - if (!err)
> + if (!err) {
> i915_request_get(rq);
> - i915_request_add(rq);
> -
> + i915_request_add(rq);
> + } else {
> + i915_request_add(rq);
> + rq = ERR_PTR(err);
> + }
> out_batch:
> i915_vma_put(batch);
> out_vma:
> i915_vma_unpin(vma);
> out_ce:
> intel_context_put(ce);
> - return err ? ERR_PTR(err) : rq;
> + return rq;
Hmm, I've used this style a few times, so could do with some syntactic
refinement.
drivers/gpu/drm/i915/gem/i915_gem_userptr.c:return err ? ERR_PTR(err) :
mm->mn;
drivers/gpu/drm/i915/gt/selftest_hangcheck.c: return err ? ERR_PTR(err) : rq;
drivers/gpu/drm/i915/gt/selftest_lrc.c: return err ? ERR_PTR(err) : rq;
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c: return err ? ERR_PTR(err) : rq;
drivers/gpu/drm/i915/selftests/i915_request.c: return err ? ERR_PTR(err) :
request;
drivers/gpu/drm/i915/selftests/igt_spinner.c: return err ? ERR_PTR(err) : rq;
-Chris
___
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: Remove local entries from GGTT on suspend
== Series Details == Series: drm/i915/gt: Remove local entries from GGTT on suspend URL : https://patchwork.freedesktop.org/series/77708/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8543 -> Patchwork_17792 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17792 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17792, 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_17792/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17792: ### IGT changes ### Possible regressions * igt@runner@aborted: - fi-ilk-650: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17792/fi-ilk-650/igt@run...@aborted.html - fi-pnv-d510:NOTRUN -> [FAIL][2] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17792/fi-pnv-d510/igt@run...@aborted.html - fi-byt-n2820: NOTRUN -> [FAIL][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17792/fi-byt-n2820/igt@run...@aborted.html - fi-ivb-3770:NOTRUN -> [FAIL][4] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17792/fi-ivb-3770/igt@run...@aborted.html - fi-byt-j1900: NOTRUN -> [FAIL][5] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17792/fi-byt-j1900/igt@run...@aborted.html - fi-elk-e7500: NOTRUN -> [FAIL][6] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17792/fi-elk-e7500/igt@run...@aborted.html - fi-blb-e6850: NOTRUN -> [FAIL][7] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17792/fi-blb-e6850/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_17792 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0: - fi-pnv-d510:[PASS][8] -> [INCOMPLETE][9] ([i915#299]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/fi-pnv-d510/igt@gem_exec_susp...@basic-s0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17792/fi-pnv-d510/igt@gem_exec_susp...@basic-s0.html - fi-blb-e6850: [PASS][10] -> [INCOMPLETE][11] ([i915#1242]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/fi-blb-e6850/igt@gem_exec_susp...@basic-s0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17792/fi-blb-e6850/igt@gem_exec_susp...@basic-s0.html - fi-elk-e7500: [PASS][12] -> [INCOMPLETE][13] ([i915#66]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/fi-elk-e7500/igt@gem_exec_susp...@basic-s0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17792/fi-elk-e7500/igt@gem_exec_susp...@basic-s0.html - fi-ilk-650: [PASS][14] -> [INCOMPLETE][15] ([i915#1242]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/fi-ilk-650/igt@gem_exec_susp...@basic-s0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17792/fi-ilk-650/igt@gem_exec_susp...@basic-s0.html - fi-ivb-3770:[PASS][16] -> [INCOMPLETE][17] ([i915#1242]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/fi-ivb-3770/igt@gem_exec_susp...@basic-s0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17792/fi-ivb-3770/igt@gem_exec_susp...@basic-s0.html - fi-hsw-4770:[PASS][18] -> [INCOMPLETE][19] ([i915#1242]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/fi-hsw-4770/igt@gem_exec_susp...@basic-s0.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17792/fi-hsw-4770/igt@gem_exec_susp...@basic-s0.html - fi-byt-j1900: [PASS][20] -> [INCOMPLETE][21] ([i915#45]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/fi-byt-j1900/igt@gem_exec_susp...@basic-s0.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17792/fi-byt-j1900/igt@gem_exec_susp...@basic-s0.html - fi-byt-n2820: [PASS][22] -> [INCOMPLETE][23] ([i915#45]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/fi-byt-n2820/igt@gem_exec_susp...@basic-s0.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17792/fi-byt-n2820/igt@gem_exec_susp...@basic-s0.html Possible fixes * igt@debugfs_test@read_all_entries: - fi-bsw-nick:[INCOMPLETE][24] ([i915#1250] / [i915#1436]) -> [PASS][25] [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/fi-bsw-nick/igt@debugfs_test@read_all_entries.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17792/fi-bsw-nick/igt@debugfs_test@read_all_entries.html [i915#1242]: https://gitlab.freedesktop.org/drm/intel/issues/1242 [i915#1250]:
Re: [Intel-gfx] [PATCH 2/3] drm/i915: work around false-positive maybe-uninitialized warning
Quoting Arnd Bergmann (2020-05-27 15:05:09) > gcc-9 gets confused by the code flow in check_dirty_whitelist: > > drivers/gpu/drm/i915/gt/selftest_workarounds.c: In function > 'check_dirty_whitelist': > drivers/gpu/drm/i915/gt/selftest_workarounds.c:492:17: error: 'rsvd' may be > used uninitialized in this function [-Werror=maybe-uninitialized] > > I could not figure out a good way to do this in a way that gcc > understands better, so initialize the variable to zero, as last > resort. Does it look neater if we initialise it as a local? No. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/atomic-helper: reset vblank on crtc reset
On Wed, May 27, 2020 at 11:48 AM Daniel Vetter wrote:
>
> Only when vblanks are supported ofc.
>
> Some drivers do this already, but most unfortunately missed it. This
> opens up bugs after driver load, before the crtc is enabled for the
> first time. syzbot spotted this when loading vkms as a secondary
> output. Given how many drivers are buggy it's best to solve this once
> and for all in shared helper code.
>
> Aside from moving the few existing calls to drm_crtc_vblank_reset into
> helpers (i915 doesn't use helpers, so keeps its own) I think the
> regression risk is minimal: atomic helpers already rely on drivers
> calling drm_crtc_vblank_on/off correctly in their hooks when they
> support vblanks. And driver that's failing to handle vblanks after
> this is missing those calls already, and vblanks could only work by
> accident when enabling a CRTC for the first time right after boot.
>
> Big thanks to Tetsuo for helping track down what's going wrong here.
>
> There's only a few drivers which already had the necessary call and
> needed some updating:
> - komeda, atmel and tidss also needed to be changed to call
> __drm_atomic_helper_crtc_reset() intead of open coding it
> - tegra and msm even had it in the same place already, just code
> motion, and malidp already uses __drm_atomic_helper_crtc_reset().
>
> Only call left is in i915, which doesn't use drm_mode_config_reset,
> but has its own fastboot infrastructure. So that's the only case where
> we actually want this in the driver still.
>
> I've also reviewed all other drivers which set up vblank support with
> drm_vblank_init. After the previous patch fixing mxsfb all atomic
> drivers do call drm_crtc_vblank_on/off as they should, the remaining
> drivers are either legacy kms or legacy dri1 drivers, so not affected
> by this change to atomic helpers.
>
> Link:
> https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
> Reported-by: Tetsuo Handa
> Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
> Cc: Tetsuo Handa
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
> Cc: Mihail Atanassov
> Cc: Brian Starkey
> Cc: Sam Ravnborg
> Cc: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Ludovic Desroches
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Brian Masney
> Cc: Emil Velikov
> Cc: zhengbin
> Cc: Thomas Gleixner
> Cc: linux-te...@vger.kernel.org
> Signed-off-by: Daniel Vetter
For the atmel part from irc because Sam's isp refused to send out a
mail with this many recipients:
Reviewed-by: Sam Ravnborg
Cheers, Daniel
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++-
> drivers/gpu/drm/arm/malidp_drv.c | 1 -
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 7 ++-
> drivers/gpu/drm/drm_atomic_state_helper.c| 4
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 2 --
> drivers/gpu/drm/tegra/dc.c | 1 -
> drivers/gpu/drm/tidss/tidss_crtc.c | 3 +--
> drivers/gpu/drm/tidss/tidss_kms.c| 4
> 8 files changed, 9 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 56bd938961ee..f33418d6e1a0 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -492,10 +492,8 @@ static void komeda_crtc_reset(struct drm_crtc *crtc)
> crtc->state = NULL;
>
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> - }
> + if (state)
> + __drm_atomic_helper_crtc_reset(crtc, >base);
> }
>
> static struct drm_crtc_state *
> @@ -616,7 +614,6 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
> return err;
>
> drm_crtc_helper_add(crtc, _crtc_helper_funcs);
> - drm_crtc_vblank_reset(crtc);
>
> crtc->port = kcrtc->master->of_output_port;
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index c2507b7d8512..02904392e370 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -870,7 +870,6 @@ static int malidp_bind(struct device *dev)
> drm->irq_enabled = true;
>
> ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
> - drm_crtc_vblank_reset(>crtc);
> if (ret < 0) {
> DRM_ERROR("failed to initialise vblank\n");
> goto vblank_fail;
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index 10985134ce0b..ce246b96330b 100644
> ---
Re: [Intel-gfx] [PATCH 1/3] drm/i915/pmu: avoid an maybe-uninitialized warning
Quoting Arnd Bergmann (2020-05-27 15:05:08)
> Conditional spinlocks make it hard for gcc and for lockdep to
> follow the code flow. This one causes a warning with at least
> gcc-9 and higher:
>
> In file included from include/linux/irq.h:14,
> from drivers/gpu/drm/i915/i915_pmu.c:7:
> drivers/gpu/drm/i915/i915_pmu.c: In function 'i915_sample':
> include/linux/spinlock.h:289:3: error: 'flags' may be used uninitialized in
> this function [-Werror=maybe-uninitialized]
> 289 | _raw_spin_unlock_irqrestore(lock, flags); \
> | ^~~
> drivers/gpu/drm/i915/i915_pmu.c:288:17: note: 'flags' was declared here
> 288 | unsigned long flags;
> | ^
>
> Split out the part between the locks into a separate function
> for readability and to let the compiler figure out what the
> logic actually is.
>
> Fixes: d79e1bd676f0 ("drm/i915/pmu: Only use exclusive mmio access for gen7")
> Signed-off-by: Arnd Bergmann
> ---
> I have no idea why I see three separate issues like this pop up in i915,
> there are not a lot of them elsewhere.
gcc v8:
add/remove: 1/0 grow/shrink: 0/1 up/down: 99/-164 (-65)
Function old new delta
engine_sample - 99 +99
i915_sample 871 707-164
Which is compelling. Is gcc 9 simliar?
Given the above reduction, I find it hard to argue with.
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()'
On Wed, May 13, 2020 at 05:08:19PM +, Ashwin H wrote: > > Ok, but what does that mean for us? > > > > You need to say why you are sending a patch, otherwise we will guess wrong. > > In drivers/gpu/drm/i915/i915_gem_execbuffer.c, ioctl functions does > user_access_begin() without doing access_ok(Checks if a user space pointer is > valid) first. > A local attacker can craft a malicious ioctl function call to overwrite > arbitrary kernel memory, resulting in a Denial of Service or privilege > escalation (CVE-2018-20669) > > This patch makes sure that user_access_begin always does access_ok. > user_access_begin has been modified to do access_ok internally. I had this in the tree, but it broke the build on alpha, sh, and maybe a few others :( See: https://lore.kernel.org/r/20200527140225.ga214...@roeck-us.net for the details. Can you dig out all of the needed follow-on patches as well, and send them all as a patch series for 4.19.y so that I can queue them all up at once? thanks, greg k-h ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/pmu: avoid an maybe-uninitialized warning
== Series Details == Series: series starting with [1/3] drm/i915/pmu: avoid an maybe-uninitialized warning URL : https://patchwork.freedesktop.org/series/77706/ State : success == Summary == CI Bug Log - changes from CI_DRM_8543 -> Patchwork_17791 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17791/index.html Known issues Here are the changes found in Patchwork_17791 that come from known issues: ### IGT changes ### Possible fixes * igt@debugfs_test@read_all_entries: - fi-bsw-nick:[INCOMPLETE][1] ([i915#1250] / [i915#1436]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/fi-bsw-nick/igt@debugfs_test@read_all_entries.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17791/fi-bsw-nick/igt@debugfs_test@read_all_entries.html [i915#1250]: https://gitlab.freedesktop.org/drm/intel/issues/1250 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 Participating hosts (51 -> 43) -- Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-kbl-7560u fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8543 -> Patchwork_17791 CI-20190529: 20190529 CI_DRM_8543: 3fcc7e306e95013f1f4c527e0dda96197e1243bf @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5680: f7e3772175c53f0c910f4513831791cb5bdcab04 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17791: c333523a465573fc6e237bcd98a186a63f085d12 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c333523a4655 drm/i915/selftests: avoid bogus maybe-uninitialized warning 459542001c2c drm/i915: work around false-positive maybe-uninitialized warning b6493a221e8d drm/i915/pmu: avoid an maybe-uninitialized warning == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17791/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Remove local entries from GGTT on suspend
Across suspend/resume, we clear the entire GGTT and rebuild from
scratch. In particular, we only preserve the global entries for use by
the HW, and delay reinstating the local binds until required by the
user. This means that we can evict and recover any local binds in the
global GTT, saving any time in preserving their state.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1947
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 15 +--
drivers/gpu/drm/i915/i915_vma.c | 59 +++-
drivers/gpu/drm/i915/i915_vma.h | 1 +
3 files changed, 45 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 317172ad5ef3..3b8d7f830a2c 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -108,13 +108,22 @@ static bool needs_idle_maps(struct drm_i915_private *i915)
void i915_ggtt_suspend(struct i915_ggtt *ggtt)
{
- struct i915_vma *vma;
+ struct i915_vma *vma, *vn;
+ int open;
- list_for_each_entry(vma, >vm.bound_list, vm_link)
- i915_vma_wait_for_bind(vma);
+ /* Skip rewriting PTE on VMA unbind. */
+ open = atomic_xchg(>vm.open, 0);
+ list_for_each_entry_safe(vma, vn, >vm.bound_list, vm_link) {
+ i915_vma_wait_for_bind(vma);
+ if (!i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND)) {
+ __i915_vma_evict(vma);
+ drm_mm_remove_node(>node);
+ }
+ }
ggtt->vm.clear_range(>vm, 0, ggtt->vm.total);
ggtt->invalidate(ggtt);
+ atomic_set(>vm.open, open);
intel_gt_check_and_clear_faults(ggtt->vm.gt);
}
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 22198b758459..9b30ddc49e4b 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1229,31 +1229,9 @@ int i915_vma_move_to_active(struct i915_vma *vma,
return 0;
}
-int __i915_vma_unbind(struct i915_vma *vma)
+void __i915_vma_evict(struct i915_vma *vma)
{
- int ret;
-
- lockdep_assert_held(>vm->mutex);
-
- if (i915_vma_is_pinned(vma)) {
- vma_print_allocator(vma, "is pinned");
- return -EAGAIN;
- }
-
- /*
-* After confirming that no one else is pinning this vma, wait for
-* any laggards who may have crept in during the wait (through
-* a residual pin skipping the vm->mutex) to complete.
-*/
- ret = i915_vma_sync(vma);
- if (ret)
- return ret;
-
- if (!drm_mm_node_allocated(>node))
- return 0;
-
GEM_BUG_ON(i915_vma_is_pinned(vma));
- GEM_BUG_ON(i915_vma_is_active(vma));
if (i915_vma_is_map_and_fenceable(vma)) {
/* Force a pagefault for domain tracking on next user access */
@@ -1292,6 +1270,33 @@ int __i915_vma_unbind(struct i915_vma *vma)
i915_vma_detach(vma);
vma_unbind_pages(vma);
+}
+
+int __i915_vma_unbind(struct i915_vma *vma)
+{
+ int ret;
+
+ lockdep_assert_held(>vm->mutex);
+
+ if (!drm_mm_node_allocated(>node))
+ return 0;
+
+ if (i915_vma_is_pinned(vma)) {
+ vma_print_allocator(vma, "is pinned");
+ return -EAGAIN;
+ }
+
+ /*
+* After confirming that no one else is pinning this vma, wait for
+* any laggards who may have crept in during the wait (through
+* a residual pin skipping the vm->mutex) to complete.
+*/
+ ret = i915_vma_sync(vma);
+ if (ret)
+ return ret;
+
+ GEM_BUG_ON(i915_vma_is_active(vma));
+ __i915_vma_evict(vma);
drm_mm_remove_node(>node); /* pairs with i915_vma_release() */
return 0;
@@ -1303,13 +1308,13 @@ int i915_vma_unbind(struct i915_vma *vma)
intel_wakeref_t wakeref = 0;
int err;
- if (!drm_mm_node_allocated(>node))
- return 0;
-
/* Optimistic wait before taking the mutex */
err = i915_vma_sync(vma);
if (err)
- goto out_rpm;
+ return err;
+
+ if (!drm_mm_node_allocated(>node))
+ return 0;
if (i915_vma_is_pinned(vma)) {
vma_print_allocator(vma, "is pinned");
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 8ad1daabcd58..d0d01f909548 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -203,6 +203,7 @@ bool i915_vma_misplaced(const struct i915_vma *vma,
u64 size, u64 alignment, u64 flags);
void __i915_vma_set_map_and_fenceable(struct i915_vma *vma);
void i915_vma_revoke_mmap(struct i915_vma *vma);
+void __i915_vma_evict(struct i915_vma *vma);
int __i915_vma_unbind(struct i915_vma *vma);
int __must_check i915_vma_unbind(struct i915_vma
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Prevent timeslicing into unpreemptible requests (rev3)
== Series Details == Series: drm/i915/gt: Prevent timeslicing into unpreemptible requests (rev3) URL : https://patchwork.freedesktop.org/series/77697/ State : success == Summary == CI Bug Log - changes from CI_DRM_8543 -> Patchwork_17790 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17790/index.html Known issues Here are the changes found in Patchwork_17790 that come from known issues: ### IGT changes ### Issues hit * igt@kms_chamelium@dp-crc-fast: - fi-icl-u2: [PASS][1] -> [FAIL][2] ([i915#262]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17790/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html Possible fixes * igt@debugfs_test@read_all_entries: - fi-bsw-nick:[INCOMPLETE][3] ([i915#1250] / [i915#1436]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/fi-bsw-nick/igt@debugfs_test@read_all_entries.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17790/fi-bsw-nick/igt@debugfs_test@read_all_entries.html [i915#1250]: https://gitlab.freedesktop.org/drm/intel/issues/1250 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262 Participating hosts (51 -> 43) -- Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-kbl-7560u fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8543 -> Patchwork_17790 CI-20190529: 20190529 CI_DRM_8543: 3fcc7e306e95013f1f4c527e0dda96197e1243bf @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5680: f7e3772175c53f0c910f4513831791cb5bdcab04 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17790: 0ac958b512be6cde56f9898fd392844f9285bbb4 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 0ac958b512be drm/i915/gt: Prevent timeslicing into unpreemptible requests == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17790/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for i915: Add debugfs for requesting HDCP version
== Series Details == Series: i915: Add debugfs for requesting HDCP version URL : https://patchwork.freedesktop.org/series/77693/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8542_full -> Patchwork_17785_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17785_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17785_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_17785_full: ### IGT changes ### Possible regressions * igt@gem_render_copy@yf-tiled-ccs-to-y-tiled-ccs: - shard-glk: NOTRUN -> [TIMEOUT][1] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17785/shard-glk1/igt@gem_render_c...@yf-tiled-ccs-to-y-tiled-ccs.html * igt@runner@aborted: - shard-hsw: NOTRUN -> [FAIL][2] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17785/shard-hsw8/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_17785_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@system-suspend-modeset: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([i915#151] / [i915#69]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8542/shard-skl2/igt@i915_pm_...@system-suspend-modeset.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17785/shard-skl2/igt@i915_pm_...@system-suspend-modeset.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8542/shard-apl8/igt@i915_susp...@sysfs-reader.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17785/shard-apl6/igt@i915_susp...@sysfs-reader.html * igt@kms_cursor_crc@pipe-c-cursor-64x64-offscreen: - shard-hsw: [PASS][7] -> [DMESG-WARN][8] ([i915#1927]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8542/shard-hsw6/igt@kms_cursor_...@pipe-c-cursor-64x64-offscreen.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17785/shard-hsw8/igt@kms_cursor_...@pipe-c-cursor-64x64-offscreen.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8542/shard-kbl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17785/shard-kbl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_frontbuffer_tracking@psr-suspend: - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([i915#123] / [i915#69]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8542/shard-skl8/igt@kms_frontbuffer_track...@psr-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17785/shard-skl7/igt@kms_frontbuffer_track...@psr-suspend.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#1188]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8542/shard-skl4/igt@kms_...@bpc-switch-dpms.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17785/shard-skl9/igt@kms_...@bpc-switch-dpms.html * igt@kms_plane@plane-panning-bottom-right-pipe-b-planes: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#1036]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8542/shard-skl2/igt@kms_pl...@plane-panning-bottom-right-pipe-b-planes.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17785/shard-skl2/igt@kms_pl...@plane-panning-bottom-right-pipe-b-planes.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180] / [i915#93] / [i915#95]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8542/shard-kbl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17785/shard-kbl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145] / [i915#265]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8542/shard-skl2/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17785/shard-skl2/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_psr@psr2_sprite_mmap_cpu: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) [21]:
Re: [Intel-gfx] [RFC PATCH 1/4] drm/i915: Drop user contexts on driver remove
Quoting Janusz Krzysztofik (2020-05-18 20:17:17)
> Contexts associated with open device file descriptors together with
> their assigned address spaces are now closed on device file close. On
> address space closure its associated DMA mappings are revoked. If the
> device is removed while being open, subsequent attempts to revoke
> those mappings while closing the device file descriptor may may be
> judged by intel-iommu code as a bug and result in kernel panic.
>
> Since user contexts become useless after the device is no longer
> available, drop them on device removal.
>
> <4> [36.900985] [ cut here ]
> <2> [36.901005] kernel BUG at drivers/iommu/intel-iommu.c:3717!
> <4> [36.901105] invalid opcode: [#1] PREEMPT SMP NOPTI
> <4> [36.901117] CPU: 0 PID: 39 Comm: kworker/u8:1 Tainted: G U W
> 5.7.0-rc5-CI-CI_DRM_8485+ #1
> <4> [36.901133] Hardware name: Intel Corporation Elkhart Lake Embedded
> Platform/ElkhartLake LPDDR4x T3 CRB, BIOS EHLSFWI1.R00.1484.A00.1911290833
> 11/29/2019
> <4> [36.901250] Workqueue: i915 __i915_vm_release [i915]
> <4> [36.901264] RIP: 0010:intel_unmap+0x1f5/0x230
> <4> [36.901274] Code: 01 e8 9f bc a9 ff 85 c0 74 09 80 3d df 60 09 01 00 74
> 19 65 ff 0d 13 12 97 7e 0f 85 fc fe ff ff e8 82 b0 95 ff e9 f2 fe ff ff <0f>
> 0b e8 d4 bd a9 ff 85 c0 75 de 48 c7 c2 10 84 2c 82 be 54 00 00
> <4> [36.901302] RSP: 0018:c91ebdc0 EFLAGS: 00010246
> <4> [36.901313] RAX: RBX: 8882561dd000 RCX:
>
> <4> [36.901324] RDX: 1000 RSI: ffd9c000 RDI:
> 888274c94000
> <4> [36.901336] RBP: 888274c940b0 R08: R09:
> 0001
> <4> [36.901348] R10: 0a25d812 R11: 112af2d4 R12:
> 888252c70200
> <4> [36.901360] R13: ffd9c000 R14: 1000 R15:
> 8882561dd010
> <4> [36.901372] FS: () GS:88827800()
> knlGS:
> <4> [36.901386] CS: 0010 DS: ES: CR0: 80050033
> <4> [36.901396] CR2: 7f06def54950 CR3: 000255844000 CR4:
> 00340ef0
> <4> [36.901408] Call Trace:
> <4> [36.901418] ? process_one_work+0x1de/0x600
> <4> [36.901494] cleanup_page_dma+0x37/0x70 [i915]
> <4> [36.901573] free_pd+0x9/0x20 [i915]
> <4> [36.901644] gen8_ppgtt_cleanup+0x59/0xc0 [i915]
> <4> [36.901721] __i915_vm_release+0x14/0x30 [i915]
> <4> [36.901733] process_one_work+0x268/0x600
> <4> [36.901744] ? __schedule+0x307/0x8d0
> <4> [36.901756] worker_thread+0x37/0x380
> <4> [36.901766] ? process_one_work+0x600/0x600
> <4> [36.901775] kthread+0x140/0x160
> <4> [36.901783] ? kthread_park+0x80/0x80
> <4> [36.901792] ret_from_fork+0x24/0x50
> <4> [36.901804] Modules linked in: mei_hdcp i915 x86_pkg_temp_thermal
> coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ax88179_178a
> usbnet mii mei_me mei prime_numbers intel_lpss_pci
> <4> [36.901857] ---[ end trace 52d1b4d81f8d1ea7 ]---
>
> Signed-off-by: Janusz Krzysztofik
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 38 +
> drivers/gpu/drm/i915/gem/i915_gem_context.h | 1 +
> drivers/gpu/drm/i915/i915_gem.c | 2 ++
> 3 files changed, 41 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 900ea8b7fc8f..0096a69fbfd3 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -927,6 +927,44 @@ void i915_gem_driver_release__contexts(struct
> drm_i915_private *i915)
> rcu_barrier(); /* and flush the left over RCU frees */
> }
>
> +void i915_gem_driver_remove__contexts(struct drm_i915_private *i915)
> +{
> + struct i915_gem_context *ctx, *cn;
> +
> + list_for_each_entry_safe(ctx, cn, >gem.contexts.list, link) {
You're not removing ctx from gem.contexts.list inside this loop.
> + struct drm_i915_file_private *file_priv = ctx->file_priv;
> + struct i915_gem_context *entry;
> + unsigned long int id;
> +
> + if (i915_gem_context_is_closed(ctx) || IS_ERR(file_priv))
> + continue;
> +
> + xa_for_each(_priv->context_xa, id, entry) {
We're iterating over contexts?
I thought we were already doing that by going over i915->gem.contexts.list.
> + struct i915_address_space *vm;
> + unsigned long int idx;
> +
> + if (entry != ctx)
> + continue;
> +
> + xa_erase(_priv->context_xa, id);
> +
> + if (id)
> + break;
Ok... So we're exiting early for !default contexts?
> +
> + xa_for_each(_priv->vm_xa, idx, vm) {
> + xa_erase(_priv->vm_xa, idx);
> + i915_vm_put(vm);
> + }
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/edid: Allow looking for ext blocks starting from a specified index
== Series Details == Series: series starting with [1/3] drm/edid: Allow looking for ext blocks starting from a specified index URL : https://patchwork.freedesktop.org/series/77699/ State : success == Summary == CI Bug Log - changes from CI_DRM_8543 -> Patchwork_17789 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17789/index.html Known issues Here are the changes found in Patchwork_17789 that come from known issues: ### IGT changes ### Possible fixes * igt@debugfs_test@read_all_entries: - fi-bsw-nick:[INCOMPLETE][1] ([i915#1250] / [i915#1436]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/fi-bsw-nick/igt@debugfs_test@read_all_entries.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17789/fi-bsw-nick/igt@debugfs_test@read_all_entries.html [i915#1250]: https://gitlab.freedesktop.org/drm/intel/issues/1250 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 Participating hosts (51 -> 43) -- Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-kbl-7560u fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8543 -> Patchwork_17789 CI-20190529: 20190529 CI_DRM_8543: 3fcc7e306e95013f1f4c527e0dda96197e1243bf @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5680: f7e3772175c53f0c910f4513831791cb5bdcab04 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17789: 664307455438421fd8ff172ec0039eb34526a0d8 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 664307455438 drm/edid: Clean up some curly braces 937f677c9c61 drm/edid: Iterate through all DispID ext blocks ee55e335d41d drm/edid: Allow looking for ext blocks starting from a specified index == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17789/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic-helper: reset vblank on crtc reset
On Wed, May 27, 2020 at 2:08 PM Liviu Dudau wrote:
>
> On Wed, May 27, 2020 at 01:07:05PM +0200, Daniel Vetter wrote:
> > On Wed, May 27, 2020 at 12:57 PM Liviu Dudau wrote:
> > >
> > > Hi Daniel,
> > >
> > > On Wed, May 27, 2020 at 11:53:32AM +0200, Daniel Vetter wrote:
> > > > Only when vblanks are supported ofc.
> > > >
> > > > Some drivers do this already, but most unfortunately missed it. This
> > > > opens up bugs after driver load, before the crtc is enabled for the
> > > > first time. syzbot spotted this when loading vkms as a secondary
> > > > output. Given how many drivers are buggy it's best to solve this once
> > > > and for all in shared helper code.
> > > >
> > > > Aside from moving the few existing calls to drm_crtc_vblank_reset into
> > > > helpers (i915 doesn't use helpers, so keeps its own) I think the
> > > > regression risk is minimal: atomic helpers already rely on drivers
> > > > calling drm_crtc_vblank_on/off correctly in their hooks when they
> > > > support vblanks. And driver that's failing to handle vblanks after
> > > > this is missing those calls already, and vblanks could only work by
> > > > accident when enabling a CRTC for the first time right after boot.
> > > >
> > > > Big thanks to Tetsuo for helping track down what's going wrong here.
> > > >
> > > > There's only a few drivers which already had the necessary call and
> > > > needed some updating:
> > > > - komeda, atmel and tidss also needed to be changed to call
> > > > __drm_atomic_helper_crtc_reset() intead of open coding it
> > > > - tegra and msm even had it in the same place already, just code
> > > > motion, and malidp already uses __drm_atomic_helper_crtc_reset().
> > > >
> > > > Only call left is in i915, which doesn't use drm_mode_config_reset,
> > > > but has its own fastboot infrastructure. So that's the only case where
> > > > we actually want this in the driver still.
> > > >
> > > > I've also reviewed all other drivers which set up vblank support with
> > > > drm_vblank_init. After the previous patch fixing mxsfb all atomic
> > > > drivers do call drm_crtc_vblank_on/off as they should, the remaining
> > > > drivers are either legacy kms or legacy dri1 drivers, so not affected
> > > > by this change to atomic helpers.
> > > >
> > > > v2: Use the drm_dev_has_vblank() helper.
> > > >
> > > > Link:
> > > > https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
> > > > Reported-by: Tetsuo Handa
> > > > Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
> > > > Cc: Tetsuo Handa
> > > > Cc: "James (Qian) Wang"
> > > > Cc: Liviu Dudau
> > > > Cc: Mihail Atanassov
> > > > Cc: Brian Starkey
> > > > Cc: Sam Ravnborg
> > > > Cc: Boris Brezillon
> > > > Cc: Nicolas Ferre
> > > > Cc: Alexandre Belloni
> > > > Cc: Ludovic Desroches
> > > > Cc: Maarten Lankhorst
> > > > Cc: Maxime Ripard
> > > > Cc: Thomas Zimmermann
> > > > Cc: David Airlie
> > > > Cc: Daniel Vetter
> > > > Cc: Thierry Reding
> > > > Cc: Jonathan Hunter
> > > > Cc: Jyri Sarha
> > > > Cc: Tomi Valkeinen
> > > > Cc: Rob Clark
> > > > Cc: Sean Paul
> > > > Cc: Brian Masney
> > > > Cc: Emil Velikov
> > > > Cc: zhengbin
> > > > Cc: Thomas Gleixner
> > > > Cc: linux-te...@vger.kernel.org
> > > > Signed-off-by: Daniel Vetter
> > > > ---
> > > > drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++-
> > > > drivers/gpu/drm/arm/malidp_drv.c | 1 -
> > > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 7 ++-
> > > > drivers/gpu/drm/drm_atomic_state_helper.c| 4
> > > > drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 2 --
> > > > drivers/gpu/drm/tegra/dc.c | 1 -
> > > > drivers/gpu/drm/tidss/tidss_crtc.c | 3 +--
> > > > drivers/gpu/drm/tidss/tidss_kms.c| 4
> > > > 8 files changed, 9 insertions(+), 20 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > > b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > > index 56bd938961ee..f33418d6e1a0 100644
> > > > --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > > @@ -492,10 +492,8 @@ static void komeda_crtc_reset(struct drm_crtc
> > > > *crtc)
> > > > crtc->state = NULL;
> > > >
> > > > state = kzalloc(sizeof(*state), GFP_KERNEL);
> > > > - if (state) {
> > > > - crtc->state = >base;
> > > > - crtc->state->crtc = crtc;
> > > > - }
> > > > + if (state)
> > > > + __drm_atomic_helper_crtc_reset(crtc, >base);
> > > > }
> > > >
> > > > static struct drm_crtc_state *
> > > > @@ -616,7 +614,6 @@ static int komeda_crtc_add(struct komeda_kms_dev
> > > > *kms,
> > > > return err;
> > > >
> > > > drm_crtc_helper_add(crtc, _crtc_helper_funcs);
> > > > - drm_crtc_vblank_reset(crtc);
> > > >
> > > > crtc->port =
Re: [Intel-gfx] [RFC 1/2] drm/i915: Add support for considering HDCP ver requested via debugfs
On Wed, 27 May 2020, Ankit Nautiyal wrote:
> For testing and debugging each HDCP version separately, a debugfs
> entry for requesting a specific version is required. The vesion
> requested via debugfs needs to be stored in hdcp structure. This can
> then be considered while enabling HDCP, provided the platform and the
> display supports the requested version.
>
> This patch adds the support for storing the version requested as a 32bit
> flag. The default value is set to signify that any of the HDCP version
> can be used.
>
> If a specific HDCP version is requested through the debugfs, the driver
> chooses that version, instead of policy of choosing the highest HDCP
> version supported.
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_display_types.h | 10 ++
> drivers/gpu/drm/i915/display/intel_hdcp.c | 8 ++--
> 2 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 9488449e4b94..cfa641c70717 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -408,6 +408,16 @@ struct intel_hdcp {
>* Hence caching the transcoder here.
>*/
> enum transcoder cpu_transcoder;
> +
> + /*
> + * HDCP version requested from debugfs i915_hdcp_ver_request.
> + * Kernel will read these bits and entertain the request, as per
> + * the HDCP capability of the panel and platform.
> + */
> +#define HDCP_VERSION_1_4 0x01
> +#define HDCP_VERSION_2_2 0x02
> +#define HDCP_VERSION_MASK0x03
> + u32 debugfs_ver_request;
> };
>
> struct intel_connector {
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 2cbc4619b4ce..951401046804 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -1977,6 +1977,8 @@ int intel_hdcp_init(struct intel_connector *connector,
> if (!shim)
> return -EINVAL;
>
> + hdcp->debugfs_ver_request = HDCP_VERSION_MASK;
It's almost always better to keep 0 as the default or initial value. If
the member is non-zero, you do as requested.
> +
> if (is_hdcp2_supported(dev_priv))
> intel_hdcp2_init(connector, shim);
>
> @@ -2023,7 +2025,8 @@ int intel_hdcp_enable(struct intel_connector *connector,
>* Considering that HDCP2.2 is more secure than HDCP1.4, If the setup
>* is capable of HDCP2.2, it is preferred to use HDCP2.2.
>*/
> - if (intel_hdcp2_capable(connector)) {
> + if ((hdcp->debugfs_ver_request & HDCP_VERSION_2_2) &&
> + intel_hdcp2_capable(connector)) {
> ret = _intel_hdcp2_enable(connector);
> if (!ret)
> check_link_interval = DRM_HDCP2_CHECK_PERIOD_MS;
> @@ -2033,7 +2036,8 @@ int intel_hdcp_enable(struct intel_connector *connector,
>* When HDCP2.2 fails and Content Type is not Type1, HDCP1.4 will
>* be attempted.
>*/
> - if (ret && intel_hdcp_capable(connector) &&
> + if (ret && (hdcp->debugfs_ver_request & HDCP_VERSION_1_4) &&
> + intel_hdcp_capable(connector) &&
> hdcp->content_type != DRM_MODE_HDCP_CONTENT_TYPE1) {
> ret = _intel_hdcp_enable(connector);
> }
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 2/2] drm/i915: Add a new debugfs to request HDCP version
On Wed, 27 May 2020, Ankit Nautiyal wrote:
> As per the current HDCP design, the driver selects the highest
> version of HDCP that can be used to satisfy the content-protection
> requirements of the user. Due to this, the content-protection
> tests cannot test a lower version of HDCP, if the platform and the
> display panel, both support higher HDCP version.
>
> To provide some support for testing and debugging, a per-connector
> debugfs is required to set the HDCP version via debugfs that the
> kernel can consider, while enabling HDCP.
>
> This patch adds a new debugfs entry for each connector that supports
> HDCP. For enforcing a particular HDCP version for a connector, the user
> can write into the debugfs for that connector.
>
> To make design simple, the HDCP version request can only be made via
> debugfs, if there is no ongoing request for Content-Protection for
> the connector. The tests are expected to make sure that HDCP is disabled
> before making HDCP version request via the debugfs for the connector.
> Otherwise, the write request to the debugfs will be failed.
>
> Signed-off-by: Ankit Nautiyal
> ---
> .../drm/i915/display/intel_display_debugfs.c | 98 +++
> 1 file changed, 98 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 70525623bcdf..e65abca1a1fa 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -2185,6 +2185,102 @@ static const struct file_operations
> i915_dsc_fec_support_fops = {
> .write = i915_dsc_fec_support_write
> };
>
> +static int i915_hdcp_ver_request_show(struct seq_file *m, void *data)
> +{
> +
> + struct drm_connector *connector = m->private;
> + struct intel_connector *intel_connector = to_intel_connector(connector);
> + u64 hdcp_ver_flag;
u64 seems a little excessive for something that needs 2 bits.
> +
> + if (connector->status != connector_status_connected)
> + return -ENODEV;
> +
> + /* HDCP is supported by connector */
> + if (!intel_connector->hdcp.shim)
> + return -EINVAL;
Why do you need to check these? The version request is valid regardless
of connection or hdcp, no?
> +
> + hdcp_ver_flag = intel_connector->hdcp.debugfs_ver_request;
> + seq_printf(m, "HDCP_VER_FLAGS: %llu\n", hdcp_ver_flag);
> +
> + seq_printf(m, "Requested Versions:\n");
> + if (hdcp_ver_flag & HDCP_VERSION_1_4)
> + seq_printf(m, "HDCP1.4\n");
> + if (hdcp_ver_flag & HDCP_VERSION_2_2)
> + seq_printf(m, "HDCP2.2\n");
Why do you need to print duplicated information? One or the other, not
both. Simplify, don't complicate.
> +
> + return 0;
> +}
> +
> +static int i915_hdcp_ver_request_open(struct inode *inode,
> + struct file *file)
> +{
> + return single_open(file, i915_hdcp_ver_request_show,
> +inode->i_private);
> +}
> +
> +static int intel_hdcp_debugfs_ver_set(struct intel_connector *connector, u64
> val)
> +{
> + struct intel_hdcp *hdcp = >hdcp;
> +
> + if (!hdcp->shim || val > HDCP_VERSION_MASK)
> + return -EINVAL;
> +
> + if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
> + return -EINVAL;
What does it matter if you can request the version independent of what's
currently going on? I think it's just extra code that can go wrong here.
> +
> + hdcp->debugfs_ver_request = val;
Usually there's a blank line before the return.
> + return 0;
> +}
Perhaps even the helper is excessive here.
> +
> +static ssize_t i915_hdcp_ver_request_write(struct file *file,
> + const char __user *ubuf,
> + size_t len, loff_t *offp)
> +{
> + unsigned int hdcp_ver = 0;
> + int ret;
> + struct drm_connector *connector =
> + ((struct seq_file *)file->private_data)->private;
> + struct intel_connector *intel_con = to_intel_connector(connector);
It's *never* intel_con. It's either intel_connector or just connector.
> + struct drm_i915_private *i915 = to_i915(connector->dev);
> + char tmp[16];
> +
> + if (len == 0)
> + return 0;
> +
> + if (len >= sizeof(tmp))
> + return -EINVAL;
> +
> + if (copy_from_user(tmp, ubuf, len))
> + return -EFAULT;
> +
> + tmp[len] = '\0';
> +
> +
> + drm_dbg(>drm,
> + "Copied %zu bytes from user to request hdcp ver\n", len);
> +
> + ret = kstrtouint(tmp, 10, _ver);
> + if (ret < 0)
> + return ret;
Replace most of the above with val = kstrtouint_from_user(...).
> +
> + drm_dbg(>drm, "Got %u for HDCP version\n", hdcp_ver);
Useless.
> + ret = intel_hdcp_debugfs_ver_set(intel_con, hdcp_ver);
> + if (ret < 0)
> + return ret;
> +
> + *offp +=
[Intel-gfx] [PATCH 1/3] drm/i915/pmu: avoid an maybe-uninitialized warning
Conditional spinlocks make it hard for gcc and for lockdep to
follow the code flow. This one causes a warning with at least
gcc-9 and higher:
In file included from include/linux/irq.h:14,
from drivers/gpu/drm/i915/i915_pmu.c:7:
drivers/gpu/drm/i915/i915_pmu.c: In function 'i915_sample':
include/linux/spinlock.h:289:3: error: 'flags' may be used uninitialized in
this function [-Werror=maybe-uninitialized]
289 | _raw_spin_unlock_irqrestore(lock, flags); \
| ^~~
drivers/gpu/drm/i915/i915_pmu.c:288:17: note: 'flags' was declared here
288 | unsigned long flags;
| ^
Split out the part between the locks into a separate function
for readability and to let the compiler figure out what the
logic actually is.
Fixes: d79e1bd676f0 ("drm/i915/pmu: Only use exclusive mmio access for gen7")
Signed-off-by: Arnd Bergmann
---
I have no idea why I see three separate issues like this pop up in i915,
there are not a lot of them elsewhere.
drivers/gpu/drm/i915/i915_pmu.c | 84 -
1 file changed, 42 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index e991a707bdb7..962ded9ce73f 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -269,12 +269,48 @@ static bool exclusive_mmio_access(const struct
drm_i915_private *i915)
return IS_GEN(i915, 7);
}
+static void engine_sample(struct intel_engine_cs *engine, unsigned int
period_ns)
+{
+ struct intel_engine_pmu *pmu = >pmu;
+ bool busy;
+ u32 val;
+
+ val = ENGINE_READ_FW(engine, RING_CTL);
+ if (val == 0) /* powerwell off => engine idle */
+ return;
+
+ if (val & RING_WAIT)
+ add_sample(>sample[I915_SAMPLE_WAIT], period_ns);
+ if (val & RING_WAIT_SEMAPHORE)
+ add_sample(>sample[I915_SAMPLE_SEMA], period_ns);
+
+ /* No need to sample when busy stats are supported. */
+ if (intel_engine_supports_stats(engine))
+ return;
+
+ /*
+* While waiting on a semaphore or event, MI_MODE reports the
+* ring as idle. However, previously using the seqno, and with
+* execlists sampling, we account for the ring waiting as the
+* engine being busy. Therefore, we record the sample as being
+* busy if either waiting or !idle.
+*/
+ busy = val & (RING_WAIT_SEMAPHORE | RING_WAIT);
+ if (!busy) {
+ val = ENGINE_READ_FW(engine, RING_MI_MODE);
+ busy = !(val & MODE_IDLE);
+ }
+ if (busy)
+ add_sample(>sample[I915_SAMPLE_BUSY], period_ns);
+}
+
static void
engines_sample(struct intel_gt *gt, unsigned int period_ns)
{
struct drm_i915_private *i915 = gt->i915;
struct intel_engine_cs *engine;
enum intel_engine_id id;
+ unsigned long flags;
if ((i915->pmu.enable & ENGINE_SAMPLE_MASK) == 0)
return;
@@ -283,53 +319,17 @@ engines_sample(struct intel_gt *gt, unsigned int
period_ns)
return;
for_each_engine(engine, gt, id) {
- struct intel_engine_pmu *pmu = >pmu;
- spinlock_t *mmio_lock;
- unsigned long flags;
- bool busy;
- u32 val;
-
if (!intel_engine_pm_get_if_awake(engine))
continue;
- mmio_lock = NULL;
- if (exclusive_mmio_access(i915))
- mmio_lock = >uncore->lock;
-
- if (unlikely(mmio_lock))
- spin_lock_irqsave(mmio_lock, flags);
-
- val = ENGINE_READ_FW(engine, RING_CTL);
- if (val == 0) /* powerwell off => engine idle */
- goto skip;
-
- if (val & RING_WAIT)
- add_sample(>sample[I915_SAMPLE_WAIT], period_ns);
- if (val & RING_WAIT_SEMAPHORE)
- add_sample(>sample[I915_SAMPLE_SEMA], period_ns);
-
- /* No need to sample when busy stats are supported. */
- if (intel_engine_supports_stats(engine))
- goto skip;
-
- /*
-* While waiting on a semaphore or event, MI_MODE reports the
-* ring as idle. However, previously using the seqno, and with
-* execlists sampling, we account for the ring waiting as the
-* engine being busy. Therefore, we record the sample as being
-* busy if either waiting or !idle.
-*/
- busy = val & (RING_WAIT_SEMAPHORE | RING_WAIT);
- if (!busy) {
- val = ENGINE_READ_FW(engine, RING_MI_MODE);
- busy = !(val & MODE_IDLE);
+ if (exclusive_mmio_access(i915)) {
+
[Intel-gfx] [PATCH 2/3] drm/i915: work around false-positive maybe-uninitialized warning
gcc-9 gets confused by the code flow in check_dirty_whitelist:
drivers/gpu/drm/i915/gt/selftest_workarounds.c: In function
'check_dirty_whitelist':
drivers/gpu/drm/i915/gt/selftest_workarounds.c:492:17: error: 'rsvd' may be
used uninitialized in this function [-Werror=maybe-uninitialized]
I could not figure out a good way to do this in a way that gcc
understands better, so initialize the variable to zero, as last
resort.
Fixes: aee20aaed887 ("drm/i915: Implement read-only support in whitelist
selftest")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/i915/gt/selftest_workarounds.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
index 5ed323254ee1..32785463ec9e 100644
--- a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
@@ -623,6 +623,8 @@ static int check_dirty_whitelist(struct intel_context *ce)
err = -EINVAL;
goto out_unpin;
}
+ } else {
+ rsvd = 0;
}
expect = results[0];
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915/selftests: avoid bogus maybe-uninitialized warning
gcc has a problem following values through IS_ERR/PTR_ERR macros,
leading to a false-positive warning in allmodconfig, with any
compiler version:
In file included from drivers/gpu/drm/i915/gt/intel_lrc.c:5892:
drivers/gpu/drm/i915/gt/selftest_lrc.c: In function 'create_gpr_client.isra.0':
drivers/gpu/drm/i915/gt/selftest_lrc.c:2902:23: error: 'rq' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
This one is hard to avoid without impairing readability or adding a
bugus NULL pointer.
Fixes: c92724de6db1 ("drm/i915/selftests: Try to detect rollback during
batchbuffer preemption")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 824f99c4cc7c..933c3f5adf0a 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -2908,23 +2908,25 @@ create_gpr_client(struct intel_engine_cs *engine,
vma = i915_vma_instance(global->obj, ce->vm, NULL);
if (IS_ERR(vma)) {
- err = PTR_ERR(vma);
+ rq = ERR_CAST(vma);
goto out_ce;
}
err = i915_vma_pin(vma, 0, 0, PIN_USER);
- if (err)
+ if (err) {
+ rq = ERR_PTR(err);
goto out_ce;
+ }
batch = create_gpr_user(engine, vma, offset);
if (IS_ERR(batch)) {
- err = PTR_ERR(batch);
+ rq = ERR_CAST(batch);
goto out_vma;
}
rq = intel_context_create_request(ce);
if (IS_ERR(rq)) {
- err = PTR_ERR(rq);
+ rq = ERR_CAST(rq);
goto out_batch;
}
@@ -2946,17 +2948,20 @@ create_gpr_client(struct intel_engine_cs *engine,
i915_vma_unlock(batch);
i915_vma_unpin(batch);
- if (!err)
+ if (!err) {
i915_request_get(rq);
- i915_request_add(rq);
-
+ i915_request_add(rq);
+ } else {
+ i915_request_add(rq);
+ rq = ERR_PTR(err);
+ }
out_batch:
i915_vma_put(batch);
out_vma:
i915_vma_unpin(vma);
out_ce:
intel_context_put(ce);
- return err ? ERR_PTR(err) : rq;
+ return rq;
}
static int preempt_user(struct intel_engine_cs *engine,
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Prevent timeslicing into unpreemptible requests
We have a I915_REQUEST_NOPREEMPT flag that we set when we must prevent
the HW from preempting during the course of this request. We need to
honour this flag and protect the HW even if we have a heartbeat request,
or other maximum priority barrier, pending. As such, restrict the
timeslicing check to avoid preempting into the topmost priority band,
leaving the unpreemptable requests in blissful peace running
uninterrupted on the HW.
Fixes: 2a98f4e65bba ("drm/i915: add infrastructure to hold off preemption on a
request")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c| 11 +++
drivers/gpu/drm/i915/gt/selftest_lrc.c | 116 +
2 files changed, 127 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 3214a4ecc31a..012afb9e0324 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1896,6 +1896,15 @@ static void defer_active(struct intel_engine_cs *engine)
defer_request(rq, i915_sched_lookup_priolist(engine, rq_prio(rq)));
}
+static inline int never_timeslice(int prio)
+{
+ /* Don't allow timeslicing of the 'unpreemptible' requests */
+ if (prio == I915_PRIORITY_UNPREEMPTABLE)
+ prio--;
+
+ return prio;
+}
+
static bool
need_timeslice(const struct intel_engine_cs *engine,
const struct i915_request *rq,
@@ -1927,6 +1936,7 @@ need_timeslice(const struct intel_engine_cs *engine,
if (!list_is_last(>sched.link, >active.requests))
hint = max(hint, rq_prio(list_next_entry(rq, sched.link)));
+ hint = never_timeslice(hint);
return hint >= effective_prio(rq);
}
@@ -2007,6 +2017,7 @@ static void start_timeslice(struct intel_engine_cs
*engine, int prio)
if (!intel_engine_has_timeslices(engine))
return;
+ prio = never_timeslice(prio);
WRITE_ONCE(execlists->switch_priority_hint, prio);
if (prio == INT_MIN)
return;
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 66f710b1b61e..0c32afbdb644 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -1289,6 +1289,121 @@ static int live_timeslice_queue(void *arg)
return err;
}
+static int live_timeslice_nopreempt(void *arg)
+{
+ struct intel_gt *gt = arg;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ struct igt_spinner spin;
+ int err = 0;
+
+ /*
+* We should not timeslice into a request that is marked with
+* I915_REQUEST_NOPREEMPT.
+*/
+ if (!IS_ACTIVE(CONFIG_DRM_I915_TIMESLICE_DURATION))
+ return 0;
+
+ if (igt_spinner_init(, gt))
+ return -ENOMEM;
+
+ for_each_engine(engine, gt, id) {
+ struct intel_context *ce;
+ struct i915_request *rq;
+ unsigned long timeslice;
+
+ if (!intel_engine_has_preemption(engine))
+ continue;
+
+ ce = intel_context_create(engine);
+ if (IS_ERR(ce)) {
+ err = PTR_ERR(ce);
+ break;
+ }
+
+ engine_heartbeat_disable(engine);
+ timeslice = xchg(>props.timeslice_duration_ms, 1);
+
+ /* Create an unpreemptible spinner */
+
+ rq = igt_spinner_create_request(, ce, MI_ARB_CHECK);
+ intel_context_put(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto out_heartbeat;
+ }
+
+ i915_request_get(rq);
+ i915_request_add(rq);
+
+ if (!igt_wait_for_spinner(, rq)) {
+ i915_request_put(rq);
+ err = -ETIME;
+ goto out_spin;
+ }
+
+ set_bit(I915_FENCE_FLAG_NOPREEMPT, >fence.flags);
+ i915_request_put(rq);
+
+ /* Followed by a maximum priority barrier (heartbeat) */
+
+ ce = intel_context_create(engine);
+ if (IS_ERR(ce)) {
+ err = PTR_ERR(rq);
+ goto out_spin;
+ }
+
+ rq = intel_context_create_request(ce);
+ intel_context_put(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto out_spin;
+ }
+
+ rq->sched.attr.priority = I915_PRIORITY_BARRIER;
+ i915_request_get(rq);
+ i915_request_add(rq);
+
+ /*
+* Wait until the barrier is in ELSP, and we know timeslicing
+* will have been activated.
+*/
+ if (wait_for_submit(engine, rq, HZ / 2)) {
+
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Prevent timeslicing into unpreemptible requests (rev2)
== Series Details == Series: drm/i915/gt: Prevent timeslicing into unpreemptible requests (rev2) URL : https://patchwork.freedesktop.org/series/77697/ State : success == Summary == CI Bug Log - changes from CI_DRM_8543 -> Patchwork_17788 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17788/index.html Known issues Here are the changes found in Patchwork_17788 that come from known issues: ### IGT changes ### Possible fixes * igt@debugfs_test@read_all_entries: - fi-bsw-nick:[INCOMPLETE][1] ([i915#1250] / [i915#1436]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8543/fi-bsw-nick/igt@debugfs_test@read_all_entries.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17788/fi-bsw-nick/igt@debugfs_test@read_all_entries.html [i915#1250]: https://gitlab.freedesktop.org/drm/intel/issues/1250 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 Participating hosts (51 -> 43) -- Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-kbl-7560u fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8543 -> Patchwork_17788 CI-20190529: 20190529 CI_DRM_8543: 3fcc7e306e95013f1f4c527e0dda96197e1243bf @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5680: f7e3772175c53f0c910f4513831791cb5bdcab04 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17788: 35548e49670cc03c9a9808c1d9e51e07e76b70e8 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 35548e49670c drm/i915/gt: Prevent timeslicing into unpreemptible requests == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17788/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Randomise bonded submission
Randomly submit a paired spinner and its cancellation as a bonded
(submit fence) pair. Apply congestion to the engine with more bonded
pairs to see if the execution order fails. If we prevent a cancellation
from running, then the spinner will remain spinning forever.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_exec_balancer.c | 108 +
1 file changed, 108 insertions(+)
diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
index 80ae82416..98715d726 100644
--- a/tests/i915/gem_exec_balancer.c
+++ b/tests/i915/gem_exec_balancer.c
@@ -1154,6 +1154,111 @@ static void bonded_semaphore(int i915)
gem_context_destroy(i915, ctx);
}
+static void __bonded_dual(int i915,
+ const struct i915_engine_class_instance *siblings,
+ unsigned int count)
+{
+ struct drm_i915_gem_exec_object2 batch = {};
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(),
+ .buffer_count = 1,
+ };
+ unsigned long cycles = 0;
+ uint32_t A, B;
+
+ A = gem_context_create(i915);
+ set_load_balancer(i915, A, siblings, count, NULL);
+
+ B = gem_context_create(i915);
+ set_load_balancer(i915, B, siblings, count, NULL);
+
+ igt_until_timeout(5) {
+ unsigned int master = rand() % count + 1;
+ int timeline, fence;
+ igt_spin_t *a, *b;
+
+ timeline = sw_sync_timeline_create();
+ fence = sw_sync_timeline_create_fence(timeline, 1);
+
+ a = igt_spin_new(i915, A,
+.engine = master,
+.fence = fence,
+.flags = (IGT_SPIN_FENCE_IN |
+ IGT_SPIN_POLL_RUN |
+ IGT_SPIN_NO_PREEMPTION |
+ IGT_SPIN_FENCE_OUT));
+ b = igt_spin_new(i915, B,
+.engine = master,
+.fence = fence,
+.flags = (IGT_SPIN_FENCE_IN |
+ IGT_SPIN_POLL_RUN |
+ IGT_SPIN_NO_PREEMPTION |
+ IGT_SPIN_FENCE_OUT));
+
+ close(fence);
+
+ if (rand() % 1)
+ igt_swap(a, b);
+
+ batch.handle = create_semaphore_to_spinner(i915, a);
+ execbuf.rsvd1 = a->execbuf.rsvd1;
+ execbuf.rsvd2 = a->out_fence;
+ do {
+ execbuf.flags = rand() % count + 1;
+ } while (execbuf.flags == master);
+ execbuf.flags |= I915_EXEC_FENCE_SUBMIT;
+ gem_execbuf(i915, );
+ gem_close(i915, batch.handle);
+
+ batch.handle = create_semaphore_to_spinner(i915, b);
+ execbuf.rsvd1 = b->execbuf.rsvd1;
+ execbuf.rsvd2 = b->out_fence;
+ do {
+ execbuf.flags = rand() % count + 1;
+ } while (execbuf.flags == master);
+ execbuf.flags |= I915_EXEC_FENCE_SUBMIT;
+ gem_execbuf(i915, );
+ gem_close(i915, batch.handle);
+
+ close(timeline);
+
+ gem_sync(i915, a->handle);
+ gem_sync(i915, b->handle);
+
+ igt_spin_free(i915, a);
+ igt_spin_free(i915, b);
+ cycles++;
+ }
+
+ igt_info("%lu cycles\n", cycles);
+
+ gem_context_destroy(i915, A);
+ gem_context_destroy(i915, B);
+}
+
+static void bonded_dual(int i915)
+{
+ /*
+* The purpose of bonded submission is to execute one or more requests
+* concurrently. However, the very nature of that requires coordinated
+* submission across multiple engines.
+*/
+ igt_require(gem_scheduler_has_preemption(i915));
+
+ for (int class = 1; class < 32; class++) {
+ struct i915_engine_class_instance *siblings;
+ unsigned int count;
+
+ siblings = list_engines(i915, 1u << class, );
+ if (count > 1) {
+ igt_fork(child, count + 1)
+ __bonded_dual(i915, siblings, count);
+ igt_waitchildren();
+ }
+ free(siblings);
+ }
+}
+
static void __bonded_nohang(int i915, uint32_t ctx,
const struct i915_engine_class_instance *siblings,
unsigned int count,
@@ -2284,6 +2389,9 @@ igt_main
igt_subtest("bonded-semaphore")
bonded_semaphore(i915);
+ igt_subtest("bonded-dual")
+ bonded_dual(i915);
+
igt_fixture {
Re: [Intel-gfx] [PATCH] drm/i915/gt: Prevent timeslicing into unpreemptible requests
Quoting Chris Wilson (2020-05-27 14:02:14)
> We have a I915_REQUEST_NOPREEMPT flag that we set when we must prevent
> the HW from preempting during the course of this request. We need to
> honour this flag and protect the HW even if we have a heartbeat request,
> or other maximum priority barrier, pending. As such, restrict the
> timeslicing check to avoid preempting into the topmost priority band,
> leaving the unpreemptable requests in blissful peace running
> uninterrupted on the HW.
>
Fixes: 2a98f4e65bba ("drm/i915: add infrastructure to hold off preemption on a
request")
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/edid: Allow looking for ext blocks starting from a specified index
From: Ville Syrjälä
Apparently EDIDs with multiple DispID ext blocks is a thing, so prepare
for iterating through multiple ext blocks of the same type by
passing the starting ext block index to drm_find_edid_extension(). Well
also have drm_find_edid_extension() update the index to point to the
next ext block on success. Thus we should be able to call
drm_find_edid_extension() in loop.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d8372d63851b..f2531d51dfa2 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3188,7 +3188,8 @@ add_detailed_modes(struct drm_connector *connector,
struct edid *edid,
/*
* Search EDID for CEA extension block.
*/
-static u8 *drm_find_edid_extension(const struct edid *edid, int ext_id)
+static u8 *drm_find_edid_extension(const struct edid *edid,
+ int ext_id, int *ext_index)
{
u8 *edid_ext = NULL;
int i;
@@ -3198,23 +3199,26 @@ static u8 *drm_find_edid_extension(const struct edid
*edid, int ext_id)
return NULL;
/* Find CEA extension */
- for (i = 0; i < edid->extensions; i++) {
+ for (i = *ext_index; i < edid->extensions; i++) {
edid_ext = (u8 *)edid + EDID_LENGTH * (i + 1);
if (edid_ext[0] == ext_id)
break;
}
- if (i == edid->extensions)
+ if (i >= edid->extensions)
return NULL;
+ *ext_index = i + 1;
+
return edid_ext;
}
static u8 *drm_find_displayid_extension(const struct edid *edid,
- int *length, int *idx)
+ int *length, int *idx,
+ int *ext_index)
{
- u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT);
+ u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT, ext_index);
struct displayid_hdr *base;
int ret;
@@ -3241,14 +3245,18 @@ static u8 *drm_find_cea_extension(const struct edid
*edid)
struct displayid_block *block;
u8 *cea;
u8 *displayid;
+ int ext_index;
/* Look for a top level CEA extension block */
- cea = drm_find_edid_extension(edid, CEA_EXT);
+ ext_index = 0;
+ cea = drm_find_edid_extension(edid, CEA_EXT, _index);
if (cea)
return cea;
/* CEA blocks can also be found embedded in a DisplayID block */
- displayid = drm_find_displayid_extension(edid, , );
+ ext_index = 0;
+ displayid = drm_find_displayid_extension(edid, , ,
+_index);
if (!displayid)
return NULL;
@@ -5195,8 +5203,10 @@ static int add_displayid_detailed_modes(struct
drm_connector *connector,
int length, idx;
struct displayid_block *block;
int num_modes = 0;
+ int ext_index = 0;
- displayid = drm_find_displayid_extension(edid, , );
+ displayid = drm_find_displayid_extension(edid, , ,
+_index);
if (!displayid)
return 0;
@@ -5870,11 +5880,13 @@ void drm_update_tile_info(struct drm_connector
*connector,
const struct edid *edid)
{
const void *displayid = NULL;
+ int ext_index = 0;
int length, idx;
int ret;
connector->has_tile = false;
- displayid = drm_find_displayid_extension(edid, , );
+ displayid = drm_find_displayid_extension(edid, , ,
+_index);
if (!displayid) {
/* drop reference to any tile group we had */
goto out_drop_ref;
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/edid: Clean up some curly braces
From: Ville Syrjälä
Drop some pointless curly braces, and add some across the
else when the if has them too.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index dcb23563d29d..8a951e2bfb41 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5836,22 +5836,21 @@ static void drm_parse_tiled_block(struct drm_connector
*connector,
DRM_DEBUG_KMS("vend %c%c%c\n", tile->topology_id[0],
tile->topology_id[1], tile->topology_id[2]);
tg = drm_mode_get_tile_group(connector->dev, tile->topology_id);
- if (!tg) {
+ if (!tg)
tg = drm_mode_create_tile_group(connector->dev,
tile->topology_id);
- }
if (!tg)
return;
if (connector->tile_group != tg) {
/* if we haven't got a pointer,
take the reference, drop ref to old tile group */
- if (connector->tile_group) {
+ if (connector->tile_group)
drm_mode_put_tile_group(connector->dev,
connector->tile_group);
- }
connector->tile_group = tg;
- } else
+ } else {
/* if same tile group, then release the ref we just took. */
drm_mode_put_tile_group(connector->dev, tg);
+ }
}
static void drm_displayid_parse_tiled(struct drm_connector *connector,
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/edid: Iterate through all DispID ext blocks
From: Ville Syrjälä
Apparently there are EDIDs in the wild with multiple DispID extension
blocks. Iterate through them all.
In one particular case the tile information is specicied in the
second DispID ext block, and since the current parser only looks
at the first DispID ext block we don't notice that we're dealing
with a tiled display.
While at it change a few functions to return void since we have
no use for the errno.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/27
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 84 +-
1 file changed, 38 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index f2531d51dfa2..dcb23563d29d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3248,6 +3248,7 @@ static u8 *drm_find_cea_extension(const struct edid *edid)
int ext_index;
/* Look for a top level CEA extension block */
+ /* FIXME: make callers iterate through multiple CEA ext blocks? */
ext_index = 0;
cea = drm_find_edid_extension(edid, CEA_EXT, _index);
if (cea)
@@ -3255,20 +3256,20 @@ static u8 *drm_find_cea_extension(const struct edid
*edid)
/* CEA blocks can also be found embedded in a DisplayID block */
ext_index = 0;
- displayid = drm_find_displayid_extension(edid, , ,
-_index);
- if (!displayid)
- return NULL;
+ for (;;) {
+ displayid = drm_find_displayid_extension(edid, , ,
+_index);
+ if (!displayid)
+ return NULL;
- idx += sizeof(struct displayid_hdr);
- for_each_displayid_db(displayid, block, idx, length) {
- if (block->tag == DATA_BLOCK_CTA) {
- cea = (u8 *)block;
- break;
+ idx += sizeof(struct displayid_hdr);
+ for_each_displayid_db(displayid, block, idx, length) {
+ if (block->tag == DATA_BLOCK_CTA)
+ return (u8 *)block;
}
}
- return cea;
+ return NULL;
}
static __always_inline const struct drm_display_mode *cea_mode_for_vic(u8 vic)
@@ -5205,19 +5206,22 @@ static int add_displayid_detailed_modes(struct
drm_connector *connector,
int num_modes = 0;
int ext_index = 0;
- displayid = drm_find_displayid_extension(edid, , ,
-_index);
- if (!displayid)
- return 0;
-
- idx += sizeof(struct displayid_hdr);
- for_each_displayid_db(displayid, block, idx, length) {
- switch (block->tag) {
- case DATA_BLOCK_TYPE_1_DETAILED_TIMING:
- num_modes += add_displayid_detailed_1_modes(connector,
block);
+ for (;;) {
+ displayid = drm_find_displayid_extension(edid, , ,
+_index);
+ if (!displayid)
break;
+
+ idx += sizeof(struct displayid_hdr);
+ for_each_displayid_db(displayid, block, idx, length) {
+ switch (block->tag) {
+ case DATA_BLOCK_TYPE_1_DETAILED_TIMING:
+ num_modes +=
add_displayid_detailed_1_modes(connector, block);
+ break;
+ }
}
}
+
return num_modes;
}
@@ -5797,8 +5801,8 @@ drm_hdmi_vendor_infoframe_from_display_mode(struct
hdmi_vendor_infoframe *frame,
}
EXPORT_SYMBOL(drm_hdmi_vendor_infoframe_from_display_mode);
-static int drm_parse_tiled_block(struct drm_connector *connector,
-const struct displayid_block *block)
+static void drm_parse_tiled_block(struct drm_connector *connector,
+ const struct displayid_block *block)
{
const struct displayid_tiled_block *tile = (struct
displayid_tiled_block *)block;
u16 w, h;
@@ -5836,7 +5840,7 @@ static int drm_parse_tiled_block(struct drm_connector
*connector,
tg = drm_mode_create_tile_group(connector->dev,
tile->topology_id);
}
if (!tg)
- return -ENOMEM;
+ return;
if (connector->tile_group != tg) {
/* if we haven't got a pointer,
@@ -5848,14 +5852,12 @@ static int drm_parse_tiled_block(struct drm_connector
*connector,
} else
/* if same tile group, then release the ref we just took. */
drm_mode_put_tile_group(connector->dev, tg);
- return 0;
}
-static int drm_displayid_parse_tiled(struct drm_connector *connector,
-const u8 *displayid, int length, int idx)
+static void
[Intel-gfx] [PATCH] drm/i915/gt: Prevent timeslicing into unpreemptible requests
We have a I915_REQUEST_NOPREEMPT flag that we set when we must prevent
the HW from preempting during the course of this request. We need to
honour this flag and protect the HW even if we have a heartbeat request,
or other maximum priority barrier, pending. As such, restrict the
timeslicing check to avoid preempting into the topmost priority band,
leaving the unpreemptable requests in blissful peace running
uninterrupted on the HW.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index a8fdd4f9eb5a..cf63613c2a60 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1896,6 +1896,15 @@ static void defer_active(struct intel_engine_cs *engine)
defer_request(rq, i915_sched_lookup_priolist(engine, rq_prio(rq)));
}
+static inline int never_timeslice(int prio)
+{
+ /* Don't allow timeslicing of the 'unpreemptible' requests */
+ if (prio == I915_PRIORITY_UNPREEMPTABLE)
+ prio--;
+
+ return prio;
+}
+
static bool
need_timeslice(const struct intel_engine_cs *engine,
const struct i915_request *rq,
@@ -1927,6 +1936,7 @@ need_timeslice(const struct intel_engine_cs *engine,
if (!list_is_last(>sched.link, >active.requests))
hint = max(hint, rq_prio(list_next_entry(rq, sched.link)));
+ hint = never_timeslice(hint);
return hint >= effective_prio(rq);
}
@@ -2007,6 +2017,7 @@ static void start_timeslice(struct intel_engine_cs
*engine, int prio)
if (!intel_engine_has_timeslices(engine))
return;
+ prio = never_timeslice(prio);
WRITE_ONCE(execlists->switch_priority_hint, prio);
if (prio == INT_MIN)
return;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gt: Prevent timeslicing into unpreemptible requests
== Series Details == Series: drm/i915/gt: Prevent timeslicing into unpreemptible requests URL : https://patchwork.freedesktop.org/series/77697/ State : failure == Summary == Applying: drm/i915/gt: Prevent timeslicing into unpreemptible requests error: sha1 information is lacking or useless (drivers/gpu/drm/i915/gt/intel_lrc.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/i915/gt: Prevent timeslicing into unpreemptible requests When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Prevent timeslicing into unpreemptible requests
We have a I915_REQUEST_NOPREEMPT flag that we set when we must prevent
the HW from preempting during the course of this request. We need to
honour this flag and protect the HW even if we have a heartbeat request,
or other maximum priority barrier, pending. As such, restrict the
timeslicing check to avoid preempting into the topmost priority band,
leaving the unpreemptable requests in blissful peace running
uninterrupted on the HW.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index d7804ce29d27..cf63613c2a60 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1896,6 +1896,15 @@ static void defer_active(struct intel_engine_cs *engine)
defer_request(rq, i915_sched_lookup_priolist(engine, rq_prio(rq)));
}
+static inline int never_timeslice(int prio)
+{
+ /* Don't allow timeslicing of the 'unpreemptible' requests */
+ if (prio == I915_PRIORITY_UNPREEMPTABLE)
+ prio--;
+
+ return prio;
+}
+
static bool
need_timeslice(const struct intel_engine_cs *engine,
const struct i915_request *rq,
@@ -1927,6 +1936,7 @@ need_timeslice(const struct intel_engine_cs *engine,
if (!list_is_last(>sched.link, >active.requests))
hint = max(hint, rq_prio(list_next_entry(rq, sched.link)));
+ hint = never_timeslice(hint);
return hint >= effective_prio(rq);
}
@@ -2007,10 +2017,7 @@ static void start_timeslice(struct intel_engine_cs
*engine, int prio)
if (!intel_engine_has_timeslices(engine))
return;
- /* Don't allow timeslicing of the 'unpreemptible' requests */
- if (prio == I915_PRIORITY_UNPREEMPTABLE)
- prio--;
-
+ prio = never_timeslice(prio);
WRITE_ONCE(execlists->switch_priority_hint, prio);
if (prio == INT_MIN)
return;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/mxsfb: Call drm_crtc_vblank_on/off (rev2)
== Series Details ==
Series: series starting with [1/2] drm/mxsfb: Call drm_crtc_vblank_on/off (rev2)
URL : https://patchwork.freedesktop.org/series/77689/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8542_full -> Patchwork_17784_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_17784_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@i915_suspend@debugfs-reader:
- shard-skl: [PASS][1] -> [INCOMPLETE][2] ([i915#69])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8542/shard-skl9/igt@i915_susp...@debugfs-reader.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17784/shard-skl6/igt@i915_susp...@debugfs-reader.html
* igt@kms_cursor_crc@pipe-c-cursor-64x64-offscreen:
- shard-skl: [PASS][3] -> [FAIL][4] ([i915#54])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8542/shard-skl1/igt@kms_cursor_...@pipe-c-cursor-64x64-offscreen.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17784/shard-skl10/igt@kms_cursor_...@pipe-c-cursor-64x64-offscreen.html
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-hsw: [PASS][5] -> [INCOMPLETE][6] ([i915#61])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8542/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17784/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html
* igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#180] / [i915#93]
/ [i915#95])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8542/shard-kbl4/igt@kms_frontbuffer_track...@fbc-suspend.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17784/shard-kbl7/igt@kms_frontbuffer_track...@fbc-suspend.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-skl: [PASS][9] -> [FAIL][10] ([i915#1188])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8542/shard-skl8/igt@kms_...@bpc-switch-suspend.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17784/shard-skl3/igt@kms_...@bpc-switch-suspend.html
* igt@kms_plane@plane-panning-bottom-right-pipe-b-planes:
- shard-skl: [PASS][11] -> [FAIL][12] ([i915#1036])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8542/shard-skl2/igt@kms_pl...@plane-panning-bottom-right-pipe-b-planes.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17784/shard-skl2/igt@kms_pl...@plane-panning-bottom-right-pipe-b-planes.html
* igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145] / [i915#265])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8542/shard-skl2/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17784/shard-skl2/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
* igt@kms_psr@psr2_sprite_mmap_cpu:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8542/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_cpu.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17784/shard-iclb4/igt@kms_psr@psr2_sprite_mmap_cpu.html
* igt@kms_setmode@basic:
- shard-apl: [PASS][17] -> [FAIL][18] ([i915#31])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8542/shard-apl1/igt@kms_setm...@basic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17784/shard-apl3/igt@kms_setm...@basic.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +5
similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8542/shard-kbl6/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17784/shard-kbl6/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html
Possible fixes
* igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-skl: [FAIL][21] ([i915#644]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8542/shard-skl1/igt@gem_pp...@flink-and-close-vma-leak.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17784/shard-skl9/igt@gem_pp...@flink-and-close-vma-leak.html
* igt@gen9_exec_parse@allowed-all:
- shard-apl: [DMESG-WARN][23] ([i915#1436] / [i915#716]) ->
[PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8542/shard-apl6/igt@gen9_exec_pa...@allowed-all.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17784/shard-apl2/igt@gen9_exec_pa...@allowed-all.html
* {igt@i915_selftest@perf@request}:
- shard-tglb: [INCOMPLETE][25] ([i915#1823]) -> [PASS][26]
[25]:
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm: use drm_dev_has_vblank more
== Series Details == Series: drm: use drm_dev_has_vblank more URL : https://patchwork.freedesktop.org/series/77695/ State : failure == Summary == Applying: drm: use drm_dev_has_vblank more error: sha1 information is lacking or useless (drivers/gpu/drm/drm_atomic_helper.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: use drm_dev_has_vblank more When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Randomise bonded submission
Randomly submit a paired spinner and its cancellation as a bonded
(submit fence) pair. Apply congestion to the engine with more bonded
pairs to see if the execution order fails. If we prevent a cancellation
from running, then the spinner will remain spinning forever.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_balancer.c | 96 ++
1 file changed, 96 insertions(+)
diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
index 80ae82416..6d82e439b 100644
--- a/tests/i915/gem_exec_balancer.c
+++ b/tests/i915/gem_exec_balancer.c
@@ -1154,6 +1154,99 @@ static void bonded_semaphore(int i915)
gem_context_destroy(i915, ctx);
}
+static void __bonded_dual(int i915,
+ const struct i915_engine_class_instance *siblings,
+ unsigned int count)
+{
+ struct drm_i915_gem_exec_object2 batch = {};
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(),
+ .buffer_count = 1,
+ };
+ uint32_t A, B;
+
+ A = gem_context_create(i915);
+ set_load_balancer(i915, A, siblings, count, NULL);
+
+ B = gem_context_create(i915);
+ set_load_balancer(i915, B, siblings, count, NULL);
+
+ igt_until_timeout(5) {
+ unsigned int master = rand() % count + 1;
+ int timeline, fence;
+ igt_spin_t *a, *b;
+
+ timeline = sw_sync_timeline_create();
+ fence = sw_sync_timeline_create_fence(timeline, 1);
+
+ a = igt_spin_new(i915, A,
+.engine = master,
+.fence = fence,
+.flags = (IGT_SPIN_FENCE_IN |
+ IGT_SPIN_POLL_RUN |
+ IGT_SPIN_FENCE_OUT));
+ b = igt_spin_new(i915, B,
+.engine = master,
+.fence = fence,
+.flags = (IGT_SPIN_FENCE_IN |
+ IGT_SPIN_POLL_RUN |
+ IGT_SPIN_FENCE_OUT));
+
+ close(fence);
+
+ if (rand() % 1)
+ igt_swap(a, b);
+
+ batch.handle = create_semaphore_to_spinner(i915, a);
+ execbuf.rsvd2 = a->out_fence;
+ execbuf.flags = I915_EXEC_FENCE_SUBMIT;
+ execbuf.flags |= rand() % count + 1;
+ gem_execbuf(i915, );
+ gem_close(i915, batch.handle);
+
+ batch.handle = create_semaphore_to_spinner(i915, b);
+ execbuf.rsvd2 = b->out_fence;
+ execbuf.flags = I915_EXEC_FENCE_SUBMIT;
+ execbuf.flags |= rand() % count + 1;
+ gem_execbuf(i915, );
+ gem_close(i915, batch.handle);
+
+ close(timeline);
+
+ gem_sync(i915, a->handle);
+ gem_sync(i915, b->handle);
+
+ igt_spin_free(i915, a);
+ igt_spin_free(i915, b);
+ }
+
+ gem_context_destroy(i915, A);
+ gem_context_destroy(i915, B);
+}
+
+static void bonded_dual(int i915)
+{
+ /*
+* The purpose of bonded submission is to execute one or more requests
+* concurrently. However, the very nature of that requires coordinated
+* submission across multiple engines.
+*/
+ igt_require(gem_scheduler_has_preemption(i915));
+
+ for (int class = 1; class < 32; class++) {
+ struct i915_engine_class_instance *siblings;
+ unsigned int count;
+
+ siblings = list_engines(i915, 1u << class, );
+ if (count > 1) {
+ igt_fork(child, count)
+ __bonded_dual(i915, siblings, count);
+ igt_waitchildren();
+ }
+ free(siblings);
+ }
+}
+
static void __bonded_nohang(int i915, uint32_t ctx,
const struct i915_engine_class_instance *siblings,
unsigned int count,
@@ -2284,6 +2377,9 @@ igt_main
igt_subtest("bonded-semaphore")
bonded_semaphore(i915);
+ igt_subtest("bonded-dual")
+ bonded_dual(i915);
+
igt_fixture {
igt_stop_hang_detector();
}
--
2.27.0.rc0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic-helper: reset vblank on crtc reset
On Wed, May 27, 2020 at 01:07:05PM +0200, Daniel Vetter wrote:
> On Wed, May 27, 2020 at 12:57 PM Liviu Dudau wrote:
> >
> > Hi Daniel,
> >
> > On Wed, May 27, 2020 at 11:53:32AM +0200, Daniel Vetter wrote:
> > > Only when vblanks are supported ofc.
> > >
> > > Some drivers do this already, but most unfortunately missed it. This
> > > opens up bugs after driver load, before the crtc is enabled for the
> > > first time. syzbot spotted this when loading vkms as a secondary
> > > output. Given how many drivers are buggy it's best to solve this once
> > > and for all in shared helper code.
> > >
> > > Aside from moving the few existing calls to drm_crtc_vblank_reset into
> > > helpers (i915 doesn't use helpers, so keeps its own) I think the
> > > regression risk is minimal: atomic helpers already rely on drivers
> > > calling drm_crtc_vblank_on/off correctly in their hooks when they
> > > support vblanks. And driver that's failing to handle vblanks after
> > > this is missing those calls already, and vblanks could only work by
> > > accident when enabling a CRTC for the first time right after boot.
> > >
> > > Big thanks to Tetsuo for helping track down what's going wrong here.
> > >
> > > There's only a few drivers which already had the necessary call and
> > > needed some updating:
> > > - komeda, atmel and tidss also needed to be changed to call
> > > __drm_atomic_helper_crtc_reset() intead of open coding it
> > > - tegra and msm even had it in the same place already, just code
> > > motion, and malidp already uses __drm_atomic_helper_crtc_reset().
> > >
> > > Only call left is in i915, which doesn't use drm_mode_config_reset,
> > > but has its own fastboot infrastructure. So that's the only case where
> > > we actually want this in the driver still.
> > >
> > > I've also reviewed all other drivers which set up vblank support with
> > > drm_vblank_init. After the previous patch fixing mxsfb all atomic
> > > drivers do call drm_crtc_vblank_on/off as they should, the remaining
> > > drivers are either legacy kms or legacy dri1 drivers, so not affected
> > > by this change to atomic helpers.
> > >
> > > v2: Use the drm_dev_has_vblank() helper.
> > >
> > > Link:
> > > https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
> > > Reported-by: Tetsuo Handa
> > > Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
> > > Cc: Tetsuo Handa
> > > Cc: "James (Qian) Wang"
> > > Cc: Liviu Dudau
> > > Cc: Mihail Atanassov
> > > Cc: Brian Starkey
> > > Cc: Sam Ravnborg
> > > Cc: Boris Brezillon
> > > Cc: Nicolas Ferre
> > > Cc: Alexandre Belloni
> > > Cc: Ludovic Desroches
> > > Cc: Maarten Lankhorst
> > > Cc: Maxime Ripard
> > > Cc: Thomas Zimmermann
> > > Cc: David Airlie
> > > Cc: Daniel Vetter
> > > Cc: Thierry Reding
> > > Cc: Jonathan Hunter
> > > Cc: Jyri Sarha
> > > Cc: Tomi Valkeinen
> > > Cc: Rob Clark
> > > Cc: Sean Paul
> > > Cc: Brian Masney
> > > Cc: Emil Velikov
> > > Cc: zhengbin
> > > Cc: Thomas Gleixner
> > > Cc: linux-te...@vger.kernel.org
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++-
> > > drivers/gpu/drm/arm/malidp_drv.c | 1 -
> > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 7 ++-
> > > drivers/gpu/drm/drm_atomic_state_helper.c| 4
> > > drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 2 --
> > > drivers/gpu/drm/tegra/dc.c | 1 -
> > > drivers/gpu/drm/tidss/tidss_crtc.c | 3 +--
> > > drivers/gpu/drm/tidss/tidss_kms.c| 4
> > > 8 files changed, 9 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > index 56bd938961ee..f33418d6e1a0 100644
> > > --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > @@ -492,10 +492,8 @@ static void komeda_crtc_reset(struct drm_crtc *crtc)
> > > crtc->state = NULL;
> > >
> > > state = kzalloc(sizeof(*state), GFP_KERNEL);
> > > - if (state) {
> > > - crtc->state = >base;
> > > - crtc->state->crtc = crtc;
> > > - }
> > > + if (state)
> > > + __drm_atomic_helper_crtc_reset(crtc, >base);
> > > }
> > >
> > > static struct drm_crtc_state *
> > > @@ -616,7 +614,6 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
> > > return err;
> > >
> > > drm_crtc_helper_add(crtc, _crtc_helper_funcs);
> > > - drm_crtc_vblank_reset(crtc);
> > >
> > > crtc->port = kcrtc->master->of_output_port;
> > >
> > > diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> > > b/drivers/gpu/drm/arm/malidp_drv.c
> > > index c2507b7d8512..02904392e370 100644
> > > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > > @@ -870,7 +870,6 @@ static int
[Intel-gfx] ✓ Fi.CI.BAT: success for i915: Add debugfs for requesting HDCP version
== Series Details == Series: i915: Add debugfs for requesting HDCP version URL : https://patchwork.freedesktop.org/series/77693/ State : success == Summary == CI Bug Log - changes from CI_DRM_8542 -> Patchwork_17785 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17785/index.html Known issues Here are the changes found in Patchwork_17785 that come from known issues: ### IGT changes ### Possible fixes * igt@i915_selftest@live@active: - fi-kbl-soraka: [DMESG-FAIL][1] ([i915#666]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8542/fi-kbl-soraka/igt@i915_selftest@l...@active.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17785/fi-kbl-soraka/igt@i915_selftest@l...@active.html [i915#666]: https://gitlab.freedesktop.org/drm/intel/issues/666 Participating hosts (51 -> 43) -- Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-kbl-7560u fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8542 -> Patchwork_17785 CI-20190529: 20190529 CI_DRM_8542: 547d23ff9379bfa0f65c53721f63e688c5356b68 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5680: f7e3772175c53f0c910f4513831791cb5bdcab04 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17785: a44896d4d87446f7ff4ffe16e31b13e3de07b79d @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == a44896d4d874 drm/i915: Add a new debugfs to request HDCP version ee34d42eee76 drm/i915: Add support for considering HDCP ver requested via debugfs == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17785/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: use drm_dev_has_vblank more
Am 27.05.20 um 13:11 schrieb Daniel Vetter:
> For historical reasons it's called dev->num_crtcs, which is rather
> confusing ever since kms was added. But now we have a nice helper, so
> let's use it for better readability!
>
> Only code change is in atomic helpers: vblank support means that
> dev->irq_enabled must be set too. Another one of these quirky things
> ... But since it's implied we can simplify that check.
>
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
Reviewed-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 2 +-
> drivers/gpu/drm/drm_irq.c | 2 +-
> drivers/gpu/drm/drm_vblank.c| 14 +++---
> 3 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 0a541368246e..bfcc7857a9a1 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1097,7 +1097,7 @@ disable_outputs(struct drm_device *dev, struct
> drm_atomic_state *old_state)
> else if (funcs->dpms)
> funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
>
> - if (!(dev->irq_enabled && dev->num_crtcs))
> + if (!drm_dev_has_vblank(dev))
> continue;
>
> ret = drm_crtc_vblank_get(crtc);
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 588be45abd7a..09d6e9e2e075 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -181,7 +181,7 @@ int drm_irq_uninstall(struct drm_device *dev)
>* vblank/irq handling. KMS drivers must ensure that vblanks are all
>* disabled when uninstalling the irq handler.
>*/
> - if (dev->num_crtcs) {
> + if (drm_dev_has_vblank(dev)) {
> spin_lock_irqsave(>vbl_lock, irqflags);
> for (i = 0; i < dev->num_crtcs; i++) {
> struct drm_vblank_crtc *vblank = >vblank[i];
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index e278d6407f8e..162d9f7e692a 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -605,7 +605,7 @@ void drm_calc_timestamping_constants(struct drm_crtc
> *crtc,
> int linedur_ns = 0, framedur_ns = 0;
> int dotclock = mode->crtc_clock;
>
> - if (!dev->num_crtcs)
> + if (!drm_dev_has_vblank(dev))
> return;
>
> if (WARN_ON(pipe >= dev->num_crtcs))
> @@ -1065,7 +1065,7 @@ void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
> unsigned int pipe = drm_crtc_index(crtc);
> ktime_t now;
>
> - if (dev->num_crtcs > 0) {
> + if (drm_dev_has_vblank(dev)) {
> seq = drm_vblank_count_and_time(dev, pipe, );
> } else {
> seq = 0;
> @@ -1137,7 +1137,7 @@ static int drm_vblank_get(struct drm_device *dev,
> unsigned int pipe)
> unsigned long irqflags;
> int ret = 0;
>
> - if (!dev->num_crtcs)
> + if (!drm_dev_has_vblank(dev))
> return -EINVAL;
>
> if (WARN_ON(pipe >= dev->num_crtcs))
> @@ -1506,7 +1506,7 @@ static void drm_legacy_vblank_pre_modeset(struct
> drm_device *dev,
> struct drm_vblank_crtc *vblank = >vblank[pipe];
>
> /* vblank is not initialized (IRQ not installed ?), or has been freed */
> - if (!dev->num_crtcs)
> + if (!drm_dev_has_vblank(dev))
> return;
>
> if (WARN_ON(pipe >= dev->num_crtcs))
> @@ -1533,7 +1533,7 @@ static void drm_legacy_vblank_post_modeset(struct
> drm_device *dev,
> unsigned long irqflags;
>
> /* vblank is not initialized (IRQ not installed ?), or has been freed */
> - if (!dev->num_crtcs)
> + if (!drm_dev_has_vblank(dev))
> return;
>
> if (WARN_ON(pipe >= dev->num_crtcs))
> @@ -1558,7 +1558,7 @@ int drm_legacy_modeset_ctl_ioctl(struct drm_device
> *dev, void *data,
> unsigned int pipe;
>
> /* If drm_vblank_init() hasn't been called yet, just no-op */
> - if (!dev->num_crtcs)
> + if (!drm_dev_has_vblank(dev))
> return 0;
>
> /* KMS drivers handle this internally */
> @@ -1896,7 +1896,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
> int pipe)
> unsigned long irqflags;
> bool disable_irq, fence_cookie;
>
> - if (WARN_ON_ONCE(!dev->num_crtcs))
> + if (WARN_ON_ONCE(!drm_dev_has_vblank(dev)))
> return false;
>
> if (WARN_ON(pipe >= dev->num_crtcs))
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915: Add debugfs for requesting HDCP version
== Series Details == Series: i915: Add debugfs for requesting HDCP version URL : https://patchwork.freedesktop.org/series/77693/ 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 +./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' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915: Add debugfs for requesting HDCP version
== Series Details ==
Series: i915: Add debugfs for requesting HDCP version
URL : https://patchwork.freedesktop.org/series/77693/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ee34d42eee76 drm/i915: Add support for considering HDCP ver requested via
debugfs
a44896d4d874 drm/i915: Add a new debugfs to request HDCP version
-:38: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#38: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2190:
+{
+
-:53: WARNING:PREFER_SEQ_PUTS: Prefer seq_puts to seq_printf
#53: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2205:
+ seq_printf(m, "Requested Versions:\n");
-:55: WARNING:PREFER_SEQ_PUTS: Prefer seq_puts to seq_printf
#55: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2207:
+ seq_printf(m, "HDCP1.4\n");
-:57: WARNING:PREFER_SEQ_PUTS: Prefer seq_puts to seq_printf
#57: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2209:
+ seq_printf(m, "HDCP2.2\n");
-:63: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#63: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2215:
+static int i915_hdcp_ver_request_open(struct inode *inode,
+struct file *file)
-:84: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#84: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2236:
+static ssize_t i915_hdcp_ver_request_write(struct file *file,
+ const char __user *ubuf,
-:106: CHECK:LINE_SPACING: Please don't use multiple blank lines
#106: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2258:
+
+
-:139: WARNING:SYMBOLIC_PERMS: Symbolic permissions 'S_IRUGO' are not
preferred. Consider using octal permissions '0444'.
#139: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2314:
+ debugfs_create_file("i915_hdcp_version_request", S_IRUGO, root,
total: 0 errors, 4 warnings, 4 checks, 110 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/display: Fix the encoder type check
> -Original Message-
> From: Intel-gfx On Behalf Of Vandita
> Kulkarni
> Sent: Monday, May 4, 2020 1:19 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH] drm/i915/display: Fix the encoder type check
>
> For all ddi, encoder->type holds output type as ddi, assigning it to
> individual o/p
> types is no more valid.
>
> Fixes: 362bfb995b78 ("drm/i915/tgl: Add DKL PHY vswing table for HDMI")
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 5601673c3f30..10d70daf714b 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -2579,14 +2579,14 @@ static void icl_ddi_vswing_sequence(struct
> intel_encoder *encoder,
>
> static void
> tgl_dkl_phy_ddi_vswing_sequence(struct intel_encoder *encoder, int
> link_clock,
> - u32 level)
> + u32 level, enum intel_output_type type)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> 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;
>
> - if (encoder->type == INTEL_OUTPUT_HDMI) {
> + if (type == INTEL_OUTPUT_HDMI) {
> n_entries = ARRAY_SIZE(tgl_dkl_phy_hdmi_ddi_trans);
> ddi_translations = tgl_dkl_phy_hdmi_ddi_trans;
> } else {
> @@ -2638,7 +2638,7 @@ static void tgl_ddi_vswing_sequence(struct
> intel_encoder *encoder,
> if (intel_phy_is_combo(dev_priv, phy))
> icl_combo_phy_ddi_vswing_sequence(encoder, level, type);
> else
> - tgl_dkl_phy_ddi_vswing_sequence(encoder, link_clock, level);
> + tgl_dkl_phy_ddi_vswing_sequence(encoder, link_clock, level,
> type);
> }
>
> static u32 translate_signal_level(struct intel_dp *intel_dp, int
> signal_levels)
> --
> 2.21.0.5.gaeb582a
>
> ___
> 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: success for series starting with [1/2] drm/mxsfb: Call drm_crtc_vblank_on/off (rev2)
== Series Details == Series: series starting with [1/2] drm/mxsfb: Call drm_crtc_vblank_on/off (rev2) URL : https://patchwork.freedesktop.org/series/77689/ State : success == Summary == CI Bug Log - changes from CI_DRM_8542 -> Patchwork_17784 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17784/index.html Known issues Here are the changes found in Patchwork_17784 that come from known issues: ### IGT changes ### Possible fixes * igt@i915_selftest@live@active: - fi-kbl-soraka: [DMESG-FAIL][1] ([i915#666]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8542/fi-kbl-soraka/igt@i915_selftest@l...@active.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17784/fi-kbl-soraka/igt@i915_selftest@l...@active.html [i915#666]: https://gitlab.freedesktop.org/drm/intel/issues/666 Participating hosts (51 -> 44) -- 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_8542 -> Patchwork_17784 CI-20190529: 20190529 CI_DRM_8542: 547d23ff9379bfa0f65c53721f63e688c5356b68 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5680: f7e3772175c53f0c910f4513831791cb5bdcab04 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17784: 256337b390c66d39d2dfd8186bbef51ab11d5ced @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 256337b390c6 drm/atomic-helper: reset vblank on crtc reset 854716133023 drm/mxsfb: Call drm_crtc_vblank_on/off == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17784/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: use drm_dev_has_vblank more
For historical reasons it's called dev->num_crtcs, which is rather
confusing ever since kms was added. But now we have a nice helper, so
let's use it for better readability!
Only code change is in atomic helpers: vblank support means that
dev->irq_enabled must be set too. Another one of these quirky things
... But since it's implied we can simplify that check.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 2 +-
drivers/gpu/drm/drm_irq.c | 2 +-
drivers/gpu/drm/drm_vblank.c| 14 +++---
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 0a541368246e..bfcc7857a9a1 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1097,7 +1097,7 @@ disable_outputs(struct drm_device *dev, struct
drm_atomic_state *old_state)
else if (funcs->dpms)
funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
- if (!(dev->irq_enabled && dev->num_crtcs))
+ if (!drm_dev_has_vblank(dev))
continue;
ret = drm_crtc_vblank_get(crtc);
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 588be45abd7a..09d6e9e2e075 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -181,7 +181,7 @@ int drm_irq_uninstall(struct drm_device *dev)
* vblank/irq handling. KMS drivers must ensure that vblanks are all
* disabled when uninstalling the irq handler.
*/
- if (dev->num_crtcs) {
+ if (drm_dev_has_vblank(dev)) {
spin_lock_irqsave(>vbl_lock, irqflags);
for (i = 0; i < dev->num_crtcs; i++) {
struct drm_vblank_crtc *vblank = >vblank[i];
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index e278d6407f8e..162d9f7e692a 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -605,7 +605,7 @@ void drm_calc_timestamping_constants(struct drm_crtc *crtc,
int linedur_ns = 0, framedur_ns = 0;
int dotclock = mode->crtc_clock;
- if (!dev->num_crtcs)
+ if (!drm_dev_has_vblank(dev))
return;
if (WARN_ON(pipe >= dev->num_crtcs))
@@ -1065,7 +1065,7 @@ void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
unsigned int pipe = drm_crtc_index(crtc);
ktime_t now;
- if (dev->num_crtcs > 0) {
+ if (drm_dev_has_vblank(dev)) {
seq = drm_vblank_count_and_time(dev, pipe, );
} else {
seq = 0;
@@ -1137,7 +1137,7 @@ static int drm_vblank_get(struct drm_device *dev,
unsigned int pipe)
unsigned long irqflags;
int ret = 0;
- if (!dev->num_crtcs)
+ if (!drm_dev_has_vblank(dev))
return -EINVAL;
if (WARN_ON(pipe >= dev->num_crtcs))
@@ -1506,7 +1506,7 @@ static void drm_legacy_vblank_pre_modeset(struct
drm_device *dev,
struct drm_vblank_crtc *vblank = >vblank[pipe];
/* vblank is not initialized (IRQ not installed ?), or has been freed */
- if (!dev->num_crtcs)
+ if (!drm_dev_has_vblank(dev))
return;
if (WARN_ON(pipe >= dev->num_crtcs))
@@ -1533,7 +1533,7 @@ static void drm_legacy_vblank_post_modeset(struct
drm_device *dev,
unsigned long irqflags;
/* vblank is not initialized (IRQ not installed ?), or has been freed */
- if (!dev->num_crtcs)
+ if (!drm_dev_has_vblank(dev))
return;
if (WARN_ON(pipe >= dev->num_crtcs))
@@ -1558,7 +1558,7 @@ int drm_legacy_modeset_ctl_ioctl(struct drm_device *dev,
void *data,
unsigned int pipe;
/* If drm_vblank_init() hasn't been called yet, just no-op */
- if (!dev->num_crtcs)
+ if (!drm_dev_has_vblank(dev))
return 0;
/* KMS drivers handle this internally */
@@ -1896,7 +1896,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
int pipe)
unsigned long irqflags;
bool disable_irq, fence_cookie;
- if (WARN_ON_ONCE(!dev->num_crtcs))
+ if (WARN_ON_ONCE(!drm_dev_has_vblank(dev)))
return false;
if (WARN_ON(pipe >= dev->num_crtcs))
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic-helper: reset vblank on crtc reset
On Wed, May 27, 2020 at 12:57 PM Liviu Dudau wrote:
>
> Hi Daniel,
>
> On Wed, May 27, 2020 at 11:53:32AM +0200, Daniel Vetter wrote:
> > Only when vblanks are supported ofc.
> >
> > Some drivers do this already, but most unfortunately missed it. This
> > opens up bugs after driver load, before the crtc is enabled for the
> > first time. syzbot spotted this when loading vkms as a secondary
> > output. Given how many drivers are buggy it's best to solve this once
> > and for all in shared helper code.
> >
> > Aside from moving the few existing calls to drm_crtc_vblank_reset into
> > helpers (i915 doesn't use helpers, so keeps its own) I think the
> > regression risk is minimal: atomic helpers already rely on drivers
> > calling drm_crtc_vblank_on/off correctly in their hooks when they
> > support vblanks. And driver that's failing to handle vblanks after
> > this is missing those calls already, and vblanks could only work by
> > accident when enabling a CRTC for the first time right after boot.
> >
> > Big thanks to Tetsuo for helping track down what's going wrong here.
> >
> > There's only a few drivers which already had the necessary call and
> > needed some updating:
> > - komeda, atmel and tidss also needed to be changed to call
> > __drm_atomic_helper_crtc_reset() intead of open coding it
> > - tegra and msm even had it in the same place already, just code
> > motion, and malidp already uses __drm_atomic_helper_crtc_reset().
> >
> > Only call left is in i915, which doesn't use drm_mode_config_reset,
> > but has its own fastboot infrastructure. So that's the only case where
> > we actually want this in the driver still.
> >
> > I've also reviewed all other drivers which set up vblank support with
> > drm_vblank_init. After the previous patch fixing mxsfb all atomic
> > drivers do call drm_crtc_vblank_on/off as they should, the remaining
> > drivers are either legacy kms or legacy dri1 drivers, so not affected
> > by this change to atomic helpers.
> >
> > v2: Use the drm_dev_has_vblank() helper.
> >
> > Link:
> > https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
> > Reported-by: Tetsuo Handa
> > Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
> > Cc: Tetsuo Handa
> > Cc: "James (Qian) Wang"
> > Cc: Liviu Dudau
> > Cc: Mihail Atanassov
> > Cc: Brian Starkey
> > Cc: Sam Ravnborg
> > Cc: Boris Brezillon
> > Cc: Nicolas Ferre
> > Cc: Alexandre Belloni
> > Cc: Ludovic Desroches
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Thomas Zimmermann
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: Thierry Reding
> > Cc: Jonathan Hunter
> > Cc: Jyri Sarha
> > Cc: Tomi Valkeinen
> > Cc: Rob Clark
> > Cc: Sean Paul
> > Cc: Brian Masney
> > Cc: Emil Velikov
> > Cc: zhengbin
> > Cc: Thomas Gleixner
> > Cc: linux-te...@vger.kernel.org
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++-
> > drivers/gpu/drm/arm/malidp_drv.c | 1 -
> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 7 ++-
> > drivers/gpu/drm/drm_atomic_state_helper.c| 4
> > drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 2 --
> > drivers/gpu/drm/tegra/dc.c | 1 -
> > drivers/gpu/drm/tidss/tidss_crtc.c | 3 +--
> > drivers/gpu/drm/tidss/tidss_kms.c| 4
> > 8 files changed, 9 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > index 56bd938961ee..f33418d6e1a0 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > @@ -492,10 +492,8 @@ static void komeda_crtc_reset(struct drm_crtc *crtc)
> > crtc->state = NULL;
> >
> > state = kzalloc(sizeof(*state), GFP_KERNEL);
> > - if (state) {
> > - crtc->state = >base;
> > - crtc->state->crtc = crtc;
> > - }
> > + if (state)
> > + __drm_atomic_helper_crtc_reset(crtc, >base);
> > }
> >
> > static struct drm_crtc_state *
> > @@ -616,7 +614,6 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
> > return err;
> >
> > drm_crtc_helper_add(crtc, _crtc_helper_funcs);
> > - drm_crtc_vblank_reset(crtc);
> >
> > crtc->port = kcrtc->master->of_output_port;
> >
> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> > b/drivers/gpu/drm/arm/malidp_drv.c
> > index c2507b7d8512..02904392e370 100644
> > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > @@ -870,7 +870,6 @@ static int malidp_bind(struct device *dev)
> > drm->irq_enabled = true;
> >
> > ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
> > - drm_crtc_vblank_reset(>crtc);
>
> It was a couple of years ago but I remember Alexandru-Cosmin tracking an
> issue around
> this. The reason for reseting the vblank
[Intel-gfx] [RFC 1/2] drm/i915: Add support for considering HDCP ver requested via debugfs
For testing and debugging each HDCP version separately, a debugfs
entry for requesting a specific version is required. The vesion
requested via debugfs needs to be stored in hdcp structure. This can
then be considered while enabling HDCP, provided the platform and the
display supports the requested version.
This patch adds the support for storing the version requested as a 32bit
flag. The default value is set to signify that any of the HDCP version
can be used.
If a specific HDCP version is requested through the debugfs, the driver
chooses that version, instead of policy of choosing the highest HDCP
version supported.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_display_types.h | 10 ++
drivers/gpu/drm/i915/display/intel_hdcp.c | 8 ++--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 9488449e4b94..cfa641c70717 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -408,6 +408,16 @@ struct intel_hdcp {
* Hence caching the transcoder here.
*/
enum transcoder cpu_transcoder;
+
+ /*
+* HDCP version requested from debugfs i915_hdcp_ver_request.
+* Kernel will read these bits and entertain the request, as per
+* the HDCP capability of the panel and platform.
+*/
+#define HDCP_VERSION_1_4 0x01
+#define HDCP_VERSION_2_2 0x02
+#define HDCP_VERSION_MASK 0x03
+ u32 debugfs_ver_request;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 2cbc4619b4ce..951401046804 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1977,6 +1977,8 @@ int intel_hdcp_init(struct intel_connector *connector,
if (!shim)
return -EINVAL;
+ hdcp->debugfs_ver_request = HDCP_VERSION_MASK;
+
if (is_hdcp2_supported(dev_priv))
intel_hdcp2_init(connector, shim);
@@ -2023,7 +2025,8 @@ int intel_hdcp_enable(struct intel_connector *connector,
* Considering that HDCP2.2 is more secure than HDCP1.4, If the setup
* is capable of HDCP2.2, it is preferred to use HDCP2.2.
*/
- if (intel_hdcp2_capable(connector)) {
+ if ((hdcp->debugfs_ver_request & HDCP_VERSION_2_2) &&
+ intel_hdcp2_capable(connector)) {
ret = _intel_hdcp2_enable(connector);
if (!ret)
check_link_interval = DRM_HDCP2_CHECK_PERIOD_MS;
@@ -2033,7 +2036,8 @@ int intel_hdcp_enable(struct intel_connector *connector,
* When HDCP2.2 fails and Content Type is not Type1, HDCP1.4 will
* be attempted.
*/
- if (ret && intel_hdcp_capable(connector) &&
+ if (ret && (hdcp->debugfs_ver_request & HDCP_VERSION_1_4) &&
+ intel_hdcp_capable(connector) &&
hdcp->content_type != DRM_MODE_HDCP_CONTENT_TYPE1) {
ret = _intel_hdcp_enable(connector);
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 0/2] i915: Add debugfs for requesting HDCP version
Currently, for a given content-protection request, the kernel selects the highest version of HDCP supported by the panel and the platform. This makes the testing/debugging difficult for lower versions of HDCP. E.g. In case both the lower and the higher HDCP versions are supported then the higher version of HDCP will always be selected and the lower HDCP version cannot be tested without changing the setup. A solution for this was proposed in an IGT patch [1] by removing "mei_hdcp" module, but a need for a generic future-proof solution was identified. As suggested by the community members, this patch attempts to add a new debugfs per connector for requesting a specific version of HDCP for debug/testing environment. The test can request for a specific HDCP version and set the appropriate content-protection connector properties to test the required version. The kernel will consider the request if the HDCP version is sufficient for the requested content-protection. To make the design simpler, the debugfs for requesting the HDCP version can be only set when the content-protection is disabled. In case, the test tries to write the debugfs while a request for content-protectiont is ongoing, the write will be failed. So the test needs to make sure that the content-protection is disabled before requesting for an HDCP version via debugfs. [1] https://patchwork.freedesktop.org/patch/358240/ Ankit Nautiyal (2): drm/i915: Add support for considering HDCP ver requested via debugfs drm/i915: Add a new debugfs to request HDCP version .../drm/i915/display/intel_display_debugfs.c | 98 +++ .../drm/i915/display/intel_display_types.h| 10 ++ drivers/gpu/drm/i915/display/intel_hdcp.c | 8 +- 3 files changed, 114 insertions(+), 2 deletions(-) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 2/2] drm/i915: Add a new debugfs to request HDCP version
As per the current HDCP design, the driver selects the highest
version of HDCP that can be used to satisfy the content-protection
requirements of the user. Due to this, the content-protection
tests cannot test a lower version of HDCP, if the platform and the
display panel, both support higher HDCP version.
To provide some support for testing and debugging, a per-connector
debugfs is required to set the HDCP version via debugfs that the
kernel can consider, while enabling HDCP.
This patch adds a new debugfs entry for each connector that supports
HDCP. For enforcing a particular HDCP version for a connector, the user
can write into the debugfs for that connector.
To make design simple, the HDCP version request can only be made via
debugfs, if there is no ongoing request for Content-Protection for
the connector. The tests are expected to make sure that HDCP is disabled
before making HDCP version request via the debugfs for the connector.
Otherwise, the write request to the debugfs will be failed.
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_debugfs.c | 98 +++
1 file changed, 98 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 70525623bcdf..e65abca1a1fa 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -2185,6 +2185,102 @@ static const struct file_operations
i915_dsc_fec_support_fops = {
.write = i915_dsc_fec_support_write
};
+static int i915_hdcp_ver_request_show(struct seq_file *m, void *data)
+{
+
+ struct drm_connector *connector = m->private;
+ struct intel_connector *intel_connector = to_intel_connector(connector);
+ u64 hdcp_ver_flag;
+
+ if (connector->status != connector_status_connected)
+ return -ENODEV;
+
+ /* HDCP is supported by connector */
+ if (!intel_connector->hdcp.shim)
+ return -EINVAL;
+
+ hdcp_ver_flag = intel_connector->hdcp.debugfs_ver_request;
+ seq_printf(m, "HDCP_VER_FLAGS: %llu\n", hdcp_ver_flag);
+
+ seq_printf(m, "Requested Versions:\n");
+ if (hdcp_ver_flag & HDCP_VERSION_1_4)
+ seq_printf(m, "HDCP1.4\n");
+ if (hdcp_ver_flag & HDCP_VERSION_2_2)
+ seq_printf(m, "HDCP2.2\n");
+
+ return 0;
+}
+
+static int i915_hdcp_ver_request_open(struct inode *inode,
+struct file *file)
+{
+ return single_open(file, i915_hdcp_ver_request_show,
+ inode->i_private);
+}
+
+static int intel_hdcp_debugfs_ver_set(struct intel_connector *connector, u64
val)
+{
+ struct intel_hdcp *hdcp = >hdcp;
+
+ if (!hdcp->shim || val > HDCP_VERSION_MASK)
+ return -EINVAL;
+
+ if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+ return -EINVAL;
+
+ hdcp->debugfs_ver_request = val;
+ return 0;
+}
+
+static ssize_t i915_hdcp_ver_request_write(struct file *file,
+ const char __user *ubuf,
+ size_t len, loff_t *offp)
+{
+ unsigned int hdcp_ver = 0;
+ int ret;
+ struct drm_connector *connector =
+ ((struct seq_file *)file->private_data)->private;
+ struct intel_connector *intel_con = to_intel_connector(connector);
+ struct drm_i915_private *i915 = to_i915(connector->dev);
+ char tmp[16];
+
+ if (len == 0)
+ return 0;
+
+ if (len >= sizeof(tmp))
+ return -EINVAL;
+
+ if (copy_from_user(tmp, ubuf, len))
+ return -EFAULT;
+
+ tmp[len] = '\0';
+
+
+ drm_dbg(>drm,
+ "Copied %zu bytes from user to request hdcp ver\n", len);
+
+ ret = kstrtouint(tmp, 10, _ver);
+ if (ret < 0)
+ return ret;
+
+ drm_dbg(>drm, "Got %u for HDCP version\n", hdcp_ver);
+ ret = intel_hdcp_debugfs_ver_set(intel_con, hdcp_ver);
+ if (ret < 0)
+ return ret;
+
+ *offp += len;
+ return len;
+}
+
+static const struct file_operations i915_hdcp_ver_request_fops = {
+ .owner = THIS_MODULE,
+ .open = i915_hdcp_ver_request_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+ .write = i915_hdcp_ver_request_write
+};
+
/**
* intel_connector_debugfs_add - add i915 specific connector debugfs files
* @connector: pointer to a registered drm_connector
@@ -2215,6 +2311,8 @@ int intel_connector_debugfs_add(struct drm_connector
*connector)
connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {
debugfs_create_file("i915_hdcp_sink_capability", S_IRUGO, root,
connector, _hdcp_sink_capability_fops);
+ debugfs_create_file("i915_hdcp_version_request", S_IRUGO,
Re: [Intel-gfx] [PATCH] drm/atomic-helper: reset vblank on crtc reset
Hi Daniel,
On Wed, May 27, 2020 at 11:53:32AM +0200, Daniel Vetter wrote:
> Only when vblanks are supported ofc.
>
> Some drivers do this already, but most unfortunately missed it. This
> opens up bugs after driver load, before the crtc is enabled for the
> first time. syzbot spotted this when loading vkms as a secondary
> output. Given how many drivers are buggy it's best to solve this once
> and for all in shared helper code.
>
> Aside from moving the few existing calls to drm_crtc_vblank_reset into
> helpers (i915 doesn't use helpers, so keeps its own) I think the
> regression risk is minimal: atomic helpers already rely on drivers
> calling drm_crtc_vblank_on/off correctly in their hooks when they
> support vblanks. And driver that's failing to handle vblanks after
> this is missing those calls already, and vblanks could only work by
> accident when enabling a CRTC for the first time right after boot.
>
> Big thanks to Tetsuo for helping track down what's going wrong here.
>
> There's only a few drivers which already had the necessary call and
> needed some updating:
> - komeda, atmel and tidss also needed to be changed to call
> __drm_atomic_helper_crtc_reset() intead of open coding it
> - tegra and msm even had it in the same place already, just code
> motion, and malidp already uses __drm_atomic_helper_crtc_reset().
>
> Only call left is in i915, which doesn't use drm_mode_config_reset,
> but has its own fastboot infrastructure. So that's the only case where
> we actually want this in the driver still.
>
> I've also reviewed all other drivers which set up vblank support with
> drm_vblank_init. After the previous patch fixing mxsfb all atomic
> drivers do call drm_crtc_vblank_on/off as they should, the remaining
> drivers are either legacy kms or legacy dri1 drivers, so not affected
> by this change to atomic helpers.
>
> v2: Use the drm_dev_has_vblank() helper.
>
> Link:
> https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
> Reported-by: Tetsuo Handa
> Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
> Cc: Tetsuo Handa
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
> Cc: Mihail Atanassov
> Cc: Brian Starkey
> Cc: Sam Ravnborg
> Cc: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Ludovic Desroches
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Brian Masney
> Cc: Emil Velikov
> Cc: zhengbin
> Cc: Thomas Gleixner
> Cc: linux-te...@vger.kernel.org
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++-
> drivers/gpu/drm/arm/malidp_drv.c | 1 -
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 7 ++-
> drivers/gpu/drm/drm_atomic_state_helper.c| 4
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 2 --
> drivers/gpu/drm/tegra/dc.c | 1 -
> drivers/gpu/drm/tidss/tidss_crtc.c | 3 +--
> drivers/gpu/drm/tidss/tidss_kms.c| 4
> 8 files changed, 9 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 56bd938961ee..f33418d6e1a0 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -492,10 +492,8 @@ static void komeda_crtc_reset(struct drm_crtc *crtc)
> crtc->state = NULL;
>
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> - }
> + if (state)
> + __drm_atomic_helper_crtc_reset(crtc, >base);
> }
>
> static struct drm_crtc_state *
> @@ -616,7 +614,6 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
> return err;
>
> drm_crtc_helper_add(crtc, _crtc_helper_funcs);
> - drm_crtc_vblank_reset(crtc);
>
> crtc->port = kcrtc->master->of_output_port;
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index c2507b7d8512..02904392e370 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -870,7 +870,6 @@ static int malidp_bind(struct device *dev)
> drm->irq_enabled = true;
>
> ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
> - drm_crtc_vblank_reset(>crtc);
It was a couple of years ago but I remember Alexandru-Cosmin tracking an issue
around
this. The reason for reseting the vblank so early after calling drm_vblank_init
was that
you could have userspace calling drm_wait_vblank() before crtc activation and
in our
case it will trigger some warnings in the driver (details are fuzzy right now).
The
relevant commit was cabce6343fd ("drm: mali-dp: Call
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/mxsfb: Call drm_crtc_vblank_on/off (rev2)
== Series Details == Series: series starting with [1/2] drm/mxsfb: Call drm_crtc_vblank_on/off (rev2) URL : https://patchwork.freedesktop.org/series/77689/ State : warning == Summary == $ dim checkpatch origin/drm-tip 854716133023 drm/mxsfb: Call drm_crtc_vblank_on/off -:47: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 14 lines checked 256337b390c6 drm/atomic-helper: reset vblank on crtc reset -:211: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 95 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic-helper: reset vblank on crtc reset
On Wed, May 27, 2020 at 11:53:32AM +0200, Daniel Vetter wrote: > Only when vblanks are supported ofc. > > Some drivers do this already, but most unfortunately missed it. This > opens up bugs after driver load, before the crtc is enabled for the > first time. syzbot spotted this when loading vkms as a secondary > output. Given how many drivers are buggy it's best to solve this once > and for all in shared helper code. > > Aside from moving the few existing calls to drm_crtc_vblank_reset into > helpers (i915 doesn't use helpers, so keeps its own) I think the > regression risk is minimal: atomic helpers already rely on drivers > calling drm_crtc_vblank_on/off correctly in their hooks when they > support vblanks. And driver that's failing to handle vblanks after > this is missing those calls already, and vblanks could only work by > accident when enabling a CRTC for the first time right after boot. > > Big thanks to Tetsuo for helping track down what's going wrong here. > > There's only a few drivers which already had the necessary call and > needed some updating: > - komeda, atmel and tidss also needed to be changed to call > __drm_atomic_helper_crtc_reset() intead of open coding it > - tegra and msm even had it in the same place already, just code > motion, and malidp already uses __drm_atomic_helper_crtc_reset(). > > Only call left is in i915, which doesn't use drm_mode_config_reset, > but has its own fastboot infrastructure. So that's the only case where > we actually want this in the driver still. > > I've also reviewed all other drivers which set up vblank support with > drm_vblank_init. After the previous patch fixing mxsfb all atomic > drivers do call drm_crtc_vblank_on/off as they should, the remaining > drivers are either legacy kms or legacy dri1 drivers, so not affected > by this change to atomic helpers. > > v2: Use the drm_dev_has_vblank() helper. > > Link: > https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb > Reported-by: Tetsuo Handa > Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com > Cc: Tetsuo Handa > Cc: "James (Qian) Wang" > Cc: Liviu Dudau > Cc: Mihail Atanassov > Cc: Brian Starkey > Cc: Sam Ravnborg > Cc: Boris Brezillon > Cc: Nicolas Ferre > Cc: Alexandre Belloni > Cc: Ludovic Desroches > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: David Airlie > Cc: Daniel Vetter > Cc: Thierry Reding > Cc: Jonathan Hunter > Cc: Jyri Sarha > Cc: Tomi Valkeinen > Cc: Rob Clark > Cc: Sean Paul > Cc: Brian Masney > Cc: Emil Velikov > Cc: zhengbin > Cc: Thomas Gleixner > Cc: linux-te...@vger.kernel.org > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++- > drivers/gpu/drm/arm/malidp_drv.c | 1 - > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 7 ++- > drivers/gpu/drm/drm_atomic_state_helper.c| 4 > drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 2 -- > drivers/gpu/drm/tegra/dc.c | 1 - > drivers/gpu/drm/tidss/tidss_crtc.c | 3 +-- > drivers/gpu/drm/tidss/tidss_kms.c| 4 > 8 files changed, 9 insertions(+), 20 deletions(-) Looks good, and nice cleanup: Acked-by: Thierry Reding signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Special handling for bonded requests
== Series Details ==
Series: drm/i915: Special handling for bonded requests
URL : https://patchwork.freedesktop.org/series/77688/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8541_full -> Patchwork_17782_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17782_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17782_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_17782_full:
### IGT changes ###
Possible regressions
* igt@gem_eio@in-flight-contexts-10ms:
- shard-snb: [PASS][1] -> [TIMEOUT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8541/shard-snb6/igt@gem_...@in-flight-contexts-10ms.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17782/shard-snb2/igt@gem_...@in-flight-contexts-10ms.html
* igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
- shard-glk: NOTRUN -> [TIMEOUT][3] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17782/shard-glk1/igt@kms_plane_alpha_bl...@pipe-b-alpha-basic.html
Warnings
* igt@runner@aborted:
- shard-hsw: [FAIL][4] ([i915#226]) -> ([FAIL][5], [FAIL][6])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8541/shard-hsw8/igt@run...@aborted.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17782/shard-hsw6/igt@run...@aborted.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17782/shard-hsw4/igt@run...@aborted.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_exec_fence@concurrent@vcs0}:
- shard-iclb: [PASS][7] -> [FAIL][8] +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8541/shard-iclb1/igt@gem_exec_fence@concurr...@vcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17782/shard-iclb8/igt@gem_exec_fence@concurr...@vcs0.html
* {igt@gem_exec_fence@submit3@vcs0}:
- shard-tglb: [PASS][9] -> [INCOMPLETE][10] +2 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8541/shard-tglb1/igt@gem_exec_fence@subm...@vcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17782/shard-tglb3/igt@gem_exec_fence@subm...@vcs0.html
* {igt@gem_exec_fence@submit67@vcs0}:
- shard-iclb: [PASS][11] -> [INCOMPLETE][12] +2 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8541/shard-iclb1/igt@gem_exec_fence@submi...@vcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17782/shard-iclb4/igt@gem_exec_fence@submi...@vcs0.html
* {igt@gem_exec_schedule@submit-golden-slice@vcs0}:
- shard-tglb: [PASS][13] -> [FAIL][14] +2 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8541/shard-tglb5/igt@gem_exec_schedule@submit-golden-sl...@vcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17782/shard-tglb5/igt@gem_exec_schedule@submit-golden-sl...@vcs0.html
Known issues
Here are the changes found in Patchwork_17782_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_crc@pipe-a-cursor-128x42-onscreen:
- shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#78])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8541/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-128x42-onscreen.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17782/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-128x42-onscreen.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +3
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8541/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17782/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-suspend.html
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-hsw: [PASS][19] -> [DMESG-WARN][20] ([i915#1927])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8541/shard-hsw8/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17782/shard-hsw4/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html
* igt@kms_draw_crc@draw-method-rgb565-render-untiled:
- shard-snb: [PASS][21] -> [SKIP][22] ([fdo#109271])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8541/shard-snb1/igt@kms_draw_...@draw-method-rgb565-render-untiled.html
[22]:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/mxsfb: Call drm_crtc_vblank_on/off
== Series Details == Series: series starting with [1/2] drm/mxsfb: Call drm_crtc_vblank_on/off URL : https://patchwork.freedesktop.org/series/77689/ State : success == Summary == CI Bug Log - changes from CI_DRM_8541 -> Patchwork_17783 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17783/index.html Changes --- No changes found 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_8541 -> Patchwork_17783 CI-20190529: 20190529 CI_DRM_8541: 6f35fec9320a0ee5178075dd3d9df6507f55af68 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5680: f7e3772175c53f0c910f4513831791cb5bdcab04 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17783: 026d27d53616816edfeab1d8caa0d6af236ef01c @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 026d27d53616 drm/atomic-helper: reset vblank on crtc reset 01d3621e8e27 drm/mxsfb: Call drm_crtc_vblank_on/off == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17783/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: Special handling for bonded requests
Quoting Tvrtko Ursulin (2020-05-27 10:36:31)
>
> On 27/05/2020 10:20, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-05-27 09:53:22)
> >> From: Tvrtko Ursulin
> >>
> >> Our generic mechanism for specifying aligned request start,
> >> I915_EXEC_FENCE_SUBMIT, has a bit too relaxed rules when it comes to the
> >> actual use case of media scalability on Tigerlake.
> >>
> >> While the submit fence can provide the aligned start, the actual media
> >> pipeline expects that execution remains in lockstep from then onwards.
> >> Otherwise the hardware cannot handle well one of the pair getting
> >> preempted leading to GPU hangs and corrupted media playback.
> >>
> >> This puts us in a difficult position where the only visible solution,
> >> which does not involve adding new uapi, is to give more meaning to the
> >> generic submit fence. At least when used between the video engines.
> >>
> >> The special semantics this patch applies in that case are two fold. First
> >> is that both of the aligned pairs will be marked as non-preemptable and
> >> second is ensuring both are not sharing ELSP ports with any other context.
> >>
> >> Non-preemptable property will ensure that once the start has been aligned
> >> the requests remain executing until completion.
> >>
> >> Single port ELSP property will ensure there are no possible inversions
> >> between different independent pairs of aligned requests.
> >
> > Nak.
> >
> >> Going forward we can think of introducing new uapi to request this
> >> behaviour as a separate, more explicit flag, and at that point retire this
> >> semi-generic special handling.
> >
> > As CI will say, such behaviour will already need a new flag. Forcing
> > no-preemption should be a privileged flag, so I would expect some
> > acknowledge that this is a HW problem that we have to workaround.
>
> I don't know how hw exactly works so from my side it's only empirical.
>
> I agree new flag is needed but we also need a fix ASAP for TGL. And I
> don't think we can add new uapi in a reasonable time frame here. We
> would need the ctx set_parallel extension with a dont-preempt flag and
> multi-batch execbuf. And a lot of work in media-driver which will not be
> ready for TGL. I don't think a flag at the I915_EXEC_FENCE_SUBMIT level
> is a solution.
I'm going to say the starting point is to remove the
I915_ENGINE_HAS_PREEMPTION flag from vcs*. That way the tests that
require preemption will skip. Sadly that's the level of our current API.
> >> Signed-off-by: Tvrtko Ursulin
> >> Suggested-by: Xiaogang Li
> >> Cc: Chris Wilson
> >> ---
> >> drivers/gpu/drm/i915/gt/intel_context.h | 2 +-
> >> drivers/gpu/drm/i915/gt/intel_lrc.c | 46 +
> >> 2 files changed, 41 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> >> b/drivers/gpu/drm/i915/gt/intel_context.h
> >> index 07be021882cc..576d11c0cdd9 100644
> >> --- a/drivers/gpu/drm/i915/gt/intel_context.h
> >> +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> >> @@ -212,7 +212,7 @@ intel_context_force_single_submission(const struct
> >> intel_context *ce)
> >> static inline void
> >> intel_context_set_single_submission(struct intel_context *ce)
> >> {
> >> - __set_bit(CONTEXT_FORCE_SINGLE_SUBMISSION, >flags);
> >> + set_bit(CONTEXT_FORCE_SINGLE_SUBMISSION, >flags);
> >> }
> >>
> >> static inline bool
> >> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> >> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> >> index 3214a4ecc31a..88cf20fd92c8 100644
> >> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> >> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> >> @@ -1734,8 +1734,7 @@ static void execlists_submit_ports(struct
> >> intel_engine_cs *engine)
> >>
> >> static bool ctx_single_port_submission(const struct intel_context *ce)
> >> {
> >> - return (IS_ENABLED(CONFIG_DRM_I915_GVT) &&
> >> - intel_context_force_single_submission(ce));
> >> + return intel_context_force_single_submission(ce);
> >> }
> >>
> >> static bool can_merge_ctx(const struct intel_context *prev,
> >> @@ -4929,9 +4928,41 @@ static void execlists_park(struct intel_engine_cs
> >> *engine)
> >> cancel_timer(>execlists.preempt);
> >> }
> >>
> >> +static void
> >> +mark_bonded_pair(struct i915_request *rq, struct i915_request *signal)
> >> +{
> >> + /*
> >> +* Give (temporary) special meaning to a pair requests with
> >> requested
> >> +* aligned start along the video engines.
> >> +*
> >> +* They should be non-preemptable and have all ELSP ports to
> >> themselves
> >> +* to avoid any deadlocks caused by inversions.
> >
> > This sentence needs expanding, because you are implying that this is an
> > issue we need to address in the code. If there is a deadlock resulting
> > from incorrect submission ordering, that is a bug in the code.
>
> If we add no-preempt I think we have to have single elsp
[Intel-gfx] [PATCH] drm/atomic-helper: reset vblank on crtc reset
Only when vblanks are supported ofc.
Some drivers do this already, but most unfortunately missed it. This
opens up bugs after driver load, before the crtc is enabled for the
first time. syzbot spotted this when loading vkms as a secondary
output. Given how many drivers are buggy it's best to solve this once
and for all in shared helper code.
Aside from moving the few existing calls to drm_crtc_vblank_reset into
helpers (i915 doesn't use helpers, so keeps its own) I think the
regression risk is minimal: atomic helpers already rely on drivers
calling drm_crtc_vblank_on/off correctly in their hooks when they
support vblanks. And driver that's failing to handle vblanks after
this is missing those calls already, and vblanks could only work by
accident when enabling a CRTC for the first time right after boot.
Big thanks to Tetsuo for helping track down what's going wrong here.
There's only a few drivers which already had the necessary call and
needed some updating:
- komeda, atmel and tidss also needed to be changed to call
__drm_atomic_helper_crtc_reset() intead of open coding it
- tegra and msm even had it in the same place already, just code
motion, and malidp already uses __drm_atomic_helper_crtc_reset().
Only call left is in i915, which doesn't use drm_mode_config_reset,
but has its own fastboot infrastructure. So that's the only case where
we actually want this in the driver still.
I've also reviewed all other drivers which set up vblank support with
drm_vblank_init. After the previous patch fixing mxsfb all atomic
drivers do call drm_crtc_vblank_on/off as they should, the remaining
drivers are either legacy kms or legacy dri1 drivers, so not affected
by this change to atomic helpers.
v2: Use the drm_dev_has_vblank() helper.
Link:
https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
Reported-by: Tetsuo Handa
Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
Cc: Tetsuo Handa
Cc: "James (Qian) Wang"
Cc: Liviu Dudau
Cc: Mihail Atanassov
Cc: Brian Starkey
Cc: Sam Ravnborg
Cc: Boris Brezillon
Cc: Nicolas Ferre
Cc: Alexandre Belloni
Cc: Ludovic Desroches
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Thierry Reding
Cc: Jonathan Hunter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
Cc: Rob Clark
Cc: Sean Paul
Cc: Brian Masney
Cc: Emil Velikov
Cc: zhengbin
Cc: Thomas Gleixner
Cc: linux-te...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++-
drivers/gpu/drm/arm/malidp_drv.c | 1 -
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 7 ++-
drivers/gpu/drm/drm_atomic_state_helper.c| 4
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 2 --
drivers/gpu/drm/tegra/dc.c | 1 -
drivers/gpu/drm/tidss/tidss_crtc.c | 3 +--
drivers/gpu/drm/tidss/tidss_kms.c| 4
8 files changed, 9 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 56bd938961ee..f33418d6e1a0 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -492,10 +492,8 @@ static void komeda_crtc_reset(struct drm_crtc *crtc)
crtc->state = NULL;
state = kzalloc(sizeof(*state), GFP_KERNEL);
- if (state) {
- crtc->state = >base;
- crtc->state->crtc = crtc;
- }
+ if (state)
+ __drm_atomic_helper_crtc_reset(crtc, >base);
}
static struct drm_crtc_state *
@@ -616,7 +614,6 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
return err;
drm_crtc_helper_add(crtc, _crtc_helper_funcs);
- drm_crtc_vblank_reset(crtc);
crtc->port = kcrtc->master->of_output_port;
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index c2507b7d8512..02904392e370 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -870,7 +870,6 @@ static int malidp_bind(struct device *dev)
drm->irq_enabled = true;
ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
- drm_crtc_vblank_reset(>crtc);
if (ret < 0) {
DRM_ERROR("failed to initialise vblank\n");
goto vblank_fail;
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 10985134ce0b..ce246b96330b 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -411,10 +411,8 @@ static void atmel_hlcdc_crtc_reset(struct drm_crtc *crtc)
}
state = kzalloc(sizeof(*state), GFP_KERNEL);
- if (state) {
- crtc->state = >base;
- crtc->state->crtc = crtc;
- }
+ if (state)
+
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/mxsfb: Call drm_crtc_vblank_on/off
== Series Details == Series: series starting with [1/2] drm/mxsfb: Call drm_crtc_vblank_on/off URL : https://patchwork.freedesktop.org/series/77689/ State : warning == Summary == $ dim checkpatch origin/drm-tip 01d3621e8e27 drm/mxsfb: Call drm_crtc_vblank_on/off -:47: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 14 lines checked 026d27d53616 drm/atomic-helper: reset vblank on crtc reset -:209: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 95 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Special handling for bonded requests
== Series Details == Series: drm/i915: Special handling for bonded requests URL : https://patchwork.freedesktop.org/series/77688/ State : success == Summary == CI Bug Log - changes from CI_DRM_8541 -> Patchwork_17782 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17782/index.html Known issues Here are the changes found in Patchwork_17782 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@coherency: - fi-gdg-551: [PASS][1] -> [DMESG-FAIL][2] ([i915#1748]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8541/fi-gdg-551/igt@i915_selftest@l...@coherency.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17782/fi-gdg-551/igt@i915_selftest@l...@coherency.html * igt@kms_chamelium@hdmi-crc-fast: - fi-kbl-7500u: [PASS][3] -> [DMESG-FAIL][4] ([i915#165]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8541/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17782/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165 [i915#1748]: https://gitlab.freedesktop.org/drm/intel/issues/1748 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_8541 -> Patchwork_17782 CI-20190529: 20190529 CI_DRM_8541: 6f35fec9320a0ee5178075dd3d9df6507f55af68 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5680: f7e3772175c53f0c910f4513831791cb5bdcab04 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17782: 10e39c0f7a03edbe826ad25606a4d465b1817d6b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 10e39c0f7a03 drm/i915: Special handling for bonded requests == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17782/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/mxsfb: Call drm_crtc_vblank_on/off
mxsfb has vblank support, is atomic, but doesn't call drm_crtc_vblank_on/off as it should. Not good. With my next patch to add the drm_crtc_vblank_reset to helpers this means not even the very first crtc enabling will vblanks work anymore, since they'll just stay off forever. Since mxsfb doesn't have any vblank waits of its own in the enable/disable flow, nor an enable/disable_vblank callback we can do the on/off as the first respectively last operation, and it should all work. Signed-off-by: Daniel Vetter Cc: Marek Vasut Cc: Stefan Agner Cc: Shawn Guo Cc: Sascha Hauer Cc: Pengutronix Kernel Team Cc: Fabio Estevam Cc: NXP Linux Team Cc: linux-arm-ker...@lists.infradead.org --- drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c index 497cf443a9af..1891cd6deb2f 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c @@ -124,6 +124,7 @@ static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe, drm_panel_prepare(mxsfb->panel); mxsfb_crtc_enable(mxsfb); drm_panel_enable(mxsfb->panel); + drm_crtc_vblank_on(>crtc); } static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe) @@ -133,6 +134,7 @@ static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe) struct drm_crtc *crtc = >crtc; struct drm_pending_vblank_event *event; + drm_crtc_vblank_off(>crtc); drm_panel_disable(mxsfb->panel); mxsfb_crtc_disable(mxsfb); drm_panel_unprepare(mxsfb->panel); -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/atomic-helper: reset vblank on crtc reset
Only when vblanks are supported ofc.
Some drivers do this already, but most unfortunately missed it. This
opens up bugs after driver load, before the crtc is enabled for the
first time. syzbot spotted this when loading vkms as a secondary
output. Given how many drivers are buggy it's best to solve this once
and for all in shared helper code.
Aside from moving the few existing calls to drm_crtc_vblank_reset into
helpers (i915 doesn't use helpers, so keeps its own) I think the
regression risk is minimal: atomic helpers already rely on drivers
calling drm_crtc_vblank_on/off correctly in their hooks when they
support vblanks. And driver that's failing to handle vblanks after
this is missing those calls already, and vblanks could only work by
accident when enabling a CRTC for the first time right after boot.
Big thanks to Tetsuo for helping track down what's going wrong here.
There's only a few drivers which already had the necessary call and
needed some updating:
- komeda, atmel and tidss also needed to be changed to call
__drm_atomic_helper_crtc_reset() intead of open coding it
- tegra and msm even had it in the same place already, just code
motion, and malidp already uses __drm_atomic_helper_crtc_reset().
Only call left is in i915, which doesn't use drm_mode_config_reset,
but has its own fastboot infrastructure. So that's the only case where
we actually want this in the driver still.
I've also reviewed all other drivers which set up vblank support with
drm_vblank_init. After the previous patch fixing mxsfb all atomic
drivers do call drm_crtc_vblank_on/off as they should, the remaining
drivers are either legacy kms or legacy dri1 drivers, so not affected
by this change to atomic helpers.
Link:
https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
Reported-by: Tetsuo Handa
Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
Cc: Tetsuo Handa
Cc: "James (Qian) Wang"
Cc: Liviu Dudau
Cc: Mihail Atanassov
Cc: Brian Starkey
Cc: Sam Ravnborg
Cc: Boris Brezillon
Cc: Nicolas Ferre
Cc: Alexandre Belloni
Cc: Ludovic Desroches
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Thierry Reding
Cc: Jonathan Hunter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
Cc: Rob Clark
Cc: Sean Paul
Cc: Brian Masney
Cc: Emil Velikov
Cc: zhengbin
Cc: Thomas Gleixner
Cc: linux-te...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++-
drivers/gpu/drm/arm/malidp_drv.c | 1 -
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 7 ++-
drivers/gpu/drm/drm_atomic_state_helper.c| 4
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 2 --
drivers/gpu/drm/tegra/dc.c | 1 -
drivers/gpu/drm/tidss/tidss_crtc.c | 3 +--
drivers/gpu/drm/tidss/tidss_kms.c| 4
8 files changed, 9 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 56bd938961ee..f33418d6e1a0 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -492,10 +492,8 @@ static void komeda_crtc_reset(struct drm_crtc *crtc)
crtc->state = NULL;
state = kzalloc(sizeof(*state), GFP_KERNEL);
- if (state) {
- crtc->state = >base;
- crtc->state->crtc = crtc;
- }
+ if (state)
+ __drm_atomic_helper_crtc_reset(crtc, >base);
}
static struct drm_crtc_state *
@@ -616,7 +614,6 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
return err;
drm_crtc_helper_add(crtc, _crtc_helper_funcs);
- drm_crtc_vblank_reset(crtc);
crtc->port = kcrtc->master->of_output_port;
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index c2507b7d8512..02904392e370 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -870,7 +870,6 @@ static int malidp_bind(struct device *dev)
drm->irq_enabled = true;
ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
- drm_crtc_vblank_reset(>crtc);
if (ret < 0) {
DRM_ERROR("failed to initialise vblank\n");
goto vblank_fail;
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 10985134ce0b..ce246b96330b 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -411,10 +411,8 @@ static void atmel_hlcdc_crtc_reset(struct drm_crtc *crtc)
}
state = kzalloc(sizeof(*state), GFP_KERNEL);
- if (state) {
- crtc->state = >base;
- crtc->state->crtc = crtc;
- }
+ if (state)
+ __drm_atomic_helper_crtc_reset(crtc, >base);
}
static
Re: [Intel-gfx] [PATCH] drm/i915/gt: Clear LOCAL_BIND from shared GGTT on resume
On Tue, 26 May 2020 at 16:07, Chris Wilson wrote:
>
> We only restore GLOBAL binds upon resume as we expect these to be pinned
> for use by HW, whereas the LOCAL binds can be recreated on demand once
> userspace is resumed. For the LOCAL bind to be recreated in the global
> GTT, we need to clear its presence flag on deciding not to restore the
> mapping upon resume.
>
> Fixes: bf0840cdb304 ("drm/i915/gt: Stop cross-polluting PIN_GLOBAL with
> PIN_USER with no-ppgtt")
> 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] drm/i915: Special handling for bonded requests
On 27/05/2020 10:20, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-05-27 09:53:22)
From: Tvrtko Ursulin
Our generic mechanism for specifying aligned request start,
I915_EXEC_FENCE_SUBMIT, has a bit too relaxed rules when it comes to the
actual use case of media scalability on Tigerlake.
While the submit fence can provide the aligned start, the actual media
pipeline expects that execution remains in lockstep from then onwards.
Otherwise the hardware cannot handle well one of the pair getting
preempted leading to GPU hangs and corrupted media playback.
This puts us in a difficult position where the only visible solution,
which does not involve adding new uapi, is to give more meaning to the
generic submit fence. At least when used between the video engines.
The special semantics this patch applies in that case are two fold. First
is that both of the aligned pairs will be marked as non-preemptable and
second is ensuring both are not sharing ELSP ports with any other context.
Non-preemptable property will ensure that once the start has been aligned
the requests remain executing until completion.
Single port ELSP property will ensure there are no possible inversions
between different independent pairs of aligned requests.
Nak.
Going forward we can think of introducing new uapi to request this
behaviour as a separate, more explicit flag, and at that point retire this
semi-generic special handling.
As CI will say, such behaviour will already need a new flag. Forcing
no-preemption should be a privileged flag, so I would expect some
acknowledge that this is a HW problem that we have to workaround.
I don't know how hw exactly works so from my side it's only empirical.
I agree new flag is needed but we also need a fix ASAP for TGL. And I
don't think we can add new uapi in a reasonable time frame here. We
would need the ctx set_parallel extension with a dont-preempt flag and
multi-batch execbuf. And a lot of work in media-driver which will not be
ready for TGL. I don't think a flag at the I915_EXEC_FENCE_SUBMIT level
is a solution.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Xiaogang Li
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.h | 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 46 +
2 files changed, 41 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 07be021882cc..576d11c0cdd9 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -212,7 +212,7 @@ intel_context_force_single_submission(const struct
intel_context *ce)
static inline void
intel_context_set_single_submission(struct intel_context *ce)
{
- __set_bit(CONTEXT_FORCE_SINGLE_SUBMISSION, >flags);
+ set_bit(CONTEXT_FORCE_SINGLE_SUBMISSION, >flags);
}
static inline bool
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 3214a4ecc31a..88cf20fd92c8 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1734,8 +1734,7 @@ static void execlists_submit_ports(struct intel_engine_cs
*engine)
static bool ctx_single_port_submission(const struct intel_context *ce)
{
- return (IS_ENABLED(CONFIG_DRM_I915_GVT) &&
- intel_context_force_single_submission(ce));
+ return intel_context_force_single_submission(ce);
}
static bool can_merge_ctx(const struct intel_context *prev,
@@ -4929,9 +4928,41 @@ static void execlists_park(struct intel_engine_cs
*engine)
cancel_timer(>execlists.preempt);
}
+static void
+mark_bonded_pair(struct i915_request *rq, struct i915_request *signal)
+{
+ /*
+* Give (temporary) special meaning to a pair requests with requested
+* aligned start along the video engines.
+*
+* They should be non-preemptable and have all ELSP ports to themselves
+* to avoid any deadlocks caused by inversions.
This sentence needs expanding, because you are implying that this is an
issue we need to address in the code. If there is a deadlock resulting
from incorrect submission ordering, that is a bug in the code.
If we add no-preempt I think we have to have single elsp because there
is no ordering between unrelated pairs and then elsp inversion certainly
sounds like a deadlock.
ctx-A: vcs0 + vcs1
ctx-B: vcs0 + vcs1
There is no ordering between A and B but we'd have to pick same port for
both pairs of A and B respectively. I don't see that we can do that
since all four submissions are async.
Regards,
Tvrtko
___
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: Special handling for bonded requests
== Series Details == Series: drm/i915: Special handling for bonded requests URL : https://patchwork.freedesktop.org/series/77688/ State : warning == Summary == $ dim checkpatch origin/drm-tip 10e39c0f7a03 drm/i915: Special handling for bonded requests -:20: WARNING:TYPO_SPELLING: 'preemptable' may be misspelled - perhaps 'preemptible'? #20: is that both of the aligned pairs will be marked as non-preemptable and -:23: WARNING:TYPO_SPELLING: 'preemptable' may be misspelled - perhaps 'preemptible'? #23: Non-preemptable property will ensure that once the start has been aligned -:75: WARNING:TYPO_SPELLING: 'preemptable' may be misspelled - perhaps 'preemptible'? #75: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:4938: +* They should be non-preemptable and have all ELSP ports to themselves total: 0 errors, 3 warnings, 0 checks, 87 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: Special handling for bonded requests
Quoting Tvrtko Ursulin (2020-05-27 09:53:22)
> From: Tvrtko Ursulin
>
> Our generic mechanism for specifying aligned request start,
> I915_EXEC_FENCE_SUBMIT, has a bit too relaxed rules when it comes to the
> actual use case of media scalability on Tigerlake.
>
> While the submit fence can provide the aligned start, the actual media
> pipeline expects that execution remains in lockstep from then onwards.
> Otherwise the hardware cannot handle well one of the pair getting
> preempted leading to GPU hangs and corrupted media playback.
>
> This puts us in a difficult position where the only visible solution,
> which does not involve adding new uapi, is to give more meaning to the
> generic submit fence. At least when used between the video engines.
>
> The special semantics this patch applies in that case are two fold. First
> is that both of the aligned pairs will be marked as non-preemptable and
> second is ensuring both are not sharing ELSP ports with any other context.
>
> Non-preemptable property will ensure that once the start has been aligned
> the requests remain executing until completion.
>
> Single port ELSP property will ensure there are no possible inversions
> between different independent pairs of aligned requests.
Nak.
> Going forward we can think of introducing new uapi to request this
> behaviour as a separate, more explicit flag, and at that point retire this
> semi-generic special handling.
As CI will say, such behaviour will already need a new flag. Forcing
no-preemption should be a privileged flag, so I would expect some
acknowledge that this is a HW problem that we have to workaround.
> Signed-off-by: Tvrtko Ursulin
> Suggested-by: Xiaogang Li
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_context.h | 2 +-
> drivers/gpu/drm/i915/gt/intel_lrc.c | 46 +
> 2 files changed, 41 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> b/drivers/gpu/drm/i915/gt/intel_context.h
> index 07be021882cc..576d11c0cdd9 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.h
> +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> @@ -212,7 +212,7 @@ intel_context_force_single_submission(const struct
> intel_context *ce)
> static inline void
> intel_context_set_single_submission(struct intel_context *ce)
> {
> - __set_bit(CONTEXT_FORCE_SINGLE_SUBMISSION, >flags);
> + set_bit(CONTEXT_FORCE_SINGLE_SUBMISSION, >flags);
> }
>
> static inline bool
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 3214a4ecc31a..88cf20fd92c8 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -1734,8 +1734,7 @@ static void execlists_submit_ports(struct
> intel_engine_cs *engine)
>
> static bool ctx_single_port_submission(const struct intel_context *ce)
> {
> - return (IS_ENABLED(CONFIG_DRM_I915_GVT) &&
> - intel_context_force_single_submission(ce));
> + return intel_context_force_single_submission(ce);
> }
>
> static bool can_merge_ctx(const struct intel_context *prev,
> @@ -4929,9 +4928,41 @@ static void execlists_park(struct intel_engine_cs
> *engine)
> cancel_timer(>execlists.preempt);
> }
>
> +static void
> +mark_bonded_pair(struct i915_request *rq, struct i915_request *signal)
> +{
> + /*
> +* Give (temporary) special meaning to a pair requests with requested
> +* aligned start along the video engines.
> +*
> +* They should be non-preemptable and have all ELSP ports to
> themselves
> +* to avoid any deadlocks caused by inversions.
This sentence needs expanding, because you are implying that this is an
issue we need to address in the code. If there is a deadlock resulting
from incorrect submission ordering, that is a bug in the code.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Special handling for bonded requests
From: Tvrtko Ursulin
Our generic mechanism for specifying aligned request start,
I915_EXEC_FENCE_SUBMIT, has a bit too relaxed rules when it comes to the
actual use case of media scalability on Tigerlake.
While the submit fence can provide the aligned start, the actual media
pipeline expects that execution remains in lockstep from then onwards.
Otherwise the hardware cannot handle well one of the pair getting
preempted leading to GPU hangs and corrupted media playback.
This puts us in a difficult position where the only visible solution,
which does not involve adding new uapi, is to give more meaning to the
generic submit fence. At least when used between the video engines.
The special semantics this patch applies in that case are two fold. First
is that both of the aligned pairs will be marked as non-preemptable and
second is ensuring both are not sharing ELSP ports with any other context.
Non-preemptable property will ensure that once the start has been aligned
the requests remain executing until completion.
Single port ELSP property will ensure there are no possible inversions
between different independent pairs of aligned requests.
Going forward we can think of introducing new uapi to request this
behaviour as a separate, more explicit flag, and at that point retire this
semi-generic special handling.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Xiaogang Li
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.h | 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 46 +
2 files changed, 41 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 07be021882cc..576d11c0cdd9 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -212,7 +212,7 @@ intel_context_force_single_submission(const struct
intel_context *ce)
static inline void
intel_context_set_single_submission(struct intel_context *ce)
{
- __set_bit(CONTEXT_FORCE_SINGLE_SUBMISSION, >flags);
+ set_bit(CONTEXT_FORCE_SINGLE_SUBMISSION, >flags);
}
static inline bool
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 3214a4ecc31a..88cf20fd92c8 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1734,8 +1734,7 @@ static void execlists_submit_ports(struct intel_engine_cs
*engine)
static bool ctx_single_port_submission(const struct intel_context *ce)
{
- return (IS_ENABLED(CONFIG_DRM_I915_GVT) &&
- intel_context_force_single_submission(ce));
+ return intel_context_force_single_submission(ce);
}
static bool can_merge_ctx(const struct intel_context *prev,
@@ -4929,9 +4928,41 @@ static void execlists_park(struct intel_engine_cs
*engine)
cancel_timer(>execlists.preempt);
}
+static void
+mark_bonded_pair(struct i915_request *rq, struct i915_request *signal)
+{
+ /*
+* Give (temporary) special meaning to a pair requests with requested
+* aligned start along the video engines.
+*
+* They should be non-preemptable and have all ELSP ports to themselves
+* to avoid any deadlocks caused by inversions.
+*
+* Gen11+
+*/
+ if (INTEL_GEN(rq->i915) < 11 ||
+ rq->engine->class != VIDEO_DECODE_CLASS ||
+ rq->engine->class != signal->engine->class)
+ return;
+
+ set_bit(I915_FENCE_FLAG_NOPREEMPT, >fence.flags);
+ set_bit(I915_FENCE_FLAG_NOPREEMPT, >fence.flags);
+
+ intel_context_set_single_submission(rq->context);
+ intel_context_set_single_submission(signal->context);
+}
+
+static void
+execlists_bond_execute(struct i915_request *rq, struct dma_fence *signal)
+{
+ mark_bonded_pair(rq, to_request(signal));
+}
+
void intel_execlists_set_default_submission(struct intel_engine_cs *engine)
{
engine->submit_request = execlists_submit_request;
+ if (engine->class == VIDEO_DECODE_CLASS)
+ engine->bond_execute = execlists_bond_execute;
engine->schedule = i915_schedule;
engine->execlists.tasklet.func = execlists_submission_tasklet;
@@ -5602,15 +5633,18 @@ virtual_find_bond(struct virtual_engine *ve,
}
static void
-virtual_bond_execute(struct i915_request *rq, struct dma_fence *signal)
+virtual_bond_execute(struct i915_request *rq, struct dma_fence *sigfence)
{
struct virtual_engine *ve = to_virtual_engine(rq->engine);
+ struct i915_request *signal = to_request(sigfence);
intel_engine_mask_t allowed, exec;
struct ve_bond *bond;
- allowed = ~to_request(signal)->engine->mask;
+ mark_bonded_pair(rq, signal);
+
+ allowed = ~signal->engine->mask;
- bond = virtual_find_bond(ve, to_request(signal)->engine);
+ bond = virtual_find_bond(ve, signal->engine);
if (bond)
allowed &= bond->sibling_mask;
@@
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Fix early deref of 'dsb'
== Series Details ==
Series: drm/i915/display: Fix early deref of 'dsb'
URL : https://patchwork.freedesktop.org/series/77617/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8529_full -> Patchwork_17766_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_17766_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_big_fb@x-tiled-64bpp-rotate-0:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#1119] / [i915#118] /
[i915#95])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8529/shard-glk1/igt@kms_big...@x-tiled-64bpp-rotate-0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17766/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-0.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +3 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8529/shard-kbl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17766/shard-kbl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html
* igt@kms_cursor_legacy@cursorb-vs-flipa-toggle:
- shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#1926])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8529/shard-glk9/igt@kms_cursor_leg...@cursorb-vs-flipa-toggle.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17766/shard-glk6/igt@kms_cursor_leg...@cursorb-vs-flipa-toggle.html
* igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-untiled:
- shard-skl: [PASS][7] -> [FAIL][8] ([i915#52] / [i915#54])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8529/shard-skl3/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-untiled.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17766/shard-skl2/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-untiled.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#165])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8529/shard-kbl1/igt@kms_fbcon_...@fbc-suspend.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17766/shard-kbl3/igt@kms_fbcon_...@fbc-suspend.html
* igt@kms_hdr@bpc-switch-dpms:
- shard-skl: [PASS][11] -> [FAIL][12] ([i915#1188])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8529/shard-skl2/igt@kms_...@bpc-switch-dpms.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17766/shard-skl10/igt@kms_...@bpc-switch-dpms.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- shard-kbl: [PASS][13] -> [INCOMPLETE][14] ([i915#155])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8529/shard-kbl6/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-c.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17766/shard-kbl1/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-c.html
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145] / [i915#265])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8529/shard-skl3/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17766/shard-skl2/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html
* igt@kms_psr@psr2_primary_mmap_cpu:
- shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +2 similar
issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8529/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17766/shard-iclb4/igt@kms_psr@psr2_primary_mmap_cpu.html
* igt@kms_vblank@pipe-b-ts-continuation-suspend:
- shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +2
similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8529/shard-apl2/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17766/shard-apl1/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html
Possible fixes
* {igt@gem_ctx_isolation@preservation-s3@bcs0}:
- shard-kbl: [DMESG-WARN][21] ([i915#180]) -> [PASS][22] +1
similar issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8529/shard-kbl7/igt@gem_ctx_isolation@preservation...@bcs0.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17766/shard-kbl1/igt@gem_ctx_isolation@preservation...@bcs0.html
* igt@gem_ctx_persistence@processes:
- shard-skl: [FAIL][23] ([i915#1528]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8529/shard-skl8/igt@gem_ctx_persiste...@processes.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17766/shard-skl10/igt@gem_ctx_persiste...@processes.html
* igt@kms_cursor_legacy@cursora-vs-flipb-toggle:
- shard-glk:
[Intel-gfx] [PULL] drm-misc-next-fixes
Hi Dave and Daniel, here's the pull request for the current drm-misc-next-fixes. Best regards Thomas drm-misc-next-fixes-2020-05-27: Short summary of fixes pull (less than what git shortlog provides): There's a fix for panel brighness on Lenovo X13 Yoga devices and a fix for -Wformat warnings on architectures where atomic-64 counters are not of type unsigned long long. The following changes since commit 152cce0006abf7e17dfb7dc94896b044bda4e588: drm/bridge: analogix_dp: Split bind() into probe() and real bind() (2020-04-09 10:29:35 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2020-05-27 for you to fetch changes up to 6f27e4c287d7bdcad1f24efcaace044617aac2f3: drm/vblank: Fix -Wformat compile warnings on some arches (2020-05-22 14:22:00 -0400) Short summary of fixes pull (less than what git shortlog provides): There's a fix for panel brighness on Lenovo X13 Yoga devices and a fix for -Wformat warnings on architectures where atomic-64 counters are not of type unsigned long long. Lyude Paul (1): drm/vblank: Fix -Wformat compile warnings on some arches Mark Pearson (1): drm/dp: Lenovo X13 Yoga OLED panel brightness fix drivers/gpu/drm/drm_dp_helper.c | 1 + drivers/gpu/drm/drm_vblank.c| 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/gt: Do not schedule normal requests immediately along virtual
On 27/05/2020 08:47, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-05-27 08:32:05)
On 27/05/2020 08:03, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-05-27 07:51:44)
On 26/05/2020 10:07, Chris Wilson wrote:
When we push a virtual request onto the HW, we update the rq->engine to
point to the physical engine. A request that is then submitted by the
user that waits upon the virtual engine, but along the physical engine
in use, will then see that it is due to be submitted to the same engine
and take a shortcut (and be queued without waiting for the completion
fence). However, the virtual request may be preempted (either by higher
priority users, or by timeslicing) and removed from the physical engine
to be migrated over to one of its siblings. The dependent normal request
however is oblivious to the removal of the virtual request and remains
queued to execute on HW, believing that once it reaches the head of its
queue all of its predecessors will have completed executing!
v2: Beware restriction of signal->execution_mask prior to submission.
Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine")
Testcase: igt/gem_exec_balancer/sliced
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: # v5.3+
---
drivers/gpu/drm/i915/i915_request.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 33bbad623e02..0b07ccc7e9bc 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1237,6 +1237,25 @@ i915_request_await_execution(struct i915_request *rq,
return 0;
}
+static int
+await_request_submit(struct i915_request *to, struct i915_request *from)
+{
+ /*
+ * If we are waiting on a virtual engine, then it may be
+ * constrained to execute on a single engine *prior* to submission.
+ * When it is submitted, it will be first submitted to the virtual
+ * engine and then passed to the physical engine. We cannot allow
+ * the waiter to be submitted immediately to the physical engine
+ * as it may then bypass the virtual request.
+ */
+ if (to->engine == READ_ONCE(from->engine))
+ return i915_sw_fence_await_sw_fence_gfp(>submit,
+ >submit,
+ I915_FENCE_GFP);
+ else
+ return __i915_request_await_execution(to, from, NULL);
If I am following correctly this branch will be the virtual <-> physical
or virtual <-> virtual dependency on the same physical engine. Why is
await_execution sufficient in this case? Is there something preventing
timeslicing between the two (not wanted right!) once from start
execution (not finishes).
Timeslicing is only between independent requests. When we expire a
request, we also expire all of its waiters along the same engine, so
that the execution order remains intact.
Via scheduler dependencies - they are enough?
Yes.
Okay, I really need to use this all more often rather than just review..
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/gt: Do not schedule normal requests immediately along virtual
Quoting Tvrtko Ursulin (2020-05-27 08:32:05)
>
> On 27/05/2020 08:03, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-05-27 07:51:44)
> >>
> >> On 26/05/2020 10:07, Chris Wilson wrote:
> >>> When we push a virtual request onto the HW, we update the rq->engine to
> >>> point to the physical engine. A request that is then submitted by the
> >>> user that waits upon the virtual engine, but along the physical engine
> >>> in use, will then see that it is due to be submitted to the same engine
> >>> and take a shortcut (and be queued without waiting for the completion
> >>> fence). However, the virtual request may be preempted (either by higher
> >>> priority users, or by timeslicing) and removed from the physical engine
> >>> to be migrated over to one of its siblings. The dependent normal request
> >>> however is oblivious to the removal of the virtual request and remains
> >>> queued to execute on HW, believing that once it reaches the head of its
> >>> queue all of its predecessors will have completed executing!
> >>>
> >>> v2: Beware restriction of signal->execution_mask prior to submission.
> >>>
> >>> Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine")
> >>> Testcase: igt/gem_exec_balancer/sliced
> >>> Signed-off-by: Chris Wilson
> >>> Cc: Tvrtko Ursulin
> >>> Cc: # v5.3+
> >>> ---
> >>>drivers/gpu/drm/i915/i915_request.c | 25 +
> >>>1 file changed, 21 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_request.c
> >>> b/drivers/gpu/drm/i915/i915_request.c
> >>> index 33bbad623e02..0b07ccc7e9bc 100644
> >>> --- a/drivers/gpu/drm/i915/i915_request.c
> >>> +++ b/drivers/gpu/drm/i915/i915_request.c
> >>> @@ -1237,6 +1237,25 @@ i915_request_await_execution(struct i915_request
> >>> *rq,
> >>>return 0;
> >>>}
> >>>
> >>> +static int
> >>> +await_request_submit(struct i915_request *to, struct i915_request *from)
> >>> +{
> >>> + /*
> >>> + * If we are waiting on a virtual engine, then it may be
> >>> + * constrained to execute on a single engine *prior* to submission.
> >>> + * When it is submitted, it will be first submitted to the virtual
> >>> + * engine and then passed to the physical engine. We cannot allow
> >>> + * the waiter to be submitted immediately to the physical engine
> >>> + * as it may then bypass the virtual request.
> >>> + */
> >>> + if (to->engine == READ_ONCE(from->engine))
> >>> + return i915_sw_fence_await_sw_fence_gfp(>submit,
> >>> + >submit,
> >>> + I915_FENCE_GFP);
> >>> + else
> >>> + return __i915_request_await_execution(to, from, NULL);
> >>
> >> If I am following correctly this branch will be the virtual <-> physical
> >> or virtual <-> virtual dependency on the same physical engine. Why is
> >> await_execution sufficient in this case? Is there something preventing
> >> timeslicing between the two (not wanted right!) once from start
> >> execution (not finishes).
> >
> > Timeslicing is only between independent requests. When we expire a
> > request, we also expire all of its waiters along the same engine, so
> > that the execution order remains intact.
>
> Via scheduler dependencies - they are enough?
Yes.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Reorder await_execution before await_request
On 26/05/2020 10:07, Chris Wilson wrote:
Reorder the code so that we can reuse the await_execution from a special
case in await_request in the next patch.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 264 ++--
1 file changed, 132 insertions(+), 132 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index c282719ad3ac..33bbad623e02 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1053,37 +1053,91 @@ emit_semaphore_wait(struct i915_request *to,
I915_FENCE_GFP);
}
+static bool intel_timeline_sync_has_start(struct intel_timeline *tl,
+ struct dma_fence *fence)
+{
+ return __intel_timeline_sync_is_later(tl,
+ fence->context,
+ fence->seqno - 1);
+}
+
+static int intel_timeline_sync_set_start(struct intel_timeline *tl,
+const struct dma_fence *fence)
+{
+ return __intel_timeline_sync_set(tl, fence->context, fence->seqno - 1);
+}
+
static int
-i915_request_await_request(struct i915_request *to, struct i915_request *from)
+__i915_request_await_execution(struct i915_request *to,
+ struct i915_request *from,
+ void (*hook)(struct i915_request *rq,
+ struct dma_fence *signal))
{
- int ret;
+ int err;
- GEM_BUG_ON(to == from);
- GEM_BUG_ON(to->timeline == from->timeline);
+ GEM_BUG_ON(intel_context_is_barrier(from->context));
- if (i915_request_completed(from)) {
- i915_sw_fence_set_error_once(>submit, from->fence.error);
+ /* Submit both requests at the same time */
+ err = __await_execution(to, from, hook, I915_FENCE_GFP);
+ if (err)
+ return err;
+
+ /* Squash repeated depenendices to the same timelines */
+ if (intel_timeline_sync_has_start(i915_request_timeline(to),
+ >fence))
return 0;
+
+ /*
+* Wait until the start of this request.
+*
+* The execution cb fires when we submit the request to HW. But in
+* many cases this may be long before the request itself is ready to
+* run (consider that we submit 2 requests for the same context, where
+* the request of interest is behind an indefinite spinner). So we hook
+* up to both to reduce our queues and keep the execution lag minimised
+* in the worst case, though we hope that the await_start is elided.
+*/
+ err = i915_request_await_start(to, from);
+ if (err < 0)
+ return err;
+
+ /*
+* Ensure both start together [after all semaphores in signal]
+*
+* Now that we are queued to the HW at roughly the same time (thanks
+* to the execute cb) and are ready to run at roughly the same time
+* (thanks to the await start), our signaler may still be indefinitely
+* delayed by waiting on a semaphore from a remote engine. If our
+* signaler depends on a semaphore, so indirectly do we, and we do not
+* want to start our payload until our signaler also starts theirs.
+* So we wait.
+*
+* However, there is also a second condition for which we need to wait
+* for the precise start of the signaler. Consider that the signaler
+* was submitted in a chain of requests following another context
+* (with just an ordinary intra-engine fence dependency between the
+* two). In this case the signaler is queued to HW, but not for
+* immediate execution, and so we must wait until it reaches the
+* active slot.
+*/
+ if (intel_engine_has_semaphores(to->engine) &&
+ !i915_request_has_initial_breadcrumb(to)) {
+ err = __emit_semaphore_wait(to, from, from->fence.seqno - 1);
+ if (err < 0)
+ return err;
}
+ /* Couple the dependency tree for PI on this exposed to->fence */
if (to->engine->schedule) {
- ret = i915_sched_node_add_dependency(>sched,
+ err = i915_sched_node_add_dependency(>sched,
>sched,
-I915_DEPENDENCY_EXTERNAL);
- if (ret < 0)
- return ret;
+I915_DEPENDENCY_WEAK);
+ if (err < 0)
+ return err;
}
- if (to->engine == from->engine)
- ret = i915_sw_fence_await_sw_fence_gfp(>submit,
- >submit,
-
Re: [Intel-gfx] [PATCH 2/2] drm/i915/gt: Do not schedule normal requests immediately along virtual
On 27/05/2020 08:03, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-05-27 07:51:44)
On 26/05/2020 10:07, Chris Wilson wrote:
When we push a virtual request onto the HW, we update the rq->engine to
point to the physical engine. A request that is then submitted by the
user that waits upon the virtual engine, but along the physical engine
in use, will then see that it is due to be submitted to the same engine
and take a shortcut (and be queued without waiting for the completion
fence). However, the virtual request may be preempted (either by higher
priority users, or by timeslicing) and removed from the physical engine
to be migrated over to one of its siblings. The dependent normal request
however is oblivious to the removal of the virtual request and remains
queued to execute on HW, believing that once it reaches the head of its
queue all of its predecessors will have completed executing!
v2: Beware restriction of signal->execution_mask prior to submission.
Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine")
Testcase: igt/gem_exec_balancer/sliced
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: # v5.3+
---
drivers/gpu/drm/i915/i915_request.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 33bbad623e02..0b07ccc7e9bc 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1237,6 +1237,25 @@ i915_request_await_execution(struct i915_request *rq,
return 0;
}
+static int
+await_request_submit(struct i915_request *to, struct i915_request *from)
+{
+ /*
+ * If we are waiting on a virtual engine, then it may be
+ * constrained to execute on a single engine *prior* to submission.
+ * When it is submitted, it will be first submitted to the virtual
+ * engine and then passed to the physical engine. We cannot allow
+ * the waiter to be submitted immediately to the physical engine
+ * as it may then bypass the virtual request.
+ */
+ if (to->engine == READ_ONCE(from->engine))
+ return i915_sw_fence_await_sw_fence_gfp(>submit,
+ >submit,
+ I915_FENCE_GFP);
+ else
+ return __i915_request_await_execution(to, from, NULL);
If I am following correctly this branch will be the virtual <-> physical
or virtual <-> virtual dependency on the same physical engine. Why is
await_execution sufficient in this case? Is there something preventing
timeslicing between the two (not wanted right!) once from start
execution (not finishes).
Timeslicing is only between independent requests. When we expire a
request, we also expire all of its waiters along the same engine, so
that the execution order remains intact.
Via scheduler dependencies - they are enough?
Regards,
Tvrtko
await_execution is a more restrictive form of the
await_sw_fence(submit), in that 'to' can only be submitted once 'from'
reaches HW and not simply once 'from' reaches its engine submission
queue.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
