Re: [Intel-gfx] [PATCH 06/12] dma-buf: Proxy fence, an unsignaled fence placeholder
Hi Chris, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm-tip/drm-tip] [cannot apply to drm-intel/for-linux-next linus/master v5.7-rc7 next-20200529] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-gt-Stop-cross-polluting-PIN_GLOBAL-with-PIN_USER-with-no-ppgtt/20200525-160038 base: git://anongit.freedesktop.org/drm/drm-tip drm-tip compiler: gcc-9 (Debian 9.3.0-13) 9.3.0 If you fix the issue, kindly add following tag as appropriate Reported-by: kbuild test robot cppcheck warnings: (new ones prefixed by >>) >> drivers/dma-buf/st-dma-fence-proxy.c:127:6: warning: Variable 'err' is >> reassigned a value before the old one has been used. [redundantAssignment] err = 0; ^ drivers/dma-buf/st-dma-fence-proxy.c:109:0: note: Variable 'err' is reassigned a value before the old one has been used. int err = -EINVAL; ^ drivers/dma-buf/st-dma-fence-proxy.c:127:6: note: Variable 'err' is reassigned a value before the old one has been used. err = 0; ^ drivers/dma-buf/st-dma-fence-proxy.c:146:6: warning: Variable 'err' is reassigned a value before the old one has been used. [redundantAssignment] err = 0; ^ drivers/dma-buf/st-dma-fence-proxy.c:136:0: note: Variable 'err' is reassigned a value before the old one has been used. int err = -EINVAL; ^ drivers/dma-buf/st-dma-fence-proxy.c:146:6: note: Variable 'err' is reassigned a value before the old one has been used. err = 0; ^ drivers/dma-buf/st-dma-fence-proxy.c:175:6: warning: Variable 'err' is reassigned a value before the old one has been used. [redundantAssignment] err = 0; ^ drivers/dma-buf/st-dma-fence-proxy.c:155:0: note: Variable 'err' is reassigned a value before the old one has been used. int err = -EINVAL; ^ drivers/dma-buf/st-dma-fence-proxy.c:175:6: note: Variable 'err' is reassigned a value before the old one has been used. err = 0; ^ drivers/dma-buf/st-dma-fence-proxy.c:217:6: warning: Variable 'err' is reassigned a value before the old one has been used. [redundantAssignment] err = 0; ^ drivers/dma-buf/st-dma-fence-proxy.c:185:0: note: Variable 'err' is reassigned a value before the old one has been used. int err = -EINVAL; ^ drivers/dma-buf/st-dma-fence-proxy.c:217:6: note: Variable 'err' is reassigned a value before the old one has been used. err = 0; ^ drivers/dma-buf/st-dma-fence-proxy.c:254:6: warning: Variable 'err' is reassigned a value before the old one has been used. [redundantAssignment] err = 0; ^ drivers/dma-buf/st-dma-fence-proxy.c:238:0: note: Variable 'err' is reassigned a value before the old one has been used. int err = -EINVAL; ^ drivers/dma-buf/st-dma-fence-proxy.c:254:6: note: Variable 'err' is reassigned a value before the old one has been used. err = 0; ^ drivers/dma-buf/st-dma-fence-proxy.c:293:6: warning: Variable 'err' is reassigned a value before the old one has been used. [redundantAssignment] err = 0; ^ drivers/dma-buf/st-dma-fence-proxy.c:265:0: note: Variable 'err' is reassigned a value before the old one has been used. int err = -EINVAL; ^ drivers/dma-buf/st-dma-fence-proxy.c:293:6: note: Variable 'err' is reassigned a value before the old one has been used. err = 0; ^ drivers/dma-buf/st-dma-fence-proxy.c:321:6: warning: Variable 'err' is reassigned a value before the old one has been used. [redundantAssignment] err = 0; ^ drivers/dma-buf/st-dma-fence-proxy.c:303:0: note: Variable 'err' is reassigned a value before the old one has been used. int err = -EINVAL; ^ drivers/dma-buf/st-dma-fence-proxy.c:321:6: note: Variable 'err' is reassigned a value before the old one has been used. err = 0; ^ drivers/dma-buf/st-dma-fence-proxy.c:348:6: warning: Variable 'err' is reassigned a value before the old one has been used. [redundantAssignment] err = 0; ^ drivers/dma-buf/st-dma-fence-proxy.c:331:0: note: Variable 'err' is reassigned a value before the old one has been used. int err = -EINVAL; ^ drivers/dma-buf/st-dma-fence-proxy.c:348:6: note: Variable 'err' is reassigned a value before the old one has been used. err = 0; ^ drivers/dma-buf/st-dma-fence-proxy.c:377:6: warning: Variable 'err' is reassigned a value before the old one has been used. [redundantAssignment] err = 0; ^ drivers/dma-buf/st-dma-fence-proxy.c:358:0: note: Variable 'err' is reassigned a value before the old one has been used. int err = -EINVAL; ^ drivers/dma-buf/st-dma-fence-p
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: Update TC DP vswing table
== Series Details == Series: drm/i915/tgl: Update TC DP vswing table URL : https://patchwork.freedesktop.org/series/77806/ State : success == Summary == CI Bug Log - changes from CI_DRM_8557_full -> Patchwork_17824_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17824_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-kbl3/igt@gem_exec_susp...@basic-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-kbl7/igt@gem_exec_susp...@basic-s3.html * igt@i915_suspend@debugfs-reader: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-apl1/igt@i915_susp...@debugfs-reader.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-apl4/igt@i915_susp...@debugfs-reader.html * igt@i915_suspend@fence-restore-untiled: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#180] / [i915#93] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-kbl7/igt@i915_susp...@fence-restore-untiled.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-kbl6/igt@i915_susp...@fence-restore-untiled.html * igt@i915_suspend@forcewake: - shard-kbl: [PASS][7] -> [INCOMPLETE][8] ([i915#155]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-kbl7/igt@i915_susp...@forcewake.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-kbl3/igt@i915_susp...@forcewake.html * igt@kms_color@pipe-c-legacy-gamma: - shard-hsw: [PASS][9] -> [INCOMPLETE][10] ([i915#61]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-hsw1/igt@kms_co...@pipe-c-legacy-gamma.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-hsw6/igt@kms_co...@pipe-c-legacy-gamma.html * igt@kms_cursor_crc@pipe-b-cursor-256x85-sliding: - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#54]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-kbl6/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-kbl1/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html - shard-skl: [PASS][13] -> [FAIL][14] ([i915#54]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-skl1/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-skl6/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html - shard-apl: [PASS][15] -> [FAIL][16] ([i915#54]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-apl1/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-apl4/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#1188]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-skl9/igt@kms_...@bpc-switch-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-skl7/igt@kms_...@bpc-switch-suspend.html * igt@kms_psr@psr2_sprite_mmap_cpu: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_cpu.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-iclb1/igt@kms_psr@psr2_sprite_mmap_cpu.html Possible fixes * igt@gem_ctx_persistence@legacy-engines-mixed-process@blt: - shard-skl: [FAIL][21] ([i915#1528]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-skl6/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-skl4/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html * igt@gem_softpin@noreloc-s3: - shard-apl: [DMESG-WARN][23] ([i915#180]) -> [PASS][24] +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-apl4/igt@gem_soft...@noreloc-s3.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-apl2/igt@gem_soft...@noreloc-s3.html * igt@gem_vm_create@isolation: - shard-apl: [TIMEOUT][25] ([i915#1635]) -> [PASS][26] +3 similar issues [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-apl7/igt@gem_vm_cre...@isolation.html [26]:
Re: [Intel-gfx] [PATCH] drm/atomic-helper: reset vblank on crtc reset
Hi Daniel,
Thank you for the patch.
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().
Have you intentionally not touched drivers that use
drm_crtc_vblank_off() at init time instead of drm_crtc_vblank_reset() ?
I'm thinking about omapdrm and rcar-du that both call neither
drm_crtc_vblank_reset() nor __drm_atomic_helper_crtc_reset() in their
CRTC reset handler, and call drm_crtc_vblank_off() at init time. Should
these (and likely other) drivers be updated ?
Other than that the patch looks good to me,
Reviewed-by: Laurent Pinchart
> 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 =
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [RFC,1/1] drm/mm: add ig_frag selftest
== Series Details ==
Series: series starting with [RFC,1/1] drm/mm: add ig_frag selftest
URL : https://patchwork.freedesktop.org/series/77803/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8556_full -> Patchwork_17823_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_17823_full:
### IGT changes ###
Possible regressions
* {igt@drm_mm@all@frag} (NEW):
- shard-apl: NOTRUN -> [DMESG-FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17823/shard-apl3/igt@drm_mm@a...@frag.html
- shard-tglb: NOTRUN -> [DMESG-FAIL][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17823/shard-tglb1/igt@drm_mm@a...@frag.html
- shard-glk: NOTRUN -> [DMESG-FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17823/shard-glk8/igt@drm_mm@a...@frag.html
New tests
-
New tests have been introduced between CI_DRM_8556_full and
Patchwork_17823_full:
### New IGT tests (1) ###
* igt@drm_mm@all@frag:
- Statuses : 3 dmesg-fail(s) 4 pass(s)
- Exec time: [2.53, 33.41] s
Known issues
Here are the changes found in Patchwork_17823_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- shard-kbl: [PASS][4] -> [DMESG-WARN][5] ([i915#180]) +3 similar
issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8556/shard-kbl7/igt@gem_exec_susp...@basic-s3.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17823/shard-kbl6/igt@gem_exec_susp...@basic-s3.html
* igt@gen9_exec_parse@allowed-all:
- shard-apl: [PASS][6] -> [DMESG-WARN][7] ([i915#1436] /
[i915#716])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8556/shard-apl3/igt@gen9_exec_pa...@allowed-all.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17823/shard-apl6/igt@gen9_exec_pa...@allowed-all.html
* igt@kms_cursor_crc@pipe-b-cursor-256x85-sliding:
- shard-kbl: [PASS][8] -> [FAIL][9] ([i915#54])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8556/shard-kbl2/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17823/shard-kbl4/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
- shard-skl: [PASS][10] -> [FAIL][11] ([i915#54])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8556/shard-skl2/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17823/shard-skl4/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
- shard-apl: [PASS][12] -> [FAIL][13] ([i915#54])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8556/shard-apl7/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17823/shard-apl6/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-apl: [PASS][14] -> [DMESG-WARN][15] ([i915#180]) +1
similar issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8556/shard-apl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17823/shard-apl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html
* igt@kms_cursor_legacy@flip-vs-cursor-crc-atomic:
- shard-kbl: [PASS][16] -> [FAIL][17] ([i915#1566] / [i915#93] /
[i915#95])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8556/shard-kbl4/igt@kms_cursor_leg...@flip-vs-cursor-crc-atomic.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17823/shard-kbl3/igt@kms_cursor_leg...@flip-vs-cursor-crc-atomic.html
* igt@kms_cursor_legacy@pipe-d-torture-bo:
- shard-tglb: [PASS][18] -> [DMESG-WARN][19] ([i915#128])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8556/shard-tglb5/igt@kms_cursor_leg...@pipe-d-torture-bo.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17823/shard-tglb7/igt@kms_cursor_leg...@pipe-d-torture-bo.html
* igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: [PASS][20] -> [SKIP][21] ([fdo#109441]) +3 similar
issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8556/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17823/shard-iclb7/igt@kms_psr@psr2_primary_page_flip.html
Possible fixes
* {igt@gem_exec_reloc@basic-concurrent0}:
- shard-glk: [FAIL][22] ([i915#1930]) -> [PASS][23]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8556/shard-glk6/igt@gem_exec_re...@basic-concurrent0.html
[23]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for compact-test-array
== Series Details ==
Series: compact-test-array
URL : https://patchwork.freedesktop.org/series/77802/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8556_full -> Patchwork_17822_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17822_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17822_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_17822_full:
### IGT changes ###
Possible regressions
* igt@kms_cursor_crc@pipe-b-cursor-alpha-opaque:
- shard-hsw: NOTRUN -> [DMESG-WARN][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17822/shard-hsw6/igt@kms_cursor_...@pipe-b-cursor-alpha-opaque.html
Known issues
Here are the changes found in Patchwork_17822_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_big_fb@x-tiled-64bpp-rotate-0:
- shard-glk: [PASS][2] -> [FAIL][3] ([i915#1119] / [i915#118] /
[i915#95]) +1 similar issue
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8556/shard-glk4/igt@kms_big...@x-tiled-64bpp-rotate-0.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17822/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-0.html
* igt@kms_cursor_crc@pipe-b-cursor-256x85-sliding:
- shard-kbl: [PASS][4] -> [FAIL][5] ([i915#54])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8556/shard-kbl2/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17822/shard-kbl1/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
- shard-skl: [PASS][6] -> [FAIL][7] ([i915#54])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8556/shard-skl2/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17822/shard-skl7/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
- shard-apl: [PASS][8] -> [FAIL][9] ([i915#54])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8556/shard-apl7/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17822/shard-apl8/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-kbl: [PASS][10] -> [DMESG-WARN][11] ([i915#180]) +1
similar issue
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8556/shard-kbl6/igt@kms_cursor_...@pipe-c-cursor-suspend.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17822/shard-kbl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
- shard-glk: [PASS][12] -> [FAIL][13] ([i915#72])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8556/shard-glk9/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17822/shard-glk4/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html
* igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-kbl: [PASS][14] -> [DMESG-WARN][15] ([i915#180] /
[i915#93] / [i915#95])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8556/shard-kbl3/igt@kms_frontbuffer_track...@fbc-suspend.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17822/shard-kbl6/igt@kms_frontbuffer_track...@fbc-suspend.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- shard-apl: [PASS][16] -> [DMESG-WARN][17] ([i915#180]) +1
similar issue
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8556/shard-apl3/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17822/shard-apl4/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [PASS][18] -> [FAIL][19] ([fdo#108145] / [i915#265])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8556/shard-skl5/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17822/shard-skl3/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
* igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: [PASS][20] -> [SKIP][21] ([fdo#109441]) +3 similar
issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8556/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17822/shard-iclb7/igt@kms_psr@psr2_primary_page_flip.html
Possible fixes
* {igt@gem_exec_reloc@basic-concurrent0}:
- shard-glk: [FAIL][22]
[Intel-gfx] ✗ Fi.CI.BUILD: failure for sna/uxa: add drm modes for no-GTF pannels
== Series Details == Series: sna/uxa: add drm modes for no-GTF pannels URL : https://patchwork.freedesktop.org/series/77808/ State : failure == Summary == Applying: sna/uxa: add drm modes for no-GTF pannels error: sha1 information is lacking or useless (src/sna/sna_display.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 sna/uxa: add drm modes for no-GTF pannels 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 xf86-video-intel] sna/uxa: add drm modes for no-GTF pannels
EDID1.4 replaced GTF Bit with Continuous or Non-Continuous Frequency
Display.
SNA still check this bit as GTF support, only defined modes in EDID
will be set.
Correct the GTF support check, then add more modes.
Note, gtf_supported must be included in xserver.
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/421
BugLink: https://gitlab.freedesktop.org/drm/intel/issues/313
Signed-off-by: Aaron Ma
---
src/sna/sna_display.c | 2 +-
src/uxa/intel_display.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 874292bc..16ecd353 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -4325,7 +4325,7 @@ sna_output_add_default_modes(xf86OutputPtr output,
DisplayModePtr modes)
int max_x = 0, max_y = 0, max_clock = 0;
float max_vrefresh = 0.0;
- if (mon && GTF_SUPPORTED(mon->features.msc))
+ if (mon && gtf_supported(mon))
return modes;
for (m = modes; m; m = m->next) {
diff --git a/src/uxa/intel_display.c b/src/uxa/intel_display.c
index ba4b8d87..2490db84 100644
--- a/src/uxa/intel_display.c
+++ b/src/uxa/intel_display.c
@@ -915,7 +915,7 @@ intel_output_panel_edid(xf86OutputPtr output,
DisplayModePtr modes)
{
xf86MonPtr mon = output->MonInfo;
- if (!mon || !GTF_SUPPORTED(mon->features.msc)) {
+ if (!mon || !gtf_supported(mon)) {
DisplayModePtr i, m, p = NULL;
int max_x = 0, max_y = 0;
float max_vrefresh = 0.0;
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/7] drm/i915: Fix ivb cpu edp vswing
On Tue, 2020-05-12 at 20:41 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> According to the DP spec supporting vswing 1 + preemph 2 is
> mandatory. We don't have the hw settings for that though. In
> order to pretend to follow the DP spec let's just select
> vswing 0 + preemph 2 in this case (the DP spec says to use
> the requested preemph in preference to the vswing when the
> requested values aren't supported).
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 13 +
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 0924e041e1bf..4952918d0904 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3960,8 +3960,6 @@ intel_dp_voltage_max(struct intel_dp *intel_dp)
> else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv) ||
>(HAS_PCH_SPLIT(dev_priv) && port != PORT_A))
> return DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
> - else if (IS_IVYBRIDGE(dev_priv) && port == PORT_A)
> - return DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
> else
> return DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
> }
> @@ -3988,16 +3986,6 @@ intel_dp_pre_emphasis_max(struct intel_dp *intel_dp,
> u8 voltage_swing)
> default:
> return DP_TRAIN_PRE_EMPH_LEVEL_0;
> }
> - } else if (IS_IVYBRIDGE(dev_priv) && port == PORT_A) {
> - switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
> - case DP_TRAIN_VOLTAGE_SWING_LEVEL_0:
> - return DP_TRAIN_PRE_EMPH_LEVEL_2;
> - case DP_TRAIN_VOLTAGE_SWING_LEVEL_1:
> - case DP_TRAIN_VOLTAGE_SWING_LEVEL_2:
> - return DP_TRAIN_PRE_EMPH_LEVEL_1;
> - default:
> - return DP_TRAIN_PRE_EMPH_LEVEL_0;
> - }
> } else {
> switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
> case DP_TRAIN_VOLTAGE_SWING_LEVEL_0:
> @@ -4293,6 +4281,7 @@ static u32 ivb_cpu_edp_signal_levels(u8 train_set)
> case DP_TRAIN_VOLTAGE_SWING_LEVEL_0 | DP_TRAIN_PRE_EMPH_LEVEL_1:
> return EDP_LINK_TRAIN_400MV_3_5DB_IVB;
> case DP_TRAIN_VOLTAGE_SWING_LEVEL_0 | DP_TRAIN_PRE_EMPH_LEVEL_2:
> + case DP_TRAIN_VOLTAGE_SWING_LEVEL_1 | DP_TRAIN_PRE_EMPH_LEVEL_2:
> return EDP_LINK_TRAIN_400MV_6DB_IVB;
>
> case DP_TRAIN_VOLTAGE_SWING_LEVEL_1 | DP_TRAIN_PRE_EMPH_LEVEL_0:
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Fix cpt/ppt max pre-emphasis
On Tue, 2020-05-12 at 20:41 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> cpt/ppt support pre-emphasis level 3. Let's actually declare
> support for it, instead of clamping things to level 2.
>
> Also tweak the if-ladder in intel_dp_voltage_max() to match
> intel_dp_pre_emphasis_max() to make it easier to compare them.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 67723dede1d1..7541264ff4e9 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3957,12 +3957,11 @@ intel_dp_voltage_max(struct intel_dp *intel_dp)
>
> if (HAS_DDI(dev_priv))
> return intel_ddi_dp_voltage_max(encoder);
> - else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> + else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv) ||
> + (HAS_PCH_CPT(dev_priv) && port != PORT_A))
> return DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
> else if (IS_IVYBRIDGE(dev_priv) && port == PORT_A)
> return DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
> - else if (HAS_PCH_CPT(dev_priv) && port != PORT_A)
> - return DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
> else
> return DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
> }
> @@ -3976,7 +3975,8 @@ intel_dp_pre_emphasis_max(struct intel_dp *intel_dp, u8
> voltage_swing)
>
> if (HAS_DDI(dev_priv)) {
> return intel_ddi_dp_pre_emphasis_max(encoder, voltage_swing);
> - } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> + } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv) ||
> +(HAS_PCH_CPT(dev_priv) && port != PORT_A)) {
Matches intel_dp_voltage_max().
> switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
> case DP_TRAIN_VOLTAGE_SWING_LEVEL_0:
> return DP_TRAIN_PRE_EMPH_LEVEL_3;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Update TC DP vswing table
On Fri, 2020-05-29 at 16:27 -0700, José Roberto de Souza wrote:
> Small updates in dkl_de_emphasis_control field.
>
> BSpec: 49292
> Signed-off-by: José Roberto de Souza
> ---
> 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 aa22465bb56e..cd211f48c401 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -639,11 +639,11 @@ struct tgl_dkl_phy_ddi_buf_trans {
> static const struct tgl_dkl_phy_ddi_buf_trans
> tgl_dkl_phy_dp_ddi_trans[] = {
> /* VS pre-emp Non-trans mVPre-
> emph dB */
> { 0x7, 0x0, 0x00 }, /* 00 400mV 0 dB
> */
> - { 0x5, 0x0, 0x03 }, /* 01 400mV 3.5
> dB */
> - { 0x2, 0x0, 0x0b }, /* 02 400mV 6 dB
> */
> + { 0x5, 0x0, 0x05 }, /* 01 400mV 3.5
> dB */
> + { 0x2, 0x0, 0x0B }, /* 02 400mV 6 dB
> */
> { 0x0, 0x0, 0x19 }, /* 03 400mV 9.5
> dB */
> { 0x5, 0x0, 0x00 }, /* 10 600mV 0 dB
> */
> - { 0x2, 0x0, 0x03 }, /* 11 600mV 3.5
> dB */
> + { 0x2, 0x0, 0x08 }, /* 11 600mV 3.5
> dB */
> { 0x0, 0x0, 0x14 }, /* 12 600mV 6 dB
> */
> { 0x2, 0x0, 0x00 }, /* 20 800mV 0 dB
> */
> { 0x0, 0x0, 0x0B }, /* 21 800mV 3.5
> dB */
Reviewed-by: Khaled Almahallawy
Thanks
Khaled
___
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/tgl: Update TC DP vswing table
== Series Details == Series: drm/i915/tgl: Update TC DP vswing table URL : https://patchwork.freedesktop.org/series/77806/ State : success == Summary == CI Bug Log - changes from CI_DRM_8557 -> Patchwork_17824 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/index.html Changes --- No changes found Participating hosts (50 -> 44) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8557 -> Patchwork_17824 CI-20190529: 20190529 CI_DRM_8557: cd02c2938ef1c5e2ca72b8240918151060dfbf92 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5684: bd399f5eb8263bb4a84ae6a5bb1a13d329e0515d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17824: 345dd71a89fb0aefcf50fb1c225825ee3cf3cf76 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 345dd71a89fb drm/i915/tgl: Update TC DP vswing table == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/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: Fix wrong CDCLK adjustment changes
On Tue, May 26, 2020 at 12:48:52PM +0300, Stanislav Lisovskiy wrote:
> Previous patch didn't take into account all pipes
> but only those in state, which could cause wrong
> CDCLK conclcusions and calculations.
> Also there was a severe issue with min_cdclk being
> assigned to 0 every compare cycle.
>
> Too bad this was found by me only after merge.
> This could be also causing the issues in test, however
> not clear - anyway marking this as fixing the
> "Adjust CDCLK accordingly to our DBuf bw needs".
>
> Signed-off-by: Stanislav Lisovskiy
> Fixes: cd1915460861 ("Adjust CDCLK accordingly to our DBuf bw needs")
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 51
> drivers/gpu/drm/i915/display/intel_cdclk.c | 19 +---
> drivers/gpu/drm/i915/display/intel_display.c | 26 +-
> 3 files changed, 53 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index a79bd7aeb03b..8096138abecc 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -437,6 +437,7 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state
> *state)
> struct intel_crtc *crtc;
> int max_bw = 0;
> int slice_id;
> + enum pipe pipe;
> int i;
>
> for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
> @@ -447,7 +448,9 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state
> *state)
> if (IS_ERR(new_bw_state))
> return PTR_ERR(new_bw_state);
>
> - crtc_bw = _bw_state->dbuf_bw[crtc->pipe];
> + old_bw_state = intel_atomic_get_old_bw_state(state);
> +
> + crtc_bw = _bw_state->dbuf_bw[pipe];
>
> memset(_bw->used_bw, 0, sizeof(crtc_bw->used_bw));
>
> @@ -478,6 +481,15 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state
> *state)
> for_each_dbuf_slice_in_mask(slice_id, dbuf_mask)
> crtc_bw->used_bw[slice_id] += data_rate;
> }
> + }
> +
> + if (!old_bw_state)
> + return 0;
> +
> + for_each_pipe(dev_priv, pipe) {
> + struct intel_dbuf_bw *crtc_bw;
> +
So the condition !old_bw_state() will make sure we loop through
only the active pipes and compute crtc_bw only for those right?
Manasi
> + crtc_bw = _bw_state->dbuf_bw[pipe];
>
> for_each_dbuf_slice(slice_id) {
> /*
> @@ -490,14 +502,9 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state
> *state)
>*/
> max_bw += crtc_bw->used_bw[slice_id];
> }
> -
> - new_bw_state->min_cdclk = max_bw / 64;
> -
> - old_bw_state = intel_atomic_get_old_bw_state(state);
> }
>
> - if (!old_bw_state)
> - return 0;
> + new_bw_state->min_cdclk = max_bw / 64;
>
> if (new_bw_state->min_cdclk != old_bw_state->min_cdclk) {
> int ret = intel_atomic_lock_global_state(_bw_state->base);
> @@ -511,34 +518,38 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state
> *state)
>
> int intel_bw_calc_min_cdclk(struct intel_atomic_state *state)
> {
> - int i;
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + struct intel_bw_state *new_bw_state = NULL;
> + struct intel_bw_state *old_bw_state = NULL;
> const struct intel_crtc_state *crtc_state;
> struct intel_crtc *crtc;
> int min_cdclk = 0;
> - struct intel_bw_state *new_bw_state = NULL;
> - struct intel_bw_state *old_bw_state = NULL;
> + enum pipe pipe;
> + int i;
>
> for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
> - struct intel_cdclk_state *cdclk_state;
> -
> new_bw_state = intel_atomic_get_bw_state(state);
> if (IS_ERR(new_bw_state))
> return PTR_ERR(new_bw_state);
>
> - cdclk_state = intel_atomic_get_cdclk_state(state);
> - if (IS_ERR(cdclk_state))
> - return PTR_ERR(cdclk_state);
> -
> - min_cdclk = max(cdclk_state->min_cdclk[crtc->pipe], min_cdclk);
> -
> - new_bw_state->min_cdclk = min_cdclk;
> -
> old_bw_state = intel_atomic_get_old_bw_state(state);
> }
>
> if (!old_bw_state)
> return 0;
>
> + for_each_pipe(dev_priv, pipe) {
> + struct intel_cdclk_state *cdclk_state;
> +
> + cdclk_state = intel_atomic_get_new_cdclk_state(state);
> + if (!cdclk_state)
> + return 0;
> +
> + min_cdclk = max(cdclk_state->min_cdclk[pipe], min_cdclk);
> + }
> +
> + new_bw_state->min_cdclk = min_cdclk;
> +
> if (new_bw_state->min_cdclk != old_bw_state->min_cdclk) {
> int ret = intel_atomic_lock_global_state(_bw_state->base);
>
> diff --git
[Intel-gfx] [PATCH] drm/i915/tgl: Update TC DP vswing table
Small updates in dkl_de_emphasis_control field.
BSpec: 49292
Signed-off-by: José Roberto de Souza
---
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 aa22465bb56e..cd211f48c401 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -639,11 +639,11 @@ struct tgl_dkl_phy_ddi_buf_trans {
static const struct tgl_dkl_phy_ddi_buf_trans tgl_dkl_phy_dp_ddi_trans[] = {
/* VS pre-emp Non-trans mVPre-emph dB */
{ 0x7, 0x0, 0x00 }, /* 00 400mV 0 dB */
- { 0x5, 0x0, 0x03 }, /* 01 400mV 3.5 dB */
- { 0x2, 0x0, 0x0b }, /* 02 400mV 6 dB */
+ { 0x5, 0x0, 0x05 }, /* 01 400mV 3.5 dB */
+ { 0x2, 0x0, 0x0B }, /* 02 400mV 6 dB */
{ 0x0, 0x0, 0x19 }, /* 03 400mV 9.5 dB */
{ 0x5, 0x0, 0x00 }, /* 10 600mV 0 dB */
- { 0x2, 0x0, 0x03 }, /* 11 600mV 3.5 dB */
+ { 0x2, 0x0, 0x08 }, /* 11 600mV 3.5 dB */
{ 0x0, 0x0, 0x14 }, /* 12 600mV 6 dB */
{ 0x2, 0x0, 0x00 }, /* 20 800mV 0 dB */
{ 0x0, 0x0, 0x0B }, /* 21 800mV 3.5 dB */
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [RFC,1/1] drm/mm: add ig_frag selftest
== Series Details == Series: series starting with [RFC,1/1] drm/mm: add ig_frag selftest URL : https://patchwork.freedesktop.org/series/77803/ State : success == Summary == CI Bug Log - changes from CI_DRM_8556 -> Patchwork_17823 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17823/index.html Known issues Here are the changes found in Patchwork_17823 that come from known issues: ### IGT changes ### Possible fixes * igt@i915_selftest@live@active: - fi-bsw-n3050: [DMESG-FAIL][1] ([i915#541]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8556/fi-bsw-n3050/igt@i915_selftest@l...@active.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17823/fi-bsw-n3050/igt@i915_selftest@l...@active.html [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541 Participating hosts (50 -> 43) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-kbl-7560u fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8556 -> Patchwork_17823 CI-20190529: 20190529 CI_DRM_8556: a12abc504361cc53eeb53c2948aebbd88709a901 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5684: bd399f5eb8263bb4a84ae6a5bb1a13d329e0515d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17823: 320cc6810801929affc6303c2481c0d2b735414e @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 320cc6810801 drm/mm: add ig_frag selftest == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17823/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [RFC,1/1] drm/mm: add ig_frag selftest
== Series Details == Series: series starting with [RFC,1/1] drm/mm: add ig_frag selftest URL : https://patchwork.freedesktop.org/series/77803/ State : warning == Summary == $ dim checkpatch origin/drm-tip 320cc6810801 drm/mm: add ig_frag selftest -:82: CHECK:BRACES: Blank lines aren't necessary before a close brace '}' #82: FILE: drivers/gpu/drm/selftests/test-drm_mm.c:1068: + +} -:106: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV) #106: FILE: drivers/gpu/drm/selftests/test-drm_mm.c:1092: +error_factor)/100; ^ -:125: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Nirmoy Das ' total: 0 errors, 1 warnings, 2 checks, 86 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 compact-test-array
== Series Details == Series: compact-test-array URL : https://patchwork.freedesktop.org/series/77802/ State : success == Summary == CI Bug Log - changes from CI_DRM_8556 -> Patchwork_17822 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17822/index.html Known issues Here are the changes found in Patchwork_17822 that come from known issues: ### IGT changes ### Possible fixes * igt@i915_selftest@live@active: - fi-bsw-n3050: [DMESG-FAIL][1] ([i915#541]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8556/fi-bsw-n3050/igt@i915_selftest@l...@active.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17822/fi-bsw-n3050/igt@i915_selftest@l...@active.html [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541 Participating hosts (50 -> 44) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8556 -> Patchwork_17822 CI-20190529: 20190529 CI_DRM_8556: a12abc504361cc53eeb53c2948aebbd88709a901 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5684: bd399f5eb8263bb4a84ae6a5bb1a13d329e0515d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17822: 546e4806fc80f3557d3395a9a101d9c21e985323 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 546e4806fc80 compact-test-array == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17822/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/gem: Taint all shrinkable object locks
== Series Details == Series: series starting with [1/2] drm/i915/gem: Taint all shrinkable object locks URL : https://patchwork.freedesktop.org/series/77799/ State : success == Summary == CI Bug Log - changes from CI_DRM_8554_full -> Patchwork_17821_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17821_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_tiled_swapping@non-threaded: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([i915#183]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8554/shard-apl4/igt@gem_tiled_swapp...@non-threaded.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17821/shard-apl8/igt@gem_tiled_swapp...@non-threaded.html * igt@gem_vm_create@isolation: - shard-apl: [PASS][3] -> [TIMEOUT][4] ([i915#1635]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8554/shard-apl1/igt@gem_vm_cre...@isolation.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17821/shard-apl4/igt@gem_vm_cre...@isolation.html * igt@gen9_exec_parse@allowed-all: - shard-skl: [PASS][5] -> [DMESG-WARN][6] ([i915#1436] / [i915#716]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8554/shard-skl10/igt@gen9_exec_pa...@allowed-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17821/shard-skl9/igt@gen9_exec_pa...@allowed-all.html * igt@kms_color@pipe-a-ctm-blue-to-red: - shard-skl: [PASS][7] -> [FAIL][8] ([i915#129]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8554/shard-skl4/igt@kms_co...@pipe-a-ctm-blue-to-red.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17821/shard-skl9/igt@kms_co...@pipe-a-ctm-blue-to-red.html * igt@kms_cursor_crc@pipe-a-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_8554/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17821/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_crc@pipe-b-cursor-256x85-sliding: - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#54]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8554/shard-kbl1/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17821/shard-kbl3/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html - shard-skl: [PASS][13] -> [FAIL][14] ([i915#54]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8554/shard-skl9/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17821/shard-skl1/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html - shard-apl: [PASS][15] -> [FAIL][16] ([i915#54]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8554/shard-apl8/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17821/shard-apl2/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#72]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8554/shard-glk1/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17821/shard-glk8/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html * igt@kms_cursor_legacy@flip-vs-cursor-crc-atomic: - shard-kbl: [PASS][19] -> [FAIL][20] ([i915#1566] / [i915#93] / [i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8554/shard-kbl4/igt@kms_cursor_leg...@flip-vs-cursor-crc-atomic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17821/shard-kbl6/igt@kms_cursor_leg...@flip-vs-cursor-crc-atomic.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8554/shard-apl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17821/shard-apl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145] / [i915#265]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8554/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17821/shard-skl9/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html * igt@kms_psr@psr2_cursor_mmap_cpu: - shard-iclb: [PASS][25] -> [SKIP][26] ([fdo#109441]) +1
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for compact-test-array
== Series Details == Series: compact-test-array URL : https://patchwork.freedesktop.org/series/77802/ State : warning == Summary == $ dim checkpatch origin/drm-tip 546e4806fc80 compact-test-array -:74: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s) total: 1 errors, 0 warnings, 0 checks, 60 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
On 2020-05-29 3:11 p.m., Marek Szyprowski wrote: > Patches are pending: > https://lore.kernel.org/linux-iommu/20200513132114.6046-1-m.szyprow...@samsung.com/T/ Cool, nice! Though, I still don't think that fixes the issue in i915_scatterlist.h given it still ignores sg_dma_len() and strictly relies on sg_next()/sg_is_last() to stop iterating -- and I suspect this is the bug that got in Tom's way. >> However, as Robin pointed out, there are other ugly tricks like stopping >> iterating through the SGL when sg_dma_len() is zero. For example, the >> AMD driver appears to use drm_prime_sg_to_page_addr_arrays() which does >> this trick and thus likely isn't buggy (otherwise, I'd expect someone to >> have complained by now seeing AMD has already switched to IOMMU-DMA. > > I'm not sure that this is a trick. Stopping at zero sg_dma_len() was > somewhere documented. Well whatever you want to call it, it is ugly to have some drivers doing one thing with the returned value and others assuming there's an extra zero at the end. It just causes confusion for people reading/copying the code. It would be better if they are all consistent. However, I concede stopping at zero should not be broken, presently. Logan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
Hi Logan, On 29.05.2020 21:05, Logan Gunthorpe wrote: > On 2020-05-29 6:45 a.m., Christoph Hellwig wrote: >> On Thu, May 28, 2020 at 06:00:44PM -0600, Logan Gunthorpe wrote: This issue is most likely in the i915 driver and is most likely caused by the driver not respecting the return value of the dma_map_ops::map_sg function. You can see the driver ignoring the return value here: https://protect2.fireeye.com/url?k=ca25a34b-97f7b813-ca242804-0cc47a31c8b4-0ecdffc9f56851e1=1=https%3A%2F%2Fgithub.com%2Ftorvalds%2Flinux%2Fblob%2F7e0165b2f1a912a06e381e91f0f4e495f4ac3736%2Fdrivers%2Fgpu%2Fdrm%2Fi915%2Fgem%2Fi915_gem_dmabuf.c%23L51 Previously this didn’t cause issues because the intel map_sg always returned the same number of elements as the input scatter gather list but with the change to this dma-iommu api this is no longer the case. I wasn’t able to track the bug down to a specific line of code unfortunately. >> Mark did a big audit into the map_sg API abuse and initially had >> some i915 patches, but then gave up on them with this comment: >> >> "The biggest TODO is DRM/i915 driver and I don't feel brave enough to fix >> it fully. The driver creatively uses sg_table->orig_nents to store the >> size of the allocate scatterlist and ignores the number of the entries >> returned by dma_map_sg function. In this patchset I only fixed the >> sg_table objects exported by dmabuf related functions. I hope that I >> didn't break anything there." >> >> it would be really nice if the i915 maintainers could help with sorting >> that API abuse out. >> > I agree completely that the API abuse should be sorted out, but I think > that's much larger than just the i915 driver. Pretty much every dma-buf > map_dma_buf implementation I looked at ignores the returned nents of > sg_attrs. This sucks, but I don't think it's the bug Tom ran into. See: > > amdgpu_dma_buf_map > armada_gem_prime_map_dma_buf > drm_gem_map_dma_buf > i915_gem_map_dma_buf > tegra_gem_prime_map_dma_buf > > So this should probably be addressed by the whole GPU community. Patches are pending: https://lore.kernel.org/linux-iommu/20200513132114.6046-1-m.szyprow...@samsung.com/T/ > However, as Robin pointed out, there are other ugly tricks like stopping > iterating through the SGL when sg_dma_len() is zero. For example, the > AMD driver appears to use drm_prime_sg_to_page_addr_arrays() which does > this trick and thus likely isn't buggy (otherwise, I'd expect someone to > have complained by now seeing AMD has already switched to IOMMU-DMA. I'm not sure that this is a trick. Stopping at zero sg_dma_len() was somewhere documented. > As I tried to point out in my previous email, i915 does not do this > trick. In fact, it completely ignores sg_dma_len() and is thus > completely broken. See i915_scatterlist.h and the __sgt_iter() function. > So it doesn't sound to me like Mark's fix would address the issue at > all. Per my previous email, I'd guess that it can be fixed simply by > adjusting the __sgt_iter() function to do something more sensible. > (Better yet, if possible, ditch __sgt_iter() and use the common DRM > function that AMD uses). > > This would at least allow us to make progress with Tom's IOMMU-DMA patch > set and once that gets in, it will be harder for other drivers to make > the same mistake. Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 1/1] drm/mm: add ig_frag selftest
This works correctly most of the times but sometimes
20k insertions can take more than 8 times of 10k insertion time.
Regards,
Nirmoy
On 5/29/20 6:33 PM, Nirmoy Das wrote:
This patch introduces fragmentation in the address range
and measures time taken by 10k and 20k insertions. ig_frag()
will fail if time taken by 20k insertions takes more than 4 times
of 10k insertions as we know that insertions scale quadratically.
Also tolerate 10% error because of kernel scheduler's jitters.
Output:
[ 8092.653518] drm_mm: Testing DRM range manger (struct drm_mm), with
random_seed=0x9bfb4117 max_iterations=8192 max_prime=128
[ 8092.653520] drm_mm: igt_sanitycheck - ok!
[ 8092.653525] igt_debug 0x-0x0200: 512: free
[ 8092.653526] igt_debug 0x0200-0x0600: 1024: used
[ 8092.653527] igt_debug 0x0600-0x0a00: 1024: free
[ 8092.653528] igt_debug 0x0a00-0x0e00: 1024: used
[ 8092.653529] igt_debug 0x0e00-0x1000: 512: free
[ 8092.653529] igt_debug total: 4096, used 2048 free 2048
[ 8112.569813] drm_mm: best fragmented insert of 1 and 2 insertions
took 504 and 1996 msecs
[ 8112.723254] drm_mm: bottom-up fragmented insert of 1 and 2
insertions took 44 and 108 msecs
[ 8112.813212] drm_mm: top-down fragmented insert of 1 and 2 insertions
took 40 and 44 msecs
[ 8112.847733] drm_mm: evict fragmented insert of 1 and 2 insertions
took 8 and 20 msecs
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 73
2 files changed, 74 insertions(+)
diff --git a/drivers/gpu/drm/selftests/drm_mm_selftests.h
b/drivers/gpu/drm/selftests/drm_mm_selftests.h
index 6b943ea1c57d..8c87c964176b 100644
--- a/drivers/gpu/drm/selftests/drm_mm_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_mm_selftests.h
@@ -14,6 +14,7 @@ selftest(insert, igt_insert)
selftest(replace, igt_replace)
selftest(insert_range, igt_insert_range)
selftest(align, igt_align)
+selftest(frag, igt_frag)
selftest(align32, igt_align32)
selftest(align64, igt_align64)
selftest(evict, igt_evict)
diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c
b/drivers/gpu/drm/selftests/test-drm_mm.c
index 9aabe82dcd3a..05d8f3659b4d 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -1033,6 +1033,79 @@ static int igt_insert_range(void *ignored)
return 0;
}
+static int get_insert_time(unsigned int num_insert,
+ const struct insert_mode *mode)
+{
+ struct drm_mm mm;
+ struct drm_mm_node *nodes, *node, *next;
+ unsigned int size = 4096, align = 8192;
+ unsigned long start;
+ unsigned int i;
+ int ret = -EINVAL;
+
+ drm_mm_init(, 1, U64_MAX - 2);
+ nodes = vzalloc(array_size(num_insert, sizeof(*nodes)));
+ if (!nodes)
+ goto err;
+
+ start = jiffies;
+ for (i = 0; i < num_insert; i++) {
+ if (!expect_insert(, [i], size, align, i, mode)) {
+ pr_err("%s insert failed\n", mode->name);
+ goto out;
+ }
+ }
+
+ ret = jiffies_to_msecs(jiffies - start);
+out:
+ drm_mm_for_each_node_safe(node, next, )
+ drm_mm_remove_node(node);
+ drm_mm_takedown();
+ vfree(nodes);
+err:
+ return ret;
+
+}
+
+static int igt_frag(void *ignored)
+{
+ const struct insert_mode *mode;
+ unsigned int insert_time1, insert_time2;
+ unsigned int insert_size = 1;
+ unsigned int scale_factor = 4;
+ /* tolerate 10% excess insertion duration */
+ unsigned int error_factor = 110;
+ int ret = -EINVAL;
+
+ for (mode = insert_modes; mode->name; mode++) {
+ unsigned int expected_time;
+
+ insert_time1 = get_insert_time(insert_size, mode);
+ if (insert_time1 < 0)
+ goto err;
+
+ insert_time2 = get_insert_time((insert_size * 2), mode);
+ if (insert_time2 < 0)
+ goto err;
+
+ expected_time = (scale_factor * insert_time1 *
+error_factor)/100;
+ if (insert_time2 > expected_time) {
+ pr_err("%s fragmented insert took more %u msecs\n",
+ mode->name, insert_time2 - expected_time);
+ goto err;
+ }
+
+ pr_info("%s fragmented insert of %u and %u insertions took %u and %u
msecs\n",
+ mode->name, insert_size, insert_size * 2, insert_time1,
+ insert_time2);
+ }
+
+ ret = 0;
+err:
+ return ret;
+}
+
static int igt_align(void *ignored)
{
const struct insert_mode *mode;
[Intel-gfx] [RFC PATCH 1/1] drm/mm: add ig_frag selftest
This patch introduces fragmentation in the address range
and measures time taken by 10k and 20k insertions. ig_frag()
will fail if time taken by 20k insertions takes more than 4 times
of 10k insertions as we know that insertions scale quadratically.
Also tolerate 10% error because of kernel scheduler's jitters.
Output:
[ 8092.653518] drm_mm: Testing DRM range manger (struct drm_mm), with
random_seed=0x9bfb4117 max_iterations=8192 max_prime=128
[ 8092.653520] drm_mm: igt_sanitycheck - ok!
[ 8092.653525] igt_debug 0x-0x0200: 512: free
[ 8092.653526] igt_debug 0x0200-0x0600: 1024: used
[ 8092.653527] igt_debug 0x0600-0x0a00: 1024: free
[ 8092.653528] igt_debug 0x0a00-0x0e00: 1024: used
[ 8092.653529] igt_debug 0x0e00-0x1000: 512: free
[ 8092.653529] igt_debug total: 4096, used 2048 free 2048
[ 8112.569813] drm_mm: best fragmented insert of 1 and 2 insertions
took 504 and 1996 msecs
[ 8112.723254] drm_mm: bottom-up fragmented insert of 1 and 2
insertions took 44 and 108 msecs
[ 8112.813212] drm_mm: top-down fragmented insert of 1 and 2 insertions
took 40 and 44 msecs
[ 8112.847733] drm_mm: evict fragmented insert of 1 and 2 insertions
took 8 and 20 msecs
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 73
2 files changed, 74 insertions(+)
diff --git a/drivers/gpu/drm/selftests/drm_mm_selftests.h
b/drivers/gpu/drm/selftests/drm_mm_selftests.h
index 6b943ea1c57d..8c87c964176b 100644
--- a/drivers/gpu/drm/selftests/drm_mm_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_mm_selftests.h
@@ -14,6 +14,7 @@ selftest(insert, igt_insert)
selftest(replace, igt_replace)
selftest(insert_range, igt_insert_range)
selftest(align, igt_align)
+selftest(frag, igt_frag)
selftest(align32, igt_align32)
selftest(align64, igt_align64)
selftest(evict, igt_evict)
diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c
b/drivers/gpu/drm/selftests/test-drm_mm.c
index 9aabe82dcd3a..05d8f3659b4d 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -1033,6 +1033,79 @@ static int igt_insert_range(void *ignored)
return 0;
}
+static int get_insert_time(unsigned int num_insert,
+ const struct insert_mode *mode)
+{
+ struct drm_mm mm;
+ struct drm_mm_node *nodes, *node, *next;
+ unsigned int size = 4096, align = 8192;
+ unsigned long start;
+ unsigned int i;
+ int ret = -EINVAL;
+
+ drm_mm_init(, 1, U64_MAX - 2);
+ nodes = vzalloc(array_size(num_insert, sizeof(*nodes)));
+ if (!nodes)
+ goto err;
+
+ start = jiffies;
+ for (i = 0; i < num_insert; i++) {
+ if (!expect_insert(, [i], size, align, i, mode)) {
+ pr_err("%s insert failed\n", mode->name);
+ goto out;
+ }
+ }
+
+ ret = jiffies_to_msecs(jiffies - start);
+out:
+ drm_mm_for_each_node_safe(node, next, )
+ drm_mm_remove_node(node);
+ drm_mm_takedown();
+ vfree(nodes);
+err:
+ return ret;
+
+}
+
+static int igt_frag(void *ignored)
+{
+ const struct insert_mode *mode;
+ unsigned int insert_time1, insert_time2;
+ unsigned int insert_size = 1;
+ unsigned int scale_factor = 4;
+ /* tolerate 10% excess insertion duration */
+ unsigned int error_factor = 110;
+ int ret = -EINVAL;
+
+ for (mode = insert_modes; mode->name; mode++) {
+ unsigned int expected_time;
+
+ insert_time1 = get_insert_time(insert_size, mode);
+ if (insert_time1 < 0)
+ goto err;
+
+ insert_time2 = get_insert_time((insert_size * 2), mode);
+ if (insert_time2 < 0)
+ goto err;
+
+ expected_time = (scale_factor * insert_time1 *
+error_factor)/100;
+ if (insert_time2 > expected_time) {
+ pr_err("%s fragmented insert took more %u msecs\n",
+ mode->name, insert_time2 - expected_time);
+ goto err;
+ }
+
+ pr_info("%s fragmented insert of %u and %u insertions took %u
and %u msecs\n",
+ mode->name, insert_size, insert_size * 2, insert_time1,
+ insert_time2);
+ }
+
+ ret = 0;
+err:
+ return ret;
+}
+
static int igt_align(void *ignored)
{
const struct insert_mode *mode;
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 1/1] drm/mm: add ig_frag selftest
On 5/29/20 5:52 PM, Chris Wilson wrote:
Quoting Nirmoy (2020-05-29 16:40:53)
This works correctly most of the times but sometimes
I have to take my word back. In another machine, 20k insertions in
best mode takes 6-9 times more than 10k insertions, all most all the time.
evict, bottom-up and top-down modes remains in 2-5 times range.
If I reduce the insertions to 1k and 2k then scaling factor for best
mode stays below 4 most of the time.
evict, bottom-up and top-down modes remains in 2-3 times range.
I wonder if it makes sense to test with only 1k and 2k insertions and
tolerate more than error if the mode == best.
Regards,
Nirmoy
20k insertions can take more than 8 times of 10k insertion time.
The pressure is on to improve then :)
Regards,
Nirmoy
On 5/29/20 6:33 PM, Nirmoy Das wrote:
This patch introduces fragmentation in the address range
and measures time taken by 10k and 20k insertions. ig_frag()
will fail if time taken by 20k insertions takes more than 4 times
of 10k insertions as we know that insertions scale quadratically.
Also tolerate 10% error because of kernel scheduler's jitters.
Output:
[ 8092.653518] drm_mm: Testing DRM range manger (struct drm_mm), with
random_seed=0x9bfb4117 max_iterations=8192 max_prime=128
[ 8092.653520] drm_mm: igt_sanitycheck - ok!
[ 8092.653525] igt_debug 0x-0x0200: 512: free
[ 8092.653526] igt_debug 0x0200-0x0600: 1024: used
[ 8092.653527] igt_debug 0x0600-0x0a00: 1024: free
[ 8092.653528] igt_debug 0x0a00-0x0e00: 1024: used
[ 8092.653529] igt_debug 0x0e00-0x1000: 512: free
[ 8092.653529] igt_debug total: 4096, used 2048 free 2048
[ 8112.569813] drm_mm: best fragmented insert of 1 and 2 insertions
took 504 and 1996 msecs
[ 8112.723254] drm_mm: bottom-up fragmented insert of 1 and 2
insertions took 44 and 108 msecs
[ 8112.813212] drm_mm: top-down fragmented insert of 1 and 2 insertions
took 40 and 44 msecs
[ 8112.847733] drm_mm: evict fragmented insert of 1 and 2 insertions
took 8 and 20 msecs
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 73
2 files changed, 74 insertions(+)
diff --git a/drivers/gpu/drm/selftests/drm_mm_selftests.h
b/drivers/gpu/drm/selftests/drm_mm_selftests.h
index 6b943ea1c57d..8c87c964176b 100644
--- a/drivers/gpu/drm/selftests/drm_mm_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_mm_selftests.h
@@ -14,6 +14,7 @@ selftest(insert, igt_insert)
selftest(replace, igt_replace)
selftest(insert_range, igt_insert_range)
selftest(align, igt_align)
+selftest(frag, igt_frag)
selftest(align32, igt_align32)
selftest(align64, igt_align64)
selftest(evict, igt_evict)
diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c
b/drivers/gpu/drm/selftests/test-drm_mm.c
index 9aabe82dcd3a..05d8f3659b4d 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -1033,6 +1033,79 @@ static int igt_insert_range(void *ignored)
return 0;
}
+static int get_insert_time(unsigned int num_insert,
+const struct insert_mode *mode)
+{
+ struct drm_mm mm;
+ struct drm_mm_node *nodes, *node, *next;
+ unsigned int size = 4096, align = 8192;
+ unsigned long start;
+ unsigned int i;
+ int ret = -EINVAL;
+
+ drm_mm_init(, 1, U64_MAX - 2);
+ nodes = vzalloc(array_size(num_insert, sizeof(*nodes)));
+ if (!nodes)
+ goto err;
+
+ start = jiffies;
Use ktime_t start = ktime_now();
+ for (i = 0; i < num_insert; i++) {
+ if (!expect_insert(, [i], size, align, i, mode)) {
+ pr_err("%s insert failed\n", mode->name);
+ goto out;
+ }
+ }
+
+ ret = jiffies_to_msecs(jiffies - start);
ret = ktime_sub(ktime_now(), start);
The downside to using ktime is remembering it is s64 and so requires care
and attention in doing math.
+out:
+ drm_mm_for_each_node_safe(node, next, )
+ drm_mm_remove_node(node);
+ drm_mm_takedown();
+ vfree(nodes);
+err:
+ return ret;
+
+}
+
+static int igt_frag(void *ignored)
+{
+ const struct insert_mode *mode;
+ unsigned int insert_time1, insert_time2;
+ unsigned int insert_size = 1;
+ unsigned int scale_factor = 4;
+ /* tolerate 10% excess insertion duration */
+ unsigned int error_factor = 110;
+ int ret = -EINVAL;
+
+ for (mode = insert_modes; mode->name; mode++) {
+ unsigned int expected_time;
+
+ insert_time1 = get_insert_time(insert_size, mode);
+ if (insert_time1 < 0)
+ goto err;
Ah, can you propagate the actual error. I see you are returning EINVAL
for ENOMEM errors. Just wait until it hits and you have to debug why :)
+
Re: [Intel-gfx] [PATCH 1/4] drm/i915/display/hsw+: Do not program the same vswing entry twice
On Fri, 2020-05-29 at 09:51 +0300, Ville Syrjälä wrote:
> On Thu, May 28, 2020 at 01:03:53PM -0700, José Roberto de Souza wrote:
> > It will be programed right before the link training, so no need to do
> > it twice.
> > It will not strictly follow BSpec sequences but most of this sequences
> > are not matching anyways.
> >
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 19 ---
> > 1 file changed, 4 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index aa22465bb56e..c100efc6a2c4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -3115,7 +3115,6 @@ static void tgl_ddi_pre_enable_dp(struct
> > intel_atomic_state *state,
> > enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
> > struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> > bool is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST);
> > - int level = intel_ddi_dp_level(intel_dp);
> > enum transcoder transcoder = crtc_state->cpu_transcoder;
> >
> > intel_dp_set_link_params(intel_dp, crtc_state->port_clock,
> > @@ -3190,9 +3189,10 @@ static void tgl_ddi_pre_enable_dp(struct
> > intel_atomic_state *state,
> > * down this function.
> > */
> >
> > - /* 7.e Configure voltage swing and related IO settings */
> > - tgl_ddi_vswing_sequence(encoder, crtc_state->port_clock, level,
> > - encoder->type);
> > + /*
> > +* 7.e Configure voltage swing and related IO settings
> > +* It will be done in intel_dp_start_link_train(), no need to do twice
> > +*/
>
> Hmm. Do we still set it up before turning on the port?
No.
intel_dp_start_link_train()
intel_dp_link_training_clock_recovery()
intel_dp->prepare_link_retrain(intel_dp)/intel_ddi_prepare_link_retrain();/*
Port is enabled here in training mode */
intel_dp_reset_link_train()
intel_dp_set_signal_levels() /* Vswing table is set
here */
Guess is safer keep programming it twice then?
>
> >
> > /*
> > * 7.f Combo PHY: Configure PORT_CL_DW10 Static Power Down to power up
> > @@ -3257,7 +3257,6 @@ static void hsw_ddi_pre_enable_dp(struct
> > intel_atomic_state *state,
> > enum phy phy = intel_port_to_phy(dev_priv, port);
> > struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> > bool is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST);
> > - int level = intel_ddi_dp_level(intel_dp);
> >
> > if (INTEL_GEN(dev_priv) < 11)
> > drm_WARN_ON(_priv->drm,
> > @@ -3279,16 +3278,6 @@ static void hsw_ddi_pre_enable_dp(struct
> > intel_atomic_state *state,
> >
> > icl_program_mg_dp_mode(dig_port, crtc_state);
> >
> > - if (INTEL_GEN(dev_priv) >= 11)
> > - icl_ddi_vswing_sequence(encoder, crtc_state->port_clock,
> > - level, encoder->type);
> > - else if (IS_CANNONLAKE(dev_priv))
> > - cnl_ddi_vswing_sequence(encoder, level, encoder->type);
> > - else if (IS_GEN9_LP(dev_priv))
> > - bxt_ddi_vswing_sequence(encoder, level, encoder->type);
> > - else
> > - intel_prepare_dp_ddi_buffers(encoder, crtc_state);
>
> This last one definitely has to stay IIRC. HSW/BDW/SKL buf trans
> stuff works quite bit differently than the BXT+ style more manual
> programming.
>
> > -
> > if (intel_phy_is_combo(dev_priv, phy)) {
> > bool lane_reversal =
> > dig_port->saved_port_bits & DDI_BUF_PORT_REVERSAL;
> > --
> > 2.26.2
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] compact-test-array
Ok, so count was variable, how about something like this. By my back of
the paper calcs this should reduce it from 408 bytes to 272 bytes.
---
drivers/gpu/drm/selftests/test-drm_mm.c | 42 -
1 file changed, 20 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c
b/drivers/gpu/drm/selftests/test-drm_mm.c
index 9aabe82dcd3a..fa643cc54b0b 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -323,32 +323,30 @@ static bool expect_reserve_fail(struct drm_mm *mm, struct
drm_mm_node *node)
return false;
}
-static bool check_reserve_boundaries(struct drm_mm *mm,
-unsigned int count,
-u64 size)
+static bool check_reserve_boundaries(struct drm_mm *mm, int count, u64 size)
{
const struct boundary {
- u64 start, size;
+ int start, size;
const char *name;
} boundaries[] = {
#define B(st, sz) { (st), (sz), "{ " #st ", " #sz "}" }
B(0, 0),
- B(-size, 0),
- B(size, 0),
- B(size * count, 0),
- B(-size, size),
- B(-size, -size),
- B(-size, 2*size),
- B(0, -size),
- B(size, -size),
- B(count*size, size),
- B(count*size, -size),
- B(count*size, count*size),
- B(count*size, -count*size),
- B(count*size, -(count+1)*size),
- B((count+1)*size, size),
- B((count+1)*size, -size),
- B((count+1)*size, -2*size),
+ B(-1, 0),
+ B(1, 0),
+ B(count, 0),
+ B(-1, 1),
+ B(-1, -1),
+ B(-1, 2),
+ B(0, -1),
+ B(1, -1),
+ B(count, 1),
+ B(count, -1),
+ B(count, count),
+ B(count, -count),
+ B(count, -(count + 1)),
+ B(count + 1, 1),
+ B(count + 1, -1),
+ B(count + 1, -2),
#undef B
};
struct drm_mm_node tmp = {};
@@ -357,8 +355,8 @@ static bool check_reserve_boundaries(struct drm_mm *mm,
for (n = 0; n < ARRAY_SIZE(boundaries); n++) {
if (!expect_reserve_fail(mm,
set_node(,
- boundaries[n].start,
- boundaries[n].size))) {
+ boundaries[n].start * size,
+ boundaries[n].size * size))) {
pr_err("boundary[%d:%s] failed, count=%u, size=%lld\n",
n, boundaries[n].name, count, size);
return false;
--
2.27.0.rc2
___
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/gem: Give each object class a friendly name
On Fri, 29 May 2020 at 19:32, Chris Wilson wrote: > > Name the object classes and their offspring for easier lockdep > debugging. > > 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 1/2] drm/i915/gem: Taint all shrinkable object locks
On Fri, 29 May 2020 at 19:32, Chris Wilson wrote: > > If we declare that an object type is shrinkable (any that we can reclaim > to recover system pages), make sure we taint the object mutex so that > lockdep expects us to use it within fs_reclaim. lockdep will then > complain the first time we try to allocate while holding the plain > mutex, as doing so invites potential recursion. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Add a few asserts around handling of i915_request_is_active() (rev6)
== Series Details ==
Series: series starting with [1/2] drm/i915: Add a few asserts around handling
of i915_request_is_active() (rev6)
URL : https://patchwork.freedesktop.org/series/77781/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8554_full -> Patchwork_17820_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_17820_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_vm_create@isolation:
- shard-apl: [PASS][1] -> [TIMEOUT][2] ([i915#1635]) +3 similar
issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8554/shard-apl1/igt@gem_vm_cre...@isolation.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17820/shard-apl8/igt@gem_vm_cre...@isolation.html
* igt@i915_suspend@fence-restore-untiled:
- shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180] / [i915#93]
/ [i915#95])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8554/shard-kbl4/igt@i915_susp...@fence-restore-untiled.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17820/shard-kbl6/igt@i915_susp...@fence-restore-untiled.html
* igt@i915_suspend@forcewake:
- shard-kbl: [PASS][5] -> [INCOMPLETE][6] ([i915#155])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8554/shard-kbl7/igt@i915_susp...@forcewake.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17820/shard-kbl4/igt@i915_susp...@forcewake.html
* igt@kms_big_fb@x-tiled-64bpp-rotate-0:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#1119] / [i915#118] /
[i915#95]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8554/shard-glk5/igt@kms_big...@x-tiled-64bpp-rotate-0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17820/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-0.html
* igt@kms_color@pipe-a-ctm-blue-to-red:
- shard-skl: [PASS][9] -> [FAIL][10] ([i915#129])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8554/shard-skl4/igt@kms_co...@pipe-a-ctm-blue-to-red.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17820/shard-skl6/igt@kms_co...@pipe-a-ctm-blue-to-red.html
* igt@kms_cursor_crc@pipe-b-cursor-256x85-sliding:
- shard-kbl: [PASS][11] -> [FAIL][12] ([i915#54])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8554/shard-kbl1/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17820/shard-kbl3/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
- shard-skl: [PASS][13] -> [FAIL][14] ([i915#54])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8554/shard-skl9/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17820/shard-skl8/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
- shard-apl: [PASS][15] -> [FAIL][16] ([i915#54])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8554/shard-apl8/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17820/shard-apl2/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +2
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8554/shard-apl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17820/shard-apl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8554/shard-kbl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17820/shard-kbl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [i915#265])
+1 similar issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8554/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17820/shard-skl10/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
* igt@kms_psr@psr2_no_drrs:
- shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8554/shard-iclb2/igt@kms_psr@psr2_no_drrs.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17820/shard-iclb6/igt@kms_psr@psr2_no_drrs.html
Possible fixes
* {igt@gem_exec_balancer@bonded-dual}:
- shard-tglb: [FAIL][25] -> [PASS][26]
Re: [Intel-gfx] [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
On 2020-05-29 6:45 a.m., Christoph Hellwig wrote: > On Thu, May 28, 2020 at 06:00:44PM -0600, Logan Gunthorpe wrote: >>> This issue is most likely in the i915 driver and is most likely caused by >>> the driver not respecting the return value of the dma_map_ops::map_sg >>> function. You can see the driver ignoring the return value here: >>> https://github.com/torvalds/linux/blob/7e0165b2f1a912a06e381e91f0f4e495f4ac3736/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c#L51 >>> >>> Previously this didn’t cause issues because the intel map_sg always >>> returned the same number of elements as the input scatter gather list but >>> with the change to this dma-iommu api this is no longer the case. I wasn’t >>> able to track the bug down to a specific line of code unfortunately. > > Mark did a big audit into the map_sg API abuse and initially had > some i915 patches, but then gave up on them with this comment: > > "The biggest TODO is DRM/i915 driver and I don't feel brave enough to fix > it fully. The driver creatively uses sg_table->orig_nents to store the > size of the allocate scatterlist and ignores the number of the entries > returned by dma_map_sg function. In this patchset I only fixed the > sg_table objects exported by dmabuf related functions. I hope that I > didn't break anything there." > > it would be really nice if the i915 maintainers could help with sorting > that API abuse out. > I agree completely that the API abuse should be sorted out, but I think that's much larger than just the i915 driver. Pretty much every dma-buf map_dma_buf implementation I looked at ignores the returned nents of sg_attrs. This sucks, but I don't think it's the bug Tom ran into. See: amdgpu_dma_buf_map armada_gem_prime_map_dma_buf drm_gem_map_dma_buf i915_gem_map_dma_buf tegra_gem_prime_map_dma_buf So this should probably be addressed by the whole GPU community. However, as Robin pointed out, there are other ugly tricks like stopping iterating through the SGL when sg_dma_len() is zero. For example, the AMD driver appears to use drm_prime_sg_to_page_addr_arrays() which does this trick and thus likely isn't buggy (otherwise, I'd expect someone to have complained by now seeing AMD has already switched to IOMMU-DMA. As I tried to point out in my previous email, i915 does not do this trick. In fact, it completely ignores sg_dma_len() and is thus completely broken. See i915_scatterlist.h and the __sgt_iter() function. So it doesn't sound to me like Mark's fix would address the issue at all. Per my previous email, I'd guess that it can be fixed simply by adjusting the __sgt_iter() function to do something more sensible. (Better yet, if possible, ditch __sgt_iter() and use the common DRM function that AMD uses). This would at least allow us to make progress with Tom's IOMMU-DMA patch set and once that gets in, it will be harder for other drivers to make the same mistake. Logan ___ 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/i915/gem: Taint all shrinkable object locks
== Series Details == Series: series starting with [1/2] drm/i915/gem: Taint all shrinkable object locks URL : https://patchwork.freedesktop.org/series/77799/ State : success == Summary == CI Bug Log - changes from CI_DRM_8554 -> Patchwork_17821 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17821/index.html Changes --- No changes found Participating hosts (49 -> 43) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8554 -> Patchwork_17821 CI-20190529: 20190529 CI_DRM_8554: ac5c0538eb79074e97a7a5c03c285f339290d961 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5684: bd399f5eb8263bb4a84ae6a5bb1a13d329e0515d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17821: 35c96a6a980bde9bcf4baf8a35ee85b468640124 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 35c96a6a980b drm/i915/gem: Give each object class a friendly name 9330abaf4eee drm/i915/gem: Taint all shrinkable object locks == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17821/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/gem: Give each object class a friendly name
Name the object classes and their offspring for easier lockdep
debugging.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_object.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 2 ++
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_shmem.c| 1 +
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 1 +
drivers/gpu/drm/i915/gem/selftests/huge_gem_object.c | 1 +
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 3 +++
drivers/gpu/drm/i915/gvt/dmabuf.c| 1 +
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c| 1 +
drivers/gpu/drm/i915/selftests/mock_region.c | 1 +
14 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 7db5a793739d..2679380159fc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -217,6 +217,7 @@ static void i915_gem_object_put_pages_dmabuf(struct
drm_i915_gem_object *obj,
}
static const struct drm_i915_gem_object_ops i915_gem_object_dmabuf_ops = {
+ .name = "i915_gem_object_dmabuf",
.get_pages = i915_gem_object_get_pages_dmabuf,
.put_pages = i915_gem_object_put_pages_dmabuf,
};
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index cbbff81aa0af..ad22f42541bd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -137,6 +137,7 @@ static void i915_gem_object_put_pages_internal(struct
drm_i915_gem_object *obj,
}
static const struct drm_i915_gem_object_ops i915_gem_object_internal_ops = {
+ .name = "i915_gem_object_internal",
.flags = I915_GEM_OBJECT_HAS_STRUCT_PAGE |
I915_GEM_OBJECT_IS_SHRINKABLE,
.get_pages = i915_gem_object_get_pages_internal,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index 70543c83df06..932ee21e6609 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -9,6 +9,7 @@
#include "i915_drv.h"
const struct drm_i915_gem_object_ops i915_gem_lmem_obj_ops = {
+ .name = "i915_gem_object_lmem",
.flags = I915_GEM_OBJECT_HAS_IOMEM,
.get_pages = i915_gem_object_get_pages_buddy,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 21635dd415a3..b6ec5b50d93b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -53,7 +53,7 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
const struct drm_i915_gem_object_ops *ops,
struct lock_class_key *key)
{
- __mutex_init(>mm.lock, "obj->mm.lock", key);
+ __mutex_init(>mm.lock, ops->name ?: "obj->mm.lock", key);
spin_lock_init(>vma.lock);
INIT_LIST_HEAD(>vma.list);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 54ee658bb168..b1f82a11aef2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -61,6 +61,8 @@ struct drm_i915_gem_object_ops {
int (*dmabuf_export)(struct drm_i915_gem_object *obj);
void (*release)(struct drm_i915_gem_object *obj);
+
+ const char *name; /* friendly name for debug, e.g. lockdep classes */
};
enum i915_mmap_type {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
index 12245a47e5fb..28147aab47b9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
@@ -140,6 +140,7 @@ static void phys_release(struct drm_i915_gem_object *obj)
}
static const struct drm_i915_gem_object_ops i915_gem_phys_ops = {
+ .name = "i915_gem_object_phys",
.get_pages = i915_gem_object_get_pages_phys,
.put_pages = i915_gem_object_put_pages_phys,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 7cf8548ff708..38113d3c0138 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -429,6 +429,7 @@ static void shmem_release(struct drm_i915_gem_object *obj)
}
const struct drm_i915_gem_object_ops i915_gem_shmem_ops = {
+ .name = "i915_gem_object_shmem",
.flags = I915_GEM_OBJECT_HAS_STRUCT_PAGE |
I915_GEM_OBJECT_IS_SHRINKABLE,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
[Intel-gfx] [PATCH 1/2] drm/i915/gem: Taint all shrinkable object locks
If we declare that an object type is shrinkable (any that we can reclaim to recover system pages), make sure we taint the object mutex so that lockdep expects us to use it within fs_reclaim. lockdep will then complain the first time we try to allocate while holding the plain mutex, as doing so invites potential recursion. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gem/i915_gem_object.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c index 99356c00c19e..21635dd415a3 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c @@ -72,6 +72,10 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj, obj->mm.madv = I915_MADV_WILLNEED; INIT_RADIX_TREE(>mm.get_page.radix, GFP_KERNEL | __GFP_NOWARN); mutex_init(>mm.get_page.lock); + + if (IS_ENABLED(CONFIG_LOCKDEP) && i915_gem_object_is_shrinkable(obj)) + i915_gem_shrinker_taints_mutex(to_i915(obj->base.dev), + >mm.lock); } /** -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Add a few asserts around handling of i915_request_is_active() (rev6)
== Series Details == Series: series starting with [1/2] drm/i915: Add a few asserts around handling of i915_request_is_active() (rev6) URL : https://patchwork.freedesktop.org/series/77781/ State : success == Summary == CI Bug Log - changes from CI_DRM_8554 -> Patchwork_17820 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17820/index.html Changes --- No changes found Participating hosts (49 -> 42) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-bdw-samus fi-byt-clapper fi-skl-6600u Build changes - * Linux: CI_DRM_8554 -> Patchwork_17820 CI-20190529: 20190529 CI_DRM_8554: ac5c0538eb79074e97a7a5c03c285f339290d961 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5684: bd399f5eb8263bb4a84ae6a5bb1a13d329e0515d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17820: 319babfa21e7433aad375377305d5ad092615dfa @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 319babfa21e7 drm/i915: Check for awaits on still currently executing requests == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17820/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 series starting with [1/2] drm/i915: Add a few asserts around handling of i915_request_is_active() (rev5)
== Series Details == Series: series starting with [1/2] drm/i915: Add a few asserts around handling of i915_request_is_active() (rev5) URL : https://patchwork.freedesktop.org/series/77781/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8553_full -> Patchwork_17819_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17819_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17819_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_17819_full: ### IGT changes ### Possible regressions * igt@kms_lease@page_flip_implicit_plane: - shard-skl: [PASS][1] -> [TIMEOUT][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl1/igt@kms_lease@page_flip_implicit_plane.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-skl6/igt@kms_lease@page_flip_implicit_plane.html Warnings * igt@i915_pm_dc@dc6-dpms: - shard-skl: [FAIL][3] ([i915#454]) -> [TIMEOUT][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl1/igt@i915_pm...@dc6-dpms.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-skl6/igt@i915_pm...@dc6-dpms.html * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-blt: - shard-skl: [SKIP][5] ([fdo#109271]) -> [TIMEOUT][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl1/igt@kms_frontbuffer_track...@fbc-2p-primscrn-cur-indfb-draw-blt.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-skl6/igt@kms_frontbuffer_track...@fbc-2p-primscrn-cur-indfb-draw-blt.html Known issues Here are the changes found in Patchwork_17819_full that come from known issues: ### IGT changes ### Issues hit * igt@gen9_exec_parse@allowed-all: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([i915#1436] / [i915#716]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-apl1/igt@gen9_exec_pa...@allowed-all.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-apl1/igt@gen9_exec_pa...@allowed-all.html * igt@kms_cursor_crc@pipe-a-cursor-64x64-random: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#54] / [i915#93] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-64x64-random.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-64x64-random.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-apl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-apl8/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_fbcon_fbt@fbc-suspend: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#1121] / [i915#118] / [i915#95]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-glk9/igt@kms_fbcon_...@fbc-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-glk5/igt@kms_fbcon_...@fbc-suspend.html * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-blt: - shard-skl: [PASS][15] -> [TIMEOUT][16] ([i915#123]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl1/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-shrfb-draw-blt.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-skl6/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-shrfb-draw-blt.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#1188]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl3/igt@kms_...@bpc-switch-dpms.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-skl5/igt@kms_...@bpc-switch-dpms.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-kbl1/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-c.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/shard-kbl2/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-c.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109642] / [fdo#111068]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-iclb2/igt@kms_psr2...@frontbuffer.html [22]:
Re: [Intel-gfx] [PATCH 3/4] drm/i915/display: Implement HOBL
On Fri, 2020-05-29 at 10:00 +0300, Ville Syrjälä wrote:
> On Thu, May 28, 2020 at 01:03:55PM -0700, José Roberto de Souza wrote:
> > Hours Of Battery Life is a new GEN12+ power-saving feature that allows
> > supported motherboards to use a special voltage swing table for eDP
> > panels that uses less power.
> >
> > So here if supported by HW, OEM will set it in VBT and i915 will try
> > to train link with HOBL vswing table if link training fails it fall
> > back to the original table.
> >
> > Just not sure if DP compliance should also use this new voltage swing
> > table too, cced some folks that worked in DP compliance.
> >
> > BSpec: 49291
> > BSpec: 49399
> > Cc: Animesh Manna
> > Cc: Manasi Navare
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 48 +--
> > .../drm/i915/display/intel_display_types.h| 2 +
> > .../drm/i915/display/intel_dp_link_training.c | 20 +++-
> > drivers/gpu/drm/i915/i915_drv.h | 2 +
> > drivers/gpu/drm/i915/i915_reg.h | 2 +
> > 5 files changed, 69 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index c100efc6a2c4..a44e190de79f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -692,6 +692,10 @@ static const struct cnl_ddi_buf_trans
> > tgl_combo_phy_ddi_translations_dp_hbr2[] =
> > { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
> > };
> >
> > +static const struct cnl_ddi_buf_trans
> > tgl_combo_phy_ddi_translations_edp_hbr2_hobl[] = {
> > + { 0x6, 0x7F, 0x3F, 0x00, 0x00 }
> > +};
>
> This doesn't seem to mesh well with the notion of "at least
> everything up to vswing 2/preemph 2 is mandatory", as laid
> out in https://patchwork.freedesktop.org/series/77198/
>
> Hmm. I was going to add some WARNs there to make sure
> .{voltage,preemph}_max() always return level 2 or level 3.
> But looks like I failed to actually do it.
Even if you had, intel_dp_voltage_max() is not aware of this new table and
if/when it is executed is because the voltage 0 and preemph 0 of the
regular table also failed the link training.
>
> > +
> > static const struct ddi_buf_trans *
> > bdw_get_buf_trans_edp(struct drm_i915_private *dev_priv, int *n_entries)
> > {
> > @@ -2297,14 +2301,51 @@ static void cnl_ddi_vswing_sequence(struct
> > intel_encoder *encoder,
> > intel_de_write(dev_priv, CNL_PORT_TX_DW5_GRP(port), val);
> > }
> >
> > +/*
> > + * If supported return HOBL vswing table and set registers to enable HOBL
> > + * otherwise returns NULL and unset registers to enable HOBL.
> > + */
> > +static const struct cnl_ddi_buf_trans *
> > +hobl_get_combo_buf_trans(struct drm_i915_private *dev_priv,
> > +struct intel_encoder *encoder, int type, int rate,
> > +u32 level, int *n_entries)
> > +{
> > + const u32 hobl_en = EDP4K2K_MODE_OVRD_EN | EDP4K2K_MODE_OVRD_OPTIMIZED;
> > + enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
> > + struct intel_dp *intel_dp;
> > +
> > + if (!HAS_HOBL(dev_priv) || type != INTEL_OUTPUT_EDP)
> > + return NULL;
> > +
> > + intel_dp = enc_to_intel_dp(encoder);
> > + if (!intel_dp->try_hobl || rate > 54) {
> > + intel_de_rmw(dev_priv, ICL_PORT_CL_DW10(phy), hobl_en, 0);
> > + return NULL;
> > + }
> > +
> > + drm_dbg_kms(_priv->drm, "Enabling HOBL in PHY %c\n", phy_name(phy));
> > + drm_WARN_ON_ONCE(_priv->drm, level > 0);
> > +
> > + intel_de_rmw(dev_priv, ICL_PORT_CL_DW10(phy), hobl_en, hobl_en);
> > + /* Same table applies to TGL, RKL and DG1 */
> > + *n_entries = ARRAY_SIZE(tgl_combo_phy_ddi_translations_edp_hbr2_hobl);
> > + return tgl_combo_phy_ddi_translations_edp_hbr2_hobl;
> > +}
> > +
> > static void icl_ddi_combo_vswing_program(struct drm_i915_private *dev_priv,
> > - u32 level, enum phy phy, int type,
> > - int rate)
> > +struct intel_encoder *encoder,
> > +u32 level, enum phy phy, int type,
> > +int rate)
> > {
> > const struct cnl_ddi_buf_trans *ddi_translations = NULL;
> > u32 n_entries, val;
> > int ln;
> >
> > + ddi_translations = hobl_get_combo_buf_trans(dev_priv, encoder, type,
> > + rate, level, _entries);
> > + if (ddi_translations)
> > + goto hobl_found;
> > +
> > if (INTEL_GEN(dev_priv) >= 12)
> > ddi_translations = tgl_get_combo_buf_trans(dev_priv, type, rate,
> >_entries);
> > @@ -2317,6 +2358,7 @@ static void icl_ddi_combo_vswing_program(struct
> > drm_i915_private *dev_priv,
> > if (!ddi_translations)
> >
Re: [Intel-gfx] [PATCH v3] drm/i915/ehl: Extend w/a 14010685332 to JSP/MCC
We've tried this on EHL and it doesn't work.
The intent of the workaround is that the bit must be toggled after all south
display registers are
accessed before entering a S0ix state. If any south display register is
accessed after this bit is
toggled, it resets things and the bit needs to be toggled again.
When we test this on EHL, the workaround isn't working. Based on some
additional testing
It appears that something is accessing a south display register after this
point. We need to
find the correct location such that this is the last thing that accesses a
south display register.
I suspect that this is also not working for ICL
Bob
--
Bob Paauwe
bob.j.paa...@intel.com
IOTG / Platform Software Engineering
Intel Corp. Folsom, CA
(916) 356-6193
(530) 409-0831 (cell)
> -Original Message-
> From: Intel-gfx On Behalf Of Swathi
> Dhanavanthri
> Sent: Wednesday, May 20, 2020 11:45 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v3] drm/i915/ehl: Extend w/a 14010685332 to
> JSP/MCC
>
> This is a permanent w/a for JSL/EHL.This is to be applied to the
> PCH types on JSL/EHL ie JSP/MCC
> Bspec: 52888
>
> v2: Fixed the wrong usage of logical OR(ville)
> v3: Removed extra braces, changed the check(jose)
>
> Signed-off-by: Swathi Dhanavanthri
> ---
> drivers/gpu/drm/i915/i915_irq.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c
> index 4dc601dffc08..bc82d0d8ad5b 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2902,8 +2902,10 @@ static void gen11_display_irq_reset(struct
> drm_i915_private *dev_priv)
> if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
> GEN3_IRQ_RESET(uncore, SDE);
>
> - /* Wa_14010685332:icl */
> - if (INTEL_PCH_TYPE(dev_priv) == PCH_ICP) {
> + /* Wa_14010685332:icl,jsl,ehl */
> + if (INTEL_PCH_TYPE(dev_priv) == PCH_ICP ||
> + INTEL_PCH_TYPE(dev_priv) == PCH_JSP ||
> + INTEL_PCH_TYPE(dev_priv) == PCH_MCC) {
> intel_uncore_rmw(uncore, SOUTH_CHICKEN1,
>SBCLK_RUN_REFCLK_DIS,
> SBCLK_RUN_REFCLK_DIS);
> intel_uncore_rmw(uncore, SOUTH_CHICKEN1,
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Discard a misplaced GGTT vma
== Series Details ==
Series: drm/i915: Discard a misplaced GGTT vma
URL : https://patchwork.freedesktop.org/series/77786/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8553_full -> Patchwork_17818_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_17818_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_whisper@basic-fds-forked-all:
- shard-hsw: [PASS][1] -> [INCOMPLETE][2] ([i915#61])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-hsw2/igt@gem_exec_whis...@basic-fds-forked-all.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-hsw2/igt@gem_exec_whis...@basic-fds-forked-all.html
* igt@i915_suspend@debugfs-reader:
- shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#180])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-apl4/igt@i915_susp...@debugfs-reader.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-apl4/igt@i915_susp...@debugfs-reader.html
* igt@kms_cursor_crc@pipe-a-cursor-64x64-random:
- shard-kbl: [PASS][5] -> [FAIL][6] ([i915#54] / [i915#93] /
[i915#95])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-64x64-random.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-64x64-random.html
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-hsw: [PASS][7] -> [INCOMPLETE][8] ([i915#1926] / [i915#61])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-hsw2/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-hsw7/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html
* igt@kms_hdr@bpc-switch-dpms:
- shard-skl: [PASS][9] -> [FAIL][10] ([i915#1188])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl3/igt@kms_...@bpc-switch-dpms.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-skl6/igt@kms_...@bpc-switch-dpms.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-kbl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-kbl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
- shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145] / [i915#265])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-skl7/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html
* igt@kms_psr2_su@frontbuffer:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109642] / [fdo#111068])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-iclb2/igt@kms_psr2...@frontbuffer.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-iclb5/igt@kms_psr2...@frontbuffer.html
* igt@kms_psr@psr2_cursor_render:
- shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-iclb6/igt@kms_psr@psr2_cursor_render.html
Possible fixes
* igt@gem_eio@in-flight-suspend:
- shard-apl: [DMESG-WARN][19] ([i915#180]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-apl1/igt@gem_...@in-flight-suspend.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-apl1/igt@gem_...@in-flight-suspend.html
* {igt@gem_exec_reloc@basic-concurrent0}:
- shard-apl: [FAIL][21] ([i915#1930]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-apl6/igt@gem_exec_re...@basic-concurrent0.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-apl8/igt@gem_exec_re...@basic-concurrent0.html
* igt@i915_suspend@fence-restore-untiled:
- shard-kbl: [DMESG-WARN][23] ([i915#180]) -> [PASS][24] +2
similar issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-kbl1/igt@i915_susp...@fence-restore-untiled.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-kbl4/igt@i915_susp...@fence-restore-untiled.html
* {igt@kms_atomic_transition@plane-all-modeset-transition-fencing@pipe-c}:
- shard-kbl: [DMESG-WARN][25] ([i915#165] /
Re: [Intel-gfx] [PATCH v2] drm/i915: Check for awaits on still currently executing requests
On 29/05/2020 15:39, Chris Wilson wrote:
With the advent of preempt-to-busy, a request may still be on the GPU as
we unwind. And in the case of a unpreemptible [due to HW] request, that
request will remain indefinitely on the GPU even though we have
returned it back to our submission queue, and cleared the active bit.
We only run the execution callbacks on transferring the request from our
submission queue to the execution queue, but if this is a bonded request
that the HW is waiting for, we will not submit it (as we wait for a
fresh execution) even though it is still being executed.
As we know that there are always preemption points between requests, we
know that only the currently executing request may be still active even
though we have cleared the flag. However, we do not precisely know which
request is in ELSP[0] due to a delay in processing events, and
furthermore we only store the last request in a context in our state
tracker.
Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
Testcase: igt/gem_exec_balancer/bonded-dual
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 49 -
1 file changed, 48 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index e5aba6824e26..c5d7220de529 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -363,6 +363,53 @@ static void __llist_add(struct llist_node *node, struct
llist_head *head)
head->first = node;
}
+static struct i915_request * const *
+__engine_active(struct intel_engine_cs *engine)
+{
+ return READ_ONCE(engine->execlists.active);
+}
+
+static bool __request_in_flight(const struct i915_request *signal)
+{
+ struct i915_request * const *port, *rq;
+ bool inflight = false;
+
+ if (!i915_request_is_ready(signal))
+ return false;
+
+ /*
+* Even if we have unwound the request, it may still be on
+* the GPU (preempt-to-busy). If that request is inside an
+* unpreemptible critical section, it will not be removed. Some
+* GPU functions may even be stuck waiting for the paired request
+* (__await_execution) to be submitted and cannot be preempted
+* until the bond is executing.
+*
+* As we know that there are always preemption points between
+* requests, we know that only the currently executing request
+* may be still active even though we have cleared the flag.
+* However, we can't rely on our tracking of ELSP[0] to known
+* which request is currently active and so maybe stuck, as
+* the tracking maybe an event behind. Instead assume that
+* if the context is still inflight, then it is still active
+* even if the active flag has been cleared.
+*/
+ if (!intel_context_inflight(signal->context))
+ return false;
+
+ rcu_read_lock();
+ for (port = __engine_active(signal->engine); (rq = *port); port++) {
+ if (rq->context == signal->context) {
+ inflight = i915_seqno_passed(rq->fence.seqno,
+signal->fence.seqno);
+ break;
+ }
+ }
+ rcu_read_unlock();
+
+ return inflight;
+}
+
static int
__await_execution(struct i915_request *rq,
struct i915_request *signal,
@@ -393,7 +440,7 @@ __await_execution(struct i915_request *rq,
}
spin_lock_irq(>lock);
- if (i915_request_is_active(signal)) {
+ if (i915_request_is_active(signal) || __request_in_flight(signal)) {
if (hook) {
hook(rq, >fence);
i915_request_put(signal);
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] [RFC PATCH 1/1] drm/mm: add ig_frag selftest
Quoting Nirmoy (2020-05-29 16:40:53)
> This works correctly most of the times but sometimes
>
> 20k insertions can take more than 8 times of 10k insertion time.
The pressure is on to improve then :)
> Regards,
>
> Nirmoy
>
> On 5/29/20 6:33 PM, Nirmoy Das wrote:
> > This patch introduces fragmentation in the address range
> > and measures time taken by 10k and 20k insertions. ig_frag()
> > will fail if time taken by 20k insertions takes more than 4 times
> > of 10k insertions as we know that insertions scale quadratically.
> > Also tolerate 10% error because of kernel scheduler's jitters.
> >
> > Output:
> >
> > [ 8092.653518] drm_mm: Testing DRM range manger (struct drm_mm), with
> > random_seed=0x9bfb4117 max_iterations=8192 max_prime=128
> > [ 8092.653520] drm_mm: igt_sanitycheck - ok!
> > [ 8092.653525] igt_debug 0x-0x0200: 512: free
> > [ 8092.653526] igt_debug 0x0200-0x0600: 1024: used
> > [ 8092.653527] igt_debug 0x0600-0x0a00: 1024: free
> > [ 8092.653528] igt_debug 0x0a00-0x0e00: 1024: used
> > [ 8092.653529] igt_debug 0x0e00-0x1000: 512: free
> > [ 8092.653529] igt_debug total: 4096, used 2048 free 2048
> > [ 8112.569813] drm_mm: best fragmented insert of 1 and 2 insertions
> > took 504 and 1996 msecs
> > [ 8112.723254] drm_mm: bottom-up fragmented insert of 1 and 2
> > insertions took 44 and 108 msecs
> > [ 8112.813212] drm_mm: top-down fragmented insert of 1 and 2
> > insertions took 40 and 44 msecs
> > [ 8112.847733] drm_mm: evict fragmented insert of 1 and 2
> > insertions took 8 and 20 msecs
> >
> >
> > Signed-off-by: Nirmoy Das
> > ---
> > drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
> > drivers/gpu/drm/selftests/test-drm_mm.c | 73
> > 2 files changed, 74 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/selftests/drm_mm_selftests.h
> > b/drivers/gpu/drm/selftests/drm_mm_selftests.h
> > index 6b943ea1c57d..8c87c964176b 100644
> > --- a/drivers/gpu/drm/selftests/drm_mm_selftests.h
> > +++ b/drivers/gpu/drm/selftests/drm_mm_selftests.h
> > @@ -14,6 +14,7 @@ selftest(insert, igt_insert)
> > selftest(replace, igt_replace)
> > selftest(insert_range, igt_insert_range)
> > selftest(align, igt_align)
> > +selftest(frag, igt_frag)
> > selftest(align32, igt_align32)
> > selftest(align64, igt_align64)
> > selftest(evict, igt_evict)
> > diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c
> > b/drivers/gpu/drm/selftests/test-drm_mm.c
> > index 9aabe82dcd3a..05d8f3659b4d 100644
> > --- a/drivers/gpu/drm/selftests/test-drm_mm.c
> > +++ b/drivers/gpu/drm/selftests/test-drm_mm.c
> > @@ -1033,6 +1033,79 @@ static int igt_insert_range(void *ignored)
> > return 0;
> > }
> >
> > +static int get_insert_time(unsigned int num_insert,
> > +const struct insert_mode *mode)
> > +{
> > + struct drm_mm mm;
> > + struct drm_mm_node *nodes, *node, *next;
> > + unsigned int size = 4096, align = 8192;
> > + unsigned long start;
> > + unsigned int i;
> > + int ret = -EINVAL;
> > +
> > + drm_mm_init(, 1, U64_MAX - 2);
> > + nodes = vzalloc(array_size(num_insert, sizeof(*nodes)));
> > + if (!nodes)
> > + goto err;
> > +
> > + start = jiffies;
Use ktime_t start = ktime_now();
> > + for (i = 0; i < num_insert; i++) {
> > + if (!expect_insert(, [i], size, align, i, mode)) {
> > + pr_err("%s insert failed\n", mode->name);
> > + goto out;
> > + }
> > + }
> > +
> > + ret = jiffies_to_msecs(jiffies - start);
ret = ktime_sub(ktime_now(), start);
The downside to using ktime is remembering it is s64 and so requires care
and attention in doing math.
> > +out:
> > + drm_mm_for_each_node_safe(node, next, )
> > + drm_mm_remove_node(node);
> > + drm_mm_takedown();
> > + vfree(nodes);
> > +err:
> > + return ret;
> > +
> > +}
> > +
> > +static int igt_frag(void *ignored)
> > +{
> > + const struct insert_mode *mode;
> > + unsigned int insert_time1, insert_time2;
> > + unsigned int insert_size = 1;
> > + unsigned int scale_factor = 4;
> > + /* tolerate 10% excess insertion duration */
> > + unsigned int error_factor = 110;
> > + int ret = -EINVAL;
> > +
> > + for (mode = insert_modes; mode->name; mode++) {
> > + unsigned int expected_time;
> > +
> > + insert_time1 = get_insert_time(insert_size, mode);
> > + if (insert_time1 < 0)
> > + goto err;
Ah, can you propagate the actual error. I see you are returning EINVAL
for ENOMEM errors. Just wait until it hits and you have to debug why :)
> > + insert_time2 = get_insert_time((insert_size * 2), mode);
> > + if (insert_time2 < 0)
> > + goto err;
> > +
>
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dsi: Drop double check for ACPI companion device
== Series Details ==
Series: drm/i915/dsi: Drop double check for ACPI companion device
URL : https://patchwork.freedesktop.org/series/77785/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8553_full -> Patchwork_17817_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_17817_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@legacy-engines-mixed-process@bsd:
- shard-skl: [PASS][1] -> [FAIL][2] ([i915#1528])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl6/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17817/shard-skl9/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd.html
* 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_8553/shard-apl1/igt@gen9_exec_pa...@allowed-all.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17817/shard-apl6/igt@gen9_exec_pa...@allowed-all.html
* igt@kms_cursor_crc@pipe-a-cursor-64x64-random:
- shard-kbl: [PASS][5] -> [FAIL][6] ([i915#54] / [i915#93] /
[i915#95])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-64x64-random.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17817/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-64x64-random.html
* igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-skl: [PASS][7] -> [INCOMPLETE][8] ([i915#300])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl1/igt@kms_cursor_...@pipe-b-cursor-suspend.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17817/shard-skl5/igt@kms_cursor_...@pipe-b-cursor-suspend.html
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
- shard-skl: [PASS][9] -> [FAIL][10] ([fdo#108145] / [i915#265])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17817/shard-skl6/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html
* igt@kms_psr2_su@frontbuffer:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109642] / [fdo#111068])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-iclb2/igt@kms_psr2...@frontbuffer.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17817/shard-iclb3/igt@kms_psr2...@frontbuffer.html
* igt@kms_psr@psr2_cursor_render:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17817/shard-iclb8/igt@kms_psr@psr2_cursor_render.html
Possible fixes
* igt@i915_suspend@fence-restore-untiled:
- shard-kbl: [DMESG-WARN][15] ([i915#180]) -> [PASS][16] +2
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-kbl1/igt@i915_susp...@fence-restore-untiled.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17817/shard-kbl4/igt@i915_susp...@fence-restore-untiled.html
* {igt@kms_atomic_transition@plane-all-modeset-transition-fencing@pipe-c}:
- shard-kbl: [DMESG-WARN][17] ([i915#165] / [i915#180]) ->
[PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-kbl2/igt@kms_atomic_transition@plane-all-modeset-transition-fenc...@pipe-c.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17817/shard-kbl4/igt@kms_atomic_transition@plane-all-modeset-transition-fenc...@pipe-c.html
* igt@kms_cursor_legacy@cursora-vs-flipb-toggle:
- shard-glk: [DMESG-FAIL][19] ([i915#1925] / [i915#1926]) ->
[PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-glk7/igt@kms_cursor_leg...@cursora-vs-flipb-toggle.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17817/shard-glk6/igt@kms_cursor_leg...@cursora-vs-flipb-toggle.html
* igt@kms_fbcon_fbt@psr-suspend:
- shard-iclb: [INCOMPLETE][21] ([i915#1185]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-iclb3/igt@kms_fbcon_...@psr-suspend.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17817/shard-iclb1/igt@kms_fbcon_...@psr-suspend.html
* {igt@kms_flip@flip-vs-expired-vblank@b-edp1}:
- shard-skl: [FAIL][23] ([i915#79]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl5/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html
[24]:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Add a few asserts around handling of i915_request_is_active() (rev5)
== Series Details == Series: series starting with [1/2] drm/i915: Add a few asserts around handling of i915_request_is_active() (rev5) URL : https://patchwork.freedesktop.org/series/77781/ State : success == Summary == CI Bug Log - changes from CI_DRM_8553 -> Patchwork_17819 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/index.html Known issues Here are the changes found in Patchwork_17819 that come from known issues: ### IGT changes ### Warnings * igt@i915_pm_rpm@module-reload: - fi-glk-dsi: [TIMEOUT][1] ([i915#1288]) -> [TIMEOUT][2] ([i915#1288] / [i915#1958]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/fi-glk-dsi/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/fi-glk-dsi/igt@i915_pm_...@module-reload.html [i915#1288]: https://gitlab.freedesktop.org/drm/intel/issues/1288 [i915#1958]: https://gitlab.freedesktop.org/drm/intel/issues/1958 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_8553 -> Patchwork_17819 CI-20190529: 20190529 CI_DRM_8553: 9f1b8b4fcb466dc714b1f825fd93e3bbd29c7de6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5683: 757b6e72d546fd2dbc3801a73796d67b0854021b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17819: 2192b036ccb7f6662671f183f6f643094daeb84b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 2192b036ccb7 drm/i915: Check for awaits on still currently executing requests 3e1109ea7977 drm/i915: Add a few asserts around handling of i915_request_is_active() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17819/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v3] i915/gem_exec_balancer: Randomise bonded submission
Quoting Tvrtko Ursulin (2020-05-29 16:08:25)
>
> On 29/05/2020 14:58, 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.
> >
> > v2: Test both immediate submission and fenced submission
> > v3: Copy-n-paste a single context variant
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > tests/i915/gem_exec_balancer.c | 341 +
> > 1 file changed, 341 insertions(+)
> >
> > diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
> > index 80ae82416..07fe45920 100644
> > --- a/tests/i915/gem_exec_balancer.c
> > +++ b/tests/i915/gem_exec_balancer.c
> > @@ -1154,6 +1154,342 @@ static void bonded_semaphore(int i915)
> > gem_context_destroy(i915, ctx);
> > }
> >
> > +static void __bonded_pair(int i915,
> > + const struct i915_engine_class_instance *siblings,
> > + unsigned int count,
> > + unsigned int flags,
> > + unsigned long *out)
> > +#define B_FENCE 0x1
> > +#define B_HOSTILE 0x2
> > +#define B_MANY 0x4
> > +{
> > + 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;
> > + unsigned int spinner;
> > + igt_spin_t *a;
> > + int timeline;
> > + uint32_t A;
> > +
> > + srandom(getpid());
> > +
> > + spinner = IGT_SPIN_POLL_RUN;
> > + if (flags & B_HOSTILE)
> > + spinner |= IGT_SPIN_NO_PREEMPTION;
> > +
> > + A = gem_context_create(i915);
> > + set_load_balancer(i915, A, siblings, count, NULL);
> > + a = igt_spin_new(i915, A, .flags = spinner);
> > + igt_spin_end(a);
> > + gem_sync(i915, a->handle);
> > +
> > + timeline = sw_sync_timeline_create();
> > +
> > + igt_until_timeout(2) {
> > + unsigned int master;
> > + int fence;
> > +
> > + master = 1;
> > + if (flags & B_MANY)
> > + master = rand() % count + 1;
> > +
> > + fence = -1;
> > + if (flags & B_FENCE)
> > + fence = sw_sync_timeline_create_fence(timeline,
> > + cycles + 1);
> > +
> > + igt_spin_reset(a);
> > + a->execbuf.flags = master | I915_EXEC_FENCE_OUT;
> > + if (fence != -1) {
> > + a->execbuf.rsvd2 = fence;
> > + a->execbuf.flags |= I915_EXEC_FENCE_IN;
> > + }
> > + gem_execbuf_wr(i915, >execbuf);
> > +
> > + batch.handle = create_semaphore_to_spinner(i915, a);
> > + execbuf.rsvd1 = a->execbuf.rsvd1;
> > + execbuf.rsvd2 = a->execbuf.rsvd2 >> 32;
> > + do {
> > + execbuf.flags = rand() % count + 1;
> > + } while (execbuf.flags == master);
> > + execbuf.flags |= I915_EXEC_FENCE_SUBMIT;
> > + gem_execbuf(i915, );
> > + gem_close(i915, batch.handle);
> > +
> > + if (fence != -1) {
> > + sw_sync_timeline_inc(timeline, 1);
> > + close(fence);
> > + }
> > + close(a->execbuf.rsvd2 >> 32);
> > +
> > + gem_sync(i915, a->handle);
> > +
> > + cycles++;
> > + }
> > +
> > + close(timeline);
> > + igt_spin_free(i915, a);
> > + gem_context_destroy(i915, A);
> > +
> > + *out = cycles;
> > +}
> > +
> > +static void bonded_pair(int i915)
> > +{
> > + static const unsigned int phases[] = {
> > + 0,
> > + B_FENCE,
> > + B_MANY,
> > + B_HOSTILE,
> > + B_HOSTILE | B_FENCE,
> > + };
> > + unsigned long *cycles;
> > +
> > + /*
> > + * 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));
> > +
> > + cycles = mmap(0, 4096, PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0);
> > +
> > + for (int class = 0; class < 32; class++) {
> > + struct i915_engine_class_instance *siblings;
> > + unsigned int count;
> > +
> > + siblings = list_engines(i915, 1u << class, );
> > + if (count < 2)
> > + continue;
> > +
> > + igt_info("Class %u, 1 thread\n", class);
> > + for (int i = 0; i < ARRAY_SIZE(phases); i++) {
> > +
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v3] i915/gem_exec_balancer: Randomise bonded submission
On 29/05/2020 14:58, 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.
v2: Test both immediate submission and fenced submission
v3: Copy-n-paste a single context variant
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_exec_balancer.c | 341 +
1 file changed, 341 insertions(+)
diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
index 80ae82416..07fe45920 100644
--- a/tests/i915/gem_exec_balancer.c
+++ b/tests/i915/gem_exec_balancer.c
@@ -1154,6 +1154,342 @@ static void bonded_semaphore(int i915)
gem_context_destroy(i915, ctx);
}
+static void __bonded_pair(int i915,
+ const struct i915_engine_class_instance *siblings,
+ unsigned int count,
+ unsigned int flags,
+ unsigned long *out)
+#define B_FENCE 0x1
+#define B_HOSTILE 0x2
+#define B_MANY 0x4
+{
+ 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;
+ unsigned int spinner;
+ igt_spin_t *a;
+ int timeline;
+ uint32_t A;
+
+ srandom(getpid());
+
+ spinner = IGT_SPIN_POLL_RUN;
+ if (flags & B_HOSTILE)
+ spinner |= IGT_SPIN_NO_PREEMPTION;
+
+ A = gem_context_create(i915);
+ set_load_balancer(i915, A, siblings, count, NULL);
+ a = igt_spin_new(i915, A, .flags = spinner);
+ igt_spin_end(a);
+ gem_sync(i915, a->handle);
+
+ timeline = sw_sync_timeline_create();
+
+ igt_until_timeout(2) {
+ unsigned int master;
+ int fence;
+
+ master = 1;
+ if (flags & B_MANY)
+ master = rand() % count + 1;
+
+ fence = -1;
+ if (flags & B_FENCE)
+ fence = sw_sync_timeline_create_fence(timeline,
+ cycles + 1);
+
+ igt_spin_reset(a);
+ a->execbuf.flags = master | I915_EXEC_FENCE_OUT;
+ if (fence != -1) {
+ a->execbuf.rsvd2 = fence;
+ a->execbuf.flags |= I915_EXEC_FENCE_IN;
+ }
+ gem_execbuf_wr(i915, >execbuf);
+
+ batch.handle = create_semaphore_to_spinner(i915, a);
+ execbuf.rsvd1 = a->execbuf.rsvd1;
+ execbuf.rsvd2 = a->execbuf.rsvd2 >> 32;
+ do {
+ execbuf.flags = rand() % count + 1;
+ } while (execbuf.flags == master);
+ execbuf.flags |= I915_EXEC_FENCE_SUBMIT;
+ gem_execbuf(i915, );
+ gem_close(i915, batch.handle);
+
+ if (fence != -1) {
+ sw_sync_timeline_inc(timeline, 1);
+ close(fence);
+ }
+ close(a->execbuf.rsvd2 >> 32);
+
+ gem_sync(i915, a->handle);
+
+ cycles++;
+ }
+
+ close(timeline);
+ igt_spin_free(i915, a);
+ gem_context_destroy(i915, A);
+
+ *out = cycles;
+}
+
+static void bonded_pair(int i915)
+{
+ static const unsigned int phases[] = {
+ 0,
+ B_FENCE,
+ B_MANY,
+ B_HOSTILE,
+ B_HOSTILE | B_FENCE,
+ };
+ unsigned long *cycles;
+
+ /*
+* 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));
+
+ cycles = mmap(0, 4096, PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0);
+
+ for (int class = 0; class < 32; class++) {
+ struct i915_engine_class_instance *siblings;
+ unsigned int count;
+
+ siblings = list_engines(i915, 1u << class, );
+ if (count < 2)
+ continue;
+
+ igt_info("Class %u, 1 thread\n", class);
+ for (int i = 0; i < ARRAY_SIZE(phases); i++) {
+ cycles[0] = 0;
+ __bonded_pair(i915,
+ siblings, count,
+ phases[i],
+ [0]);
+ gem_quiescent_gpu(i915);
+ igt_info("%s %s %s submission, %lu cycles\n",
+phases[i] & B_HOSTILE ? "Non-preemptible" :
Re: [Intel-gfx] [PATCH 06/13] ocfs2: use new sysctl subdir helper register_sysctl_subdir()
On Fri, May 29, 2020 at 11:49:12AM +, Luis Chamberlain wrote: > Yikes, sense, you're right. Nope, I left the random config tests to > 0day. Will fix, thanks! Yeah, I do the same for randconfig, but I always do an "allmodconfig" build before sending stuff. It's a good smoke test. -- Kees Cook ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCHES] uaccess i915
On Fri, May 29, 2020 at 08:06:14AM +0300, Jani Nikula wrote: > On Fri, 29 May 2020, Al Viro wrote: > > Low-hanging fruit in i915 uaccess-related stuff. > > There's some subtler stuff remaining after that; these > > are the simple ones. > > Please Cc: intel-gfx@lists.freedesktop.org for i915 changes. Will do. Do you want me to resend those (or post them there separately, or...)? > Also added Chris who I believe will be able to best review the changes. FWIW, the branch is in git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git #uaccess.i915 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Add a few asserts around handling of i915_request_is_active() (rev4)
== Series Details == Series: series starting with [1/2] drm/i915: Add a few asserts around handling of i915_request_is_active() (rev4) URL : https://patchwork.freedesktop.org/series/77781/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8553_full -> Patchwork_17816_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17816_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17816_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_17816_full: ### IGT changes ### Possible regressions * igt@kms_lease@page_flip_implicit_plane: - shard-skl: [PASS][1] -> [TIMEOUT][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl1/igt@kms_lease@page_flip_implicit_plane.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17816/shard-skl5/igt@kms_lease@page_flip_implicit_plane.html Warnings * igt@i915_pm_dc@dc6-dpms: - shard-skl: [FAIL][3] ([i915#454]) -> [TIMEOUT][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl1/igt@i915_pm...@dc6-dpms.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17816/shard-skl5/igt@i915_pm...@dc6-dpms.html * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-blt: - shard-skl: [SKIP][5] ([fdo#109271]) -> [TIMEOUT][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl1/igt@kms_frontbuffer_track...@fbc-2p-primscrn-cur-indfb-draw-blt.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17816/shard-skl5/igt@kms_frontbuffer_track...@fbc-2p-primscrn-cur-indfb-draw-blt.html Known issues Here are the changes found in Patchwork_17816_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_dc@dc6-psr: - shard-skl: [PASS][7] -> [FAIL][8] ([i915#454]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl6/igt@i915_pm...@dc6-psr.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17816/shard-skl4/igt@i915_pm...@dc6-psr.html * igt@kms_cursor_crc@pipe-a-cursor-64x64-random: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#54] / [i915#93] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-64x64-random.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17816/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-64x64-random.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: - shard-hsw: [PASS][11] -> [DMESG-FAIL][12] ([i915#1926]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-hsw2/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17816/shard-hsw8/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-blt: - shard-skl: [PASS][13] -> [TIMEOUT][14] ([i915#123]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl1/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-shrfb-draw-blt.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17816/shard-skl5/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-shrfb-draw-blt.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180] / [i915#95]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-apl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17816/shard-apl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#265]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17816/shard-skl9/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109642] / [fdo#111068]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-iclb2/igt@kms_psr2...@frontbuffer.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17816/shard-iclb1/igt@kms_psr2...@frontbuffer.html * igt@kms_psr@psr2_cursor_render: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) [21]:
[Intel-gfx] [PATCH v2] drm/i915: Check for awaits on still currently executing requests
With the advent of preempt-to-busy, a request may still be on the GPU as
we unwind. And in the case of a unpreemptible [due to HW] request, that
request will remain indefinitely on the GPU even though we have
returned it back to our submission queue, and cleared the active bit.
We only run the execution callbacks on transferring the request from our
submission queue to the execution queue, but if this is a bonded request
that the HW is waiting for, we will not submit it (as we wait for a
fresh execution) even though it is still being executed.
As we know that there are always preemption points between requests, we
know that only the currently executing request may be still active even
though we have cleared the flag. However, we do not precisely know which
request is in ELSP[0] due to a delay in processing events, and
furthermore we only store the last request in a context in our state
tracker.
Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
Testcase: igt/gem_exec_balancer/bonded-dual
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 49 -
1 file changed, 48 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index e5aba6824e26..c5d7220de529 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -363,6 +363,53 @@ static void __llist_add(struct llist_node *node, struct
llist_head *head)
head->first = node;
}
+static struct i915_request * const *
+__engine_active(struct intel_engine_cs *engine)
+{
+ return READ_ONCE(engine->execlists.active);
+}
+
+static bool __request_in_flight(const struct i915_request *signal)
+{
+ struct i915_request * const *port, *rq;
+ bool inflight = false;
+
+ if (!i915_request_is_ready(signal))
+ return false;
+
+ /*
+* Even if we have unwound the request, it may still be on
+* the GPU (preempt-to-busy). If that request is inside an
+* unpreemptible critical section, it will not be removed. Some
+* GPU functions may even be stuck waiting for the paired request
+* (__await_execution) to be submitted and cannot be preempted
+* until the bond is executing.
+*
+* As we know that there are always preemption points between
+* requests, we know that only the currently executing request
+* may be still active even though we have cleared the flag.
+* However, we can't rely on our tracking of ELSP[0] to known
+* which request is currently active and so maybe stuck, as
+* the tracking maybe an event behind. Instead assume that
+* if the context is still inflight, then it is still active
+* even if the active flag has been cleared.
+*/
+ if (!intel_context_inflight(signal->context))
+ return false;
+
+ rcu_read_lock();
+ for (port = __engine_active(signal->engine); (rq = *port); port++) {
+ if (rq->context == signal->context) {
+ inflight = i915_seqno_passed(rq->fence.seqno,
+signal->fence.seqno);
+ break;
+ }
+ }
+ rcu_read_unlock();
+
+ return inflight;
+}
+
static int
__await_execution(struct i915_request *rq,
struct i915_request *signal,
@@ -393,7 +440,7 @@ __await_execution(struct i915_request *rq,
}
spin_lock_irq(>lock);
- if (i915_request_is_active(signal)) {
+ if (i915_request_is_active(signal) || __request_in_flight(signal)) {
if (hook) {
hook(rq, >fence);
i915_request_put(signal);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Discard a misplaced GGTT vma
Quoting Mika Kuoppala (2020-05-29 15:24:17) > Chris Wilson writes: > > > Across the many users of the GGTT vma (internal objects, mmapings, > > display etc), we may end up with conflicting requirements for the > > placement. Currently, we try to resolve the conflict by unbinding the > > vma and rebinding it to match the new constraints; over time we will end > > up with a GGTT that matches the most strict constraints over all > > concurrent users. However, this causes a problem if the vma is currently > > in use as we must wait until it is idle before moving it. But there is > > no restriction on the number of views we may (apart from the limited > > we may...have/impose? we may have/create/use >From the object point-of-view, there is a presumption that is a single normal view with as many partials as required (one expects up to obj->size/chunk_size). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Discard a misplaced GGTT vma
Chris Wilson writes:
> Across the many users of the GGTT vma (internal objects, mmapings,
> display etc), we may end up with conflicting requirements for the
> placement. Currently, we try to resolve the conflict by unbinding the
> vma and rebinding it to match the new constraints; over time we will end
> up with a GGTT that matches the most strict constraints over all
> concurrent users. However, this causes a problem if the vma is currently
> in use as we must wait until it is idle before moving it. But there is
> no restriction on the number of views we may (apart from the limited
we may...have/impose?
-Mika
> size of the GGTT itself), and so if the active vma does not meet our
> requirements, try and build a new one!
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem.c | 44 +
> 1 file changed, 44 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 0cbcb9f54e7d..29a4594ddef2 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -933,6 +933,44 @@ void i915_gem_runtime_suspend(struct drm_i915_private
> *i915)
> }
> }
>
> +static bool
> +discard_ggtt_vma(struct i915_vma *vma, const struct i915_ggtt_view *view)
> +{
> + const struct i915_ggtt_view discard = {
> + .type = I915_GGTT_VIEW_PARTIAL,
> + };
> + struct drm_i915_gem_object *obj = vma->obj;
> +
> + spin_lock(>vma.lock);
> + if (i915_vma_compare(vma, vma->vm, )) {
> + struct rb_node *rb, **p;
> +
> + rb_erase(>obj_node, >vma.tree);
> + vma->ggtt_view = discard;
> +
> + rb = NULL;
> + p = >vma.tree.rb_node;
> + while (*p) {
> + struct i915_vma *pos;
> + long cmp;
> +
> + rb = *p;
> + pos = rb_entry(rb, struct i915_vma, obj_node);
> +
> + cmp = i915_vma_compare(pos, vma->vm, );
> + if (cmp < 0)
> + p = >rb_right;
> + else
> + p = >rb_left;
> + }
> + rb_link_node(>obj_node, rb, p);
> + rb_insert_color(>obj_node, >vma.tree);
> + }
> + spin_unlock(>vma.lock);
> +
> + return i915_vma_compare(vma, vma->vm, view);
> +}
> +
> struct i915_vma *
> i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
>const struct i915_ggtt_view *view,
> @@ -979,6 +1017,7 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
> return ERR_PTR(-ENOSPC);
> }
>
> +new_vma:
> vma = i915_vma_instance(obj, >vm, view);
> if (IS_ERR(vma))
> return vma;
> @@ -993,6 +1032,11 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object
> *obj,
> return ERR_PTR(-ENOSPC);
> }
>
> + if (i915_vma_is_pinned(vma) || i915_vma_is_active(vma)) {
> + if (discard_ggtt_vma(vma, view))
> + goto new_vma;
> + }
> +
> ret = i915_vma_unbind(vma);
> if (ret)
> return ERR_PTR(ret);
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Discard a misplaced GGTT vma
== Series Details == Series: drm/i915: Discard a misplaced GGTT vma URL : https://patchwork.freedesktop.org/series/77786/ State : success == Summary == CI Bug Log - changes from CI_DRM_8553 -> Patchwork_17818 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/index.html Known issues Here are the changes found in Patchwork_17818 that come from known issues: ### IGT changes ### Warnings * igt@i915_pm_rpm@module-reload: - fi-glk-dsi: [TIMEOUT][1] ([i915#1288]) -> [TIMEOUT][2] ([i915#1288] / [i915#1958]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/fi-glk-dsi/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/fi-glk-dsi/igt@i915_pm_...@module-reload.html [i915#1288]: https://gitlab.freedesktop.org/drm/intel/issues/1288 [i915#1958]: https://gitlab.freedesktop.org/drm/intel/issues/1958 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_8553 -> Patchwork_17818 CI-20190529: 20190529 CI_DRM_8553: 9f1b8b4fcb466dc714b1f825fd93e3bbd29c7de6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5683: 757b6e72d546fd2dbc3801a73796d67b0854021b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17818: c92c12f5de38ad38c279bbcd5f131392a3c78732 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c92c12f5de38 drm/i915: Discard a misplaced GGTT vma == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: Check for awaits on still currently executing requests
Quoting Chris Wilson (2020-05-29 13:28:51)
> With the advent of preempt-to-busy, a request may still be on the GPU as
> we unwind. And in the case of a unpreemptible [due to HW] request, that
> request will remain indefinitely on the GPU even though we have
> returned it back to our submission queue, and cleared the active bit.
>
> We only run the execution callbacks on transferring the request from our
> submission queue to the execution queue, but if this is a bonded request
> that the HW is waiting for, we will not submit it (as we wait for a
> fresh execution) even though it is still being executed.
>
> As we know that there are always preemption points between requests, we
> know that only the currently executing request may be still active even
> though we have cleared the flag.
>
> Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
> Testcase: igt/gem_exec_balancer/bonded-dual
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_request.c | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_request.c
> b/drivers/gpu/drm/i915/i915_request.c
> index e5aba6824e26..2f0e9a63002d 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -363,6 +363,23 @@ static void __llist_add(struct llist_node *node, struct
> llist_head *head)
> head->first = node;
> }
>
> +static bool __request_in_flight(const struct i915_request *signal)
> +{
> + /*
> +* Even if we have unwound the request, it may still be on
> +* the GPU (preempt-to-busy). If that request is inside an
> +* unpreemptible critical section, it will not be removed. Some
> +* GPU functions may even be stuck waiting for the paired request
> +* (__await_execution) to be submitted and cannot be preempted
> +* until the bond is executing.
> +*
> +* As we know that there are always preemption points between
> +* requests, we know that only the currently executing request
> +* may be still active even though we have cleared the flag.
> +*/
> + return signal == execlists_active(>engine->execlists);
Iff and only if there is one request in ELSP[0]. And presuming
process_csb has been run recently.
I think I'm back at intel_context_inflight(signal).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/5] uaccess: Selectively open read or write user access
On Fri, 2020-04-03 at 07:20:51 UTC, Christophe Leroy wrote: > When opening user access to only perform reads, only open read access. > When opening user access to only perform writes, only open write > access. > > Signed-off-by: Christophe Leroy > Reviewed-by: Kees Cook Applied to powerpc topic/uaccess, thanks. https://git.kernel.org/powerpc/c/41cd780524674082b037e7c8461f90c5e42103f0 cheers ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/13] random: simplify sysctl declaration with register_sysctl_subdir()
On 2020/5/29 18:26, Greg KH wrote:
On Fri, May 29, 2020 at 07:41:06AM +, Luis Chamberlain wrote:
From: Xiaoming Ni
Move random_table sysctl from kernel/sysctl.c to drivers/char/random.c
and use register_sysctl_subdir() to help remove the clutter out of
kernel/sysctl.c.
Signed-off-by: Xiaoming Ni
Signed-off-by: Luis Chamberlain
---
drivers/char/random.c | 14 --
include/linux/sysctl.h | 1 -
kernel/sysctl.c| 5 -
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index a7cf6aa65908..73fd4b6e9c18 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -2101,8 +2101,7 @@ static int proc_do_entropy(struct ctl_table *table, int
write,
}
static int sysctl_poolsize = INPUT_POOL_WORDS * 32;
-extern struct ctl_table random_table[];
-struct ctl_table random_table[] = {
+static struct ctl_table random_table[] = {
{
.procname = "poolsize",
.data = _poolsize,
@@ -2164,6 +2163,17 @@ struct ctl_table random_table[] = {
#endif
{ }
};
+
+/*
+ * rand_initialize() is called before sysctl_init(),
+ * so we cannot call register_sysctl_init() in rand_initialize()
+ */
+static int __init random_sysctls_init(void)
+{
+ register_sysctl_subdir("kernel", "random", random_table);
No error checking?
:(
It was my mistake, I forgot to add a comment here.
Same as the comment of register_sysctl_init(),
There is almost no failure here during the system initialization phase,
and failure in time does not affect the main function.
Thanks
Xiaoming Ni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/13] firmware_loader: simplify sysctl declaration with register_sysctl_subdir()
On 2020/5/29 18:26, Greg KH wrote:
On Fri, May 29, 2020 at 07:41:04AM +, Luis Chamberlain wrote:
From: Xiaoming Ni
Move the firmware config sysctl table to fallback_table.c and use the
new register_sysctl_subdir() helper. This removes the clutter from
kernel/sysctl.c.
Signed-off-by: Xiaoming Ni
Signed-off-by: Luis Chamberlain
---
drivers/base/firmware_loader/fallback.c | 4
drivers/base/firmware_loader/fallback.h | 11 ++
drivers/base/firmware_loader/fallback_table.c | 22 +--
include/linux/sysctl.h| 1 -
kernel/sysctl.c | 7 --
5 files changed, 35 insertions(+), 10 deletions(-)
So it now takes more lines than the old stuff? :(
CONFIG_FW_LOADER = m
Before cleaning, no matter whether ko is loaded or not, the sysctl
interface will be created, but now we need to add register and
unregister interfaces, so the number of lines of code has increased
diff --git a/drivers/base/firmware_loader/fallback.c
b/drivers/base/firmware_loader/fallback.c
index d9ac7296205e..8190653ae9a3 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -200,12 +200,16 @@ static struct class firmware_class = {
int register_sysfs_loader(void)
{
+ int ret = register_firmware_config_sysctl();
+ if (ret != 0)
+ return ret;
checkpatch :(
This is my fault, thanks for your guidance
return class_register(_class);
And if that fails?
Yes, it is better to call register_firmware_config_sysctl() after
class_register().
thanks for your guidance.
}
void unregister_sysfs_loader(void)
{
class_unregister(_class);
+ unregister_firmware_config_sysctl();
}
static ssize_t firmware_loading_show(struct device *dev,
diff --git a/drivers/base/firmware_loader/fallback.h
b/drivers/base/firmware_loader/fallback.h
index 06f4577733a8..7d2cb5f6ceb8 100644
--- a/drivers/base/firmware_loader/fallback.h
+++ b/drivers/base/firmware_loader/fallback.h
@@ -42,6 +42,17 @@ void fw_fallback_set_default_timeout(void);
int register_sysfs_loader(void);
void unregister_sysfs_loader(void);
+#ifdef CONFIG_SYSCTL
+extern int register_firmware_config_sysctl(void);
+extern void unregister_firmware_config_sysctl(void);
+#else
+static inline int register_firmware_config_sysctl(void)
+{
+ return 0;
+}
+static inline void unregister_firmware_config_sysctl(void) { }
+#endif /* CONFIG_SYSCTL */
+
#else /* CONFIG_FW_LOADER_USER_HELPER */
static inline int firmware_fallback_sysfs(struct firmware *fw, const char
*name,
struct device *device,
diff --git a/drivers/base/firmware_loader/fallback_table.c
b/drivers/base/firmware_loader/fallback_table.c
index 46a731dede6f..4234aa5ee5df 100644
--- a/drivers/base/firmware_loader/fallback_table.c
+++ b/drivers/base/firmware_loader/fallback_table.c
@@ -24,7 +24,7 @@ struct firmware_fallback_config fw_fallback_config = {
EXPORT_SYMBOL_NS_GPL(fw_fallback_config, FIRMWARE_LOADER_PRIVATE);
#ifdef CONFIG_SYSCTL
-struct ctl_table firmware_config_table[] = {
+static struct ctl_table firmware_config_table[] = {
{
.procname = "force_sysfs_fallback",
.data = _fallback_config.force_sysfs_fallback,
@@ -45,4 +45,22 @@ struct ctl_table firmware_config_table[] = {
},
{ }
};
-#endif
+
+static struct ctl_table_header *hdr;
+int register_firmware_config_sysctl(void)
+{
+ if (hdr)
+ return -EEXIST;
How can hdr be set?
It's my mistake, register_firmware_config_sysctl() is not exported,
there will be no repeated calls.
thanks for your guidance.
+ hdr = register_sysctl_subdir("kernel", "firmware_config",
+firmware_config_table);
+ if (!hdr)
+ return -ENOMEM;
+ return 0;
+}
+
+void unregister_firmware_config_sysctl(void)
+{
+ if (hdr)
+ unregister_sysctl_table(hdr);
Why can't unregister_sysctl_table() take a null pointer value?
Sorry, I didn't notice that the unregister_sysctl_table() already checks
the input parameters.
thanks for your guidance.
And what sets 'hdr' (worst name for a static variable) to NULL so that
it knows not to be unregistered again as it looks like
register_firmware_config_sysctl() could be called multiple times.
How about renaming hdr to firmware_config_sysct_table_header?
+ if (hdr)
+ return -EEXIST;
After deleting this code in register_firmware_config_sysctl(), and
considering register_firmware_config_sysctl() and
unregister_firmware_config_sysctl() are not exported, whether there is
no need to add "hdr = NULL;" ?
Thanks
Xiaoming Ni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/13] sysctl: add helper to register empty subdir
Luis Chamberlain writes:
> The way to create a subdirectory from the base set of directories
> is a bit obscure, so provide a helper which makes this clear, and
> also helps remove boiler plate code required to do this work.
I agreee calling:
register_sysctl("fs/binfmt_misc", sysctl_mount_point)
is a bit obscure but if you are going to make a wrapper
please make it the trivial one liner above.
Say something that looks like:
struct sysctl_header *register_sysctl_mount_point(const char *path)
{
return register_sysctl(path, sysctl_mount_point);
}
And yes please talk about a mount point and not an empty dir, as these
are permanently empty directories to serve as mount points. There are
some subtle but important permission checks this allows in the case of
unprivileged mounts.
Further code like this belong in proc_sysctl.c next to all of the code
it is related to so that it is easier to see how to refactor the code if
necessary.
Eric
>
> Signed-off-by: Luis Chamberlain
> ---
> include/linux/sysctl.h | 7 +++
> kernel/sysctl.c| 16 +---
> 2 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
> index 33a471b56345..89c92390e6de 100644
> --- a/include/linux/sysctl.h
> +++ b/include/linux/sysctl.h
> @@ -208,6 +208,8 @@ extern void register_sysctl_init(const char *path, struct
> ctl_table *table,
> extern struct ctl_table_header *register_sysctl_subdir(const char *base,
> const char *subdir,
> struct ctl_table *table);
> +extern void register_sysctl_empty_subdir(const char *base, const char
> *subdir);
> +
> void do_sysctl_args(void);
>
> extern int pwrsw_enabled;
> @@ -231,6 +233,11 @@ inline struct ctl_table_header
> *register_sysctl_subdir(const char *base,
> return NULL;
> }
>
> +static inline void register_sysctl_empty_subdir(const char *base,
> + const char *subdir)
> +{
> +}
> +
> static inline struct ctl_table_header *register_sysctl_paths(
> const struct ctl_path *path, struct ctl_table *table)
> {
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index f9a35325d5d5..460532cd5ac8 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -3188,13 +3188,17 @@ struct ctl_table_header *register_sysctl_subdir(const
> char *base,
> { }
> };
>
> - if (!table->procname)
> + if (table != sysctl_mount_point && !table->procname)
> goto out;
>
> hdr = register_sysctl_table(base_table);
> if (unlikely(!hdr)) {
> - pr_err("failed when creating subdirectory sysctl %s/%s/%s\n",
> -base, subdir, table->procname);
> + if (table != sysctl_mount_point)
> + pr_err("failed when creating subdirectory sysctl
> %s/%s/%s\n",
> +base, subdir, table->procname);
> + else
> + pr_err("failed when creating empty subddirectory
> %s/%s\n",
> +base, subdir);
> goto out;
> }
> kmemleak_not_leak(hdr);
> @@ -3202,6 +3206,12 @@ struct ctl_table_header *register_sysctl_subdir(const
> char *base,
> return hdr;
> }
> EXPORT_SYMBOL_GPL(register_sysctl_subdir);
> +
> +void register_sysctl_empty_subdir(const char *base,
> + const char *subdir)
> +{
> + register_sysctl_subdir(base, subdir, sysctl_mount_point);
> +}
> #endif /* CONFIG_SYSCTL */
> /*
> * No sense putting this after each symbol definition, twice,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/13] sysctl: add new register_sysctl_subdir() helper
Luis Chamberlain writes: > Often enough all we need to do is create a subdirectory so that > we can stuff sysctls underneath it. However, *if* that directory > was already created early on the boot sequence we really have no > need to use the full boiler plate code for it, we can just use > local variables to help us guide sysctl to place the new leaf files. > > So use a helper to do precisely this. Reset restart. This is patch is total nonsense. - You are using register_sysctl_table which as I believe I have mentioned is a deprecated compatibility wrapper. The point of spring house cleaning is to get off of the deprecated functions isn't it? - You are using the old nasty form for creating directories instead of just passing in a path. - None of this is even remotely necessary. The directories are created automatically if you just register their entries. Eric ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/gem: Replace user_access_begin by user_write_access_begin
On Fri, 2020-04-03 at 07:20:52 UTC, Christophe Leroy wrote: > When i915_gem_execbuffer2_ioctl() is using user_access_begin(), > that's only to perform unsafe_put_user() so use > user_write_access_begin() in order to only open write access. > > Signed-off-by: Christophe Leroy > Reviewed-by: Kees Cook Applied to powerpc topic/uaccess, thanks. https://git.kernel.org/powerpc/c/b44f687386875b714dae2afa768e73401e45c21c cheers ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/13] sysctl: add new register_sysctl_subdir() helper
ebied...@xmission.com (Eric W. Biederman) writes: > Luis Chamberlain writes: > >> Often enough all we need to do is create a subdirectory so that >> we can stuff sysctls underneath it. However, *if* that directory >> was already created early on the boot sequence we really have no >> need to use the full boiler plate code for it, we can just use >> local variables to help us guide sysctl to place the new leaf files. >> >> So use a helper to do precisely this. > > Reset restart. This is patch is total nonsense. > > - You are using register_sysctl_table which as I believe I have > mentioned is a deprecated compatibility wrapper. The point of > spring house cleaning is to get off of the deprecated functions > isn't it? > > - You are using the old nasty form for creating directories instead > of just passing in a path. > > - None of this is even remotely necessary. The directories > are created automatically if you just register their entries. Oh. *blink* The poor naming threw me off. This is a clumsy and poorly named version of register_sysctl(); Yes. This change is totally unnecessary. Eric ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/5] powerpc/uaccess: Implement user_read_access_begin and user_write_access_begin
On Fri, 2020-04-03 at 07:20:53 UTC, Christophe Leroy wrote: > Add support for selective read or write user access with > user_read_access_begin/end and user_write_access_begin/end. > > Signed-off-by: Christophe Leroy > Reviewed-by: Kees Cook Applied to powerpc topic/uaccess-ppc, thanks. https://git.kernel.org/powerpc/c/4fe5cda9f89d0aea8e915b7c96ae34bda4e12e51 cheers ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/13] cdrom: use new sysctl subdir helper register_sysctl_subdir()
Luis Chamberlain writes:
> This simplifies the code considerably. The following coccinelle
With register_sysctl the code would read:
cdrom_sysctl_header = register_sysctl("dev/cdrom", cdrom_table);
Please go that direction. Thank you.
Eric
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
On Thu, May 28, 2020 at 06:00:44PM -0600, Logan Gunthorpe wrote: > > This issue is most likely in the i915 driver and is most likely caused by > > the driver not respecting the return value of the dma_map_ops::map_sg > > function. You can see the driver ignoring the return value here: > > https://github.com/torvalds/linux/blob/7e0165b2f1a912a06e381e91f0f4e495f4ac3736/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c#L51 > > > > Previously this didn’t cause issues because the intel map_sg always > > returned the same number of elements as the input scatter gather list but > > with the change to this dma-iommu api this is no longer the case. I wasn’t > > able to track the bug down to a specific line of code unfortunately. Mark did a big audit into the map_sg API abuse and initially had some i915 patches, but then gave up on them with this comment: "The biggest TODO is DRM/i915 driver and I don't feel brave enough to fix it fully. The driver creatively uses sg_table->orig_nents to store the size of the allocate scatterlist and ignores the number of the entries returned by dma_map_sg function. In this patchset I only fixed the sg_table objects exported by dmabuf related functions. I hope that I didn't break anything there." it would be really nice if the i915 maintainers could help with sorting that API abuse out. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/5] uaccess: Add user_read_access_begin/end and user_write_access_begin/end
On Fri, 2020-04-03 at 07:20:50 UTC, Christophe Leroy wrote: > Some architectures like powerpc64 have the capability to separate > read access and write access protection. > For get_user() and copy_from_user(), powerpc64 only open read access. > For put_user() and copy_to_user(), powerpc64 only open write access. > But when using unsafe_get_user() or unsafe_put_user(), > user_access_begin open both read and write. > > Other architectures like powerpc book3s 32 bits only allow write > access protection. And on this architecture protection is an heavy > operation as it requires locking/unlocking per segment of 256Mbytes. > On those architecture it is therefore desirable to do the unlocking > only for write access. (Note that book3s/32 ranges from very old > powermac from the 90's with powerpc 601 processor, till modern > ADSL boxes with PowerQuicc II processors for instance so it > is still worth considering.) > > In order to avoid any risk based of hacking some variable parameters > passed to user_access_begin/end that would allow hacking and > leaving user access open or opening too much, it is preferable to > use dedicated static functions that can't be overridden. > > Add a user_read_access_begin and user_read_access_end to only open > read access. > > Add a user_write_access_begin and user_write_access_end to only open > write access. > > By default, when undefined, those new access helpers default on the > existing user_access_begin and user_access_end. > > Signed-off-by: Christophe Leroy > Reviewed-by: Kees Cook Applied to powerpc topic/uaccess, thanks. https://git.kernel.org/powerpc/c/999a22890cb183b918e4372395d24426a755cef2 cheers ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v3] 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.
v2: Test both immediate submission and fenced submission
v3: Copy-n-paste a single context variant
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_exec_balancer.c | 341 +
1 file changed, 341 insertions(+)
diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
index 80ae82416..07fe45920 100644
--- a/tests/i915/gem_exec_balancer.c
+++ b/tests/i915/gem_exec_balancer.c
@@ -1154,6 +1154,342 @@ static void bonded_semaphore(int i915)
gem_context_destroy(i915, ctx);
}
+static void __bonded_pair(int i915,
+ const struct i915_engine_class_instance *siblings,
+ unsigned int count,
+ unsigned int flags,
+ unsigned long *out)
+#define B_FENCE 0x1
+#define B_HOSTILE 0x2
+#define B_MANY 0x4
+{
+ 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;
+ unsigned int spinner;
+ igt_spin_t *a;
+ int timeline;
+ uint32_t A;
+
+ srandom(getpid());
+
+ spinner = IGT_SPIN_POLL_RUN;
+ if (flags & B_HOSTILE)
+ spinner |= IGT_SPIN_NO_PREEMPTION;
+
+ A = gem_context_create(i915);
+ set_load_balancer(i915, A, siblings, count, NULL);
+ a = igt_spin_new(i915, A, .flags = spinner);
+ igt_spin_end(a);
+ gem_sync(i915, a->handle);
+
+ timeline = sw_sync_timeline_create();
+
+ igt_until_timeout(2) {
+ unsigned int master;
+ int fence;
+
+ master = 1;
+ if (flags & B_MANY)
+ master = rand() % count + 1;
+
+ fence = -1;
+ if (flags & B_FENCE)
+ fence = sw_sync_timeline_create_fence(timeline,
+ cycles + 1);
+
+ igt_spin_reset(a);
+ a->execbuf.flags = master | I915_EXEC_FENCE_OUT;
+ if (fence != -1) {
+ a->execbuf.rsvd2 = fence;
+ a->execbuf.flags |= I915_EXEC_FENCE_IN;
+ }
+ gem_execbuf_wr(i915, >execbuf);
+
+ batch.handle = create_semaphore_to_spinner(i915, a);
+ execbuf.rsvd1 = a->execbuf.rsvd1;
+ execbuf.rsvd2 = a->execbuf.rsvd2 >> 32;
+ do {
+ execbuf.flags = rand() % count + 1;
+ } while (execbuf.flags == master);
+ execbuf.flags |= I915_EXEC_FENCE_SUBMIT;
+ gem_execbuf(i915, );
+ gem_close(i915, batch.handle);
+
+ if (fence != -1) {
+ sw_sync_timeline_inc(timeline, 1);
+ close(fence);
+ }
+ close(a->execbuf.rsvd2 >> 32);
+
+ gem_sync(i915, a->handle);
+
+ cycles++;
+ }
+
+ close(timeline);
+ igt_spin_free(i915, a);
+ gem_context_destroy(i915, A);
+
+ *out = cycles;
+}
+
+static void bonded_pair(int i915)
+{
+ static const unsigned int phases[] = {
+ 0,
+ B_FENCE,
+ B_MANY,
+ B_HOSTILE,
+ B_HOSTILE | B_FENCE,
+ };
+ unsigned long *cycles;
+
+ /*
+* 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));
+
+ cycles = mmap(0, 4096, PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0);
+
+ for (int class = 0; class < 32; class++) {
+ struct i915_engine_class_instance *siblings;
+ unsigned int count;
+
+ siblings = list_engines(i915, 1u << class, );
+ if (count < 2)
+ continue;
+
+ igt_info("Class %u, 1 thread\n", class);
+ for (int i = 0; i < ARRAY_SIZE(phases); i++) {
+ cycles[0] = 0;
+ __bonded_pair(i915,
+ siblings, count,
+ phases[i],
+ [0]);
+ gem_quiescent_gpu(i915);
+ igt_info("%s %s %s submission, %lu cycles\n",
+phases[i] & B_HOSTILE ? "Non-preemptible" :
"Preemptible",
+phases[i] &
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add a few asserts around handling of i915_request_is_active()
On 29/05/2020 09:58, Chris Wilson wrote:
Let's assert that we only call the execute callbacks on making the
request active, and that we do not execute the request without calling
the callbacks.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 0d810a62ff46..e5aba6824e26 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -192,6 +192,7 @@ static void __notify_execute_cb(struct i915_request *rq)
lockdep_assert_held(>lock);
+ GEM_BUG_ON(!i915_request_is_active(rq));
if (llist_empty(>execute_cb))
return;
@@ -518,15 +519,15 @@ bool __i915_request_submit(struct i915_request *request)
if (!test_and_set_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags)) {
list_move_tail(>sched.link, >active.requests);
clear_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
+ __notify_execute_cb(request);
}
+ GEM_BUG_ON(!llist_empty(>execute_cb));
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags) &&
!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags) &&
!i915_request_enable_breadcrumb(request))
intel_engine_signal_breadcrumbs(engine);
- __notify_execute_cb(request);
-
spin_unlock(>lock);
return result;
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 0/9] shmem helper untangling
On Mon, 11 May 2020 11:35:45 +0200 Daniel Vetter wrote: > Hi all, > > I've started this a while ago, with the idea to move shmem helpers over > to dma_resv_lock. Big prep work for that was to untangle the layering > between functions called by drivers, and functions used to implement > drm_gem_object_funcs. > > I didn't ever get to the locking part, but I think the cleanup here are > worth it stand-alone still. > > Comments, review and testing very much welcome. > > Cheers, Daniel > > Daniel Vetter (9): > drm/msm: Don't call dma_buf_vunmap without _vmap > drm/gem: WARN if drm_gem_get_pages is called on a private obj > drm/doc: Some polish for shmem helpers > drm/virtio: Call the right shmem helpers > drm/udl: Don't call get/put_pages on imported dma-buf > drm/shmem-helpers: Don't call get/put_pages on imported dma-buf in > vmap > drm/shmem-helpers: Redirect mmap for imported dma-buf > drm/shmem-helpers: Ensure get_pages is not called on imported dma-buf > drm/shmem-helpers: Simplify dma-buf importing With the fix suggested on patch 9 (or something similar to initialize pages_use_count to 1 when importing a dma-buf), this patchset seems to work on panfrost: Tested-by: Boris Brezillon > > Documentation/gpu/drm-kms-helpers.rst | 12 --- > Documentation/gpu/drm-mm.rst| 12 +++ > drivers/gpu/drm/drm_gem.c | 8 ++ > drivers/gpu/drm/drm_gem_shmem_helper.c | 128 ++-- > drivers/gpu/drm/msm/msm_gem.c | 3 +- > drivers/gpu/drm/udl/udl_gem.c | 22 ++-- > drivers/gpu/drm/virtio/virtgpu_object.c | 2 +- > 7 files changed, 111 insertions(+), 76 deletions(-) > ___ 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/dsi: Drop double check for ACPI companion device
== Series Details == Series: drm/i915/dsi: Drop double check for ACPI companion device URL : https://patchwork.freedesktop.org/series/77785/ State : success == Summary == CI Bug Log - changes from CI_DRM_8553 -> Patchwork_17817 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17817/index.html Known issues Here are the changes found in Patchwork_17817 that come from known issues: ### IGT changes ### Warnings * igt@i915_pm_rpm@module-reload: - fi-glk-dsi: [TIMEOUT][1] ([i915#1288]) -> [TIMEOUT][2] ([i915#1288] / [i915#1958]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/fi-glk-dsi/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17817/fi-glk-dsi/igt@i915_pm_...@module-reload.html [i915#1288]: https://gitlab.freedesktop.org/drm/intel/issues/1288 [i915#1958]: https://gitlab.freedesktop.org/drm/intel/issues/1958 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_8553 -> Patchwork_17817 CI-20190529: 20190529 CI_DRM_8553: 9f1b8b4fcb466dc714b1f825fd93e3bbd29c7de6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5683: 757b6e72d546fd2dbc3801a73796d67b0854021b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17817: faa5526ffe05ac74e4dfa156fa1d893db0c9835e @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == faa5526ffe05 drm/i915/dsi: Drop double check for ACPI companion device == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17817/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2] i915/gem_exec_balancer: Randomise bonded submission
On 28/05/2020 21:31, 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.
v2: Test both immediate submission and fenced submission
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_exec_balancer.c | 172 +
1 file changed, 172 insertions(+)
diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
index 80ae82416..04b14dd3a 100644
--- a/tests/i915/gem_exec_balancer.c
+++ b/tests/i915/gem_exec_balancer.c
@@ -1154,6 +1154,175 @@ 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,
+ unsigned int flags,
+ unsigned long *out)
+#define BD_FENCE 0x1
+#define BD_HOSTILE 0x2
+#define BD_MANY 0x4
+{
+ 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;
+ unsigned int spinner;
+ igt_spin_t *a, *b;
+ int timeline;
+ uint32_t A, B;
+
+ srandom(getpid());
+
+ spinner = IGT_SPIN_POLL_RUN;
+ if (flags & BD_HOSTILE)
+ spinner |= IGT_SPIN_NO_PREEMPTION;
+
+ A = gem_context_create(i915);
+ set_load_balancer(i915, A, siblings, count, NULL);
+ a = igt_spin_new(i915, A, .flags = spinner);
+ igt_spin_end(a);
+ gem_sync(i915, a->handle);
+
+ B = gem_context_create(i915);
+ set_load_balancer(i915, B, siblings, count, NULL);
+ b = igt_spin_new(i915, B, .flags = spinner);
+ igt_spin_end(b);
+ gem_sync(i915, b->handle);
+
+ timeline = sw_sync_timeline_create();
+
+ igt_until_timeout(2) {
+ unsigned int master;
+ int fence;
+
+ master = 1;
+ if (flags & BD_MANY)
+ master = rand() % count + 1;
+
+ fence = -1;
+ if (flags & BD_FENCE)
+ fence = sw_sync_timeline_create_fence(timeline,
+ cycles + 1);
+
+ igt_spin_reset(a);
+ a->execbuf.flags = master | I915_EXEC_FENCE_OUT;
+ if (fence != -1) {
+ a->execbuf.rsvd2 = fence;
+ a->execbuf.flags |= I915_EXEC_FENCE_IN;
+ }
+ gem_execbuf_wr(i915, >execbuf);
+
+ igt_spin_reset(b);
+ b->execbuf.flags = master | I915_EXEC_FENCE_OUT;
+ if (fence != -1) {
+ b->execbuf.rsvd2 = fence;
+ b->execbuf.flags |= I915_EXEC_FENCE_IN;
+ }
+ gem_execbuf_wr(i915, >execbuf);
+
+ if (rand() % 1)
+ igt_swap(a, b);
+
+ batch.handle = create_semaphore_to_spinner(i915, a);
+ execbuf.rsvd1 = a->execbuf.rsvd1;
+ execbuf.rsvd2 = a->execbuf.rsvd2 >> 32;
+ 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->execbuf.rsvd2 >> 32;
+ do {
+ execbuf.flags = rand() % count + 1;
+ } while (execbuf.flags == master);
+ execbuf.flags |= I915_EXEC_FENCE_SUBMIT;
+ gem_execbuf(i915, );
+ gem_close(i915, batch.handle);
+
+ if (fence != -1) {
+ sw_sync_timeline_inc(timeline, 1);
+ close(fence);
+ }
Would it be worth adding another submit pattern: Am + As/Bs, Bm + Bs/As?
A bit awkward to implement, probably would need copy & paste of the
function.
+ close(a->execbuf.rsvd2 >> 32);
+ close(b->execbuf.rsvd2 >> 32);
+
+ gem_sync(i915, a->handle);
+ gem_sync(i915, b->handle);
+
+ cycles++;
+ }
+
+ *out = cycles;
+
+ close(timeline);
+
+ 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)
+{
+ unsigned long *cycles;
+
+ /*
+* The purpose of bonded
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Add a few asserts around handling of i915_request_is_active() (rev4)
== Series Details == Series: series starting with [1/2] drm/i915: Add a few asserts around handling of i915_request_is_active() (rev4) URL : https://patchwork.freedesktop.org/series/77781/ State : success == Summary == CI Bug Log - changes from CI_DRM_8553 -> Patchwork_17816 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17816/index.html Known issues Here are the changes found in Patchwork_17816 that come from known issues: ### IGT changes ### Warnings * igt@i915_pm_rpm@module-reload: - fi-glk-dsi: [TIMEOUT][1] ([i915#1288]) -> [TIMEOUT][2] ([i915#1288] / [i915#1958]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/fi-glk-dsi/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17816/fi-glk-dsi/igt@i915_pm_...@module-reload.html [i915#1288]: https://gitlab.freedesktop.org/drm/intel/issues/1288 [i915#1958]: https://gitlab.freedesktop.org/drm/intel/issues/1958 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_8553 -> Patchwork_17816 CI-20190529: 20190529 CI_DRM_8553: 9f1b8b4fcb466dc714b1f825fd93e3bbd29c7de6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5683: 757b6e72d546fd2dbc3801a73796d67b0854021b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17816: 8d7f23d402092041673d05543408cfb36eaa118e @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 8d7f23d40209 drm/i915: Check for awaits on still currently executing requests fb44414e530c drm/i915: Add a few asserts around handling of i915_request_is_active() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17816/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Discard a misplaced GGTT vma
Across the many users of the GGTT vma (internal objects, mmapings,
display etc), we may end up with conflicting requirements for the
placement. Currently, we try to resolve the conflict by unbinding the
vma and rebinding it to match the new constraints; over time we will end
up with a GGTT that matches the most strict constraints over all
concurrent users. However, this causes a problem if the vma is currently
in use as we must wait until it is idle before moving it. But there is
no restriction on the number of views we may (apart from the limited
size of the GGTT itself), and so if the active vma does not meet our
requirements, try and build a new one!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 44 +
1 file changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0cbcb9f54e7d..29a4594ddef2 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -933,6 +933,44 @@ void i915_gem_runtime_suspend(struct drm_i915_private
*i915)
}
}
+static bool
+discard_ggtt_vma(struct i915_vma *vma, const struct i915_ggtt_view *view)
+{
+ const struct i915_ggtt_view discard = {
+ .type = I915_GGTT_VIEW_PARTIAL,
+ };
+ struct drm_i915_gem_object *obj = vma->obj;
+
+ spin_lock(>vma.lock);
+ if (i915_vma_compare(vma, vma->vm, )) {
+ struct rb_node *rb, **p;
+
+ rb_erase(>obj_node, >vma.tree);
+ vma->ggtt_view = discard;
+
+ rb = NULL;
+ p = >vma.tree.rb_node;
+ while (*p) {
+ struct i915_vma *pos;
+ long cmp;
+
+ rb = *p;
+ pos = rb_entry(rb, struct i915_vma, obj_node);
+
+ cmp = i915_vma_compare(pos, vma->vm, );
+ if (cmp < 0)
+ p = >rb_right;
+ else
+ p = >rb_left;
+ }
+ rb_link_node(>obj_node, rb, p);
+ rb_insert_color(>obj_node, >vma.tree);
+ }
+ spin_unlock(>vma.lock);
+
+ return i915_vma_compare(vma, vma->vm, view);
+}
+
struct i915_vma *
i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
const struct i915_ggtt_view *view,
@@ -979,6 +1017,7 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
return ERR_PTR(-ENOSPC);
}
+new_vma:
vma = i915_vma_instance(obj, >vm, view);
if (IS_ERR(vma))
return vma;
@@ -993,6 +1032,11 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
return ERR_PTR(-ENOSPC);
}
+ if (i915_vma_is_pinned(vma) || i915_vma_is_active(vma)) {
+ if (discard_ggtt_vma(vma, view))
+ goto new_vma;
+ }
+
ret = i915_vma_unbind(vma);
if (ret)
return ERR_PTR(ret);
--
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/i915: Add a few asserts around handling of i915_request_is_active() (rev3)
== Series Details == Series: series starting with [1/2] drm/i915: Add a few asserts around handling of i915_request_is_active() (rev3) URL : https://patchwork.freedesktop.org/series/77781/ State : success == Summary == CI Bug Log - changes from CI_DRM_8552_full -> Patchwork_17814_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17814_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-tglb: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [FAIL][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]) ([i915#1926]) -> ([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], [PASS][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_8552/shard-tglb8/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb8/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb8/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb8/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb7/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb7/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb7/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb7/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb6/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb6/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb5/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb5/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb3/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb3/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb3/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb2/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb2/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb2/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb1/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb1/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb1/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17814/shard-tglb8/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17814/shard-tglb8/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17814/shard-tglb8/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17814/shard-tglb8/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17814/shard-tglb7/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17814/shard-tglb7/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17814/shard-tglb7/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17814/shard-tglb6/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17814/shard-tglb6/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17814/shard-tglb6/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17814/shard-tglb6/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17814/shard-tglb5/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17814/shard-tglb5/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17814/shard-tglb5/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17814/shard-tglb3/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17814/shard-tglb3/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17814/shard-tglb3/boot.html [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17814/shard-tglb3/boot.html [44]:
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Track i915_vma with its own reference counter
== Series Details ==
Series: series starting with [1/2] drm/i915: Track i915_vma with its own
reference counter
URL : https://patchwork.freedesktop.org/series/77784/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8553 -> Patchwork_17815
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17815 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17815, 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_17815/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17815:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@evict:
- fi-bsw-kefka: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/fi-bsw-kefka/igt@i915_selftest@l...@evict.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17815/fi-bsw-kefka/igt@i915_selftest@l...@evict.html
- fi-kbl-soraka: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/fi-kbl-soraka/igt@i915_selftest@l...@evict.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17815/fi-kbl-soraka/igt@i915_selftest@l...@evict.html
* igt@i915_selftest@live@gem_contexts:
- fi-icl-u2: [PASS][5] -> [INCOMPLETE][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/fi-icl-u2/igt@i915_selftest@live@gem_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17815/fi-icl-u2/igt@i915_selftest@live@gem_contexts.html
* igt@i915_selftest@live@requests:
- fi-bsw-nick:[PASS][7] -> [INCOMPLETE][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/fi-bsw-nick/igt@i915_selftest@l...@requests.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17815/fi-bsw-nick/igt@i915_selftest@l...@requests.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gem_contexts:
- {fi-tgl-dsi}: [PASS][9] -> [INCOMPLETE][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/fi-tgl-dsi/igt@i915_selftest@live@gem_contexts.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17815/fi-tgl-dsi/igt@i915_selftest@live@gem_contexts.html
Known issues
Here are the changes found in Patchwork_17815 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-skl-6700k2: [PASS][11] -> [INCOMPLETE][12] ([i915#151])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/fi-skl-6700k2/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17815/fi-skl-6700k2/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gem_contexts:
- fi-bsw-n3050: [PASS][13] -> [INCOMPLETE][14] ([i915#392])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/fi-bsw-n3050/igt@i915_selftest@live@gem_contexts.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17815/fi-bsw-n3050/igt@i915_selftest@live@gem_contexts.html
* igt@i915_selftest@live@sanitycheck:
- fi-skl-lmem:[PASS][15] -> [INCOMPLETE][16] ([i915#198])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/fi-skl-lmem/igt@i915_selftest@l...@sanitycheck.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17815/fi-skl-lmem/igt@i915_selftest@l...@sanitycheck.html
* igt@kms_chamelium@dp-crc-fast:
- fi-cml-u2: [PASS][17] -> [FAIL][18] ([i915#262])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17815/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [SKIP][19] ([fdo#109271]) -> [FAIL][20] ([i915#62] /
[i915#95])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17815/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151
[i915#198]: https://gitlab.freedesktop.org/drm/intel/issues/198
[i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262
[i915#392]:
[Intel-gfx] [PATCH v1] drm/i915/dsi: Drop double check for ACPI companion device
acpi_dev_get_resources() does perform the NULL pointer check against
ACPI companion device which is given as function parameter. Thus,
there is no need to duplicate this check in the caller.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 24
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
index 574dcfec9577..6f9e08cda964 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
@@ -426,23 +426,19 @@ static void i2c_acpi_find_adapter(struct intel_dsi
*intel_dsi,
{
struct drm_device *drm_dev = intel_dsi->base.base.dev;
struct device *dev = _dev->pdev->dev;
- struct acpi_device *acpi_dev;
+ struct acpi_device *acpi_dev = ACPI_COMPANION(dev);
struct list_head resource_list;
struct i2c_adapter_lookup lookup;
- acpi_dev = ACPI_COMPANION(dev);
- if (acpi_dev) {
- memset(, 0, sizeof(lookup));
- lookup.slave_addr = slave_addr;
- lookup.intel_dsi = intel_dsi;
- lookup.dev_handle = acpi_device_handle(acpi_dev);
-
- INIT_LIST_HEAD(_list);
- acpi_dev_get_resources(acpi_dev, _list,
- i2c_adapter_lookup,
- );
- acpi_dev_free_resource_list(_list);
- }
+ memset(, 0, sizeof(lookup));
+ lookup.slave_addr = slave_addr;
+ lookup.intel_dsi = intel_dsi;
+ lookup.dev_handle = acpi_device_handle(acpi_dev);
+
+ INIT_LIST_HEAD(_list);
+ acpi_dev_get_resources(acpi_dev, _list,
+ i2c_adapter_lookup, );
+ acpi_dev_free_resource_list(_list);
}
#else
static inline void i2c_acpi_find_adapter(struct intel_dsi *intel_dsi,
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915: Track i915_vma with its own reference counter
== Series Details == Series: series starting with [1/2] drm/i915: Track i915_vma with its own reference counter URL : https://patchwork.freedesktop.org/series/77784/ 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: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/gem/i915_gem_context.c:2280:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2281:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2282:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2283:17: error: bad integer constant expression +drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/sysfs_engines.c:61:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:62:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:66:10: error: bad integer constant expression +drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1423:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1477:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/intel_wakeref.c:137:19: warning: context imbalance in 'wakeref_auto_timeout' - unexpected unlock +./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
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: Track i915_vma with its own reference counter
== Series Details == Series: series starting with [1/2] drm/i915: Track i915_vma with its own reference counter URL : https://patchwork.freedesktop.org/series/77784/ State : warning == Summary == $ dim checkpatch origin/drm-tip 5ddf1d723df5 drm/i915: Track i915_vma with its own reference counter -:2232: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #2232: FILE: drivers/gpu/drm/i915/gt/intel_gtt.h:267: + spinlock_t lock; -:4006: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #4006: FILE: drivers/gpu/drm/i915/i915_vma.h:386: + spinlock_t lock; -:4253: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #4253: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:394: + if (offset < hole_start + vma->size) -:4264: WARNING:LONG_LINE: line over 100 characters #4264: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:402: + __func__, p->name, err, npages, prime, offset, -:4274: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #4274: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:419: + if (offset + vma->node.size > hole_end) -:4290: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #4290: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:428: + if (offset < hole_start + vma->node.size) -:4302: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #4302: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:451: + if (offset + vma->node.size > hole_end) -:4318: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #4318: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:460: + if (offset < hole_start + vma->node.size) -:4330: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #4330: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:484: + if (offset + vma->size >= hole_end) -:4346: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #4346: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:493: + if (offset < hole_start + vma->size) -:4358: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #4358: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:516: + if (offset + vma->size >= hole_end) total: 0 errors, 9 warnings, 2 checks, 4783 lines checked fd7715d1f5e5 drm/i915: Discard a misplaced GGTT vma ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] drm/i915: Check for awaits on still currently executing requests
With the advent of preempt-to-busy, a request may still be on the GPU as
we unwind. And in the case of a unpreemptible [due to HW] request, that
request will remain indefinitely on the GPU even though we have
returned it back to our submission queue, and cleared the active bit.
We only run the execution callbacks on transferring the request from our
submission queue to the execution queue, but if this is a bonded request
that the HW is waiting for, we will not submit it (as we wait for a
fresh execution) even though it is still being executed.
As we know that there are always preemption points between requests, we
know that only the currently executing request may be still active even
though we have cleared the flag.
Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
Testcase: igt/gem_exec_balancer/bonded-dual
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index e5aba6824e26..2f0e9a63002d 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -363,6 +363,23 @@ static void __llist_add(struct llist_node *node, struct
llist_head *head)
head->first = node;
}
+static bool __request_in_flight(const struct i915_request *signal)
+{
+ /*
+* Even if we have unwound the request, it may still be on
+* the GPU (preempt-to-busy). If that request is inside an
+* unpreemptible critical section, it will not be removed. Some
+* GPU functions may even be stuck waiting for the paired request
+* (__await_execution) to be submitted and cannot be preempted
+* until the bond is executing.
+*
+* As we know that there are always preemption points between
+* requests, we know that only the currently executing request
+* may be still active even though we have cleared the flag.
+*/
+ return signal == execlists_active(>engine->execlists);
+}
+
static int
__await_execution(struct i915_request *rq,
struct i915_request *signal,
@@ -393,7 +410,7 @@ __await_execution(struct i915_request *rq,
}
spin_lock_irq(>lock);
- if (i915_request_is_active(signal)) {
+ if (i915_request_is_active(signal) || __request_in_flight(signal)) {
if (hook) {
hook(rq, >fence);
i915_request_put(signal);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/13] sysctl: add new register_sysctl_subdir() helper
On Fri, May 29, 2020 at 11:13:21AM +0300, Jani Nikula wrote: > On Fri, 29 May 2020, Luis Chamberlain wrote: > > Often enough all we need to do is create a subdirectory so that > > we can stuff sysctls underneath it. However, *if* that directory > > was already created early on the boot sequence we really have no > > need to use the full boiler plate code for it, we can just use > > local variables to help us guide sysctl to place the new leaf files. > > I find it hard to figure out the lifetime requirements for the tables > passed in; when it's okay to use local variables and when you need > longer lifetimes. It's not documented, everyone appears to be using > static tables for this. It's far from obvious. I agree 2000% that it is not obvious. What made me consider it was that I *knew* that the base directory would already exist, so it wouldn't make sense for the code to rely on earlier parts of a table if part of the hierarchy already existed. In fact, a *huge* part of the due dilligence on this and futre series on this cleanup will be to be 100% sure that the base path is already created. And so this use is obviously dangerous, you just *need* to know that the base path is created before. Non-posted changes also deal with link order to help address this in other places, given that link order controls how *initcalls() (early_initcall(), late_initcall(), etc) are ordered if you have multiple of these. I had a link order series long ago which augmented our ability to make things clearer at a link order. Eventually I believe this will become more important, specially as we end up wanting to async more code. For now, we can only rely on manual code inspection for ensuring proper ordering. Part of the implicit aspects of this cleanup is to slowly make these things clearer for each base path. So... the "fs" base path will actually end up being created in fs/sysctl.c after we are *fully* done with the fs sysctl cleanups. Luis ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/13] firmware_loader: simplify sysctl declaration with register_sysctl_subdir()
On Fri, May 29, 2020 at 12:26:13PM +0200, Greg KH wrote: > On Fri, May 29, 2020 at 07:41:04AM +, Luis Chamberlain wrote: > > From: Xiaoming Ni > > > > Move the firmware config sysctl table to fallback_table.c and use the > > new register_sysctl_subdir() helper. This removes the clutter from > > kernel/sysctl.c. > > > > Signed-off-by: Xiaoming Ni > > Signed-off-by: Luis Chamberlain > > --- > > drivers/base/firmware_loader/fallback.c | 4 > > drivers/base/firmware_loader/fallback.h | 11 ++ > > drivers/base/firmware_loader/fallback_table.c | 22 +-- > > include/linux/sysctl.h| 1 - > > kernel/sysctl.c | 7 -- > > 5 files changed, 35 insertions(+), 10 deletions(-) > > So it now takes more lines than the old stuff? :( Pretty much agreed with the other changes, thanks for the review! But this diff-stat change, indeed, it is unfortunate that we end up with more code here than before. We'll try to reduce it instead somehow, however in some cases during this spring-cleaning, since the goal is to move code from one file to another, it *may* require more code. So it won't always be negative. But we'll try! Luis ___ 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, 27 May 2020 11:47:57 +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.
>
> 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 ++-
For atmel-hlcdc:
Reviewed-by: Boris Brezillon
> 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
Re: [Intel-gfx] [PATCH 2/2] drm/atomic-helper: reset vblank on crtc reset
On Wed, May 27, 2020 at 11:47:57AM +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.
Note that mxsfb has accidentally totally broken vblank support, so doesn't
need fixing at all. I'll update that paragraph when merging.
>
> 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
Ping for some more eyes and maybe testing on this patch here.
Thanks, 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
[Intel-gfx] [PATCH 2/2] drm/i915: Discard a misplaced GGTT vma
Across the many users of the GGTT vma (internal objects, mmapings,
display etc), we may end up with conflicting requirements for the
placement. Currently, we try to resolve the conflict by unbinding the
vma and rebinding it to match the new constraints; over time we will end
up with a GGTT that matches the most strict constraints over all
concurrent users. However, this causes a problem if the vma is currently
in use as we must wait until it is idle before moving it. But there is
no restriction on the number of views we may (apart from the limited
size of the GGTT itself), and so if the active vma does not meet our
requirements, try and build a new one!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 46 +
1 file changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 921bbd4a9265..69c1e52ca254 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -878,6 +878,44 @@ void i915_gem_runtime_suspend(struct drm_i915_private
*i915)
}
}
+static bool
+discard_ggtt_vma(struct i915_vma *vma, const struct i915_ggtt_view *view)
+{
+ const struct i915_ggtt_view discard = {
+ .type = I915_GGTT_VIEW_PARTIAL,
+ };
+ struct drm_i915_gem_object *obj = vma->obj;
+
+ spin_lock(>vma.lock);
+ if (i915_vma_compare(vma, vma->vm, )) {
+ struct rb_node *rb, **p;
+
+ rb_erase(>obj_node, >vma.tree);
+ vma->ggtt_view = discard;
+
+ rb = NULL;
+ p = >vma.tree.rb_node;
+ while (*p) {
+ struct i915_vma *pos;
+ long cmp;
+
+ rb = *p;
+ pos = rb_entry(rb, struct i915_vma, obj_node);
+
+ cmp = i915_vma_compare(pos, vma->vm, );
+ if (cmp < 0)
+ p = >rb_right;
+ else
+ p = >rb_left;
+ }
+ rb_link_node(>obj_node, rb, p);
+ rb_insert_color(>obj_node, >vma.tree);
+ }
+ spin_unlock(>vma.lock);
+
+ return i915_vma_compare(vma, vma->vm, view);
+}
+
struct i915_vma *
i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
const struct i915_ggtt_view *view,
@@ -924,6 +962,7 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
return ERR_PTR(-ENOSPC);
}
+new_vma:
vma = i915_vma_instance(obj, >vm, view);
if (IS_ERR(vma))
return vma;
@@ -943,6 +982,13 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
}
}
+ if (i915_vma_is_pinned(vma) || i915_vma_is_active(vma)) {
+ if (discard_ggtt_vma(vma, view)) {
+ i915_vma_put(vma);
+ goto new_vma;
+ }
+ }
+
ret = i915_vma_unbind(vma);
if (ret)
goto err_put;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/13] ocfs2: use new sysctl subdir helper register_sysctl_subdir()
On Fri, May 29, 2020 at 01:23:19AM -0700, Kees Cook wrote:
> On Fri, May 29, 2020 at 07:41:01AM +, Luis Chamberlain wrote:
> > This simplifies the code considerably. The following coccinelle
> > SmPL grammar rule was used to transform this code.
> >
> > // pycocci sysctl-subdir.cocci fs/ocfs2/stackglue.c
> >
> > @c1@
> > expression E1;
> > identifier subdir, sysctls;
> > @@
> >
> > static struct ctl_table subdir[] = {
> > {
> > .procname = E1,
> > .maxlen = 0,
> > .mode = 0555,
> > .child = sysctls,
> > },
> > { }
> > };
> >
> > @c2@
> > identifier c1.subdir;
> >
> > expression E2;
> > identifier base;
> > @@
> >
> > static struct ctl_table base[] = {
> > {
> > .procname = E2,
> > .maxlen = 0,
> > .mode = 0555,
> > .child = subdir,
> > },
> > { }
> > };
> >
> > @c3@
> > identifier c2.base;
> > identifier header;
> > @@
> >
> > header = register_sysctl_table(base);
> >
> > @r1 depends on c1 && c2 && c3@
> > expression c1.E1;
> > identifier c1.subdir, c1.sysctls;
> > @@
> >
> > -static struct ctl_table subdir[] = {
> > - {
> > - .procname = E1,
> > - .maxlen = 0,
> > - .mode = 0555,
> > - .child = sysctls,
> > - },
> > - { }
> > -};
> >
> > @r2 depends on c1 && c2 && c3@
> > identifier c1.subdir;
> >
> > expression c2.E2;
> > identifier c2.base;
> > @@
> > -static struct ctl_table base[] = {
> > - {
> > - .procname = E2,
> > - .maxlen = 0,
> > - .mode = 0555,
> > - .child = subdir,
> > - },
> > - { }
> > -};
> >
> > @r3 depends on c1 && c2 && c3@
> > expression c1.E1;
> > identifier c1.sysctls;
> > expression c2.E2;
> > identifier c2.base;
> > identifier c3.header;
> > @@
> >
> > header =
> > -register_sysctl_table(base);
> > +register_sysctl_subdir(E2, E1, sysctls);
> >
> > Generated-by: Coccinelle SmPL
> >
> > Signed-off-by: Luis Chamberlain
> > ---
> > fs/ocfs2/stackglue.c | 27 ---
> > 1 file changed, 4 insertions(+), 23 deletions(-)
> >
> > diff --git a/fs/ocfs2/stackglue.c b/fs/ocfs2/stackglue.c
> > index a191094694c6..addafced7f59 100644
> > --- a/fs/ocfs2/stackglue.c
> > +++ b/fs/ocfs2/stackglue.c
> > @@ -677,28 +677,8 @@ static struct ctl_table ocfs2_mod_table[] = {
> > },
> > { }
> > };
> > -
> > -static struct ctl_table ocfs2_kern_table[] = {
> > - {
> > - .procname = "ocfs2",
> > - .data = NULL,
> > - .maxlen = 0,
> > - .mode = 0555,
> > - .child = ocfs2_mod_table
> > - },
> > - { }
> > -};
> > -
> > -static struct ctl_table ocfs2_root_table[] = {
> > - {
> > - .procname = "fs",
> > - .data = NULL,
> > - .maxlen = 0,
> > - .mode = 0555,
> > - .child = ocfs2_kern_table
> > - },
> > - { }
> > -};
> > + .data = NULL,
> > + .data = NULL,
>
> The conversion script doesn't like the .data field assignments. ;)
>
> Was this series built with allmodconfig? I would have expected this to
> blow up very badly. :)
Yikes, sense, you're right. Nope, I left the random config tests to
0day. Will fix, thanks!
Luis
___
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
On Wed, May 27, 2020 at 02:02:12PM +0200, Thomas Zimmermann wrote:
>
> 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
Thanks for your review, patch queued up.
-Daniel
>
> > ---
> > 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.
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Add a few asserts around handling of i915_request_is_active() (rev3)
== Series Details == Series: series starting with [1/2] drm/i915: Add a few asserts around handling of i915_request_is_active() (rev3) URL : https://patchwork.freedesktop.org/series/77781/ State : success == Summary == CI Bug Log - changes from CI_DRM_8552 -> Patchwork_17814 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17814/index.html Changes --- No changes found Participating hosts (50 -> 42) -- 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_8552 -> Patchwork_17814 CI-20190529: 20190529 CI_DRM_8552: cd4a9b47339259e3a98601fff14438f17fd2d7dc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5683: 757b6e72d546fd2dbc3801a73796d67b0854021b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17814: e47881371cdf60297c9afbe65f4f6fedac2ba27e @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == e47881371cdf drm/i915: Check for awaits on still currently executing requests 681101f60674 drm/i915: Add a few asserts around handling of i915_request_is_active() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17814/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Add a few asserts around handling of i915_request_is_active() (rev2)
== Series Details == Series: series starting with [1/2] drm/i915: Add a few asserts around handling of i915_request_is_active() (rev2) URL : https://patchwork.freedesktop.org/series/77781/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8552 -> Patchwork_17813 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17813 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17813, 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_17813/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17813: ### IGT changes ### Possible regressions * igt@runner@aborted: - fi-bwr-2160:NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17813/fi-bwr-2160/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_17813 that come from known issues: ### IGT changes ### Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [SKIP][2] ([fdo#109271]) -> [FAIL][3] ([i915#62] / [i915#95]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17813/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (50 -> 43) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8552 -> Patchwork_17813 CI-20190529: 20190529 CI_DRM_8552: cd4a9b47339259e3a98601fff14438f17fd2d7dc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5683: 757b6e72d546fd2dbc3801a73796d67b0854021b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17813: 39714304d5c296d6f0737d6bf32b9c4a6e901d79 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 39714304d5c2 drm/i915: Check for awaits on still currently executing requests 711dac999c56 drm/i915: Add a few asserts around handling of i915_request_is_active() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17813/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 series starting with [1/2] drm/i915: Add a few asserts around handling of i915_request_is_active()
== Series Details == Series: series starting with [1/2] drm/i915: Add a few asserts around handling of i915_request_is_active() URL : https://patchwork.freedesktop.org/series/77781/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8552_full -> Patchwork_17812_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17812_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17812_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_17812_full: ### IGT changes ### Possible regressions * igt@gem_softpin@noreloc-s3: - shard-kbl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-kbl2/igt@gem_soft...@noreloc-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17812/shard-kbl3/igt@gem_soft...@noreloc-s3.html * igt@kms_lease@page_flip_implicit_plane: - shard-glk: NOTRUN -> [TIMEOUT][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17812/shard-glk7/igt@kms_lease@page_flip_implicit_plane.html Known issues Here are the changes found in Patchwork_17812_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-tglb: ([PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [FAIL][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], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb8/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb8/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb8/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb8/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb7/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb7/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb7/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb7/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb6/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb6/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb6/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb5/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb5/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb5/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb5/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb3/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb3/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb3/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb2/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb2/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb2/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb1/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8552/shard-tglb1/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17812/shard-tglb8/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17812/shard-tglb8/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17812/shard-tglb8/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17812/shard-tglb7/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17812/shard-tglb7/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17812/shard-tglb7/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17812/shard-tglb6/boot.html [36]:
Re: [Intel-gfx] [PATCH 11/13] random: simplify sysctl declaration with register_sysctl_subdir()
On Fri, May 29, 2020 at 07:41:06AM +, Luis Chamberlain wrote:
> From: Xiaoming Ni
>
> Move random_table sysctl from kernel/sysctl.c to drivers/char/random.c
> and use register_sysctl_subdir() to help remove the clutter out of
> kernel/sysctl.c.
>
> Signed-off-by: Xiaoming Ni
> Signed-off-by: Luis Chamberlain
> ---
> drivers/char/random.c | 14 --
> include/linux/sysctl.h | 1 -
> kernel/sysctl.c| 5 -
> 3 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index a7cf6aa65908..73fd4b6e9c18 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -2101,8 +2101,7 @@ static int proc_do_entropy(struct ctl_table *table, int
> write,
> }
>
> static int sysctl_poolsize = INPUT_POOL_WORDS * 32;
> -extern struct ctl_table random_table[];
> -struct ctl_table random_table[] = {
> +static struct ctl_table random_table[] = {
> {
> .procname = "poolsize",
> .data = _poolsize,
> @@ -2164,6 +2163,17 @@ struct ctl_table random_table[] = {
> #endif
> { }
> };
> +
> +/*
> + * rand_initialize() is called before sysctl_init(),
> + * so we cannot call register_sysctl_init() in rand_initialize()
> + */
> +static int __init random_sysctls_init(void)
> +{
> + register_sysctl_subdir("kernel", "random", random_table);
No error checking?
:(
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/13] firmware_loader: simplify sysctl declaration with register_sysctl_subdir()
On Fri, May 29, 2020 at 07:41:04AM +, Luis Chamberlain wrote:
> From: Xiaoming Ni
>
> Move the firmware config sysctl table to fallback_table.c and use the
> new register_sysctl_subdir() helper. This removes the clutter from
> kernel/sysctl.c.
>
> Signed-off-by: Xiaoming Ni
> Signed-off-by: Luis Chamberlain
> ---
> drivers/base/firmware_loader/fallback.c | 4
> drivers/base/firmware_loader/fallback.h | 11 ++
> drivers/base/firmware_loader/fallback_table.c | 22 +--
> include/linux/sysctl.h| 1 -
> kernel/sysctl.c | 7 --
> 5 files changed, 35 insertions(+), 10 deletions(-)
So it now takes more lines than the old stuff? :(
>
> diff --git a/drivers/base/firmware_loader/fallback.c
> b/drivers/base/firmware_loader/fallback.c
> index d9ac7296205e..8190653ae9a3 100644
> --- a/drivers/base/firmware_loader/fallback.c
> +++ b/drivers/base/firmware_loader/fallback.c
> @@ -200,12 +200,16 @@ static struct class firmware_class = {
>
> int register_sysfs_loader(void)
> {
> + int ret = register_firmware_config_sysctl();
> + if (ret != 0)
> + return ret;
checkpatch :(
> return class_register(_class);
And if that fails?
> }
>
> void unregister_sysfs_loader(void)
> {
> class_unregister(_class);
> + unregister_firmware_config_sysctl();
> }
>
> static ssize_t firmware_loading_show(struct device *dev,
> diff --git a/drivers/base/firmware_loader/fallback.h
> b/drivers/base/firmware_loader/fallback.h
> index 06f4577733a8..7d2cb5f6ceb8 100644
> --- a/drivers/base/firmware_loader/fallback.h
> +++ b/drivers/base/firmware_loader/fallback.h
> @@ -42,6 +42,17 @@ void fw_fallback_set_default_timeout(void);
>
> int register_sysfs_loader(void);
> void unregister_sysfs_loader(void);
> +#ifdef CONFIG_SYSCTL
> +extern int register_firmware_config_sysctl(void);
> +extern void unregister_firmware_config_sysctl(void);
> +#else
> +static inline int register_firmware_config_sysctl(void)
> +{
> + return 0;
> +}
> +static inline void unregister_firmware_config_sysctl(void) { }
> +#endif /* CONFIG_SYSCTL */
> +
> #else /* CONFIG_FW_LOADER_USER_HELPER */
> static inline int firmware_fallback_sysfs(struct firmware *fw, const char
> *name,
> struct device *device,
> diff --git a/drivers/base/firmware_loader/fallback_table.c
> b/drivers/base/firmware_loader/fallback_table.c
> index 46a731dede6f..4234aa5ee5df 100644
> --- a/drivers/base/firmware_loader/fallback_table.c
> +++ b/drivers/base/firmware_loader/fallback_table.c
> @@ -24,7 +24,7 @@ struct firmware_fallback_config fw_fallback_config = {
> EXPORT_SYMBOL_NS_GPL(fw_fallback_config, FIRMWARE_LOADER_PRIVATE);
>
> #ifdef CONFIG_SYSCTL
> -struct ctl_table firmware_config_table[] = {
> +static struct ctl_table firmware_config_table[] = {
> {
> .procname = "force_sysfs_fallback",
> .data = _fallback_config.force_sysfs_fallback,
> @@ -45,4 +45,22 @@ struct ctl_table firmware_config_table[] = {
> },
> { }
> };
> -#endif
> +
> +static struct ctl_table_header *hdr;
> +int register_firmware_config_sysctl(void)
> +{
> + if (hdr)
> + return -EEXIST;
How can hdr be set?
> + hdr = register_sysctl_subdir("kernel", "firmware_config",
> + firmware_config_table);
> + if (!hdr)
> + return -ENOMEM;
> + return 0;
> +}
> +
> +void unregister_firmware_config_sysctl(void)
> +{
> + if (hdr)
> + unregister_sysctl_table(hdr);
Why can't unregister_sysctl_table() take a null pointer value?
And what sets 'hdr' (worst name for a static variable) to NULL so that
it knows not to be unregistered again as it looks like
register_firmware_config_sysctl() could be called multiple times.
thanks,
greg k-h
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915: Check for awaits on still currently executing requests
With the advent of preempt-to-busy, a request may still be on the GPU as
we unwind. And in the case of a unpreemptible [due to HW] request, that
request will remain indefinitely on the GPU even though we have
returned it back to our submission queue, and cleared the active bit.
We only run the execution callbacks on transferring the request from our
submission queue to the execution queue, but if this is a bonded request
that the HW is waiting for, we will not submit it (as we wait for a
fresh execution) even though it is still being executed.
As we know that there are always preemption points between requests, we
know that only the currently executing request may be still active even
though we have cleared the flag.
Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
Testcase: igt/gem_exec_balancer/bonded-dual
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index e5aba6824e26..f851c7d8fc7c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -363,6 +363,11 @@ static void __llist_add(struct llist_node *node, struct
llist_head *head)
head->first = node;
}
+static bool __request_in_flight(const struct i915_request *signal)
+{
+ return signal == execlists_active(>engine->execlists);
+}
+
static int
__await_execution(struct i915_request *rq,
struct i915_request *signal,
@@ -393,7 +398,7 @@ __await_execution(struct i915_request *rq,
}
spin_lock_irq(>lock);
- if (i915_request_is_active(signal)) {
+ if (i915_request_is_active(signal) || __request_in_flight(signal)) {
if (hook) {
hook(rq, >fence);
i915_request_put(signal);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Check for awaits on still currently executing requests
With the advent of preempt-to-busy, a request may still be on the GPU as
we unwind. And in the case of a unpreemptible [due to HW] request, that
request will remain indefinitely on the GPU even though we have
returned it back to our submission queue, and cleared the active bit.
We only run the execution callbacks on transferring the request from our
submission queue to the execution queue, but if this is a bonded request
that the HW is waiting for, we will not submit it (as we wait for a
fresh execution) even though it is still being executed.
As we know that there are always preemption points between requests, we
know that only the currently executing request may be still active even
though we have cleared the flag.
Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
Testcase: igt/gem_exec_balancer/bonded-dual
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index e5aba6824e26..dfc143f81168 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -363,6 +363,16 @@ static void __llist_add(struct llist_node *node, struct
llist_head *head)
head->first = node;
}
+static bool __request_in_flight(struct i915_request *signal)
+{
+ bool result = false;
+
+ if (intel_context_inflight(signal->context))
+ result = signal == execlists_active(>engine->execlists);
+
+ return result;
+}
+
static int
__await_execution(struct i915_request *rq,
struct i915_request *signal,
@@ -393,7 +403,7 @@ __await_execution(struct i915_request *rq,
}
spin_lock_irq(>lock);
- if (i915_request_is_active(signal)) {
+ if (i915_request_is_active(signal) || __request_in_flight(signal)) {
if (hook) {
hook(rq, >fence);
i915_request_put(signal);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Add a few asserts around handling of i915_request_is_active()
== Series Details == Series: series starting with [1/2] drm/i915: Add a few asserts around handling of i915_request_is_active() URL : https://patchwork.freedesktop.org/series/77781/ State : success == Summary == CI Bug Log - changes from CI_DRM_8552 -> Patchwork_17812 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17812/index.html Changes --- No changes found Participating hosts (50 -> 42) -- 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_8552 -> Patchwork_17812 CI-20190529: 20190529 CI_DRM_8552: cd4a9b47339259e3a98601fff14438f17fd2d7dc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5683: 757b6e72d546fd2dbc3801a73796d67b0854021b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17812: 522975053dc11eb107875674dddf3538ed967134 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 522975053dc1 drm/i915: Once executed, always executed f238d6cb8ea9 drm/i915: Add a few asserts around handling of i915_request_is_active() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17812/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/i915: Add a few asserts around handling of i915_request_is_active()
Let's assert that we only call the execute callbacks on making the
request active, and that we do not execute the request without calling
the callbacks.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 0d810a62ff46..e5aba6824e26 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -192,6 +192,7 @@ static void __notify_execute_cb(struct i915_request *rq)
lockdep_assert_held(>lock);
+ GEM_BUG_ON(!i915_request_is_active(rq));
if (llist_empty(>execute_cb))
return;
@@ -518,15 +519,15 @@ bool __i915_request_submit(struct i915_request *request)
if (!test_and_set_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags)) {
list_move_tail(>sched.link, >active.requests);
clear_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
+ __notify_execute_cb(request);
}
+ GEM_BUG_ON(!llist_empty(>execute_cb));
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags) &&
!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags) &&
!i915_request_enable_breadcrumb(request))
intel_engine_signal_breadcrumbs(engine);
- __notify_execute_cb(request);
-
spin_unlock(>lock);
return result;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Once executed, always executed
With the advent of preempt-to-busy, a request may still be on the GPU as
we unwind. And in the case of a unpreemptible [due to HW] request, that
request will remain indefinitely on the GPU event though we have
returned it back to our submission queue, and cleared the active bit.
We only run the execution callbacks on transferring the request from our
submission queue to the execution queue, but if this is a bonded request
that the HW is waiting for, we will not submit it (as we wait for a
fresh execution) even though it is still being executed.
To resolve this issue, once we have executed a request, consider it
always ready for execution and allow the submit-fence to proceed.
Alternatively, we could check the actual inflight context very carefully
to see if the signaller currently executing.
Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
Testcase: igt/gem_exec_balancer/bonded-dual
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index e5aba6824e26..b59dd3606914 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -186,6 +186,11 @@ static void irq_execute_cb_hook(struct irq_work *wrk)
irq_execute_cb(wrk);
}
+static bool __request_has_executed(const struct i915_request *rq)
+{
+ return READ_ONCE(rq->execute_cb.first) == ERR_PTR(-1);
+}
+
static void __notify_execute_cb(struct i915_request *rq)
{
struct execute_cb *cb, *cn;
@@ -193,7 +198,7 @@ static void __notify_execute_cb(struct i915_request *rq)
lockdep_assert_held(>lock);
GEM_BUG_ON(!i915_request_is_active(rq));
- if (llist_empty(>execute_cb))
+ if (__request_has_executed(rq))
return;
llist_for_each_entry_safe(cb, cn, rq->execute_cb.first, work.llnode)
@@ -209,7 +214,7 @@ static void __notify_execute_cb(struct i915_request *rq)
* preempt-to-idle cycle on the target engine, all the while the
* master execute_cb may refire.
*/
- init_llist_head(>execute_cb);
+ rq->execute_cb.first = ERR_PTR(-1);
}
static inline void
@@ -323,11 +328,7 @@ bool i915_request_retire(struct i915_request *rq)
GEM_BUG_ON(!atomic_read(>engine->gt->rps.num_waiters));
atomic_dec(>engine->gt->rps.num_waiters);
}
- if (!test_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags)) {
- set_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags);
- __notify_execute_cb(rq);
- }
- GEM_BUG_ON(!llist_empty(>execute_cb));
+ GEM_BUG_ON(!__request_has_executed(rq));
spin_unlock_irq(>lock);
remove_from_client(rq);
@@ -372,7 +373,7 @@ __await_execution(struct i915_request *rq,
{
struct execute_cb *cb;
- if (i915_request_is_active(signal)) {
+ if (__request_has_executed(signal)) {
if (hook)
hook(rq, >fence);
return 0;
@@ -393,7 +394,7 @@ __await_execution(struct i915_request *rq,
}
spin_lock_irq(>lock);
- if (i915_request_is_active(signal)) {
+ if (__request_has_executed(signal)) {
if (hook) {
hook(rq, >fence);
i915_request_put(signal);
@@ -521,7 +522,7 @@ bool __i915_request_submit(struct i915_request *request)
clear_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
__notify_execute_cb(request);
}
- GEM_BUG_ON(!llist_empty(>execute_cb));
+ GEM_BUG_ON(!__request_has_executed(request));
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags) &&
!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags) &&
@@ -709,8 +710,6 @@ static void __i915_request_ctor(void *arg)
rq->file_priv = NULL;
rq->capture_list = NULL;
-
- init_llist_head(>execute_cb);
}
struct i915_request *
@@ -798,9 +797,9 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp)
/* No zalloc, everything must be cleared after use */
rq->batch = NULL;
+ rq->execute_cb.first = NULL;
GEM_BUG_ON(rq->file_priv);
GEM_BUG_ON(rq->capture_list);
- GEM_BUG_ON(!llist_empty(>execute_cb));
/*
* Reserve space in the ring buffer for all the commands required to
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/13] ocfs2: use new sysctl subdir helper register_sysctl_subdir()
On Fri, May 29, 2020 at 07:41:01AM +, Luis Chamberlain wrote:
> This simplifies the code considerably. The following coccinelle
> SmPL grammar rule was used to transform this code.
>
> // pycocci sysctl-subdir.cocci fs/ocfs2/stackglue.c
>
> @c1@
> expression E1;
> identifier subdir, sysctls;
> @@
>
> static struct ctl_table subdir[] = {
> {
> .procname = E1,
> .maxlen = 0,
> .mode = 0555,
> .child = sysctls,
> },
> { }
> };
>
> @c2@
> identifier c1.subdir;
>
> expression E2;
> identifier base;
> @@
>
> static struct ctl_table base[] = {
> {
> .procname = E2,
> .maxlen = 0,
> .mode = 0555,
> .child = subdir,
> },
> { }
> };
>
> @c3@
> identifier c2.base;
> identifier header;
> @@
>
> header = register_sysctl_table(base);
>
> @r1 depends on c1 && c2 && c3@
> expression c1.E1;
> identifier c1.subdir, c1.sysctls;
> @@
>
> -static struct ctl_table subdir[] = {
> - {
> - .procname = E1,
> - .maxlen = 0,
> - .mode = 0555,
> - .child = sysctls,
> - },
> - { }
> -};
>
> @r2 depends on c1 && c2 && c3@
> identifier c1.subdir;
>
> expression c2.E2;
> identifier c2.base;
> @@
> -static struct ctl_table base[] = {
> - {
> - .procname = E2,
> - .maxlen = 0,
> - .mode = 0555,
> - .child = subdir,
> - },
> - { }
> -};
>
> @r3 depends on c1 && c2 && c3@
> expression c1.E1;
> identifier c1.sysctls;
> expression c2.E2;
> identifier c2.base;
> identifier c3.header;
> @@
>
> header =
> -register_sysctl_table(base);
> +register_sysctl_subdir(E2, E1, sysctls);
>
> Generated-by: Coccinelle SmPL
>
> Signed-off-by: Luis Chamberlain
> ---
> fs/ocfs2/stackglue.c | 27 ---
> 1 file changed, 4 insertions(+), 23 deletions(-)
>
> diff --git a/fs/ocfs2/stackglue.c b/fs/ocfs2/stackglue.c
> index a191094694c6..addafced7f59 100644
> --- a/fs/ocfs2/stackglue.c
> +++ b/fs/ocfs2/stackglue.c
> @@ -677,28 +677,8 @@ static struct ctl_table ocfs2_mod_table[] = {
> },
> { }
> };
> -
> -static struct ctl_table ocfs2_kern_table[] = {
> - {
> - .procname = "ocfs2",
> - .data = NULL,
> - .maxlen = 0,
> - .mode = 0555,
> - .child = ocfs2_mod_table
> - },
> - { }
> -};
> -
> -static struct ctl_table ocfs2_root_table[] = {
> - {
> - .procname = "fs",
> - .data = NULL,
> - .maxlen = 0,
> - .mode = 0555,
> - .child = ocfs2_kern_table
> - },
> - { }
> -};
> + .data = NULL,
> + .data = NULL,
The conversion script doesn't like the .data field assignments. ;)
Was this series built with allmodconfig? I would have expected this to
blow up very badly. :)
--
Kees Cook
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/13] sysctl: add helper to register empty subdir
On Fri, May 29, 2020 at 07:41:07AM +, Luis Chamberlain wrote: > The way to create a subdirectory from the base set of directories > is a bit obscure, so provide a helper which makes this clear, and > also helps remove boiler plate code required to do this work. > > Signed-off-by: Luis Chamberlain Reviewed-by: Kees Cook -- Kees Cook ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/13] fs: move binfmt_misc sysctl to its own file
On Fri, May 29, 2020 at 07:41:08AM +, Luis Chamberlain wrote:
> This moves the binfmt_misc sysctl to its own file to help remove
> clutter from kernel/sysctl.c.
>
> Signed-off-by: Luis Chamberlain
> ---
> fs/binfmt_misc.c | 1 +
> kernel/sysctl.c | 7 ---
> 2 files changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
> index f69a043f562b..656b3f5f3bbf 100644
> --- a/fs/binfmt_misc.c
> +++ b/fs/binfmt_misc.c
> @@ -821,6 +821,7 @@ static int __init init_misc_binfmt(void)
> int err = register_filesystem(_fs_type);
> if (!err)
> insert_binfmt(_format);
> + register_sysctl_empty_subdir("fs", "binfmt_misc");
> return err;
Nit: let's make the dir before registering the filesystem. I can't
imagine a realistic situation where userspace is reacting so fast it
would actually fail to mount the fs on /proc/sys/fs/binfmt_misc, but why
risk it?
-Kees
> }
>
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index 460532cd5ac8..7714e7b476c2 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -3042,13 +3042,6 @@ static struct ctl_table fs_table[] = {
> .extra1 = SYSCTL_ZERO,
> .extra2 = SYSCTL_TWO,
> },
> -#if defined(CONFIG_BINFMT_MISC) || defined(CONFIG_BINFMT_MISC_MODULE)
> - {
> - .procname = "binfmt_misc",
> - .mode = 0555,
> - .child = sysctl_mount_point,
> - },
> -#endif
> {
> .procname = "pipe-max-size",
> .data = _max_size,
> --
> 2.26.2
>
--
Kees Cook
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/13] sysctl: add new register_sysctl_subdir() helper
On Fri, 29 May 2020, Luis Chamberlain wrote: > Often enough all we need to do is create a subdirectory so that > we can stuff sysctls underneath it. However, *if* that directory > was already created early on the boot sequence we really have no > need to use the full boiler plate code for it, we can just use > local variables to help us guide sysctl to place the new leaf files. I find it hard to figure out the lifetime requirements for the tables passed in; when it's okay to use local variables and when you need longer lifetimes. It's not documented, everyone appears to be using static tables for this. It's far from obvious. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/13] sysctl: add helper to register empty subdir
The way to create a subdirectory from the base set of directories
is a bit obscure, so provide a helper which makes this clear, and
also helps remove boiler plate code required to do this work.
Signed-off-by: Luis Chamberlain
---
include/linux/sysctl.h | 7 +++
kernel/sysctl.c| 16 +---
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 33a471b56345..89c92390e6de 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -208,6 +208,8 @@ extern void register_sysctl_init(const char *path, struct
ctl_table *table,
extern struct ctl_table_header *register_sysctl_subdir(const char *base,
const char *subdir,
struct ctl_table *table);
+extern void register_sysctl_empty_subdir(const char *base, const char *subdir);
+
void do_sysctl_args(void);
extern int pwrsw_enabled;
@@ -231,6 +233,11 @@ inline struct ctl_table_header
*register_sysctl_subdir(const char *base,
return NULL;
}
+static inline void register_sysctl_empty_subdir(const char *base,
+ const char *subdir)
+{
+}
+
static inline struct ctl_table_header *register_sysctl_paths(
const struct ctl_path *path, struct ctl_table *table)
{
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index f9a35325d5d5..460532cd5ac8 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -3188,13 +3188,17 @@ struct ctl_table_header *register_sysctl_subdir(const
char *base,
{ }
};
- if (!table->procname)
+ if (table != sysctl_mount_point && !table->procname)
goto out;
hdr = register_sysctl_table(base_table);
if (unlikely(!hdr)) {
- pr_err("failed when creating subdirectory sysctl %s/%s/%s\n",
- base, subdir, table->procname);
+ if (table != sysctl_mount_point)
+ pr_err("failed when creating subdirectory sysctl
%s/%s/%s\n",
+ base, subdir, table->procname);
+ else
+ pr_err("failed when creating empty subddirectory
%s/%s\n",
+ base, subdir);
goto out;
}
kmemleak_not_leak(hdr);
@@ -3202,6 +3206,12 @@ struct ctl_table_header *register_sysctl_subdir(const
char *base,
return hdr;
}
EXPORT_SYMBOL_GPL(register_sysctl_subdir);
+
+void register_sysctl_empty_subdir(const char *base,
+ const char *subdir)
+{
+ register_sysctl_subdir(base, subdir, sysctl_mount_point);
+}
#endif /* CONFIG_SYSCTL */
/*
* No sense putting this after each symbol definition, twice,
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/13] fs: move binfmt_misc sysctl to its own file
This moves the binfmt_misc sysctl to its own file to help remove
clutter from kernel/sysctl.c.
Signed-off-by: Luis Chamberlain
---
fs/binfmt_misc.c | 1 +
kernel/sysctl.c | 7 ---
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
index f69a043f562b..656b3f5f3bbf 100644
--- a/fs/binfmt_misc.c
+++ b/fs/binfmt_misc.c
@@ -821,6 +821,7 @@ static int __init init_misc_binfmt(void)
int err = register_filesystem(_fs_type);
if (!err)
insert_binfmt(_format);
+ register_sysctl_empty_subdir("fs", "binfmt_misc");
return err;
}
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 460532cd5ac8..7714e7b476c2 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -3042,13 +3042,6 @@ static struct ctl_table fs_table[] = {
.extra1 = SYSCTL_ZERO,
.extra2 = SYSCTL_TWO,
},
-#if defined(CONFIG_BINFMT_MISC) || defined(CONFIG_BINFMT_MISC_MODULE)
- {
- .procname = "binfmt_misc",
- .mode = 0555,
- .child = sysctl_mount_point,
- },
-#endif
{
.procname = "pipe-max-size",
.data = _max_size,
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/13] eventpoll: simplify sysctl declaration with register_sysctl_subdir()
From: Xiaoming Ni
Move epoll_table sysctl to fs/eventpoll.c and remove the
clutter out of kernel/sysctl.c by using register_sysctl_subdir()..
Signed-off-by: Xiaoming Ni
Signed-off-by: Luis Chamberlain
---
fs/eventpoll.c | 10 +-
include/linux/poll.h | 2 --
include/linux/sysctl.h | 1 -
kernel/sysctl.c| 7 ---
4 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 12eebcdea9c8..957ebc9700e3 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -299,7 +299,7 @@ static LIST_HEAD(tfile_check_list);
static long long_zero;
static long long_max = LONG_MAX;
-struct ctl_table epoll_table[] = {
+static struct ctl_table epoll_table[] = {
{
.procname = "max_user_watches",
.data = _user_watches,
@@ -311,6 +311,13 @@ struct ctl_table epoll_table[] = {
},
{ }
};
+
+static void __init epoll_sysctls_init(void)
+{
+ register_sysctl_subdir("fs", "epoll", epoll_table);
+}
+#else
+#define epoll_sysctls_init() do { } while (0)
#endif /* CONFIG_SYSCTL */
static const struct file_operations eventpoll_fops;
@@ -2422,6 +2429,7 @@ static int __init eventpoll_init(void)
/* Allocates slab cache used to allocate "struct eppoll_entry" */
pwq_cache = kmem_cache_create("eventpoll_pwq",
sizeof(struct eppoll_entry), 0, SLAB_PANIC|SLAB_ACCOUNT, NULL);
+ epoll_sysctls_init();
return 0;
}
diff --git a/include/linux/poll.h b/include/linux/poll.h
index 1cdc32b1f1b0..a9e0e1c2d1f2 100644
--- a/include/linux/poll.h
+++ b/include/linux/poll.h
@@ -8,12 +8,10 @@
#include
#include
#include
-#include
#include
#include
#include
-extern struct ctl_table epoll_table[]; /* for sysctl */
/* ~832 bytes of stack space used max in sys_select/sys_poll before allocating
additional memory. */
#ifdef __clang__
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index aa01f54d0442..e5364b69dd95 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -217,7 +217,6 @@ extern int no_unaligned_warning;
extern struct ctl_table sysctl_mount_point[];
extern struct ctl_table random_table[];
-extern struct ctl_table epoll_table[];
#else /* CONFIG_SYSCTL */
static inline struct ctl_table_header *register_sysctl_table(struct ctl_table
* table)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index e007375c8a11..5c116904feb7 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -3001,13 +3001,6 @@ static struct ctl_table fs_table[] = {
.proc_handler = proc_dointvec,
},
#endif
-#ifdef CONFIG_EPOLL
- {
- .procname = "epoll",
- .mode = 0555,
- .child = epoll_table,
- },
-#endif
#endif
{
.procname = "protected_symlinks",
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/13] test_sysctl: use new sysctl subdir helper register_sysctl_subdir()
This simplifies the code considerably. The following coccinelle
SmPL grammar rule was used to transform this code.
// pycocci sysctl-subdir.cocci lib/test_sysctl.c
@c1@
expression E1;
identifier subdir, sysctls;
@@
static struct ctl_table subdir[] = {
{
.procname = E1,
.maxlen = 0,
.mode = 0555,
.child = sysctls,
},
{ }
};
@c2@
identifier c1.subdir;
expression E2;
identifier base;
@@
static struct ctl_table base[] = {
{
.procname = E2,
.maxlen = 0,
.mode = 0555,
.child = subdir,
},
{ }
};
@c3@
identifier c2.base;
identifier header;
@@
header = register_sysctl_table(base);
@r1 depends on c1 && c2 && c3@
expression c1.E1;
identifier c1.subdir, c1.sysctls;
@@
-static struct ctl_table subdir[] = {
- {
- .procname = E1,
- .maxlen = 0,
- .mode = 0555,
- .child = sysctls,
- },
- { }
-};
@r2 depends on c1 && c2 && c3@
identifier c1.subdir;
expression c2.E2;
identifier c2.base;
@@
-static struct ctl_table base[] = {
- {
- .procname = E2,
- .maxlen = 0,
- .mode = 0555,
- .child = subdir,
- },
- { }
-};
@r3 depends on c1 && c2 && c3@
expression c1.E1;
identifier c1.sysctls;
expression c2.E2;
identifier c2.base;
identifier c3.header;
@@
header =
-register_sysctl_table(base);
+register_sysctl_subdir(E2, E1, sysctls);
Generated-by: Coccinelle SmPL
Signed-off-by: Luis Chamberlain
---
lib/test_sysctl.c | 23 ++-
1 file changed, 2 insertions(+), 21 deletions(-)
diff --git a/lib/test_sysctl.c b/lib/test_sysctl.c
index 84eaae22d3a6..b17581307756 100644
--- a/lib/test_sysctl.c
+++ b/lib/test_sysctl.c
@@ -128,26 +128,6 @@ static struct ctl_table test_table[] = {
{ }
};
-static struct ctl_table test_sysctl_table[] = {
- {
- .procname = "test_sysctl",
- .maxlen = 0,
- .mode = 0555,
- .child = test_table,
- },
- { }
-};
-
-static struct ctl_table test_sysctl_root_table[] = {
- {
- .procname = "debug",
- .maxlen = 0,
- .mode = 0555,
- .child = test_sysctl_table,
- },
- { }
-};
-
static struct ctl_table_header *test_sysctl_header;
static int __init test_sysctl_init(void)
@@ -155,7 +135,8 @@ static int __init test_sysctl_init(void)
test_data.bitmap_0001 = kzalloc(SYSCTL_TEST_BITMAP_SIZE/8, GFP_KERNEL);
if (!test_data.bitmap_0001)
return -ENOMEM;
- test_sysctl_header = register_sysctl_table(test_sysctl_root_table);
+ test_sysctl_header = register_sysctl_subdir("debug", "test_sysctl",
+ test_table);
if (!test_sysctl_header) {
kfree(test_data.bitmap_0001);
return -ENOMEM;
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
