[Intel-gfx] ✓ Fi.CI.IGT: success for SAGV support for Gen12+ (rev13)
== Series Details == Series: SAGV support for Gen12+ (rev13) URL : https://patchwork.freedesktop.org/series/75129/ State : success == Summary == CI Bug Log - changes from CI_DRM_8247_full -> Patchwork_17204_full Summary --- **SUCCESS** No regressions found. New tests - New tests have been introduced between CI_DRM_8247_full and Patchwork_17204_full: ### New IGT tests (7) ### * igt@perf_pmu@faulting-read: - Statuses : - Exec time: [None] s * igt@prime_busy@after: - Statuses : - Exec time: [None] s * igt@prime_busy@after-wait: - Statuses : - Exec time: [None] s * igt@prime_busy@before: - Statuses : - Exec time: [None] s * igt@prime_busy@hang: - Statuses : - Exec time: [None] s * igt@prime_busy@hang-wait: - Statuses : - Exec time: [None] s * igt@prime_vgem@busy: - Statuses : - Exec time: [None] s Known issues Here are the changes found in Patchwork_17204_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_tiled_swapping@non-threaded: - shard-snb: [PASS][1] -> [FAIL][2] ([i915#1618]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/shard-snb5/igt@gem_tiled_swapp...@non-threaded.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17204/shard-snb2/igt@gem_tiled_swapp...@non-threaded.html * igt@gem_workarounds@suspend-resume: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/shard-apl7/igt@gem_workarou...@suspend-resume.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17204/shard-apl8/igt@gem_workarou...@suspend-resume.html * igt@gem_workarounds@suspend-resume-fd: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([i915#69]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/shard-skl1/igt@gem_workarou...@suspend-resume-fd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17204/shard-skl5/igt@gem_workarou...@suspend-resume-fd.html * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109349]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17204/shard-iclb7/igt@kms_dp_...@basic-dsc-enable-edp.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][9] -> [FAIL][10] ([i915#1188]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/shard-skl3/igt@kms_...@bpc-switch-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17204/shard-skl5/igt@kms_...@bpc-switch-suspend.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/shard-kbl7/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17204/shard-kbl2/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145] / [i915#265]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17204/shard-skl1/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html * igt@kms_psr@psr2_sprite_plane_move: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17204/shard-iclb7/igt@kms_psr@psr2_sprite_plane_move.html Possible fixes * igt@gem_mmap_gtt@hang: - shard-iclb: [FAIL][17] ([i915#1621]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/shard-iclb3/igt@gem_mmap_...@hang.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17204/shard-iclb8/igt@gem_mmap_...@hang.html * igt@gem_workarounds@suspend-resume-fd: - shard-kbl: [DMESG-WARN][19] ([i915#180] / [i915#93] / [i915#95]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/shard-kbl2/igt@gem_workarou...@suspend-resume-fd.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17204/shard-kbl7/igt@gem_workarou...@suspend-resume-fd.html * igt@i915_selftest@live@execlists: - shard-tglb: [INCOMPLETE][21] ([i915#647]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/shard-tglb6/igt@i915_selftest@l...@execlists.html [22]:
Re: [Intel-gfx] [PATCH v8 04/12] perf tool: extend Perf tool with CAP_PERFMON capability support
Hello, On Thu, Apr 2, 2020 at 5:47 PM Alexey Budankov wrote: > > > Extend error messages to mention CAP_PERFMON capability as an option > to substitute CAP_SYS_ADMIN capability for secure system performance > monitoring and observability operations. Make perf_event_paranoid_check() > and __cmd_ftrace() to be aware of CAP_PERFMON capability. > > CAP_PERFMON implements the principal of least privilege for performance > monitoring and observability operations (POSIX IEEE 1003.1e 2.2.2.39 > principle of least privilege: A security design principle that states > that a process or program be granted only those privileges (e.g., > capabilities) necessary to accomplish its legitimate function, and only > for the time that such privileges are actually required) > > For backward compatibility reasons access to perf_events subsystem remains > open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for > secure perf_events monitoring is discouraged with respect to CAP_PERFMON > capability. > > Signed-off-by: Alexey Budankov > Reviewed-by: James Morris Acked-by: Namhyung Kim Thanks Namhyung ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Revoke mmap before fence
== Series Details ==
Series: drm/i915: Revoke mmap before fence
URL : https://patchwork.freedesktop.org/series/75470/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8247_full -> Patchwork_17202_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17202_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17202_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_17202_full:
### IGT changes ###
Possible regressions
* igt@gem_ringfill@basic-default-hang:
- shard-skl: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17202/shard-skl1/igt@gem_ringf...@basic-default-hang.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_wait@write-busy@all}:
- shard-glk: [PASS][2] -> [FAIL][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/shard-glk3/igt@gem_wait@write-b...@all.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17202/shard-glk8/igt@gem_wait@write-b...@all.html
New tests
-
New tests have been introduced between CI_DRM_8247_full and
Patchwork_17202_full:
### New IGT tests (7) ###
* igt@perf_pmu@faulting-read:
- Statuses :
- Exec time: [None] s
* igt@prime_busy@after:
- Statuses :
- Exec time: [None] s
* igt@prime_busy@after-wait:
- Statuses :
- Exec time: [None] s
* igt@prime_busy@before:
- Statuses :
- Exec time: [None] s
* igt@prime_busy@hang:
- Statuses :
- Exec time: [None] s
* igt@prime_busy@hang-wait:
- Statuses :
- Exec time: [None] s
* igt@prime_vgem@busy:
- Statuses :
- Exec time: [None] s
Known issues
Here are the changes found in Patchwork_17202_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gen9_exec_parse@allowed-all:
- shard-glk: [PASS][4] -> [DMESG-WARN][5] ([i915#716])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/shard-glk2/igt@gen9_exec_pa...@allowed-all.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17202/shard-glk5/igt@gen9_exec_pa...@allowed-all.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][6] -> [FAIL][7] ([i915#454])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/shard-iclb2/igt@i915_pm...@dc6-psr.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17202/shard-iclb4/igt@i915_pm...@dc6-psr.html
* igt@kms_cursor_legacy@cursora-vs-flipa-atomic:
- shard-snb: [PASS][8] -> [SKIP][9] ([fdo#109271]) +4 similar
issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/shard-snb1/igt@kms_cursor_leg...@cursora-vs-flipa-atomic.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17202/shard-snb6/igt@kms_cursor_leg...@cursora-vs-flipa-atomic.html
* igt@kms_dp_dsc@basic-dsc-enable-edp:
- shard-iclb: [PASS][10] -> [SKIP][11] ([fdo#109349])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17202/shard-iclb4/igt@kms_dp_...@basic-dsc-enable-edp.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-apl: [PASS][12] -> [DMESG-WARN][13] ([i915#180] /
[i915#95])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/shard-apl4/igt@kms_fbcon_...@fbc-suspend.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17202/shard-apl8/igt@kms_fbcon_...@fbc-suspend.html
* igt@kms_flip@2x-flip-vs-expired-vblank:
- shard-glk: [PASS][14] -> [FAIL][15] ([i915#46])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/shard-glk7/igt@kms_f...@2x-flip-vs-expired-vblank.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17202/shard-glk4/igt@kms_f...@2x-flip-vs-expired-vblank.html
* igt@kms_flip@basic-flip-vs-wf_vblank:
- shard-skl: [PASS][16] -> [FAIL][17] ([i915#34])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/shard-skl5/igt@kms_flip@basic-flip-vs-wf_vblank.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17202/shard-skl7/igt@kms_flip@basic-flip-vs-wf_vblank.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl: [PASS][18] -> [FAIL][19] ([i915#79])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/shard-skl5/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
[19]:
Re: [Intel-gfx] [PATCH v2 16/17] drm: Nuke mode->private_flags
Hi Ville
Thanks for the patch.
Our understanding of private_flags was that we can use it within our
drivers to handle vendor specific features.
Hence we do have several features in our downstream drivers as well as
some planned work based on this.
This was the only method to pass around and consume the driver only
information which we have been using.
In the current qualcomm upstream display drivers, the only usage of the
mode->private_flags is what you have removed in
https://patchwork.kernel.org/patch/11473497/.
However, for other projects which do not use upstream drivers yet, we
have several features already which are using the mode->private_flags.
We do have a plan to remove the usage of mode->private_flags for those
drivers as well but its not ready yet.
These downstream drivers still use the upstream drm files for
compilation.
So how it works is we use all the headers under include/drm and also the
files under drivers/gpu/drm as-it-is from upstream but maintain our
drivers on top of this.
Removing this will result in compilation failures for us in the near
term.
Can we keep this one as-it-is and when our changes are ready to post it
upstream we shall remove private_flags from the drm_modes.h
Thanks
Abhinav
On 2020-04-03 13:40, Ville Syrjala wrote:
From: Ville Syrjälä
The last two uses of mode->private_flags (in i915 and gma500)
are now gone. So let's remove mode->private_flags entirely.
CC: Sam Ravnborg
Cc: Daniel Vetter
Cc: Emil Velikov
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 47d62b9d8d20..1e97138a9b8c 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -348,16 +348,6 @@ struct drm_display_mode {
*/
u8 type;
- /**
-* @private_flags:
-*
-* Driver private flags. private_flags can only be used for mode
- * objects passed to drivers in modeset operations. It shouldn't be
used
-* by atomic drivers since they can store any additional data by
-* subclassing state structures.
-*/
- u8 private_flags;
-
/**
* @head:
*
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for devm_drm_dev_alloc, no more drmm_add_final_kfree (rev3)
== Series Details == Series: devm_drm_dev_alloc, no more drmm_add_final_kfree (rev3) URL : https://patchwork.freedesktop.org/series/75463/ State : success == Summary == CI Bug Log - changes from CI_DRM_8252 -> Patchwork_17210 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17210/index.html Known issues Here are the changes found in Patchwork_17210 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@late_gt_pm: - fi-bsw-nick:[PASS][1] -> [INCOMPLETE][2] ([i915#1382]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8252/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17210/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html [i915#1382]: https://gitlab.freedesktop.org/drm/intel/issues/1382 Participating hosts (51 -> 39) -- Missing(12): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-ilk-650 fi-bdw-samus fi-byt-n2820 fi-byt-clapper fi-skl-6600u fi-snb-2600 Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8252 -> Patchwork_17210 CI-20190529: 20190529 CI_DRM_8252: 3690abb8ed49d9a066f80de39e4e75792c86ac76 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5563: 7ab7807727262b7ed7e12197b78e867287a17ef6 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17210: 7b4b396a9651b81dd206bd91b4f9f0b15ffcb5bb @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 7b4b396a9651 drm/managed: Cleanup of unused functions and polishing docs 3987454b5211 drm/i915/selftests: align more to real device lifetimes 6393e4b92e1c drm/i915/selftest: Create mock_destroy_device 4a439cfa5fcf drm/i915: Use devm_drm_dev_alloc 98784a0227c1 drm/cirrus: Don't use drm_device->dev_private 6249fdd96afa drm/cirrus: Use devm_drm_dev_alloc db39d7083700 drm/armada: Don't use drm_device->dev_private c7f35d34191f drm/armada: Use devm_drm_dev_alloc c689c28c7c33 drm/komeda: use devm_drm_dev_alloc 30d321d9c183 drm/ingenic: Don't set drm_device->dev_private ec4f2c0b4634 drm/ingenic: Use devm_drm_dev_alloc 84a9b2b7c79f drm/mcde: Don't use drm_device->dev_private 3ac62531c793 drm/mcde: Use devm_drm_dev_alloc d88455e402f4 drm/qxl: Don't use drm_device->dev_private 05389abcb0c1 drm/qxl: Use devm_drm_dev_alloc 74d72be056ef drm/tidss: Delete tidss->saved_state 877109556b31 drm/tidss: Don't use drm_device->dev_private 02af73e35a85 drm/tidss: Use devm_drm_dev_alloc 3376d9019b4c drm/gm12u320: Don't use drm_device->dev_private eb394269 drm/gm12u320: Use devm_drm_dev_alloc 7d059380b7de drm/hx8357d: Use devm_drm_dev_alloc 4b8b9048fa61 drm/ili9225: Use devm_drm_dev_alloc 25c9c3f9e447 drm/ili9341: Use devm_drm_dev_alloc a8b3f3a2dfb2 drm/ili9486: Use devm_drm_dev_alloc 6d7d1f235e30 drm/mi0283qt: Use devm_drm_dev_alloc d5de90a7063e drm/repaper: Use devm_drm_dev_alloc 09e5644e82b8 drm/st7586: Use devm_drm_dev_alloc 3dc0b3b337f2 drm/st7735r: Use devm_drm_dev_alloc 4cb201d3bd97 drm/udl: don't set drm_device->dev_private ec9cf4556e61 drm/udl: Use demv_drm_dev_alloc 66c944512b95 drm/v3d: Delete v3d_dev->pdev f48e47f68a86 drm/v3d: Delete v3d_dev->dev d25b70710de9 drm/v3d: Use devm_drm_dev_alloc ec196f9e0be0 drm/v3d: Don't set drm_device->dev_private 6e4b89850b36 drm/vboxvideo: Use devm_gen_pool_create 9ba07a46cef1 drm/vboxvidoe: use managed pci functions 76793ba02626 drm/vboxvideo: Stop using drm_device->dev_private 098edba18627 drm/vboxvideo: Use devm_drm_dev_alloc aae694a8a5d2 drm/vboxvideo: drop DRM_MTRR_WC #define 5920030f62ea drm/vkms: Use devm_drm_dev_alloc a78829a54af6 drm/vgem: Use devm_drm_dev_alloc ed01ac38e04a drm/device: Deprecate dev_private harder e239d39afecc drm: Add devm_drm_dev_alloc macro e72346e75771 drivers/base: Always release devres on device_del == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17210/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for devm_drm_dev_alloc, no more drmm_add_final_kfree (rev3)
== Series Details == Series: devm_drm_dev_alloc, no more drmm_add_final_kfree (rev3) URL : https://patchwork.freedesktop.org/series/75463/ State : warning == Summary == $ dim checkpatch origin/drm-tip e72346e75771 drivers/base: Always release devres on device_del -:78: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 8 lines checked e239d39afecc drm: Add devm_drm_dev_alloc macro -:26: ERROR:POINTER_LOCATION: "foo* bar" should be "foo *bar" #26: FILE: drivers/gpu/drm/drm_drv.c:742: +void* __devm_drm_dev_alloc(struct device *parent, struct drm_driver *driver, -:60: ERROR:POINTER_LOCATION: "foo* bar" should be "foo *bar" #60: FILE: include/drm/drm_drv.h:626: +void* __devm_drm_dev_alloc(struct device *parent, struct drm_driver *driver, -:90: CHECK:SPACING: No space is necessary after a cast #90: FILE: include/drm/drm_drv.h:656: + ((type *) __devm_drm_dev_alloc(parent, driver, sizeof(type), \ -:95: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 2 errors, 1 warnings, 1 checks, 68 lines checked ed01ac38e04a drm/device: Deprecate dev_private harder -:30: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 15 lines checked a78829a54af6 drm/vgem: Use devm_drm_dev_alloc -:13: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #13: This also somewhat untangles the load code, since the drm and platform device total: 0 errors, 1 warnings, 0 checks, 79 lines checked 5920030f62ea drm/vkms: Use devm_drm_dev_alloc -:13: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #13: This also somewhat untangles the load code, since the drm and platform device -:118: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 2 warnings, 0 checks, 90 lines checked aae694a8a5d2 drm/vboxvideo: drop DRM_MTRR_WC #define -:40: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 25 lines checked 098edba18627 drm/vboxvideo: Use devm_drm_dev_alloc -:62: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 45 lines checked 76793ba02626 drm/vboxvideo: Stop using drm_device->dev_private -:97: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 62 lines checked 9ba07a46cef1 drm/vboxvidoe: use managed pci functions -:76: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 52 lines checked 6e4b89850b36 drm/vboxvideo: Use devm_gen_pool_create -:75: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 57 lines checked ec196f9e0be0 drm/v3d: Don't set drm_device->dev_private -:37: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 15 lines checked d25b70710de9 drm/v3d: Use devm_drm_dev_alloc -:104: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 84 lines checked f48e47f68a86 drm/v3d: Delete v3d_dev->dev -:347: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 271 lines checked 66c944512b95 drm/v3d: Delete v3d_dev->pdev -:60: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'v3d' may be better as '(v3d)' to avoid precedence issues #60: FILE: drivers/gpu/drm/v3d/v3d_drv.h:130: +#define v3d_to_pdev(v3d) to_platform_device(v3d->drm.dev) -:97: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 1 checks, 56 lines checked ec9cf4556e61 drm/udl: Use demv_drm_dev_alloc -:93: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 68 lines checked 4cb201d3bd97 drm/udl: don't set drm_device->dev_private -:91: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 47 lines checked 3dc0b3b337f2 drm/st7735r: Use devm_drm_dev_alloc -:44: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 25 lines checked 09e5644e82b8 drm/st7586: Use devm_drm_dev_alloc -:38: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter '
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/dp_mst: Remove drm_dp_mst_has_audio()
== Series Details ==
Series: drm/dp_mst: Remove drm_dp_mst_has_audio()
URL : https://patchwork.freedesktop.org/series/75488/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8252 -> Patchwork_17209
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17209/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17209:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_wait@busy@all}:
- fi-bwr-2160:[PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8252/fi-bwr-2160/igt@gem_wait@b...@all.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17209/fi-bwr-2160/igt@gem_wait@b...@all.html
Known issues
Here are the changes found in Patchwork_17209 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-icl-dsi: [PASS][3] -> [INCOMPLETE][4] ([i915#189])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8252/fi-icl-dsi/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17209/fi-icl-dsi/igt@i915_pm_...@module-reload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#189]: https://gitlab.freedesktop.org/drm/intel/issues/189
Participating hosts (51 -> 39)
--
Missing(12): fi-ilk-m540 fi-bdw-5557u fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-bsw-kefka fi-skl-lmem fi-kbl-7560u fi-byt-n2820 fi-byt-clapper
fi-bsw-nick fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8252 -> Patchwork_17209
CI-20190529: 20190529
CI_DRM_8252: 3690abb8ed49d9a066f80de39e4e75792c86ac76 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5563: 7ab7807727262b7ed7e12197b78e867287a17ef6 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17209: 021adaffa4ba4407444a9fec8a29e2c5cba3f755 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
021adaffa4ba drm/dp_mst: Remove drm_dp_mst_has_audio()
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17209/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: align more to real device lifetimes
The big change is device_add so that device_del can auto-cleanup
devres resources. This allows us to use devm_drm_dev_alloc, which
removes the last user of drm_dev_init.
v2: Rebased
Signed-off-by: Daniel Vetter
---
.../gpu/drm/i915/selftests/mock_gem_device.c | 33 +--
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 41afc357f4d0..1ab97fa55929 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -123,12 +123,6 @@ struct drm_i915_private *mock_gem_device(void)
pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
if (!pdev)
return NULL;
- i915 = kzalloc(sizeof(*i915), GFP_KERNEL);
- if (!i915) {
- kfree(pdev);
- return NULL;
- }
-
device_initialize(>dev);
pdev->class = PCI_BASE_CLASS_DISPLAY << 16;
pdev->dev.release = release_dev;
@@ -139,8 +133,23 @@ struct drm_i915_private *mock_gem_device(void)
/* hack to disable iommu for the fake device; force identity mapping */
pdev->dev.archdata.iommu = (void *)-1;
#endif
+ err = device_add(>dev);
+ if (err) {
+ kfree(pdev);
+ return NULL;
+ }
+
+ i915 = devm_drm_dev_alloc(>dev, _driver,
+ struct drm_i915_private, drm);
+ if (err) {
+ pr_err("Failed to allocate mock GEM device: err=%d\n", err);
+ put_device(>dev);
+
+ return NULL;
+ }
pci_set_drvdata(pdev, i915);
+ i915->drm.pdev = pdev;
dev_pm_domain_set(>dev, _domain);
pm_runtime_enable(>dev);
@@ -148,16 +157,6 @@ struct drm_i915_private *mock_gem_device(void)
if (pm_runtime_enabled(>dev))
WARN_ON(pm_runtime_get_sync(>dev));
- err = drm_dev_init(>drm, _driver, >dev);
- if (err) {
- pr_err("Failed to initialise mock GEM device: err=%d\n", err);
- put_device(>dev);
- kfree(i915);
-
- return NULL;
- }
- i915->drm.pdev = pdev;
- drmm_add_final_kfree(>drm, i915);
intel_runtime_pm_init_early(>runtime_pm);
@@ -221,5 +220,5 @@ struct drm_i915_private *mock_gem_device(void)
void mock_destroy_device(struct drm_i915_private *i915)
{
- drm_dev_put(>drm);
+ device_del(i915->drm.dev);
}
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftest: Create mock_destroy_device
Just some prep work before we rework the lifetime handling, which requires replacing all the drm_dev_put in selftests by something else. v2: Don't go with a static inline, upsets the header tests and separation. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 2 +- drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 2 +- drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c | 2 +- drivers/gpu/drm/i915/gem/selftests/i915_gem_phys.c| 2 +- drivers/gpu/drm/i915/gt/selftest_timeline.c | 2 +- drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 2 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +- drivers/gpu/drm/i915/selftests/i915_request.c | 2 +- drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +- drivers/gpu/drm/i915/selftests/intel_memory_region.c | 2 +- drivers/gpu/drm/i915/selftests/mock_gem_device.c | 7 ++- drivers/gpu/drm/i915/selftests/mock_gem_device.h | 2 ++ 13 files changed, 19 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c index 2d0fd50c5312..d19bb011fc6b 100644 --- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c +++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c @@ -1789,7 +1789,7 @@ int i915_gem_huge_page_mock_selftests(void) i915_vm_put(>vm); out_unlock: - drm_dev_put(_priv->drm); + mock_destroy_device(dev_priv); return err; } diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c index f4f933240b39..d9d96d23e37e 100644 --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c @@ -1986,7 +1986,7 @@ int i915_gem_context_mock_selftests(void) err = i915_subtests(tests, i915); - drm_dev_put(>drm); + mock_destroy_device(i915); return err; } diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c index 2a52b92586b9..0845ce1ae37c 100644 --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c @@ -272,7 +272,7 @@ int i915_gem_dmabuf_mock_selftests(void) err = i915_subtests(tests, i915); - drm_dev_put(>drm); + mock_destroy_device(i915); return err; } diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c index 2b6db6f799de..085644edebfc 100644 --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c @@ -85,7 +85,7 @@ int i915_gem_object_mock_selftests(void) err = i915_subtests(tests, i915); - drm_dev_put(>drm); + mock_destroy_device(i915); return err; } diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_phys.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_phys.c index 34932871b3a5..2a9709eb5a42 100644 --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_phys.c +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_phys.c @@ -73,6 +73,6 @@ int i915_gem_phys_mock_selftests(void) err = i915_subtests(tests, i915); - drm_dev_put(>drm); + mock_destroy_device(i915); return err; } diff --git a/drivers/gpu/drm/i915/gt/selftest_timeline.c b/drivers/gpu/drm/i915/gt/selftest_timeline.c index c2578a0f2f14..1c0865227714 100644 --- a/drivers/gpu/drm/i915/gt/selftest_timeline.c +++ b/drivers/gpu/drm/i915/gt/selftest_timeline.c @@ -157,7 +157,7 @@ static int mock_hwsp_freelist(void *arg) __mock_hwsp_record(, na, NULL); kfree(state.history); err_put: - drm_dev_put(>drm); + mock_destroy_device(i915); return err; } diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c index 028baae9631f..f88473d396f4 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c +++ b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c @@ -536,7 +536,7 @@ int i915_gem_evict_mock_selftests(void) with_intel_runtime_pm(>runtime_pm, wakeref) err = i915_subtests(tests, >gt); - drm_dev_put(>drm); + mock_destroy_device(i915); return err; } diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c index 5d2a02fcf595..035e4f77f06f 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c @@ -1714,7 +1714,7 @@ int i915_gem_gtt_mock_selftests(void) mock_fini_ggtt(ggtt); kfree(ggtt); out_put: - drm_dev_put(>drm); + mock_destroy_device(i915); return err; } diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Put drm_display_mode on diet (rev2)
== Series Details ==
Series: drm: Put drm_display_mode on diet (rev2)
URL : https://patchwork.freedesktop.org/series/73674/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8252 -> Patchwork_17208
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17208 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17208, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17208/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17208:
### IGT changes ###
Possible regressions
* igt@runner@aborted:
- fi-ilk-650: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17208/fi-ilk-650/igt@run...@aborted.html
- fi-snb-2520m: NOTRUN -> [FAIL][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17208/fi-snb-2520m/igt@run...@aborted.html
- fi-snb-2600:NOTRUN -> [FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17208/fi-snb-2600/igt@run...@aborted.html
- fi-ivb-3770:NOTRUN -> [FAIL][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17208/fi-ivb-3770/igt@run...@aborted.html
Participating hosts (51 -> 42)
--
Missing(9): fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy fi-byt-squawks
fi-bsw-cyan fi-kbl-7560u fi-byt-n2820 fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8252 -> Patchwork_17208
CI-20190529: 20190529
CI_DRM_8252: 3690abb8ed49d9a066f80de39e4e75792c86ac76 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5563: 7ab7807727262b7ed7e12197b78e867287a17ef6 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17208: ace765c38dc55b9864e8b9478cbca5f3bf10cc57 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ace765c38dc5 drm: Replace mode->export_head with a boolean
5b136e94b7a4 drm: Nuke mode->private_flags
6e809802b439 drm/gma500: Stop using mode->private_flags
6c2380cbc283 drm/i915: Replace I915_MODE_FLAG_INHERITED with a boolean
103e75194d66 drm/i915: Stop using mode->private_flags
9122853a9574 drm/mcde: Use mode->clock instead of reverse calculating it from
the vrefresh
d3368fb30d7c drm: pahole struct drm_display_mode
00ab805b0fb4 drm: Shrink mode->private_flags
8f96019c76dc drm: Flatten drm_mode_vrefresh()
d6bf22e2b0a3 drm: Shrink drm_display_mode timings
34c66e3566bb drm: Make mode->flags u32
4f5ba370e14f drm: Shrink mode->type to u8
f44cce4a1d9f drm: Shrink {width,height}_mm to u16
4b303d777e7b drm/msm/dpu: Stop copying around mode->private_flags
325b0ad221fe drm: Nuke mode->vrefresh
bb6f7d766981 drm/i915: Introduce some local intel_dp variables
fa630bba9e2b drm: Nuke mode->hsync
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17208/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/dp_mst: Remove drm_dp_mst_has_audio()
Drive-by fix I noticed the other day - drm_dp_mst_has_audio() only ever
made sense back when we still had to validate ports before accessing
them in order to (attempt to) avoid NULL dereferences. Since we have
proper reference counting that guarantees we always can safely access
the MST port, there's no use in keeping this function around as all it
does is validate the port pointer before checking the audio status.
Note - drm_dp_mst_port->has_audio is technically protected by
drm_device->mode_config.connection_mutex, since it's only ever updated
from drm_dp_mst_get_edid(). Additionally, we change the declaration for
port in struct intel_connector to be properly typed, so we can directly
access it.
Cc: "Lee, Shawn C"
Cc: Sean Paul
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 21 ---
.../drm/i915/display/intel_display_debugfs.c | 10 ++---
.../drm/i915/display/intel_display_types.h| 2 +-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +--
include/drm/drm_dp_mst_helper.h | 2 --
5 files changed, 4 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 1ff49547b2e8..129126091e90 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4063,27 +4063,6 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
}
EXPORT_SYMBOL(drm_dp_mst_detect_port);
-/**
- * drm_dp_mst_port_has_audio() - Check whether port has audio capability or not
- * @mgr: manager for this port
- * @port: unverified pointer to a port.
- *
- * This returns whether the port supports audio or not.
- */
-bool drm_dp_mst_port_has_audio(struct drm_dp_mst_topology_mgr *mgr,
- struct drm_dp_mst_port *port)
-{
- bool ret = false;
-
- port = drm_dp_mst_topology_get_port_validated(mgr, port);
- if (!port)
- return ret;
- ret = port->has_audio;
- drm_dp_mst_topology_put_port(port);
- return ret;
-}
-EXPORT_SYMBOL(drm_dp_mst_port_has_audio);
-
/**
* drm_dp_mst_get_edid() - get EDID for an MST port
* @connector: toplevel connector to get EDID for
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 424f4e52f783..9f736420d83f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -631,15 +631,9 @@ static void intel_dp_info(struct seq_file *m,
}
static void intel_dp_mst_info(struct seq_file *m,
- struct intel_connector *intel_connector)
+ struct intel_connector *intel_connector)
{
- struct intel_encoder *intel_encoder =
intel_attached_encoder(intel_connector);
- struct intel_dp_mst_encoder *intel_mst =
- enc_to_mst(intel_encoder);
- struct intel_digital_port *intel_dig_port = intel_mst->primary;
- struct intel_dp *intel_dp = _dig_port->dp;
- bool has_audio = drm_dp_mst_port_has_audio(_dp->mst_mgr,
- intel_connector->port);
+ bool has_audio = intel_connector->port->has_audio;
seq_printf(m, "\taudio support: %s\n", yesno(has_audio));
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 2bedd626c686..1de7bef0a49b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -436,7 +436,7 @@ struct intel_connector {
state of connector->polled in case hotplug storm detection changes
it */
u8 polled;
- void *port; /* store this opaque as its illegal to dereference it */
+ struct drm_dp_mst_port *port;
struct intel_dp *mst_port;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 61605eb8c2af..c35efc9e628d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -114,8 +114,7 @@ static int intel_dp_mst_compute_config(struct intel_encoder
*encoder,
if (intel_conn_state->force_audio == HDMI_AUDIO_AUTO)
pipe_config->has_audio =
- drm_dp_mst_port_has_audio(_dp->mst_mgr,
- connector->port);
+ connector->port->has_audio;
else
pipe_config->has_audio =
intel_conn_state->force_audio == HDMI_AUDIO_ON;
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 7af51c947b81..2d7c26592c05 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -732,8 +732,6 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
struct drm_dp_mst_topology_mgr *mgr,
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Put drm_display_mode on diet (rev2)
== Series Details ==
Series: drm: Put drm_display_mode on diet (rev2)
URL : https://patchwork.freedesktop.org/series/73674/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fa630bba9e2b drm: Nuke mode->hsync
bb6f7d766981 drm/i915: Introduce some local intel_dp variables
325b0ad221fe drm: Nuke mode->vrefresh
-:1431: WARNING:LONG_LINE: line over 100 characters
#1431: FILE: drivers/gpu/drm/i915/display/intel_dp.c:7750:
+
drm_mode_vrefresh(intel_dp->attached_connector->panel.fixed_mode));
-:1440: WARNING:LONG_LINE: line over 100 characters
#1440: FILE: drivers/gpu/drm/i915/display/intel_dp.c:7796:
+
drm_mode_vrefresh(intel_dp->attached_connector->panel.fixed_mode));
total: 0 errors, 2 warnings, 0 checks, 2591 lines checked
4b303d777e7b drm/msm/dpu: Stop copying around mode->private_flags
-:85: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#85: FILE: drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h:330:
+ TP_PROTO(uint32_t drm_id, unsigned int flags),
total: 0 errors, 0 warnings, 1 checks, 71 lines checked
f44cce4a1d9f drm: Shrink {width,height}_mm to u16
4f5ba370e14f drm: Shrink mode->type to u8
34c66e3566bb drm: Make mode->flags u32
d6bf22e2b0a3 drm: Shrink drm_display_mode timings
8f96019c76dc drm: Flatten drm_mode_vrefresh()
00ab805b0fb4 drm: Shrink mode->private_flags
d3368fb30d7c drm: pahole struct drm_display_mode
9122853a9574 drm/mcde: Use mode->clock instead of reverse calculating it from
the vrefresh
103e75194d66 drm/i915: Stop using mode->private_flags
6c2380cbc283 drm/i915: Replace I915_MODE_FLAG_INHERITED with a boolean
6e809802b439 drm/gma500: Stop using mode->private_flags
5b136e94b7a4 drm: Nuke mode->private_flags
ace765c38dc5 drm: Replace mode->export_head with a boolean
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Treat idling as a RPS downclock event
Quoting Lyude Paul (2020-04-03 22:25:43) > Hey - almost forgot to reply to this, I actually probably won't be able to > test this properly for a while since my razer laptop is actually stuck in the > office I work at, and I legally can't get to it with COVID-19 shelter-in- > place. Sorry about that! No worries, but I'll probably forget to ping you when the world settles down again. It's just something for you to keep in mind in case we get some strange bug reports in 6 months time. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Treat idling as a RPS downclock event
Hey - almost forgot to reply to this, I actually probably won't be able to
test this properly for a while since my razer laptop is actually stuck in the
office I work at, and I legally can't get to it with COVID-19 shelter-in-
place. Sorry about that!
On Sun, 2020-03-22 at 15:40 +, Chris Wilson wrote:
> If we park/unpark faster than we can respond to RPS events, we never
> will process a downlock event after expiring a waitboost, and thus we
> will forever restart the GPU at max clocks even if the workload switches
> and doesn't justify full power.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/issues/1500
> Fixes: 3e7abf814193 ("drm/i915: Extract GT render power state management")
> Signed-off-by: Chris Wilson
> Cc: Andi Shyti
> Cc: Lyude Paul
> ---
> drivers/gpu/drm/i915/gt/intel_rps.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
> b/drivers/gpu/drm/i915/gt/intel_rps.c
> index 7bf631ca560b..50884aeac49c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> @@ -771,6 +771,19 @@ void intel_rps_park(struct intel_rps *rps)
> intel_uncore_forcewake_get(rps_to_uncore(rps), FORCEWAKE_MEDIA);
> rps_set(rps, rps->idle_freq, false);
> intel_uncore_forcewake_put(rps_to_uncore(rps), FORCEWAKE_MEDIA);
> +
> + /*
> + * Since we will try and restart from the previously requested
> + * frequency on unparking, treat this idle point as a downlock
> + * interrupt and reduce the frequency for resume. If we park/unpark
> + * more frequently than the rps worker can run, we will not respond
> + * to any EI and never see a change in frequency.
> + *
> + * (Note the we accommodate Cherryview's limitation of only using
> + * an even bin by applying it to all.)
> + */
> + rps->cur_freq =
> + max_t(u8, round_down(rps->cur_freq - 1, 2), rps->min_freq);
> }
>
> void intel_rps_boost(struct i915_request *rq)
--
Cheers,
Lyude Paul (she/her)
Associate Software Engineer at Red Hat
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Free request pool from virtual engines
== Series Details ==
Series: drm/i915/gt: Free request pool from virtual engines
URL : https://patchwork.freedesktop.org/series/75483/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8251 -> Patchwork_17207
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17207/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17207:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_wait@busy@all}:
- fi-gdg-551: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8251/fi-gdg-551/igt@gem_wait@b...@all.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17207/fi-gdg-551/igt@gem_wait@b...@all.html
Known issues
Here are the changes found in Patchwork_17207 that come from known issues:
### IGT changes ###
Possible fixes
* igt@i915_selftest@live@execlists:
- fi-bxt-dsi: [INCOMPLETE][3] ([i915#656]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8251/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17207/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656
Participating hosts (50 -> 44)
--
Additional (1): fi-kbl-7560u
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-byt-squawks
fi-bsw-cyan fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8251 -> Patchwork_17207
CI-20190529: 20190529
CI_DRM_8251: 06ddf8dd059d59bc27c24b09a6e500809e619982 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5563: 7ab7807727262b7ed7e12197b78e867287a17ef6 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17207: 2b48a55078059e7c8ac8fda34f5d2b0c3aa9ace5 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
2b48a5507805 drm/i915/gt: Free request pool from virtual engines
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17207/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 03/17] drm: Nuke mode->vrefresh
Hi Ville,
Thank you for the patch.
On Fri, Apr 03, 2020 at 11:39:54PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Get rid of mode->vrefresh and just calculate it on demand. Saves
> a bit of space and avoids the cached value getting out of sync
> with reality.
>
> Mostly done with cocci, with the following manual fixups:
> - Remove the now empty loop in drm_helper_probe_single_connector_modes()
> - Fix __MODE() macro in ch7006_mode.c
> - Fix DRM_MODE_ARG() macro in drm_modes.h
> - Remove leftover comment from samsung_s6d16d0_mode
> - Drop the TODO
>
> @@
> @@
> struct drm_display_mode {
> ...
> - int vrefresh;
> ...
> };
>
> @@
> identifier N;
> expression E;
> @@
> struct drm_display_mode N = {
> - .vrefresh = E
> };
>
> @@
> identifier N;
> expression E;
> @@
> struct drm_display_mode N[...] = {
> ...,
> {
> - .vrefresh = E
> }
> ,...
> };
>
> @@
> expression E;
> @@
> {
> DRM_MODE(...),
> - .vrefresh = E,
> }
>
> @@
> identifier M, R;
> @@
> int drm_mode_vrefresh(const struct drm_display_mode *M)
> {
> ...
> - if (M->vrefresh > 0)
> - R = M->vrefresh;
> - else
> if (...) {
> ...
> }
> ...
> }
>
> @@
> struct drm_display_mode *p;
> expression E;
> @@
> (
> - p->vrefresh = E;
> |
> - p->vrefresh
> + drm_mode_vrefresh(p)
> )
>
> @@
> struct drm_display_mode s;
> expression E;
> @@
> (
> - s.vrefresh = E;
> |
> - s.vrefresh
> + drm_mode_vrefresh()
> )
>
> @@
> expression E;
> @@
> - drm_mode_vrefresh(E) ? drm_mode_vrefresh(E) : drm_mode_vrefresh(E)
> + drm_mode_vrefresh(E)
>
> @find_substruct@
> identifier X;
> identifier S;
> @@
> struct X {
> ...
> struct drm_display_mode S;
> ...
> };
>
> @@
> identifier find_substruct.S;
> expression E;
> identifier I;
> @@
> {
> .S = {
> - .vrefresh = E
> }
> }
>
> @@
> identifier find_substruct.S;
> identifier find_substruct.X;
> expression E;
> identifier I;
> @@
> struct X I[...] = {
> ...,
> .S = {
> - .vrefresh = E
> }
> ,...
> };
>
> v2: Drop TODO
>
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Cc: Linus Walleij
> Cc: CK Hu
> Cc: Philipp Zabel
> Cc: Ben Skeggs
> Cc: Thierry Reding
> Cc: Sam Ravnborg
> Cc: Jerry Han
> Cc: Icenowy Zheng
> Cc: Jagan Teki
> Cc: Stefan Mavrodiev
> Cc: Robert Chiras
> Cc: "Guido Günther"
> Cc: Purism Kernel Team
> Cc: Benjamin Gaignard
> Cc: Vincent Abriou
> Cc: VMware Graphics
> Cc: Thomas Hellstrom
> Cc: linux-amlo...@lists.infradead.org
> Cc: nouv...@lists.freedesktop.org
> Reviewed-by: Emil Velikov
> Reviewed-by: Sam Ravnborg
> Acked-by: Linus Walleij
> Signed-off-by: Ville Syrjälä
> ---
> Documentation/gpu/todo.rst| 20 --
> drivers/gpu/drm/bridge/sii902x.c | 2 +-
> drivers/gpu/drm/drm_client_modeset.c | 2 +-
> drivers/gpu/drm/drm_edid.c| 328 +-
> drivers/gpu/drm/drm_modes.c | 9 +-
> drivers/gpu/drm/drm_probe_helper.c| 3 -
> drivers/gpu/drm/exynos/exynos_hdmi.c | 5 +-
> drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
> drivers/gpu/drm/i2c/ch7006_mode.c | 1 -
> drivers/gpu/drm/i915/display/intel_display.c | 1 -
> .../drm/i915/display/intel_display_debugfs.c | 4 +-
> drivers/gpu/drm/i915/display/intel_dp.c | 10 +-
> drivers/gpu/drm/i915/display/intel_tv.c | 3 -
> drivers/gpu/drm/mcde/mcde_dsi.c | 6 +-
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +-
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
> drivers/gpu/drm/meson/meson_venc_cvbs.c | 2 -
> drivers/gpu/drm/nouveau/nouveau_connector.c | 5 +-
> drivers/gpu/drm/panel/panel-arm-versatile.c | 4 -
> drivers/gpu/drm/panel/panel-boe-himax8279d.c | 3 +-
> .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 6 +-
> drivers/gpu/drm/panel/panel-elida-kd35t133.c | 3 +-
> .../gpu/drm/panel/panel-feixin-k101-im2ba02.c | 3 +-
> .../drm/panel/panel-feiyang-fy07024di26a30d.c | 3 +-
> drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 7 -
> drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 3 +-
> drivers/gpu/drm/panel/panel-innolux-p079zca.c | 4 +-
> .../gpu/drm/panel/panel-jdi-lt070me05000.c| 3 +-
> .../drm/panel/panel-kingdisplay-kd097d04.c| 3 +-
> .../drm/panel/panel-leadtek-ltk500hd1829.c| 3 +-
> drivers/gpu/drm/panel/panel-lg-lb035q02.c | 1 -
> drivers/gpu/drm/panel/panel-lg-lg4573.c | 3 +-
> drivers/gpu/drm/panel/panel-nec-nl8048hl11.c | 1 -
> drivers/gpu/drm/panel/panel-novatek-nt35510.c | 1 -
> drivers/gpu/drm/panel/panel-novatek-nt39016.c | 1 -
> .../drm/panel/panel-olimex-lcd-olinuxino.c| 1 -
> .../gpu/drm/panel/panel-orisetech-otm8009a.c | 3 +-
> .../drm/panel/panel-osd-osd101t2587-53ts.c| 3 +-
>
Re: [Intel-gfx] [PATCH v2 5/5] uaccess: Rename user_access_begin/end() to user_full_access_begin/end()
On Fri, Apr 03, 2020 at 11:01:10AM -0700, Linus Torvalds wrote:
> On Fri, Apr 3, 2020 at 12:21 AM Christophe Leroy
> wrote:
> >
> > Now we have user_read_access_begin() and user_write_access_begin()
> > in addition to user_access_begin().
>
> I realize Al asked for this, but I don't think it really adds anything
> to the series.
>
> The "full" makes the names longer, but not really any more legible.
>
> So I like 1-4, but am unconvinced about 5 and would prefer that to be
> dropped. Sorry for the bikeshedding.
>
> And I like this series much better without the cookie that was
> discussed, and just making the hard rule be that they can't nest.
>
> Some architecture may obviously use a cookie internally if they have
> some nesting behavior of their own, but it doesn't look like we have
> any major reason to expose that as the actual interface.
>
> The only other question is how to synchronize this? I'm ok with it
> going through the ppc tree, for example, and just let others build on
> that. Maybe using a shared immutable branch with 5.6 as a base?
I can do a 5.7-rc1-based branch with that; depending upon what we end
up doing for arm and s390 we can always change the calling conventions
come next cycle ;-/
My impressions after digging through arm side of things:
1) the only instance of nesting I'd found there (so far) is a mistake.
The rule should be "no fucking nesting, TYVM".
2) I'm really unhappy about the uaccess_with_memcpy thing. Besides
being fucking ugly, it kills any hope of lifting user_access_begin/end
out of raw_copy_to_user() - the things done in that bastard are
obviously *NOT* fit for uaccess block. Including the wonders like
/* the mmap semaphore is taken only if not in an atomic context */
atomic = faulthandler_disabled();
if (!atomic)
down_read(>mm->mmap_sem);
which, IMO, deserves to be taken out and shot. Not that pin_page_for_write()
in the same file (arch/arm/lib/uaccess_with_memcpy.c) did not deserve the
same treatment... As far as I can tell, the whole point of that thing
is that well, memcpy() is optimized better than raw_copy_to_user()...
So what's wrong with taking the damn optimized memcpy and using it for
raw_copy_to_user() instead?
Is that the lack of STRT analogue that would store several registers?
Because AFAICS commit f441882a5229ffaef61a47bccd4518f7e2749cbc
Author: Vincent Whitchurch
Date: Fri Nov 9 10:09:48 2018 +0100
ARM: 8812/1: Optimise copy_{from/to}_user for !CPU_USE_DOMAINS
makes for much saner solution... I realize that it's v6+ and this
thing is specifically for a v5 variant, but...
3) how much do we need to keep the old DACR value in a register for
uaccess_restore()? AFAICS, if we prohibit nesting it becomes
a function of USER_DS/KERNEL_DS setting (and that - only for
CPU_USE_DOMAINS), doesn't it? And we had to have fetched it
recently, back when access_ok() had been done, so shouldn't
it be in cache?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Wait until we start timeslicing after a submit
== Series Details == Series: drm/i915/selftests: Wait until we start timeslicing after a submit URL : https://patchwork.freedesktop.org/series/75479/ State : success == Summary == CI Bug Log - changes from CI_DRM_8251 -> Patchwork_17206 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17206/index.html Known issues Here are the changes found in Patchwork_17206 that come from known issues: ### IGT changes ### Issues hit * igt@kms_flip@basic-flip-vs-dpms: - fi-skl-6770hq: [PASS][1] -> [SKIP][2] ([fdo#109271]) +24 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8251/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17206/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html Possible fixes * igt@i915_selftest@live@execlists: - fi-bxt-dsi: [INCOMPLETE][3] ([i915#656]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8251/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17206/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656 Participating hosts (50 -> 43) -- Additional (1): fi-kbl-7560u Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-bsw-kefka fi-byt-n2820 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8251 -> Patchwork_17206 CI-20190529: 20190529 CI_DRM_8251: 06ddf8dd059d59bc27c24b09a6e500809e619982 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5563: 7ab7807727262b7ed7e12197b78e867287a17ef6 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17206: f4b4d95a71b90b41b333fab5fd92683386ee0f79 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == f4b4d95a71b9 drm/i915/selftests: Wait until we start timeslicing after a submit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17206/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 17/17] drm: Replace mode->export_head with a boolean
From: Ville Syrjälä
In order to shrink drm_display_mode below the magic two cacheline
mark in 64bit we need to shrink it by another 8 bytes. The easiest
thing to eliminate is the 'export_head' list head which is only
used during the getconnector ioctl to temporarly track which modes
on the connector's mode list are to be exposed and which are to
remain hidden.
We can simply replace the list head with a boolean which we use
to tag the modes that are to be exposed. If we make sure to clear
the tags after we're done with them we don't even need an extra
loop over the modes to reset the tags at the start of the
getconnector ioctl.
Conveniently we already have a hole for the boolean left
behind by the removal of mode->private_flags. The final size
of the struct is now 112 bytes on 32bit and 120 bytes on 64bit.
The downside is that drm_mode_expose_to_userspace() gets to
iterate a few more modes. It already was O(n^2), now it's
a slightly worse O(n^2).
Another alternative would be a temp bitmask so we wouldn't have
to have anything in the mode struct itself. The mail issues is
how large of a bitmask do we need? I guess we could allocate
it dynamically but that means an extra kcalloc() and an extra
loop through the modes to count them first (or grow the bitmask
with krealloc() as needed).
CC: Sam Ravnborg
Cc: Daniel Vetter
Cc: Emil Velikov
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_connector.c | 45 +++--
include/drm/drm_modes.h | 24 --
2 files changed, 43 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b1099e1251a2..7e719b08564d 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2198,7 +2198,7 @@ static struct drm_encoder
*drm_connector_get_encoder(struct drm_connector *conne
static bool
drm_mode_expose_to_userspace(const struct drm_display_mode *mode,
-const struct list_head *export_list,
+const struct list_head *modes,
const struct drm_file *file_priv)
{
/*
@@ -2214,15 +2214,17 @@ drm_mode_expose_to_userspace(const struct
drm_display_mode *mode,
* while preparing the list of user-modes.
*/
if (!file_priv->aspect_ratio_allowed) {
- struct drm_display_mode *mode_itr;
+ const struct drm_display_mode *mode_itr;
- list_for_each_entry(mode_itr, export_list, export_head)
- if (drm_mode_match(mode_itr, mode,
+ list_for_each_entry(mode_itr, modes, head) {
+ if (mode_itr->expose_to_userspace &&
+ drm_mode_match(mode_itr, mode,
DRM_MODE_MATCH_TIMINGS |
DRM_MODE_MATCH_CLOCK |
DRM_MODE_MATCH_FLAGS |
DRM_MODE_MATCH_3D_FLAGS))
return false;
+ }
}
return true;
@@ -2242,7 +2244,6 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
struct drm_mode_modeinfo u_mode;
struct drm_mode_modeinfo __user *mode_ptr;
uint32_t __user *encoder_ptr;
- LIST_HEAD(export_list);
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EOPNOTSUPP;
@@ -2286,25 +2287,30 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
out_resp->connection = connector->status;
/* delayed so we get modes regardless of pre-fill_modes state */
- list_for_each_entry(mode, >modes, head)
- if (drm_mode_expose_to_userspace(mode, _list,
+ list_for_each_entry(mode, >modes, head) {
+ WARN_ON(mode->expose_to_userspace);
+
+ if (drm_mode_expose_to_userspace(mode, >modes,
file_priv)) {
- list_add_tail(>export_head, _list);
+ mode->expose_to_userspace = true;
mode_count++;
}
+ }
/*
* This ioctl is called twice, once to determine how much space is
* needed, and the 2nd time to fill it.
-* The modes that need to be exposed to the user are maintained in the
-* 'export_list'. When the ioctl is called first time to determine the,
-* space, the export_list gets filled, to find the no.of modes. In the
-* 2nd time, the user modes are filled, one by one from the export_list.
*/
if ((out_resp->count_modes >= mode_count) && mode_count) {
copied = 0;
mode_ptr = (struct drm_mode_modeinfo __user *)(unsigned
long)out_resp->modes_ptr;
- list_for_each_entry(mode, _list, export_head) {
+
[Intel-gfx] [PATCH v2 16/17] drm: Nuke mode->private_flags
From: Ville Syrjälä
The last two uses of mode->private_flags (in i915 and gma500)
are now gone. So let's remove mode->private_flags entirely.
CC: Sam Ravnborg
Cc: Daniel Vetter
Cc: Emil Velikov
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 47d62b9d8d20..1e97138a9b8c 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -348,16 +348,6 @@ struct drm_display_mode {
*/
u8 type;
- /**
-* @private_flags:
-*
-* Driver private flags. private_flags can only be used for mode
-* objects passed to drivers in modeset operations. It shouldn't be used
-* by atomic drivers since they can store any additional data by
-* subclassing state structures.
-*/
- u8 private_flags;
-
/**
* @head:
*
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 14/17] drm/i915: Replace I915_MODE_FLAG_INHERITED with a boolean
From: Ville Syrjälä
There's no reason for I915_MODE_FLAG_INHERITED to exist as a flag
anymore. Just make it a boolean.
CC: Sam Ravnborg
Cc: Daniel Vetter
Cc: Emil Velikov
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.c | 15 ++-
.../gpu/drm/i915/display/intel_display_types.h| 2 +-
3 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 5863e339a426..2deafaa9ec74 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -249,10 +249,10 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
crtc_state->update_wm_post = false;
crtc_state->fifo_changed = false;
crtc_state->preload_luts = false;
+ crtc_state->inherited = false;
crtc_state->wm.need_postvbl_update = false;
crtc_state->fb_bits = 0;
crtc_state->update_planes = 0;
- crtc_state->mode_flags &= ~I915_MODE_FLAG_INHERITED;
return _state->uapi;
}
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index d88cade45c35..550369444811 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6413,8 +6413,7 @@ static bool hsw_post_update_enable_ips(const struct
intel_crtc_state *old_crtc_s
* We can't read out IPS on broadwell, assume the worst and
* forcibly enable IPS on the first fastset.
*/
- if (new_crtc_state->update_pipe &&
- old_crtc_state->mode_flags & I915_MODE_FLAG_INHERITED)
+ if (new_crtc_state->update_pipe && old_crtc_state->inherited)
return true;
return !old_crtc_state->ips_enabled;
@@ -13516,8 +13515,7 @@ intel_pipe_config_compare(const struct intel_crtc_state
*current_config,
bool ret = true;
u32 bp_gamma = 0;
bool fixup_inherited = fastset &&
- (current_config->mode_flags & I915_MODE_FLAG_INHERITED) &&
- !(pipe_config->mode_flags & I915_MODE_FLAG_INHERITED);
+ current_config->inherited && !pipe_config->inherited;
if (fixup_inherited && !fastboot_enabled(dev_priv)) {
drm_dbg_kms(_priv->drm,
@@ -14667,10 +14665,9 @@ static int intel_atomic_check(struct drm_device *dev,
int ret, i;
bool any_ms = false;
- /* Catch I915_MODE_FLAG_INHERITED */
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
- if (new_crtc_state->mode_flags != old_crtc_state->mode_flags)
+ if (new_crtc_state->inherited != old_crtc_state->inherited)
new_crtc_state->uapi.mode_changed = true;
}
@@ -15016,7 +15013,7 @@ static void intel_update_crtc(struct intel_atomic_state
*state,
* of enabling them on the CRTC's first fastset.
*/
if (new_crtc_state->update_pipe && !modeset &&
- old_crtc_state->mode_flags & I915_MODE_FLAG_INHERITED)
+ old_crtc_state->inherited)
intel_crtc_arm_fifo_underrun(crtc, new_crtc_state);
}
@@ -17494,7 +17491,7 @@ static int intel_initial_commit(struct drm_device *dev)
* happen only for the first real commit from userspace.
* So preserve the inherited flag for the time being.
*/
- crtc_state->mode_flags |= I915_MODE_FLAG_INHERITED;
+ crtc_state->inherited = true;
ret = drm_atomic_add_affected_planes(state,
>base);
if (ret)
@@ -18266,7 +18263,7 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
* set a flag to indicate that a full recalculation is
* needed on the next commit.
*/
- crtc_state->mode_flags |= I915_MODE_FLAG_INHERITED;
+ crtc_state->inherited = true;
intel_crtc_compute_pixel_rate(crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 26df856f8b72..f529b14fbb2a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -642,7 +642,6 @@ struct intel_crtc_scaler_state {
};
/* {crtc,crtc_state}->mode_flags */
-#define I915_MODE_FLAG_INHERITED (1<<0)
/* Flag to get scanline using frame time stamps */
#define I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP (1<<1)
/* Flag to use the scanline counter instead of the pixel counter */
@@ -837,6 +836,7 @@ struct intel_crtc_state {
bool update_wm_pre, update_wm_post; /*
[Intel-gfx] [PATCH v2 10/17] drm: Shrink mode->private_flags
From: Ville Syrjälä
gma500 needs 4 bits (to store a pixel multiplier) in the
mode->private_flags, i915 currently has three bits defined.
No one else uses this. Reduce the size to u8.
Reviewed-by: Emil Velikov
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 917527eb8067..95c23f86ae0c 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -378,7 +378,7 @@ struct drm_display_mode {
* by atomic drivers since they can store any additional data by
* subclassing state structures.
*/
- int private_flags;
+ u8 private_flags;
/**
* @picture_aspect_ratio:
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 13/17] drm/i915: Stop using mode->private_flags
From: Ville Syrjälä
Replace the use of mode->private_flags with a truly private bitmaks
in our own crtc state. We also need a copy in the crtc itself so the
vblank code can get at it. We already have scanline_offset in there
for a similar reason, as well as the vblank->hwmode which is assigned
via drm_calc_timestamping_constants(). Fortunately we now have a
nice place for doing the crtc_state->crtc copy in
intel_crtc_update_active_timings() which gets called both for
modesets and init/resume readout.
The one slightly iffy spot is the INHERITED flag which we want to
preserve until userspace/fb_helper does the first proper commit after
actually calling .detecti() on the connectors. Otherwise we don't have
the full sink capabilities (audio,infoframes,etc.) when .compute_config()
gets called and thus we will fail to enable those features when the
first userspace commit happens. The only internal commit we do prior to
that should be from intel_initial_commit() and there we can simply
preserve the INHERITED flag from the readout.
CC: Sam Ravnborg
Cc: Daniel Vetter
Cc: Emil Velikov
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/icl_dsi.c| 13 --
drivers/gpu/drm/i915/display/intel_atomic.c | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 24 +--
.../drm/i915/display/intel_display_types.h| 9 ++-
drivers/gpu/drm/i915/display/intel_tv.c | 4 ++--
drivers/gpu/drm/i915/display/vlv_dsi.c| 6 ++---
drivers/gpu/drm/i915/i915_irq.c | 4 ++--
7 files changed, 37 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 99a25c0bb08f..4d6788ef2e5e 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1469,8 +1469,7 @@ static void gen11_dsi_get_config(struct intel_encoder
*encoder,
pipe_config->pipe_bpp = bdw_get_pipemisc_bpp(crtc);
if (gen11_dsi_is_periodic_cmd_mode(intel_dsi))
- pipe_config->hw.adjusted_mode.private_flags |=
- I915_MODE_FLAG_DSI_PERIODIC_CMD_MODE;
+ pipe_config->mode_flags |= I915_MODE_FLAG_DSI_PERIODIC_CMD_MODE;
}
static int gen11_dsi_dsc_compute_config(struct intel_encoder *encoder,
@@ -1555,10 +1554,6 @@ static int gen11_dsi_compute_config(struct intel_encoder
*encoder,
pipe_config->port_clock = afe_clk(encoder, pipe_config) / 5;
- /* We would not operate in periodic command mode */
- pipe_config->hw.adjusted_mode.private_flags &=
- ~I915_MODE_FLAG_DSI_PERIODIC_CMD_MODE;
-
/*
* In case of TE GATE cmd mode, we
* receive TE from the slave if
@@ -1566,14 +1561,14 @@ static int gen11_dsi_compute_config(struct
intel_encoder *encoder,
*/
if (is_cmd_mode(intel_dsi)) {
if (intel_dsi->ports == (BIT(PORT_B) | BIT(PORT_A)))
- pipe_config->hw.adjusted_mode.private_flags |=
+ pipe_config->mode_flags |=
I915_MODE_FLAG_DSI_USE_TE1 |
I915_MODE_FLAG_DSI_USE_TE0;
else if (intel_dsi->ports == BIT(PORT_B))
- pipe_config->hw.adjusted_mode.private_flags |=
+ pipe_config->mode_flags |=
I915_MODE_FLAG_DSI_USE_TE1;
else
- pipe_config->hw.adjusted_mode.private_flags |=
+ pipe_config->mode_flags |=
I915_MODE_FLAG_DSI_USE_TE0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index d043057d2fa0..5863e339a426 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -252,6 +252,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
crtc_state->wm.need_postvbl_update = false;
crtc_state->fb_bits = 0;
crtc_state->update_planes = 0;
+ crtc_state->mode_flags &= ~I915_MODE_FLAG_INHERITED;
return _state->uapi;
}
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index bcb5d754f20d..d88cade45c35 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6414,7 +6414,7 @@ static bool hsw_post_update_enable_ips(const struct
intel_crtc_state *old_crtc_s
* forcibly enable IPS on the first fastset.
*/
if (new_crtc_state->update_pipe &&
- old_crtc_state->hw.adjusted_mode.private_flags &
I915_MODE_FLAG_INHERITED)
+ old_crtc_state->mode_flags & I915_MODE_FLAG_INHERITED)
return true;
return !old_crtc_state->ips_enabled;
@@ -13516,8
[Intel-gfx] [PATCH v2 15/17] drm/gma500: Stop using mode->private_flags
From: Ville Syrjälä
gma500 only uses mode->private_flags to convey the sdvo pixel
multiplier from the encoder .mode_fixup() hook to the encoder
.mode_set() hook. Those always seems get called as a pair so
let's just stuff the pixel multiplier into the encoder itself
as there are no state objects we could use in this non-atomic
driver.
Paves the way for nuking mode->private_flag.
Cc: Patrik Jakobsson
CC: Sam Ravnborg
Cc: Daniel Vetter
Cc: Emil Velikov
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/gma500/psb_intel_drv.h | 19 ---
drivers/gpu/drm/gma500/psb_intel_sdvo.c | 11 ++-
2 files changed, 6 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_intel_drv.h
b/drivers/gpu/drm/gma500/psb_intel_drv.h
index fb601983cef0..3dd5718c3e31 100644
--- a/drivers/gpu/drm/gma500/psb_intel_drv.h
+++ b/drivers/gpu/drm/gma500/psb_intel_drv.h
@@ -56,25 +56,6 @@
#define INTEL_OUTPUT_DISPLAYPORT 9
#define INTEL_OUTPUT_EDP 10
-#define INTEL_MODE_PIXEL_MULTIPLIER_SHIFT (0x0)
-#define INTEL_MODE_PIXEL_MULTIPLIER_MASK (0xf <<
INTEL_MODE_PIXEL_MULTIPLIER_SHIFT)
-
-static inline void
-psb_intel_mode_set_pixel_multiplier(struct drm_display_mode *mode,
- int multiplier)
-{
- mode->clock *= multiplier;
- mode->private_flags |= multiplier;
-}
-
-static inline int
-psb_intel_mode_get_pixel_multiplier(const struct drm_display_mode *mode)
-{
- return (mode->private_flags & INTEL_MODE_PIXEL_MULTIPLIER_MASK)
- >> INTEL_MODE_PIXEL_MULTIPLIER_SHIFT;
-}
-
-
/*
* Hold information useally put on the device driver privates here,
* since it needs to be shared across multiple of devices drivers privates.
diff --git a/drivers/gpu/drm/gma500/psb_intel_sdvo.c
b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
index 264d7ad004b4..9e88a37f55e9 100644
--- a/drivers/gpu/drm/gma500/psb_intel_sdvo.c
+++ b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
@@ -132,6 +132,8 @@ struct psb_intel_sdvo {
/* DDC bus used by this SDVO encoder */
uint8_t ddc_bus;
+ u8 pixel_multiplier;
+
/* Input timings for adjusted_mode */
struct psb_intel_sdvo_dtd input_dtd;
@@ -958,7 +960,6 @@ static bool psb_intel_sdvo_mode_fixup(struct drm_encoder
*encoder,
struct drm_display_mode *adjusted_mode)
{
struct psb_intel_sdvo *psb_intel_sdvo = to_psb_intel_sdvo(encoder);
- int multiplier;
/* We need to construct preferred input timings based on our
* output timings. To do that, we have to set the output
@@ -985,8 +986,9 @@ static bool psb_intel_sdvo_mode_fixup(struct drm_encoder
*encoder,
/* Make the CRTC code factor in the SDVO pixel multiplier. The
* SDVO device will factor out the multiplier during mode_set.
*/
- multiplier = psb_intel_sdvo_get_pixel_multiplier(adjusted_mode);
- psb_intel_mode_set_pixel_multiplier(adjusted_mode, multiplier);
+ psb_intel_sdvo->pixel_multiplier =
+ psb_intel_sdvo_get_pixel_multiplier(adjusted_mode);
+ adjusted_mode->clock *= psb_intel_sdvo->pixel_multiplier;
return true;
}
@@ -1002,7 +1004,6 @@ static void psb_intel_sdvo_mode_set(struct drm_encoder
*encoder,
u32 sdvox;
struct psb_intel_sdvo_in_out_map in_out;
struct psb_intel_sdvo_dtd input_dtd;
- int pixel_multiplier =
psb_intel_mode_get_pixel_multiplier(adjusted_mode);
int rate;
int need_aux = IS_MRST(dev) ? 1 : 0;
@@ -1060,7 +1061,7 @@ static void psb_intel_sdvo_mode_set(struct drm_encoder
*encoder,
(void) psb_intel_sdvo_set_input_timing(psb_intel_sdvo, _dtd);
- switch (pixel_multiplier) {
+ switch (psb_intel_sdvo->pixel_multiplier) {
default:
case 1: rate = SDVO_CLOCK_RATE_MULT_1X; break;
case 2: rate = SDVO_CLOCK_RATE_MULT_2X; break;
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 08/17] drm: Shrink drm_display_mode timings
From: Ville Syrjälä
Store the timings (apart from the clock) as u16. The uapi mode
struct already uses u16 for everything so using something bigger
internally doesn't really help us.
Reviewed-by: Emil Velikov
Reviewed-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 7 --
include/drm/drm_modes.h | 46 ++---
2 files changed, 23 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index e3d5f011f7bd..77d68120931a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1901,13 +1901,6 @@ EXPORT_SYMBOL(drm_mode_create_from_cmdline_mode);
void drm_mode_convert_to_umode(struct drm_mode_modeinfo *out,
const struct drm_display_mode *in)
{
- WARN(in->hdisplay > USHRT_MAX || in->hsync_start > USHRT_MAX ||
-in->hsync_end > USHRT_MAX || in->htotal > USHRT_MAX ||
-in->hskew > USHRT_MAX || in->vdisplay > USHRT_MAX ||
-in->vsync_start > USHRT_MAX || in->vsync_end > USHRT_MAX ||
-in->vtotal > USHRT_MAX || in->vscan > USHRT_MAX,
-"timing values too large for mode info\n");
-
out->clock = in->clock;
out->hdisplay = in->hdisplay;
out->hsync_start = in->hsync_start;
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index da7db74a215e..917527eb8067 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -278,16 +278,16 @@ struct drm_display_mode {
* Pixel clock in kHz.
*/
int clock; /* in kHz */
- int hdisplay;
- int hsync_start;
- int hsync_end;
- int htotal;
- int hskew;
- int vdisplay;
- int vsync_start;
- int vsync_end;
- int vtotal;
- int vscan;
+ u16 hdisplay;
+ u16 hsync_start;
+ u16 hsync_end;
+ u16 htotal;
+ u16 hskew;
+ u16 vdisplay;
+ u16 vsync_start;
+ u16 vsync_end;
+ u16 vtotal;
+ u16 vscan;
/**
* @flags:
*
@@ -356,19 +356,19 @@ struct drm_display_mode {
* difference is exactly a factor of 10.
*/
int crtc_clock;
- int crtc_hdisplay;
- int crtc_hblank_start;
- int crtc_hblank_end;
- int crtc_hsync_start;
- int crtc_hsync_end;
- int crtc_htotal;
- int crtc_hskew;
- int crtc_vdisplay;
- int crtc_vblank_start;
- int crtc_vblank_end;
- int crtc_vsync_start;
- int crtc_vsync_end;
- int crtc_vtotal;
+ u16 crtc_hdisplay;
+ u16 crtc_hblank_start;
+ u16 crtc_hblank_end;
+ u16 crtc_hsync_start;
+ u16 crtc_hsync_end;
+ u16 crtc_htotal;
+ u16 crtc_hskew;
+ u16 crtc_vdisplay;
+ u16 crtc_vblank_start;
+ u16 crtc_vblank_end;
+ u16 crtc_vsync_start;
+ u16 crtc_vsync_end;
+ u16 crtc_vtotal;
/**
* @private_flags:
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 07/17] drm: Make mode->flags u32
From: Ville Syrjälä
The mode flags are direclty exposed in the uapi as u32. Use the
same size type to store them internally.
Reviewed-by: Emil Velikov
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index f4507b987038..da7db74a215e 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -322,7 +322,7 @@ struct drm_display_mode {
* - DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF: frame split into left and
*right parts.
*/
- unsigned int flags;
+ u32 flags;
/**
* @width_mm:
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 02/17] drm/i915: Introduce some local intel_dp variables
From: Ville Syrjälä
The drrs code dereferences mode->vrefresh via some really long chain
of structures/pointers. Couldn't get coccinelle to see through all
that so let's add some local variables to help it.
Reviewed-by: Emil Velikov
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index db6ae8e9af6e..ffc2816787db 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -7721,6 +7721,7 @@ static void intel_edp_drrs_downclock_work(struct
work_struct *work)
void intel_edp_drrs_invalidate(struct drm_i915_private *dev_priv,
unsigned int frontbuffer_bits)
{
+ struct intel_dp *intel_dp;
struct drm_crtc *crtc;
enum pipe pipe;
@@ -7730,12 +7731,14 @@ void intel_edp_drrs_invalidate(struct drm_i915_private
*dev_priv,
cancel_delayed_work(_priv->drrs.work);
mutex_lock(_priv->drrs.mutex);
- if (!dev_priv->drrs.dp) {
+
+ intel_dp = dev_priv->drrs.dp;
+ if (!intel_dp) {
mutex_unlock(_priv->drrs.mutex);
return;
}
- crtc = dp_to_dig_port(dev_priv->drrs.dp)->base.base.crtc;
+ crtc = dp_to_dig_port(intel_dp)->base.base.crtc;
pipe = to_intel_crtc(crtc)->pipe;
frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);
@@ -7744,7 +7747,7 @@ void intel_edp_drrs_invalidate(struct drm_i915_private
*dev_priv,
/* invalidate means busy screen hence upclock */
if (frontbuffer_bits && dev_priv->drrs.refresh_rate_type == DRRS_LOW_RR)
intel_dp_set_drrs_state(dev_priv, to_intel_crtc(crtc)->config,
-
dev_priv->drrs.dp->attached_connector->panel.fixed_mode->vrefresh);
+
intel_dp->attached_connector->panel.fixed_mode->vrefresh);
mutex_unlock(_priv->drrs.mutex);
}
@@ -7764,6 +7767,7 @@ void intel_edp_drrs_invalidate(struct drm_i915_private
*dev_priv,
void intel_edp_drrs_flush(struct drm_i915_private *dev_priv,
unsigned int frontbuffer_bits)
{
+ struct intel_dp *intel_dp;
struct drm_crtc *crtc;
enum pipe pipe;
@@ -7773,12 +,14 @@ void intel_edp_drrs_flush(struct drm_i915_private
*dev_priv,
cancel_delayed_work(_priv->drrs.work);
mutex_lock(_priv->drrs.mutex);
- if (!dev_priv->drrs.dp) {
+
+ intel_dp = dev_priv->drrs.dp;
+ if (!intel_dp) {
mutex_unlock(_priv->drrs.mutex);
return;
}
- crtc = dp_to_dig_port(dev_priv->drrs.dp)->base.base.crtc;
+ crtc = dp_to_dig_port(intel_dp)->base.base.crtc;
pipe = to_intel_crtc(crtc)->pipe;
frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);
@@ -7787,7 +7793,7 @@ void intel_edp_drrs_flush(struct drm_i915_private
*dev_priv,
/* flush means busy screen hence upclock */
if (frontbuffer_bits && dev_priv->drrs.refresh_rate_type == DRRS_LOW_RR)
intel_dp_set_drrs_state(dev_priv, to_intel_crtc(crtc)->config,
-
dev_priv->drrs.dp->attached_connector->panel.fixed_mode->vrefresh);
+
intel_dp->attached_connector->panel.fixed_mode->vrefresh);
/*
* flush also means no more activity hence schedule downclock, if all
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 09/17] drm: Flatten drm_mode_vrefresh()
From: Ville Syrjälä
Remove the pointless whole-function indentation. Also don't
need to worry about negative values anymore since we switched
everything to u16.
Reviewed-by: Emil Velikov
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 77d68120931a..f2865f88bd54 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -757,24 +757,22 @@ EXPORT_SYMBOL(drm_mode_set_name);
*/
int drm_mode_vrefresh(const struct drm_display_mode *mode)
{
- int refresh = 0;
+ unsigned int num, den;
- if (mode->htotal > 0 && mode->vtotal > 0) {
- unsigned int num, den;
+ if (mode->htotal == 0 || mode->vtotal == 0)
+ return 0;
- num = mode->clock * 1000;
- den = mode->htotal * mode->vtotal;
+ num = mode->clock * 1000;
+ den = mode->htotal * mode->vtotal;
- if (mode->flags & DRM_MODE_FLAG_INTERLACE)
- num *= 2;
- if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
- den *= 2;
- if (mode->vscan > 1)
- den *= mode->vscan;
+ if (mode->flags & DRM_MODE_FLAG_INTERLACE)
+ num *= 2;
+ if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
+ den *= 2;
+ if (mode->vscan > 1)
+ den *= mode->vscan;
- refresh = DIV_ROUND_CLOSEST(num, den);
- }
- return refresh;
+ return DIV_ROUND_CLOSEST(num, den);
}
EXPORT_SYMBOL(drm_mode_vrefresh);
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 11/17] drm: pahole struct drm_display_mode
From: Ville Syrjälä
Reorganize drm_display_mode to eliminate all the holes.
We'll put all the actual timings to the start of the
struct and all the extra junk to the end.
Gets the size down to 136 bytes on 64bit and 120 bytes on
32bit. With a bit more work we should be able to get this
below the two cacheline mark even on 64bit.
Reviewed-by: Emil Velikov
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 139
1 file changed, 70 insertions(+), 69 deletions(-)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 95c23f86ae0c..47d62b9d8d20 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -222,56 +222,6 @@ enum drm_mode_status {
* For printing you can use %DRM_MODE_FMT and DRM_MODE_ARG().
*/
struct drm_display_mode {
- /**
-* @head:
-*
-* struct list_head for mode lists.
-*/
- struct list_head head;
-
- /**
-* @name:
-*
-* Human-readable name of the mode, filled out with drm_mode_set_name().
-*/
- char name[DRM_DISPLAY_MODE_LEN];
-
- /**
-* @status:
-*
-* Status of the mode, used to filter out modes not supported by the
-* hardware. See enum _mode_status.
-*/
- enum drm_mode_status status;
-
- /**
-* @type:
-*
-* A bitmask of flags, mostly about the source of a mode. Possible flags
-* are:
-*
-* - DRM_MODE_TYPE_PREFERRED: Preferred mode, usually the native
-*resolution of an LCD panel. There should only be one preferred
-*mode per connector at any given time.
-* - DRM_MODE_TYPE_DRIVER: Mode created by the driver, which is all of
-*them really. Drivers must set this bit for all modes they create
-*and expose to userspace.
-* - DRM_MODE_TYPE_USERDEF: Mode defined via kernel command line
-*
-* Plus a big list of flags which shouldn't be used at all, but are
-* still around since these flags are also used in the userspace ABI.
-* We no longer accept modes with these types though:
-*
-* - DRM_MODE_TYPE_BUILTIN: Meant for hard-coded modes, unused.
-*Use DRM_MODE_TYPE_DRIVER instead.
-* - DRM_MODE_TYPE_DEFAULT: Again a leftover, use
-*DRM_MODE_TYPE_PREFERRED instead.
-* - DRM_MODE_TYPE_CLOCK_C and DRM_MODE_TYPE_CRTC_C: Define leftovers
-*which are stuck around for hysterical raisins only. No one has an
-*idea what they were meant for. Don't use.
-*/
- u8 type;
-
/**
* @clock:
*
@@ -324,22 +274,6 @@ struct drm_display_mode {
*/
u32 flags;
- /**
-* @width_mm:
-*
-* Addressable size of the output in mm, projectors should set this to
-* 0.
-*/
- u16 width_mm;
-
- /**
-* @height_mm:
-*
-* Addressable size of the output in mm, projectors should set this to
-* 0.
-*/
- u16 height_mm;
-
/**
* @crtc_clock:
*
@@ -370,6 +304,50 @@ struct drm_display_mode {
u16 crtc_vsync_end;
u16 crtc_vtotal;
+ /**
+* @width_mm:
+*
+* Addressable size of the output in mm, projectors should set this to
+* 0.
+*/
+ u16 width_mm;
+
+ /**
+* @height_mm:
+*
+* Addressable size of the output in mm, projectors should set this to
+* 0.
+*/
+ u16 height_mm;
+
+ /**
+* @type:
+*
+* A bitmask of flags, mostly about the source of a mode. Possible flags
+* are:
+*
+* - DRM_MODE_TYPE_PREFERRED: Preferred mode, usually the native
+*resolution of an LCD panel. There should only be one preferred
+*mode per connector at any given time.
+* - DRM_MODE_TYPE_DRIVER: Mode created by the driver, which is all of
+*them really. Drivers must set this bit for all modes they create
+*and expose to userspace.
+* - DRM_MODE_TYPE_USERDEF: Mode defined via kernel command line
+*
+* Plus a big list of flags which shouldn't be used at all, but are
+* still around since these flags are also used in the userspace ABI.
+* We no longer accept modes with these types though:
+*
+* - DRM_MODE_TYPE_BUILTIN: Meant for hard-coded modes, unused.
+*Use DRM_MODE_TYPE_DRIVER instead.
+* - DRM_MODE_TYPE_DEFAULT: Again a leftover, use
+*DRM_MODE_TYPE_PREFERRED instead.
+* - DRM_MODE_TYPE_CLOCK_C and DRM_MODE_TYPE_CRTC_C: Define leftovers
+*which are stuck around for hysterical raisins only. No one has an
+*idea what they were meant for. Don't use.
+*/
+ u8 type;
+
/**
[Intel-gfx] [PATCH v2 06/17] drm: Shrink mode->type to u8
From: Ville Syrjälä
We only have 7 bits defined for mode->type. Shrink the storage to u8.
Reviewed-by: Emil Velikov
Reviewed-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 3625e3681488..f4507b987038 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -270,7 +270,7 @@ struct drm_display_mode {
*which are stuck around for hysterical raisins only. No one has an
*idea what they were meant for. Don't use.
*/
- unsigned int type;
+ u8 type;
/**
* @clock:
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 04/17] drm/msm/dpu: Stop copying around mode->private_flags
From: Ville Syrjälä
The driver never sets mode->private_flags so copying
it back and forth is entirely pointless. Stop doing it.
Also drop private_flags from the tracepoint.
Cc: Rob Clark
Cc: Sean Paul
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Reviewed-by: Emil Velikov
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 29 +
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 10 +++
2 files changed, 5 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index a1b79ee2bd9d..d22ecabebb08 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -498,23 +498,6 @@ void dpu_encoder_helper_split_config(
}
}
-static void _dpu_encoder_adjust_mode(struct drm_connector *connector,
- struct drm_display_mode *adj_mode)
-{
- struct drm_display_mode *cur_mode;
-
- if (!connector || !adj_mode)
- return;
-
- list_for_each_entry(cur_mode, >modes, head) {
- if (cur_mode->vdisplay == adj_mode->vdisplay &&
- cur_mode->hdisplay == adj_mode->hdisplay &&
- drm_mode_vrefresh(cur_mode) == drm_mode_vrefresh(adj_mode))
{
- adj_mode->private_flags |= cur_mode->private_flags;
- }
- }
-}
-
static struct msm_display_topology dpu_encoder_get_topology(
struct dpu_encoder_virt *dpu_enc,
struct dpu_kms *dpu_kms,
@@ -580,15 +563,6 @@ static int dpu_encoder_virt_atomic_check(
global_state = dpu_kms_get_existing_global_state(dpu_kms);
trace_dpu_enc_atomic_check(DRMID(drm_enc));
- /*
-* display drivers may populate private fields of the drm display mode
-* structure while registering possible modes of a connector with DRM.
-* These private fields are not populated back while DRM invokes
-* the mode_set callbacks. This module retrieves and populates the
-* private fields of the given mode.
-*/
- _dpu_encoder_adjust_mode(conn_state->connector, adj_mode);
-
/* perform atomic check on the first physical encoder (master) */
for (i = 0; i < dpu_enc->num_phys_encs; i++) {
struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
@@ -621,8 +595,7 @@ static int dpu_encoder_virt_atomic_check(
}
}
- trace_dpu_enc_atomic_check_flags(DRMID(drm_enc), adj_mode->flags,
- adj_mode->private_flags);
+ trace_dpu_enc_atomic_check_flags(DRMID(drm_enc), adj_mode->flags);
return ret;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
index eecfe9b3199e..6714b088970f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
@@ -327,20 +327,18 @@ DEFINE_EVENT(dpu_enc_keyval_template,
dpu_enc_trigger_start,
);
TRACE_EVENT(dpu_enc_atomic_check_flags,
- TP_PROTO(uint32_t drm_id, unsigned int flags, int private_flags),
- TP_ARGS(drm_id, flags, private_flags),
+ TP_PROTO(uint32_t drm_id, unsigned int flags),
+ TP_ARGS(drm_id, flags),
TP_STRUCT__entry(
__field(uint32_t, drm_id )
__field(unsigned int, flags )
- __field(int,private_flags )
),
TP_fast_assign(
__entry->drm_id = drm_id;
__entry->flags = flags;
- __entry->private_flags = private_flags;
),
- TP_printk("id=%u, flags=%u, private_flags=%d",
- __entry->drm_id, __entry->flags, __entry->private_flags)
+ TP_printk("id=%u, flags=%u",
+ __entry->drm_id, __entry->flags)
);
DECLARE_EVENT_CLASS(dpu_enc_id_enable_template,
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 05/17] drm: Shrink {width,height}_mm to u16
From: Ville Syrjälä
Instead of supporting ~2000km wide displayes let's limit ourselves
to ~65m. That seems plenty big enough to me.
Even with EDID_QUIRK_DETAILED_IN_CM EDIDs seem to be limited to
10*0xfff which fits into the 16 bits.
Reviewed-by: Emil Velikov
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 8b05f3705d0e..3625e3681488 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -330,7 +330,7 @@ struct drm_display_mode {
* Addressable size of the output in mm, projectors should set this to
* 0.
*/
- int width_mm;
+ u16 width_mm;
/**
* @height_mm:
@@ -338,7 +338,7 @@ struct drm_display_mode {
* Addressable size of the output in mm, projectors should set this to
* 0.
*/
- int height_mm;
+ u16 height_mm;
/**
* @crtc_clock:
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 12/17] drm/mcde: Use mode->clock instead of reverse calculating it from the vrefresh
From: Ville Syrjälä htotal*vtotal*vrefresh ~= clock. So just say "clock" when we mean it. Cc: Linus Walleij Cc: Sam Ravnborg Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/mcde/mcde_dsi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c index 52031d826f2c..c07a8e273b6f 100644 --- a/drivers/gpu/drm/mcde/mcde_dsi.c +++ b/drivers/gpu/drm/mcde/mcde_dsi.c @@ -537,8 +537,7 @@ static void mcde_dsi_setup_video_mode(struct mcde_dsi *d, * porches and sync. */ /* (ps/s) / (pixels/s) = ps/pixels */ - pclk = DIV_ROUND_UP_ULL(1, - (drm_mode_vrefresh(mode) * mode->htotal * mode->vtotal)); + pclk = DIV_ROUND_UP_ULL(1, mode->clock); dev_dbg(d->dev, "picoseconds between two pixels: %llu\n", pclk); -- 2.24.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 01/17] drm: Nuke mode->hsync
From: Ville Syrjälä
Let's just calculate the hsync rate on demand. No point in wasting
space storing it and risking the cached value getting out of sync
with reality.
v2: Move drm_mode_hsync() next to its only users
Drop the TODO
Reviewed-by: Emil Velikov #v1
Signed-off-by: Ville Syrjälä
---
Documentation/gpu/todo.rst | 12 -
drivers/gpu/drm/drm_edid.c | 8 ++
drivers/gpu/drm/drm_modes.c | 26
drivers/gpu/drm/i915/display/intel_display.c | 1 -
include/drm/drm_modes.h | 11 -
5 files changed, 8 insertions(+), 50 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 439656f55c5d..658b52f7ffc6 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -347,18 +347,6 @@ Contact: Sean Paul
Level: Starter
-Remove drm_display_mode.hsync
--
-
-We have drm_mode_hsync() to calculate this from hsync_start/end, since drivers
-shouldn't/don't use this, remove this member to avoid any temptations to use it
-in the future. If there is any debug code using drm_display_mode.hsync, convert
-it to use drm_mode_hsync() instead.
-
-Contact: Sean Paul
-
-Level: Starter
-
connector register/unregister fixes
---
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 43b6ca364daa..3bd95c4b02eb 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2380,6 +2380,14 @@ bad_std_timing(u8 a, u8 b)
(a == 0x20 && b == 0x20);
}
+static int drm_mode_hsync(const struct drm_display_mode *mode)
+{
+ if (mode->htotal <= 0)
+ return 0;
+
+ return DIV_ROUND_CLOSEST(mode->clock, mode->htotal);
+}
+
/**
* drm_mode_std - convert standard mode info (width, height, refresh) into mode
* @connector: connector of for the EDID block
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index d4d64518e11b..fec1c33b3045 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -747,32 +747,6 @@ void drm_mode_set_name(struct drm_display_mode *mode)
}
EXPORT_SYMBOL(drm_mode_set_name);
-/**
- * drm_mode_hsync - get the hsync of a mode
- * @mode: mode
- *
- * Returns:
- * @modes's hsync rate in kHz, rounded to the nearest integer. Calculates the
- * value first if it is not yet set.
- */
-int drm_mode_hsync(const struct drm_display_mode *mode)
-{
- unsigned int calc_val;
-
- if (mode->hsync)
- return mode->hsync;
-
- if (mode->htotal <= 0)
- return 0;
-
- calc_val = (mode->clock * 1000) / mode->htotal; /* hsync in Hz */
- calc_val += 500;/* round to 1000Hz */
- calc_val /= 1000; /* truncate to kHz */
-
- return calc_val;
-}
-EXPORT_SYMBOL(drm_mode_hsync);
-
/**
* drm_mode_vrefresh - get the vrefresh of a mode
* @mode: mode
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 70ec301fe6e3..5ebb2df5f1f4 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8870,7 +8870,6 @@ void intel_mode_from_pipe_config(struct drm_display_mode
*mode,
mode->clock = pipe_config->hw.adjusted_mode.crtc_clock;
- mode->hsync = drm_mode_hsync(mode);
mode->vrefresh = drm_mode_vrefresh(mode);
drm_mode_set_name(mode);
}
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 99134d4f35eb..730fc31de4fb 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -390,16 +390,6 @@ struct drm_display_mode {
*/
int vrefresh;
- /**
-* @hsync:
-*
-* Horizontal refresh rate, for debug output in human readable form. Not
-* used in a functional way.
-*
-* This value is in kHz.
-*/
- int hsync;
-
/**
* @picture_aspect_ratio:
*
@@ -493,7 +483,6 @@ int of_get_drm_display_mode(struct device_node *np,
int index);
void drm_mode_set_name(struct drm_display_mode *mode);
-int drm_mode_hsync(const struct drm_display_mode *mode);
int drm_mode_vrefresh(const struct drm_display_mode *mode);
void drm_mode_get_hv_timing(const struct drm_display_mode *mode,
int *hdisplay, int *vdisplay);
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 00/17] drm: Put drm_display_mode on diet
From: Ville Syrjälä
Refreshed version of the mode diet.
New unseen stuff at the end:
- Nuke private_flags entirely
- Replace export_head with a bool to shrink the struct
below the magic two cachelines
I kept the intermediate "shrink private_flags to u8" step
because I didn't want to redo the pahole numbers.
Ville Syrjälä (17):
drm: Nuke mode->hsync
drm/i915: Introduce some local intel_dp variables
drm: Nuke mode->vrefresh
drm/msm/dpu: Stop copying around mode->private_flags
drm: Shrink {width,height}_mm to u16
drm: Shrink mode->type to u8
drm: Make mode->flags u32
drm: Shrink drm_display_mode timings
drm: Flatten drm_mode_vrefresh()
drm: Shrink mode->private_flags
drm: pahole struct drm_display_mode
drm/mcde: Use mode->clock instead of reverse calculating it from the
vrefresh
drm/i915: Stop using mode->private_flags
drm/i915: Replace I915_MODE_FLAG_INHERITED with a boolean
drm/gma500: Stop using mode->private_flags
drm: Nuke mode->private_flags
drm: Replace mode->export_head with a boolean
Documentation/gpu/todo.rst| 32 --
drivers/gpu/drm/bridge/sii902x.c | 2 +-
drivers/gpu/drm/drm_client_modeset.c | 2 +-
drivers/gpu/drm/drm_connector.c | 45 ++-
drivers/gpu/drm/drm_edid.c| 336 +-
drivers/gpu/drm/drm_modes.c | 66 +---
drivers/gpu/drm/drm_probe_helper.c| 3 -
drivers/gpu/drm/exynos/exynos_hdmi.c | 5 +-
drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
drivers/gpu/drm/gma500/psb_intel_drv.h| 19 -
drivers/gpu/drm/gma500/psb_intel_sdvo.c | 11 +-
drivers/gpu/drm/i2c/ch7006_mode.c | 1 -
drivers/gpu/drm/i915/display/icl_dsi.c| 13 +-
drivers/gpu/drm/i915/display/intel_atomic.c | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 27 +-
.../drm/i915/display/intel_display_debugfs.c | 4 +-
.../drm/i915/display/intel_display_types.h| 11 +-
drivers/gpu/drm/i915/display/intel_dp.c | 24 +-
drivers/gpu/drm/i915/display/intel_tv.c | 7 +-
drivers/gpu/drm/i915/display/vlv_dsi.c| 6 +-
drivers/gpu/drm/i915/i915_irq.c | 4 +-
drivers/gpu/drm/mcde/mcde_dsi.c | 7 +-
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +-
drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
drivers/gpu/drm/meson/meson_venc_cvbs.c | 2 -
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 29 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 10 +-
drivers/gpu/drm/nouveau/nouveau_connector.c | 5 +-
drivers/gpu/drm/panel/panel-arm-versatile.c | 4 -
drivers/gpu/drm/panel/panel-boe-himax8279d.c | 3 +-
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 6 +-
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 3 +-
.../gpu/drm/panel/panel-feixin-k101-im2ba02.c | 3 +-
.../drm/panel/panel-feiyang-fy07024di26a30d.c | 3 +-
drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 7 -
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 3 +-
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 4 +-
.../gpu/drm/panel/panel-jdi-lt070me05000.c| 3 +-
.../drm/panel/panel-kingdisplay-kd097d04.c| 3 +-
.../drm/panel/panel-leadtek-ltk500hd1829.c| 3 +-
drivers/gpu/drm/panel/panel-lg-lb035q02.c | 1 -
drivers/gpu/drm/panel/panel-lg-lg4573.c | 3 +-
drivers/gpu/drm/panel/panel-nec-nl8048hl11.c | 1 -
drivers/gpu/drm/panel/panel-novatek-nt35510.c | 1 -
drivers/gpu/drm/panel/panel-novatek-nt39016.c | 1 -
.../drm/panel/panel-olimex-lcd-olinuxino.c| 1 -
.../gpu/drm/panel/panel-orisetech-otm8009a.c | 3 +-
.../drm/panel/panel-osd-osd101t2587-53ts.c| 3 +-
.../drm/panel/panel-panasonic-vvx10f034n00.c | 3 +-
.../drm/panel/panel-raspberrypi-touchscreen.c | 4 +-
drivers/gpu/drm/panel/panel-raydium-rm67191.c | 3 +-
drivers/gpu/drm/panel/panel-raydium-rm68200.c | 3 +-
.../drm/panel/panel-rocktech-jh057n00900.c| 5 +-
drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 1 -
drivers/gpu/drm/panel/panel-samsung-s6d16d0.c | 6 -
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 4 +-
.../gpu/drm/panel/panel-samsung-s6e63j0x03.c | 3 +-
drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 3 +-
.../panel/panel-samsung-s6e88a0-ams452ef01.c | 1 -
drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 3 +-
.../gpu/drm/panel/panel-sharp-lq101r1sx01.c | 3 +-
.../gpu/drm/panel/panel-sharp-ls037v7dw01.c | 1 -
.../gpu/drm/panel/panel-sharp-ls043t1le01.c | 3 +-
drivers/gpu/drm/panel/panel-simple.c | 87 +
drivers/gpu/drm/panel/panel-sitronix-st7701.c | 2 +-
.../gpu/drm/panel/panel-sitronix-st7789v.c| 3 +-
drivers/gpu/drm/panel/panel-sony-acx424akp.c | 2 -
drivers/gpu/drm/panel/panel-sony-acx565akm.c | 1 -
drivers/gpu/drm/panel/panel-tpo-td028ttec1.c | 1 -
drivers/gpu/drm/panel/panel-tpo-td043mtea1.c | 1 -
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Wait until we start timeslicing after a submit
>-Original Message-
>From: Chris Wilson
>Sent: Friday, April 3, 2020 4:34 PM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/selftests: Wait until we start
>timeslicing after a submit
>
>Quoting Ruhl, Michael J (2020-04-03 21:31:42)
>> >-Original Message-
>> >From: Intel-gfx On Behalf Of
>Chris
>> >Wilson
>> >Sent: Friday, April 3, 2020 3:02 PM
>> >To: intel-gfx@lists.freedesktop.org
>> >Cc: Chris Wilson
>> >Subject: [Intel-gfx] [PATCH] drm/i915/selftests: Wait until we start
>timeslicing
>> >after a submit
>> >
>> >If we submit, we do not start timeslicnig until we process the CS event
>>
>> s/timeslicnig/timeslicing/
>>
>> >that marks the start of the context running on HW. So in the selftest,
>> >be sure to wait until we have processed the pending events before
>> >asserting that timeslicing has begun.
>> >
>> >Signed-off-by: Chris Wilson
>> >---
>> > drivers/gpu/drm/i915/gt/selftest_lrc.c | 6 +-
>> > 1 file changed, 5 insertions(+), 1 deletion(-)
>> >
>> >diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
>> >b/drivers/gpu/drm/i915/gt/selftest_lrc.c
>> >index 985d4041d929..9e02917695b1 100644
>> >--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
>> >+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
>> >@@ -1244,7 +1244,11 @@ static int live_timeslice_queue(void *arg)
>> > if (err)
>> > goto err_rq;
>> >
>> >- intel_engine_flush_submission(engine);
>> >+ /* Wait until we ack the release_queue and start timeslicing
>> >*/
>> >+ do {
>> >+ intel_engine_flush_submission(engine);
>> >+ } while (READ_ONCE(engine->execlists.pending[0]));
>>
>> Is this guaranteed to clear? Or should there be a count to protect against
>> the endless loop?
>
>Yes. If the HW stops, we reset it and clear the submission queue.
In that case:
Acked-by: Michael J. Ruhl
M
>-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Wait until we start timeslicing after a submit
Quoting Ruhl, Michael J (2020-04-03 21:31:42)
> >-Original Message-
> >From: Intel-gfx On Behalf Of Chris
> >Wilson
> >Sent: Friday, April 3, 2020 3:02 PM
> >To: intel-gfx@lists.freedesktop.org
> >Cc: Chris Wilson
> >Subject: [Intel-gfx] [PATCH] drm/i915/selftests: Wait until we start
> >timeslicing
> >after a submit
> >
> >If we submit, we do not start timeslicnig until we process the CS event
>
> s/timeslicnig/timeslicing/
>
> >that marks the start of the context running on HW. So in the selftest,
> >be sure to wait until we have processed the pending events before
> >asserting that timeslicing has begun.
> >
> >Signed-off-by: Chris Wilson
> >---
> > drivers/gpu/drm/i915/gt/selftest_lrc.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> >b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> >index 985d4041d929..9e02917695b1 100644
> >--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> >+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> >@@ -1244,7 +1244,11 @@ static int live_timeslice_queue(void *arg)
> > if (err)
> > goto err_rq;
> >
> >- intel_engine_flush_submission(engine);
> >+ /* Wait until we ack the release_queue and start timeslicing
> >*/
> >+ do {
> >+ intel_engine_flush_submission(engine);
> >+ } while (READ_ONCE(engine->execlists.pending[0]));
>
> Is this guaranteed to clear? Or should there be a count to protect against
> the endless loop?
Yes. If the HW stops, we reset it and clear the submission queue.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915/gt: Free request pool from virtual engines
While extremely unlikely to be populated, we could capture a request on
the virtual engine which we should free along with the virtual engine.
Fixes: 43acd6516ca9 ("drm/i915: Keep a per-engine request pool")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine.h| 2 ++
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 13 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 ++
3 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index b469de0dd9b6..d9ee64e2ef79 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -199,6 +199,8 @@ void intel_engine_cleanup(struct intel_engine_cs *engine);
int intel_engines_init_mmio(struct intel_gt *gt);
int intel_engines_init(struct intel_gt *gt);
+void intel_engine_free_request_pool(struct intel_engine_cs *engine);
+
void intel_engines_release(struct intel_gt *gt);
void intel_engines_free(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 5f45c8274203..977e23fac5ce 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -426,6 +426,14 @@ void intel_engines_release(struct intel_gt *gt)
}
}
+void intel_engine_free_request_pool(struct intel_engine_cs *engine)
+{
+ if (!engine->request_pool)
+ return;
+
+ kmem_cache_free(i915_request_slab_cache(), engine->request_pool);
+}
+
void intel_engines_free(struct intel_gt *gt)
{
struct intel_engine_cs *engine;
@@ -435,10 +443,7 @@ void intel_engines_free(struct intel_gt *gt)
rcu_barrier();
for_each_engine(engine, gt, id) {
- if (engine->request_pool)
- kmem_cache_free(i915_request_slab_cache(),
- engine->request_pool);
-
+ intel_engine_free_request_pool(engine);
kfree(engine);
gt->engine[id] = NULL;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index f028114714cd..19ffc7763683 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -4931,6 +4931,8 @@ static void virtual_context_destroy(struct kref *kref)
__execlists_context_fini(>context);
intel_context_fini(>context);
+ intel_engine_free_request_pool(>base);
+
kfree(ve->bonds);
kfree(ve);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Wait until we start timeslicing after a submit
>-Original Message-
>From: Intel-gfx On Behalf Of Chris
>Wilson
>Sent: Friday, April 3, 2020 3:02 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Chris Wilson
>Subject: [Intel-gfx] [PATCH] drm/i915/selftests: Wait until we start
>timeslicing
>after a submit
>
>If we submit, we do not start timeslicnig until we process the CS event
s/timeslicnig/timeslicing/
>that marks the start of the context running on HW. So in the selftest,
>be sure to wait until we have processed the pending events before
>asserting that timeslicing has begun.
>
>Signed-off-by: Chris Wilson
>---
> drivers/gpu/drm/i915/gt/selftest_lrc.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
>b/drivers/gpu/drm/i915/gt/selftest_lrc.c
>index 985d4041d929..9e02917695b1 100644
>--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
>+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
>@@ -1244,7 +1244,11 @@ static int live_timeslice_queue(void *arg)
> if (err)
> goto err_rq;
>
>- intel_engine_flush_submission(engine);
>+ /* Wait until we ack the release_queue and start timeslicing
>*/
>+ do {
>+ intel_engine_flush_submission(engine);
>+ } while (READ_ONCE(engine->execlists.pending[0]));
Is this guaranteed to clear? Or should there be a count to protect against
the endless loop?
Or am I too paranoid?
M
> if (!READ_ONCE(engine->execlists.timer.expires) &&
> !i915_request_completed(rq)) {
> struct drm_printer p =
>--
>2.20.1
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: move remaining debugfs interfaces into gt (rev4)
== Series Details == Series: drm/i915/gt: move remaining debugfs interfaces into gt (rev4) URL : https://patchwork.freedesktop.org/series/75333/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8251 -> Patchwork_17205 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17205 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17205, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17205/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17205: ### IGT changes ### Possible regressions * igt@i915_selftest@live@execlists: - fi-apl-guc: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8251/fi-apl-guc/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17205/fi-apl-guc/igt@i915_selftest@l...@execlists.html Known issues Here are the changes found in Patchwork_17205 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload: - fi-skl-6770hq: [PASS][3] -> [DMESG-WARN][4] ([i915#203]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8251/fi-skl-6770hq/igt@i915_module_l...@reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17205/fi-skl-6770hq/igt@i915_module_l...@reload.html * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-skl-6770hq: [PASS][5] -> [SKIP][6] ([fdo#109271]) +5 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8251/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17205/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html * igt@kms_pipe_crc_basic@read-crc-pipe-b: - fi-skl-6770hq: [PASS][7] -> [DMESG-WARN][8] ([i915#106]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8251/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17205/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html Possible fixes * igt@i915_selftest@live@execlists: - fi-bxt-dsi: [INCOMPLETE][9] ([i915#656]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8251/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17205/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#106]: https://gitlab.freedesktop.org/drm/intel/issues/106 [i915#203]: https://gitlab.freedesktop.org/drm/intel/issues/203 [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656 Participating hosts (50 -> 44) -- Additional (1): fi-kbl-7560u Missing(7): fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8251 -> Patchwork_17205 CI-20190529: 20190529 CI_DRM_8251: 06ddf8dd059d59bc27c24b09a6e500809e619982 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5563: 7ab7807727262b7ed7e12197b78e867287a17ef6 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17205: 88806913668da4525869dff6f099152bf63b0178 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 88806913668d drm/i915/gt: move remaining debugfs interfaces into gt == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17205/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: move remaining debugfs interfaces into gt (rev4)
== Series Details == Series: drm/i915/gt: move remaining debugfs interfaces into gt (rev4) URL : https://patchwork.freedesktop.org/series/75333/ State : warning == Summary == $ dim checkpatch origin/drm-tip 88806913668d drm/i915/gt: move remaining debugfs interfaces into gt -:119: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #119: new file mode 100644 -:443: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #443: FILE: drivers/gpu/drm/i915/gt/debugfs_sseu.c:74: + eu_reg[2 * s + 1] = intel_uncore_read(uncore, + GEN10_SS23_EU_PGCTL_ACK(s)); -:493: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV) #493: FILE: drivers/gpu/drm/i915/gt/debugfs_sseu.c:124: + eu_reg[2*s] = intel_uncore_read(uncore, ^ -:495: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV) #495: FILE: drivers/gpu/drm/i915/gt/debugfs_sseu.c:126: + eu_reg[2*s + 1] = intel_uncore_read(uncore, ^ -:533: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV) #533: FILE: drivers/gpu/drm/i915/gt/debugfs_sseu.c:164: + eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] & ^ -:533: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV) #533: FILE: drivers/gpu/drm/i915/gt/debugfs_sseu.c:164: + eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] & ^ -:534: CHECK:SPACING: spaces preferred around that '%' (ctx:VxV) #534: FILE: drivers/gpu/drm/i915/gt/debugfs_sseu.c:165: + eu_mask[ss%2]); ^ total: 0 errors, 1 warnings, 6 checks, 1062 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Wait until we start timeslicing after a submit
If we submit, we do not start timeslicnig until we process the CS event
that marks the start of the context running on HW. So in the selftest,
be sure to wait until we have processed the pending events before
asserting that timeslicing has begun.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 985d4041d929..9e02917695b1 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -1244,7 +1244,11 @@ static int live_timeslice_queue(void *arg)
if (err)
goto err_rq;
- intel_engine_flush_submission(engine);
+ /* Wait until we ack the release_queue and start timeslicing */
+ do {
+ intel_engine_flush_submission(engine);
+ } while (READ_ONCE(engine->execlists.pending[0]));
+
if (!READ_ONCE(engine->execlists.timer.expires) &&
!i915_request_completed(rq)) {
struct drm_printer p =
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5] drm/i915/gt: move remaining debugfs interfaces into gt
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
i915_rcs_topology
i915_sseu_status
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
gt
|
+-- forcewake_user
|
+-- interrupt_info
|
+-- reset
|
+-- rcs_topology
|
+-- sseu_status
Signed-off-by: Andi Shyti
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
Hi,
this patch is the first of a series that aims to refactor the
debugfs structure in the i915. Some changes will affect the
debugfs framework as well.
It has gone through a series of offline reviews mainly from
Tvrtko. Even though it hasn't been done publicly, I took the
freedom to add Tvrtko's review.
Thanks Tvrtko and Chris for the review,
Andi
Changelog
=
v5:
- renamed from debugfs_gt_sseu.[ch] to debugfs_sseu.[ch]
- moved i915_rcs_topology from i915_debugfs.c to
gt/debugfs_sseu.c
- added Tvrtko's and Chris r-b.
v4:
- interrupt and sseu debugfs interface are moved to their own
"debugfs_gt_irq" and "debugfs_gt_sseu" files
- reset functions are renamed to reset_show/store
v3:
- better arrangement of what should stay in i915_debugfs and
what needs to be moved under gt/
- more use of the local "uncore" and "i915" variables to improve
readability
v2:
- dropped changes on "drop_caches", they were indeed irrelevant
- improved interrupt info function
drivers/gpu/drm/i915/Makefile| 2 +
drivers/gpu/drm/i915/gt/debugfs_gt.c | 50 ++-
drivers/gpu/drm/i915/gt/debugfs_gt_irq.c | 162 ++
drivers/gpu/drm/i915/gt/debugfs_gt_irq.h | 15 +
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 32 ++
drivers/gpu/drm/i915/gt/debugfs_sseu.c | 294 +
drivers/gpu/drm/i915/gt/debugfs_sseu.h | 16 +
drivers/gpu/drm/i915/i915_debugfs.c | 384 +--
8 files changed, 571 insertions(+), 384 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/debugfs_gt_irq.c
create mode 100644 drivers/gpu/drm/i915/gt/debugfs_gt_irq.h
create mode 100644 drivers/gpu/drm/i915/gt/debugfs_sseu.c
create mode 100644 drivers/gpu/drm/i915/gt/debugfs_sseu.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 2fce8b0040f3..51929d6648e2 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -79,6 +79,8 @@ gt-y += \
gt/debugfs_engines.o \
gt/debugfs_gt.o \
gt/debugfs_gt_pm.o \
+ gt/debugfs_gt_irq.o \
+ gt/debugfs_sseu.o \
gt/gen6_ppgtt.o \
gt/gen7_renderclear.o \
gt/gen8_ppgtt.o \
diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt.c
b/drivers/gpu/drm/i915/gt/debugfs_gt.c
index 1de5fbaa1cf9..507fe5dcb360 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_gt.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_gt.c
@@ -8,9 +8,53 @@
#include "debugfs_engines.h"
#include "debugfs_gt.h"
+#include "debugfs_gt_irq.h"
#include "debugfs_gt_pm.h"
-#include "uc/intel_uc_debugfs.h"
+#include "debugfs_sseu.h"
#include "i915_drv.h"
+#include "intel_gt_pm.h"
+#include "intel_gt_requests.h"
+#include "uc/intel_uc_debugfs.h"
+
+static int reset_show(void *data, u64 *val)
+{
+ struct intel_gt *gt = data;
+ int ret = intel_gt_terminally_wedged(gt);
+
+ switch (ret) {
+ case -EIO:
+ *val = 1;
+ return 0;
+ case 0:
+ *val = 0;
+ return 0;
+ default:
+ return ret;
+ }
+}
+
+static int reset_store(void *data, u64 val)
+{
+ struct intel_gt *gt = data;
+
+ /* Flush any previous reset before applying for a new one */
+ wait_event(gt->reset.queue,
+ !test_bit(I915_RESET_BACKOFF, >reset.flags));
+
+ intel_gt_handle_error(gt, val, I915_ERROR_CAPTURE,
+ "Manually reset engine mask to %llx", val);
+ return 0;
+}
+DEFINE_SIMPLE_ATTRIBUTE(reset_fops, reset_show, reset_store, "%llu\n");
+
+static void __debugfs_gt_register(struct intel_gt *gt, struct dentry *root)
+{
+ static const struct debugfs_gt_file files[] = {
+ { "reset", _fops, NULL },
+ };
+
+ intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), gt);
+}
void debugfs_gt_register(struct intel_gt *gt)
{
@@ -23,8 +67,12 @@ void debugfs_gt_register(struct intel_gt *gt)
if (IS_ERR(root))
return;
+ __debugfs_gt_register(gt, root);
+
debugfs_engines_register(gt, root);
debugfs_gt_pm_register(gt, root);
+ debugfs_gt_register_sseu(gt, root);
+ debugfs_gt_register_irq(gt, root);
intel_uc_debugfs_register(>uc, root);
}
diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt_irq.c
b/drivers/gpu/drm/i915/gt/debugfs_gt_irq.c
new file mode 100644
index ..8aaf76dfc573
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/debugfs_gt_irq.c
@@ -0,0 +1,162 @@
+// SPDX-License-Identifier: MIT
+
+/*
+ *
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Check current i915_vma.pin_count status first on unbind (rev6)
== Series Details ==
Series: drm/i915: Check current i915_vma.pin_count status first on unbind (rev6)
URL : https://patchwork.freedesktop.org/series/72529/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8244_full -> Patchwork_17199_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17199_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17199_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_17199_full:
### IGT changes ###
Possible regressions
* igt@gem_tiled_swapping@non-threaded:
- shard-glk: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8244/shard-glk3/igt@gem_tiled_swapp...@non-threaded.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17199/shard-glk1/igt@gem_tiled_swapp...@non-threaded.html
- shard-tglb: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8244/shard-tglb3/igt@gem_tiled_swapp...@non-threaded.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17199/shard-tglb7/igt@gem_tiled_swapp...@non-threaded.html
- shard-snb: [PASS][5] -> [FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8244/shard-snb6/igt@gem_tiled_swapp...@non-threaded.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17199/shard-snb5/igt@gem_tiled_swapp...@non-threaded.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@sysfs_timeslice_duration@timeout@rcs0}:
- shard-skl: [PASS][7] -> [FAIL][8] +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8244/shard-skl10/igt@sysfs_timeslice_duration@time...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17199/shard-skl3/igt@sysfs_timeslice_duration@time...@rcs0.html
Known issues
Here are the changes found in Patchwork_17199_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_tiled_swapping@non-threaded:
- shard-kbl: [PASS][9] -> [FAIL][10] ([i915#93] / [i915#95])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8244/shard-kbl2/igt@gem_tiled_swapp...@non-threaded.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17199/shard-kbl6/igt@gem_tiled_swapp...@non-threaded.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][11] -> [FAIL][12] ([i915#454])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8244/shard-iclb2/igt@i915_pm...@dc6-psr.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17199/shard-iclb6/igt@i915_pm...@dc6-psr.html
* igt@i915_selftest@live@execlists:
- shard-apl: [PASS][13] -> [INCOMPLETE][14] ([i915#656])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8244/shard-apl3/igt@i915_selftest@l...@execlists.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17199/shard-apl8/igt@i915_selftest@l...@execlists.html
* igt@i915_suspend@debugfs-reader:
- shard-iclb: [PASS][15] -> [INCOMPLETE][16] ([i915#1185])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8244/shard-iclb8/igt@i915_susp...@debugfs-reader.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17199/shard-iclb3/igt@i915_susp...@debugfs-reader.html
* igt@i915_suspend@sysfs-reader:
- shard-skl: [PASS][17] -> [INCOMPLETE][18] ([i915#69])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8244/shard-skl10/igt@i915_susp...@sysfs-reader.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17199/shard-skl3/igt@i915_susp...@sysfs-reader.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-hsw: [PASS][19] -> [INCOMPLETE][20] ([i915#61])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8244/shard-hsw4/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17199/shard-hsw2/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_draw_crc@draw-method-rgb565-pwrite-untiled:
- shard-glk: [PASS][21] -> [FAIL][22] ([i915#177] / [i915#52] /
[i915#54])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8244/shard-glk2/igt@kms_draw_...@draw-method-rgb565-pwrite-untiled.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17199/shard-glk1/igt@kms_draw_...@draw-method-rgb565-pwrite-untiled.html
* igt@kms_draw_crc@draw-method-xrgb-mmap-gtt-untiled:
- shard-apl:
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] lib: Bump estimates for object overhead
On Fri, 3 Apr 2020 at 14:24, Chris Wilson wrote: > > We are dramatically underestimating the overhead for an active object > and its inodes. > > Signed-off-by: Chris Wilson Acked-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 5/5] uaccess: Rename user_access_begin/end() to user_full_access_begin/end()
On Fri, Apr 3, 2020 at 12:21 AM Christophe Leroy wrote: > > Now we have user_read_access_begin() and user_write_access_begin() > in addition to user_access_begin(). I realize Al asked for this, but I don't think it really adds anything to the series. The "full" makes the names longer, but not really any more legible. So I like 1-4, but am unconvinced about 5 and would prefer that to be dropped. Sorry for the bikeshedding. And I like this series much better without the cookie that was discussed, and just making the hard rule be that they can't nest. Some architecture may obviously use a cookie internally if they have some nesting behavior of their own, but it doesn't look like we have any major reason to expose that as the actual interface. The only other question is how to synchronize this? I'm ok with it going through the ppc tree, for example, and just let others build on that. Maybe using a shared immutable branch with 5.6 as a base? Linus ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: Do not clear pollin for small user read buffers
Quoting Dixit, Ashutosh (2020-04-03 18:45:09) > On Fri, 03 Apr 2020 09:17:14 -0700, Chris Wilson wrote: > > > > Quoting Ashutosh Dixit (2020-04-03 02:01:20) > > > It is wrong to block the user thread in the next poll when OA data is > > > already available which could not fit in the user buffer provided in > > > the previous read. In several cases the exact user buffer size is not > > > known. Blocking user space in poll can lead to data loss when the > > > buffer size used is smaller than the available data. > > > > > > This change fixes this issue and allows user space to read all OA data > > > even when using a buffer size smaller than the available data using > > > multiple non-blocking reads rather than staying blocked in poll till > > > the next timer interrupt. > > > > > > v2: Fix ret value for blocking reads (Umesh) > > > v3: Mistake during patch send (Ashutosh) > > > v4: Remove -EAGAIN from comment (Umesh) > > > v5: Improve condition for clearing pollin and return (Lionel) > > > v6: Improve blocking read loop and other cleanups (Lionel) > > > v7: Added Cc stable > > > > > > Cc: Umesh Nerlige Ramappa > > > Cc: > > > Reviewed-by: Lionel Landwerlin > > > Signed-off-by: Ashutosh Dixit > > > > Did you manage to devise a test case? It is nice (some might say > > important) to pair a patch for stable with its regression test. > > Yes there is a test case here: > > https://patchwork.freedesktop.org/series/75100/#rev3 > > Lionel verified that it is fails on stable kernels here: > > https://patchwork.freedesktop.org/patch/358873/?series=75100=1 Ta. Pushed both, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/44] drm/st7586: Use devm_drm_dev_alloc
On 4/3/20 8:58 AM, Daniel Vetter wrote: Already using devm_drm_dev_init, so very simple replacment. Signed-off-by: Daniel Vetter Cc: David Lechner --- Acked-by: David Lechner ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] gvt-next-fixes
+Dave and Daniel, On Fri, Apr 03, 2020 at 11:05:07AM +0800, Zhenyu Wang wrote: > On 2020.03.31 09:26:44 -0700, Rodrigo Vivi wrote: > > On Tue, Mar 31, 2020 at 03:00:25PM +0800, Zhenyu Wang wrote: > > > > > > Hi, > > > > > > Here's more queued gvt fixes for 5.7. Please see details below. > > > > > > Thanks > > > -- > > > The following changes since commit > > > a61ac1e75105a077ec1efd6923ae3c619f862304: > > > > > > drm/i915/gvt: Wean gvt off using dev_priv (2020-03-06 10:08:10 +0800) > > > > > > are available in the Git repository at: > > > > > > https://github.com/intel/gvt-linux.git tags/gvt-next-fixes-2020-03-31 > > > > > > for you to fetch changes up to eb0ff8074e0baecba2cd0c7813f6cfa99bafc430: > > > > > > drm/i915/gvt: Fix klocwork issues about data size (2020-03-27 15:37:58 > > > +0800) > > > > pulled, thanks > > I forgot to mention one thing for 5.7. We've fixed to change guest mem r/w > from KVM to use new VFIO dma r/w instead in this series: > https://patchwork.freedesktop.org/series/72038/ > > As this depends on VFIO tree and looks VFIO pull for 5.7 is not settled down > yet, we'd need to backmerge and send pull against vfio merge for 5.7. I'm not sure if I'm following on which backmerge you are willing us to do here. And for me it looks like late for 5.7 already. Maybe you mean we ack all of this to go through vfio flow then once that is settled drm backmerge and then drm-intel backmerge and you backmerge... Is that what you want? > > thanks > > > > > > > > > > > > gvt-next-fixes-2020-03-31 > > > > > > - Fix non-privilege access warning (Tina) > > > - Fix display port type (Tina) > > > - BDW cmd parser missed SWTESS_BASE_ADDRESS (Yan) > > > - Bypass length check of LRI (Yan) > > > - Fix one klocwork warning (Tina) > > > > > > > > > Tina Zhang (3): > > > drm/i915/gvt: Add some regs to force-to-nonpriv whitelist > > > drm/i915/gvt: Fix display port type issue > > > drm/i915/gvt: Fix klocwork issues about data size > > > > > > Yan Zhao (2): > > > drm/i915/gvt: add support to command SWTESS_BASE_ADDRESS > > > drm/i915/gvt: do not check len & max_len for lri > > > > > > drivers/gpu/drm/i915/gvt/cmd_parser.c | 16 > > > drivers/gpu/drm/i915/gvt/display.c| 6 +++--- > > > drivers/gpu/drm/i915/gvt/handlers.c | 8 ++-- > > > drivers/gpu/drm/i915/gvt/scheduler.c | 4 ++-- > > > 4 files changed, 15 insertions(+), 19 deletions(-) > > > > > > -- > > > Open Source Technology Center, Intel ltd. > > > > > > $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 > > > > > > ___ > > intel-gvt-dev mailing list > > intel-gvt-...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev > > -- > Open Source Technology Center, Intel ltd. > > $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: Do not clear pollin for small user read buffers
On Fri, 03 Apr 2020 09:17:14 -0700, Chris Wilson wrote: > > Quoting Ashutosh Dixit (2020-04-03 02:01:20) > > It is wrong to block the user thread in the next poll when OA data is > > already available which could not fit in the user buffer provided in > > the previous read. In several cases the exact user buffer size is not > > known. Blocking user space in poll can lead to data loss when the > > buffer size used is smaller than the available data. > > > > This change fixes this issue and allows user space to read all OA data > > even when using a buffer size smaller than the available data using > > multiple non-blocking reads rather than staying blocked in poll till > > the next timer interrupt. > > > > v2: Fix ret value for blocking reads (Umesh) > > v3: Mistake during patch send (Ashutosh) > > v4: Remove -EAGAIN from comment (Umesh) > > v5: Improve condition for clearing pollin and return (Lionel) > > v6: Improve blocking read loop and other cleanups (Lionel) > > v7: Added Cc stable > > > > Cc: Umesh Nerlige Ramappa > > Cc: > > Reviewed-by: Lionel Landwerlin > > Signed-off-by: Ashutosh Dixit > > Did you manage to devise a test case? It is nice (some might say > important) to pair a patch for stable with its regression test. Yes there is a test case here: https://patchwork.freedesktop.org/series/75100/#rev3 Lionel verified that it is fails on stable kernels here: https://patchwork.freedesktop.org/patch/358873/?series=75100=1 Thanks! -- Ashutosh ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 40/44] drm/cirrus: Don't use drm_device->dev_private
On Fri, Apr 3, 2020 at 6:59 AM Daniel Vetter wrote: > > Upcasting using a container_of macro is more typesafe, faster and > easier for the compiler to optimize. > > Signed-off-by: Daniel Vetter > Cc: Dave Airlie > Cc: Gerd Hoffmann > Cc: Daniel Vetter > Cc: "Noralf Trønnes" > Cc: Sam Ravnborg Acked-by: Eric Anholt ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/44] drm/v3d: Don't set drm_device->dev_private
On Fri, Apr 3, 2020 at 6:58 AM Daniel Vetter wrote: > > And switch the helper over to container_of, which is a bunch faster > than chasing a pointer. Plus allows gcc to see through this maze. > > Signed-off-by: Daniel Vetter Acked-by: Eric Anholt ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 24/44] drm/hx8357d: Use devm_drm_dev_alloc
On Fri, Apr 3, 2020 at 6:59 AM Daniel Vetter wrote: > > Already using devm_drm_dev_init, so very simple replacment. > > Signed-off-by: Daniel Vetter Acked-by: Eric Anholt ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/44] drm/v3d: Use devm_drm_dev_alloc
On Fri, Apr 3, 2020 at 6:58 AM Daniel Vetter wrote: > > Also allows us to simplify the unroll code since the drm_dev_put > disappears. > > Signed-off-by: Daniel Vetter Acked-by: Eric Anholt ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/44] drm/v3d: Delete v3d_dev->dev
On Fri, Apr 3, 2020 at 6:58 AM Daniel Vetter wrote: > > We already have it in v3d_dev->drm.dev with zero additional pointer > chasing. Personally I don't like duplicated pointers like this > because: > - reviewers need to check whether the pointer is for the same or > different objects if there's multiple > - compilers have an easier time too > > But also a bit a bikeshed, so feel free to ignore. > > Signed-off-by: Daniel Vetter > Cc: Eric Anholt a-b. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/44] drm/v3d: Delete v3d_dev->pdev
On Fri, Apr 3, 2020 at 6:58 AM Daniel Vetter wrote: > > We already have it in v3d_dev->drm.dev with zero additional pointer > chasing. Personally I don't like duplicated pointers like this > because: > - reviewers need to check whether the pointer is for the same or > different objects if there's multiple > - compilers have an easier time too > > To avoid having to pull in some big headers I implemented the casting > function as a macro instead of a static inline. Typechecking thanks to > container_of still assured. > > But also a bit a bikeshed, so feel free to ignore. > > Signed-off-by: Daniel Vetter > Cc: Eric Anholt ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 23/44] drm/ili9225: Use devm_drm_dev_alloc
On 4/3/20 8:58 AM, Daniel Vetter wrote: Already using devm_drm_dev_init, so very simple replacment. Signed-off-by: Daniel Vetter Cc: David Lechner --- Acked-by: David Lechner ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for SAGV support for Gen12+ (rev13)
== Series Details == Series: SAGV support for Gen12+ (rev13) URL : https://patchwork.freedesktop.org/series/75129/ State : success == Summary == CI Bug Log - changes from CI_DRM_8247 -> Patchwork_17204 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17204/index.html Known issues Here are the changes found in Patchwork_17204 that come from known issues: ### IGT changes ### Possible fixes * igt@gem_tiled_fence_blits@basic: - fi-blb-e6850: [DMESG-WARN][1] ([i915#1612]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/fi-blb-e6850/igt@gem_tiled_fence_bl...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17204/fi-blb-e6850/igt@gem_tiled_fence_bl...@basic.html * igt@i915_module_load@reload: - fi-skl-6770hq: [DMESG-WARN][3] ([i915#203]) -> [PASS][4] +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/fi-skl-6770hq/igt@i915_module_l...@reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17204/fi-skl-6770hq/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@basic-rte: - fi-icl-dsi: [INCOMPLETE][5] ([i915#189]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/fi-icl-dsi/igt@i915_pm_...@basic-rte.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17204/fi-icl-dsi/igt@i915_pm_...@basic-rte.html * igt@i915_selftest@live@execlists: - fi-skl-guc: [INCOMPLETE][7] ([i915#656]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/fi-skl-guc/igt@i915_selftest@l...@execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17204/fi-skl-guc/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@dp-edid-read: - fi-cml-u2: [FAIL][9] ([i915#976]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17204/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-skl-6770hq: [SKIP][11] ([fdo#109271]) -> [PASS][12] +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17204/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html * igt@kms_pipe_crc_basic@read-crc-pipe-c: - fi-skl-6770hq: [DMESG-WARN][13] ([i915#106]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17204/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#106]: https://gitlab.freedesktop.org/drm/intel/issues/106 [i915#1612]: https://gitlab.freedesktop.org/drm/intel/issues/1612 [i915#189]: https://gitlab.freedesktop.org/drm/intel/issues/189 [i915#203]: https://gitlab.freedesktop.org/drm/intel/issues/203 [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656 [i915#976]: https://gitlab.freedesktop.org/drm/intel/issues/976 Participating hosts (51 -> 44) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-kbl-7560u fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8247 -> Patchwork_17204 CI-20190529: 20190529 CI_DRM_8247: 4ceaa00bfb032d9f29a485596fbc02fdeab06bc9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5562: 4770480c8c1f105ff9225e8eb07b652ca954e06a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17204: 893ba5a63c98048f77ddbd19ba4f10d0bad98148 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 893ba5a63c98 drm/i915: Enable SAGV support for Gen12 24c7d7d3c6b3 drm/i915: Restrict qgv points which don't have enough bandwidth. 86922c9a6deb drm/i915: Rename bw_state to new_bw_state 22bc551a31f5 drm/i915: Added required new PCode commands b493687dd5af drm/i915: Add proper SAGV support for TGL+ b7d98af9e158 drm/i915: Extract gen specific functions from intel_can_enable_sagv 32a8f02d9693 drm/i915: Add intel_atomic_get_bw_*_state helpers 9fd3eb581b6a drm/i915: Introduce skl_plane_wm_level accessor. 2cb942fadfcf drm/i915: Eliminate magic numbers "0" and "1" from color plane f121c205f975 drm/i915: Start passing latency as parameter == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17204/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Revoke mmap before fence
On Fri, 3 Apr 2020 at 17:10, Chris Wilson wrote:
>
> Make sure we revoke the user's mmaps of this vma to force them to take a
> pagefault *before* we remove the associated aperture detiling register.
>
> Fixes: 0d86ee35097a ("drm/i915/gt: Make fence revocation unequivocal")
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/44] drm/st7735r: Use devm_drm_dev_alloc
On 4/3/20 8:58 AM, Daniel Vetter wrote: Already using devm_drm_dev_init, so very simple replacment. Aside: There was an oddity in the old code, we allocated priv but in the error path we've freed priv->dbidev ... Signed-off-by: Daniel Vetter Cc: David Lechner --- Acked-by: David Lechner ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/13] drm/i915: Fix port sync code to work with >2 pipes
On Fri, Apr 03, 2020 at 12:32:20AM +, Souza, Jose wrote:
> On Fri, 2020-03-13 at 18:48 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Don't assume there is just one port sync slave. We might have
> > several.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 98 ++--
> >
> > 1 file changed, 49 insertions(+), 49 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index b56a5a49418f..33f38c8a5da4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -15009,18 +15009,6 @@ static void intel_update_crtc(struct
> > intel_atomic_state *state,
> > intel_crtc_arm_fifo_underrun(crtc, new_crtc_state);
> > }
> >
> > -static struct intel_crtc *intel_get_slave_crtc(const struct
> > intel_crtc_state *new_crtc_state)
> > -{
> > - struct drm_i915_private *dev_priv = to_i915(new_crtc_state-
> > >uapi.crtc->dev);
> > - enum transcoder slave_transcoder;
> > -
> > - drm_WARN_ON(_priv->drm,
> > - !is_power_of_2(new_crtc_state-
> > >sync_mode_slaves_mask));
> > -
> > - slave_transcoder = ffs(new_crtc_state->sync_mode_slaves_mask) -
> > 1;
> > - return intel_get_crtc_for_pipe(dev_priv,
> > - (enum pipe)slave_transcoder);
> > -}
> >
> > static void intel_old_crtc_state_disables(struct intel_atomic_state
> > *state,
> > struct intel_crtc_state
> > *old_crtc_state,
> > @@ -15109,8 +15097,8 @@ static void
> > intel_commit_modeset_enables(struct intel_atomic_state *state)
> > }
> > }
> >
> > -static void intel_set_dp_tp_ctl_normal(struct intel_crtc *crtc,
> > - struct intel_atomic_state
> > *state)
> > +static void intel_set_dp_tp_ctl_normal(struct intel_atomic_state
> > *state,
> > + struct intel_crtc *crtc)
> > {
> > struct drm_connector *uninitialized_var(conn);
> > struct drm_connector_state *conn_state;
> > @@ -15125,45 +15113,55 @@ static void
> > intel_set_dp_tp_ctl_normal(struct intel_crtc *crtc,
> > intel_dp_stop_link_train(intel_dp);
> > }
> >
> > -static void intel_update_trans_port_sync_crtcs(struct intel_crtc
> > *crtc,
> > - struct
> > intel_atomic_state *state,
> > - struct intel_crtc_state
> > *old_crtc_state,
> > - struct intel_crtc_state
> > *new_crtc_state)
> > +static void intel_update_trans_port_sync_crtcs(struct
> > intel_atomic_state *state,
> > + struct intel_crtc *crtc)
> > {
> > - struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > - struct intel_crtc *slave_crtc =
> > intel_get_slave_crtc(new_crtc_state);
> > - struct intel_crtc_state *new_slave_crtc_state =
> > - intel_atomic_get_new_crtc_state(state, slave_crtc);
> > - struct intel_crtc_state *old_slave_crtc_state =
> > - intel_atomic_get_old_crtc_state(state, slave_crtc);
> > + struct drm_i915_private *i915 = to_i915(state->base.dev);
> > + const struct intel_crtc_state *new_slave_crtc_state;
> > + const struct intel_crtc_state *new_crtc_state;
> > + struct intel_crtc *slave_crtc;
> > + int i;
> >
> > - drm_WARN_ON(>drm, !slave_crtc || !new_slave_crtc_state ||
> > - !old_slave_crtc_state);
> > + for_each_new_intel_crtc_in_state(state, slave_crtc,
> > +new_slave_crtc_state, i) {
> > + if (new_slave_crtc_state->master_transcoder !=
> > + new_crtc_state->cpu_transcoder)
>
> Missing new_crtc_state initialization.
Whoops. Fixed.
>
> With that:
> Reviewed-by: José Roberto de Souza
>
> > - /* TODO: update entries[] of slave */
> > - modeset_pipes &= ~BIT(slave_crtc->pipe);
> > + for_each_new_intel_crtc_in_state(state,
> > slave_crtc,
> > +new_slave_crtc
> > _state, i) {
> >
> > + /* TODO: update entries[] of slave */
> > + modeset_pipes &= ~BIT(slave_crtc-
> > >pipe);
Noticed another problem here. Instead of clearing modeset_pipes for
the slaves of the current crtc we clear it for all crtcs. Fixed to do
the same master_transcoder check as above.
> > + }
> > } else {
> > intel_enable_crtc(state, crtc);
> > intel_update_crtc(state, crtc);
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 22/44] drm/ili9341: Use devm_drm_dev_alloc
On 4/3/20 8:58 AM, Daniel Vetter wrote: Already using devm_drm_dev_init, so very simple replacment. Signed-off-by: Daniel Vetter Cc: "Noralf Trønnes" Cc: Sam Ravnborg Cc: Daniel Vetter Cc: Eric Anholt Cc: David Lechner --- Acked-by: David Lechner ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/10] drm/i915/selftests: Add request throughput measurement to perf
== Series Details ==
Series: series starting with [01/10] drm/i915/selftests: Add request throughput
measurement to perf
URL : https://patchwork.freedesktop.org/series/75452/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8243_full -> Patchwork_17197_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17197_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17197_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_17197_full:
### IGT changes ###
Possible regressions
* igt@gem_mmap_gtt@cpuset-basic-small-copy-xy:
- shard-kbl: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-kbl4/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17197/shard-kbl3/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html
* igt@gem_mmap_gtt@hang:
- shard-iclb: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-iclb2/igt@gem_mmap_...@hang.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17197/shard-iclb5/igt@gem_mmap_...@hang.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@sysfs_heartbeat_interval@mixed@bcs0}:
- shard-skl: [PASS][5] -> [INCOMPLETE][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-skl2/igt@sysfs_heartbeat_interval@mi...@bcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17197/shard-skl2/igt@sysfs_heartbeat_interval@mi...@bcs0.html
New tests
-
New tests have been introduced between CI_DRM_8243_full and
Patchwork_17197_full:
### New IGT tests (4) ###
* igt@dmabuf@all@dma_fence_chain:
- Statuses : 7 pass(s)
- Exec time: [7.44, 36.86] s
* igt@dmabuf@all@dma_fence_proxy:
- Statuses : 7 pass(s)
- Exec time: [0.04, 0.09] s
* igt@i915_selftest@perf@request:
- Statuses : 7 pass(s)
- Exec time: [3.50, 5.68] s
* igt@perf_pmu@faulting-read:
- Statuses :
- Exec time: [None] s
Known issues
Here are the changes found in Patchwork_17197_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_workarounds@suspend-resume-context:
- shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#180] / [i915#93]
/ [i915#95])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-kbl1/igt@gem_workarou...@suspend-resume-context.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17197/shard-kbl2/igt@gem_workarou...@suspend-resume-context.html
* igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-apl4/igt@kms_cursor_...@pipe-b-cursor-suspend.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17197/shard-apl6/igt@kms_cursor_...@pipe-b-cursor-suspend.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +4
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-kbl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17197/shard-kbl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
- shard-glk: [PASS][13] -> [FAIL][14] ([i915#72])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-glk6/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17197/shard-glk3/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html
* igt@kms_draw_crc@draw-method-xrgb-mmap-gtt-untiled:
- shard-apl: [PASS][15] -> [FAIL][16] ([i915#52] / [i915#54] /
[i915#95])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-apl4/igt@kms_draw_...@draw-method-xrgb-mmap-gtt-untiled.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17197/shard-apl6/igt@kms_draw_...@draw-method-xrgb-mmap-gtt-untiled.html
* igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#265])
+2 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-skl5/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
[18]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/23] perf/core: Only copy-to-user after completely unlocking all locks, v2.
== Series Details == Series: series starting with [01/23] perf/core: Only copy-to-user after completely unlocking all locks, v2. URL : https://patchwork.freedesktop.org/series/75423/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8238_full -> Patchwork_17184_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17184_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17184_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17184_full: ### IGT changes ### Possible regressions * igt@gem_close@many-handles-one-vma: - shard-glk: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-glk5/igt@gem_cl...@many-handles-one-vma.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17184/shard-glk8/igt@gem_cl...@many-handles-one-vma.html - shard-apl: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-apl6/igt@gem_cl...@many-handles-one-vma.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17184/shard-apl6/igt@gem_cl...@many-handles-one-vma.html - shard-tglb: [PASS][5] -> [FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-tglb3/igt@gem_cl...@many-handles-one-vma.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17184/shard-tglb1/igt@gem_cl...@many-handles-one-vma.html - shard-kbl: [PASS][7] -> [FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-kbl6/igt@gem_cl...@many-handles-one-vma.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17184/shard-kbl7/igt@gem_cl...@many-handles-one-vma.html - shard-hsw: [PASS][9] -> [FAIL][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-hsw8/igt@gem_cl...@many-handles-one-vma.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17184/shard-hsw2/igt@gem_cl...@many-handles-one-vma.html - shard-snb: [PASS][11] -> [FAIL][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-snb4/igt@gem_cl...@many-handles-one-vma.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17184/shard-snb5/igt@gem_cl...@many-handles-one-vma.html - shard-iclb: [PASS][13] -> [FAIL][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-iclb5/igt@gem_cl...@many-handles-one-vma.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17184/shard-iclb6/igt@gem_cl...@many-handles-one-vma.html * igt@gem_exec_balancer@bonded-imm: - shard-iclb: [PASS][15] -> [INCOMPLETE][16] +4 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-iclb6/igt@gem_exec_balan...@bonded-imm.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17184/shard-iclb1/igt@gem_exec_balan...@bonded-imm.html * igt@gem_exec_balancer@full-late: - shard-tglb: [PASS][17] -> [INCOMPLETE][18] +12 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-tglb8/igt@gem_exec_balan...@full-late.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17184/shard-tglb1/igt@gem_exec_balan...@full-late.html * igt@gem_exec_balancer@smoke: - shard-kbl: [PASS][19] -> [INCOMPLETE][20] +11 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-kbl7/igt@gem_exec_balan...@smoke.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17184/shard-kbl7/igt@gem_exec_balan...@smoke.html * igt@gem_media_fill: - shard-hsw: [PASS][21] -> [DMESG-FAIL][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-hsw6/igt@gem_media_fill.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17184/shard-hsw4/igt@gem_media_fill.html * igt@gem_mmap_gtt@cpuset-medium-copy-xy: - shard-skl: [PASS][23] -> [FAIL][24] +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-skl9/igt@gem_mmap_...@cpuset-medium-copy-xy.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17184/shard-skl2/igt@gem_mmap_...@cpuset-medium-copy-xy.html * igt@gem_render_copy@linear: - shard-hsw: [PASS][25] -> [DMESG-WARN][26] +3 similar issues [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-hsw2/igt@gem_render_c...@linear.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17184/shard-hsw1/igt@gem_render_c...@linear.html * igt@i915_selftest@live@gem_contexts: - shard-kbl: [PASS][27] -> [DMESG-WARN][28] [27]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for SAGV support for Gen12+ (rev13)
== Series Details == Series: SAGV support for Gen12+ (rev13) URL : https://patchwork.freedesktop.org/series/75129/ State : warning == Summary == $ dim checkpatch origin/drm-tip f121c205f975 drm/i915: Start passing latency as parameter 2cb942fadfcf drm/i915: Eliminate magic numbers "0" and "1" from color plane 9fd3eb581b6a drm/i915: Introduce skl_plane_wm_level accessor. 32a8f02d9693 drm/i915: Add intel_atomic_get_bw_*_state helpers b7d98af9e158 drm/i915: Extract gen specific functions from intel_can_enable_sagv b493687dd5af drm/i915: Add proper SAGV support for TGL+ -:512: WARNING:LONG_LINE: line over 100 characters #512: FILE: drivers/gpu/drm/i915/intel_pm.c:5838: + plane->base.base.id, plane->base.name, old_wm->sagv_wm0.min_ddb_alloc, total: 0 errors, 1 warnings, 0 checks, 358 lines checked 22bc551a31f5 drm/i915: Added required new PCode commands 86922c9a6deb drm/i915: Rename bw_state to new_bw_state 24c7d7d3c6b3 drm/i915: Restrict qgv points which don't have enough bandwidth. 893ba5a63c98 drm/i915: Enable SAGV support for Gen12 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for i915 lpsp support for lpsp igt (rev6)
== Series Details ==
Series: i915 lpsp support for lpsp igt (rev6)
URL : https://patchwork.freedesktop.org/series/74648/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8228_full -> Patchwork_17155_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_17155_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17155_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_17155_full:
### IGT changes ###
Possible regressions
* {igt@i915_pm_lpsp@non-edp-lpsp} (NEW):
- shard-tglb: NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17155/shard-tglb1/igt@i915_pm_l...@non-edp-lpsp.html
- shard-iclb: NOTRUN -> [SKIP][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17155/shard-iclb6/igt@i915_pm_l...@non-edp-lpsp.html
Warnings
* igt@i915_pm_lpsp@screens-disabled:
- shard-snb: [SKIP][3] ([fdo#109271]) -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-snb2/igt@i915_pm_l...@screens-disabled.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17155/shard-snb4/igt@i915_pm_l...@screens-disabled.html
New tests
-
New tests have been introduced between CI_DRM_8228_full and
Patchwork_17155_full:
### New IGT tests (1) ###
* igt@i915_pm_lpsp@non-edp-lpsp:
- Statuses : 4 pass(s) 3 skip(s)
- Exec time: [0.0, 0.77] s
Known issues
Here are the changes found in Patchwork_17155_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_busy@busy-vcs1:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112080]) +8 similar
issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb1/igt@gem_b...@busy-vcs1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17155/shard-iclb6/igt@gem_b...@busy-vcs1.html
* igt@gem_exec_schedule@implicit-both-bsd1:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276] / [i915#677]) +1
similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb2/igt@gem_exec_sched...@implicit-both-bsd1.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17155/shard-iclb6/igt@gem_exec_sched...@implicit-both-bsd1.html
* igt@gem_exec_schedule@in-order-bsd2:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +10 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb2/igt@gem_exec_sched...@in-order-bsd2.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17155/shard-iclb8/igt@gem_exec_sched...@in-order-bsd2.html
* igt@gem_exec_schedule@pi-distinct-iova-bsd:
- shard-iclb: [PASS][11] -> [SKIP][12] ([i915#677]) +1 similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb8/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17155/shard-iclb1/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
* igt@gem_exec_schedule@preempt-bsd:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#112146]) +5 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb3/igt@gem_exec_sched...@preempt-bsd.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17155/shard-iclb1/igt@gem_exec_sched...@preempt-bsd.html
* igt@gem_exec_suspend@basic-s3:
- shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180] /
[i915#93] / [i915#95])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-kbl3/igt@gem_exec_susp...@basic-s3.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17155/shard-kbl1/igt@gem_exec_susp...@basic-s3.html
* igt@i915_pm_rc6_residency@rc6-idle:
- shard-snb: [PASS][17] -> [TIMEOUT][18] ([i915#1526])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-snb6/igt@i915_pm_rc6_reside...@rc6-idle.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17155/shard-snb5/igt@i915_pm_rc6_reside...@rc6-idle.html
- shard-glk: [PASS][19] -> [FAIL][20] ([i915#1527])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-glk4/igt@i915_pm_rc6_reside...@rc6-idle.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17155/shard-glk4/igt@i915_pm_rc6_reside...@rc6-idle.html
* igt@i915_pm_rpm@fences-dpms:
- shard-glk: [PASS][21] -> [SKIP][22] ([fdo#109271]) +1 similar
issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-glk2/igt@i915_pm_...@fences-dpms.html
[22]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Revoke mmap before fence
== Series Details == Series: drm/i915: Revoke mmap before fence URL : https://patchwork.freedesktop.org/series/75470/ State : success == Summary == CI Bug Log - changes from CI_DRM_8247 -> Patchwork_17202 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17202/index.html Known issues Here are the changes found in Patchwork_17202 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@execlists: - fi-bxt-dsi: [PASS][1] -> [INCOMPLETE][2] ([i915#656]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17202/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html * igt@kms_flip@basic-flip-vs-dpms: - fi-skl-6770hq: [PASS][3] -> [SKIP][4] ([fdo#109271]) +18 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17202/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html Possible fixes * igt@gem_tiled_fence_blits@basic: - fi-blb-e6850: [DMESG-WARN][5] ([i915#1612]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/fi-blb-e6850/igt@gem_tiled_fence_bl...@basic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17202/fi-blb-e6850/igt@gem_tiled_fence_bl...@basic.html * igt@i915_module_load@reload: - fi-skl-6770hq: [DMESG-WARN][7] ([i915#203]) -> [PASS][8] +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/fi-skl-6770hq/igt@i915_module_l...@reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17202/fi-skl-6770hq/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@basic-rte: - fi-icl-dsi: [INCOMPLETE][9] ([i915#189]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/fi-icl-dsi/igt@i915_pm_...@basic-rte.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17202/fi-icl-dsi/igt@i915_pm_...@basic-rte.html * igt@i915_selftest@live@execlists: - fi-skl-guc: [INCOMPLETE][11] ([i915#656]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/fi-skl-guc/igt@i915_selftest@l...@execlists.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17202/fi-skl-guc/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@dp-edid-read: - fi-cml-u2: [FAIL][13] ([i915#976]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17202/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html Warnings * igt@kms_pipe_crc_basic@read-crc-pipe-c: - fi-skl-6770hq: [DMESG-WARN][15] ([i915#106]) -> [SKIP][16] ([fdo#109271]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8247/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17202/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#106]: https://gitlab.freedesktop.org/drm/intel/issues/106 [i915#1612]: https://gitlab.freedesktop.org/drm/intel/issues/1612 [i915#189]: https://gitlab.freedesktop.org/drm/intel/issues/189 [i915#203]: https://gitlab.freedesktop.org/drm/intel/issues/203 [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656 [i915#976]: https://gitlab.freedesktop.org/drm/intel/issues/976 Participating hosts (51 -> 45) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8247 -> Patchwork_17202 CI-20190529: 20190529 CI_DRM_8247: 4ceaa00bfb032d9f29a485596fbc02fdeab06bc9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5562: 4770480c8c1f105ff9225e8eb07b652ca954e06a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17202: fc8f69a629a3d787065ea17a3ad8cd91ae53429f @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == fc8f69a629a3 drm/i915: Revoke mmap before fence == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17202/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [v2,1/5] uaccess: Add user_read_access_begin/end and user_write_access_begin/end
== Series Details == Series: series starting with [v2,1/5] uaccess: Add user_read_access_begin/end and user_write_access_begin/end URL : https://patchwork.freedesktop.org/series/75471/ State : failure == Summary == Applying: uaccess: Add user_read_access_begin/end and user_write_access_begin/end Applying: uaccess: Selectively open read or write user access Applying: drm/i915/gem: Replace user_access_begin by user_write_access_begin Applying: powerpc/uaccess: Implement user_read_access_begin and user_write_access_begin Applying: uaccess: Rename user_access_begin/end() to user_full_access_begin/end() error: sha1 information is lacking or useless (arch/x86/include/asm/futex.h). error: could not build fake ancestor hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0005 uaccess: Rename user_access_begin/end() to user_full_access_begin/end() When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Avoid setting timer->expires to 0
== Series Details ==
Series: drm/i915: Avoid setting timer->expires to 0
URL : https://patchwork.freedesktop.org/series/75447/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8243_full -> Patchwork_17195_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17195_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17195_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_17195_full:
### IGT changes ###
Possible regressions
* igt@gem_tiled_swapping@non-threaded:
- shard-iclb: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-iclb1/igt@gem_tiled_swapp...@non-threaded.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17195/shard-iclb5/igt@gem_tiled_swapp...@non-threaded.html
- shard-glk: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-glk7/igt@gem_tiled_swapp...@non-threaded.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17195/shard-glk4/igt@gem_tiled_swapp...@non-threaded.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_wait@write-busy@vcs0}:
- shard-glk: [PASS][5] -> [FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-glk9/igt@gem_wait@write-b...@vcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17195/shard-glk9/igt@gem_wait@write-b...@vcs0.html
Known issues
Here are the changes found in Patchwork_17195_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#110854])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-iclb4/igt@gem_exec_balan...@smoke.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17195/shard-iclb6/igt@gem_exec_balan...@smoke.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-apl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17195/shard-apl1/igt@kms_cursor_...@pipe-a-cursor-suspend.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-hsw: [PASS][11] -> [INCOMPLETE][12] ([i915#61])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-hsw6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17195/shard-hsw2/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_draw_crc@draw-method-xrgb-mmap-gtt-untiled:
- shard-apl: [PASS][13] -> [FAIL][14] ([i915#52] / [i915#54] /
[i915#95])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-apl4/igt@kms_draw_...@draw-method-xrgb-mmap-gtt-untiled.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17195/shard-apl4/igt@kms_draw_...@draw-method-xrgb-mmap-gtt-untiled.html
* igt@kms_hdr@bpc-switch-dpms:
- shard-skl: [PASS][15] -> [FAIL][16] ([i915#1188])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-skl8/igt@kms_...@bpc-switch-dpms.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17195/shard-skl10/igt@kms_...@bpc-switch-dpms.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +5
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-kbl1/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17195/shard-kbl3/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145] / [i915#265])
+1 similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-skl1/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17195/shard-skl7/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html
* igt@kms_psr@psr2_sprite_blt:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +1 similar
issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-iclb2/igt@kms_psr@psr2_sprite_blt.html
[22]:
[Intel-gfx] [PATCH v21 09/10] drm/i915: Restrict qgv points which don't have enough bandwidth.
According to BSpec 53998, we should try to restrict qgv points, which can't provide enough bandwidth for desired display configuration. Currently we are just comparing against all of those and take minimum(worst case). v2: Fixed wrong PCode reply mask, removed hardcoded values. v3: Forbid simultaneous legacy SAGV PCode requests and restricting qgv points. Put the actual restriction to commit function, added serialization(thanks to Ville) to prevent commit being applied out of order in case of nonblocking and/or nomodeset commits. v4: - Minor code refactoring, fixed few typos(thanks to James Ausmus) - Change the naming of qgv point masking/unmasking functions(James Ausmus). - Simplify the masking/unmasking operation itself, as we don't need to mask only single point per request(James Ausmus) - Reject and stick to highest bandwidth point if SAGV can't be enabled(BSpec) v5: - Add new mailbox reply codes, which seems to happen during boot time for TGL and indicate that QGV setting is not yet available. v6: - Increase number of supported QGV points to be in sync with BSpec. v7: - Rebased and resolved conflict to fix build failure. - Fix NUM_QGV_POINTS to 8 and moved that to header file(James Ausmus) v8: - Don't report an error if we can't restrict qgv points, as SAGV can be disabled by BIOS, which is completely legal. So don't make CI panic. Instead if we detect that there is only 1 QGV point accessible just analyze if we can fit the required bandwidth requirements, but no need in restricting. v9: - Fix wrong QGV transition if we have 0 planes and no SAGV simultaneously. v10: - Fix CDCLK corruption, because of global state getting serialized without modeset, which caused copying of non-calculated cdclk to be copied to dev_priv(thanks to Ville for the hint). v11: - Remove unneeded headers and spaces(Matthew Roper) - Remove unneeded intel_qgv_info qi struct from bw check and zero out the needed one(Matthew Roper) - Changed QGV error message to have more clear meaning(Matthew Roper) - Use state->modeset_set instead of any_ms(Matthew Roper) - Moved NUM_SAGV_POINTS from i915_reg.h to i915_drv.h where it's used - Keep using crtc_state->hw.active instead of .enable(Matthew Roper) - Moved unrelated changes to other patch(using latency as parameter for plane wm calculation, moved to SAGV refactoring patch) v12: - Fix rebase conflict with own temporary SAGV/QGV fix. - Remove unnecessary mask being zero check when unmasking qgv points as this is completely legal(Matt Roper) - Check if we are setting the same mask as already being set in hardware to prevent error from PCode. - Fix error message when restricting/unrestricting qgv points to "mask/unmask" which sounds more accurate(Matt Roper) - Move sagv status setting to icl_get_bw_info from atomic check as this should be calculated only once.(Matt Roper) - Edited comments for the case when we can't enable SAGV and use only 1 QGV point with highest bandwidth to be more understandable.(Matt Roper) v13: - Moved max_data_rate in bw check to closer scope(Ville Syrjälä) - Changed comment for zero new_mask in qgv points masking function to better reflect reality(Ville Syrjälä) - Simplified bit mask operation in qgv points masking function (Ville Syrjälä) - Moved intel_qgv_points_mask closer to gen11 SAGV disabling, however this still can't be under modeset condition(Ville Syrjälä) - Packed qgv_points_mask as u8 and moved closer to pipe_sagv_mask (Ville Syrjälä) - Extracted PCode changes to separate patch.(Ville Syrjälä) - Now treat num_planes 0 same as 1 to avoid confusion and returning max_bw as 0, which would prevent choosing QGV point having max bandwidth in case if SAGV is not allowed, as per BSpec(Ville Syrjälä) - Do the actual qgv_points_mask swap in the same place as all other global state parts like cdclk are swapped. In the next patch, this all will be moved to bw state as global state, once new global state patch series from Ville lands v14: - Now using global state to serialize access to qgv points - Added global state locking back, otherwise we seem to read bw state in a wrong way. v15: - Added TODO comment for near atomic global state locking in bw code. v16: - Fixed intel_atomic_bw_* functions to be intel_bw_* as discussed with Jani Nikula. - Take bw_state_changed flag into use. v17: - Moved qgv point related manipulations next to SAGV code, as those are semantically related(Ville Syrjälä) - Renamed those into intel_sagv_(pre)|(post)_plane_update (Ville Syrjälä) v18: - Move sagv related calls from commit tail into intel_sagv_(pre)|(post)_plane_update(Ville
[Intel-gfx] ✗ Fi.CI.IGT: failure for SAGV support for Gen12+ (rev10)
== Series Details == Series: SAGV support for Gen12+ (rev10) URL : https://patchwork.freedesktop.org/series/75129/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8243_full -> Patchwork_17194_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17194_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17194_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17194_full: ### IGT changes ### Possible regressions * igt@gem_mmap_gtt@cpuset-medium-copy-xy: - shard-apl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-apl7/igt@gem_mmap_...@cpuset-medium-copy-xy.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17194/shard-apl2/igt@gem_mmap_...@cpuset-medium-copy-xy.html * igt@gem_mmap_gtt@hang: - shard-iclb: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-iclb2/igt@gem_mmap_...@hang.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17194/shard-iclb7/igt@gem_mmap_...@hang.html Known issues Here are the changes found in Patchwork_17194_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#110854]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-iclb4/igt@gem_exec_balan...@smoke.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17194/shard-iclb8/igt@gem_exec_balan...@smoke.html * igt@gem_tiled_swapping@non-threaded: - shard-apl: [PASS][7] -> [FAIL][8] ([i915#95]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-apl2/igt@gem_tiled_swapp...@non-threaded.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17194/shard-apl6/igt@gem_tiled_swapp...@non-threaded.html * igt@i915_selftest@live@requests: - shard-tglb: [PASS][9] -> [INCOMPLETE][10] ([i915#1531]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-tglb3/igt@i915_selftest@l...@requests.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17194/shard-tglb7/igt@i915_selftest@l...@requests.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-apl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17194/shard-apl1/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_draw_crc@draw-method-xrgb-mmap-gtt-untiled: - shard-apl: [PASS][13] -> [FAIL][14] ([i915#52] / [i915#54] / [i915#95]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-apl4/igt@kms_draw_...@draw-method-xrgb-mmap-gtt-untiled.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17194/shard-apl3/igt@kms_draw_...@draw-method-xrgb-mmap-gtt-untiled.html * igt@kms_flip@wf_vblank-ts-check: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#34]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-skl8/igt@kms_flip@wf_vblank-ts-check.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17194/shard-skl2/igt@kms_flip@wf_vblank-ts-check.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#1188]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-skl8/igt@kms_...@bpc-switch-dpms.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17194/shard-skl2/igt@kms_...@bpc-switch-dpms.html * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145] / [i915#265]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-skl5/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17194/shard-skl7/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html * igt@kms_psr@psr2_sprite_blt: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-iclb2/igt@kms_psr@psr2_sprite_blt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17194/shard-iclb7/igt@kms_psr@psr2_sprite_blt.html * igt@kms_setmode@basic: - shard-apl: [PASS][23] -> [FAIL][24] ([i915#31]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8243/shard-apl8/igt@kms_setm...@basic.html [24]:
[Intel-gfx] ✗ Fi.CI.BUILD: failure for SAGV support for Gen12+ (rev12)
== Series Details == Series: SAGV support for Gen12+ (rev12) URL : https://patchwork.freedesktop.org/series/75129/ State : failure == Summary == Applying: drm/i915: Start passing latency as parameter Applying: drm/i915: Eliminate magic numbers "0" and "1" from color plane Applying: drm/i915: Introduce skl_plane_wm_level accessor. Applying: drm/i915: Add intel_atomic_get_bw_*_state helpers Applying: drm/i915: Extract gen specific functions from intel_can_enable_sagv Applying: drm/i915: Add proper SAGV support for TGL+ Applying: drm/i915: Added required new PCode commands Applying: drm/i915: Rename bw_state to new_bw_state Applying: drm/i915: Restrict qgv points which don't have enough bandwidth. error: sha1 information is lacking or useless (drivers/gpu/drm/i915/display/intel_display.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0009 drm/i915: Restrict qgv points which don't have enough bandwidth. When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/5] powerpc/uaccess: Implement user_read_access_begin and user_write_access_begin
Add support for selective read or write user access with
user_read_access_begin/end and user_write_access_begin/end.
Signed-off-by: Christophe Leroy
Reviewed-by: Kees Cook
---
v2: no change
---
arch/powerpc/include/asm/book3s/32/kup.h | 4 ++--
arch/powerpc/include/asm/kup.h | 14 +-
arch/powerpc/include/asm/uaccess.h | 22 ++
3 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/32/kup.h
b/arch/powerpc/include/asm/book3s/32/kup.h
index 3c0ba22dc360..1617e73bee30 100644
--- a/arch/powerpc/include/asm/book3s/32/kup.h
+++ b/arch/powerpc/include/asm/book3s/32/kup.h
@@ -108,7 +108,7 @@ static __always_inline void allow_user_access(void __user
*to, const void __user
u32 addr, end;
BUILD_BUG_ON(!__builtin_constant_p(dir));
- BUILD_BUG_ON(dir == KUAP_CURRENT);
+ BUILD_BUG_ON(dir & ~KUAP_READ_WRITE);
if (!(dir & KUAP_WRITE))
return;
@@ -131,7 +131,7 @@ static __always_inline void prevent_user_access(void __user
*to, const void __us
BUILD_BUG_ON(!__builtin_constant_p(dir));
- if (dir == KUAP_CURRENT) {
+ if (dir & KUAP_CURRENT_WRITE) {
u32 kuap = current->thread.kuap;
if (unlikely(!kuap))
diff --git a/arch/powerpc/include/asm/kup.h b/arch/powerpc/include/asm/kup.h
index 92bcd1a26d73..c745ee41ad66 100644
--- a/arch/powerpc/include/asm/kup.h
+++ b/arch/powerpc/include/asm/kup.h
@@ -10,7 +10,9 @@
* Use the current saved situation instead of the to/from/size params.
* Used on book3s/32
*/
-#define KUAP_CURRENT 4
+#define KUAP_CURRENT_READ 4
+#define KUAP_CURRENT_WRITE 8
+#define KUAP_CURRENT (KUAP_CURRENT_READ | KUAP_CURRENT_WRITE)
#ifdef CONFIG_PPC64
#include
@@ -101,6 +103,16 @@ static inline void prevent_current_access_user(void)
prevent_user_access(NULL, NULL, ~0UL, KUAP_CURRENT);
}
+static inline void prevent_current_read_from_user(void)
+{
+ prevent_user_access(NULL, NULL, ~0UL, KUAP_CURRENT_READ);
+}
+
+static inline void prevent_current_write_to_user(void)
+{
+ prevent_user_access(NULL, NULL, ~0UL, KUAP_CURRENT_WRITE);
+}
+
#endif /* !__ASSEMBLY__ */
#endif /* _ASM_POWERPC_KUAP_H_ */
diff --git a/arch/powerpc/include/asm/uaccess.h
b/arch/powerpc/include/asm/uaccess.h
index 2f500debae21..4427d419eb1d 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -468,6 +468,28 @@ static __must_check inline bool user_access_begin(const
void __user *ptr, size_t
#define user_access_save prevent_user_access_return
#define user_access_restorerestore_user_access
+static __must_check inline bool
+user_read_access_begin(const void __user *ptr, size_t len)
+{
+ if (unlikely(!access_ok(ptr, len)))
+ return false;
+ allow_read_from_user(ptr, len);
+ return true;
+}
+#define user_read_access_begin user_read_access_begin
+#define user_read_access_end prevent_current_read_from_user
+
+static __must_check inline bool
+user_write_access_begin(const void __user *ptr, size_t len)
+{
+ if (unlikely(!access_ok(ptr, len)))
+ return false;
+ allow_write_to_user((void __user *)ptr, len);
+ return true;
+}
+#define user_write_access_beginuser_write_access_begin
+#define user_write_access_end prevent_current_write_to_user
+
#define unsafe_op_wrap(op, err) do { if (unlikely(op)) goto err; } while (0)
#define unsafe_get_user(x, p, e) unsafe_op_wrap(__get_user_allowed(x, p), e)
#define unsafe_put_user(x, p, e) unsafe_op_wrap(__put_user_allowed(x, p), e)
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/5] drm/i915/gem: Replace user_access_begin by user_write_access_begin
When i915_gem_execbuffer2_ioctl() is using user_access_begin(),
that's only to perform unsafe_put_user() so use
user_write_access_begin() in order to only open write access.
Signed-off-by: Christophe Leroy
Reviewed-by: Kees Cook
---
v2: Rebased (one part of the patch flies away)
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 36d069504836..b4c903308590 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2794,7 +2794,8 @@ i915_gem_execbuffer2_ioctl(struct drm_device *dev, void
*data,
* And this range already got effectively checked earlier
* when we did the "copy_from_user()" above.
*/
- if (!user_access_begin(user_exec_list, count *
sizeof(*user_exec_list)))
+ if (!user_write_access_begin(user_exec_list,
+count * sizeof(*user_exec_list)))
goto end;
for (i = 0; i < args->buffer_count; i++) {
@@ -2808,7 +2809,7 @@ i915_gem_execbuffer2_ioctl(struct drm_device *dev, void
*data,
end_user);
}
end_user:
- user_access_end();
+ user_write_access_end();
end:;
}
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/5] uaccess: Add user_read_access_begin/end and user_write_access_begin/end
Some architectures like powerpc64 have the capability to separate
read access and write access protection.
For get_user() and copy_from_user(), powerpc64 only open read access.
For put_user() and copy_to_user(), powerpc64 only open write access.
But when using unsafe_get_user() or unsafe_put_user(),
user_access_begin open both read and write.
Other architectures like powerpc book3s 32 bits only allow write
access protection. And on this architecture protection is an heavy
operation as it requires locking/unlocking per segment of 256Mbytes.
On those architecture it is therefore desirable to do the unlocking
only for write access. (Note that book3s/32 ranges from very old
powermac from the 90's with powerpc 601 processor, till modern
ADSL boxes with PowerQuicc II processors for instance so it
is still worth considering.)
In order to avoid any risk based of hacking some variable parameters
passed to user_access_begin/end that would allow hacking and
leaving user access open or opening too much, it is preferable to
use dedicated static functions that can't be overridden.
Add a user_read_access_begin and user_read_access_end to only open
read access.
Add a user_write_access_begin and user_write_access_end to only open
write access.
By default, when undefined, those new access helpers default on the
existing user_access_begin and user_access_end.
Signed-off-by: Christophe Leroy
Reviewed-by: Kees Cook
---
v2: no change in this patch. See each patch for related changes.
v1 at https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=168174
This series is based on the discussion we had in January, see
https://patchwork.ozlabs.org/patch/1227926/ . I tried to
take into account all remarks, especially @hpa 's remark to use
a fixed API on not base the relocking on a magic id returned at
unlocking.
This series is awaited for implementing selective lkdtm test to
test powerpc64 independant read and write protection, see
https://patchwork.ozlabs.org/patch/1231765/
Signed-off-by: Christophe Leroy
---
include/linux/uaccess.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
index 67f016010aad..9861c89f93be 100644
--- a/include/linux/uaccess.h
+++ b/include/linux/uaccess.h
@@ -378,6 +378,14 @@ extern long strnlen_unsafe_user(const void __user
*unsafe_addr, long count);
static inline unsigned long user_access_save(void) { return 0UL; }
static inline void user_access_restore(unsigned long flags) { }
#endif
+#ifndef user_write_access_begin
+#define user_write_access_begin user_access_begin
+#define user_write_access_end user_access_end
+#endif
+#ifndef user_read_access_begin
+#define user_read_access_begin user_access_begin
+#define user_read_access_end user_access_end
+#endif
#ifdef CONFIG_HARDENED_USERCOPY
void usercopy_warn(const char *name, const char *detail, bool to_user,
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/5] uaccess: Selectively open read or write user access
When opening user access to only perform reads, only open read access.
When opening user access to only perform writes, only open write
access.
Signed-off-by: Christophe Leroy
Reviewed-by: Kees Cook
---
v2: Fixed a mismatched use of _read_ and _write_ in compat_get_bitmap()
and compat_put_bitmap()
---
fs/readdir.c| 12 ++--
kernel/compat.c | 12 ++--
kernel/exit.c | 12 ++--
lib/strncpy_from_user.c | 4 ++--
lib/strnlen_user.c | 4 ++--
lib/usercopy.c | 6 +++---
6 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/fs/readdir.c b/fs/readdir.c
index de2eceffdee8..ed6aaad451aa 100644
--- a/fs/readdir.c
+++ b/fs/readdir.c
@@ -242,7 +242,7 @@ static int filldir(struct dir_context *ctx, const char
*name, int namlen,
return -EINTR;
dirent = buf->current_dir;
prev = (void __user *) dirent - prev_reclen;
- if (!user_access_begin(prev, reclen + prev_reclen))
+ if (!user_write_access_begin(prev, reclen + prev_reclen))
goto efault;
/* This might be 'dirent->d_off', but if so it will get overwritten */
@@ -251,14 +251,14 @@ static int filldir(struct dir_context *ctx, const char
*name, int namlen,
unsafe_put_user(reclen, >d_reclen, efault_end);
unsafe_put_user(d_type, (char __user *) dirent + reclen - 1,
efault_end);
unsafe_copy_dirent_name(dirent->d_name, name, namlen, efault_end);
- user_access_end();
+ user_write_access_end();
buf->current_dir = (void __user *)dirent + reclen;
buf->prev_reclen = reclen;
buf->count -= reclen;
return 0;
efault_end:
- user_access_end();
+ user_write_access_end();
efault:
buf->error = -EFAULT;
return -EFAULT;
@@ -327,7 +327,7 @@ static int filldir64(struct dir_context *ctx, const char
*name, int namlen,
return -EINTR;
dirent = buf->current_dir;
prev = (void __user *)dirent - prev_reclen;
- if (!user_access_begin(prev, reclen + prev_reclen))
+ if (!user_write_access_begin(prev, reclen + prev_reclen))
goto efault;
/* This might be 'dirent->d_off', but if so it will get overwritten */
@@ -336,7 +336,7 @@ static int filldir64(struct dir_context *ctx, const char
*name, int namlen,
unsafe_put_user(reclen, >d_reclen, efault_end);
unsafe_put_user(d_type, >d_type, efault_end);
unsafe_copy_dirent_name(dirent->d_name, name, namlen, efault_end);
- user_access_end();
+ user_write_access_end();
buf->prev_reclen = reclen;
buf->current_dir = (void __user *)dirent + reclen;
@@ -344,7 +344,7 @@ static int filldir64(struct dir_context *ctx, const char
*name, int namlen,
return 0;
efault_end:
- user_access_end();
+ user_write_access_end();
efault:
buf->error = -EFAULT;
return -EFAULT;
diff --git a/kernel/compat.c b/kernel/compat.c
index 843dd17e6078..b8d2800bb4b7 100644
--- a/kernel/compat.c
+++ b/kernel/compat.c
@@ -199,7 +199,7 @@ long compat_get_bitmap(unsigned long *mask, const
compat_ulong_t __user *umask,
bitmap_size = ALIGN(bitmap_size, BITS_PER_COMPAT_LONG);
nr_compat_longs = BITS_TO_COMPAT_LONGS(bitmap_size);
- if (!user_access_begin(umask, bitmap_size / 8))
+ if (!user_read_access_begin(umask, bitmap_size / 8))
return -EFAULT;
while (nr_compat_longs > 1) {
@@ -211,11 +211,11 @@ long compat_get_bitmap(unsigned long *mask, const
compat_ulong_t __user *umask,
}
if (nr_compat_longs)
unsafe_get_user(*mask, umask++, Efault);
- user_access_end();
+ user_read_access_end();
return 0;
Efault:
- user_access_end();
+ user_read_access_end();
return -EFAULT;
}
@@ -228,7 +228,7 @@ long compat_put_bitmap(compat_ulong_t __user *umask,
unsigned long *mask,
bitmap_size = ALIGN(bitmap_size, BITS_PER_COMPAT_LONG);
nr_compat_longs = BITS_TO_COMPAT_LONGS(bitmap_size);
- if (!user_access_begin(umask, bitmap_size / 8))
+ if (!user_write_access_begin(umask, bitmap_size / 8))
return -EFAULT;
while (nr_compat_longs > 1) {
@@ -239,10 +239,10 @@ long compat_put_bitmap(compat_ulong_t __user *umask,
unsigned long *mask,
}
if (nr_compat_longs)
unsafe_put_user((compat_ulong_t)*mask, umask++, Efault);
- user_access_end();
+ user_write_access_end();
return 0;
Efault:
- user_access_end();
+ user_write_access_end();
return -EFAULT;
}
diff --git a/kernel/exit.c b/kernel/exit.c
index d70d47159640..61b2f7a85079 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -1555,7 +1555,7 @@ SYSCALL_DEFINE5(waitid, int, which, pid_t, upid, struct
siginfo __user *,
if (!infop)
return err;
- if (!user_access_begin(infop,
[Intel-gfx] [PATCH v2 5/5] uaccess: Rename user_access_begin/end() to user_full_access_begin/end()
Now we have user_read_access_begin() and user_write_access_begin()
in addition to user_access_begin().
Make it explicit that user_access_begin() provides both read and
write by renaming it user_full_access_begin(). And the same for
user_access_end() which becomes user_full_access_end().
Done with following command, then hand splitted two too long lines.
sed -i s/user_access_begin/user_full_access_begin/g `git grep -l
user_access_begin`
Signed-off-by: Christophe Leroy
---
v2: New, based on remark from Al Viro.
---
arch/powerpc/include/asm/uaccess.h | 5 +++--
arch/x86/include/asm/futex.h | 4 ++--
arch/x86/include/asm/uaccess.h | 7 ---
include/linux/uaccess.h| 8
4 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/include/asm/uaccess.h
b/arch/powerpc/include/asm/uaccess.h
index 4427d419eb1d..7fe799e081f2 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -456,14 +456,15 @@ extern long __copy_from_user_flushcache(void *dst, const
void __user *src,
extern void memcpy_page_flushcache(char *to, struct page *page, size_t offset,
size_t len);
-static __must_check inline bool user_access_begin(const void __user *ptr,
size_t len)
+static __must_check inline bool
+user_full_access_begin(const void __user *ptr, size_t len)
{
if (unlikely(!access_ok(ptr, len)))
return false;
allow_read_write_user((void __user *)ptr, ptr, len);
return true;
}
-#define user_access_begin user_access_begin
+#define user_full_access_begin user_full_access_begin
#define user_access_endprevent_current_access_user
#define user_access_save prevent_user_access_return
#define user_access_restorerestore_user_access
diff --git a/arch/x86/include/asm/futex.h b/arch/x86/include/asm/futex.h
index f9c00110a69a..9eefea374bd4 100644
--- a/arch/x86/include/asm/futex.h
+++ b/arch/x86/include/asm/futex.h
@@ -56,7 +56,7 @@ do {
\
static __always_inline int arch_futex_atomic_op_inuser(int op, int oparg, int
*oval,
u32 __user *uaddr)
{
- if (!user_access_begin(uaddr, sizeof(u32)))
+ if (!user_full_access_begin(uaddr, sizeof(u32)))
return -EFAULT;
switch (op) {
@@ -92,7 +92,7 @@ static inline int futex_atomic_cmpxchg_inatomic(u32 *uval,
u32 __user *uaddr,
{
int ret = 0;
- if (!user_access_begin(uaddr, sizeof(u32)))
+ if (!user_full_access_begin(uaddr, sizeof(u32)))
return -EFAULT;
asm volatile("\n"
"1:\t" LOCK_PREFIX "cmpxchgl %4, %2\n"
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index d8f283b9a569..8776e815f215 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -473,16 +473,17 @@ extern struct movsl_mask {
* The "unsafe" user accesses aren't really "unsafe", but the naming
* is a big fat warning: you have to not only do the access_ok()
* checking before using them, but you have to surround them with the
- * user_access_begin/end() pair.
+ * user_full_access_begin/end() pair.
*/
-static __must_check __always_inline bool user_access_begin(const void __user
*ptr, size_t len)
+static __must_check __always_inline bool
+user_full_access_begin(const void __user *ptr, size_t len)
{
if (unlikely(!access_ok(ptr,len)))
return 0;
__uaccess_begin_nospec();
return 1;
}
-#define user_access_begin(a,b) user_access_begin(a,b)
+#define user_full_access_begin(a,b)user_full_access_begin(a,b)
#define user_access_end() __uaccess_end()
#define user_access_save() smap_save()
diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
index 9861c89f93be..5be9bc930342 100644
--- a/include/linux/uaccess.h
+++ b/include/linux/uaccess.h
@@ -368,8 +368,8 @@ extern long strnlen_unsafe_user(const void __user
*unsafe_addr, long count);
#define probe_kernel_address(addr, retval) \
probe_kernel_read(, addr, sizeof(retval))
-#ifndef user_access_begin
-#define user_access_begin(ptr,len) access_ok(ptr, len)
+#ifndef user_full_access_begin
+#define user_full_access_begin(ptr,len) access_ok(ptr, len)
#define user_access_end() do { } while (0)
#define unsafe_op_wrap(op, err) do { if (unlikely(op)) goto err; } while (0)
#define unsafe_get_user(x,p,e) unsafe_op_wrap(__get_user(x,p),e)
@@ -379,11 +379,11 @@ static inline unsigned long user_access_save(void) {
return 0UL; }
static inline void user_access_restore(unsigned long flags) { }
#endif
#ifndef user_write_access_begin
-#define user_write_access_begin user_access_begin
+#define user_write_access_begin user_full_access_begin
#define user_write_access_end user_access_end
#endif
#ifndef user_read_access_begin
-#define user_read_access_begin user_access_begin
+#define user_read_access_begin
Re: [Intel-gfx] [PATCH] drm/i915/perf: Do not clear pollin for small user read buffers
Quoting Ashutosh Dixit (2020-04-03 02:01:20) > It is wrong to block the user thread in the next poll when OA data is > already available which could not fit in the user buffer provided in > the previous read. In several cases the exact user buffer size is not > known. Blocking user space in poll can lead to data loss when the > buffer size used is smaller than the available data. > > This change fixes this issue and allows user space to read all OA data > even when using a buffer size smaller than the available data using > multiple non-blocking reads rather than staying blocked in poll till > the next timer interrupt. > > v2: Fix ret value for blocking reads (Umesh) > v3: Mistake during patch send (Ashutosh) > v4: Remove -EAGAIN from comment (Umesh) > v5: Improve condition for clearing pollin and return (Lionel) > v6: Improve blocking read loop and other cleanups (Lionel) > v7: Added Cc stable > > Cc: Umesh Nerlige Ramappa > Cc: > Reviewed-by: Lionel Landwerlin > Signed-off-by: Ashutosh Dixit Did you manage to devise a test case? It is nice (some might say important) to pair a patch for stable with its regression test. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/perf: Do not clear pollin for small user read buffers (rev7)
== Series Details ==
Series: drm/i915/perf: Do not clear pollin for small user read buffers (rev7)
URL : https://patchwork.freedesktop.org/series/75085/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8242_full -> Patchwork_17191_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17191_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17191_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_17191_full:
### IGT changes ###
Possible regressions
* igt@gem_mmap_gtt@cpuset-big-copy-odd:
- shard-skl: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8242/shard-skl6/igt@gem_mmap_...@cpuset-big-copy-odd.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17191/shard-skl8/igt@gem_mmap_...@cpuset-big-copy-odd.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@sysfs_timeslice_duration@timeout@vcs0}:
- shard-skl: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8242/shard-skl1/igt@sysfs_timeslice_duration@time...@vcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17191/shard-skl7/igt@sysfs_timeslice_duration@time...@vcs0.html
### Piglit changes ###
Possible regressions
* spec@!opengl 1.1@max-texture-size (NEW):
- pig-snb-2600: NOTRUN -> [INCOMPLETE][5]
[5]: None
New tests
-
New tests have been introduced between CI_DRM_8242_full and
Patchwork_17191_full:
### New IGT tests (1) ###
* igt@perf_pmu@faulting-read:
- Statuses :
- Exec time: [None] s
### New Piglit tests (1) ###
* spec@!opengl 1.1@max-texture-size:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_17191_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_tiled_swapping@non-threaded:
- shard-kbl: [PASS][6] -> [FAIL][7] ([i915#93] / [i915#95])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8242/shard-kbl7/igt@gem_tiled_swapp...@non-threaded.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17191/shard-kbl3/igt@gem_tiled_swapp...@non-threaded.html
* igt@gem_workarounds@suspend-resume-context:
- shard-apl: [PASS][8] -> [DMESG-WARN][9] ([i915#180] / [i915#95])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8242/shard-apl2/igt@gem_workarou...@suspend-resume-context.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17191/shard-apl4/igt@gem_workarou...@suspend-resume-context.html
* igt@i915_selftest@live@execlists:
- shard-apl: [PASS][10] -> [INCOMPLETE][11] ([i915#656])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8242/shard-apl3/igt@i915_selftest@l...@execlists.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17191/shard-apl1/igt@i915_selftest@l...@execlists.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-apl: [PASS][12] -> [DMESG-WARN][13] ([i915#180]) +2
similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8242/shard-apl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17191/shard-apl8/igt@kms_cursor_...@pipe-c-cursor-suspend.html
* igt@kms_draw_crc@draw-method-xrgb-mmap-gtt-untiled:
- shard-apl: [PASS][14] -> [FAIL][15] ([i915#52] / [i915#54] /
[i915#95]) +1 similar issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8242/shard-apl2/igt@kms_draw_...@draw-method-xrgb-mmap-gtt-untiled.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17191/shard-apl4/igt@kms_draw_...@draw-method-xrgb-mmap-gtt-untiled.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-kbl: [PASS][16] -> [DMESG-WARN][17] ([i915#180] /
[i915#93] / [i915#95])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8242/shard-kbl1/igt@kms_fbcon_...@fbc-suspend.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17191/shard-kbl6/igt@kms_fbcon_...@fbc-suspend.html
* igt@kms_flip@2x-flip-vs-expired-vblank:
- shard-glk: [PASS][18] -> [FAIL][19] ([i915#79])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8242/shard-glk1/igt@kms_f...@2x-flip-vs-expired-vblank.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17191/shard-glk2/igt@kms_f...@2x-flip-vs-expired-vblank.html
* igt@kms_flip@plain-flip-fb-recreate:
- shard-skl:
[Intel-gfx] [PATCH] drm/i915: Revoke mmap before fence
Make sure we revoke the user's mmaps of this vma to force them to take a
pagefault *before* we remove the associated aperture detiling register.
Fixes: 0d86ee35097a ("drm/i915/gt: Make fence revocation unequivocal")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_vma.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 4cdd883f9d66..42b2f24c8568 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1258,6 +1258,9 @@ int __i915_vma_unbind(struct i915_vma *vma)
GEM_BUG_ON(i915_vma_is_active(vma));
if (i915_vma_is_map_and_fenceable(vma)) {
+ /* Force a pagefault for domain tracking on next user access */
+ i915_vma_revoke_mmap(vma);
+
/*
* Check that we have flushed all writes through the GGTT
* before the unbind, other due to non-strict nature of those
@@ -1276,9 +1279,6 @@ int __i915_vma_unbind(struct i915_vma *vma)
/* release the fence reg _after_ flushing */
i915_vma_revoke_fence(vma);
- /* Force a pagefault for domain tracking on next user access */
- i915_vma_revoke_mmap(vma);
-
__i915_vma_iounmap(vma);
clear_bit(I915_VMA_CAN_FENCE_BIT, __i915_vma_flags(vma));
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v21 06/10] drm/i915: Add proper SAGV support for TGL+
Let's refactor the whole SAGV logic, moving the main calculations from intel_can_enable_sagv to intel_compute_sagv_mask, which also handles this in a unified way calling gen specific functions to evaluate if SAGV is allowed for each crtc. If crtc sagv mask have been changed we serialize access and modify global state. intel_can_enable_sagv now uses bw_state which stores all information related to SAGV and is now a trivial helper. v2: - Rework watermark calculation algorithm to attempt to calculate Level 0 watermark with added sagv block time latency and check if it fits in DBuf in order to determine if SAGV can be enabled already at this stage, just as BSpec 49325 states. if that fails rollback to usual Level 0 latency and disable SAGV. - Remove unneeded tabs(James Ausmus) v3: Rebased the patch v4: - Added back interlaced check for Gen12 and added separate function for TGL SAGV check (thanks to James Ausmus for spotting) - Removed unneeded gen check - Extracted Gen12 SAGV decision making code to a separate function from skl_compute_wm v5: - Added SAGV global state to dev_priv, because we need to track all pipes, not only those in atomic state. Each pipe has now correspondent bit mask reflecting, whether it can tolerate SAGV or not(thanks to Ville Syrjala for suggestions). - Now using active flag instead of enable in crc usage check. v6: - Fixed rebase conflicts v7: - kms_cursor_legacy seems to get broken because of multiple memcpy calls when copying level 0 water marks for enabled SAGV, to fix this now simply using that field right away, without copying, for that introduced a new wm_level accessor which decides which wm_level to return based on SAGV state. v8: - Protect crtc_sagv_mask same way as we do for other global state changes: i.e check if changes are needed, then grab all crtc locks to serialize the changes(Ville Syrjälä) - Add crtc_sagv_mask caching in order to avoid needless recalculations (Matthew Roper) - Put back Gen12 SAGV switch in order to get it enabled in separate patch(Matthew Roper) - Rename *_set_sagv_mask to *_compute_sagv_mask(Matthew Roper) - Check if there are no active pipes in intel_can_enable_sagv instead of platform specific functions(Matthew Roper), same for intel_has_sagv check. v9 - Switched to u8 for crtc_sagv_mask(Ville Syrjälä) - crtc_sagv_mask now is pipe_sagv_mask(Ville Syrjälä) - Extracted sagv checking logic from skl/icl/tgl_compute_sagv_mask - Extracted skl_plane_wm_level function and passing latency to separate patches(Ville Syrjälä) - Removed part of unneeded copy-paste from tgl_check_pipe_fits_sagv_wm (Ville Syrjälä) - Now using simple assignment for sagv_wm0 as it contains only pod types and no pointers(Ville Syrjälä) - Fixed intel_can_enable_sagv not to do double duty, now it only check SAGV bits by ANDing those between local and global state. The SAGV masks are now computed after watermarks are available, in order to be able to figure out if ddb ranges are fitting nicely. (Ville Syrjälä) - Now having uv_sagv_wm0 and sagv_wm0, otherwise we have wrong logic when using skl_plane_wm_level accessor, as we had previously for Gen11+ color plane and regular wm levels, so probably both has to be recalculated with additional SAGV block time for Level 0. v10: - Starting to use new global state for storing pipe_sagv_mask v11: - Fixed rebase conflict with recent drm-tip - Check if we really need to recalculate SAGV mask, otherwise bail out without making any changes. - Use cached SAGV result, instead of recalculating it everytime, if bw_state hasn't changed. v12: - Removed WARN from intel_can_enable_sagv, in some of the commits if we don't recalculated watermarks, bw_state is not recalculated, thus leading to SAGV state not recalculated by the commit state, which is still calling intel_can_enable_sagv function. Fix that by just analyzing the current global bw_state object - because we simply have no other objects related to that. v13: - Rebased, fixed warnings regarding long lines - Changed function call sites from intel_atomic_bw* to intel_wb_* as was suggested.(Jani Nikula) - Taken ddb_state_changed and bw_state_changed into use. v14: - total_affected_planes is no longer needed to check for ddb changes, just as active_pipe_changes. v15: - Fixed stupid mistake with uninitialized crtc in skl_compute_sagv_mask. v16: - Convert pipe_sagv_mask to pipe_sagv_reject and now using inverted flag to indicate SAGV readiness for the pipe(Ville Syrjälä) - Added return value to intel_compute_sagv_mask which call intel_atomic_serialize_global_state in order to properly propagate EDEADLCK
[Intel-gfx] [PATCH v21 02/10] drm/i915: Eliminate magic numbers "0" and "1" from color plane
According to many computer science sources - magic values
in code _are_ _bad_. For many reasons: the reason is that "0"
or "1" or whatever magic values confuses and doesn't give any
info why this parameter is this value and what it's meaning
is.
I renamed "0" to COLOR_PLANE_Y and "1" to COLOR_PLANE_UV,
because we in fact already use this naming in many other places
and function names, when dealing with color planes.
v2: Removed long line to make checkpatch happy.
Signed-off-by: Stanislav Lisovskiy
---
.../drm/i915/display/intel_display_types.h| 5 +++
drivers/gpu/drm/i915/intel_pm.c | 42 ++-
2 files changed, 27 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 176ab5f1e867..523e0444b373 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -682,6 +682,11 @@ struct skl_plane_wm {
bool is_planar;
};
+enum color_plane {
+ COLOR_PLANE_Y,
+ COLOR_PLANE_UV
+};
+
struct skl_pipe_wm {
struct skl_plane_wm planes[I915_MAX_PLANES];
};
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b632b6bb9c3e..176a28d71822 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4013,7 +4013,7 @@ static int skl_compute_wm_params(const struct
intel_crtc_state *crtc_state,
int width, const struct drm_format_info
*format,
u64 modifier, unsigned int rotation,
u32 plane_pixel_rate, struct skl_wm_params *wp,
-int color_plane);
+enum color_plane);
static void skl_compute_plane_wm(const struct intel_crtc_state *crtc_state,
int level,
unsigned int latency,
@@ -4035,7 +4035,7 @@ skl_cursor_allocation(const struct intel_crtc_state
*crtc_state,
drm_format_info(DRM_FORMAT_ARGB),
DRM_FORMAT_MOD_LINEAR,
DRM_MODE_ROTATE_0,
- crtc_state->pixel_rate, , 0);
+ crtc_state->pixel_rate, , COLOR_PLANE_Y);
drm_WARN_ON(_priv->drm, ret);
for (level = 0; level <= max_level; level++) {
@@ -4431,7 +4431,7 @@ static u8 skl_compute_dbuf_slices(const struct
intel_crtc_state *crtc_state,
static u64
skl_plane_relative_data_rate(const struct intel_crtc_state *crtc_state,
const struct intel_plane_state *plane_state,
-int color_plane)
+enum color_plane color_plane)
{
struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
const struct drm_framebuffer *fb = plane_state->hw.fb;
@@ -4446,7 +4446,7 @@ skl_plane_relative_data_rate(const struct
intel_crtc_state *crtc_state,
if (plane->id == PLANE_CURSOR)
return 0;
- if (color_plane == 1 &&
+ if (color_plane == COLOR_PLANE_UV &&
!intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier))
return 0;
@@ -4459,7 +4459,7 @@ skl_plane_relative_data_rate(const struct
intel_crtc_state *crtc_state,
height = drm_rect_height(_state->uapi.src) >> 16;
/* UV plane does 1/2 pixel sub-sampling */
- if (color_plane == 1) {
+ if (color_plane == COLOR_PLANE_UV) {
width /= 2;
height /= 2;
}
@@ -4489,12 +4489,12 @@ skl_get_total_relative_data_rate(struct
intel_crtc_state *crtc_state,
u64 rate;
/* packed/y */
- rate = skl_plane_relative_data_rate(crtc_state, plane_state, 0);
+ rate = skl_plane_relative_data_rate(crtc_state, plane_state,
COLOR_PLANE_Y);
plane_data_rate[plane_id] = rate;
total_data_rate += rate;
/* uv-plane */
- rate = skl_plane_relative_data_rate(crtc_state, plane_state, 1);
+ rate = skl_plane_relative_data_rate(crtc_state, plane_state,
COLOR_PLANE_UV);
uv_plane_data_rate[plane_id] = rate;
total_data_rate += rate;
}
@@ -4516,7 +4516,7 @@ icl_get_total_relative_data_rate(struct intel_crtc_state
*crtc_state,
u64 rate;
if (!plane_state->planar_linked_plane) {
- rate = skl_plane_relative_data_rate(crtc_state,
plane_state, 0);
+ rate = skl_plane_relative_data_rate(crtc_state,
plane_state, COLOR_PLANE_Y);
plane_data_rate[plane_id] = rate;
total_data_rate += rate;
} else {
@@ -4533,12 +4533,14 @@
Re: [Intel-gfx] [PATCH 01/44] drivers/base: Always release devres on device_del
On Fri, Apr 3, 2020 at 5:15 PM Daniel Vetter wrote: > > On Fri, Apr 3, 2020 at 5:06 PM Greg Kroah-Hartman > wrote: > > > > On Fri, Apr 03, 2020 at 04:47:04PM +0200, Daniel Vetter wrote: > > > On Fri, Apr 3, 2020 at 4:17 PM Greg Kroah-Hartman > > > wrote: > > > > > > > > On Fri, Apr 03, 2020 at 03:57:45PM +0200, Daniel Vetter wrote: > > > > > In drm we've added nice drm_device (the main gpu driver thing, which > > > > > also represents the userspace interfaces and has everything else > > > > > dangling off it) init functions using devres, devm_drm_dev_init and > > > > > soon devm_drm_dev_alloc (this patch series adds that). > > > > > > > > > > A slight trouble is that drm_device itself holds a reference on the > > > > > struct device it's sitting on top (for sysfs links and dmesg debug and > > > > > lots of other things), so there's a reference loop. For real drivers > > > > > this is broken at remove/unplug time, where all devres resources are > > > > > released device_release_driver(), before the final device reference is > > > > > dropped. So far so good. > > > > > > > > > > There's 2 exceptions: > > > > > - drm/vkms|vgem: Virtual drivers for which we create a fake/virtual > > > > > platform device to make them look more like normal devices to > > > > > userspace. These aren't drivers in the driver model sense, we simple > > > > > create a platform_device and register it. > > > > > > > > That's a horrid abuse of platform devices, just use a "virtual" device > > > > please, create/remove it when you need it, and all should be fine. > > > > > > > > > - drm/i915/selftests, where we create minimal mock devices, and again > > > > > the selftests aren't proper drivers in the driver model sense. > > > > > > > > Again, virtual devices are best to use for this. > > > > > > Hm yeah, I guess we should fix that. i915 selftests do use raw struct > > > device though, and it's not really the problem. > > > > > > > > For these two cases the reference loop isn't broken, because devres is > > > > > only cleaned up when the last device reference is dropped. But that's > > > > > not happening, because the drm_device holds that last struct device > > > > > reference. > > > > > > > > > > Thus far this wasn't a problem since the above cases simply > > > > > hand-rolled their cleanup code. But I want to convert all drivers over > > > > > to the devm_ versions, hence it would be really nice if these > > > > > virtual/fake/mock uses-cases could also be managed with devres > > > > > cleanup. > > > > > > > > > > I see three possible approaches: > > > > > > > > > > - Clean up devres from device_del (or platform_device_unregister) even > > > > > when no driver is bound. This seems like the simplest solution, but > > > > > also the one with the widest impact, and what this patch implements. > > > > > We might want to include more of the cleanup than just > > > > > devres_release_all, but this is all I need to get my use case going. > > > > > > > > After device_del, you should never be using that structure again anyway. > > > > So why is there any "resource leak"? You can't recycle the structure, > > > > and you can't assign it to anything else, so eventually you have to do > > > > a final put on the thing, which will free up the resources. > > > > > > I guess I should have spent more time explaining this. There's two > > > references involved: > > > > > > - drm_device->dev points at the underlying struct device. The > > > drm_device holds a reference until it's fully cleaned up, so that we > > > can do nice stuff like use dev_ versions of printk functions, and you > > > always know that there's not going to be a use-after free. > > > > > > - now the other dependency is that as long as the device exists (not > > > just in memory, but in the device model, i.e. between device_add() and > > > device_del()) the drm_device should exist. So what we do in the > > > bus-specific remove/disconnect callback is that we call > > > drm_dev_unregister(). This drops the drm_device refcount that the drm > > > chardev was holding, to make sure that an open() on the chardev can > > > actually get at the memory without going boom. Then after the > > > drm_dev_unregister, again in the remove/disconnect callback of th > > > driver, there's a drm_dev_put(). Which might or might not be the final > > > drm_dev_put(), since if there's currently some open fd we keep the > > > refcount elevated, to avoid oopses and fun stuff like that. And > > > drm_device pointers get shared very widely, thanks to fun stuff like > > > dma_buf buffer sharing and dma_fence hw syncpt sharing across > > > processes and drivers. > > > > > > Once the final drm_dev_put() is called we also end up calling > > > put_device() and everything is happy. > > > > > > So far so good. > > > > > > Now the problem is that refcount is hard, and most drm drivers get it > > > wrong in some fashion or another, so I'm trying to solve all this with > > > more magic. > > > > Wait,
Re: [Intel-gfx] [PATCH] drm/i915: Avoid setting timer->expires to 0
On 03/04/2020 08:36, Chris Wilson wrote: We use timer->expires == 0 to detect if a timer had been cancelled, but it's a valid expiration we could set. Just skip using 0 and set the expiry for the next jiffie. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_utils.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_utils.c b/drivers/gpu/drm/i915/i915_utils.c index 029854ae65fc..9769d278e800 100644 --- a/drivers/gpu/drm/i915/i915_utils.c +++ b/drivers/gpu/drm/i915/i915_utils.c @@ -101,5 +101,5 @@ void set_timer_ms(struct timer_list *t, unsigned long timeout) */ barrier(); - mod_timer(t, jiffies + timeout); + mod_timer(t, jiffies + timeout ?: 1); } "Glitch in the matrix" type workaround for timeslicing and preemption timeout, at the moment at least. No big deal given the frequency of the event and low accuracy requirements. But since it is a generic helper I think we need a comment pointing that out. With that: Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/44] drivers/base: Always release devres on device_del
On Fri, Apr 3, 2020 at 5:06 PM Greg Kroah-Hartman wrote: > > On Fri, Apr 03, 2020 at 04:47:04PM +0200, Daniel Vetter wrote: > > On Fri, Apr 3, 2020 at 4:17 PM Greg Kroah-Hartman > > wrote: > > > > > > On Fri, Apr 03, 2020 at 03:57:45PM +0200, Daniel Vetter wrote: > > > > In drm we've added nice drm_device (the main gpu driver thing, which > > > > also represents the userspace interfaces and has everything else > > > > dangling off it) init functions using devres, devm_drm_dev_init and > > > > soon devm_drm_dev_alloc (this patch series adds that). > > > > > > > > A slight trouble is that drm_device itself holds a reference on the > > > > struct device it's sitting on top (for sysfs links and dmesg debug and > > > > lots of other things), so there's a reference loop. For real drivers > > > > this is broken at remove/unplug time, where all devres resources are > > > > released device_release_driver(), before the final device reference is > > > > dropped. So far so good. > > > > > > > > There's 2 exceptions: > > > > - drm/vkms|vgem: Virtual drivers for which we create a fake/virtual > > > > platform device to make them look more like normal devices to > > > > userspace. These aren't drivers in the driver model sense, we simple > > > > create a platform_device and register it. > > > > > > That's a horrid abuse of platform devices, just use a "virtual" device > > > please, create/remove it when you need it, and all should be fine. > > > > > > > - drm/i915/selftests, where we create minimal mock devices, and again > > > > the selftests aren't proper drivers in the driver model sense. > > > > > > Again, virtual devices are best to use for this. > > > > Hm yeah, I guess we should fix that. i915 selftests do use raw struct > > device though, and it's not really the problem. > > > > > > For these two cases the reference loop isn't broken, because devres is > > > > only cleaned up when the last device reference is dropped. But that's > > > > not happening, because the drm_device holds that last struct device > > > > reference. > > > > > > > > Thus far this wasn't a problem since the above cases simply > > > > hand-rolled their cleanup code. But I want to convert all drivers over > > > > to the devm_ versions, hence it would be really nice if these > > > > virtual/fake/mock uses-cases could also be managed with devres > > > > cleanup. > > > > > > > > I see three possible approaches: > > > > > > > > - Clean up devres from device_del (or platform_device_unregister) even > > > > when no driver is bound. This seems like the simplest solution, but > > > > also the one with the widest impact, and what this patch implements. > > > > We might want to include more of the cleanup than just > > > > devres_release_all, but this is all I need to get my use case going. > > > > > > After device_del, you should never be using that structure again anyway. > > > So why is there any "resource leak"? You can't recycle the structure, > > > and you can't assign it to anything else, so eventually you have to do > > > a final put on the thing, which will free up the resources. > > > > I guess I should have spent more time explaining this. There's two > > references involved: > > > > - drm_device->dev points at the underlying struct device. The > > drm_device holds a reference until it's fully cleaned up, so that we > > can do nice stuff like use dev_ versions of printk functions, and you > > always know that there's not going to be a use-after free. > > > > - now the other dependency is that as long as the device exists (not > > just in memory, but in the device model, i.e. between device_add() and > > device_del()) the drm_device should exist. So what we do in the > > bus-specific remove/disconnect callback is that we call > > drm_dev_unregister(). This drops the drm_device refcount that the drm > > chardev was holding, to make sure that an open() on the chardev can > > actually get at the memory without going boom. Then after the > > drm_dev_unregister, again in the remove/disconnect callback of th > > driver, there's a drm_dev_put(). Which might or might not be the final > > drm_dev_put(), since if there's currently some open fd we keep the > > refcount elevated, to avoid oopses and fun stuff like that. And > > drm_device pointers get shared very widely, thanks to fun stuff like > > dma_buf buffer sharing and dma_fence hw syncpt sharing across > > processes and drivers. > > > > Once the final drm_dev_put() is called we also end up calling > > put_device() and everything is happy. > > > > So far so good. > > > > Now the problem is that refcount is hard, and most drm drivers get it > > wrong in some fashion or another, so I'm trying to solve all this with > > more magic. > > Wait, no. Fix the drivers. Seriously, don't try to "bust" the > reference count logic here. I guess still not clear. What I'm doing is fixing the drivers. But because they all get it wrong, I'm trying to hide as much of the refcounting as possible
Re: [Intel-gfx] [PATCH 01/44] drivers/base: Always release devres on device_del
On Fri, Apr 03, 2020 at 04:47:04PM +0200, Daniel Vetter wrote: > On Fri, Apr 3, 2020 at 4:17 PM Greg Kroah-Hartman > wrote: > > > > On Fri, Apr 03, 2020 at 03:57:45PM +0200, Daniel Vetter wrote: > > > In drm we've added nice drm_device (the main gpu driver thing, which > > > also represents the userspace interfaces and has everything else > > > dangling off it) init functions using devres, devm_drm_dev_init and > > > soon devm_drm_dev_alloc (this patch series adds that). > > > > > > A slight trouble is that drm_device itself holds a reference on the > > > struct device it's sitting on top (for sysfs links and dmesg debug and > > > lots of other things), so there's a reference loop. For real drivers > > > this is broken at remove/unplug time, where all devres resources are > > > released device_release_driver(), before the final device reference is > > > dropped. So far so good. > > > > > > There's 2 exceptions: > > > - drm/vkms|vgem: Virtual drivers for which we create a fake/virtual > > > platform device to make them look more like normal devices to > > > userspace. These aren't drivers in the driver model sense, we simple > > > create a platform_device and register it. > > > > That's a horrid abuse of platform devices, just use a "virtual" device > > please, create/remove it when you need it, and all should be fine. > > > > > - drm/i915/selftests, where we create minimal mock devices, and again > > > the selftests aren't proper drivers in the driver model sense. > > > > Again, virtual devices are best to use for this. > > Hm yeah, I guess we should fix that. i915 selftests do use raw struct > device though, and it's not really the problem. > > > > For these two cases the reference loop isn't broken, because devres is > > > only cleaned up when the last device reference is dropped. But that's > > > not happening, because the drm_device holds that last struct device > > > reference. > > > > > > Thus far this wasn't a problem since the above cases simply > > > hand-rolled their cleanup code. But I want to convert all drivers over > > > to the devm_ versions, hence it would be really nice if these > > > virtual/fake/mock uses-cases could also be managed with devres > > > cleanup. > > > > > > I see three possible approaches: > > > > > > - Clean up devres from device_del (or platform_device_unregister) even > > > when no driver is bound. This seems like the simplest solution, but > > > also the one with the widest impact, and what this patch implements. > > > We might want to include more of the cleanup than just > > > devres_release_all, but this is all I need to get my use case going. > > > > After device_del, you should never be using that structure again anyway. > > So why is there any "resource leak"? You can't recycle the structure, > > and you can't assign it to anything else, so eventually you have to do > > a final put on the thing, which will free up the resources. > > I guess I should have spent more time explaining this. There's two > references involved: > > - drm_device->dev points at the underlying struct device. The > drm_device holds a reference until it's fully cleaned up, so that we > can do nice stuff like use dev_ versions of printk functions, and you > always know that there's not going to be a use-after free. > > - now the other dependency is that as long as the device exists (not > just in memory, but in the device model, i.e. between device_add() and > device_del()) the drm_device should exist. So what we do in the > bus-specific remove/disconnect callback is that we call > drm_dev_unregister(). This drops the drm_device refcount that the drm > chardev was holding, to make sure that an open() on the chardev can > actually get at the memory without going boom. Then after the > drm_dev_unregister, again in the remove/disconnect callback of th > driver, there's a drm_dev_put(). Which might or might not be the final > drm_dev_put(), since if there's currently some open fd we keep the > refcount elevated, to avoid oopses and fun stuff like that. And > drm_device pointers get shared very widely, thanks to fun stuff like > dma_buf buffer sharing and dma_fence hw syncpt sharing across > processes and drivers. > > Once the final drm_dev_put() is called we also end up calling > put_device() and everything is happy. > > So far so good. > > Now the problem is that refcount is hard, and most drm drivers get it > wrong in some fashion or another, so I'm trying to solve all this with > more magic. Wait, no. Fix the drivers. Seriously, don't try to "bust" the reference count logic here. > Since all drivers need to have a drm_dev_put() at the end of their > driver's remove/disconnect callback we've added a devm_drm_dev_init > function which registers a devres action to do that drm_dev_put() at > device_del time (which might or might not be the final drm_dev_put()). > Nothing has changed thus far. > > Now this works really well because when you have a real driver model >
Re: [Intel-gfx] [PATCH 01/44] drivers/base: Always release devres on device_del
On Fri, Apr 03, 2020 at 04:51:33PM +0200, Daniel Vetter wrote: > On Fri, Apr 3, 2020 at 4:47 PM Daniel Vetter wrote: > > > > On Fri, Apr 3, 2020 at 4:17 PM Greg Kroah-Hartman > > wrote: > > > > > > On Fri, Apr 03, 2020 at 03:57:45PM +0200, Daniel Vetter wrote: > > > > In drm we've added nice drm_device (the main gpu driver thing, which > > > > also represents the userspace interfaces and has everything else > > > > dangling off it) init functions using devres, devm_drm_dev_init and > > > > soon devm_drm_dev_alloc (this patch series adds that). > > > > > > > > A slight trouble is that drm_device itself holds a reference on the > > > > struct device it's sitting on top (for sysfs links and dmesg debug and > > > > lots of other things), so there's a reference loop. For real drivers > > > > this is broken at remove/unplug time, where all devres resources are > > > > released device_release_driver(), before the final device reference is > > > > dropped. So far so good. > > > > > > > > There's 2 exceptions: > > > > - drm/vkms|vgem: Virtual drivers for which we create a fake/virtual > > > > platform device to make them look more like normal devices to > > > > userspace. These aren't drivers in the driver model sense, we simple > > > > create a platform_device and register it. > > > > > > That's a horrid abuse of platform devices, just use a "virtual" device > > > please, create/remove it when you need it, and all should be fine. > > > > > > > - drm/i915/selftests, where we create minimal mock devices, and again > > > > the selftests aren't proper drivers in the driver model sense. > > > > > > Again, virtual devices are best to use for this. > > > > Hm yeah, I guess we should fix that. i915 selftests do use raw struct > > device though, and it's not really the problem. > > > > > > For these two cases the reference loop isn't broken, because devres is > > > > only cleaned up when the last device reference is dropped. But that's > > > > not happening, because the drm_device holds that last struct device > > > > reference. > > > > > > > > Thus far this wasn't a problem since the above cases simply > > > > hand-rolled their cleanup code. But I want to convert all drivers over > > > > to the devm_ versions, hence it would be really nice if these > > > > virtual/fake/mock uses-cases could also be managed with devres > > > > cleanup. > > > > > > > > I see three possible approaches: > > > > > > > > - Clean up devres from device_del (or platform_device_unregister) even > > > > when no driver is bound. This seems like the simplest solution, but > > > > also the one with the widest impact, and what this patch implements. > > > > We might want to include more of the cleanup than just > > > > devres_release_all, but this is all I need to get my use case going. > > > > > > After device_del, you should never be using that structure again anyway. > > > So why is there any "resource leak"? You can't recycle the structure, > > > and you can't assign it to anything else, so eventually you have to do > > > a final put on the thing, which will free up the resources. > > > > I guess I should have spent more time explaining this. There's two > > references involved: > > > > - drm_device->dev points at the underlying struct device. The > > drm_device holds a reference until it's fully cleaned up, so that we > > can do nice stuff like use dev_ versions of printk functions, and you > > always know that there's not going to be a use-after free. > > > > - now the other dependency is that as long as the device exists (not > > just in memory, but in the device model, i.e. between device_add() and > > device_del()) the drm_device should exist. So what we do in the > > bus-specific remove/disconnect callback is that we call > > drm_dev_unregister(). This drops the drm_device refcount that the drm > > chardev was holding, to make sure that an open() on the chardev can > > actually get at the memory without going boom. Then after the > > drm_dev_unregister, again in the remove/disconnect callback of th > > driver, there's a drm_dev_put(). Which might or might not be the final > > drm_dev_put(), since if there's currently some open fd we keep the > > refcount elevated, to avoid oopses and fun stuff like that. And > > drm_device pointers get shared very widely, thanks to fun stuff like > > dma_buf buffer sharing and dma_fence hw syncpt sharing across > > processes and drivers. > > > > Once the final drm_dev_put() is called we also end up calling > > put_device() and everything is happy. > > > > So far so good. > > > > Now the problem is that refcount is hard, and most drm drivers get it > > wrong in some fashion or another, so I'm trying to solve all this with > > more magic. > > > > Since all drivers need to have a drm_dev_put() at the end of their > > driver's remove/disconnect callback we've added a devm_drm_dev_init > > function which registers a devres action to do that drm_dev_put() at > > device_del time (which might or
Re: [Intel-gfx] [PATCH 01/44] drivers/base: Always release devres on device_del
On Fri, Apr 3, 2020 at 4:47 PM Daniel Vetter wrote: > > On Fri, Apr 3, 2020 at 4:17 PM Greg Kroah-Hartman > wrote: > > > > On Fri, Apr 03, 2020 at 03:57:45PM +0200, Daniel Vetter wrote: > > > In drm we've added nice drm_device (the main gpu driver thing, which > > > also represents the userspace interfaces and has everything else > > > dangling off it) init functions using devres, devm_drm_dev_init and > > > soon devm_drm_dev_alloc (this patch series adds that). > > > > > > A slight trouble is that drm_device itself holds a reference on the > > > struct device it's sitting on top (for sysfs links and dmesg debug and > > > lots of other things), so there's a reference loop. For real drivers > > > this is broken at remove/unplug time, where all devres resources are > > > released device_release_driver(), before the final device reference is > > > dropped. So far so good. > > > > > > There's 2 exceptions: > > > - drm/vkms|vgem: Virtual drivers for which we create a fake/virtual > > > platform device to make them look more like normal devices to > > > userspace. These aren't drivers in the driver model sense, we simple > > > create a platform_device and register it. > > > > That's a horrid abuse of platform devices, just use a "virtual" device > > please, create/remove it when you need it, and all should be fine. > > > > > - drm/i915/selftests, where we create minimal mock devices, and again > > > the selftests aren't proper drivers in the driver model sense. > > > > Again, virtual devices are best to use for this. > > Hm yeah, I guess we should fix that. i915 selftests do use raw struct > device though, and it's not really the problem. > > > > For these two cases the reference loop isn't broken, because devres is > > > only cleaned up when the last device reference is dropped. But that's > > > not happening, because the drm_device holds that last struct device > > > reference. > > > > > > Thus far this wasn't a problem since the above cases simply > > > hand-rolled their cleanup code. But I want to convert all drivers over > > > to the devm_ versions, hence it would be really nice if these > > > virtual/fake/mock uses-cases could also be managed with devres > > > cleanup. > > > > > > I see three possible approaches: > > > > > > - Clean up devres from device_del (or platform_device_unregister) even > > > when no driver is bound. This seems like the simplest solution, but > > > also the one with the widest impact, and what this patch implements. > > > We might want to include more of the cleanup than just > > > devres_release_all, but this is all I need to get my use case going. > > > > After device_del, you should never be using that structure again anyway. > > So why is there any "resource leak"? You can't recycle the structure, > > and you can't assign it to anything else, so eventually you have to do > > a final put on the thing, which will free up the resources. > > I guess I should have spent more time explaining this. There's two > references involved: > > - drm_device->dev points at the underlying struct device. The > drm_device holds a reference until it's fully cleaned up, so that we > can do nice stuff like use dev_ versions of printk functions, and you > always know that there's not going to be a use-after free. > > - now the other dependency is that as long as the device exists (not > just in memory, but in the device model, i.e. between device_add() and > device_del()) the drm_device should exist. So what we do in the > bus-specific remove/disconnect callback is that we call > drm_dev_unregister(). This drops the drm_device refcount that the drm > chardev was holding, to make sure that an open() on the chardev can > actually get at the memory without going boom. Then after the > drm_dev_unregister, again in the remove/disconnect callback of th > driver, there's a drm_dev_put(). Which might or might not be the final > drm_dev_put(), since if there's currently some open fd we keep the > refcount elevated, to avoid oopses and fun stuff like that. And > drm_device pointers get shared very widely, thanks to fun stuff like > dma_buf buffer sharing and dma_fence hw syncpt sharing across > processes and drivers. > > Once the final drm_dev_put() is called we also end up calling > put_device() and everything is happy. > > So far so good. > > Now the problem is that refcount is hard, and most drm drivers get it > wrong in some fashion or another, so I'm trying to solve all this with > more magic. > > Since all drivers need to have a drm_dev_put() at the end of their > driver's remove/disconnect callback we've added a devm_drm_dev_init > function which registers a devres action to do that drm_dev_put() at > device_del time (which might or might not be the final drm_dev_put()). > Nothing has changed thus far. > > Now this works really well because when you have a real driver model > driver attached, then device_del ends up calling devres_release_all(), > which ends up triggering the
Re: [Intel-gfx] [PATCH 01/44] drivers/base: Always release devres on device_del
On Fri, Apr 3, 2020 at 4:17 PM Greg Kroah-Hartman wrote: > > On Fri, Apr 03, 2020 at 03:57:45PM +0200, Daniel Vetter wrote: > > In drm we've added nice drm_device (the main gpu driver thing, which > > also represents the userspace interfaces and has everything else > > dangling off it) init functions using devres, devm_drm_dev_init and > > soon devm_drm_dev_alloc (this patch series adds that). > > > > A slight trouble is that drm_device itself holds a reference on the > > struct device it's sitting on top (for sysfs links and dmesg debug and > > lots of other things), so there's a reference loop. For real drivers > > this is broken at remove/unplug time, where all devres resources are > > released device_release_driver(), before the final device reference is > > dropped. So far so good. > > > > There's 2 exceptions: > > - drm/vkms|vgem: Virtual drivers for which we create a fake/virtual > > platform device to make them look more like normal devices to > > userspace. These aren't drivers in the driver model sense, we simple > > create a platform_device and register it. > > That's a horrid abuse of platform devices, just use a "virtual" device > please, create/remove it when you need it, and all should be fine. > > > - drm/i915/selftests, where we create minimal mock devices, and again > > the selftests aren't proper drivers in the driver model sense. > > Again, virtual devices are best to use for this. Hm yeah, I guess we should fix that. i915 selftests do use raw struct device though, and it's not really the problem. > > For these two cases the reference loop isn't broken, because devres is > > only cleaned up when the last device reference is dropped. But that's > > not happening, because the drm_device holds that last struct device > > reference. > > > > Thus far this wasn't a problem since the above cases simply > > hand-rolled their cleanup code. But I want to convert all drivers over > > to the devm_ versions, hence it would be really nice if these > > virtual/fake/mock uses-cases could also be managed with devres > > cleanup. > > > > I see three possible approaches: > > > > - Clean up devres from device_del (or platform_device_unregister) even > > when no driver is bound. This seems like the simplest solution, but > > also the one with the widest impact, and what this patch implements. > > We might want to include more of the cleanup than just > > devres_release_all, but this is all I need to get my use case going. > > After device_del, you should never be using that structure again anyway. > So why is there any "resource leak"? You can't recycle the structure, > and you can't assign it to anything else, so eventually you have to do > a final put on the thing, which will free up the resources. I guess I should have spent more time explaining this. There's two references involved: - drm_device->dev points at the underlying struct device. The drm_device holds a reference until it's fully cleaned up, so that we can do nice stuff like use dev_ versions of printk functions, and you always know that there's not going to be a use-after free. - now the other dependency is that as long as the device exists (not just in memory, but in the device model, i.e. between device_add() and device_del()) the drm_device should exist. So what we do in the bus-specific remove/disconnect callback is that we call drm_dev_unregister(). This drops the drm_device refcount that the drm chardev was holding, to make sure that an open() on the chardev can actually get at the memory without going boom. Then after the drm_dev_unregister, again in the remove/disconnect callback of th driver, there's a drm_dev_put(). Which might or might not be the final drm_dev_put(), since if there's currently some open fd we keep the refcount elevated, to avoid oopses and fun stuff like that. And drm_device pointers get shared very widely, thanks to fun stuff like dma_buf buffer sharing and dma_fence hw syncpt sharing across processes and drivers. Once the final drm_dev_put() is called we also end up calling put_device() and everything is happy. So far so good. Now the problem is that refcount is hard, and most drm drivers get it wrong in some fashion or another, so I'm trying to solve all this with more magic. Since all drivers need to have a drm_dev_put() at the end of their driver's remove/disconnect callback we've added a devm_drm_dev_init function which registers a devres action to do that drm_dev_put() at device_del time (which might or might not be the final drm_dev_put()). Nothing has changed thus far. Now this works really well because when you have a real driver model driver attached, then device_del ends up calling devres_release_all(), which ends up triggering the multi-stage cleanup of drm_devices. But if you do _not_ have a real driver attached, then device_del does nothing wrt devres cleanup. Instead this is delayed until the final put_device(). Unfortunately that final put_device() will never happen,
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Keep a per-engine request pools (rev2)
== Series Details == Series: drm/i915: Keep a per-engine request pools (rev2) URL : https://patchwork.freedesktop.org/series/75427/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8238_full -> Patchwork_17189_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17189_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17189_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17189_full: ### IGT changes ### Possible regressions * igt@gem_mmap_gtt@cpuset-basic-small-copy-xy: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-skl2/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17189/shard-skl7/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html * igt@gem_mmap_gtt@hang: - shard-iclb: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-iclb1/igt@gem_mmap_...@hang.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17189/shard-iclb2/igt@gem_mmap_...@hang.html * igt@i915_pm_rc6_residency@rc6-idle: - shard-snb: [PASS][5] -> [FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-snb6/igt@i915_pm_rc6_reside...@rc6-idle.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17189/shard-snb5/igt@i915_pm_rc6_reside...@rc6-idle.html Known issues Here are the changes found in Patchwork_17189_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@execlists: - shard-apl: [PASS][7] -> [INCOMPLETE][8] ([i915#656]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-apl8/igt@i915_selftest@l...@execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17189/shard-apl6/igt@i915_selftest@l...@execlists.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17189/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_fbcon_fbt@fbc-suspend: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#180] / [i915#95]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-apl1/igt@kms_fbcon_...@fbc-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17189/shard-apl1/igt@kms_fbcon_...@fbc-suspend.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#1188]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-skl10/igt@kms_...@bpc-switch-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17189/shard-skl6/igt@kms_...@bpc-switch-suspend.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-apl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17189/shard-apl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_plane_cursor@pipe-a-overlay-size-128: - shard-kbl: [PASS][17] -> [FAIL][18] ([i915#1559] / [i915#93] / [i915#95]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-kbl7/igt@kms_plane_cur...@pipe-a-overlay-size-128.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17189/shard-kbl3/igt@kms_plane_cur...@pipe-a-overlay-size-128.html - shard-apl: [PASS][19] -> [FAIL][20] ([i915#1559] / [i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-apl2/igt@kms_plane_cur...@pipe-a-overlay-size-128.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17189/shard-apl8/igt@kms_plane_cur...@pipe-a-overlay-size-128.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#899]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-glk8/igt@kms_plane_low...@pipe-a-tiling-x.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17189/shard-glk7/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_psr@psr2_cursor_render: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +2 similar issues [23]:
Re: [Intel-gfx] [PATCH 01/44] drivers/base: Always release devres on device_del
On Fri, Apr 03, 2020 at 03:57:45PM +0200, Daniel Vetter wrote: > In drm we've added nice drm_device (the main gpu driver thing, which > also represents the userspace interfaces and has everything else > dangling off it) init functions using devres, devm_drm_dev_init and > soon devm_drm_dev_alloc (this patch series adds that). > > A slight trouble is that drm_device itself holds a reference on the > struct device it's sitting on top (for sysfs links and dmesg debug and > lots of other things), so there's a reference loop. For real drivers > this is broken at remove/unplug time, where all devres resources are > released device_release_driver(), before the final device reference is > dropped. So far so good. > > There's 2 exceptions: > - drm/vkms|vgem: Virtual drivers for which we create a fake/virtual > platform device to make them look more like normal devices to > userspace. These aren't drivers in the driver model sense, we simple > create a platform_device and register it. That's a horrid abuse of platform devices, just use a "virtual" device please, create/remove it when you need it, and all should be fine. > - drm/i915/selftests, where we create minimal mock devices, and again > the selftests aren't proper drivers in the driver model sense. Again, virtual devices are best to use for this. > For these two cases the reference loop isn't broken, because devres is > only cleaned up when the last device reference is dropped. But that's > not happening, because the drm_device holds that last struct device > reference. > > Thus far this wasn't a problem since the above cases simply > hand-rolled their cleanup code. But I want to convert all drivers over > to the devm_ versions, hence it would be really nice if these > virtual/fake/mock uses-cases could also be managed with devres > cleanup. > > I see three possible approaches: > > - Clean up devres from device_del (or platform_device_unregister) even > when no driver is bound. This seems like the simplest solution, but > also the one with the widest impact, and what this patch implements. > We might want to include more of the cleanup than just > devres_release_all, but this is all I need to get my use case going. After device_del, you should never be using that structure again anyway. So why is there any "resource leak"? You can't recycle the structure, and you can't assign it to anything else, so eventually you have to do a final put on the thing, which will free up the resources. And then all should be fine, right? But, by putting the freeing here, you can still have a "live" device that thinks it has resources availble that it can access, but yet they are now gone. Yeah, it's probably not ever going to really happen, but the lifecycles of dynamic devices are tough to "prove" at times, and I worry that freeing things this early is going to cause odd disconnect issues. thanks, greg k-h ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for devm_drm_dev_alloc, no more drmm_add_final_kfree
== Series Details == Series: devm_drm_dev_alloc, no more drmm_add_final_kfree URL : https://patchwork.freedesktop.org/series/75463/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h HDRTEST drivers/gpu/drm/i915/selftests/mock_gem_device.h In file included from :0:0: ./drivers/gpu/drm/i915/selftests/mock_gem_device.h: In function ‘mock_destroy_device’: ./drivers/gpu/drm/i915/selftests/mock_gem_device.h:12:2: error: implicit declaration of function ‘device_del’ [-Werror=implicit-function-declaration] device_del(i915->drm.dev); ^~ ./drivers/gpu/drm/i915/selftests/mock_gem_device.h:12:17: error: dereferencing pointer to incomplete type ‘struct drm_i915_private’ device_del(i915->drm.dev); ^~ cc1: all warnings being treated as errors drivers/gpu/drm/i915/Makefile:298: recipe for target 'drivers/gpu/drm/i915/selftests/mock_gem_device.hdrtest' failed make[4]: *** [drivers/gpu/drm/i915/selftests/mock_gem_device.hdrtest] Error 1 scripts/Makefile.build:505: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:505: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:505: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1683: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
On 2020-03-01 6:46 a.m., Marek Olšák wrote: > For Mesa, we could run CI only when Marge pushes, so that it's a strictly > pre-merge CI. Thanks for the suggestion! I implemented something like this for Mesa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: move remaining debugfs interfaces into gt (rev3)
== Series Details == Series: drm/i915/gt: move remaining debugfs interfaces into gt (rev3) URL : https://patchwork.freedesktop.org/series/75333/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8238_full -> Patchwork_17188_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17188_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17188_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17188_full: ### IGT changes ### Possible regressions * igt@i915_pm_rpm@debugfs-forcewake-user: - shard-iclb: [PASS][1] -> [SKIP][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-iclb7/igt@i915_pm_...@debugfs-forcewake-user.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17188/shard-iclb3/igt@i915_pm_...@debugfs-forcewake-user.html - shard-tglb: [PASS][3] -> [SKIP][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-tglb7/igt@i915_pm_...@debugfs-forcewake-user.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17188/shard-tglb1/igt@i915_pm_...@debugfs-forcewake-user.html * igt@i915_suspend@forcewake: - shard-snb: [PASS][5] -> [FAIL][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-snb4/igt@i915_susp...@forcewake.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17188/shard-snb4/igt@i915_susp...@forcewake.html * igt@perf_pmu@rc6: - shard-apl: [PASS][7] -> [FAIL][8] +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-apl1/igt@perf_...@rc6.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17188/shard-apl7/igt@perf_...@rc6.html - shard-glk: [PASS][9] -> [FAIL][10] +5 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-glk6/igt@perf_...@rc6.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17188/shard-glk1/igt@perf_...@rc6.html - shard-tglb: [PASS][11] -> [FAIL][12] +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-tglb5/igt@perf_...@rc6.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17188/shard-tglb5/igt@perf_...@rc6.html - shard-kbl: [PASS][13] -> [FAIL][14] +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-kbl7/igt@perf_...@rc6.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17188/shard-kbl2/igt@perf_...@rc6.html * igt@perf_pmu@rc6-runtime-pm: - shard-skl: [PASS][15] -> [FAIL][16] +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-skl9/igt@perf_...@rc6-runtime-pm.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17188/shard-skl8/igt@perf_...@rc6-runtime-pm.html * igt@perf_pmu@rc6-runtime-pm-long: - shard-iclb: [PASS][17] -> [FAIL][18] +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-iclb6/igt@perf_...@rc6-runtime-pm-long.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17188/shard-iclb6/igt@perf_...@rc6-runtime-pm-long.html - shard-skl: NOTRUN -> [FAIL][19] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17188/shard-skl3/igt@perf_...@rc6-runtime-pm-long.html Known issues Here are the changes found in Patchwork_17188_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_cs_tlb@vcs1: - shard-iclb: [PASS][20] -> [SKIP][21] ([fdo#112080]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-iclb4/igt@gem_cs_...@vcs1.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17188/shard-iclb7/igt@gem_cs_...@vcs1.html * igt@i915_pm_rpm@debugfs-forcewake-user: - shard-skl: [PASS][22] -> [SKIP][23] ([fdo#109271]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-skl8/igt@i915_pm_...@debugfs-forcewake-user.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17188/shard-skl5/igt@i915_pm_...@debugfs-forcewake-user.html * igt@i915_pm_sseu@full-enable: - shard-apl: [PASS][24] -> [SKIP][25] ([fdo#109271]) +1 similar issue [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8238/shard-apl8/igt@i915_pm_s...@full-enable.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17188/shard-apl4/igt@i915_pm_s...@full-enable.html - shard-kbl: [PASS][26] -> [SKIP][27] ([fdo#109271]) +1 similar issue [26]:
Re: [Intel-gfx] [PATCH] drm/i915: Keep a per-engine request pools
Quoting Janusz Krzysztofik (2020-04-03 14:58:47) > On Thu, 2020-04-02 at 19:40 +0100, Chris Wilson wrote: > > Add a tiny per-engine request mempool so that we should always have a > > request available for powermanagement allocations from tricky > > contexts. This reserve is expected to be only used for kernel > > contexts when barriers must be emitted [almost] without fail. > > > > The main consumer for this reserved request is expected to be engine-pm, > > for which we know that there will always be at least the previous pm > > request that we can reuse under mempressure (so there should always be > > a spare request for engine_park()). > > > > This is an alternative to using a comparatively bulky mempool, which > > requires custom handling for both our reserved allocation requirement > > and to protect our TYPESAFE_BY_RCU slab cache. > > This change resolves the issue for me, and being more simple than the > mempool approach, looks still better. Cool. I couldn't decide if mempool was worth it or not. If we needed more than a single slot, definitely, but the impedance mismatch and that the general advice is not to add more mempools suggest no. Thanks, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 41/44] drm/i915: Use devm_drm_dev_alloc
Luckily we're already well set up in the main driver, with
drm_dev_put() being the last thing in both the unload error case and
the pci remove function.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 17 -
drivers/gpu/drm/i915/i915_pci.c | 2 --
2 files changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a7a3b4b98572..9c0ff25c5d41 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -879,19 +879,11 @@ i915_driver_create(struct pci_dev *pdev, const struct
pci_device_id *ent)
(struct intel_device_info *)ent->driver_data;
struct intel_device_info *device_info;
struct drm_i915_private *i915;
- int err;
- i915 = kzalloc(sizeof(*i915), GFP_KERNEL);
- if (!i915)
- return ERR_PTR(-ENOMEM);
-
- err = drm_dev_init(>drm, , >dev);
- if (err) {
- kfree(i915);
- return ERR_PTR(err);
- }
-
- drmm_add_final_kfree(>drm, i915);
+ i915 = devm_drm_dev_alloc(>dev, ,
+ struct drm_i915_private, drm);
+ if (IS_ERR(i915))
+ return i915;
i915->drm.pdev = pdev;
pci_set_drvdata(pdev, i915);
@@ -1008,7 +1000,6 @@ int i915_driver_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
pci_disable_device(pdev);
out_fini:
i915_probe_error(i915, "Device initialization failed (%d)\n", ret);
- drm_dev_put(>drm);
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 2c80a0194c80..0f8b439d6fd5 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -920,8 +920,6 @@ static void i915_pci_remove(struct pci_dev *pdev)
i915_driver_remove(i915);
pci_set_drvdata(pdev, NULL);
-
- drm_dev_put(>drm);
}
/* is device_id present in comma separated list of ids */
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 43/44] drm/i915/selftests: align more to real device lifetimes
The big change is device_add so that device_del can auto-cleanup
devres resources. This allows us to use devm_drm_dev_alloc, which
removes the last user of drm_dev_init.
Signed-off-by: Daniel Vetter
---
.../gpu/drm/i915/selftests/mock_gem_device.c | 31 +--
.../gpu/drm/i915/selftests/mock_gem_device.h | 2 +-
2 files changed, 16 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 03607647cdeb..ea73d1f7cf12 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -123,12 +123,6 @@ struct drm_i915_private *mock_gem_device(void)
pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
if (!pdev)
return NULL;
- i915 = kzalloc(sizeof(*i915), GFP_KERNEL);
- if (!i915) {
- kfree(pdev);
- return NULL;
- }
-
device_initialize(>dev);
pdev->class = PCI_BASE_CLASS_DISPLAY << 16;
pdev->dev.release = release_dev;
@@ -139,8 +133,23 @@ struct drm_i915_private *mock_gem_device(void)
/* hack to disable iommu for the fake device; force identity mapping */
pdev->dev.archdata.iommu = (void *)-1;
#endif
+ err = device_add(>dev);
+ if (err) {
+ kfree(pdev);
+ return NULL;
+ }
+
+ i915 = devm_drm_dev_alloc(>dev, _driver,
+ struct drm_i915_private, drm);
+ if (err) {
+ pr_err("Failed to allocate mock GEM device: err=%d\n", err);
+ put_device(>dev);
+
+ return NULL;
+ }
pci_set_drvdata(pdev, i915);
+ i915->drm.pdev = pdev;
dev_pm_domain_set(>dev, _domain);
pm_runtime_enable(>dev);
@@ -148,16 +157,6 @@ struct drm_i915_private *mock_gem_device(void)
if (pm_runtime_enabled(>dev))
WARN_ON(pm_runtime_get_sync(>dev));
- err = drm_dev_init(>drm, _driver, >dev);
- if (err) {
- pr_err("Failed to initialise mock GEM device: err=%d\n", err);
- put_device(>dev);
- kfree(i915);
-
- return NULL;
- }
- i915->drm.pdev = pdev;
- drmm_add_final_kfree(>drm, i915);
intel_runtime_pm_init_early(>runtime_pm);
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.h
b/drivers/gpu/drm/i915/selftests/mock_gem_device.h
index 2e3c7585a7bb..4f309a05c85a 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.h
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.h
@@ -9,7 +9,7 @@ void mock_device_flush(struct drm_i915_private *i915);
static inline void mock_destroy_device(struct drm_i915_private *i915)
{
- drm_dev_put(>drm);
+ device_del(i915->drm.dev);
}
#endif /* !__MOCK_GEM_DEVICE_H__ */
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 39/44] drm/cirrus: Use devm_drm_dev_alloc
Already using devm_drm_dev_init, so very simple replacment.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc: "Noralf Trønnes"
Cc: Rob Herring
Cc: Thomas Zimmermann
Cc: virtualizat...@lists.linux-foundation.org
Cc: Emil Velikov
---
drivers/gpu/drm/cirrus/cirrus.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus.c b/drivers/gpu/drm/cirrus/cirrus.c
index a36269717c3b..4b65637147ba 100644
--- a/drivers/gpu/drm/cirrus/cirrus.c
+++ b/drivers/gpu/drm/cirrus/cirrus.c
@@ -567,18 +567,13 @@ static int cirrus_pci_probe(struct pci_dev *pdev,
return ret;
ret = -ENOMEM;
- cirrus = kzalloc(sizeof(*cirrus), GFP_KERNEL);
- if (cirrus == NULL)
- return ret;
+ cirrus = devm_drm_dev_alloc(>dev, _driver,
+ struct cirrus_device, dev);
+ if (IS_ERR(cirrus))
+ return PTR_ERR(cirrus);
dev = >dev;
- ret = devm_drm_dev_init(>dev, dev, _driver);
- if (ret) {
- kfree(cirrus);
- return ret;
- }
dev->dev_private = cirrus;
- drmm_add_final_kfree(dev, cirrus);
cirrus->vram = devm_ioremap(>dev, pci_resource_start(pdev, 0),
pci_resource_len(pdev, 0));
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 36/44] drm/komeda: use devm_drm_dev_alloc
Komeda uses the component framework, which does open/close a new
devres group around all the bind callbacks. Which means we can use
devm_ functions for managing the drm_device cleanup, with leaking
stuff in case of deferred probes or other reasons to unbind
components, or the component_master.
Also note that this fixes a double-free in the probe unroll code, bot
drm_dev_put and kfree(kms) result in the kms allocation getting freed.
Aside: komeda_bind could be cleaned up a lot, devm_kfree is a bit
redundant. Plus I'm not clear on why there's suballocations for
mdrv->mdev and mdrv->kms. Plus I'm not sure the lifetimes are correct
with all that devm_kzalloc usage ... That structure layout is also the
reason why komeda still uses drm_device->dev_private and can't easily
be replaced with a proper container_of upcasting. I'm pretty sure that
there's endless amounts of hotunplug/hotremove bugs in there with all
the unprotected dereferencing of drm_device->dev_private.
Signed-off-by: Daniel Vetter
Cc: "James (Qian) Wang"
Cc: Liviu Dudau
Cc: Mihail Atanassov
---
drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index 16dfd5cdb66c..6b85d5f4caa8 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -261,18 +261,16 @@ static void komeda_kms_mode_config_init(struct
komeda_kms_dev *kms,
struct komeda_kms_dev *komeda_kms_attach(struct komeda_dev *mdev)
{
- struct komeda_kms_dev *kms = kzalloc(sizeof(*kms), GFP_KERNEL);
+ struct komeda_kms_dev *kms;
struct drm_device *drm;
int err;
- if (!kms)
- return ERR_PTR(-ENOMEM);
+ kms = devm_drm_dev_alloc(mdev->dev, _kms_driver,
+struct komeda_kms_dev, base);
+ if (IS_ERR(kms))
+ return kms;
drm = >base;
- err = drm_dev_init(drm, _kms_driver, mdev->dev);
- if (err)
- goto free_kms;
- drmm_add_final_kfree(drm, kms);
drm->dev_private = mdev;
@@ -329,9 +327,6 @@ struct komeda_kms_dev *komeda_kms_attach(struct komeda_dev
*mdev)
drm_mode_config_cleanup(drm);
komeda_kms_cleanup_private_objs(kms);
drm->dev_private = NULL;
- drm_dev_put(drm);
-free_kms:
- kfree(kms);
return ERR_PTR(err);
}
@@ -348,5 +343,4 @@ void komeda_kms_detach(struct komeda_kms_dev *kms)
drm_mode_config_cleanup(drm);
komeda_kms_cleanup_private_objs(kms);
drm->dev_private = NULL;
- drm_dev_put(drm);
}
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 42/44] drm/i915/selftest: Create mock_destroy_device
Just some prep work before we rework the lifetime handling, which requires replacing all the drm_dev_put in selftests by something else. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 2 +- drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 2 +- drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c | 2 +- drivers/gpu/drm/i915/gem/selftests/i915_gem_phys.c| 2 +- drivers/gpu/drm/i915/gt/selftest_timeline.c | 2 +- drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 2 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +- drivers/gpu/drm/i915/selftests/i915_request.c | 2 +- drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +- drivers/gpu/drm/i915/selftests/intel_memory_region.c | 2 +- drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +- drivers/gpu/drm/i915/selftests/mock_gem_device.h | 5 + 13 files changed, 17 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c index 2d0fd50c5312..d19bb011fc6b 100644 --- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c +++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c @@ -1789,7 +1789,7 @@ int i915_gem_huge_page_mock_selftests(void) i915_vm_put(>vm); out_unlock: - drm_dev_put(_priv->drm); + mock_destroy_device(dev_priv); return err; } diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c index f4f933240b39..d9d96d23e37e 100644 --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c @@ -1986,7 +1986,7 @@ int i915_gem_context_mock_selftests(void) err = i915_subtests(tests, i915); - drm_dev_put(>drm); + mock_destroy_device(i915); return err; } diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c index 2a52b92586b9..0845ce1ae37c 100644 --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c @@ -272,7 +272,7 @@ int i915_gem_dmabuf_mock_selftests(void) err = i915_subtests(tests, i915); - drm_dev_put(>drm); + mock_destroy_device(i915); return err; } diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c index 2b6db6f799de..085644edebfc 100644 --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c @@ -85,7 +85,7 @@ int i915_gem_object_mock_selftests(void) err = i915_subtests(tests, i915); - drm_dev_put(>drm); + mock_destroy_device(i915); return err; } diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_phys.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_phys.c index 34932871b3a5..2a9709eb5a42 100644 --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_phys.c +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_phys.c @@ -73,6 +73,6 @@ int i915_gem_phys_mock_selftests(void) err = i915_subtests(tests, i915); - drm_dev_put(>drm); + mock_destroy_device(i915); return err; } diff --git a/drivers/gpu/drm/i915/gt/selftest_timeline.c b/drivers/gpu/drm/i915/gt/selftest_timeline.c index c2578a0f2f14..1c0865227714 100644 --- a/drivers/gpu/drm/i915/gt/selftest_timeline.c +++ b/drivers/gpu/drm/i915/gt/selftest_timeline.c @@ -157,7 +157,7 @@ static int mock_hwsp_freelist(void *arg) __mock_hwsp_record(, na, NULL); kfree(state.history); err_put: - drm_dev_put(>drm); + mock_destroy_device(i915); return err; } diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c index 028baae9631f..f88473d396f4 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c +++ b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c @@ -536,7 +536,7 @@ int i915_gem_evict_mock_selftests(void) with_intel_runtime_pm(>runtime_pm, wakeref) err = i915_subtests(tests, >gt); - drm_dev_put(>drm); + mock_destroy_device(i915); return err; } diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c index 5d2a02fcf595..035e4f77f06f 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c @@ -1714,7 +1714,7 @@ int i915_gem_gtt_mock_selftests(void) mock_fini_ggtt(ggtt); kfree(ggtt); out_put: - drm_dev_put(>drm); + mock_destroy_device(i915); return err; } diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c b/drivers/gpu/drm/i915/selftests/i915_request.c index 1dab0360f76a..6bc6a2fc83ab 100644 ---
