[Intel-gfx] ✓ Fi.CI.IGT: success for drm/dp_mst: Use kHz as link rate units when settig source max link caps at init (rev2)
== Series Details == Series: drm/dp_mst: Use kHz as link rate units when settig source max link caps at init (rev2) URL : https://patchwork.freedesktop.org/series/90099/ State : success == Summary == CI Bug Log - changes from CI_DRM_10113_full -> Patchwork_20163_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20163_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-persistence: - shard-snb: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-persistence.html * igt@gem_ctx_ringsize@idle@bcs0: - shard-skl: NOTRUN -> [INCOMPLETE][2] ([i915#3316]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/shard-skl5/igt@gem_ctx_ringsize@i...@bcs0.html * igt@gem_ctx_sseu@engines: - shard-tglb: NOTRUN -> [SKIP][3] ([i915#280]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/shard-tglb6/igt@gem_ctx_s...@engines.html * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-apl: NOTRUN -> [FAIL][4] ([i915#2389]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/shard-apl6/igt@gem_exec_reloc@basic-wide-act...@bcs0.html * igt@gem_mmap_gtt@cpuset-basic-small-copy: - shard-glk: [PASS][5] -> [INCOMPLETE][6] ([i915#2055] / [i915#3468]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-glk8/igt@gem_mmap_...@cpuset-basic-small-copy.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/shard-glk4/igt@gem_mmap_...@cpuset-basic-small-copy.html - shard-kbl: [PASS][7] -> [INCOMPLETE][8] ([i915#3468]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-kbl3/igt@gem_mmap_...@cpuset-basic-small-copy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/shard-kbl7/igt@gem_mmap_...@cpuset-basic-small-copy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-xy: - shard-snb: NOTRUN -> [INCOMPLETE][9] ([i915#2055]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/shard-snb7/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html - shard-tglb: [PASS][10] -> [INCOMPLETE][11] ([i915#3468]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-tglb1/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/shard-tglb2/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html * igt@gem_mmap_gtt@cpuset-big-copy-xy: - shard-iclb: [PASS][12] -> [FAIL][13] ([i915#2428]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-iclb6/igt@gem_mmap_...@cpuset-big-copy-xy.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/shard-iclb1/igt@gem_mmap_...@cpuset-big-copy-xy.html * igt@gem_mmap_gtt@cpuset-medium-copy-xy: - shard-tglb: [PASS][14] -> [INCOMPLETE][15] ([i915#3468] / [i915#750]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-tglb8/igt@gem_mmap_...@cpuset-medium-copy-xy.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/shard-tglb7/igt@gem_mmap_...@cpuset-medium-copy-xy.html * igt@gem_mmap_gtt@fault-concurrent: - shard-glk: NOTRUN -> [INCOMPLETE][16] ([i915#3468]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/shard-glk4/igt@gem_mmap_...@fault-concurrent.html * igt@gem_mmap_gtt@fault-concurrent-x: - shard-snb: NOTRUN -> [INCOMPLETE][17] ([i915#3468] / [i915#3485]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/shard-snb5/igt@gem_mmap_...@fault-concurrent-x.html * igt@gem_mmap_gtt@fault-concurrent-y: - shard-snb: NOTRUN -> [INCOMPLETE][18] ([i915#3468]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/shard-snb7/igt@gem_mmap_...@fault-concurrent-y.html - shard-apl: NOTRUN -> [INCOMPLETE][19] ([i915#3468]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/shard-apl6/igt@gem_mmap_...@fault-concurrent-y.html * igt@gem_mmap_gtt@medium-copy-xy: - shard-snb: NOTRUN -> [INCOMPLETE][20] ([i915#2055] / [i915#2502]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/shard-snb2/igt@gem_mmap_...@medium-copy-xy.html * igt@gem_mmap_offset@clear: - shard-iclb: [PASS][21] -> [FAIL][22] ([i915#3160]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-iclb3/igt@gem_mmap_off...@clear.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/shard-iclb8/igt@gem_mmap_off...@clear.html * igt@gem_pread@exhaustion: - shard-apl: NOTRUN ->
[Intel-gfx] ✗ Fi.CI.IGT: failure for Per client engine busyness
== Series Details == Series: Per client engine busyness URL : https://patchwork.freedesktop.org/series/90375/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10113_full -> Patchwork_20162_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20162_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20162_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_20162_full: ### Piglit changes ### Possible regressions * spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 42 1 64 4 (NEW): - pig-glk-j5005: NOTRUN -> [INCOMPLETE][1] +2 similar issues [1]: None New tests - New tests have been introduced between CI_DRM_10113_full and Patchwork_20162_full: ### New Piglit tests (3) ### * spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 42 1 64 2: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 42 1 64 3: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 42 1 64 4: - Statuses : 1 incomplete(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_20162_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@engines-hostile-preempt: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +2 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20162/shard-snb7/igt@gem_ctx_persiste...@engines-hostile-preempt.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: [PASS][3] -> [FAIL][4] ([i915#2410]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-tglb5/igt@gem_ctx_persiste...@many-contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20162/shard-tglb2/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_ctx_ringsize@idle@bcs0: - shard-skl: NOTRUN -> [INCOMPLETE][5] ([i915#3316]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20162/shard-skl5/igt@gem_ctx_ringsize@i...@bcs0.html * igt@gem_ctx_sseu@engines: - shard-tglb: NOTRUN -> [SKIP][6] ([i915#280]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20162/shard-tglb8/igt@gem_ctx_s...@engines.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-tglb5/igt@gem_exec_fair@basic-f...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20162/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_suspend@basic-s3: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-kbl7/igt@gem_exec_susp...@basic-s3.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20162/shard-kbl7/igt@gem_exec_susp...@basic-s3.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#2190]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20162/shard-apl7/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@big-copy-xy: - shard-skl: [PASS][12] -> [FAIL][13] ([i915#307]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl7/igt@gem_mmap_...@big-copy-xy.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20162/shard-skl7/igt@gem_mmap_...@big-copy-xy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy: - shard-glk: [PASS][14] -> [INCOMPLETE][15] ([i915#2055] / [i915#3468]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-glk8/igt@gem_mmap_...@cpuset-basic-small-copy.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20162/shard-glk3/igt@gem_mmap_...@cpuset-basic-small-copy.html - shard-snb: NOTRUN -> [INCOMPLETE][16] ([i915#2055] / [i915#3468]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20162/shard-snb5/igt@gem_mmap_...@cpuset-basic-small-copy.html - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([i915#198] / [i915#3468]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl4/igt@gem_mmap_...@cpuset-basic-small-copy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20162/shard-skl2/igt@gem_mmap_...@cpuset-basic-small-copy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-xy: - shard-snb:
[Intel-gfx] ✗ Fi.CI.BAT: failure for Pipe DMC Support
== Series Details ==
Series: Pipe DMC Support
URL : https://patchwork.freedesktop.org/series/90445/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10120 -> Patchwork_20175
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_20175 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20175, 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_20175/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_20175:
### IGT changes ###
Possible regressions
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-skl-6700k2: [PASS][1] -> [DMESG-WARN][2] +3 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-skl-6700k2/igt@kms_chamel...@common-hpd-after-suspend.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20175/fi-skl-6700k2/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-skl-6600u: [PASS][3] -> [DMESG-WARN][4] +2 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-skl-6600u/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20175/fi-skl-6600u/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@runner@aborted:
- {fi-rkl-11500t}:NOTRUN -> [FAIL][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20175/fi-rkl-11500t/igt@run...@aborted.html
- {fi-tgl-dsi}: [FAIL][6] ([i915#1436] / [i915#2966]) -> [FAIL][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-tgl-dsi/igt@run...@aborted.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20175/fi-tgl-dsi/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_20175 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-kbl-soraka: [PASS][8] -> [DMESG-WARN][9] ([i915#1982])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-kbl-soraka/igt@i915_module_l...@reload.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20175/fi-kbl-soraka/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6600u: [PASS][10] -> [SKIP][11] ([fdo#109271]) +2 similar
issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-skl-6600u/igt@i915_pm_...@module-reload.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20175/fi-skl-6600u/igt@i915_pm_...@module-reload.html
- fi-skl-6700k2: [PASS][12] -> [SKIP][13] ([fdo#109271]) +2 similar
issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-skl-6700k2/igt@i915_pm_...@module-reload.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20175/fi-skl-6700k2/igt@i915_pm_...@module-reload.html
Possible fixes
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [FAIL][14] ([i915#1372]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20175/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2: [FAIL][16] ([i915#49]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20175/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
Warnings
* igt@i915_selftest@live@execlists:
- fi-cfl-8109u: [INCOMPLETE][18] ([i915#3462]) -> [DMESG-FAIL][19]
([i915#3462])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20175/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
* igt@runner@aborted:
- fi-cfl-8700k: [FAIL][20] ([i915#3363]) -> [FAIL][21] ([i915#2426] /
[i915#3363])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-cfl-8700k/igt@run...@aborted.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20175/fi-cfl-8700k/igt@run...@aborted.html
- fi-cfl-8109u: [FAIL][22] ([i915#3363]) -> [FAIL][23] ([i915#2426] /
[i915#3363])
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-cfl-8109u/igt@run...@aborted.html
[23]:
Re: [Intel-gfx] [PATCH 3/7] drm/i915/dmc: Move struct intel_dmc to intel_dmc.h
On Fri, May 21, 2021 at 04:01:10PM -0700, Anusha Srivatsa wrote:
Move struct intel_dmc from i915_drv.h to intel_dmc.h.
v2: Add includes along with moving the struct.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_dmc.h | 21 +
drivers/gpu/drm/i915/i915_drv.h | 18 +-
2 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.h
b/drivers/gpu/drm/i915/display/intel_dmc.h
index 64816f4a71b6..8baeb85cf8db 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.h
+++ b/drivers/gpu/drm/i915/display/intel_dmc.h
@@ -6,12 +6,33 @@
#ifndef __INTEL_DMC_H__
#define __INTEL_DMC_H__
+#include
I can't find what this is for in this patch. You actually need
other than that,
Reviewed-by: Lucas De Marchi
Lucas De Marchi
+#include "intel_wakeref.h"
+#include "i915_reg.h"
+
struct drm_i915_private;
#define DMC_VERSION(major, minor) ((major) << 16 | (minor))
#define DMC_VERSION_MAJOR(version) ((version) >> 16)
#define DMC_VERSION_MINOR(version) ((version) & 0x)
+struct intel_dmc {
+ struct work_struct work;
+ const char *fw_path;
+ u32 required_version;
+ u32 max_fw_size; /* bytes */
+ u32 *dmc_payload;
+ u32 dmc_fw_size; /* dwords */
+ u32 version;
+ u32 mmio_count;
+ i915_reg_t mmioaddr[20];
+ u32 mmiodata[20];
+ u32 dc_state;
+ u32 target_dc_state;
+ u32 allowed_dc_mask;
+ intel_wakeref_t wakeref;
+};
+
void intel_dmc_ucode_init(struct drm_i915_private *i915);
void intel_dmc_load_program(struct drm_i915_private *i915);
void intel_dmc_ucode_fini(struct drm_i915_private *i915);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9cb02618ba15..b5962768a1f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -67,6 +67,7 @@
#include "display/intel_bios.h"
#include "display/intel_display.h"
#include "display/intel_display_power.h"
+#include "display/intel_dmc.h"
#include "display/intel_dpll_mgr.h"
#include "display/intel_dsb.h"
#include "display/intel_frontbuffer.h"
@@ -328,23 +329,6 @@ struct drm_i915_display_funcs {
void (*read_luts)(struct intel_crtc_state *crtc_state);
};
-struct intel_dmc {
- struct work_struct work;
- const char *fw_path;
- u32 required_version;
- u32 max_fw_size; /* bytes */
- u32 *dmc_payload;
- u32 dmc_fw_size; /* dwords */
- u32 version;
- u32 mmio_count;
- i915_reg_t mmioaddr[20];
- u32 mmiodata[20];
- u32 dc_state;
- u32 target_dc_state;
- u32 allowed_dc_mask;
- intel_wakeref_t wakeref;
-};
-
enum i915_cache_level {
I915_CACHE_NONE = 0,
I915_CACHE_LLC, /* also used for snoopable memory on non-LLC */
--
2.25.0
___
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 06/11] drm/: drm_gem_plane_helper_prepare_fb is now the default
Hi, Daniel: Daniel Vetter 於 2021年5月21日 週五 下午5:10寫道： > > No need to set it explicitly. > > Signed-off-by: Daniel Vetter > Cc: Laurentiu Palcu > Cc: Lucas Stach > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: Pengutronix Kernel Team > Cc: Fabio Estevam > Cc: NXP Linux Team > Cc: Philipp Zabel > Cc: Paul Cercueil > Cc: Chun-Kuang Hu > Cc: Matthias Brugger > Cc: Neil Armstrong > Cc: Kevin Hilman > Cc: Jerome Brunet > Cc: Martin Blumenstingl > Cc: Marek Vasut > Cc: Stefan Agner > Cc: Sandy Huang > Cc: "Heiko Stübner" > Cc: Yannick Fertre > Cc: Philippe Cornu > Cc: Benjamin Gaignard > Cc: Maxime Coquelin > Cc: Alexandre Torgue > Cc: Maxime Ripard > Cc: Chen-Yu Tsai > Cc: Jernej Skrabec > Cc: Jyri Sarha > Cc: Tomi Valkeinen > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-m...@vger.kernel.org > Cc: linux-media...@lists.infradead.org > Cc: linux-amlo...@lists.infradead.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-st...@st-md-mailman.stormreply.com > Cc: linux-su...@lists.linux.dev For Mediatek, Acked-by: Chun-Kuang Hu ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Pipe DMC Support
== Series Details == Series: Pipe DMC Support URL : https://patchwork.freedesktop.org/series/90445/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1887:21:expected struct i915_vma *[assigned] vma +drivers/gpu/drm/i915/display/intel_display.c:1887:21:got void [noderef] __iomem *[assigned] iomem +drivers/gpu/drm/i915/display/intel_display.c:1887:21: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1329:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/intel_ring_submission.c:1203:24: warning: Using plain integer as NULL pointer +drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 16777216 +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block
[Intel-gfx] ✓ Fi.CI.IGT: success for Core TTM changes for i915 TTM enabling
== Series Details == Series: Core TTM changes for i915 TTM enabling URL : https://patchwork.freedesktop.org/series/90373/ State : success == Summary == CI Bug Log - changes from CI_DRM_10113_full -> Patchwork_20161_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20161_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-skl: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24]) -> ([PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [FAIL][45], [PASS][46], [PASS][47]) ([i915#3174]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl4/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl4/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl3/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl3/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl2/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl2/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl10/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl10/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl10/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl1/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl1/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl1/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl9/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl9/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl7/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl7/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl7/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl6/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl6/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl6/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl5/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl5/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl5/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/shard-skl4/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/shard-skl2/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/shard-skl2/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/shard-skl2/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/shard-skl10/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/shard-skl10/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/shard-skl10/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/shard-skl1/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/shard-skl1/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/shard-skl1/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/shard-skl9/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/shard-skl9/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/shard-skl7/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/shard-skl7/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/shard-skl7/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/shard-skl6/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/shard-skl6/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/shard-skl5/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/shard-skl5/boot.html [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/shard-skl5/boot.html [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/shard-skl4/boot.html [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/shard-skl3/boot.html
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Pipe DMC Support
== Series Details ==
Series: Pipe DMC Support
URL : https://patchwork.freedesktop.org/series/90445/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a8b7ab0262fe drm/i915/dmc: s/DRM_ERROR/drm_err
-:80: WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message
#80: FILE: drivers/gpu/drm/i915/display/intel_dmc.c:487:
if (!dmc->dmc_payload) {
+ drm_err(>drm, "Memory allocation failed for dmc
payload\n");
total: 0 errors, 1 warnings, 0 checks, 140 lines checked
f6d008702d42 drm/i915/dmc: Add intel_dmc_has_payload() helper
75977e83820a drm/i915/dmc: Move struct intel_dmc to intel_dmc.h
3af09944a9b8 drm/i915/dmc: Introduce DMC_FW_MAIN
3123bc3537b1 drm/i915/xelpd: Pipe A DMC plugging
-:39: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#39: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:587:
+ intel_de_read(dev_priv,
DMC_PROGRAM(dmc->dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)));
-:54: WARNING:LONG_LINE: line length of 105 exceeds 100 columns
#54: FILE: drivers/gpu/drm/i915/display/intel_display_power.c:965:
+
DMC_PROGRAM(dev_priv->dmc.dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)),
-:147: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#147: FILE: drivers/gpu/drm/i915/display/intel_dmc.c:387:
+ drm_notice(>drm, "Invalid firmware id:
%d\n", fw_info[i].dmc_id);
total: 0 errors, 3 warnings, 0 checks, 263 lines checked
25192ad69b25 drm/i915/adl_p: Pipe B DMC Support
7faebf7b9853 drm/i915/adl_p: Load DMC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/7] drm/i915/adl_p: Load DMC
Load DMC v2.06 on ADLP. The release notes mention that
this version enables few power savings features.
Cc: Lucas De Marchi
Cc: Clint Taylor
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_dmc.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 3b3bb15e6a24..e1a7426cb7b6 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -45,6 +45,10 @@
#define GEN12_DMC_MAX_FW_SIZE ICL_DMC_MAX_FW_SIZE
+#define ADLP_DMC_PATH "i915/adlp_dmc_ver2_10.bin"
+#define ADLP_DMC_VERSION_REQUIRED DMC_VERSION(2, 10)
+MODULE_FIRMWARE(ADLP_DMC_PATH);
+
#define ADLS_DMC_PATH DMC_PATH(adls, 2, 01)
#define ADLS_DMC_VERSION_REQUIRED DMC_VERSION(2, 1)
MODULE_FIRMWARE(ADLS_DMC_PATH);
@@ -722,7 +726,11 @@ void intel_dmc_ucode_init(struct drm_i915_private
*dev_priv)
*/
intel_dmc_runtime_pm_get(dev_priv);
- if (IS_ALDERLAKE_S(dev_priv)) {
+ if (IS_ALDERLAKE_P(dev_priv)) {
+ dmc->fw_path = ADLP_DMC_PATH;
+ dmc->required_version = ADLP_DMC_VERSION_REQUIRED;
+ dmc->max_fw_size = GEN12_DMC_MAX_FW_SIZE;
+ } else if (IS_ALDERLAKE_S(dev_priv)) {
dmc->fw_path = ADLS_DMC_PATH;
dmc->required_version = ADLS_DMC_VERSION_REQUIRED;
dmc->max_fw_size = GEN12_DMC_MAX_FW_SIZE;
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/7] Pipe DMC Support
Adding the actual Pipe DMC bits. This series is rebased on top of "More DMC cleanup": https://patchwork.freedesktop.org/series/90379/ Anusha Srivatsa (7): drm/i915/dmc: s/DRM_ERROR/drm_err drm/i915/dmc: Add intel_dmc_has_payload() helper drm/i915/dmc: Move struct intel_dmc to intel_dmc.h drm/i915/dmc: Introduce DMC_FW_MAIN drm/i915/xelpd: Pipe A DMC plugging drm/i915/adl_p: Pipe B DMC Support drm/i915/adl_p: Load DMC .../drm/i915/display/intel_display_debugfs.c | 10 +- .../drm/i915/display/intel_display_power.c| 21 +- drivers/gpu/drm/i915/display/intel_dmc.c | 212 ++ drivers/gpu/drm/i915/display/intel_dmc.h | 35 +++ drivers/gpu/drm/i915/i915_drv.h | 18 +- drivers/gpu/drm/i915/i915_gpu_error.c | 2 +- drivers/gpu/drm/i915/i915_reg.h | 2 +- 7 files changed, 178 insertions(+), 122 deletions(-) -- 2.25.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/7] drm/i915/xelpd: Pipe A DMC plugging
This patch adds Pipe A plumbing to the already
existing parsing and loading functions which is
taken care of in the prep patches. Adding MAX_DMC_FW
to keep track for both Main and Pipe A DMC while loading
the respective blobs.
Also adding present field in dmc_info.
s/find_dmc_fw_offset/csr_set_dmc_fw_offset. While at it add
fw_info_matches_stepping() helper. CSR_PROGRAM() should now
take the starting address of the particular blob (Main or Pipe)
and not hardcode it.
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
---
.../drm/i915/display/intel_display_debugfs.c | 4 +-
.../drm/i915/display/intel_display_power.c| 5 +-
drivers/gpu/drm/i915/display/intel_dmc.c | 121 ++
drivers/gpu/drm/i915/display/intel_dmc.h | 2 +
drivers/gpu/drm/i915/i915_reg.h | 2 +-
5 files changed, 79 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 88bb05d5c483..2a1c39a0e56e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -544,6 +544,8 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
seq_printf(m, "fw loaded: %s\n",
yesno(intel_dmc_has_payload(dev_priv)));
seq_printf(m, "path: %s\n", dmc->fw_path);
+ seq_printf(m, "Pipe A fw support: %s\n", yesno(INTEL_GEN(dev_priv) >=
12));
+ seq_printf(m, "Pipe A fw loaded: %s\n",
yesno(dmc->dmc_info[DMC_FW_PIPEA].payload));
if (!intel_dmc_has_payload(dev_priv))
goto out;
@@ -582,7 +584,7 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
out:
seq_printf(m, "program base: 0x%08x\n",
- intel_de_read(dev_priv, DMC_PROGRAM(0)));
+ intel_de_read(dev_priv,
DMC_PROGRAM(dmc->dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)));
seq_printf(m, "ssp base: 0x%08x\n",
intel_de_read(dev_priv, DMC_SSP_BASE));
seq_printf(m, "htp: 0x%08x\n", intel_de_read(dev_priv, DMC_HTP_SKL));
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index b546672c9b00..dce7f1d1540f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -961,8 +961,9 @@ static void bxt_disable_dc9(struct drm_i915_private
*dev_priv)
static void assert_dmc_loaded(struct drm_i915_private *dev_priv)
{
drm_WARN_ONCE(_priv->drm,
- !intel_de_read(dev_priv, DMC_PROGRAM(0)),
- "DMC program storage start is NULL\n");
+ !intel_de_read(dev_priv,
+
DMC_PROGRAM(dev_priv->dmc.dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)),
+"DMC program storage start is NULL\n");
drm_WARN_ONCE(_priv->drm, !intel_de_read(dev_priv, DMC_SSP_BASE),
"DMC SSP Base Not fine\n");
drm_WARN_ONCE(_priv->drm, !intel_de_read(dev_priv, DMC_HTP_SKL),
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 16bfbca6c1ed..3b3bb15e6a24 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -317,8 +317,7 @@ static void gen9_set_dc_state_debugmask(struct
drm_i915_private *dev_priv)
void intel_dmc_load_program(struct drm_i915_private *dev_priv)
{
struct intel_dmc *dmc = _priv->dmc;
- struct dmc_fw_info *dmc_info = >dmc_info[DMC_FW_MAIN];
- u32 i, fw_size;
+ u32 id, i;
if (!HAS_DMC(dev_priv)) {
drm_err(_priv->drm,
@@ -332,20 +331,25 @@ void intel_dmc_load_program(struct drm_i915_private
*dev_priv)
return;
}
- fw_size = dmc_info->dmc_fw_size;
assert_rpm_wakelock_held(_priv->runtime_pm);
preempt_disable();
- for (i = 0; i < fw_size; i++)
- intel_uncore_write_fw(_priv->uncore, DMC_PROGRAM(i),
- dmc_info->payload[i]);
+ for (id = 0; id < DMC_FW_MAX; id++) {
+ for (i = 0; i < dmc->dmc_info[id].dmc_fw_size; i++) {
+ intel_uncore_write_fw(_priv->uncore,
+
DMC_PROGRAM(dmc->dmc_info[id].start_mmioaddr, i),
+ dmc->dmc_info[id].payload[i]);
+ }
+ }
preempt_enable();
- for (i = 0; i < dmc_info->mmio_count; i++) {
- intel_de_write(dev_priv, dmc_info->mmioaddr[i],
- dmc_info->mmiodata[i]);
+ for (id = 0; id < DMC_FW_MAX; id++) {
+ for (i = 0; i < dmc->dmc_info[id].mmio_count; i++) {
+ intel_de_write(dev_priv, dmc->dmc_info[id].mmioaddr[i],
+
[Intel-gfx] [PATCH 6/7] drm/i915/adl_p: Pipe B DMC Support
ADLP requires us to load both Pipe A and Pipe B.
Plug Pipe B loading support.
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 ++
drivers/gpu/drm/i915/display/intel_dmc.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 2a1c39a0e56e..db38891a9ef0 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -546,6 +546,8 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
seq_printf(m, "path: %s\n", dmc->fw_path);
seq_printf(m, "Pipe A fw support: %s\n", yesno(INTEL_GEN(dev_priv) >=
12));
seq_printf(m, "Pipe A fw loaded: %s\n",
yesno(dmc->dmc_info[DMC_FW_PIPEA].payload));
+ seq_printf(m, "Pipe B fw support: %s\n",
yesno(IS_ALDERLAKE_P(dev_priv)));
+ seq_printf(m, "Pipe B fw loaded: %s\n",
yesno(dmc->dmc_info[DMC_FW_PIPEB].payload));
if (!intel_dmc_has_payload(dev_priv))
goto out;
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.h
b/drivers/gpu/drm/i915/display/intel_dmc.h
index 5b38cbdbdd34..5257bcf50fc5 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.h
+++ b/drivers/gpu/drm/i915/display/intel_dmc.h
@@ -19,6 +19,7 @@ struct drm_i915_private;
enum {
DMC_FW_MAIN = 0,
DMC_FW_PIPEA,
+ DMC_FW_PIPEB,
DMC_FW_MAX
};
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/7] drm/i915/dmc: Introduce DMC_FW_MAIN
This is a prep patch for Pipe DMC plugging.
Add dmc_info struct in intel_dmc to have all common fields
shared between all DMC's in the package.
Add DMC_FW_MAIN(dmc_id 0) to refer to the blob.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_dmc.c | 44 +++-
drivers/gpu/drm/i915/display/intel_dmc.h | 20 ---
2 files changed, 35 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index f9a0f194f9cf..16bfbca6c1ed 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -239,7 +239,7 @@ struct stepping_info {
bool intel_dmc_has_payload(struct drm_i915_private *i915)
{
- return i915->dmc.dmc_payload;
+ return i915->dmc.dmc_info[DMC_FW_MAIN].payload;
}
static const struct stepping_info skl_stepping_info[] = {
@@ -316,7 +316,8 @@ static void gen9_set_dc_state_debugmask(struct
drm_i915_private *dev_priv)
*/
void intel_dmc_load_program(struct drm_i915_private *dev_priv)
{
- u32 *payload = dev_priv->dmc.dmc_payload;
+ struct intel_dmc *dmc = _priv->dmc;
+ struct dmc_fw_info *dmc_info = >dmc_info[DMC_FW_MAIN];
u32 i, fw_size;
if (!HAS_DMC(dev_priv)) {
@@ -325,26 +326,26 @@ void intel_dmc_load_program(struct drm_i915_private
*dev_priv)
return;
}
- if (!intel_dmc_has_payload(dev_priv)) {
+ if (!dev_priv->dmc.dmc_info[DMC_FW_MAIN].payload) {
drm_err(_priv->drm,
"Tried to program CSR with empty payload\n");
return;
}
- fw_size = dev_priv->dmc.dmc_fw_size;
+ fw_size = dmc_info->dmc_fw_size;
assert_rpm_wakelock_held(_priv->runtime_pm);
preempt_disable();
for (i = 0; i < fw_size; i++)
intel_uncore_write_fw(_priv->uncore, DMC_PROGRAM(i),
- payload[i]);
+ dmc_info->payload[i]);
preempt_enable();
- for (i = 0; i < dev_priv->dmc.mmio_count; i++) {
- intel_de_write(dev_priv, dev_priv->dmc.mmioaddr[i],
- dev_priv->dmc.mmiodata[i]);
+ for (i = 0; i < dmc_info->mmio_count; i++) {
+ intel_de_write(dev_priv, dmc_info->mmioaddr[i],
+ dmc_info->mmiodata[i]);
}
dev_priv->dmc.dc_state = 0;
@@ -401,13 +402,14 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
size_t rem_size)
{
struct drm_i915_private *i915 = container_of(dmc, typeof(*i915), dmc);
+ struct dmc_fw_info *dmc_info = >dmc_info[DMC_FW_MAIN];
unsigned int header_len_bytes, dmc_header_size, payload_size, i;
const u32 *mmioaddr, *mmiodata;
u32 mmio_count, mmio_count_max;
u8 *payload;
- BUILD_BUG_ON(ARRAY_SIZE(dmc->mmioaddr) < DMC_V3_MAX_MMIO_COUNT ||
-ARRAY_SIZE(dmc->mmioaddr) < DMC_V1_MAX_MMIO_COUNT);
+ BUILD_BUG_ON(ARRAY_SIZE(dmc_info->mmioaddr) < DMC_V3_MAX_MMIO_COUNT ||
+ARRAY_SIZE(dmc_info->mmioaddr) < DMC_V1_MAX_MMIO_COUNT);
/*
* Check if we can access common fields, we will checkc again below
@@ -463,16 +465,10 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
}
for (i = 0; i < mmio_count; i++) {
- if (mmioaddr[i] < DMC_MMIO_START_RANGE ||
- mmioaddr[i] > DMC_MMIO_END_RANGE) {
- drm_err(>drm, "DMC firmware has wrong mmio
address 0x%x\n",
- mmioaddr[i]);
- return 0;
- }
- dmc->mmioaddr[i] = _MMIO(mmioaddr[i]);
- dmc->mmiodata[i] = mmiodata[i];
+ dmc_info->mmioaddr[i] = _MMIO(mmioaddr[i]);
+ dmc_info->mmiodata[i] = mmiodata[i];
}
- dmc->mmio_count = mmio_count;
+ dmc_info->mmio_count = mmio_count;
rem_size -= header_len_bytes;
@@ -485,16 +481,16 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
drm_err(>drm, "DMC FW too big (%u bytes)\n",
payload_size);
return 0;
}
- dmc->dmc_fw_size = dmc_header->fw_size;
+ dmc_info->dmc_fw_size = dmc_header->fw_size;
- dmc->dmc_payload = kmalloc(payload_size, GFP_KERNEL);
- if (!dmc->dmc_payload) {
+ dmc_info->payload = kmalloc(payload_size, GFP_KERNEL);
+ if (!dmc_info->payload) {
drm_err(>drm, "Memory allocation failed for dmc
payload\n");
return 0;
}
payload = (u8 *)(dmc_header) + header_len_bytes;
- memcpy(dmc->dmc_payload, payload, payload_size);
+ memcpy(dmc_info->payload, payload, payload_size);
return header_len_bytes + payload_size;
@@ -829,5 +825,5 @@ void intel_dmc_ucode_fini(struct
[Intel-gfx] [PATCH 3/7] drm/i915/dmc: Move struct intel_dmc to intel_dmc.h
Move struct intel_dmc from i915_drv.h to intel_dmc.h.
v2: Add includes along with moving the struct.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_dmc.h | 21 +
drivers/gpu/drm/i915/i915_drv.h | 18 +-
2 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.h
b/drivers/gpu/drm/i915/display/intel_dmc.h
index 64816f4a71b6..8baeb85cf8db 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.h
+++ b/drivers/gpu/drm/i915/display/intel_dmc.h
@@ -6,12 +6,33 @@
#ifndef __INTEL_DMC_H__
#define __INTEL_DMC_H__
+#include
+#include "intel_wakeref.h"
+#include "i915_reg.h"
+
struct drm_i915_private;
#define DMC_VERSION(major, minor) ((major) << 16 | (minor))
#define DMC_VERSION_MAJOR(version) ((version) >> 16)
#define DMC_VERSION_MINOR(version) ((version) & 0x)
+struct intel_dmc {
+ struct work_struct work;
+ const char *fw_path;
+ u32 required_version;
+ u32 max_fw_size; /* bytes */
+ u32 *dmc_payload;
+ u32 dmc_fw_size; /* dwords */
+ u32 version;
+ u32 mmio_count;
+ i915_reg_t mmioaddr[20];
+ u32 mmiodata[20];
+ u32 dc_state;
+ u32 target_dc_state;
+ u32 allowed_dc_mask;
+ intel_wakeref_t wakeref;
+};
+
void intel_dmc_ucode_init(struct drm_i915_private *i915);
void intel_dmc_load_program(struct drm_i915_private *i915);
void intel_dmc_ucode_fini(struct drm_i915_private *i915);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9cb02618ba15..b5962768a1f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -67,6 +67,7 @@
#include "display/intel_bios.h"
#include "display/intel_display.h"
#include "display/intel_display_power.h"
+#include "display/intel_dmc.h"
#include "display/intel_dpll_mgr.h"
#include "display/intel_dsb.h"
#include "display/intel_frontbuffer.h"
@@ -328,23 +329,6 @@ struct drm_i915_display_funcs {
void (*read_luts)(struct intel_crtc_state *crtc_state);
};
-struct intel_dmc {
- struct work_struct work;
- const char *fw_path;
- u32 required_version;
- u32 max_fw_size; /* bytes */
- u32 *dmc_payload;
- u32 dmc_fw_size; /* dwords */
- u32 version;
- u32 mmio_count;
- i915_reg_t mmioaddr[20];
- u32 mmiodata[20];
- u32 dc_state;
- u32 target_dc_state;
- u32 allowed_dc_mask;
- intel_wakeref_t wakeref;
-};
-
enum i915_cache_level {
I915_CACHE_NONE = 0,
I915_CACHE_LLC, /* also used for snoopable memory on non-LLC */
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/7] drm/i915/dmc: Add intel_dmc_has_payload() helper
We check for dmc_payload being there at various points in the driver.
Replace it with the helper.
v2: rebased.
v3: Move intel_dmc to intel_dmc.h in another patch (Lucas)
v4: Remove headers not needed from intel_dmc.h
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
Reviewed-by: Lucas De Marchi
---
.../gpu/drm/i915/display/intel_display_debugfs.c | 4 ++--
.../gpu/drm/i915/display/intel_display_power.c | 16
drivers/gpu/drm/i915/display/intel_dmc.c | 13 +
drivers/gpu/drm/i915/display/intel_dmc.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c| 2 +-
5 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 94e5cbd86e77..88bb05d5c483 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -542,10 +542,10 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
wakeref = intel_runtime_pm_get(_priv->runtime_pm);
- seq_printf(m, "fw loaded: %s\n", yesno(dmc->dmc_payload));
+ seq_printf(m, "fw loaded: %s\n",
yesno(intel_dmc_has_payload(dev_priv)));
seq_printf(m, "path: %s\n", dmc->fw_path);
- if (!dmc->dmc_payload)
+ if (!intel_dmc_has_payload(dev_priv))
goto out;
seq_printf(m, "version: %d.%d\n", DMC_VERSION_MAJOR(dmc->version),
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 991ceea06a07..b546672c9b00 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -1220,7 +1220,7 @@ static void gen9_dc_off_power_well_enable(struct
drm_i915_private *dev_priv,
static void gen9_dc_off_power_well_disable(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
{
- if (!dev_priv->dmc.dmc_payload)
+ if (!intel_dmc_has_payload(dev_priv))
return;
switch (dev_priv->dmc.target_dc_state) {
@@ -5579,7 +5579,7 @@ static void skl_display_core_init(struct drm_i915_private
*dev_priv,
gen9_dbuf_enable(dev_priv);
- if (resume && dev_priv->dmc.dmc_payload)
+ if (resume && intel_dmc_has_payload(dev_priv))
intel_dmc_load_program(dev_priv);
}
@@ -5646,7 +5646,7 @@ static void bxt_display_core_init(struct drm_i915_private
*dev_priv, bool resume
gen9_dbuf_enable(dev_priv);
- if (resume && dev_priv->dmc.dmc_payload)
+ if (resume && intel_dmc_has_payload(dev_priv))
intel_dmc_load_program(dev_priv);
}
@@ -5712,7 +5712,7 @@ static void cnl_display_core_init(struct drm_i915_private
*dev_priv, bool resume
/* 6. Enable DBUF */
gen9_dbuf_enable(dev_priv);
- if (resume && dev_priv->dmc.dmc_payload)
+ if (resume && intel_dmc_has_payload(dev_priv))
intel_dmc_load_program(dev_priv);
}
@@ -5869,7 +5869,7 @@ static void icl_display_core_init(struct drm_i915_private
*dev_priv,
if (DISPLAY_VER(dev_priv) >= 12)
tgl_bw_buddy_init(dev_priv);
- if (resume && dev_priv->dmc.dmc_payload)
+ if (resume && intel_dmc_has_payload(dev_priv))
intel_dmc_load_program(dev_priv);
/* Wa_14011508470 */
@@ -6230,7 +6230,7 @@ void intel_power_domains_suspend(struct drm_i915_private
*i915,
*/
if (!(i915->dmc.allowed_dc_mask & DC_STATE_EN_DC9) &&
suspend_mode == I915_DRM_SUSPEND_IDLE &&
- i915->dmc.dmc_payload) {
+ intel_dmc_has_payload(i915)) {
intel_display_power_flush_work(i915);
intel_power_domains_verify_state(i915);
return;
@@ -6420,7 +6420,7 @@ void intel_display_power_resume(struct drm_i915_private
*i915)
if (DISPLAY_VER(i915) >= 11) {
bxt_disable_dc9(i915);
icl_display_core_init(i915, true);
- if (i915->dmc.dmc_payload) {
+ if (intel_dmc_has_payload(i915)) {
if (i915->dmc.allowed_dc_mask &
DC_STATE_EN_UPTO_DC6)
skl_enable_dc6(i915);
@@ -6431,7 +6431,7 @@ void intel_display_power_resume(struct drm_i915_private
*i915)
} else if (IS_GEMINILAKE(i915) || IS_BROXTON(i915)) {
bxt_disable_dc9(i915);
bxt_display_core_init(i915, true);
- if (i915->dmc.dmc_payload &&
+ if (intel_dmc_has_payload(i915) &&
(i915->dmc.allowed_dc_mask & DC_STATE_EN_UPTO_DC5))
gen9_enable_dc5(i915);
} else if (IS_HASWELL(i915) || IS_BROADWELL(i915)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index
[Intel-gfx] [PATCH 1/7] drm/i915/dmc: s/DRM_ERROR/drm_err
Use new format of debug messages across intel_csr.
While at it, change some function definitions which now
need dev_priv for drm_err and drm_info etc.
v2: use container_of() (Jani)
v3: Indentation fixes. (Jani)
Cc: Jani Nikula
Suggested-by: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_dmc.c | 48 +---
1 file changed, 26 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 560574dd929a..5887453ff302 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -395,6 +395,7 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
const struct intel_dmc_header_base *dmc_header,
size_t rem_size)
{
+ struct drm_i915_private *i915 = container_of(dmc, typeof(*i915), dmc);
unsigned int header_len_bytes, dmc_header_size, payload_size, i;
const u32 *mmioaddr, *mmiodata;
u32 mmio_count, mmio_count_max;
@@ -439,28 +440,28 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
header_len_bytes = dmc_header->header_len;
dmc_header_size = sizeof(*v1);
} else {
- DRM_ERROR("Unknown DMC fw header version: %u\n",
- dmc_header->header_ver);
+ drm_err(>drm, "Unknown DMC fw header version: %u\n",
+ dmc_header->header_ver);
return 0;
}
if (header_len_bytes != dmc_header_size) {
- DRM_ERROR("DMC firmware has wrong dmc header length "
- "(%u bytes)\n", header_len_bytes);
+ drm_err(>drm, "DMC firmware has wrong dmc header length "
+ "(%u bytes)\n", header_len_bytes);
return 0;
}
/* Cache the dmc header info. */
if (mmio_count > mmio_count_max) {
- DRM_ERROR("DMC firmware has wrong mmio count %u\n", mmio_count);
+ drm_err(>drm, "DMC firmware has wrong mmio count %u\n",
mmio_count);
return 0;
}
for (i = 0; i < mmio_count; i++) {
if (mmioaddr[i] < DMC_MMIO_START_RANGE ||
mmioaddr[i] > DMC_MMIO_END_RANGE) {
- DRM_ERROR("DMC firmware has wrong mmio address 0x%x\n",
- mmioaddr[i]);
+ drm_err(>drm, "DMC firmware has wrong mmio
address 0x%x\n",
+ mmioaddr[i]);
return 0;
}
dmc->mmioaddr[i] = _MMIO(mmioaddr[i]);
@@ -476,14 +477,14 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
goto error_truncated;
if (payload_size > dmc->max_fw_size) {
- DRM_ERROR("DMC FW too big (%u bytes)\n", payload_size);
+ drm_err(>drm, "DMC FW too big (%u bytes)\n",
payload_size);
return 0;
}
dmc->dmc_fw_size = dmc_header->fw_size;
dmc->dmc_payload = kmalloc(payload_size, GFP_KERNEL);
if (!dmc->dmc_payload) {
- DRM_ERROR("Memory allocation failed for dmc payload\n");
+ drm_err(>drm, "Memory allocation failed for dmc
payload\n");
return 0;
}
@@ -493,7 +494,7 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
return header_len_bytes + payload_size;
error_truncated:
- DRM_ERROR("Truncated DMC firmware, refusing.\n");
+ drm_err(>drm, "Truncated DMC firmware, refusing.\n");
return 0;
}
@@ -503,6 +504,7 @@ parse_dmc_fw_package(struct intel_dmc *dmc,
const struct stepping_info *si,
size_t rem_size)
{
+ struct drm_i915_private *i915 = container_of(dmc, typeof(*i915), dmc);
u32 package_size = sizeof(struct intel_package_header);
u32 num_entries, max_entries, dmc_offset;
const struct intel_fw_info *fw_info;
@@ -515,8 +517,8 @@ parse_dmc_fw_package(struct intel_dmc *dmc,
} else if (package_header->header_ver == 2) {
max_entries = PACKAGE_V2_MAX_FW_INFO_ENTRIES;
} else {
- DRM_ERROR("DMC firmware has unknown header version %u\n",
- package_header->header_ver);
+ drm_err(>drm, "DMC firmware has unknown header version
%u\n",
+ package_header->header_ver);
return 0;
}
@@ -529,8 +531,8 @@ parse_dmc_fw_package(struct intel_dmc *dmc,
goto error_truncated;
if (package_header->header_len * 4 != package_size) {
- DRM_ERROR("DMC firmware has wrong package header length "
- "(%u bytes)\n", package_size);
+ drm_err(>drm, "DMC firmware has wrong package header
length "
+
Re: [Intel-gfx] [PATCH 11/11] drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default
On 5/21/21 12:09 PM, Daniel Vetter wrote: > Goes through all the drivers and deletes the default hook since it's > the default now. > > Signed-off-by: Daniel Vetter Acked-by: Oleksandr Andrushchenko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 18/23] drm/i915/display: Introduce new intel_psr_pause/resume function
On Fri, 2021-05-21 at 11:58 +0100, Mun, Gwan-gyeong wrote:
> On Tue, 2021-05-18 at 14:06 +0300, Ville Syrjälä wrote:
> > On Tue, May 18, 2021 at 09:33:09AM +, Mun, Gwan-gyeong wrote:
> > > Hi Ville,
> > > initially, intel_psr_pause() called intel_psr_disable_locked()
> > > instead
> > > of intel_psr_exit().
> > > In intel_psr_resume(), _intel_psr_enable_locked() was called instead
> > > of
> > > intel_psr_activate().
> > > Can you share what problem the initial code caused when calling
> > > intel_psr_pause() / intel_psr_resume()?
> >
> > It was doing illegal stuff with crtc->state/etc. That was oopsing.
> > The other problem was that IIRC it was going to do DPCD accesses
> > while the cdclk code was already holding the aux mutexes. I moved it
> > out from under the lock, but I think we might actually want it inside
> > the lock since we'll need that to prevent PSR during all AUX transfers
> > anyway. Putting it back inside the lock should also make it less racy
> > I guess.
> >
> > >
> > > In addition, intel_psr_exit() /intel_psr_activate() function disable
> > > /
> > > enable only the PSR source.
> > > So, if disable/enable for PSR Sink Device is not called together,
> > > there
> > > will be a problem that the PSR state machine of sink and source is
> > > different.
> > > What do you think?
> >
> > If possible I wouldn't want it touch the sink at all. It should
> > basically be no different to eg. enabling the vblank interrupt.
> >
>
> Hi Ville and Stan,
> Thanks, Ville, for explaining.
>
> intel_psr_pause() and intel_psr_resume() are an api added to use when
> reactivating (disable and enable) the psr functionality without
> intel_crtc_state and drm_connector_state, as described in the commit
> log.
> And in order to deactivate and activate psr normally, we must
> deactivate the psr functionality of the sink as well, and at this time,
> sink psr deactivate using dpcd.
>
> And in the part explaining disabling psr in cdclk setting in bspec, the
> following procedure is explained for disabling psr.
> 1. Temporarily disable PSR1, PSR2, and GTC.
> 2. Wait for disabling status from those functions.
> 3. Wait for any pending Aux transactions to complete, and do not start
> any new Aux transaction.
> ...
I don't think we need to disable, psr_exit() + wait until PSR is idle is
enough, all other stuff can be left as is.
>
> So, in my opinion, when the cdclk setting is called from
> intel_atomic_commit_tail() with functions such as
> intel_set_cdclk_pre_plane_update() /
> intel_set_cdclk_post_plane_update(),
> if psr deactivation/activation is necessary, it seems that
> intel_set_cdclk_pre_plane_update() /
> intel_set_cdclk_post_plane_update() should be called with
> intel_psr_enable() / intel_psr_disable() functions together. What do
> you think?
>
> Br,
> G.G.
> > >
> > > On Mon, 2021-05-17 at 09:58 -0700, Souza, Jose wrote:
> > > > On Fri, 2021-05-14 at 20:10 -0700, Matt Roper wrote:
> > > > > From: Gwan-gyeong Mun
> > > > >
> > > > > This introduces the following function that can enable and
> > > > > disable
> > > > > psr
> > > > > without intel_crtc_state/drm_connector_state when intel_psr is
> > > > > already
> > > > > enabled with current intel_crtc_state and drm_connector_state
> > > > > information.
> > > > >
> > > > > - intel_psr_pause(): Pause current PSR. it deactivates current
> > > > > psr
> > > > > state.
> > > > > - intel_psr_resume(): Resume paused PSR without intel_crtc_state
> > > > > and
> > > > > drm_connector_state. It activates paused
> > > > > psr
> > > > > state.
> > > > >
> > > > > Cc: José Roberto de Souza
> > > > > Cc: Stanislav Lisovskiy
> > > > > Cc: Ville Syrjälä
> > > > > Signed-off-by: Gwan-gyeong Mun
> > > > > Signed-off-by: Matt Roper
> > > > > ---
> > > > > .../drm/i915/display/intel_display_types.h | 1 +
> > > > > drivers/gpu/drm/i915/display/intel_psr.c | 93
> > > > > -
> > > > > --
> > > > > drivers/gpu/drm/i915/display/intel_psr.h | 2 +
> > > > > 3 files changed, 82 insertions(+), 14 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > index b8d1f702d808..ee7cbdd7db87 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > @@ -1482,6 +1482,7 @@ struct intel_psr {
> > > > > bool sink_support;
> > > > > bool source_support;
> > > > > bool enabled;
> > > > > + bool paused;
> > > > > enum pipe pipe;
> > > > > enum transcoder transcoder;
> > > > > bool active;
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > index 4a63d10876ce..d4df3f5e7918 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > +++
[Intel-gfx] ✓ Fi.CI.BAT: success for More DMC cleanup (rev3)
== Series Details ==
Series: More DMC cleanup (rev3)
URL : https://patchwork.freedesktop.org/series/90379/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10120 -> Patchwork_20174
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20174/index.html
Known issues
Here are the changes found in Patchwork_20174 that come from known issues:
### IGT changes ###
Possible fixes
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2: [FAIL][1] ([i915#49]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20174/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
Warnings
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][3] ([i915#2782] / [i915#2940] /
[i915#3462]) -> [DMESG-FAIL][4] ([i915#3462])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20174/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@runner@aborted:
- fi-glk-dsi: [FAIL][5] ([i915#2426] / [i915#3363] /
[k.org#202321]) -> [FAIL][6] ([i915#3363] / [k.org#202321])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-glk-dsi/igt@run...@aborted.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20174/fi-glk-dsi/igt@run...@aborted.html
- fi-kbl-r: [FAIL][7] ([i915#1436] / [i915#3363]) -> [FAIL][8]
([i915#1436] / [i915#2426] / [i915#3363])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-kbl-r/igt@run...@aborted.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20174/fi-kbl-r/igt@run...@aborted.html
- fi-bdw-5557u: [FAIL][9] ([i915#3462]) -> [FAIL][10] ([i915#1602] /
[i915#2029])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-bdw-5557u/igt@run...@aborted.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20174/fi-bdw-5557u/igt@run...@aborted.html
- fi-kbl-soraka: [FAIL][11] ([i915#1436] / [i915#2426] / [i915#3363])
-> [FAIL][12] ([i915#1436] / [i915#3363])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-kbl-soraka/igt@run...@aborted.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20174/fi-kbl-soraka/igt@run...@aborted.html
- fi-cml-u2: [FAIL][13] ([i915#2082] / [i915#2426] / [i915#3363] /
[i915#3462]) -> [FAIL][14] ([i915#3363] / [i915#3462])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-cml-u2/igt@run...@aborted.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20174/fi-cml-u2/igt@run...@aborted.html
- fi-skl-6700k2: [FAIL][15] ([i915#1436] / [i915#2426] / [i915#3363])
-> [FAIL][16] ([i915#1436] / [i915#3363])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-skl-6700k2/igt@run...@aborted.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20174/fi-skl-6700k2/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
[i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
[i915#2082]: https://gitlab.freedesktop.org/drm/intel/issues/2082
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
[i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
[i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
[i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
[i915#3276]: https://gitlab.freedesktop.org/drm/intel/issues/3276
[i915#3277]: https://gitlab.freedesktop.org/drm/intel/issues/3277
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3283]: https://gitlab.freedesktop.org/drm/intel/issues/3283
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
[i915#3462]: https://gitlab.freedesktop.org/drm/intel/issues/3462
[i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
[k.org#202321]: https://bugzilla.kernel.org/show_bug.cgi?id=202321
Participating hosts (41 -> 39)
Re: [Intel-gfx] [PATCH v6 1/9] drm/i915/dpcd_bl: Remove redundant AUX backlight frequency calculations
On Fri, May 14, 2021 at 02:14:55PM -0400, Lyude Paul wrote:
> Noticed this while moving all of the VESA backlight code in i915 over to
> DRM helpers: it would appear that we calculate the frequency value we want
> to write to DP_EDP_BACKLIGHT_FREQ_SET twice even though this value never
> actually changes during runtime. So, let's simplify things by just caching
> this value in intel_panel.backlight, and re-writing it as-needed.
>
> Changes since v1:
> * Wrap panel->backlight.edp.vesa.pwm_freq_pre_divider in
> DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP check - Jani
This looks okay to me now... Jani, agree?
>
> Signed-off-by: Lyude Paul
> Cc: Jani Nikula
> Cc: Dave Airlie
> Cc: greg.depo...@gmail.com
> ---
> .../drm/i915/display/intel_display_types.h| 1 +
> .../drm/i915/display/intel_dp_aux_backlight.c | 65 ++-
> 2 files changed, 20 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 9c0adfc60c6f..7054a37363fb 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -311,6 +311,7 @@ struct intel_panel {
> union {
> struct {
> u8 pwmgen_bit_count;
> + u8 pwm_freq_pre_divider;
> } vesa;
> struct {
> bool sdr_uses_aux;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index 8e9ac9ba1d38..68bfe50ada59 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -373,50 +373,6 @@ intel_dp_aux_vesa_set_backlight(const struct
> drm_connector_state *conn_state,
> }
> }
>
> -/*
> - * Set PWM Frequency divider to match desired frequency in vbt.
> - * The PWM Frequency is calculated as 27Mhz / (F x P).
> - * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
> - * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
> - * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
> - * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
> - */
> -static bool intel_dp_aux_vesa_set_pwm_freq(struct intel_connector *connector)
> -{
> - struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> - struct intel_dp *intel_dp = intel_attached_dp(connector);
> - const u8 pn = connector->panel.backlight.edp.vesa.pwmgen_bit_count;
> - int freq, fxp, f, fxp_actual, fxp_min, fxp_max;
> -
> - freq = dev_priv->vbt.backlight.pwm_freq_hz;
> - if (!freq) {
> - drm_dbg_kms(_priv->drm,
> - "Use panel default backlight frequency\n");
> - return false;
> - }
> -
> - fxp = DIV_ROUND_CLOSEST(KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ), freq);
> - f = clamp(DIV_ROUND_CLOSEST(fxp, 1 << pn), 1, 255);
> - fxp_actual = f << pn;
> -
> - /* Ensure frequency is within 25% of desired value */
> - fxp_min = DIV_ROUND_CLOSEST(fxp * 3, 4);
> - fxp_max = DIV_ROUND_CLOSEST(fxp * 5, 4);
> -
> - if (fxp_min > fxp_actual || fxp_actual > fxp_max) {
> - drm_dbg_kms(_priv->drm, "Actual frequency out of range\n");
> - return false;
> - }
> -
> - if (drm_dp_dpcd_writeb(_dp->aux,
> -DP_EDP_BACKLIGHT_FREQ_SET, (u8) f) < 0) {
> - drm_dbg_kms(_priv->drm,
> - "Failed to write aux backlight freq\n");
> - return false;
> - }
> - return true;
> -}
> -
> static void
> intel_dp_aux_vesa_enable_backlight(const struct intel_crtc_state *crtc_state,
> const struct drm_connector_state
> *conn_state, u32 level)
> @@ -459,9 +415,13 @@ intel_dp_aux_vesa_enable_backlight(const struct
> intel_crtc_state *crtc_state,
> break;
> }
>
> - if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP)
> - if (intel_dp_aux_vesa_set_pwm_freq(connector))
> + if (panel->backlight.edp.vesa.pwm_freq_pre_divider) {
> + if (drm_dp_dpcd_writeb(_dp->aux,
> DP_EDP_BACKLIGHT_FREQ_SET,
> +
> panel->backlight.edp.vesa.pwm_freq_pre_divider) == 1)
> new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
> + else
> + drm_dbg_kms(>drm, "Failed to write aux backlight
> frequency\n");
> + }
>
> if (new_dpcd_buf != dpcd_buf) {
> if (drm_dp_dpcd_writeb(_dp->aux,
> @@ -482,6 +442,14 @@ static void intel_dp_aux_vesa_disable_backlight(const
> struct drm_connector_state
> false);
> }
>
> +/*
> + * Compute PWM frequency divider value based off the frequency provided
Re: [Intel-gfx] [PATCH v6 8/9] drm/dp: Extract i915's eDP backlight code into DRM helpers
On Fri, May 14, 2021 at 02:15:02PM -0400, Lyude Paul wrote:
> Since we're about to implement eDP backlight support in nouveau using the
> standard protocol from VESA, we might as well just take the code that's
> already written for this and move it into a set of shared DRM helpers.
>
> Note that these helpers are intended to handle DPCD related backlight
> control bits such as setting the brightness level over AUX, probing the
> backlight's TCON, enabling/disabling the backlight over AUX if supported,
> etc. Any PWM-related portions of backlight control are explicitly left up
> to the driver, as these will vary from platform to platform.
>
> The only exception to this is the calculation of the PWM frequency
> pre-divider value. This is because the only platform-specific information
> required for this is the PWM frequency of the panel, which the driver is
> expected to provide if available. The actual algorithm for calculating this
> value is standard and is defined in the eDP specification from VESA.
>
> Note that these helpers do not yet implement the full range of features
> the VESA backlight interface provides, and only provide the following
> functionality (all of which was already present in i915's DPCD backlight
> support):
>
> * Basic control of brightness levels
> * Basic probing of backlight capabilities
> * Helpers for enabling and disabling the backlight
>
> v3:
> * Split out changes to i915's backlight code to separate patches to make it
> easier to review
> v4:
> * Style/spelling changes from Thomas Zimmermann
> v5:
> * Start using new drm_dbg_*() functions
This version was indeed much easier to review. Thanks for addressing all the
comments.
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: Lyude Paul
> Cc: Jani Nikula
> Cc: Dave Airlie
> Cc: greg.depo...@gmail.com
> ---
> drivers/gpu/drm/drm_dp_helper.c | 347 ++
> .../drm/i915/display/intel_display_types.h| 5 +-
> .../drm/i915/display/intel_dp_aux_backlight.c | 285 ++
> include/drm/drm_dp_helper.h | 48 +++
> 4 files changed, 427 insertions(+), 258 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 55b53df6ce34..24bbc710c825 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -3115,3 +3115,350 @@ int drm_dp_pcon_convert_rgb_to_ycbcr(struct
> drm_dp_aux *aux, u8 color_spc)
> return 0;
> }
> EXPORT_SYMBOL(drm_dp_pcon_convert_rgb_to_ycbcr);
> +
> +/**
> + * drm_edp_backlight_set_level() - Set the backlight level of an eDP panel
> via AUX
> + * @aux: The DP AUX channel to use
> + * @bl: Backlight capability info from drm_edp_backlight_init()
> + * @level: The brightness level to set
> + *
> + * Sets the brightness level of an eDP panel's backlight. Note that the
> panel's backlight must
> + * already have been enabled by the driver by calling
> drm_edp_backlight_enable().
> + *
> + * Returns: %0 on success, negative error code on failure
> + */
> +int drm_edp_backlight_set_level(struct drm_dp_aux *aux, const struct
> drm_edp_backlight_info *bl,
> + u16 level)
> +{
> + int ret;
> + u8 buf[2] = { 0 };
> +
> + if (bl->lsb_reg_used) {
> + buf[0] = (level & 0xff00) >> 8;
> + buf[1] = (level & 0x00ff);
> + } else {
> + buf[0] = level;
> + }
> +
> + ret = drm_dp_dpcd_write(aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB, buf,
> sizeof(buf));
> + if (ret != sizeof(buf)) {
> + drm_err(aux->drm_dev,
> + "%s: Failed to write aux backlight level: %d\n",
> + aux->name, ret);
> + return ret < 0 ? ret : -EIO;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_edp_backlight_set_level);
> +
> +static int
> +drm_edp_backlight_set_enable(struct drm_dp_aux *aux, const struct
> drm_edp_backlight_info *bl,
> + bool enable)
> +{
> + int ret;
> + u8 buf;
> +
> + /* The panel uses something other then DPCD for enabling its backlight
> */
> + if (!bl->aux_enable)
> + return 0;
> +
> + ret = drm_dp_dpcd_readb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, );
> + if (ret != 1) {
> + drm_err(aux->drm_dev, "%s: Failed to read eDP display control
> register: %d\n",
> + aux->name, ret);
> + return ret < 0 ? ret : -EIO;
> + }
> + if (enable)
> + buf |= DP_EDP_BACKLIGHT_ENABLE;
> + else
> + buf &= ~DP_EDP_BACKLIGHT_ENABLE;
> +
> + ret = drm_dp_dpcd_writeb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, buf);
> + if (ret != 1) {
> + drm_err(aux->drm_dev, "%s: Failed to write eDP display control
> register: %d\n",
> + aux->name, ret);
> + return ret < 0 ? ret : -EIO;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * drm_edp_backlight_enable() - Enable an eDP
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for More DMC cleanup (rev3)
== Series Details ==
Series: More DMC cleanup (rev3)
URL : https://patchwork.freedesktop.org/series/90379/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fff364de84b7 drm/i915/dmc: s/DRM_ERROR/drm_err
-:80: WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message
#80: FILE: drivers/gpu/drm/i915/display/intel_dmc.c:487:
if (!dmc->dmc_payload) {
+ drm_err(>drm, "Memory allocation failed for dmc
payload\n");
total: 0 errors, 1 warnings, 0 checks, 140 lines checked
e297b14bd44f drm/i915/dmc: Add intel_dmc_has_payload() helper
73d9b38058d5 drm/i915/dmc: Move struct intel_dmc to intel_dmc.h
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/display: Nuke has_infoframe
On Fri, 2021-05-21 at 16:27 +0100, Mun, Gwan-gyeong wrote: > On Fri, 2021-05-14 at 16:22 -0700, José Roberto de Souza wrote: > > This was only reduntant information has_hdmi_sink can do the same job. > > set_infoframes() hooks will call intel_write_infoframe() for the > > supported infoframes types and it will only be enabled if given type > > is set in crtc_state->infoframes.enable. > > > > While at it also fixing the style of dig_port->set_infoframes() calls. > > > > Cc: Ville Syrjälä > > Signed-off-by: José Roberto de Souza > > --- > > drivers/gpu/drm/i915/display/g4x_hdmi.c | 22 ++- > > drivers/gpu/drm/i915/display/intel_ddi.c | 17 +- > > drivers/gpu/drm/i915/display/intel_display.c | 6 ++--- > > .../drm/i915/display/intel_display_types.h| 3 --- > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 ++-- > > drivers/gpu/drm/i915/display/intel_hdmi.c | 13 +-- > > 6 files changed, 22 insertions(+), 43 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/display/g4x_hdmi.c > > b/drivers/gpu/drm/i915/display/g4x_hdmi.c > > index be352e9f0afc..f35db96e6239 100644 > > --- a/drivers/gpu/drm/i915/display/g4x_hdmi.c > > +++ b/drivers/gpu/drm/i915/display/g4x_hdmi.c > > @@ -105,9 +105,6 @@ static void intel_hdmi_get_config(struct > > intel_encoder *encoder, > > pipe_config->infoframes.enable |= > > intel_hdmi_infoframes_enabled(encoder, pipe_config); > > > > - if (pipe_config->infoframes.enable) > > - pipe_config->has_infoframe = true; > > - > "pipe_config->infoframes.enable" is set with information about the > infoframes currently active in the hardware through "pipe_config- > > infoframes.enable |= intel_hdmi_infoframes_enabled(encoder, > pipe_config);". > > Therefore, when calling set_infoframes() semantically, the > has_infoframe information set by "if (pipe_config->infoframes.enable) > pipe_config->has_infoframe = true;" is more clear. That don't work because the functions that will check if a infoframe is needed and set pipe_config->infoframes.enable depends on pipe_config- >has_infoframe/crtc_state->has_hdmi_sink. That is probably because DVI ports don't support infoframes but in i915 are handle very similar to HDMI. > > > if (tmp & HDMI_AUDIO_ENABLE) > > pipe_config->has_audio = true; > > > > @@ -343,9 +340,7 @@ static void intel_disable_hdmi(struct > > intel_atomic_state *state, > > intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, > > true); > > } > > > > - dig_port->set_infoframes(encoder, > > - false, > > - old_crtc_state, old_conn_state); > > + dig_port->set_infoframes(encoder, false, old_crtc_state, > > old_conn_state); > > > > intel_dp_dual_mode_set_tmds_output(intel_hdmi, false); > > } > > @@ -390,9 +385,8 @@ static void intel_hdmi_pre_enable(struct > > intel_atomic_state *state, > > > > intel_hdmi_prepare(encoder, pipe_config); > > > > - dig_port->set_infoframes(encoder, > > - pipe_config->has_infoframe, > > - pipe_config, conn_state); > > + dig_port->set_infoframes(encoder, pipe_config->has_hdmi_sink, > > +pipe_config, conn_state); > > } > > > > static void vlv_hdmi_pre_enable(struct intel_atomic_state *state, > > @@ -410,9 +404,8 @@ static void vlv_hdmi_pre_enable(struct > > intel_atomic_state *state, > > 0x2b245f5f, 0x2000, > > 0x5578b83a, 0x2b247878); > > > > - dig_port->set_infoframes(encoder, > > - pipe_config->has_infoframe, > > - pipe_config, conn_state); > > + dig_port->set_infoframes(encoder, pipe_config->has_hdmi_sink, > > +pipe_config, conn_state); > > > > g4x_enable_hdmi(state, encoder, pipe_config, conn_state); > > > > @@ -487,9 +480,8 @@ static void chv_hdmi_pre_enable(struct > > intel_atomic_state *state, > > /* Use 800mV-0dB */ > > chv_set_phy_signal_level(encoder, pipe_config, 128, 102, > > false); > > > > - dig_port->set_infoframes(encoder, > > - pipe_config->has_infoframe, > > - pipe_config, conn_state); > > + dig_port->set_infoframes(encoder, pipe_config->has_hdmi_sink, > > +pipe_config, conn_state); > > > > g4x_enable_hdmi(state, encoder, pipe_config, conn_state); > > > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c > > b/drivers/gpu/drm/i915/display/intel_ddi.c > > index b7a2fce684c9..5bc5528f3091 100644 > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c > > @@ -2722,9 +2722,8 @@ static void
[Intel-gfx] [PATCH 2/3] drm/i915/dmc: Add intel_dmc_has_payload() helper
We check for dmc_payload being there at various points in the driver.
Replace it with the helper.
v2: rebased.
v3: Move intel_dmc to intel_dmc.h in another patch (Lucas)
v4: Remove headers not needed from intel_dmc.h
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
Reviewed-by: Lucas De Marchi
---
.../gpu/drm/i915/display/intel_display_debugfs.c | 4 ++--
.../gpu/drm/i915/display/intel_display_power.c | 16
drivers/gpu/drm/i915/display/intel_dmc.c | 13 +
drivers/gpu/drm/i915/display/intel_dmc.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c| 2 +-
5 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 94e5cbd86e77..88bb05d5c483 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -542,10 +542,10 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
wakeref = intel_runtime_pm_get(_priv->runtime_pm);
- seq_printf(m, "fw loaded: %s\n", yesno(dmc->dmc_payload));
+ seq_printf(m, "fw loaded: %s\n",
yesno(intel_dmc_has_payload(dev_priv)));
seq_printf(m, "path: %s\n", dmc->fw_path);
- if (!dmc->dmc_payload)
+ if (!intel_dmc_has_payload(dev_priv))
goto out;
seq_printf(m, "version: %d.%d\n", DMC_VERSION_MAJOR(dmc->version),
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 991ceea06a07..b546672c9b00 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -1220,7 +1220,7 @@ static void gen9_dc_off_power_well_enable(struct
drm_i915_private *dev_priv,
static void gen9_dc_off_power_well_disable(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
{
- if (!dev_priv->dmc.dmc_payload)
+ if (!intel_dmc_has_payload(dev_priv))
return;
switch (dev_priv->dmc.target_dc_state) {
@@ -5579,7 +5579,7 @@ static void skl_display_core_init(struct drm_i915_private
*dev_priv,
gen9_dbuf_enable(dev_priv);
- if (resume && dev_priv->dmc.dmc_payload)
+ if (resume && intel_dmc_has_payload(dev_priv))
intel_dmc_load_program(dev_priv);
}
@@ -5646,7 +5646,7 @@ static void bxt_display_core_init(struct drm_i915_private
*dev_priv, bool resume
gen9_dbuf_enable(dev_priv);
- if (resume && dev_priv->dmc.dmc_payload)
+ if (resume && intel_dmc_has_payload(dev_priv))
intel_dmc_load_program(dev_priv);
}
@@ -5712,7 +5712,7 @@ static void cnl_display_core_init(struct drm_i915_private
*dev_priv, bool resume
/* 6. Enable DBUF */
gen9_dbuf_enable(dev_priv);
- if (resume && dev_priv->dmc.dmc_payload)
+ if (resume && intel_dmc_has_payload(dev_priv))
intel_dmc_load_program(dev_priv);
}
@@ -5869,7 +5869,7 @@ static void icl_display_core_init(struct drm_i915_private
*dev_priv,
if (DISPLAY_VER(dev_priv) >= 12)
tgl_bw_buddy_init(dev_priv);
- if (resume && dev_priv->dmc.dmc_payload)
+ if (resume && intel_dmc_has_payload(dev_priv))
intel_dmc_load_program(dev_priv);
/* Wa_14011508470 */
@@ -6230,7 +6230,7 @@ void intel_power_domains_suspend(struct drm_i915_private
*i915,
*/
if (!(i915->dmc.allowed_dc_mask & DC_STATE_EN_DC9) &&
suspend_mode == I915_DRM_SUSPEND_IDLE &&
- i915->dmc.dmc_payload) {
+ intel_dmc_has_payload(i915)) {
intel_display_power_flush_work(i915);
intel_power_domains_verify_state(i915);
return;
@@ -6420,7 +6420,7 @@ void intel_display_power_resume(struct drm_i915_private
*i915)
if (DISPLAY_VER(i915) >= 11) {
bxt_disable_dc9(i915);
icl_display_core_init(i915, true);
- if (i915->dmc.dmc_payload) {
+ if (intel_dmc_has_payload(i915)) {
if (i915->dmc.allowed_dc_mask &
DC_STATE_EN_UPTO_DC6)
skl_enable_dc6(i915);
@@ -6431,7 +6431,7 @@ void intel_display_power_resume(struct drm_i915_private
*i915)
} else if (IS_GEMINILAKE(i915) || IS_BROXTON(i915)) {
bxt_disable_dc9(i915);
bxt_display_core_init(i915, true);
- if (i915->dmc.dmc_payload &&
+ if (intel_dmc_has_payload(i915) &&
(i915->dmc.allowed_dc_mask & DC_STATE_EN_UPTO_DC5))
gen9_enable_dc5(i915);
} else if (IS_HASWELL(i915) || IS_BROADWELL(i915)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index
[Intel-gfx] [PATCH 3/3] drm/i915/dmc: Move struct intel_dmc to intel_dmc.h
Move struct intel_dmc from i915_drv.h to intel_dmc.h.
v2: Add includes along with moving the struct.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_dmc.h | 21 +
drivers/gpu/drm/i915/i915_drv.h | 18 +-
2 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.h
b/drivers/gpu/drm/i915/display/intel_dmc.h
index 64816f4a71b6..8baeb85cf8db 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.h
+++ b/drivers/gpu/drm/i915/display/intel_dmc.h
@@ -6,12 +6,33 @@
#ifndef __INTEL_DMC_H__
#define __INTEL_DMC_H__
+#include
+#include "intel_wakeref.h"
+#include "i915_reg.h"
+
struct drm_i915_private;
#define DMC_VERSION(major, minor) ((major) << 16 | (minor))
#define DMC_VERSION_MAJOR(version) ((version) >> 16)
#define DMC_VERSION_MINOR(version) ((version) & 0x)
+struct intel_dmc {
+ struct work_struct work;
+ const char *fw_path;
+ u32 required_version;
+ u32 max_fw_size; /* bytes */
+ u32 *dmc_payload;
+ u32 dmc_fw_size; /* dwords */
+ u32 version;
+ u32 mmio_count;
+ i915_reg_t mmioaddr[20];
+ u32 mmiodata[20];
+ u32 dc_state;
+ u32 target_dc_state;
+ u32 allowed_dc_mask;
+ intel_wakeref_t wakeref;
+};
+
void intel_dmc_ucode_init(struct drm_i915_private *i915);
void intel_dmc_load_program(struct drm_i915_private *i915);
void intel_dmc_ucode_fini(struct drm_i915_private *i915);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9cb02618ba15..b5962768a1f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -67,6 +67,7 @@
#include "display/intel_bios.h"
#include "display/intel_display.h"
#include "display/intel_display_power.h"
+#include "display/intel_dmc.h"
#include "display/intel_dpll_mgr.h"
#include "display/intel_dsb.h"
#include "display/intel_frontbuffer.h"
@@ -328,23 +329,6 @@ struct drm_i915_display_funcs {
void (*read_luts)(struct intel_crtc_state *crtc_state);
};
-struct intel_dmc {
- struct work_struct work;
- const char *fw_path;
- u32 required_version;
- u32 max_fw_size; /* bytes */
- u32 *dmc_payload;
- u32 dmc_fw_size; /* dwords */
- u32 version;
- u32 mmio_count;
- i915_reg_t mmioaddr[20];
- u32 mmiodata[20];
- u32 dc_state;
- u32 target_dc_state;
- u32 allowed_dc_mask;
- intel_wakeref_t wakeref;
-};
-
enum i915_cache_level {
I915_CACHE_NONE = 0,
I915_CACHE_LLC, /* also used for snoopable memory on non-LLC */
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/dmc: s/DRM_ERROR/drm_err
Use new format of debug messages across intel_csr.
While at it, change some function definitions which now
need dev_priv for drm_err and drm_info etc.
v2: use container_of() (Jani)
v3: Indentation fixes. (Jani)
Cc: Jani Nikula
Suggested-by: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_dmc.c | 48 +---
1 file changed, 26 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 560574dd929a..5887453ff302 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -395,6 +395,7 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
const struct intel_dmc_header_base *dmc_header,
size_t rem_size)
{
+ struct drm_i915_private *i915 = container_of(dmc, typeof(*i915), dmc);
unsigned int header_len_bytes, dmc_header_size, payload_size, i;
const u32 *mmioaddr, *mmiodata;
u32 mmio_count, mmio_count_max;
@@ -439,28 +440,28 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
header_len_bytes = dmc_header->header_len;
dmc_header_size = sizeof(*v1);
} else {
- DRM_ERROR("Unknown DMC fw header version: %u\n",
- dmc_header->header_ver);
+ drm_err(>drm, "Unknown DMC fw header version: %u\n",
+ dmc_header->header_ver);
return 0;
}
if (header_len_bytes != dmc_header_size) {
- DRM_ERROR("DMC firmware has wrong dmc header length "
- "(%u bytes)\n", header_len_bytes);
+ drm_err(>drm, "DMC firmware has wrong dmc header length "
+ "(%u bytes)\n", header_len_bytes);
return 0;
}
/* Cache the dmc header info. */
if (mmio_count > mmio_count_max) {
- DRM_ERROR("DMC firmware has wrong mmio count %u\n", mmio_count);
+ drm_err(>drm, "DMC firmware has wrong mmio count %u\n",
mmio_count);
return 0;
}
for (i = 0; i < mmio_count; i++) {
if (mmioaddr[i] < DMC_MMIO_START_RANGE ||
mmioaddr[i] > DMC_MMIO_END_RANGE) {
- DRM_ERROR("DMC firmware has wrong mmio address 0x%x\n",
- mmioaddr[i]);
+ drm_err(>drm, "DMC firmware has wrong mmio
address 0x%x\n",
+ mmioaddr[i]);
return 0;
}
dmc->mmioaddr[i] = _MMIO(mmioaddr[i]);
@@ -476,14 +477,14 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
goto error_truncated;
if (payload_size > dmc->max_fw_size) {
- DRM_ERROR("DMC FW too big (%u bytes)\n", payload_size);
+ drm_err(>drm, "DMC FW too big (%u bytes)\n",
payload_size);
return 0;
}
dmc->dmc_fw_size = dmc_header->fw_size;
dmc->dmc_payload = kmalloc(payload_size, GFP_KERNEL);
if (!dmc->dmc_payload) {
- DRM_ERROR("Memory allocation failed for dmc payload\n");
+ drm_err(>drm, "Memory allocation failed for dmc
payload\n");
return 0;
}
@@ -493,7 +494,7 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
return header_len_bytes + payload_size;
error_truncated:
- DRM_ERROR("Truncated DMC firmware, refusing.\n");
+ drm_err(>drm, "Truncated DMC firmware, refusing.\n");
return 0;
}
@@ -503,6 +504,7 @@ parse_dmc_fw_package(struct intel_dmc *dmc,
const struct stepping_info *si,
size_t rem_size)
{
+ struct drm_i915_private *i915 = container_of(dmc, typeof(*i915), dmc);
u32 package_size = sizeof(struct intel_package_header);
u32 num_entries, max_entries, dmc_offset;
const struct intel_fw_info *fw_info;
@@ -515,8 +517,8 @@ parse_dmc_fw_package(struct intel_dmc *dmc,
} else if (package_header->header_ver == 2) {
max_entries = PACKAGE_V2_MAX_FW_INFO_ENTRIES;
} else {
- DRM_ERROR("DMC firmware has unknown header version %u\n",
- package_header->header_ver);
+ drm_err(>drm, "DMC firmware has unknown header version
%u\n",
+ package_header->header_ver);
return 0;
}
@@ -529,8 +531,8 @@ parse_dmc_fw_package(struct intel_dmc *dmc,
goto error_truncated;
if (package_header->header_len * 4 != package_size) {
- DRM_ERROR("DMC firmware has wrong package header length "
- "(%u bytes)\n", package_size);
+ drm_err(>drm, "DMC firmware has wrong package header
length "
+
[Intel-gfx] [PATCH 0/3] More DMC cleanup
Last of prep patches before Pipe DMC patches can land. v2: Add struct intel_dmc to intel_dmc.h in a separate patch v3: Minor code shuffling and indentation fixes. Anusha Srivatsa (3): drm/i915/dmc: s/DRM_ERROR/drm_err drm/i915/dmc: Add intel_dmc_has_payload() helper drm/i915/dmc: Move struct intel_dmc to intel_dmc.h .../drm/i915/display/intel_display_debugfs.c | 4 +- .../drm/i915/display/intel_display_power.c| 16 ++--- drivers/gpu/drm/i915/display/intel_dmc.c | 61 +++ drivers/gpu/drm/i915/display/intel_dmc.h | 22 +++ drivers/gpu/drm/i915/i915_drv.h | 18 +- drivers/gpu/drm/i915/i915_gpu_error.c | 2 +- 6 files changed, 69 insertions(+), 54 deletions(-) -- 2.25.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: fix typo issue
== Series Details == Series: drm/i915/gt: fix typo issue URL : https://patchwork.freedesktop.org/series/90364/ State : success == Summary == CI Bug Log - changes from CI_DRM_10112_full -> Patchwork_20160_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20160_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-skl: NOTRUN -> [DMESG-WARN][1] ([i915#3002]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/shard-skl6/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +5 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_ctx_persistence@smoketest: - shard-tglb: [PASS][3] -> [FAIL][4] ([i915#2896]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10112/shard-tglb5/igt@gem_ctx_persiste...@smoketest.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/shard-tglb6/igt@gem_ctx_persiste...@smoketest.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][5] ([i915#3354]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/shard-snb7/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10112/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-iclb: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10112/shard-iclb8/igt@gem_exec_fair@basic-p...@bcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/shard-iclb5/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_exec_params@rsvd2-dirt: - shard-tglb: NOTRUN -> [SKIP][10] ([fdo#109283]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/shard-tglb6/igt@gem_exec_par...@rsvd2-dirt.html * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-apl: NOTRUN -> [FAIL][11] ([i915#2389]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/shard-apl7/igt@gem_exec_reloc@basic-wide-act...@bcs0.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-snb: NOTRUN -> [FAIL][12] ([i915#2389]) +2 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/shard-snb2/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-iclb: NOTRUN -> [SKIP][13] ([i915#2190]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/shard-iclb5/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy: - shard-skl: [PASS][14] -> [INCOMPLETE][15] ([i915#198] / [i915#3468]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10112/shard-skl4/igt@gem_mmap_...@cpuset-basic-small-copy.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/shard-skl7/igt@gem_mmap_...@cpuset-basic-small-copy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd: - shard-snb: NOTRUN -> [INCOMPLETE][16] ([i915#2055]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/shard-snb7/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-xy: - shard-skl: NOTRUN -> [INCOMPLETE][17] ([i915#198] / [i915#3468]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/shard-skl2/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html * igt@gem_mmap_offset@clear: - shard-glk: [PASS][18] -> [FAIL][19] ([i915#3160]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10112/shard-glk2/igt@gem_mmap_off...@clear.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/shard-glk3/igt@gem_mmap_off...@clear.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-glk: [PASS][20] -> [FAIL][21] ([i915#644]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10112/shard-glk4/igt@gem_pp...@flink-and-close-vma-leak.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/shard-glk7/igt@gem_pp...@flink-and-close-vma-leak.html * igt@gem_pread@exhaustion: - shard-apl: NOTRUN -> [WARN][22] ([i915#2658]) +1 similar issue [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/shard-apl7/igt@gem_pr...@exhaustion.html * igt@gem_pwrite@basic-exhaustion: - shard-snb: NOTRUN -> [WARN][23] ([i915#2658]) +1 similar
Re: [Intel-gfx] [PATCH 2/3] drm/i915/dmc: Add intel_dmc_has_payload() helper
> -Original Message-
> From: Srivatsa, Anusha
> Sent: Friday, May 21, 2021 12:28 PM
> To: 'Jani Nikula' ; intel-
> g...@lists.freedesktop.org
> Cc: De Marchi, Lucas
> Subject: RE: [Intel-gfx] [PATCH 2/3] drm/i915/dmc: Add
> intel_dmc_has_payload() helper
>
>
>
> > -Original Message-
> > From: Jani Nikula
> > Sent: Friday, May 21, 2021 3:04 AM
> > To: Srivatsa, Anusha ; intel-
> > g...@lists.freedesktop.org
> > Cc: De Marchi, Lucas
> > Subject: Re: [Intel-gfx] [PATCH 2/3] drm/i915/dmc: Add
> > intel_dmc_has_payload() helper
> >
> > On Thu, 20 May 2021, Anusha Srivatsa
> wrote:
> > > We check for dmc_payload being there at various points in the driver.
> > > Replace it with the helper.
> >
> > Seems like a good idea. Some comments inline.
> >
> > BR,
> > Jani.
> >
> > >
> > > v2: rebased.
> > > v3: Move intel_dmc to intel_dmc.h in another patch (Lucas)
> > >
> > > Cc: Lucas De Marchi
> > > Signed-off-by: Anusha Srivatsa
> > > Reviewed-by: Lucas De Marchi
> > > ---
> > > .../gpu/drm/i915/display/intel_display_debugfs.c | 4 ++--
> > > .../gpu/drm/i915/display/intel_display_power.c | 16
> > > drivers/gpu/drm/i915/display/intel_dmc.c | 13 +
> > > drivers/gpu/drm/i915/display/intel_dmc.h | 5 +
> > > drivers/gpu/drm/i915/i915_gpu_error.c| 2 +-
> > > 5 files changed, 25 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > index 94e5cbd86e77..88bb05d5c483 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > @@ -542,10 +542,10 @@ static int i915_dmc_info(struct seq_file *m,
> > > void *unused)
> > >
> > > wakeref = intel_runtime_pm_get(_priv->runtime_pm);
> > >
> > > - seq_printf(m, "fw loaded: %s\n", yesno(dmc->dmc_payload));
> > > + seq_printf(m, "fw loaded: %s\n",
> > > +yesno(intel_dmc_has_payload(dev_priv)));
> > > seq_printf(m, "path: %s\n", dmc->fw_path);
> > >
> > > - if (!dmc->dmc_payload)
> > > + if (!intel_dmc_has_payload(dev_priv))
> > > goto out;
> > >
> > > seq_printf(m, "version: %d.%d\n", DMC_VERSION_MAJOR(dmc-
> version),
> > >diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > index 991ceea06a07..b546672c9b00 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > @@ -1220,7 +1220,7 @@ static void
> > gen9_dc_off_power_well_enable(struct
> > > drm_i915_private *dev_priv, static void
> > gen9_dc_off_power_well_disable(struct drm_i915_private *dev_priv,
> > > struct i915_power_well
> > *power_well) {
> > > - if (!dev_priv->dmc.dmc_payload)
> > > + if (!intel_dmc_has_payload(dev_priv))
> > > return;
> > >
> > > switch (dev_priv->dmc.target_dc_state) { @@ -5579,7 +5579,7 @@
> > > static void skl_display_core_init(struct drm_i915_private *dev_priv,
> > >
> > > gen9_dbuf_enable(dev_priv);
> > >
> > > - if (resume && dev_priv->dmc.dmc_payload)
> > > + if (resume && intel_dmc_has_payload(dev_priv))
> > > intel_dmc_load_program(dev_priv); }
> > >
> > > @@ -5646,7 +5646,7 @@ static void bxt_display_core_init(struct
> > > drm_i915_private *dev_priv, bool resume
> > >
> > > gen9_dbuf_enable(dev_priv);
> > >
> > > - if (resume && dev_priv->dmc.dmc_payload)
> > > + if (resume && intel_dmc_has_payload(dev_priv))
> > > intel_dmc_load_program(dev_priv); }
> > >
> > > @@ -5712,7 +5712,7 @@ static void cnl_display_core_init(struct
> > drm_i915_private *dev_priv, bool resume
> > > /* 6. Enable DBUF */
> > > gen9_dbuf_enable(dev_priv);
> > >
> > > - if (resume && dev_priv->dmc.dmc_payload)
> > > + if (resume && intel_dmc_has_payload(dev_priv))
> > > intel_dmc_load_program(dev_priv); }
> > >
> > > @@ -5869,7 +5869,7 @@ static void icl_display_core_init(struct
> > drm_i915_private *dev_priv,
> > > if (DISPLAY_VER(dev_priv) >= 12)
> > > tgl_bw_buddy_init(dev_priv);
> > >
> > > - if (resume && dev_priv->dmc.dmc_payload)
> > > + if (resume && intel_dmc_has_payload(dev_priv))
> > > intel_dmc_load_program(dev_priv);
> > >
> > > /* Wa_14011508470 */
> > > @@ -6230,7 +6230,7 @@ void intel_power_domains_suspend(struct
> > drm_i915_private *i915,
> > >*/
> > > if (!(i915->dmc.allowed_dc_mask & DC_STATE_EN_DC9) &&
> > > suspend_mode == I915_DRM_SUSPEND_IDLE &&
> > > - i915->dmc.dmc_payload) {
> > > + intel_dmc_has_payload(i915)) {
> > > intel_display_power_flush_work(i915);
> > > intel_power_domains_verify_state(i915);
> > > return;
> > > @@ -6420,7 +6420,7 @@ void intel_display_power_resume(struct
> > drm_i915_private *i915)
> > > if (DISPLAY_VER(i915) >= 11) {
> > >
Re: [Intel-gfx] [PATCH 2/3] drm/i915/dmc: Add intel_dmc_has_payload() helper
> -Original Message-
> From: Jani Nikula
> Sent: Friday, May 21, 2021 3:04 AM
> To: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org
> Cc: De Marchi, Lucas
> Subject: Re: [Intel-gfx] [PATCH 2/3] drm/i915/dmc: Add
> intel_dmc_has_payload() helper
>
> On Thu, 20 May 2021, Anusha Srivatsa wrote:
> > We check for dmc_payload being there at various points in the driver.
> > Replace it with the helper.
>
> Seems like a good idea. Some comments inline.
>
> BR,
> Jani.
>
> >
> > v2: rebased.
> > v3: Move intel_dmc to intel_dmc.h in another patch (Lucas)
> >
> > Cc: Lucas De Marchi
> > Signed-off-by: Anusha Srivatsa
> > Reviewed-by: Lucas De Marchi
> > ---
> > .../gpu/drm/i915/display/intel_display_debugfs.c | 4 ++--
> > .../gpu/drm/i915/display/intel_display_power.c | 16
> > drivers/gpu/drm/i915/display/intel_dmc.c | 13 +
> > drivers/gpu/drm/i915/display/intel_dmc.h | 5 +
> > drivers/gpu/drm/i915/i915_gpu_error.c| 2 +-
> > 5 files changed, 25 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > index 94e5cbd86e77..88bb05d5c483 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > @@ -542,10 +542,10 @@ static int i915_dmc_info(struct seq_file *m,
> > void *unused)
> >
> > wakeref = intel_runtime_pm_get(_priv->runtime_pm);
> >
> > - seq_printf(m, "fw loaded: %s\n", yesno(dmc->dmc_payload));
> > + seq_printf(m, "fw loaded: %s\n",
> > +yesno(intel_dmc_has_payload(dev_priv)));
> > seq_printf(m, "path: %s\n", dmc->fw_path);
> >
> > - if (!dmc->dmc_payload)
> > + if (!intel_dmc_has_payload(dev_priv))
> > goto out;
> >
> > seq_printf(m, "version: %d.%d\n", DMC_VERSION_MAJOR(dmc-
> >version),
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > index 991ceea06a07..b546672c9b00 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > @@ -1220,7 +1220,7 @@ static void
> gen9_dc_off_power_well_enable(struct
> > drm_i915_private *dev_priv, static void
> gen9_dc_off_power_well_disable(struct drm_i915_private *dev_priv,
> >struct i915_power_well
> *power_well) {
> > - if (!dev_priv->dmc.dmc_payload)
> > + if (!intel_dmc_has_payload(dev_priv))
> > return;
> >
> > switch (dev_priv->dmc.target_dc_state) { @@ -5579,7 +5579,7 @@
> > static void skl_display_core_init(struct drm_i915_private *dev_priv,
> >
> > gen9_dbuf_enable(dev_priv);
> >
> > - if (resume && dev_priv->dmc.dmc_payload)
> > + if (resume && intel_dmc_has_payload(dev_priv))
> > intel_dmc_load_program(dev_priv);
> > }
> >
> > @@ -5646,7 +5646,7 @@ static void bxt_display_core_init(struct
> > drm_i915_private *dev_priv, bool resume
> >
> > gen9_dbuf_enable(dev_priv);
> >
> > - if (resume && dev_priv->dmc.dmc_payload)
> > + if (resume && intel_dmc_has_payload(dev_priv))
> > intel_dmc_load_program(dev_priv);
> > }
> >
> > @@ -5712,7 +5712,7 @@ static void cnl_display_core_init(struct
> drm_i915_private *dev_priv, bool resume
> > /* 6. Enable DBUF */
> > gen9_dbuf_enable(dev_priv);
> >
> > - if (resume && dev_priv->dmc.dmc_payload)
> > + if (resume && intel_dmc_has_payload(dev_priv))
> > intel_dmc_load_program(dev_priv);
> > }
> >
> > @@ -5869,7 +5869,7 @@ static void icl_display_core_init(struct
> drm_i915_private *dev_priv,
> > if (DISPLAY_VER(dev_priv) >= 12)
> > tgl_bw_buddy_init(dev_priv);
> >
> > - if (resume && dev_priv->dmc.dmc_payload)
> > + if (resume && intel_dmc_has_payload(dev_priv))
> > intel_dmc_load_program(dev_priv);
> >
> > /* Wa_14011508470 */
> > @@ -6230,7 +6230,7 @@ void intel_power_domains_suspend(struct
> drm_i915_private *i915,
> > */
> > if (!(i915->dmc.allowed_dc_mask & DC_STATE_EN_DC9) &&
> > suspend_mode == I915_DRM_SUSPEND_IDLE &&
> > - i915->dmc.dmc_payload) {
> > + intel_dmc_has_payload(i915)) {
> > intel_display_power_flush_work(i915);
> > intel_power_domains_verify_state(i915);
> > return;
> > @@ -6420,7 +6420,7 @@ void intel_display_power_resume(struct
> drm_i915_private *i915)
> > if (DISPLAY_VER(i915) >= 11) {
> > bxt_disable_dc9(i915);
> > icl_display_core_init(i915, true);
> > - if (i915->dmc.dmc_payload) {
> > + if (intel_dmc_has_payload(i915)) {
> > if (i915->dmc.allowed_dc_mask &
> > DC_STATE_EN_UPTO_DC6)
> > skl_enable_dc6(i915);
> > @@ -6431,7 +6431,7 @@ void intel_display_power_resume(struct
> drm_i915_private
[Intel-gfx] ✓ Fi.CI.BAT: success for Clean a few backend interfaces in the i915
== Series Details ==
Series: Clean a few backend interfaces in the i915
URL : https://patchwork.freedesktop.org/series/90432/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10120 -> Patchwork_20173
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20173/index.html
Known issues
Here are the changes found in Patchwork_20173 that come from known issues:
### IGT changes ###
Possible fixes
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [FAIL][1] ([i915#1372]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20173/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2: [FAIL][3] ([i915#49]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20173/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
Warnings
* igt@i915_selftest@live@execlists:
- fi-icl-u2: [INCOMPLETE][5] ([i915#2782] / [i915#3462]) ->
[DMESG-FAIL][6] ([i915#3462])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-icl-u2/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20173/fi-icl-u2/igt@i915_selftest@l...@execlists.html
* igt@runner@aborted:
- fi-icl-u2: [FAIL][7] ([i915#2782] / [i915#3363]) -> [FAIL][8]
([i915#2426] / [i915#2782] / [i915#3363])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-icl-u2/igt@run...@aborted.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20173/fi-icl-u2/igt@run...@aborted.html
- fi-kbl-soraka: [FAIL][9] ([i915#1436] / [i915#2426] / [i915#3363])
-> [FAIL][10] ([i915#1436] / [i915#3363])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-kbl-soraka/igt@run...@aborted.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20173/fi-kbl-soraka/igt@run...@aborted.html
- fi-kbl-7500u: [FAIL][11] ([i915#1436] / [i915#3363]) -> [FAIL][12]
([i915#1436] / [i915#2426] / [i915#3363])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-kbl-7500u/igt@run...@aborted.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20173/fi-kbl-7500u/igt@run...@aborted.html
- fi-cml-u2: [FAIL][13] ([i915#2082] / [i915#2426] / [i915#3363] /
[i915#3462]) -> [FAIL][14] ([i915#3363] / [i915#3462])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-cml-u2/igt@run...@aborted.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20173/fi-cml-u2/igt@run...@aborted.html
- fi-skl-6700k2: [FAIL][15] ([i915#1436] / [i915#2426] / [i915#3363])
-> [FAIL][16] ([i915#1436] / [i915#3363])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-skl-6700k2/igt@run...@aborted.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20173/fi-skl-6700k2/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#2082]: https://gitlab.freedesktop.org/drm/intel/issues/2082
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
[i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
[i915#2932]: https://gitlab.freedesktop.org/drm/intel/issues/2932
[i915#2966]: https://gitlab.freedesktop.org/drm/intel/issues/2966
[i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
[i915#3276]: https://gitlab.freedesktop.org/drm/intel/issues/3276
[i915#3277]: https://gitlab.freedesktop.org/drm/intel/issues/3277
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3283]: https://gitlab.freedesktop.org/drm/intel/issues/3283
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
[i915#3462]: https://gitlab.freedesktop.org/drm/intel/issues/3462
[i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: Add missing macro name changes (rev2)
== Series Details ==
Series: drm/i915/gvt: Add missing macro name changes (rev2)
URL : https://patchwork.freedesktop.org/series/90427/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10120 -> Patchwork_20172
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20172/index.html
Known issues
Here are the changes found in Patchwork_20172 that come from known issues:
### IGT changes ###
Possible fixes
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [FAIL][1] ([i915#1372]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20172/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2: [FAIL][3] ([i915#49]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20172/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
Warnings
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][5] ([i915#2782] / [i915#2940] /
[i915#3462]) -> [DMESG-FAIL][6] ([i915#3462])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20172/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@runner@aborted:
- fi-cfl-8700k: [FAIL][7] ([i915#3363]) -> [FAIL][8] ([i915#2426] /
[i915#3363])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-cfl-8700k/igt@run...@aborted.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20172/fi-cfl-8700k/igt@run...@aborted.html
- fi-kbl-7500u: [FAIL][9] ([i915#1436] / [i915#3363]) -> [FAIL][10]
([i915#1436] / [i915#2426] / [i915#3363])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-kbl-7500u/igt@run...@aborted.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20172/fi-kbl-7500u/igt@run...@aborted.html
- fi-cml-u2: [FAIL][11] ([i915#2082] / [i915#2426] / [i915#3363] /
[i915#3462]) -> [FAIL][12] ([i915#3363] / [i915#3462])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-cml-u2/igt@run...@aborted.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20172/fi-cml-u2/igt@run...@aborted.html
- fi-kbl-7567u: [FAIL][13] ([i915#1436] / [i915#3363]) -> [FAIL][14]
([i915#1436] / [i915#2426] / [i915#3363])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-kbl-7567u/igt@run...@aborted.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20172/fi-kbl-7567u/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#2082]: https://gitlab.freedesktop.org/drm/intel/issues/2082
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
[i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
[i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
[i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
[i915#3276]: https://gitlab.freedesktop.org/drm/intel/issues/3276
[i915#3277]: https://gitlab.freedesktop.org/drm/intel/issues/3277
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3283]: https://gitlab.freedesktop.org/drm/intel/issues/3283
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
[i915#3462]: https://gitlab.freedesktop.org/drm/intel/issues/3462
[i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
Participating hosts (41 -> 38)
--
Additional (1): fi-rkl-11500t
Missing(4): fi-kbl-soraka fi-bsw-cyan fi-bdw-samus fi-hsw-4200u
Build changes
-
* Linux: CI_DRM_10120 -> Patchwork_20172
CI-20190529: 20190529
CI_DRM_10120: 9221d50d353487d2e10226318d89027037255621 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6091: a7016bde81f6e6ee9f2ded3c091c56766a6adc46 @
Re: [Intel-gfx] [PATCH] drm/i915/gvt: remove local storage of debugfs file
On Wed, May 19, 2021 at 04:21:23PM +0800, Zhenyu Wang wrote: > On 2021.05.19 10:31:18 +0200, Greg Kroah-Hartman wrote: > > On Wed, May 19, 2021 at 04:03:13PM +0800, Zhenyu Wang wrote: > > > On 2021.05.18 18:28:53 +0200, Greg Kroah-Hartman wrote: > > > > On Tue, May 18, 2021 at 06:17:05PM +0200, Greg Kroah-Hartman wrote: > > > > > There is no need to keep the dentry around for the debugfs kvmgt cache > > > > > file, as we can just look it up when we want to remove it later on. > > > > > Simplify the structure by removing the dentry and relying on debugfs > > > > > to find the dentry to remove when we want to. > > > > > > > > > > By doing this change, we remove the last in-kernel user that was > > > > > storing > > > > > the result of debugfs_create_long(), so that api can be cleaned up. > > > > > > > > > > Cc: Zhenyu Wang > > > > > Cc: Zhi Wang > > > > > Cc: Jani Nikula > > > > > Cc: Joonas Lahtinen > > > > > Cc: Rodrigo Vivi > > > > > Cc: David Airlie > > > > > Cc: Daniel Vetter > > > > > Cc: intel-gvt-...@lists.freedesktop.org > > > > > Cc: intel-gfx@lists.freedesktop.org > > > > > Cc: dri-de...@lists.freedesktop.org > > > > > Signed-off-by: Greg Kroah-Hartman > > > > > --- > > > > > drivers/gpu/drm/i915/gvt/kvmgt.c | 11 +-- > > > > > 1 file changed, 5 insertions(+), 6 deletions(-) > > > > > > > > Note, I can take this through my debugfs tree if wanted, that way I can > > > > clean up the debugfs_create_long() api at the same time. Otherwise it's > > > > fine, I can wait until next -rc1 for that to happen. > > > > > > > > > > It's fine with me to go through debugfs tree. Just double check that > > > recent > > > kvmgt change would not cause conflict with this as well. > > > > How can I check that? I'll be glad to take this through my tree, we can > > handle the merge issues later for 5.14-rc1 :) > > > > Current kvmgt change in merge queue is just > https://patchwork.freedesktop.org/patch/433536/?series=89995=2 > It applies fine with debugfs change. Thanks, I'll go take this through my tree now. greg k-h ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules
On Fri, May 21, 2021 at 8:08 PM Christian König
wrote:
>
> Am 21.05.21 um 17:16 schrieb Daniel Vetter:
> > On Fri, May 21, 2021 at 05:00:46PM +0200, Bas Nieuwenhuizen wrote:
> >> On Fri, May 21, 2021 at 4:37 PM Daniel Vetter wrote:
> >>> On Fri, May 21, 2021 at 11:46:23AM +0200, Bas Nieuwenhuizen wrote:
> On Fri, May 21, 2021 at 11:10 AM Daniel Vetter
> wrote:
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > index 88a24a0b5691..cc8426e1e8a8 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > @@ -617,8 +617,8 @@ static int amdgpu_cs_parser_bos(struct
> > amdgpu_cs_parser *p,
> > amdgpu_bo_list_for_each_entry(e, p->bo_list) {
> > struct amdgpu_bo *bo = ttm_to_amdgpu_bo(e->tv.bo);
> >
> > - /* Make sure we use the exclusive slot for shared BOs */
> > - if (bo->prime_shared_count)
> > + /* Make sure we use the exclusive slot for all
> > potentially shared BOs */
> > + if (!(bo->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID))
> > e->tv.num_shared = 0;
> I think it also makes sense to skip this with
> AMDGPU_GEM_CREATE_EXPLICIT_SYNC? It can be shared but I don't think
> anyone expects implicit sync to happen with those.
> >>> Ah yes, I missed this entirely. So the "no implicit flag" is already
> >>> there, and the _only_ thing that's missing really is a way to fish out the
> >>> implicit fences, and set them.
> >>>
> >>> https://lore.kernel.org/dri-devel/20210520190007.534046-1-ja...@jlekstrand.net/
> >>>
> >>> So I think all that's really needed in radv is not setting
> >>> RADEON_FLAG_IMPLICIT_SYNC for winsys buffers when Jason's dma-buf ioctl
> >>> are present (means you need to do some import/export and keep the fd
> >>> around for winsys buffers, but shouldn't be too bad), and then control the
> >>> implicit fences entirely explicitly like vk expects.
> >> That is the part I'm less sure about. This is a BO wide flag so we are
> >> also disabling implicit sync in the compositor. If the compositor does
> >> only do read stuff that is ok, as the inserted exclusive fence will
> >> work for that. But as I learned recently the app provided buffer may
> >> end up being written to by the X server which open a whole can of
> >> potential problems if implicit sync gets disabled between Xserver
> >> operations on the app provided buffer. Hence setting that on the WSI
> >> buffer is a whole new can of potential problems and hence I've said a
> >> submission based flag would be preferred.
> >>
> >> I can certainly try it out though.
> > Hm yeah that's the wrong flag. We need a flag on the drm_file which the
> > explicit userspace sets. And which is valid only for itself.
> >
> > There's a nice flags field when creating a ctx, but it's not validated and
> > there's already a comment that we have to filter out garbage priority, so
> > that's not use. I'll whip up something entirely untested just as a draft.
>
> We could provide an IOCTL for the BO to change the flag.
That's not the semantics we need.
> But could we first figure out the semantics we want to use here?
>
> Cause I'm pretty sure we don't actually need those changes at all and as
> said before I'm certainly NAKing things which break existing use cases.
Please read how other drivers do this and at least _try_ to understand
it. I'm really loosing my patience here with you NAKing patches you're
not even understanding (or did you actually read and fully understand
the entire story I typed up here, and your NAK is on the entire
thing?). There's not much useful conversation to be had with that
approach. And with drivers I mean kernel + userspace here.
That's the other frustration part: You're trying to fix this purely in
the kernel. This is exactly one of these issues why we require open
source userspace, so that we can fix the issues correctly across the
entire stack. And meanwhile you're steadfastily refusing to even look
at that the userspace side of the picture.
Also I thought through your tlb issue, why are you even putting these
tlb flush fences into the shard dma_resv slots? If you store them
somewhere else in the amdgpu private part, the oversync issues goes
away
- in your ttm bo move callback, you can just make your bo copy job
depend on them too (you have to anyway)
- even for p2p there's not an issue here, because you have the
->move_notify callback, and can then lift the tlb flush fences from
your private place to the shared slots so the exporter can see them.
The kernel move fences otoh are a bit more nasty to wring through the
p2p dma-buf interface. That one probably needs something new.
-Daniel
>
>
Re: [Intel-gfx] [PATCH 11/11] drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default
Den 21.05.2021 11.09, skrev Daniel Vetter: > Goes through all the drivers and deletes the default hook since it's > the default now. > > Signed-off-by: Daniel Vetter Acked-by: Noralf Trønnes ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/11] drm/: drm_gem_plane_helper_prepare_fb is now the default
Dne petek, 21. maj 2021 ob 11:09:54 CEST je Daniel Vetter napisal(a): > No need to set it explicitly. > > Signed-off-by: Daniel Vetter > Cc: Laurentiu Palcu > Cc: Lucas Stach > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: Pengutronix Kernel Team > Cc: Fabio Estevam > Cc: NXP Linux Team > Cc: Philipp Zabel > Cc: Paul Cercueil > Cc: Chun-Kuang Hu > Cc: Matthias Brugger > Cc: Neil Armstrong > Cc: Kevin Hilman > Cc: Jerome Brunet > Cc: Martin Blumenstingl > Cc: Marek Vasut > Cc: Stefan Agner > Cc: Sandy Huang > Cc: "Heiko Stübner" > Cc: Yannick Fertre > Cc: Philippe Cornu > Cc: Benjamin Gaignard > Cc: Maxime Coquelin > Cc: Alexandre Torgue > Cc: Maxime Ripard > Cc: Chen-Yu Tsai > Cc: Jernej Skrabec > Cc: Jyri Sarha > Cc: Tomi Valkeinen > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-m...@vger.kernel.org > Cc: linux-media...@lists.infradead.org > Cc: linux-amlo...@lists.infradead.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-st...@st-md-mailman.stormreply.com > Cc: linux-su...@lists.linux.dev For sun4i: Acked-by: Jernej Skrabec Best regards, Jernej ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules
Am 21.05.21 um 17:16 schrieb Daniel Vetter:
On Fri, May 21, 2021 at 05:00:46PM +0200, Bas Nieuwenhuizen wrote:
On Fri, May 21, 2021 at 4:37 PM Daniel Vetter wrote:
On Fri, May 21, 2021 at 11:46:23AM +0200, Bas Nieuwenhuizen wrote:
On Fri, May 21, 2021 at 11:10 AM Daniel Vetter wrote:
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 88a24a0b5691..cc8426e1e8a8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -617,8 +617,8 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser *p,
amdgpu_bo_list_for_each_entry(e, p->bo_list) {
struct amdgpu_bo *bo = ttm_to_amdgpu_bo(e->tv.bo);
- /* Make sure we use the exclusive slot for shared BOs */
- if (bo->prime_shared_count)
+ /* Make sure we use the exclusive slot for all potentially
shared BOs */
+ if (!(bo->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID))
e->tv.num_shared = 0;
I think it also makes sense to skip this with
AMDGPU_GEM_CREATE_EXPLICIT_SYNC? It can be shared but I don't think
anyone expects implicit sync to happen with those.
Ah yes, I missed this entirely. So the "no implicit flag" is already
there, and the _only_ thing that's missing really is a way to fish out the
implicit fences, and set them.
https://lore.kernel.org/dri-devel/20210520190007.534046-1-ja...@jlekstrand.net/
So I think all that's really needed in radv is not setting
RADEON_FLAG_IMPLICIT_SYNC for winsys buffers when Jason's dma-buf ioctl
are present (means you need to do some import/export and keep the fd
around for winsys buffers, but shouldn't be too bad), and then control the
implicit fences entirely explicitly like vk expects.
That is the part I'm less sure about. This is a BO wide flag so we are
also disabling implicit sync in the compositor. If the compositor does
only do read stuff that is ok, as the inserted exclusive fence will
work for that. But as I learned recently the app provided buffer may
end up being written to by the X server which open a whole can of
potential problems if implicit sync gets disabled between Xserver
operations on the app provided buffer. Hence setting that on the WSI
buffer is a whole new can of potential problems and hence I've said a
submission based flag would be preferred.
I can certainly try it out though.
Hm yeah that's the wrong flag. We need a flag on the drm_file which the
explicit userspace sets. And which is valid only for itself.
There's a nice flags field when creating a ctx, but it's not validated and
there's already a comment that we have to filter out garbage priority, so
that's not use. I'll whip up something entirely untested just as a draft.
We could provide an IOCTL for the BO to change the flag.
But could we first figure out the semantics we want to use here?
Cause I'm pretty sure we don't actually need those changes at all and as
said before I'm certainly NAKing things which break existing use cases.
Regards,
Christian.
-Daniel
Are you bored enough to type this up for radv? I'll give Jason's kernel
stuff another review meanwhile.
-Daniel
e->bo_va = amdgpu_vm_bo_find(vm, bo);
}
--
2.31.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: Add missing macro name changes
== Series Details ==
Series: drm/i915/gvt: Add missing macro name changes
URL : https://patchwork.freedesktop.org/series/90427/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10120 -> Patchwork_20171
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/index.html
Known issues
Here are the changes found in Patchwork_20171 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@hangcheck:
- fi-icl-y: [PASS][1] -> [INCOMPLETE][2] ([i915#2782])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-icl-y/igt@i915_selftest@l...@hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-icl-y/igt@i915_selftest@l...@hangcheck.html
Possible fixes
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [FAIL][3] ([i915#1372]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2: [FAIL][5] ([i915#49]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
Warnings
* igt@i915_selftest@live@execlists:
- fi-cfl-8109u: [INCOMPLETE][7] ([i915#3462]) -> [DMESG-FAIL][8]
([i915#3462])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
- fi-icl-u2: [INCOMPLETE][9] ([i915#2782] / [i915#3462]) ->
[DMESG-FAIL][10] ([i915#3462])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-icl-u2/igt@i915_selftest@l...@execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-icl-u2/igt@i915_selftest@l...@execlists.html
* igt@runner@aborted:
- fi-cfl-8700k: [FAIL][11] ([i915#3363]) -> [FAIL][12] ([i915#2426] /
[i915#3363])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-cfl-8700k/igt@run...@aborted.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-cfl-8700k/igt@run...@aborted.html
- fi-cfl-8109u: [FAIL][13] ([i915#3363]) -> [FAIL][14] ([i915#2426] /
[i915#3363])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-cfl-8109u/igt@run...@aborted.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-cfl-8109u/igt@run...@aborted.html
- fi-icl-u2: [FAIL][15] ([i915#2782] / [i915#3363]) -> [FAIL][16]
([i915#2426] / [i915#2782] / [i915#3363])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-icl-u2/igt@run...@aborted.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-icl-u2/igt@run...@aborted.html
- fi-glk-dsi: [FAIL][17] ([i915#2426] / [i915#3363] /
[k.org#202321]) -> [FAIL][18] ([i915#3363] / [k.org#202321])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-glk-dsi/igt@run...@aborted.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-glk-dsi/igt@run...@aborted.html
- fi-bdw-5557u: [FAIL][19] ([i915#3462]) -> [FAIL][20] ([i915#1602] /
[i915#2029])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-bdw-5557u/igt@run...@aborted.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-bdw-5557u/igt@run...@aborted.html
- fi-kbl-guc: [FAIL][21] ([i915#1436] / [i915#2426] / [i915#3363])
-> [FAIL][22] ([i915#1436] / [i915#3363])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-kbl-guc/igt@run...@aborted.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-kbl-guc/igt@run...@aborted.html
- fi-cfl-guc: [FAIL][23] ([i915#3363]) -> [FAIL][24] ([i915#2426] /
[i915#3363])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-cfl-guc/igt@run...@aborted.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-cfl-guc/igt@run...@aborted.html
- fi-skl-6700k2: [FAIL][25] ([i915#1436] / [i915#2426] / [i915#3363])
-> [FAIL][26] ([i915#1436] / [i915#3363])
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-skl-6700k2/igt@run...@aborted.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-skl-6700k2/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109285]:
[Intel-gfx] [PATCH 0/3] Clean a few backend interfaces in the i915
As discussed in [1] start merging some support patches as a precursor to GuC submission the i915. This is step #1 mentioned in [1]. [1] https://patchwork.freedesktop.org/series/89844/ Signed-off-by: Matthew Brost Chris Wilson (3): drm/i915/gt: Move engine setup out of set_default_submission drm/i915/gt: Move submission_method into intel_gt drm/i915/gt: Move CS interrupt handler to the backend drivers/gpu/drm/i915/gt/intel_engine.h| 8 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 19 +++- drivers/gpu/drm/i915/gt/intel_engine_types.h | 14 +-- .../drm/i915/gt/intel_execlists_submission.c | 95 +-- .../drm/i915/gt/intel_execlists_submission.h | 3 - drivers/gpu/drm/i915/gt/intel_gt_irq.c| 82 +--- drivers/gpu/drm/i915/gt/intel_gt_irq.h| 23 + drivers/gpu/drm/i915/gt/intel_gt_types.h | 7 ++ drivers/gpu/drm/i915/gt/intel_reset.c | 7 +- .../gpu/drm/i915/gt/intel_ring_submission.c | 12 ++- drivers/gpu/drm/i915/gt/intel_rps.c | 2 +- drivers/gpu/drm/i915/gt/selftest_execlists.c | 2 +- .../drm/i915/gt/selftest_ring_submission.c| 2 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 64 ++--- .../gpu/drm/i915/gt/uc/intel_guc_submission.h | 1 - drivers/gpu/drm/i915/i915_irq.c | 10 +- drivers/gpu/drm/i915/i915_perf.c | 10 +- 17 files changed, 199 insertions(+), 162 deletions(-) -- 2.28.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915/gt: Move submission_method into intel_gt
From: Chris Wilson
Since we setup the submission method for the engines once, it is easy to
assign an enum and use that instead of probing into the backends.
Signed-off-by: Matthew Brost
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_engine.h | 8 +++-
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 12
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 8
drivers/gpu/drm/i915/gt/intel_execlists_submission.h | 3 ---
drivers/gpu/drm/i915/gt/intel_gt_types.h | 7 +++
drivers/gpu/drm/i915/gt/intel_reset.c| 7 +++
drivers/gpu/drm/i915/gt/selftest_execlists.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_ring_submission.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c| 5 -
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h| 1 -
drivers/gpu/drm/i915/i915_perf.c | 10 +-
11 files changed, 32 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 47ee8578e511..8d9184920c51 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -13,8 +13,9 @@
#include "i915_reg.h"
#include "i915_request.h"
#include "i915_selftest.h"
-#include "gt/intel_timeline.h"
#include "intel_engine_types.h"
+#include "intel_gt_types.h"
+#include "intel_timeline.h"
#include "intel_workarounds.h"
struct drm_printer;
@@ -262,6 +263,11 @@ void intel_engine_init_active(struct intel_engine_cs
*engine,
#define ENGINE_MOCK1
#define ENGINE_VIRTUAL 2
+static inline bool intel_engine_uses_guc(const struct intel_engine_cs *engine)
+{
+ return engine->gt->submission_method >= INTEL_SUBMISSION_GUC;
+}
+
static inline bool
intel_engine_has_preempt_reset(const struct intel_engine_cs *engine)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index eba2da9679a5..e54a2a4df87c 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -909,12 +909,16 @@ int intel_engines_init(struct intel_gt *gt)
enum intel_engine_id id;
int err;
- if (intel_uc_uses_guc_submission(>uc))
+ if (intel_uc_uses_guc_submission(>uc)) {
+ gt->submission_method = INTEL_SUBMISSION_GUC;
setup = intel_guc_submission_setup;
- else if (HAS_EXECLISTS(gt->i915))
+ } else if (HAS_EXECLISTS(gt->i915)) {
+ gt->submission_method = INTEL_SUBMISSION_ELSP;
setup = intel_execlists_submission_setup;
- else
+ } else {
+ gt->submission_method = INTEL_SUBMISSION_RING;
setup = intel_ring_submission_setup;
+ }
for_each_engine(engine, gt, id) {
err = engine_setup_common(engine);
@@ -1479,7 +1483,7 @@ static void intel_engine_print_registers(struct
intel_engine_cs *engine,
drm_printf(m, "\tIPEHR: 0x%08x\n", ENGINE_READ(engine, IPEHR));
}
- if (intel_engine_in_guc_submission_mode(engine)) {
+ if (intel_engine_uses_guc(engine)) {
/* nothing to print yet */
} else if (HAS_EXECLISTS(dev_priv)) {
struct i915_request * const *port, *rq;
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 1108c193ab65..9d2da5ccaef6 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -1768,7 +1768,6 @@ process_csb(struct intel_engine_cs *engine, struct
i915_request **inactive)
*/
GEM_BUG_ON(!tasklet_is_locked(>tasklet) &&
!reset_in_progress(execlists));
- GEM_BUG_ON(!intel_engine_in_execlists_submission_mode(engine));
/*
* Note that csb_write, csb_status may be either in HWSP or mmio.
@@ -3884,13 +3883,6 @@ void intel_execlists_show_requests(struct
intel_engine_cs *engine,
spin_unlock_irqrestore(>active.lock, flags);
}
-bool
-intel_engine_in_execlists_submission_mode(const struct intel_engine_cs *engine)
-{
- return engine->set_default_submission ==
- execlists_set_default_submission;
-}
-
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftest_execlists.c"
#endif
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
index fd61dae820e9..4ca9b475e252 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
@@ -43,7 +43,4 @@ int intel_virtual_engine_attach_bond(struct intel_engine_cs
*engine,
const struct intel_engine_cs *master,
const struct intel_engine_cs *sibling);
[Intel-gfx] [PATCH 1/3] drm/i915/gt: Move engine setup out of set_default_submission
From: Chris Wilson
Now that we no longer switch back and forth between guc and execlists,
we no longer need to restore the backend's vfunc and can leave them set
after initialisation. The only catch is that we lose the submission on
wedging and still need to reset the submit_request vfunc on unwedging.
Signed-off-by: Matthew Brost
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Matthew Brost
---
.../drm/i915/gt/intel_execlists_submission.c | 46 -
.../gpu/drm/i915/gt/intel_ring_submission.c | 4 --
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 50 ---
3 files changed, 44 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index de124870af44..1108c193ab65 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -3076,29 +3076,6 @@ static void execlists_set_default_submission(struct
intel_engine_cs *engine)
engine->submit_request = execlists_submit_request;
engine->schedule = i915_schedule;
engine->execlists.tasklet.callback = execlists_submission_tasklet;
-
- engine->reset.prepare = execlists_reset_prepare;
- engine->reset.rewind = execlists_reset_rewind;
- engine->reset.cancel = execlists_reset_cancel;
- engine->reset.finish = execlists_reset_finish;
-
- engine->park = execlists_park;
- engine->unpark = NULL;
-
- engine->flags |= I915_ENGINE_SUPPORTS_STATS;
- if (!intel_vgpu_active(engine->i915)) {
- engine->flags |= I915_ENGINE_HAS_SEMAPHORES;
- if (can_preempt(engine)) {
- engine->flags |= I915_ENGINE_HAS_PREEMPTION;
- if (IS_ACTIVE(CONFIG_DRM_I915_TIMESLICE_DURATION))
- engine->flags |= I915_ENGINE_HAS_TIMESLICES;
- }
- }
-
- if (intel_engine_has_preemption(engine))
- engine->emit_bb_start = gen8_emit_bb_start;
- else
- engine->emit_bb_start = gen8_emit_bb_start_noarb;
}
static void execlists_shutdown(struct intel_engine_cs *engine)
@@ -3129,6 +3106,14 @@ logical_ring_default_vfuncs(struct intel_engine_cs
*engine)
engine->cops = _context_ops;
engine->request_alloc = execlists_request_alloc;
+ engine->reset.prepare = execlists_reset_prepare;
+ engine->reset.rewind = execlists_reset_rewind;
+ engine->reset.cancel = execlists_reset_cancel;
+ engine->reset.finish = execlists_reset_finish;
+
+ engine->park = execlists_park;
+ engine->unpark = NULL;
+
engine->emit_flush = gen8_emit_flush_xcs;
engine->emit_init_breadcrumb = gen8_emit_init_breadcrumb;
engine->emit_fini_breadcrumb = gen8_emit_fini_breadcrumb_xcs;
@@ -3149,6 +3134,21 @@ logical_ring_default_vfuncs(struct intel_engine_cs
*engine)
* until a more refined solution exists.
*/
}
+
+ engine->flags |= I915_ENGINE_SUPPORTS_STATS;
+ if (!intel_vgpu_active(engine->i915)) {
+ engine->flags |= I915_ENGINE_HAS_SEMAPHORES;
+ if (can_preempt(engine)) {
+ engine->flags |= I915_ENGINE_HAS_PREEMPTION;
+ if (IS_ACTIVE(CONFIG_DRM_I915_TIMESLICE_DURATION))
+ engine->flags |= I915_ENGINE_HAS_TIMESLICES;
+ }
+ }
+
+ if (intel_engine_has_preemption(engine))
+ engine->emit_bb_start = gen8_emit_bb_start;
+ else
+ engine->emit_bb_start = gen8_emit_bb_start_noarb;
}
static void logical_ring_default_irqs(struct intel_engine_cs *engine)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 9585546556ee..5f4f7f1df48f 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -989,14 +989,10 @@ static void gen6_bsd_submit_request(struct i915_request
*request)
static void i9xx_set_default_submission(struct intel_engine_cs *engine)
{
engine->submit_request = i9xx_submit_request;
-
- engine->park = NULL;
- engine->unpark = NULL;
}
static void gen6_bsd_set_default_submission(struct intel_engine_cs *engine)
{
- i9xx_set_default_submission(engine);
engine->submit_request = gen6_bsd_submit_request;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 92688a9b6717..f72faa0b8339 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -608,35 +608,6 @@ static int guc_resume(struct intel_engine_cs *engine)
static void guc_set_default_submission(struct intel_engine_cs *engine)
{
engine->submit_request = guc_submit_request;
-
[Intel-gfx] [PATCH 3/3] drm/i915/gt: Move CS interrupt handler to the backend
From: Chris Wilson
The different submission backends each have their own preferred
behaviour and interrupt setup. Let each handle their own interrupts.
This becomes more useful later as we to extract the use of auxiliary
state in the interrupt handler that is backend specific.
Signed-off-by: Matthew Brost
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 7 ++
drivers/gpu/drm/i915/gt/intel_engine_types.h | 14 +---
.../drm/i915/gt/intel_execlists_submission.c | 41 ++
drivers/gpu/drm/i915/gt/intel_gt_irq.c| 82 ++-
drivers/gpu/drm/i915/gt/intel_gt_irq.h| 23 ++
.../gpu/drm/i915/gt/intel_ring_submission.c | 8 ++
drivers/gpu/drm/i915/gt/intel_rps.c | 2 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 11 ++-
drivers/gpu/drm/i915/i915_irq.c | 10 ++-
9 files changed, 124 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index e54a2a4df87c..3f9a811eb02b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -255,6 +255,11 @@ static void intel_engine_sanitize_mmio(struct
intel_engine_cs *engine)
intel_engine_set_hwsp_writemask(engine, ~0u);
}
+static void nop_irq_handler(struct intel_engine_cs *engine, u16 iir)
+{
+ GEM_DEBUG_WARN_ON(iir);
+}
+
static int intel_engine_setup(struct intel_gt *gt, enum intel_engine_id id)
{
const struct engine_info *info = _engines[id];
@@ -292,6 +297,8 @@ static int intel_engine_setup(struct intel_gt *gt, enum
intel_engine_id id)
engine->hw_id = info->hw_id;
engine->guc_id = MAKE_GUC_ID(info->class, info->instance);
+ engine->irq_handler = nop_irq_handler;
+
engine->class = info->class;
engine->instance = info->instance;
__sprint_engine_name(engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 883bafc44902..9ef349cd5cea 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -402,6 +402,7 @@ struct intel_engine_cs {
u32 irq_enable_mask; /* bitmask to enable ring interrupt */
void(*irq_enable)(struct intel_engine_cs *engine);
void(*irq_disable)(struct intel_engine_cs *engine);
+ void(*irq_handler)(struct intel_engine_cs *engine, u16 iir);
void(*sanitize)(struct intel_engine_cs *engine);
int (*resume)(struct intel_engine_cs *engine);
@@ -481,10 +482,9 @@ struct intel_engine_cs {
#define I915_ENGINE_HAS_PREEMPTION BIT(2)
#define I915_ENGINE_HAS_SEMAPHORES BIT(3)
#define I915_ENGINE_HAS_TIMESLICES BIT(4)
-#define I915_ENGINE_NEEDS_BREADCRUMB_TASKLET BIT(5)
-#define I915_ENGINE_IS_VIRTUAL BIT(6)
-#define I915_ENGINE_HAS_RELATIVE_MMIO BIT(7)
-#define I915_ENGINE_REQUIRES_CMD_PARSER BIT(8)
+#define I915_ENGINE_IS_VIRTUAL BIT(5)
+#define I915_ENGINE_HAS_RELATIVE_MMIO BIT(6)
+#define I915_ENGINE_REQUIRES_CMD_PARSER BIT(7)
unsigned int flags;
/*
@@ -593,12 +593,6 @@ intel_engine_has_timeslices(const struct intel_engine_cs
*engine)
return engine->flags & I915_ENGINE_HAS_TIMESLICES;
}
-static inline bool
-intel_engine_needs_breadcrumb_tasklet(const struct intel_engine_cs *engine)
-{
- return engine->flags & I915_ENGINE_NEEDS_BREADCRUMB_TASKLET;
-}
-
static inline bool
intel_engine_is_virtual(const struct intel_engine_cs *engine)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 9d2da5ccaef6..8db200422950 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -118,6 +118,7 @@
#include "intel_engine_stats.h"
#include "intel_execlists_submission.h"
#include "intel_gt.h"
+#include "intel_gt_irq.h"
#include "intel_gt_pm.h"
#include "intel_gt_requests.h"
#include "intel_lrc.h"
@@ -2384,6 +2385,45 @@ static void execlists_submission_tasklet(struct
tasklet_struct *t)
rcu_read_unlock();
}
+static void execlists_irq_handler(struct intel_engine_cs *engine, u16 iir)
+{
+ bool tasklet = false;
+
+ if (unlikely(iir & GT_CS_MASTER_ERROR_INTERRUPT)) {
+ u32 eir;
+
+ /* Upper 16b are the enabling mask, rsvd for internal errors */
+ eir = ENGINE_READ(engine, RING_EIR) & GENMASK(15, 0);
+ ENGINE_TRACE(engine, "CS error: %x\n", eir);
+
+ /* Disable the error interrupt until after the reset */
+ if (likely(eir)) {
+ ENGINE_WRITE(engine, RING_EMR, ~0u);
+ ENGINE_WRITE(engine, RING_EIR, eir);
+
[Intel-gfx] [PATCH] drm/i915/gvt: Add missing macro name changes
Propagate changes to macros name containing CSR_*
to DMC_* from display side.
Cc: intel-gvt-...@lists.freedesktop.org
Cc: Jani Nikula
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/gvt/handlers.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index dda320749c65..33496397a74f 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -3342,9 +3342,9 @@ static int init_skl_mmio_info(struct intel_gvt *gvt)
MMIO_D(_MMIO(_PLANE_SURF_3_A), D_SKL_PLUS);
MMIO_D(_MMIO(_PLANE_SURF_3_B), D_SKL_PLUS);
- MMIO_D(CSR_SSP_BASE, D_SKL_PLUS);
- MMIO_D(CSR_HTP_SKL, D_SKL_PLUS);
- MMIO_D(CSR_LAST_WRITE, D_SKL_PLUS);
+ MMIO_D(DMC_SSP_BASE, D_SKL_PLUS);
+ MMIO_D(DMC_HTP_SKL, D_SKL_PLUS);
+ MMIO_D(DMC_LAST_WRITE, D_SKL_PLUS);
MMIO_DFH(BDW_SCRATCH1, D_SKL_PLUS, F_CMD_ACCESS, NULL, NULL);
@@ -3655,7 +3655,7 @@ void intel_gvt_clean_mmio_info(struct intel_gvt *gvt)
* otherwise, need to update cmd_reg_handler in cmd_parser.c
*/
static struct gvt_mmio_block mmio_blocks[] = {
- {D_SKL_PLUS, _MMIO(CSR_MMIO_START_RANGE), 0x3000, NULL, NULL},
+ {D_SKL_PLUS, _MMIO(DMC_MMIO_START_RANGE), 0x3000, NULL, NULL},
{D_ALL, _MMIO(MCHBAR_MIRROR_BASE_SNB), 0x4, NULL, NULL},
{D_ALL, _MMIO(VGT_PVINFO_PAGE), VGT_PVINFO_SIZE,
pvinfo_mmio_read, pvinfo_mmio_write},
--
2.25.0
___
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/gvt: Add missing macro name changes
== Series Details == Series: drm/i915/gvt: Add missing macro name changes URL : https://patchwork.freedesktop.org/series/90427/ State : warning == Summary == $ dim checkpatch origin/drm-tip 355406594b6b drm/i915/gvt: Add missing macro name changes -:6: WARNING:TYPO_SPELLING: 'Propogate' may be misspelled - perhaps 'Propagate'? #6: Propogate changes to macros name containing CSR_* ^ total: 0 errors, 1 warnings, 0 checks, 20 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gvt: Add missing macro name changes
Propogate changes to macros name containing CSR_*
to DMC_* from display side.
Fixes: 0633cdcbaa77 ("drm/i915/dmc: Rename macro names containing csr")
Cc: intel-gvt-...@lists.freedesktop.org
Cc: Jani Nikula
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/gvt/handlers.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index dda320749c65..33496397a74f 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -3342,9 +3342,9 @@ static int init_skl_mmio_info(struct intel_gvt *gvt)
MMIO_D(_MMIO(_PLANE_SURF_3_A), D_SKL_PLUS);
MMIO_D(_MMIO(_PLANE_SURF_3_B), D_SKL_PLUS);
- MMIO_D(CSR_SSP_BASE, D_SKL_PLUS);
- MMIO_D(CSR_HTP_SKL, D_SKL_PLUS);
- MMIO_D(CSR_LAST_WRITE, D_SKL_PLUS);
+ MMIO_D(DMC_SSP_BASE, D_SKL_PLUS);
+ MMIO_D(DMC_HTP_SKL, D_SKL_PLUS);
+ MMIO_D(DMC_LAST_WRITE, D_SKL_PLUS);
MMIO_DFH(BDW_SCRATCH1, D_SKL_PLUS, F_CMD_ACCESS, NULL, NULL);
@@ -3655,7 +3655,7 @@ void intel_gvt_clean_mmio_info(struct intel_gvt *gvt)
* otherwise, need to update cmd_reg_handler in cmd_parser.c
*/
static struct gvt_mmio_block mmio_blocks[] = {
- {D_SKL_PLUS, _MMIO(CSR_MMIO_START_RANGE), 0x3000, NULL, NULL},
+ {D_SKL_PLUS, _MMIO(DMC_MMIO_START_RANGE), 0x3000, NULL, NULL},
{D_ALL, _MMIO(MCHBAR_MIRROR_BASE_SNB), 0x4, NULL, NULL},
{D_ALL, _MMIO(VGT_PVINFO_PAGE), VGT_PVINFO_SIZE,
pvinfo_mmio_read, pvinfo_mmio_write},
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display: fix typo when returning table
Reviewed-by: Anusha Srivatsa
> -Original Message-
> From: De Marchi, Lucas
> Sent: Thursday, May 20, 2021 5:52 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha
> Subject: [PATCH] drm/i915/display: fix typo when returning table
>
> Fix table returned when port_clock > 27:
>
> drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c:752:47: error:
> variable 'adlp_dkl_phy_dp_ddi_trans_hbr2_hbr3' is not needed and will not
> be emitted [-Werror,-Wunneeded-internal-declaration]
> static const struct tgl_dkl_phy_ddi_buf_trans
> adlp_dkl_phy_dp_ddi_trans_hbr2_hbr3[] = {
>
> Initial version of the patch had it in a single table, but on second version
> the
> table got split, but we continued to reference just one of them.
>
> Fixes: ca962882268a ("drm/i915/adl_p: Define and use ADL-P specific DP
> translation tables")
> Reported-by: kernel test robot
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> index ce5d5d13b7c1..8bfd00f49f2a 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> @@ -1383,7 +1383,7 @@ adlp_get_dkl_buf_trans_dp(struct intel_encoder
> *encoder, {
> if (crtc_state->port_clock > 27) {
> *n_entries =
> ARRAY_SIZE(adlp_dkl_phy_dp_ddi_trans_hbr2_hbr3);
> - return adlp_dkl_phy_dp_ddi_trans_hbr;
> + return adlp_dkl_phy_dp_ddi_trans_hbr2_hbr3;
> }
>
> *n_entries = ARRAY_SIZE(adlp_dkl_phy_dp_ddi_trans_hbr);
> --
> 2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan
On Fri, May 21, 2021 at 01:00:54PM +0100, Tvrtko Ursulin wrote:
>
> On 19/05/2021 00:58, Matthew Brost wrote:
> > Add entry fpr i915 new parallel submission uAPI plan.
> >
> > v2:
> > (Daniel Vetter):
> >- Expand logical order explaination
> >- Add dummy header
> >- Only allow N BBs in execbuf IOCTL
> >- Configure parallel submission per slot not per gem context
> >
> > Cc: Tvrtko Ursulin
> > Cc: Tony Ye
> > CC: Carl Zhang
> > Cc: Daniel Vetter
> > Cc: Jason Ekstrand
> > Signed-off-by: Matthew Brost
> > ---
> > Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 ++
> > Documentation/gpu/rfc/i915_scheduler.rst | 53 ++-
> > 2 files changed, 196 insertions(+), 1 deletion(-)
> > create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h
> >
> > diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > new file mode 100644
> > index ..8c64b983ccad
> > --- /dev/null
> > +++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > @@ -0,0 +1,144 @@
> > +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see
> > i915_context_engines_parallel_submit */
> > +
> > +/*
> > + * i915_context_engines_parallel_submit:
> > + *
> > + * Setup a slot to allow multiple BBs to be submitted in a single execbuf
> > IOCTL.
> > + * Those BBs will then be scheduled to run on the GPU in parallel. Multiple
> > + * hardware contexts are created internally in the i915 run these BBs.
> > Once a
> > + * slot is configured for N BBs only N BBs can be submitted in each execbuf
> > + * IOCTL and this is implict behavior (e.g. the user doesn't tell the
> > execbuf
> > + * IOCTL there are N BBs, the execbuf IOCTL know how many BBs there are
> > based on
> > + * the slots configuration).
>
> 1)
> Expand the term slot here with "slot in the context engine map" least once
> for clarity.
>
Sure.
> 2)
> About where execbuf will implicitly be finding batches - suggest to also
> cover first/last flag here. I know you have it in the readme but I think it
> is good if uapi header is as self-contained as possible.
>
Yep, good idea.
> > + *
> > + * Their are two currently defined ways to control the placement of the
> > + * hardware contexts on physical engines: default behavior (no flags) and
> > + * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added the in the
> > + * future as new hardware / use cases arise. Details of how to use this
> > + * interface below above the flags.
> > + *
> > + * Returns -EINVAL if hardware context placement configuration invalid or
> > if the
> > + * placement configuration isn't supported on the platform / submission
> > + * interface.
> > + * Returns -ENODEV if extension isn't supported on the platform /
> > submission
> > + * inteface.
> > + */
> > +struct i915_context_engines_parallel_submit {
> > + struct i915_user_extension base;
> > +
> > + __u16 engine_index; /* slot for parallel engine */
> > + __u16 width;/* number of contexts per parallel engine */
> > + __u16 num_siblings; /* number of siblings per context */
> > + __u16 mbz16;
> > +/*
> > + * Default placement behvavior (currently unsupported):
> > + *
> > + * Rather than restricting parallel submission to a single class with a
> > + * logically contiguous placement (I915_PARALLEL_IMPLICT_BONDS), add a
> > mode that
>
> What do you mean with logically contiguous here? It sounds ambiguous versus
> logical vs "normal" engine instance numbers.
>
This is a little backwards. I think when I wrote this originally the implicit
placement comments were first. I can reword this.
> > + * enables parallel submission across multiple engine classes. In this
> > case each
> > + * context's logical engine mask indicates where that context can placed.
> > It is
> > + * implied in this mode that all contexts have mutual exclusive placement
> > (e.g.
> > + * if one context is running CS0 no other contexts can run on CS0).
>
> I think talk about logical context and its mask is too implementation detail
> at the uapi level. Instead I would suggest more userspace programmer centric
> description.
Ok, can you give me suggestion? Writing DOC isn't really my strength.
>
> > + *
> > + * Example 1 pseudo code:
> > + * CSX[Y] = engine class X, logical instance Y
> > + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
> > + * set_engines(INVALID)
> > + * set_parallel(engine_index=0, width=2, num_siblings=2,
> > + * engines=CS0[0],CS0[1],CS1[0],CS1[1])
> > + *
> > + * Results in the following valid placements:
> > + * CS0[0], CS1[0]
> > + * CS0[0], CS1[1]
> > + * CS0[1], CS1[0]
> > + * CS0[1], CS1[1]
> > + *
> > + * This can also be though of as 2 virtual engines:
> > + * VE[0] = CS0[0], CS0[1]
> > + * VE[1] = CS1[0], CS1[1]
>
> Ah okay so essentially similar to what I was proposing a year ago. But then
> it is no longer "set_parallel" really. It is one slot in
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Move LMEM (VRAM) management over to TTM (rev3)
== Series Details ==
Series: drm/i915: Move LMEM (VRAM) management over to TTM (rev3)
URL : https://patchwork.freedesktop.org/series/90022/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10120 -> Patchwork_20170
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20170/index.html
Known issues
Here are the changes found in Patchwork_20170 that come from known issues:
### IGT changes ###
Possible fixes
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [FAIL][1] ([i915#1372]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20170/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2: [FAIL][3] ([i915#49]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20170/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
Warnings
* igt@i915_selftest@live@execlists:
- fi-bsw-kefka: [INCOMPLETE][5] ([i915#2782] / [i915#2940] /
[i915#3462]) -> [DMESG-FAIL][6] ([i915#3462])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20170/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
* igt@runner@aborted:
- fi-skl-6600u: [FAIL][7] ([i915#1436] / [i915#3363]) -> [FAIL][8]
([i915#1436] / [i915#2426] / [i915#3363])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-skl-6600u/igt@run...@aborted.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20170/fi-skl-6600u/igt@run...@aborted.html
- fi-bdw-5557u: [FAIL][9] ([i915#3462]) -> [FAIL][10] ([i915#1602] /
[i915#2029])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-bdw-5557u/igt@run...@aborted.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20170/fi-bdw-5557u/igt@run...@aborted.html
- fi-kbl-soraka: [FAIL][11] ([i915#1436] / [i915#2426] / [i915#3363])
-> [FAIL][12] ([i915#1436] / [i915#3363])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-kbl-soraka/igt@run...@aborted.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20170/fi-kbl-soraka/igt@run...@aborted.html
- fi-cml-u2: [FAIL][13] ([i915#2082] / [i915#2426] / [i915#3363] /
[i915#3462]) -> [FAIL][14] ([i915#3363] / [i915#3462])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-cml-u2/igt@run...@aborted.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20170/fi-cml-u2/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
[i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
[i915#2082]: https://gitlab.freedesktop.org/drm/intel/issues/2082
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
[i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
[i915#2932]: https://gitlab.freedesktop.org/drm/intel/issues/2932
[i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
[i915#2966]: https://gitlab.freedesktop.org/drm/intel/issues/2966
[i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
[i915#3276]: https://gitlab.freedesktop.org/drm/intel/issues/3276
[i915#3277]: https://gitlab.freedesktop.org/drm/intel/issues/3277
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3283]: https://gitlab.freedesktop.org/drm/intel/issues/3283
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
[i915#3462]: https://gitlab.freedesktop.org/drm/intel/issues/3462
[i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
Participating hosts (41 -> 39)
--
Additional (1): fi-rkl-11500t
Missing(3): fi-bsw-cyan fi-bdw-samus fi-hsw-4200u
Build changes
-
*
Re: [Intel-gfx] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan
On Thu, May 20, 2021 at 09:41:20PM +0200, Daniel Vetter wrote:
> On Thu, May 20, 2021 at 11:57:44AM +0100, Tvrtko Ursulin wrote:
> >
> > On 20/05/2021 10:54, Daniel Vetter wrote:
> > > On Wed, May 19, 2021 at 7:19 PM Matthew Brost
> > > wrote:
> > > >
> > > > On Wed, May 19, 2021 at 01:10:04PM +0200, Daniel Vetter wrote:
> > > > > On Tue, May 18, 2021 at 04:58:30PM -0700, Matthew Brost wrote:
> > > > > > Add entry fpr i915 new parallel submission uAPI plan.
> > > > > >
> > > > > > v2:
> > > > > > (Daniel Vetter):
> > > > > >- Expand logical order explaination
> > > > > >- Add dummy header
> > > > > >- Only allow N BBs in execbuf IOCTL
> > > > > >- Configure parallel submission per slot not per gem context
> > > > > >
> > > > > > Cc: Tvrtko Ursulin
> > > > > > Cc: Tony Ye
> > > > > > CC: Carl Zhang
> > > > > > Cc: Daniel Vetter
> > > > > > Cc: Jason Ekstrand
> > > > > > Signed-off-by: Matthew Brost
> > > > > > ---
> > > > > > Documentation/gpu/rfc/i915_parallel_execbuf.h | 144
> > > > > > ++
> > > > > > Documentation/gpu/rfc/i915_scheduler.rst | 53 ++-
> > > > > > 2 files changed, 196 insertions(+), 1 deletion(-)
> > > > > > create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > > > >
> > > > > > diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > > > > b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > > > > new file mode 100644
> > > > > > index ..8c64b983ccad
> > > > > > --- /dev/null
> > > > > > +++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > > > > @@ -0,0 +1,144 @@
> > > > > > +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see
> > > > > > i915_context_engines_parallel_submit */
> > > > > > +
> > > > > > +/*
> > > > > > + * i915_context_engines_parallel_submit:
> > > > > > + *
> > > > > > + * Setup a slot to allow multiple BBs to be submitted in a single
> > > > > > execbuf IOCTL.
> > > > > > + * Those BBs will then be scheduled to run on the GPU in parallel.
> > > > > > Multiple
> > > > > > + * hardware contexts are created internally in the i915 run these
> > > > > > BBs. Once a
> > > > > > + * slot is configured for N BBs only N BBs can be submitted in
> > > > > > each execbuf
> > > > > > + * IOCTL and this is implict behavior (e.g. the user doesn't tell
> > > > > > the execbuf
> > > > > > + * IOCTL there are N BBs, the execbuf IOCTL know how many BBs
> > > > > > there are based on
> > > > > > + * the slots configuration).
> > > > > > + *
> > > > > > + * Their are two currently defined ways to control the placement
> > > > > > of the
> > > > > > + * hardware contexts on physical engines: default behavior (no
> > > > > > flags) and
> > > > > > + * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added
> > > > > > the in the
> > > > > > + * future as new hardware / use cases arise. Details of how to use
> > > > > > this
> > > > > > + * interface below above the flags.
> > > > > > + *
> > > > > > + * Returns -EINVAL if hardware context placement configuration
> > > > > > invalid or if the
> > > > > > + * placement configuration isn't supported on the platform /
> > > > > > submission
> > > > > > + * interface.
> > > > > > + * Returns -ENODEV if extension isn't supported on the platform /
> > > > > > submission
> > > > > > + * inteface.
> > > > > > + */
> > > > > > +struct i915_context_engines_parallel_submit {
> > > > > > + struct i915_user_extension base;
> > > > > > +
> > > > > > + __u16 engine_index; /* slot for parallel engine */
> > > > > > + __u16 width;/* number of contexts per parallel
> > > > > > engine */
> > > > > > + __u16 num_siblings; /* number of siblings per context */
> > > > > > + __u16 mbz16;
> > > > >
> > > > > Ok the big picture looks reasonable now, the flags still confuse me.
> > > > >
> > > >
> > > > Yea, it is a bit confusing.
> > > >
> > > > > > +/*
> > > > > > + * Default placement behvavior (currently unsupported):
> > > > > > + *
> > > > > > + * Rather than restricting parallel submission to a single class
> > > > > > with a
> > > > > > + * logically contiguous placement (I915_PARALLEL_IMPLICT_BONDS),
> > > > > > add a mode that
> > > > > > + * enables parallel submission across multiple engine classes. In
> > > > > > this case each
> > > > > > + * context's logical engine mask indicates where that context can
> > > > > > placed. It is
> > > > > > + * implied in this mode that all contexts have mutual exclusive
> > > > > > placement (e.g.
> > > > > > + * if one context is running CS0 no other contexts can run on CS0).
> > > > > > + *
> > > > > > + * Example 1 pseudo code:
> > > > > > + * CSX[Y] = engine class X, logical instance Y
> > > > > > + * INVALID = I915_ENGINE_CLASS_INVALID,
> > > > > > I915_ENGINE_CLASS_INVALID_NONE
> > > > > > + * set_engines(INVALID)
> > > > > > + * set_parallel(engine_index=0, width=2, num_siblings=2,
> > > > > > + *
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Reenable LTTPR non-transparent LT mode for DPCD_REV<1.4
Re-reported.
-Original Message-
From: Deak, Imre
Sent: Friday, May 21, 2021 7:33 AM
To: intel-gfx@lists.freedesktop.org; Casey Harkins ;
Almahallawy, Khaled ; Vudum, Lakshminarayana
Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915: Reenable LTTPR non-transparent
LT mode for DPCD_REV<1.4
On Thu, May 13, 2021 at 11:23:41PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Reenable LTTPR non-transparent LT mode for DPCD_REV<1.4
> URL : https://patchwork.freedesktop.org/series/90102/
> State : failure
Pushed to drm-intel-next, thanks for the report, testing and review.
The failures are unrelated see below.
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_10074_full -> Patchwork_20115_full
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_20115_full absolutely need to
> be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_20115_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_20115_full:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@kms_draw_crc@draw-method-xrgb-blt-untiled:
> - shard-skl: NOTRUN -> [FAIL][1]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-skl8/ig
> t@kms_draw_...@draw-method-xrgb-blt-untiled.html
>
> * igt@kms_flip_tiling@flip-changes-tiling@hdmi-a-1-pipe-c:
> - shard-glk: [PASS][2] -> [FAIL][3] +1 similar issue
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10074/shard-glk8/igt@kms_flip_tiling@flip-changes-til...@hdmi-a-1-pipe-c.html
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-glk6/ig
> t@kms_flip_tiling@flip-changes-til...@hdmi-a-1-pipe-c.html
>
> * igt@kms_plane_cursor@pipe-b-primary-size-256:
> - shard-snb: NOTRUN -> [FAIL][4]
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-snb5/ig
> t@kms_plane_cur...@pipe-b-primary-size-256.html
On all the above platforms the LTTPR detection is disabled, so the change is
unrelevant on them.
All the logs have the
x86/PAT: gem_mmap_offset:1163 map pfn RAM range req write-combining for [mem
0x11d278000-0x11d278fff], got write-back message, so the failures could be
related to that.
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * {igt@kms_plane@plane-position-hole@pipe-a-planes}:
> - shard-glk: [FAIL][5] ([i915#3457]) -> [FAIL][6]
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10074/shard-glk9/igt@kms_plane@plane-position-h...@pipe-a-planes.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-glk8/ig
> t@kms_plane@plane-position-h...@pipe-a-planes.html
>
>
>
> ### Piglit changes ###
>
> Possible regressions
>
> *
> spec@arb_gpu_shader_int64@execution@built-in-functions@fs-op-ne-uint64_t-uint64_t
> (NEW):
> - {pig-icl-1065g7}: NOTRUN -> [CRASH][7]
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/pig-icl-1065g
> 7/spec@arb_gpu_shader_int64@execution@built-in-functions@fs-op-ne-uint
> 64_t-uint64_t.html
>
> *
> spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-gt-uint64_t-uint64_t-using-if
> (NEW):
> - {pig-icl-1065g7}: NOTRUN -> [INCOMPLETE][8] +7 similar issues
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/pig-icl-1065g
> 7/spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-gt-uin
> t64_t-uint64_t-using-if.html
>
>
> New tests
> -
>
> New tests have been introduced between CI_DRM_10074_full and
> Patchwork_20115_full:
>
> ### New Piglit tests (9) ###
>
> *
> spec@arb_gpu_shader_int64@execution@built-in-functions@cs-min-i64vec2-i64vec2:
> - Statuses : 1 incomplete(s)
> - Exec time: [0.0] s
>
> *
> spec@arb_gpu_shader_int64@execution@built-in-functions@cs-op-mult-i64vec3-i64vec3:
> - Statuses : 1 incomplete(s)
> - Exec time: [0.0] s
>
> *
> spec@arb_gpu_shader_int64@execution@built-in-functions@fs-op-ne-uint64_t-uint64_t:
> - Statuses : 1 crash(s)
> - Exec time: [0.76] s
>
> *
> spec@arb_gpu_shader_int64@execution@built-in-functions@gs-max-i64vec3-i64vec3:
> - Statuses : 1 incomplete(s)
> - Exec time: [0.0] s
>
> *
> spec@arb_gpu_shader_int64@execution@built-in-functions@gs-op-mult-i64vec4-i64vec4:
> - Statuses : 1 incomplete(s)
> - Exec time: [0.0] s
>
> *
> spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-gt-uint64_t-uint64_t-using-if:
> - Statuses : 1 incomplete(s)
> - Exec
Re: [Intel-gfx] [CI 3/5] drm/i915/dmc: Rename macro names containing csr
> -Original Message- > From: Jani Nikula > Sent: Friday, May 21, 2021 12:45 AM > To: De Marchi, Lucas ; Srivatsa, Anusha > > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [CI 3/5] drm/i915/dmc: Rename macro names > containing csr > > On Tue, 18 May 2021, Lucas De Marchi wrote: > > On Tue, May 18, 2021 at 02:34:42PM -0700, Anusha Srivatsa wrote: > >>Rename all occurences of CSR_* with DMC_* > >> > >>Cc: Jani Nikula > >>Signed-off-by: Anusha Srivatsa > > > > > > Reviewed-by: Lucas De Marchi > > We failed to take GVT into account, and apparently neither CI or Anusha has > CONFIG_DRM_I915_GVT=y. They use the register definitions, and this broke > the build. > > Anusha, please enable the config, and fix the fallout. Cc: the patch to GVT > folks for ack. On it. Anusha > > > Thanks, > Jani. > > > > > > > Lucas De Marchi > > > >>--- > >> drivers/gpu/drm/i915/display/intel_csr.c | 167 +- > >> drivers/gpu/drm/i915/display/intel_csr.h | 6 +- > >> .../drm/i915/display/intel_display_debugfs.c | 16 +- > >> .../drm/i915/display/intel_display_power.c| 14 +- > >> drivers/gpu/drm/i915/i915_gpu_error.c | 4 +- > >> drivers/gpu/drm/i915/i915_reg.h | 28 +-- > >> 6 files changed, 117 insertions(+), 118 deletions(-) > >> > >>diff --git a/drivers/gpu/drm/i915/display/intel_csr.c > >>b/drivers/gpu/drm/i915/display/intel_csr.c > >>index 5ed286dc6720..f2124796ce77 100644 > >>--- a/drivers/gpu/drm/i915/display/intel_csr.c > >>+++ b/drivers/gpu/drm/i915/display/intel_csr.c > >>@@ -30,10 +30,9 @@ > >> #include "intel_de.h" > >> > >> /** > >>- * DOC: csr support for dmc > >>+ * DOC: DMC firmware support > >> * > >>- * Display Context Save and Restore (CSR) firmware support added from > >>gen9 > >>- * onwards to drive newly added DMC (Display microcontroller) in > >>display > >>+ * From gen9 onwards we have newly added DMC (Display > >>+ microcontroller) in display > >> * engine to save and restore the state of display engine when it > >>enter into > >> * low-power state and comes back to normal. > >> */ > >>@@ -44,55 +43,55 @@ > >>__stringify(major) "_" \ > >>__stringify(minor) ".bin" > >> > >>-#define GEN12_CSR_MAX_FW_SIZE ICL_CSR_MAX_FW_SIZE > >>+#define GEN12_DMC_MAX_FW_SIZE > ICL_DMC_MAX_FW_SIZE > >> > >>-#define ADLS_CSR_PATH DMC_PATH(adls, 2, 01) > >>-#define ADLS_CSR_VERSION_REQUIRED CSR_VERSION(2, 1) > >>-MODULE_FIRMWARE(ADLS_CSR_PATH); > >>+#define ADLS_DMC_PATH DMC_PATH(adls, 2, 01) > >>+#define ADLS_DMC_VERSION_REQUIRED DMC_VERSION(2, 1) > >>+MODULE_FIRMWARE(ADLS_DMC_PATH); > >> > >>-#define DG1_CSR_PATH DMC_PATH(dg1, 2, 02) > >>-#define DG1_CSR_VERSION_REQUIRED CSR_VERSION(2, 2) > >>-MODULE_FIRMWARE(DG1_CSR_PATH); > >>+#define DG1_DMC_PATH DMC_PATH(dg1, 2, 02) > >>+#define DG1_DMC_VERSION_REQUIRED DMC_VERSION(2, 2) > >>+MODULE_FIRMWARE(DG1_DMC_PATH); > >> > >>-#define RKL_CSR_PATH DMC_PATH(rkl, 2, 02) > >>-#define RKL_CSR_VERSION_REQUIRED CSR_VERSION(2, 2) > >>-MODULE_FIRMWARE(RKL_CSR_PATH); > >>+#define RKL_DMC_PATH DMC_PATH(rkl, 2, 02) > >>+#define RKL_DMC_VERSION_REQUIRED DMC_VERSION(2, 2) > >>+MODULE_FIRMWARE(RKL_DMC_PATH); > >> > >>-#define TGL_CSR_PATH DMC_PATH(tgl, 2, 08) > >>-#define TGL_CSR_VERSION_REQUIRED CSR_VERSION(2, 8) > >>-MODULE_FIRMWARE(TGL_CSR_PATH); > >>+#define TGL_DMC_PATH DMC_PATH(tgl, 2, 08) > >>+#define TGL_DMC_VERSION_REQUIRED DMC_VERSION(2, 8) > >>+MODULE_FIRMWARE(TGL_DMC_PATH); > >> > >>-#define ICL_CSR_PATH DMC_PATH(icl, 1, 09) > >>-#define ICL_CSR_VERSION_REQUIRED CSR_VERSION(1, 9) > >>-#define ICL_CSR_MAX_FW_SIZE0x6000 > >>-MODULE_FIRMWARE(ICL_CSR_PATH); > >>+#define ICL_DMC_PATH DMC_PATH(icl, 1, 09) > >>+#define ICL_DMC_VERSION_REQUIRED DMC_VERSION(1, 9) > >>+#define ICL_DMC_MAX_FW_SIZE0x6000 > >>+MODULE_FIRMWARE(ICL_DMC_PATH); > >> > >>-#define CNL_CSR_PATH DMC_PATH(cnl, 1, 07) > >>-#define CNL_CSR_VERSION_REQUIRED CSR_VERSION(1, 7) > >>-#define CNL_CSR_MAX_FW_SIZEGLK_CSR_MAX_FW_SIZE > >>-MODULE_FIRMWARE(CNL_CSR_PATH); > >>+#define CNL_DMC_PATH DMC_PATH(cnl, 1, 07) > >>+#define CNL_DMC_VERSION_REQUIRED DMC_VERSION(1, 7) > >>+#define CNL_DMC_MAX_FW_SIZEGLK_DMC_MAX_FW_SIZE > >>+MODULE_FIRMWARE(CNL_DMC_PATH); > >> > >>-#define GLK_CSR_PATH DMC_PATH(glk, 1, 04) > >>-#define GLK_CSR_VERSION_REQUIRED CSR_VERSION(1, 4) > >>-#define GLK_CSR_MAX_FW_SIZE0x4000 > >>-MODULE_FIRMWARE(GLK_CSR_PATH); > >>+#define GLK_DMC_PATH DMC_PATH(glk, 1, 04) > >>+#define GLK_DMC_VERSION_REQUIRED DMC_VERSION(1, 4) > >>+#define GLK_DMC_MAX_FW_SIZE0x4000 >
Re: [Intel-gfx] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan
On Thu, May 20, 2021 at 09:44:59PM +0200, Daniel Vetter wrote:
> On Thu, May 20, 2021 at 08:10:59AM -0700, Matthew Brost wrote:
> > On Thu, May 20, 2021 at 11:54:25AM +0200, Daniel Vetter wrote:
> > > On Wed, May 19, 2021 at 7:19 PM Matthew Brost
> > > wrote:
> > > >
> > > > On Wed, May 19, 2021 at 01:10:04PM +0200, Daniel Vetter wrote:
> > > > > On Tue, May 18, 2021 at 04:58:30PM -0700, Matthew Brost wrote:
> > > > > > Add entry fpr i915 new parallel submission uAPI plan.
> > > > > >
> > > > > > v2:
> > > > > > (Daniel Vetter):
> > > > > > - Expand logical order explaination
> > > > > > - Add dummy header
> > > > > > - Only allow N BBs in execbuf IOCTL
> > > > > > - Configure parallel submission per slot not per gem context
> > > > > >
> > > > > > Cc: Tvrtko Ursulin
> > > > > > Cc: Tony Ye
> > > > > > CC: Carl Zhang
> > > > > > Cc: Daniel Vetter
> > > > > > Cc: Jason Ekstrand
> > > > > > Signed-off-by: Matthew Brost
> > > > > > ---
> > > > > > Documentation/gpu/rfc/i915_parallel_execbuf.h | 144
> > > > > > ++
> > > > > > Documentation/gpu/rfc/i915_scheduler.rst | 53 ++-
> > > > > > 2 files changed, 196 insertions(+), 1 deletion(-)
> > > > > > create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > > > >
> > > > > > diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > > > > b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > > > > new file mode 100644
> > > > > > index ..8c64b983ccad
> > > > > > --- /dev/null
> > > > > > +++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > > > > @@ -0,0 +1,144 @@
> > > > > > +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see
> > > > > > i915_context_engines_parallel_submit */
> > > > > > +
> > > > > > +/*
> > > > > > + * i915_context_engines_parallel_submit:
> > > > > > + *
> > > > > > + * Setup a slot to allow multiple BBs to be submitted in a single
> > > > > > execbuf IOCTL.
> > > > > > + * Those BBs will then be scheduled to run on the GPU in parallel.
> > > > > > Multiple
> > > > > > + * hardware contexts are created internally in the i915 run these
> > > > > > BBs. Once a
> > > > > > + * slot is configured for N BBs only N BBs can be submitted in
> > > > > > each execbuf
> > > > > > + * IOCTL and this is implict behavior (e.g. the user doesn't tell
> > > > > > the execbuf
> > > > > > + * IOCTL there are N BBs, the execbuf IOCTL know how many BBs
> > > > > > there are based on
> > > > > > + * the slots configuration).
> > > > > > + *
> > > > > > + * Their are two currently defined ways to control the placement
> > > > > > of the
> > > > > > + * hardware contexts on physical engines: default behavior (no
> > > > > > flags) and
> > > > > > + * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added
> > > > > > the in the
> > > > > > + * future as new hardware / use cases arise. Details of how to use
> > > > > > this
> > > > > > + * interface below above the flags.
> > > > > > + *
> > > > > > + * Returns -EINVAL if hardware context placement configuration
> > > > > > invalid or if the
> > > > > > + * placement configuration isn't supported on the platform /
> > > > > > submission
> > > > > > + * interface.
> > > > > > + * Returns -ENODEV if extension isn't supported on the platform /
> > > > > > submission
> > > > > > + * inteface.
> > > > > > + */
> > > > > > +struct i915_context_engines_parallel_submit {
> > > > > > + struct i915_user_extension base;
> > > > > > +
> > > > > > + __u16 engine_index; /* slot for parallel engine */
> > > > > > + __u16 width;/* number of contexts per parallel
> > > > > > engine */
> > > > > > + __u16 num_siblings; /* number of siblings per context */
> > > > > > + __u16 mbz16;
> > > > >
> > > > > Ok the big picture looks reasonable now, the flags still confuse me.
> > > > >
> > > >
> > > > Yea, it is a bit confusing.
> > > >
> > > > > > +/*
> > > > > > + * Default placement behvavior (currently unsupported):
> > > > > > + *
> > > > > > + * Rather than restricting parallel submission to a single class
> > > > > > with a
> > > > > > + * logically contiguous placement (I915_PARALLEL_IMPLICT_BONDS),
> > > > > > add a mode that
> > > > > > + * enables parallel submission across multiple engine classes. In
> > > > > > this case each
> > > > > > + * context's logical engine mask indicates where that context can
> > > > > > placed. It is
> > > > > > + * implied in this mode that all contexts have mutual exclusive
> > > > > > placement (e.g.
> > > > > > + * if one context is running CS0 no other contexts can run on CS0).
> > > > > > + *
> > > > > > + * Example 1 pseudo code:
> > > > > > + * CSX[Y] = engine class X, logical instance Y
> > > > > > + * INVALID = I915_ENGINE_CLASS_INVALID,
> > > > > > I915_ENGINE_CLASS_INVALID_NONE
> > > > > > + * set_engines(INVALID)
> > > > > > + * set_parallel(engine_index=0, width=2, num_siblings=2,
> > > > > > + *
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Reenable LTTPR non-transparent LT mode for DPCD_REV<1.4
== Series Details ==
Series: drm/i915: Reenable LTTPR non-transparent LT mode for DPCD_REV<1.4
URL : https://patchwork.freedesktop.org/series/90102/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10074_full -> Patchwork_20115_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_20115_full:
### Piglit changes ###
Possible regressions
*
spec@arb_gpu_shader_int64@execution@built-in-functions@fs-op-ne-uint64_t-uint64_t
(NEW):
- {pig-icl-1065g7}: NOTRUN -> [CRASH][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/pig-icl-1065g7/spec@arb_gpu_shader_int64@execution@built-in-functions@fs-op-ne-uint64_t-uint64_t.html
*
spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-gt-uint64_t-uint64_t-using-if
(NEW):
- {pig-icl-1065g7}: NOTRUN -> [INCOMPLETE][2] +7 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/pig-icl-1065g7/spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-gt-uint64_t-uint64_t-using-if.html
New tests
-
New tests have been introduced between CI_DRM_10074_full and
Patchwork_20115_full:
### New Piglit tests (9) ###
*
spec@arb_gpu_shader_int64@execution@built-in-functions@cs-min-i64vec2-i64vec2:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@arb_gpu_shader_int64@execution@built-in-functions@cs-op-mult-i64vec3-i64vec3:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@arb_gpu_shader_int64@execution@built-in-functions@fs-op-ne-uint64_t-uint64_t:
- Statuses : 1 crash(s)
- Exec time: [0.76] s
*
spec@arb_gpu_shader_int64@execution@built-in-functions@gs-max-i64vec3-i64vec3:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@arb_gpu_shader_int64@execution@built-in-functions@gs-op-mult-i64vec4-i64vec4:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-gt-uint64_t-uint64_t-using-if:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-mod-u64vec2-uint64_t:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@arb_gpu_shader_int64@execution@built-in-functions@vs-op-add-uint64_t-u64vec2:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@arb_gpu_shader_int64@execution@built-in-functions@vs-op-bitxor-uint64_t-uint64_t:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_20115_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@api_intel_bb@blit-noreloc-purge-cache-random:
- shard-apl: NOTRUN -> [DMESG-FAIL][3] ([i915#3457])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-apl7/igt@api_intel...@blit-noreloc-purge-cache-random.html
* igt@api_intel_bb@intel-bb-blit-none:
- shard-glk: [PASS][4] -> [FAIL][5] ([i915#3471]) +1 similar issue
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10074/shard-glk5/igt@api_intel...@intel-bb-blit-none.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-glk4/igt@api_intel...@intel-bb-blit-none.html
* igt@api_intel_bb@offset-control:
- shard-skl: NOTRUN -> [DMESG-WARN][6] ([i915#3457])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-skl8/igt@api_intel...@offset-control.html
* igt@gem_ctx_persistence@legacy-engines-queued:
- shard-snb: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099]) +5
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-queued.html
* igt@gem_eio@unwedge-stress:
- shard-skl: [PASS][8] -> [TIMEOUT][9] ([i915#2369] / [i915#3063]
/ [i915#3457])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10074/shard-skl7/igt@gem_...@unwedge-stress.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-skl9/igt@gem_...@unwedge-stress.html
- shard-snb: NOTRUN -> [FAIL][10] ([i915#3354] / [i915#3457])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-snb5/igt@gem_...@unwedge-stress.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-apl: [PASS][11] -> [FAIL][12] ([i915#3457]) +2 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10074/shard-apl3/igt@gem_exec_fair@basic-none-r...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-apl2/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gem_exec_fair@basic-none@bcs0:
- shard-glk: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#3457])
[13]:
Re: [Intel-gfx] [Mesa-dev] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan
On Fri, May 21, 2021 at 10:35:37AM +0200, Christian König wrote: > Am 20.05.21 um 23:38 schrieb Jason Ekstrand: > > On Thu, May 20, 2021 at 10:46 AM Matthew Brost > > wrote: > > > On Thu, May 20, 2021 at 01:11:59PM +0200, Christian König wrote: > > > > Am 19.05.21 um 18:51 schrieb Matthew Brost: > > > > > On Wed, May 19, 2021 at 01:45:39PM +0200, Christian König wrote: > > > > > > Oh, yeah we call that gang submit on the AMD side. > > > > > > > > > > > > Had already some internal discussions how to implement this, but so > > > > > > far > > > > > > couldn't figure out how to cleanly introduce that into the DRM > > > > > > scheduler. > > > > > > > > > > > > Can you briefly describe in a few words how that is supposed to > > > > > > work on the > > > > > > Intel side? > > On Intel, we actually have two cases which don't fit the current > > drm/scheduler model well: balanced and bonded. > > > > In the balanced model, we want to submit a batch which can go to any > > one of some set of engines and we don't care which. It's up to the > > kernel to pick an engine. Imagine you had 64 identical HW compute > > queues, for instance. This could be done by making all the identical > > engines share a single drm_gpu_scheduler and round-robin around the HW > > queues or something. I don't know that we strictly need drm/scheduler > > to be aware of it but it might be nice if it grew support for this > > mode so we could maintain a 1:1 relationship between HW queues and > > drm_gpu_schedulers. That said, I'm not sure how this would play with > > GuC queues so maybe it doesn't help? > > Oh, we do have support for load balancing like that. > > When you call drm_sched_entity_init() you can give a list of > drm_gpu_scheduler object to use round robing for scheduling. > > New jobs are then scheduler to the drm_gpu_scheduler instance which is idle > or rather the least busy one. > > > The bonded model is like your ganged, I think. We want to submit N > > batches to run in parallel. And they actually have to be executing on > > the GPU simultaneously and not just sort-of at similar times. We need > > this for video. There are also potential use-cases in Vulkan or even > > GL that might be able to use this. One difference with the balanced > > mode is that bonds don't, strictly speaking, need to be on the same > > type of engine. Imagine, for instance, a 3D batch with a parallel > > compute batch doing vertex pre-processing. > > > > I'm pretty sure the bonded case is something that the mobile drivers > > (panfrost, etc.) would like as well for doing Vulkan on tilers where > > you often have to have two command buffers running in parallel. > > They're currently doing it by submitting a giant pile of batches where > > they split the batch and add sync primitives every time some GL call > > requires them to sync between fragment and vertex pipes. > > Yeah, we have exactly the same problem as well. > > But so far every model we discussed has some drawbacks and it is rather hard > for the scheduler to guarantee that stuff runs at the same time. > > So if you got any ideas how to cleanly implement that then they would be > rather welcomed. > Everything Jason said about our submission modes is correct for execlists, we have balanced + bonded models which is tightly coupled with that backend. Fortunately with GuC submission most of this complexity goes away as the GuC handles this for us. e.g. For balanced when we register a context we just give it a mask of which physical engines a context is allowed to run on. For parallel we register N contexts in a single command with the placement information + submit to all the contexts with a command which moves the tails in LRCs for us. We really don't need to bake any of this into the DRM scheduler for GuC submission. Execlists is different story but I think our plan is to do the minimum possible to plum that into the DRM scheduler (e.g. leave the balanced / bonded code in the backend). Could we update the DRM scheduler to understand balanced (seems like already does to some extent) and bonded? Yes we could but IMO the ROI on that is low for Intel. The DRM scheduler is quite clean at the moment compared to our near incomprehensible execlist backend. Execlists are basically a legacy interface so pushing features which are only required for that backend to the DRM scheduler doesn't make sense to me. That being said, if this is something AMD needs in the DRM scheduler of course we can support you. Matt > Regards, > Christian. > > > > > So, to sum up, I think there's likely some good collaboration to be > > had here for everyone. :-) > > > > --Jason > > > > > > > Sure, I've done a quick PoC internally and have been able to hook this > > > > > into the DRM scheduler. > > > > > > > > > > Basically each BB still maps to a single job as each job is somewhat > > > > > unique (e.g. each job has its own ring, lrc, seqno, etc...). However > > > > > all > > > > > the
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Move LMEM (VRAM) management over to TTM (rev3)
== Series Details == Series: drm/i915: Move LMEM (VRAM) management over to TTM (rev3) URL : https://patchwork.freedesktop.org/series/90022/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Move LMEM (VRAM) management over to TTM (rev3)
== Series Details == Series: drm/i915: Move LMEM (VRAM) management over to TTM (rev3) URL : https://patchwork.freedesktop.org/series/90022/ State : warning == Summary == $ dim checkpatch origin/drm-tip 1bf39c8cd594 drm/i915: Untangle the vma pages_mutex 650181499469 drm/i915: Don't free shared locks while shared e0cd60e6a0d3 drm/i915: Fix i915_sg_page_sizes to record dma segments rather than physical pages 4f895c63cc41 drm/i915/ttm Initialize the ttm device and memory managers -:480: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #480: deleted file mode 100644 total: 0 errors, 1 warnings, 0 checks, 1578 lines checked fbd2191fd254 drm/i915/ttm: Embed a ttm buffer object in the i915 gem object 67e58a6747b0 drm/ttm: Add a generic TTM memcpy move for page-based iomem -:383: CHECK:ARCH_DEFINES: architecture specific defines should be avoided #383: FILE: drivers/gpu/drm/ttm/ttm_module.c:56: +#if defined(__i386__) || defined(__x86_64__) -:699: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #699: new file mode 100644 total: 0 errors, 1 warnings, 1 checks, 812 lines checked fa7a4164f770 drm, drm/i915: Move the memcpy_from_wc functionality to core drm -:54: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #54: rename from drivers/gpu/drm/i915/i915_memcpy.c total: 0 errors, 1 warnings, 0 checks, 410 lines checked 533ef0911275 drm/ttm: Use drm_memcpy_from_wc_dbm for TTM bo moves 655c519cecf1 drm/ttm: Document and optimize ttm_bo_pipeline_gutting() 2f38e8009d75 drm/ttm, drm/amdgpu: Allow the driver some control over swapping 356c346230f1 drm/i915/ttm: Introduce a TTM i915 gem object backend -:449: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #449: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 1024 lines checked 7ced8a9675bb drm/i915/lmem: Verify checks for lmem residency ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 12/12] drm/i915/lmem: Verify checks for lmem residency
Since objects can be migrated or evicted when not pinned or locked,
update the checks for lmem residency or future residency so that
the value returned is not immediately stale.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2: Simplify i915_gem_object_migratable() (Reported by Mattew Auld)
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 42 +++-
drivers/gpu/drm/i915/gem/i915_gem_object.c | 18 +
drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 ++
4 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index de1f13d203b5..b95def2d5af3 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11615,7 +11615,7 @@ intel_user_framebuffer_create(struct drm_device *dev,
/* object is backed with LMEM for discrete */
i915 = to_i915(obj->base.dev);
- if (HAS_LMEM(i915) && !i915_gem_object_is_lmem(obj)) {
+ if (HAS_LMEM(i915) && !i915_gem_object_validates_to_lmem(obj)) {
/* object is "remote", not in local memory */
i915_gem_object_put(obj);
return ERR_PTR(-EREMOTE);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index 2b8cd15de1d9..d539dffa1554 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -23,10 +23,50 @@ i915_gem_object_lmem_io_map(struct drm_i915_gem_object *obj,
return io_mapping_map_wc(>mm.region->iomap, offset, size);
}
+/**
+ * i915_gem_object_validates_to_lmem - Whether the object is resident in
+ * lmem when pages are present.
+ * @obj: The object to check.
+ *
+ * Migratable objects residency may change from under us if the object is
+ * not pinned or locked. This function is intended to be used to check whether
+ * the object can only reside in lmem when pages are present.
+ *
+ * Return: Whether the object is always resident in lmem when pages are
+ * present.
+ */
+bool i915_gem_object_validates_to_lmem(struct drm_i915_gem_object *obj)
+{
+ struct intel_memory_region *mr = READ_ONCE(obj->mm.region);
+
+ return !i915_gem_object_migratable(obj) &&
+ mr && (mr->type == INTEL_MEMORY_LOCAL ||
+ mr->type == INTEL_MEMORY_STOLEN_LOCAL);
+}
+
+/**
+ * i915_gem_object_is_lmem - Whether the object is resident in
+ * lmem
+ * @obj: The object to check.
+ *
+ * Even if an object is allowed to migrate and change memory region,
+ * this function checks whether it will always be present in lmem when
+ * valid *or* if that's not the case, whether it's currently resident in lmem.
+ * For migratable and evictable objects, the latter only makes sense when
+ * the object is locked.
+ *
+ * Return: Whether the object migratable but resident in lmem, or not
+ * migratable and will be present in lmem when valid.
+ */
bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj)
{
- struct intel_memory_region *mr = obj->mm.region;
+ struct intel_memory_region *mr = READ_ONCE(obj->mm.region);
+#ifdef CONFIG_LOCKDEP
+ if (i915_gem_object_migratable(obj) &&
+ i915_gem_object_evictable(obj))
+ assert_object_held(obj);
+#endif
return mr && (mr->type == INTEL_MEMORY_LOCAL ||
mr->type == INTEL_MEMORY_STOLEN_LOCAL);
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index df2b4e6b9bcc..c8bb6fb1dba3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -458,6 +458,24 @@ bool i915_gem_object_evictable(struct drm_i915_gem_object
*obj)
return pin_count == 0;
}
+/**
+ * i915_gem_object_migratable - Whether the object is migratable out of the
+ * current region.
+ * @obj: Pointer to the object.
+ *
+ * Return: Whether the object is allowed to be resident in other
+ * regions than the current while pages are present.
+ */
+bool i915_gem_object_migratable(struct drm_i915_gem_object *obj)
+{
+ struct intel_memory_region *mr = READ_ONCE(obj->mm.region);
+
+ if (!mr)
+ return false;
+
+ return obj->mm.n_placements > 1;
+}
+
void i915_gem_init__objects(struct drm_i915_private *i915)
{
INIT_WORK(>mm.free_work, __i915_gem_free_work);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index ae5930e307d5..a3ad8cf4eefd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -596,6 +596,10 @@ void __i915_gem_free_object(struct drm_i915_gem_object
*obj);
bool i915_gem_object_evictable(struct drm_i915_gem_object *obj);
+bool i915_gem_object_migratable(struct drm_i915_gem_object *obj);
+
+bool
[Intel-gfx] [PATCH v3 10/12] drm/ttm, drm/amdgpu: Allow the driver some control over swapping
We are calling the eviction_valuable driver callback at eviction time to
determine whether we actually can evict a buffer object.
The upcoming i915 TTM backend needs the same functionality for swapout,
and that might actually be beneficial to other drivers as well.
Add an eviction_valuable call also in the swapout path. Try to keep the
current behaviour for all drivers by returning true if the buffer object
is already in the TTM_PL_SYSTEM placement. We change behaviour for the
case where a buffer object is in a TT backed placement when swapped out,
in which case the drivers normal eviction_valuable path is run.
Finally make sure we don't try to swapout a bo that was recently purged
and therefore unpopulated.
Reviewed-by: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Thomas Hellström
---
v3:
- Don't export ttm_tt_unpopulate
- Fix confusion reading the locked pointer instead of the value
pointed to in ttm_bo_evict_swapout_allowable (Reported by
Maarten Lankhorst)
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 +++
drivers/gpu/drm/ttm/ttm_bo.c| 43 -
drivers/gpu/drm/ttm/ttm_tt.c| 3 ++
3 files changed, 34 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 8c7ec09eb1a4..d5a9d7a88315 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1399,6 +1399,10 @@ static bool amdgpu_ttm_bo_eviction_valuable(struct
ttm_buffer_object *bo,
struct dma_fence *f;
int i;
+ /* Swapout? */
+ if (bo->mem.mem_type == TTM_PL_SYSTEM)
+ return true;
+
if (bo->type == ttm_bo_type_kernel &&
!amdgpu_vm_evictable(ttm_to_amdgpu_bo(bo)))
return false;
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index a8fa3375b8aa..f45486837b44 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -536,6 +536,10 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
const struct ttm_place *place)
{
+ dma_resv_assert_held(bo->base.resv);
+ if (bo->mem.mem_type == TTM_PL_SYSTEM)
+ return true;
+
/* Don't evict this BO if it's outside of the
* requested placement range
*/
@@ -558,7 +562,9 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
* b. Otherwise, trylock it.
*/
static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
- struct ttm_operation_ctx *ctx, bool *locked, bool *busy)
+ struct ttm_operation_ctx *ctx,
+ const struct ttm_place *place,
+ bool *locked, bool *busy)
{
bool ret = false;
@@ -576,6 +582,14 @@ static bool ttm_bo_evict_swapout_allowable(struct
ttm_buffer_object *bo,
*busy = !ret;
}
+ if (ret && place && !bo->bdev->funcs->eviction_valuable(bo, place)) {
+ ret = false;
+ if (*locked) {
+ dma_resv_unlock(bo->base.resv);
+ *locked = false;
+ }
+ }
+
return ret;
}
@@ -630,20 +644,14 @@ int ttm_mem_evict_first(struct ttm_device *bdev,
list_for_each_entry(bo, >lru[i], lru) {
bool busy;
- if (!ttm_bo_evict_swapout_allowable(bo, ctx, ,
- )) {
+ if (!ttm_bo_evict_swapout_allowable(bo, ctx, place,
+ , )) {
if (busy && !busy_bo && ticket !=
dma_resv_locking_ctx(bo->base.resv))
busy_bo = bo;
continue;
}
- if (place && !bdev->funcs->eviction_valuable(bo,
- place)) {
- if (locked)
- dma_resv_unlock(bo->base.resv);
- continue;
- }
if (!ttm_bo_get_unless_zero(bo)) {
if (locked)
dma_resv_unlock(bo->base.resv);
@@ -1138,10 +1146,18 @@ EXPORT_SYMBOL(ttm_bo_wait);
int ttm_bo_swapout(struct ttm_buffer_object *bo, struct ttm_operation_ctx *ctx,
gfp_t gfp_flags)
{
+ struct ttm_place place = {};
bool locked;
int ret;
- if (!ttm_bo_evict_swapout_allowable(bo, ctx, , NULL))
+ /*
+* While the bo may already reside in SYSTEM placement, set
+* SYSTEM as
[Intel-gfx] [PATCH v3 08/12] drm/ttm: Use drm_memcpy_from_wc_dbm for TTM bo moves
Use fast wc memcpy for reading out of wc memory for TTM bo moves.
Cc: Dave Airlie
Cc: Christian König
Cc: Daniel Vetter
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 912cbe8e60a2..4a7d3d672f9a 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -31,6 +31,7 @@
#include
#include
+#include
#include
#include
#include
@@ -91,6 +92,7 @@ void ttm_move_memcpy(struct ttm_buffer_object *bo,
const struct ttm_kmap_iter_ops *src_ops = src_iter->ops;
struct ttm_tt *ttm = bo->ttm;
struct dma_buf_map src_map, dst_map;
+ bool wc_memcpy;
pgoff_t i;
/* Single TTM move. NOP */
@@ -114,11 +116,16 @@ void ttm_move_memcpy(struct ttm_buffer_object *bo,
return;
}
+ wc_memcpy = ((!src_ops->maps_tt || ttm->caching != ttm_cached) &&
+drm_has_memcpy_from_wc());
+
for (i = 0; i < dst_mem->num_pages; ++i) {
dst_ops->map_local(dst_iter, _map, i);
src_ops->map_local(src_iter, _map, i);
- if (!src_map.is_iomem && !dst_map.is_iomem) {
+ if (wc_memcpy) {
+ drm_memcpy_from_wc_dbm(_map, _map, PAGE_SIZE);
+ } else if (!src_map.is_iomem && !dst_map.is_iomem) {
memcpy(dst_map.vaddr, src_map.vaddr, PAGE_SIZE);
} else if (!src_map.is_iomem) {
dma_buf_map_memcpy_to(_map, src_map.vaddr,
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 11/12] drm/i915/ttm: Introduce a TTM i915 gem object backend
Most logical place to introduce TTM buffer objects is as an i915
gem object backend. We need to add some ops to account for added
functionality like delayed delete and LRU list manipulation.
Initially we support only LMEM and SYSTEM memory, but SYSTEM
(which in this case means evicted LMEM objects) is not
visible to i915 GEM yet. The plan is to move the i915 gem system region
over to the TTM system memory type in upcoming patches.
We set up GPU bindings directly both from LMEM and from the system region,
as there is no need to use the legacy TTM_TT memory type. We reserve
that for future porting of GGTT bindings to TTM.
Remove the old lmem backend.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2:
- Break out needed TTM functionality to a separate patch (Reported by
Christian König).
- Fix an unhandled error (Reported by Matthew Auld and Maarten Lankhorst)
- Remove a stray leftover sg_table allocation (Reported by Matthew Auld)
- Use ttm_tt_unpopulate() rather than ttm_tt_destroy() in the purge path
as some TTM functionality relies on having a ttm_tt present for !is_iomem.
v3:
- Use ttm_bo_type_device for userspace visible objects so that TTM can
allocate an address space offset for mmap'ing.
- Fix up the destruction path (Reported by Matthew Auld)
- Use ttm_bo_validate() for purging (Reported by Christian König)
- Create ttm_tts write-combined as they are currently for eviction only and
we want to maintain consistent write-combined caching for bos that are
not in system only. (Suggested by Daniel Vetter)
- Make struct ttm_placements static.
- Add the ttm device funcs/ops to i915_gem_ttm.h for the region code.
- Rename new->dst and old->src. Check for swapin in the move callback.
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_create.c| 9 +-
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 84 ---
drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 5 -
drivers/gpu/drm/i915/gem/i915_gem_object.c| 125 +++--
drivers/gpu/drm/i915/gem/i915_gem_object.h| 9 +
.../gpu/drm/i915/gem/i915_gem_object_types.h | 27 +-
drivers/gpu/drm/i915/gem/i915_gem_region.c| 6 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 531 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 50 ++
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 3 +-
drivers/gpu/drm/i915/i915_gem.c | 5 +-
drivers/gpu/drm/i915/intel_memory_region.c| 1 -
drivers/gpu/drm/i915/intel_memory_region.h| 1 -
drivers/gpu/drm/i915/intel_region_ttm.c | 6 +-
drivers/gpu/drm/i915/intel_region_ttm.h | 8 +-
16 files changed, 717 insertions(+), 154 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm.c
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 998606b7f49f..2022e763f8f7 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -154,6 +154,7 @@ gem-y += \
gem/i915_gem_stolen.o \
gem/i915_gem_throttle.o \
gem/i915_gem_tiling.o \
+ gem/i915_gem_ttm.o \
gem/i915_gem_userptr.o \
gem/i915_gem_wait.o \
gem/i915_gemfs.o
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 548ddf39d853..93bf63bbaff1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -85,13 +85,10 @@ i915_gem_setup(struct drm_i915_gem_object *obj, u64 size)
return -E2BIG;
/*
-* For now resort to CPU based clearing for device local-memory, in the
-* near future this will use the blitter engine for accelerated, GPU
-* based clearing.
+* I915_BO_ALLOC_USER will make sure the object is cleared before
+* any user access.
*/
- flags = 0;
- if (mr->type == INTEL_MEMORY_LOCAL)
- flags = I915_BO_ALLOC_CPU_CLEAR;
+ flags = I915_BO_ALLOC_USER;
ret = mr->ops->init_object(mr, obj, size, flags);
if (ret)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index 3b4aa28a076d..2b8cd15de1d9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -4,74 +4,10 @@
*/
#include "intel_memory_region.h"
-#include "intel_region_ttm.h"
#include "gem/i915_gem_region.h"
#include "gem/i915_gem_lmem.h"
#include "i915_drv.h"
-static void lmem_put_pages(struct drm_i915_gem_object *obj,
- struct sg_table *pages)
-{
- intel_region_ttm_node_free(obj->mm.region, obj->mm.st_mm_node);
- obj->mm.dirty = false;
- sg_free_table(pages);
- kfree(pages);
-}
-
-static int lmem_get_pages(struct drm_i915_gem_object *obj)
-{
- unsigned int flags;
- struct sg_table *pages;
-
- flags =
[Intel-gfx] [PATCH v3 09/12] drm/ttm: Document and optimize ttm_bo_pipeline_gutting()
If the bo is idle when calling ttm_bo_pipeline_gutting(), we unnecessarily
create a ghost object and push it out to delayed destroy.
Fix this by adding a path for idle, and document the function.
Also avoid having the bo end up in a bad state vulnerable to user-space
triggered kernel BUGs if the call to ttm_tt_create() fails.
Finally reuse ttm_bo_pipeline_gutting() in ttm_bo_evict().
Cc: Christian König
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_bo.c | 20 ++--
drivers/gpu/drm/ttm/ttm_bo_util.c | 52 ---
drivers/gpu/drm/ttm/ttm_tt.c | 5 +++
include/drm/ttm/ttm_tt.h | 10 ++
4 files changed, 73 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index ca1b098b6a56..a8fa3375b8aa 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -501,10 +501,15 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
bdev->funcs->evict_flags(bo, );
if (!placement.num_placement && !placement.num_busy_placement) {
- ttm_bo_wait(bo, false, false);
+ ret = ttm_bo_wait(bo, true, false);
+ if (ret)
+ return ret;
- ttm_bo_cleanup_memtype_use(bo);
- return ttm_tt_create(bo, false);
+ /*
+* Since we've already synced, this frees backing store
+* immediately.
+*/
+ return ttm_bo_pipeline_gutting(bo);
}
ret = ttm_bo_mem_space(bo, , _mem, ctx);
@@ -974,13 +979,8 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
/*
* Remove the backing store if no placement is given.
*/
- if (!placement->num_placement && !placement->num_busy_placement) {
- ret = ttm_bo_pipeline_gutting(bo);
- if (ret)
- return ret;
-
- return ttm_tt_create(bo, false);
- }
+ if (!placement->num_placement && !placement->num_busy_placement)
+ return ttm_bo_pipeline_gutting(bo);
/*
* Check whether we need to move buffer.
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 4a7d3d672f9a..7fa9b3a852eb 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -585,26 +585,70 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object
*bo,
}
EXPORT_SYMBOL(ttm_bo_move_accel_cleanup);
+/**
+ * ttm_bo_pipeline_gutting - purge the contents of a bo
+ * @bo: The buffer object
+ *
+ * Purge the contents of a bo, async if the bo is not idle.
+ * After a successful call, the bo is left unpopulated in
+ * system placement. The function may wait uninterruptible
+ * for idle on OOM.
+ *
+ * Return: 0 if successful, negative error code on failure.
+ */
int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
{
static const struct ttm_place sys_mem = { .mem_type = TTM_PL_SYSTEM };
struct ttm_buffer_object *ghost;
+ struct ttm_tt *ttm;
int ret;
- ret = ttm_buffer_object_transfer(bo, );
+ /* If already idle, no need for ghost object dance. */
+ ret = ttm_bo_wait(bo, false, true);
+ if (ret != -EBUSY) {
+ if (!bo->ttm) {
+ ret = ttm_tt_create(bo, true);
+ if (ret)
+ return ret;
+ } else {
+ ttm_tt_unpopulate(bo->bdev, bo->ttm);
+ if (bo->type == ttm_bo_type_device)
+ ttm_tt_mark_for_clear(bo->ttm);
+ }
+ ttm_resource_free(bo, >mem);
+ ttm_resource_alloc(bo, _mem, >mem);
+
+ return 0;
+ }
+
+ /*
+* We need an unpopulated ttm_tt after giving our current one,
+* if any, to the ghost object. And we can't afford to fail
+* creating one *after* the operation.
+*/
+
+ ttm = bo->ttm;
+ bo->ttm = NULL;
+ ret = ttm_tt_create(bo, true);
+ swap(bo->ttm, ttm);
if (ret)
return ret;
+ ret = ttm_buffer_object_transfer(bo, );
+ if (ret) {
+ ttm_tt_destroy(bo->bdev, ttm);
+ return ret;
+ }
+
ret = dma_resv_copy_fences(>base._resv, bo->base.resv);
/* Last resort, wait for the BO to be idle when we are OOM */
if (ret)
ttm_bo_wait(bo, false, false);
- ttm_resource_alloc(bo, _mem, >mem);
- bo->ttm = NULL;
-
dma_resv_unlock(>base._resv);
ttm_bo_put(ghost);
+ bo->ttm = ttm;
+ ttm_resource_alloc(bo, _mem, >mem);
return 0;
}
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 0e41227116b1..913b330a234b 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -134,6 +134,11 @@ void
[Intel-gfx] [PATCH v3 04/12] drm/i915/ttm Initialize the ttm device and memory managers
Temporarily remove the buddy allocator and related selftests
and hook up the TTM range manager for i915 regions.
Also modify the mock region selftests somewhat to account for a
fragmenting manager.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld #v2
---
v2:
- Fix an error unwind in lmem_get_pages() (Reported by Matthew Auld)
- Break out and modify usage of i915_sg_dma_sizes() (Reported by Mattew Auld)
- Break out TTM changes to a separate patch (Reported by Christian König)
v3:
- Fix the same error unwind in mock_region_get_pages()
(Reported by Matthew Auld)
- Don't rely on new TTM functionality, but create a mock TTM device,
(Reported by Christian König)
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/Makefile | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 59 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 6 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_region.c| 120 ---
drivers/gpu/drm/i915/gem/i915_gem_region.h| 4 -
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 4 +-
drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 10 +-
drivers/gpu/drm/i915/gem/i915_gem_stolen.h| 9 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 2 -
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 27 +-
drivers/gpu/drm/i915/i915_buddy.c | 435 --
drivers/gpu/drm/i915/i915_buddy.h | 131 ---
drivers/gpu/drm/i915/i915_drv.c | 8 +
drivers/gpu/drm/i915/i915_drv.h | 7 +-
drivers/gpu/drm/i915/i915_gem.c | 1 +
drivers/gpu/drm/i915/i915_globals.c | 1 -
drivers/gpu/drm/i915/i915_globals.h | 1 -
drivers/gpu/drm/i915/i915_scatterlist.c | 70 ++
drivers/gpu/drm/i915/i915_scatterlist.h | 4 +
drivers/gpu/drm/i915/intel_memory_region.c| 180 ++--
drivers/gpu/drm/i915/intel_memory_region.h| 44 +-
drivers/gpu/drm/i915/intel_region_ttm.c | 334
drivers/gpu/drm/i915/intel_region_ttm.h | 38 +
drivers/gpu/drm/i915/selftests/i915_buddy.c | 789 --
.../drm/i915/selftests/i915_mock_selftests.h | 1 -
.../drm/i915/selftests/intel_memory_region.c | 133 +--
drivers/gpu/drm/i915/selftests/mock_region.c | 52 +-
29 files changed, 722 insertions(+), 1754 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/i915_buddy.c
delete mode 100644 drivers/gpu/drm/i915/i915_buddy.h
create mode 100644 drivers/gpu/drm/i915/intel_region_ttm.c
create mode 100644 drivers/gpu/drm/i915/intel_region_ttm.h
delete mode 100644 drivers/gpu/drm/i915/selftests/i915_buddy.c
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 1e1cb245fca7..b63d374dff23 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -26,6 +26,7 @@ config DRM_I915
select SND_HDA_I915 if SND_HDA_CORE
select CEC_CORE if CEC_NOTIFIER
select VMAP_PFN
+ select DRM_TTM
help
Choose this option if you have a system that has "Intel Graphics
Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d0d936d9137b..cb8823570996 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -50,6 +50,7 @@ i915-y += i915_drv.o \
intel_memory_region.o \
intel_pch.o \
intel_pm.o \
+ intel_region_ttm.o \
intel_runtime_pm.o \
intel_sideband.o \
intel_step.o \
@@ -160,7 +161,6 @@ gem-y += \
i915-y += \
$(gem-y) \
i915_active.o \
- i915_buddy.o \
i915_cmd_parser.o \
i915_gem_evict.o \
i915_gem_gtt.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index f44bdd08f7cb..3b4aa28a076d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -4,16 +4,71 @@
*/
#include "intel_memory_region.h"
+#include "intel_region_ttm.h"
#include "gem/i915_gem_region.h"
#include "gem/i915_gem_lmem.h"
#include "i915_drv.h"
+static void lmem_put_pages(struct drm_i915_gem_object *obj,
+ struct sg_table *pages)
+{
+ intel_region_ttm_node_free(obj->mm.region, obj->mm.st_mm_node);
+ obj->mm.dirty = false;
+ sg_free_table(pages);
+ kfree(pages);
+}
+
+static int lmem_get_pages(struct drm_i915_gem_object *obj)
+{
+ unsigned int flags;
+ struct sg_table *pages;
+
+ flags = I915_ALLOC_MIN_PAGE_SIZE;
+ if (obj->flags & I915_BO_ALLOC_CONTIGUOUS)
+ flags |= I915_ALLOC_CONTIGUOUS;
+
+ obj->mm.st_mm_node = intel_region_ttm_node_alloc(obj->mm.region,
+obj->base.size,
+flags);
+ if
[Intel-gfx] [PATCH v3 06/12] drm/ttm: Add a generic TTM memcpy move for page-based iomem
The internal ttm_bo_util memcpy uses ioremap functionality, and while it
probably might be possible to use it for copying in- and out of
sglist represented io memory, using io_mem_reserve() / io_mem_free()
callbacks, that would cause problems with fault().
Instead, implement a method mapping page-by-page using kmap_local()
semantics. As an additional benefit we then avoid the occasional global
TLB flushes of ioremap() and consuming ioremap space, elimination of a
critical point of failure and with a slight change of semantics we could
also push the memcpy out async for testing and async driver development
purposes.
A special linear iomem iterator is introduced internally to mimic the
old ioremap behaviour for code-paths that can't immediately be ported
over. This adds to the code size and should be considered a temporary
solution.
Looking at the code we have a lot of checks for iomap tagged pointers.
Ideally we should extend the core memremap functions to also accept
uncached memory and kmap_local functionality. Then we could strip a
lot of code.
Cc: Christian König
Signed-off-by: Thomas Hellström
---
v3:
- Split up in various TTM files and addressed review comments by
Christian König. Tested and fixed legacy iomap memcpy path on i915.
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 278 ++---
drivers/gpu/drm/ttm/ttm_module.c | 35
drivers/gpu/drm/ttm/ttm_resource.c | 166 +
drivers/gpu/drm/ttm/ttm_tt.c | 42 +
include/drm/ttm/ttm_bo_driver.h| 28 +++
include/drm/ttm/ttm_caching.h | 2 +
include/drm/ttm/ttm_kmap_iter.h| 61 +++
include/drm/ttm/ttm_resource.h | 61 +++
include/drm/ttm/ttm_tt.h | 16 ++
9 files changed, 508 insertions(+), 181 deletions(-)
create mode 100644 include/drm/ttm/ttm_kmap_iter.h
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index ae8b61460724..912cbe8e60a2 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -72,190 +72,126 @@ void ttm_mem_io_free(struct ttm_device *bdev,
mem->bus.addr = NULL;
}
-static int ttm_resource_ioremap(struct ttm_device *bdev,
- struct ttm_resource *mem,
- void **virtual)
+/**
+ * ttm_move_memcpy - Helper to perform a memcpy ttm move operation.
+ * @bo: The struct ttm_buffer_object.
+ * @new_mem: The struct ttm_resource we're moving to (copy destination).
+ * @new_iter: A struct ttm_kmap_iter representing the destination resource.
+ * @src_iter: A struct ttm_kmap_iter representing the source resource.
+ *
+ * This function is intended to be able to move out async under a
+ * dma-fence if desired.
+ */
+void ttm_move_memcpy(struct ttm_buffer_object *bo,
+struct ttm_resource *dst_mem,
+struct ttm_kmap_iter *dst_iter,
+struct ttm_kmap_iter *src_iter)
{
- int ret;
- void *addr;
-
- *virtual = NULL;
- ret = ttm_mem_io_reserve(bdev, mem);
- if (ret || !mem->bus.is_iomem)
- return ret;
+ const struct ttm_kmap_iter_ops *dst_ops = dst_iter->ops;
+ const struct ttm_kmap_iter_ops *src_ops = src_iter->ops;
+ struct ttm_tt *ttm = bo->ttm;
+ struct dma_buf_map src_map, dst_map;
+ pgoff_t i;
- if (mem->bus.addr) {
- addr = mem->bus.addr;
- } else {
- size_t bus_size = (size_t)mem->num_pages << PAGE_SHIFT;
+ /* Single TTM move. NOP */
+ if (dst_ops->maps_tt && src_ops->maps_tt)
+ return;
- if (mem->bus.caching == ttm_write_combined)
- addr = ioremap_wc(mem->bus.offset, bus_size);
-#ifdef CONFIG_X86
- else if (mem->bus.caching == ttm_cached)
- addr = ioremap_cache(mem->bus.offset, bus_size);
-#endif
- else
- addr = ioremap(mem->bus.offset, bus_size);
- if (!addr) {
- ttm_mem_io_free(bdev, mem);
- return -ENOMEM;
+ /* Don't move nonexistent data. Clear destination instead. */
+ if (src_ops->maps_tt && (!ttm || !ttm_tt_is_populated(ttm))) {
+ if (ttm && !(ttm->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC))
+ return;
+
+ for (i = 0; i < dst_mem->num_pages; ++i) {
+ dst_ops->map_local(dst_iter, _map, i);
+ if (dst_map.is_iomem)
+ memset_io(dst_map.vaddr_iomem, 0, PAGE_SIZE);
+ else
+ memset(dst_map.vaddr, 0, PAGE_SIZE);
+ if (dst_ops->unmap_local)
+ dst_ops->unmap_local(dst_iter, _map);
}
+ return;
}
- *virtual = addr;
- return 0;
-}
-
-static void ttm_resource_iounmap(struct ttm_device
[Intel-gfx] [PATCH v3 05/12] drm/i915/ttm: Embed a ttm buffer object in the i915 gem object
Embed a struct ttm_buffer_object into the i915 gem object, making sure
we alias the gem object part. It's a bit unfortunate that the
struct ttm_buffer_ojbect embeds a gem object since we otherwise could
make the TTM part private to the TTM backend, and use the usual
i915 gem object for the other backends.
To make this a bit more storage efficient for the other backends,
we'd have to use a pointer for the gem object which would require
a lot of changes in the driver. We postpone that for later.
Signed-off-by: Thomas Hellström
Acked-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 7 +++
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 12 +++-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 2be6109d0093..5706d471692d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -62,6 +62,13 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
const struct drm_i915_gem_object_ops *ops,
struct lock_class_key *key, unsigned flags)
{
+ /*
+* A gem object is embedded both in a struct ttm_buffer_object :/ and
+* in a drm_i915_gem_object. Make sure they are aliased.
+*/
+ BUILD_BUG_ON(offsetof(typeof(*obj), base) !=
+offsetof(typeof(*obj), __do_not_access.base));
+
spin_lock_init(>vma.lock);
INIT_LIST_HEAD(>vma.list);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index f5b46d11e6e6..d047ea126029 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -10,6 +10,7 @@
#include
#include
+#include
#include
#include "i915_active.h"
@@ -99,7 +100,16 @@ struct i915_gem_object_page_iter {
};
struct drm_i915_gem_object {
- struct drm_gem_object base;
+ /*
+* We might have reason to revisit the below since it wastes
+* a lot of space for non-ttm gem objects.
+* In any case, always use the accessors for the ttm_buffer_object
+* when accessing it.
+*/
+ union {
+ struct drm_gem_object base;
+ struct ttm_buffer_object __do_not_access;
+ };
const struct drm_i915_gem_object_ops *ops;
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 07/12] drm, drm/i915: Move the memcpy_from_wc functionality to core drm
Memcpy from wc will be used as well by TTM memcpy.
Move it to core drm, and make the interface do the right thing
even on !X86.
Cc: Christian König
Cc: Daniel Vetter
Cc: Dave Airlie
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_drv.c | 2 +
.../drm/{i915/i915_memcpy.c => drm_memcpy.c} | 63 ++-
drivers/gpu/drm/i915/Makefile | 1 -
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 4 +-
drivers/gpu/drm/i915/gem/i915_gem_object.c| 5 +-
drivers/gpu/drm/i915/gt/selftest_reset.c | 7 ++-
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 11 ++--
drivers/gpu/drm/i915/i915_cmd_parser.c| 4 +-
drivers/gpu/drm/i915/i915_drv.c | 2 -
drivers/gpu/drm/i915/i915_gpu_error.c | 8 +--
drivers/gpu/drm/i915/i915_memcpy.h| 34 --
.../drm/i915/selftests/intel_memory_region.c | 7 ++-
include/drm/drm_memcpy.h | 47 ++
14 files changed, 121 insertions(+), 76 deletions(-)
rename drivers/gpu/drm/{i915/i915_memcpy.c => drm_memcpy.c} (70%)
delete mode 100644 drivers/gpu/drm/i915/i915_memcpy.h
create mode 100644 include/drm/drm_memcpy.h
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index a91cc7684904..f3ab8586c3d7 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,7 +18,7 @@ drm-y :=drm_aperture.o drm_auth.o drm_cache.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o \
- drm_managed.o drm_vblank_work.o
+ drm_managed.o drm_vblank_work.o drm_memcpy.o \
drm-$(CONFIG_DRM_LEGACY) += drm_agpsupport.o drm_bufs.o drm_context.o
drm_dma.o \
drm_legacy_misc.o drm_lock.o drm_memory.o
drm_scatter.o \
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 3d8d68a98b95..351cc2900cf1 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1041,6 +1042,7 @@ static int __init drm_core_init(void)
drm_connector_ida_init();
idr_init(_minors_idr);
+ drm_memcpy_init_early();
ret = drm_sysfs_init();
if (ret < 0) {
diff --git a/drivers/gpu/drm/i915/i915_memcpy.c b/drivers/gpu/drm/drm_memcpy.c
similarity index 70%
rename from drivers/gpu/drm/i915/i915_memcpy.c
rename to drivers/gpu/drm/drm_memcpy.c
index 1b021a4902de..740377749caa 100644
--- a/drivers/gpu/drm/i915/i915_memcpy.c
+++ b/drivers/gpu/drm/drm_memcpy.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: MIT
/*
* Copyright © 2016 Intel Corporation
*
@@ -22,16 +23,12 @@
*
*/
+#ifdef CONFIG_X86
+#include
#include
#include
-#include "i915_memcpy.h"
-
-#if IS_ENABLED(CONFIG_DRM_I915_DEBUG)
-#define CI_BUG_ON(expr) BUG_ON(expr)
-#else
-#define CI_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
-#endif
+#include "drm/drm_memcpy.h"
static DEFINE_STATIC_KEY_FALSE(has_movntdqa);
@@ -94,23 +91,24 @@ static void __memcpy_ntdqu(void *dst, const void *src,
unsigned long len)
}
/**
- * i915_memcpy_from_wc: perform an accelerated *aligned* read from WC
+ * drm_memcpy_from_wc: perform an accelerated *aligned* read from WC
* @dst: destination pointer
* @src: source pointer
* @len: how many bytes to copy
*
- * i915_memcpy_from_wc copies @len bytes from @src to @dst using
+ * drm_memcpy_from_wc copies @len bytes from @src to @dst using
* non-temporal instructions where available. Note that all arguments
* (@src, @dst) must be aligned to 16 bytes and @len must be a multiple
* of 16.
*
* To test whether accelerated reads from WC are supported, use
- * i915_memcpy_from_wc(NULL, NULL, 0);
+ * drm_memcpy_from_wc(NULL, NULL, 0);
+ * This interface is intended for memremapped memory without the __iomem tag.
*
* Returns true if the copy was successful, false if the preconditions
* are not met.
*/
-bool i915_memcpy_from_wc(void *dst, const void *src, unsigned long len)
+bool drm_memcpy_from_wc(void *dst, const void *src, unsigned long len)
{
if (unlikely(((unsigned long)dst | (unsigned long)src | len) & 15))
return false;
@@ -123,24 +121,53 @@ bool i915_memcpy_from_wc(void *dst, const void *src,
unsigned long len)
return false;
}
+EXPORT_SYMBOL(drm_memcpy_from_wc);
/**
- * i915_unaligned_memcpy_from_wc: perform a mostly accelerated read from WC
+ * drm_memcpy_from_wc_dbm: perform an accelerated *aligned* read from WC with
+ * struct dma_buf_map arguments.
+ * @dst: destination map
+ * @src: source map
+ * @len: how many bytes to copy
+ *
+ * This is identical to drm_memcpy_from_wc, except it's intended for
+ * potentially ioremapped memory rather than memremapped memory.
+ *
+ * Returns
[Intel-gfx] [PATCH v3 03/12] drm/i915: Fix i915_sg_page_sizes to record dma segments rather than physical pages
All users of this function actually want the dma segment sizes, but that's
not what's calculated. Fix that and rename the function to
i915_sg_dma_sizes to reflect what's calculated.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_phys.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +-
drivers/gpu/drm/i915/i915_scatterlist.h | 16
4 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index ccede73c6465..616c3a2f1baf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -209,7 +209,7 @@ static int i915_gem_object_get_pages_dmabuf(struct
drm_i915_gem_object *obj)
if (IS_ERR(pages))
return PTR_ERR(pages);
- sg_page_sizes = i915_sg_page_sizes(pages->sgl);
+ sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
__i915_gem_object_set_pages(obj, pages, sg_page_sizes);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
index 81dc2bf59bc3..36f373dc493c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
@@ -208,7 +208,7 @@ static int i915_gem_object_shmem_to_phys(struct
drm_i915_gem_object *obj)
err_xfer:
if (!IS_ERR_OR_NULL(pages)) {
- unsigned int sg_page_sizes = i915_sg_page_sizes(pages->sgl);
+ unsigned int sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
__i915_gem_object_set_pages(obj, pages, sg_page_sizes);
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index a657b99ec760..602f0ed983ec 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -173,7 +173,7 @@ static int i915_gem_userptr_get_pages(struct
drm_i915_gem_object *obj)
goto err;
}
- sg_page_sizes = i915_sg_page_sizes(st->sgl);
+ sg_page_sizes = i915_sg_dma_sizes(st->sgl);
__i915_gem_object_set_pages(obj, st, sg_page_sizes);
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h
b/drivers/gpu/drm/i915/i915_scatterlist.h
index 9cb26a224034..b96baad66a3a 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.h
+++ b/drivers/gpu/drm/i915/i915_scatterlist.h
@@ -101,15 +101,23 @@ static inline struct scatterlist *__sg_next(struct
scatterlist *sg)
(((__iter).curr += PAGE_SIZE) >= (__iter).max) ? \
(__iter) = __sgt_iter(__sg_next((__iter).sgp), false), 0 : 0)
-static inline unsigned int i915_sg_page_sizes(struct scatterlist *sg)
+/**
+ * i915_sg_dma_sizes - Record the dma segment sizes of a scatterlist
+ * @sg: The scatterlist
+ *
+ * Return: An unsigned int with segment sizes logically or'ed together.
+ * A caller can use this information to determine what hardware page table
+ * entry sizes can be used to map the memory represented by the scatterlist.
+ */
+static inline unsigned int i915_sg_dma_sizes(struct scatterlist *sg)
{
unsigned int page_sizes;
page_sizes = 0;
- while (sg) {
+ while (sg && sg_dma_len(sg)) {
GEM_BUG_ON(sg->offset);
- GEM_BUG_ON(!IS_ALIGNED(sg->length, PAGE_SIZE));
- page_sizes |= sg->length;
+ GEM_BUG_ON(!IS_ALIGNED(sg_dma_len(sg), PAGE_SIZE));
+ page_sizes |= sg_dma_len(sg);
sg = __sg_next(sg);
}
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 02/12] drm/i915: Don't free shared locks while shared
We are currently sharing the VM reservation locks across a number of
gem objects with page-table memory. Since TTM will individiualize the
reservation locks when freeing objects, including accessing the shared
locks, make sure that the shared locks are not freed until that is done.
For PPGTT we add an additional refcount, for GGTT we take additional
measures to make sure objects sharing the GGTT reservation lock are
freed at GGTT takedown
Signed-off-by: Thomas Hellström
Reviewed-by: Maarten Lankhorst
---
v2: Try harder to make sure objects sharing the GGTT reservation lock are
freed at GGTT takedown.
v3: Use a pointer to the vm to indicate that an object shares a reservation
object from that vm, rather than a pointer to the reservation object itself.
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 3 ++
.../gpu/drm/i915/gem/i915_gem_object_types.h | 4 ++
drivers/gpu/drm/i915/gt/intel_ggtt.c | 19 ++--
drivers/gpu/drm/i915/gt/intel_gtt.c | 45 +++
drivers/gpu/drm/i915/gt/intel_gtt.h | 28 +++-
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 5 +++
7 files changed, 93 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 28144410df86..2be6109d0093 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -252,6 +252,9 @@ static void __i915_gem_free_objects(struct drm_i915_private
*i915,
if (obj->mm.n_placements > 1)
kfree(obj->mm.placements);
+ if (obj->shares_resv_from)
+ i915_vm_resv_put(obj->shares_resv_from);
+
/* But keep the pointer alive for RCU-protected lookups */
call_rcu(>rcu, __i915_gem_free_object_rcu);
cond_resched();
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 0727d0c76aa0..0415f99b6b95 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -149,6 +149,10 @@ struct drm_i915_gem_object {
* when i915_gem_ww_ctx_backoff() or i915_gem_ww_ctx_fini() are called.
*/
struct list_head obj_link;
+ /**
+* @shared_resv_from: The object shares the resv from this vm.
+*/
+ struct i915_address_space *shares_resv_from;
union {
struct rcu_head rcu;
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 35069ca5d7de..10c23a749a95 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -746,7 +746,6 @@ static void ggtt_cleanup_hw(struct i915_ggtt *ggtt)
mutex_unlock(>vm.mutex);
i915_address_space_fini(>vm);
- dma_resv_fini(>vm.resv);
arch_phys_wc_del(ggtt->mtrr);
@@ -768,6 +767,19 @@ void i915_ggtt_driver_release(struct drm_i915_private
*i915)
ggtt_cleanup_hw(ggtt);
}
+/**
+ * i915_ggtt_driver_late_release - Cleanup of GGTT that needs to be done after
+ * all free objects have been drained.
+ * @i915: i915 device
+ */
+void i915_ggtt_driver_late_release(struct drm_i915_private *i915)
+{
+ struct i915_ggtt *ggtt = >ggtt;
+
+ GEM_WARN_ON(kref_read(>vm.resv_ref) != 1);
+ dma_resv_fini(>vm._resv);
+}
+
static unsigned int gen6_get_total_gtt_size(u16 snb_gmch_ctl)
{
snb_gmch_ctl >>= SNB_GMCH_GGMS_SHIFT;
@@ -829,6 +841,7 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64
size)
return -ENOMEM;
}
+ kref_init(>vm.resv_ref);
ret = setup_scratch_page(>vm);
if (ret) {
drm_err(>drm, "Scratch setup failed\n");
@@ -1135,7 +1148,7 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct
intel_gt *gt)
ggtt->vm.gt = gt;
ggtt->vm.i915 = i915;
ggtt->vm.dma = i915->drm.dev;
- dma_resv_init(>vm.resv);
+ dma_resv_init(>vm._resv);
if (INTEL_GEN(i915) <= 5)
ret = i915_gmch_probe(ggtt);
@@ -1144,7 +1157,7 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct
intel_gt *gt)
else
ret = gen8_gmch_probe(ggtt);
if (ret) {
- dma_resv_fini(>vm.resv);
+ dma_resv_fini(>vm._resv);
return ret;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 9b98f9d9faa3..94849567143d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -22,8 +22,11 @@ struct drm_i915_gem_object *alloc_pt_lmem(struct
i915_address_space *vm, int sz)
* object underneath, with the idea that one object_lock() will lock
* them all at once.
*/
- if (!IS_ERR(obj))
-
[Intel-gfx] [PATCH v3 01/12] drm/i915: Untangle the vma pages_mutex
Any sleeping dma_resv lock taken while the vma pages_mutex is held
will cause a lockdep splat.
Move the i915_gem_object_pin_pages() call out of the pages_mutex
critical section.
Signed-off-by: Thomas Hellström
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_vma.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index a6cd0fa62847..f2b5912fc542 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -800,32 +800,37 @@ static bool try_qad_pin(struct i915_vma *vma, unsigned
int flags)
static int vma_get_pages(struct i915_vma *vma)
{
int err = 0;
+ bool pinned_pages = false;
if (atomic_add_unless(>pages_count, 1, 0))
return 0;
+ if (vma->obj) {
+ err = i915_gem_object_pin_pages(vma->obj);
+ if (err)
+ return err;
+ pinned_pages = true;
+ }
+
/* Allocations ahoy! */
- if (mutex_lock_interruptible(>pages_mutex))
- return -EINTR;
+ if (mutex_lock_interruptible(>pages_mutex)) {
+ err = -EINTR;
+ goto unpin;
+ }
if (!atomic_read(>pages_count)) {
- if (vma->obj) {
- err = i915_gem_object_pin_pages(vma->obj);
- if (err)
- goto unlock;
- }
-
err = vma->ops->set_pages(vma);
- if (err) {
- if (vma->obj)
- i915_gem_object_unpin_pages(vma->obj);
+ if (err)
goto unlock;
- }
+ pinned_pages = false;
}
atomic_inc(>pages_count);
unlock:
mutex_unlock(>pages_mutex);
+unpin:
+ if (pinned_pages)
+ __i915_gem_object_unpin_pages(vma->obj);
return err;
}
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 00/12] drm/i915: Move LMEM (VRAM) management over to TTM
This is an initial patch series to move discrete memory management over to
TTM. It will be followed up shortly with adding more functionality.
The buddy allocator is temporarily removed along with its selftests and
It is replaced with the TTM range manager and some selftests are adjusted
to account for introduced fragmentation. Work is ongoing to reintroduce the
buddy allocator as a TTM resource manager.
A new memcpy ttm move is introduced that uses kmap_local() functionality
rather than vmap(). Among other things stated in the patch commit message
it helps us deal with page-pased LMEM memory. It is generic enough to replace
the ttm memcpy move with some additional work if so desired. On x86 it also
enables prefetching reads from write-combined memory.
Finally the old i915 gem object LMEM backend is replaced with a
i915 gem object TTM backend and some additional i915 gem object ops are
introduced to support the added functionality.
Currently it is used only to support management and eviction of the LMEM
region, but work is underway to extend the support to system memory. In this
way we use TTM the way it was originally intended, having the GPU binding
taken care of by driver code.
Intention is to follow up with
- System memory support
- Pipelined accelerated moves / migration
- Re-added buddy allocator in the TTM framework
v2:
- Add patches to move pagefaulting over to TTM
- Break out TTM changes to separate patches
- Address various review comments as detailed in the affected patches
v3:
- Drop TTM pagefaulting patches for now due changing approach due to a NAK.
- Address feedback on TTM patches
- Move the new TTM memcpy functionality into TTM.
- Move fast WC memcpy to drm
- Various fixes all over the place as shown in patch commit messages.
Cc: Christian König
Thomas Hellström (12):
drm/i915: Untangle the vma pages_mutex
drm/i915: Don't free shared locks while shared
drm/i915: Fix i915_sg_page_sizes to record dma segments rather than
physical pages
drm/i915/ttm Initialize the ttm device and memory managers
drm/i915/ttm: Embed a ttm buffer object in the i915 gem object
drm/ttm: Add a generic TTM memcpy move for page-based iomem
drm, drm/i915: Move the memcpy_from_wc functionality to core drm
drm/ttm: Use drm_memcpy_from_wc_dbm for TTM bo moves
drm/ttm: Document and optimize ttm_bo_pipeline_gutting()
drm/ttm, drm/amdgpu: Allow the driver some control over swapping
drm/i915/ttm: Introduce a TTM i915 gem object backend
drm/i915/lmem: Verify checks for lmem residency
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 +
drivers/gpu/drm/drm_drv.c | 2 +
.../drm/{i915/i915_memcpy.c => drm_memcpy.c} | 63 +-
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/Makefile | 4 +-
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_create.c| 9 +-
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 2 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 4 +-
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 71 +-
drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 5 -
drivers/gpu/drm/i915/gem/i915_gem_object.c| 154 +++-
drivers/gpu/drm/i915/gem/i915_gem_object.h| 13 +
.../gpu/drm/i915/gem/i915_gem_object_types.h | 49 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_region.c| 126 +--
drivers/gpu/drm/i915/gem/i915_gem_region.h| 4 -
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 4 +-
drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 10 +-
drivers/gpu/drm/i915/gem/i915_gem_stolen.h| 9 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 531
drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 50 ++
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 19 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 2 -
drivers/gpu/drm/i915/gt/intel_gtt.c | 45 +-
drivers/gpu/drm/i915/gt/intel_gtt.h | 28 +-
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 30 +-
drivers/gpu/drm/i915/gt/selftest_reset.c | 7 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 11 +-
drivers/gpu/drm/i915/i915_buddy.c | 435 --
drivers/gpu/drm/i915/i915_buddy.h | 131 ---
drivers/gpu/drm/i915/i915_cmd_parser.c| 4 +-
drivers/gpu/drm/i915/i915_drv.c | 15 +-
drivers/gpu/drm/i915/i915_drv.h | 7 +-
drivers/gpu/drm/i915/i915_gem.c | 6 +-
drivers/gpu/drm/i915/i915_globals.c | 1 -
drivers/gpu/drm/i915/i915_globals.h | 1 -
drivers/gpu/drm/i915/i915_gpu_error.c | 8 +-
drivers/gpu/drm/i915/i915_memcpy.h| 34 -
Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/display: Nuke has_infoframe
On Fri, 2021-05-14 at 16:22 -0700, José Roberto de Souza wrote: > This was only reduntant information has_hdmi_sink can do the same job. > set_infoframes() hooks will call intel_write_infoframe() for the > supported infoframes types and it will only be enabled if given type > is set in crtc_state->infoframes.enable. > > While at it also fixing the style of dig_port->set_infoframes() calls. > > Cc: Ville Syrjälä > Signed-off-by: José Roberto de Souza > --- > drivers/gpu/drm/i915/display/g4x_hdmi.c | 22 ++- > drivers/gpu/drm/i915/display/intel_ddi.c | 17 +- > drivers/gpu/drm/i915/display/intel_display.c | 6 ++--- > .../drm/i915/display/intel_display_types.h | 3 --- > drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 ++-- > drivers/gpu/drm/i915/display/intel_hdmi.c | 13 +-- > 6 files changed, 22 insertions(+), 43 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/g4x_hdmi.c > b/drivers/gpu/drm/i915/display/g4x_hdmi.c > index be352e9f0afc..f35db96e6239 100644 > --- a/drivers/gpu/drm/i915/display/g4x_hdmi.c > +++ b/drivers/gpu/drm/i915/display/g4x_hdmi.c > @@ -105,9 +105,6 @@ static void intel_hdmi_get_config(struct > intel_encoder *encoder, > pipe_config->infoframes.enable |= > intel_hdmi_infoframes_enabled(encoder, pipe_config); > > - if (pipe_config->infoframes.enable) > - pipe_config->has_infoframe = true; > - "pipe_config->infoframes.enable" is set with information about the infoframes currently active in the hardware through "pipe_config- >infoframes.enable |= intel_hdmi_infoframes_enabled(encoder, pipe_config);". Therefore, when calling set_infoframes() semantically, the has_infoframe information set by "if (pipe_config->infoframes.enable) pipe_config->has_infoframe = true;" is more clear. > if (tmp & HDMI_AUDIO_ENABLE) > pipe_config->has_audio = true; > > @@ -343,9 +340,7 @@ static void intel_disable_hdmi(struct > intel_atomic_state *state, > intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, > true); > } > > - dig_port->set_infoframes(encoder, > - false, > - old_crtc_state, old_conn_state); > + dig_port->set_infoframes(encoder, false, old_crtc_state, > old_conn_state); > > intel_dp_dual_mode_set_tmds_output(intel_hdmi, false); > } > @@ -390,9 +385,8 @@ static void intel_hdmi_pre_enable(struct > intel_atomic_state *state, > > intel_hdmi_prepare(encoder, pipe_config); > > - dig_port->set_infoframes(encoder, > - pipe_config->has_infoframe, > - pipe_config, conn_state); > + dig_port->set_infoframes(encoder, pipe_config->has_hdmi_sink, > + pipe_config, conn_state); > } > > static void vlv_hdmi_pre_enable(struct intel_atomic_state *state, > @@ -410,9 +404,8 @@ static void vlv_hdmi_pre_enable(struct > intel_atomic_state *state, > 0x2b245f5f, 0x2000, > 0x5578b83a, 0x2b247878); > > - dig_port->set_infoframes(encoder, > - pipe_config->has_infoframe, > - pipe_config, conn_state); > + dig_port->set_infoframes(encoder, pipe_config->has_hdmi_sink, > + pipe_config, conn_state); > > g4x_enable_hdmi(state, encoder, pipe_config, conn_state); > > @@ -487,9 +480,8 @@ static void chv_hdmi_pre_enable(struct > intel_atomic_state *state, > /* Use 800mV-0dB */ > chv_set_phy_signal_level(encoder, pipe_config, 128, 102, > false); > > - dig_port->set_infoframes(encoder, > - pipe_config->has_infoframe, > - pipe_config, conn_state); > + dig_port->set_infoframes(encoder, pipe_config->has_hdmi_sink, > + pipe_config, conn_state); > > g4x_enable_hdmi(state, encoder, pipe_config, conn_state); > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c > b/drivers/gpu/drm/i915/display/intel_ddi.c > index b7a2fce684c9..5bc5528f3091 100644 > --- a/drivers/gpu/drm/i915/display/intel_ddi.c > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c > @@ -2722,9 +2722,8 @@ static void intel_ddi_pre_enable_hdmi(struct > intel_atomic_state *state, > > intel_ddi_enable_pipe_clock(encoder, crtc_state); > > - dig_port->set_infoframes(encoder, > - crtc_state->has_infoframe, > - crtc_state, conn_state); > + dig_port->set_infoframes(encoder, crtc_state->has_hdmi_sink, > crtc_state, > + conn_state); > } > > static void intel_ddi_pre_enable(struct intel_atomic_state *state, > @@ -2765,9 +2764,8 @@ static void
Re: [Intel-gfx] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules
On Fri, May 21, 2021 at 05:00:46PM +0200, Bas Nieuwenhuizen wrote:
> On Fri, May 21, 2021 at 4:37 PM Daniel Vetter wrote:
> >
> > On Fri, May 21, 2021 at 11:46:23AM +0200, Bas Nieuwenhuizen wrote:
> > > On Fri, May 21, 2021 at 11:10 AM Daniel Vetter
> > > wrote:
> > > > ---
> > > > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > > > index 88a24a0b5691..cc8426e1e8a8 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > > > @@ -617,8 +617,8 @@ static int amdgpu_cs_parser_bos(struct
> > > > amdgpu_cs_parser *p,
> > > > amdgpu_bo_list_for_each_entry(e, p->bo_list) {
> > > > struct amdgpu_bo *bo = ttm_to_amdgpu_bo(e->tv.bo);
> > > >
> > > > - /* Make sure we use the exclusive slot for shared BOs */
> > > > - if (bo->prime_shared_count)
> > > > + /* Make sure we use the exclusive slot for all
> > > > potentially shared BOs */
> > > > + if (!(bo->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID))
> > > > e->tv.num_shared = 0;
> > >
> > > I think it also makes sense to skip this with
> > > AMDGPU_GEM_CREATE_EXPLICIT_SYNC? It can be shared but I don't think
> > > anyone expects implicit sync to happen with those.
> >
> > Ah yes, I missed this entirely. So the "no implicit flag" is already
> > there, and the _only_ thing that's missing really is a way to fish out the
> > implicit fences, and set them.
> >
> > https://lore.kernel.org/dri-devel/20210520190007.534046-1-ja...@jlekstrand.net/
> >
> > So I think all that's really needed in radv is not setting
> > RADEON_FLAG_IMPLICIT_SYNC for winsys buffers when Jason's dma-buf ioctl
> > are present (means you need to do some import/export and keep the fd
> > around for winsys buffers, but shouldn't be too bad), and then control the
> > implicit fences entirely explicitly like vk expects.
>
> That is the part I'm less sure about. This is a BO wide flag so we are
> also disabling implicit sync in the compositor. If the compositor does
> only do read stuff that is ok, as the inserted exclusive fence will
> work for that. But as I learned recently the app provided buffer may
> end up being written to by the X server which open a whole can of
> potential problems if implicit sync gets disabled between Xserver
> operations on the app provided buffer. Hence setting that on the WSI
> buffer is a whole new can of potential problems and hence I've said a
> submission based flag would be preferred.
>
> I can certainly try it out though.
Hm yeah that's the wrong flag. We need a flag on the drm_file which the
explicit userspace sets. And which is valid only for itself.
There's a nice flags field when creating a ctx, but it's not validated and
there's already a comment that we have to filter out garbage priority, so
that's not use. I'll whip up something entirely untested just as a draft.
-Daniel
>
> >
> > Are you bored enough to type this up for radv? I'll give Jason's kernel
> > stuff another review meanwhile.
> > -Daniel
> >
> > > > e->bo_va = amdgpu_vm_bo_find(vm, bo);
> > > > }
> > > > --
> > > > 2.31.0
> > > >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules
On Fri, May 21, 2021 at 4:37 PM Daniel Vetter wrote:
>
> On Fri, May 21, 2021 at 11:46:23AM +0200, Bas Nieuwenhuizen wrote:
> > On Fri, May 21, 2021 at 11:10 AM Daniel Vetter
> > wrote:
> > > ---
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > > index 88a24a0b5691..cc8426e1e8a8 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > > @@ -617,8 +617,8 @@ static int amdgpu_cs_parser_bos(struct
> > > amdgpu_cs_parser *p,
> > > amdgpu_bo_list_for_each_entry(e, p->bo_list) {
> > > struct amdgpu_bo *bo = ttm_to_amdgpu_bo(e->tv.bo);
> > >
> > > - /* Make sure we use the exclusive slot for shared BOs */
> > > - if (bo->prime_shared_count)
> > > + /* Make sure we use the exclusive slot for all
> > > potentially shared BOs */
> > > + if (!(bo->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID))
> > > e->tv.num_shared = 0;
> >
> > I think it also makes sense to skip this with
> > AMDGPU_GEM_CREATE_EXPLICIT_SYNC? It can be shared but I don't think
> > anyone expects implicit sync to happen with those.
>
> Ah yes, I missed this entirely. So the "no implicit flag" is already
> there, and the _only_ thing that's missing really is a way to fish out the
> implicit fences, and set them.
>
> https://lore.kernel.org/dri-devel/20210520190007.534046-1-ja...@jlekstrand.net/
>
> So I think all that's really needed in radv is not setting
> RADEON_FLAG_IMPLICIT_SYNC for winsys buffers when Jason's dma-buf ioctl
> are present (means you need to do some import/export and keep the fd
> around for winsys buffers, but shouldn't be too bad), and then control the
> implicit fences entirely explicitly like vk expects.
That is the part I'm less sure about. This is a BO wide flag so we are
also disabling implicit sync in the compositor. If the compositor does
only do read stuff that is ok, as the inserted exclusive fence will
work for that. But as I learned recently the app provided buffer may
end up being written to by the X server which open a whole can of
potential problems if implicit sync gets disabled between Xserver
operations on the app provided buffer. Hence setting that on the WSI
buffer is a whole new can of potential problems and hence I've said a
submission based flag would be preferred.
I can certainly try it out though.
>
> Are you bored enough to type this up for radv? I'll give Jason's kernel
> stuff another review meanwhile.
> -Daniel
>
> > > e->bo_va = amdgpu_vm_bo_find(vm, bo);
> > > }
> > > --
> > > 2.31.0
> > >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules
On Fri, May 21, 2021 at 07:58:57AM -0700, Rob Clark wrote: > On Fri, May 21, 2021 at 2:10 AM Daniel Vetter wrote: > > > > - msm is mildly entertaining. It also supports MSM_SUBMIT_NO_IMPLICIT, > > but because it doesn't use the drm/scheduler it handles fences from > > the wrong context with a synchronous dma_fence_wait. See > > submit_fence_sync() leading to msm_gem_sync_object(). Investing into > > a scheduler might be a good idea. > > Yeah, drm/scheduler is (along with a lot of other things) on the TODO > list. But this isn't quite as bad as it sounds because userspace uses > a u_queue thread to call the submit ioctl rather than blocking the > driver. (It also offloads some other work from the driver thread, > like submit merging to reduce # of ioctls. Coincidentally that > arrangement was a step towards preparing userspace for some > hypothetical non-ioctl uapi ;-)) You're also holding a pile of locks, which I expect latest with multi-engine buffer sharing will be pain. If you push this to the scheduler then the locks aren't held. Or maybe I've misread the flow, it's become all a bit a blurr after all these drivers :-) > OTOH it would be good to move blocking until the system can free > enough pages to repin bo's out of the ioctl path to better handle some > memory pressure corner cases without having to be interruptable over a > lot more of the submit path.. Running chrome+android on devices > without a lot of memory is fun.. Uh that one needs the userspace thread. Or entirely different semantics of your ioctl, because you're not allowed to allocate memory once any dma_fence is visible. So offloading the entire pinning to a submit thread is no-go. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules
On Fri, May 21, 2021 at 2:10 AM Daniel Vetter wrote: > > - msm is mildly entertaining. It also supports MSM_SUBMIT_NO_IMPLICIT, > but because it doesn't use the drm/scheduler it handles fences from > the wrong context with a synchronous dma_fence_wait. See > submit_fence_sync() leading to msm_gem_sync_object(). Investing into > a scheduler might be a good idea. Yeah, drm/scheduler is (along with a lot of other things) on the TODO list. But this isn't quite as bad as it sounds because userspace uses a u_queue thread to call the submit ioctl rather than blocking the driver. (It also offloads some other work from the driver thread, like submit merging to reduce # of ioctls. Coincidentally that arrangement was a step towards preparing userspace for some hypothetical non-ioctl uapi ;-)) OTOH it would be good to move blocking until the system can free enough pages to repin bo's out of the ioctl path to better handle some memory pressure corner cases without having to be interruptable over a lot more of the submit path.. Running chrome+android on devices without a lot of memory is fun.. BR, -R ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use DRIVER_NAME for tracing unattached requests
== Series Details == Series: drm/i915: Use DRIVER_NAME for tracing unattached requests URL : https://patchwork.freedesktop.org/series/90351/ State : success == Summary == CI Bug Log - changes from CI_DRM_10110_full -> Patchwork_20157_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20157_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@vcs0: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([i915#198]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10110/shard-skl2/igt@gem_ctx_isolation@preservation...@vcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-skl1/igt@gem_ctx_isolation@preservation...@vcs0.html * igt@gem_ctx_param@set-priority-not-supported: - shard-tglb: NOTRUN -> [SKIP][3] ([fdo#109314]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-tglb7/igt@gem_ctx_pa...@set-priority-not-supported.html * igt@gem_ctx_persistence@legacy-engines-queued: - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-queued.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][5] ([i915#3354]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-snb7/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: NOTRUN -> [FAIL][6] ([i915#2846]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-kbl1/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10110/shard-glk7/igt@gem_exec_fair@basic-none-r...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-glk3/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10110/shard-kbl4/igt@gem_exec_fair@basic-none-...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-kbl3/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10110/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-tglb: NOTRUN -> [FAIL][13] ([i915#2842]) +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-tglb7/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_exec_flush@basic-batch-kernel-default-cmd: - shard-tglb: NOTRUN -> [SKIP][14] ([fdo#109313]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-tglb7/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-apl: NOTRUN -> [FAIL][15] ([i915#2389]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-apl7/igt@gem_exec_reloc@basic-wide-act...@bcs0.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][16] ([i915#2389]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-iclb2/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_mmap_gtt@big-copy-xy: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#307]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10110/shard-skl7/igt@gem_mmap_...@big-copy-xy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-skl7/igt@gem_mmap_...@big-copy-xy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy: - shard-apl: NOTRUN -> [INCOMPLETE][19] ([i915#3468]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-apl7/igt@gem_mmap_...@cpuset-basic-small-copy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd: - shard-glk: NOTRUN -> [INCOMPLETE][20] ([i915#2055] / [i915#3468]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-glk6/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-xy: - shard-snb: NOTRUN -> [INCOMPLETE][21] ([i915#2055] / [i915#3468]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-snb2/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html - shard-kbl: NOTRUN -> [INCOMPLETE][22]
Re: [Intel-gfx] [PATCH 02/11] drm/panfrost: Remove sched_lock
On Fri, May 21, 2021 at 11:32:48AM +0200, Lucas Stach wrote:
> Am Freitag, dem 21.05.2021 um 11:09 +0200 schrieb Daniel Vetter:
> > Scheduler takes care of its own locking, dont worry. For everything else
> > there's reservation locking on each bo.
> >
> > So seems to be entirely redundnant and just a bit in the way.
>
> I haven't read all the surrounding code, but this looks wrong from a
> glance. You must hold a lock across drm_sched_job_init ->
> drm_sched_entity_push_job as the scheduler fences are initialized in
> the job init, so if there's no exclusive section across those two
> function calls you might end up with jobs being queued with their fence
> seqnos not monotonically increasing, which breaks all kinds of other
> stuff.
Uh indeed. That's a bit a loaded gun since generally _init() shouldn't
have any such side effects.
> I don't see a reason to hold the lock across the reservation calls,
> though.
Ok I'll adjust the patch.
-Daniel
>
> Regards,
> Lucas
>
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Rob Herring
> > Cc: Tomeu Vizoso
> > Cc: Steven Price
> > Cc: Alyssa Rosenzweig
> > ---
> > drivers/gpu/drm/panfrost/panfrost_device.c | 1 -
> > drivers/gpu/drm/panfrost/panfrost_device.h | 2 --
> > drivers/gpu/drm/panfrost/panfrost_job.c| 13 ++---
> > 3 files changed, 2 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c
> > b/drivers/gpu/drm/panfrost/panfrost_device.c
> > index 125ed973feaa..23070c01c63f 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_device.c
> > +++ b/drivers/gpu/drm/panfrost/panfrost_device.c
> > @@ -199,7 +199,6 @@ int panfrost_device_init(struct panfrost_device *pfdev)
> > int err;
> > struct resource *res;
> >
> > - mutex_init(>sched_lock);
> > INIT_LIST_HEAD(>scheduled_jobs);
> > INIT_LIST_HEAD(>as_lru_list);
> >
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
> > b/drivers/gpu/drm/panfrost/panfrost_device.h
> > index 597cf1459b0a..7519903bb031 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_device.h
> > +++ b/drivers/gpu/drm/panfrost/panfrost_device.h
> > @@ -105,8 +105,6 @@ struct panfrost_device {
> >
> > struct panfrost_perfcnt *perfcnt;
> >
> > - struct mutex sched_lock;
> > -
> > struct {
> > struct work_struct work;
> > atomic_t pending;
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
> > b/drivers/gpu/drm/panfrost/panfrost_job.c
> > index 6003cfeb1322..f5d39ee14ab5 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_job.c
> > +++ b/drivers/gpu/drm/panfrost/panfrost_job.c
> > @@ -218,26 +218,19 @@ static void panfrost_attach_object_fences(struct
> > drm_gem_object **bos,
> >
> > int panfrost_job_push(struct panfrost_job *job)
> > {
> > - struct panfrost_device *pfdev = job->pfdev;
> > int slot = panfrost_job_get_slot(job);
> > struct drm_sched_entity *entity = >file_priv->sched_entity[slot];
> > struct ww_acquire_ctx acquire_ctx;
> > int ret = 0;
> >
> > - mutex_lock(>sched_lock);
> > -
> > ret = drm_gem_lock_reservations(job->bos, job->bo_count,
> > _ctx);
> > - if (ret) {
> > - mutex_unlock(>sched_lock);
> > + if (ret)
> > return ret;
> > - }
> >
> > ret = drm_sched_job_init(>base, entity, NULL);
> > - if (ret) {
> > - mutex_unlock(>sched_lock);
> > + if (ret)
> > goto unlock;
> > - }
> >
> > job->render_done_fence = dma_fence_get(>base.s_fence->finished);
> >
> > @@ -248,8 +241,6 @@ int panfrost_job_push(struct panfrost_job *job)
> >
> > drm_sched_entity_push_job(>base, entity);
> >
> > - mutex_unlock(>sched_lock);
> > -
> > panfrost_attach_object_fences(job->bos, job->bo_count,
> > job->render_done_fence);
> >
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules
On Fri, May 21, 2021 at 11:46:23AM +0200, Bas Nieuwenhuizen wrote: > On Fri, May 21, 2021 at 11:10 AM Daniel Vetter wrote: > > > > Docs for struct dma_resv are fairly clear: > > > > "A reservation object can have attached one exclusive fence (normally > > associated with write operations) or N shared fences (read > > operations)." > > > > https://dri.freedesktop.org/docs/drm/driver-api/dma-buf.html#reservation-objects > > > > Furthermore a review across all of upstream. > > > > First of render drivers and how they set implicit fences: > > > > - nouveau follows this contract, see in validate_fini_no_ticket() > > > > nouveau_bo_fence(nvbo, fence, !!b->write_domains); > > > > and that last boolean controls whether the exclusive or shared fence > > slot is used. > > > > - radeon follows this contract by setting > > > > p->relocs[i].tv.num_shared = !r->write_domain; > > > > in radeon_cs_parser_relocs(), which ensures that the call to > > ttm_eu_fence_buffer_objects() in radeon_cs_parser_fini() will do the > > right thing. > > > > - vmwgfx seems to follow this contract with the shotgun approach of > > always setting ttm_val_buf->num_shared = 0, which means > > ttm_eu_fence_buffer_objects() will only use the exclusive slot. > > > > - etnaviv follows this contract, as can be trivially seen by looking > > at submit_attach_object_fences() > > > > - i915 is a bit a convoluted maze with multiple paths leading to > > i915_vma_move_to_active(). Which sets the exclusive flag if > > EXEC_OBJECT_WRITE is set. This can either come as a buffer flag for > > softpin mode, or through the write_domain when using relocations. It > > follows this contract. > > > > - lima follows this contract, see lima_gem_submit() which sets the > > exclusive fence when the LIMA_SUBMIT_BO_WRITE flag is set for that > > bo > > > > - msm follows this contract, see msm_gpu_submit() which sets the > > exclusive flag when the MSM_SUBMIT_BO_WRITE is set for that buffer > > > > - panfrost follows this contract with the shotgun approach of just > > always setting the exclusive fence, see > > panfrost_attach_object_fences(). Benefits of a single engine I guess > > > > - v3d follows this contract with the same shotgun approach in > > v3d_attach_fences_and_unlock_reservation(), but it has at least an > > XXX comment that maybe this should be improved > > > > - v4c uses the same shotgun approach of always setting an exclusive > > fence, see vc4_update_bo_seqnos() > > > > - vgem also follows this contract, see vgem_fence_attach_ioctl() and > > the VGEM_FENCE_WRITE. This is used in some igts to validate prime > > sharing with i915.ko without the need of a 2nd gpu > > > > - vritio follows this contract again with the shotgun approach of > > always setting an exclusive fence, see virtio_gpu_array_add_fence() > > > > This covers the setting of the exclusive fences when writing. > > > > Synchronizing against the exclusive fence is a lot more tricky, and I > > only spot checked a few: > > > > - i915 does it, with the optional EXEC_OBJECT_ASYNC to skip all > > implicit dependencies (which is used by vulkan) > > > > - etnaviv does this. Implicit dependencies are collected in > > submit_fence_sync(), again with an opt-out flag > > ETNA_SUBMIT_NO_IMPLICIT. These are then picked up in > > etnaviv_sched_dependency which is the > > drm_sched_backend_ops->dependency callback. > > > > - v4c seems to not do much here, maybe gets away with it by not having > > a scheduler and only a single engine. Since all newer broadcom chips than > > the OG vc4 use v3d for rendering, which follows this contract, the > > impact of this issue is fairly small. > > > > - v3d does this using the drm_gem_fence_array_add_implicit() helper, > > which then it's drm_sched_backend_ops->dependency callback > > v3d_job_dependency() picks up. > > > > - panfrost is nice here and tracks the implicit fences in > > panfrost_job->implicit_fences, which again the > > drm_sched_backend_ops->dependency callback panfrost_job_dependency() > > picks up. It is mildly questionable though since it only picks up > > exclusive fences in panfrost_acquire_object_fences(), but not buggy > > in practice because it also always sets the exclusive fence. It > > should pick up both sets of fences, just in case there's ever going > > to be a 2nd gpu in a SoC with a mali gpu. Or maybe a mali SoC with a > > pcie port and a real gpu, which might actually happen eventually. A > > bug, but easy to fix. Should probably use the > > drm_gem_fence_array_add_implicit() helper. > > > > - lima is nice an easy, uses drm_gem_fence_array_add_implicit() and > > the same schema as v3d. > > > > - msm is mildly entertaining. It also supports MSM_SUBMIT_NO_IMPLICIT, > > but because it doesn't use the drm/scheduler it handles fences from > > the wrong context with a synchronous dma_fence_wait. See > >
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Reenable LTTPR non-transparent LT mode for DPCD_REV<1.4
On Thu, May 13, 2021 at 11:23:41PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Reenable LTTPR non-transparent LT mode for DPCD_REV<1.4
> URL : https://patchwork.freedesktop.org/series/90102/
> State : failure
Pushed to drm-intel-next, thanks for the report, testing and review.
The failures are unrelated see below.
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_10074_full -> Patchwork_20115_full
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_20115_full absolutely need to
> be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_20115_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_20115_full:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@kms_draw_crc@draw-method-xrgb-blt-untiled:
> - shard-skl: NOTRUN -> [FAIL][1]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-skl8/igt@kms_draw_...@draw-method-xrgb-blt-untiled.html
>
> * igt@kms_flip_tiling@flip-changes-tiling@hdmi-a-1-pipe-c:
> - shard-glk: [PASS][2] -> [FAIL][3] +1 similar issue
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10074/shard-glk8/igt@kms_flip_tiling@flip-changes-til...@hdmi-a-1-pipe-c.html
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-glk6/igt@kms_flip_tiling@flip-changes-til...@hdmi-a-1-pipe-c.html
>
> * igt@kms_plane_cursor@pipe-b-primary-size-256:
> - shard-snb: NOTRUN -> [FAIL][4]
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-snb5/igt@kms_plane_cur...@pipe-b-primary-size-256.html
On all the above platforms the LTTPR detection is disabled, so the change
is unrelevant on them.
All the logs have the
x86/PAT: gem_mmap_offset:1163 map pfn RAM range req write-combining for [mem
0x11d278000-0x11d278fff], got write-back
message, so the failures could be related to that.
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * {igt@kms_plane@plane-position-hole@pipe-a-planes}:
> - shard-glk: [FAIL][5] ([i915#3457]) -> [FAIL][6]
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10074/shard-glk9/igt@kms_plane@plane-position-h...@pipe-a-planes.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-glk8/igt@kms_plane@plane-position-h...@pipe-a-planes.html
>
>
>
> ### Piglit changes ###
>
> Possible regressions
>
> *
> spec@arb_gpu_shader_int64@execution@built-in-functions@fs-op-ne-uint64_t-uint64_t
> (NEW):
> - {pig-icl-1065g7}: NOTRUN -> [CRASH][7]
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/pig-icl-1065g7/spec@arb_gpu_shader_int64@execution@built-in-functions@fs-op-ne-uint64_t-uint64_t.html
>
> *
> spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-gt-uint64_t-uint64_t-using-if
> (NEW):
> - {pig-icl-1065g7}: NOTRUN -> [INCOMPLETE][8] +7 similar issues
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/pig-icl-1065g7/spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-gt-uint64_t-uint64_t-using-if.html
>
>
> New tests
> -
>
> New tests have been introduced between CI_DRM_10074_full and
> Patchwork_20115_full:
>
> ### New Piglit tests (9) ###
>
> *
> spec@arb_gpu_shader_int64@execution@built-in-functions@cs-min-i64vec2-i64vec2:
> - Statuses : 1 incomplete(s)
> - Exec time: [0.0] s
>
> *
> spec@arb_gpu_shader_int64@execution@built-in-functions@cs-op-mult-i64vec3-i64vec3:
> - Statuses : 1 incomplete(s)
> - Exec time: [0.0] s
>
> *
> spec@arb_gpu_shader_int64@execution@built-in-functions@fs-op-ne-uint64_t-uint64_t:
> - Statuses : 1 crash(s)
> - Exec time: [0.76] s
>
> *
> spec@arb_gpu_shader_int64@execution@built-in-functions@gs-max-i64vec3-i64vec3:
> - Statuses : 1 incomplete(s)
> - Exec time: [0.0] s
>
> *
> spec@arb_gpu_shader_int64@execution@built-in-functions@gs-op-mult-i64vec4-i64vec4:
> - Statuses : 1 incomplete(s)
> - Exec time: [0.0] s
>
> *
> spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-gt-uint64_t-uint64_t-using-if:
> - Statuses : 1 incomplete(s)
> - Exec time: [0.0] s
>
> *
> spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-mod-u64vec2-uint64_t:
> - Statuses : 1 incomplete(s)
> - Exec time: [0.0] s
>
> *
> spec@arb_gpu_shader_int64@execution@built-in-functions@vs-op-add-uint64_t-u64vec2:
> - Statuses : 1 incomplete(s)
> - Exec time: [0.0] s
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/kms_big_fb: Wait for vblank before collecting CRC
Hello Juha-Pekka
We are seeing the CRC failures on Jasperlake systems. Sometimes the test passes
and sometimes it fails throwing CRC error.
Regards
Vidya
-Original Message-
From: Juha-Pekka Heikkila
Sent: Friday, May 21, 2021 5:00 PM
To: Srinivas, Vidya ;
intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
igt-...@lists.freedesktop.org
Cc: Lin, Charlton
Subject: Re: [igt-dev] [PATCH i-g-t] tests/kms_big_fb: Wait for vblank before
collecting CRC
Hi Vidya,
on which machines this would help? I see there's many vblanks already being
waited. There's igt_display_commit2 which probably will block and even if it
didn't there's igt_pipe_crc_collect_crc(..) where crc calculation is started
after flip and then get one crc before disabling crc counting again.
/Juha-Pekka
On 21.5.2021 7.08, Vidya Srinivas wrote:
> Without wait for vblank, CRC mismatch is seen between big and small
> CRC on few systems
>
> Change-Id: I3bec931aa901130997e693ac1cacf389e2a8100f
> Signed-off-by: Vidya Srinivas
> ---
> tests/kms_big_fb.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/tests/kms_big_fb.c b/tests/kms_big_fb.c index
> b2027b6b9d1b..7d78ff829d41 100644
> --- a/tests/kms_big_fb.c
> +++ b/tests/kms_big_fb.c
> @@ -254,6 +254,7 @@ static void unset_lut(data_t *data)
> static bool test_plane(data_t *data)
> {
> igt_plane_t *plane = data->plane;
> + igt_display_t *display = >display;
> struct igt_fb *small_fb = >small_fb;
> struct igt_fb *big_fb = >big_fb;
> int w = data->big_fb_width - small_fb->width; @@ -337,16 +338,17 @@
> static bool test_plane(data_t *data)
> igt_display_commit2(>display, data->display.is_atomic ?
> COMMIT_ATOMIC : COMMIT_UNIVERSAL);
>
> -
> + igt_wait_for_vblank(data->drm_fd,
> +display->pipes[data->pipe].crtc_offset);
> igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
>
> igt_plane_set_fb(plane, big_fb);
> igt_fb_set_position(big_fb, plane, x, y);
> igt_fb_set_size(big_fb, plane, small_fb->width,
> small_fb->height);
> +
> igt_plane_set_size(plane, data->width, data->height);
> igt_display_commit2(>display, data->display.is_atomic ?
> COMMIT_ATOMIC : COMMIT_UNIVERSAL);
> -
> + igt_wait_for_vblank(data->drm_fd,
> +display->pipes[data->pipe].crtc_offset);
> igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
>
> igt_plane_set_fb(plane, NULL);
>
___
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: Implement PSF GV point support (rev2)
== Series Details ==
Series: drm/i915: Implement PSF GV point support (rev2)
URL : https://patchwork.freedesktop.org/series/90361/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10119 -> Patchwork_20169
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/index.html
Known issues
Here are the changes found in Patchwork_20169 that come from known issues:
### IGT changes ###
Issues hit
* igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u: NOTRUN -> [WARN][1] ([i915#2283])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html
* igt@i915_selftest@live@execlists:
- fi-bdw-5557u: NOTRUN -> [DMESG-FAIL][2] ([i915#3462])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u: NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#111827]) +8
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u: NOTRUN -> [SKIP][4] ([fdo#109271]) +9 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html
Warnings
* igt@i915_selftest@live@execlists:
- fi-cfl-8109u: [INCOMPLETE][5] ([i915#3462]) -> [DMESG-FAIL][6]
([i915#3462])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
- fi-bsw-nick:[DMESG-FAIL][7] ([i915#3462]) -> [INCOMPLETE][8]
([i915#2782] / [i915#2940] / [i915#3462])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
- fi-icl-u2: [DMESG-FAIL][9] ([i915#3462]) -> [INCOMPLETE][10]
([i915#2782] / [i915#3462])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-icl-u2/igt@i915_selftest@l...@execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-icl-u2/igt@i915_selftest@l...@execlists.html
- fi-bsw-kefka: [DMESG-FAIL][11] ([i915#3462]) -> [INCOMPLETE][12]
([i915#2782] / [i915#2940] / [i915#3462])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
* igt@runner@aborted:
- fi-cfl-8109u: [FAIL][13] ([i915#3363]) -> [FAIL][14] ([i915#2426] /
[i915#3363])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-cfl-8109u/igt@run...@aborted.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-cfl-8109u/igt@run...@aborted.html
- fi-icl-u2: [FAIL][15] ([i915#2426] / [i915#2782] / [i915#3363])
-> [FAIL][16] ([i915#2782] / [i915#3363])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-icl-u2/igt@run...@aborted.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-icl-u2/igt@run...@aborted.html
- fi-glk-dsi: [FAIL][17] ([i915#3363] / [k.org#202321]) ->
[FAIL][18] ([i915#2426] / [i915#3363] / [k.org#202321])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-glk-dsi/igt@run...@aborted.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-glk-dsi/igt@run...@aborted.html
- fi-bdw-5557u: [FAIL][19] ([i915#1602] / [i915#2029]) -> [FAIL][20]
([i915#3462])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-bdw-5557u/igt@run...@aborted.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-bdw-5557u/igt@run...@aborted.html
- fi-kbl-7567u: [FAIL][21] ([i915#1436] / [i915#2426] / [i915#3363])
-> [FAIL][22] ([i915#1436] / [i915#3363])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-kbl-7567u/igt@run...@aborted.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-kbl-7567u/igt@run...@aborted.html
- fi-skl-6700k2: [FAIL][23] ([i915#1436] / [i915#2426] / [i915#3363])
-> [FAIL][24] ([i915#1436] / [i915#3363])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-skl-6700k2/igt@run...@aborted.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-skl-6700k2/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]:
Re: [Intel-gfx] [PATCH 11/11] drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default
On 5/21/21 4:09 AM, Daniel Vetter wrote: Goes through all the drivers and deletes the default hook since it's the default now. 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.CHECKPATCH: warning for drm/i915: Implement PSF GV point support (rev2)
== Series Details == Series: drm/i915: Implement PSF GV point support (rev2) URL : https://patchwork.freedesktop.org/series/90361/ State : warning == Summary == $ dim checkpatch origin/drm-tip dbf9d296fc57 drm/i915: Implement PSF GV point support -:59: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #59: FILE: drivers/gpu/drm/i915/display/intel_bw.c:59: +static int adls_pcode_read_psf_gv_point_info(struct drm_i915_private *dev_priv, + struct intel_psf_gv_point *points) -:88: WARNING:LONG_LINE: line length of 108 exceeds 100 columns #88: FILE: drivers/gpu/drm/i915/display/intel_bw.c:93: + drm_err(_priv->drm, "Failed to disable qgv points (%d) points: %x\n", ret, points_mask); -:113: WARNING:QUOTED_WHITESPACE_BEFORE_NEWLINE: unnecessary whitespace before a quoted newline #113: FILE: drivers/gpu/drm/i915/display/intel_bw.c:150: + "PSF GV %d: CLK=%d \n", total: 0 errors, 2 warnings, 1 checks, 247 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Implement PSF GV point support
PSF GV points are an additional factor that can limit the
bandwidth available to display, separate from the traditional
QGV points. Whereas traditional QGV points represent possible
memory clock frequencies, PSF GV points reflect possible
frequencies of the memory fabric.
Switching between PSF GV points has the advantage of incurring
almost no memory access block time and thus does not need to be
accounted for in watermark calculations.
This patch adds support for those on top of regular QGV points.
Those are supposed to be used simultaneously, i.e we are always
at some QGV and some PSF GV point, based on the current video
mode requirements.
Bspec: 64631, 53998
v2: Seems that initial assumption made during ml conversation
was wrong, PCode rejects any masks containing points beyond
the ones returned, so even though BSpec says we have around
8 points theoretically, we can mask/unmask only those which
are returned, trying to manipulate those beyond causes a
failure from PCode. So switched back to generating mask
from 1 - num_qgv_points, where num_qgv_points is the actual
amount of points, advertised by PCode.
Signed-off-by: Stanislav Lisovskiy
Cc: Matt Roper
---
drivers/gpu/drm/i915/display/intel_bw.c | 113 +++-
drivers/gpu/drm/i915/i915_drv.h | 7 ++
drivers/gpu/drm/i915/i915_reg.h | 4 +
drivers/gpu/drm/i915/intel_dram.c | 1 +
4 files changed, 121 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index 3a1ba52266a7..fd23a4818c19 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -17,9 +17,15 @@ struct intel_qgv_point {
u16 dclk, t_rp, t_rdpre, t_rc, t_ras, t_rcd;
};
+struct intel_psf_gv_point {
+ u8 clk; /* clock in multiples of 16. MHz */
+};
+
struct intel_qgv_info {
struct intel_qgv_point points[I915_NUM_QGV_POINTS];
+ struct intel_psf_gv_point psf_points[I915_NUM_PSF_GV_POINTS];
u8 num_points;
+ u8 num_psf_points;
u8 t_bl;
};
@@ -49,6 +55,28 @@ static int icl_pcode_read_qgv_point_info(struct
drm_i915_private *dev_priv,
return 0;
}
+static int adls_pcode_read_psf_gv_point_info(struct drm_i915_private *dev_priv,
+ struct intel_psf_gv_point *points)
+{
+ u32 val = 0, val2 = 0;
+ int ret;
+ int i;
+
+ ret = sandybridge_pcode_read(dev_priv,
+ICL_PCODE_MEM_SUBSYSYSTEM_INFO |
+ADL_PCODE_MEM_SS_READ_PSF_GV_INFO,
+, );
+ if (ret)
+ return ret;
+
+ for (i = 0; i < I915_NUM_PSF_GV_POINTS; i++) {
+ points[i].clk = val & 0xff;
+ val >>= 8;
+ }
+
+ return 0;
+}
+
int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
u32 points_mask)
{
@@ -62,7 +90,7 @@ int icl_pcode_restrict_qgv_points(struct drm_i915_private
*dev_priv,
1);
if (ret < 0) {
- drm_err(_priv->drm, "Failed to disable qgv points (%d)\n",
ret);
+ drm_err(_priv->drm, "Failed to disable qgv points (%d)
points: %x\n", ret, points_mask);
return ret;
}
@@ -76,6 +104,7 @@ static int icl_get_qgv_points(struct drm_i915_private
*dev_priv,
int i, ret;
qi->num_points = dram_info->num_qgv_points;
+ qi->num_psf_points = dram_info->num_psf_gv_points;
if (DISPLAY_VER(dev_priv) == 12)
switch (dram_info->type) {
@@ -109,6 +138,19 @@ static int icl_get_qgv_points(struct drm_i915_private
*dev_priv,
sp->t_rcd, sp->t_rc);
}
+ if (qi->num_psf_points > 0) {
+ ret = adls_pcode_read_psf_gv_point_info(dev_priv,
qi->psf_points);
+ if (ret) {
+ drm_err(_priv->drm, "Failed to read PSF point data;
PSF points will not be considered in bandwidth calculations.\n");
+ qi->num_psf_points = 0;
+ }
+
+ for (i = 0; i < qi->num_psf_points; i++)
+ drm_dbg_kms(_priv->drm,
+ "PSF GV %d: CLK=%d \n",
+ i, qi->psf_points[i].clk);
+ }
+
return 0;
}
@@ -118,6 +160,16 @@ static int icl_calc_bw(int dclk, int num, int den)
return DIV_ROUND_CLOSEST(num * dclk * 100, den * 6);
}
+static int adl_calc_psf_bw(int clk)
+{
+ /*
+* clk is multiples of 16.666MHz (100/6)
+* According to BSpec PSF GV bandwidth is
+* calculated as BW = 64 * clk * 16.666Mhz
+*/
+ return DIV_ROUND_CLOSEST(64 * clk * 100, 6);
+}
+
static int icl_sagv_max_dclk(const struct intel_qgv_info *qi)
{
u16 dclk = 0;
@@
Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 04/11] drm/panfrost: Fix implicit sync
On Fri, 21 May 2021 at 14:09, Christian König wrote: > Am 21.05.21 um 14:54 schrieb Daniel Stone: > > If you're curious, the interface definitions are in the csf/ directory > > in the 'Bifrost kernel driver' r30p0 download you can get from the Arm > > developer site. Unfortunately the exact semantics aren't completely > > clear. > > Well it is actually relatively simple. Take a look at the timeline > semaphores from Vulkan, everybody is basically implementing the same > semantics now. > > When you queued up a bunch of commands on your hardware, the first one > will write value 1 to a 64bit memory location, the second one will write > value 2, the third value 3 and so on. After writing the value the > hardware raises and interrupt signal to everybody interested. > > In other words pretty standard memory fence behavior. > > When you now have a second queue which depends on work of the first one > you look at the memory location and do a compare. If you depend on the > third submission you just wait for the value to be >3 and are done. Right, it is clearly defined to the timeline semaphore semantics, I just meant that it's not clear how it works at a lower level wrt the synchronisation and signaling. The simplest possible interpretation is that wait_addrval blocks infinitely before kick-cmdbuf, but that seems painful with only 32 queues. And the same for fences, which are a binary signal. I guess we'll find out. My tooth hurts. Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 04/11] drm/panfrost: Fix implicit sync
Am 21.05.21 um 14:54 schrieb Daniel Stone: On Fri, 21 May 2021 at 13:28, Christian König wrote: Am 21.05.21 um 14:22 schrieb Daniel Stone: Yeah, the 'second-generation Valhall' GPUs coming later this year / early next year are starting to get pretty weird. Firmware-mediated job scheduling out of multiple queues, userspace having direct access to the queues and can do inter-queue synchronisation (at least I think so), etc. For bonus points, synchronisation is based on $addr = $val to signal and $addr == $val to wait, with a separate fence primitive as well. Well that sounds familiar :) I laughed when I first saw it, because it was better than crying I guess. In Germany we say "Ich freue mich drauf wie auf Zahnschmerzen". If you're curious, the interface definitions are in the csf/ directory in the 'Bifrost kernel driver' r30p0 download you can get from the Arm developer site. Unfortunately the exact semantics aren't completely clear. Well it is actually relatively simple. Take a look at the timeline semaphores from Vulkan, everybody is basically implementing the same semantics now. When you queued up a bunch of commands on your hardware, the first one will write value 1 to a 64bit memory location, the second one will write value 2, the third value 3 and so on. After writing the value the hardware raises and interrupt signal to everybody interested. In other words pretty standard memory fence behavior. When you now have a second queue which depends on work of the first one you look at the memory location and do a compare. If you depend on the third submission you just wait for the value to be >3 and are done. Regards, Christian. Obviously Arm should be part of this conversation here, but I guess we'll have to wait for a while yet to see how everything's shaken out with this new gen, and hope that whatever's been designed upstream in the meantime is actually vaguely compatible ... Yeah, going to keep you in CC when we start to code and review user fences. Awesome, thanks Christian. Appreciate it. :) Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 04/11] drm/panfrost: Fix implicit sync
On Fri, 21 May 2021 at 13:28, Christian König wrote: > Am 21.05.21 um 14:22 schrieb Daniel Stone: > > Yeah, the 'second-generation Valhall' GPUs coming later this year / > > early next year are starting to get pretty weird. Firmware-mediated > > job scheduling out of multiple queues, userspace having direct access > > to the queues and can do inter-queue synchronisation (at least I think > > so), etc. For bonus points, synchronisation is based on $addr = $val > > to signal and $addr == $val to wait, with a separate fence primitive > > as well. > > Well that sounds familiar :) I laughed when I first saw it, because it was better than crying I guess. If you're curious, the interface definitions are in the csf/ directory in the 'Bifrost kernel driver' r30p0 download you can get from the Arm developer site. Unfortunately the exact semantics aren't completely clear. > > Obviously Arm should be part of this conversation here, but I guess > > we'll have to wait for a while yet to see how everything's shaken out > > with this new gen, and hope that whatever's been designed upstream in > > the meantime is actually vaguely compatible ... > > Yeah, going to keep you in CC when we start to code and review user fences. Awesome, thanks Christian. Appreciate it. :) Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/11] drm/: drm_gem_plane_helper_prepare_fb is now the default
Am Freitag, 21. Mai 2021, 11:09:54 CEST schrieb Daniel Vetter: > No need to set it explicitly. > > Signed-off-by: Daniel Vetter > Cc: Laurentiu Palcu > Cc: Lucas Stach > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: Pengutronix Kernel Team > Cc: Fabio Estevam > Cc: NXP Linux Team > Cc: Philipp Zabel > Cc: Paul Cercueil > Cc: Chun-Kuang Hu > Cc: Matthias Brugger > Cc: Neil Armstrong > Cc: Kevin Hilman > Cc: Jerome Brunet > Cc: Martin Blumenstingl > Cc: Marek Vasut > Cc: Stefan Agner > Cc: Sandy Huang > Cc: "Heiko Stübner" > Cc: Yannick Fertre > Cc: Philippe Cornu > Cc: Benjamin Gaignard > Cc: Maxime Coquelin > Cc: Alexandre Torgue > Cc: Maxime Ripard > Cc: Chen-Yu Tsai > Cc: Jernej Skrabec > Cc: Jyri Sarha > Cc: Tomi Valkeinen > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-m...@vger.kernel.org > Cc: linux-media...@lists.infradead.org > Cc: linux-amlo...@lists.infradead.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-st...@st-md-mailman.stormreply.com > Cc: linux-su...@lists.linux.dev > --- > drivers/gpu/drm/imx/dcss/dcss-plane.c | 1 - > drivers/gpu/drm/imx/ipuv3-plane.c | 1 - > drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 1 - > drivers/gpu/drm/ingenic/ingenic-ipu.c | 1 - > drivers/gpu/drm/mediatek/mtk_drm_plane.c| 1 - > drivers/gpu/drm/meson/meson_overlay.c | 1 - > drivers/gpu/drm/meson/meson_plane.c | 1 - > drivers/gpu/drm/mxsfb/mxsfb_kms.c | 2 -- > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 - For Rockchip Acked-by: Heiko Stuebner ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/11] drm/: drm_gem_plane_helper_prepare_fb is now the default
Hi Daniel,
Le ven., mai 21 2021 at 11:09:54 +0200, Daniel Vetter
a écrit :
No need to set it explicitly.
Signed-off-by: Daniel Vetter
Cc: Laurentiu Palcu
Cc: Lucas Stach
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Pengutronix Kernel Team
Cc: Fabio Estevam
Cc: NXP Linux Team
Cc: Philipp Zabel
Cc: Paul Cercueil
Cc: Chun-Kuang Hu
Cc: Matthias Brugger
Cc: Neil Armstrong
Cc: Kevin Hilman
Cc: Jerome Brunet
Cc: Martin Blumenstingl
Cc: Marek Vasut
Cc: Stefan Agner
Cc: Sandy Huang
Cc: "Heiko Stübner"
Cc: Yannick Fertre
Cc: Philippe Cornu
Cc: Benjamin Gaignard
Cc: Maxime Coquelin
Cc: Alexandre Torgue
Cc: Maxime Ripard
Cc: Chen-Yu Tsai
Cc: Jernej Skrabec
Cc: Jyri Sarha
Cc: Tomi Valkeinen
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-m...@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-su...@lists.linux.dev
---
drivers/gpu/drm/imx/dcss/dcss-plane.c | 1 -
drivers/gpu/drm/imx/ipuv3-plane.c | 1 -
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 1 -
drivers/gpu/drm/ingenic/ingenic-ipu.c | 1 -
For drivers/gpu/drm/ingenic/*:
Acked-by: Paul Cercueil
Cheers,
-Paul
drivers/gpu/drm/mediatek/mtk_drm_plane.c| 1 -
drivers/gpu/drm/meson/meson_overlay.c | 1 -
drivers/gpu/drm/meson/meson_plane.c | 1 -
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 2 --
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 -
drivers/gpu/drm/stm/ltdc.c | 1 -
drivers/gpu/drm/sun4i/sun4i_layer.c | 1 -
drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 1 -
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 1 -
drivers/gpu/drm/tidss/tidss_plane.c | 1 -
14 files changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/imx/dcss/dcss-plane.c
b/drivers/gpu/drm/imx/dcss/dcss-plane.c
index 044d3bdf313c..ac45d54acd4e 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-plane.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-plane.c
@@ -361,7 +361,6 @@ static void dcss_plane_atomic_disable(struct
drm_plane *plane,
}
static const struct drm_plane_helper_funcs dcss_plane_helper_funcs =
{
- .prepare_fb = drm_gem_plane_helper_prepare_fb,
.atomic_check = dcss_plane_atomic_check,
.atomic_update = dcss_plane_atomic_update,
.atomic_disable = dcss_plane_atomic_disable,
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 8710f55d2579..ef114b6aa691 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -772,7 +772,6 @@ static void ipu_plane_atomic_update(struct
drm_plane *plane,
}
static const struct drm_plane_helper_funcs ipu_plane_helper_funcs = {
- .prepare_fb = drm_gem_plane_helper_prepare_fb,
.atomic_check = ipu_plane_atomic_check,
.atomic_disable = ipu_plane_atomic_disable,
.atomic_update = ipu_plane_atomic_update,
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 389cad59e090..62db7349bf6a 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -786,7 +786,6 @@ static const struct drm_plane_helper_funcs
ingenic_drm_plane_helper_funcs = {
.atomic_update = ingenic_drm_plane_atomic_update,
.atomic_check = ingenic_drm_plane_atomic_check,
.atomic_disable = ingenic_drm_plane_atomic_disable,
- .prepare_fb = drm_gem_plane_helper_prepare_fb,
};
static const struct drm_crtc_helper_funcs
ingenic_drm_crtc_helper_funcs = {
diff --git a/drivers/gpu/drm/ingenic/ingenic-ipu.c
b/drivers/gpu/drm/ingenic/ingenic-ipu.c
index 3b1091e7c0cd..caf038f3e231 100644
--- a/drivers/gpu/drm/ingenic/ingenic-ipu.c
+++ b/drivers/gpu/drm/ingenic/ingenic-ipu.c
@@ -615,7 +615,6 @@ static const struct drm_plane_helper_funcs
ingenic_ipu_plane_helper_funcs = {
.atomic_update = ingenic_ipu_plane_atomic_update,
.atomic_check = ingenic_ipu_plane_atomic_check,
.atomic_disable = ingenic_ipu_plane_atomic_disable,
- .prepare_fb = drm_gem_plane_helper_prepare_fb,
};
static int
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index b5582dcf564c..1667a7e7de38 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -227,7 +227,6 @@ static void mtk_plane_atomic_update(struct
drm_plane *plane,
}
static const struct drm_plane_helper_funcs mtk_plane_helper_funcs = {
- .prepare_fb = drm_gem_plane_helper_prepare_fb,
.atomic_check = mtk_plane_atomic_check,
.atomic_update = mtk_plane_atomic_update,
.atomic_disable = mtk_plane_atomic_disable,
diff --git a/drivers/gpu/drm/meson/meson_overlay.c
b/drivers/gpu/drm/meson/meson_overlay.c
index ed063152aecd..dfef8afcc245 100644
---
Re: [Intel-gfx] [RFC 7/7] drm/i915: Expose client engine utilisation via fdinfo
Am 21.05.21 um 14:26 schrieb Tvrtko Ursulin: On 20/05/2021 18:47, Daniel Vetter wrote: On Thu, May 20, 2021 at 6:31 PM Christian König wrote: Yeah, having the timestamp is a good idea as well. drm-driver: i915 I think we should rather add something like printing file_operations->owner->name to the common fdinfo code. This way we would have something common for all drivers in the system. I'm just not sure if that also works if they are compiled into the kernel. Yeah common code could print driver name, busid and all that stuff. I think the common code should also provide some helpers for the key: value pair formatting (and maybe check for all lower-case and stuff like that) because if we don't then this is going to be a complete mess that's not parseable. I see we could have a few options here, non exhaustive list (especially omitting some sub-options): 1) DRM core implements fdinfo, which emits the common parts, calling into the driver to do the rest. 2) DRM adds helpers for driver to emit common parts of fdinfo. 3) DRM core establishes a "spec" defining the common fields, the optional ones, and formats. I was trending towards 3) because it is most lightweight and feeling is there isn't that much value in extracting a tiny bit of commonality in code. Proof in the pudding is how short the fdinfo vfunc is in this patch. I would say that we should add printing the module name to the common fdinfo function for the whole kernel. And for the DRM specific stuff either 2 or 3 is the way to go I think. Number 1 sounds to much like mid-layering to me. Regards, Christian. And value should be real semantic stuff, not "here's a string". So accumulated time as a struct ktime as the example. Ideally yes, but I have a feeling the ways how amdgpu and i915 track things are so different so first lets learn more about that. Am 20.05.21 um 18:26 schrieb Nieto, David M: [AMD Official Use Only] i would like to add a unit marker for the stats that we monitor in the fd, as we discussed currently we are displaying the usage percentage, because we wanted to to provide single query percentages, but this may evolve with time. May I suggest to add two new fields drm-stat-interval: <64 bit> ns drm-stat-timestamp: <64 bit> ns If interval is set, engine utilization is calculated by doing render> = 100*/ if interval is not set, two reads are needed : = 100* / - drm-stat-timestamp0> I would like to understand how admgpu tracks GPU time since I am not getting these fields yet. 1) You suggest to have a timestamp because of different clock domains? 2) With the interval option - you actually have a restarting counter? Do you keep that in the driver or get it from hw itself? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 04/11] drm/panfrost: Fix implicit sync
Am 21.05.21 um 14:22 schrieb Daniel Stone: Hi, On Fri, 21 May 2021 at 10:10, Daniel Vetter wrote: Currently this has no practial relevance I think because there's not many who can pull off a setup with panfrost and another gpu in the same system. But the rules are that if you're setting an exclusive fence, indicating a gpu write access in the implicit fencing system, then you need to wait for all fences, not just the previous exclusive fence. panfrost against itself has no problem, because it always sets the exclusive fence (but that's probably something that will need to be fixed for vulkan and/or multi-engine gpus, or you'll suffer badly). Also no problem with that against display. Yeah, the 'second-generation Valhall' GPUs coming later this year / early next year are starting to get pretty weird. Firmware-mediated job scheduling out of multiple queues, userspace having direct access to the queues and can do inter-queue synchronisation (at least I think so), etc. For bonus points, synchronisation is based on $addr = $val to signal and $addr == $val to wait, with a separate fence primitive as well. Well that sounds familiar :) Obviously Arm should be part of this conversation here, but I guess we'll have to wait for a while yet to see how everything's shaken out with this new gen, and hope that whatever's been designed upstream in the meantime is actually vaguely compatible ... Yeah, going to keep you in CC when we start to code and review user fences. Cheers, Christian. Cheers, Daniel ___ Linaro-mm-sig mailing list linaro-mm-...@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-mm-sig ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 7/7] drm/i915: Expose client engine utilisation via fdinfo
On 20/05/2021 18:47, Daniel Vetter wrote: On Thu, May 20, 2021 at 6:31 PM Christian König wrote: Yeah, having the timestamp is a good idea as well. drm-driver: i915 I think we should rather add something like printing file_operations->owner->name to the common fdinfo code. This way we would have something common for all drivers in the system. I'm just not sure if that also works if they are compiled into the kernel. Yeah common code could print driver name, busid and all that stuff. I think the common code should also provide some helpers for the key: value pair formatting (and maybe check for all lower-case and stuff like that) because if we don't then this is going to be a complete mess that's not parseable. I see we could have a few options here, non exhaustive list (especially omitting some sub-options): 1) DRM core implements fdinfo, which emits the common parts, calling into the driver to do the rest. 2) DRM adds helpers for driver to emit common parts of fdinfo. 3) DRM core establishes a "spec" defining the common fields, the optional ones, and formats. I was trending towards 3) because it is most lightweight and feeling is there isn't that much value in extracting a tiny bit of commonality in code. Proof in the pudding is how short the fdinfo vfunc is in this patch. And value should be real semantic stuff, not "here's a string". So accumulated time as a struct ktime as the example. Ideally yes, but I have a feeling the ways how amdgpu and i915 track things are so different so first lets learn more about that. Am 20.05.21 um 18:26 schrieb Nieto, David M: [AMD Official Use Only] i would like to add a unit marker for the stats that we monitor in the fd, as we discussed currently we are displaying the usage percentage, because we wanted to to provide single query percentages, but this may evolve with time. May I suggest to add two new fields drm-stat-interval: <64 bit> ns drm-stat-timestamp: <64 bit> ns If interval is set, engine utilization is calculated by doing = 100*/ if interval is not set, two reads are needed : = 100* / I would like to understand how admgpu tracks GPU time since I am not getting these fields yet. 1) You suggest to have a timestamp because of different clock domains? 2) With the interval option - you actually have a restarting counter? Do you keep that in the driver or get it from hw itself? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/11] drm/panfrost: Fix implicit sync
Hi, On Fri, 21 May 2021 at 10:10, Daniel Vetter wrote: > Currently this has no practial relevance I think because there's not > many who can pull off a setup with panfrost and another gpu in the > same system. But the rules are that if you're setting an exclusive > fence, indicating a gpu write access in the implicit fencing system, > then you need to wait for all fences, not just the previous exclusive > fence. > > panfrost against itself has no problem, because it always sets the > exclusive fence (but that's probably something that will need to be > fixed for vulkan and/or multi-engine gpus, or you'll suffer badly). > Also no problem with that against display. Yeah, the 'second-generation Valhall' GPUs coming later this year / early next year are starting to get pretty weird. Firmware-mediated job scheduling out of multiple queues, userspace having direct access to the queues and can do inter-queue synchronisation (at least I think so), etc. For bonus points, synchronisation is based on $addr = $val to signal and $addr == $val to wait, with a separate fence primitive as well. Obviously Arm should be part of this conversation here, but I guess we'll have to wait for a while yet to see how everything's shaken out with this new gen, and hope that whatever's been designed upstream in the meantime is actually vaguely compatible ... Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Invoke another _DSM to enable MUX on HP Workstation laptops (rev2)
== Series Details == Series: drm/i915: Invoke another _DSM to enable MUX on HP Workstation laptops (rev2) URL : https://patchwork.freedesktop.org/series/89503/ State : success == Summary == CI Bug Log - changes from CI_DRM_10109_full -> Patchwork_20156_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20156_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-skl: NOTRUN -> [DMESG-WARN][1] ([i915#3002]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-skl1/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@clone: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +2 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-snb7/igt@gem_ctx_persiste...@clone.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][3] ([i915#3354]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-snb7/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][4] -> [FAIL][5] ([i915#2846]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10109/shard-glk2/igt@gem_exec_f...@basic-deadline.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-glk8/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10109/shard-tglb7/igt@gem_exec_fair@basic-p...@bcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-tglb5/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10109/shard-glk4/igt@gem_exec_fair@basic-p...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-glk6/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_params@rsvd2-dirt: - shard-tglb: NOTRUN -> [SKIP][10] ([fdo#109283]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-tglb8/igt@gem_exec_par...@rsvd2-dirt.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-snb: NOTRUN -> [FAIL][11] ([i915#2389]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-snb5/igt@gem_exec_reloc@basic-wide-act...@rcs0.html - shard-kbl: NOTRUN -> [FAIL][12] ([i915#2389]) +4 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-kbl3/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][13] ([i915#2389]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-iclb1/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_exec_whisper@basic-contexts-all: - shard-glk: [PASS][14] -> [DMESG-WARN][15] ([i915#118] / [i915#95]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10109/shard-glk5/igt@gem_exec_whis...@basic-contexts-all.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-glk7/igt@gem_exec_whis...@basic-contexts-all.html * igt@gem_mmap_gtt@cpuset-basic-small-copy: - shard-kbl: NOTRUN -> [INCOMPLETE][16] ([i915#3468]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-kbl3/igt@gem_mmap_...@cpuset-basic-small-copy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd: - shard-iclb: [PASS][17] -> [INCOMPLETE][18] ([i915#2910] / [i915#3468]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10109/shard-iclb3/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-iclb2/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([i915#198] / [i915#2910] / [i915#3468]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10109/shard-skl7/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-skl8/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-xy: - shard-tglb: [PASS][21] -> [INCOMPLETE][22] ([i915#3468]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10109/shard-tglb5/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-tglb3/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html * igt@gem_mmap_gtt@fault-concurrent-x: - shard-apl: NOTRUN -> [INCOMPLETE][23] ([i915#3468]) [23]:
Re: [Intel-gfx] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan
On 20/05/2021 20:41, Daniel Vetter wrote:
On Thu, May 20, 2021 at 11:57:44AM +0100, Tvrtko Ursulin wrote:
On 20/05/2021 10:54, Daniel Vetter wrote:
On Wed, May 19, 2021 at 7:19 PM Matthew Brost wrote:
On Wed, May 19, 2021 at 01:10:04PM +0200, Daniel Vetter wrote:
On Tue, May 18, 2021 at 04:58:30PM -0700, Matthew Brost wrote:
Add entry fpr i915 new parallel submission uAPI plan.
v2:
(Daniel Vetter):
- Expand logical order explaination
- Add dummy header
- Only allow N BBs in execbuf IOCTL
- Configure parallel submission per slot not per gem context
Cc: Tvrtko Ursulin
Cc: Tony Ye
CC: Carl Zhang
Cc: Daniel Vetter
Cc: Jason Ekstrand
Signed-off-by: Matthew Brost
---
Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 ++
Documentation/gpu/rfc/i915_scheduler.rst | 53 ++-
2 files changed, 196 insertions(+), 1 deletion(-)
create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h
diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h
b/Documentation/gpu/rfc/i915_parallel_execbuf.h
new file mode 100644
index ..8c64b983ccad
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
@@ -0,0 +1,144 @@
+#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see
i915_context_engines_parallel_submit */
+
+/*
+ * i915_context_engines_parallel_submit:
+ *
+ * Setup a slot to allow multiple BBs to be submitted in a single execbuf
IOCTL.
+ * Those BBs will then be scheduled to run on the GPU in parallel. Multiple
+ * hardware contexts are created internally in the i915 run these BBs. Once a
+ * slot is configured for N BBs only N BBs can be submitted in each execbuf
+ * IOCTL and this is implict behavior (e.g. the user doesn't tell the execbuf
+ * IOCTL there are N BBs, the execbuf IOCTL know how many BBs there are based
on
+ * the slots configuration).
+ *
+ * Their are two currently defined ways to control the placement of the
+ * hardware contexts on physical engines: default behavior (no flags) and
+ * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added the in the
+ * future as new hardware / use cases arise. Details of how to use this
+ * interface below above the flags.
+ *
+ * Returns -EINVAL if hardware context placement configuration invalid or if
the
+ * placement configuration isn't supported on the platform / submission
+ * interface.
+ * Returns -ENODEV if extension isn't supported on the platform / submission
+ * inteface.
+ */
+struct i915_context_engines_parallel_submit {
+ struct i915_user_extension base;
+
+ __u16 engine_index; /* slot for parallel engine */
+ __u16 width;/* number of contexts per parallel engine */
+ __u16 num_siblings; /* number of siblings per context */
+ __u16 mbz16;
Ok the big picture looks reasonable now, the flags still confuse me.
Yea, it is a bit confusing.
+/*
+ * Default placement behvavior (currently unsupported):
+ *
+ * Rather than restricting parallel submission to a single class with a
+ * logically contiguous placement (I915_PARALLEL_IMPLICT_BONDS), add a mode
that
+ * enables parallel submission across multiple engine classes. In this case
each
+ * context's logical engine mask indicates where that context can placed. It is
+ * implied in this mode that all contexts have mutual exclusive placement (e.g.
+ * if one context is running CS0 no other contexts can run on CS0).
+ *
+ * Example 1 pseudo code:
+ * CSX[Y] = engine class X, logical instance Y
+ * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
+ * set_engines(INVALID)
+ * set_parallel(engine_index=0, width=2, num_siblings=2,
+ * engines=CS0[0],CS0[1],CS1[0],CS1[1])
+ *
+ * Results in the following valid placements:
+ * CS0[0], CS1[0]
+ * CS0[0], CS1[1]
+ * CS0[1], CS1[0]
+ * CS0[1], CS1[1]
+ *
+ * This can also be though of as 2 virtual engines:
+ * VE[0] = CS0[0], CS0[1]
+ * VE[1] = CS1[0], CS1[1]
+ *
+ * Example 2 pseudo code:
+ * CS[X] = generic engine of same class, logical instance X
+ * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
+ * set_engines(INVALID)
+ * set_parallel(engine_index=0, width=2, num_siblings=3,
+ * engines=CS[0],CS[1],CS[2],CS[0],CS[1],CS[2])
+ *
+ * Results in the following valid placements:
+ * CS[0], CS[1]
+ * CS[0], CS[2]
+ * CS[1], CS[0]
+ * CS[1], CS[2]
+ * CS[2], CS[0]
+ * CS[2], CS[1]
+ *
+ *
+ * This can also be though of as 2 virtual engines:
+ * VE[0] = CS[0], CS[1], CS[2]
+ * VE[1] = CS[0], CS[1], CS[2]
+
+ * This enables a use case where all engines are created equally, we don't care
+ * where they are scheduled, we just want a certain number of resources, for
+ * those resources to be scheduled in parallel, and possibly across multiple
+ * engine classes.
+ */
So I don't really get what this does compared to setting the flag below.
Is this just about running the batchbuffers the wrong way round, i.e. if
you have (simplest case)
width=2, num_sibglings=1,
Re: [Intel-gfx] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan
On 19/05/2021 00:58, Matthew Brost wrote:
Add entry fpr i915 new parallel submission uAPI plan.
v2:
(Daniel Vetter):
- Expand logical order explaination
- Add dummy header
- Only allow N BBs in execbuf IOCTL
- Configure parallel submission per slot not per gem context
Cc: Tvrtko Ursulin
Cc: Tony Ye
CC: Carl Zhang
Cc: Daniel Vetter
Cc: Jason Ekstrand
Signed-off-by: Matthew Brost
---
Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 ++
Documentation/gpu/rfc/i915_scheduler.rst | 53 ++-
2 files changed, 196 insertions(+), 1 deletion(-)
create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h
diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h
b/Documentation/gpu/rfc/i915_parallel_execbuf.h
new file mode 100644
index ..8c64b983ccad
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
@@ -0,0 +1,144 @@
+#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see
i915_context_engines_parallel_submit */
+
+/*
+ * i915_context_engines_parallel_submit:
+ *
+ * Setup a slot to allow multiple BBs to be submitted in a single execbuf
IOCTL.
+ * Those BBs will then be scheduled to run on the GPU in parallel. Multiple
+ * hardware contexts are created internally in the i915 run these BBs. Once a
+ * slot is configured for N BBs only N BBs can be submitted in each execbuf
+ * IOCTL and this is implict behavior (e.g. the user doesn't tell the execbuf
+ * IOCTL there are N BBs, the execbuf IOCTL know how many BBs there are based
on
+ * the slots configuration).
1)
Expand the term slot here with "slot in the context engine map" least
once for clarity.
2)
About where execbuf will implicitly be finding batches - suggest to also
cover first/last flag here. I know you have it in the readme but I think
it is good if uapi header is as self-contained as possible.
+ *
+ * Their are two currently defined ways to control the placement of the
+ * hardware contexts on physical engines: default behavior (no flags) and
+ * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added the in the
+ * future as new hardware / use cases arise. Details of how to use this
+ * interface below above the flags.
+ *
+ * Returns -EINVAL if hardware context placement configuration invalid or if
the
+ * placement configuration isn't supported on the platform / submission
+ * interface.
+ * Returns -ENODEV if extension isn't supported on the platform / submission
+ * inteface.
+ */
+struct i915_context_engines_parallel_submit {
+ struct i915_user_extension base;
+
+ __u16 engine_index; /* slot for parallel engine */
+ __u16 width;/* number of contexts per parallel engine */
+ __u16 num_siblings; /* number of siblings per context */
+ __u16 mbz16;
+/*
+ * Default placement behvavior (currently unsupported):
+ *
+ * Rather than restricting parallel submission to a single class with a
+ * logically contiguous placement (I915_PARALLEL_IMPLICT_BONDS), add a mode
that
What do you mean with logically contiguous here? It sounds ambiguous
versus logical vs "normal" engine instance numbers.
+ * enables parallel submission across multiple engine classes. In this case
each
+ * context's logical engine mask indicates where that context can placed. It is
+ * implied in this mode that all contexts have mutual exclusive placement (e.g.
+ * if one context is running CS0 no other contexts can run on CS0).
I think talk about logical context and its mask is too implementation
detail at the uapi level. Instead I would suggest more userspace
programmer centric description.
+ *
+ * Example 1 pseudo code:
+ * CSX[Y] = engine class X, logical instance Y
+ * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
+ * set_engines(INVALID)
+ * set_parallel(engine_index=0, width=2, num_siblings=2,
+ * engines=CS0[0],CS0[1],CS1[0],CS1[1])
+ *
+ * Results in the following valid placements:
+ * CS0[0], CS1[0]
+ * CS0[0], CS1[1]
+ * CS0[1], CS1[0]
+ * CS0[1], CS1[1]
+ *
+ * This can also be though of as 2 virtual engines:
+ * VE[0] = CS0[0], CS0[1]
+ * VE[1] = CS1[0], CS1[1]
Ah okay so essentially similar to what I was proposing a year ago. But
then it is no longer "set_parallel" really. It is one slot in the engine
map, right, with the idea to super class intel_context in the
implementation?
So really a wide virtual engine, as opposed to single one. In which case
I think it makes sense to stay close to the existing naming of the
load_balance extension for consistency. Load_balance_wide?
Load_balance_parallel? Multi?
I also have to say the notation "CS0[0]" - I who know this problem space
am finding it hard to penetrate what that actually means. (Also
uppercase IMO makes it hard to read, but maybe it is just me.)
Looking a bit lower below, extension seems to be taking a 2d array of
class:instance pairs, right? If so then reading these docs in order, or
even just
Re: [Intel-gfx] [Nouveau] [PATCH 0/7] Per client engine busyness
> Well if it becomes a problem fixing the debugfs "clients" file and > making it sysfs shouldn't be much of a problem later on. Why not to try using something in terms of perf / opensnoop or bpf to do the work. Should be optimal enough. ie. http://www.brendangregg.com/blog/2014-07-25/opensnoop-for-linux.html https://man7.org/linux/man-pages/man2/bpf.2.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/11] drm/vram-helpers: Create DRM_GEM_VRAM_PLANE_HELPER_FUNCS
在 2021/5/21 17:09, Daniel Vetter 写道:
Like we have for the shadow helpers too, and roll it out to drivers.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Thomas Zimmermann
Cc: Hans de Goede
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: David Airlie
Cc: Daniel Vetter
Cc: Tian Tao
Cc: Laurent Pinchart
---
drivers/gpu/drm/ast/ast_mode.c | 3 +--
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 3 +--
drivers/gpu/drm/vboxvideo/vbox_mode.c | 3 +--
include/drm/drm_gem_vram_helper.h | 12
4 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 36d9575aa27b..20557d2c2fae 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -612,8 +612,7 @@ ast_primary_plane_helper_atomic_disable(struct drm_plane
*plane,
}
static const struct drm_plane_helper_funcs ast_primary_plane_helper_funcs = {
- .prepare_fb = drm_gem_vram_plane_helper_prepare_fb,
- .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb,
+ DRM_GEM_VRAM_PLANE_HELPER_FUNCS,
.atomic_check = ast_primary_plane_helper_atomic_check,
.atomic_update = ast_primary_plane_helper_atomic_update,
.atomic_disable = ast_primary_plane_helper_atomic_disable,
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index 29b8332b2bca..ccf80e369b4b 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -158,8 +158,7 @@ static const struct drm_plane_funcs hibmc_plane_funcs = {
};
static const struct drm_plane_helper_funcs hibmc_plane_helper_funcs = {
- .prepare_fb = drm_gem_vram_plane_helper_prepare_fb,
- .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb,
+ DRM_GEM_VRAM_PLANE_HELPER_FUNCS,
.atomic_check = hibmc_plane_atomic_check,
.atomic_update = hibmc_plane_atomic_update,
};
Reviewed-by: Tian Tao
diff --git a/drivers/gpu/drm/vboxvideo/vbox_mode.c
b/drivers/gpu/drm/vboxvideo/vbox_mode.c
index 964381d55fc1..972c83b720aa 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_mode.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_mode.c
@@ -488,8 +488,7 @@ static const struct drm_plane_helper_funcs
vbox_primary_helper_funcs = {
.atomic_check = vbox_primary_atomic_check,
.atomic_update = vbox_primary_atomic_update,
.atomic_disable = vbox_primary_atomic_disable,
- .prepare_fb = drm_gem_vram_plane_helper_prepare_fb,
- .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb,
+ DRM_GEM_VRAM_PLANE_HELPER_FUNCS,
};
static const struct drm_plane_funcs vbox_primary_plane_funcs = {
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index 27ed7e9243b9..f48d181c824b 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -124,6 +124,18 @@ void
drm_gem_vram_plane_helper_cleanup_fb(struct drm_plane *plane,
struct drm_plane_state *old_state);
+/**
+ * DRM_GEM_VRAM_PLANE_HELPER_FUNCS -
+ * Initializes struct drm_plane_helper_funcs for VRAM handling
+ *
+ * Drivers may use GEM BOs as VRAM helpers for the framebuffer memory. This
+ * macro initializes struct drm_plane_helper_funcs to use the respective helper
+ * functions.
+ */
+#define DRM_GEM_VRAM_PLANE_HELPER_FUNCS \
+ .prepare_fb = drm_gem_vram_plane_helper_prepare_fb, \
+ .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb
+
/*
* Helpers for struct drm_simple_display_pipe_funcs
*/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan
Am 20.05.21 um 23:38 schrieb Jason Ekstrand: On Thu, May 20, 2021 at 10:46 AM Matthew Brost wrote: On Thu, May 20, 2021 at 01:11:59PM +0200, Christian König wrote: Am 19.05.21 um 18:51 schrieb Matthew Brost: On Wed, May 19, 2021 at 01:45:39PM +0200, Christian König wrote: Oh, yeah we call that gang submit on the AMD side. Had already some internal discussions how to implement this, but so far couldn't figure out how to cleanly introduce that into the DRM scheduler. Can you briefly describe in a few words how that is supposed to work on the Intel side? On Intel, we actually have two cases which don't fit the current drm/scheduler model well: balanced and bonded. In the balanced model, we want to submit a batch which can go to any one of some set of engines and we don't care which. It's up to the kernel to pick an engine. Imagine you had 64 identical HW compute queues, for instance. This could be done by making all the identical engines share a single drm_gpu_scheduler and round-robin around the HW queues or something. I don't know that we strictly need drm/scheduler to be aware of it but it might be nice if it grew support for this mode so we could maintain a 1:1 relationship between HW queues and drm_gpu_schedulers. That said, I'm not sure how this would play with GuC queues so maybe it doesn't help? Oh, we do have support for load balancing like that. When you call drm_sched_entity_init() you can give a list of drm_gpu_scheduler object to use round robing for scheduling. New jobs are then scheduler to the drm_gpu_scheduler instance which is idle or rather the least busy one. The bonded model is like your ganged, I think. We want to submit N batches to run in parallel. And they actually have to be executing on the GPU simultaneously and not just sort-of at similar times. We need this for video. There are also potential use-cases in Vulkan or even GL that might be able to use this. One difference with the balanced mode is that bonds don't, strictly speaking, need to be on the same type of engine. Imagine, for instance, a 3D batch with a parallel compute batch doing vertex pre-processing. I'm pretty sure the bonded case is something that the mobile drivers (panfrost, etc.) would like as well for doing Vulkan on tilers where you often have to have two command buffers running in parallel. They're currently doing it by submitting a giant pile of batches where they split the batch and add sync primitives every time some GL call requires them to sync between fragment and vertex pipes. Yeah, we have exactly the same problem as well. But so far every model we discussed has some drawbacks and it is rather hard for the scheduler to guarantee that stuff runs at the same time. So if you got any ideas how to cleanly implement that then they would be rather welcomed. Regards, Christian. So, to sum up, I think there's likely some good collaboration to be had here for everyone. :-) --Jason Sure, I've done a quick PoC internally and have been able to hook this into the DRM scheduler. Basically each BB still maps to a single job as each job is somewhat unique (e.g. each job has its own ring, lrc, seqno, etc...). However all the jobs configured to run in parallel map to a single sched_entity which maintains the order each job was generated from the execbuf IOCTL (1 - N). When the backend receives jobs 1 to N - 1 it basically just updates some internal state. When the backend sees job N (last job) it actually does the submit for jobs 1 - N which with GuC submission is a simple command moving the LRC tail of the N jobs. Daniel has suggested that we create a single job for the NN BBs but that would be huge rework to the internals of the i915 and likely won't happen by the time this code first lands. Also worth noting one way a job isn't really a treated individually is the excl slot with dma-resv. In that case we create a composite fence of all jobs (dma_fence_array). Yeah, that's something we have discussed as well. How do you prevent the scheduler from over committing to a single ring buffer in this scenario? Each job has its own ring, the execbuf IOCTL throttles itself for each job if there isn't space in the ring. This is exactly the same as non-parallel submits. I think this is what you were asking? If not, maybe try explaining the question a bit more. Matt Christian. Matt Thanks, Christian. Am 19.05.21 um 01:58 schrieb Matthew Brost: Add entry fpr i915 new parallel submission uAPI plan. v2: (Daniel Vetter): - Expand logical order explaination - Add dummy header - Only allow N BBs in execbuf IOCTL - Configure parallel submission per slot not per gem context Cc: Tvrtko Ursulin Cc: Tony Ye CC: Carl Zhang Cc: Daniel Vetter Cc: Jason Ekstrand Signed-off-by: Matthew Brost --- Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 ++ Documentation/gpu/rfc/i915_scheduler.rst | 53 ++- 2 files changed,
Re: [Intel-gfx] [RFC 7/7] drm/i915: Expose client engine utilisation via fdinfo
[AMD Official Use Only]
i would like to add a unit marker for the stats that we monitor in the fd, as
we discussed currently we are displaying the usage percentage, because we
wanted to to provide single query percentages, but this may evolve with time.
May I suggest to add two new fields
drm-stat-interval: <64 bit> ns
drm-stat-timestamp: <64 bit> ns
If interval is set, engine utilization is calculated by doing =
100*/
if interval is not set, two reads are needed : =
100* /
Regards,
David
From: Tvrtko Ursulin
Sent: Thursday, May 20, 2021 8:12 AM
To: Intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org ; Tvrtko
Ursulin ; Nieto, David M ;
Koenig, Christian ; Daniel Vetter
Subject: [RFC 7/7] drm/i915: Expose client engine utilisation via fdinfo
From: Tvrtko Ursulin
Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for i915.
Example of the output:
pos:0
flags: 012
mnt_id: 21
drm-driver: i915
drm-pdev: :00:02.0
drm-client-id: 7
drm-engine-render: 9288864723 ns
drm-engine-copy:2035071108 ns
drm-engine-video: 0 ns
drm-engine-video-enhance: 0 ns
DRM related fields are appropriately prefixed for easy parsing and
separation from generic fdinfo fields.
Idea is for some fields to become either fully or partially standardised
in order to enable writting of generic top-like tools.
Initial proposal for fully standardised common fields:
drm-driver:
drm-pdev:
Optional fully standardised:
drm-client-id:
Optional partially standardised:
engine-: ns
memory-: KiB
Once agreed the format would need to go to some README or kerneldoc in
DRM core.
Signed-off-by: Tvrtko Ursulin
Cc: David M Nieto
Cc: Christian König
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drm_client.c | 68 ++
drivers/gpu/drm/i915/i915_drm_client.h | 4 ++
drivers/gpu/drm/i915/i915_drv.c| 3 ++
3 files changed, 75 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index 1e5db7753276..5e9cfba1116b 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -9,6 +9,11 @@
#include
+#include
+
+#include "gem/i915_gem_context.h"
+#include "gt/intel_engine_user.h"
+
#include "i915_drm_client.h"
#include "i915_drv.h"
#include "i915_gem.h"
@@ -168,3 +173,66 @@ void i915_drm_clients_fini(struct i915_drm_clients
*clients)
xa_destroy(>xarray);
}
+
+#ifdef CONFIG_PROC_FS
+static const char * const uabi_class_names[] = {
+ [I915_ENGINE_CLASS_RENDER] = "render",
+ [I915_ENGINE_CLASS_COPY] = "copy",
+ [I915_ENGINE_CLASS_VIDEO] = "video",
+ [I915_ENGINE_CLASS_VIDEO_ENHANCE] = "video-enhance",
+};
+
+static u64 busy_add(struct i915_gem_context *ctx, unsigned int class)
+{
+ struct i915_gem_engines_iter it;
+ struct intel_context *ce;
+ u64 total = 0;
+
+ for_each_gem_engine(ce, rcu_dereference(ctx->engines), it) {
+ if (ce->engine->uabi_class != class)
+ continue;
+
+ total += intel_context_get_total_runtime_ns(ce);
+ }
+
+ return total;
+}
+
+static void
+show_client_class(struct seq_file *m,
+ struct i915_drm_client *client,
+ unsigned int class)
+{
+ const struct list_head *list = >ctx_list;
+ u64 total = atomic64_read(>past_runtime[class]);
+ struct i915_gem_context *ctx;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(ctx, list, client_link)
+ total += busy_add(ctx, class);
+ rcu_read_unlock();
+
+ return seq_printf(m, "drm-engine-%s:\t%llu ns\n",
+ uabi_class_names[class], total);
+}
+
+void i915_drm_client_fdinfo(struct seq_file *m, struct file *f)
+{
+ struct drm_file *file = f->private_data;
+ struct drm_i915_file_private *file_priv = file->driver_priv;
+ struct drm_i915_private *i915 = file_priv->dev_priv;
+ struct i915_drm_client *client = file_priv->client;
+ struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
+ unsigned int i;
+
+ seq_printf(m, "drm-driver:\ti915\n");
+ seq_printf(m, "drm-pdev:\t%04x:%02x:%02x.%d\n",
+ pci_domain_nr(pdev->bus), pdev->bus->number,
+ PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
+
+ seq_printf(m, "drm-client-id:\t%u\n", client->id);
+
+ for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
+ show_client_class(m, client, i);
+}
+#endif
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
b/drivers/gpu/drm/i915/i915_drm_client.h
index b2b69d6985e4..9885002433a0 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -98,6 +98,10 @@
Re: [Intel-gfx] [PATCH 0/8] drm + usb-type-c: Add support for out-of-band hotplug notification (v3)
On Tue, May 11, 2021 at 10:05:26AM +0300, Heikki Krogerus wrote: > On Wed, May 05, 2021 at 06:24:07PM +0200, Hans de Goede wrote: > > Hi All, > > > > Here is v3 of my patchset making DP over Type-C work on devices where the > > Type-C controller does not drive the HPD pin on the GPU, but instead > > we need to forward HPD events from the Type-C controller to the DRM driver. > > These look good to me. I can also test these next week if needed. I'll > give my Tested-by tag after that if these haven't been taken by > anybody by that. It's almost weird to see console output from the Type-C connector on my good old GPD printed to an actual display :-) At least in my tests, the DP alt mode driver now calls drm_connector_oob_hotplug_event() only when it should. This is pretty cool! FWIW: Tested-by: Heikki Krogerus thanks, -- heikki ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
