[Intel-gfx] ✓ Fi.CI.BAT: success for igt/kms_rotation_crc : Remove flip tests for sprite plane (rev3)
== Series Details == Series: igt/kms_rotation_crc : Remove flip tests for sprite plane (rev3) URL : https://patchwork.freedesktop.org/series/30588/ State : success == Summary == IGT patchset tested on top of latest successful build 6e2622564dc85875ee9e2f22874f9607cf0cdd9c meson: share the configuration_data object with latest DRM-Tip kernel build CI_DRM_3117 bed15796ff69 drm-tip: 2017y-09m-20d-20h-05m-31s UTC integration manifest Test gem_exec_suspend: Subgroup basic-s3: pass -> INCOMPLETE (fi-kbl-7500u) fdo#102850 Test gem_ringfill: Subgroup basic-default-hang: pass -> DMESG-WARN (fi-pnv-d510) fdo#101600 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 Test pm_rpm: Subgroup basic-rte: dmesg-warn -> PASS (fi-cfl-s) fdo#102294 Test drv_module_reload: Subgroup basic-reload: pass -> DMESG-WARN (fi-glk-1) fdo#102777 fdo#102850 https://bugs.freedesktop.org/show_bug.cgi?id=102850 fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294 fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:447s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:471s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:423s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:518s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:277s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:508s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:499s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:495s fi-cfl-s total:289 pass:223 dwarn:34 dfail:0 fail:0 skip:32 time:546s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:423s fi-glk-1 total:289 pass:259 dwarn:1 dfail:0 fail:0 skip:29 time:572s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:429s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:405s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:432s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:488s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:466s fi-kbl-7500u total:118 pass:100 dwarn:1 dfail:0 fail:0 skip:16 fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:577s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:603s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:549s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:452s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:746s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:493s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:473s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:580s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:1 skip:39 time:415s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_236/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] SENT_UPSTREAM [IOTG] drm/i915: Add error handling to drm_plane_create_rotation_property call
In kernel 4.10, drm_plane_create_rotation_property is replaced by
drm_mode_create_rotation_property which returns int instead of struct.
Thus, it's possible for this function to return non 0 which the caller must
handle
Signed-off-by: Badiuzzaman Iskhandar
---
drivers/gpu/drm/i915/intel_display.c | 14 ++
drivers/gpu/drm/i915/intel_sprite.c | 4 +++-
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3903754..cabc92d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15388,10 +15388,13 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
supported_rotations = DRM_ROTATE_0;
}
- if (INTEL_GEN(dev_priv) >= 4)
- drm_plane_create_rotation_property(&primary->base,
+ if (INTEL_GEN(dev_priv) >= 4) {
+ ret = drm_plane_create_rotation_property(&primary->base,
DRM_ROTATE_0,
supported_rotations);
+if (ret)
+goto fail;
+}
drm_plane_helper_add(&primary->base, &intel_plane_helper_funcs);
@@ -15537,11 +15540,14 @@ intel_cursor_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
if (ret)
goto fail;
- if (INTEL_GEN(dev_priv) >= 4)
- drm_plane_create_rotation_property(&cursor->base,
+ if (INTEL_GEN(dev_priv) >= 4) {
+ ret = drm_plane_create_rotation_property(&cursor->base,
DRM_ROTATE_0,
DRM_ROTATE_0 |
DRM_ROTATE_180);
+if (ret)
+goto fail;
+}
if (INTEL_GEN(dev_priv) >= 9)
state->scaler_id = -1;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index b53bc57..5f0ac6f 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1141,9 +1141,11 @@ intel_sprite_plane_create(struct drm_i915_private
*dev_priv,
if (ret)
goto fail;
- drm_plane_create_rotation_property(&intel_plane->base,
+ ret = drm_plane_create_rotation_property(&intel_plane->base,
DRM_ROTATE_0,
supported_rotations);
+if (ret)
+goto fail;
drm_plane_helper_add(&intel_plane->base, &intel_plane_helper_funcs);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for SENT_UPSTREAM [IOTG] drm/i915: Add error handling to drm_plane_create_rotation_property call
== Series Details == Series: SENT_UPSTREAM [IOTG] drm/i915: Add error handling to drm_plane_create_rotation_property call URL : https://patchwork.freedesktop.org/series/30691/ State : failure == Summary == Series 30691 revision 1 was fully merged or fully failed: no git log ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for igt/kms_rotation_crc : Remove flip tests for sprite plane (rev3)
== Series Details == Series: igt/kms_rotation_crc : Remove flip tests for sprite plane (rev3) URL : https://patchwork.freedesktop.org/series/30588/ State : failure == Summary == Test kms_rotation_crc: Subgroup sprite-rotation-180-flip: fail -> PASS (shard-hsw) fdo#102691 Test perf: Subgroup blocking: pass -> FAIL (shard-hsw) fdo#102252 Test gem_exec_store: Subgroup pages-render: pass -> FAIL (shard-hsw) Test gem_flink_race: Subgroup flink_close: pass -> FAIL (shard-hsw) fdo#102655 Test kms_cursor_legacy: Subgroup flip-vs-cursor-toggle: pass -> FAIL (shard-hsw) fdo#102670 fdo#102691 https://bugs.freedesktop.org/show_bug.cgi?id=102691 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#102655 https://bugs.freedesktop.org/show_bug.cgi?id=102655 fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670 shard-hswtotal:2317 pass:1244 dwarn:2 dfail:0 fail:14 skip:1057 time:9729s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_236/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] force yuv 4:2:0 output
On Wed, 20 Sep 2017, Wolfgang Haupt wrote: > I've tried v4.14-rc1. > Now I do not have 4k@60 anymore. Okay, please file a bug at https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel > dmesg with drm.debug: > http://sprunge.us/TKbO Attach dmesg all the way from boot to the bug please. BR, Jani. > > > Best Regards, > Wolfgang > > Jani Nikula schrieb am Di., 19. Sep. 2017 um > 12:08 Uhr: > >> On Mon, 18 Sep 2017, Wolfgang Haupt wrote: >> > Hello everyone, >> > >> > recently I played around with my kabylake i5 nuc box and found that on >> some >> > TV's >> > the screen stays black as soon as I go to 4k@60. >> > The TV only accepts 4k@60 at yuv 4:2:0 (I also saw hdmi range extenders >> and >> > stuff that don't support yuv 4:4:4 on 4k@60). >> > I tried to force limited mode through xrandr or by overriding the edid >> > information, but nothing worked so far. >> > Now I wonder if there is a way to force yuv 4:2:0 ouptut on the kernel >> > level. >> > Thanks. >> >> Please try v4.14-rc1. >> >> BR, >> Jani. >> >> >> -- >> Jani Nikula, Intel Open Source Technology Center >> -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Remove use_mmio_flip modparm
This has been unused since commit afa8ce5b3080
("drm/i915: Nuke legacy flip queueing code").
Cc: Chris Wilson
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_params.c | 4
drivers/gpu/drm/i915/i915_params.h | 1 -
drivers/gpu/drm/i915/intel_lrc.c | 3 +--
3 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index b1c928582079..96a50a2cf302 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -58,7 +58,6 @@ struct i915_params i915 __read_mostly = {
.invert_brightness = 0,
.disable_display = 0,
.enable_cmd_parser = true,
- .use_mmio_flip = 0,
.mmio_debug = 0,
.verbose_state_checks = 1,
.edp_vswing = 0,
@@ -181,9 +180,6 @@ i915_param_named(disable_display, bool, 0400,
i915_param_named_unsafe(enable_cmd_parser, bool, 0400,
"Enable command parsing (true=enabled [default], false=disabled)");
-i915_param_named_unsafe(use_mmio_flip, int, 0600,
- "use MMIO flips (-1=never, 0=driver discretion [default], 1=always)");
-
i915_param_named(mmio_debug, int, 0600,
"Enable the MMIO debug code for the first N failures (default: off). "
"This may negatively affect performance.");
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index cb66451cefde..6ce49f09def9 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -49,7 +49,6 @@
func(int, guc_log_level); \
func(char *, guc_firmware_path); \
func(char *, huc_firmware_path); \
- func(int, use_mmio_flip); \
func(int, mmio_debug); \
func(int, edp_vswing); \
func(int, reset); \
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 86fed9f1f1ae..5fbe3177bf63 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -243,8 +243,7 @@ int intel_sanitize_enable_execlists(struct drm_i915_private
*dev_priv, int enabl
return 0;
if (HAS_LOGICAL_RING_CONTEXTS(dev_priv) &&
- USES_PPGTT(dev_priv) &&
- i915.use_mmio_flip >= 0)
+ USES_PPGTT(dev_priv))
return 1;
return 0;
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Remove use_mmio_flip modparm
== Series Details == Series: drm/i915: Remove use_mmio_flip modparm URL : https://patchwork.freedesktop.org/series/30693/ State : failure == Summary == Series 30693 revision 1 was fully merged or fully failed: no git log ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/31] drm/i915: Name structure in dev_priv that contains RPS/RC6 state as "pm"
On Tue, 2017-09-19 at 23:11 +0530, Sagar Arun Kamble wrote: > Prepared substructure rps for RPS related state. autoenable_work and > pcu_lock are used for RC6 hence they are defined outside rps structure. > Renamed the RPS lock as pcu_lock. > > Cc: Chris Wilson > Cc: Imre Deak > Signed-off-by: Sagar Arun Kamble Reviewed-by: Radoslaw Szwichtenberg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/31] drm/i915: Rename intel_enable_rc6 to intel_rc6_enabled
On Tue, 2017-09-19 at 23:11 +0530, Sagar Arun Kamble wrote: > This function gives the status of RC6, whether disabled or if > enabled then which state. intel_enable_rc6 will be used for > enabling RC6 in the next patch. > > Cc: Chris Wilson > Cc: Imre Deak > Signed-off-by: Sagar Arun Kamble Reviewed-by: Radoslaw Szwichtenberg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-next
Hi Dave, the first batch of i915 features heading for v4.15. I can't really name any one overarching theme here other than, "changes all over the place". Details below. BR, Jani. drm-intel-next-2017-09-07: Getting started with v4.15 features: - Cannonlake workarounds (Rodrigo, Oscar) - Infoframe refactoring and fixes to enable infoframes for DP (Ville) - VBT definition updates (Jani) - Sparse warning fixes (Ville, Chris) - Crtc state usage fixes and cleanups (Ville) - DP vswing, pre-emph and buffer translation refactoring and fixes (Rodrigo) - Prevent IPS from interfering with CRC capture (Ville, Marta) - Enable Mesa to advertise ARB_timer_query (Nanley) - Refactor GT number into intel_device_info (Lionel) - Avoid eDP DP AUX CH timeouts harder (Manasi) - CDCLK check improvements (Ville) - Restore GPU clock boost on missed pageflip vblanks (Chris) - Fence register reservation API for vGPU (Changbin) - First batch of CCS fixes (Ville) - Finally, numerous GEM fixes, cleanups and improvements (Chris) BR, Jani. The following changes since commit 7846b12fe0b5feab5446d892f41b5140c1419109: Merge branch 'drm-vmwgfx-next' of git://people.freedesktop.org/~syeh/repos_linux into drm-next (2017-08-29 10:38:14 +1000) are available in the git repository at: git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-next-2017-09-07 for you to fetch changes up to bb9d2d050503c69695557b8b741276686ca2a396: drm/i915: Update DRIVER_DATE to 20170907 (2017-09-07 11:28:20 +0300) Getting started with v4.15 features: - Cannonlake workarounds (Rodrigo, Oscar) - Infoframe refactoring and fixes to enable infoframes for DP (Ville) - VBT definition updates (Jani) - Sparse warning fixes (Ville, Chris) - Crtc state usage fixes and cleanups (Ville) - DP vswing, pre-emph and buffer translation refactoring and fixes (Rodrigo) - Prevent IPS from interfering with CRC capture (Ville, Marta) - Enable Mesa to advertise ARB_timer_query (Nanley) - Refactor GT number into intel_device_info (Lionel) - Avoid eDP DP AUX CH timeouts harder (Manasi) - CDCLK check improvements (Ville) - Restore GPU clock boost on missed pageflip vblanks (Chris) - Fence register reservation API for vGPU (Changbin) - First batch of CCS fixes (Ville) - Finally, numerous GEM fixes, cleanups and improvements (Chris) Changbin Du (1): drm/i915: Add interface to reserve fence registers for vGPU Chris Wilson (20): drm/i915: Clear lost context-switch interrupts across reset drm/i915: Boost GPU clocks if we miss the pageflip's vblank drm/i915: Keep a small stash of preallocated WC pages drm/i915: Assert the context is not closed on object-close drm/i915: Assert that the handle->vma lut is empty on object close drm/i915: Ignore duplicate VMA stored within the per-object handle LUT drm/i915: Quietly cancel FBC activation if CRTC is turned off before worker drm/i915: Remove excess indent in intel_finish_reset() caught by sparse drm/i915: Recreate vmapping even when the object is pinned drm/i915: Don't use GPU relocations prior to cmdparser stalls drm/i915: Always sanity check engine state upon idling drm/i915: Clear wedged status upon resume drm/i915: Discard the request queue if we fail to sleep before suspend drm/i915: Always wake the device to flush the GTT drm/i915: Silence sparse by using gfp_t drm/i915/perf: Remove __user from u64 in drm_i915_perf_oa_config drm/i915: Re-enable GTT following a device reset drm/i915: Disable MI_STORE_DATA_IMM for i915g/i915gm drm/i915: Move device_info.has_snoop into the static tables drm/i915: Lift has-pinned-pages assert to caller of i915_gem_object_get_pages Jani Nikula (18): drm/i915/dp: rename intel_dp_is_edp to intel_dp_is_port_edp drm/i915/dp: make is_edp non-static and rename to intel_dp_is_edp drm/i915/bios: amend child device config parameters drm/i915/bios: document BDB versions of child device config fields drm/i915/bios: remove the raw version of child device config drm/i915/bios: add legacy contents to common child device config drm/i915/bios: throw away high level child device union drm/i915/bios: throw away struct old_child_dev_config drm/i915/bios: document child device config dvo_port values a bit better drm/i915/bios: group device type definitions together drm/i915/bios: throw away unused DVO_* macros drm/i915/bios: drop the rest of the p_ prefixes from pointers drm/i915/bios: split up iboost to hdmi and dp bitfields drm/i915/bios: amend bdb_general_features drm/i915/bios: amend child device flags based on intel_vbt_decode drm/i915/bios: amend edp block based on intel_vbt_decode Merge drm-upstream/drm-next into drm-intel-next-queued drm/i915:
Re: [Intel-gfx] [PATCH] drm/i915: Remove use_mmio_flip modparm
Quoting Maarten Lankhorst (2017-09-21 09:18:55)
> This has been unused since commit afa8ce5b3080
> ("drm/i915: Nuke legacy flip queueing code").
>
> Cc: Chris Wilson
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 3/3] drm/i915: Make i915_modparams members const
On Wed, 20 Sep 2017 15:07:50 +0200, Joonas Lahtinen wrote: On Wed, 2017-09-20 at 15:01 +0300, Jani Nikula wrote: On Wed, 20 Sep 2017, Joonas Lahtinen wrote: > On Tue, 2017-09-19 at 19:38 +, Michal Wajdeczko wrote: > > We should discourage developers from modifying modparams. > > Introduce special macro for easier tracking of changes done > > in modparams and enforce its use by defining existing modparams > > members as const. Note that defining whole modparams struct > > as const makes checkpatch unhappy. > > > > v2: rebased > > > > Credits-to: Coccinelle > > > > @@ > > identifier n; > > expression e; > > @@ > > ( > > - i915_modparams.n = e; > > + i915_modparams_set(n, e); > > Not cool with such a brief name, it really needs to be something more > standing out to make the developer think they've failed design if > they're calling the function. > > 'i915_modparams_force_write' is my current favourite. > > And we need huge kerneldoc comment for the function about the concerns > expressed by Jani, me and Ville. There must be no potential readers for > the variables while they're being changed, compiler optimizations need > to be watched for etc. > > Because really, if we change a module parameter variable while somebody > is for example running a loop based on it, we're in deep problems. > > Might be worthwhile having a i915_modparams_lock to be taken when > sanitization of options begins, and asserting that lock is held when > _force_write() is being called. rw_semaphore sounds like the right > choice here. Many can read but only one can write. > > Any opinions on that? It can't protect against users changing the parameters via sysfs, and I think fixing that at the moment would have an air of overengineering. I'm thinking review and merge patch 1 to fix the i915 name collision, and forget about the rest for now. Agreed on merging, disagreeing on forgetting next steps. Too much controversy, no real rush or pressure to do anything right now beyond patch 1. Don't just do something, stand there. The controversy seemed to be around compiler optimizations, and that doesn't seem to be a worry. The other thing is how to name the function, and that's not too bad discussion. It naturally shouldn't block merging the first patch. If there is an agreement on merging first patch, can someone give it r-b and merge ? Note that this patch is prone to rebase conflicts. Michal Reviewing the places where the modparams get written/read may only lead to improvements as I see it. Any troublesome variables should get moved to device state instead of module state. For example while sanitizing enable_ppgtt and other user requested kernel parameters, we should copy the state to relevant dynamic structures where it'll have an effect, if we actually intend to support changing the parameters on the fly. Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/kms_cursor_legacy: Use gem_mmap__gtt() rather than gem_mmap__wc()
Quoting Ville Syrjala (2017-09-20 17:35:05) > From: Ville Syrjälä > > WC mmaps aren't universally supported, so let's not depend on them when > any kind of mmap will do. We can replace this code now with igt_spin_batch https://patchwork.freedesktop.org/patch/176860/ -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Miscellaneous fixes to reduce dependency for I915_MAX_PIPES
On Fri, 2017-09-15 at 10:58 -0700, Rodrigo Vivi wrote: > On Thu, Sep 14, 2017 at 09:12:50AM +, Patchwork wrote: > > > > == Series Details == > > > > Series: drm/i915: Miscellaneous fixes to reduce dependency for > > I915_MAX_PIPES > > URL : https://patchwork.freedesktop.org/series/30336/ > > State : warning > > > > == Summary == > > > > Test kms_cursor_legacy: > > Subgroup flip-vs-cursor-crc-legacy: > > pass -> SKIP (shard-hsw) > > Subgroup cursor-vs-flip-atomic: > > pass -> SKIP (shard-hsw) > > Test kms_cursor_crc: > > Subgroup cursor-128x128-random: > > pass -> SKIP (shard-hsw) > > Test kms_draw_crc: > > Subgroup draw-method-rgb565-mmap-cpu-xtiled: > > pass -> SKIP (shard-hsw) > I liked the clean-up on this series very much. > And all patches looks good to me. > Only concern I have are this tests here skiping with > > "Test requirement: !(n >= display.n_pipes)" > > So, could you please double check and see if this is > caused by any change in here? I ran the CI tests for three times and every time I received different results. I didn't see these skips on those runs. > > Thanks, > Rodrigo. > > > > > Test kms_flip: > > Subgroup wf_vblank-vs-dpms: > > dmesg-warn -> PASS (shard-hsw) fdo#102614 > > Test gem_flink_race: > > Subgroup flink_close: > > fail -> PASS (shard-hsw) fdo#102655 > > Test perf: > > Subgroup polling: > > fail -> PASS (shard-hsw) fdo#102252 > > Test gem_eio: > > Subgroup in-flight: > > fail -> PASS (shard-hsw) fdo#102616 > > > > fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 > > fdo#102655 https://bugs.freedesktop.org/show_bug.cgi?id=102655 > > fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 > > fdo#102616 https://bugs.freedesktop.org/show_bug.cgi?id=102616 > > > > shard-hswtotal:2313 pass:1242 > > dwarn:0 dfail:0 fail:12 skip:1059 time:9338s > > > > == Logs == > > > > For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patc > > hwork_5692/shards.html > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Mika Kahola - Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] igt/kms_rotation_crc: Add horizontal flip subtest.
On Wed, Sep 20, 2017 at 08:50:37PM -0700, Joseph Garvey wrote:
> Test that horizontal flip works with supported rotations. Includes
> a fix for the unrotated fb which was not being positioned correctly
> with portrait and landscape rectangles.
>
> Signed-off-by: Joseph Garvey
> ---
> lib/igt_kms.c| 2 +-
> lib/igt_kms.h| 4 +
> tests/kms_rotation_crc.c | 197
> ++-
> 3 files changed, 166 insertions(+), 37 deletions(-)
>
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index 7bcafc0..ec6ffd2 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -3054,7 +3054,7 @@ void igt_fb_set_size(struct igt_fb *fb, igt_plane_t
> *plane,
>
> static const char *rotation_name(igt_rotation_t rotation)
> {
> - switch (rotation) {
> + switch (rotation & IGT_ROTATION_MASK) {
> case IGT_ROTATION_0:
> return "0°";
> case IGT_ROTATION_90:
> diff --git a/lib/igt_kms.h b/lib/igt_kms.h
> index 3d1061f..61393d1 100644
> --- a/lib/igt_kms.h
> +++ b/lib/igt_kms.h
> @@ -281,8 +281,12 @@ typedef enum {
> IGT_ROTATION_90 = 1 << 1,
> IGT_ROTATION_180 = 1 << 2,
> IGT_ROTATION_270 = 1 << 3,
> + IGT_REFLECT_X= 1 << 4,
Maybe add REFLECT_Y as well?
> } igt_rotation_t;
>
> +#define IGT_ROTATION_MASK \
> + (IGT_ROTATION_0 | IGT_ROTATION_90 | IGT_ROTATION_180 | IGT_ROTATION_270)
> +
> typedef struct {
> /*< private >*/
> igt_pipe_t *pipe;
> diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
> index 21e264a..0e2df96 100644
> --- a/tests/kms_rotation_crc.c
> +++ b/tests/kms_rotation_crc.c
> @@ -32,6 +32,7 @@ typedef struct {
> igt_display_t display;
> struct igt_fb fb;
> struct igt_fb fb_reference;
> + struct igt_fb fb_unrotated;
> struct igt_fb fb_modeset;
> struct igt_fb fb_flip;
> igt_crc_t ref_crc;
> @@ -43,8 +44,62 @@ typedef struct {
> uint32_t override_fmt;
> uint64_t override_tiling;
> bool flips;
> + int devid;
> } data_t;
>
> +typedef struct {
> + float r;
> + float g;
> + float b;
> +} rgb_color_t;
> +
> +static void set_color(rgb_color_t *color, float r, float g, float b)
> +{
> + color->r = r;
> + color->g = g;
> + color->b = b;
> +}
> +
> +static void rotate_colors(rgb_color_t *tl, rgb_color_t *tr, rgb_color_t *br,
> + rgb_color_t *bl, igt_rotation_t rotation)
> +{
> + rgb_color_t bl_tmp, br_tmp, tl_tmp, tr_tmp;
> +
> + if (rotation & IGT_REFLECT_X) {
> + bl_tmp = *bl;
> + br_tmp = *br;
> + tl_tmp = *tl;
> + tr_tmp = *tr;
> + *tl = tr_tmp;
> + *bl = br_tmp;
> + *tr = tl_tmp;
> + *br = bl_tmp;
These could use igt_swap()
> + }
> +
> + if (rotation & IGT_ROTATION_90) {
> + bl_tmp = *bl;
> + br_tmp = *br;
> + tl_tmp = *tl;
> + tr_tmp = *tr;
> + *tl = tr_tmp;
> + *bl = tl_tmp;
> + *tr = br_tmp;
> + *br = bl_tmp;
> + } else if (rotation & IGT_ROTATION_270) {
> + bl_tmp = *bl;
> + br_tmp = *br;
> + tl_tmp = *tl;
> + tr_tmp = *tr;
> + *tl = bl_tmp;
> + *bl = br_tmp;
> + *tr = tl_tmp;
> + *br = tr_tmp;
> + }
> +}
> +
> +#define RGB_COLOR(color) \
> + color.r, color.g, color.b
> +
> static void
> paint_squares(data_t *data, igt_rotation_t rotation,
> struct igt_fb *fb, float o)
> @@ -52,35 +107,26 @@ paint_squares(data_t *data, igt_rotation_t rotation,
> cairo_t *cr;
> unsigned int w = fb->width;
> unsigned int h = fb->height;
> + rgb_color_t tl, tr, bl, br;
>
> cr = igt_get_cairo_ctx(data->gfx_fd, fb);
>
> - if (rotation == IGT_ROTATION_180) {
> + set_color(&tl, o, 0, 0);
> + set_color(&tr, 0, o, 0);
> + set_color(&br, o, o, o);
> + set_color(&bl, 0, 0, o);
Maybe write the float constants as actual float constants? Would make
it much more clear that it actually takes floats instead of integers.
> +
> + rotate_colors(&tl, &tr, &br, &bl, rotation);
> +
> + if (rotation & IGT_ROTATION_180) {
> cairo_translate(cr, w, h);
> cairo_rotate(cr, M_PI);
> }
This 180 degree special case has always bothered me. Could you remove this
and just do things one way for all angles?
>
> - if (rotation == IGT_ROTATION_90) {
> - /* Paint 4 squares with width == height in Green, White,
> - Blue, Red Clockwise order to look like 270 degree rotated*/
> - igt_paint_color(cr, 0, 0, w / 2, h / 2, 0.0, o, 0.0);
> - igt_paint_color(cr, w / 2, 0, w / 2, h / 2, o, o, o);
> - igt_paint_color(cr, 0, h / 2, w / 2, h / 2, o, 0.0, 0.0);
> - igt_paint_color(cr, w / 2, h / 2, w / 2, h / 2, 0.0, 0.0, o
Re: [Intel-gfx] [PATCH igt] igt/prime_vgem: Split out the fine-grain coherency check
Quoting Michał Winiarski (2017-09-20 11:48:54)
> On Tue, Sep 19, 2017 at 01:21:08PM +0100, Chris Wilson wrote:
> > Quoting Chris Wilson (2017-09-07 15:30:55)
> > > We don't expect every machine to be able to pass the WC/GTT coherency
> > > check, see
> > >
> > > kernel commit 3b5724d702ef24ee41ca008a1fab1cf94f3d31b5
> > > Author: Chris Wilson
> > > Date: Thu Aug 18 17:16:49 2016 +0100
> > >
> > > drm/i915: Wait for writes through the GTT to land before reading back
> > >
> > > If we quickly switch from writing through the GTT to a read of the
> > > physical page directly with the CPU (e.g. performing relocations
> > > through
> > > the GTT and then running the command parser), we can observe that the
> > > writes are not visible to the CPU. It is not a coherency problem, as
> > > extensive investigations with clflush have demonstrated, but a mere
> > > timing issue - we have to wait for the GTT to complete it's write
> > > before
> > > we start our read from the CPU.
> > >
> > > The issue can be illustrated in userspace with:
> > >
> > > gtt = gem_mmap__gtt(fd, handle, 0, OBJECT_SIZE, PROT_READ |
> > > PROT_WRITE);
> > > cpu = gem_mmap__cpu(fd, handle, 0, OBJECT_SIZE, PROT_READ |
> > > PROT_WRITE);
> > > gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT,
> > > I915_GEM_DOMAIN_GTT);
> > >
> > > for (i = 0; i < OBJECT_SIZE / 64; i++) {
> > > int x = 16*i + (i%16);
> > > gtt[x] = i;
> > > clflush(&cpu[x], sizeof(cpu[x]));
> > > assert(cpu[x] == i);
> > > }
> > >
> > > Experimenting with that shows that this behaviour is indeed limited to
> > > recent Atom-class hardware.
> > >
> > > so split out the interleave coherency check from the basic
> > > interopability check.
> > >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102577
> > > Signed-off-by: Chris Wilson
> >
> > Ping?
>
> Mechanical change. LGTM.
> One question though - if we do expect that coherency-gtt may fail on low-power
> HW, perhaps we should skip it there, rather than filter through the noisy
> results?
I don't know for sure; the test is a good discriminator for which
platforms do need extra care (and so far big core seems reliable).
> OTOH, determining test behaviour based on particular "device id" (generation
> really), rather than some "capability" is kind of ugly.
Yup. And such knowledge should flow from the kernel "hey, on this
platform this ABI expectation can no longer be met".
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Document the split in internal and public execbuf flags
Since we reuse the same field for the user passing in their control
flags, and for the kernel to track a couple of bits of state, document
and check that those do not overlap.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index e962a0111b5e..163d71c9abdb 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -58,6 +58,7 @@ enum {
#define __EXEC_HAS_RELOC BIT(31)
#define __EXEC_VALIDATED BIT(30)
+#define __EXEC_INTERNAL_FLAGS (~0u << 30)
#define UPDATE PIN_OFFSET_FIXED
#define BATCH_OFFSET_BIAS (256*1024)
@@ -2185,6 +2186,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
int out_fence_fd = -1;
int err;
+ BUILD_BUG_ON(__EXEC_INTERNAL_FLAGS & ~__I915_EXEC_ILLEGAL_FLAGS);
BUILD_BUG_ON(__EXEC_OBJECT_INTERNAL_FLAGS &
~__EXEC_OBJECT_UNKNOWN_FLAGS);
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 25/29] drm/i915: Stop frobbing with DDI encoder->type
From: Ville Syrjälä
Currently the DDI encoder->type will change at runtime depending on
what kind of hotplugs we've processed. That's quite bad since we can't
really trust that that current value of encoder->type actually matches
the type of signal we're trying to drive through it.
Let's eliminate that problem by declaring that non-eDP DDI port will
always have the encoder type as INTEL_OUTPUT_DDI. This means the code
can no longer try to distinguish DP vs. HDMI based on encoder->type.
We'll eDP as INTEL_OUTPUT_EDP, since it'll never change and there's a
bunch of code that relies on that value to identofy eDP.
We'll introduce a new encoder .compute_output_type() hook. This allows
us to compute the full output_types before any encoder .compute_config()
hooks get called, thus those hooks can rely on output_types being
correct, which is useful for cloning on oldr platforms. For now we'll
just look at the connector type and pick the correct mode based on that.
In the future the new hook could be used to implement dynamic switching
between LS and PCON modes for LSPCON.
TODO: maybe make .get_config() populate output_types rather than doing
the default encoder->type thing in caller and then undoing it for
DDI in .get_config().
v2: Fix BXT/GLK PPS explosion with DSI/MST encoders
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/intel_ddi.c | 49 +--
drivers/gpu/drm/i915/intel_display.c | 11 +---
drivers/gpu/drm/i915/intel_dp.c | 15 ++-
drivers/gpu/drm/i915/intel_drv.h | 7 +++--
drivers/gpu/drm/i915/intel_hdmi.c | 10 ++-
drivers/gpu/drm/i915/intel_opregion.c | 2 +-
7 files changed, 60 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index ca6fa6d122c6..73601464240d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3053,7 +3053,7 @@ static void intel_connector_info(struct seq_file *m,
break;
case DRM_MODE_CONNECTOR_HDMIA:
if (intel_encoder->type == INTEL_OUTPUT_HDMI ||
- intel_encoder->type == INTEL_OUTPUT_UNKNOWN)
+ intel_encoder->type == INTEL_OUTPUT_DDI)
intel_hdmi_info(m, intel_connector);
break;
default:
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index d625bfe6d420..e93ed0d31738 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -497,10 +497,8 @@ enum port intel_ddi_get_encoder_port(struct intel_encoder
*encoder)
switch (encoder->type) {
case INTEL_OUTPUT_DP_MST:
return enc_to_mst(&encoder->base)->primary->port;
- case INTEL_OUTPUT_DP:
case INTEL_OUTPUT_EDP:
- case INTEL_OUTPUT_HDMI:
- case INTEL_OUTPUT_UNKNOWN:
+ case INTEL_OUTPUT_DDI:
return enc_to_dig_port(&encoder->base)->port;
case INTEL_OUTPUT_ANALOG:
return PORT_E;
@@ -1516,6 +1514,7 @@ void intel_ddi_set_vc_payload_alloc(const struct
intel_crtc_state *crtc_state,
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
uint32_t temp;
+
temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (state == true)
temp |= TRANS_DDI_DP_VC_PAYLOAD_ALLOC;
@@ -2489,6 +2488,13 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
struct intel_digital_port *intel_dig_port;
u32 temp, flags = 0;
+ /*
+* Can be set by the caller based on encoder->type.
+* Undo that since we don't want INTEL_OUTPUT_DDI
+* to appear in output_types.
+*/
+ pipe_config->output_types &= ~BIT(INTEL_OUTPUT_DDI);
+
/* XXX: DSI transcoder paranoia */
if (WARN_ON(transcoder_is_dsi(cpu_transcoder)))
return;
@@ -2537,12 +2543,23 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
pipe_config->hdmi_high_tmds_clock_ratio = true;
/* fall through */
case TRANS_DDI_MODE_SELECT_DVI:
+ pipe_config->output_types |= BIT(INTEL_OUTPUT_HDMI);
pipe_config->lane_count = 4;
break;
case TRANS_DDI_MODE_SELECT_FDI:
+ pipe_config->output_types |= BIT(INTEL_OUTPUT_ANALOG);
break;
case TRANS_DDI_MODE_SELECT_DP_SST:
+ if (encoder->type == INTEL_OUTPUT_EDP)
+ pipe_config->output_types |= BIT(INTEL_OUTPUT_EDP);
+ else
+ pipe_config->output_types |= BIT(INTEL_OUTPUT_DP);
+ pipe_config->lane_count =
+ ((temp & DDI_PORT_WIDTH_MASK) >> DDI_PORT_WIDTH_SHIFT)
+ 1;
+ intel_dp_get_m_n(intel_crtc, pip
Re: [Intel-gfx] [PATCH v6 3/3] drm/i915: Make i915_modparams members const
On Wed, 20 Sep 2017, Joonas Lahtinen wrote: > On Wed, 2017-09-20 at 15:01 +0300, Jani Nikula wrote: >> On Wed, 20 Sep 2017, Joonas Lahtinen wrote: >> > On Tue, 2017-09-19 at 19:38 +, Michal Wajdeczko wrote: >> > > We should discourage developers from modifying modparams. >> > > Introduce special macro for easier tracking of changes done >> > > in modparams and enforce its use by defining existing modparams >> > > members as const. Note that defining whole modparams struct >> > > as const makes checkpatch unhappy. >> > > >> > > v2: rebased >> > > >> > > Credits-to: Coccinelle >> > > >> > > @@ >> > > identifier n; >> > > expression e; >> > > @@ >> > > ( >> > > -i915_modparams.n = e; >> > > +i915_modparams_set(n, e); >> > >> > Not cool with such a brief name, it really needs to be something more >> > standing out to make the developer think they've failed design if >> > they're calling the function. >> > >> > 'i915_modparams_force_write' is my current favourite. >> > >> > And we need huge kerneldoc comment for the function about the concerns >> > expressed by Jani, me and Ville. There must be no potential readers for >> > the variables while they're being changed, compiler optimizations need >> > to be watched for etc. >> > >> > Because really, if we change a module parameter variable while somebody >> > is for example running a loop based on it, we're in deep problems. >> > >> > Might be worthwhile having a i915_modparams_lock to be taken when >> > sanitization of options begins, and asserting that lock is held when >> > _force_write() is being called. rw_semaphore sounds like the right >> > choice here. Many can read but only one can write. >> > >> > Any opinions on that? >> >> It can't protect against users changing the parameters via sysfs, and I >> think fixing that at the moment would have an air of overengineering. >> >> I'm thinking review and merge patch 1 to fix the i915 name collision, >> and forget about the rest for now. > > Agreed on merging, disagreeing on forgetting next steps. > >> Too much controversy, no real rush or >> pressure to do anything right now beyond patch 1. Don't just do >> something, stand there. > > The controversy seemed to be around compiler optimizations, and that > doesn't seem to be a worry. The other thing is how to name the > function, and that's not too bad discussion. It naturally shouldn't > block merging the first patch. It's not just that. > Reviewing the places where the modparams get written/read may only lead > to improvements as I see it. Any troublesome variables should get moved > to device state instead of module state. For example while sanitizing > enable_ppgtt and other user requested kernel parameters, we should copy > the state to relevant dynamic structures where it'll have an effect, if > we actually intend to support changing the parameters on the fly. Please figure out the alternatives to changing module parameters first. The hurdles introduced in patch 3 aren't going to stop anyone from adding new ones. I'm not going to tell anyone to stop doing that until I have a better idea what to do *instead*. Overall I'm more concerned about the insane total number of module parameters that we have. We have them primarily because they are *convenient*, and they are pretty much the only way to force some behaviour on module probe. Anything you put in i915 debugfs or sysfs is going to be much less convenient for debugging. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Document the split in internal and public execbuf flags
On 21/09/2017 12:01, Chris Wilson wrote:
Since we reuse the same field for the user passing in their control
flags, and for the kernel to track a couple of bits of state, document
and check that those do not overlap.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index e962a0111b5e..163d71c9abdb 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -58,6 +58,7 @@ enum {
#define __EXEC_HAS_RELOC BIT(31)
#define __EXEC_VALIDATED BIT(30)
+#define __EXEC_INTERNAL_FLAGS (~0u << 30)
#define UPDATEPIN_OFFSET_FIXED
#define BATCH_OFFSET_BIAS (256*1024)
@@ -2185,6 +2186,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
int out_fence_fd = -1;
int err;
+ BUILD_BUG_ON(__EXEC_INTERNAL_FLAGS & ~__I915_EXEC_ILLEGAL_FLAGS);
BUILD_BUG_ON(__EXEC_OBJECT_INTERNAL_FLAGS &
~__EXEC_OBJECT_UNKNOWN_FLAGS);
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dim: Accept author x signed-off based on email.
On Wed, 20 Sep 2017, Rodrigo Vivi wrote: > It seems Patchwork or SMTP servers are messing some patches > and changing the original git's author name on git per "Last, First". > So we end up with a mismatch were signed-off uses one name format > and author is using another format. > > So, let's check for email addresses instead. > > v2: Avoid useles warning and only check for email. > > Cc: Jani Nikula > Cc: Joonas Lahtinen > Signed-off-by: Rodrigo Vivi Reviewed-by: Jani Nikula > --- > dim | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dim b/dim > index dbaeb1ec944d..a63000fb67a8 100755 > --- a/dim > +++ b/dim > @@ -689,7 +689,7 @@ function checkpatch_commit_push > sha1=$1 > > # use real names for people with many different email addresses > - author=$(git show -s $sha1 --format="format:%an") > + author=$(git show -s $sha1 --format="format:%ae") > committer=$(git show -s $sha1 --format="format:%cn") > > # check for author sign-off -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] igt/kms_cursor_legacy: Use common spinbatch
On Thu, Sep 14, 2017 at 02:19:34PM +0100, Chris Wilson wrote:
> Remove the local recursive spinner in favour of igt_spin_t.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Ville Syrjälä
> ---
> tests/kms_cursor_legacy.c | 103
> --
> 1 file changed, 9 insertions(+), 94 deletions(-)
>
> diff --git a/tests/kms_cursor_legacy.c b/tests/kms_cursor_legacy.c
> index 2d32d3a9..fb365f12 100644
> --- a/tests/kms_cursor_legacy.c
> +++ b/tests/kms_cursor_legacy.c
> @@ -490,92 +490,6 @@ enum basic_flip_cursor {
> FLIP_AFTER_CURSOR
> };
>
> -static uint32_t *make_busy(int fd, uint32_t target)
> -{
> - const int gen = intel_gen(intel_get_drm_devid(fd));
> - struct drm_i915_gem_exec_object2 obj[2];
> - struct drm_i915_gem_relocation_entry reloc[2];
> - struct drm_i915_gem_execbuffer2 execbuf;
> - uint32_t *batch;
> - int i;
> -
> - memset(&execbuf, 0, sizeof(execbuf));
> - execbuf.buffers_ptr = (uintptr_t)obj;
> - execbuf.buffer_count = 2;
> -
> - memset(obj, 0, sizeof(obj));
> - obj[0].handle = target;
> - obj[1].handle = gem_create(fd, 4096);
> - batch = gem_mmap__wc(fd, obj[1].handle, 0, 4096, PROT_WRITE);
> - gem_set_domain(fd, obj[1].handle,
> - I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
> -
> -
> - obj[1].relocs_ptr = (uintptr_t)reloc;
> - obj[1].relocation_count = 2;
> - memset(reloc, 0, sizeof(reloc));
> -
> - reloc[0].target_handle = obj[1].handle; /* recurse */
> - reloc[0].presumed_offset = 0;
> - reloc[0].offset = sizeof(uint32_t);
> - reloc[0].delta = 0;
> - reloc[0].read_domains = I915_GEM_DOMAIN_COMMAND;
> - reloc[0].write_domain = 0;
> -
> - reloc[1].target_handle = target;
> - reloc[1].presumed_offset = 0;
> - reloc[1].offset = 1024;
> - reloc[1].delta = 0;
> - reloc[1].read_domains = I915_GEM_DOMAIN_COMMAND;
> - reloc[1].write_domain = I915_GEM_DOMAIN_COMMAND;
> -
> - i = 0;
> - batch[i] = MI_BATCH_BUFFER_START;
> - if (gen >= 8) {
> - batch[i] |= 1 << 8 | 1;
> - batch[++i] = 0;
> - batch[++i] = 0;
> - } else if (gen >= 6) {
> - batch[i] |= 1 << 8;
> - batch[++i] = 0;
> - } else {
> - batch[i] |= 2 << 6;
> - batch[++i] = 0;
> - if (gen < 4) {
> - batch[i] |= 1;
> - reloc[0].delta = 1;
> - }
> - }
> - i++;
> -
> - gem_execbuf(fd, &execbuf);
> - gem_close(fd, obj[1].handle);
> -
> - return batch;
> -}
> -
> -static void cancel_busy(uint32_t *busy)
> -{
> - *busy = MI_BATCH_BUFFER_END;
> - munmap(busy, 4096);
> -}
> -
> -static uint32_t *
> -make_fb_busy(int fd, const struct igt_fb *fb)
> -{
> - uint32_t *busy;
> -
> - busy = make_busy(fd, fb->gem_handle);
> - igt_assert(gem_bo_busy(fd, fb->gem_handle));
> -
> - return busy;
> -}
> -
> -static void finish_fb_busy(uint32_t *busy)
> -{
> - cancel_busy(busy);
> -}
> -
> #define BASIC_BUSY 0x1
>
> static void basic_flip_cursor(igt_display_t *display,
> @@ -588,7 +502,7 @@ static void basic_flip_cursor(igt_display_t *display,
> struct igt_fb fb_info, cursor_fb, cursor_fb2, argb_fb;
> unsigned vblank_start;
> enum pipe pipe = find_connected_pipe(display, false);
> - uint32_t *busy;
> + igt_spin_t *spin;
> int i, miss1 = 0, miss2 = 0, delta;
>
> if (mode >= flip_test_atomic)
> @@ -616,9 +530,9 @@ static void basic_flip_cursor(igt_display_t *display,
> /* Bind the cursor first to warm up */
> do_ioctl(display->drm_fd, DRM_IOCTL_MODE_CURSOR, &arg[0]);
>
> - busy = NULL;
> + spin = NULL;
> if (flags & BASIC_BUSY)
> - busy = make_fb_busy(display->drm_fd, &fb_info);
> + spin = igt_spin_batch_new(display->drm_fd, 0, 0,
> fb_info.gem_handle);
>
> /* Start with a synchronous query to align with the vblank */
> vblank_start = get_vblank(display->drm_fd, pipe,
> DRM_VBLANK_NEXTONMISS);
> @@ -660,10 +574,10 @@ static void basic_flip_cursor(igt_display_t *display,
>
> delta = get_vblank(display->drm_fd, pipe, 0) - vblank_start;
>
> - if (busy) {
> + if (spin) {
> struct pollfd pfd = { display->drm_fd, POLLIN };
> igt_assert(poll(&pfd, 1, 0) == 0);
> - finish_fb_busy(busy);
> + igt_spin_batch_free(display->drm_fd, spin);
> }
>
> if (miss)
> @@ -1373,9 +1287,10 @@ static void flip_vs_cursor_busy_crc(igt_display_t
> *display, bool atomic)
>
> /* Disable cursor, and immediately queue a flip. Check if resulting crc
> is correct. */
> for (int i = 1; i >= 0; i--) {
> - uint32_t *busy;
> + igt_spin_t *spin;
Re: [Intel-gfx] [PATCH] drm/i915: Remove use_mmio_flip modparm
On Thu, 21 Sep 2017, Chris Wilson wrote:
> Quoting Maarten Lankhorst (2017-09-21 09:18:55)
>> This has been unused since commit afa8ce5b3080
>> ("drm/i915: Nuke legacy flip queueing code").
>>
>> Cc: Chris Wilson
>> Signed-off-by: Maarten Lankhorst
> Reviewed-by: Chris Wilson
\o/-by: Jani Nikula
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] igt/kms_rotation_crc : Fix flip tests for sprite plane
Thanks Maarten,
Tested-by: Marta Lofstedt
Acked-by: Marta Lofstedt
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Maarten Lankhorst
> Sent: Thursday, September 21, 2017 9:38 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH i-g-t] igt/kms_rotation_crc : Fix flip tests for
> sprite
> plane
>
> This test was flipping the primary plane instead of the sprite plane.
> Flip the correct plane to make the test pass properly.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102691
> Signed-off-by: Maarten Lankhorst
> ---
> Resend for CI.
>
> tests/kms_rotation_crc.c | 23 +--
> 1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c index
> 21e264addc09..69301252bda1 100644
> --- a/tests/kms_rotation_crc.c
> +++ b/tests/kms_rotation_crc.c
> @@ -332,6 +332,9 @@ static void test_plane_rotation(data_t *data, int
> plane_type)
> enum igt_commit_style commit = COMMIT_LEGACY;
> int ret;
>
> + if (data->flips && plane_type != DRM_PLANE_TYPE_PRIMARY)
> + igt_require(data->display.is_atomic);
> +
> if (plane_type == DRM_PLANE_TYPE_PRIMARY || plane_type
> == DRM_PLANE_TYPE_CURSOR)
> commit = COMMIT_UNIVERSAL;
>
> @@ -390,12 +393,20 @@ static void test_plane_rotation(data_t *data, int
> plane_type)
>* check CRC against that one as
> well.
>*/
> if (data->flips) {
> - ret =
> drmModePageFlip(data->gfx_fd,
> -
> output->config.crtc->crtc_id,
> -
> data->fb_flip.fb_id,
> -
> DRM_MODE_PAGE_FLIP_EVENT,
> -
> NULL);
> - igt_assert_eq(ret,
> 0);
> +
> igt_plane_set_fb(plane, &data->fb_flip);
> + if (data->rotation
> == IGT_ROTATION_90 || data->rotation == IGT_ROTATION_270)
> +
> igt_plane_set_size(plane, data->fb.height, data->fb.width);
> +
> + if (plane_type !=
> DRM_PLANE_TYPE_PRIMARY) {
> +
> igt_display_commit_atomic(display,
> DRM_MODE_PAGE_FLIP_EVENT | DRM_MODE_ATOMIC_NONBLOCK,
> NULL);
> + } else {
> + ret =
> drmModePageFlip(data->gfx_fd,
> +
> output->config.crtc->crtc_id,
> +
> data->fb_flip.fb_id,
> +
> DRM_MODE_PAGE_FLIP_EVENT,
> +
> NULL);
> +
> igt_assert_eq(ret, 0);
> + }
>
> wait_for_pageflip(data->gfx_fd);
>
> igt_pipe_crc_collect_crc(data->pipe_crc,
>
>&crc_output);
> --
> 2.14.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] igt/prime_vgem: Split out the fine-grain coherency check
On Thu, Sep 21, 2017 at 11:59:29AM +0100, Chris Wilson wrote:
> Quoting Michał Winiarski (2017-09-20 11:48:54)
> > On Tue, Sep 19, 2017 at 01:21:08PM +0100, Chris Wilson wrote:
> > > Quoting Chris Wilson (2017-09-07 15:30:55)
> > > > We don't expect every machine to be able to pass the WC/GTT coherency
> > > > check, see
> > > >
> > > > kernel commit 3b5724d702ef24ee41ca008a1fab1cf94f3d31b5
> > > > Author: Chris Wilson
> > > > Date: Thu Aug 18 17:16:49 2016 +0100
> > > >
> > > > drm/i915: Wait for writes through the GTT to land before reading
> > > > back
> > > >
> > > > If we quickly switch from writing through the GTT to a read of the
> > > > physical page directly with the CPU (e.g. performing relocations
> > > > through
> > > > the GTT and then running the command parser), we can observe that
> > > > the
> > > > writes are not visible to the CPU. It is not a coherency problem, as
> > > > extensive investigations with clflush have demonstrated, but a mere
> > > > timing issue - we have to wait for the GTT to complete it's write
> > > > before
> > > > we start our read from the CPU.
> > > >
> > > > The issue can be illustrated in userspace with:
> > > >
> > > > gtt = gem_mmap__gtt(fd, handle, 0, OBJECT_SIZE, PROT_READ |
> > > > PROT_WRITE);
> > > > cpu = gem_mmap__cpu(fd, handle, 0, OBJECT_SIZE, PROT_READ |
> > > > PROT_WRITE);
> > > > gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT,
> > > > I915_GEM_DOMAIN_GTT);
> > > >
> > > > for (i = 0; i < OBJECT_SIZE / 64; i++) {
> > > > int x = 16*i + (i%16);
> > > > gtt[x] = i;
> > > > clflush(&cpu[x], sizeof(cpu[x]));
> > > > assert(cpu[x] == i);
> > > > }
> > > >
> > > > Experimenting with that shows that this behaviour is indeed limited
> > > > to
> > > > recent Atom-class hardware.
> > > >
> > > > so split out the interleave coherency check from the basic
> > > > interopability check.
> > > >
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102577
> > > > Signed-off-by: Chris Wilson
> > >
> > > Ping?
> >
> > Mechanical change. LGTM.
> > One question though - if we do expect that coherency-gtt may fail on
> > low-power
> > HW, perhaps we should skip it there, rather than filter through the noisy
> > results?
>
> I don't know for sure; the test is a good discriminator for which
> platforms do need extra care (and so far big core seems reliable).
>
> > OTOH, determining test behaviour based on particular "device id" (generation
> > really), rather than some "capability" is kind of ugly.
>
> Yup. And such knowledge should flow from the kernel "hey, on this
> platform this ABI expectation can no longer be met".
> -Chris
Reviewed-by: Michał Winiarski
-Michał
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/i915: Make own struct for execlist items
On Wed, Sep 20, 2017 at 05:36:58PM +0300, Mika Kuoppala wrote: > Engine's execlist related items have been increasing to > a point where a separate struct is warranted. Carve execlist > specific items to a dedicated struct to add clarity. > > v2: add kerneldoc and fix whitespace (Joonas, Chris) > v3: csb_mmio changes, rebase > > Suggested-by: Chris Wilson > Cc: Chris Wilson > Cc: Joonas Lahtinen > Signed-off-by: Mika Kuoppala > Acked-by: Joonas Lahtinen Reviewed-by: Michał Winiarski -Michał > --- > drivers/gpu/drm/i915/i915_debugfs.c| 8 +-- > drivers/gpu/drm/i915/i915_gem.c| 6 +- > drivers/gpu/drm/i915/i915_gpu_error.c | 4 +- > drivers/gpu/drm/i915/i915_guc_submission.c | 31 + > drivers/gpu/drm/i915/i915_irq.c| 5 +- > drivers/gpu/drm/i915/intel_engine_cs.c | 12 ++-- > drivers/gpu/drm/i915/intel_lrc.c | 100 > +++-- > drivers/gpu/drm/i915/intel_ringbuffer.h| 100 > +++-- > 8 files changed, 167 insertions(+), 99 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v6,1/3] drm/i915: Rename global i915 to i915_modparams
== Series Details == Series: series starting with [v6,1/3] drm/i915: Rename global i915 to i915_modparams URL : https://patchwork.freedesktop.org/series/30621/ State : warning == Summary == Series 30621v1 series starting with [v6,1/3] drm/i915: Rename global i915 to i915_modparams https://patchwork.freedesktop.org/api/1.0/series/30621/revisions/1/mbox/ Test gem_ringfill: Subgroup basic-default-hang: pass -> DMESG-WARN (fi-pnv-d510) fdo#101600 Test kms_addfb_basic: Subgroup tile-pitch-mismatch: pass -> DMESG-WARN (fi-kbl-7500u) Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> INCOMPLETE (fi-kbl-7500u) fdo#102850 fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#102850 https://bugs.freedesktop.org/show_bug.cgi?id=102850 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:444s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:469s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:423s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:513s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:280s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:512s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:499s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:495s fi-cfl-s total:289 pass:222 dwarn:35 dfail:0 fail:0 skip:32 time:546s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:420s fi-glk-1 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:573s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:428s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:412s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:438s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:506s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:468s fi-kbl-7500u total:245 pass:222 dwarn:2 dfail:0 fail:0 skip:20 fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:585s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:590s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:546s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:463s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:756s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:493s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:483s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:573s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:1 skip:39 time:419s bed15796ff696a0a77324b69cfad9e61b50a70a4 drm-tip: 2017y-09m-20d-20h-05m-31s UTC integration manifest 7c9afa5ffe5f drm/i915: Make i915_modparams members const 955a70cc8998 drm/i915: Prepare error capture to work with const modparams 7b9cb66de358 drm/i915: Rename global i915 to i915_modparams == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5775/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/8] drm/i915: Keep track of reserved execlist ports
Mika Kuoppala writes:
> To further enchance port processing, keep track of
> reserved ports. This way we can iterate only the used subset
> of port space. Note that we lift the responsibility of
> execlists_submit_request() to inspect hw availability and
s/execlist_submit_request/insert_request.
-Mika
> always do dequeuing. This is to ensure that only the irq
> handler will be responsible for keeping track of available ports.
>
> v2: rebase, comment fix, READ_ONCE only outside of irq handler (Chris)
>
> Cc: Chris Wilson
> Cc: Michał Winiarski
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_guc_submission.c | 51 +
> drivers/gpu/drm/i915/i915_irq.c| 2 +-
> drivers/gpu/drm/i915/intel_engine_cs.c | 7 ++-
> drivers/gpu/drm/i915/intel_lrc.c | 90
> ++
> drivers/gpu/drm/i915/intel_ringbuffer.h| 55 +-
> 5 files changed, 129 insertions(+), 76 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
> b/drivers/gpu/drm/i915/i915_guc_submission.c
> index 25c9bac94c39..359f57a59cba 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -487,7 +487,7 @@ static void guc_ring_doorbell(struct i915_guc_client
> *client)
> * @engine: engine associated with the commands
> *
> * The only error here arises if the doorbell hardware isn't functioning
> - * as expected, which really shouln't happen.
> + * as expected, which really shouldn't happen.
> */
> static void i915_guc_submit(struct intel_engine_cs *engine)
> {
> @@ -495,17 +495,19 @@ static void i915_guc_submit(struct intel_engine_cs
> *engine)
> struct intel_guc *guc = &dev_priv->guc;
> struct i915_guc_client *client = guc->execbuf_client;
> struct intel_engine_execlist * const el = &engine->execlist;
> - struct execlist_port *port = el->port;
> const unsigned int engine_id = engine->id;
> unsigned int n;
>
> - for (n = 0; n < ARRAY_SIZE(el->port); n++) {
> + for (n = 0; n < execlist_active_ports(el); n++) {
> + struct execlist_port *port;
> struct drm_i915_gem_request *rq;
> unsigned int count;
>
> - rq = port_unpack(&port[n], &count);
> + port = execlist_port_index(el, n);
> +
> + rq = port_unpack(port, &count);
> if (rq && count == 0) {
> - port_set(&port[n], port_pack(rq, ++count));
> + port_set(port, port_pack(rq, ++count));
>
> if (i915_vma_is_map_and_fenceable(rq->ring->vma))
> POSTING_READ_FW(GUC_STATUS);
> @@ -560,25 +562,27 @@ static void port_assign(struct execlist_port *port,
> static void i915_guc_dequeue(struct intel_engine_cs *engine)
> {
> struct intel_engine_execlist * const el = &engine->execlist;
> - struct execlist_port *port = el->port;
> + struct execlist_port *port;
> struct drm_i915_gem_request *last = NULL;
> - const struct execlist_port * const last_port = execlist_port_tail(el);
> bool submit = false;
> struct rb_node *rb;
>
> - if (port_isset(port))
> - port++;
> -
> spin_lock_irq(&engine->timeline->lock);
> rb = el->first;
> GEM_BUG_ON(rb_first(&el->queue) != rb);
> - while (rb) {
> +
> + if (unlikely(!rb))
> + goto done;
> +
> + port = execlist_request_port(el);
> +
> + do {
> struct i915_priolist *p = rb_entry(rb, typeof(*p), node);
> struct drm_i915_gem_request *rq, *rn;
>
> list_for_each_entry_safe(rq, rn, &p->requests, priotree.link) {
> if (last && rq->ctx != last->ctx) {
> - if (port == last_port) {
> + if (!execlist_inactive_ports(el)) {
> __list_del_many(&p->requests,
> &rq->priotree.link);
> goto done;
> @@ -587,7 +591,8 @@ static void i915_guc_dequeue(struct intel_engine_cs
> *engine)
> if (submit)
> port_assign(port, last);
>
> - port = execlist_port_next(el, port);
> + port = execlist_request_port(el);
> + GEM_BUG_ON(port_isset(port));
> }
>
> INIT_LIST_HEAD(&rq->priotree.link);
> @@ -604,7 +609,7 @@ static void i915_guc_dequeue(struct intel_engine_cs
> *engine)
> INIT_LIST_HEAD(&p->requests);
> if (p->priority != I915_PRIORITY_NORMAL)
> kmem_cache_free(engine->i915->priorities, p);
> - }
> + } while (rb);
> done:
> el->first = rb;
> if (submit) {
> @@ -618,21 +623,21 @@ static void
Re: [Intel-gfx] [PATCH 3/8] drm/i915: Wrap port cancellation into a function
On Wed, Sep 20, 2017 at 05:37:00PM +0300, Mika Kuoppala wrote:
> On reset and wedged path, we want to release the requests
> that are tied to ports and then mark the ports to be unset.
> Introduce a function for this.
>
> v2: rebase
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 21 -
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index a4ece4c4f291..ffb9c900328b 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -568,6 +568,16 @@ static void execlists_dequeue(struct intel_engine_cs
> *engine)
> execlists_submit_ports(engine);
> }
>
> +static void execlist_cancel_port_requests(struct intel_engine_execlist *el)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(el->port); i++)
> + i915_gem_request_put(port_request(&el->port[i]));
> +
> + memset(el->port, 0, sizeof(el->port));
> +}
> +
> static void execlists_cancel_requests(struct intel_engine_cs *engine)
> {
> struct intel_engine_execlist * const el = &engine->execlist;
> @@ -575,14 +585,11 @@ static void execlists_cancel_requests(struct
> intel_engine_cs *engine)
> struct drm_i915_gem_request *rq, *rn;
> struct rb_node *rb;
> unsigned long flags;
> - unsigned long n;
>
> spin_lock_irqsave(&engine->timeline->lock, flags);
>
> /* Cancel the requests on the HW and clear the ELSP tracker. */
> - for (n = 0; n < ARRAY_SIZE(el->port); n++)
> - i915_gem_request_put(port_request(&port[n]));
We could also drop the local variable for port.
It's only used in GEM_BUG_ON(port_isset(&port[0])).
Do we even need this assert when we're starting to treat ports in a more
ring-like fashion?
Reviewed-by: Michał Winiarski
-Michał
> - memset(el->port, 0, sizeof(el->port));
> + execlist_cancel_port_requests(el);
>
> /* Mark all executing requests as skipped. */
> list_for_each_entry(rq, &engine->timeline->requests, link) {
> @@ -1372,11 +1379,9 @@ static void reset_common_ring(struct intel_engine_cs
> *engine,
> struct drm_i915_gem_request *request)
> {
> struct intel_engine_execlist * const el = &engine->execlist;
> - struct execlist_port *port = el->port;
> struct drm_i915_gem_request *rq, *rn;
> struct intel_context *ce;
> unsigned long flags;
> - unsigned int n;
>
> spin_lock_irqsave(&engine->timeline->lock, flags);
>
> @@ -1389,9 +1394,7 @@ static void reset_common_ring(struct intel_engine_cs
> *engine,
>* guessing the missed context-switch events by looking at what
>* requests were completed.
>*/
> - for (n = 0; n < ARRAY_SIZE(el->port); n++)
> - i915_gem_request_put(port_request(&port[n]));
> - memset(el->port, 0, sizeof(el->port));
> + execlist_cancel_port_requests(el);
>
> /* Push back any incomplete requests for replay after the reset. */
> list_for_each_entry_safe_reverse(rq, rn,
> --
> 2.11.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 1/8] drm/i915: Make own struct for execlist items
Quoting Mika Kuoppala (2017-09-20 15:36:58) > Engine's execlist related items have been increasing to > a point where a separate struct is warranted. Carve execlist > specific items to a dedicated struct to add clarity. > > v2: add kerneldoc and fix whitespace (Joonas, Chris) > v3: csb_mmio changes, rebase > > Suggested-by: Chris Wilson > Cc: Chris Wilson > Cc: Joonas Lahtinen > Signed-off-by: Mika Kuoppala > Acked-by: Joonas Lahtinen Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/8] drm/i915: Move execlist initialization into intel_engine_cs.c
Quoting Mika Kuoppala (2017-09-20 15:36:59) > Move execlist init into a common engine setup. As it is > common to both guc and hw execlists. > > v2: rebase with csb changes > > Signed-off-by: Mika Kuoppala Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/8] drm/i915: Wrap port cancellation into a function
Quoting Mika Kuoppala (2017-09-20 15:37:00) > On reset and wedged path, we want to release the requests > that are tied to ports and then mark the ports to be unset. > Introduce a function for this. > > v2: rebase > > Cc: Chris Wilson > Signed-off-by: Mika Kuoppala Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/8] drm/i915: Add execlist_port_complete
Quoting Mika Kuoppala (2017-09-20 15:37:01) > When first execlist entry is processed, we move the port (contents). > Introduce function for this as execlist and guc use this common > operation. > > v2: rebase. s/GEM_DEBUG_BUG/GEM_BUG (Chris) > > Signed-off-by: Mika Kuoppala Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/8] drm/i915: Make execlist port count variable
Quoting Mika Kuoppala (2017-09-20 15:37:02) > As we emulate execlists on top of the GuC workqueue, it is not > restricted to just 2 ports and we can increase that number arbitrarily > to trade-off queue depth (i.e. scheduling latency) against pipeline > bubbles. > > v2: rebase. better commit msg (Chris) > > Signed-off-by: Mika Kuoppala Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/i915: Introduce execlist_port_* accessors
Quoting Mika Kuoppala (2017-09-20 15:37:03)
> Instead of trusting that first available port is at index 0,
> use accessor to hide this. This is a preparation for a
> following patches where head can be at arbitrary location
> in the port array.
>
> v2: improved commit message, elsp_ready readability (Chris)
>
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_debugfs.c| 16 +++
> drivers/gpu/drm/i915/i915_gpu_error.c | 4 +--
> drivers/gpu/drm/i915/i915_guc_submission.c | 17 ++-
> drivers/gpu/drm/i915/i915_irq.c| 2 +-
> drivers/gpu/drm/i915/intel_engine_cs.c | 2 +-
> drivers/gpu/drm/i915/intel_lrc.c | 42 +++
> drivers/gpu/drm/i915/intel_ringbuffer.h| 46
> ++
> 7 files changed, 87 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index dbeb6f08ab79..af8cc2eab1b1 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3348,16 +3348,20 @@ static int i915_engine_info(struct seq_file *m, void
> *unused)
>
> rcu_read_lock();
> for (idx = 0; idx < execlist_num_ports(el); idx++) {
> - unsigned int count;
> + const struct execlist_port *port;
> + unsigned int count, n;
>
> - rq = port_unpack(&el->port[idx], &count);
> + port = execlist_port_index(el, idx);
> + n = port_index(port, el);
Bah, execlist_port_index() implies to me that it should return the
index, not the port. I would just call it execlist_port(). How does that
look?
> -static inline void
> +#define __port_idx(start, index, mask) (((start) + (index)) & (mask))
> +
> +static inline struct execlist_port *
> +execlist_port_head(struct intel_engine_execlist * const el)
> +{
> + return &el->port[el->port_head];
> +}
> +
> +/* Index starting from port_head */
> +static inline struct execlist_port *
> +execlist_port_index(struct intel_engine_execlist * const el,
> + const unsigned int n)
> +{
> + return &el->port[__port_idx(el->port_head, n, el->port_mask)];
> +}
> +
> +static inline struct execlist_port *
> +execlist_port_tail(struct intel_engine_execlist * const el)
> +{
> + return &el->port[__port_idx(el->port_head, -1, el->port_mask)];
> +}
Hmm, I was expecting
execlist_port_head() { return execlist_port(el, 0); }
execlist_port_tail() { return execlist_port(el, -1); }
What's the impact on object size? (As a quick guide to how much the
compiler can keep the code in check.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/8] drm/i915: Keep track of reserved execlist ports
Quoting Mika Kuoppala (2017-09-20 15:37:04) > To further enchance port processing, keep track of > reserved ports. This way we can iterate only the used subset > of port space. Note that we lift the responsibility of > execlists_submit_request() to inspect hw availability and > always do dequeuing. This is to ensure that only the irq > handler will be responsible for keeping track of available ports. > > v2: rebase, comment fix, READ_ONCE only outside of irq handler (Chris) > > Cc: Chris Wilson > Cc: Michał Winiarski > Signed-off-by: Mika Kuoppala Ok, doesn't look hideous. I need to look at it with a clear head, but for now, could you check scripts/bloat-o-meter for my usual quick guide on how much gcc likes it? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Improve GuC request coalescing
Quoting Mika Kuoppala (2017-09-20 15:37:05)
> -static void i915_guc_submit(struct intel_engine_cs *engine)
> +static void i915_guc_submit(struct intel_engine_cs *engine,
> + const unsigned int first)
> {
> struct drm_i915_private *dev_priv = engine->i915;
> struct intel_guc *guc = &dev_priv->guc;
> @@ -498,7 +500,7 @@ static void i915_guc_submit(struct intel_engine_cs
> *engine)
> const unsigned int engine_id = engine->id;
> unsigned int n;
>
> - for (n = 0; n < execlist_active_ports(el); n++) {
> + for (n = first; n < execlist_active_ports(el); n++) {
> struct execlist_port *port;
> struct drm_i915_gem_request *rq;
> unsigned int count;
> @@ -506,21 +508,22 @@ static void i915_guc_submit(struct intel_engine_cs
> *engine)
> port = execlist_port_index(el, n);
>
> rq = port_unpack(port, &count);
> - if (rq && count == 0) {
> - port_set(port, port_pack(rq, ++count));
> + GEM_BUG_ON(!rq);
> + GEM_BUG_ON(count);
>
> - if (i915_vma_is_map_and_fenceable(rq->ring->vma))
> - POSTING_READ_FW(GUC_STATUS);
> + port_set(port, port_pack(rq, ++count));
Ok, with this method we don't need count anymore. Seems sensible.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/31] drm/i915/slpc: Sanitize GuC version
On Tue, 19 Sep 2017 19:41:51 +0200, Sagar Arun Kamble
wrote:
From: Tom O'Rourke
The SLPC interface is dependent on GuC version.
Only GuC versions known to be compatible are supported here.
SLPC with GuC firmware v9 is supported with this series.
v1: Updated with modified sanitize_slpc_option in earlier patch.
v2-v3: Rebase.
v4: Updated support for GuC firmware v9.
v5: Commit subject updated.
v6: Commit subject and message update. Add support condition as >=v9.
v7: Sanitizing GuC version in intel_uc_init_fw for SLPC compatibility.
Added info. print for needed version and pointer to 01.org.
v8: s/FIRMWARE_URL/I915_FIRMWARE_URL, Macro added for SLPC required GuC
Major version and rearrangement for sanitization. (MichalW, Joonas)
v9: Checking major_ver_found to sanitize SLPC option enable_slpc post
fetching the firmware as with Custom firmware loaded through
guc_firmware_path parameter, major_ver_wanted are cleared. (Lukasz)
v10: Moved the I915_FIRMWARE_URL macro to intel_uc_common.h.
Signed-off-by: Tom O'Rourke
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_csr.c| 15 ++-
drivers/gpu/drm/i915/intel_guc.h| 1 +
drivers/gpu/drm/i915/intel_guc_loader.c | 15 +++
drivers/gpu/drm/i915/intel_uc.c | 1 +
drivers/gpu/drm/i915/intel_uc_common.h | 2 ++
5 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_csr.c
b/drivers/gpu/drm/i915/intel_csr.c
index 965988f..56c56f5 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -52,11 +52,6 @@
MODULE_FIRMWARE(I915_CSR_BXT);
#define BXT_CSR_VERSION_REQUIRED CSR_VERSION(1, 7)
-#define FIRMWARE_URL "https://01.org/linuxgraphics/downloads/firmware";
-
-
-
-
#define CSR_MAX_FW_SIZE0x2FFF
#define CSR_DEFAULT_FW_OFFSET 0x
@@ -309,11 +304,12 @@ static uint32_t *parse_csr_fw(struct
drm_i915_private *dev_priv,
if (csr->version != required_version) {
DRM_INFO("Refusing to load DMC firmware v%u.%u,"
-" please use v%u.%u [" FIRMWARE_URL "].\n",
+" please use v%u.%u [%s].\n",
CSR_VERSION_MAJOR(csr->version),
CSR_VERSION_MINOR(csr->version),
CSR_VERSION_MAJOR(required_version),
-CSR_VERSION_MINOR(required_version));
+CSR_VERSION_MINOR(required_version),
+I915_FIRMWARE_URL);
Hmm, I'm not sure that including URL here is useful.
URL will be repeated in csr_load_work_fn() where we can explain
its purpose ;)
return NULL;
}
@@ -420,8 +416,9 @@ static void csr_load_work_fn(struct work_struct
*work)
} else {
dev_notice(dev_priv->drm.dev,
"Failed to load DMC firmware"
- " [" FIRMWARE_URL "],"
- " disabling runtime power management.\n");
+ " [%s],"
+ " disabling runtime power management.\n",
+ I915_FIRMWARE_URL);
Maybe more user friendly message should looks like:
"Failed to load DMC firmware, disabling runtime power management."
"DMC firmware can be downloaded from
https://01.org/linuxgraphics/downloads/firmware";
}
release_firmware(fw);
diff --git a/drivers/gpu/drm/i915/intel_guc.h
b/drivers/gpu/drm/i915/intel_guc.h
index a894991..3821bf2 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -159,6 +159,7 @@ static inline void intel_guc_init_early(struct
intel_guc *guc)
int intel_guc_select_fw(struct intel_guc *guc);
int intel_guc_init_hw(struct intel_guc *guc);
u32 intel_guc_wopcm_size(struct intel_guc *guc);
+void intel_guc_fetch_sanitize_options(struct intel_guc *guc);
/* i915_guc_submission.c */
int i915_guc_submission_init(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 6ee7c16..4550620 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -64,6 +64,8 @@
#define GLK_FW_MAJOR 10
#define GLK_FW_MINOR 56
+#define I915_SLPC_REQUIRED_GUC_MAJOR 9
+
#define GUC_FW_PATH(platform, major, minor) \
"i915/" __stringify(platform) "_guc_ver" __stringify(major) "_"
__stringify(minor) ".bin"
@@ -418,3 +420,16 @@ int intel_guc_select_fw(struct intel_guc *guc)
return 0;
}
+
+void intel_guc_fetch_sanitize_options(struct intel_guc *guc)
+{
+ if (guc->fw.major_ver_found <
+ I915_SLPC_REQUIRED_GUC_MAJOR) {
Generally we do not allow Guc fw major "found" to be different than
"wanted"
so this check could be also done against "wanted".
+ DRM_INFO("SLPC not supported with GuC firmware"
+
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Improve GuC request coalescing
On Wed, Sep 20, 2017 at 05:37:05PM +0300, Mika Kuoppala wrote:
> Now that we can keep track of what ports we have
> dequeued, coalesce only those ports instead of iterating
> through all ports.
s/coalesce/submit.
By coalescing I meant that we're no longer have a 1:1 relationship between a
request and GuC workitem. But we're doing that in guc_dequeue by keeping the
request-to-be-turned-into-workitem in port.
>
> Cc: Michał Winiarski
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_guc_submission.c | 31
> +-
> drivers/gpu/drm/i915/intel_ringbuffer.h| 9 +
> 2 files changed, 27 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
> b/drivers/gpu/drm/i915/i915_guc_submission.c
> index 359f57a59cba..1057a0fb9f27 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -485,11 +485,13 @@ static void guc_ring_doorbell(struct i915_guc_client
> *client)
> /**
> * i915_guc_submit() - Submit commands through GuC
> * @engine: engine associated with the commands
> + * @first: index of first execlist port to start coalescing from
s/coalescing/submitting
Reviewed-by: Michał Winiarski
-Michał
> *
> * The only error here arises if the doorbell hardware isn't functioning
> * as expected, which really shouldn't happen.
> */
> -static void i915_guc_submit(struct intel_engine_cs *engine)
> +static void i915_guc_submit(struct intel_engine_cs *engine,
> + const unsigned int first)
> {
> struct drm_i915_private *dev_priv = engine->i915;
> struct intel_guc *guc = &dev_priv->guc;
> @@ -498,7 +500,7 @@ static void i915_guc_submit(struct intel_engine_cs
> *engine)
> const unsigned int engine_id = engine->id;
> unsigned int n;
>
> - for (n = 0; n < execlist_active_ports(el); n++) {
> + for (n = first; n < execlist_active_ports(el); n++) {
> struct execlist_port *port;
> struct drm_i915_gem_request *rq;
> unsigned int count;
> @@ -506,21 +508,22 @@ static void i915_guc_submit(struct intel_engine_cs
> *engine)
> port = execlist_port_index(el, n);
>
> rq = port_unpack(port, &count);
> - if (rq && count == 0) {
> - port_set(port, port_pack(rq, ++count));
> + GEM_BUG_ON(!rq);
> + GEM_BUG_ON(count);
>
> - if (i915_vma_is_map_and_fenceable(rq->ring->vma))
> - POSTING_READ_FW(GUC_STATUS);
> + port_set(port, port_pack(rq, ++count));
>
> - spin_lock(&client->wq_lock);
> + if (i915_vma_is_map_and_fenceable(rq->ring->vma))
> + POSTING_READ_FW(GUC_STATUS);
>
> - guc_wq_item_append(client, rq);
> - guc_ring_doorbell(client);
> + spin_lock(&client->wq_lock);
>
> - client->submissions[engine_id] += 1;
> + guc_wq_item_append(client, rq);
> + guc_ring_doorbell(client);
>
> - spin_unlock(&client->wq_lock);
> - }
> + client->submissions[engine_id] += 1;
> +
> + spin_unlock(&client->wq_lock);
> }
> }
>
> @@ -566,6 +569,7 @@ static void i915_guc_dequeue(struct intel_engine_cs
> *engine)
> struct drm_i915_gem_request *last = NULL;
> bool submit = false;
> struct rb_node *rb;
> + unsigned int first_idx;
>
> spin_lock_irq(&engine->timeline->lock);
> rb = el->first;
> @@ -575,6 +579,7 @@ static void i915_guc_dequeue(struct intel_engine_cs
> *engine)
> goto done;
>
> port = execlist_request_port(el);
> + first_idx = execlist_get_port_index(el, port);
>
> do {
> struct i915_priolist *p = rb_entry(rb, typeof(*p), node);
> @@ -614,7 +619,7 @@ static void i915_guc_dequeue(struct intel_engine_cs
> *engine)
> el->first = rb;
> if (submit) {
> port_assign(port, last);
> - i915_guc_submit(engine);
> + i915_guc_submit(engine, first_idx);
> }
> spin_unlock_irq(&engine->timeline->lock);
> }
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
> b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index efa5a8ea1ecb..f2eb32539300 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -556,6 +556,15 @@ execlist_port_index(struct intel_engine_execlist * const
> el,
> return &el->port[__port_idx(el->port_head, n, el->port_mask)];
> }
>
> +static inline unsigned int
> +execlist_get_port_index(const struct intel_engine_execlist * const el,
> + const struct execlist_port * const port)
> +{
> + const unsigned int n = port_index(port, el);
> +
> + return __port_idx(n, -el->port_head, el->p
[Intel-gfx] [PATCH i-g-t 2/2] igt_core: Rework igt_system()
Instead of redirecting output to pipes and forking, redirect after
forking to avoid having to carefully unredirect before logging
anything.
igt@tools_test@sysfs_l3_parity had a racy condition where it prints
the output of intel_l3_parity prepended by [cmd], but that ended up
being printed again prepended by [cmd] because output was redirected,
causing outputs to appear multiple times. This patch fixes that.
CC: Abdiel Janulgue
Signed-off-by: Petri Latvala
---
lib/igt_core.c | 115 -
1 file changed, 40 insertions(+), 75 deletions(-)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 9f4ee68b..47b4682d 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -2237,58 +2237,23 @@ FILE *__igt_fopen_data(const char* igt_srcdir, const
char* igt_datadir,
return fp;
}
-struct output_pipe {
- int output_fd;
- int save_fd;
- int read_fd;
- int write_fd;
- bool redirected;
- enum igt_log_level log_level;
-};
-
-static bool redirect_output(struct output_pipe *p, int output_fd,
- enum igt_log_level level)
+static void log_output(int *fd, enum igt_log_level level)
{
- int fds[2];
-
- if (pipe(fds) == -1)
- goto err;
-
- /* save output */
- if ((p->save_fd = dup(output_fd)) == -1)
- goto err;
-
- /* Redirect output to our buffer */
- if (dup2(fds[1], output_fd) == -1)
- goto err;
-
- p->output_fd = output_fd;
- p->read_fd = fds[0];
- p->write_fd = fds[1];
- p->redirected = true;
- p->log_level = level;
-
- return true;
-err:
- close(fds[0]);
- close(fds[1]);
- close(p->save_fd);
+ ssize_t len;
+ char buf[PIPE_BUF];
- return false;
-}
+ if (*fd < 0)
+ return;
-static void unredirect_output(struct output_pipe *p)
-{
- if (!p->redirected)
+ memset(buf, 0, sizeof(buf));
+ len = read(*fd, buf, sizeof(buf));
+ if (len <= 0) {
+ close(*fd);
+ *fd = -1;
return;
+ }
- /* read_fd is closed separately. We still need to read its
-* buffered contents after un-redirecting the stream.
-*/
- close(p->write_fd);
- dup2(p->save_fd, p->output_fd);
- close(p->save_fd);
- p->redirected = false;
+ igt_log(IGT_LOG_DOMAIN, level, "[cmd] %s", buf);
}
/**
@@ -2304,48 +2269,48 @@ static void unredirect_output(struct output_pipe *p)
*/
int igt_system(const char *command)
{
-#define OUT 0
-#define ERR 1
- struct output_pipe op[2];
- int i, status;
+ int outpipe[2] = { -1, -1 };
+ int errpipe[2] = { -1, -1 };
+ int status;
struct igt_helper_process process = {};
- char buf[PIPE_BUF];
- if (!redirect_output(&op[OUT], STDOUT_FILENO, IGT_LOG_INFO))
+ if (pipe(outpipe) < 0)
goto err;
- if (!redirect_output(&op[ERR], STDERR_FILENO, IGT_LOG_WARN))
+ if (pipe(errpipe) < 0)
goto err;
igt_fork_helper(&process) {
- igt_assert(execl("/bin/sh", "sh", "-c", command,
-(char *) NULL) != -1);
+ close(outpipe[0]);
+ close(errpipe[0]);
+
+ if (dup2(outpipe[1], STDOUT_FILENO) < 0)
+ goto child_err;
+ if (dup2(errpipe[1], STDERR_FILENO) < 0)
+ goto child_err;
+
+ execl("/bin/sh", "sh", "-c", command,
+ (char *) NULL);
+
+ child_err:
+ exit(EXIT_FAILURE);
}
- for (i = 0; i < ARRAY_SIZE(op); i++) {
- struct output_pipe *current = &op[i];
+ close(outpipe[1]);
+ close(errpipe[1]);
- /* Unredirect so igt_log() works */
- unredirect_output(current);
- memset(buf, 0, sizeof(buf));
- while (read(current->read_fd, buf, sizeof(buf)) > 0) {
- igt_log(IGT_LOG_DOMAIN, current->log_level,
- "[cmd] %s", buf);
- memset(buf, 0, sizeof(buf));
- }
- close(current->read_fd);
+ while (outpipe[0] >= 0 || errpipe[0] >= 0) {
+ log_output(&outpipe[0], IGT_LOG_INFO);
+ log_output(&errpipe[0], IGT_LOG_WARN);
}
+
status = igt_wait_helper(&process);
return WEXITSTATUS(status);
err:
- /* Failed to redirect one or both streams. Roll back changes. */
- for (i = 0; i < ARRAY_SIZE(op); i++) {
- if (!op[i].redirected)
- continue;
- close(op[i].read_fd);
- unredirect_output(&op[i]);
- }
-
+ close(outpipe[0]);
+ close(outpipe[1]);
+ close(errpipe[0]);
+ close(errpipe[1]);
return -1;
}
--
2.14.
[Intel-gfx] [PATCH i-g-t 1/2] tools_test: Clean up and fix sysfs_l3_parity
Multiple misunderstandings of the expectations of the test and some
missed parts of the shell-to-c conversion caused a couple of issues to
remain.
First, we need to actually disable a subbank before we check that a
subbank is disabled (invoke the tool with -d).
Second, the original pipe to wc -l was to check that the tool prints
only one line, not that it prints "at least" a line. Modify the last
check to verify that an "is disabled" text is _not_ printed.
v2: Add a TODO comment
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101650
Signed-off-by: Petri Latvala
Reviewed-by: Abdiel Janulgue
---
tests/tools_test.c | 87 +++---
1 file changed, 50 insertions(+), 37 deletions(-)
diff --git a/tests/tools_test.c b/tests/tools_test.c
index 132bb88b..6aea7a8a 100644
--- a/tests/tools_test.c
+++ b/tests/tools_test.c
@@ -28,26 +28,31 @@
#include
struct line_check {
- bool found;
+ int found;
const char *substr;
};
/**
* Our igt_log_buffer_inspect handler. Checks the output of the
- * intel_l3_parity tool and returns line_check::found to true if
- * a specific substring is found.
+ * intel_l3_parity tool and increments line_check::found if a specific
+ * substring is found.
*/
-static bool check_cmd_return_value(const char *line, void *data)
+static bool check_cmd_output(const char *line, void *data)
{
struct line_check *check = data;
- if (!strstr(line, check->substr)) {
- check->found = false;
- return false;
+ if (strstr(line, check->substr)) {
+ check->found++;
}
- check->found = true;
- return true;
+ return false;
+}
+
+static void assert_cmd_success(int exec_return)
+{
+ igt_skip_on_f(exec_return == IGT_EXIT_SKIP,
+ "intel_l3_parity not supported\n");
+ igt_assert_eq(exec_return, IGT_EXIT_SUCCESS);
}
igt_main
@@ -56,46 +61,54 @@ igt_main
igt_subtest("sysfs_l3_parity") {
int exec_return;
+ struct line_check line;
+ /* Sanity check that l3 parity tool is usable: Enable
+* row,bank,subbank 0,0,0.
+*
+* TODO: Better way to find intel_l3_parity. This path
+* is relative to piglit's path, when run through
+* piglit.
+*/
igt_system_cmd(exec_return,
"../tools/intel_l3_parity -r 0 -b 0 "
"-s 0 -e");
- igt_skip_on_f(exec_return == IGT_EXIT_SKIP,
- "intel_l3_parity not supported\n");
- igt_assert_eq(exec_return, IGT_EXIT_SUCCESS);
+ assert_cmd_success(exec_return);
+ /* Disable row,bank,subbank 0,0,0. */
+ igt_system_cmd(exec_return, "../tools/intel_l3_parity -r 0 -b 0
"
+ "-s 0 -d");
+ assert_cmd_success(exec_return);
+
+ /* Check that disabling was successful */
igt_system_cmd(exec_return, "../tools/intel_l3_parity -l");
- if (exec_return == IGT_EXIT_SUCCESS) {
- struct line_check line;
- line.substr = "Row 0, Bank 0, Subbank 0 is disabled";
- igt_log_buffer_inspect(check_cmd_return_value,
- &line);
- igt_assert_eq(line.found, true);
- }
+ assert_cmd_success(exec_return);
+ line.substr = "Row 0, Bank 0, Subbank 0 is disabled";
+ line.found = 0;
+ igt_log_buffer_inspect(check_cmd_output,
+ &line);
+ igt_assert_eq(line.found, 1);
+ /* Re-enable row,bank,subbank 0,0,0 */
igt_system_cmd(exec_return,
"../tools/intel_l3_parity -r 0 -b 0 "
"-s 0 -e");
- igt_skip_on_f(exec_return == IGT_EXIT_SKIP,
- "intel_l3_parity not supported\n");
- igt_assert_eq(exec_return, IGT_EXIT_SUCCESS);
+ assert_cmd_success(exec_return);
- /* Check that we can clear remaps:
-* In the original shell script, the output of intel_l3_parity
-l
-* was piped thru wc -l to check if the tool would at least
-* return a line. Just watch for one of the expected output
-* string as an alternative.
-* ("is disabled" unique only to intel_l3_parity.c:dumpit())
+ /* Check that re-enabling was successful:
+* intel_l3_parity -l should now not print that Row 0,
+* Bank 0, Subbank 0 is disabled.
+*
+* The previously printed line is already in the log
+
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Document the split in internal and public execbuf flags
== Series Details == Series: drm/i915: Document the split in internal and public execbuf flags URL : https://patchwork.freedesktop.org/series/30696/ State : warning == Summary == Series 30696v1 drm/i915: Document the split in internal and public execbuf flags https://patchwork.freedesktop.org/api/1.0/series/30696/revisions/1/mbox/ Test gem_exec_reloc: Subgroup basic-gtt-noreloc: pass -> DMESG-WARN (fi-kbl-7500u) Test gem_exec_suspend: Subgroup basic-s3: pass -> INCOMPLETE (fi-kbl-7500u) fdo#102850 Test gem_ringfill: Subgroup basic-default-hang: pass -> DMESG-WARN (fi-pnv-d510) fdo#101600 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-legacy: fail -> PASS (fi-snb-2600) fdo#100215 fdo#102850 https://bugs.freedesktop.org/show_bug.cgi?id=102850 fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:441s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:468s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:422s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:512s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:278s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:503s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:498s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:499s fi-cfl-s total:289 pass:222 dwarn:35 dfail:0 fail:0 skip:32 time:546s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:415s fi-glk-1 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:572s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:432s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:406s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:436s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:499s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:468s fi-kbl-7500u total:118 pass:99 dwarn:2 dfail:0 fail:0 skip:16 fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:583s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:590s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:551s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:450s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:752s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:490s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:470s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:576s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:1 skip:39 time:426s bed15796ff696a0a77324b69cfad9e61b50a70a4 drm-tip: 2017y-09m-20d-20h-05m-31s UTC integration manifest 69a0f4b9318e drm/i915: Document the split in internal and public execbuf flags == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5776/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/31] drm/i915/slpc: Lay out SLPC init/enable/disable/cleanup helpers
On Tue, 19 Sep 2017 19:41:52 +0200, Sagar Arun Kamble
wrote:
SLPC operates based on parameters setup in shared data between
i915 and GuC SLPC. This is to be created/initialized in intel_slpc_init.
From there onwards i915 can control the SLPC operations by Enabling,
Disabling complete SLPC or changing SLPC parameters. During cleanup
SLPC shared data has to be freed.
With this patch on platforms with SLPC support we call intel_slpc_*()
functions from GuC setup functions and do not use Host rps functions.
With SLPC, intel_enable_gt_powersave will only handle RC6. In the later
patch intel_init_gt_powersave will check if SLPC has started running
through shared data and update initial state that i915 needs like
frequency limits if needed.
v1: Return void instead of ignored error code (Paulo)
enable/disable RC6 in SLPC flows (Sagar)
replace HAS_SLPC() use with intel_slpc_enabled()
or intel_slpc_active() (Paulo)
Fix for renaming gen9_disable_rps to gen9_disable_rc6 in
"drm/i915/bxt: Explicitly clear the Turbo control register"
Defer RC6 and SLPC enabling to intel_gen6_powersave_work. (Sagar)
Performance drop with SLPC was happening as ring frequency table
was not programmed when SLPC was enabled. This patch programs ring
frequency table with SLPC. Initial reset of SLPC is based on kernel
parameter as planning to add slpc state in intel_slpc_active. Cleanup
is also based on kernel parameter as SLPC gets disabled in
disable/suspend.(Sagar)
v2: Usage of INTEL_GEN instead of INTEL_INFO->gen (David)
Checkpatch update.
v3: Rebase
v4: Removed reset functions to comply with *_gt_powersave routines.
(Sagar)
v5: Removed intel_slpc_active. Relying on slpc.active for control flows
that are based on SLPC active status in GuC. State setup/cleanup
needed
for SLPC is handled using kernel parameter i915.enable_slpc. Moved
SLPC
init and enabling to GuC enable path as SLPC in GuC can start doing
the
setup post GuC init. Commit message update. (Sagar)
v6: Rearranged function definitions.
v7: Makefile rearrangement. Reducing usage of i915.enable_slpc and
relying
mostly on rps.rps_enabled to bypass Host RPS flows. Commit message
update.
v8: Changed parameters for SLPC functions to struct intel_slpc*.
v9: Reinstated intel_slpc_active and intel_slpc_enabled as they are more
meaningful.
v10: Rebase changes due to creation of intel_guc.h. Updates in
intel_guc_cleanup w.r.t slpc cleanup.
Signed-off-by: Tom O'Rourke
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.h | 12 ++
drivers/gpu/drm/i915/intel_guc.c | 3 +++
drivers/gpu/drm/i915/intel_guc.h | 3 +++
Hmm, this looks like cross dependency on other pending series
drivers/gpu/drm/i915/intel_pm.c | 19 +++-
drivers/gpu/drm/i915/intel_slpc.c | 42
It looks that SLPC is tight with Guc so maybe better names would be:
intel_guc_slpc.c and struct intel_guc_slpc
ie. the same pattern as with Guc log.
++
drivers/gpu/drm/i915/intel_slpc.h | 47
+++
drivers/gpu/drm/i915/intel_uc.c | 20 +
8 files changed, 142 insertions(+), 5 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_slpc.c
create mode 100644 drivers/gpu/drm/i915/intel_slpc.h
diff --git a/drivers/gpu/drm/i915/Makefile
b/drivers/gpu/drm/i915/Makefile
index d1327f6..62bf4f6e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -64,6 +64,7 @@ i915-y += intel_uc.o \
intel_guc_log.o \
intel_guc_loader.o \
intel_huc.o \
+ intel_slpc.o \
i915_guc_submission.o
# autogenerated null render state
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 428cb1c..af633c6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2748,6 +2748,18 @@ static inline struct drm_i915_private
*guc_to_i915(struct intel_guc *guc)
return container_of(guc, struct drm_i915_private, guc);
}
+static inline struct intel_guc *slpc_to_guc(struct intel_slpc *slpc)
+{
+ return container_of(slpc, struct intel_guc, slpc);
+}
+
+static inline struct drm_i915_private *slpc_to_i915(struct intel_slpc
*slpc)
+{
+ struct intel_guc *guc = slpc_to_guc(slpc);
+
+ return guc_to_i915(guc);
+}
+
static inline struct drm_i915_private *huc_to_i915(struct intel_huc
*huc)
{
return container_of(huc, struct drm_i915_private, huc);
diff --git a/drivers/gpu/drm/i915/intel_guc.c
b/drivers/gpu/drm/i915/intel_guc.c
index f4dc708..a92c7e8 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -226,6 +226,9 @@ void intel_guc_cleanup(struct intel_guc *guc)
if (i915.enable_guc_submission)
i915_guc_submission_cleanup(dev_priv);
+
+
Re: [Intel-gfx] [PATCH i-g-t] scripts/run-tests.sh: Look for test-lists.txt in 'build' as well
On Wed, 20 Sep 2017, Ville Syrjala wrote: > From: Ville Syrjälä > > Meson always uses a separate build directotry. Adjust the assumptions > in run-tests.sh to work in that environment. For now I'll just hardcode > it to look for a directly called 'build'. I suppose we might want to > let the user pass that in, but for now I can't be bothered to do that. As I suggested to Daniel in the mesonification patches, we could produce an sh.config with all the relevant paths and more, and have the scripts include that. Of course, you'll need to either pass in the information about the location of sh.config, or expect run-tests.sh to be run with the build directory as the CWD. Or support both. BR, Jani. > > Signed-off-by: Ville Syrjälä > --- > scripts/run-tests.sh | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/scripts/run-tests.sh b/scripts/run-tests.sh > index a28dd8760a63..11e65d492fa1 100755 > --- a/scripts/run-tests.sh > +++ b/scripts/run-tests.sh > @@ -34,6 +34,8 @@ if [ ! -d "$IGT_TEST_ROOT" ]; then > exit 1 > fi > > +[ -f "$IGT_TEST_ROOT/test-list.txt" ] || IGT_TEST_ROOT="$ROOT/build/tests" > + > if [ ! -f "$IGT_TEST_ROOT/test-list.txt" ]; then > echo "Error: test list not found." > echo "Please run make in the tests directory to generate the test list." -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/bios: ignore HDMI on port A
The hardware state readout oopses after several warnings when trying to
use HDMI on port A, if such a combination is configured in VBT. Filter
the combo out already at the VBT parsing phase.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102889
Cc: sta...@vger.kernel.org
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 5949750a35ee..f85f736569f1 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1162,6 +1162,11 @@ static void parse_ddi_port(struct drm_i915_private
*dev_priv, enum port port,
is_hdmi = is_dvi && (child->device_type & DEVICE_TYPE_NOT_HDMI_OUTPUT)
== 0;
is_edp = is_dp && (child->device_type & DEVICE_TYPE_INTERNAL_CONNECTOR);
+ if (port == PORT_A && is_hdmi) {
+ DRM_DEBUG_KMS("VBT claims port A supports HDMI, ignoring\n");
+ is_hdmi = false;
+ }
+
info->supports_dvi = is_dvi;
info->supports_hdmi = is_hdmi;
info->supports_dp = is_dp;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/31] drm/i915/slpc: Add SLPC communication interfaces
On Tue, 19 Sep 2017 19:41:54 +0200, Sagar Arun Kamble
wrote:
Communication with SLPC is via Host to GuC interrupt through
shared data and parameters. This patch defines the structure of
shared data, parameters, data structure to be passed as input and
received as output from SLPC. This patch also defines the events
to be sent as input and status values output by GuC on processing
SLPC events. SLPC shared data has details of SKU type, Slice count,
IA Perf MSR values, SLPC state, Power source/plan, SLPC tasks status.
Parameters allow overriding task control, frequency range etc.
v1: fix whitespace (Sagar)
v2-v3: Rebase.
v4: Updated with GuC firmware v9.
v5: Added definition of input and output data structures for SLPC
events. Updated commit message.
v6: Removed definition of host2guc_slpc. Will be added in the next
patch that uses it. Commit subject update. Rebase.
v7: Added definition of SLPC_RESET_FLAG_TDR_OCCURRED to be sent
throgh SLPC reset in case of engine reset. Moved all Host/SLPC
interfaces from later patches to this patch. Commit message update.
v8: Updated value of SLPC_RESET_FLAG_TDR_OCCURRED.
Signed-off-by: Tom O'Rourke
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_slpc.c | 39 +++
drivers/gpu/drm/i915/intel_slpc.h | 207
++
2 files changed, 246 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_slpc.c
b/drivers/gpu/drm/i915/intel_slpc.c
index 06abda5..a3db63c 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -25,6 +25,45 @@
#include "i915_drv.h"
#include "intel_uc.h"
+struct slpc_param slpc_paramlist[SLPC_MAX_PARAM] = {
+ {SLPC_PARAM_TASK_ENABLE_GTPERF, "Enable task GTPERF"},
+ {SLPC_PARAM_TASK_DISABLE_GTPERF, "Disable task GTPERF"},
+ {SLPC_PARAM_TASK_ENABLE_BALANCER, "Enable task BALANCER"},
+ {SLPC_PARAM_TASK_DISABLE_BALANCER, "Disable task BALANCER"},
+ {SLPC_PARAM_TASK_ENABLE_DCC, "Enable task DCC"},
+ {SLPC_PARAM_TASK_DISABLE_DCC, "Disable task DCC"},
+ {SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ,
+ "Minimum GT frequency request for unslice"},
+ {SLPC_PARAM_GLOBAL_MAX_GT_UNSLICE_FREQ_MHZ,
+ "Maximum GT frequency request for unslice"},
+ {SLPC_PARAM_GLOBAL_MIN_GT_SLICE_FREQ_MHZ,
+ "Minimum GT frequency request for slice"},
+ {SLPC_PARAM_GLOBAL_MAX_GT_SLICE_FREQ_MHZ,
+ "Maximum GT frequency request for slice"},
+ {SLPC_PARAM_GTPERF_THRESHOLD_MAX_FPS,
+ "If non-zero, algorithm will slow down "
+ "frame-based applications to this frame-rate"},
+ {SLPC_PARAM_GLOBAL_DISABLE_GT_FREQ_MANAGEMENT,
+ "Lock GT frequency request to RPe"},
+ {SLPC_PARAM_GTPERF_ENABLE_FRAMERATE_STALLING,
+ "Set to TRUE to enable slowing framerate"},
+ {SLPC_PARAM_GLOBAL_DISABLE_RC6_MODE_CHANGE,
+ "Prevent from changing the RC mode"},
+ {SLPC_PARAM_GLOBAL_OC_UNSLICE_FREQ_MHZ,
+ "Override fused value of unslice RP0"},
+ {SLPC_PARAM_GLOBAL_OC_SLICE_FREQ_MHZ,
+ "Override fused value of slice RP0"},
+ {SLPC_PARAM_GLOBAL_ENABLE_IA_GT_BALANCING,
+ "TRUE means enable Intelligent Bias Control"},
+ {SLPC_PARAM_GLOBAL_ENABLE_ADAPTIVE_BURST_TURBO,
+ "TRUE = enable eval mode when transitioning "
+ "from idle to active."},
+ {SLPC_PARAM_GLOBAL_ENABLE_EVAL_MODE,
+ "FALSE = disable eval mode completely"},
+ {SLPC_PARAM_GLOBAL_ENABLE_BALANCER_IN_NON_GAMING_MODE,
+ "Enable IBC when non-Gaming Mode is enabled"}
+};
+
void intel_slpc_init(struct intel_slpc *slpc)
{
}
diff --git a/drivers/gpu/drm/i915/intel_slpc.h
b/drivers/gpu/drm/i915/intel_slpc.h
index f68671f..ac4cb65 100644
--- a/drivers/gpu/drm/i915/intel_slpc.h
+++ b/drivers/gpu/drm/i915/intel_slpc.h
@@ -38,6 +38,213 @@ static inline bool intel_slpc_active(struct
intel_slpc *slpc)
return slpc->active;
}
+enum slpc_status {
+ SLPC_STATUS_OK = 0,
+ SLPC_STATUS_ERROR = 1,
+ SLPC_STATUS_ILLEGAL_COMMAND = 2,
+ SLPC_STATUS_INVALID_ARGS = 3,
+ SLPC_STATUS_INVALID_PARAMS = 4,
+ SLPC_STATUS_INVALID_DATA = 5,
+ SLPC_STATUS_OUT_OF_RANGE = 6,
+ SLPC_STATUS_NOT_SUPPORTED = 7,
+ SLPC_STATUS_NOT_IMPLEMENTED = 8,
+ SLPC_STATUS_NO_DATA = 9,
+ SLPC_STATUS_EVENT_NOT_REGISTERED = 10,
+ SLPC_STATUS_REGISTER_LOCKED = 11,
+ SLPC_STATUS_TEMPORARILY_UNAVAILABLE = 12,
+ SLPC_STATUS_VALUE_ALREADY_SET = 13,
+ SLPC_STATUS_VALUE_ALREADY_UNSET = 14,
+ SLPC_STATUS_VALUE_NOT_CHANGED = 15,
+
Re: [Intel-gfx] [PATCH] drm/i915/bios: ignore HDMI on port A
On Thu, Sep 21, 2017 at 04:11:49PM +0300, Jani Nikula wrote:
> The hardware state readout oopses after several warnings when trying to
> use HDMI on port A, if such a combination is configured in VBT. Filter
> the combo out already at the VBT parsing phase.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102889
> Cc: sta...@vger.kernel.org
> Cc: Imre Deak
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_bios.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 5949750a35ee..f85f736569f1 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1162,6 +1162,11 @@ static void parse_ddi_port(struct drm_i915_private
> *dev_priv, enum port port,
> is_hdmi = is_dvi && (child->device_type & DEVICE_TYPE_NOT_HDMI_OUTPUT)
> == 0;
> is_edp = is_dp && (child->device_type & DEVICE_TYPE_INTERNAL_CONNECTOR);
>
> + if (port == PORT_A && is_hdmi) {
s/is_hdmi/is_dvi/
> + DRM_DEBUG_KMS("VBT claims port A supports HDMI, ignoring\n");
> + is_hdmi = false;
+ is_dvi = false;
> + }
> +
> info->supports_dvi = is_dvi;
> info->supports_hdmi = is_hdmi;
> info->supports_dp = is_dp;
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [GIT PULL] gvt-next pull
On Fri, 08 Sep 2017, Zhenyu Wang wrote: > Hi, > > This is an earlier request for gvt-next pull which is mainly > for required PCI config changes on OVMF support for Redhat and > also contains massive error handling improvement on workload > submission. Both are targeted for 4.15. N.b. I've pulled this ages ago, just forgot to reply on the list. BR, Jani. > > Thanks > -- > The following changes since commit bb9d2d050503c69695557b8b741276686ca2a396: > > drm/i915: Update DRIVER_DATE to 20170907 (2017-09-07 11:28:20 +0300) > > are available in the git repository at: > > https://github.com/01org/gvt-linux.git tags/gvt-next-2017-09-08 > > for you to fetch changes up to 02d578e5edd980eac3fbed15db4d9e5665f22089: > > drm/i915/gvt: Add support for PCIe extended configuration space (2017-09-08 > 14:21:16 +0800) > > > gvt-next-2017-09-08 > > - PCI config sanitize series (Changbin) > - Workload submission error handling series (Fred) > > > Changbin Du (4): > drm/i915/kvmgt: Sanitize PCI bar emulation > drm/i915/gvt: Add emulation for BAR2 (aperture) with normal file RW > approach > drm/i915/gvt: Fix incorrect PCI BARs reporting > drm/i915/gvt: Add support for PCIe extended configuration space > > fred gao (6): > drm/i915/gvt: Separate cmd scan from request allocation > drm/i915/gvt: Add error handling for intel_gvt_scan_and_shadow_workload > drm/i915/gvt: Refine error handling for prepare_execlist_workload > drm/i915/gvt: Refine error handling for intel_vgpu_pin_mm > drm/i915/gvt: Refine error handling in dispatch_workload > drm/i915/gvt: Refine error handling for perform_bb_shadow > > drivers/gpu/drm/i915/gvt/cfg_space.c | 143 > +- > drivers/gpu/drm/i915/gvt/cmd_parser.c | 37 + > drivers/gpu/drm/i915/gvt/execlist.c | 127 ++ > drivers/gpu/drm/i915/gvt/gtt.c| 3 +- > drivers/gpu/drm/i915/gvt/gvt.c| 2 +- > drivers/gpu/drm/i915/gvt/gvt.h| 14 +++- > drivers/gpu/drm/i915/gvt/kvmgt.c | 44 ++- > drivers/gpu/drm/i915/gvt/mmio.c | 47 ++- > drivers/gpu/drm/i915/gvt/scheduler.c | 110 ++ > drivers/gpu/drm/i915/gvt/scheduler.h | 1 + > 10 files changed, 353 insertions(+), 175 deletions(-) -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Eliminate DDI encoder->type frobbery redux (rev3)
== Series Details == Series: drm/i915: Eliminate DDI encoder->type frobbery redux (rev3) URL : https://patchwork.freedesktop.org/series/30548/ State : failure == Summary == Series 30548v3 drm/i915: Eliminate DDI encoder->type frobbery redux https://patchwork.freedesktop.org/api/1.0/series/30548/revisions/3/mbox/ Test gem_exec_suspend: Subgroup basic-s3: pass -> DMESG-WARN (fi-bxt-j4205) pass -> DMESG-WARN (fi-glk-1) Test gem_ringfill: Subgroup basic-default-hang: pass -> DMESG-WARN (fi-pnv-d510) fdo#101600 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 +1 Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-b-frame-sequence: dmesg-warn -> DMESG-FAIL (fi-cfl-s) fdo#102294 Subgroup nonblocking-crc-pipe-c: skip -> INCOMPLETE (fi-cfl-s) Subgroup suspend-read-crc-pipe-a: pass -> DMESG-WARN (fi-bxt-j4205) pass -> DMESG-WARN (fi-glk-1) Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-bxt-j4205) pass -> DMESG-WARN (fi-glk-1) Subgroup suspend-read-crc-pipe-c: pass -> DMESG-WARN (fi-bxt-j4205) pass -> DMESG-WARN (fi-glk-1) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (fi-bxt-j4205) pass -> DMESG-WARN (fi-glk-1) Subgroup basic-rte: pass -> DMESG-WARN (fi-bxt-j4205) pass -> DMESG-WARN (fi-glk-1) Test prime_vgem: Subgroup basic-fence-flip: pass -> DMESG-WARN (fi-bxt-j4205) Test drv_module_reload: Subgroup basic-no-display: pass -> DMESG-WARN (fi-glk-1) fdo#102777 +1 fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294 fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:437s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:475s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:427s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:518s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:278s fi-bxt-j4205 total:289 pass:253 dwarn:7 dfail:0 fail:0 skip:29 time:499s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:491s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:492s fi-cfl-s total:237 pass:188 dwarn:21 dfail:1 fail:0 skip:26 fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:419s fi-glk-1 total:289 pass:252 dwarn:8 dfail:0 fail:0 skip:29 time:565s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:427s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:403s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:435s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:491s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:465s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:472s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:575s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:588s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:539s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:446s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:755s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:483s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:466s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:566s fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:415s bed15796ff696a0a77324b69cfad9e61b50a70a4 drm-tip: 2017y-09m-20d-20h-05m-31s UTC integration manifest e27cac9ba960 drm/i915: Pass a crtc state to ddi post_disable from MST code 0de78b80d54d drm/i915: Replace most intel_ddi_get_encoder_port() alls with encoder->port 512bce39587a drm/i915: Clear up the types we use for DDI buf trans level/n_entries 0bfc26bcb85a drm/i915: Unify error handling for missing DDI buf trans tables acd739878a0d drm/i915: Stop frobbing with DDI encoder->type fe543e6e9956 drm/i915: Centralize the SKL D
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/kbl: Change a KBL pci id to GT2 from GT1.5
On Wed, Sep 20, 2017 at 09:43:38PM +, Anuj Phogat wrote: > On Wed, Sep 20, 2017 at 2:34 PM, Rodrigo Vivi wrote: > > On Wed, Sep 20, 2017 at 08:31:26PM +, Anuj Phogat wrote: > >> See Mesa commit 9c588ff > >> > >> Cc: Matt Turner > >> Cc: Rodrigo Vivi > >> Signed-off-by: Anuj Phogat > > > > Reviewed-by: Rodrigo Vivi > > > Thanks Rodrigo. Can you push it for me? merged to dinq. Thanks for the patch and for organizing the ids acros the stack. > >> --- > >> include/drm/i915_pciids.h | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h > >> index 1257e15c1a03..972a25633525 100644 > >> --- a/include/drm/i915_pciids.h > >> +++ b/include/drm/i915_pciids.h > >> @@ -339,7 +339,6 @@ > >> #define INTEL_KBL_GT1_IDS(info) \ > >> INTEL_VGA_DEVICE(0x5913, info), /* ULT GT1.5 */ \ > >> INTEL_VGA_DEVICE(0x5915, info), /* ULX GT1.5 */ \ > >> - INTEL_VGA_DEVICE(0x5917, info), /* DT GT1.5 */ \ > >> INTEL_VGA_DEVICE(0x5906, info), /* ULT GT1 */ \ > >> INTEL_VGA_DEVICE(0x590E, info), /* ULX GT1 */ \ > >> INTEL_VGA_DEVICE(0x5902, info), /* DT GT1 */ \ > >> @@ -349,6 +348,7 @@ > >> > >> #define INTEL_KBL_GT2_IDS(info) \ > >> INTEL_VGA_DEVICE(0x5916, info), /* ULT GT2 */ \ > >> + INTEL_VGA_DEVICE(0x5917, info), /* Mobile GT2 */ \ > >> INTEL_VGA_DEVICE(0x5921, info), /* ULT GT2F */ \ > >> INTEL_VGA_DEVICE(0x591E, info), /* ULX GT2 */ \ > >> INTEL_VGA_DEVICE(0x5912, info), /* DT GT2 */ \ > >> -- > >> 2.13.5 > >> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dim: Accept author x signed-off based on email.
On Thu, Sep 21, 2017 at 11:12:52AM +, Jani Nikula wrote: > On Wed, 20 Sep 2017, Rodrigo Vivi wrote: > > It seems Patchwork or SMTP servers are messing some patches > > and changing the original git's author name on git per "Last, First". > > So we end up with a mismatch were signed-off uses one name format > > and author is using another format. > > > > So, let's check for email addresses instead. > > > > v2: Avoid useles warning and only check for email. > > > > Cc: Jani Nikula > > Cc: Joonas Lahtinen > > Signed-off-by: Rodrigo Vivi > > Reviewed-by: Jani Nikula pushed, thanks. > > > --- > > dim | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/dim b/dim > > index dbaeb1ec944d..a63000fb67a8 100755 > > --- a/dim > > +++ b/dim > > @@ -689,7 +689,7 @@ function checkpatch_commit_push > > sha1=$1 > > > > # use real names for people with many different email addresses > > - author=$(git show -s $sha1 --format="format:%an") > > + author=$(git show -s $sha1 --format="format:%ae") > > committer=$(git show -s $sha1 --format="format:%cn") > > > > # check for author sign-off > > -- > Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Check waiter->seqno carefully in case of preemption
On Tue, Sep 19, 2017 at 11:07:43AM +0100, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2017-09-19 10:28:42)
> >
> > On 18/09/2017 17:27, Chris Wilson wrote:
> > > If preemption occurs at precisely the right moment, we may decide that
> > > the wait is complete even though the wait's request is no longer
> > > executing (having been preempted). We handle this situation by double
> > > checking that request following deciding whether the wait is complete.
> > >
> > > Reported-by: Michał Winiarski > > Signed-off-by: Chris Wilson
> > > Cc: Michał Winiarski
> > > Cc: Tvrtko Ursulin
> > > ---
> > > drivers/gpu/drm/i915/i915_irq.c | 7 +--
> > > 1 file changed, 5 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > b/drivers/gpu/drm/i915/i915_irq.c
> > > index bb69c5b0efc4..7a53d94b7e61 100644
> > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -1053,10 +1053,13 @@ static void notify_ring(struct intel_engine_cs
> > > *engine)
> > >*/
> > > if (i915_seqno_passed(intel_engine_get_seqno(engine),
> > > wait->seqno)) {
> > > + struct drm_i915_gem_request *waiter = wait->request;
> > > +
> > > wakeup = true;
> > > if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
> > > - &wait->request->fence.flags))
> > > - rq = i915_gem_request_get(wait->request);
> > > + &waiter->fence.flags) &&
> > > + intel_wait_check_request(wait, waiter))
> > > + rq = i915_gem_request_get(waiter);
> > > }
> > >
> > > if (wakeup)
> > >
> >
> > Hm but as the user interrupt is nor serialized to exelists, what
> > prevents the preemption to happen after the intel_wait_check_request and
> > before dma_fence_signal?
>
> The preemption is serialized to the breadcrumb, so that our
> understanding of i915_gem_request_completed() is accurate. It would be
> a nasty bug if we flagged DMA_FENCE_FLAG_SIGNALED_BIT prior to
> i915_gem_request_completed().
>
> Here, wait_check_request just confirms that the wait->seqno still
> matches the rq->global_seqno. So as we have already found that the
> breadcrumb has passed wait->seqno, that means that the request is ready
> to wake up. We only do the wake avoidance if we believe that we can
> trust the order of MI_USER_INTERRUPT with the breadcrumb write, so that
> then we know that if the request is not yet ready, we will receive
> another interrupt in the future. (On the other side, if the wait queue
> is manipulated, it ensures that the new waiter is woken to do the
> breadcrumb check to avoid missed interrupts.)
>
> So... If the preemption happens after intel_wait_check_request, it does
> not affect the prior completed request.
Reviewed-by: Michał Winiarski
-Michał
> -Chris
> ___
> 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 20/31] drm/i915/slpc: Add parameter set/unset/get, task control/status functions
On Tue, 19 Sep 2017 19:41:56 +0200, Sagar Arun Kamble
wrote:
SLPC behavior can be changed through set of parameters.
These parameters can be updated and queried from i915 though
Host to GuC SLPC events. This patch adds parameter update
events for setting/unsetting/getting parameters. SLPC has
various tasks for controlling different controls. This patch
adds functions to control and query the task status.
v1: Use host2guc_slpc
update slcp_param_id enum values for SLPC 2015.2.4
return void instead of ignored error code (Paulo)
v2: Checkpatch update.
v3: Rebase.
v4: Updated with GuC firmware v9.
v5: Updated input structure to host2guc_slpc. Added functions
to update only parameters in the SLPC shared memory. This
will allow to setup shared data with all parameters and send
single event to SLPC take them into effect. Commit message
update. (Sagar)
v6: Rearranged helpers to use them in slpc_shared_data_init.
Added definition of SLPC_KMD_MAX_PARAM.
v7: Added definition of host2guc_slpc with rearrangement of patches.
Added task control/status functions.
v8: Rebase w.r.t s/intel_guc_send/intel_guc_send_mmio.
Cc: Michal Wajdeczko
Signed-off-by: Tom O'Rourke
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_guc.c | 21 -
drivers/gpu/drm/i915/intel_guc.h | 2 +
drivers/gpu/drm/i915/intel_slpc.c | 185
++
drivers/gpu/drm/i915/intel_slpc.h | 8 ++
4 files changed, 215 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c
b/drivers/gpu/drm/i915/intel_guc.c
index a92c7e8..656bae9 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -67,9 +67,11 @@ void intel_guc_init_send_regs(struct intel_guc *guc)
/*
* This function implements the MMIO based host to GuC interface.
*/
-int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32
len)
+int __intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32
len,
+ u32 *output)
{
struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ union slpc_event_output_header header;
Don't pollute generic send function with slpc specific code.
u32 status;
int i;
int ret;
@@ -115,12 +117,29 @@ int intel_guc_send_mmio(struct intel_guc *guc,
const u32 *action, u32 len)
action[0], ret, status, I915_READ(SOFT_SCRATCH(15)));
}
+ /*
+* Output data from Host to GuC SLPC actions is populated in scratch
+* registers SOFT_SCRATCH(1) to SOFT_SCRATCH(14) based on event.
Note that receiving more data over MMIO will be handled by these pending
patches
https://patchwork.freedesktop.org/patch/170667/
https://patchwork.freedesktop.org/patch/170669/
The same series will also add support for responses over CT so stay tuned!
+* Currently only SLPC action status in GuC is meaningful as Host
+* can query only overridden parameters and that are fetched from
+* Host-GuC SLPC shared data.
+*/
+ if (output && !ret) {
+ output[0] = header.value = I915_READ(SOFT_SCRATCH(1));
+ ret = header.status;
+ }
+
intel_uncore_forcewake_put(dev_priv, guc->send_regs.fw_domains);
mutex_unlock(&guc->send_mutex);
return ret;
}
+int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32
len)
+{
+ return __intel_guc_send_mmio(guc, action, len, NULL);
+}
+
int intel_guc_sample_forcewake(struct intel_guc *guc)
{
struct drm_i915_private *dev_priv = guc_to_i915(guc);
diff --git a/drivers/gpu/drm/i915/intel_guc.h
b/drivers/gpu/drm/i915/intel_guc.h
index b835d30..c27d2dd 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -132,6 +132,8 @@ struct intel_guc {
int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32
len);
void gen8_guc_raise_irq(struct intel_guc *guc);
void intel_guc_init_send_regs(struct intel_guc *guc);
+int __intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32
len,
+ u32 *output);
int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32
len);
int intel_guc_sample_forcewake(struct intel_guc *guc);
int intel_guc_runtime_suspend(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_slpc.c
b/drivers/gpu/drm/i915/intel_slpc.c
index 73e7bf5..f47d81e 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -132,6 +132,191 @@ int slpc_mem_task_control(struct slpc_shared_data
*data, u64 val,
return ret;
}
+static void host2guc_slpc(struct intel_slpc *slpc,
+ struct slpc_event_input *input, u32 len)
+{
+ struct intel_guc *guc = slpc_to_guc(slpc);
+ u32 *data;
+ u32 output[SLPC_EVENT_MAX_OUTPUT_ARGS];
+ int ret = 0;
+
+ /*
+* We have
Re: [Intel-gfx] [PATCH i-g-t 2/9] tests/perf: Test i915 assisted command stream based perf metrics capture
On Wed, Sep 13, 2017 at 04:22:01PM +0530, Sagar Arun Kamble wrote:
> This tests different performance metrics being streamed by i915 driver.
> This feature in i915 also referred as Driver Assisted Performance
> Capture (DAPC) provides userspace an ability to sample the OA reports
> at execbuf boundaries and associate other metadata like CTX ID, PID, TAG
> with each sample. Further, ability to capture engine timestamps and MMIO
> reads is also provided.
>
> v2: Defining the enums for OA_SOURCE and PERF_PROP locally till the
> libdrm changes are merged.
>
> Cc: Lionel Landwerlin
> Signed-off-by: Sagar Arun Kamble
Reviewed-by: Ewelina Musial
> ---
> tests/Makefile.sources | 1 +
> tests/intel_perf_dapc.c | 811
>
> 2 files changed, 812 insertions(+)
> create mode 100644 tests/intel_perf_dapc.c
>
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index 6c19509..24bd099 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -170,6 +170,7 @@ TESTS_progs = \
> gen7_forcewake_mt \
> gvt_basic \
> intel_perf \
> + intel_perf_dapc \
> kms_3d \
> kms_addfb_basic \
> kms_atomic \
> diff --git a/tests/intel_perf_dapc.c b/tests/intel_perf_dapc.c
> new file mode 100644
> index 000..92b4dee
> --- /dev/null
> +++ b/tests/intel_perf_dapc.c
> @@ -0,0 +1,811 @@
> +/*
> + * Copyright © 2017 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + */
> +#include
> +
> +#include "igt.h"
> +#include "drm.h"
> +
> +IGT_TEST_DESCRIPTION("Test the i915 command stream based perf metrics
> streaming interface");
> +
> +/* Temporarily copy i915-perf uapi here to avoid a dependency on libdrm's
> + * i915_drm.h copy being updated with the i915-perf interface before this
> + * test can land in i-g-t.
> + *
> + * TODO: remove this once the interface lands in libdrm
> + */
> +#ifndef DRM_I915_PERF_OPEN
> +#define DRM_I915_PERF_OPEN 0x36
> +#define DRM_IOCTL_I915_PERF_OPEN DRM_IOW(DRM_COMMAND_BASE + \
> + DRM_I915_PERF_OPEN, \
> + struct drm_i915_perf_open_param)
> +
> +enum drm_i915_oa_format {
> + I915_OA_FORMAT_A13 = 1, /* HSW only */
> + I915_OA_FORMAT_A29, /* HSW only */
> + I915_OA_FORMAT_A13_B8_C8, /* HSW only */
> + I915_OA_FORMAT_B4_C8, /* HSW only */
> + I915_OA_FORMAT_A45_B8_C8, /* HSW only */
> + I915_OA_FORMAT_B4_C8_A16, /* HSW only */
> + I915_OA_FORMAT_C4_B8, /* HSW+ */
> +
> + /* Gen8+ */
> + I915_OA_FORMAT_A12,
> + I915_OA_FORMAT_A12_B8_C8,
> + I915_OA_FORMAT_A32u40_A4u32_B8_C8,
> +
> + I915_OA_FORMAT_MAX /* non-ABI */
> +};
> +
> +enum drm_i915_perf_sample_oa_source {
> + I915_PERF_SAMPLE_OA_SOURCE_OABUFFER,
> + I915_PERF_SAMPLE_OA_SOURCE_CS,
> + I915_PERF_SAMPLE_OA_SOURCE_MAX /* non-ABI */
> +};
> +
> +#define I915_PERF_MMIO_NUM_MAX 8
> +struct drm_i915_perf_mmio_list {
> + __u32 num_mmio;
> + __u32 mmio_list[I915_PERF_MMIO_NUM_MAX];
> +};
> +
> +enum drm_i915_perf_property_id {
> + DRM_I915_PERF_PROP_CTX_HANDLE = 1,
> + DRM_I915_PERF_PROP_SAMPLE_OA,
> + DRM_I915_PERF_PROP_OA_METRICS_SET,
> + DRM_I915_PERF_PROP_OA_FORMAT,
> + DRM_I915_PERF_PROP_OA_EXPONENT,
> + DRM_I915_PERF_PROP_SAMPLE_OA_SOURCE,
> + DRM_I915_PERF_PROP_ENGINE,
> + DRM_I915_PERF_PROP_SAMPLE_CTX_ID,
> + DRM_I915_PERF_PROP_SAMPLE_PID,
> + DRM_I915_PERF_PROP_SAMPLE_TAG,
> + DRM_I915_PERF_PROP_SAMPLE_TS,
> + DRM_I915_PERF_PROP_SAMPLE_MMIO,
> + DRM_I915_PERF_PROP_MAX /* non-ABI */
> +};
> +
> +struct drm_i915_perf_open_param {
> + __u32 flags;
> +#define I915_PERF_FLAG_FD_CLOEXEC(1<<0)
> +#define I915_PERF_FLAG_FD_NONBLOCK (1<<1)
> +#define
[Intel-gfx] [PATCH 2/2] drm/i915/lrc: Skip no-op per-bb buffer on gen9
Since we inherited the context image setup from gen8 which needed a
per-bb workaround (for GPGPU), we are submitting an empty per-bb buffer
on gen9. Now that we can skip adding the buffer to the context image,
remove the dangling per-bb. This slightly improves execution latency,
most notably on an idle engine.
References: https://bugs.freedesktop.org/show_bug.cgi?id=87725
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 297c9c1564e5..91a5411bb9da 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1171,13 +1171,6 @@ static u32 *gen9_init_indirectctx_bb(struct
intel_engine_cs *engine, u32 *batch)
return batch;
}
-static u32 *gen9_init_perctx_bb(struct intel_engine_cs *engine, u32 *batch)
-{
- *batch++ = MI_BATCH_BUFFER_END;
-
- return batch;
-}
-
#define CTX_WA_BB_OBJ_SIZE (PAGE_SIZE)
static int lrc_setup_wa_ctx(struct intel_engine_cs *engine)
@@ -1234,7 +1227,7 @@ static int intel_init_workaround_bb(struct
intel_engine_cs *engine)
return 0;
case 9:
wa_bb_fn[0] = gen9_init_indirectctx_bb;
- wa_bb_fn[1] = gen9_init_perctx_bb;
+ wa_bb_fn[1] = NULL;
break;
case 8:
wa_bb_fn[0] = gen8_init_indirectctx_bb;
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/lrc: Only enable per-context and per-bb buffers if set
The per-context and per-batch workaround buffers are optional, yet we
tell the GPU to execute them even if they contain no instructions. Doing
so incurs the dispatch latency, which we can avoid if we don't ask the
GPU to execute the no-op buffers. Allow ourselves to skip setup of empty
buffer, and then to only enable non-empty buffers in the context image.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 86fed9f1f1ae..297c9c1564e5 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1265,7 +1265,8 @@ static int intel_init_workaround_bb(struct
intel_engine_cs *engine)
ret = -EINVAL;
break;
}
- batch_ptr = wa_bb_fn[i](engine, batch_ptr);
+ if (wa_bb_fn[i])
+ batch_ptr = wa_bb_fn[i](engine, batch_ptr);
wa_bb[i]->size = batch_ptr - (batch + wa_bb[i]->offset);
}
@@ -1994,13 +1995,12 @@ static void execlists_init_reg_state(u32 *regs,
CTX_REG(regs, CTX_SECOND_BB_HEAD_L, RING_SBBADDR(base), 0);
CTX_REG(regs, CTX_SECOND_BB_STATE, RING_SBBSTATE(base), 0);
if (rcs) {
- CTX_REG(regs, CTX_BB_PER_CTX_PTR, RING_BB_PER_CTX_PTR(base), 0);
+ struct i915_ctx_workarounds *wa_ctx = &engine->wa_ctx;
+
CTX_REG(regs, CTX_RCS_INDIRECT_CTX, RING_INDIRECT_CTX(base), 0);
CTX_REG(regs, CTX_RCS_INDIRECT_CTX_OFFSET,
RING_INDIRECT_CTX_OFFSET(base), 0);
-
- if (engine->wa_ctx.vma) {
- struct i915_ctx_workarounds *wa_ctx = &engine->wa_ctx;
+ if (wa_ctx->indirect_ctx.size) {
u32 ggtt_offset = i915_ggtt_offset(wa_ctx->vma);
regs[CTX_RCS_INDIRECT_CTX + 1] =
@@ -2009,6 +2009,11 @@ static void execlists_init_reg_state(u32 *regs,
regs[CTX_RCS_INDIRECT_CTX_OFFSET + 1] =
intel_lr_indirect_ctx_offset(engine) << 6;
+ }
+
+ CTX_REG(regs, CTX_BB_PER_CTX_PTR, RING_BB_PER_CTX_PTR(base), 0);
+ if (wa_ctx->per_ctx.size) {
+ u32 ggtt_offset = i915_ggtt_offset(wa_ctx->vma);
regs[CTX_BB_PER_CTX_PTR + 1] =
(ggtt_offset + wa_ctx->per_ctx.offset) | 0x01;
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/8] drm/i915: Wrap port cancellation into a function
Michał Winiarski writes:
> On Wed, Sep 20, 2017 at 05:37:00PM +0300, Mika Kuoppala wrote:
>> On reset and wedged path, we want to release the requests
>> that are tied to ports and then mark the ports to be unset.
>> Introduce a function for this.
>>
>> v2: rebase
>>
>> Cc: Chris Wilson
>> Signed-off-by: Mika Kuoppala
>> ---
>> drivers/gpu/drm/i915/intel_lrc.c | 21 -
>> 1 file changed, 12 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
>> b/drivers/gpu/drm/i915/intel_lrc.c
>> index a4ece4c4f291..ffb9c900328b 100644
>> --- a/drivers/gpu/drm/i915/intel_lrc.c
>> +++ b/drivers/gpu/drm/i915/intel_lrc.c
>> @@ -568,6 +568,16 @@ static void execlists_dequeue(struct intel_engine_cs
>> *engine)
>> execlists_submit_ports(engine);
>> }
>>
>> +static void execlist_cancel_port_requests(struct intel_engine_execlist *el)
>> +{
>> +unsigned int i;
>> +
>> +for (i = 0; i < ARRAY_SIZE(el->port); i++)
>> +i915_gem_request_put(port_request(&el->port[i]));
>> +
>> +memset(el->port, 0, sizeof(el->port));
>> +}
>> +
>> static void execlists_cancel_requests(struct intel_engine_cs *engine)
>> {
>> struct intel_engine_execlist * const el = &engine->execlist;
>> @@ -575,14 +585,11 @@ static void execlists_cancel_requests(struct
>> intel_engine_cs *engine)
>> struct drm_i915_gem_request *rq, *rn;
>> struct rb_node *rb;
>> unsigned long flags;
>> -unsigned long n;
>>
>> spin_lock_irqsave(&engine->timeline->lock, flags);
>>
>> /* Cancel the requests on the HW and clear the ELSP tracker. */
>> -for (n = 0; n < ARRAY_SIZE(el->port); n++)
>> -i915_gem_request_put(port_request(&port[n]));
>
> We could also drop the local variable for port.
Dropped.
> It's only used in GEM_BUG_ON(port_isset(&port[0])).
> Do we even need this assert when we're starting to treat ports in a more
> ring-like fashion?
>
The memset is, still, so close there in this version that it indeed
begs the question.
But it is there to ensure that we really did the port parts
properly.
-Mika
> Reviewed-by: Michał Winiarski
>
> -Michał
>
>> -memset(el->port, 0, sizeof(el->port));
>> +execlist_cancel_port_requests(el);
>>
>> /* Mark all executing requests as skipped. */
>> list_for_each_entry(rq, &engine->timeline->requests, link) {
>> @@ -1372,11 +1379,9 @@ static void reset_common_ring(struct intel_engine_cs
>> *engine,
>>struct drm_i915_gem_request *request)
>> {
>> struct intel_engine_execlist * const el = &engine->execlist;
>> -struct execlist_port *port = el->port;
>> struct drm_i915_gem_request *rq, *rn;
>> struct intel_context *ce;
>> unsigned long flags;
>> -unsigned int n;
>>
>> spin_lock_irqsave(&engine->timeline->lock, flags);
>>
>> @@ -1389,9 +1394,7 @@ static void reset_common_ring(struct intel_engine_cs
>> *engine,
>> * guessing the missed context-switch events by looking at what
>> * requests were completed.
>> */
>> -for (n = 0; n < ARRAY_SIZE(el->port); n++)
>> -i915_gem_request_put(port_request(&port[n]));
>> -memset(el->port, 0, sizeof(el->port));
>> +execlist_cancel_port_requests(el);
>>
>> /* Push back any incomplete requests for replay after the reset. */
>> list_for_each_entry_safe_reverse(rq, rn,
>> --
>> 2.11.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 21/31] drm/i915/slpc: Send RESET event to enable SLPC during Load/TDR
On Tue, 19 Sep 2017 19:41:57 +0200, Sagar Arun Kamble
wrote:
Send host2guc SLPC reset event to GuC post GuC load.
Post this, i915 can ascertain if SLPC has started running successfully
through shared data. This check is done during intel_init_gt_powersave.
This allows to get initial configuration setup by SLPC and if needed
move to Host RPS if SLPC runs into issues.
On TDR/Engine reset i915 should send extra flag
SLPC_RESET_FLAG_TDR_OCCURREDto clear SLPC state as appropriate.
v1: Extract host2guc_slpc to handle slpc status code
coding style changes (Paulo)
Removed WARN_ON for checking msb of gtt address of
shared gem obj. (ChrisW)
host2guc_action to i915_guc_action change.(Sagar)
Updating SLPC enabled status. (Sagar)
v2: Commit message update. (David)
v3: Rebase.
v4: Added DRM_INFO message when SLPC is enabled.
v5: Updated patch as host2guc_slpc is moved to earlier patch.
SLPC activation status message put after checking the
state from shared data during intel_init_gt_powersave.
v6: Added definition of host2guc_slpc and clflush the shared data only
for required size. Setting state to NOT_RUNNING before sending RESET
event. Output data for SLPC actions is to be retrieved during
intel_guc_send with lock protection so created wrapper
__intel_guc_send that outputs GuC output data if needed. Clearing
pm_rps_events on confirming SLPC RUNNING status so that even if
host touches any of the PM registers by mistake it should not have
any effect. (Sagar)
v7: Added save/restore_default_rps as Uncore sanitize will clear the
RP_CONTROL setup by BIOS. s/i915_ggtt_offset/guc_ggtt_offset.
v8: Added support for handling TDR based SLPC reset. Added functions
host2guc_slpc_tdr_reset, intel_slpc_reset_prepare and
intel_slpc_tdr_reset to handle TDR based SLPC reset.
Cc: Michal Wajdeczko
Signed-off-by: Tom O'Rourke
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_drv.c | 2 +
drivers/gpu/drm/i915/i915_irq.c | 7 +-
drivers/gpu/drm/i915/intel_pm.c | 10 +++
drivers/gpu/drm/i915/intel_slpc.c | 170
++
drivers/gpu/drm/i915/intel_slpc.h | 9 ++
drivers/gpu/drm/i915/intel_uc.c | 1 +
6 files changed, 198 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index f13a3de..932f9ef 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1074,6 +1074,8 @@ static int i915_driver_init_hw(struct
drm_i915_private *dev_priv)
intel_sanitize_options(dev_priv);
+ intel_slpc_save_default_rps(&dev_priv->guc.slpc);
+
ret = i915_ggtt_probe_hw(dev_priv);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c
index 4a1554c..2d5ad13 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2838,8 +2838,13 @@ void i915_handle_error(struct drm_i915_private
*dev_priv,
}
}
- if (!engine_mask)
+ if (!engine_mask) {
+ if (intel_slpc_active(&dev_priv->guc.slpc)) {
+ intel_slpc_reset_prepare(&dev_priv->guc.slpc);
+ intel_slpc_tdr_reset(&dev_priv->guc.slpc);
+ }
Can you just jump to single slpc function that will hide slpc internals ?
goto out;
+ }
/* Full reset needs the mutex, stop any other user trying to do so. */
if (test_and_set_bit(I915_RESET_BACKOFF, &dev_priv->gpu_error.flags)) {
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 6b2b7f8..c2065f2 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7918,6 +7918,16 @@ void intel_init_gt_powersave(struct
drm_i915_private *dev_priv)
intel_runtime_pm_get(dev_priv);
}
+ if (intel_slpc_enabled()) {
+ dev_priv->guc.slpc.active =
+ intel_slpc_get_status(&dev_priv->guc.slpc);
+ if (!intel_slpc_active(&dev_priv->guc.slpc)) {
+ i915.enable_slpc = 0;
+ intel_sanitize_gt_powersave(dev_priv);
+ } else
+ dev_priv->pm_rps_events = 0;
+ }
+
Hmm, on one hand you're trying to use friendly wrappers like
enabled() active() but at the same time you're modifying data
which these helpers were trying to hide ...
mutex_lock(&dev_priv->drm.struct_mutex);
mutex_lock(&dev_priv->pm.pcu_lock);
diff --git a/drivers/gpu/drm/i915/intel_slpc.c
b/drivers/gpu/drm/i915/intel_slpc.c
index f47d81e..57e69d4 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -390,6 +390,140 @@ static void slpc_shared_data_init(struct
intel_slpc *slpc)
kunmap_atomic(data);
}
+static void host2guc_slpc_reset(struct intel_slpc *slpc)
+{
+
Re: [Intel-gfx] [PATCH i-g-t 3/9] tests/perf: Add testcase to verify ctx id
On Wed, Sep 13, 2017 at 04:22:02PM +0530, Sagar Arun Kamble wrote:
> This subtest verifies that the CS perf samples contains
> proper HW context ID as captured through CONTEXT_PARAM_HW_ID.
>
> v2: Updated property enum names.
>
> Signed-off-by: Sagar Arun Kamble
Reviewed-by: Ewelina Musial
> ---
> lib/ioctl_wrappers.h| 1 +
> tests/intel_perf_dapc.c | 102
> +++-
> 2 files changed, 101 insertions(+), 2 deletions(-)
>
> diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
> index 090c125..44f15a0 100644
> --- a/lib/ioctl_wrappers.h
> +++ b/lib/ioctl_wrappers.h
> @@ -131,6 +131,7 @@ struct local_i915_gem_context_param {
> #define LOCAL_CONTEXT_PARAM_GTT_SIZE 0x3
> #define LOCAL_CONTEXT_PARAM_NO_ERROR_CAPTURE 0x4
> #define LOCAL_CONTEXT_PARAM_BANNABLE 0x5
> +#define LOCAL_CONTEXT_PARAM_HW_ID0x6
> uint64_t value;
> };
> void gem_context_require_bannable(int fd);
> diff --git a/tests/intel_perf_dapc.c b/tests/intel_perf_dapc.c
> index 92b4dee..23d6ffe 100644
> --- a/tests/intel_perf_dapc.c
> +++ b/tests/intel_perf_dapc.c
> @@ -644,10 +644,28 @@ read_perf_reports(int stream_fd,
> return true;
> }
>
> +static unsigned int
> +context_get_hw_ctx_id(int fd, unsigned int ctx)
> +{
> + struct local_i915_gem_context_param param;
> +
> + memset(¶m, 0, sizeof(param));
> + param.context = ctx;
> + param.param = LOCAL_CONTEXT_PARAM_HW_ID;
> + param.value = 0;
> + param.size = 0;
> +
> + if (__gem_context_get_param(fd, ¶m) == -EINVAL)
> + igt_assert(param.value == 0);
> +
> + return param.value;
> +}
> +
> static void
> perf_stream_capture_workload_samples(struct drm_i915_perf_open_param *param,
>uint8_t *perf_reports,
> - int num_reports, int report_size)
> + int num_reports, int report_size,
> + uint64_t *hw_ctx_id)
> {
> drm_intel_bufmgr *bufmgr;
> drm_intel_context *context0;
> @@ -676,6 +694,9 @@ retry:
> igt_assert_eq(ret, 0);
> igt_assert_neq(ctx_id, 0x);
>
> + if (hw_ctx_id)
> + *hw_ctx_id = context_get_hw_ctx_id(drm_fd, ctx_id);
> +
> igt_debug("opening i915-perf stream\n");
> stream_fd = __perf_open(drm_fd, param);
>
> @@ -776,7 +797,8 @@ test_oa_source(void)
> igt_assert(perf_reports);
>
> perf_stream_capture_workload_samples(¶m, perf_reports,
> - num_reports, report_size);
> + num_reports, report_size,
> + NULL);
> verify_source(perf_reports, num_reports, report_size);
> free(perf_reports);
> }
> @@ -784,6 +806,79 @@ test_oa_source(void)
> igt_waitchildren();
> }
>
> +struct oa_ctxid_sample {
> + uint64_t ctx_id;
> + uint8_t oa_report[];
> +};
> +
> +static void
> +verify_ctxid(uint8_t *perf_reports, int num_reports, size_t report_size,
> + uint64_t hw_ctx_id)
> +{
> + struct oa_ctxid_sample *sample;
> + uint32_t *oa_report;
> +
> + for (int i = 0; i < num_reports; i++) {
> + size_t offset = i * report_size;
> +
> + sample = (struct oa_ctxid_sample *) (perf_reports + offset);
> + oa_report = (uint32_t *) sample->oa_report;
> +
> + igt_debug("read report: ctx_id= %lu, reason = %x, "
> + "timestamp = %x\n",
> + sample->ctx_id, oa_report[0], oa_report[1]);
> +
> + if (!oa_report[0])
> + igt_assert(sample->ctx_id == hw_ctx_id);
> + }
> +}
> +
> +static void
> +test_perf_ctxid(void)
> +{
> + uint64_t properties[] = {
> + /* Include OA reports in samples */
> + DRM_I915_PERF_PROP_SAMPLE_OA, true,
> +
> + /* OA unit configuration */
> + DRM_I915_PERF_PROP_OA_METRICS_SET, test_metric_set_id,
> + DRM_I915_PERF_PROP_OA_FORMAT, test_oa_format,
> + DRM_I915_PERF_PROP_OA_EXPONENT, oa_exp_1_millisec,
> +
> + /* CS parameters */
> + local_DRM_I915_PERF_PROP_ENGINE, I915_EXEC_RENDER,
> + local_DRM_I915_PERF_PROP_SAMPLE_CTX_ID, true,
> + };
> + struct drm_i915_perf_open_param param = {
> + .flags = I915_PERF_FLAG_FD_CLOEXEC,
> + .num_properties = sizeof(properties) / 16,
> + .properties_ptr = to_user_pointer(properties),
> + };
> +
> + /* should be default, but just to be sure... */
> + write_u64_file("/proc/sys/dev/i915/perf_stream_paranoid", 1);
This function is used to write parameter to only one file so path could be
defined inside function
> +
> + igt_fork(child, 1) {
> + int prop_size = ARRAY_SIZE(properties);
> + int num_reports = 10
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bios: ignore HDMI on port A
== Series Details == Series: drm/i915/bios: ignore HDMI on port A URL : https://patchwork.freedesktop.org/series/30700/ State : success == Summary == Series 30700v1 drm/i915/bios: ignore HDMI on port A https://patchwork.freedesktop.org/api/1.0/series/30700/revisions/1/mbox/ Test chamelium: Subgroup dp-crc-fast: pass -> FAIL (fi-kbl-7500u) fdo#102514 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-legacy: pass -> FAIL (fi-snb-2600) fdo#100215 Test pm_rpm: Subgroup basic-rte: pass -> DMESG-WARN (fi-cfl-s) fdo#102294 fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:438s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:472s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:417s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:521s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:278s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:508s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:489s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:497s fi-cfl-s total:289 pass:222 dwarn:35 dfail:0 fail:0 skip:32 time:547s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:416s fi-glk-1 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:563s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:430s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:404s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:434s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:489s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:460s fi-kbl-7500u total:289 pass:263 dwarn:1 dfail:0 fail:1 skip:24 time:460s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:574s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:585s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:547s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:452s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:750s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:486s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:476s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:567s fi-snb-2600 total:289 pass:248 dwarn:0 dfail:0 fail:2 skip:39 time:409s 01a2040bb790263c0d32ec30d83bd2ddf3b922c2 drm-tip: 2017y-09m-21d-13h-23m-06s UTC integration manifest 6cc7ac35bcff drm/i915/bios: ignore HDMI on port A == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5778/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/bios: ignore HDMI on port A
The hardware state readout oopses after several warnings when trying to
use HDMI on port A, if such a combination is configured in VBT. Filter
the combo out already at the VBT parsing phase.
v2: also ignore DVI (Ville)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102889
Cc: sta...@vger.kernel.org
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 5949750a35ee..97931b294f9a 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1162,6 +1162,13 @@ static void parse_ddi_port(struct drm_i915_private
*dev_priv, enum port port,
is_hdmi = is_dvi && (child->device_type & DEVICE_TYPE_NOT_HDMI_OUTPUT)
== 0;
is_edp = is_dp && (child->device_type & DEVICE_TYPE_INTERNAL_CONNECTOR);
+ if (port == PORT_A && is_dvi) {
+ DRM_DEBUG_KMS("VBT claims port A supports DVI%s, ignoring\n",
+ is_hdmi ? "/HDMI" : "");
+ is_dvi = false;
+ is_hdmi = false;
+ }
+
info->supports_dvi = is_dvi;
info->supports_hdmi = is_hdmi;
info->supports_dp = is_dp;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] force yuv 4:2:0 output
Done. https://bugs.freedesktop.org/show_bug.cgi?id=102928 Let me know if I miss anything or you need me to do more tests. BR, Wolfgang Jani Nikula schrieb am Do., 21. Sep. 2017 um 10:14 Uhr: > > On Wed, 20 Sep 2017, Wolfgang Haupt wrote: > > I've tried v4.14-rc1. > > Now I do not have 4k@60 anymore. > > Okay, please file a bug at > https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel > > > dmesg with drm.debug: > > http://sprunge.us/TKbO > > Attach dmesg all the way from boot to the bug please. > > BR, > Jani. > > > > > > > Best Regards, > > Wolfgang > > > > Jani Nikula schrieb am Di., 19. Sep. 2017 > um > > 12:08 Uhr: > > > >> On Mon, 18 Sep 2017, Wolfgang Haupt wrote: > >> > Hello everyone, > >> > > >> > recently I played around with my kabylake i5 nuc box and found that on > >> some > >> > TV's > >> > the screen stays black as soon as I go to 4k@60. > >> > The TV only accepts 4k@60 at yuv 4:2:0 (I also saw hdmi range > extenders > >> and > >> > stuff that don't support yuv 4:4:4 on 4k@60). > >> > I tried to force limited mode through xrandr or by overriding the edid > >> > information, but nothing worked so far. > >> > Now I wonder if there is a way to force yuv 4:2:0 ouptut on the kernel > >> > level. > >> > Thanks. > >> > >> Please try v4.14-rc1. > >> > >> BR, > >> Jani. > >> > >> > >> -- > >> Jani Nikula, Intel Open Source Technology Center > >> > > -- > Jani Nikula, Intel Open Source Technology Center > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v6,1/3] drm/i915: Rename global i915 to i915_modparams
== Series Details == Series: series starting with [v6,1/3] drm/i915: Rename global i915 to i915_modparams URL : https://patchwork.freedesktop.org/series/30621/ State : success == Summary == Series 30621v1 series starting with [v6,1/3] drm/i915: Rename global i915 to i915_modparams https://patchwork.freedesktop.org/api/1.0/series/30621/revisions/1/mbox/ Test pm_rpm: Subgroup basic-rte: pass -> DMESG-WARN (fi-cfl-s) fdo#102294 Test drv_module_reload: Subgroup basic-reload: pass -> DMESG-WARN (fi-glk-1) fdo#102777 fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294 fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:446s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:469s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:417s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:511s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:277s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:504s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:489s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:480s fi-cfl-s total:289 pass:222 dwarn:35 dfail:0 fail:0 skip:32 time:539s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:415s fi-glk-1 total:289 pass:259 dwarn:1 dfail:0 fail:0 skip:29 time:562s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:433s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:404s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:429s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:484s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:465s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:471s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:577s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:589s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:541s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:452s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:751s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:484s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:474s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:569s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:1 skip:39 time:417s 01a2040bb790263c0d32ec30d83bd2ddf3b922c2 drm-tip: 2017y-09m-21d-13h-23m-06s UTC integration manifest 8087d51804e4 drm/i915: Make i915_modparams members const c16310a7a4e0 drm/i915: Prepare error capture to work with const modparams bfcde34551b0 drm/i915: Rename global i915 to i915_modparams == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5779/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH][drm-next] drm/i915/gvt: ensure -ve return value is handled correctly
On Thu, 2017-09-21 at 06:44 +0800, Zhenyu Wang wrote:
> On 2017.09.19 19:35:23 -0700, Joe Perches wrote:
> > On Wed, 2017-09-20 at 05:46 +0800, Zhenyu Wang wrote:
> > > On 2017.09.19 16:55:34 +0100, Colin King wrote:
> > > > From: Colin Ian King
> > > >
> > > > An earlier fix changed the return type from find_bb_size however the
> > > > integer return is being assigned to a unsigned int so the -ve error
> > > > check will never be detected. Make bb_size an int to fix this.
> > > >
> > > > Detected by CoverityScan CID#1456886 ("Unsigned compared against 0")
> > > >
> > > > Fixes: 1e3197d6ad73 ("drm/i915/gvt: Refine error handling for
> > > > perform_bb_shadow")
> > > > Signed-off-by: Colin Ian King
> > > > ---
> > > > drivers/gpu/drm/i915/gvt/cmd_parser.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> > > > b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> > > > index 2c0ccbb817dc..f41cbf664b69 100644
> > > > --- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> > > > +++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> > > > @@ -1628,7 +1628,7 @@ static int perform_bb_shadow(struct
> > > > parser_exec_state *s)
> > > > struct intel_shadow_bb_entry *entry_obj;
> > > > struct intel_vgpu *vgpu = s->vgpu;
> > > > unsigned long gma = 0;
> > > > - uint32_t bb_size;
> > > > + int bb_size;
> > > > void *dst = NULL;
> > > > int ret = 0;
> > > >
> > >
> > > Applied this, thanks!
> >
> > Is it possible for bb_size to be both >= 2g and valid?
>
> Never be possible in practise and if really that big I think something
> is already insane indeed.
It's good idea to document these assumptions as WARN_ON's. In i915, if
the value is completely internal to kernel, we're using GEM_BUG_ON for
these so that our CI will notice breakage. If it's not a driver
internal value only, a WARN_ON is the appropriate action.
Otherwise the information is lost and the next person reading the code
will have the same question in mind.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/6] tests/kms_mmio_vs_cs_flip: Reduce blit width
From: Ville Syrjälä
The blit stride is a two's complement 16 bit number, so trying to
use a stride of 32k would in fact give us -32k. Not sure how this
ever worked on anything, but my 945gm sure doesn't like it. The
machine dies pretty much instantly. Let's reduce the blit to use
a 16k stride instead. Also put in the missing bits for a proper
32bpp blit.
Or maybe time to retire this test since we no longer use CS flips?
Signed-off-by: Ville Syrjälä
---
tests/kms_mmio_vs_cs_flip.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/tests/kms_mmio_vs_cs_flip.c b/tests/kms_mmio_vs_cs_flip.c
index fa947d9cd7f4..851f9a66ebbf 100644
--- a/tests/kms_mmio_vs_cs_flip.c
+++ b/tests/kms_mmio_vs_cs_flip.c
@@ -72,12 +72,13 @@ static void exec_blt(data_t *data)
batch = intel_batchbuffer_alloc(data->bufmgr, data->devid);
igt_assert(batch);
- w = 8192;
- h = data->busy_bo->size / (8192 * 4);
+ w = 4096;
+ h = data->busy_bo->size / (4096 * 4);
pitch = w * 4;
for (i = 0; i < 40; i++) {
- BLIT_COPY_BATCH_START(0);
+ BLIT_COPY_BATCH_START(XY_SRC_COPY_BLT_WRITE_ALPHA |
+ XY_SRC_COPY_BLT_WRITE_RGB);
OUT_BATCH((3 << 24) | /* 32 bits */
(0xcc << 16) | /* copy ROP */
pitch);
--
2.13.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 5/6] tests/kms_panel_fitting: Skip sprite test if we exceed sprite scaling limits
From: Ville Syrjälä
g4x-bdw surface isn't allowed to exceed 2kx2k pixels when scaling, and
the stride must not exceed 4k bytes. The test tries to scale a 1920x1080
32bpp image which exceeds the sprite's stride limitations. Let's make
the test a bit more tolerant and just ignore failures from the sprite
tests. This does reduce the usefulness of the test somewhat, but without
CRC support the test isn't all that useful anyway.
Bugzilla: https://bugs.freedesktop.org/attachment.cgi?id=132953
Signed-off-by: Ville Syrjälä
---
tests/kms_panel_fitting.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/tests/kms_panel_fitting.c b/tests/kms_panel_fitting.c
index 5266862a70cf..af3e39fd7b22 100644
--- a/tests/kms_panel_fitting.c
+++ b/tests/kms_panel_fitting.c
@@ -197,12 +197,16 @@ static void test_panel_fitting(data_t *d)
igt_fb_set_size(&d->fb2, d->plane2, d->fb2.width-200,
d->fb2.height-200);
igt_plane_set_position(d->plane2, 100, 100);
igt_plane_set_size(d->plane2, mode->hdisplay-200,
mode->vdisplay-200);
- igt_display_commit2(display, COMMIT_UNIVERSAL);
-
- /* enable panel fitting along with sprite scaling */
- mode->hdisplay = 1024;
- mode->vdisplay = 768;
- prepare_crtc(d, output, pipe, d->plane1, mode, COMMIT_LEGACY);
+ /*
+* The sprite may not be able to scale such a large image.
+* Just skip the sprite scaling tests in that case.
+*/
+ if (!igt_display_try_commit2(display, COMMIT_UNIVERSAL)) {
+ /* enable panel fitting along with sprite scaling */
+ mode->hdisplay = 1024;
+ mode->vdisplay = 768;
+ prepare_crtc(d, output, pipe, d->plane1, mode,
COMMIT_LEGACY);
+ }
/* back to single plane mode */
igt_plane_set_fb(d->plane2, NULL);
--
2.13.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 4/6] tests/kms_panel_fitting: Use igt_cairo_image_surface_create_from_png_file()
From: Ville Syrjälä Switch to using igt_cairo_image_surface_create_from_png_file() over the raw cairo version so that the test can actually find the image file no matter where we run it from. Signed-off-by: Ville Syrjälä --- tests/kms_panel_fitting.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/kms_panel_fitting.c b/tests/kms_panel_fitting.c index e145a2dfc970..5266862a70cf 100644 --- a/tests/kms_panel_fitting.c +++ b/tests/kms_panel_fitting.c @@ -159,7 +159,7 @@ static void test_panel_fitting(data_t *d) native_mode = *mode; /* allocate fb2 with image size */ - image = cairo_image_surface_create_from_png(FILE_NAME); + image = igt_cairo_image_surface_create_from_png(FILE_NAME); igt_assert(cairo_surface_status(image) == CAIRO_STATUS_SUCCESS); d->image_w = cairo_image_surface_get_width(image); d->image_h = cairo_image_surface_get_height(image); -- 2.13.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 3/6] lib/igt_fb: Add igt_cairo_image_surface_create_from_png()
From: Ville Syrjälä
Raw usage of cairo_image_surface_create_from_png() doesn't work
since it doesn't know about IGT_DATADIR and IGT_SRCDIR. Let's extract
the helper from igt_paint_image() that uses igt_fopen_data() +
cairo_image_surface_create_from_png_stream() and call it
igt_cairo_image_surface_create_from_png_file().
Signed-off-by: Ville Syrjälä
---
lib/igt_fb.c | 21 ++---
lib/igt_fb.h | 1 +
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index 95434a699dcf..d4eaed71acef 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -583,6 +583,18 @@ stdio_read_func(void *closure, unsigned char* data,
unsigned int size)
return CAIRO_STATUS_SUCCESS;
}
+cairo_surface_t *igt_cairo_image_surface_create_from_png(const char *filename)
+{
+ cairo_surface_t *image;
+ FILE *f;
+
+ f = igt_fopen_data(filename);
+ image = cairo_image_surface_create_from_png_stream(&stdio_read_func, f);
+ fclose(f);
+
+ return image;
+}
+
/**
* igt_paint_image:
* @cr: cairo drawing context
@@ -601,11 +613,8 @@ void igt_paint_image(cairo_t *cr, const char *filename,
cairo_surface_t *image;
int img_width, img_height;
double scale_x, scale_y;
- FILE* f;
-
- f = igt_fopen_data(filename);
- image = cairo_image_surface_create_from_png_stream(&stdio_read_func, f);
+ image = igt_cairo_image_surface_create_from_png(filename);
igt_assert(cairo_surface_status(image) == CAIRO_STATUS_SUCCESS);
img_width = cairo_image_surface_get_width(image);
@@ -624,8 +633,6 @@ void igt_paint_image(cairo_t *cr, const char *filename,
cairo_surface_destroy(image);
cairo_restore(cr);
-
- fclose(f);
}
/**
@@ -877,7 +884,7 @@ unsigned int igt_create_image_fb(int fd, int width, int
height,
uint32_t fb_id;
cairo_t *cr;
- image = cairo_image_surface_create_from_png(filename);
+ image = igt_cairo_image_surface_create_from_png(filename);
igt_assert(cairo_surface_status(image) == CAIRO_STATUS_SUCCESS);
if (width == 0)
width = cairo_image_surface_get_width(image);
diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index a193a1e7572d..3f549036abc5 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -136,6 +136,7 @@ uint64_t igt_fb_tiling_to_mod(uint64_t tiling);
/* cairo-based painting */
cairo_surface_t *igt_get_cairo_surface(int fd, struct igt_fb *fb);
+cairo_surface_t *igt_cairo_image_surface_create_from_png(const char *filename);
cairo_t *igt_get_cairo_ctx(int fd, struct igt_fb *fb);
void igt_paint_color(cairo_t *cr, int x, int y, int w, int h,
double r, double g, double b);
--
2.13.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 6/6] tests/kms_draw_crc: Skip tests for unsupported formats
From: Ville Syrjälä
10bpc formats aren't supported on all platforms, so skip the test when
we can't create the framebuffer.
Signed-off-by: Ville Syrjälä
---
tests/kms_draw_crc.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/tests/kms_draw_crc.c b/tests/kms_draw_crc.c
index 260950c76e00..723e7a182c95 100644
--- a/tests/kms_draw_crc.c
+++ b/tests/kms_draw_crc.c
@@ -153,16 +153,33 @@ static void get_method_crc(enum igt_draw_method method,
uint32_t drm_format,
igt_remove_fb(drm_fd, &fb);
}
+static bool format_is_supported(uint32_t format, uint64_t modifier)
+{
+ uint32_t gem_handle, fb_id;
+ unsigned int stride;
+ int ret;
+
+ gem_handle = igt_create_bo_with_dimensions(drm_fd, 64, 64,
+ format, modifier,
+ 0, NULL, &stride, NULL);
+ ret = __kms_addfb(drm_fd, gem_handle, 64, 64,
+ stride, format, modifier,
+ LOCAL_DRM_MODE_FB_MODIFIERS, &fb_id);
+ drmModeRmFB(drm_fd, fb_id);
+ gem_close(drm_fd, gem_handle);
+
+ return ret == 0;
+}
+
static void draw_method_subtest(enum igt_draw_method method,
uint32_t format_index, uint64_t tiling)
{
igt_crc_t crc;
- if (tiling == LOCAL_I915_FORMAT_MOD_Y_TILED)
- igt_require(intel_gen(intel_get_drm_devid(drm_fd)) >= 9);
-
igt_skip_on(method == IGT_DRAW_MMAP_WC && !gem_mmap__has_wc(drm_fd));
+ igt_require(format_is_supported(formats[format_index], tiling));
+
/* Use IGT_DRAW_MMAP_GTT on an untiled buffer as the parameter for
* comparison. Cache the value so we don't recompute it for every single
* subtest. */
--
2.13.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/6] lib/igt_kms: Don't assert on non-existent plane
From: Ville Syrjälä
Skip when a test can't find a plane by the index. Previously
in commit 5426dc0a889a ("lib/kms: Skip rather than fail when
a suitable plane can't be found") we added similar handling for
tests trying to find a non-existent plane by type. Saves from
every test with hardcoded plane numbers having to check the
number of planes available.
Signed-off-by: Ville Syrjälä
---
lib/igt_kms.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 7bcafc072f70..83ebb42e6c9a 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -2008,9 +2008,9 @@ static igt_pipe_t
*igt_output_get_driving_pipe(igt_output_t *output)
static igt_plane_t *igt_pipe_get_plane(igt_pipe_t *pipe, int plane_idx)
{
- igt_assert_f(plane_idx >= 0 && plane_idx < pipe->n_planes,
- "Valid pipe->planes plane_idx not found, plane_idx=%d
n_planes=%d",
- plane_idx, pipe->n_planes);
+ igt_require_f(plane_idx >= 0 && plane_idx < pipe->n_planes,
+ "Valid pipe->planes plane_idx not found, plane_idx=%d
n_planes=%d",
+ plane_idx, pipe->n_planes);
return &pipe->planes[plane_idx];
}
--
2.13.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 7/9] tests/perf: Add testcase to verify mmio
On Wed, Sep 13, 2017 at 04:22:06PM +0530, Sagar Arun Kamble wrote:
> v2: Updated the check for RC6 register value.
> Updated property enum names. Defined local_I915_PERF_MMIO_NUM_MAX
> and local_drm_i915_perf_mmio_list for local use.
>
> Signed-off-by: Sagar Arun Kamble
> ---
> tests/intel_perf_dapc.c | 266
>
> 1 file changed, 266 insertions(+)
>
> diff --git a/tests/intel_perf_dapc.c b/tests/intel_perf_dapc.c
> index 7a6effa..8644505 100644
> --- a/tests/intel_perf_dapc.c
> +++ b/tests/intel_perf_dapc.c
> @@ -127,6 +127,12 @@ enum {
> local_I915_PERF_SAMPLE_OA_SOURCE_MAX/* non-ABI */
> };
>
> +#define local_I915_PERF_MMIO_NUM_MAX 8
> +struct local_drm_i915_perf_mmio_list {
> + __u32 num_mmio;
> + __u32 mmio_list[local_I915_PERF_MMIO_NUM_MAX];
> +};
> +
> enum {
> local_DRM_I915_PERF_PROP_SAMPLE_OA_SOURCE =
> DRM_I915_PERF_PROP_OA_EXPONENT + 1,
> local_DRM_I915_PERF_PROP_ENGINE = DRM_I915_PERF_PROP_OA_EXPONENT + 2,
> @@ -1163,6 +1169,260 @@ test_perf_ts(void)
> igt_waitchildren();
> }
>
> +static char *
> +read_debugfs_record(int device, const char *file, const char *key)
In igt_debugfs.c we have some functions which could be used instead I think.
If not those could be added there as a another helpers.
> +{
> + FILE *fp;
> + int fd;
> + char *line = NULL;
> + size_t line_buf_size = 0;
> + int len = 0;
> + int key_len = strlen(key);
> + char *value = NULL;
> +
> + fd = igt_debugfs_open(device, file, O_RDONLY);
> + fp = fdopen(fd, "r");
> + igt_require(fp);
> +
> + while ((len = getline(&line, &line_buf_size, fp)) > 0) {
> +
> + if (line[len - 1] == '\n')
> + line[len - 1] = '\0';
> +
> + if (strncmp(key, line, key_len) == 0 &&
> + line[key_len] == ':' &&
> + line[key_len + 1] == ' ') {
> + value = strdup(line + key_len + 2);
> + goto done;
> + }
> + }
> +
> + igt_assert(!"reached");
> +done:
> + free(line);
> + fclose(fp);
> + close(fd);
> + return value;
> +}
> +
> +static uint64_t
> +read_debugfs_u64_record(int fd, const char *file, const char *key)
The same as above
> +{
> + char *str_val = read_debugfs_record(fd, file, key);
> + uint64_t val;
> +
> + igt_require(str_val);
> +
> + val = strtoull(str_val, NULL, 0);
> + free(str_val);
> +
> + return val;
> +}
> +
> +struct oa_mmio_sample {
> + uint32_t mmio[2];
> + uint8_t oa_report[];
> +};
> +
> +static void
> +verify_oa_mmio(uint8_t *perf_reports, int num_reports, size_t report_size,
> +uint64_t *pre_mmio_residency, uint64_t *post_mmio_residency)
> +{
> + struct oa_mmio_sample *sample;
> + uint32_t *oa_report;
> +
> + igt_debug("pre rc6 residency = %lu, rc6p residency = %lu, "
> + "post rc6 residency = %lu, rc6p residency = %lu\n",
> + pre_mmio_residency[0], pre_mmio_residency[1],
> + post_mmio_residency[0], post_mmio_residency[1]);
> +
> + for (int i = 0; i < num_reports; i++) {
> + size_t offset = i * report_size;
> +
> + sample = (struct oa_mmio_sample *) (perf_reports + offset);
> + oa_report = (uint32_t *) sample->oa_report;
> +
> + igt_debug("read mmio: rc6 = %u, rc6p = %u\n",
> + sample->mmio[0], sample->mmio[1]);
> +
> + igt_debug("read report: reason = %x, timestamp = %x\n",
> + oa_report[0], oa_report[1]);
> +
> + if (!oa_report[0]) {
> + igt_assert(sample->mmio[0] >= pre_mmio_residency[0]);
> + igt_assert(sample->mmio[1] >= pre_mmio_residency[1]);
> + igt_assert(sample->mmio[0] <= post_mmio_residency[0]);
> + igt_assert(sample->mmio[1] <= post_mmio_residency[1]);
> + }
> + }
> +}
> +
> +static void
> +test_perf_oa_mmio(void)
> +{
> + uint64_t properties[] = {
> + /* Include OA reports in samples */
> + DRM_I915_PERF_PROP_SAMPLE_OA, true,
> +
> + /* OA unit configuration */
> + DRM_I915_PERF_PROP_OA_METRICS_SET, test_metric_set_id,
> + DRM_I915_PERF_PROP_OA_FORMAT, test_oa_format,
> + DRM_I915_PERF_PROP_OA_EXPONENT, oa_exp_1_millisec,
> +
> + /* CS parameters */
> + local_DRM_I915_PERF_PROP_ENGINE, I915_EXEC_RENDER,
> + local_DRM_I915_PERF_PROP_SAMPLE_MMIO, 0,
> + };
> + struct drm_i915_perf_open_param param = {
> + .flags = I915_PERF_FLAG_FD_CLOEXEC,
> + .num_properties = sizeof(properties) / 16,
> + .properties_ptr = to_user_pointer(properties),
> + };
> + struct local_drm_i915_perf_mmio_list mmio;
> +
> + memset(&mmio, 0, sizeof(mmio));
> +
> +#define GEN6_GT_GFX_RC6
Re: [Intel-gfx] [PATCH 1/2] drm/dp: Add defines for latency in sink
On Wed, Sep 20, 2017 at 02:32:34PM +, vathsala nagaraju wrote: > Add defines for dpcd register 2009 (synchronization latency > in sink). > > Cc: Rodrigo Vivi > CC: Puthikorn Voravootivat > Signed-off-by: Vathsala Nagaraju I keep forgetting to update my eDP spec 1.4 to this 1.4b... Reviewed-by: Rodrigo Vivi > --- > include/drm/drm_dp_helper.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index 11c39f1..846004e6 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -735,6 +735,9 @@ > # define DP_PSR_SINK_INTERNAL_ERROR 7 > # define DP_PSR_SINK_STATE_MASK 0x07 > > +#define DP_SINK_SYNCHRONIZATION_LATENCY 0x2009 > +# define DP_MAX_RESYNC_FRAME_CNT_MASK0xf > + > #define DP_RECEIVER_ALPM_STATUS 0x200b /* eDP 1.4 */ > # define DP_ALPM_LOCK_TIMEOUT_ERROR (1 << 0) > > -- > 1.9.1 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/i915: Introduce execlist_port_* accessors
Chris Wilson writes:
> Quoting Mika Kuoppala (2017-09-20 15:37:03)
>> Instead of trusting that first available port is at index 0,
>> use accessor to hide this. This is a preparation for a
>> following patches where head can be at arbitrary location
>> in the port array.
>>
>> v2: improved commit message, elsp_ready readability (Chris)
>>
>> Signed-off-by: Mika Kuoppala
>> ---
>> drivers/gpu/drm/i915/i915_debugfs.c| 16 +++
>> drivers/gpu/drm/i915/i915_gpu_error.c | 4 +--
>> drivers/gpu/drm/i915/i915_guc_submission.c | 17 ++-
>> drivers/gpu/drm/i915/i915_irq.c| 2 +-
>> drivers/gpu/drm/i915/intel_engine_cs.c | 2 +-
>> drivers/gpu/drm/i915/intel_lrc.c | 42 +++
>> drivers/gpu/drm/i915/intel_ringbuffer.h| 46
>> ++
>> 7 files changed, 87 insertions(+), 42 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
>> b/drivers/gpu/drm/i915/i915_debugfs.c
>> index dbeb6f08ab79..af8cc2eab1b1 100644
>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>> @@ -3348,16 +3348,20 @@ static int i915_engine_info(struct seq_file *m, void
>> *unused)
>>
>> rcu_read_lock();
>> for (idx = 0; idx < execlist_num_ports(el); idx++) {
>> - unsigned int count;
>> + const struct execlist_port *port;
>> + unsigned int count, n;
>>
>> - rq = port_unpack(&el->port[idx], &count);
>> + port = execlist_port_index(el, idx);
>> + n = port_index(port, el);
>
> Bah, execlist_port_index() implies to me that it should return the
> index, not the port. I would just call it execlist_port(). How does that
> look?
It looks much better.
>
>> -static inline void
>> +#define __port_idx(start, index, mask) (((start) + (index)) & (mask))
>> +
>> +static inline struct execlist_port *
>> +execlist_port_head(struct intel_engine_execlist * const el)
>> +{
>> + return &el->port[el->port_head];
>> +}
>> +
>> +/* Index starting from port_head */
>> +static inline struct execlist_port *
>> +execlist_port_index(struct intel_engine_execlist * const el,
>> + const unsigned int n)
>> +{
>> + return &el->port[__port_idx(el->port_head, n, el->port_mask)];
>> +}
>> +
>> +static inline struct execlist_port *
>> +execlist_port_tail(struct intel_engine_execlist * const el)
>> +{
>> + return &el->port[__port_idx(el->port_head, -1, el->port_mask)];
>> +}
>
> Hmm, I was expecting
>
> execlist_port_head() { return execlist_port(el, 0); }
> execlist_port_tail() { return execlist_port(el, -1); }
Seems that I did these on the next patch, moved to here.
>
> What's the impact on object size? (As a quick guide to how much the
> compiler can keep the code in check.)
I can't say what would constitute as a still in check, but things
grow:
add/remove: 0/0 grow/shrink: 6/1 up/down: 277/-26 (251)
function old new delta
intel_lrc_irq_handler 15911700+109
i915_guc_irq_handler10411110 +69
i915_engine_info19832031 +48
insert_request 127 152 +25
intel_engine_is_idle 304 317 +13
gen8_cs_irq_handler 113 126 +13
capture 54545428 -26
Total: Before=1144612, After=1144863, chg +0.02%
-Mika
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/bios: ignore HDMI on port A
On Thu, Sep 21, 2017 at 05:19:20PM +0300, Jani Nikula wrote:
> The hardware state readout oopses after several warnings when trying to
> use HDMI on port A, if such a combination is configured in VBT. Filter
> the combo out already at the VBT parsing phase.
>
> v2: also ignore DVI (Ville)
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102889
> Cc: sta...@vger.kernel.org
> Cc: Imre Deak
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_bios.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 5949750a35ee..97931b294f9a 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1162,6 +1162,13 @@ static void parse_ddi_port(struct drm_i915_private
> *dev_priv, enum port port,
> is_hdmi = is_dvi && (child->device_type & DEVICE_TYPE_NOT_HDMI_OUTPUT)
> == 0;
> is_edp = is_dp && (child->device_type & DEVICE_TYPE_INTERNAL_CONNECTOR);
>
> + if (port == PORT_A && is_dvi) {
We may want to do the same for PORT_E. Although in that case we would
already reject it in intel_hdmi_init_connector() since PORT_E can have
max 2 lanes and HDMI needs 4. But looks like that would result in a WARN.
Given that we've now seen a bogus VBT for port A I wouldn't put it past
them to cook one up for port E as well.
Either way
Reviewed-by: Ville Syrjälä
> + DRM_DEBUG_KMS("VBT claims port A supports DVI%s, ignoring\n",
> + is_hdmi ? "/HDMI" : "");
> + is_dvi = false;
> + is_hdmi = false;
> + }
> +
> info->supports_dvi = is_dvi;
> info->supports_hdmi = is_hdmi;
> info->supports_dp = is_dp;
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/lrc: Only enable per-context and per-bb buffers if set
== Series Details == Series: series starting with [1/2] drm/i915/lrc: Only enable per-context and per-bb buffers if set URL : https://patchwork.freedesktop.org/series/30701/ State : success == Summary == Series 30701v1 series starting with [1/2] drm/i915/lrc: Only enable per-context and per-bb buffers if set https://patchwork.freedesktop.org/api/1.0/series/30701/revisions/1/mbox/ Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 Test drv_module_reload: Subgroup basic-reload: pass -> DMESG-WARN (fi-glk-1) fdo#102777 +1 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:437s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:471s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:415s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:520s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:277s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:507s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:491s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:495s fi-cfl-s total:289 pass:223 dwarn:34 dfail:0 fail:0 skip:32 time:536s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:416s fi-glk-1 total:289 pass:258 dwarn:2 dfail:0 fail:0 skip:29 time:622s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:426s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:404s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:433s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:487s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:460s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:470s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:572s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:588s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:545s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:449s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:741s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:489s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:475s fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:419s fi-snb-2520m failed to connect after reboot 01a2040bb790263c0d32ec30d83bd2ddf3b922c2 drm-tip: 2017y-09m-21d-13h-23m-06s UTC integration manifest d02479d1940a drm/i915/lrc: Skip no-op per-bb buffer on gen9 894bcf3f84c6 drm/i915/lrc: Only enable per-context and per-bb buffers if set == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5780/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt] igt/kms_psr_sink_crc: Fix regression in psr_drrs subtest
On Thu, Sep 21, 2017 at 01:37:31AM +, Radhakrishna Sripada wrote: > The substring to be matched is modified to reflect kernel code. Well, technically it is not a regression on psr_drrs because it has this bug since the beginning ;) Also this commit message doesn't explain the false positive case that DK pointed out. Also this doesn't explain that is safe to use the reverse logic of !yes because DRRS is only enabled for eDP. Otherwise we would have to parse specifically the eDP block. What brings me the question of why do we list all that useless information on debugfs? :) > > Fixes: 33355210a43e (igt/kms_psr_sink_crc: Add psr_drrs subtest) > Cc: Rodrigo Vivi > Cc: Dhinakaran Pandiyan > Signed-off-by: Radhakrishna Sripada Please also CC other folks that are currently working on DRRS.. > --- > tests/kms_psr_sink_crc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c > index 1c25f2c81a34..f023b12c0131 100644 > --- a/tests/kms_psr_sink_crc.c > +++ b/tests/kms_psr_sink_crc.c > @@ -290,7 +290,7 @@ static bool drrs_disabled(data_t *data) > > igt_debugfs_read(data->drm_fd, "i915_drrs_status", buf); > > - return strstr(buf, "DRRS Support: No\n"); > + return !strstr(buf, "DRRS Supported: Yes\n"); > } > > static void run_test(data_t *data) > -- > 2.9.3 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 25/29] drm/i915: Stop frobbing with DDI encoder->type
From: Ville Syrjälä
Currently the DDI encoder->type will change at runtime depending on
what kind of hotplugs we've processed. That's quite bad since we can't
really trust that that current value of encoder->type actually matches
the type of signal we're trying to drive through it.
Let's eliminate that problem by declaring that non-eDP DDI port will
always have the encoder type as INTEL_OUTPUT_DDI. This means the code
can no longer try to distinguish DP vs. HDMI based on encoder->type.
We'll eDP as INTEL_OUTPUT_EDP, since it'll never change and there's a
bunch of code that relies on that value to identofy eDP.
We'll introduce a new encoder .compute_output_type() hook. This allows
us to compute the full output_types before any encoder .compute_config()
hooks get called, thus those hooks can rely on output_types being
correct, which is useful for cloning on oldr platforms. For now we'll
just look at the connector type and pick the correct mode based on that.
In the future the new hook could be used to implement dynamic switching
between LS and PCON modes for LSPCON.
TODO: maybe make .get_config() populate output_types rather than doing
the default encoder->type thing in caller and then undoing it for
DDI in .get_config().
v2: Fix BXT/GLK PPS explosion with DSI/MST encoders
v3: Avoid the PPS warn on pure HDMI/DVI DDI encoders by checking dp.output_reg
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/intel_ddi.c | 50 +--
drivers/gpu/drm/i915/intel_display.c | 11 +---
drivers/gpu/drm/i915/intel_dp.c | 19 +
drivers/gpu/drm/i915/intel_drv.h | 7 +++--
drivers/gpu/drm/i915/intel_hdmi.c | 10 ++-
drivers/gpu/drm/i915/intel_opregion.c | 2 +-
7 files changed, 65 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index ca6fa6d122c6..73601464240d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3053,7 +3053,7 @@ static void intel_connector_info(struct seq_file *m,
break;
case DRM_MODE_CONNECTOR_HDMIA:
if (intel_encoder->type == INTEL_OUTPUT_HDMI ||
- intel_encoder->type == INTEL_OUTPUT_UNKNOWN)
+ intel_encoder->type == INTEL_OUTPUT_DDI)
intel_hdmi_info(m, intel_connector);
break;
default:
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index d625bfe6d420..17b9bb80fb09 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -497,10 +497,8 @@ enum port intel_ddi_get_encoder_port(struct intel_encoder
*encoder)
switch (encoder->type) {
case INTEL_OUTPUT_DP_MST:
return enc_to_mst(&encoder->base)->primary->port;
- case INTEL_OUTPUT_DP:
case INTEL_OUTPUT_EDP:
- case INTEL_OUTPUT_HDMI:
- case INTEL_OUTPUT_UNKNOWN:
+ case INTEL_OUTPUT_DDI:
return enc_to_dig_port(&encoder->base)->port;
case INTEL_OUTPUT_ANALOG:
return PORT_E;
@@ -1516,6 +1514,7 @@ void intel_ddi_set_vc_payload_alloc(const struct
intel_crtc_state *crtc_state,
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
uint32_t temp;
+
temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (state == true)
temp |= TRANS_DDI_DP_VC_PAYLOAD_ALLOC;
@@ -2489,6 +2488,13 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
struct intel_digital_port *intel_dig_port;
u32 temp, flags = 0;
+ /*
+* Can be set by the caller based on encoder->type.
+* Undo that since we don't want INTEL_OUTPUT_DDI
+* to appear in output_types.
+*/
+ pipe_config->output_types &= ~BIT(INTEL_OUTPUT_DDI);
+
/* XXX: DSI transcoder paranoia */
if (WARN_ON(transcoder_is_dsi(cpu_transcoder)))
return;
@@ -2537,12 +2543,23 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
pipe_config->hdmi_high_tmds_clock_ratio = true;
/* fall through */
case TRANS_DDI_MODE_SELECT_DVI:
+ pipe_config->output_types |= BIT(INTEL_OUTPUT_HDMI);
pipe_config->lane_count = 4;
break;
case TRANS_DDI_MODE_SELECT_FDI:
+ pipe_config->output_types |= BIT(INTEL_OUTPUT_ANALOG);
break;
case TRANS_DDI_MODE_SELECT_DP_SST:
+ if (encoder->type == INTEL_OUTPUT_EDP)
+ pipe_config->output_types |= BIT(INTEL_OUTPUT_EDP);
+ else
+ pipe_config->output_types |= BIT(INTEL_OUTPUT_DP);
+ pipe_config->lane_count =
+ ((temp & DDI_PORT_WIDTH_MASK
Re: [Intel-gfx] [PATCH 24/31] drm/i915/slpc: Add debugfs support to read/write/revert the parameters
On Tue, 19 Sep 2017 19:42:00 +0200, Sagar Arun Kamble
wrote:
This patch adds two debugfs interfaces:
1. i915_slpc_paramlist: List of all parameters that Host can configure.
Currently listing id and description of each.
2. i915_slpc_param_ctl: This allows to change the parameters. Syntax is:
echo "write " > i915_slpc_param_ctl.
echo "read " > i915_slpc_param_ctl; cat i915_slpc_param_ctl
revert allows to set to default SLPC internal values. Syntax is:
echo "revert " > i915_slpc_param_ctl.
Added support to set/read parameters and unset the parameters which will
revert them to default SLPC internal values. Also added RPM ref. cover
around set/unset calls. Explicit SLPC reset is needed on
setting/unsetting
some of the parameters.
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_debugfs.c | 19 +
drivers/gpu/drm/i915/intel_slpc.c | 158
drivers/gpu/drm/i915/intel_slpc.h | 6 ++
3 files changed, 183 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index dbfe185..0a04f3d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2352,6 +2352,23 @@ static int i915_huc_load_status_info(struct
seq_file *m, void *data)
return 0;
}
+static int i915_slpc_paramlist_info(struct seq_file *m, void *data)
I'm little confused that part of the debugfs functionality is done here
while other part in slpc.c
+{
+ struct drm_i915_private *dev_priv = node_to_i915(m->private);
+ int i;
+
+ if (!dev_priv->guc.slpc.active) {
intel_slpc_active() ?
+ seq_puts(m, "SLPC not active\n");
+ return 0;
+ }
+
+ seq_puts(m, "Param id\tParam description\n");
+ for (i = 0; i < SLPC_MAX_PARAM; i++)
+ seq_printf(m, "%8d\t%s\n", slpc_paramlist[i].id,
+ slpc_paramlist[i].description);
What if size of slpc_paramlist[] will be smaller than i ?
+ return 0;
+}
+
static int i915_guc_load_status_info(struct seq_file *m, void *data)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -4881,6 +4898,7 @@ static int i915_hpd_storm_ctl_open(struct inode
*inode, struct file *file)
{"i915_guc_load_err_log_dump", i915_guc_log_dump, 0, (void *)1},
{"i915_guc_stage_pool", i915_guc_stage_pool, 0},
{"i915_huc_load_status", i915_huc_load_status_info, 0},
+ {"i915_slpc_paramlist", i915_slpc_paramlist_info, 0},
{"i915_frequency_info", i915_frequency_info, 0},
{"i915_hangcheck_info", i915_hangcheck_info, 0},
{"i915_reset_info", i915_reset_info, 0},
@@ -4944,6 +4962,7 @@ static int i915_hpd_storm_ctl_open(struct inode
*inode, struct file *file)
{"i915_dp_test_type", &i915_displayport_test_type_fops},
{"i915_dp_test_active", &i915_displayport_test_active_fops},
{"i915_guc_log_control", &i915_guc_log_control_fops},
+ {"i915_slpc_param_ctl", &i915_slpc_param_ctl_fops},
{"i915_hpd_storm_ctl", &i915_hpd_storm_ctl_fops},
{"i915_ipc_status", &i915_ipc_status_fops}
};
diff --git a/drivers/gpu/drm/i915/intel_slpc.c
b/drivers/gpu/drm/i915/intel_slpc.c
index d0fd402..0c094f0 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -25,6 +25,8 @@
#include
#include "i915_drv.h"
#include "intel_uc.h"
+#include
+#include
struct slpc_param slpc_paramlist[SLPC_MAX_PARAM] = {
{SLPC_PARAM_TASK_ENABLE_GTPERF, "Enable task GTPERF"},
@@ -684,3 +686,159 @@ void intel_slpc_disable(struct intel_slpc *slpc)
slpc->active = false;
}
+
+static int slpc_param_ctl_show(struct seq_file *m, void *data)
+{
+ struct drm_i915_private *dev_priv = m->private;
+ struct intel_slpc *slpc = &dev_priv->guc.slpc;
+
+ if (!slpc->active) {
intel_slpc_active() ?
+ seq_puts(m, "SLPC not active\n");
+ return 0;
+ }
+
+ seq_printf(m, "%s=%u, override=%s\n",
+ slpc_paramlist[slpc->debug_param_id].description,
+ slpc->debug_param_value,
+ yesno(!!slpc->debug_param_override));
+
What if slpc->debug_param_id >= SLPC_MAX_PARAM or sizeof paramlist ?
+ return 0;
+}
+
+static int slpc_param_ctl_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, slpc_param_ctl_show, inode->i_private);
+}
+
+static const char *read_token = "read", *write_token = "write",
+ *revert_token = "revert";
+
+/*
+ * Parse SLPC parameter control strings: (Similar to Pipe CRC handling)
+ * command: wsp* op wsp+ param id wsp+ [value] wsp*
+ * op: "read"/"write"/"revert"
+ * param id: slpc_param_id
+ * value: u32 value
+ * wsp: (#0x20 | #0x9 | #0xA)+
+ *
+ * eg.:
+ * "read 0" -> read SLPC_PARAM_TASK_ENABLE_GTPERF
+ * "write 7 500" -> set SLPC_PAR
Re: [Intel-gfx] [PATCH 1/2] drm/i915/lrc: Only enable per-context and per-bb buffers if set
On 21/09/2017 14:54, Chris Wilson wrote:
The per-context and per-batch workaround buffers are optional, yet we
tell the GPU to execute them even if they contain no instructions. Doing
so incurs the dispatch latency, which we can avoid if we don't ask the
GPU to execute the no-op buffers. Allow ourselves to skip setup of empty
buffer, and then to only enable non-empty buffers in the context image.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 86fed9f1f1ae..297c9c1564e5 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1265,7 +1265,8 @@ static int intel_init_workaround_bb(struct
intel_engine_cs *engine)
ret = -EINVAL;
break;
}
- batch_ptr = wa_bb_fn[i](engine, batch_ptr);
+ if (wa_bb_fn[i])
+ batch_ptr = wa_bb_fn[i](engine, batch_ptr);
wa_bb[i]->size = batch_ptr - (batch + wa_bb[i]->offset);
}
@@ -1994,13 +1995,12 @@ static void execlists_init_reg_state(u32 *regs,
CTX_REG(regs, CTX_SECOND_BB_HEAD_L, RING_SBBADDR(base), 0);
CTX_REG(regs, CTX_SECOND_BB_STATE, RING_SBBSTATE(base), 0);
if (rcs) {
- CTX_REG(regs, CTX_BB_PER_CTX_PTR, RING_BB_PER_CTX_PTR(base), 0);
+ struct i915_ctx_workarounds *wa_ctx = &engine->wa_ctx;
+
CTX_REG(regs, CTX_RCS_INDIRECT_CTX, RING_INDIRECT_CTX(base), 0);
CTX_REG(regs, CTX_RCS_INDIRECT_CTX_OFFSET,
RING_INDIRECT_CTX_OFFSET(base), 0);
-
- if (engine->wa_ctx.vma) {
- struct i915_ctx_workarounds *wa_ctx = &engine->wa_ctx;
+ if (wa_ctx->indirect_ctx.size) {
u32 ggtt_offset = i915_ggtt_offset(wa_ctx->vma);
regs[CTX_RCS_INDIRECT_CTX + 1] =
@@ -2009,6 +2009,11 @@ static void execlists_init_reg_state(u32 *regs,
regs[CTX_RCS_INDIRECT_CTX_OFFSET + 1] =
intel_lr_indirect_ctx_offset(engine) << 6;
+ }
+
+ CTX_REG(regs, CTX_BB_PER_CTX_PTR, RING_BB_PER_CTX_PTR(base), 0);
+ if (wa_ctx->per_ctx.size) {
+ u32 ggtt_offset = i915_ggtt_offset(wa_ctx->vma);
regs[CTX_BB_PER_CTX_PTR + 1] =
(ggtt_offset + wa_ctx->per_ctx.offset) | 0x01;
Looks OK. Does it make sense to fetch the ggtt offset only once ("if
(size || size) ggtt_offset = ...")? Meh.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/lrc: Skip no-op per-bb buffer on gen9
On 21/09/2017 14:54, Chris Wilson wrote:
Since we inherited the context image setup from gen8 which needed a
per-bb workaround (for GPGPU), we are submitting an empty per-bb buffer
on gen9. Now that we can skip adding the buffer to the context image,
remove the dangling per-bb. This slightly improves execution latency,
most notably on an idle engine.
References: https://bugs.freedesktop.org/show_bug.cgi?id=87725
How much of the 7% we get back? :)
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 297c9c1564e5..91a5411bb9da 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1171,13 +1171,6 @@ static u32 *gen9_init_indirectctx_bb(struct
intel_engine_cs *engine, u32 *batch)
return batch;
}
-static u32 *gen9_init_perctx_bb(struct intel_engine_cs *engine, u32 *batch)
-{
- *batch++ = MI_BATCH_BUFFER_END;
-
- return batch;
-}
-
#define CTX_WA_BB_OBJ_SIZE (PAGE_SIZE)
static int lrc_setup_wa_ctx(struct intel_engine_cs *engine)
@@ -1234,7 +1227,7 @@ static int intel_init_workaround_bb(struct
intel_engine_cs *engine)
return 0;
case 9:
wa_bb_fn[0] = gen9_init_indirectctx_bb;
- wa_bb_fn[1] = gen9_init_perctx_bb;
+ wa_bb_fn[1] = NULL;
break;
case 8:
wa_bb_fn[0] = gen8_init_indirectctx_bb;
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 26/31] drm/i915/slpc: Add i915_slpc_info to debugfs
On Tue, 19 Sep 2017 19:42:02 +0200, Sagar Arun Kamble
wrote:
From: Tom O'Rourke
i915_slpc_info shows the contents of SLPC shared data
parsed into text format.
v1: Reformat slpc info (Radek)
squashed query task state info
in slpc info, kunmap before seq_print (Paulo)
return void instead of ignored return value (Paulo)
Avoid magic numbers and use local variables (Jon Bloomfield)
Removed WARN_ON for checking msb of gtt address of
shared gem obj. (ChrisW)
Moved definition of power plan and power source to earlier
patch in the series.
drm/i915/slpc: Allocate/Release/Initialize SLPC shared data
(Akash)
v2-v3: Rebase.
v4: Updated with GuC firmware v9.
v5: Updated host2guc_slpc_query_task_state with struct slpc_input_event
structure. Removed unnecessary checks of vma from i915_slpc_info.
Created helpers for reading the SLPC shared data and string form of
SLPC state. (Sagar)
Signed-off-by: Tom O'Rourke
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_debugfs.c | 165
1 file changed, 165 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e6fd63f..7a0838f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1023,6 +1023,170 @@ static int i915_error_state_open(struct inode
*inode, struct file *file)
NULL, i915_next_seqno_set,
"0x%llx\n");
+static int i915_slpc_info(struct seq_file *m, void *unused)
+{
+ struct drm_i915_private *dev_priv = node_to_i915(m->private);
+ int i, value;
+ struct slpc_shared_data data;
+ enum slpc_global_state global_state;
+ enum slpc_platform_sku platform_sku;
+ struct slpc_task_state_data *task_data;
+ enum slpc_power_plan power_plan;
+ enum slpc_power_source power_source;
+
+ if (!dev_priv->guc.slpc.active)
+ return -ENODEV;
+
+ intel_runtime_pm_get(dev_priv);
+ mutex_lock(&dev_priv->pm.pcu_lock);
+
+ intel_slpc_read_shared_data(&dev_priv->guc.slpc, &data);
+
+ mutex_unlock(&dev_priv->pm.pcu_lock);
+ intel_runtime_pm_put(dev_priv);
+
+ seq_printf(m, "shared data size: %d\n", data.shared_data_size);
+
+ global_state = (enum slpc_global_state) data.global_state;
+ seq_printf(m, "global state: %d (", global_state);
+ seq_printf(m, "%s)\n", intel_slpc_get_state_str(global_state));
+
+ platform_sku = (enum slpc_platform_sku)
+ data.platform_info.platform_sku;
+ seq_printf(m, "sku: %d (", platform_sku);
+ switch (platform_sku) {
+ case SLPC_PLATFORM_SKU_UNDEFINED:
+ seq_puts(m, "undefined)\n");
+ break;
+ case SLPC_PLATFORM_SKU_ULX:
+ seq_puts(m, "ULX)\n");
+ break;
+ case SLPC_PLATFORM_SKU_ULT:
+ seq_puts(m, "ULT)\n");
+ break;
+ case SLPC_PLATFORM_SKU_T:
+ seq_puts(m, "T)\n");
+ break;
+ case SLPC_PLATFORM_SKU_MOBL:
+ seq_puts(m, "Mobile)\n");
+ break;
+ case SLPC_PLATFORM_SKU_DT:
+ seq_puts(m, "DT)\n");
+ break;
+ case SLPC_PLATFORM_SKU_UNKNOWN:
+ default:
+ seq_puts(m, "unknown)\n");
+ break;
+ }
Define platform_to_string() followed by single seq_puts()
+ seq_printf(m, "slice count: %d\n",
+ data.platform_info.slice_count);
+
+ seq_printf(m, "power plan/source: 0x%x\n\tplan:\t",
+ data.platform_info.power_plan_source);
+ power_plan = (enum slpc_power_plan) SLPC_POWER_PLAN(
+ data.platform_info.power_plan_source);
+ power_source = (enum slpc_power_source) SLPC_POWER_SOURCE(
+ data.platform_info.power_plan_source);
+ switch (power_plan) {
+ case SLPC_POWER_PLAN_UNDEFINED:
+ seq_puts(m, "undefined");
+ break;
+ case SLPC_POWER_PLAN_BATTERY_SAVER:
+ seq_puts(m, "battery saver");
+ break;
+ case SLPC_POWER_PLAN_BALANCED:
+ seq_puts(m, "balanced");
+ break;
+ case SLPC_POWER_PLAN_PERFORMANCE:
+ seq_puts(m, "performance");
+ break;
+ case SLPC_POWER_PLAN_UNKNOWN:
+ default:
+ seq_puts(m, "unknown");
+ break;
+ }
Define power_plan_to_string() followed by single seq_puts()
+ seq_puts(m, "\n\tsource:\t");
+ switch (power_source) {
+ case SLPC_POWER_SOURCE_UNDEFINED:
+ seq_puts(m, "undefined\n");
+ break;
+ case SLPC_POWER_SOURCE_AC:
+ seq_puts(m, "AC\n");
+ break;
+ case SLPC_POWER_SOURCE_DC:
+ seq_puts(m, "DC\n");
+
Re: [Intel-gfx] [PATCH 01/31] drm/i915/debugfs: Create generic string tokenize function and update CRC control parsing
On Tue, 19 Sep 2017 19:41:37 +0200, Sagar Arun Kamble
wrote:
Input string parsing used in CRC control parameter parsing is generic
and can be reused for other debugfs interfaces. Hence name it as
buffer_tokenize instead of tieing to display_crc. Also fix the function
desciption for CRC control parsing that was misplaced at tokenize
function.
Cc: Tomeu Vizoso
Signed-off-by: Sagar Arun Kamble
Acked-by: Radoslaw Szwichtenberg
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_pipe_crc.c | 88
+--
2 files changed, 45 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 6d7d871..4d5ffde 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3847,6 +3847,7 @@ u32 i915_gem_fence_alignment(struct
drm_i915_private *dev_priv, u32 size,
int i915_debugfs_register(struct drm_i915_private *dev_priv);
int i915_debugfs_connector_add(struct drm_connector *connector);
void intel_display_crc_init(struct drm_i915_private *dev_priv);
+int buffer_tokenize(char *buf, char *words[], int max_words);
#else
static inline int i915_debugfs_register(struct drm_i915_private
*dev_priv) {return 0;}
static inline int i915_debugfs_connector_add(struct drm_connector
*connector)
diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
b/drivers/gpu/drm/i915/intel_pipe_crc.c
index 96043a5..2e312b8 100644
--- a/drivers/gpu/drm/i915/intel_pipe_crc.c
+++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
@@ -710,49 +710,6 @@ static int pipe_crc_set_source(struct
drm_i915_private *dev_priv,
return ret;
}
-/*
- * Parse pipe CRC command strings:
- * command: wsp* object wsp+ name wsp+ source wsp*
- * object: 'pipe'
- * name: (A | B | C)
- * source: (none | plane1 | plane2 | pf)
- * wsp: (#0x20 | #0x9 | #0xA)+
- *
- * eg.:
- * "pipe A plane1" -> Start CRC computations on plane1 of pipe A
- * "pipe A none"-> Stop CRC
- */
-static int display_crc_ctl_tokenize(char *buf, char *words[], int
max_words)
-{
- int n_words = 0;
-
- while (*buf) {
- char *end;
-
- /* skip leading white space */
- buf = skip_spaces(buf);
- if (!*buf)
- break; /* end of buffer */
-
- /* find end of word */
- for (end = buf; *end && !isspace(*end); end++)
- ;
-
- if (n_words == max_words) {
- DRM_DEBUG_DRIVER("too many words, allowed <= %d\n",
-max_words);
- return -EINVAL; /* ran out of words[] before bytes */
- }
-
- if (*end)
- *end++ = '\0';
- words[n_words++] = buf;
- buf = end;
- }
-
- return n_words;
-}
-
enum intel_pipe_crc_object {
PIPE_CRC_OBJECT_PIPE,
};
@@ -806,6 +763,49 @@ static int display_crc_ctl_parse_pipe(const char
*buf, enum pipe *pipe)
return -EINVAL;
}
+int buffer_tokenize(char *buf, char *words[], int max_words)
+{
+ int n_words = 0;
+
+ while (*buf) {
+ char *end;
+
+ /* skip leading white space */
+ buf = skip_spaces(buf);
+ if (!*buf)
+ break; /* end of buffer */
+
+ /* find end of word */
+ for (end = buf; *end && !isspace(*end); end++)
+ ;
+
+ if (n_words == max_words) {
+ DRM_DEBUG_DRIVER("too many words, allowed <= %d\n",
+max_words);
+ return -EINVAL; /* ran out of words[] before bytes */
+ }
+
+ if (*end)
+ *end++ = '\0';
+ words[n_words++] = buf;
+ buf = end;
+ }
+
+ return n_words;
+}
You should move this function to i915_debugfs.c
+
+/*
+ * Parse pipe CRC command strings:
+ * command: wsp* object wsp+ name wsp+ source wsp*
+ * object: 'pipe'
+ * name: (A | B | C)
+ * source: (none | plane1 | plane2 | pf)
+ * wsp: (#0x20 | #0x9 | #0xA)+
+ *
+ * eg.:
+ * "pipe A plane1" -> Start CRC computations on plane1 of pipe A
+ * "pipe A none"-> Stop CRC
+ */
static int display_crc_ctl_parse(struct drm_i915_private *dev_priv,
char *buf, size_t len)
{
@@ -816,7 +816,7 @@ static int display_crc_ctl_parse(struct
drm_i915_private *dev_priv,
enum intel_pipe_crc_object object;
enum intel_pipe_crc_source source;
- n_words = display_crc_ctl_tokenize(buf, words, N_WORDS);
+ n_words = buffer_tokenize(buf, words, N_WORDS);
if (n_words != N_WORDS) {
DRM_DEBUG_DRIVER("tokenize failed, a command is %d words\n",
N_WORDS);
_
Re: [Intel-gfx] [PATCH 1/8] drm/i915: Make own struct for execlist items
On Wed, 2017-09-20 at 17:36 +0300, Mika Kuoppala wrote: > Engine's execlist related items have been increasing to > a point where a separate struct is warranted. Carve execlist > specific items to a dedicated struct to add clarity. > > v2: add kerneldoc and fix whitespace (Joonas, Chris) > v3: csb_mmio changes, rebase > > Suggested-by: Chris Wilson > Cc: Chris Wilson > Cc: Joonas Lahtinen > Signed-off-by: Mika Kuoppala > Acked-by: Joonas Lahtinen With s/\b(el|execlist)\b/execlists/ this is; Reviewed-by: Joonas Lahtinen Please rebase and merge, it's going to cause rebases anyway, so now is the best time after yesterday. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ 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/bios: ignore HDMI on port A (rev2)
== Series Details == Series: drm/i915/bios: ignore HDMI on port A (rev2) URL : https://patchwork.freedesktop.org/series/30700/ State : success == Summary == Series 30700v2 drm/i915/bios: ignore HDMI on port A https://patchwork.freedesktop.org/api/1.0/series/30700/revisions/2/mbox/ fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:446s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:465s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:416s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:513s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:278s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:509s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:487s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:499s fi-cfl-s total:289 pass:223 dwarn:34 dfail:0 fail:0 skip:32 time:537s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:418s fi-glk-1 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:566s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:424s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:404s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:435s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:480s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:467s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:471s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:582s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:589s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:539s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:450s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:756s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:487s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:470s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:568s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:1 skip:39 time:411s 01a2040bb790263c0d32ec30d83bd2ddf3b922c2 drm-tip: 2017y-09m-21d-13h-23m-06s UTC integration manifest 16bee02cf2bc drm/i915/bios: ignore HDMI on port A == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5781/ ___ 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: Eliminate DDI encoder->type frobbery redux (rev4)
== Series Details ==
Series: drm/i915: Eliminate DDI encoder->type frobbery redux (rev4)
URL : https://patchwork.freedesktop.org/series/30548/
State : success
== Summary ==
Series 30548v4 drm/i915: Eliminate DDI encoder->type frobbery redux
https://patchwork.freedesktop.org/api/1.0/series/30548/revisions/4/mbox/
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
fail -> PASS (fi-snb-2600) fdo#100215
Test drv_module_reload:
Subgroup basic-reload:
pass -> DMESG-WARN (fi-glk-1) fdo#102777
fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215
fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777
fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21
time:442s
fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24
time:468s
fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64
time:419s
fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46
time:514s
fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105
time:279s
fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29
time:495s
fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34
time:494s
fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38
time:490s
fi-cfl-s total:289 pass:223 dwarn:34 dfail:0 fail:0 skip:32
time:545s
fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59
time:419s
fi-glk-1 total:289 pass:259 dwarn:1 dfail:0 fail:0 skip:29
time:564s
fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26
time:423s
fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26
time:401s
fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60
time:432s
fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28
time:487s
fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28
time:462s
fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24
time:471s
fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19
time:579s
fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27
time:584s
fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65
time:542s
fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20
time:452s
fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24
time:759s
fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20
time:490s
fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23
time:476s
fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38
time:570s
fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39
time:416s
01a2040bb790263c0d32ec30d83bd2ddf3b922c2 drm-tip: 2017y-09m-21d-13h-23m-06s UTC
integration manifest
0d436ce0607c drm/i915: Pass a crtc state to ddi post_disable from MST code
06ee9d5e1968 drm/i915: Replace most intel_ddi_get_encoder_port() alls with
encoder->port
35f95362bef7 drm/i915: Clear up the types we use for DDI buf trans
level/n_entries
75d4c084aa69 drm/i915: Unify error handling for missing DDI buf trans tables
b740892f7d5f drm/i915: Stop frobbing with DDI encoder->type
b8b0743053f6 drm/i915: Centralize the SKL DDI A/E vs. B/C/D buf trans handling
c9ecfc1b6dae drm/i915: Stop using encoder->type in
intel_ddi_enable_transcoder_func()
9df2b07256dc drm/i915: Start using output_types for DPLL selection
c395dd510660 drm/i915: Pass crtc state to intel_prepare_dp_ddi_buffers()
67099547f5c4 drm/i915: Don't use encoder->type in intel_ddi_set_pipe_settings()
934c4f1c46db drm/i915: Kill off the BXT buf_trans default_index
b4c12f00b0ab drm/i915: Pass encoder type to cnl_ddi_vswing_sequence() explicitly
9265fe78bec2 drm/i915: Integrate BXT into intel_ddi_dp_voltage_max()
bae07ed9119f drm/i915: Pass the level to intel_prepare_hdmi_ddi_buffers()
5e1400daa0af drm/i915: Pass the encoder type explicitly to skl_set_iboost()
2d0d93dba6ac drm/i915: Extract intel_ddi_get_buf_trans_hdmi()
bc6bf91f6815 drm/i915: Relocate intel_ddi_get_buf_trans_*() functions
5da01d6a42c6 drm/i915: Split intel_enable_ddi() into DP and HDMI variants
17f0fa8b4714 drm/i915: Plump crtc_state etc. directly to
intel_ddi_pre_enable_{dp, hdmi}()
3fc8810273fc drm/i915: Split intel_disable_ddi() into DP vs. HDMI variants
578f4af09991 drm/i915: Remove useless eDP check from intel_ddi_pre_enable_dp()
e43133e54173 drm/i915: Split intel_ddi_post_disable() into DP vs. HDMI variants
66dc29cdd552 drm/i915: Inline the required bits of intel_ddi_post_disable()
into intel_ddi_fdi_post_disable()
6bca6d71144f drm/i915: Extract intel_disable_ddi_buf()
a0cc3a170cf3 drm/i915: Extract intel_ddi_clk_disable()
f5f173ad95f3 drm/i915: Dump 'outpu
Re: [Intel-gfx] [PATCH 2/2] drm/i915/lrc: Skip no-op per-bb buffer on gen9
Quoting Tvrtko Ursulin (2017-09-21 16:12:21) > > On 21/09/2017 14:54, Chris Wilson wrote: > > Since we inherited the context image setup from gen8 which needed a > > per-bb workaround (for GPGPU), we are submitting an empty per-bb buffer > > on gen9. Now that we can skip adding the buffer to the context image, > > remove the dangling per-bb. This slightly improves execution latency, > > most notably on an idle engine. > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=87725 > > How much of the 7% we get back? :) Not enough. The difference in execution latency between ringbuffer submission and execlists for this type of workload is roughly an order of magnitude (~5us to ~30us, using gem_sync as a reasonable proxy). The per-bb accounts for around 6us of that on bdw, so a big chunk but still a few times slower. Not that we do move the GPGPU workaround on bdw just yet, I left that for when we do play with preemption and MI_ARB_ON_OFF. (Side note, the remaining difference between ringbuffer and execlists seems to be related to MI arbitration...) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v6,1/3] drm/i915: Rename global i915 to i915_modparams
== Series Details == Series: series starting with [v6,1/3] drm/i915: Rename global i915 to i915_modparams URL : https://patchwork.freedesktop.org/series/30621/ State : failure == Summary == Test perf: Subgroup polling: fail -> PASS (shard-hsw) fdo#102252 +1 Test prime_busy: Subgroup wait-before-render: pass -> FAIL (shard-hsw) Test drv_module_reload: Subgroup basic-no-display: dmesg-warn -> PASS (shard-hsw) fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-hswtotal:2429 pass:1332 dwarn:3 dfail:0 fail:11 skip:1083 time:9756s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5779/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] tools_test: Clean up and fix sysfs_l3_parity
== Series Details == Series: series starting with [1/2] tools_test: Clean up and fix sysfs_l3_parity URL : https://patchwork.freedesktop.org/series/30699/ State : success == Summary == IGT patchset tested on top of latest successful build f86dc17cfc81f53f3bf216009ffda1ac05208bcc igt/prime_vgem: Split out the fine-grain coherency check with latest DRM-Tip kernel build CI_DRM_3118 01a2040bb790 drm-tip: 2017y-09m-21d-13h-23m-06s UTC integration manifest Test gem_exec_suspend: Subgroup basic-s3: pass -> INCOMPLETE (fi-kbl-7500u) fdo#102850 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 +1 Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b: dmesg-warn -> INCOMPLETE (fi-cfl-s) fdo#102294 Test drv_module_reload: Subgroup basic-reload: pass -> DMESG-WARN (fi-glk-1) fdo#102777 fdo#102850 https://bugs.freedesktop.org/show_bug.cgi?id=102850 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294 fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:441s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:477s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:420s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:518s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:277s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:514s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:499s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:503s fi-cfl-s total:241 pass:188 dwarn:24 dfail:0 fail:0 skip:28 fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:427s fi-glk-1 total:289 pass:259 dwarn:1 dfail:0 fail:0 skip:29 time:569s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:427s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:411s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:439s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:496s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:469s fi-kbl-7500u total:118 pass:100 dwarn:1 dfail:0 fail:0 skip:16 fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:575s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:592s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:546s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:451s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:756s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:494s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:474s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:581s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:1 skip:39 time:421s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_237/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH][drm-next] drm/i915/gvt: ensure -ve return value is handled correctly
Hi Joonas:
Thanks for the introduction. I have been thinking about the possibility of
introducing GEM_BUG_ON into GVT-g recently and investigating on it. I'm just a
bit confused about the usage between GEM_BUG_ON and WARN_ON.
GEM_BUG_ON is only enabled when kernel debug is enabled, which mostly is
disabled in a production kernel. In the case of i915, I'm sure it will be
enabled in CI test so that it can catch broken code path. Looking into GVT-g,
the similar scenario is we enable it in QA test.
Let's say GEM_BUG_ON can do its work very well in QA test but QA test is not
fully covered all the condition, then something might be still broken when it
comes to the production kernel for user and GEM_BUG_ON will be disabled and
will not catch that, I guess.
That's my confusion which scratched my mind during the investigation: If
GEM_BUG_ON is not always working, then it looks WARN_ON should always be
used Expected to learn more about the story behind. :)
Thanks,
Zhi.
-Original Message-
From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
Behalf Of Joonas Lahtinen
Sent: Thursday, September 21, 2017 5:32 PM
To: Zhenyu Wang ; Joe Perches
Cc: Gao, Fred ; David Airlie ;
intel-gfx@lists.freedesktop.org; kernel-janit...@vger.kernel.org;
linux-ker...@vger.kernel.org; Jani Nikula ;
dri-de...@lists.freedesktop.org; Vivi, Rodrigo ; Colin
King ; intel-gvt-...@lists.freedesktop.org; Wang, Zhi
A
Subject: Re: [PATCH][drm-next] drm/i915/gvt: ensure -ve return value is handled
correctly
On Thu, 2017-09-21 at 06:44 +0800, Zhenyu Wang wrote:
> On 2017.09.19 19:35:23 -0700, Joe Perches wrote:
> > On Wed, 2017-09-20 at 05:46 +0800, Zhenyu Wang wrote:
> > > On 2017.09.19 16:55:34 +0100, Colin King wrote:
> > > > From: Colin Ian King
> > > >
> > > > An earlier fix changed the return type from find_bb_size however
> > > > the integer return is being assigned to a unsigned int so the
> > > > -ve error check will never be detected. Make bb_size an int to fix this.
> > > >
> > > > Detected by CoverityScan CID#1456886 ("Unsigned compared against
> > > > 0")
> > > >
> > > > Fixes: 1e3197d6ad73 ("drm/i915/gvt: Refine error handling for
> > > > perform_bb_shadow")
> > > > Signed-off-by: Colin Ian King
> > > > ---
> > > > drivers/gpu/drm/i915/gvt/cmd_parser.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> > > > b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> > > > index 2c0ccbb817dc..f41cbf664b69 100644
> > > > --- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> > > > +++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> > > > @@ -1628,7 +1628,7 @@ static int perform_bb_shadow(struct
> > > > parser_exec_state *s)
> > > > struct intel_shadow_bb_entry *entry_obj;
> > > > struct intel_vgpu *vgpu = s->vgpu;
> > > > unsigned long gma = 0;
> > > > - uint32_t bb_size;
> > > > + int bb_size;
> > > > void *dst = NULL;
> > > > int ret = 0;
> > > >
> > >
> > > Applied this, thanks!
> >
> > Is it possible for bb_size to be both >= 2g and valid?
>
> Never be possible in practise and if really that big I think something
> is already insane indeed.
It's good idea to document these assumptions as WARN_ON's. In i915, if the
value is completely internal to kernel, we're using GEM_BUG_ON for these so
that our CI will notice breakage. If it's not a driver internal value only, a
WARN_ON is the appropriate action.
Otherwise the information is lost and the next person reading the code will
have the same question in mind.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
intel-gvt-dev mailing list
intel-gvt-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/6] lib/igt_kms: Don't assert on non-existent plane
== Series Details == Series: series starting with [1/6] lib/igt_kms: Don't assert on non-existent plane URL : https://patchwork.freedesktop.org/series/30706/ State : warning == Summary == IGT patchset tested on top of latest successful build f86dc17cfc81f53f3bf216009ffda1ac05208bcc igt/prime_vgem: Split out the fine-grain coherency check with latest DRM-Tip kernel build CI_DRM_3118 01a2040bb790 drm-tip: 2017y-09m-21d-13h-23m-06s UTC integration manifest Test chamelium: Subgroup hdmi-crc-fast: pass -> DMESG-WARN (fi-skl-6700k) Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 +1 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:442s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:478s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:417s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:527s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:276s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:504s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:497s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:501s fi-cfl-s total:289 pass:223 dwarn:34 dfail:0 fail:0 skip:32 time:591s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:424s fi-glk-1 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:569s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:429s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:414s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:438s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:485s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:466s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:470s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:577s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:600s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:544s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:454s fi-skl-6700k total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:755s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:496s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:474s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:578s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:1 skip:39 time:419s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_238/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Document the split in internal and public execbuf flags
Quoting Patchwork (2017-09-21 13:57:48) > == Series Details == > > Series: drm/i915: Document the split in internal and public execbuf flags > URL : https://patchwork.freedesktop.org/series/30696/ > State : warning > > == Summary == > > Series 30696v1 drm/i915: Document the split in internal and public execbuf > flags > https://patchwork.freedesktop.org/api/1.0/series/30696/revisions/1/mbox/ > > Test gem_exec_reloc: > Subgroup basic-gtt-noreloc: > pass -> DMESG-WARN (fi-kbl-7500u) > Test gem_exec_suspend: > Subgroup basic-s3: > pass -> INCOMPLETE (fi-kbl-7500u) fdo#102850 > Test gem_ringfill: > Subgroup basic-default-hang: > pass -> DMESG-WARN (fi-pnv-d510) fdo#101600 > Test kms_cursor_legacy: > Subgroup basic-busy-flip-before-cursor-legacy: > fail -> PASS (fi-snb-2600) fdo#100215 Pushed since it was a compile-time only change and the warn here is something fishy going on since rc1. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/lrc: Only enable per-context and per-bb buffers if set
== Series Details == Series: series starting with [1/2] drm/i915/lrc: Only enable per-context and per-bb buffers if set URL : https://patchwork.freedesktop.org/series/30701/ State : failure == Summary == Test gem_exec_schedule: Subgroup wide-blt: skip -> INCOMPLETE (shard-hsw) Test kms_setmode: Subgroup basic: pass -> FAIL (shard-hsw) fdo#99912 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 shard-hswtotal:2429 pass:1306 dwarn:4 dfail:0 fail:11 skip:1060 time:9689s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5780/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/9] drm/i915/guc: Update prototype/name of GuC suspend/resume fns and move to intel_uc.c
On 9/21/2017 2:55 AM, Michal Wajdeczko wrote:
On Wed, 20 Sep 2017 19:38:17 +0200, Sagar Arun Kamble
wrote:
Renamed intel_guc_suspend to intel_guc_enter_sleep and intel_guc_resume
to intel_guc_exit_sleep to match GuC nomenclature compatibility.
We plan to use intel_guc_suspend and intel_guc_resume through
intel_uc_suspend and intel_uc_resume in the path i915_drm_suspend and
i915_drm_resume respectively for better naming.
Also, with this patch we pass intel_guc struct as parameter to
enter_sleep
and exit_sleep functions as they are GuC specific and they are moved to
intel_uc.c as static functions called from uc generic functions.
I'm not sure that we need this semi-refactoring right now.
We can return to this later and do it right at once.
Michal
Ok. Will return to this later. Dropping in next series.
v2: Rebase w.r.t removal of GuC code restructuring.
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_guc_submission.c | 52
---
drivers/gpu/drm/i915/intel_uc.c | 58
--
drivers/gpu/drm/i915/intel_uc.h | 2 --
3 files changed, 55 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index e191d56..94efe32 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1205,55 +1205,3 @@ void i915_guc_submission_disable(struct
drm_i915_private *dev_priv)
guc_client_free(guc->execbuf_client);
guc->execbuf_client = NULL;
}
-
-/**
- * intel_guc_suspend() - notify GuC entering suspend state
- * @dev_priv: i915 device private
- */
-int intel_guc_suspend(struct drm_i915_private *dev_priv)
-{
- struct intel_guc *guc = &dev_priv->guc;
- struct i915_gem_context *ctx;
- u32 data[3];
-
- if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
- return 0;
-
- gen9_disable_guc_interrupts(dev_priv);
-
- ctx = dev_priv->kernel_context;
-
- data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
- /* any value greater than GUC_POWER_D0 */
- data[1] = GUC_POWER_D1;
- /* first page is shared data with GuC */
- data[2] = guc_ggtt_offset(ctx->engine[RCS].state) +
LRC_GUCSHR_PN * PAGE_SIZE;
-
- return intel_guc_send(guc, data, ARRAY_SIZE(data));
-}
-
-/**
- * intel_guc_resume() - notify GuC resuming from suspend state
- * @dev_priv: i915 device private
- */
-int intel_guc_resume(struct drm_i915_private *dev_priv)
-{
- struct intel_guc *guc = &dev_priv->guc;
- struct i915_gem_context *ctx;
- u32 data[3];
-
- if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
- return 0;
-
- if (i915.guc_log_level >= 0)
- gen9_enable_guc_interrupts(dev_priv);
-
- ctx = dev_priv->kernel_context;
-
- data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
- data[1] = GUC_POWER_D0;
- /* first page is shared data with GuC */
- data[2] = guc_ggtt_offset(ctx->engine[RCS].state) +
LRC_GUCSHR_PN * PAGE_SIZE;
-
- return intel_guc_send(guc, data, ARRAY_SIZE(data));
-}
diff --git a/drivers/gpu/drm/i915/intel_uc.c
b/drivers/gpu/drm/i915/intel_uc.c
index 8e4d8b0..0dbb4b9 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -538,19 +538,71 @@ int intel_guc_sample_forcewake(struct intel_guc
*guc)
return intel_guc_send(guc, action, ARRAY_SIZE(action));
}
+/**
+ * intel_guc_enter_sleep() - notify GuC entering sleep state
+ * @guc: guc structure
+ */
+static int intel_guc_enter_sleep(struct intel_guc *guc)
+{
+ struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ struct i915_gem_context *ctx;
+ u32 data[3];
+
+ if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
+ return 0;
+
+ gen9_disable_guc_interrupts(dev_priv);
+
+ ctx = dev_priv->kernel_context;
+
+ data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
+ /* any value greater than GUC_POWER_D0 */
+ data[1] = GUC_POWER_D1;
+ /* first page is shared data with GuC */
+ data[2] = guc_ggtt_offset(ctx->engine[RCS].state) +
LRC_GUCSHR_PN * PAGE_SIZE;
+
+ return intel_guc_send(guc, data, ARRAY_SIZE(data));
+}
+
+/**
+ * intel_guc_exit_sleep() - notify GuC exit from sleep state
+ * @guc: guc structure
+ */
+static int intel_guc_exit_sleep(struct intel_guc *guc)
+{
+ struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ struct i915_gem_context *ctx;
+ u32 data[3];
+
+ if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
+ return 0;
+
+ if (i915.guc_log_level >= 0)
+ gen9_enable_guc_interrupts(dev_priv);
+
+ ctx = dev_priv->kernel_context;
+
+ data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
+ data[1] = GUC_POWER_D0;
+ /* first page is shared data with GuC */
+ data[2] = guc_ggtt_offset(ctx->engine[RCS].state) +
LRC_GUCSHR_PN * PAGE_SIZE;
+
+ return intel_guc_send(guc, data, ARRAY_SIZE(data));
+}
+
int intel_uc_runtime_suspend(struct d
Re: [Intel-gfx] [PATCH v4 3/9] drm/i915/guc: Update GuC ggtt.invalidate/interrupts/communication across RPM suspend/resume
On 9/21/2017 3:03 AM, Michal Wajdeczko wrote:
On Wed, 20 Sep 2017 19:38:18 +0200, Sagar Arun Kamble
wrote:
Apart from configuring interrupts, we need to update the ggtt invalidate
interface and GuC communication on suspend. This functionality can be
reused for other suspend and reset paths.
Prepared GuC specific helpers to handle these suspend/resume tasks
namely - intel_guc_runtime_suspend, intel_guc_runtime_resume.
v2: Rebase w.r.t removal of GuC code restructuring.
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_uc.c | 66
-
1 file changed, 59 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uc.c
b/drivers/gpu/drm/i915/intel_uc.c
index 0dbb4b9..fa698db 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -551,8 +551,6 @@ static int intel_guc_enter_sleep(struct intel_guc
*guc)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
- gen9_disable_guc_interrupts(dev_priv);
-
ctx = dev_priv->kernel_context;
data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
@@ -577,9 +575,6 @@ static int intel_guc_exit_sleep(struct intel_guc
*guc)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
- if (i915.guc_log_level >= 0)
- gen9_enable_guc_interrupts(dev_priv);
-
ctx = dev_priv->kernel_context;
data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
@@ -590,14 +585,71 @@ static int intel_guc_exit_sleep(struct
intel_guc *guc)
return intel_guc_send(guc, data, ARRAY_SIZE(data));
}
+int intel_guc_runtime_suspend(struct intel_guc *guc)
+{
+ struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ int ret;
+
+ ret = intel_guc_enter_sleep(guc);
+ if (ret) {
+ DRM_ERROR("GuC enter sleep failed (%d)\n", ret);
+ return ret;
+ }
+
+ i915_ggtt_disable_guc(dev_priv);
+ gen9_disable_guc_interrupts(dev_priv);
To match existing approach in intel_uc_init_hw() move interrupts
control to uc_runtime_suspend()
Yes. Will update as suggested.
+
+ return 0;
+}
+
+int intel_guc_runtime_resume(struct intel_guc *guc)
+{
+ struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ int ret;
+
+ if (i915.guc_log_level >= 0)
+ gen9_enable_guc_interrupts(dev_priv);
Similar here
Yes. Will update as suggested.
+ i915_ggtt_enable_guc(dev_priv);
+
+ ret = intel_guc_exit_sleep(guc);
+ if (ret) {
+ DRM_ERROR("GuC exit sleep failed (%d)\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
int intel_uc_runtime_suspend(struct drm_i915_private *dev_priv)
{
- return intel_guc_enter_sleep(&dev_priv->guc);
+ int ret;
+
+ if (!i915.enable_guc_loading)
+ return 0;
+
+ ret = intel_guc_runtime_suspend(&dev_priv->guc);
+ if (ret)
+ return ret;
+
+ guc_disable_communication(&dev_priv->guc);
+
+ return 0;
}
int intel_uc_runtime_resume(struct drm_i915_private *dev_priv)
{
- return intel_guc_exit_sleep(&dev_priv->guc);
+ int ret;
+
+ if (!i915.enable_guc_loading)
+ return 0;
+
+ ret = guc_enable_communication(&dev_priv->guc);
+ if (ret) {
+ DRM_ERROR("GuC enable communication failed (%d)\n", ret);
+ return ret;
+ }
+
+ return intel_guc_runtime_resume(&dev_priv->guc);
}
int intel_uc_suspend(struct drm_i915_private *dev_priv)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 4/9] drm/i915/guc: Update suspend functionality in intel_uc_suspend path
On Wed, Sep 20, 2017 at 11:08:19PM +0530, Sagar Arun Kamble wrote:
> With this patch we disable GuC submission in i915_drm_suspend. This will
> destroy the client which will be setup back again. We also reuse the
> complete sanitization done via intel_uc_runtime_suspend in this path.
> Post drm resume this state is recreated by intel_uc_init_hw hence we need
> not have similar reuse for intel_uc_resume.
> This also fixes issue where intel_uc_fini_hw was being called after GPU
> reset happening in i915_gem_suspend in i915_driver_unload.
>
> v2: Rebase w.r.t removal of GuC code restructuring. Added struct_mutex
> protection for i915_guc_submission_disable.
>
> Cc: Michal Wajdeczko
> Cc: Michał Winiarski
> Signed-off-by: Sagar Arun Kamble
> ---
> drivers/gpu/drm/i915/intel_uc.c | 18 ++
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
> index fa698db..0c7e45c7 100644
> --- a/drivers/gpu/drm/i915/intel_uc.c
> +++ b/drivers/gpu/drm/i915/intel_uc.c
> @@ -446,9 +446,6 @@ void intel_uc_fini_hw(struct drm_i915_private *dev_priv)
> if (!i915.enable_guc_loading)
> return;
>
> - if (i915.enable_guc_submission)
> - i915_guc_submission_disable(dev_priv);
> -
> guc_disable_communication(&dev_priv->guc);
>
> if (i915.enable_guc_submission) {
> @@ -654,7 +651,20 @@ int intel_uc_runtime_resume(struct drm_i915_private
> *dev_priv)
>
> int intel_uc_suspend(struct drm_i915_private *dev_priv)
> {
> - return intel_guc_enter_sleep(&dev_priv->guc);
> + struct drm_device *dev = &dev_priv->drm;
> + int ret;
Drop the locals.
I'd drop the dev, and just go through dev_priv in this case.
> +
> + if (i915.enable_guc_submission) {
> + mutex_lock(&dev->struct_mutex);
> + i915_guc_submission_disable(dev_priv);
> + mutex_unlock(&dev->struct_mutex);
> + }
Since we're starting to use i915_guc_submission_disable from different places,
some of which without struct_mutex already held (like this one), it would be a
good idea to add a lockdep assert documenting this requirement inside both
i915_guc_submission_enable and i915_guc_submission_disable.
It could be even squeezed in with this patch IMHO.
> +
> + ret = intel_uc_runtime_suspend(dev_priv);
> + if (ret)
> + return ret;
return intel_guc_runtime_suspend(dev_priv);
With that:
Reviewed-by: Michał Winiarski
-Michał
> +
> + return 0;
> }
>
> int intel_uc_resume(struct drm_i915_private *dev_priv)
> --
> 1.9.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 4/9] drm/i915/guc: Update suspend functionality in intel_uc_suspend path
On 9/21/2017 10:16 PM, Michał Winiarski wrote:
On Wed, Sep 20, 2017 at 11:08:19PM +0530, Sagar Arun Kamble wrote:
With this patch we disable GuC submission in i915_drm_suspend. This will
destroy the client which will be setup back again. We also reuse the
complete sanitization done via intel_uc_runtime_suspend in this path.
Post drm resume this state is recreated by intel_uc_init_hw hence we need
not have similar reuse for intel_uc_resume.
This also fixes issue where intel_uc_fini_hw was being called after GPU
reset happening in i915_gem_suspend in i915_driver_unload.
v2: Rebase w.r.t removal of GuC code restructuring. Added struct_mutex
protection for i915_guc_submission_disable.
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_uc.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index fa698db..0c7e45c7 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -446,9 +446,6 @@ void intel_uc_fini_hw(struct drm_i915_private *dev_priv)
if (!i915.enable_guc_loading)
return;
- if (i915.enable_guc_submission)
- i915_guc_submission_disable(dev_priv);
-
guc_disable_communication(&dev_priv->guc);
if (i915.enable_guc_submission) {
@@ -654,7 +651,20 @@ int intel_uc_runtime_resume(struct drm_i915_private
*dev_priv)
int intel_uc_suspend(struct drm_i915_private *dev_priv)
{
- return intel_guc_enter_sleep(&dev_priv->guc);
+ struct drm_device *dev = &dev_priv->drm;
+ int ret;
Drop the locals.
I'd drop the dev, and just go through dev_priv in this case.
Sure. Will update.
+
+ if (i915.enable_guc_submission) {
+ mutex_lock(&dev->struct_mutex);
+ i915_guc_submission_disable(dev_priv);
+ mutex_unlock(&dev->struct_mutex);
+ }
Since we're starting to use i915_guc_submission_disable from different places,
some of which without struct_mutex already held (like this one), it would be a
good idea to add a lockdep assert documenting this requirement inside both
i915_guc_submission_enable and i915_guc_submission_disable.
It could be even squeezed in with this patch IMHO.
Sure. Will update.
+
+ ret = intel_uc_runtime_suspend(dev_priv);
+ if (ret)
+ return ret;
return intel_guc_runtime_suspend(dev_priv);
Did you really mean intel_*guc*_runtime_suspend here or was typo?
With that:
Reviewed-by: Michał Winiarski
-Michał
+
+ return 0;
}
int intel_uc_resume(struct drm_i915_private *dev_priv)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/9] drm/i915: Create uc runtime and system suspend/resume helpers
On Wed, Sep 20, 2017 at 11:08:16PM +0530, Sagar Arun Kamble wrote:
> Prepared generic helpers intel_uc_suspend, intel_uc_resume,
> intel_uc_runtime_suspend, intel_uc_runtime_resume. Added
> error handling to all the calls for suspend/resume.
I find the error handling done this way quite surprising...
More below.
>
> v2: Rebase w.r.t removal of GuC code restructuring.
>
> Cc: Michal Wajdeczko
> Cc: Michał Winiarski
> Signed-off-by: Sagar Arun Kamble
> ---
> drivers/gpu/drm/i915/i915_drv.c | 23 ---
> drivers/gpu/drm/i915/i915_gem.c | 7 ++-
> drivers/gpu/drm/i915/intel_uc.c | 20
> drivers/gpu/drm/i915/intel_uc.h | 4
> 4 files changed, 50 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 5c111ea..8635f40 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1691,7 +1691,15 @@ static int i915_drm_resume(struct drm_device *dev)
> }
> mutex_unlock(&dev->struct_mutex);
>
> - intel_guc_resume(dev_priv);
> + /*
> + * NB: Full gem reinitialization is being done above, hence
> + * intel_uc_resume will be of no use. Currently intel_uc_resume
> + * is nop. If full reinitialization is removed, will need to put
> + * functionality to resume from sleep in intel_uc_resume.
> + */
> + ret = intel_uc_resume(dev_priv);
> + if (ret)
> + DRM_ERROR("failed to resume uc\n");
>
> intel_modeset_init_hw(dev);
>
> @@ -2493,7 +2501,12 @@ static int intel_runtime_suspend(struct device *kdev)
>*/
> i915_gem_runtime_suspend(dev_priv);
>
> - intel_guc_suspend(dev_priv);
> + ret = intel_uc_runtime_suspend(dev_priv);
> + if (ret) {
> + DRM_ERROR("uc runtime suspend failed, disabling it(%d)\n", ret);
> + enable_rpm_wakeref_asserts(dev_priv);
> + return ret;
Early exit?
> + }
>
> intel_runtime_pm_disable_interrupts(dev_priv);
>
> @@ -2578,7 +2591,11 @@ static int intel_runtime_resume(struct device *kdev)
> if (intel_uncore_unclaimed_mmio(dev_priv))
> DRM_DEBUG_DRIVER("Unclaimed access during suspend, bios?\n");
>
> - intel_guc_resume(dev_priv);
> + ret = intel_uc_runtime_resume(dev_priv);
> + if (ret) {
> + DRM_ERROR("uc runtime resume failed (%d)\n", ret);
> + return ret;
Same here.
> + }
>
> if (IS_GEN9_LP(dev_priv)) {
> bxt_disable_dc9(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index c4bf348..dd56d45 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4539,7 +4539,11 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
> i915_gem_contexts_lost(dev_priv);
> mutex_unlock(&dev->struct_mutex);
>
> - intel_guc_suspend(dev_priv);
> + ret = intel_uc_suspend(dev_priv);
> + if (ret) {
> + DRM_ERROR("uc suspend failed (%d)\n", ret);
> + goto out;
Should we really exit early if GuC sleep action fails?
In all of those cases - is this really something critical? Shouldn't we go
through the rest of the suspend/resume dance even if we fail to talk with GuC?
-Michał
> + }
>
> cancel_delayed_work_sync(&dev_priv->gpu_error.hangcheck_work);
> cancel_delayed_work_sync(&dev_priv->gt.retire_work);
> @@ -4583,6 +4587,7 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
>
> err_unlock:
> mutex_unlock(&dev->struct_mutex);
> +out:
> intel_runtime_pm_put(dev_priv);
> return ret;
> }
> diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
> index 0178ba4..8e4d8b0 100644
> --- a/drivers/gpu/drm/i915/intel_uc.c
> +++ b/drivers/gpu/drm/i915/intel_uc.c
> @@ -537,3 +537,23 @@ int intel_guc_sample_forcewake(struct intel_guc *guc)
>
> return intel_guc_send(guc, action, ARRAY_SIZE(action));
> }
> +
> +int intel_uc_runtime_suspend(struct drm_i915_private *dev_priv)
> +{
> + return intel_guc_suspend(dev_priv);
> +}
> +
> +int intel_uc_runtime_resume(struct drm_i915_private *dev_priv)
> +{
> + return intel_guc_resume(dev_priv);
> +}
> +
> +int intel_uc_suspend(struct drm_i915_private *dev_priv)
> +{
> + return intel_guc_suspend(dev_priv);
> +}
> +
> +int intel_uc_resume(struct drm_i915_private *dev_priv)
> +{
> + return 0;
> +}
> diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
> index 7703c9a..3d33a51 100644
> --- a/drivers/gpu/drm/i915/intel_uc.h
> +++ b/drivers/gpu/drm/i915/intel_uc.h
> @@ -208,6 +208,10 @@ struct intel_huc {
> void intel_uc_fini_fw(struct drm_i915_private *dev_priv);
> int intel_uc_init_hw(struct drm_i915_private *dev_priv);
> void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
> +int intel_uc_runtime_suspend(struct drm_i915_private *dev_priv);
> +int intel_uc_runt
Re: [Intel-gfx] [RFC PATCH 4/4] drm/i915: Expose RPCS (SSEU) configuration to userspace
On 01/09/17 19:58, Chris Wilson wrote:
Quoting Lionel Landwerlin (2017-09-01 18:12:30)
From: Chris Wilson
We want to allow userspace to reconfigure the subslice configuration for
its own use case. To do so, we expose a context parameter to allow
adjustment of the RPCS register stored within the context image (and
currently not accessible via LRI). If the context is adjusted before
first use, the adjustment is for "free"; otherwise if the context is
active we flush the context off the GPU (stalling all users) and forcing
the GPU to save the context to memory where we can modify it and so
ensure that the register is reloaded on next execution.
The overhead of managing additional EU subslices can be significant,
especially in multi-context workloads. Non-GPGPU contexts should
preferably disable the subslices it is not using, and others should
fine-tune the number to match their workload.
We expose complete control over the RPCS register, allowing
configuration of slice/subslice, via masks packed into a u64 for
simplicity. For example,
struct drm_i915_gem_context_param arg;
memset(&arg, 0, sizeof(arg));
arg.ctx_id = ctx;
arg.param = I915_CONTEXT_PARAM_SSEU;
if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, &arg) == 0) {
union drm_i915_gem_context_param_sseu *sseu = &arg.value;
sseu->packed.subslice_mask = 0;
drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, &arg);
}
could be used to disable all subslices where supported.
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
Cc: Dmitry Rogozhkin
CC: Tvrtko Ursulin
CC: Zhipeng Gong
CC: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_context.c | 11 ++
drivers/gpu/drm/i915/intel_lrc.c| 69 +
drivers/gpu/drm/i915/intel_lrc.h| 2 +
include/uapi/drm/i915_drm.h | 11 ++
4 files changed, 93 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 97fcb01d70eb..d399b03f452c 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1042,6 +1042,9 @@ int i915_gem_context_getparam_ioctl(struct drm_device
*dev, void *data,
case I915_CONTEXT_PARAM_BANNABLE:
args->value = i915_gem_context_is_bannable(ctx);
break;
+ case I915_CONTEXT_PARAM_SSEU:
+ args->value = intel_lr_context_get_sseu(ctx);
+ break;
default:
ret = -EINVAL;
break;
@@ -1097,6 +1100,14 @@ int i915_gem_context_setparam_ioctl(struct drm_device
*dev, void *data,
else
i915_gem_context_clear_bannable(ctx);
break;
+ case I915_CONTEXT_PARAM_SSEU:
+ if (args->size)
+ ret = -EINVAL;
+ else if (!i915.enable_execlists)
+ ret = -ENODEV;
+ else
+ ret = intel_lr_context_set_sseu(ctx, args->value);
+ break;
default:
ret = -EINVAL;
break;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 1693fd9d279b..c063b84911d5 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2122,3 +2122,72 @@ void intel_lr_context_resume(struct drm_i915_private
*dev_priv)
}
}
}
+
+int intel_lr_context_set_sseu(struct i915_gem_context *ctx, u64 value)
+{
+ union drm_i915_gem_context_param_sseu user = { .value = value };
+ struct drm_i915_private *i915 = ctx->i915;
+ struct intel_context *ce = &ctx->engine[RCS];
+ struct sseu_dev_info sseu = ctx->engine[RCS].sseu;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ int ret;
I have a note saying that we want to pass in (engine, class), and so
forgo the packed value and switch to an array of structs.
-Chris
Not sure what you meant by class. I've used the same flags as the
execbuff2 field.
I'm programming only the RCS (since documentation says that's the only
thing that is allowed).
But reading the R_PWR_CLK_STATE from other engine seems to give
incoherent results...
Would you expect that?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/9] drm/i915: Create uc runtime and system suspend/resume helpers
On 9/21/2017 10:46 PM, Michał Winiarski wrote:
On Wed, Sep 20, 2017 at 11:08:16PM +0530, Sagar Arun Kamble wrote:
Prepared generic helpers intel_uc_suspend, intel_uc_resume,
intel_uc_runtime_suspend, intel_uc_runtime_resume. Added
error handling to all the calls for suspend/resume.
I find the error handling done this way quite surprising...
More below.
v2: Rebase w.r.t removal of GuC code restructuring.
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_drv.c | 23 ---
drivers/gpu/drm/i915/i915_gem.c | 7 ++-
drivers/gpu/drm/i915/intel_uc.c | 20
drivers/gpu/drm/i915/intel_uc.h | 4
4 files changed, 50 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5c111ea..8635f40 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1691,7 +1691,15 @@ static int i915_drm_resume(struct drm_device *dev)
}
mutex_unlock(&dev->struct_mutex);
- intel_guc_resume(dev_priv);
+ /*
+* NB: Full gem reinitialization is being done above, hence
+* intel_uc_resume will be of no use. Currently intel_uc_resume
+* is nop. If full reinitialization is removed, will need to put
+* functionality to resume from sleep in intel_uc_resume.
+*/
+ ret = intel_uc_resume(dev_priv);
+ if (ret)
+ DRM_ERROR("failed to resume uc\n");
intel_modeset_init_hw(dev);
@@ -2493,7 +2501,12 @@ static int intel_runtime_suspend(struct device *kdev)
*/
i915_gem_runtime_suspend(dev_priv);
- intel_guc_suspend(dev_priv);
+ ret = intel_uc_runtime_suspend(dev_priv);
+ if (ret) {
+ DRM_ERROR("uc runtime suspend failed, disabling it(%d)\n", ret);
+ enable_rpm_wakeref_asserts(dev_priv);
+ return ret;
Early exit?
+ }
intel_runtime_pm_disable_interrupts(dev_priv);
@@ -2578,7 +2591,11 @@ static int intel_runtime_resume(struct device *kdev)
if (intel_uncore_unclaimed_mmio(dev_priv))
DRM_DEBUG_DRIVER("Unclaimed access during suspend, bios?\n");
- intel_guc_resume(dev_priv);
+ ret = intel_uc_runtime_resume(dev_priv);
+ if (ret) {
+ DRM_ERROR("uc runtime resume failed (%d)\n", ret);
+ return ret;
Same here.
+ }
if (IS_GEN9_LP(dev_priv)) {
bxt_disable_dc9(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c4bf348..dd56d45 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4539,7 +4539,11 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
i915_gem_contexts_lost(dev_priv);
mutex_unlock(&dev->struct_mutex);
- intel_guc_suspend(dev_priv);
+ ret = intel_uc_suspend(dev_priv);
+ if (ret) {
+ DRM_ERROR("uc suspend failed (%d)\n", ret);
+ goto out;
Should we really exit early if GuC sleep action fails?
In all of those cases - is this really something critical? Shouldn't we go
through the rest of the suspend/resume dance even if we fail to talk with GuC?
-Michał
Yes. Failure in GuC suspend/resume has to be critical. Essentially while
going into RPM suspend
we do want to ensure GuC is paused and dont want to go ahead and set PCI
device state to D3 even if
we knew GuC is active.
Similarly for resume. If we want to resume with i915 execlists when GuC
resume fails that would be
different code change.
+ }
cancel_delayed_work_sync(&dev_priv->gpu_error.hangcheck_work);
cancel_delayed_work_sync(&dev_priv->gt.retire_work);
@@ -4583,6 +4587,7 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
err_unlock:
mutex_unlock(&dev->struct_mutex);
+out:
intel_runtime_pm_put(dev_priv);
return ret;
}
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 0178ba4..8e4d8b0 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -537,3 +537,23 @@ int intel_guc_sample_forcewake(struct intel_guc *guc)
return intel_guc_send(guc, action, ARRAY_SIZE(action));
}
+
+int intel_uc_runtime_suspend(struct drm_i915_private *dev_priv)
+{
+ return intel_guc_suspend(dev_priv);
+}
+
+int intel_uc_runtime_resume(struct drm_i915_private *dev_priv)
+{
+ return intel_guc_resume(dev_priv);
+}
+
+int intel_uc_suspend(struct drm_i915_private *dev_priv)
+{
+ return intel_guc_suspend(dev_priv);
+}
+
+int intel_uc_resume(struct drm_i915_private *dev_priv)
+{
+ return 0;
+}
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 7703c9a..3d33a51 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -208,6 +208,10 @@ struct intel_huc {
void intel_uc_fini_fw(struc
[Intel-gfx] [PATCH v18 1/2] drm/i915: Do not allocate unused PPAT entries
Only PPAT entries 0/2/3/4 are using. Remove extra PPAT entry allocation
during initialization.
v17:
- Refine ppat_index() and move the comments. (Joonas)
v8:
- Move ppat_index() into i915_gem_gtt.c. (Chris)
- Change the name of ppat_bits_to_index to ppat_index.
Suggested-by: Joonas Lahtinen
Signed-off-by: Zhi Wang
Cc: Ben Widawsky
Cc: Rodrigo Vivi
Cc: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 52 ++---
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 731ce22..43e0d23 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -230,9 +230,11 @@ static gen8_pte_t gen8_pte_encode(dma_addr_t addr,
switch (level) {
case I915_CACHE_NONE:
+ /* Uncached objects, mostly for scanout */
pte |= PPAT_UNCACHED;
break;
case I915_CACHE_WT:
+ /* for scanout with eLLC */
pte |= PPAT_DISPLAY_ELLC;
break;
default:
@@ -249,6 +251,7 @@ static gen8_pde_t gen8_pde_encode(const dma_addr_t addr,
gen8_pde_t pde = _PAGE_PRESENT | _PAGE_RW;
pde |= addr;
if (level != I915_CACHE_NONE)
+ /* for normal objects, no eLLC */
pde |= PPAT_CACHED_PDE;
else
pde |= PPAT_UNCACHED;
@@ -2988,6 +2991,14 @@ static unsigned int chv_private_pat_match(u8 src, u8 dst)
INTEL_PPAT_PERFECT_MATCH : 0;
}
+/* PPAT index = 4 * PAT + 2 * PCD + PWT */
+static inline unsigned int ppat_index(unsigned int bits)
+{
+ return (4 * !!(bits & _PAGE_PAT) +
+ 2 * !!(bits & _PAGE_PCD) +
+ !!(bits & _PAGE_PWT));
+}
+
static void cnl_setup_private_ppat(struct intel_ppat *ppat)
{
ppat->max_entries = 8;
@@ -2997,18 +3008,14 @@ static void cnl_setup_private_ppat(struct intel_ppat
*ppat)
/* XXX: spec is unclear if this is still needed for CNL+ */
if (!USES_PPGTT(ppat->i915)) {
- __alloc_ppat_entry(ppat, 0, GEN8_PPAT_UC);
+ __alloc_ppat_entry(ppat, ppat_index(PPAT_CACHED_PDE),
GEN8_PPAT_UC);
return;
}
- __alloc_ppat_entry(ppat, 0, GEN8_PPAT_WB | GEN8_PPAT_LLC);
- __alloc_ppat_entry(ppat, 1, GEN8_PPAT_WC | GEN8_PPAT_LLCELLC);
- __alloc_ppat_entry(ppat, 2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC);
- __alloc_ppat_entry(ppat, 3, GEN8_PPAT_UC);
- __alloc_ppat_entry(ppat, 4, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC |
GEN8_PPAT_AGE(0));
- __alloc_ppat_entry(ppat, 5, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC |
GEN8_PPAT_AGE(1));
- __alloc_ppat_entry(ppat, 6, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC |
GEN8_PPAT_AGE(2));
- __alloc_ppat_entry(ppat, 7, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC |
GEN8_PPAT_AGE(3));
+ __alloc_ppat_entry(ppat, ppat_index(PPAT_CACHED_PDE), GEN8_PPAT_WB |
GEN8_PPAT_LLC);
+ __alloc_ppat_entry(ppat, ppat_index(PPAT_DISPLAY_ELLC), GEN8_PPAT_WT |
GEN8_PPAT_LLCELLC);
+ __alloc_ppat_entry(ppat, ppat_index(PPAT_UNCACHED), GEN8_PPAT_UC);
+ __alloc_ppat_entry(ppat, ppat_index(PPAT_CACHED), GEN8_PPAT_WB |
GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(0));
}
/* The GGTT and PPGTT need a private PPAT setup in order to handle cacheability
@@ -3035,18 +3042,14 @@ static void bdw_setup_private_ppat(struct intel_ppat
*ppat)
* So we can still hold onto all our assumptions wrt cpu
* clflushing on LLC machines.
*/
- __alloc_ppat_entry(ppat, 0, GEN8_PPAT_UC);
+ __alloc_ppat_entry(ppat, ppat_index(PPAT_CACHED_PDE),
GEN8_PPAT_UC);
return;
}
- __alloc_ppat_entry(ppat, 0, GEN8_PPAT_WB | GEN8_PPAT_LLC); /* for
normal objects, no eLLC */
- __alloc_ppat_entry(ppat, 1, GEN8_PPAT_WC | GEN8_PPAT_LLCELLC); /* for
something pointing to ptes? */
- __alloc_ppat_entry(ppat, 2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC); /* for
scanout with eLLC */
- __alloc_ppat_entry(ppat, 3, GEN8_PPAT_UC); /*
Uncached objects, mostly for scanout */
- __alloc_ppat_entry(ppat, 4, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC |
GEN8_PPAT_AGE(0));
- __alloc_ppat_entry(ppat, 5, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC |
GEN8_PPAT_AGE(1));
- __alloc_ppat_entry(ppat, 6, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC |
GEN8_PPAT_AGE(2));
- __alloc_ppat_entry(ppat, 7, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC |
GEN8_PPAT_AGE(3));
+ __alloc_ppat_entry(ppat, ppat_index(PPAT_CACHED_PDE), GEN8_PPAT_WB |
GEN8_PPAT_LLC);
+ __alloc_ppat_entry(ppat, ppat_index(PPAT_DISPLAY_ELLC), GEN8_PPAT_WT |
GEN8_PPAT_LLCELLC);
+ __alloc_ppat_entry(ppat, ppat_index(PPAT_UNCACHED), GEN8_PPAT_UC);
+ __alloc_ppat_entry(ppat, ppat_index(PPAT_CACHED), GEN8_PPAT_WB |
GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(0));
}
s
