[Intel-gfx] ✗ Fi.CI.IGT: failure for dma-fence: Deadline awareness (rev2)
== Series Details ==
Series: dma-fence: Deadline awareness (rev2)
URL : https://patchwork.freedesktop.org/series/114863/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12965_full -> Patchwork_114863v2_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_114863v2_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_114863v2_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_114863v2_full:
### IGT changes ###
Possible regressions
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-blt:
- shard-glk: [PASS][1] -> [TIMEOUT][2] +3 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-glk8/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-pri-indfb-draw-blt.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114863v2/shard-glk3/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-pri-indfb-draw-blt.html
* igt@syncobj_timeline@invalid-wait-zero-handles:
- shard-apl: [PASS][3] -> [FAIL][4] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-apl1/igt@syncobj_timel...@invalid-wait-zero-handles.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114863v2/shard-apl7/igt@syncobj_timel...@invalid-wait-zero-handles.html
- shard-snb: [PASS][5] -> [FAIL][6] +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-snb7/igt@syncobj_timel...@invalid-wait-zero-handles.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114863v2/shard-snb5/igt@syncobj_timel...@invalid-wait-zero-handles.html
- shard-glk: [PASS][7] -> [FAIL][8] +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-glk8/igt@syncobj_timel...@invalid-wait-zero-handles.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114863v2/shard-glk3/igt@syncobj_timel...@invalid-wait-zero-handles.html
Warnings
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-wc:
- shard-glk: [SKIP][9] ([fdo#109271]) -> [TIMEOUT][10] +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-glk8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-wc.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114863v2/shard-glk3/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-wc.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@syncobj_timeline@invalid-wait-zero-handles:
- {shard-rkl}:[PASS][11] -> [FAIL][12] +1 similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-rkl-7/igt@syncobj_timel...@invalid-wait-zero-handles.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114863v2/shard-rkl-2/igt@syncobj_timel...@invalid-wait-zero-handles.html
- {shard-tglu}: [PASS][13] -> [FAIL][14] +1 similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-tglu-2/igt@syncobj_timel...@invalid-wait-zero-handles.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114863v2/shard-tglu-2/igt@syncobj_timel...@invalid-wait-zero-handles.html
Known issues
Here are the changes found in Patchwork_114863v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@device_reset@cold-reset-bound:
- shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271]) +32 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114863v2/shard-apl3/igt@device_re...@cold-reset-bound.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-apl: [PASS][16] -> [FAIL][17] ([i915#2842])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-apl6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114863v2/shard-apl4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_reloc@basic-cpu-read-active:
- shard-apl: [PASS][18] -> [DMESG-WARN][19] ([i915#62]) +26
similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-apl4/igt@gem_exec_re...@basic-cpu-read-active.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114863v2/shard-apl2/igt@gem_exec_re...@basic-cpu-read-active.html
* igt@gem_lmem_swapping@heavy-multi:
- shard-glk: NOTRUN -> [SKIP][20] ([fdo#109271] /
Re: [Intel-gfx] [PATCH v3] drm/i915/mtl: Disable stolen memory backed FB for A0
On Tue, 2023-04-04 at 23:26 +0200, Das, Nirmoy wrote: > > On 4/4/2023 8:27 PM, Ville Syrjälä wrote: > > On Tue, Apr 04, 2023 at 08:13:42PM +0200, Nirmoy Das wrote: > > > Stolen memory is not usable for MTL A0 stepping beyond > > > certain access size and we have no control over userspace > > > access size of /dev/fb which can be backed by stolen memory. > > > So disable stolen memory backed fb by setting i915- > > > >dsm.usable_size > > > to zero. > > > > > > v2: remove hsdes reference and fix commit message(Andi) > > > v3: use revid as we want to target SOC stepping(Radhakrishna) > > > > > > Cc: Matthew Auld > > > Cc: Andi Shyti > > > Cc: Daniele Ceraolo Spurio > > > Cc: Lucas De Marchi > > > Cc: Radhakrishna Sripada > > > Signed-off-by: Nirmoy Das > > > Reviewed-by: Andi Shyti > > > --- > > > drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 8 > > > 1 file changed, 8 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > > > b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > > > index 8ac376c24aa2..ee492d823f1b 100644 > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > > > @@ -535,6 +535,14 @@ static int i915_gem_init_stolen(struct > > > intel_memory_region *mem) > > > /* Basic memrange allocator for stolen space. */ > > > drm_mm_init(>mm.stolen, 0, i915->dsm.usable_size); > > > > > > + /* > > > + * Access to stolen lmem beyond certain size for MTL A0 > > > stepping > > > + * would crash the machine. Disable stolen lmem for > > > userspace access > > > + * by setting usable_size to zero. > > > + */ > > > + if (IS_METEORLAKE(i915) && INTEL_REVID(i915) == 0x0) > > > + i915->dsm.usable_size = 0; > > That certainly won't prevent FBC from using stolen. > > Are we sure that FBC accesses are fine? > > I think so. I remember Jouni tested this patch internally to unblock > a > FBC test. > > Jouni, could you please share your thoughts. I can't seem to find the > internal JIRA reference right now. I tested this patch and it was fixing the problem it was targeted. I didn't noticed any issue back then. > > > Regards, > > Nirmoy > > > > > > + > > > return 0; > > > } > > > > > > -- > > > 2.39.0
[Intel-gfx] ✓ Fi.CI.BAT: success for Update DSC Bigjoiner BW check (rev3)
== Series Details == Series: Update DSC Bigjoiner BW check (rev3) URL : https://patchwork.freedesktop.org/series/115773/ State : success == Summary == CI Bug Log - changes from CI_DRM_12967 -> Patchwork_115773v3 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115773v3/index.html Participating hosts (37 -> 36) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_115773v3 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3@lmem0: - bat-dg2-11: [PASS][1] -> [INCOMPLETE][2] ([i915#6311]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12967/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115773v3/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html * igt@i915_selftest@live@reset: - bat-rpls-2: NOTRUN -> [ABORT][3] ([i915#4983] / [i915#7913]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115773v3/bat-rpls-2/igt@i915_selftest@l...@reset.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - fi-bsw-n3050: NOTRUN -> [SKIP][4] ([fdo#109271]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115773v3/fi-bsw-n3050/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@read-crc: - bat-dg2-11: NOTRUN -> [SKIP][5] ([i915#5354]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115773v3/bat-dg2-11/igt@kms_pipe_crc_ba...@read-crc.html Possible fixes * igt@i915_selftest@live@execlists: - fi-bsw-n3050: [ABORT][6] ([i915#7911] / [i915#7913]) -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12967/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115773v3/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@requests: - bat-rpls-2: [ABORT][8] ([i915#7913] / [i915#7982]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12967/bat-rpls-2/igt@i915_selftest@l...@requests.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115773v3/bat-rpls-2/igt@i915_selftest@l...@requests.html * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1: - bat-dg2-8: [FAIL][10] ([i915#7932]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12967/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115773v3/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354 [i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932 [i915#7982]: https://gitlab.freedesktop.org/drm/intel/issues/7982 Build changes - * Linux: CI_DRM_12967 -> Patchwork_115773v3 CI-20190529: 20190529 CI_DRM_12967: 28c342e55ec8081498c63f4a38825f055e294a3a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7236: bac5a4cc31b3212a205219a6cbc45a173d30d04b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_115773v3: 28c342e55ec8081498c63f4a38825f055e294a3a @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits ee0caf573163 drm/i915/intel_cdclk: Add vdsc with bigjoiner constraints on min_cdlck 503111c9e5aa drm/i915/dp: Update Bigjoiner interface bits for computing compressed bpp == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115773v3/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Update DSC Bigjoiner BW check (rev3)
== Series Details == Series: Update DSC Bigjoiner BW check (rev3) URL : https://patchwork.freedesktop.org/series/115773/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:112:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:121:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:128:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:166:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:168:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:169:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:170:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:172:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:28:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:31:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:37:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:40:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:55:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:58:9:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/mtl: Disable stolen memory backed FB for A0 (rev6)
== Series Details ==
Series: drm/i915/mtl: Disable stolen memory backed FB for A0 (rev6)
URL : https://patchwork.freedesktop.org/series/114925/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12965_full -> Patchwork_114925v6_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_114925v6_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@gem-execbuf-stress@smem0:
- {shard-dg1}:[PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-dg1-17/igt@i915_pm_rpm@gem-execbuf-str...@smem0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/shard-dg1-15/igt@i915_pm_rpm@gem-execbuf-str...@smem0.html
Known issues
Here are the changes found in Patchwork_114925v6_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-apl: [PASS][3] -> [FAIL][4] ([i915#2842])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-apl6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/shard-apl7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_huc_copy@huc-copy:
- shard-apl: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/shard-apl2/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@heavy-multi:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/shard-glk9/igt@gem_lmem_swapp...@heavy-multi.html
* igt@gem_lmem_swapping@verify-random-ccs:
- shard-apl: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +1
similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/shard-apl4/igt@gem_lmem_swapp...@verify-random-ccs.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][8] -> [ABORT][9] ([i915#5566])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-glk5/igt@gen9_exec_pa...@allowed-single.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/shard-glk3/igt@gen9_exec_pa...@allowed-single.html
* igt@i915_selftest@live@gt_heartbeat:
- shard-apl: [PASS][10] -> [DMESG-FAIL][11] ([i915#5334])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-apl4/igt@i915_selftest@live@gt_heartbeat.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/shard-apl4/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip:
- shard-glk: NOTRUN -> [SKIP][12] ([fdo#109271]) +52 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/shard-glk9/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip.html
* igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#3886]) +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/shard-glk9/igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#3886])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/shard-apl4/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-b-random-ccs-data-4_tiled_dg2_rc_ccs:
- shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271]) +58 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/shard-apl2/igt@kms_ccs@pipe-b-random-ccs-data-4_tiled_dg2_rc_ccs.html
* igt@kms_plane_alpha_blend@alpha-basic@pipe-a-dp-1:
- shard-apl: NOTRUN -> [FAIL][16] ([i915#7862]) +1 similar issue
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/shard-apl2/igt@kms_plane_alpha_blend@alpha-ba...@pipe-a-dp-1.html
* igt@kms_plane_alpha_blend@alpha-transparent-fb@pipe-a-hdmi-a-1:
- shard-glk: NOTRUN -> [FAIL][17] ([i915#4573]) +1 similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/shard-glk9/igt@kms_plane_alpha_blend@alpha-transparent...@pipe-a-hdmi-a-1.html
* igt@kms_psr2_sf@cursor-plane-move-continuous-exceed-fully-sf:
- shard-apl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#658])
[18]:
[Intel-gfx] [PATCH 0/2] Update DSC Bigjoiner BW check
Update the DSC Bigjoiner BW check for computing compressed bpp: -As per latest Bspec update bigjoiner interface bits for DP for DISPLAY > 13 is 36. -Account for the check during computing of min CDCLK. Rev2: Fixed display version Rev3: Added new patch to account for Bigjoiner BW check while computing min CDCLK. Ankit Nautiyal (2): drm/i915/dp: Update Bigjoiner interface bits for computing compressed bpp drm/i915/intel_cdclk: Add vdsc with bigjoiner constraints on min_cdlck drivers/gpu/drm/i915/display/intel_cdclk.c | 49 ++ drivers/gpu/drm/i915/display/intel_dp.c| 3 +- 2 files changed, 44 insertions(+), 8 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH 2/2] drm/i915/intel_cdclk: Add vdsc with bigjoiner constraints on min_cdlck
As per Bsepc:49259, Bigjoiner BW check puts restriction on the
compressed bpp for a given CDCLK, pixelclock in cases where
Bigjoiner + DSC are used.
Currently compressed bpp is computed first, and it is ensured that
the bpp will work at least with the max CDCLK freq.
Since the CDCLK is computed later, lets account for Bigjoiner BW
check while calculating Min CDCLK.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 49 ++
1 file changed, 42 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 084a483f9776..4c0e0d605bf1 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2400,6 +2400,46 @@ static int intel_planes_min_cdclk(const struct
intel_crtc_state *crtc_state)
return min_cdclk;
}
+static int intel_vdsc_min_cdclk(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+ int min_cdclk = 0;
+
+ /*
+* When we decide to use only one VDSC engine, since
+* each VDSC operates with 1 ppc throughput, pixel clock
+* cannot be higher than the VDSC clock (cdclk)
+*/
+ if (!crtc_state->dsc.dsc_split)
+ min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate);
+
+ if (crtc_state->bigjoiner_pipes) {
+ /*
+* According to Bigjoiner bw check:
+* compressed_bpp <= PPC * CDCLK * Big joiner Interface bits /
Pixel clock
+*
+* We have already computed compressed_bpp, so now compute the
min CDCLK that
+* is required to support this compressed_bpp.
+*
+* => CDCLK >= compressed_bpp * Pixel clock / (PPC * Bigjoiner
Interface bits)
+*
+* Since Num of pipes joined = 2, and PPC = 2 with bigjoiner
+* => CDCLK >= compressed_bpp * pixel_rate / Bigjoiner
Interface bits
+*
+* #TODO Bspec mentions to account for FEC overhead while using
pixel clock.
+* Check if we need to use FEC overhead in the above
calculations.
+*/
+ int bigjoiner_interface_bits = DISPLAY_VER(i915) > 13 ? 36 : 24;
+ int min_cdclk_bj = crtc_state->dsc.compressed_bpp *
crtc_state->pixel_rate /
+ bigjoiner_interface_bits;
+
+ min_cdclk = max(min_cdclk, min_cdclk_bj);
+ }
+
+ return min_cdclk;
+}
+
int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *dev_priv =
@@ -2471,13 +2511,8 @@ int intel_crtc_compute_min_cdclk(const struct
intel_crtc_state *crtc_state)
/* Account for additional needs from the planes */
min_cdclk = max(intel_planes_min_cdclk(crtc_state), min_cdclk);
- /*
-* When we decide to use only one VDSC engine, since
-* each VDSC operates with 1 ppc throughput, pixel clock
-* cannot be higher than the VDSC clock (cdclk)
-*/
- if (crtc_state->dsc.compression_enable && !crtc_state->dsc.dsc_split)
- min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate);
+ if (crtc_state->dsc.compression_enable)
+ min_cdclk = max(min_cdclk, intel_vdsc_min_cdclk(crtc_state));
/*
* HACK. Currently for TGL/DG2 platforms we calculate
--
2.25.1
[Intel-gfx] [PATCH 1/2] drm/i915/dp: Update Bigjoiner interface bits for computing compressed bpp
In Bigjoiner check for DSC, bigjoiner interface bits for DP for
DISPLAY > 13 is 36 (Bspec: 49259).
v2: Corrected Display ver to 13.
v3: Follow convention for conditional statement. (Ville)
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index da1c00ee92fb..74a16ac77bd6 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -756,8 +756,9 @@ u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private
*i915,
bits_per_pixel = min(bits_per_pixel, max_bpp_small_joiner_ram);
if (bigjoiner) {
+ int bigjoiner_interface_bits = DISPLAY_VER(i915) > 13 ? 36 : 24;
u32 max_bpp_bigjoiner =
- i915->display.cdclk.max_cdclk_freq * 48 /
+ i915->display.cdclk.max_cdclk_freq * 2 *
bigjoiner_interface_bits /
intel_dp_mode_to_fec_clock(mode_clock);
bits_per_pixel = min(bits_per_pixel, max_bpp_bigjoiner);
--
2.25.1
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: Allow arbitrary refresh rates with VRR eDP panels
== Series Details ==
Series: series starting with [1/3] drm/i915: Allow arbitrary refresh rates with
VRR eDP panels
URL : https://patchwork.freedesktop.org/series/116101/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12965_full -> Patchwork_116101v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_116101v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-apl: [PASS][1] -> [FAIL][2] ([i915#2842])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-apl6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/shard-apl1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_huc_copy@huc-copy:
- shard-apl: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/shard-apl4/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@heavy-multi:
- shard-glk: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/shard-glk6/igt@gem_lmem_swapp...@heavy-multi.html
* igt@gem_lmem_swapping@verify-random-ccs:
- shard-apl: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +1
similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/shard-apl7/igt@gem_lmem_swapp...@verify-random-ccs.html
* igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271]) +52 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/shard-glk6/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip.html
* igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#3886]) +1
similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/shard-glk6/igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#3886])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/shard-apl7/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-b-random-ccs-data-4_tiled_dg2_rc_ccs:
- shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271]) +58 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/shard-apl4/igt@kms_ccs@pipe-b-random-ccs-data-4_tiled_dg2_rc_ccs.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [PASS][10] -> [FAIL][11] ([i915#2346])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-glk6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/shard-glk2/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@b-hdmi-a2:
- shard-glk: [PASS][12] -> [FAIL][13] ([i915#79])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-glk2/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-hdmi-a2.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/shard-glk6/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-hdmi-a2.html
* igt@kms_plane_alpha_blend@alpha-basic@pipe-a-dp-1:
- shard-apl: NOTRUN -> [FAIL][14] ([i915#7862]) +1 similar issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/shard-apl4/igt@kms_plane_alpha_blend@alpha-ba...@pipe-a-dp-1.html
* igt@kms_plane_alpha_blend@alpha-transparent-fb@pipe-a-hdmi-a-1:
- shard-glk: NOTRUN -> [FAIL][15] ([i915#4573]) +1 similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/shard-glk6/igt@kms_plane_alpha_blend@alpha-transparent...@pipe-a-hdmi-a-1.html
* igt@kms_psr2_sf@cursor-plane-move-continuous-exceed-fully-sf:
- shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#658])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/shard-apl4/igt@kms_psr2...@cursor-plane-move-continuous-exceed-fully-sf.html
* igt@kms_psr2_sf@overlay-plane-move-continuous-exceed-fully-sf:
- shard-glk: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#658])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/shard-glk6/igt@kms_psr2...@overlay-plane-move-continuous-exceed-fully-sf.html
Possible fixes
* igt@drm_fdinfo@most-busy-check-all@rcs0:
- {shard-rkl}:[FAIL][18] ([i915#7742]) -> [PASS][19]
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/mtl: Add Wa_14017856879
== Series Details == Series: drm/i915/mtl: Add Wa_14017856879 URL : https://patchwork.freedesktop.org/series/116100/ State : success == Summary == CI Bug Log - changes from CI_DRM_12965_full -> Patchwork_116100v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (7 -> 8) -- Additional (1): shard-tglu0 Known issues Here are the changes found in Patchwork_116100v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/shard-apl1/igt@gem_huc_c...@huc-copy.html - shard-glk: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/shard-glk2/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@heavy-multi: - shard-glk: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/shard-glk5/igt@gem_lmem_swapp...@heavy-multi.html * igt@gem_lmem_swapping@verify-random-ccs: - shard-apl: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/shard-apl6/igt@gem_lmem_swapp...@verify-random-ccs.html * igt@i915_pm_rps@reset: - shard-snb: [PASS][5] -> [DMESG-FAIL][6] ([i915#8319]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-snb2/igt@i915_pm_...@reset.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/shard-snb4/igt@i915_pm_...@reset.html * igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_mc_ccs: - shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#3886]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/shard-glk5/igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#3886]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/shard-apl6/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-b-random-ccs-data-4_tiled_dg2_rc_ccs: - shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271]) +58 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/shard-apl1/igt@kms_ccs@pipe-b-random-ccs-data-4_tiled_dg2_rc_ccs.html * igt@kms_cursor_crc@cursor-random-max-size: - shard-glk: NOTRUN -> [SKIP][10] ([fdo#109271]) +64 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/shard-glk2/igt@kms_cursor_...@cursor-random-max-size.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions: - shard-glk: [PASS][11] -> [FAIL][12] ([i915#2346]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-glk6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/shard-glk6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html - shard-apl: [PASS][13] -> [FAIL][14] ([i915#2346]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-apl2/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html * igt@kms_plane_alpha_blend@alpha-basic@pipe-a-dp-1: - shard-apl: NOTRUN -> [FAIL][15] ([i915#7862]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/shard-apl1/igt@kms_plane_alpha_blend@alpha-ba...@pipe-a-dp-1.html * igt@kms_plane_alpha_blend@alpha-basic@pipe-c-hdmi-a-1: - shard-glk: NOTRUN -> [FAIL][16] ([i915#7862]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/shard-glk2/igt@kms_plane_alpha_blend@alpha-ba...@pipe-c-hdmi-a-1.html * igt@kms_plane_alpha_blend@alpha-transparent-fb@pipe-a-hdmi-a-1: - shard-glk: NOTRUN -> [FAIL][17] ([i915#4573]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/shard-glk5/igt@kms_plane_alpha_blend@alpha-transparent...@pipe-a-hdmi-a-1.html * igt@kms_psr2_sf@cursor-plane-move-continuous-exceed-fully-sf: - shard-apl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#658]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/shard-apl1/igt@kms_psr2...@cursor-plane-move-continuous-exceed-fully-sf.html - shard-glk: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#658]) +1 similar issue [19]:
[Intel-gfx] ✓ Fi.CI.BAT: success for fdinfo: Enable some support for GuC based client busyness
== Series Details == Series: fdinfo: Enable some support for GuC based client busyness URL : https://patchwork.freedesktop.org/series/116120/ State : success == Summary == CI Bug Log - changes from CI_DRM_12967 -> Patchwork_116120v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v1/index.html Participating hosts (37 -> 37) -- Additional (1): fi-kbl-soraka Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_116120v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@i915_pm_rps@basic-api: - bat-dg2-11: [PASS][3] -> [FAIL][4] ([i915#8308]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12967/bat-dg2-11/igt@i915_pm_...@basic-api.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v1/bat-dg2-11/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gt_heartbeat: - fi-apl-guc: [PASS][5] -> [DMESG-FAIL][6] ([i915#5334]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12967/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][7] ([i915#1886]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@migrate: - bat-dg2-11: [PASS][8] -> [DMESG-WARN][9] ([i915#7699]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12967/bat-dg2-11/igt@i915_selftest@l...@migrate.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html * igt@i915_selftest@live@reset: - bat-rpls-1: [PASS][10] -> [ABORT][11] ([i915#4983]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12967/bat-rpls-1/igt@i915_selftest@l...@reset.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v1/bat-rpls-1/igt@i915_selftest@l...@reset.html * igt@i915_selftest@live@slpc: - bat-rpls-2: NOTRUN -> [DMESG-FAIL][12] ([i915#6367] / [i915#7913]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html - bat-dg2-11: [PASS][13] -> [DMESG-WARN][14] ([i915#7996]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12967/bat-dg2-11/igt@i915_selftest@l...@slpc.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v1/bat-dg2-11/igt@i915_selftest@l...@slpc.html * igt@kms_chamelium_frames@hdmi-crc-fast: - fi-kbl-soraka: NOTRUN -> [SKIP][15] ([fdo#109271]) +16 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v1/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-rpls-2: NOTRUN -> [SKIP][16] ([i915#7828]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v1/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html - fi-bsw-n3050: NOTRUN -> [SKIP][17] ([fdo#109271]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v1/fi-bsw-n3050/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@read-crc: - bat-adlp-9: NOTRUN -> [SKIP][18] ([i915#3546]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v1/bat-adlp-9/igt@kms_pipe_crc_ba...@read-crc.html * igt@kms_pipe_crc_basic@suspend-read-crc: - bat-rpls-2: NOTRUN -> [SKIP][19] ([i915#1845]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v1/bat-rpls-2/igt@kms_pipe_crc_ba...@suspend-read-crc.html * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-a-hdmi-a-1: - fi-rkl-11600: [PASS][20] -> [FAIL][21] ([fdo#103375]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12967/fi-rkl-11600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-hdmi-a-1.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116120v1/fi-rkl-11600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-hdmi-a-1.html Possible fixes * igt@i915_selftest@live@execlists: - fi-bsw-n3050: [ABORT][22] ([i915#7911] / [i915#7913]) -> [PASS][23] [22]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for fdinfo: Enable some support for GuC based client busyness
== Series Details == Series: fdinfo: Enable some support for GuC based client busyness URL : https://patchwork.freedesktop.org/series/116120/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH v1 5/7] Revert "drm: Assert held reservation lock for dma-buf mmapping"
On 4/3/23 18:17, Christian König wrote:
> Am 02.04.23 um 18:48 schrieb Dmitry Osipenko:
>> Don't assert held dma-buf reservation lock on memory mapping of exported
>> buffer.
>>
>> We're going to change dma-buf mmap() locking policy such that exporters
>> will have to handle the lock. The previous locking policy caused deadlock
>> problem for DRM drivers in a case of self-imported dma-bufs, it's solved
>> by moving the lock down to exporters.
>
> I only checked the TTM code path and think that at least that one should
> work fine.
>
>> Fixes: 39ce25291871 ("drm: Assert held reservation lock for dma-buf
>> mmapping")
>
> This here is not really a "fix" for the previous patch. We just found
> that we didn't like the behavior and so reverted the original patch.
>
> A "Reverts..." comment in the commit message would be more appropriate I
> think.
Ack, will drop the fixes tag in v2. Thank you and Emil for the review.
--
Best regards,
Dmitry
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/5] drm/i915/ttm: Add I915_BO_PREALLOC
== Series Details == Series: series starting with [1/5] drm/i915/ttm: Add I915_BO_PREALLOC URL : https://patchwork.freedesktop.org/series/116093/ State : success == Summary == CI Bug Log - changes from CI_DRM_12965_full -> Patchwork_116093v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (7 -> 7) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_116093v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-contexts-1us: - shard-snb: [PASS][1] -> [FAIL][2] ([i915#7942]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-snb4/igt@gem_...@in-flight-contexts-1us.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-snb4/igt@gem_...@in-flight-contexts-1us.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-apl3/igt@gem_huc_c...@huc-copy.html - shard-glk: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-glk3/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@heavy-multi: - shard-glk: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-glk9/igt@gem_lmem_swapp...@heavy-multi.html * igt@gem_lmem_swapping@verify-random-ccs: - shard-apl: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-apl1/igt@gem_lmem_swapp...@verify-random-ccs.html * igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_mc_ccs: - shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#3886]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-glk9/igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#3886]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-apl1/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-b-random-ccs-data-4_tiled_dg2_rc_ccs: - shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271]) +58 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-apl3/igt@kms_ccs@pipe-b-random-ccs-data-4_tiled_dg2_rc_ccs.html * igt@kms_cursor_crc@cursor-random-max-size: - shard-glk: NOTRUN -> [SKIP][10] ([fdo#109271]) +64 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-glk3/igt@kms_cursor_...@cursor-random-max-size.html * igt@kms_plane_alpha_blend@alpha-basic@pipe-a-dp-1: - shard-apl: NOTRUN -> [FAIL][11] ([i915#7862]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-apl3/igt@kms_plane_alpha_blend@alpha-ba...@pipe-a-dp-1.html * igt@kms_plane_alpha_blend@alpha-basic@pipe-c-hdmi-a-1: - shard-glk: NOTRUN -> [FAIL][12] ([i915#7862]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-glk3/igt@kms_plane_alpha_blend@alpha-ba...@pipe-c-hdmi-a-1.html * igt@kms_plane_alpha_blend@alpha-transparent-fb@pipe-a-hdmi-a-1: - shard-glk: NOTRUN -> [FAIL][13] ([i915#4573]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-glk9/igt@kms_plane_alpha_blend@alpha-transparent...@pipe-a-hdmi-a-1.html * igt@kms_psr2_sf@cursor-plane-move-continuous-exceed-fully-sf: - shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#658]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-apl3/igt@kms_psr2...@cursor-plane-move-continuous-exceed-fully-sf.html - shard-glk: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#658]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-glk3/igt@kms_psr2...@cursor-plane-move-continuous-exceed-fully-sf.html Possible fixes * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-apl: [ABORT][16] ([i915#180]) -> [PASS][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-apl2/igt@gem_ctx_isolation@preservation...@rcs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-apl1/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-apl: [FAIL][18] ([i915#2842]) -> [PASS][19] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-apl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html [19]:
[Intel-gfx] [PATCH 2/2] drm/i915/fdinfo: Enable fdinfo for GuC backends
Enable fdinfo for GuC based platforms with the exception that long running contexts will not provide reliable busyness data unless they switch out at some reasonable point in time. Link: https://gitlab.freedesktop.org/drm/intel/issues/8303 Signed-off-by: Umesh Nerlige Ramappa --- drivers/gpu/drm/i915/i915_drm_client.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drm_client.c b/drivers/gpu/drm/i915/i915_drm_client.c index e8fa172ebe5e..d18d0a3ed905 100644 --- a/drivers/gpu/drm/i915/i915_drm_client.c +++ b/drivers/gpu/drm/i915/i915_drm_client.c @@ -147,11 +147,7 @@ void i915_drm_client_fdinfo(struct seq_file *m, struct file *f) PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn)); seq_printf(m, "drm-client-id:\t%u\n", client->id); - /* -* Temporarily skip showing client engine information with GuC submission till -* fetching engine busyness is implemented in the GuC submission backend -*/ - if (GRAPHICS_VER(i915) < 8 || intel_uc_uses_guc_submission(>gt0.uc)) + if (GRAPHICS_VER(i915) < 8) return; for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++) -- 2.36.1
[Intel-gfx] [PATCH 1/2] i915/pmu: Add support for total context runtime for GuC back-end
GPU accumulates the context runtime in a 32 bit counter - CTX_TIMESTAMP
in the context image. This value is saved/restored on context switches.
KMD accumulates these values into a 64 bit counter taking care of any
overflows as needed. This count provides the basis for client specific
busyness in the fdinfo interface.
KMD accumulation happens just before the context is unpinned and when
context switches out. This works for execlist back-end since execlist
scheduling has visibility into context switches. With GuC mode, KMD does
not have visibility into context switches and this counter is
accumulated only when context is unpinned. Context is unpinned once the
context scheduling is successfully disabled. Disabling context
scheduling is an asynchronous operation. Also if a context is servicing
frequent requests, scheduling may never be disabled on it.
For GuC mode, since updates to the context runtime may be delayed, add
hooks to update the context runtime in a worker thread as well as when
a user queries for it.
Limitation:
- If a context is never switched out or runs for a long period of time,
the runtime value of CTX_TIMESTAMP may never be updated, so the
counter value may be unreliable. This patch does not support such
cases. Such support must be available from the GuC FW and it is WIP.
This patch is an extract from previous work authored by John/Umesh here -
https://patchwork.freedesktop.org/patch/496441/?series=105085=4
Signed-off-by: Umesh Nerlige Ramappa
Co-developed-by: John Harrison
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_context.c | 12 +--
drivers/gpu/drm/i915/gt/intel_context.h | 2 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 5 +++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 33 +++
4 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 2aa63ec521b8..e01f222e9e42 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -578,16 +578,24 @@ void intel_context_bind_parent_child(struct intel_context
*parent,
child->parallel.parent = parent;
}
-u64 intel_context_get_total_runtime_ns(const struct intel_context *ce)
+u64 intel_context_get_total_runtime_ns(struct intel_context *ce)
{
u64 total, active;
+ if (ce->ops->update_stats)
+ ce->ops->update_stats(ce);
+
total = ce->stats.runtime.total;
if (ce->ops->flags & COPS_RUNTIME_CYCLES)
total *= ce->engine->gt->clock_period_ns;
active = READ_ONCE(ce->stats.active);
- if (active)
+ /*
+* When COPS_RUNTIME_ACTIVE_TOTAL is set for ce->cops, the backend
+* already provides the total active time of the context, so skip this
+* calculation when this flag is set.
+*/
+ if (active && !(ce->ops->flags & COPS_RUNTIME_ACTIVE_TOTAL))
active = intel_context_clock() - active;
return total + active;
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 0a8d553da3f4..720809523e2d 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -368,7 +368,7 @@ intel_context_clear_nopreempt(struct intel_context *ce)
clear_bit(CONTEXT_NOPREEMPT, >flags);
}
-u64 intel_context_get_total_runtime_ns(const struct intel_context *ce);
+u64 intel_context_get_total_runtime_ns(struct intel_context *ce);
u64 intel_context_get_avg_runtime_ns(struct intel_context *ce);
static inline u64 intel_context_clock(void)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index e36670f2e626..58b0294d359d 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -38,6 +38,9 @@ struct intel_context_ops {
#define COPS_RUNTIME_CYCLES_BIT 1
#define COPS_RUNTIME_CYCLES BIT(COPS_RUNTIME_CYCLES_BIT)
+#define COPS_RUNTIME_ACTIVE_TOTAL_BIT 2
+#define COPS_RUNTIME_ACTIVE_TOTAL BIT(COPS_RUNTIME_ACTIVE_TOTAL_BIT)
+
int (*alloc)(struct intel_context *ce);
void (*revoke)(struct intel_context *ce, struct i915_request *rq,
@@ -58,6 +61,8 @@ struct intel_context_ops {
void (*sched_disable)(struct intel_context *ce);
+ void (*update_stats)(struct intel_context *ce);
+
void (*reset)(struct intel_context *ce);
void (*destroy)(struct kref *kref);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 88e881b100cf..8048a3e97a68 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1402,13 +1402,25 @@ static void __update_guc_busyness_stats(struct
intel_guc *guc)
spin_unlock_irqrestore(>timestamp.lock, flags);
}
+static void
[Intel-gfx] [PATCH 0/2] fdinfo: Enable some support for GuC based client busyness
Export context runtime into the fdinfo framework to enable per client busyness for GuC back-end. v2: Fix zeroed busyness values Signed-off-by: Umesh Nerlige Ramappa Test-with: 20230405000909.51175-1-umesh.nerlige.rama...@intel.com Umesh Nerlige Ramappa (2): i915/pmu: Add support for total context runtime for GuC back-end drm/i915/fdinfo: Enable fdinfo for GuC backends drivers/gpu/drm/i915/gt/intel_context.c | 12 +-- drivers/gpu/drm/i915/gt/intel_context.h | 2 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 5 +++ .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 33 +++ drivers/gpu/drm/i915/i915_drm_client.c| 6 +--- 5 files changed, 50 insertions(+), 8 deletions(-) -- 2.36.1
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/8] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers
== Series Details == Series: series starting with [1/8] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers URL : https://patchwork.freedesktop.org/series/116115/ State : success == Summary == CI Bug Log - changes from CI_DRM_12966 -> Patchwork_116115v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116115v1/index.html Participating hosts (37 -> 36) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_116115v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-1: [PASS][1] -> [ABORT][2] ([i915#6687] / [i915#7978]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116115v1/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@mman: - bat-rpls-2: [PASS][3] -> [TIMEOUT][4] ([i915#6794]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-rpls-2/igt@i915_selftest@l...@mman.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116115v1/bat-rpls-2/igt@i915_selftest@l...@mman.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-dg2-11: NOTRUN -> [SKIP][5] ([i915#7828]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116115v1/bat-dg2-11/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1: - bat-dg2-8: [PASS][6] -> [FAIL][7] ([i915#7932]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116115v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html Possible fixes * igt@gem_exec_suspend@basic-s3@smem: - fi-skl-6600u: [FAIL][8] ([fdo#103375]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116115v1/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@gt_lrc: - bat-dg2-11: [INCOMPLETE][10] ([i915#7609] / [i915#7913]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116115v1/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1: - bat-dg2-8: [FAIL][12] ([i915#7932]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116115v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-hdmi-a-1: - fi-rkl-11600: [FAIL][14] ([fdo#103375]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/fi-rkl-11600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-hdmi-a-1.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116115v1/fi-rkl-11600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-hdmi-a-1.html [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687 [i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794 [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932 [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978 Build changes - * Linux: CI_DRM_12966 -> Patchwork_116115v1 CI-20190529: 20190529 CI_DRM_12966: 202141796dba6058f9f7623c0ee48ff4ebcc2607 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7236: bac5a4cc31b3212a205219a6cbc45a173d30d04b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_116115v1: 202141796dba6058f9f7623c0ee48ff4ebcc2607 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 8fcadcdb6f80 fbdev: Simplify fb_is_primary_device for x86 3f0bbb1d4a16 video/aperture: Only remove sysfb on the default vga pci device 760e01f859e2 video/aperture: Drop primary argument bcbc1c70fec0 video/aperture: Move vga handling to pci function 55bca2e9a6ae video/aperture: Only kick vgacon when the pdev is decoding vga eded9d1fdd59 drm/aperture: Remove primary argument b9417246cd7c video/aperture: use generic code
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/8] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers
== Series Details == Series: series starting with [1/8] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers URL : https://patchwork.freedesktop.org/series/116115/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/8] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers
== Series Details ==
Series: series starting with [1/8] drm/gma500: Use
drm_aperture_remove_conflicting_pci_framebuffers
URL : https://patchwork.freedesktop.org/series/116115/
State : warning
== Summary ==
Error: dim checkpatch failed
7db5ea09e0ca drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers
-:47: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 19 lines checked
76418eb2d2d0 video/aperture: use generic code to figure out the vga default
device
-:10: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 1d38fe6ee6a8 ("PCI/VGA: Move
vgaarb to drivers/pci")'
#10:
specific hack. See also 1d38fe6ee6a8 ("PCI/VGA: Move vgaarb to
-:68: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 15 lines checked
b33e4ae52179 drm/aperture: Remove primary argument
-:8: WARNING:TYPO_SPELLING: 'preceeding' may be misspelled - perhaps
'preceding'?
#8:
with the preceeding two patches those are all using the pci version of
^^
-:256: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 2 warnings, 0 checks, 149 lines checked
a443b6f084bd video/aperture: Only kick vgacon when the pdev is decoding vga
-:15: WARNING:COMMIT_LOG_USE_LINK: Unknown link reference 'References:', use
'Link:' instead
#15:
References: https://bugzilla.kernel.org/show_bug.cgi?id=216303
-:48: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 2 warnings, 0 checks, 22 lines checked
ab328b0e47f5 video/aperture: Move vga handling to pci function
-:61: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 27 lines checked
396ad4927181 video/aperture: Drop primary argument
-:6: WARNING:TYPO_SPELLING: 'preceeding' may be misspelled - perhaps
'preceding'?
#6:
With the preceeding patches it's become defunct. Also I'm about to add
^^
-:133: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 2 warnings, 0 checks, 81 lines checked
3f7bc16a62fe video/aperture: Only remove sysfb on the default vga pci device
-:13: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit ee7a69aa38d8 ("fbdev: Disable
sysfb device registration when removing conflicting FBs")'
#13:
This fixes a regression introduced by ee7a69aa38d8 ("fbdev: Disable
-:16: WARNING:TYPO_SPELLING: 'loosing' may be misspelled - perhaps 'losing'?
#16:
resulting in the user loosing their efifb console or similar.
^^^
-:50: WARNING:COMMIT_LOG_USE_LINK: Unknown link reference 'References:', use
'Link:' instead
#50:
References: https://bugzilla.kernel.org/show_bug.cgi?id=216303#c28
-:83: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 1 errors, 3 warnings, 0 checks, 19 lines checked
466711f2ccb2 fbdev: Simplify fb_is_primary_device for x86
-:20: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 88674088d10c ("x86: Use
vga_default_device() when determining whether an fb is primary")'
#20:
up in 88674088d10c ("x86: Use vga_default_device() when determining
-:68: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 27 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/ttm: Small fixes / cleanups in prep for shrinking (rev3)
== Series Details == Series: drm/ttm: Small fixes / cleanups in prep for shrinking (rev3) URL : https://patchwork.freedesktop.org/series/114774/ State : success == Summary == CI Bug Log - changes from CI_DRM_12966 -> Patchwork_114774v3 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v3/index.html Participating hosts (37 -> 36) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_114774v3 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@reset: - bat-rpls-1: [PASS][1] -> [ABORT][2] ([i915#4983]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-rpls-1/igt@i915_selftest@l...@reset.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v3/bat-rpls-1/igt@i915_selftest@l...@reset.html * igt@i915_suspend@basic-s3-without-i915: - bat-rpls-2: [PASS][3] -> [ABORT][4] ([i915#7978]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-rpls-2/igt@i915_susp...@basic-s3-without-i915.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v3/bat-rpls-2/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-dg2-11: NOTRUN -> [SKIP][5] ([i915#7828]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v3/bat-dg2-11/igt@kms_chamelium_...@common-hpd-after-suspend.html Possible fixes * igt@gem_exec_suspend@basic-s3@smem: - fi-skl-6600u: [FAIL][6] ([fdo#103375]) -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v3/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@gt_lrc: - bat-dg2-11: [INCOMPLETE][8] ([i915#7609] / [i915#7913]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v3/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-hdmi-a-1: - fi-rkl-11600: [FAIL][10] ([fdo#103375]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/fi-rkl-11600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-hdmi-a-1.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v3/fi-rkl-11600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-hdmi-a-1.html Warnings * igt@i915_selftest@live@slpc: - bat-rpls-2: [DMESG-FAIL][12] ([i915#6367] / [i915#7913] / [i915#7996]) -> [DMESG-FAIL][13] ([i915#6367] / [i915#7913]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-rpls-2/igt@i915_selftest@l...@slpc.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v3/bat-rpls-2/igt@i915_selftest@l...@slpc.html [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978 [i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996 Build changes - * Linux: CI_DRM_12966 -> Patchwork_114774v3 CI-20190529: 20190529 CI_DRM_12966: 202141796dba6058f9f7623c0ee48ff4ebcc2607 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7236: bac5a4cc31b3212a205219a6cbc45a173d30d04b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_114774v3: 202141796dba6058f9f7623c0ee48ff4ebcc2607 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits a42f1c7dda48 drm/ttm: Make the call to ttm_tt_populate() interruptible when faulting 8ee4de7f70fa drm/ttm: Reduce the number of used allocation orders for TTM pages f0f151642ee9 drm/ttm/pool: Fix ttm_pool_alloc error path == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v3/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/ttm: Small fixes / cleanups in prep for shrinking (rev3)
== Series Details == Series: drm/ttm: Small fixes / cleanups in prep for shrinking (rev3) URL : https://patchwork.freedesktop.org/series/114774/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:112:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:121:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:128:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:166:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:168:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:169:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:170:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:172:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:28:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:31:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:37:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:40:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:55:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'mask'
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/ttm: Small fixes / cleanups in prep for shrinking (rev3)
== Series Details == Series: drm/ttm: Small fixes / cleanups in prep for shrinking (rev3) URL : https://patchwork.freedesktop.org/series/114774/ State : warning == Summary == Error: dim checkpatch failed 20b987c8b612 drm/ttm/pool: Fix ttm_pool_alloc error path 48e572a2078c drm/ttm: Reduce the number of used allocation orders for TTM pages -:38: WARNING:CONSTANT_COMPARISON: Comparisons should place the constant on the right side of the test #38: FILE: drivers/gpu/drm/ttm/ttm_pool.c:53: +#define TTM_DIM_ORDER (__TTM_DIM_ORDER <= MAX_ORDER ? __TTM_DIM_ORDER : MAX_ORDER) total: 0 errors, 1 warnings, 0 checks, 91 lines checked ae0dffefba8a drm/ttm: Make the call to ttm_tt_populate() interruptible when faulting
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var
== Series Details == Series: series starting with [1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var URL : https://patchwork.freedesktop.org/series/116109/ State : success == Summary == CI Bug Log - changes from CI_DRM_12966 -> Patchwork_116109v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/index.html Participating hosts (37 -> 36) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_116109v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0@smem: - bat-dg2-9: [PASS][1] -> [DMESG-WARN][2] ([i915#6704]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@execlists: - fi-bsw-nick:[PASS][3] -> [ABORT][4] ([i915#7911] / [i915#7913]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/fi-bsw-nick/igt@i915_selftest@l...@execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@reset: - bat-rpls-1: [PASS][5] -> [ABORT][6] ([i915#7981]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-rpls-1/igt@i915_selftest@l...@reset.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/bat-rpls-1/igt@i915_selftest@l...@reset.html * igt@i915_suspend@basic-s3-without-i915: - bat-rpls-2: [PASS][7] -> [ABORT][8] ([i915#6687] / [i915#7978]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-rpls-2/igt@i915_susp...@basic-s3-without-i915.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/bat-rpls-2/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-dg2-11: NOTRUN -> [SKIP][9] ([i915#7828]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/bat-dg2-11/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1: - bat-dg2-8: [PASS][10] -> [FAIL][11] ([i915#7932]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html * igt@kms_pipe_crc_basic@read-crc: - bat-dg2-11: NOTRUN -> [SKIP][12] ([i915#5354]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/bat-dg2-11/igt@kms_pipe_crc_ba...@read-crc.html Possible fixes * igt@gem_exec_suspend@basic-s3@smem: - fi-skl-6600u: [FAIL][13] ([fdo#103375]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@gt_lrc: - bat-dg2-11: [INCOMPLETE][15] ([i915#7609] / [i915#7913]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-hdmi-a-1: - fi-rkl-11600: [FAIL][17] ([fdo#103375]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/fi-rkl-11600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-hdmi-a-1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/fi-rkl-11600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-hdmi-a-1.html [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354 [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687 [i915#6704]: https://gitlab.freedesktop.org/drm/intel/issues/6704 [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932 [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978 [i915#7981]: https://gitlab.freedesktop.org/drm/intel/issues/7981 Build changes - * Linux: CI_DRM_12966 -> Patchwork_116109v1 CI-20190529: 20190529
Re: [Intel-gfx] [PATCH v9 16/25] iommufd/device: Add iommufd_access_detach() API
On Sat, 1 Apr 2023 08:18:24 -0700 Yi Liu wrote: > From: Nicolin Chen > > Previously, the detach routine is only done by the destroy(). And it was > called by vfio_iommufd_emulated_unbind() when the device runs close(), so > all the mappings in iopt were cleaned in that setup, when the call trace > reaches this detach() routine. > > Now, there's a need of a detach uAPI, meaning that it does not only need > a new iommufd_access_detach() API, but also requires access->ops->unmap() > call as a cleanup. So add one. > > However, leaving that unprotected can introduce some potential of a race > condition during the pin_/unpin_pages() call, where access->ioas->iopt is > getting referenced. So, add an ioas_lock to protect the context of iopt > referencings. > > Also, to allow the iommufd_access_unpin_pages() callback to happen via > this unmap() call, add an ioas_unpin pointer, so the unpin routine won't > be affected by the "access->ioas = NULL" trick. > > Reviewed-by: Kevin Tian > Tested-by: Terrence Xu > Tested-by: Yanting Jiang > Signed-off-by: Nicolin Chen > Signed-off-by: Yi Liu > --- > drivers/iommu/iommufd/device.c | 76 +++-- > drivers/iommu/iommufd/iommufd_private.h | 2 + > include/linux/iommufd.h | 1 + > 3 files changed, 74 insertions(+), 5 deletions(-) Does this need to go in via iommufd first? There seems to be quite a bit of churn in iommufd/device.c vs the vfio_mdev_ops branch (ie. it doesn't apply). Thanks, Alex
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var
== Series Details ==
Series: series starting with [1/3] drm/fb-helper: set x/yres_virtual in
drm_fb_helper_check_var
URL : https://patchwork.freedesktop.org/series/116109/
State : warning
== Summary ==
Error: dim checkpatch failed
8b9227e2090f drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var
-:7: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 6c11df58fd1a ("fbmem: Check
virtual screen sizes in fb_set_var()")'
#7:
reject it. Uncovered by 6c11df58fd1a ("fbmem: Check virtual screen
-:31: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 9 lines checked
c7187f14b77e drm/fb-helper: drop redundant pixclock check from
drm_fb_helper_set_par()
-:33: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 11 lines checked
07636f85167e drm/fb-helper: fix input validation gaps in check_var
-:39: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#39: FILE: drivers/gpu/drm/drm_fb_helper.c:1550:
+ var->height = var->width = 0;
-:40: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#40: FILE: drivers/gpu/drm/drm_fb_helper.c:1551:
+ var->left_margin = var->right_margin = 0;
-:41: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#41: FILE: drivers/gpu/drm/drm_fb_helper.c:1552:
+ var->upper_margin = var->lower_margin = 0;
-:42: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#42: FILE: drivers/gpu/drm/drm_fb_helper.c:1553:
+ var->hsync_len = var->vsync_len = 0;
-:43: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#43: FILE: drivers/gpu/drm/drm_fb_helper.c:1554:
+ var->sync = var->vmode = 0;
-:103: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 5 checks, 75 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for fbmem: Reject FB_ACTIVATE_KD_TEXT from userspace
== Series Details == Series: fbmem: Reject FB_ACTIVATE_KD_TEXT from userspace URL : https://patchwork.freedesktop.org/series/116107/ State : success == Summary == CI Bug Log - changes from CI_DRM_12966 -> Patchwork_116107v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116107v1/index.html Participating hosts (37 -> 36) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_116107v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0@smem: - bat-jsl-3: [PASS][1] -> [ABORT][2] ([i915#5122]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116107v1/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@hangcheck: - fi-skl-guc: [PASS][3] -> [DMESG-WARN][4] ([i915#8073]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116107v1/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@requests: - bat-rpls-1: [PASS][5] -> [ABORT][6] ([i915#7911]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-rpls-1/igt@i915_selftest@l...@requests.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116107v1/bat-rpls-1/igt@i915_selftest@l...@requests.html * igt@i915_suspend@basic-s3-without-i915: - bat-jsl-3: [PASS][7] -> [FAIL][8] ([fdo#103375]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116107v1/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-dg2-11: NOTRUN -> [SKIP][9] ([i915#7828]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116107v1/bat-dg2-11/igt@kms_chamelium_...@common-hpd-after-suspend.html Possible fixes * igt@gem_exec_suspend@basic-s3@smem: - fi-skl-6600u: [FAIL][10] ([fdo#103375]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116107v1/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@gt_lrc: - bat-dg2-11: [INCOMPLETE][12] ([i915#7609] / [i915#7913]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116107v1/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-hdmi-a-1: - fi-rkl-11600: [FAIL][14] ([fdo#103375]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/fi-rkl-11600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-hdmi-a-1.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116107v1/fi-rkl-11600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-hdmi-a-1.html Warnings * igt@i915_selftest@live@slpc: - bat-rpls-2: [DMESG-FAIL][16] ([i915#6367] / [i915#7913] / [i915#7996]) -> [DMESG-FAIL][17] ([i915#6997] / [i915#7913]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-rpls-2/igt@i915_selftest@l...@slpc.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116107v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [i915#5122]: https://gitlab.freedesktop.org/drm/intel/issues/5122 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997 [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996 [i915#8073]: https://gitlab.freedesktop.org/drm/intel/issues/8073 Build changes - * Linux: CI_DRM_12966 -> Patchwork_116107v1 CI-20190529: 20190529 CI_DRM_12966: 202141796dba6058f9f7623c0ee48ff4ebcc2607 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7236: bac5a4cc31b3212a205219a6cbc45a173d30d04b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_116107v1: 202141796dba6058f9f7623c0ee48ff4ebcc2607 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits e95669aaab2d fbmem: Reject FB_ACTIVATE_KD_TEXT
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Allow user to set cache at BO creation
On Monday, April 3, 2023 9:48:40 AM PDT Ville Syrjälä wrote:
> On Mon, Apr 03, 2023 at 09:35:32AM -0700, Matt Roper wrote:
> > On Mon, Apr 03, 2023 at 07:02:08PM +0300, Ville Syrjälä wrote:
> > > On Fri, Mar 31, 2023 at 11:38:30PM -0700, fei.y...@intel.com wrote:
> > > > From: Fei Yang
> > > >
> > > > To comply with the design that buffer objects shall have immutable
> > > > cache setting through out its life cycle, {set, get}_caching ioctl's
> > > > are no longer supported from MTL onward. With that change caching
> > > > policy can only be set at object creation time. The current code
> > > > applies a default (platform dependent) cache setting for all objects.
> > > > However this is not optimal for performance tuning. The patch extends
> > > > the existing gem_create uAPI to let user set PAT index for the object
> > > > at creation time.
> > >
> > > This is missing the whole justification for the new uapi.
> > > Why is MOCS not sufficient?
> >
> > PAT and MOCS are somewhat related, but they're not the same thing. The
> > general direction of the hardware architecture recently has been to
> > slowly dumb down MOCS and move more of the important memory/cache
> > control over to the PAT instead. On current platforms there is some
> > overlap (and MOCS has an "ignore PAT" setting that makes the MOCS "win"
> > for the specific fields that both can control), but MOCS doesn't have a
> > way to express things like snoop/coherency mode (on MTL), or class of
> > service (on PVC). And if you check some of the future platforms, the
> > hardware design starts packing even more stuff into the PAT (not just
> > cache behavior) which will never be handled by MOCS.
>
> Sigh. So the hardware designers screwed up MOCS yet again and
> instead of getting that fixed we are adding a new uapi to work
> around it?
>
> The IMO sane approach (which IIRC was the situation for a few
> platform generations at least) is that you just shove the PAT
> index into MOCS (or tell it to go look it up from the PTE).
> Why the heck did they not just stick with that?
There are actually some use cases in newer APIs where MOCS doesn't
work well. For example, VK_KHR_buffer_device_address in Vulkan 1.2:
https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_KHR_buffer_device_address.html
It essentially adds "pointers to buffer memory in shaders", where apps
can just get a 64-bit pointer, and use it with an address. On our EUs,
that turns into A64 data port messages which refer directly to memory.
Notably, there's no descriptor (i.e. SURFACE_STATE) where you could
stuff a MOCS value. So, you get one single MOCS entry for all such
buffers...which is specified in STATE_BASE_ADDRESS. Hope you wanted
all of them to have the same cache & coherency settings!
With PAT/PTE, we can at least specify settings for each buffer, rather
than one global setting.
Compression has also been moving towards virtual address-based solutions
and handling in the caches and memory controller, rather than in e.g.
the sampler reading SURFACE_STATE. (It started evolving that way with
Tigerlake, really, but continues.)
> > Also keep in mind that MOCS generally applies at the GPU instruction
> > level; although a lot of instructions have a field to provide a MOCS
> > index, or can use a MOCS already associated with a surface state, there
> > are still some that don't. PAT is the source of memory access
> > characteristics for anything that can't provide a MOCS directly.
>
> So what are the things that don't have MOCS and where we need
> some custom cache behaviour, and we already know all that at
> buffer creation time?
For Meteorlake...we have MOCS for cache settings. We only need to use
PAT for coherency settings; I believe we can get away with deciding that
up-front at buffer creation time. If we were doing full cacheability,
I'd be very nervous about deciding performance tuning at creation time.
--Ken
signature.asc
Description: This is a digitally signed message part.
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
On Sat, 1 Apr 2023 07:44:29 -0700
Yi Liu wrote:
> for the users that accept device fds passed from management stacks to be
> able to figure out the host reset affected devices among the devices
> opened by the user. This is needed as such users do not have BDF (bus,
> devfn) knowledge about the devices it has opened, hence unable to use
> the information reported by existing VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
> to figure out the affected devices.
>
> Signed-off-by: Yi Liu
> ---
> drivers/vfio/pci/vfio_pci_core.c | 58
> include/uapi/linux/vfio.h| 24 -
> 2 files changed, 74 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci_core.c
> b/drivers/vfio/pci/vfio_pci_core.c
> index 19f5b075d70a..a5a7e148dce1 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -30,6 +30,7 @@
> #if IS_ENABLED(CONFIG_EEH)
> #include
> #endif
> +#include
>
> #include "vfio_pci_priv.h"
>
> @@ -767,6 +768,20 @@ static int vfio_pci_get_irq_count(struct
> vfio_pci_core_device *vdev, int irq_typ
> return 0;
> }
>
> +static struct vfio_device *
> +vfio_pci_find_device_in_devset(struct vfio_device_set *dev_set,
> +struct pci_dev *pdev)
> +{
> + struct vfio_device *cur;
> +
> + lockdep_assert_held(_set->lock);
> +
> + list_for_each_entry(cur, _set->device_list, dev_set_list)
> + if (cur->dev == >dev)
> + return cur;
> + return NULL;
> +}
> +
> static int vfio_pci_count_devs(struct pci_dev *pdev, void *data)
> {
> (*(int *)data)++;
> @@ -776,13 +791,20 @@ static int vfio_pci_count_devs(struct pci_dev *pdev,
> void *data)
> struct vfio_pci_fill_info {
> int max;
> int cur;
> + bool require_devid;
> + struct iommufd_ctx *iommufd;
> + struct vfio_device_set *dev_set;
> struct vfio_pci_dependent_device *devices;
Poor structure packing, move the bool to the end.
Nit, maybe just name it @devid.
> };
>
> static int vfio_pci_fill_devs(struct pci_dev *pdev, void *data)
> {
> struct vfio_pci_fill_info *fill = data;
> + struct vfio_device_set *dev_set = fill->dev_set;
> struct iommu_group *iommu_group;
> + struct vfio_device *vdev;
> +
> + lockdep_assert_held(_set->lock);
>
> if (fill->cur == fill->max)
> return -EAGAIN; /* Something changed, try again */
> @@ -791,7 +813,21 @@ static int vfio_pci_fill_devs(struct pci_dev *pdev, void
> *data)
> if (!iommu_group)
> return -EPERM; /* Cannot reset non-isolated devices */
>
> - fill->devices[fill->cur].group_id = iommu_group_id(iommu_group);
> + if (fill->require_devid) {
Nit, @vdev could be scoped here.
> + /*
> + * Report dev_id of the devices that are opened as cdev
> + * and have the same iommufd with the fill->iommufd.
> + * Otherwise, just fill IOMMUFD_INVALID_ID.
> + */
> + vdev = vfio_pci_find_device_in_devset(dev_set, pdev);
I wish I had a better solution to this, but I don't.
> + if (vdev && vfio_device_cdev_opened(vdev) &&
> + fill->iommufd == vfio_iommufd_physical_ictx(vdev))
> + vfio_iommufd_physical_devid(vdev,
> >devices[fill->cur].dev_id);
Long line, maybe a pointer to >devices[fill->cur] would help.
> + else
> + fill->devices[fill->cur].dev_id = IOMMUFD_INVALID_ID;
> + } else {
> + fill->devices[fill->cur].group_id = iommu_group_id(iommu_group);
> + }
> fill->devices[fill->cur].segment = pci_domain_nr(pdev->bus);
> fill->devices[fill->cur].bus = pdev->bus->number;
> fill->devices[fill->cur].devfn = pdev->devfn;
> @@ -1230,17 +1266,27 @@ static int vfio_pci_ioctl_get_pci_hot_reset_info(
> return -ENOMEM;
>
> fill.devices = devices;
> + fill.dev_set = vdev->vdev.dev_set;
>
> + mutex_lock(>vdev.dev_set->lock);
> + if (vfio_device_cdev_opened(>vdev)) {
> + fill.require_devid = true;
> + fill.iommufd = vfio_iommufd_physical_ictx(>vdev);
> + }
We can do this unconditionally:
fill.devid = vfio_device_cdev_opened(>vdev);
fill.iommufd = vfio_iommufd_physical_ictx(>vdev);
Thanks,
Alex
> ret = vfio_pci_for_each_slot_or_bus(vdev->pdev, vfio_pci_fill_devs,
> , slot);
> + mutex_unlock(>vdev.dev_set->lock);
>
> /*
>* If a device was removed between counting and filling, we may come up
>* short of fill.max. If a device was added, we'll have a return of
>* -EAGAIN above.
>*/
> - if (!ret)
> + if (!ret) {
> hdr.count = fill.cur;
> + if (fill.require_devid)
> + hdr.flags = VFIO_PCI_HOT_RESET_FLAG_IOMMUFD_DEV_ID;
> + }
>
> reset_info_exit:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: run kernel-doc on headers as part of HDRTEST
== Series Details ==
Series: drm/i915: run kernel-doc on headers as part of HDRTEST
URL : https://patchwork.freedesktop.org/series/116077/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12964_full -> Patchwork_116077v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_116077v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_rotation_crc@primary-rotation-270:
- {shard-rkl}:[PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12964/shard-rkl-4/igt@kms_rotation_...@primary-rotation-270.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116077v1/shard-rkl-4/igt@kms_rotation_...@primary-rotation-270.html
* igt@kms_universal_plane@universal-plane-pageflip-windowed-pipe-d:
- {shard-rkl}:[SKIP][3] ([i915#4070] / [i915#533] / [i915#6768]) ->
[ABORT][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12964/shard-rkl-1/igt@kms_universal_pl...@universal-plane-pageflip-windowed-pipe-d.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116077v1/shard-rkl-2/igt@kms_universal_pl...@universal-plane-pageflip-windowed-pipe-d.html
Known issues
Here are the changes found in Patchwork_116077v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-apl: [PASS][5] -> [FAIL][6] ([i915#2846])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12964/shard-apl4/igt@gem_exec_f...@basic-deadline.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116077v1/shard-apl3/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12964/shard-glk3/igt@gem_exec_fair@basic-p...@vcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116077v1/shard-glk6/igt@gem_exec_fair@basic-p...@vcs0.html
* igt@gem_pwrite@basic-exhaustion:
- shard-snb: NOTRUN -> [WARN][9] ([i915#2658])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116077v1/shard-snb2/igt@gem_pwr...@basic-exhaustion.html
* igt@kms_ccs@pipe-a-random-ccs-data-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#3886])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116077v1/shard-apl3/igt@kms_ccs@pipe-a-random-ccs-data-y_tiled_gen12_mc_ccs.html
* igt@kms_content_protection@atomic-dpms:
- shard-snb: NOTRUN -> [SKIP][11] ([fdo#109271]) +86 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116077v1/shard-snb2/igt@kms_content_protect...@atomic-dpms.html
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-mmap-gtt:
- shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271]) +9 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116077v1/shard-apl3/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-pri-indfb-draw-mmap-gtt.html
Possible fixes
* igt@drm_fdinfo@most-busy-check-all@rcs0:
- {shard-rkl}:[FAIL][13] ([i915#7742]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12964/shard-rkl-1/igt@drm_fdinfo@most-busy-check-...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116077v1/shard-rkl-2/igt@drm_fdinfo@most-busy-check-...@rcs0.html
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-tglu}: [FAIL][15] ([i915#6268]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12964/shard-tglu-3/igt@gem_ctx_e...@basic-nohangcheck.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116077v1/shard-tglu-9/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@i915_pm_dc@dc9-dpms:
- {shard-tglu}: [SKIP][17] ([i915#4281]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12964/shard-tglu-8/igt@i915_pm...@dc9-dpms.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116077v1/shard-tglu-9/igt@i915_pm...@dc9-dpms.html
* igt@i915_pm_rpm@dpms-mode-unset-non-lpsp:
- {shard-rkl}:[SKIP][19] ([i915#1397]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12964/shard-rkl-7/igt@i915_pm_...@dpms-mode-unset-non-lpsp.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116077v1/shard-rkl-6/igt@i915_pm_...@dpms-mode-unset-non-lpsp.html
* igt@i915_pm_rpm@modeset-lpsp-stress-no-wait:
- {shard-dg1}:[SKIP][21] ([i915#1397]) -> [PASS][22]
[21]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for fbmem: Reject FB_ACTIVATE_KD_TEXT from userspace
== Series Details ==
Series: fbmem: Reject FB_ACTIVATE_KD_TEXT from userspace
URL : https://patchwork.freedesktop.org/series/116107/
State : warning
== Summary ==
Error: dim checkpatch failed
734551df04d6 fbmem: Reject FB_ACTIVATE_KD_TEXT from userspace
-:9: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit dc5bdb68b5b3 ("drm/fb-helper:
Fix vt restore")'
#9:
This is an oversight from dc5bdb68b5b3 ("drm/fb-helper: Fix vt
-:60: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 8 lines checked
Re: [Intel-gfx] [PATCH v10 11/15] drm/atomic-helper: Set fence deadline for vblank
On 04/04/2023 22:16, Daniel Vetter wrote:
On Tue, Apr 04, 2023 at 08:22:05PM +0300, Dmitry Baryshkov wrote:
On 08/03/2023 17:53, Rob Clark wrote:
From: Rob Clark
For an atomic commit updating a single CRTC (ie. a pageflip) calculate
the next vblank time, and inform the fence(s) of that deadline.
v2: Comment typo fix (danvet)
v3: If there are multiple CRTCs, consider the time of the soonest vblank
Signed-off-by: Rob Clark
Reviewed-by: Daniel Vetter
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_atomic_helper.c | 37 +
1 file changed, 37 insertions(+)
As I started playing with hotplug on RB5 (sm8250, DSI-HDMI bridge), I found
that this patch introduces the following backtrace on HDMI hotplug. Is there
anything that I can do to debug/fix the issue? The warning seems harmless,
but it would be probably be good to still fix it. With addresses decoded:
Bit a shot in the dark, but does the below help?
This indeed seems to fix the issue. I'm not sure about the possible side
effects, but, if you were to send the patch:
Tested-by: Dmitry Baryshkov
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index f21b5a74176c..6640d80d84f3 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1528,6 +1528,9 @@ static void set_fence_deadline(struct drm_device *dev,
for_each_new_crtc_in_state (state, crtc, new_crtc_state, i) {
ktime_t v;
+ if (drm_atomic_crtc_needs_modeset(new_crtc_state))
+ continue;
+
if (drm_crtc_next_vblank_start(crtc, ))
continue;
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 78a8c51a4abf..7ae38e8e27e8 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1001,6 +1001,9 @@ int drm_crtc_next_vblank_start(struct drm_crtc *crtc,
ktime_t *vblanktime)
struct drm_display_mode *mode = >hwmode;
u64 vblank_start;
+ if (!drm_dev_has_vblank(crtc->dev))
+ return -EINVAL;
+
if (!vblank->framedur_ns || !vblank->linedur_ns)
return -EINVAL;
[ 31.151348] [ cut here ]
[ 31.157043] msm_dpu ae01000.display-controller:
drm_WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev))
[ 31.157177] WARNING: CPU: 0 PID: 13 at drivers/gpu/drm/drm_vblank.c:728
drm_crtc_vblank_helper_get_vblank_timestamp_internal
(drivers/gpu/drm/drm_vblank.c:728)
[ 31.180629] Modules linked in:
[ 31.184106] CPU: 0 PID: 13 Comm: kworker/0:1 Not tainted
6.3.0-rc2-8-gd39e48ca80c0 #542
[ 31.193358] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
[ 31.200796] Workqueue: events lt9611uxc_hpd_work
[ 31.205990] pstate: 6045 (nZCv daif +PAN -UAO -TCO -DIT -SSBS
BTYPE=--)
[ 31.213722] pc : drm_crtc_vblank_helper_get_vblank_timestamp_internal
(drivers/gpu/drm/drm_vblank.c:728)
[ 31.222032] lr : drm_crtc_vblank_helper_get_vblank_timestamp_internal
(drivers/gpu/drm/drm_vblank.c:728)
[ 31.230341] sp : 880bb8d0
[ 31.234061] x29: 880bb900 x28: 0038 x27:
61a7956b8d60
[ 31.242051] x26: x25: x24:
880bb9c4
[ 31.250038] x23: 0001 x22: bf0033b94ef0 x21:
61a7957901d0
[ 31.258029] x20: 61a79571 x19: 61a78128b000 x18:
fffec278
[ 31.266014] x17: 00400465 x16: 0020 x15:
0060
[ 31.274001] x14: 0001 x13: bf00354550e0 x12:
0825
[ 31.281989] x11: 02b7 x10: bf00354b1208 x9 :
bf00354550e0
[ 31.289976] x8 : efff x7 : bf00354ad0e0 x6 :
02b7
[ 31.297963] x5 : 61a8feebbe48 x4 : 4000f2b7 x3 :
a2a8c9f64000
[ 31.305947] x2 : x1 : x0 :
61a780283100
[ 31.313934] Call trace:
[ 31.316719] drm_crtc_vblank_helper_get_vblank_timestamp_internal
(drivers/gpu/drm/drm_vblank.c:728)
[ 31.324646] drm_crtc_vblank_helper_get_vblank_timestamp
(drivers/gpu/drm/drm_vblank.c:843)
[ 31.331528] drm_crtc_get_last_vbltimestamp
(drivers/gpu/drm/drm_vblank.c:884)
[ 31.337170] drm_crtc_next_vblank_start
(drivers/gpu/drm/drm_vblank.c:1006)
[ 31.342430] drm_atomic_helper_wait_for_fences
(drivers/gpu/drm/drm_atomic_helper.c:1531
drivers/gpu/drm/drm_atomic_helper.c:1578)
[ 31.348561] drm_atomic_helper_commit
(drivers/gpu/drm/drm_atomic_helper.c:2007)
[ 31.353724] drm_atomic_commit (drivers/gpu/drm/drm_atomic.c:1444)
[ 31.358127] drm_client_modeset_commit_atomic
(drivers/gpu/drm/drm_client_modeset.c:1045)
[ 31.364146] drm_client_modeset_commit_locked
(drivers/gpu/drm/drm_client_modeset.c:1148)
[ 31.370071] drm_client_modeset_commit
(drivers/gpu/drm/drm_client_modeset.c:1174)
[ 31.375233] drm_fb_helper_set_par (drivers/gpu/drm/drm_fb_helper.c:254
drivers/gpu/drm/drm_fb_helper.c:229
Re: [Intel-gfx] [PATCH v3 04/12] vfio-iommufd: Add helper to retrieve iommufd_ctx and devid for vfio_device
On Tue, 4 Apr 2023 17:28:40 +0200
Eric Auger wrote:
> Hi,
>
> On 4/1/23 16:44, Yi Liu wrote:
> > This is needed by the vfio-pci driver to report affected devices in the
> > hot reset for a given device.
> >
> > Reviewed-by: Jason Gunthorpe
> > Tested-by: Yanting Jiang
> > Signed-off-by: Yi Liu
> > ---
> > drivers/iommu/iommufd/device.c | 12
> > drivers/vfio/iommufd.c | 14 ++
> > include/linux/iommufd.h| 3 +++
> > include/linux/vfio.h | 13 +
> > 4 files changed, 42 insertions(+)
> >
> > diff --git a/drivers/iommu/iommufd/device.c b/drivers/iommu/iommufd/device.c
> > index 25115d401d8f..04a57aa1ae2c 100644
> > --- a/drivers/iommu/iommufd/device.c
> > +++ b/drivers/iommu/iommufd/device.c
> > @@ -131,6 +131,18 @@ void iommufd_device_unbind(struct iommufd_device *idev)
> > }
> > EXPORT_SYMBOL_NS_GPL(iommufd_device_unbind, IOMMUFD);
> >
> > +struct iommufd_ctx *iommufd_device_to_ictx(struct iommufd_device *idev)
> > +{
> > + return idev->ictx;
> > +}
> > +EXPORT_SYMBOL_NS_GPL(iommufd_device_to_ictx, IOMMUFD);
> > +
> > +u32 iommufd_device_to_id(struct iommufd_device *idev)
> > +{
> > + return idev->obj.id;
> > +}
> > +EXPORT_SYMBOL_NS_GPL(iommufd_device_to_id, IOMMUFD);
> > +
> > static int iommufd_device_setup_msi(struct iommufd_device *idev,
> > struct iommufd_hw_pagetable *hwpt,
> > phys_addr_t sw_msi_start)
> > diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
> > index 88b00c501015..809f2dd73b9e 100644
> > --- a/drivers/vfio/iommufd.c
> > +++ b/drivers/vfio/iommufd.c
> > @@ -66,6 +66,20 @@ void vfio_iommufd_unbind(struct vfio_device *vdev)
> > vdev->ops->unbind_iommufd(vdev);
> > }
> >
> > +struct iommufd_ctx *vfio_iommufd_physical_ictx(struct vfio_device *vdev)
> > +{
> > + if (!vdev->iommufd_device)
> > + return NULL;
> > + return iommufd_device_to_ictx(vdev->iommufd_device);
> > +}
> > +EXPORT_SYMBOL_GPL(vfio_iommufd_physical_ictx);
> > +
> > +void vfio_iommufd_physical_devid(struct vfio_device *vdev, u32 *id)
> > +{
> > + if (vdev->iommufd_device)
> > + *id = iommufd_device_to_id(vdev->iommufd_device);
> since there is no return value, may be worth to add at least a WARN_ON
> in case of !vdev->iommufd_device
Yeah, this is bizarre and makes the one caller of this interface very
awkward. We later go on to define IOMMUFD_INVALID_ID, so this should
simply return that in the case of no iommufd_device and skip this
unnecessary pointer passing. Thanks,
Alex
> > +}
> > +EXPORT_SYMBOL_GPL(vfio_iommufd_physical_devid);
> > /*
> > * The physical standard ops mean that the iommufd_device is bound to the
> > * physical device vdev->dev that was provided to vfio_init_group_dev().
> > Drivers
> > diff --git a/include/linux/iommufd.h b/include/linux/iommufd.h
> > index 1129a36a74c4..ac96df406833 100644
> > --- a/include/linux/iommufd.h
> > +++ b/include/linux/iommufd.h
> > @@ -24,6 +24,9 @@ void iommufd_device_unbind(struct iommufd_device *idev);
> > int iommufd_device_attach(struct iommufd_device *idev, u32 *pt_id);
> > void iommufd_device_detach(struct iommufd_device *idev);
> >
> > +struct iommufd_ctx *iommufd_device_to_ictx(struct iommufd_device *idev);
> > +u32 iommufd_device_to_id(struct iommufd_device *idev);
> > +
> > struct iommufd_access_ops {
> > u8 needs_pin_pages : 1;
> > void (*unmap)(void *data, unsigned long iova, unsigned long length);
> > diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> > index 3188d8a374bd..97a1174b922f 100644
> > --- a/include/linux/vfio.h
> > +++ b/include/linux/vfio.h
> > @@ -113,6 +113,8 @@ struct vfio_device_ops {
> > };
> >
> > #if IS_ENABLED(CONFIG_IOMMUFD)
> > +struct iommufd_ctx *vfio_iommufd_physical_ictx(struct vfio_device *vdev);
> > +void vfio_iommufd_physical_devid(struct vfio_device *vdev, u32 *id);
> > int vfio_iommufd_physical_bind(struct vfio_device *vdev,
> >struct iommufd_ctx *ictx, u32 *out_device_id);
> > void vfio_iommufd_physical_unbind(struct vfio_device *vdev);
> > @@ -122,6 +124,17 @@ int vfio_iommufd_emulated_bind(struct vfio_device
> > *vdev,
> > void vfio_iommufd_emulated_unbind(struct vfio_device *vdev);
> > int vfio_iommufd_emulated_attach_ioas(struct vfio_device *vdev, u32
> > *pt_id);
> > #else
> > +static inline struct iommufd_ctx *
> > +vfio_iommufd_physical_ictx(struct vfio_device *vdev)
> > +{
> > + return NULL;
> > +}
> > +
> > +static inline void
> > +vfio_iommufd_physical_devid(struct vfio_device *vdev, u32 *id)
> > +{
> > +}
> > +
> > #define vfio_iommufd_physical_bind \
> > ((int (*)(struct vfio_device *vdev, struct iommufd_ctx *ictx, \
> > u32 *out_device_id)) NULL)
> besides
>
> Reviewed-by: Eric Auger
>
> Eric
>
Re: [Intel-gfx] [PATCH 4/7] drm/i915/mtl: Add Support for C10 PHY message bus and pll programming
On Tue, Apr 04, 2023 at 10:22:53PM +0300, Sripada, Radhakrishna wrote:
>
>
> > -Original Message-
> > From: Deak, Imre
> > Sent: Tuesday, April 4, 2023 11:03 AM
> > To: Sripada, Radhakrishna
> > Cc: Kahola, Mika ; intel-gfx@lists.freedesktop.org;
> > Shankar, Uma ; Sousa, Gustavo
> >
> > Subject: Re: [PATCH 4/7] drm/i915/mtl: Add Support for C10 PHY message bus
> > and pll programming
> >
> > On Tue, Apr 04, 2023 at 07:50:00PM +0300, Sripada, Radhakrishna wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Deak, Imre
> > > > Sent: Tuesday, April 4, 2023 6:28 AM
> > > > To: Kahola, Mika
> > > > Cc: intel-gfx@lists.freedesktop.org; Sripada, Radhakrishna
> > > > ; Shankar, Uma
> > ;
> > > > Sousa, Gustavo
> > > > Subject: Re: [PATCH 4/7] drm/i915/mtl: Add Support for C10 PHY message
> > bus
> > > > and pll programming
> > > >
> > > > On Tue, Apr 04, 2023 at 04:01:55PM +0300, Kahola, Mika wrote:
> > > > > [...]
> > > > > > >
> > > > > > > > > +void intel_c10mpllb_readout_hw_state(struct intel_encoder
> > *encoder,
> > > > > > > > > +struct intel_c10mpllb_state
> > > > > > > > > pll_state) {
> > > > > > > > > + struct drm_i915_private *i915 =
> > > > > > > > > to_i915(encoder->base.dev);
> > > > > > > > > + struct intel_digital_port *dig_port =
> > > > > > > > > enc_to_dig_port(encoder);
> > > > > > > > > + bool lane_reversal = dig_port->saved_port_bits &
> > DDI_BUF_PORT_REVERSAL;
> > > > > > > > > + u8 lane = lane_reversal ? INTEL_CX0_LANE1 :
> > > > > > > > > + INTEL_CX0_LANE0;
> > > > > > > > > + enum phy phy = intel_port_to_phy(i915, encoder->port);
> > > > > > > > > + int i;
> > > > > > > > > + u8 cmn, tx0;
> > > > > > > > > +
> > > > > > > > > + /*
> > > > > > > > > +* According to C10 VDR Register programming Sequence we
> > need
> > > > > > > > > +* to do this to read PHY internal registers from MsgBus.
> > > > > > > > > +*/
> > > > > > > > > + intel_cx0_rmw(i915, encoder->port, lane,
> > PHY_C10_VDR_CONTROL(1), 0,
> > > > > > > > > + C10_VDR_CTRL_MSGBUS_ACCESS,
> > MB_WRITE_COMMITTED);
> > > > > > > > > +
> > > > > > > > > + for (i = 0; i < ARRAY_SIZE(pll_state->pll); i++)
> > > > > > > > > + pll_state->pll[i] = intel_cx0_read(i915,
> > > > > > > > > encoder->port, lane,
> > PHY_C10_VDR_PLL(i));
> > > > > > > > > +
> > > > > > > > > + cmn = intel_cx0_read(i915, encoder->port, lane,
> > PHY_C10_VDR_CMN(0));
> > > > > > > > > + tx0 = intel_cx0_read(i915, encoder->port, lane,
> > PHY_C10_VDR_TX(0));
> > > > > > > >
> > > > > > > > The driver programs these registers, so why aren't they also
> > > > > > > > stored
> > > > > > > > in the intell_c20pll_state struct?
> > > > > > >
> > > > > > > Maybe I'm not really following here but intel_c20pll_state has
> > > > > > > its own
> > > > > > > tx, cmn and mplla/mpllb stored.
> > > > > >
> > > > > > Yes, just typoed that, I meant struct intel_c10mpllb_state which
> > > > > > doesn't include tx and cmn.
> > > > >
> > > > > Yes, for C10 tx and cmn is missing. Maybe we could add those here as
> > > > > well. It seems that currently these are not necessary required but for
> > > > > the future use, these could be defined.
> > > >
> > > > These are needed already now to make the state computation / HW readout
> > /
> > > > state checking work for these two params the same way they do for the
> > > > rest of PLL state.
> > >
> > > I believe C10 tx and cmn values are not changing across frequencies. Cmn
> > > only
> > > Changes for DP and HDMI so does it make sense to include in the pll
> > > structure?
> >
> > They should be part of the atomic state. To save the bytes in the
> > precomputed tables they could be added to intel_cx0pll_state, something
> > like:
> >
> > struct intel_cx0pll_state {
> > union {
> > struct {
> > struct intel_c10mpllb_state pllb;
> > u8 cmn;
> > u8 tx;
> > } c10;
> > struct intel_c20pll_state c20pll_state;
> > };
> > };
> >
> I am bit concerned about the mismatch in the names for c10 and c20 states,
> adding further complexity in the structure may look more ugly. Let us afford
> the
> extra space in the tables if they need to be part of the atomic state and
> maintain
> homogeneity across c10 and c20 structures.
Both ways are better than the current way and fine by me.
>
> Thoughts?
>
> -RK
> > --Imre
Re: [Intel-gfx] [PATCH v3] drm/i915/mtl: Disable stolen memory backed FB for A0
On 4/4/2023 8:27 PM, Ville Syrjälä wrote: On Tue, Apr 04, 2023 at 08:13:42PM +0200, Nirmoy Das wrote: Stolen memory is not usable for MTL A0 stepping beyond certain access size and we have no control over userspace access size of /dev/fb which can be backed by stolen memory. So disable stolen memory backed fb by setting i915->dsm.usable_size to zero. v2: remove hsdes reference and fix commit message(Andi) v3: use revid as we want to target SOC stepping(Radhakrishna) Cc: Matthew Auld Cc: Andi Shyti Cc: Daniele Ceraolo Spurio Cc: Lucas De Marchi Cc: Radhakrishna Sripada Signed-off-by: Nirmoy Das Reviewed-by: Andi Shyti --- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c index 8ac376c24aa2..ee492d823f1b 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c @@ -535,6 +535,14 @@ static int i915_gem_init_stolen(struct intel_memory_region *mem) /* Basic memrange allocator for stolen space. */ drm_mm_init(>mm.stolen, 0, i915->dsm.usable_size); + /* +* Access to stolen lmem beyond certain size for MTL A0 stepping +* would crash the machine. Disable stolen lmem for userspace access +* by setting usable_size to zero. +*/ + if (IS_METEORLAKE(i915) && INTEL_REVID(i915) == 0x0) + i915->dsm.usable_size = 0; That certainly won't prevent FBC from using stolen. Are we sure that FBC accesses are fine? I think so. I remember Jouni tested this patch internally to unblock a FBC test. Jouni, could you please share your thoughts. I can't seem to find the internal JIRA reference right now. Regards, Nirmoy + return 0; } -- 2.39.0
Re: [Intel-gfx] [PATCH v3 08/12] vfio/pci: Renaming for accepting device fd in hot reset path
On Sat, 1 Apr 2023 07:44:25 -0700
Yi Liu wrote:
> No functional change is intended.
>
> Reviewed-by: Kevin Tian
> Reviewed-by: Jason Gunthorpe
> Tested-by: Yanting Jiang
> Signed-off-by: Yi Liu
> ---
> drivers/vfio/pci/vfio_pci_core.c | 52
> 1 file changed, 26 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci_core.c
> b/drivers/vfio/pci/vfio_pci_core.c
> index 2a510b71edcb..da6325008872 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -177,10 +177,10 @@ static void vfio_pci_probe_mmaps(struct
> vfio_pci_core_device *vdev)
> }
> }
>
> -struct vfio_pci_group_info;
> +struct vfio_pci_file_info;
> static void vfio_pci_dev_set_try_reset(struct vfio_device_set *dev_set);
> static int vfio_pci_dev_set_hot_reset(struct vfio_device_set *dev_set,
> - struct vfio_pci_group_info *groups,
> + struct vfio_pci_file_info *info,
> struct iommufd_ctx *iommufd_ctx);
>
> /*
> @@ -800,7 +800,7 @@ static int vfio_pci_fill_devs(struct pci_dev *pdev, void
> *data)
> return 0;
> }
>
> -struct vfio_pci_group_info {
> +struct vfio_pci_file_info {
> int count;
> struct file **files;
> };
> @@ -1257,14 +1257,14 @@ static int vfio_pci_ioctl_get_pci_hot_reset_info(
> }
>
> static int
> -vfio_pci_ioctl_pci_hot_reset_groups(struct vfio_pci_core_device *vdev,
> - struct vfio_pci_hot_reset *hdr,
> - bool slot,
> - struct vfio_pci_hot_reset __user *arg)
> +vfio_pci_ioctl_pci_hot_reset_files(struct vfio_pci_core_device *vdev,
> +struct vfio_pci_hot_reset *hdr,
> +bool slot,
> +struct vfio_pci_hot_reset __user *arg)
> {
> - int32_t *group_fds;
> + int32_t *fds;
> struct file **files;
> - struct vfio_pci_group_info info;
> + struct vfio_pci_file_info info;
> int file_idx, count = 0, ret = 0;
>
> /*
> @@ -1281,17 +1281,17 @@ vfio_pci_ioctl_pci_hot_reset_groups(struct
> vfio_pci_core_device *vdev,
> if (hdr->count > count)
> return -EINVAL;
>
> - group_fds = kcalloc(hdr->count, sizeof(*group_fds), GFP_KERNEL);
> + fds = kcalloc(hdr->count, sizeof(*fds), GFP_KERNEL);
> files = kcalloc(hdr->count, sizeof(*files), GFP_KERNEL);
> - if (!group_fds || !files) {
> - kfree(group_fds);
> + if (!fds || !files) {
> + kfree(fds);
> kfree(files);
> return -ENOMEM;
> }
>
> - if (copy_from_user(group_fds, arg->group_fds,
> -hdr->count * sizeof(*group_fds))) {
> - kfree(group_fds);
> + if (copy_from_user(fds, arg->group_fds,
> +hdr->count * sizeof(*fds))) {
> + kfree(fds);
> kfree(files);
> return -EFAULT;
> }
> @@ -1301,7 +1301,7 @@ vfio_pci_ioctl_pci_hot_reset_groups(struct
> vfio_pci_core_device *vdev,
>* the reset
>*/
> for (file_idx = 0; file_idx < hdr->count; file_idx++) {
> - struct file *file = fget(group_fds[file_idx]);
> + struct file *file = fget(fds[file_idx]);
>
> if (!file) {
> ret = -EBADF;
> @@ -1318,9 +1318,9 @@ vfio_pci_ioctl_pci_hot_reset_groups(struct
> vfio_pci_core_device *vdev,
> files[file_idx] = file;
> }
>
> - kfree(group_fds);
> + kfree(fds);
>
> - /* release reference to groups on error */
> + /* release reference to fds on error */
> if (ret)
> goto hot_reset_release;
>
> @@ -1358,7 +1358,7 @@ static int vfio_pci_ioctl_pci_hot_reset(struct
> vfio_pci_core_device *vdev,
> return -ENODEV;
>
> if (hdr.count)
> - return vfio_pci_ioctl_pci_hot_reset_groups(vdev, , slot,
> arg);
> + return vfio_pci_ioctl_pci_hot_reset_files(vdev, , slot,
> arg);
>
> iommufd = vfio_iommufd_physical_ictx(>vdev);
>
> @@ -2329,16 +2329,16 @@ const struct pci_error_handlers
> vfio_pci_core_err_handlers = {
> };
> EXPORT_SYMBOL_GPL(vfio_pci_core_err_handlers);
>
> -static bool vfio_dev_in_groups(struct vfio_pci_core_device *vdev,
> -struct vfio_pci_group_info *groups)
> +static bool vfio_dev_in_files(struct vfio_pci_core_device *vdev,
> + struct vfio_pci_file_info *info)
> {
> unsigned int i;
>
> - if (!groups)
> + if (!info)
> return false;
>
> - for (i = 0; i < groups->count; i++)
> - if (vfio_file_has_dev(groups->files[i], >vdev))
> + for (i = 0; i < info->count; i++)
> + if (vfio_file_has_dev(info->files[i], >vdev))
>
[Intel-gfx] ✓ Fi.CI.BAT: success for dma-fence: Deadline awareness (rev2)
== Series Details == Series: dma-fence: Deadline awareness (rev2) URL : https://patchwork.freedesktop.org/series/114863/ State : success == Summary == CI Bug Log - changes from CI_DRM_12965 -> Patchwork_114863v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114863v2/index.html Participating hosts (38 -> 36) -- Missing(2): fi-kbl-soraka fi-snb-2520m Known issues Here are the changes found in Patchwork_114863v2 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@module-reload: - fi-bsw-n3050: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/fi-bsw-n3050/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114863v2/fi-bsw-n3050/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@slpc: - bat-rpls-1: NOTRUN -> [DMESG-FAIL][3] ([i915#6367]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114863v2/bat-rpls-1/igt@i915_selftest@l...@slpc.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-dg2-11: NOTRUN -> [SKIP][4] ([i915#7828]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114863v2/bat-dg2-11/igt@kms_chamelium_...@common-hpd-after-suspend.html - bat-rpls-1: NOTRUN -> [SKIP][5] ([i915#7828]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114863v2/bat-rpls-1/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][6] ([i915#5354]) +2 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114863v2/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html * igt@kms_pipe_crc_basic@suspend-read-crc: - bat-rpls-1: NOTRUN -> [SKIP][7] ([i915#1845]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114863v2/bat-rpls-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-hdmi-a-3: - bat-dg2-11: NOTRUN -> [INCOMPLETE][8] ([i915#7908]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114863v2/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-hdmi-a-3.html Possible fixes * igt@i915_selftest@live@gt_heartbeat: - fi-apl-guc: [DMESG-FAIL][9] ([i915#5334]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114863v2/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@gt_lrc: - bat-dg2-11: [INCOMPLETE][11] ([i915#7609] / [i915#7913]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114863v2/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html * igt@i915_selftest@live@requests: - bat-rpls-1: [ABORT][13] ([i915#4983] / [i915#7911]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/bat-rpls-1/igt@i915_selftest@l...@requests.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114863v2/bat-rpls-1/igt@i915_selftest@l...@requests.html [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334 [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#7908]: https://gitlab.freedesktop.org/drm/intel/issues/7908 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 Build changes - * Linux: CI_DRM_12965 -> Patchwork_114863v2 CI-20190529: 20190529 CI_DRM_12965: 53e37ca502cfe620396e498fae8430c293fb2c83 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7236: bac5a4cc31b3212a205219a6cbc45a173d30d04b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_114863v2: 53e37ca502cfe620396e498fae8430c293fb2c83 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 06e6595f265f drm/i915: Add deadline based boost support cb9e982d5078 drm/msm/atomic: Switch to vblank_start helper bdf5bc55f225 drm/msm: Add wait-boost support 5891ca38b3e1 drm/msm: Add deadline based boost support b4059a78d971 drm/atomic-helper: Set fence deadline for vblank a8d0c70c9462
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for dma-fence: Deadline awareness (rev2)
== Series Details == Series: dma-fence: Deadline awareness (rev2) URL : https://patchwork.freedesktop.org/series/114863/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for dma-fence: Deadline awareness (rev2)
== Series Details ==
Series: dma-fence: Deadline awareness (rev2)
URL : https://patchwork.freedesktop.org/series/114863/
State : warning
== Summary ==
Error: dim checkpatch failed
b82ef96a4f95 dma-buf/sync_file: Add SET_DEADLINE ioctl
-:12: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#12:
https://gitlab.freedesktop.org/robclark/igt-gpu-tools/-/commits/fence-deadline
total: 0 errors, 1 warnings, 0 checks, 73 lines checked
1f0b01a9198a dma-buf/sw_sync: Add fence deadline support
-:57: CHECK:LINE_SPACING: Please don't use multiple blank lines
#57: FILE: drivers/dma-buf/sw_sync.c:80:
+
+
-:119: WARNING:BRACES: braces {} are not necessary for any arm of this statement
#119: FILE: drivers/dma-buf/sw_sync.c:450:
+ if (test_bit(SW_SYNC_HAS_DEADLINE_BIT, >flags)) {
[...]
+ } else {
[...]
total: 0 errors, 1 warnings, 1 checks, 130 lines checked
d0201cc976fc drm/syncobj: Add deadline support for syncobj waits
-:41: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#41: FILE: drivers/gpu/drm/drm_syncobj.c:981:
+ uint32_t *idx,
-:96: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#96: FILE: drivers/gpu/drm/drm_syncobj.c:1264:
+ unsigned possible_flags;
-:137: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#137: FILE: drivers/gpu/drm/drm_syncobj.c:1307:
+ unsigned possible_flags;
total: 0 errors, 2 warnings, 1 checks, 177 lines checked
f0f1f4138061 drm/atomic-helper: Set fence deadline for vblank
-:14: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#14:
> > v3: If there are multiple CRTCs, consider the time of the soonest vblank
-:156: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)
total: 1 errors, 1 warnings, 0 checks, 18 lines checked
5d36f6c01873 drm/msm: Add deadline based boost support
-:26: WARNING:LINE_SPACING: Missing a blank line after declarations
#26: FILE: drivers/gpu/drm/msm/msm_fence.c:16:
+ struct msm_drm_private *priv = fctx->dev->dev_private;
+ return priv->gpu;
-:91: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#91: FILE: drivers/gpu/drm/msm/msm_fence.c:144:
+ if (ktime_after(now, fctx->next_deadline) ||
+ ktime_before(deadline, fctx->next_deadline)) {
-:105: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#105: FILE: drivers/gpu/drm/msm/msm_fence.c:158:
+ kthread_queue_work(fctx2gpu(fctx)->worker,
+ >deadline_work);
-:108: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#108: FILE: drivers/gpu/drm/msm/msm_fence.c:161:
+ hrtimer_start(>deadline_timer, deadline,
+ HRTIMER_MODE_ABS);
-:147: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#147: FILE: drivers/gpu/drm/msm/msm_fence.h:71:
+ uint32_t next_deadline_fence;
total: 0 errors, 1 warnings, 4 checks, 128 lines checked
25a5a1fbc3ed drm/msm: Add wait-boost support
651372c8d54b drm/msm/atomic: Switch to vblank_start helper
e60e06f3c7e1 drm/i915: Add deadline based boost support
Re: [Intel-gfx] [PATCH v3 11/12] iommufd: Define IOMMUFD_INVALID_ID in uapi
On Sat, 1 Apr 2023 07:44:28 -0700
Yi Liu wrote:
> as there are IOMMUFD users that want to know check if an ID generated
> by IOMMUFD is valid or not. e.g. vfio-pci optionaly returns invalid
> dev_id to user in the VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl. User
> needs to check if the ID is valid or not.
>
> IOMMUFD_INVALID_ID is defined as 0 since the IDs generated by IOMMUFD
> starts from 0.
>
> Signed-off-by: Yi Liu
> ---
> include/uapi/linux/iommufd.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h
> index 98ebba80cfa1..aeae73a93833 100644
> --- a/include/uapi/linux/iommufd.h
> +++ b/include/uapi/linux/iommufd.h
> @@ -9,6 +9,9 @@
>
> #define IOMMUFD_TYPE (';')
>
> +/* IDs allocated by IOMMUFD starts from 0 */
> +#define IOMMUFD_INVALID_ID 0
> +
> /**
> * DOC: General ioctl format
> *
If allocation "starts from 0" then 0 is a valid id, no? Does allocation
start from 1, ie. skip 0? Thanks,
Alex
Re: [Intel-gfx] [PATCH 7/8] video/aperture: Only remove sysfb on the default vga pci device
On 4/4/23 1:18 PM, Daniel Vetter wrote:
Instead of calling aperture_remove_conflicting_devices() to remove the
conflicting devices, just call to aperture_detach_devices() to detach
the device that matches the same PCI BAR / aperture range. Since the
former is just a wrapper of the latter plus a sysfb_disable() call,
and now that's done in this function but only for the primary devices.
This fixes a regression introduced by ee7a69aa38d8 ("fbdev: Disable
sysfb device registration when removing conflicting FBs"), where we
remove the sysfb when loading a driver for an unrelated pci device,
resulting in the user loosing their efifb console or similar.
Note that in practice this only is a problem with the nvidia blob,
because that's the only gpu driver people might install which does not
come with an fbdev driver of it's own. For everyone else the real gpu
driver will restore a working console.
It might be worth noting that this also affects devices that have no
driver installed, or where the driver failed to initialize or was
configured not to set a mode. E.g. I reproduced this problem on a laptop
with i915.modeset=0 and an NVIDIA driver that calls
drm_fbdev_generic_setup. It would also reproduce on a system that sets
modeset=0 (or has a GPU that's too new for its corresponding kernel
driver) and that passes an NVIDIA GPU through to a VM using vfio-pci
since that also calls aperture_remove_conflicting_pci_devices.
I agree that in practice this will mostly affect people with our driver
until I get my changes to add drm_fbdev_generic_setup checked in. But
these other cases don't seem all that unlikely to me.
-- Aaron
Also note that in the referenced bug there's confusion that this same
bug also happens on amdgpu. But that was just another amdgpu specific
regression, which just happened to happen at roughly the same time and
with the same user-observable symptoms. That bug is fixed now, see
https://bugzilla.kernel.org/show_bug.cgi?id=216331#c15
Note that we should not have any such issues on non-pci multi-gpu
issues, because I could only find two such cases:
- SoC with some external panel over spi or similar. These panel
drivers do not use drm_aperture_remove_conflicting_framebuffers(),
so no problem.
- vga+mga, which is a direct console driver and entirely bypasses all
this.
For the above reasons the cc: stable is just notionally, this patch
will need a backport and that's up to nvidia if they care enough.
v2:
- Explain a bit better why other multi-gpu that aren't pci shouldn't
have any issues with making all this fully pci specific.
v3
- polish commit message (Javier)
Fixes: ee7a69aa38d8 ("fbdev: Disable sysfb device registration when removing
conflicting FBs")
Tested-by: Aaron Plattner
Reviewed-by: Javier Martinez Canillas
References: https://bugzilla.kernel.org/show_bug.cgi?id=216303#c28
Signed-off-by: Daniel Vetter
Cc: Aaron Plattner
Cc: Javier Martinez Canillas
Cc: Thomas Zimmermann
Cc: Helge Deller
Cc: Sam Ravnborg
Cc: Alex Deucher
Cc: # v5.19+ (if someone else does the backport)
---
drivers/video/aperture.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
index 8f1437339e49..2394c2d310f8 100644
--- a/drivers/video/aperture.c
+++ b/drivers/video/aperture.c
@@ -321,15 +321,16 @@ int aperture_remove_conflicting_pci_devices(struct
pci_dev *pdev, const char *na
primary = pdev == vga_default_device();
+ if (primary)
+ sysfb_disable();
+
for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) {
if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
continue;
base = pci_resource_start(pdev, bar);
size = pci_resource_len(pdev, bar);
- ret = aperture_remove_conflicting_devices(base, size, name);
- if (ret)
- return ret;
+ aperture_detach_devices(base, size);
}
if (primary) {
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: Disable stolen memory backed FB for A0 (rev6)
== Series Details == Series: drm/i915/mtl: Disable stolen memory backed FB for A0 (rev6) URL : https://patchwork.freedesktop.org/series/114925/ State : success == Summary == CI Bug Log - changes from CI_DRM_12965 -> Patchwork_114925v6 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/index.html Participating hosts (38 -> 36) -- Missing(2): fi-kbl-soraka fi-snb-2520m Known issues Here are the changes found in Patchwork_114925v6 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@reset: - bat-rpls-1: NOTRUN -> [ABORT][1] ([i915#4983] / [i915#7981]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/bat-rpls-1/igt@i915_selftest@l...@reset.html * igt@i915_selftest@live@slpc: - bat-rpls-2: NOTRUN -> [DMESG-FAIL][2] ([i915#6367] / [i915#7913]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/bat-rpls-2/igt@i915_selftest@l...@slpc.html * igt@i915_suspend@basic-s2idle-without-i915: - bat-rpls-2: NOTRUN -> [ABORT][3] ([i915#6687]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/bat-rpls-2/igt@i915_susp...@basic-s2idle-without-i915.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-dg2-11: NOTRUN -> [SKIP][4] ([i915#7828]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/bat-dg2-11/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][5] ([i915#5354]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html Possible fixes * igt@i915_selftest@live@gt_heartbeat: - fi-apl-guc: [DMESG-FAIL][6] ([i915#5334]) -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@gt_lrc: - bat-dg2-11: [INCOMPLETE][8] ([i915#7609] / [i915#7913]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html * igt@i915_selftest@live@requests: - bat-rpls-2: [ABORT][10] ([i915#4983] / [i915#7913]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/bat-rpls-2/igt@i915_selftest@l...@requests.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/bat-rpls-2/igt@i915_selftest@l...@requests.html - bat-rpls-1: [ABORT][12] ([i915#4983] / [i915#7911]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/bat-rpls-1/igt@i915_selftest@l...@requests.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/bat-rpls-1/igt@i915_selftest@l...@requests.html * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1: - bat-dg2-8: [FAIL][14] ([i915#7932]) -> [PASS][15] +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114925v6/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334 [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687 [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932 [i915#7981]: https://gitlab.freedesktop.org/drm/intel/issues/7981 Build changes - * Linux: CI_DRM_12965 -> Patchwork_114925v6 CI-20190529: 20190529 CI_DRM_12965: 53e37ca502cfe620396e498fae8430c293fb2c83 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7236: bac5a4cc31b3212a205219a6cbc45a173d30d04b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_114925v6: 53e37ca502cfe620396e498fae8430c293fb2c83 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 904d135573d2 drm/i915/mtl: Disable stolen memory backed FB for A0 == Logs == For more details see:
Re: [Intel-gfx] [PATCH v3 07/12] vfio: Accpet device file from vfio PCI hot reset path
On Sat, 1 Apr 2023 07:44:24 -0700
Yi Liu wrote:
> This extends both vfio_file_is_valid() and vfio_file_has_dev() to accept
> device file from the vfio PCI hot reset.
>
> Reviewed-by: Kevin Tian
> Reviewed-by: Jason Gunthorpe
> Tested-by: Yanting Jiang
> Signed-off-by: Yi Liu
> ---
> drivers/vfio/vfio_main.c | 23 +++
> 1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> index fe7446805afd..ebbb6b91a498 100644
> --- a/drivers/vfio/vfio_main.c
> +++ b/drivers/vfio/vfio_main.c
> @@ -1154,13 +1154,23 @@ const struct file_operations vfio_device_fops = {
> .mmap = vfio_device_fops_mmap,
> };
>
> +static struct vfio_device *vfio_device_from_file(struct file *file)
> +{
> + struct vfio_device *device = file->private_data;
> +
> + if (file->f_op != _device_fops)
> + return NULL;
> + return device;
> +}
> +
> /**
> * vfio_file_is_valid - True if the file is valid vfio file
> * @file: VFIO group file or VFIO device file
> */
> bool vfio_file_is_valid(struct file *file)
> {
> - return vfio_group_from_file(file);
> + return vfio_group_from_file(file) ||
> +vfio_device_from_file(file);
> }
> EXPORT_SYMBOL_GPL(vfio_file_is_valid);
>
> @@ -1174,12 +1184,17 @@ EXPORT_SYMBOL_GPL(vfio_file_is_valid);
> bool vfio_file_has_dev(struct file *file, struct vfio_device *device)
> {
> struct vfio_group *group;
> + struct vfio_device *vdev;
>
> group = vfio_group_from_file(file);
> - if (!group)
> - return false;
> + if (group)
> + return vfio_group_has_dev(group, device);
> +
> + vdev = vfio_device_from_file(file);
> + if (vdev)
> + return vdev == device;
>
> - return vfio_group_has_dev(group, device);
> + return false;
Nit, unless we expect to be testing against NULL devices, this could
just be:
return device == vfio_device_from_file(file);
Thanks,
Alex
[Intel-gfx] [PATCH 8/8] fbdev: Simplify fb_is_primary_device for x86
vga_default_device really is supposed to cover all corners, at least
for x86. Additionally checking for rom shadowing should be redundant,
because the bios/fw only does that for the boot vga device.
If this turns out to be wrong, then most likely that's a special case
which should be added to the vgaarb code, not replicated all over.
Patch motived by changes to the aperture helpers, which also have this
open code in a bunch of places, and which are all removed in a
clean-up series. This function here is just for selecting the default
fbdev device for fbcon, but I figured for consistency it might be good
to throw this patch in on top.
Note that the shadow rom check predates vgaarb, which was only wired
up in 88674088d10c ("x86: Use vga_default_device() when determining
whether an fb is primary"). That patch doesn't explain why we still
fall back to the shadow rom check.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Helge Deller
Cc: Daniel Vetter
Cc: Javier Martinez Canillas
Cc: Thomas Zimmermann
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Dave Hansen
Cc: x...@kernel.org
Cc: "H. Peter Anvin"
---
arch/x86/video/fbdev.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/arch/x86/video/fbdev.c b/arch/x86/video/fbdev.c
index 9fd24846d094..5ec4eafbb981 100644
--- a/arch/x86/video/fbdev.c
+++ b/arch/x86/video/fbdev.c
@@ -14,26 +14,15 @@
int fb_is_primary_device(struct fb_info *info)
{
struct device *device = info->device;
- struct pci_dev *default_device = vga_default_device();
struct pci_dev *pci_dev;
- struct resource *res;
if (!device || !dev_is_pci(device))
return 0;
pci_dev = to_pci_dev(device);
- if (default_device) {
- if (pci_dev == default_device)
- return 1;
- return 0;
- }
-
- res = pci_dev->resource + PCI_ROM_RESOURCE;
-
- if (res->flags & IORESOURCE_ROM_SHADOW)
+ if (pci_dev == vga_default_device())
return 1;
-
return 0;
}
EXPORT_SYMBOL(fb_is_primary_device);
--
2.40.0
[Intel-gfx] [PATCH 4/8] video/aperture: Only kick vgacon when the pdev is decoding vga
Otherwise it's bit silly, and we might throw out the driver for the
screen the user is actually looking at. I haven't found a bug report
for this case yet, but we did get bug reports for the analog case
where we're throwing out the efifb driver.
v2: Flip the check around to make it clear it's a special case for
kicking out the vgacon driver only (Thomas)
References: https://bugzilla.kernel.org/show_bug.cgi?id=216303
Signed-off-by: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
---
drivers/video/aperture.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
index 8835d3bc39bf..552cffdb827b 100644
--- a/drivers/video/aperture.c
+++ b/drivers/video/aperture.c
@@ -341,13 +341,15 @@ int aperture_remove_conflicting_pci_devices(struct
pci_dev *pdev, const char *na
return ret;
}
- /*
-* WARNING: Apparently we must kick fbdev drivers before vgacon,
-* otherwise the vga fbdev driver falls over.
-*/
- ret = vga_remove_vgacon(pdev);
- if (ret)
- return ret;
+ if (primary) {
+ /*
+* WARNING: Apparently we must kick fbdev drivers before vgacon,
+* otherwise the vga fbdev driver falls over.
+*/
+ ret = vga_remove_vgacon(pdev);
+ if (ret)
+ return ret;
+ }
return 0;
--
2.40.0
[Intel-gfx] [PATCH 7/8] video/aperture: Only remove sysfb on the default vga pci device
Instead of calling aperture_remove_conflicting_devices() to remove the
conflicting devices, just call to aperture_detach_devices() to detach
the device that matches the same PCI BAR / aperture range. Since the
former is just a wrapper of the latter plus a sysfb_disable() call,
and now that's done in this function but only for the primary devices.
This fixes a regression introduced by ee7a69aa38d8 ("fbdev: Disable
sysfb device registration when removing conflicting FBs"), where we
remove the sysfb when loading a driver for an unrelated pci device,
resulting in the user loosing their efifb console or similar.
Note that in practice this only is a problem with the nvidia blob,
because that's the only gpu driver people might install which does not
come with an fbdev driver of it's own. For everyone else the real gpu
driver will restore a working console.
Also note that in the referenced bug there's confusion that this same
bug also happens on amdgpu. But that was just another amdgpu specific
regression, which just happened to happen at roughly the same time and
with the same user-observable symptoms. That bug is fixed now, see
https://bugzilla.kernel.org/show_bug.cgi?id=216331#c15
Note that we should not have any such issues on non-pci multi-gpu
issues, because I could only find two such cases:
- SoC with some external panel over spi or similar. These panel
drivers do not use drm_aperture_remove_conflicting_framebuffers(),
so no problem.
- vga+mga, which is a direct console driver and entirely bypasses all
this.
For the above reasons the cc: stable is just notionally, this patch
will need a backport and that's up to nvidia if they care enough.
v2:
- Explain a bit better why other multi-gpu that aren't pci shouldn't
have any issues with making all this fully pci specific.
v3
- polish commit message (Javier)
Fixes: ee7a69aa38d8 ("fbdev: Disable sysfb device registration when removing
conflicting FBs")
Tested-by: Aaron Plattner
Reviewed-by: Javier Martinez Canillas
References: https://bugzilla.kernel.org/show_bug.cgi?id=216303#c28
Signed-off-by: Daniel Vetter
Cc: Aaron Plattner
Cc: Javier Martinez Canillas
Cc: Thomas Zimmermann
Cc: Helge Deller
Cc: Sam Ravnborg
Cc: Alex Deucher
Cc: # v5.19+ (if someone else does the backport)
---
drivers/video/aperture.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
index 8f1437339e49..2394c2d310f8 100644
--- a/drivers/video/aperture.c
+++ b/drivers/video/aperture.c
@@ -321,15 +321,16 @@ int aperture_remove_conflicting_pci_devices(struct
pci_dev *pdev, const char *na
primary = pdev == vga_default_device();
+ if (primary)
+ sysfb_disable();
+
for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) {
if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
continue;
base = pci_resource_start(pdev, bar);
size = pci_resource_len(pdev, bar);
- ret = aperture_remove_conflicting_devices(base, size, name);
- if (ret)
- return ret;
+ aperture_detach_devices(base, size);
}
if (primary) {
--
2.40.0
[Intel-gfx] [PATCH 6/8] video/aperture: Drop primary argument
With the preceeding patches it's become defunct. Also I'm about to add
a different boolean argument, so it's better to keep the confusion
down to the absolute minimum.
v2: Since the hypervfb patch got droppped (it's only a pci device for
gen1 vm, not for gen2) there is one leftover user in an actual driver
left to touch.
Signed-off-by: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Wei Liu
Cc: Dexuan Cui
Cc: linux-hyp...@vger.kernel.org
---
drivers/gpu/drm/drm_aperture.c | 2 +-
drivers/video/aperture.c| 7 +++
drivers/video/fbdev/hyperv_fb.c | 2 +-
include/linux/aperture.h| 9 -
4 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_aperture.c b/drivers/gpu/drm/drm_aperture.c
index 697cffbfd603..5729f3bb4398 100644
--- a/drivers/gpu/drm/drm_aperture.c
+++ b/drivers/gpu/drm/drm_aperture.c
@@ -168,7 +168,7 @@ EXPORT_SYMBOL(devm_aperture_acquire_from_firmware);
int drm_aperture_remove_conflicting_framebuffers(resource_size_t base,
resource_size_t size,
const struct drm_driver
*req_driver)
{
- return aperture_remove_conflicting_devices(base, size, false,
req_driver->name);
+ return aperture_remove_conflicting_devices(base, size,
req_driver->name);
}
EXPORT_SYMBOL(drm_aperture_remove_conflicting_framebuffers);
diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
index ec9387d94049..8f1437339e49 100644
--- a/drivers/video/aperture.c
+++ b/drivers/video/aperture.c
@@ -43,7 +43,7 @@
* base = mem->start;
* size = resource_size(mem);
*
- * ret = aperture_remove_conflicting_devices(base, size, false,
"example");
+ * ret = aperture_remove_conflicting_devices(base, size,
"example");
* if (ret)
* return ret;
*
@@ -274,7 +274,6 @@ static void aperture_detach_devices(resource_size_t base,
resource_size_t size)
* aperture_remove_conflicting_devices - remove devices in the given range
* @base: the aperture's base address in physical memory
* @size: aperture size in bytes
- * @primary: also kick vga16fb if present; only relevant for VGA devices
* @name: a descriptive name of the requesting driver
*
* This function removes devices that own apertures within @base and @size.
@@ -283,7 +282,7 @@ static void aperture_detach_devices(resource_size_t base,
resource_size_t size)
* 0 on success, or a negative errno code otherwise
*/
int aperture_remove_conflicting_devices(resource_size_t base, resource_size_t
size,
- bool primary, const char *name)
+ const char *name)
{
/*
* If a driver asked to unregister a platform device registered by
@@ -328,7 +327,7 @@ int aperture_remove_conflicting_pci_devices(struct pci_dev
*pdev, const char *na
base = pci_resource_start(pdev, bar);
size = pci_resource_len(pdev, bar);
- ret = aperture_remove_conflicting_devices(base, size, primary,
name);
+ ret = aperture_remove_conflicting_devices(base, size, name);
if (ret)
return ret;
}
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index ec3f6cf05f8c..54f433e09ab8 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -1073,7 +1073,7 @@ static int hvfb_getmem(struct hv_device *hdev, struct
fb_info *info)
info->screen_size = dio_fb_size;
getmem_done:
- aperture_remove_conflicting_devices(base, size, false, KBUILD_MODNAME);
+ aperture_remove_conflicting_devices(base, size, KBUILD_MODNAME);
if (gen2vm) {
/* framebuffer is reallocated, clear screen_info to avoid
misuse from kexec */
diff --git a/include/linux/aperture.h b/include/linux/aperture.h
index 442f15a57cad..7248727753be 100644
--- a/include/linux/aperture.h
+++ b/include/linux/aperture.h
@@ -14,7 +14,7 @@ int devm_aperture_acquire_for_platform_device(struct
platform_device *pdev,
resource_size_t size);
int aperture_remove_conflicting_devices(resource_size_t base, resource_size_t
size,
- bool primary, const char *name);
+ const char *name);
int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const char
*name);
#else
@@ -26,7 +26,7 @@ static inline int
devm_aperture_acquire_for_platform_device(struct platform_devi
}
static inline int aperture_remove_conflicting_devices(resource_size_t base,
resource_size_t size,
- bool primary, const char
*name)
+
[Intel-gfx] [PATCH 5/8] video/aperture: Move vga handling to pci function
A few reasons for this:
- It's really the only one where this matters. I tried looking around,
and I didn't find any non-pci vga-compatible controllers for x86
(since that's the only platform where we had this until a few
patches ago), where a driver participating in the aperture claim
dance would interfere.
- I also don't expect that any future bus anytime soon will
not just look like pci towards the OS, that's been the case for like
25+ years by now for practically everything (even non non-x86).
- Also it's a bit funny if we have one part of the vga removal in the
pci function, and the other in the generic one.
v2: Rebase.
Signed-off-by: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
---
drivers/video/aperture.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
index 552cffdb827b..ec9387d94049 100644
--- a/drivers/video/aperture.c
+++ b/drivers/video/aperture.c
@@ -298,14 +298,6 @@ int aperture_remove_conflicting_devices(resource_size_t
base, resource_size_t si
aperture_detach_devices(base, size);
- /*
-* If this is the primary adapter, there could be a VGA device
-* that consumes the VGA framebuffer I/O range. Remove this device
-* as well.
-*/
- if (primary)
- aperture_detach_devices(VGA_FB_PHYS_BASE, VGA_FB_PHYS_SIZE);
-
return 0;
}
EXPORT_SYMBOL(aperture_remove_conflicting_devices);
@@ -342,6 +334,13 @@ int aperture_remove_conflicting_pci_devices(struct pci_dev
*pdev, const char *na
}
if (primary) {
+ /*
+* If this is the primary adapter, there could be a VGA device
+* that consumes the VGA framebuffer I/O range. Remove this
+* device as well.
+*/
+ aperture_detach_devices(VGA_FB_PHYS_BASE, VGA_FB_PHYS_SIZE);
+
/*
* WARNING: Apparently we must kick fbdev drivers before vgacon,
* otherwise the vga fbdev driver falls over.
--
2.40.0
[Intel-gfx] [PATCH 1/8] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers
This one nukes all framebuffers, which is a bit much. In reality gma500 is igpu and never shipped with anything discrete, so there should not be any difference. v2: Unfortunately the framebuffer sits outside of the pci bars for gma500, and so only using the pci helpers won't be enough. Otoh if we only use non-pci helper, then we don't get the vga handling, and subsequent refactoring to untangle these special cases won't work. It's not pretty, but the simplest fix (since gma500 really is the only quirky pci driver like this we have) is to just have both calls. Signed-off-by: Daniel Vetter Cc: Patrik Jakobsson Cc: Thomas Zimmermann Cc: Javier Martinez Canillas --- drivers/gpu/drm/gma500/psb_drv.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c index 2ce96b1b9c74..f1e0eed8fea4 100644 --- a/drivers/gpu/drm/gma500/psb_drv.c +++ b/drivers/gpu/drm/gma500/psb_drv.c @@ -422,12 +422,17 @@ static int psb_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) /* * We cannot yet easily find the framebuffer's location in memory. So -* remove all framebuffers here. +* remove all framebuffers here. Note that we still want the pci special +* handling to kick out vgacon. * * TODO: Refactor psb_driver_load() to map vdc_reg earlier. Then we * might be able to read the framebuffer range from the device. */ - ret = drm_aperture_remove_framebuffers(true, ); + ret = drm_aperture_remove_framebuffers(false, ); + if (ret) + return ret; + + ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, ); if (ret) return ret; -- 2.40.0
[Intel-gfx] [PATCH 3/8] drm/aperture: Remove primary argument
Only really pci devices have a business setting this - it's for
figuring out whether the legacy vga stuff should be nuked too. And
with the preceeding two patches those are all using the pci version of
this.
Which means for all other callers primary == false and we can remove
it now.
v2:
- Reorder to avoid compile fail (Thomas)
- Include gma500, which retained it's called to the non-pci version.
Signed-off-by: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Deepak Rawat
Cc: Neil Armstrong
Cc: Kevin Hilman
Cc: Jerome Brunet
Cc: Martin Blumenstingl
Cc: Thierry Reding
Cc: Jonathan Hunter
Cc: Emma Anholt
Cc: Helge Deller
Cc: David Airlie
Cc: Daniel Vetter
Cc: linux-hyp...@vger.kernel.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-te...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
---
drivers/gpu/drm/arm/hdlcd_drv.c | 2 +-
drivers/gpu/drm/armada/armada_drv.c | 2 +-
drivers/gpu/drm/drm_aperture.c | 11 +++
drivers/gpu/drm/gma500/psb_drv.c| 2 +-
drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 1 -
drivers/gpu/drm/meson/meson_drv.c | 2 +-
drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
drivers/gpu/drm/stm/drv.c | 2 +-
drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +-
drivers/gpu/drm/tegra/drm.c | 2 +-
drivers/gpu/drm/vc4/vc4_drv.c | 2 +-
include/drm/drm_aperture.h | 7 +++
13 files changed, 16 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index 9020bf820bc8..12f5a2c7f03d 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -285,7 +285,7 @@ static int hdlcd_drm_bind(struct device *dev)
*/
if (hdlcd_read(hdlcd, HDLCD_REG_COMMAND)) {
hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
- drm_aperture_remove_framebuffers(false, _driver);
+ drm_aperture_remove_framebuffers(_driver);
}
drm_mode_config_reset(drm);
diff --git a/drivers/gpu/drm/armada/armada_drv.c
b/drivers/gpu/drm/armada/armada_drv.c
index 0643887800b4..c99ec7078301 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -95,7 +95,7 @@ static int armada_drm_bind(struct device *dev)
}
/* Remove early framebuffers */
- ret = drm_aperture_remove_framebuffers(false, _drm_driver);
+ ret = drm_aperture_remove_framebuffers(_drm_driver);
if (ret) {
dev_err(dev, "[" DRM_NAME ":%s] can't kick out simple-fb: %d\n",
__func__, ret);
diff --git a/drivers/gpu/drm/drm_aperture.c b/drivers/gpu/drm/drm_aperture.c
index 3b8fdeeafd53..697cffbfd603 100644
--- a/drivers/gpu/drm/drm_aperture.c
+++ b/drivers/gpu/drm/drm_aperture.c
@@ -32,17 +32,13 @@
*
* static int remove_conflicting_framebuffers(struct pci_dev *pdev)
* {
- * bool primary = false;
* resource_size_t base, size;
* int ret;
*
* base = pci_resource_start(pdev, 0);
* size = pci_resource_len(pdev, 0);
- * #ifdef CONFIG_X86
- * primary = pdev->resource[PCI_ROM_RESOURCE].flags &
IORESOURCE_ROM_SHADOW;
- * #endif
*
- * return drm_aperture_remove_conflicting_framebuffers(base, size,
primary,
+ * return drm_aperture_remove_conflicting_framebuffers(base, size,
*
_driver);
* }
*
@@ -161,7 +157,6 @@ EXPORT_SYMBOL(devm_aperture_acquire_from_firmware);
* drm_aperture_remove_conflicting_framebuffers - remove existing framebuffers
in the given range
* @base: the aperture's base address in physical memory
* @size: aperture size in bytes
- * @primary: also kick vga16fb if present
* @req_driver: requesting DRM driver
*
* This function removes graphics device drivers which use the memory range
described by
@@ -171,9 +166,9 @@ EXPORT_SYMBOL(devm_aperture_acquire_from_firmware);
* 0 on success, or a negative errno code otherwise
*/
int drm_aperture_remove_conflicting_framebuffers(resource_size_t base,
resource_size_t size,
-bool primary, const struct
drm_driver *req_driver)
+const struct drm_driver
*req_driver)
{
- return aperture_remove_conflicting_devices(base, size, primary,
req_driver->name);
+ return aperture_remove_conflicting_devices(base, size, false,
req_driver->name);
}
EXPORT_SYMBOL(drm_aperture_remove_conflicting_framebuffers);
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index f1e0eed8fea4..4bb06a89e48d 100644
---
[Intel-gfx] [PATCH 2/8] video/aperture: use generic code to figure out the vga default device
Since vgaarb has been promoted to be a core piece of the pci subsystem
we don't have to open code random guesses anymore, we actually know
this in a platform agnostic way, and there's no need for an x86
specific hack. See also 1d38fe6ee6a8 ("PCI/VGA: Move vgaarb to
drivers/pci")
This should not result in any functional change, and the non-x86
multi-gpu pci systems are probably rare enough to not matter (I don't
know of any tbh). But it's a nice cleanup, so let's do it.
There's been a few questions on previous iterations on dri-devel and
irc:
- fb_is_primary_device() seems to be yet another implementation of
this theme, and at least on x86 it checks for both
vga_default_device OR rom shadowing. There shouldn't ever be a case
where rom shadowing gives any additional hints about the boot vga
device, but if there is then the default vga selection in vgaarb
should probably be fixed. And not special-case checks replicated all
over.
- Thomas also brought up that on most !x86 systems
fb_is_primary_device() returns 0, except on sparc/parisc. But these
2 special cases are about platform specific devices and not pci, so
shouldn't have any interactions.
- Furthermore fb_is_primary_device() is a bit a red herring since it's
only used to select the right fbdev driver for fbcon, and not for
the fw handover dance which the aperture helpers handle. At least
for x86 we might want to look into unifying them, but that's a
separate thing.
v2: Extend commit message trying to summarize various discussions.
Signed-off-by: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
---
drivers/video/aperture.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
index b009468ffdff..8835d3bc39bf 100644
--- a/drivers/video/aperture.c
+++ b/drivers/video/aperture.c
@@ -324,13 +324,11 @@ EXPORT_SYMBOL(aperture_remove_conflicting_devices);
*/
int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const char
*name)
{
- bool primary = false;
+ bool primary;
resource_size_t base, size;
int bar, ret;
-#ifdef CONFIG_X86
- primary = pdev->resource[PCI_ROM_RESOURCE].flags &
IORESOURCE_ROM_SHADOW;
-#endif
+ primary = pdev == vga_default_device();
for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) {
if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
--
2.40.0
Re: [Intel-gfx] [PATCH v3 05/12] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
On Sat, 1 Apr 2023 07:44:22 -0700
Yi Liu wrote:
> as an alternative method for ownership check when iommufd is used. In
> this case all opened devices in the affected dev_set are verified to
> be bound to a same valid iommufd value to allow reset. It's simpler
> and faster as user does not need to pass a set of fds and kernel no
> need to search the device within the given fds.
>
> a device in noiommu mode doesn't have a valid iommufd, so this method
> should not be used in a dev_set which contains multiple devices and one
> of them is in noiommu. The only allowed noiommu scenario is that the
> calling device is noiommu and it's in a singleton dev_set.
>
> Suggested-by: Jason Gunthorpe
> Signed-off-by: Jason Gunthorpe
> Reviewed-by: Jason Gunthorpe
> Tested-by: Yanting Jiang
> Signed-off-by: Yi Liu
> ---
> drivers/vfio/pci/vfio_pci_core.c | 42 +++-
> include/uapi/linux/vfio.h| 9 ++-
> 2 files changed, 44 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci_core.c
> b/drivers/vfio/pci/vfio_pci_core.c
> index 3696b8e58445..b68fcba67a4b 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -180,7 +180,8 @@ static void vfio_pci_probe_mmaps(struct
> vfio_pci_core_device *vdev)
> struct vfio_pci_group_info;
> static void vfio_pci_dev_set_try_reset(struct vfio_device_set *dev_set);
> static int vfio_pci_dev_set_hot_reset(struct vfio_device_set *dev_set,
> - struct vfio_pci_group_info *groups);
> + struct vfio_pci_group_info *groups,
> + struct iommufd_ctx *iommufd_ctx);
>
> /*
> * INTx masking requires the ability to disable INTx signaling via
> PCI_COMMAND
> @@ -1277,7 +1278,7 @@ vfio_pci_ioctl_pci_hot_reset_groups(struct
> vfio_pci_core_device *vdev,
> return ret;
>
> /* Somewhere between 1 and count is OK */
> - if (!hdr->count || hdr->count > count)
> + if (hdr->count > count)
> return -EINVAL;
>
> group_fds = kcalloc(hdr->count, sizeof(*group_fds), GFP_KERNEL);
> @@ -1326,7 +1327,7 @@ vfio_pci_ioctl_pci_hot_reset_groups(struct
> vfio_pci_core_device *vdev,
> info.count = hdr->count;
> info.files = files;
>
> - ret = vfio_pci_dev_set_hot_reset(vdev->vdev.dev_set, );
> + ret = vfio_pci_dev_set_hot_reset(vdev->vdev.dev_set, , NULL);
>
> hot_reset_release:
> for (file_idx--; file_idx >= 0; file_idx--)
> @@ -1341,6 +1342,7 @@ static int vfio_pci_ioctl_pci_hot_reset(struct
> vfio_pci_core_device *vdev,
> {
> unsigned long minsz = offsetofend(struct vfio_pci_hot_reset, count);
> struct vfio_pci_hot_reset hdr;
> + struct iommufd_ctx *iommufd;
> bool slot = false;
>
> if (copy_from_user(, arg, minsz))
> @@ -1355,7 +1357,12 @@ static int vfio_pci_ioctl_pci_hot_reset(struct
> vfio_pci_core_device *vdev,
> else if (pci_probe_reset_bus(vdev->pdev->bus))
> return -ENODEV;
>
> - return vfio_pci_ioctl_pci_hot_reset_groups(vdev, , slot, arg);
> + if (hdr.count)
> + return vfio_pci_ioctl_pci_hot_reset_groups(vdev, , slot,
> arg);
> +
> + iommufd = vfio_iommufd_physical_ictx(>vdev);
> +
> + return vfio_pci_dev_set_hot_reset(vdev->vdev.dev_set, NULL, iommufd);
> }
>
> static int vfio_pci_ioctl_ioeventfd(struct vfio_pci_core_device *vdev,
> @@ -2327,6 +2334,9 @@ static bool vfio_dev_in_groups(struct
> vfio_pci_core_device *vdev,
> {
> unsigned int i;
>
> + if (!groups)
> + return false;
> +
> for (i = 0; i < groups->count; i++)
> if (vfio_file_has_dev(groups->files[i], >vdev))
> return true;
> @@ -2402,13 +2412,25 @@ static int vfio_pci_dev_set_pm_runtime_get(struct
> vfio_device_set *dev_set)
> return ret;
> }
>
> +static bool vfio_dev_in_iommufd_ctx(struct vfio_pci_core_device *vdev,
> + struct iommufd_ctx *iommufd_ctx)
> +{
> + struct iommufd_ctx *iommufd = vfio_iommufd_physical_ictx(>vdev);
> +
> + if (!iommufd)
> + return false;
> +
> + return iommufd == iommufd_ctx;
> +}
> +
> /*
> * We need to get memory_lock for each device, but devices can share
> mmap_lock,
> * therefore we need to zap and hold the vma_lock for each device, and only
> then
> * get each memory_lock.
> */
> static int vfio_pci_dev_set_hot_reset(struct vfio_device_set *dev_set,
> - struct vfio_pci_group_info *groups)
> + struct vfio_pci_group_info *groups,
> + struct iommufd_ctx *iommufd_ctx)
> {
> struct vfio_pci_core_device *cur_mem;
> struct vfio_pci_core_device *cur_vma;
> @@ -2448,9 +2470,17 @@ static int vfio_pci_dev_set_hot_reset(struct
> vfio_device_set *dev_set,
>*
>
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Allow arbitrary refresh rates with VRR eDP panels
== Series Details == Series: series starting with [1/3] drm/i915: Allow arbitrary refresh rates with VRR eDP panels URL : https://patchwork.freedesktop.org/series/116101/ State : success == Summary == CI Bug Log - changes from CI_DRM_12965 -> Patchwork_116101v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/index.html Participating hosts (38 -> 36) -- Missing(2): fi-kbl-soraka fi-snb-2520m Known issues Here are the changes found in Patchwork_116101v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0@smem: - bat-rpls-2: NOTRUN -> [ABORT][1] ([i915#6687]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-1: NOTRUN -> [ABORT][2] ([i915#6687] / [i915#7978]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@slpc: - bat-rpls-2: NOTRUN -> [DMESG-FAIL][3] ([i915#6367] / [i915#7913] / [i915#7996]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html - bat-rpls-1: NOTRUN -> [DMESG-FAIL][4] ([i915#6367]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-dg2-11: NOTRUN -> [SKIP][5] ([i915#7828]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/bat-dg2-11/igt@kms_chamelium_...@common-hpd-after-suspend.html Possible fixes * igt@i915_selftest@live@gt_heartbeat: - fi-apl-guc: [DMESG-FAIL][6] ([i915#5334]) -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@gt_lrc: - bat-dg2-11: [INCOMPLETE][8] ([i915#7609] / [i915#7913]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html * igt@i915_selftest@live@requests: - bat-rpls-2: [ABORT][10] ([i915#4983] / [i915#7913]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/bat-rpls-2/igt@i915_selftest@l...@requests.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/bat-rpls-2/igt@i915_selftest@l...@requests.html - bat-rpls-1: [ABORT][12] ([i915#4983] / [i915#7911]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/bat-rpls-1/igt@i915_selftest@l...@requests.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/bat-rpls-1/igt@i915_selftest@l...@requests.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1: - bat-dg2-8: [FAIL][14] ([i915#7932]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116101v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687 [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932 [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978 [i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996 Build changes - * Linux: CI_DRM_12965 -> Patchwork_116101v1 CI-20190529: 20190529 CI_DRM_12965: 53e37ca502cfe620396e498fae8430c293fb2c83 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7236: bac5a4cc31b3212a205219a6cbc45a173d30d04b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_116101v1: 53e37ca502cfe620396e498fae8430c293fb2c83 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 3aa58bc3bca9 drm/i915: Use min() instead of hand rolling it 4dbf01e7922b drm/i915: Evade transcoder's vblank when doing seamless M/N
[Intel-gfx] [PATCH RESEND v3 2/3] drm/ttm: Reduce the number of used allocation orders for TTM pages
When swapping out, we will split multi-order pages both in order to
move them to the swap-cache and to be able to return memory to the
swap cache as soon as possible on a page-by-page basis.
Reduce the page max order to the system PMD size, as we can then be nicer
to the system and avoid splitting gigantic pages.
Looking forward to when we might be able to swap out PMD size folios
without splitting, this will also be a benefit.
v2:
- Include all orders up to the PMD size (Christian König)
v3:
- Avoid compilation errors for architectures with special PFN_SHIFTs
Signed-off-by: Thomas Hellström
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index dfce896c4bae..18c342a919a2 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -47,6 +47,11 @@
#include "ttm_module.h"
+#define TTM_MAX_ORDER (PMD_SHIFT - PAGE_SHIFT)
+#define __TTM_DIM_ORDER (TTM_MAX_ORDER + 1)
+/* Some architectures have a weird PMD_SHIFT */
+#define TTM_DIM_ORDER (__TTM_DIM_ORDER <= MAX_ORDER ? __TTM_DIM_ORDER :
MAX_ORDER)
+
/**
* struct ttm_pool_dma - Helper object for coherent DMA mappings
*
@@ -65,11 +70,11 @@ module_param(page_pool_size, ulong, 0644);
static atomic_long_t allocated_pages;
-static struct ttm_pool_type global_write_combined[MAX_ORDER];
-static struct ttm_pool_type global_uncached[MAX_ORDER];
+static struct ttm_pool_type global_write_combined[TTM_DIM_ORDER];
+static struct ttm_pool_type global_uncached[TTM_DIM_ORDER];
-static struct ttm_pool_type global_dma32_write_combined[MAX_ORDER];
-static struct ttm_pool_type global_dma32_uncached[MAX_ORDER];
+static struct ttm_pool_type global_dma32_write_combined[TTM_DIM_ORDER];
+static struct ttm_pool_type global_dma32_uncached[TTM_DIM_ORDER];
static spinlock_t shrinker_lock;
static struct list_head shrinker_list;
@@ -444,7 +449,7 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt *tt,
else
gfp_flags |= GFP_HIGHUSER;
- for (order = min_t(unsigned int, MAX_ORDER - 1, __fls(num_pages));
+ for (order = min_t(unsigned int, TTM_MAX_ORDER, __fls(num_pages));
num_pages;
order = min_t(unsigned int, order, __fls(num_pages))) {
struct ttm_pool_type *pt;
@@ -563,7 +568,7 @@ void ttm_pool_init(struct ttm_pool *pool, struct device
*dev,
if (use_dma_alloc) {
for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
- for (j = 0; j < MAX_ORDER; ++j)
+ for (j = 0; j < TTM_DIM_ORDER; ++j)
ttm_pool_type_init(>caching[i].orders[j],
pool, i, j);
}
@@ -583,7 +588,7 @@ void ttm_pool_fini(struct ttm_pool *pool)
if (pool->use_dma_alloc) {
for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
- for (j = 0; j < MAX_ORDER; ++j)
+ for (j = 0; j < TTM_DIM_ORDER; ++j)
ttm_pool_type_fini(>caching[i].orders[j]);
}
@@ -637,7 +642,7 @@ static void ttm_pool_debugfs_header(struct seq_file *m)
unsigned int i;
seq_puts(m, "\t ");
- for (i = 0; i < MAX_ORDER; ++i)
+ for (i = 0; i < TTM_DIM_ORDER; ++i)
seq_printf(m, " ---%2u---", i);
seq_puts(m, "\n");
}
@@ -648,7 +653,7 @@ static void ttm_pool_debugfs_orders(struct ttm_pool_type
*pt,
{
unsigned int i;
- for (i = 0; i < MAX_ORDER; ++i)
+ for (i = 0; i < TTM_DIM_ORDER; ++i)
seq_printf(m, " %8u", ttm_pool_type_count([i]));
seq_puts(m, "\n");
}
@@ -751,13 +756,16 @@ int ttm_pool_mgr_init(unsigned long num_pages)
{
unsigned int i;
+ BUILD_BUG_ON(TTM_DIM_ORDER > MAX_ORDER);
+ BUILD_BUG_ON(TTM_DIM_ORDER < 1);
+
if (!page_pool_size)
page_pool_size = num_pages;
spin_lock_init(_lock);
INIT_LIST_HEAD(_list);
- for (i = 0; i < MAX_ORDER; ++i) {
+ for (i = 0; i < TTM_DIM_ORDER; ++i) {
ttm_pool_type_init(_write_combined[i], NULL,
ttm_write_combined, i);
ttm_pool_type_init(_uncached[i], NULL, ttm_uncached, i);
@@ -790,7 +798,7 @@ void ttm_pool_mgr_fini(void)
{
unsigned int i;
- for (i = 0; i < MAX_ORDER; ++i) {
+ for (i = 0; i < TTM_DIM_ORDER; ++i) {
ttm_pool_type_fini(_write_combined[i]);
ttm_pool_type_fini(_uncached[i]);
--
2.39.2
[Intel-gfx] [PATCH RESEND v3 3/3] drm/ttm: Make the call to ttm_tt_populate() interruptible when faulting
When swapping in, or under memory pressure ttm_tt_populate() may sleep
for a substantiable amount of time. Allow interrupts during the sleep.
This will also allow us to inject -EINTR errors during swapin in upcoming
patches.
Also avoid returning VM_FAULT_OOM, since that will confuse the core
mm, making it print out a confused message and retrying the fault.
Return VM_FAULT_SIGBUS also under OOM conditions.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index ca7744b852f5..4bca6b54520a 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -218,14 +218,21 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
prot = ttm_io_prot(bo, bo->resource, prot);
if (!bo->resource->bus.is_iomem) {
struct ttm_operation_ctx ctx = {
- .interruptible = false,
+ .interruptible = true,
.no_wait_gpu = false,
.force_alloc = true
};
ttm = bo->ttm;
- if (ttm_tt_populate(bdev, bo->ttm, ))
- return VM_FAULT_OOM;
+ err = ttm_tt_populate(bdev, bo->ttm, );
+ if (err) {
+ if (err == -EINTR || err == -ERESTARTSYS ||
+ err == -EAGAIN)
+ return VM_FAULT_NOPAGE;
+
+ pr_debug("TTM fault hit %pe.\n", ERR_PTR(err));
+ return VM_FAULT_SIGBUS;
+ }
} else {
/* Iomem should not be marked encrypted */
prot = pgprot_decrypted(prot);
--
2.39.2
[Intel-gfx] [PATCH RESEND v3 0/3] drm/ttm: Small fixes / cleanups in prep for shrinking
I collected the, from my POW, uncontroversial patches from V1 of the TTM
shrinker series, some corrected after the initial patch submission, one
patch added from the Xe RFC ("drm/ttm: Don't print error message if
eviction was interrupted"). It would be nice to have these reviewed and
merged while reworking the rest.
v2:
- Simplify __ttm_pool_free().
- Fix the TTM_TT_FLAG bit numbers.
- Keep all allocation orders for TTM pages at or below PMD order
v3:
- Rename __tm_pool_free() to ttm_pool_free_range(). Document.
- Compile-fix.
Thomas Hellström (3):
drm/ttm/pool: Fix ttm_pool_alloc error path
drm/ttm: Reduce the number of used allocation orders for TTM pages
drm/ttm: Make the call to ttm_tt_populate() interruptible when
faulting
drivers/gpu/drm/ttm/ttm_bo_vm.c | 13 +++-
drivers/gpu/drm/ttm/ttm_pool.c | 111
2 files changed, 80 insertions(+), 44 deletions(-)
--
2.39.2
[Intel-gfx] [PATCH RESEND v3 1/3] drm/ttm/pool: Fix ttm_pool_alloc error path
When hitting an error, the error path forgot to unmap dma mappings and
could call set_pages_wb() on already uncached pages.
Fix this by introducing a common ttm_pool_free_range() function that
does the right thing.
v2:
- Simplify that common function (Christian König)
v3:
- Rename that common function to ttm_pool_free_range() (Christian König)
Fixes: d099fc8f540a ("drm/ttm: new TT backend allocation pool v3")
Cc: Christian König
Cc: Dave Airlie
Cc: Christian Koenig
Cc: Huang Rui
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_pool.c | 81 +-
1 file changed, 51 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index aa116a7bbae3..dfce896c4bae 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -367,6 +367,43 @@ static int ttm_pool_page_allocated(struct ttm_pool *pool,
unsigned int order,
return 0;
}
+/**
+ * ttm_pool_free_range() - Free a range of TTM pages
+ * @pool: The pool used for allocating.
+ * @tt: The struct ttm_tt holding the page pointers.
+ * @caching: The page caching mode used by the range.
+ * @start_page: index for first page to free.
+ * @end_page: index for last page to free + 1.
+ *
+ * During allocation the ttm_tt page-vector may be populated with ranges of
+ * pages with different attributes if allocation hit an error without being
+ * able to completely fulfill the allocation. This function can be used
+ * to free these individual ranges.
+ */
+static void ttm_pool_free_range(struct ttm_pool *pool, struct ttm_tt *tt,
+ enum ttm_caching caching,
+ pgoff_t start_page, pgoff_t end_page)
+{
+ struct page **pages = tt->pages;
+ unsigned int order;
+ pgoff_t i, nr;
+
+ for (i = start_page; i < end_page; i += nr, pages += nr) {
+ struct ttm_pool_type *pt = NULL;
+
+ order = ttm_pool_page_order(pool, *pages);
+ nr = (1UL << order);
+ if (tt->dma_address)
+ ttm_pool_unmap(pool, tt->dma_address[i], nr);
+
+ pt = ttm_pool_select_type(pool, caching, order);
+ if (pt)
+ ttm_pool_type_give(pt, *pages);
+ else
+ ttm_pool_free_page(pool, caching, order, *pages);
+ }
+}
+
/**
* ttm_pool_alloc - Fill a ttm_tt object
*
@@ -382,12 +419,14 @@ static int ttm_pool_page_allocated(struct ttm_pool *pool,
unsigned int order,
int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt *tt,
struct ttm_operation_ctx *ctx)
{
- unsigned long num_pages = tt->num_pages;
+ pgoff_t num_pages = tt->num_pages;
dma_addr_t *dma_addr = tt->dma_address;
struct page **caching = tt->pages;
struct page **pages = tt->pages;
+ enum ttm_caching page_caching;
gfp_t gfp_flags = GFP_USER;
- unsigned int i, order;
+ pgoff_t caching_divide;
+ unsigned int order;
struct page *p;
int r;
@@ -410,6 +449,7 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt *tt,
order = min_t(unsigned int, order, __fls(num_pages))) {
struct ttm_pool_type *pt;
+ page_caching = tt->caching;
pt = ttm_pool_select_type(pool, tt->caching, order);
p = pt ? ttm_pool_type_take(pt) : NULL;
if (p) {
@@ -418,6 +458,7 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt *tt,
if (r)
goto error_free_page;
+ caching = pages;
do {
r = ttm_pool_page_allocated(pool, order, p,
_addr,
@@ -426,14 +467,15 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt
*tt,
if (r)
goto error_free_page;
+ caching = pages;
if (num_pages < (1 << order))
break;
p = ttm_pool_type_take(pt);
} while (p);
- caching = pages;
}
+ page_caching = ttm_cached;
while (num_pages >= (1 << order) &&
(p = ttm_pool_alloc_page(pool, gfp_flags, order))) {
@@ -442,6 +484,7 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt *tt,
tt->caching);
if (r)
goto error_free_page;
+ caching = pages;
}
r = ttm_pool_page_allocated(pool, order,
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915: Allow arbitrary refresh rates with VRR eDP panels
== Series Details == Series: series starting with [1/3] drm/i915: Allow arbitrary refresh rates with VRR eDP panels URL : https://patchwork.freedesktop.org/series/116101/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:14:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: Add Wa_14017856879
== Series Details == Series: drm/i915/mtl: Add Wa_14017856879 URL : https://patchwork.freedesktop.org/series/116100/ State : success == Summary == CI Bug Log - changes from CI_DRM_12965 -> Patchwork_116100v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/index.html Participating hosts (38 -> 36) -- Missing(2): fi-kbl-soraka fi-snb-2520m Known issues Here are the changes found in Patchwork_116100v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@slpc: - bat-rpls-2: NOTRUN -> [DMESG-FAIL][1] ([i915#6997] / [i915#7913]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html - bat-rpls-1: NOTRUN -> [DMESG-FAIL][2] ([i915#6367] / [i915#7996]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-rpls-2: NOTRUN -> [SKIP][3] ([i915#7828]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html - bat-dg2-11: NOTRUN -> [SKIP][4] ([i915#7828]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/bat-dg2-11/igt@kms_chamelium_...@common-hpd-after-suspend.html - bat-rpls-1: NOTRUN -> [SKIP][5] ([i915#7828]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/bat-rpls-1/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][6] ([i915#5354]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html * igt@kms_pipe_crc_basic@suspend-read-crc: - bat-rpls-1: NOTRUN -> [SKIP][7] ([i915#1845]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/bat-rpls-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html - bat-rpls-2: NOTRUN -> [SKIP][8] ([i915#1845]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/bat-rpls-2/igt@kms_pipe_crc_ba...@suspend-read-crc.html Possible fixes * igt@i915_selftest@live@gt_heartbeat: - fi-apl-guc: [DMESG-FAIL][9] ([i915#5334]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@gt_lrc: - bat-dg2-11: [INCOMPLETE][11] ([i915#7609] / [i915#7913]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html * igt@i915_selftest@live@requests: - bat-rpls-2: [ABORT][13] ([i915#4983] / [i915#7913]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/bat-rpls-2/igt@i915_selftest@l...@requests.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/bat-rpls-2/igt@i915_selftest@l...@requests.html - bat-rpls-1: [ABORT][15] ([i915#4983] / [i915#7911]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/bat-rpls-1/igt@i915_selftest@l...@requests.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/bat-rpls-1/igt@i915_selftest@l...@requests.html * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1: - bat-dg2-8: [FAIL][17] ([i915#7932]) -> [PASS][18] +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116100v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845 [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334 [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997 [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932 [i915#7996]:
[Intel-gfx] [PATCH 3/3] drm/fb-helper: fix input validation gaps in check_var
Apparently drivers need to check all this stuff themselves, which for
most things makes sense I guess. And for everything else we luck out,
because modern distros stopped supporting any other fbdev drivers than
drm ones and I really don't want to argue anymore about who needs to
check stuff. Therefore fixing all this just for drm fbdev emulation is
good enough.
Note that var->active is not set or validated. This is just control
flow for fbmem.c and needs to be validated in there as needed.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 49 +
1 file changed, 38 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index b9696d13a741..ef4eb8b12766 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1543,6 +1543,27 @@ static void drm_fb_helper_fill_pixel_fmt(struct
fb_var_screeninfo *var,
}
}
+static void __fill_var(struct fb_var_screeninfo *var,
+ struct drm_framebuffer *fb)
+{
+ int i;
+
+ var->xres_virtual = fb->width;
+ var->yres_virtual = fb->height;
+ var->accel_flags = FB_ACCELF_TEXT;
+ var->bits_per_pixel = drm_format_info_bpp(fb->format, 0);
+
+ var->height = var->width = 0;
+ var->left_margin = var->right_margin = 0;
+ var->upper_margin = var->lower_margin = 0;
+ var->hsync_len = var->vsync_len = 0;
+ var->sync = var->vmode = 0;
+ var->rotate = 0;
+ var->colorspace = 0;
+ for (i = 0; i < 4; i++)
+ var->reserved[i] = 0;
+}
+
/**
* drm_fb_helper_check_var - implementation for _ops.fb_check_var
* @var: screeninfo to check
@@ -1595,8 +1616,22 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
*var,
return -EINVAL;
}
- var->xres_virtual = fb->width;
- var->yres_virtual = fb->height;
+ __fill_var(var, fb);
+
+ /*
+* fb_pan_display() validates this, but fb_set_par() doesn't and just
+* falls over. Note that __fill_var above adjusts y/res_virtual.
+*/
+ if (var->yoffset > var->yres_virtual - var->yres ||
+ var->xoffset > var->xres_virtual - var->xres)
+ return -EINVAL;
+
+ /* We neither support grayscale nor FOURCC (also stored in here). */
+ if (var->grayscale > 0)
+ return -EINVAL;
+
+ if (var->nonstd)
+ return -EINVAL;
/*
* Workaround for SDL 1.2, which is known to be setting all pixel format
@@ -1612,11 +1647,6 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
*var,
drm_fb_helper_fill_pixel_fmt(var, format);
}
- /*
-* Likewise, bits_per_pixel should be rounded up to a supported value.
-*/
- var->bits_per_pixel = bpp;
-
/*
* drm fbdev emulation doesn't support changing the pixel format at all,
* so reject all pixel format changing requests.
@@ -2040,12 +2070,9 @@ static void drm_fb_helper_fill_var(struct fb_info *info,
}
info->pseudo_palette = fb_helper->pseudo_palette;
- info->var.xres_virtual = fb->width;
- info->var.yres_virtual = fb->height;
- info->var.bits_per_pixel = drm_format_info_bpp(format, 0);
- info->var.accel_flags = FB_ACCELF_TEXT;
info->var.xoffset = 0;
info->var.yoffset = 0;
+ __fill_var(>var, fb);
info->var.activate = FB_ACTIVATE_NOW;
drm_fb_helper_fill_pixel_fmt(>var, format);
--
2.40.0
[Intel-gfx] [PATCH 2/3] drm/fb-helper: drop redundant pixclock check from drm_fb_helper_set_par()
The fb_check_var hook is supposed to validate all this stuff. Any
errors from fb_set_par are considered driver/hw issues and resulting
in dmesg warnings.
Luckily we do fix up the pixclock already, so this is all fine.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index eb4ece3e0027..b9696d13a741 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1647,11 +1647,6 @@ int drm_fb_helper_set_par(struct fb_info *info)
if (oops_in_progress)
return -EBUSY;
- if (var->pixclock != 0) {
- drm_err(fb_helper->dev, "PIXEL CLOCK SET\n");
- return -EINVAL;
- }
-
/*
* Normally we want to make sure that a kms master takes precedence over
* fbdev, to avoid fbdev flickering and occasionally stealing the
--
2.40.0
[Intel-gfx] [PATCH 1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var
Drivers are supposed to fix this up if needed if they don't outright
reject it. Uncovered by 6c11df58fd1a ("fbmem: Check virtual screen
sizes in fb_set_var()").
Reported-by: syzbot+20dcf81733d43ddff...@syzkaller.appspotmail.com
Link:
https://syzkaller.appspot.com/bug?id=c5faf983bfa4a607de530cd3bb00bf06cefc
Cc: sta...@vger.kernel.org # v5.4+
Cc: Daniel Vetter
Cc: Javier Martinez Canillas
Cc: Thomas Zimmermann
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 59409820f424..eb4ece3e0027 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1595,6 +1595,9 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
return -EINVAL;
}
+ var->xres_virtual = fb->width;
+ var->yres_virtual = fb->height;
+
/*
* Workaround for SDL 1.2, which is known to be setting all pixel format
* fields values to zero in some cases. We treat this situation as a
--
2.40.0
[Intel-gfx] [PATCH] fbmem: Reject FB_ACTIVATE_KD_TEXT from userspace
This is an oversight from dc5bdb68b5b3 ("drm/fb-helper: Fix vt
restore") - I failed to realize that nasty userspace could set this.
It's not pretty to mix up kernel-internal and userspace uapi flags
like this, but since the entire fb_var_screeninfo structure is uapi
we'd need to either add a new parameter to the ->fb_set_par callback
and fb_set_par() function, which has a _lot_ of users. Or some other
fairly ugly side-channel int fb_info. Neither is a pretty prospect.
Instead just correct the issue at hand by filtering out this
kernel-internal flag in the ioctl handling code.
Signed-off-by: Daniel Vetter
Fixes: dc5bdb68b5b3 ("drm/fb-helper: Fix vt restore")
Cc: Alex Deucher
Cc: shl...@fastmail.com
Cc: Michel Dänzer
Cc: Noralf Trønnes
Cc: Thomas Zimmermann
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: # v5.7+
Cc: Bartlomiej Zolnierkiewicz
Cc: Geert Uytterhoeven
Cc: Nathan Chancellor
Cc: Qiujun Huang
Cc: Peter Rosin
Cc: linux-fb...@vger.kernel.org
Cc: Helge Deller
Cc: Sam Ravnborg
Cc: Geert Uytterhoeven
Cc: Samuel Thibault
Cc: Tetsuo Handa
Cc: Shigeru Yoshida
---
drivers/video/fbdev/core/fbmem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 875541ff185b..3fd95a79e4c3 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1116,6 +1116,8 @@ static long do_fb_ioctl(struct fb_info *info, unsigned
int cmd,
case FBIOPUT_VSCREENINFO:
if (copy_from_user(, argp, sizeof(var)))
return -EFAULT;
+ /* only for kernel-internal use */
+ var.activate &= ~FB_ACTIVATE_KD_TEXT;
console_lock();
lock_fb_info(info);
ret = fbcon_modechange_possible(info, );
--
2.40.0
Re: [Intel-gfx] [PATCH 4/7] drm/i915/mtl: Add Support for C10 PHY message bus and pll programming
> -Original Message-
> From: Deak, Imre
> Sent: Tuesday, April 4, 2023 11:03 AM
> To: Sripada, Radhakrishna
> Cc: Kahola, Mika ; intel-gfx@lists.freedesktop.org;
> Shankar, Uma ; Sousa, Gustavo
>
> Subject: Re: [PATCH 4/7] drm/i915/mtl: Add Support for C10 PHY message bus
> and pll programming
>
> On Tue, Apr 04, 2023 at 07:50:00PM +0300, Sripada, Radhakrishna wrote:
> >
> >
> > > -Original Message-
> > > From: Deak, Imre
> > > Sent: Tuesday, April 4, 2023 6:28 AM
> > > To: Kahola, Mika
> > > Cc: intel-gfx@lists.freedesktop.org; Sripada, Radhakrishna
> > > ; Shankar, Uma
> ;
> > > Sousa, Gustavo
> > > Subject: Re: [PATCH 4/7] drm/i915/mtl: Add Support for C10 PHY message
> bus
> > > and pll programming
> > >
> > > On Tue, Apr 04, 2023 at 04:01:55PM +0300, Kahola, Mika wrote:
> > > > [...]
> > > > > >
> > > > > > > > +void intel_c10mpllb_readout_hw_state(struct intel_encoder
> *encoder,
> > > > > > > > +struct intel_c10mpllb_state
> > > > > > > > pll_state) {
> > > > > > > > + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > > > > > > > + struct intel_digital_port *dig_port =
> > > > > > > > enc_to_dig_port(encoder);
> > > > > > > > + bool lane_reversal = dig_port->saved_port_bits &
> DDI_BUF_PORT_REVERSAL;
> > > > > > > > + u8 lane = lane_reversal ? INTEL_CX0_LANE1 :
> > > > > > > > + INTEL_CX0_LANE0;
> > > > > > > > + enum phy phy = intel_port_to_phy(i915, encoder->port);
> > > > > > > > + int i;
> > > > > > > > + u8 cmn, tx0;
> > > > > > > > +
> > > > > > > > + /*
> > > > > > > > +* According to C10 VDR Register programming Sequence we
> need
> > > > > > > > +* to do this to read PHY internal registers from MsgBus.
> > > > > > > > +*/
> > > > > > > > + intel_cx0_rmw(i915, encoder->port, lane,
> PHY_C10_VDR_CONTROL(1), 0,
> > > > > > > > + C10_VDR_CTRL_MSGBUS_ACCESS,
> MB_WRITE_COMMITTED);
> > > > > > > > +
> > > > > > > > + for (i = 0; i < ARRAY_SIZE(pll_state->pll); i++)
> > > > > > > > + pll_state->pll[i] = intel_cx0_read(i915,
> > > > > > > > encoder->port, lane,
> PHY_C10_VDR_PLL(i));
> > > > > > > > +
> > > > > > > > + cmn = intel_cx0_read(i915, encoder->port, lane,
> PHY_C10_VDR_CMN(0));
> > > > > > > > + tx0 = intel_cx0_read(i915, encoder->port, lane,
> PHY_C10_VDR_TX(0));
> > > > > > >
> > > > > > > The driver programs these registers, so why aren't they also
> > > > > > > stored
> > > > > > > in the intell_c20pll_state struct?
> > > > > >
> > > > > > Maybe I'm not really following here but intel_c20pll_state has its
> > > > > > own
> > > > > > tx, cmn and mplla/mpllb stored.
> > > > >
> > > > > Yes, just typoed that, I meant struct intel_c10mpllb_state which
> > > > > doesn't include tx and cmn.
> > > >
> > > > Yes, for C10 tx and cmn is missing. Maybe we could add those here as
> > > > well. It seems that currently these are not necessary required but for
> > > > the future use, these could be defined.
> > >
> > > These are needed already now to make the state computation / HW readout
> /
> > > state checking work for these two params the same way they do for the
> > > rest of PLL state.
> >
> > I believe C10 tx and cmn values are not changing across frequencies. Cmn
> > only
> > Changes for DP and HDMI so does it make sense to include in the pll
> > structure?
>
> They should be part of the atomic state. To save the bytes in the
> precomputed tables they could be added to intel_cx0pll_state, something
> like:
>
> struct intel_cx0pll_state {
> union {
> struct {
> struct intel_c10mpllb_state pllb;
> u8 cmn;
> u8 tx;
> } c10;
> struct intel_c20pll_state c20pll_state;
> };
> };
>
I am bit concerned about the mismatch in the names for c10 and c20 states,
adding further complexity in the structure may look more ugly. Let us afford the
extra space in the tables if they need to be part of the atomic state and
maintain
homogeneity across c10 and c20 structures.
Thoughts?
-RK
> --Imre
Re: [Intel-gfx] [PATCH v10 11/15] drm/atomic-helper: Set fence deadline for vblank
On Tue, Apr 04, 2023 at 08:22:05PM +0300, Dmitry Baryshkov wrote:
> On 08/03/2023 17:53, Rob Clark wrote:
> > From: Rob Clark
> >
> > For an atomic commit updating a single CRTC (ie. a pageflip) calculate
> > the next vblank time, and inform the fence(s) of that deadline.
> >
> > v2: Comment typo fix (danvet)
> > v3: If there are multiple CRTCs, consider the time of the soonest vblank
> >
> > Signed-off-by: Rob Clark
> > Reviewed-by: Daniel Vetter
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 37 +
> > 1 file changed, 37 insertions(+)
>
> As I started playing with hotplug on RB5 (sm8250, DSI-HDMI bridge), I found
> that this patch introduces the following backtrace on HDMI hotplug. Is there
> anything that I can do to debug/fix the issue? The warning seems harmless,
> but it would be probably be good to still fix it. With addresses decoded:
Bit a shot in the dark, but does the below help?
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index f21b5a74176c..6640d80d84f3 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1528,6 +1528,9 @@ static void set_fence_deadline(struct drm_device *dev,
for_each_new_crtc_in_state (state, crtc, new_crtc_state, i) {
ktime_t v;
+ if (drm_atomic_crtc_needs_modeset(new_crtc_state))
+ continue;
+
if (drm_crtc_next_vblank_start(crtc, ))
continue;
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 78a8c51a4abf..7ae38e8e27e8 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1001,6 +1001,9 @@ int drm_crtc_next_vblank_start(struct drm_crtc *crtc,
ktime_t *vblanktime)
struct drm_display_mode *mode = >hwmode;
u64 vblank_start;
+ if (!drm_dev_has_vblank(crtc->dev))
+ return -EINVAL;
+
if (!vblank->framedur_ns || !vblank->linedur_ns)
return -EINVAL;
>
> [ 31.151348] [ cut here ]
> [ 31.157043] msm_dpu ae01000.display-controller:
> drm_WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev))
> [ 31.157177] WARNING: CPU: 0 PID: 13 at drivers/gpu/drm/drm_vblank.c:728
> drm_crtc_vblank_helper_get_vblank_timestamp_internal
> (drivers/gpu/drm/drm_vblank.c:728)
> [ 31.180629] Modules linked in:
> [ 31.184106] CPU: 0 PID: 13 Comm: kworker/0:1 Not tainted
> 6.3.0-rc2-8-gd39e48ca80c0 #542
> [ 31.193358] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
> [ 31.200796] Workqueue: events lt9611uxc_hpd_work
> [ 31.205990] pstate: 6045 (nZCv daif +PAN -UAO -TCO -DIT -SSBS
> BTYPE=--)
> [ 31.213722] pc : drm_crtc_vblank_helper_get_vblank_timestamp_internal
> (drivers/gpu/drm/drm_vblank.c:728)
> [ 31.222032] lr : drm_crtc_vblank_helper_get_vblank_timestamp_internal
> (drivers/gpu/drm/drm_vblank.c:728)
> [ 31.230341] sp : 880bb8d0
> [ 31.234061] x29: 880bb900 x28: 0038 x27:
> 61a7956b8d60
> [ 31.242051] x26: x25: x24:
> 880bb9c4
> [ 31.250038] x23: 0001 x22: bf0033b94ef0 x21:
> 61a7957901d0
> [ 31.258029] x20: 61a79571 x19: 61a78128b000 x18:
> fffec278
> [ 31.266014] x17: 00400465 x16: 0020 x15:
> 0060
> [ 31.274001] x14: 0001 x13: bf00354550e0 x12:
> 0825
> [ 31.281989] x11: 02b7 x10: bf00354b1208 x9 :
> bf00354550e0
> [ 31.289976] x8 : efff x7 : bf00354ad0e0 x6 :
> 02b7
> [ 31.297963] x5 : 61a8feebbe48 x4 : 4000f2b7 x3 :
> a2a8c9f64000
> [ 31.305947] x2 : x1 : x0 :
> 61a780283100
> [ 31.313934] Call trace:
> [ 31.316719] drm_crtc_vblank_helper_get_vblank_timestamp_internal
> (drivers/gpu/drm/drm_vblank.c:728)
> [ 31.324646] drm_crtc_vblank_helper_get_vblank_timestamp
> (drivers/gpu/drm/drm_vblank.c:843)
> [ 31.331528] drm_crtc_get_last_vbltimestamp
> (drivers/gpu/drm/drm_vblank.c:884)
> [ 31.337170] drm_crtc_next_vblank_start
> (drivers/gpu/drm/drm_vblank.c:1006)
> [ 31.342430] drm_atomic_helper_wait_for_fences
> (drivers/gpu/drm/drm_atomic_helper.c:1531
> drivers/gpu/drm/drm_atomic_helper.c:1578)
> [ 31.348561] drm_atomic_helper_commit
> (drivers/gpu/drm/drm_atomic_helper.c:2007)
> [ 31.353724] drm_atomic_commit (drivers/gpu/drm/drm_atomic.c:1444)
> [ 31.358127] drm_client_modeset_commit_atomic
> (drivers/gpu/drm/drm_client_modeset.c:1045)
> [ 31.364146] drm_client_modeset_commit_locked
> (drivers/gpu/drm/drm_client_modeset.c:1148)
> [ 31.370071] drm_client_modeset_commit
> (drivers/gpu/drm/drm_client_modeset.c:1174)
> [ 31.375233] drm_fb_helper_set_par (drivers/gpu/drm/drm_fb_helper.c:254
> drivers/gpu/drm/drm_fb_helper.c:229
Re: [Intel-gfx] [PATCH] drm/i915/mtl: Add Wa_14017856879
Quoting Haridhar Kalvala (2023-04-04 14:32:20) > Wa_14017856879 implementation for mtl. > > Bspec: 46046 > > Signed-off-by: Haridhar Kalvala Reviewed-by: Gustavo Sousa > --- > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 ++ > drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 + > 2 files changed, 7 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > index 35a4cfac2d20..492b3de6678d 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > @@ -1177,7 +1177,9 @@ > #define THREAD_EX_ARB_MODE_RR_AFTER_DEP > REG_FIELD_PREP(THREAD_EX_ARB_MODE, 0x2) > > #define HSW_ROW_CHICKEN3 _MMIO(0xe49c) > +#define GEN9_ROW_CHICKEN3 MCR_REG(0xe49c) > #define HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE (1 << 6) > +#define MTL_DISABLE_FIX_FOR_EOT_FLUSHREG_BIT(9) > > #define GEN8_ROW_CHICKEN MCR_REG(0xe4f0) > #define FLOW_CONTROL_ENABLE REG_BIT(15) > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c > b/drivers/gpu/drm/i915/gt/intel_workarounds.c > index 1c8e0e91a2fe..6ea453ddd011 100644 > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c > @@ -2971,6 +2971,11 @@ general_render_compute_wa_init(struct intel_engine_cs > *engine, struct i915_wa_li > > add_render_compute_tuning_settings(i915, wal); > > + if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_B0, STEP_FOREVER) || > + IS_MTL_GRAPHICS_STEP(i915, P, STEP_B0, STEP_FOREVER)) > + /* Wa_14017856879 */ > + wa_mcr_masked_en(wal, GEN9_ROW_CHICKEN3, > MTL_DISABLE_FIX_FOR_EOT_FLUSH); > + > if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) || > IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0)) > /* > -- > 2.25.1 >
Re: [Intel-gfx] [PATCH v3] drm/i915/mtl: Disable stolen memory backed FB for A0
On Tue, Apr 04, 2023 at 08:13:42PM +0200, Nirmoy Das wrote: > Stolen memory is not usable for MTL A0 stepping beyond > certain access size and we have no control over userspace > access size of /dev/fb which can be backed by stolen memory. > So disable stolen memory backed fb by setting i915->dsm.usable_size > to zero. > > v2: remove hsdes reference and fix commit message(Andi) > v3: use revid as we want to target SOC stepping(Radhakrishna) > > Cc: Matthew Auld > Cc: Andi Shyti > Cc: Daniele Ceraolo Spurio > Cc: Lucas De Marchi > Cc: Radhakrishna Sripada > Signed-off-by: Nirmoy Das > Reviewed-by: Andi Shyti > --- > drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > index 8ac376c24aa2..ee492d823f1b 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > @@ -535,6 +535,14 @@ static int i915_gem_init_stolen(struct > intel_memory_region *mem) > /* Basic memrange allocator for stolen space. */ > drm_mm_init(>mm.stolen, 0, i915->dsm.usable_size); > > + /* > + * Access to stolen lmem beyond certain size for MTL A0 stepping > + * would crash the machine. Disable stolen lmem for userspace access > + * by setting usable_size to zero. > + */ > + if (IS_METEORLAKE(i915) && INTEL_REVID(i915) == 0x0) > + i915->dsm.usable_size = 0; That certainly won't prevent FBC from using stolen. Are we sure that FBC accesses are fine? > + > return 0; > } > > -- > 2.39.0 -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH v3] drm/i915/mtl: Disable stolen memory backed FB for A0
> -Original Message- > From: Das, Nirmoy > Sent: Tuesday, April 4, 2023 11:14 AM > To: intel-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org; Das, Nirmoy ; > Auld, Matthew ; Andi Shyti > ; Ceraolo Spurio, Daniele > ; De Marchi, Lucas > ; Sripada, Radhakrishna > > Subject: [PATCH v3] drm/i915/mtl: Disable stolen memory backed FB for A0 > > Stolen memory is not usable for MTL A0 stepping beyond > certain access size and we have no control over userspace > access size of /dev/fb which can be backed by stolen memory. > So disable stolen memory backed fb by setting i915->dsm.usable_size > to zero. > > v2: remove hsdes reference and fix commit message(Andi) > v3: use revid as we want to target SOC stepping(Radhakrishna) > > Cc: Matthew Auld > Cc: Andi Shyti > Cc: Daniele Ceraolo Spurio > Cc: Lucas De Marchi > Cc: Radhakrishna Sripada > Signed-off-by: Nirmoy Das > Reviewed-by: Andi Shyti LGTM, Reviewed-by: Radhakrishna Sripada > --- > drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > index 8ac376c24aa2..ee492d823f1b 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > @@ -535,6 +535,14 @@ static int i915_gem_init_stolen(struct > intel_memory_region *mem) > /* Basic memrange allocator for stolen space. */ > drm_mm_init(>mm.stolen, 0, i915->dsm.usable_size); > > + /* > + * Access to stolen lmem beyond certain size for MTL A0 stepping > + * would crash the machine. Disable stolen lmem for userspace access > + * by setting usable_size to zero. > + */ > + if (IS_METEORLAKE(i915) && INTEL_REVID(i915) == 0x0) > + i915->dsm.usable_size = 0; > + > return 0; > } > > -- > 2.39.0
[Intel-gfx] [PATCH v3] drm/i915/mtl: Disable stolen memory backed FB for A0
Stolen memory is not usable for MTL A0 stepping beyond certain access size and we have no control over userspace access size of /dev/fb which can be backed by stolen memory. So disable stolen memory backed fb by setting i915->dsm.usable_size to zero. v2: remove hsdes reference and fix commit message(Andi) v3: use revid as we want to target SOC stepping(Radhakrishna) Cc: Matthew Auld Cc: Andi Shyti Cc: Daniele Ceraolo Spurio Cc: Lucas De Marchi Cc: Radhakrishna Sripada Signed-off-by: Nirmoy Das Reviewed-by: Andi Shyti --- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c index 8ac376c24aa2..ee492d823f1b 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c @@ -535,6 +535,14 @@ static int i915_gem_init_stolen(struct intel_memory_region *mem) /* Basic memrange allocator for stolen space. */ drm_mm_init(>mm.stolen, 0, i915->dsm.usable_size); + /* +* Access to stolen lmem beyond certain size for MTL A0 stepping +* would crash the machine. Disable stolen lmem for userspace access +* by setting usable_size to zero. +*/ + if (IS_METEORLAKE(i915) && INTEL_REVID(i915) == 0x0) + i915->dsm.usable_size = 0; + return 0; } -- 2.39.0
Re: [Intel-gfx] [PATCH 4/7] drm/i915/mtl: Add Support for C10 PHY message bus and pll programming
On Tue, Apr 04, 2023 at 07:50:00PM +0300, Sripada, Radhakrishna wrote:
>
>
> > -Original Message-
> > From: Deak, Imre
> > Sent: Tuesday, April 4, 2023 6:28 AM
> > To: Kahola, Mika
> > Cc: intel-gfx@lists.freedesktop.org; Sripada, Radhakrishna
> > ; Shankar, Uma ;
> > Sousa, Gustavo
> > Subject: Re: [PATCH 4/7] drm/i915/mtl: Add Support for C10 PHY message bus
> > and pll programming
> >
> > On Tue, Apr 04, 2023 at 04:01:55PM +0300, Kahola, Mika wrote:
> > > [...]
> > > > >
> > > > > > > +void intel_c10mpllb_readout_hw_state(struct intel_encoder
> > > > > > > *encoder,
> > > > > > > +struct intel_c10mpllb_state
> > > > > > > pll_state) {
> > > > > > > + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > > > > > > + struct intel_digital_port *dig_port =
> > > > > > > enc_to_dig_port(encoder);
> > > > > > > + bool lane_reversal = dig_port->saved_port_bits &
> > > > > > > DDI_BUF_PORT_REVERSAL;
> > > > > > > + u8 lane = lane_reversal ? INTEL_CX0_LANE1 :
> > > > > > > + INTEL_CX0_LANE0;
> > > > > > > + enum phy phy = intel_port_to_phy(i915, encoder->port);
> > > > > > > + int i;
> > > > > > > + u8 cmn, tx0;
> > > > > > > +
> > > > > > > + /*
> > > > > > > +* According to C10 VDR Register programming Sequence we need
> > > > > > > +* to do this to read PHY internal registers from MsgBus.
> > > > > > > +*/
> > > > > > > + intel_cx0_rmw(i915, encoder->port, lane,
> > > > > > > PHY_C10_VDR_CONTROL(1), 0,
> > > > > > > + C10_VDR_CTRL_MSGBUS_ACCESS, MB_WRITE_COMMITTED);
> > > > > > > +
> > > > > > > + for (i = 0; i < ARRAY_SIZE(pll_state->pll); i++)
> > > > > > > + pll_state->pll[i] = intel_cx0_read(i915,
> > > > > > > encoder->port, lane, PHY_C10_VDR_PLL(i));
> > > > > > > +
> > > > > > > + cmn = intel_cx0_read(i915, encoder->port, lane,
> > > > > > > PHY_C10_VDR_CMN(0));
> > > > > > > + tx0 = intel_cx0_read(i915, encoder->port, lane,
> > > > > > > PHY_C10_VDR_TX(0));
> > > > > >
> > > > > > The driver programs these registers, so why aren't they also stored
> > > > > > in the intell_c20pll_state struct?
> > > > >
> > > > > Maybe I'm not really following here but intel_c20pll_state has its own
> > > > > tx, cmn and mplla/mpllb stored.
> > > >
> > > > Yes, just typoed that, I meant struct intel_c10mpllb_state which
> > > > doesn't include tx and cmn.
> > >
> > > Yes, for C10 tx and cmn is missing. Maybe we could add those here as
> > > well. It seems that currently these are not necessary required but for
> > > the future use, these could be defined.
> >
> > These are needed already now to make the state computation / HW readout /
> > state checking work for these two params the same way they do for the
> > rest of PLL state.
>
> I believe C10 tx and cmn values are not changing across frequencies. Cmn only
> Changes for DP and HDMI so does it make sense to include in the pll structure?
They should be part of the atomic state. To save the bytes in the
precomputed tables they could be added to intel_cx0pll_state, something
like:
struct intel_cx0pll_state {
union {
struct {
struct intel_c10mpllb_state pllb;
u8 cmn;
u8 tx;
} c10;
struct intel_c20pll_state c20pll_state;
};
};
--Imre
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Add a function to mmap framebuffer obj
Hi Andi,
On 4/4/2023 6:57 PM, Andi Shyti wrote:
Hi Nirmoy,
[...]
+int i915_gem_fb_mmap(struct drm_i915_gem_object *obj, struct vm_area_struct
*vma)
+{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ struct drm_device *dev = >drm;
+ struct i915_mmap_offset *mmo = NULL;
+ enum i915_mmap_type mmap_type;
+ struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
+
+ if (drm_dev_is_unplugged(dev))
+ return -ENODEV;
+
+ /* handle ttm object */
+ if (obj->ops->mmap_ops) {
+ /*
+* ttm fault handler, ttm_bo_vm_fault_reserved() uses fake
offset
+* to calculate page offset so set that up.
+*/
+ vma->vm_pgoff += drm_vma_node_start(>base.vma_node);
you could have kept my r-b.
I wasn't sure, so I removed it :)
Good work here!
Reviewed-by: Andi Shyti
Thanks,
Nirmoy
Thanks,
Andi
+ } else {
+ /* handle stolen and smem objects */
+ mmap_type = i915_ggtt_has_aperture(ggtt) ? I915_MMAP_TYPE_GTT :
I915_MMAP_TYPE_WC;
+ mmo = mmap_offset_attach(obj, mmap_type, NULL);
+ if (!mmo)
+ return -ENODEV;
+ }
+
+ /*
+* When we install vm_ops for mmap we are too late for
+* the vm_ops->open() which increases the ref_count of
+* this obj and then it gets decreased by the vm_ops->close().
+* To balance this increase the obj ref_count here.
+*/
+ obj = i915_gem_object_get(obj);
+ return i915_gem_object_mmap(obj, mmo, vma);
+}
[Intel-gfx] [PATCH 3/3] drm/i915: Use min() instead of hand rolling it
From: Ville Syrjälä Most places in the vblank code use min() to clamp scanline counters below vtotal. But we missed one in the gen3/4 pixel counter based codepath. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_vblank.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c b/drivers/gpu/drm/i915/display/intel_vblank.c index f8bf9810527d..136393d99298 100644 --- a/drivers/gpu/drm/i915/display/intel_vblank.c +++ b/drivers/gpu/drm/i915/display/intel_vblank.c @@ -340,8 +340,7 @@ static bool i915_get_crtc_scanoutpos(struct drm_crtc *_crtc, * matches how the scanline counter based position works since * the scanline counter doesn't count the two half lines. */ - if (position >= vtotal) - position = vtotal - 1; + position = min(position, vtotal - 1); /* * Start of vblank interrupt is triggered at start of hsync, -- 2.39.2
[Intel-gfx] [PATCH 2/3] drm/i915: Evade transcoder's vblank when doing seamless M/N changes
From: Ville Syrjälä
The transcoder M/N values are double buffered on the transcoder's
undelayed vblank. So when doing seamless M/N fastsets we need to
evade also that.
Not that currently the pipe's delayed vblank == transcoder's
undelayed vblank, so this is still a nop change. But in the
future when we may have to delay the pipe's vblank to create
a register programming window ("window2") for the DSB.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crtc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
b/drivers/gpu/drm/i915/display/intel_crtc.c
index ed45a6934854..f3b836829296 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -510,6 +510,13 @@ void intel_pipe_update_start(struct intel_crtc_state
*new_crtc_state)
VBLANK_EVASION_TIME_US);
max = vblank_start - 1;
+ /*
+* M/N is double buffered on the transcoder's undelayed vblank,
+* so with seamless M/N we must evade both vblanks.
+*/
+ if (new_crtc_state->seamless_m_n &&
intel_crtc_needs_fastset(new_crtc_state))
+ min -= adjusted_mode->crtc_vblank_start -
adjusted_mode->crtc_vdisplay;
+
if (min <= 0 || max <= 0)
goto irq_disable;
--
2.39.2
[Intel-gfx] [PATCH 1/3] drm/i915: Allow arbitrary refresh rates with VRR eDP panels
From: Ville Syrjälä
If the panel supports VRR it must be capable of accepting
timings with arbitrary vblank length, within the valid VRR
range. Use that fact to allow the user to request any refresh
rate they like. We simply pick the next highest fixed mode
from our list, and adjust the vblank to get the desired refresh
rate in the end.
Of course currently everything to do with the vrefresh is
using 1Hz precision, so might not be exact. But we can improve
that in the future by just upping our vrefresh precision.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_panel.c | 80 ++
1 file changed, 66 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
b/drivers/gpu/drm/i915/display/intel_panel.c
index ce2a34a25211..9acdd68b2dbc 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -42,6 +42,7 @@
#include "intel_lvds_regs.h"
#include "intel_panel.h"
#include "intel_quirks.h"
+#include "intel_vrr.h"
bool intel_panel_use_ssc(struct drm_i915_private *i915)
{
@@ -58,6 +59,38 @@ intel_panel_preferred_fixed_mode(struct intel_connector
*connector)
struct drm_display_mode, head);
}
+static bool is_in_vrr_range(struct intel_connector *connector, int vrefresh)
+{
+ const struct drm_display_info *info = >base.display_info;
+
+ return intel_vrr_is_capable(connector) &&
+ vrefresh >= info->monitor_range.min_vfreq &&
+ vrefresh <= info->monitor_range.max_vfreq;
+}
+
+static bool is_best_fixed_mode(struct intel_connector *connector,
+ int vrefresh, int fixed_mode_vrefresh,
+ const struct drm_display_mode *best_mode)
+{
+ /* we want to always return something */
+ if (!best_mode)
+ return true;
+
+ /*
+* With VRR always pick a mode with equal/higher than requested
+* vrefresh, which we can then reduce to match the requested
+* vrefresh by extending the vblank length.
+*/
+ if (is_in_vrr_range(connector, vrefresh) &&
+ is_in_vrr_range(connector, fixed_mode_vrefresh) &&
+ fixed_mode_vrefresh < vrefresh)
+ return false;
+
+ /* pick the fixed_mode that is closest in terms of vrefresh */
+ return abs(fixed_mode_vrefresh - vrefresh) <
+ abs(drm_mode_vrefresh(best_mode) - vrefresh);
+}
+
const struct drm_display_mode *
intel_panel_fixed_mode(struct intel_connector *connector,
const struct drm_display_mode *mode)
@@ -65,11 +98,11 @@ intel_panel_fixed_mode(struct intel_connector *connector,
const struct drm_display_mode *fixed_mode, *best_mode = NULL;
int vrefresh = drm_mode_vrefresh(mode);
- /* pick the fixed_mode that is closest in terms of vrefresh */
list_for_each_entry(fixed_mode, >panel.fixed_modes, head) {
- if (!best_mode ||
- abs(drm_mode_vrefresh(fixed_mode) - vrefresh) <
- abs(drm_mode_vrefresh(best_mode) - vrefresh))
+ int fixed_mode_vrefresh = drm_mode_vrefresh(fixed_mode);
+
+ if (is_best_fixed_mode(connector, vrefresh,
+ fixed_mode_vrefresh, best_mode))
best_mode = fixed_mode;
}
@@ -178,27 +211,46 @@ int intel_panel_compute_config(struct intel_connector
*connector,
{
const struct drm_display_mode *fixed_mode =
intel_panel_fixed_mode(connector, adjusted_mode);
+ int vrefresh, fixed_mode_vrefresh;
+ bool is_vrr;
if (!fixed_mode)
return 0;
+ vrefresh = drm_mode_vrefresh(adjusted_mode);
+ fixed_mode_vrefresh = drm_mode_vrefresh(fixed_mode);
+
/*
-* We don't want to lie too much to the user about the refresh
-* rate they're going to get. But we have to allow a bit of latitude
-* for Xorg since it likes to automagically cook up modes with slightly
-* off refresh rates.
+* Assume that we shouldn't muck about with the
+* timings if they don't land in the VRR range.
*/
- if (abs(drm_mode_vrefresh(adjusted_mode) -
drm_mode_vrefresh(fixed_mode)) > 1) {
- drm_dbg_kms(connector->base.dev,
- "[CONNECTOR:%d:%s] Requested mode vrefresh (%d Hz)
does not match fixed mode vrefresh (%d Hz)\n",
- connector->base.base.id, connector->base.name,
- drm_mode_vrefresh(adjusted_mode),
drm_mode_vrefresh(fixed_mode));
+ is_vrr = is_in_vrr_range(connector, vrefresh) &&
+ is_in_vrr_range(connector, fixed_mode_vrefresh);
- return -EINVAL;
+ if (!is_vrr) {
+ /*
+* We don't want to lie too much to the user about the refresh
+
[Intel-gfx] [PATCH] drm/i915/mtl: Add Wa_14017856879
Wa_14017856879 implementation for mtl. Bspec: 46046 Signed-off-by: Haridhar Kalvala --- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 ++ drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 + 2 files changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h index 35a4cfac2d20..492b3de6678d 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h @@ -1177,7 +1177,9 @@ #define THREAD_EX_ARB_MODE_RR_AFTER_DEP REG_FIELD_PREP(THREAD_EX_ARB_MODE, 0x2) #define HSW_ROW_CHICKEN3 _MMIO(0xe49c) +#define GEN9_ROW_CHICKEN3 MCR_REG(0xe49c) #define HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE (1 << 6) +#define MTL_DISABLE_FIX_FOR_EOT_FLUSHREG_BIT(9) #define GEN8_ROW_CHICKEN MCR_REG(0xe4f0) #define FLOW_CONTROL_ENABLE REG_BIT(15) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index 1c8e0e91a2fe..6ea453ddd011 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -2971,6 +2971,11 @@ general_render_compute_wa_init(struct intel_engine_cs *engine, struct i915_wa_li add_render_compute_tuning_settings(i915, wal); + if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_B0, STEP_FOREVER) || + IS_MTL_GRAPHICS_STEP(i915, P, STEP_B0, STEP_FOREVER)) + /* Wa_14017856879 */ + wa_mcr_masked_en(wal, GEN9_ROW_CHICKEN3, MTL_DISABLE_FIX_FOR_EOT_FLUSH); + if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) || IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0)) /* -- 2.25.1
Re: [Intel-gfx] [PATCH v10 11/15] drm/atomic-helper: Set fence deadline for vblank
On 08/03/2023 17:53, Rob Clark wrote: From: Rob Clark For an atomic commit updating a single CRTC (ie. a pageflip) calculate the next vblank time, and inform the fence(s) of that deadline. v2: Comment typo fix (danvet) v3: If there are multiple CRTCs, consider the time of the soonest vblank Signed-off-by: Rob Clark Reviewed-by: Daniel Vetter Signed-off-by: Rob Clark --- drivers/gpu/drm/drm_atomic_helper.c | 37 + 1 file changed, 37 insertions(+) As I started playing with hotplug on RB5 (sm8250, DSI-HDMI bridge), I found that this patch introduces the following backtrace on HDMI hotplug. Is there anything that I can do to debug/fix the issue? The warning seems harmless, but it would be probably be good to still fix it. With addresses decoded: [ 31.151348] [ cut here ] [ 31.157043] msm_dpu ae01000.display-controller: drm_WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev)) [ 31.157177] WARNING: CPU: 0 PID: 13 at drivers/gpu/drm/drm_vblank.c:728 drm_crtc_vblank_helper_get_vblank_timestamp_internal (drivers/gpu/drm/drm_vblank.c:728) [ 31.180629] Modules linked in: [ 31.184106] CPU: 0 PID: 13 Comm: kworker/0:1 Not tainted 6.3.0-rc2-8-gd39e48ca80c0 #542 [ 31.193358] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) [ 31.200796] Workqueue: events lt9611uxc_hpd_work [ 31.205990] pstate: 6045 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 31.213722] pc : drm_crtc_vblank_helper_get_vblank_timestamp_internal (drivers/gpu/drm/drm_vblank.c:728) [ 31.222032] lr : drm_crtc_vblank_helper_get_vblank_timestamp_internal (drivers/gpu/drm/drm_vblank.c:728) [ 31.230341] sp : 880bb8d0 [ 31.234061] x29: 880bb900 x28: 0038 x27: 61a7956b8d60 [ 31.242051] x26: x25: x24: 880bb9c4 [ 31.250038] x23: 0001 x22: bf0033b94ef0 x21: 61a7957901d0 [ 31.258029] x20: 61a79571 x19: 61a78128b000 x18: fffec278 [ 31.266014] x17: 00400465 x16: 0020 x15: 0060 [ 31.274001] x14: 0001 x13: bf00354550e0 x12: 0825 [ 31.281989] x11: 02b7 x10: bf00354b1208 x9 : bf00354550e0 [ 31.289976] x8 : efff x7 : bf00354ad0e0 x6 : 02b7 [ 31.297963] x5 : 61a8feebbe48 x4 : 4000f2b7 x3 : a2a8c9f64000 [ 31.305947] x2 : x1 : x0 : 61a780283100 [ 31.313934] Call trace: [ 31.316719] drm_crtc_vblank_helper_get_vblank_timestamp_internal (drivers/gpu/drm/drm_vblank.c:728) [ 31.324646] drm_crtc_vblank_helper_get_vblank_timestamp (drivers/gpu/drm/drm_vblank.c:843) [ 31.331528] drm_crtc_get_last_vbltimestamp (drivers/gpu/drm/drm_vblank.c:884) [ 31.337170] drm_crtc_next_vblank_start (drivers/gpu/drm/drm_vblank.c:1006) [ 31.342430] drm_atomic_helper_wait_for_fences (drivers/gpu/drm/drm_atomic_helper.c:1531 drivers/gpu/drm/drm_atomic_helper.c:1578) [ 31.348561] drm_atomic_helper_commit (drivers/gpu/drm/drm_atomic_helper.c:2007) [ 31.353724] drm_atomic_commit (drivers/gpu/drm/drm_atomic.c:1444) [ 31.358127] drm_client_modeset_commit_atomic (drivers/gpu/drm/drm_client_modeset.c:1045) [ 31.364146] drm_client_modeset_commit_locked (drivers/gpu/drm/drm_client_modeset.c:1148) [ 31.370071] drm_client_modeset_commit (drivers/gpu/drm/drm_client_modeset.c:1174) [ 31.375233] drm_fb_helper_set_par (drivers/gpu/drm/drm_fb_helper.c:254 drivers/gpu/drm/drm_fb_helper.c:229 drivers/gpu/drm/drm_fb_helper.c:1644) [ 31.380108] drm_fb_helper_hotplug_event (drivers/gpu/drm/drm_fb_helper.c:2302 (discriminator 4)) [ 31.385456] drm_fb_helper_output_poll_changed (drivers/gpu/drm/drm_fb_helper.c:2331) [ 31.391376] drm_kms_helper_hotplug_event (drivers/gpu/drm/drm_probe_helper.c:697) [ 31.396825] drm_bridge_connector_hpd_cb (drivers/gpu/drm/drm_bridge_connector.c:129) [ 31.402175] drm_bridge_hpd_notify (drivers/gpu/drm/drm_bridge.c:1315) [ 31.406954] lt9611uxc_hpd_work (drivers/gpu/drm/bridge/lontium-lt9611uxc.c:185) [ 31.411450] process_one_work (kernel/workqueue.c:2395) [ 31.415949] worker_thread (include/linux/list.h:292 kernel/workqueue.c:2538) [ 31.426843] kthread (kernel/kthread.c:376) [ 31.437182] ret_from_fork (arch/arm64/kernel/entry.S:871) [ 31.447828] irq event stamp: 44642 [ 31.458284] hardirqs last enabled at (44641): __up_console_sem (arch/arm64/include/asm/irqflags.h:182 (discriminator 1) arch/arm64/include/asm/irqflags.h:202 (discriminator 1) kernel/printk/printk.c:345 (discriminator 1)) [ 31.474540] hardirqs last disabled at (44642): el1_dbg (arch/arm64/kernel/entry-common.c:335 arch/arm64/kernel/entry-common.c:406) [ 31.489882] softirqs last enabled at (42912): _stext (arch/arm64/include/asm/current.h:19 arch/arm64/include/asm/preempt.h:13 kernel/softirq.c:415 kernel/softirq.c:600) [ 31.505256]
[Intel-gfx] [PATCH i-g-t v2] tools: Add tool to dump GuC/HuC CSS header
Since we are now using unversioned GuC/HuC, it's useful to be able to
dump the firmware blob and get that information from the CSS header.
Add a tool that decodes that information and dumps the raw header.
Example output:
$ tools/intel-gfx-fw-info /lib/firmware/i915/tgl_guc_70.bin
version: 70.5.1
date: 2022-09-09
raw dump:
06 00 00 00 a1 00 00 00 00 00 01 00 00 00 00 00
0010 86 80 00 00 09 09 22 20 71 17 01 00 40 00 00 00 .."
q...@...
0020 40 00 00 00 01 00 00 00 09 21 45 00 73 79 73 5f
@!E.sys_
0030 67 62 73 62 50 43 2d 31 2e 30 2e 33 31 35 30 00
gbsbPC-1.0.3150.
0040 01 05 46 00 00 00 00 00 00 00 00 00 00 00 00 00
..F.
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0070 00 00 00 00 00 00 00 00 00 10 80 00 00 01 40 00
..@.
struct uc_css_header:
- module_type: 0x6
- header_size_dw: 0xa1
- header_version: 0x1
- module_id: 0x0
- module_vendor: 0x8086
- date: 0x20220909
- size_dw: 0x11771
- key_size_dw: 0x40
- modulus_size_dw: 0x40
- exponent_size_dw: 0x1
- time: 0x452109
- username: b'sys_gbsb'
- buildnumber: b'PC-1.0.3150\x00'
- sw_version: 0x460501
- vf_version: 0x0
- reserved0: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
- rsvd:
- header_info: 0x400100
v2:
- Comments in the struct don't need to be removed: the defines do.
Just comment them out with a "//" which should bring people's
attention to it since it's not an approved way for comments
according to kernel coding style
- Better logging handling, without an explicit logger object
- Catch ImportError for the dissect.cstruct dependency (Gustavo)
Signed-off-by: Lucas De Marchi
Acked-by: Gustavo Sousa
Acked-by: Kamil Konieczny
---
tools/intel-gfx-fw-info | 138
tools/meson.build | 2 +-
2 files changed, 139 insertions(+), 1 deletion(-)
create mode 100755 tools/intel-gfx-fw-info
diff --git a/tools/intel-gfx-fw-info b/tools/intel-gfx-fw-info
new file mode 100755
index 0..77903bbb7
--- /dev/null
+++ b/tools/intel-gfx-fw-info
@@ -0,0 +1,138 @@
+#!/usr/bin/env python3
+# pylint: disable=C0301
+# SPDX-License-Identifier: (GPL-2.0 OR MIT)
+#
+# Copyright (C) 2023 Intel Corporation
+
+import argparse
+import logging
+import sys
+import typing
+
+# struct definition below should match the one from i915
+# (drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h) and xe
+# (drivers/gpu/drm/xe/xe_uc_fw_abi.h).
+#
+# For compatibility reasons with dissect.cstruct python module, the following
+# things are changed from the original kernel definition:
+#
+# 1) #define in the middle of the struct removed: comment them out
+# 2) No anonymous union - not compatible with the
+# dumpstruct(): give it a name
+
+CDEF = """
+typedef uint32 u32;
+
+struct uc_css_header {
+ u32 module_type;
+ /*
+* header_size includes all non-uCode bits, including css_header, rsa
+* key, modulus key and exponent data.
+*/
+ u32 header_size_dw;
+ u32 header_version;
+ u32 module_id;
+ u32 module_vendor;
+ u32 date;
+// #define CSS_DATE_DAY(0xFF << 0)
+// #define CSS_DATE_MONTH (0xFF << 8)
+// #define CSS_DATE_YEAR (0x << 16)
+ u32 size_dw; /* uCode plus header_size_dw */
+ u32 key_size_dw;
+ u32 modulus_size_dw;
+ u32 exponent_size_dw;
+ u32 time;
+// #define CSS_TIME_HOUR (0xFF << 0)
+// #define CSS_DATE_MIN(0xFF << 8)
+// #define CSS_DATE_SEC(0x << 16)
+ char username[8];
+ char buildnumber[12];
+ u32 sw_version;
+// #define CSS_SW_VERSION_UC_MAJOR (0xFF << 16)
+// #define CSS_SW_VERSION_UC_MINOR (0xFF << 8)
+// #define CSS_SW_VERSION_UC_PATCH (0xFF << 0)
+ u32 vf_version;
+ u32 reserved0[12];
+ union {
+ u32 private_data_size; /* only applies to GuC */
+ u32 reserved1;
+ } rsvd;
+ u32 header_info;
+};
+"""
+
+logging.basicConfig(format="%(levelname)s: %(message)s")
+
+try:
+from dissect import cstruct
+except:
+logging.critical(
+"Could not import dissect.cstruct module. See
https://github.com/fox-it/dissect.cstruct for installation options"
+)
+raise SystemExit(1)
+
+
+def ffs(x: int) -> int:
+"""Returns the index, counting from 0, of the
+least significant set bit in `x`.
+"""
+return (x & -x).bit_length() - 1
+
+
+def
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Add a function to mmap framebuffer obj
Hi Nirmoy,
[...]
> +int i915_gem_fb_mmap(struct drm_i915_gem_object *obj, struct vm_area_struct
> *vma)
> +{
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> + struct drm_device *dev = >drm;
> + struct i915_mmap_offset *mmo = NULL;
> + enum i915_mmap_type mmap_type;
> + struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
> +
> + if (drm_dev_is_unplugged(dev))
> + return -ENODEV;
> +
> + /* handle ttm object */
> + if (obj->ops->mmap_ops) {
> + /*
> + * ttm fault handler, ttm_bo_vm_fault_reserved() uses fake
> offset
> + * to calculate page offset so set that up.
> + */
> + vma->vm_pgoff += drm_vma_node_start(>base.vma_node);
you could have kept my r-b. Good work here!
Reviewed-by: Andi Shyti
Thanks,
Andi
> + } else {
> + /* handle stolen and smem objects */
> + mmap_type = i915_ggtt_has_aperture(ggtt) ? I915_MMAP_TYPE_GTT :
> I915_MMAP_TYPE_WC;
> + mmo = mmap_offset_attach(obj, mmap_type, NULL);
> + if (!mmo)
> + return -ENODEV;
> + }
> +
> + /*
> + * When we install vm_ops for mmap we are too late for
> + * the vm_ops->open() which increases the ref_count of
> + * this obj and then it gets decreased by the vm_ops->close().
> + * To balance this increase the obj ref_count here.
> + */
> + obj = i915_gem_object_get(obj);
> + return i915_gem_object_mmap(obj, mmo, vma);
> +}
Re: [Intel-gfx] [PATCH v3 05/12] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
Hi Yi,
On 4/1/23 16:44, Yi Liu wrote:
> as an alternative method for ownership check when iommufd is used. In
I don't understand the 1st sentence.
> this case all opened devices in the affected dev_set are verified to
> be bound to a same valid iommufd value to allow reset. It's simpler
> and faster as user does not need to pass a set of fds and kernel no
kernel does not need to search
> need to search the device within the given fds.
>
> a device in noiommu mode doesn't have a valid iommufd, so this method
> should not be used in a dev_set which contains multiple devices and one
> of them is in noiommu. The only allowed noiommu scenario is that the
> calling device is noiommu and it's in a singleton dev_set.
>
> Suggested-by: Jason Gunthorpe
> Signed-off-by: Jason Gunthorpe
> Reviewed-by: Jason Gunthorpe
> Tested-by: Yanting Jiang
> Signed-off-by: Yi Liu
> ---
> drivers/vfio/pci/vfio_pci_core.c | 42 +++-
> include/uapi/linux/vfio.h| 9 ++-
> 2 files changed, 44 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci_core.c
> b/drivers/vfio/pci/vfio_pci_core.c
> index 3696b8e58445..b68fcba67a4b 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -180,7 +180,8 @@ static void vfio_pci_probe_mmaps(struct
> vfio_pci_core_device *vdev)
> struct vfio_pci_group_info;
> static void vfio_pci_dev_set_try_reset(struct vfio_device_set *dev_set);
> static int vfio_pci_dev_set_hot_reset(struct vfio_device_set *dev_set,
> - struct vfio_pci_group_info *groups);
> + struct vfio_pci_group_info *groups,
> + struct iommufd_ctx *iommufd_ctx);
>
> /*
> * INTx masking requires the ability to disable INTx signaling via
> PCI_COMMAND
> @@ -1277,7 +1278,7 @@ vfio_pci_ioctl_pci_hot_reset_groups(struct
> vfio_pci_core_device *vdev,
> return ret;
>
> /* Somewhere between 1 and count is OK */
> - if (!hdr->count || hdr->count > count)
> + if (hdr->count > count)
then I would simply remove the above comment since !count check is done
by the caller.
> return -EINVAL;
>
> group_fds = kcalloc(hdr->count, sizeof(*group_fds), GFP_KERNEL);
> @@ -1326,7 +1327,7 @@ vfio_pci_ioctl_pci_hot_reset_groups(struct
> vfio_pci_core_device *vdev,
> info.count = hdr->count;
> info.files = files;
>
> - ret = vfio_pci_dev_set_hot_reset(vdev->vdev.dev_set, );
> + ret = vfio_pci_dev_set_hot_reset(vdev->vdev.dev_set, , NULL);
>
> hot_reset_release:
> for (file_idx--; file_idx >= 0; file_idx--)
> @@ -1341,6 +1342,7 @@ static int vfio_pci_ioctl_pci_hot_reset(struct
> vfio_pci_core_device *vdev,
> {
> unsigned long minsz = offsetofend(struct vfio_pci_hot_reset, count);
> struct vfio_pci_hot_reset hdr;
> + struct iommufd_ctx *iommufd;
> bool slot = false;
>
> if (copy_from_user(, arg, minsz))
> @@ -1355,7 +1357,12 @@ static int vfio_pci_ioctl_pci_hot_reset(struct
> vfio_pci_core_device *vdev,
> else if (pci_probe_reset_bus(vdev->pdev->bus))
> return -ENODEV;
>
> - return vfio_pci_ioctl_pci_hot_reset_groups(vdev, , slot, arg);
> + if (hdr.count)
> + return vfio_pci_ioctl_pci_hot_reset_groups(vdev, , slot,
> arg);
> +
> + iommufd = vfio_iommufd_physical_ictx(>vdev);
> +
> + return vfio_pci_dev_set_hot_reset(vdev->vdev.dev_set, NULL, iommufd);
> }
>
> static int vfio_pci_ioctl_ioeventfd(struct vfio_pci_core_device *vdev,
> @@ -2327,6 +2334,9 @@ static bool vfio_dev_in_groups(struct
> vfio_pci_core_device *vdev,
> {
> unsigned int i;
>
> + if (!groups)
> + return false;
> +
> for (i = 0; i < groups->count; i++)
> if (vfio_file_has_dev(groups->files[i], >vdev))
> return true;
> @@ -2402,13 +2412,25 @@ static int vfio_pci_dev_set_pm_runtime_get(struct
> vfio_device_set *dev_set)
> return ret;
> }
>
> +static bool vfio_dev_in_iommufd_ctx(struct vfio_pci_core_device *vdev,
> + struct iommufd_ctx *iommufd_ctx)
> +{
> + struct iommufd_ctx *iommufd = vfio_iommufd_physical_ictx(>vdev);
> +
> + if (!iommufd)
> + return false;
> +
> + return iommufd == iommufd_ctx;
> +}
> +
> /*
> * We need to get memory_lock for each device, but devices can share
> mmap_lock,
> * therefore we need to zap and hold the vma_lock for each device, and only
> then
> * get each memory_lock.
> */
> static int vfio_pci_dev_set_hot_reset(struct vfio_device_set *dev_set,
> - struct vfio_pci_group_info *groups)
> + struct vfio_pci_group_info *groups,
> + struct iommufd_ctx *iommufd_ctx)
> {
> struct vfio_pci_core_device *cur_mem;
> struct vfio_pci_core_device
Re: [Intel-gfx] [PATCH 4/7] drm/i915/mtl: Add Support for C10 PHY message bus and pll programming
> -Original Message-
> From: Deak, Imre
> Sent: Tuesday, April 4, 2023 6:28 AM
> To: Kahola, Mika
> Cc: intel-gfx@lists.freedesktop.org; Sripada, Radhakrishna
> ; Shankar, Uma ;
> Sousa, Gustavo
> Subject: Re: [PATCH 4/7] drm/i915/mtl: Add Support for C10 PHY message bus
> and pll programming
>
> On Tue, Apr 04, 2023 at 04:01:55PM +0300, Kahola, Mika wrote:
> > [...]
> > > >
> > > > > > +void intel_c10mpllb_readout_hw_state(struct intel_encoder
> *encoder,
> > > > > > +struct intel_c10mpllb_state
> > > > > > +*pll_state) {
> > > > > > + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > > > > > + struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> > > > > > + bool lane_reversal = dig_port->saved_port_bits &
> DDI_BUF_PORT_REVERSAL;
> > > > > > + u8 lane = lane_reversal ? INTEL_CX0_LANE1 :
> > > > > > + INTEL_CX0_LANE0;
> > > > > > + enum phy phy = intel_port_to_phy(i915, encoder->port);
> > > > > > + int i;
> > > > > > + u8 cmn, tx0;
> > > > > > +
> > > > > > + /*
> > > > > > +* According to C10 VDR Register programming Sequence we need
> > > > > > +* to do this to read PHY internal registers from MsgBus.
> > > > > > +*/
> > > > > > + intel_cx0_rmw(i915, encoder->port, lane,
> PHY_C10_VDR_CONTROL(1), 0,
> > > > > > + C10_VDR_CTRL_MSGBUS_ACCESS,
> MB_WRITE_COMMITTED);
> > > > > > +
> > > > > > + for (i = 0; i < ARRAY_SIZE(pll_state->pll); i++)
> > > > > > + pll_state->pll[i] = intel_cx0_read(i915, encoder->port,
> > > > > > lane,
> PHY_C10_VDR_PLL(i));
> > > > > > +
> > > > > > + cmn = intel_cx0_read(i915, encoder->port, lane,
> PHY_C10_VDR_CMN(0));
> > > > > > + tx0 = intel_cx0_read(i915, encoder->port, lane,
> PHY_C10_VDR_TX(0));
> > > > >
> > > > > The driver programs these registers, so why aren't they also stored
> > > > > in the intell_c20pll_state struct?
> > > >
> > > > Maybe I'm not really following here but intel_c20pll_state has its own
> > > > tx, cmn and mplla/mpllb stored.
> > >
> > > Yes, just typoed that, I meant struct intel_c10mpllb_state which
> > > doesn't include tx and cmn.
> >
> > Yes, for C10 tx and cmn is missing. Maybe we could add those here as
> > well. It seems that currently these are not necessary required but for
> > the future use, these could be defined.
>
> These are needed already now to make the state computation / HW readout /
> state checking work for these two params the same way they do for the
> rest of PLL state.
I believe C10 tx and cmn values are not changing across frequencies. Cmn on ly
Changes for DP and HDMI so does it make sense to include in the pll structure?
-RK
>
> > > > > > +
> > > > > > + if (tx0 != C10_TX0_VAL || cmn != C10_CMN0_DP_VAL)
> > > > > > + drm_warn(>drm, "Unexpected tx: %x or cmn: %x for
> > > > > > phy:
> %c.\n",
> > > > > > +tx0, cmn, phy_name(phy));
> > > > >
> > > > > Shouldn't
> PHY_C10_VDR_CONTROL(1)/C10_VDR_CTRL_MSGBUS_ACCESS be
> > > > > cleared here?
> > > >
> > > > Usually this means that we are not accessing these values from the
> > > > register. Was this in the spec that we would need to clear it?
> > >
> > > It does get cleared at the end of intel_c10_pll_program(), at least
> > > from one of the PHY lanes, so was wondering why things are done
> > > differently here. Yes, the spec doesn't require clearing it, but
> > > then it should not be cleared at other places either (has related
> > > comments on this in follow-up reviews).
> >
> > To be consistent maybe we can clear this here as well.
>
> If there is no need for it, let's follow the spec and not clear it at
> any other spot either.
>
> >
> > >
> > > > > > +}
> > > > > > +
Re: [Intel-gfx] [PATCH 2/5] drm/i915/display: Set I915_BO_ALLOC_USER for fb
Hi Nirmoy, On Tue, Apr 04, 2023 at 04:30:57PM +0200, Nirmoy Das wrote: > Framebuffer is exposed to userspace so make sure we set > proper flags for it. Set I915_BO_PREALLOC for prealloced > fb so that ttm won't clear existing data. > > Cc: Matthew Auld > Cc: Andi Shyti > Cc: Andrzej Hajda > Cc: Ville Syrjälä > Cc: Jani Nikula > Cc: Imre Deak > Signed-off-by: Nirmoy Das Reviewed-by: Andi Shyti Thanks, Andi
Re: [Intel-gfx] [PATCH v2] drm/i915/gt: Hold a wakeref for the active VM
Hi, On Fri, Mar 31, 2023 at 04:16:36PM +0200, Andrzej Hajda wrote: > From: Chris Wilson > > There may be a disconnect between the GT used by the engine and the GT > used for the VM, requiring us to hold a wakeref on both while the GPU is > active with this request. > > v2: added explanation to __queue_and_release_pm > > Signed-off-by: Chris Wilson > [ahajda: removed not-yet-upstremed wakeref tracking bits] > Signed-off-by: Andrzej Hajda Thank you Tvrtko and Chris for answering my questions, Reviewed-by: Andi Shyti Andi
Re: [Intel-gfx] [PATCH i-g-t] tools: Add tool to dump GuC/HuC CSS header
Quoting Lucas De Marchi (2023-04-04 11:10:53) > On Tue, Apr 04, 2023 at 09:29:51AM -0300, Gustavo Sousa wrote: > >Quoting Lucas De Marchi (2023-04-03 17:24:37) > >> Since we are now using unversioned GuC/HuC, it's useful to be able to > >> dump the firmware blob and get that information from the CSS header. > >> Add a tool that decodes that information and dumps the raw header. > >> > >> Example output: > >> > >> $ tools/intel-gfx-fw-info /lib/firmware/i915/tgl_guc_70.bin > >> version: 70.5.1 > >> date: 2022-09-09 > >> raw dump: > >> 06 00 00 00 a1 00 00 00 00 00 01 00 00 00 00 00 > >> > >> 0010 86 80 00 00 09 09 22 20 71 17 01 00 40 00 00 00 > >> .." q...@... > >> 0020 40 00 00 00 01 00 00 00 09 21 45 00 73 79 73 5f > >> @!E.sys_ > >> 0030 67 62 73 62 50 43 2d 31 2e 30 2e 33 31 35 30 00 > >> gbsbPC-1.0.3150. > >> 0040 01 05 46 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> ..F. > >> 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> > >> 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> > >> 0070 00 00 00 00 00 00 00 00 00 10 80 00 00 01 40 00 > >> ..@. > >> > >> struct uc_css_header: > >> - module_type: 0x6 > >> - header_size_dw: 0xa1 > >> - header_version: 0x1 > >> - module_id: 0x0 > >> - module_vendor: 0x8086 > >> - date: 0x20220909 > >> - size_dw: 0x11771 > >> - key_size_dw: 0x40 > >> - modulus_size_dw: 0x40 > >> - exponent_size_dw: 0x1 > >> - time: 0x452109 > >> - username: b'sys_gbsb' > >> - buildnumber: b'PC-1.0.3150\x00' > >> - sw_version: 0x460501 > >> - vf_version: 0x0 > >> - reserved0: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] > >> - rsvd: > >> - header_info: 0x400100 > >> > >> Signed-off-by: Lucas De Marchi > >> --- > >> tools/intel-gfx-fw-info | 120 > >> tools/meson.build | 2 +- > >> 2 files changed, 121 insertions(+), 1 deletion(-) > >> create mode 100755 tools/intel-gfx-fw-info > >> > >> diff --git a/tools/intel-gfx-fw-info b/tools/intel-gfx-fw-info > >> new file mode 100755 > >> index 0..fc1fafdf5 > >> --- /dev/null > >> +++ b/tools/intel-gfx-fw-info > >> @@ -0,0 +1,120 @@ > >> +#!/usr/bin/env python3 > >> +# pylint: disable=C0301 > >> +# SPDX-License-Identifier: (GPL-2.0 OR MIT) > >> +# > >> +# Copyright (C) 2023Intel Corporation > >> + > >> +import argparse > >> +import logging > >> +import pprint > >> +import sys > >> +import typing > >> + > >> +from dissect import cstruct > > > >Since we are not packaging this tool in a way that dependencies are > >automatically installed, I think it is worth to capture an ImportError > >here and point the user to the github repository for this dependency. > > sounds good. I also have a minor update to this patch: we don't really > need to remove the comments as stated below, it's just the defines in > the middle of the struct that are not compatible with the minimal C > parser from this module. > Cool, although I'm not sure keeping the comments will be really useful for this tool specifically, as it is mostly used to provide an easy way to parse the binary data with cstruct (the only fields we explicitly use in the code are "sw_version" and "date"). With or without the comments in the string, the ack stands. :-) > > > >Acked-by: Gustavo Sousa > > thanks > > Lucas De Marchi
Re: [Intel-gfx] [PATCH 1/5] drm/i915/ttm: Add I915_BO_PREALLOC
Hi Nirmoy, On Tue, Apr 04, 2023 at 04:30:56PM +0200, Nirmoy Das wrote: > Add a mechanism to keep existing data when creating > a ttm object with I915_BO_ALLOC_USER flag. why do we need this mechanism? What was the logic behind? These are all questions people might have when checking this commit. Please be a bit more explicative. > Cc: Matthew Auld > Cc: Andi Shyti > Cc: Andrzej Hajda > Cc: Ville Syrjälä > Cc: Jani Nikula > Cc: Imre Deak > Signed-off-by: Nirmoy Das Reviewed-by: Andi Shyti Thanks, Andi
Re: [Intel-gfx] [PATCH v2] drm/i915/gt: Hold a wakeref for the active VM
On 04/04/2023 17:00, Andi Shyti wrote:
Hi Tvrtko,
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 0a8d553da3f439..48f888c3da083b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -14,6 +14,7 @@
#include "i915_drv.h"
#include "intel_context_types.h"
#include "intel_engine_types.h"
+#include "intel_gt_pm.h"
#include "intel_ring_types.h"
#include "intel_timeline_types.h"
#include "i915_trace.h"
@@ -207,8 +208,11 @@ void intel_context_exit_engine(struct intel_context *ce);
static inline void intel_context_enter(struct intel_context *ce)
{
lockdep_assert_held(>timeline->mutex);
- if (!ce->active_count++)
- ce->ops->enter(ce);
+ if (ce->active_count++)
+ return;
+
+ ce->ops->enter(ce);
+ intel_gt_pm_get(ce->vm->gt);
}
static inline void intel_context_mark_active(struct intel_context *ce)
@@ -222,8 +226,11 @@ static inline void intel_context_exit(struct intel_context
*ce)
{
lockdep_assert_held(>timeline->mutex);
GEM_BUG_ON(!ce->active_count);
- if (!--ce->active_count)
- ce->ops->exit(ce);
+ if (--ce->active_count)
+ return;
+
+ intel_gt_pm_put_async(ce->vm->gt);
+ ce->ops->exit(ce);
shouldn't these two be swapped?
maybe I wasn't clear here... shouldn't it be
I missed this one.
ce->ops->exit(ce);
intel_gt_pm_put_async(ce->vm->gt);
Don't we need to hold the pm until exiting?
I think it doesn't matter. The problematic edge case this is fixing is
when ce->engine->gt is different from ce->vm->gt but at this point if it
is safe to release one it must be safe to release the other too.
Regards,
Tvrtko
}
static inline struct intel_context *intel_context_get(struct intel_context
*ce)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index e971b153fda976..ee531a5c142c77 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -114,6 +114,15 @@ __queue_and_release_pm(struct i915_request *rq,
ENGINE_TRACE(engine, "parking\n");
+ /*
+* Open coded one half of intel_context_enter, which we have to omit
+* here (see the large comment below) and because the other part must
+* not be called due constructing directly with __i915_request_create
+* which increments active count via intel_context_mark_active.
+*/
+ GEM_BUG_ON(rq->context->active_count != 1);
+ __intel_gt_pm_get(engine->gt);
where is it's brother "put"?
It's in request retire via intel_context_exit. Ie. request construction is
special here, while retirement is standard.
Thank you!
Andi
Re: [Intel-gfx] [PATCH] drm/i915: run kernel-doc on headers as part of HDRTEST
On Tue, Apr 04, 2023 at 03:26:24PM +0300, Jani Nikula wrote: > On Tue, 04 Apr 2023, kernel test robot wrote: > > Hi Jani, > > > > kernel test robot noticed the following build warnings: > > Yeah, that's kind of the point of adding more checks. ;) Indeed. I was in doubt if the include of the full dir was the right way, but this reply shows it works as expected :) Reviewed-by: Rodrigo Vivi > > BR, > Jani. > > > > > > [auto build test WARNING on drm-tip/drm-tip] > > > > url: > > https://github.com/intel-lab-lkp/linux/commits/Jani-Nikula/drm-i915-run-kernel-doc-on-headers-as-part-of-HDRTEST/20230404-170637 > > base: git://anongit.freedesktop.org/drm/drm-tip drm-tip > > patch link: > > https://lore.kernel.org/r/20230404090528.173075-1-jani.nikula%40intel.com > > patch subject: [Intel-gfx] [PATCH] drm/i915: run kernel-doc on headers as > > part of HDRTEST > > config: i386-defconfig > > (https://download.01.org/0day-ci/archive/20230404/202304042026.uzbs3cc2-...@intel.com/config) > > compiler: gcc-11 (Debian 11.3.0-8) 11.3.0 > > reproduce (this is a W=1 build): > > # > > https://github.com/intel-lab-lkp/linux/commit/336391cc647b2fbdf0ebd2eda8a10fb4509918b7 > > git remote add linux-review https://github.com/intel-lab-lkp/linux > > git fetch --no-tags linux-review > > Jani-Nikula/drm-i915-run-kernel-doc-on-headers-as-part-of-HDRTEST/20230404-170637 > > git checkout 336391cc647b2fbdf0ebd2eda8a10fb4509918b7 > > # save the config file > > mkdir build_dir && cp config build_dir/.config > > make W=1 O=build_dir ARCH=i386 olddefconfig > > make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/ > > > > If you fix the issue, kindly add following tag where applicable > > | Reported-by: kernel test robot > > | Link: > > https://lore.kernel.org/oe-kbuild-all/202304042026.uzbs3cc2-...@intel.com/ > > > > All warnings (new ones prefixed by >>): > > > >drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:27: warning: Function > > parameter or member 'size' not described in '__guc_capture_bufstate' > >drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:27: warning: Function > > parameter or member 'data' not described in '__guc_capture_bufstate' > >drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:27: warning: Function > > parameter or member 'rd' not described in '__guc_capture_bufstate' > >drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:27: warning: Function > > parameter or member 'wr' not described in '__guc_capture_bufstate' > >drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function > > parameter or member 'link' not described in '__guc_capture_parsed_output' > >drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function > > parameter or member 'is_partial' not described in > > '__guc_capture_parsed_output' > >drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function > > parameter or member 'eng_class' not described in > > '__guc_capture_parsed_output' > >drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function > > parameter or member 'eng_inst' not described in > > '__guc_capture_parsed_output' > >drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function > > parameter or member 'guc_id' not described in '__guc_capture_parsed_output' > >drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function > > parameter or member 'lrca' not described in '__guc_capture_parsed_output' > >drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function > > parameter or member 'reginfo' not described in '__guc_capture_parsed_output' > >>> drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:62: warning: wrong > >>> kernel-doc identifier on line: > > * struct guc_debug_capture_list_header / struct guc_debug_capture_list > >drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:80: warning: wrong > > kernel-doc identifier on line: > > * struct __guc_mmio_reg_descr / struct __guc_mmio_reg_descr_group > >drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:105: warning: wrong > > kernel-doc identifier on line: > > * struct guc_state_capture_header_t / struct guc_state_capture_t / > >drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:163: warning: Function > > parameter or member 'is_valid' not described in '__guc_capture_ads_cache' > >drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:163: warning: Function > > parameter or member 'ptr' not described in '__guc_capture_ads_cac
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Allow user to set cache at BO creation
> Subject: Re: [Intel-gfx] [PATCH 7/7] drm/i915: Allow user to set cache at BO
> creation
>
> On 01/04/2023 09:38, fei.y...@intel.com wrote:
>> From: Fei Yang
>>
>> To comply with the design that buffer objects shall have immutable
>> cache setting through out its life cycle, {set, get}_caching ioctl's
>> are no longer supported from MTL onward. With that change caching
>> policy can only be set at object creation time. The current code
>> applies a default (platform dependent) cache setting for all objects.
>> However this is not optimal for performance tuning. The patch extends
>> the existing gem_create uAPI to let user set PAT index for the object
>> at creation time.
>> The new extension is platform independent, so UMD's can switch to
>> using this extension for older platforms as well, while {set,
>> get}_caching are still supported on these legacy paltforms for compatibility
>> reason.
>>
>> Cc: Chris Wilson
>> Cc: Matt Roper
>> Signed-off-by: Fei Yang
>> Reviewed-by: Andi Shyti
>
>
> Just like the protected content uAPI, there is no way for userspace to tell
> this feature is available other than trying using it.
>
> Given the issues with protected content, is it not thing we could want to add?
Sorry I'm not aware of the issues with protected content, could you elaborate?
There was a long discussion on teams uAPI channel, could you comment there if
any concerns?
https://teams.microsoft.com/l/message/19:f1767bda6734476ba0a9c7d147b928d1@thread.skype/1675860924675?tenantId=46c98d88-e344-4ed4-8496-4ed7712e255d=379f3ae1-d138-4205-bb65-d4c7d38cb481=1675860924675=GSE%20OSGC=i915%20uAPI%20changes=1675860924675=false
Thanks,
-Fei
>Thanks,
>
>-Lionel
>
>
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_create.c | 33
>> include/uapi/drm/i915_drm.h| 36 ++
>> tools/include/uapi/drm/i915_drm.h | 36 ++
>> 3 files changed, 105 insertions(+)
>>
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915/ttm: Add I915_BO_PREALLOC
== Series Details == Series: series starting with [1/5] drm/i915/ttm: Add I915_BO_PREALLOC URL : https://patchwork.freedesktop.org/series/116093/ State : success == Summary == CI Bug Log - changes from CI_DRM_12965 -> Patchwork_116093v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/index.html Participating hosts (38 -> 36) -- Missing(2): bat-rpls-2 fi-snb-2520m Known issues Here are the changes found in Patchwork_116093v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@execlists: - fi-kbl-soraka: [PASS][1] -> [INCOMPLETE][2] ([i915#7156] / [i915#7913]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@slpc: - bat-rpls-1: NOTRUN -> [DMESG-FAIL][3] ([i915#6367] / [i915#7996]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-dg2-11: NOTRUN -> [SKIP][4] ([i915#7828]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/bat-dg2-11/igt@kms_chamelium_...@common-hpd-after-suspend.html - bat-rpls-1: NOTRUN -> [SKIP][5] ([i915#7828]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/bat-rpls-1/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@suspend-read-crc: - bat-rpls-1: NOTRUN -> [SKIP][6] ([i915#1845]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/bat-rpls-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html Possible fixes * igt@i915_selftest@live@gt_heartbeat: - fi-apl-guc: [DMESG-FAIL][7] ([i915#5334]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@gt_lrc: - bat-dg2-11: [INCOMPLETE][9] ([i915#7609] / [i915#7913]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html * igt@i915_selftest@live@requests: - bat-rpls-1: [ABORT][11] ([i915#4983] / [i915#7911]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/bat-rpls-1/igt@i915_selftest@l...@requests.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/bat-rpls-1/igt@i915_selftest@l...@requests.html * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1: - bat-dg2-8: [FAIL][13] ([i915#7932]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845 [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#7156]: https://gitlab.freedesktop.org/drm/intel/issues/7156 [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932 [i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996 Build changes - * Linux: CI_DRM_12965 -> Patchwork_116093v1 CI-20190529: 20190529 CI_DRM_12965: 53e37ca502cfe620396e498fae8430c293fb2c83 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7236: bac5a4cc31b3212a205219a6cbc45a173d30d04b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_116093v1: 53e37ca502cfe620396e498fae8430c293fb2c83 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 7d5216c49733 drm/i915/display: Implement fb_mmap callback function a3e84ec57029 drm/i915/display: Add helper func to get intel_fbdev from drm_fb_helper df67f701575d drm/i915: Add a function to mmap framebuffer obj 5629582ffdd6 drm/i915/display: Set I915_BO_ALLOC_USER for fb eb10111d59e3 drm/i915/ttm: Add I915_BO_PREALLOC == Logs == For more details see:
Re: [Intel-gfx] [PATCH v2] drm/i915/gt: Hold a wakeref for the active VM
Hi Tvrtko,
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> > > b/drivers/gpu/drm/i915/gt/intel_context.h
> > > index 0a8d553da3f439..48f888c3da083b 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_context.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> > > @@ -14,6 +14,7 @@
> > > #include "i915_drv.h"
> > > #include "intel_context_types.h"
> > > #include "intel_engine_types.h"
> > > +#include "intel_gt_pm.h"
> > > #include "intel_ring_types.h"
> > > #include "intel_timeline_types.h"
> > > #include "i915_trace.h"
> > > @@ -207,8 +208,11 @@ void intel_context_exit_engine(struct intel_context
> > > *ce);
> > > static inline void intel_context_enter(struct intel_context *ce)
> > > {
> > > lockdep_assert_held(>timeline->mutex);
> > > - if (!ce->active_count++)
> > > - ce->ops->enter(ce);
> > > + if (ce->active_count++)
> > > + return;
> > > +
> > > + ce->ops->enter(ce);
> > > + intel_gt_pm_get(ce->vm->gt);
> > > }
> > > static inline void intel_context_mark_active(struct intel_context *ce)
> > > @@ -222,8 +226,11 @@ static inline void intel_context_exit(struct
> > > intel_context *ce)
> > > {
> > > lockdep_assert_held(>timeline->mutex);
> > > GEM_BUG_ON(!ce->active_count);
> > > - if (!--ce->active_count)
> > > - ce->ops->exit(ce);
> > > + if (--ce->active_count)
> > > + return;
> > > +
> > > + intel_gt_pm_put_async(ce->vm->gt);
> > > + ce->ops->exit(ce);
> >
> > shouldn't these two be swapped?
maybe I wasn't clear here... shouldn't it be
ce->ops->exit(ce);
intel_gt_pm_put_async(ce->vm->gt);
Don't we need to hold the pm until exiting?
> > > }
> > > static inline struct intel_context *intel_context_get(struct
> > > intel_context *ce)
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > index e971b153fda976..ee531a5c142c77 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > @@ -114,6 +114,15 @@ __queue_and_release_pm(struct i915_request *rq,
> > > ENGINE_TRACE(engine, "parking\n");
> > > + /*
> > > + * Open coded one half of intel_context_enter, which we have to omit
> > > + * here (see the large comment below) and because the other part must
> > > + * not be called due constructing directly with __i915_request_create
> > > + * which increments active count via intel_context_mark_active.
> > > + */
> > > + GEM_BUG_ON(rq->context->active_count != 1);
> > > + __intel_gt_pm_get(engine->gt);
> >
> > where is it's brother "put"?
>
> It's in request retire via intel_context_exit. Ie. request construction is
> special here, while retirement is standard.
Thank you!
Andi
Re: [Intel-gfx] [PATCH v3 02/12] vfio/pci: Only check ownership of opened devices in hot reset
On 4/4/23 17:29, Liu, Yi L wrote:
>> From: Eric Auger
>> Sent: Tuesday, April 4, 2023 11:19 PM
>>
>> Hi Yi,
>>
>> On 4/4/23 16:37, Liu, Yi L wrote:
>>> Hi Eric,
>>>
From: Eric Auger
Sent: Tuesday, April 4, 2023 10:00 PM
Hi YI,
On 4/1/23 16:44, Yi Liu wrote:
> If the affected device is not opened by any user, it's safe to reset it
> given it's not in use.
>
> Reviewed-by: Kevin Tian
> Reviewed-by: Jason Gunthorpe
> Tested-by: Yanting Jiang
> Signed-off-by: Yi Liu
> ---
> drivers/vfio/pci/vfio_pci_core.c | 14 +++---
> include/uapi/linux/vfio.h| 8
> 2 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci_core.c
> b/drivers/vfio/pci/vfio_pci_core.c
> index 65bbef562268..5d745c9abf05 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -2429,10 +2429,18 @@ static int vfio_pci_dev_set_hot_reset(struct
vfio_device_set *dev_set,
> list_for_each_entry(cur_vma, _set->device_list, vdev.dev_set_list) {
> /*
> - * Test whether all the affected devices are contained by the
> - * set of groups provided by the user.
> + * Test whether all the affected devices can be reset by the
> + * user.
> + *
> + * Resetting an unused device (not opened) is safe, because
> + * dev_set->lock is held in hot reset path so this device
> + * cannot race being opened by another user simultaneously.
> + *
> + * Otherwise all opened devices in the dev_set must be
> + * contained by the set of groups provided by the user.
>*/
> - if (!vfio_dev_in_groups(cur_vma, groups)) {
> + if (cur_vma->vdev.open_count &&
> + !vfio_dev_in_groups(cur_vma, groups)) {
> ret = -EINVAL;
> goto err_undo;
> }
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 0552e8dcf0cb..f96e5689cffc 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -673,6 +673,14 @@ struct vfio_pci_hot_reset_info {
> * VFIO_DEVICE_PCI_HOT_RESET - _IOW(VFIO_TYPE, VFIO_BASE + 13,
> * struct vfio_pci_hot_reset)
> *
> + * Userspace requests hot reset for the devices it uses. Due to the
> + * underlying topology, multiple devices can be affected in the reset
by the reset
> + * while some might be opened by another user. To avoid interference
s/interference/hot reset failure?
>>> I don’t think user can really avoid hot reset failure since there may
>>> be new devices plugged into the affected slot. Even user has opened
>> I don't know the legacy wrt that issue but this sounds a serious issue,
>> meaning the reset of an assigned device could impact another device
>> belonging to another group not not owned by the user?
> but the hot reset shall fail as the group is not owned by the user.
sure it shall but I fail to understand if the reset fails or the device
plug is somehow delayed until the reset completes.
>
>>> all the groups/devices reported by VFIO_DEVICE_GET_PCI_HOT_RESET_INFO,
>>> the hot reset can fail if new device is plugged in and has not been
>>> bound to vfio or opened by another user during the window of
>>> _INFO and HOT_RESET.
>> with respect to the latter isn't the dev_set lock held during the hot
>> reset and sufficient to prevent any new opening to occur?
> yes. new open needs to acquire the dev_set lock. So when hot reset
> acquires the dev_set lock, then no new open can occur.
>
> Regards,
> Yi Liu
>
>>> maybe the whole statement should be as below:
>>>
>>> To avoid interference, the hot reset can only be conducted when all
>>> the affected devices are either opened by the calling user or not
>>> opened yet at the moment of the hot reset attempt.
>> OK
>>
>> Eric
> + * the calling user must ensure all affected devices, if opened, are
> + * owned by itself.
> + *
> + * The ownership is proved by an array of group fds.
> + *
> * Return: 0 on success, -errno on failure.
> */
> struct vfio_pci_hot_reset {
>>> Regards,
>>> Yi Liu
Re: [Intel-gfx] [PATCH v2] drm/i915/gt: Hold a wakeref for the active VM
On 04/04/2023 16:39, Andi Shyti wrote:
Hi Andrzej,
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 0a8d553da3f439..48f888c3da083b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -14,6 +14,7 @@
#include "i915_drv.h"
#include "intel_context_types.h"
#include "intel_engine_types.h"
+#include "intel_gt_pm.h"
#include "intel_ring_types.h"
#include "intel_timeline_types.h"
#include "i915_trace.h"
@@ -207,8 +208,11 @@ void intel_context_exit_engine(struct intel_context *ce);
static inline void intel_context_enter(struct intel_context *ce)
{
lockdep_assert_held(>timeline->mutex);
- if (!ce->active_count++)
- ce->ops->enter(ce);
+ if (ce->active_count++)
+ return;
+
+ ce->ops->enter(ce);
+ intel_gt_pm_get(ce->vm->gt);
}
static inline void intel_context_mark_active(struct intel_context *ce)
@@ -222,8 +226,11 @@ static inline void intel_context_exit(struct intel_context
*ce)
{
lockdep_assert_held(>timeline->mutex);
GEM_BUG_ON(!ce->active_count);
- if (!--ce->active_count)
- ce->ops->exit(ce);
+ if (--ce->active_count)
+ return;
+
+ intel_gt_pm_put_async(ce->vm->gt);
+ ce->ops->exit(ce);
shouldn't these two be swapped?
}
static inline struct intel_context *intel_context_get(struct intel_context *ce)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index e971b153fda976..ee531a5c142c77 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -114,6 +114,15 @@ __queue_and_release_pm(struct i915_request *rq,
ENGINE_TRACE(engine, "parking\n");
+ /*
+* Open coded one half of intel_context_enter, which we have to omit
+* here (see the large comment below) and because the other part must
+* not be called due constructing directly with __i915_request_create
+* which increments active count via intel_context_mark_active.
+*/
+ GEM_BUG_ON(rq->context->active_count != 1);
+ __intel_gt_pm_get(engine->gt);
where is it's brother "put"?
It's in request retire via intel_context_exit. Ie. request construction
is special here, while retirement is standard.
Regards,
Tvrtko
Thanks,
Andi
+
/*
* We have to serialise all potential retirement paths with our
* submission, as we don't want to underflow either the
---
base-commit: 3385d6482cd60f2a0bbb0fa97b70ae7dbba4f95c
change-id: 20230330-hold_wakeref_for_active_vm-7f013a449ef3
Best regards,
--
Andrzej Hajda
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/5] drm/i915/ttm: Add I915_BO_PREALLOC
== Series Details == Series: series starting with [1/5] drm/i915/ttm: Add I915_BO_PREALLOC URL : https://patchwork.freedesktop.org/series/116093/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] drm/i915/ttm: Add I915_BO_PREALLOC
== Series Details == Series: series starting with [1/5] drm/i915/ttm: Add I915_BO_PREALLOC URL : https://patchwork.freedesktop.org/series/116093/ State : warning == Summary == Error: dim checkpatch failed 6d227bf78d21 drm/i915/ttm: Add I915_BO_PREALLOC 0afb53513af0 drm/i915/display: Set I915_BO_ALLOC_USER for fb 238ea32be324 drm/i915: Add a function to mmap framebuffer obj -:131: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #131: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.c:1040: + GEM_BUG_ON(obj && obj->ops->mmap_ops); -:137: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #137: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.c:1046: + GEM_BUG_ON(obj && !obj->ops->mmap_ops); total: 0 errors, 2 warnings, 0 checks, 164 lines checked ee0620d0ce67 drm/i915/display: Add helper func to get intel_fbdev from drm_fb_helper 062c04b1867c drm/i915/display: Implement fb_mmap callback function
Re: [Intel-gfx] [PATCH v2] drm/i915/gt: Hold a wakeref for the active VM
Hi Andrzej,
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> b/drivers/gpu/drm/i915/gt/intel_context.h
> index 0a8d553da3f439..48f888c3da083b 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.h
> +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> @@ -14,6 +14,7 @@
> #include "i915_drv.h"
> #include "intel_context_types.h"
> #include "intel_engine_types.h"
> +#include "intel_gt_pm.h"
> #include "intel_ring_types.h"
> #include "intel_timeline_types.h"
> #include "i915_trace.h"
> @@ -207,8 +208,11 @@ void intel_context_exit_engine(struct intel_context *ce);
> static inline void intel_context_enter(struct intel_context *ce)
> {
> lockdep_assert_held(>timeline->mutex);
> - if (!ce->active_count++)
> - ce->ops->enter(ce);
> + if (ce->active_count++)
> + return;
> +
> + ce->ops->enter(ce);
> + intel_gt_pm_get(ce->vm->gt);
> }
>
> static inline void intel_context_mark_active(struct intel_context *ce)
> @@ -222,8 +226,11 @@ static inline void intel_context_exit(struct
> intel_context *ce)
> {
> lockdep_assert_held(>timeline->mutex);
> GEM_BUG_ON(!ce->active_count);
> - if (!--ce->active_count)
> - ce->ops->exit(ce);
> + if (--ce->active_count)
> + return;
> +
> + intel_gt_pm_put_async(ce->vm->gt);
> + ce->ops->exit(ce);
shouldn't these two be swapped?
> }
>
> static inline struct intel_context *intel_context_get(struct intel_context
> *ce)
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> index e971b153fda976..ee531a5c142c77 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> @@ -114,6 +114,15 @@ __queue_and_release_pm(struct i915_request *rq,
>
> ENGINE_TRACE(engine, "parking\n");
>
> + /*
> + * Open coded one half of intel_context_enter, which we have to omit
> + * here (see the large comment below) and because the other part must
> + * not be called due constructing directly with __i915_request_create
> + * which increments active count via intel_context_mark_active.
> + */
> + GEM_BUG_ON(rq->context->active_count != 1);
> + __intel_gt_pm_get(engine->gt);
where is it's brother "put"?
Thanks,
Andi
> +
> /*
>* We have to serialise all potential retirement paths with our
>* submission, as we don't want to underflow either the
>
> ---
> base-commit: 3385d6482cd60f2a0bbb0fa97b70ae7dbba4f95c
> change-id: 20230330-hold_wakeref_for_active_vm-7f013a449ef3
>
> Best regards,
> --
> Andrzej Hajda
Re: [Intel-gfx] [PATCH 1/5] drm/i915/ttm: Add I915_BO_PREALLOC
On 04.04.2023 16:30, Nirmoy Das wrote:
Add a mechanism to keep existing data when creating
a ttm object with I915_BO_ALLOC_USER flag.
Cc: Matthew Auld
Cc: Andi Shyti
Cc: Andrzej Hajda
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Imre Deak
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 15 +++
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 5 +++--
2 files changed, 14 insertions(+), 6 deletions(-)
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 5dcbbef31d44..830c11431ee8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -328,6 +328,12 @@ struct drm_i915_gem_object {
*/
#define I915_BO_ALLOC_GPU_ONLY BIT(6)
#define I915_BO_ALLOC_CCS_AUX BIT(7)
+/*
+ * Object is allowed to retain its initial data and will not be cleared on
first
+ * access if used along with I915_BO_ALLOC_USER. This is mainly to keep
+ * preallocated framebuffer data intact while transitioning it to i915drmfb.
+ */
+#define I915_BO_PREALLOC BIT(8)
#define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
I915_BO_ALLOC_VOLATILE | \
I915_BO_ALLOC_CPU_CLEAR | \
@@ -335,10 +341,11 @@ struct drm_i915_gem_object {
I915_BO_ALLOC_PM_VOLATILE | \
I915_BO_ALLOC_PM_EARLY | \
I915_BO_ALLOC_GPU_ONLY | \
-I915_BO_ALLOC_CCS_AUX)
-#define I915_BO_READONLY BIT(8)
-#define I915_TILING_QUIRK_BIT 9 /* unknown swizzling; do not release! */
-#define I915_BO_PROTECTED BIT(10)
+I915_BO_ALLOC_CCS_AUX | \
+I915_BO_PREALLOC)
+#define I915_BO_READONLY BIT(9)
+#define I915_TILING_QUIRK_BIT 10 /* unknown swizzling; do not release! */
+#define I915_BO_PROTECTED BIT(11)
/**
* @mem_flags - Mutable placement-related flags
*
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index dd188dfcc423..69eb20ed4d47 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -576,7 +576,7 @@ int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
struct dma_fence *migration_fence = NULL;
struct ttm_tt *ttm = bo->ttm;
struct i915_refct_sgt *dst_rsgt;
- bool clear;
+ bool clear, prealloc_bo;
int ret;
if (GEM_WARN_ON(i915_ttm_is_ghost_object(bo))) {
@@ -632,7 +632,8 @@ int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
return PTR_ERR(dst_rsgt);
clear = !i915_ttm_cpu_maps_iomem(bo->resource) && (!ttm || !ttm_tt_is_populated(ttm));
- if (!(clear && ttm && !(ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC))) {
+ prealloc_bo = obj->flags & I915_BO_PREALLOC;
+ if (!(clear && ttm && !((ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC) &&
!prealloc_bo))) {
This looks like school exercise for complicated usage of logical
operators, and I have problem with understanding this :)
Couldn't this be somehow simplified?
Anyway as the patch just reuses existing code:
Reviewed-by: Andrzej Hajda
Regards
Andrzej
struct i915_deps deps;
i915_deps_init(, GFP_KERNEL | __GFP_NORETRY | __GFP_NOWARN);
Re: [Intel-gfx] [PATCH v3 02/12] vfio/pci: Only check ownership of opened devices in hot reset
> From: Eric Auger
> Sent: Tuesday, April 4, 2023 11:19 PM
>
> Hi Yi,
>
> On 4/4/23 16:37, Liu, Yi L wrote:
> > Hi Eric,
> >
> >> From: Eric Auger
> >> Sent: Tuesday, April 4, 2023 10:00 PM
> >>
> >> Hi YI,
> >>
> >> On 4/1/23 16:44, Yi Liu wrote:
> >>> If the affected device is not opened by any user, it's safe to reset it
> >>> given it's not in use.
> >>>
> >>> Reviewed-by: Kevin Tian
> >>> Reviewed-by: Jason Gunthorpe
> >>> Tested-by: Yanting Jiang
> >>> Signed-off-by: Yi Liu
> >>> ---
> >>> drivers/vfio/pci/vfio_pci_core.c | 14 +++---
> >>> include/uapi/linux/vfio.h| 8
> >>> 2 files changed, 19 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/vfio/pci/vfio_pci_core.c
> >>> b/drivers/vfio/pci/vfio_pci_core.c
> >>> index 65bbef562268..5d745c9abf05 100644
> >>> --- a/drivers/vfio/pci/vfio_pci_core.c
> >>> +++ b/drivers/vfio/pci/vfio_pci_core.c
> >>> @@ -2429,10 +2429,18 @@ static int vfio_pci_dev_set_hot_reset(struct
> >> vfio_device_set *dev_set,
> >>> list_for_each_entry(cur_vma, _set->device_list, vdev.dev_set_list) {
> >>> /*
> >>> - * Test whether all the affected devices are contained by the
> >>> - * set of groups provided by the user.
> >>> + * Test whether all the affected devices can be reset by the
> >>> + * user.
> >>> + *
> >>> + * Resetting an unused device (not opened) is safe, because
> >>> + * dev_set->lock is held in hot reset path so this device
> >>> + * cannot race being opened by another user simultaneously.
> >>> + *
> >>> + * Otherwise all opened devices in the dev_set must be
> >>> + * contained by the set of groups provided by the user.
> >>>*/
> >>> - if (!vfio_dev_in_groups(cur_vma, groups)) {
> >>> + if (cur_vma->vdev.open_count &&
> >>> + !vfio_dev_in_groups(cur_vma, groups)) {
> >>> ret = -EINVAL;
> >>> goto err_undo;
> >>> }
> >>> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> >>> index 0552e8dcf0cb..f96e5689cffc 100644
> >>> --- a/include/uapi/linux/vfio.h
> >>> +++ b/include/uapi/linux/vfio.h
> >>> @@ -673,6 +673,14 @@ struct vfio_pci_hot_reset_info {
> >>> * VFIO_DEVICE_PCI_HOT_RESET - _IOW(VFIO_TYPE, VFIO_BASE + 13,
> >>> * struct vfio_pci_hot_reset)
> >>> *
> >>> + * Userspace requests hot reset for the devices it uses. Due to the
> >>> + * underlying topology, multiple devices can be affected in the reset
> >> by the reset
> >>> + * while some might be opened by another user. To avoid interference
> >> s/interference/hot reset failure?
> > I don’t think user can really avoid hot reset failure since there may
> > be new devices plugged into the affected slot. Even user has opened
> I don't know the legacy wrt that issue but this sounds a serious issue,
> meaning the reset of an assigned device could impact another device
> belonging to another group not not owned by the user?
but the hot reset shall fail as the group is not owned by the user.
> > all the groups/devices reported by VFIO_DEVICE_GET_PCI_HOT_RESET_INFO,
> > the hot reset can fail if new device is plugged in and has not been
> > bound to vfio or opened by another user during the window of
> > _INFO and HOT_RESET.
> with respect to the latter isn't the dev_set lock held during the hot
> reset and sufficient to prevent any new opening to occur?
yes. new open needs to acquire the dev_set lock. So when hot reset
acquires the dev_set lock, then no new open can occur.
Regards,
Yi Liu
> >
> > maybe the whole statement should be as below:
> >
> > To avoid interference, the hot reset can only be conducted when all
> > the affected devices are either opened by the calling user or not
> > opened yet at the moment of the hot reset attempt.
>
> OK
>
> Eric
> >
> >>> + * the calling user must ensure all affected devices, if opened, are
> >>> + * owned by itself.
> >>> + *
> >>> + * The ownership is proved by an array of group fds.
> >>> + *
> >>> * Return: 0 on success, -errno on failure.
> >>> */
> >>> struct vfio_pci_hot_reset {
> > Regards,
> > Yi Liu
Re: [Intel-gfx] [PATCH v3 04/12] vfio-iommufd: Add helper to retrieve iommufd_ctx and devid for vfio_device
Hi,
On 4/1/23 16:44, Yi Liu wrote:
> This is needed by the vfio-pci driver to report affected devices in the
> hot reset for a given device.
>
> Reviewed-by: Jason Gunthorpe
> Tested-by: Yanting Jiang
> Signed-off-by: Yi Liu
> ---
> drivers/iommu/iommufd/device.c | 12
> drivers/vfio/iommufd.c | 14 ++
> include/linux/iommufd.h| 3 +++
> include/linux/vfio.h | 13 +
> 4 files changed, 42 insertions(+)
>
> diff --git a/drivers/iommu/iommufd/device.c b/drivers/iommu/iommufd/device.c
> index 25115d401d8f..04a57aa1ae2c 100644
> --- a/drivers/iommu/iommufd/device.c
> +++ b/drivers/iommu/iommufd/device.c
> @@ -131,6 +131,18 @@ void iommufd_device_unbind(struct iommufd_device *idev)
> }
> EXPORT_SYMBOL_NS_GPL(iommufd_device_unbind, IOMMUFD);
>
> +struct iommufd_ctx *iommufd_device_to_ictx(struct iommufd_device *idev)
> +{
> + return idev->ictx;
> +}
> +EXPORT_SYMBOL_NS_GPL(iommufd_device_to_ictx, IOMMUFD);
> +
> +u32 iommufd_device_to_id(struct iommufd_device *idev)
> +{
> + return idev->obj.id;
> +}
> +EXPORT_SYMBOL_NS_GPL(iommufd_device_to_id, IOMMUFD);
> +
> static int iommufd_device_setup_msi(struct iommufd_device *idev,
> struct iommufd_hw_pagetable *hwpt,
> phys_addr_t sw_msi_start)
> diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
> index 88b00c501015..809f2dd73b9e 100644
> --- a/drivers/vfio/iommufd.c
> +++ b/drivers/vfio/iommufd.c
> @@ -66,6 +66,20 @@ void vfio_iommufd_unbind(struct vfio_device *vdev)
> vdev->ops->unbind_iommufd(vdev);
> }
>
> +struct iommufd_ctx *vfio_iommufd_physical_ictx(struct vfio_device *vdev)
> +{
> + if (!vdev->iommufd_device)
> + return NULL;
> + return iommufd_device_to_ictx(vdev->iommufd_device);
> +}
> +EXPORT_SYMBOL_GPL(vfio_iommufd_physical_ictx);
> +
> +void vfio_iommufd_physical_devid(struct vfio_device *vdev, u32 *id)
> +{
> + if (vdev->iommufd_device)
> + *id = iommufd_device_to_id(vdev->iommufd_device);
since there is no return value, may be worth to add at least a WARN_ON
in case of !vdev->iommufd_device
> +}
> +EXPORT_SYMBOL_GPL(vfio_iommufd_physical_devid);
> /*
> * The physical standard ops mean that the iommufd_device is bound to the
> * physical device vdev->dev that was provided to vfio_init_group_dev().
> Drivers
> diff --git a/include/linux/iommufd.h b/include/linux/iommufd.h
> index 1129a36a74c4..ac96df406833 100644
> --- a/include/linux/iommufd.h
> +++ b/include/linux/iommufd.h
> @@ -24,6 +24,9 @@ void iommufd_device_unbind(struct iommufd_device *idev);
> int iommufd_device_attach(struct iommufd_device *idev, u32 *pt_id);
> void iommufd_device_detach(struct iommufd_device *idev);
>
> +struct iommufd_ctx *iommufd_device_to_ictx(struct iommufd_device *idev);
> +u32 iommufd_device_to_id(struct iommufd_device *idev);
> +
> struct iommufd_access_ops {
> u8 needs_pin_pages : 1;
> void (*unmap)(void *data, unsigned long iova, unsigned long length);
> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> index 3188d8a374bd..97a1174b922f 100644
> --- a/include/linux/vfio.h
> +++ b/include/linux/vfio.h
> @@ -113,6 +113,8 @@ struct vfio_device_ops {
> };
>
> #if IS_ENABLED(CONFIG_IOMMUFD)
> +struct iommufd_ctx *vfio_iommufd_physical_ictx(struct vfio_device *vdev);
> +void vfio_iommufd_physical_devid(struct vfio_device *vdev, u32 *id);
> int vfio_iommufd_physical_bind(struct vfio_device *vdev,
> struct iommufd_ctx *ictx, u32 *out_device_id);
> void vfio_iommufd_physical_unbind(struct vfio_device *vdev);
> @@ -122,6 +124,17 @@ int vfio_iommufd_emulated_bind(struct vfio_device *vdev,
> void vfio_iommufd_emulated_unbind(struct vfio_device *vdev);
> int vfio_iommufd_emulated_attach_ioas(struct vfio_device *vdev, u32 *pt_id);
> #else
> +static inline struct iommufd_ctx *
> +vfio_iommufd_physical_ictx(struct vfio_device *vdev)
> +{
> + return NULL;
> +}
> +
> +static inline void
> +vfio_iommufd_physical_devid(struct vfio_device *vdev, u32 *id)
> +{
> +}
> +
> #define vfio_iommufd_physical_bind \
> ((int (*)(struct vfio_device *vdev, struct iommufd_ctx *ictx, \
> u32 *out_device_id)) NULL)
besides
Reviewed-by: Eric Auger
Eric
Re: [Intel-gfx] [PATCH] drm/fb-helper: Remove helpers to change frame buffer config
Hi Daniel,
On Tue, Aug 9, 2022 at 5:03 PM Daniel Vetter wrote:
> On Sat, Jul 02, 2022 at 08:05:54PM +0200, Helge Deller wrote:
> > On 6/29/22 12:56, Geert Uytterhoeven wrote:
> > > The DRM fbdev emulation layer does not support pushing back
> > > changes to fb_var_screeninfo to KMS.
> > >
> > > However, drm_fb_helper still implements the fb_ops.fb_check_var() and
> > > fb_ops.fb_set_par() callbacks, but the former fails to validate various
> > > parameters passed from userspace. Hence unsanitized and possible
> > > invaled values are passed up through the fbdev, fbcon, and console
> > > stack, which has become an endless source of security issues reported
> > > against fbdev.
> > >
> > > Fix this by not populating the fb_ops.fb_check_var() and
> > > fb_ops.fb_set_par() callbacks, as there is no point in providing them if
> > > the frame buffer config cannot be changed anyway. This makes the fbdev
> > > core aware that making changes to the frame buffer config is not
> > > supported, so it will always return the current config.
> > >
> > > Signed-off-by: Geert Uytterhoeven
> >
> > It's unfortunate that DRM currently isn't able to switch resolutions
> > at runtime.
> >
> > With that in mind I agree with Geert that it's probably better to
> > disable (or drop) that code until DRM can cope with fbdev's
> > interface to switch resolutions.
> >
> > Furthermore, with the upcoming patches to fbcon (which prevents crashes on
> > invalid userspace input), you will face a kernel WARNING if you call fbset
> > to switch screen resolutions with DRM drivers.
> >
> > So, from my side (although I'd prefer a better fix for DRM):
> >
> > Acked-by: Helge Deller
>
> So maybe I'm missing something, but I think this breaks a lot of stuff.
> The issue is that fbdev is only a subordinate owner of the kms device, if
> there's a real drm kms owner around that wins.
>
> Which means when you switch back then set_par needs to restore the fbdev
> framebuffer. So that might break some recovery/use-cases.
Upon closer look, I think I was a bit too over-eager, and we can keep
the implementation of fb_ops.fb_set_par().
> The other thing is that I think this also breaks the scanout offset, and
> people do use that for double-buffering on top of fbdev on top of drm
> drivers. So we can't just nuke it completely.
You mean panning? That does not need fb_ops.fb_check_var(), as it
should be done through fb_ops.fb_pan_display().
> For better or worse I think we need to keep playing the whack-a-mole game.
> Or do I miss something here?
With the above fixed, we can continue whacking the drm bugs in
implementing the fbdev API?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [Intel-gfx] [PATCH v3 02/12] vfio/pci: Only check ownership of opened devices in hot reset
Hi Yi,
On 4/4/23 16:37, Liu, Yi L wrote:
> Hi Eric,
>
>> From: Eric Auger
>> Sent: Tuesday, April 4, 2023 10:00 PM
>>
>> Hi YI,
>>
>> On 4/1/23 16:44, Yi Liu wrote:
>>> If the affected device is not opened by any user, it's safe to reset it
>>> given it's not in use.
>>>
>>> Reviewed-by: Kevin Tian
>>> Reviewed-by: Jason Gunthorpe
>>> Tested-by: Yanting Jiang
>>> Signed-off-by: Yi Liu
>>> ---
>>> drivers/vfio/pci/vfio_pci_core.c | 14 +++---
>>> include/uapi/linux/vfio.h| 8
>>> 2 files changed, 19 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/vfio/pci/vfio_pci_core.c
>>> b/drivers/vfio/pci/vfio_pci_core.c
>>> index 65bbef562268..5d745c9abf05 100644
>>> --- a/drivers/vfio/pci/vfio_pci_core.c
>>> +++ b/drivers/vfio/pci/vfio_pci_core.c
>>> @@ -2429,10 +2429,18 @@ static int vfio_pci_dev_set_hot_reset(struct
>> vfio_device_set *dev_set,
>>> list_for_each_entry(cur_vma, _set->device_list, vdev.dev_set_list) {
>>> /*
>>> -* Test whether all the affected devices are contained by the
>>> -* set of groups provided by the user.
>>> +* Test whether all the affected devices can be reset by the
>>> +* user.
>>> +*
>>> +* Resetting an unused device (not opened) is safe, because
>>> +* dev_set->lock is held in hot reset path so this device
>>> +* cannot race being opened by another user simultaneously.
>>> +*
>>> +* Otherwise all opened devices in the dev_set must be
>>> +* contained by the set of groups provided by the user.
>>> */
>>> - if (!vfio_dev_in_groups(cur_vma, groups)) {
>>> + if (cur_vma->vdev.open_count &&
>>> + !vfio_dev_in_groups(cur_vma, groups)) {
>>> ret = -EINVAL;
>>> goto err_undo;
>>> }
>>> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
>>> index 0552e8dcf0cb..f96e5689cffc 100644
>>> --- a/include/uapi/linux/vfio.h
>>> +++ b/include/uapi/linux/vfio.h
>>> @@ -673,6 +673,14 @@ struct vfio_pci_hot_reset_info {
>>> * VFIO_DEVICE_PCI_HOT_RESET - _IOW(VFIO_TYPE, VFIO_BASE + 13,
>>> * struct vfio_pci_hot_reset)
>>> *
>>> + * Userspace requests hot reset for the devices it uses. Due to the
>>> + * underlying topology, multiple devices can be affected in the reset
>> by the reset
>>> + * while some might be opened by another user. To avoid interference
>> s/interference/hot reset failure?
> I don’t think user can really avoid hot reset failure since there may
> be new devices plugged into the affected slot. Even user has opened
I don't know the legacy wrt that issue but this sounds a serious issue,
meaning the reset of an assigned device could impact another device
belonging to another group not not owned by the user?
> all the groups/devices reported by VFIO_DEVICE_GET_PCI_HOT_RESET_INFO,
> the hot reset can fail if new device is plugged in and has not been
> bound to vfio or opened by another user during the window of
> _INFO and HOT_RESET.
with respect to the latter isn't the dev_set lock held during the hot
reset and sufficient to prevent any new opening to occur?
>
> maybe the whole statement should be as below:
>
> To avoid interference, the hot reset can only be conducted when all
> the affected devices are either opened by the calling user or not
> opened yet at the moment of the hot reset attempt.
OK
Eric
>
>>> + * the calling user must ensure all affected devices, if opened, are
>>> + * owned by itself.
>>> + *
>>> + * The ownership is proved by an array of group fds.
>>> + *
>>> * Return: 0 on success, -errno on failure.
>>> */
>>> struct vfio_pci_hot_reset {
> Regards,
> Yi Liu
Re: [Intel-gfx] [PATCH] drm/i915: run kernel-doc on headers as part of HDRTEST
On 4/4/2023 11:05 AM, Jani Nikula wrote:
Enabling kernel-doc warnings in commit aaee4bbe8a1a ("drm/i915: enable
kernel-doc warnings for CONFIG_DRM_I915_WERROR=y") actually only covers
the .c files. And it's good for avoiding warnings in W= builds. However,
we need something more to check for kernel-doc issues in headers. Add it
as part of the existing HDRTEST.
We have tons of issues, and this unleashes warnings galore on
CONFIG_DRM_I915_WERROR=y. It doesn't fail the build because (at least
for now) we don't pass -Werror to kernel-doc.
Cc: Rodrigo Vivi
Signed-off-by: Jani Nikula
This will be really helpful.
Acked-by: Nirmoy Das
Thanks,
Nirmoy
---
drivers/gpu/drm/i915/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 831e42175165..b739300267c2 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -387,7 +387,8 @@ always-$(CONFIG_DRM_I915_WERROR) += \
$(shell cd $(srctree)/$(src) && find * -name '*.h')))
quiet_cmd_hdrtest = HDRTEST $(patsubst %.hdrtest,%.h,$@)
- cmd_hdrtest = $(CC) $(filter-out $(CFLAGS_GCOV), $(c_flags)) -S -o
/dev/null -x c /dev/null -include $<; touch $@
+ cmd_hdrtest = $(CC) $(filter-out $(CFLAGS_GCOV), $(c_flags)) -S -o
/dev/null -x c /dev/null -include $<; \
+ $(srctree)/scripts/kernel-doc -none $<; touch $@
$(obj)/%.hdrtest: $(src)/%.h FORCE
$(call if_changed_dep,hdrtest)
