[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Disable LVDS on Radiant P845
== Series Details == Series: drm/i915: Disable LVDS on Radiant P845 URL : https://patchwork.freedesktop.org/series/39732/ State : success == Summary == Possible new issues: Test kms_cursor_crc: Subgroup cursor-64x64-suspend: skip -> PASS (shard-snb) Known issues: Test drv_suspend: Subgroup debugfs-reader: pass -> SKIP (shard-snb) fdo#102365 Test gem_eio: Subgroup in-flight-contexts: incomplete -> PASS (shard-apl) fdo#105341 Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-pri-shrfb-draw-blt: pass -> FAIL (shard-apl) fdo#101623 fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 shard-apltotal:3467 pass:1825 dwarn:1 dfail:0 fail:8 skip:1632 time:12221s shard-hswtotal:3467 pass:1773 dwarn:1 dfail:0 fail:1 skip:1691 time:11580s shard-snbtotal:3467 pass:1364 dwarn:1 dfail:0 fail:1 skip:2101 time:7005s Blacklisted hosts: shard-kbltotal:3405 pass:1911 dwarn:4 dfail:0 fail:7 skip:1481 time:8597s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8298/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for igt: Add gem_ctx_freq to exercise requesting freq on a ctx (rev2)
== Series Details == Series: igt: Add gem_ctx_freq to exercise requesting freq on a ctx (rev2) URL : https://patchwork.freedesktop.org/series/39571/ State : failure == Summary == Possible new issues: Test kms_draw_crc: Subgroup draw-method-xrgb2101010-mmap-gtt-xtiled: pass -> FAIL (shard-apl) Known issues: Test drv_suspend: Subgroup debugfs-reader: skip -> PASS (shard-snb) fdo#102365 Test gem_eio: Subgroup in-flight-contexts: pass -> INCOMPLETE (shard-apl) fdo#105341 Test kms_flip: Subgroup plain-flip-fb-recreate-interruptible: pass -> FAIL (shard-hsw) fdo#100368 +1 Test kms_plane: Subgroup plane-panning-bottom-right-suspend-pipe-a-planes: pass -> FAIL (shard-apl) fdo#103375 Test pm_lpsp: Subgroup screens-disabled: fail -> PASS (shard-hsw) fdo#104941 fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941 shard-apltotal:3407 pass:1770 dwarn:1 dfail:0 fail:9 skip:1625 time:11840s shard-hswtotal:3494 pass:1771 dwarn:1 dfail:0 fail:3 skip:1718 time:11673s shard-snbtotal:3494 pass:1365 dwarn:1 dfail:0 fail:1 skip:2127 time:7011s Blacklisted hosts: shard-kbltotal:3331 pass:1849 dwarn:1 dfail:0 fail:5 skip:1474 time:8608s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1101/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Add Plane Color Properties (rev3)
== Series Details == Series: Add Plane Color Properties (rev3) URL : https://patchwork.freedesktop.org/series/30875/ State : failure == Summary == Possible new issues: Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-spr-indfb-draw-mmap-wc: pass -> DMESG-FAIL (shard-hsw) Known issues: Test gem_eio: Subgroup in-flight: incomplete -> PASS (shard-apl) fdo#105341 +1 Test kms_flip: Subgroup plain-flip-ts-check-interruptible: fail -> PASS (shard-hsw) fdo#100368 +1 Test kms_sysfs_edid_timing: pass -> WARN (shard-apl) fdo#100047 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 shard-apltotal:3467 pass:1825 dwarn:1 dfail:0 fail:8 skip:1632 time:12253s shard-hswtotal:3467 pass:1770 dwarn:1 dfail:1 fail:2 skip:1692 time:11436s shard-snbtotal:3467 pass:1365 dwarn:1 dfail:0 fail:1 skip:2100 time:6926s Blacklisted hosts: shard-kbltotal:3398 pass:1907 dwarn:7 dfail:1 fail:6 skip:1476 time:8953s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8297/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/uc: Sanitize uC together with GEM
On 09/03/18 08:01, Michal Wajdeczko wrote: Instead of dancing around uC on reset/suspend/resume scenarios, explicitly sanitize uC when we sanitize GEM to force uC reload and start from known beginning. v2: don't forget about reset path (Daniele) sanitize uc before gem initiated full reset (Daniele) Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Cc: Sagar Arun Kamble Cc: Chris Wilson Cc: Michel Thierry Reviewed-by: Daniele Ceraolo Spurio a small comment below diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index a45171c..abd1f7b 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -327,6 +327,24 @@ void intel_uc_fini(struct drm_i915_private *dev_priv) intel_guc_fini(guc); } +void intel_uc_sanitize(struct drm_i915_private *i915) +{ + struct intel_guc *guc = &i915->guc; + struct intel_huc *huc = &i915->huc; + + if (!USES_GUC(i915)) + return; + + GEM_BUG_ON(!HAS_GUC(i915)); + + guc_disable_communication(guc); With this here, can we now drop the guc_disable_communication in intel_uc_init_hw? Thanks, Daniele + + intel_huc_sanitize(huc); + intel_guc_sanitize(guc); + + __intel_uc_reset_hw(i915); +} + int intel_uc_init_hw(struct drm_i915_private *dev_priv) { struct intel_guc *guc = &dev_priv->guc; diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h index dce4813..937e611 100644 --- a/drivers/gpu/drm/i915/intel_uc.h +++ b/drivers/gpu/drm/i915/intel_uc.h @@ -34,6 +34,7 @@ void intel_uc_fini_fw(struct drm_i915_private *dev_priv); int intel_uc_init_misc(struct drm_i915_private *dev_priv); void intel_uc_fini_misc(struct drm_i915_private *dev_priv); +void intel_uc_sanitize(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_init(struct drm_i915_private *dev_priv); diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h b/drivers/gpu/drm/i915/intel_uc_fw.h index d5fd460..2601521 100644 --- a/drivers/gpu/drm/i915/intel_uc_fw.h +++ b/drivers/gpu/drm/i915/intel_uc_fw.h @@ -115,6 +115,12 @@ static inline bool intel_uc_fw_is_selected(struct intel_uc_fw *uc_fw) return uc_fw->path != NULL; } +static inline void intel_uc_fw_sanitize(struct intel_uc_fw *uc_fw) +{ + if (uc_fw->load_status == INTEL_UC_FIRMWARE_SUCCESS) + uc_fw->load_status = INTEL_UC_FIRMWARE_PENDING; +} + void intel_uc_fw_fetch(struct drm_i915_private *dev_priv, struct intel_uc_fw *uc_fw); int intel_uc_fw_upload(struct intel_uc_fw *uc_fw, ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make edp optimize config
On Fri, 2018-03-09 at 14:05 +0200, Jani Nikula wrote: > On Thu, 08 Mar 2018, matthew.s.atw...@intel.com wrote: > > > > From: Matt Atwood > > > > Previously it was assumed that eDP panels would advertise the > > lowest link > > rate required for their singular mode to function. With the > > introduction > > of more advanced features there are advantages to a panel > > advertising a > > higher rate then it needs for a its given mode. For panels that > > did, the > > driver previously used a higher rate then necessary for that mode. > > > > Signed-off-by: Matt Atwood > > --- > > drivers/gpu/drm/i915/intel_dp.c | 10 -- > > 1 file changed, 10 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > > b/drivers/gpu/drm/i915/intel_dp.c > > index a2eeede..aa6d77d 100644 > > --- a/drivers/gpu/drm/i915/intel_dp.c > > +++ b/drivers/gpu/drm/i915/intel_dp.c > > @@ -1758,16 +1758,6 @@ intel_dp_compute_config(struct intel_encoder > > *encoder, > > dev_priv->vbt.edp.bpp); > > bpp = dev_priv->vbt.edp.bpp; > > } > > - > > - /* > > - * Use the maximum clock and number of lanes the > > eDP panel > > - * advertizes being capable of. The panels are > > generally > > - * designed to support only a single clock and > > lane > > - * configuration, and typically these values > > correspond to the > > - * native resolution of the panel. > > - */ > > - min_lane_count = max_lane_count; > > - min_clock = max_clock; > Please see my reply to Manasi's identical patch [1]. If we apply this > as-is, it will regress and will be reverted. > > BR, > Jani. > > > [1] http://patchwork.freedesktop.org/patch/msgid/1520579339-14745-1- > git-send-email-manasi.d.nav...@intel.com to consolidate some of the information the bug that's referenced in Manasi's patch is https://bugs.freedesktop.org/show_bug.cgi?id=73539. I understand this bug as the following some panels may advertise a mode that requires less then MAX_LANE_COUNT, however those panels would fail if less lanes were used. When this bug was filed the compute config inner for loop iterated on rate and the outer iterated on lanes; this is now flipped. It *should* be the case that the lowest frequency with the max amount of lanes is preferred. Given the opposite behavior of the alogorithm to select I dont think we'd come across this again. Even if I'm wrong we could still min_lane_count = max_lane count and let the clock optimize itself. I guess my question is, is there also a bug where if MAX_RATE wasnt used we saw a panel fail as well? Matt > > > > > > } > > > > for (; bpp >= 6*3; bpp -= 2*3) { ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4
On Thu, 2018-03-08 at 09:22 +0200, Jani Nikula wrote: > On Wed, 07 Mar 2018, matthew.s.atw...@intel.com wrote: > > > > From: Matt Atwood > > > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme > > from 8 > > bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended > > receiver capabilities. For panels that use this new feature wait > > interval > > would be increased by 512 ms, when spec is max 16 ms. This behavior > > is > > described in table 2-158 of DP 1.4 spec address eh. > > > > With the introduction of DP 1.4 spec main link clock recovery was > > standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL > > value. > > > > To avoid breaking panels that are not spec compiant we now warn on > > invalid values. > > > > V2: commit title/message, masking all 7 bits, warn on out of spec > > values. > > V3: commit message, make link train clock recovery follow DP 1.4 > > spec. > > V4: style changes > > V5: typo > > > > Signed-off-by: Matt Atwood > > --- > > drivers/gpu/drm/drm_dp_helper.c | 18 ++ > > include/drm/drm_dp_helper.h | 6 ++ > > 2 files changed, 20 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_dp_helper.c > > b/drivers/gpu/drm/drm_dp_helper.c > > index adf79be..cdb04c9 100644 > > --- a/drivers/gpu/drm/drm_dp_helper.c > > +++ b/drivers/gpu/drm/drm_dp_helper.c > > @@ -119,18 +119,28 @@ u8 > > drm_dp_get_adjust_request_pre_emphasis(const u8 > > link_status[DP_LINK_STATUS_SI > > EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis); > > > > void drm_dp_link_train_clock_recovery_delay(const u8 > > dpcd[DP_RECEIVER_CAP_SIZE]) { > > - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0) > > + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & > > DP_TRAINING_AUX_RD_MASK; > > + > > + if (rd_interval > 4) > > + DRM_DEBUG_KMS("AUX interval %d, out of range (max > > 4)", rd_interval); > \n missing. will do > > > > > + > > + if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DP_REV_14)) > > udelay(100); > > else > > - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4); > > + mdelay(rd_interval * 4); > > } > > EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay); > > > > void drm_dp_link_train_channel_eq_delay(const u8 > > dpcd[DP_RECEIVER_CAP_SIZE]) { > > - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0) > > + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & > > DP_TRAINING_AUX_RD_MASK; > > + > > + if (rd_interval > 4) > > + DRM_DEBUG_KMS("AUX interval %d, out of range (max > > 4)", rd_interval); > \n missing. will do > > > > > + > > + if (rd_interval == 0) > > udelay(400); > > else > > - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4); > > + mdelay(rd_interval * 4); > > } > > EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay); > > > > diff --git a/include/drm/drm_dp_helper.h > > b/include/drm/drm_dp_helper.h > > index da58a42..1269ef8 100644 > > --- a/include/drm/drm_dp_helper.h > > +++ b/include/drm/drm_dp_helper.h > > @@ -64,6 +64,11 @@ > > /* AUX CH addresses */ > > /* DPCD */ > > #define DP_DPCD_REV 0x000 > > +# define DP_REV_10 0x10 > > +# define DP_REV_11 0x11 > > +# define DP_REV_12 0x12 > > +# define DP_REV_13 0x13 > > +# define DP_REV_14 0x14 > I am not sure what good these buy us, but if people think they're the > way to go, then so be it. Just bear in mind that per spec, "The DPCD > revision number does not necessarily match the DisplayPort version > number." so "DP_REV" doesn't actually mean *DP* revision. > > > BR, > Jani. you're right likely a better name is DPCD_REV_XX. I think we sill want to base the main-link clock recovery on time on this value. Next revision will include this naming convention. > > > > > > > #define DP_MAX_LINK_RATE0x001 > > > > @@ -118,6 +123,7 @@ > > # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 > > or higher */ > > > > #define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ > > +# define DP_TRAINING_AUX_RD_MASK0x7F/* 1.3 */ Rodrigo has shown me a DP 1.2 spec that had this change and conflicts with my copy so I'll be changing to XXX 1.2 Matt > > > > #define DP_ADAPTER_CAP 0x00f /* 1.2 > > */ > > # define DP_FORCE_LOAD_SENSE_CAP (1 << 0) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Add NV12 support
== Series Details == Series: Add NV12 support URL : https://patchwork.freedesktop.org/series/39670/ State : failure == Summary == Possible new issues: Test kms_chv_cursor_fail: Subgroup pipe-a-128x128-left-edge: fail -> PASS (shard-apl) Test kms_color: Subgroup pipe-c-ctm-negative: pass -> INCOMPLETE (shard-apl) Test kms_plane_scaling: Subgroup pipe-a-scaler-with-pixel-format: pass -> FAIL (shard-apl) Subgroup pipe-a-scaler-with-rotation: pass -> FAIL (shard-apl) Subgroup pipe-b-scaler-with-pixel-format: pass -> FAIL (shard-apl) Subgroup pipe-b-scaler-with-rotation: pass -> FAIL (shard-apl) Known issues: Test gem_eio: Subgroup in-flight: incomplete -> PASS (shard-apl) fdo#105341 Test kms_flip: Subgroup plain-flip-ts-check-interruptible: fail -> PASS (shard-hsw) fdo#100368 Test kms_frontbuffer_tracking: Subgroup fbc-suspend: pass -> DMESG-WARN (shard-snb) fdo#101623 Test kms_sysfs_edid_timing: pass -> WARN (shard-apl) fdo#100047 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 shard-apltotal:3388 pass:1782 dwarn:1 dfail:0 fail:10 skip:1592 time:11647s shard-hswtotal:3467 pass:1772 dwarn:1 dfail:0 fail:1 skip:1692 time:11578s shard-snbtotal:3467 pass:1364 dwarn:2 dfail:0 fail:1 skip:2100 time:6943s Blacklisted hosts: shard-kbltotal:3398 pass:1909 dwarn:2 dfail:0 fail:10 skip:1476 time:8942s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8296/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 drm/i915: Disable LVDS on Radiant P845
== Series Details == Series: drm/i915: Disable LVDS on Radiant P845 URL : https://patchwork.freedesktop.org/series/39732/ State : success == Summary == Series 39732v1 drm/i915: Disable LVDS on Radiant P845 https://patchwork.freedesktop.org/api/1.0/series/39732/revisions/1/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:423s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:370s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:500s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:278s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:490s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:489s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:487s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:467s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:410s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:576s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:586s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:415s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:288s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:519s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:397s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:409s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:462s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:418s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:471s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:459s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:508s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:592s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:430s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:524s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:531s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:499s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:489s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:421s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:430s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:513s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:391s Blacklisted hosts: fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:505s fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:510s 7e5ff4244a75361f62abdb9e484e31a125131920 drm-tip: 2018y-03m-09d-22h-21m-43s UTC integration manifest 7985fffe1a0d drm/i915: Disable LVDS on Radiant P845 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8298/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/4] drm/i915/guc: Tidy guc_log_control
== Series Details == Series: series starting with [CI,1/4] drm/i915/guc: Tidy guc_log_control URL : https://patchwork.freedesktop.org/series/39710/ State : failure == Summary == Possible new issues: Test drv_missed_irq: pass -> SKIP (shard-apl) Test drv_selftest: Subgroup live_guc: pass -> DMESG-WARN (shard-apl) Test gem_exec_capture: Subgroup capture-vebox: pass -> FAIL (shard-apl) Test perf: Subgroup gen8-unprivileged-single-ctx-counters: pass -> FAIL (shard-apl) Known issues: Test gem_eio: Subgroup in-flight-contexts: incomplete -> PASS (shard-apl) fdo#105341 +1 Test kms_flip: Subgroup 2x-flip-vs-expired-vblank: pass -> FAIL (shard-hsw) fdo#102887 Subgroup plain-flip-ts-check-interruptible: fail -> PASS (shard-hsw) fdo#100368 +1 Test kms_plane_multiple: Subgroup atomic-pipe-c-tiling-y: pass -> FAIL (shard-apl) fdo#103166 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166 shard-apltotal:3262 pass:1716 dwarn:2 dfail:0 fail:17 skip:1524 time:11509s shard-hswtotal:3467 pass:1770 dwarn:1 dfail:0 fail:3 skip:1692 time:11547s shard-snbtotal:3467 pass:1365 dwarn:1 dfail:0 fail:1 skip:2100 time:6868s Blacklisted hosts: shard-kbltotal:3168 pass:1779 dwarn:2 dfail:1 fail:18 skip:1364 time:8065s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8295/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Disable LVDS on Radiant P845
Radiant P845 does not have LVDS, only VGA. Signed-off-by: Ondrej Zary --- drivers/gpu/drm/i915/intel_lvds.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c index ef80499113ee..6939e63d8bae 100644 --- a/drivers/gpu/drm/i915/intel_lvds.c +++ b/drivers/gpu/drm/i915/intel_lvds.c @@ -819,6 +819,14 @@ static const struct dmi_system_id intel_no_lvds[] = { DMI_EXACT_MATCH(DMI_BOARD_NAME, "D525MW"), }, }, + { + .callback = intel_no_lvds_dmi_callback, + .ident = "Radiant P845", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Radiant Systems Inc"), + DMI_MATCH(DMI_PRODUCT_NAME, "P845"), + }, + }, { } /* terminating entry */ }; -- Ondrej Zary ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: misc fixes in headers (RESEND)
Quoting Patchwork (2018-03-09 22:12:20) > == Series Details == > > Series: drm/i915: misc fixes in headers (RESEND) > URL : https://patchwork.freedesktop.org/series/39589/ > State : failure > > == Summary == > > Possible new issues: > > Test kms_cursor_legacy: > Subgroup short-flip-after-cursor-atomic-transitions: > pass -> FAIL (shard-hsw) > Test kms_frontbuffer_tracking: > Subgroup fbc-rgb101010-draw-pwrite: > pass -> FAIL (shard-apl) > > Known issues: > > Test gem_eio: > Subgroup in-flight: > incomplete -> PASS (shard-apl) fdo#105341 > Test kms_cursor_crc: > Subgroup cursor-128x128-suspend: > skip -> PASS (shard-hsw) fdo#103540 > Test kms_flip: > Subgroup 2x-modeset-vs-vblank-race: > pass -> DMESG-WARN (shard-hsw) fdo#103060 > Subgroup plain-flip-ts-check-interruptible: > fail -> PASS (shard-hsw) fdo#100368 > Test pm_lpsp: > Subgroup screens-disabled: > pass -> FAIL (shard-hsw) fdo#104941 > > fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 > fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 > fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 > fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 > fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941 > > shard-apltotal:3398 pass:1792 dwarn:1 dfail:0 fail:8 skip:1596 > time:11758s > shard-hswtotal:3467 pass:1770 dwarn:2 dfail:0 fail:3 skip:1691 > time:11639s > shard-snbtotal:3467 pass:1365 dwarn:1 dfail:0 fail:1 skip:2100 > time:6999s As pw is finally happy, pushed. Thanks for the cleanup, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: misc fixes in headers (RESEND)
== Series Details == Series: drm/i915: misc fixes in headers (RESEND) URL : https://patchwork.freedesktop.org/series/39589/ State : failure == Summary == Possible new issues: Test kms_cursor_legacy: Subgroup short-flip-after-cursor-atomic-transitions: pass -> FAIL (shard-hsw) Test kms_frontbuffer_tracking: Subgroup fbc-rgb101010-draw-pwrite: pass -> FAIL (shard-apl) Known issues: Test gem_eio: Subgroup in-flight: incomplete -> PASS (shard-apl) fdo#105341 Test kms_cursor_crc: Subgroup cursor-128x128-suspend: skip -> PASS (shard-hsw) fdo#103540 Test kms_flip: Subgroup 2x-modeset-vs-vblank-race: pass -> DMESG-WARN (shard-hsw) fdo#103060 Subgroup plain-flip-ts-check-interruptible: fail -> PASS (shard-hsw) fdo#100368 Test pm_lpsp: Subgroup screens-disabled: pass -> FAIL (shard-hsw) fdo#104941 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941 shard-apltotal:3398 pass:1792 dwarn:1 dfail:0 fail:8 skip:1596 time:11758s shard-hswtotal:3467 pass:1770 dwarn:2 dfail:0 fail:3 skip:1691 time:11639s shard-snbtotal:3467 pass:1365 dwarn:1 dfail:0 fail:1 skip:2100 time:6999s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8294/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 igt: Add gem_ctx_freq to exercise requesting freq on a ctx (rev2)
== Series Details == Series: igt: Add gem_ctx_freq to exercise requesting freq on a ctx (rev2) URL : https://patchwork.freedesktop.org/series/39571/ State : success == Summary == IGT patchset tested on top of latest successful build 5d71d7782a830843c7231fbd72ab3edae19b48d7 igt/gem_fd_exhaustion: Modify fs.nr_open for duration of the test with latest DRM-Tip kernel build CI_DRM_3907 b97cfb3880fd drm-tip: 2018y-03m-09d-21h-14m-12s UTC integration manifest Testlist changes: +igt@gem_ctx_freq@blt-continuous +igt@gem_ctx_freq@blt-inflight +igt@gem_ctx_freq@blt-single +igt@gem_ctx_freq@bsd1-continuous +igt@gem_ctx_freq@bsd1-inflight +igt@gem_ctx_freq@bsd1-single +igt@gem_ctx_freq@bsd2-continuous +igt@gem_ctx_freq@bsd2-inflight +igt@gem_ctx_freq@bsd2-single +igt@gem_ctx_freq@bsd-continuous +igt@gem_ctx_freq@bsd-inflight +igt@gem_ctx_freq@bsd-single +igt@gem_ctx_freq@default-continuous +igt@gem_ctx_freq@default-inflight +igt@gem_ctx_freq@default-single +igt@gem_ctx_freq@idempotent +igt@gem_ctx_freq@independent +igt@gem_ctx_freq@invalid +igt@gem_ctx_freq@range +igt@gem_ctx_freq@render-continuous +igt@gem_ctx_freq@render-inflight +igt@gem_ctx_freq@render-single +igt@gem_ctx_freq@sandwich +igt@gem_ctx_freq@smoketest +igt@gem_ctx_freq@vebox-continuous +igt@gem_ctx_freq@vebox-inflight +igt@gem_ctx_freq@vebox-single Known issues: Test debugfs_test: Subgroup read_all_entries: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 Test kms_chamelium: Subgroup dp-edid-read: pass -> FAIL (fi-kbl-7500u) fdo#102505 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> INCOMPLETE (fi-hsw-4770) fdo#104944 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505 fdo#104944 https://bugs.freedesktop.org/show_bug.cgi?id=104944 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:425s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:373s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:510s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:280s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:490s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:495s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:483s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:476s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:409s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:578s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:589s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:415s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:288s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:520s fi-hsw-4770 total:244 pass:220 dwarn:0 dfail:0 fail:0 skip:23 fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:412s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:465s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:417s fi-kbl-7500u total:288 pass:262 dwarn:1 dfail:0 fail:1 skip:24 time:470s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:467s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:507s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:584s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:433s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:524s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:533s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:505s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:495s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:423s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:434s fi-snb-2520m total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:394s Blacklisted hosts: fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:504s fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:509s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1101/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://list
[Intel-gfx] [PATCH i-g-t v2] tests/kms_rotation_crc: Remove hardcoding of platforms in igt_require()
From: Anusha Srivatsa Rework the rotate and reflect subtests by checking the crtc supported properties against the ones that the test is testing. Remove the hardcoded platform names in igt_require() v2: Make use of the property enums to get the supported rotations Cc: Radhakrishna Sripada Cc: Daniel Vetter Cc: Rodrigo Vivi Cc: Maarten Lankhorst Cc: Mika Kahola Cc: Manasi Navare Signed-off-by: Anusha Srivatsa Signed-off-by: Radhakrishna Sripada --- lib/igt_kms.h| 1 + tests/kms_rotation_crc.c | 46 +- 2 files changed, 38 insertions(+), 9 deletions(-) diff --git a/lib/igt_kms.h b/lib/igt_kms.h index 1c46186e8a9d..c306aa1f5b8d 100644 --- a/lib/igt_kms.h +++ b/lib/igt_kms.h @@ -289,6 +289,7 @@ typedef enum { #define IGT_ROTATION_MASK \ (IGT_ROTATION_0 | IGT_ROTATION_90 | IGT_ROTATION_180 | IGT_ROTATION_270) +#define IGT_REFLECT_MASK (IGT_REFLECT_X | IGT_REFLECT_Y) typedef struct { /*< private >*/ diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c index 0cd5c6e52b57..8f7e5d4f2dd2 100644 --- a/tests/kms_rotation_crc.c +++ b/tests/kms_rotation_crc.c @@ -38,6 +38,7 @@ typedef struct { igt_crc_t flip_crc; igt_pipe_crc_t *pipe_crc; igt_rotation_t rotation; + int **supported_rotation; int pos_x; int pos_y; uint32_t override_fmt; @@ -373,13 +374,14 @@ static void test_plane_rotation(data_t *data, int plane_type, bool test_bad_form igt_plane_t *plane; int i, j; - if (IS_CHERRYVIEW(data->devid) && pipe != PIPE_B) - continue; - igt_output_set_pipe(output, pipe); plane = igt_output_get_plane_type(output, plane_type); igt_require(igt_plane_has_prop(plane, IGT_PLANE_ROTATION)); + igt_require(data->supported_rotation[pipe][plane->index] & data->rotation); + + if (data->rotation & IGT_REFLECT_MASK) + igt_require(data->supported_rotation[pipe][plane->index] & IGT_REFLECT_MASK); prepare_crtc(data, output, pipe, plane); @@ -460,6 +462,36 @@ static void test_plane_rotation_exhaust_fences(data_t *data, igt_remove_fb(fd, &fb[i]); } +static void igt_supported_rotation_init(data_t *data) +{ + igt_display_t *display = &data->display; + bool found; + int i, j, k, n_pipes = display->n_pipes; + int **s_rotation; + + s_rotation = calloc(sizeof(int *), n_pipes); + + for (i = 0; i < n_pipes; i++) { + s_rotation[i] = calloc(sizeof(int), (display->pipes + i)->n_planes); + + for (j = 0; j < (display->pipes + i)->n_planes; j++) { + drmModePropertyPtr prop; + found = kmstest_get_property(data->gfx_fd, display->pipes[i].planes[j].drm_plane->plane_id, + DRM_MODE_OBJECT_PLANE, "rotation", NULL, NULL, &prop); + igt_assert(found); + igt_assert(prop->flags & DRM_MODE_PROP_BITMASK); + + for (k = 0; k < prop->count_enums; k++) { + s_rotation[i][j] |= 1 << (prop->enums[k].value); + } + + drmModeFreeProperty(prop); + } + } + + data->supported_rotation = s_rotation; +} + static const char *plane_test_str(unsigned plane) { switch (plane) { @@ -552,15 +584,13 @@ igt_main igt_require_pipe_crc(data.gfx_fd); igt_display_init(&data.display, data.gfx_fd); + igt_supported_rotation_init(&data); } for (subtest = subtests; subtest->rot; subtest++) { igt_subtest_f("%s-rotation-%s", plane_test_str(subtest->plane), rot_test_str(subtest->rot)) { - igt_require(!(subtest->rot & - (IGT_ROTATION_90 | IGT_ROTATION_270)) || - gen >= 9); data.rotation = subtest->rot; test_plane_rotation(&data, subtest->plane, false); } @@ -596,9 +626,7 @@ igt_main igt_subtest_f("primary-%s-reflect-x-%s", tiling_test_str(reflect_x->tiling), rot_test_str(reflect_x->rot)) { - igt_require(gen >= 10 || - (IS_CHERRYVIEW(data.devid) && reflect_x->rot == IGT_ROTATION_0 -&& reflect_x->tiling == LOCAL_I915_FORMAT_MOD_X_TILED)); + igt_require(reflect_x->rot == IGT_ROTATION_0 && reflect_x->tiling == LOCAL_I915_FORMAT_MOD_X_TILED); data.rotation = (IGT_REFLECT_X | reflect_x->rot);
[Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx
Exercise some new API that allows applications to request that individual contexts are executed within a desired frequency range. v2: Split single/continuous set_freq subtests v3: Do an up/down ramp for individual freq request, check nothing changes after each invalid request v4: Check the frequencies reported by the kernel across the entire range. v5: Rewrite sandwich to create a sandwich between multiple concurrent engines. Signed-off-by: Chris Wilson Cc: Praveen Paneri Cc: Sagar A Kamble Cc: Antonio Argenziano --- tests/Makefile.am | 1 + tests/Makefile.sources | 1 + tests/gem_ctx_freq.c | 691 + tests/meson.build | 1 + 4 files changed, 694 insertions(+) create mode 100644 tests/gem_ctx_freq.c diff --git a/tests/Makefile.am b/tests/Makefile.am index dbc7be72..389f7fc7 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -104,6 +104,7 @@ drm_import_export_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS) drm_import_export_LDADD = $(LDADD) -lpthread gem_close_race_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS) gem_close_race_LDADD = $(LDADD) -lpthread +gem_ctx_freq_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la gem_ctx_thrash_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS) gem_ctx_thrash_LDADD = $(LDADD) -lpthread gem_exec_parallel_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS) diff --git a/tests/Makefile.sources b/tests/Makefile.sources index 4a81ac4a..3d079c42 100644 --- a/tests/Makefile.sources +++ b/tests/Makefile.sources @@ -58,6 +58,7 @@ TESTS_progs = \ gem_ctx_bad_exec \ gem_ctx_create \ gem_ctx_exec \ + gem_ctx_freq \ gem_ctx_isolation \ gem_ctx_param \ gem_ctx_switch \ diff --git a/tests/gem_ctx_freq.c b/tests/gem_ctx_freq.c new file mode 100644 index ..fc5df3d9 --- /dev/null +++ b/tests/gem_ctx_freq.c @@ -0,0 +1,691 @@ +/* + * Copyright © 2018 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 +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "igt.h" +#include "igt_perf.h" + +#define LOCAL_CONTEXT_PARAM_FREQUENCY 7 + +#define SAMPLE_PERIOD (USEC_PER_SEC / 10) + +static int __set_freq(int fd, uint32_t ctx, uint32_t min, uint32_t max) +{ + struct drm_i915_gem_context_param param = { + .ctx_id = ctx, + .param = LOCAL_CONTEXT_PARAM_FREQUENCY, + .value = (uint64_t)max << 32 | min, + }; + + return __gem_context_set_param(fd, ¶m); +} + +static void set_freq(int fd, uint32_t ctx, uint32_t min, uint32_t max) +{ + igt_assert_eq(__set_freq(fd, ctx, min, max), 0); +} + +static void get_freq(int fd, uint32_t ctx, uint32_t *min, uint32_t *max) +{ + struct drm_i915_gem_context_param param = { + .ctx_id = ctx, + .param = LOCAL_CONTEXT_PARAM_FREQUENCY, + }; + + gem_context_get_param(fd, ¶m); + + *min = param.value & 0x; + *max = param.value >> 32; +} + +static double measure_frequency(int pmu, int period_us) +{ + uint64_t data[2]; + uint64_t d_t, d_v; + + igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data)); + d_v = -data[0]; + d_t = -data[1]; + + usleep(period_us); + + igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data)); + d_v += data[0]; + d_t += data[1]; + + return d_v * 1e9 / d_t; +} + +static void single(int fd, const struct intel_execution_engine *e) +{ +#define N_STEPS 10 + const unsigned int engine = e->exec_id | e->flags; + uint32_t ctx = gem_context_create(fd); + uint32_t min, max; + double measured; + igt_spin_t *spin; + int pmu; + + get_freq(fd, ctx, &min, &max); + igt_info("Min freq: %dMHz; Max freq: %dMHz\n", min, max); + + pmu = perf_i915_open(I915_
[Intel-gfx] [PATCH v3 1/5] drm/i915: Move DP modeset retry work into intel_dp
While having the modeset_retry_work in intel_connector makes sense with SST, this paradigm doesn't make a whole ton of sense when it comes to MST since we have to deal with multiple connectors. In most cases, it's more useful to just use the intel_dp struct since it indicates whether or not we're dealing with an MST device, along with being able to easily trace the intel_dp struct back to it's respective connector (if there is any). So, move the modeset_retry_work function out of the intel_connector struct and into intel_dp. Signed-off-by: Lyude Paul Reviewed-by: Manasi Navare Cc: Manasi Navare Cc: Ville Syrjälä V2: - Remove accidental duplicate modeset_retry_work in intel_connector V3: - Also check against eDP in intel_hpd_poll_fini() - mdnavare Signed-off-by: Lyude Paul --- drivers/gpu/drm/i915/intel_display.c | 25 +++-- drivers/gpu/drm/i915/intel_dp.c | 10 -- drivers/gpu/drm/i915/intel_dp_link_training.c | 2 +- drivers/gpu/drm/i915/intel_drv.h | 6 +++--- 4 files changed, 31 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f424fff477f6..3b7fa430a84a 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -15394,16 +15394,37 @@ static void intel_hpd_poll_fini(struct drm_device *dev) { struct intel_connector *connector; struct drm_connector_list_iter conn_iter; + struct work_struct *work; + int conn_type; /* Kill all the work that may have been queued by hpd. */ drm_connector_list_iter_begin(dev, &conn_iter); for_each_intel_connector_iter(connector, &conn_iter) { - if (connector->modeset_retry_work.func) - cancel_work_sync(&connector->modeset_retry_work); if (connector->hdcp_shim) { cancel_delayed_work_sync(&connector->hdcp_check_work); cancel_work_sync(&connector->hdcp_prop_work); } + + conn_type = connector->base.connector_type; + if (conn_type != DRM_MODE_CONNECTOR_eDP && + conn_type != DRM_MODE_CONNECTOR_DisplayPort) + continue; + + if (connector->mst_port) { + work = &connector->mst_port->modeset_retry_work; + } else { + struct intel_encoder *intel_encoder = + connector->encoder; + struct intel_dp *intel_dp; + + if (!intel_encoder) + continue; + + intel_dp = enc_to_intel_dp(&intel_encoder->base); + work = &intel_dp->modeset_retry_work; + } + + cancel_work_sync(work); } drm_connector_list_iter_end(&conn_iter); } diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 4dd1b2287dd6..5abf0c95725a 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -6261,12 +6261,10 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp, static void intel_dp_modeset_retry_work_fn(struct work_struct *work) { - struct intel_connector *intel_connector; - struct drm_connector *connector; + struct intel_dp *intel_dp = container_of(work, typeof(*intel_dp), +modeset_retry_work); + struct drm_connector *connector = &intel_dp->attached_connector->base; - intel_connector = container_of(work, typeof(*intel_connector), - modeset_retry_work); - connector = &intel_connector->base; DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id, connector->name); @@ -6295,7 +6293,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port, int type; /* Initialize the work for modeset in case of link train failure */ - INIT_WORK(&intel_connector->modeset_retry_work, + INIT_WORK(&intel_dp->modeset_retry_work, intel_dp_modeset_retry_work_fn); if (WARN(intel_dig_port->max_lanes < 1, diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c index f59b59bb0a21..2cfa58ce1f95 100644 --- a/drivers/gpu/drm/i915/intel_dp_link_training.c +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c @@ -340,7 +340,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp) intel_dp->link_rate, intel_dp->lane_count)) /* Schedule a Hotplug Uevent to userspace to start modeset */ - schedule_work(&intel_connector->modeset_retry_work); + schedule_w
[Intel-gfx] [PATCH v3 5/5] drm/i915: Implement proper fallback training for MST
For a while we actually haven't had any way of retraining MST links with fallback link parameters like we do with SST. While uncommon, certain setups such as my Caldigit TS3 + EVGA MST hub require this since otherwise, they end up getting stuck in an infinite MST retraining loop. MST retraining is somewhat different then SST retraining. While it's possible during the normal link retraining sequence for a hub to indicate bad link status, it's also possible for a hub to only indicate this status through ESI messages and it's possible for this to happen after the initial link training succeeds. This can lead to a pattern that looks like this: - Train MST link - Training completes successfully - MST hub sets Channel EQ failed bit in ESI - Retraining starts - Retraining completes successfully - MST hub sets Channel EQ failed bit in ESI again - Rinse and repeat In these situations, we need to be able to actually trigger fallback link training from the ESI handler as well, along with using the ESI handler during retraining to figure out whether or not our retraining actually succeeded. This gets a bit more complicated since we have to ensure that we don't block the ESI handler at all while doing retraining. If we do, due to DisplayPort's general issues with being sensitive to IRQ latency most MST hubs will just stop responding to us if their interrupts aren't handled in a timely manner. So: move retraining into it's own seperate handler. Running in a seperate handler allows us to avoid stalling the ESI during link retraining, and we can have the ESI signal that the channel EQ bit was cleared through a simple completion struct. Additionally, we take care to stick as much of this into the SST retraining path as possible since sharing is caring. Signed-off-by: Lyude Paul Cc: Manasi Navare Cc: Ville Syrjälä --- drivers/gpu/drm/i915/intel_dp.c | 342 +++- drivers/gpu/drm/i915/intel_dp_mst.c | 42 - drivers/gpu/drm/i915/intel_drv.h| 8 + 3 files changed, 302 insertions(+), 90 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 5645a194de92..7626652732b6 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -45,6 +45,8 @@ #define DP_DPRX_ESI_LEN 14 +#define DP_MST_RETRAIN_TIMEOUT (msecs_to_jiffies(100)) + /* Compliance test status bits */ #define INTEL_DP_RESOLUTION_SHIFT_MASK 0 #define INTEL_DP_RESOLUTION_PREFERRED (1 << INTEL_DP_RESOLUTION_SHIFT_MASK) @@ -4224,6 +4226,118 @@ static void intel_dp_handle_test_request(struct intel_dp *intel_dp) DRM_DEBUG_KMS("Could not write test response to sink\n"); } +/* Get a mask of the CRTCs that are running on the given intel_dp struct. For + * MST, this returns a crtc mask containing all of the CRTCs driving + * downstream sinks, for SST it just returns a mask of the attached + * connector's CRTC. + */ +int +intel_dp_get_crtc_mask(struct intel_dp *intel_dp) +{ + struct drm_device *dev = dp_to_dig_port(intel_dp)->base.base.dev; + struct drm_connector *connector; + struct drm_connector_state *conn_state; + struct intel_connector *intel_connector; + struct drm_crtc *crtc; + int crtc_mask = 0; + + WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex)); + + if (intel_dp->is_mst) { + struct drm_connector_list_iter conn_iter; + + drm_connector_list_iter_begin(dev, &conn_iter); + for_each_intel_connector_iter(intel_connector, &conn_iter) { + if (intel_connector->mst_port != intel_dp) + continue; + + conn_state = intel_connector->base.state; + if (!conn_state->crtc) + continue; + + crtc_mask |= drm_crtc_mask(conn_state->crtc); + } + drm_connector_list_iter_end(&conn_iter); + } else { + connector = &intel_dp->attached_connector->base; + crtc = connector->state->crtc; + + if (crtc) + crtc_mask |= drm_crtc_mask(crtc); + } + + return crtc_mask; +} + +static bool +intel_dp_needs_link_retrain(struct intel_dp *intel_dp, + const u8 esi[DP_DPRX_ESI_LEN]) +{ + u8 buf[max(DP_LINK_STATUS_SIZE, DP_DPRX_ESI_LEN)]; + const u8 *link_status = NULL; + + if (intel_dp->is_mst) { + if (!intel_dp->active_mst_links) + return false; + if (intel_dp->mst_link_is_bad) + return false; + + if (esi) { + link_status = &esi[10]; + } else { + /* We're not running from the ESI handler, so wait a +* little bit to see if the ESI handler lets us know +* that the link status is
[Intel-gfx] [PATCH v3 2/5] drm/i915: Only use one link bw config for MST topologies
When a DP MST link needs retraining, sometimes the hub will detect that the current link bw config is impossible and will update it's RX caps in the DPCD to reflect the new maximum link rate. Currently, we make the assumption that the RX caps in the dpcd will never change like this. This means if the sink changes it's RX caps after we've already set up an MST link and we attempt to add or remove another sink from the topology, we could put ourselves into an invalid state where we've tried to configure different sinks on the same MST topology with different link rates. We could also run into this situation if a sink reports a higher link rate after suspend, usually from us having trained it with a fallback bw configuration before suspending. So: "lock" the bw config by only using the max DP link rate/lane count on the first modeset for an MST topology. For every modeset following, we instead use the last configured link bw for this topology. We only unlock the bw config when we've detected a new MST sink. Signed-off-by: Lyude Paul Cc: Manasi Navare Cc: Ville Syrjälä --- drivers/gpu/drm/i915/intel_dp.c | 11 +-- drivers/gpu/drm/i915/intel_dp_mst.c | 22 +++--- drivers/gpu/drm/i915/intel_drv.h| 6 ++ 3 files changed, 30 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 5abf0c95725a..5645a194de92 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -3871,18 +3871,25 @@ intel_dp_can_mst(struct intel_dp *intel_dp) static void intel_dp_configure_mst(struct intel_dp *intel_dp) { + bool was_mst; + if (!i915_modparams.enable_dp_mst) return; if (!intel_dp->can_mst) return; + was_mst = intel_dp->is_mst; intel_dp->is_mst = intel_dp_can_mst(intel_dp); - if (intel_dp->is_mst) + if (intel_dp->is_mst) { DRM_DEBUG_KMS("Sink is MST capable\n"); - else + + if (!was_mst) + intel_dp->mst_bw_locked = false; + } else { DRM_DEBUG_KMS("Sink is not MST capable\n"); + } drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr, intel_dp->is_mst); diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index c3de0918ee13..c0553456b18e 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -42,7 +42,7 @@ static bool intel_dp_mst_compute_config(struct intel_encoder *encoder, to_intel_connector(conn_state->connector); struct drm_atomic_state *state = pipe_config->base.state; int bpp; - int lane_count, slots; + int lane_count, link_rate, slots; const struct drm_display_mode *adjusted_mode = &pipe_config->base.adjusted_mode; int mst_pbn; bool reduce_m_n = drm_dp_has_quirk(&intel_dp->desc, @@ -56,16 +56,22 @@ static bool intel_dp_mst_compute_config(struct intel_encoder *encoder, bpp); } /* -* for MST we always configure max link bw - the spec doesn't -* seem to suggest we should do otherwise. +* for MST we always configure max link bw if we don't know better - +* the spec doesn't seem to suggest we should do otherwise. But, +* ensure it always stays consistent with the rest of this hub's +* state. */ - lane_count = intel_dp_max_lane_count(intel_dp); + if (intel_dp->mst_bw_locked) { + lane_count = intel_dp->lane_count; + link_rate = intel_dp->link_rate; + } else { + lane_count = intel_dp_max_lane_count(intel_dp); + link_rate = intel_dp_max_link_rate(intel_dp); + } pipe_config->lane_count = lane_count; - pipe_config->pipe_bpp = bpp; - - pipe_config->port_clock = intel_dp_max_link_rate(intel_dp); + pipe_config->port_clock = link_rate; if (drm_dp_mst_port_has_audio(&intel_dp->mst_mgr, connector->port)) pipe_config->has_audio = true; @@ -221,6 +227,8 @@ static void intel_mst_pre_enable_dp(struct intel_encoder *encoder, connector->encoder = encoder; intel_mst->connector = connector; + intel_dp->mst_bw_locked = true; + DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links); drm_dp_send_power_updown_phy(&intel_dp->mst_mgr, connector->port, true); diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 3f19dc80997f..fc338529e918 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -1107,6 +1107,12 @@ struct intel_dp { bool can_mst; /* this port supports mst */ bool is_mst; int active_mst_links; + /* Set when we've already decided on a link bw for mst, to prevent us +* fr
[Intel-gfx] [PATCH v3 3/5] drm/dp_mst: Add drm_dp_mst_topology_mgr_lower_link_rate()
Unlike SST, MST can have far more then a single display hooked up on a single port. What this also means however, is that if the DisplayPort link to the top-level MST branch device becomes unstable then every single branch device also has an unstable link. Additionally, MST has a few more steps that must be taken in order to properly retrain the entire topology under a lower link rate. Since the VCID allocations for each mstb is determined based off the link rate for the top of the topology, we also have to recalculate all of the VCID allocations for the downstream ports as well to ensure that we still have enough link bandwidth to drive each mstb. Additionally, since we have multiple downstream connectors per port, setting the link status of the parent mstb's port to bad isn't enough: all of the downstream mstb ports have to have their link status set to bad. This basically follows the same paradigm that our DP link status logic in DRM does, in that we simply tell userspace that all of the mstb ports need retraining and additionally applying the new lower bandwidth constraints to all of the atomic commits on the topology that follow. Since the work of figuring out which connectors live downstream on an MST topology and updating their link status is something that any driver supporting MST is going to need to do in order to retrain MST links properly, we add the drm_dp_mst_topology_mgr_lower_link_rate() helper which simply recalculates the pbn_div for a given mst topology, then marks the link status of all connectors living in that topology as bad. We'll make use of it in i915 later in this series. Signed-off-by: Lyude Paul Cc: Manasi Navare Cc: Ville Syrjälä --- drivers/gpu/drm/drm_dp_mst_topology.c | 73 ++- include/drm/drm_dp_mst_helper.h | 3 ++ 2 files changed, 75 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 6fac4129e6a2..0d6604500b29 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -2076,7 +2076,7 @@ static bool drm_dp_get_vc_payload_bw(int dp_link_bw, { switch (dp_link_bw) { default: - DRM_DEBUG_KMS("invalid link bandwidth in DPCD: %x (link count: %d)\n", + DRM_DEBUG_KMS("invalid link bandwidth: %x (link count: %d)\n", dp_link_bw, dp_link_count); return false; @@ -2096,6 +2096,77 @@ static bool drm_dp_get_vc_payload_bw(int dp_link_bw, return true; } +static void drm_dp_set_mstb_link_status(struct drm_dp_mst_branch *mstb, + enum drm_link_status status) +{ + struct drm_dp_mst_branch *rmstb; + struct drm_dp_mst_port *port; + + list_for_each_entry(port, &mstb->ports, next) { + rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb); + if (rmstb) { + drm_dp_set_mstb_link_status(rmstb, status); + drm_dp_put_mst_branch_device(rmstb); + } + + if (port->connector) + port->connector->state->link_status = status; + } +} + +/** + * drm_dp_mst_topology_mgr_lower_link_rate() - Override the DP link bw/count + * for all connectors in a given MST topology + * @mgr: manager to set state for + * @dp_link_bw: The new DP link bandwidth + * @dp_link_count: The new DP link count + * + * This is called by the driver when it detects that the current DP link for + * the given topology manager is unstable, and needs to be retrained at a + * lower link rate. + * + * This takes care of updating the link status on all downstream connectors + * along with recalculating the VC payloads. The driver should send a hotplug + * event after calling this function to notify userspace of the link status + * change. + * + * RETURNS: + * + * True for success, or negative error code on failure. + */ +int drm_dp_mst_topology_mgr_lower_link_rate(struct drm_dp_mst_topology_mgr *mgr, + int dp_link_bw, int dp_link_count) +{ + struct drm_device *dev = mgr->dev; + struct drm_dp_mst_branch *mst_primary; + int new_pbn_div; + int ret = 0; + + drm_modeset_lock(&dev->mode_config.connection_mutex, NULL); + + if (!drm_dp_get_vc_payload_bw(drm_dp_link_rate_to_bw_code(dp_link_bw), + dp_link_count, &new_pbn_div)) { + ret = -EINVAL; + goto out; + } + + mst_primary = drm_dp_get_validated_mstb_ref(mgr, mgr->mst_primary); + if (!mst_primary) + goto out; + + DRM_DEBUG_KMS("MST link failed to retrain, lowering pbn_div to %d\n", + new_pbn_div); + mgr->pbn_div = new_pbn_div; + + drm_dp_set_mstb_link_status(mst_primary, DRM_MODE_LINK_STATUS_BAD); + + drm_dp_put_mst_branch_device(mst_primar
[Intel-gfx] [PATCH v3 4/5] drm/dp_mst: Add drm_atomic_dp_mst_retrain_topology()
Retraining MST is rather difficult. In order to do it properly while guaranteeing that we'll never run into a spot where we commit a physically impossible configuration, we have to do a lot of checks on atomic commits which affect MST topologies. All of this work is going to need to be repeated for every driver at some point, so let's save ourselves some trouble and just implement these atomic checks as a single helper. Signed-off-by: Lyude Paul Cc: Manasi Navare Cc: Ville Syrjälä --- drivers/gpu/drm/drm_dp_mst_topology.c | 223 ++ include/drm/drm_dp_mst_helper.h | 2 + 2 files changed, 225 insertions(+) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 0d6604500b29..c4a91b1ba61b 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -2167,6 +2167,229 @@ int drm_dp_mst_topology_mgr_lower_link_rate(struct drm_dp_mst_topology_mgr *mgr, } EXPORT_SYMBOL(drm_dp_mst_topology_mgr_lower_link_rate); +static bool drm_atomic_dp_mst_state_only_disables_mstbs(struct drm_atomic_state *state, + struct drm_dp_mst_topology_mgr *mgr, + struct drm_dp_mst_branch *mstb) +{ + struct drm_dp_mst_branch *rmstb; + struct drm_dp_mst_port *port; + struct drm_connector *connector; + struct drm_connector_state *conn_state; + struct drm_crtc *crtc; + struct drm_crtc_state *crtc_state; + int ret; + + list_for_each_entry(port, &mstb->ports, next) { + rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb); + if (rmstb) { + ret = drm_atomic_dp_mst_state_only_disables_mstbs( + state, mgr, rmstb); + drm_dp_put_mst_branch_device(rmstb); + if (!ret) + return false; + } + + connector = port->connector; + if (!connector) + continue; + + conn_state = drm_atomic_get_new_connector_state( + state, connector); + if (!conn_state) + continue; + + crtc = conn_state->crtc; + if (!crtc) + continue; + + crtc_state = drm_atomic_get_new_crtc_state(state, crtc); + if (!crtc_state) + continue; + + if (drm_atomic_crtc_needs_modeset(crtc_state)) + return false; + } + + return true; +} + +static int drm_atomic_dp_mst_all_mstbs_disabled(struct drm_atomic_state *state, + struct drm_dp_mst_topology_mgr *mgr, + struct drm_dp_mst_branch *mstb) +{ + struct drm_dp_mst_branch *rmstb; + struct drm_dp_mst_port *port; + struct drm_connector *connector; + struct drm_connector_state *conn_state; + int ret; + + list_for_each_entry(port, &mstb->ports, next) { + rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb); + if (rmstb) { + ret = drm_atomic_dp_mst_all_mstbs_disabled( + state, mgr, rmstb); + drm_dp_put_mst_branch_device(rmstb); + if (ret <= 0) + return ret; + } + + connector = port->connector; + if (!connector) + continue; + + conn_state = drm_atomic_get_connector_state( + state, connector); + if (IS_ERR(conn_state)) + return PTR_ERR(conn_state); + + if (conn_state->crtc) + return false; + } + + /* No enabled CRTCs found */ + return true; +} + +static int drm_atomic_dp_mst_retrain_mstb(struct drm_atomic_state *state, + struct drm_dp_mst_topology_mgr *mgr, + struct drm_dp_mst_branch *mstb, + bool full_modeset) +{ + struct drm_dp_mst_branch *rmstb; + struct drm_dp_mst_port *port; + struct drm_connector *connector; + struct drm_connector_state *conn_state; + struct drm_crtc *crtc; + struct drm_crtc_state *crtc_state; + int ret; + + list_for_each_entry(port, &mstb->ports, next) { + rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb); + if (rmstb) { + ret = drm_atomic_dp_mst_retrain_mstb( + state, mgr, rmstb, full_modeset); + drm_dp_put_mst_branch_device(rmstb); + if (ret) +
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/uc: Sanitize uC (rev2)
== Series Details == Series: drm/i915/uc: Sanitize uC (rev2) URL : https://patchwork.freedesktop.org/series/39634/ State : failure == Summary == Possible new issues: Test drv_missed_irq: pass -> SKIP (shard-apl) Test drv_selftest: Subgroup live_guc: pass -> DMESG-WARN (shard-apl) Test perf: Subgroup gen8-unprivileged-single-ctx-counters: pass -> FAIL (shard-apl) Known issues: Test gem_eio: Subgroup in-flight-contexts: incomplete -> PASS (shard-apl) fdo#105341 +1 Test kms_cursor_crc: Subgroup cursor-128x128-suspend: skip -> PASS (shard-hsw) fdo#103540 Test kms_flip: Subgroup dpms-vs-vblank-race: pass -> FAIL (shard-hsw) fdo#103060 Subgroup plain-flip-ts-check: pass -> FAIL (shard-hsw) fdo#100368 +2 Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 +1 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-apltotal:3338 pass:1754 dwarn:2 dfail:0 fail:14 skip:1566 time:11690s shard-hswtotal:3467 pass:1766 dwarn:1 dfail:0 fail:8 skip:1691 time:11581s shard-snbtotal:3467 pass:1365 dwarn:1 dfail:0 fail:1 skip:2100 time:6947s Blacklisted hosts: shard-kbltotal:2994 pass:1678 dwarn:2 dfail:1 fail:13 skip:1293 time:7175s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8293/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/vc4: Validate framebuffer pixel format/modifier
Ville Syrjala writes: > From: Ville Syrjälä > > Only create framebuffers with supported format/modifier combinations by > checking that at least one plane supports the requested combination. > > Using drm_any_plane_has_format() is somewhat suboptimal for vc4 since > the planes have (mostly) uniform capabilities. But I was lazy and > didn't feel like exporting drm_plane_format_check() and hand rolling > anything better. Also I really just wanted to come up with another > user for drm_any_plane_has_format() ;) I'm not excited about vc4 having error-return behavior that other drivers don't have. Actually, I don't really see why we should be doing this check in fb create at all, given that you have to do so again at atomic_check time with the specific plane. Could you just delete the i915 fb format check code? signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/cnl; Add macro to get PORT_TX register
On Fri, Mar 09, 2018 at 11:55:47AM -0800, Rodrigo Vivi wrote: > On Fri, Mar 09, 2018 at 06:28:56PM +0530, Mahesh Kumar wrote: > > This patch creates a new macro to get PORT_TX register for any given DW. > > This will remove the need of defining register address for each port & DW. > > please squash patches 1 and 2. I had to open both simultaneously to review it > what indicates that they should be 1 patch. > > > > > Signed-off-by: Mahesh Kumar > > --- > > drivers/gpu/drm/i915/i915_reg.h | 28 > > 1 file changed, 28 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h > > b/drivers/gpu/drm/i915/i915_reg.h > > index e6a8c0ee7df1..30ef3513dc6f 100644 > > --- a/drivers/gpu/drm/i915/i915_reg.h > > +++ b/drivers/gpu/drm/i915/i915_reg.h > > @@ -1964,6 +1964,34 @@ enum i915_power_well_id { > > _CNL_PORT_PCS_DW1_LN0_F) > > #define COMMON_KEEPER_EN (1 << 26) > > > > +/* CNL Port TX registers */ > > +#define _CNL_PORT_TX_AE_GRP_OFFSET 0x162340 > > +#define _CNL_PORT_TX_B_GRP_OFFSET 0x1623C0 > > +#define _CNL_PORT_TX_C_GRP_OFFSET 0x162B40 > > +#define _CNL_PORT_TX_D_GRP_OFFSET 0x162BC0 > > +#define _CNL_PORT_TX_F_GRP_OFFSET 0x162A40 > > +#define _CNL_PORT_TX_AE_LN0_OFFSET 0x162440 > > +#define _CNL_PORT_TX_B_LN0_OFFSET 0x162640 > > +#define _CNL_PORT_TX_C_LN0_OFFSET 0x162C40 > > +#define _CNL_PORT_TX_D_LN0_OFFSET 0x162E40 > > +#define _CNL_PORT_TX_F_LN0_OFFSET 0x162840 > > +#define CNL_PORT_TX_DW_GRP(port, dw) (_PICK((port), \ > > + _CNL_PORT_TX_AE_GRP_OFFSET, \ > > + _CNL_PORT_TX_B_GRP_OFFSET, \ > > + _CNL_PORT_TX_B_GRP_OFFSET, \ > > + _CNL_PORT_TX_D_GRP_OFFSET, \ > > + _CNL_PORT_TX_AE_GRP_OFFSET, \ > > + _CNL_PORT_TX_F_GRP_OFFSET) + \ > > + 4*(dw)) > > the math is right. I'm glad someone could see some logic on all these > numbers. I with we had a basic offset and math for all the port registers, > but... > > > +#define CNL_PORT_TX_DW_LN0(port, dw) (_PICK((port), \ > > who converts the offset to MMIO reg now? I don't think this is supposed to be used outside the header is it? I think it should have a underscore, because otherwise it's confusing that CNL_PORT_TX_DW_LN0 returns an offsed and CNL_PORT_TX_DW[0-5]_LN0 return an mmio reg. And if it's used elsewhere, maybe append _OFFSET to the macro? Lucas De Marchi > > > + _CNL_PORT_TX_AE_LN0_OFFSET, \ > > + _CNL_PORT_TX_B_LN0_OFFSET, \ > > + _CNL_PORT_TX_B_LN0_OFFSET, \ > > + _CNL_PORT_TX_D_LN0_OFFSET, \ > > + _CNL_PORT_TX_AE_LN0_OFFSET, \ > > + _CNL_PORT_TX_F_LN0_OFFSET) + \ > > + 4*(dw)) > > + > > #define _CNL_PORT_TX_DW2_GRP_AE0x162348 > > #define _CNL_PORT_TX_DW2_GRP_B 0x1623C8 > > #define _CNL_PORT_TX_DW2_GRP_C 0x162B48 > > -- > > 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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v2] tests/perf_pmu: Use absolute tolerance in accuracy tests
Quoting Tvrtko Ursulin (2018-03-09 11:54:13) > From: Tvrtko Ursulin > > We need to use absolute tolerance when asserting on percentages. Relative > tolerance in this case is unfair and inaccurate since it's strictness > varies with relative target busyness. > > v2: > * Do not include spin batch edit and submit into measured time. > * Open PMU before child is in test PWM phase. > * No need to emit test PWM for twice as long with the new explicit >synchroniazation via pipe. > * Log test duration in ms for better readability. > * Drop inverse assert. (Chris Wilson) > > Signed-off-by: Tvrtko Ursulin > Cc: Chris Wilson > Reviewed-by: Chris Wilson # v1 Reviewed-by: Chris Wilson Would be nice to add a comment now we have a reasonable suspicion: > @@ -1537,19 +1545,16 @@ accuracy(int gem_fd, const struct > intel_execution_engine2 *e, > > igt_nsec_elapsed(&test_start); > do { > - struct timespec t_busy = { }; > - unsigned int target_idle_us; > - > - igt_nsec_elapsed(&t_busy); > + unsigned int target_idle_us, t_busy; > > /* Restart the spinbatch. */ > __rearm_spin_batch(spin); > __submit_spin_batch(gem_fd, &obj, e); /* * Note that the submission may be delayed to a tasklet (ksoftirqd) * which cannot run until we sleep as we hog the cpu (we are RT). */ > - measured_usleep(busy_us); > + t_busy = measured_usleep(busy_us); > igt_spin_batch_end(spin); > gem_sync(gem_fd, obj.handle); And back to thinking how we can kick the tasklet, or kick the habit. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx
Quoting Antonio Argenziano (2018-03-09 19:15:45) > > > On 08/03/18 17:03, Chris Wilson wrote: > > Quoting Antonio Argenziano (2018-03-09 00:45:42) > >> > >> > >> On 08/03/18 09:13, Chris Wilson wrote: > >>> Exercise some new API that allows applications to request that > >>> individual contexts are executed within a desired frequency range. > >>> > >>> v2: Split single/continuous set_freq subtests > >>> > >>> Signed-off-by: Chris Wilson > >>> Cc: Paneri, Praveen > >>> Cc: Kamble, Sagar A > >>> Cc: Antonio Argenziano > >>> --- > >>>tests/Makefile.am | 1 + > >>>tests/Makefile.sources | 1 + > >>>tests/gem_ctx_freq.c | 604 > >>> + > >>>tests/meson.build | 1 + > >>>4 files changed, 607 insertions(+) > >>>create mode 100644 tests/gem_ctx_freq.c > >>> > >> > > >>> + uint32_t cur, discard; > >>> + > >>> + set_freq(fd, ctx, freq, freq); > >>> + get_freq(fd, ctx, &cur, &discard); > >> > >> igt_assert_eq(freq, cur)? > > > > Not quite. The trick is that the interface is not strictly idempotent, > > since we pass in MHz, the driver converts that into freq bins and spits > > it back out to the nearest MHz. So cur is not strictly freq, it just > > happens that 50MHz is the bin size on gen9. > > > > The idea here is that we grab the adjusted freq from the driver to > > validate with. > > I see, can we enforce a tolerance? It feels like we are trusting the > kernel too much, but if that is the only thing we can do... for (i = min; i <= max; i++) igt_assert(min <= set_and_fetch_freq(i) <= max); I don't think we want to constrain the ABI any more than that. But adding that level of check seems ok. The behaviour is we ask the kernel for a range, the kernel tells us what range it can provide based on the request. Then we expect that the kernel upholds that contract. (Except where we make a conflicting contract with another party, either parallel execution or sysadmin override.) Binding ourselves into a tighter contract feels overly prescriptive and not flexible enough to weasel our way out of bad situations in future. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/cnl: Kill _MMIO_PORT6 macro
On Fri, Mar 09, 2018 at 06:28:58PM +0530, Mahesh Kumar wrote: > This patch replaces use of remaining _MMIO_PORT6 macro and removes the > macro. Thanks... I hope that we don't need to bring it back for the ICL patches... > > Signed-off-by: Mahesh Kumar Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/i915_reg.h | 12 +--- > 1 file changed, 5 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 7987a3f85d04..37742d774ba0 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -153,9 +153,6 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) > #define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c)) > #define _PLL(pll, a, b) ((a) + (pll)*((b)-(a))) > #define _MMIO_PLL(pll, a, b) _MMIO(_PLL(pll, a, b)) > -#define _MMIO_PORT6(port, a, b, c, d, e, f) _MMIO(_PICK(port, a, b, c, d, e, > f)) > -#define _MMIO_PORT6_LN(port, ln, a0, a1, b, c, d, e, f) > \ > - _MMIO(_PICK(port, a0, b, c, d, e, f) + (ln * (a1 - a0))) > #define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__) > #define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c)) > > @@ -1948,20 +1945,21 @@ enum i915_power_well_id { > #define _CNL_PORT_PCS_DW1_LN0_C 0x162C04 > #define _CNL_PORT_PCS_DW1_LN0_D 0x162E04 > #define _CNL_PORT_PCS_DW1_LN0_F 0x162804 > -#define CNL_PORT_PCS_DW1_GRP(port) _MMIO_PORT6(port, \ > +#define CNL_PORT_PCS_DW1_GRP(port) _MMIO(_PICK(port, \ > _CNL_PORT_PCS_DW1_GRP_AE, \ > _CNL_PORT_PCS_DW1_GRP_B, \ > _CNL_PORT_PCS_DW1_GRP_C, \ > _CNL_PORT_PCS_DW1_GRP_D, \ > _CNL_PORT_PCS_DW1_GRP_AE, \ > - _CNL_PORT_PCS_DW1_GRP_F) > -#define CNL_PORT_PCS_DW1_LN0(port) _MMIO_PORT6(port, \ > + _CNL_PORT_PCS_DW1_GRP_F)) > + > +#define CNL_PORT_PCS_DW1_LN0(port) _MMIO(_PICK(port, \ > _CNL_PORT_PCS_DW1_LN0_AE, \ > _CNL_PORT_PCS_DW1_LN0_B, \ > _CNL_PORT_PCS_DW1_LN0_C, \ > _CNL_PORT_PCS_DW1_LN0_D, \ > _CNL_PORT_PCS_DW1_LN0_AE, \ > - _CNL_PORT_PCS_DW1_LN0_F) > + _CNL_PORT_PCS_DW1_LN0_F)) > #define COMMON_KEEPER_EN (1 << 26) > > /* CNL Port TX registers */ > -- > 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 1/3] drm/i915/cnl; Add macro to get PORT_TX register
On Fri, Mar 09, 2018 at 06:28:56PM +0530, Mahesh Kumar wrote: > This patch creates a new macro to get PORT_TX register for any given DW. > This will remove the need of defining register address for each port & DW. please squash patches 1 and 2. I had to open both simultaneously to review it what indicates that they should be 1 patch. > > Signed-off-by: Mahesh Kumar > --- > drivers/gpu/drm/i915/i915_reg.h | 28 > 1 file changed, 28 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index e6a8c0ee7df1..30ef3513dc6f 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -1964,6 +1964,34 @@ enum i915_power_well_id { > _CNL_PORT_PCS_DW1_LN0_F) > #define COMMON_KEEPER_EN (1 << 26) > > +/* CNL Port TX registers */ > +#define _CNL_PORT_TX_AE_GRP_OFFSET 0x162340 > +#define _CNL_PORT_TX_B_GRP_OFFSET0x1623C0 > +#define _CNL_PORT_TX_C_GRP_OFFSET0x162B40 > +#define _CNL_PORT_TX_D_GRP_OFFSET0x162BC0 > +#define _CNL_PORT_TX_F_GRP_OFFSET0x162A40 > +#define _CNL_PORT_TX_AE_LN0_OFFSET 0x162440 > +#define _CNL_PORT_TX_B_LN0_OFFSET0x162640 > +#define _CNL_PORT_TX_C_LN0_OFFSET0x162C40 > +#define _CNL_PORT_TX_D_LN0_OFFSET0x162E40 > +#define _CNL_PORT_TX_F_LN0_OFFSET0x162840 > +#define CNL_PORT_TX_DW_GRP(port, dw) (_PICK((port), \ > +_CNL_PORT_TX_AE_GRP_OFFSET, \ > +_CNL_PORT_TX_B_GRP_OFFSET, \ > +_CNL_PORT_TX_B_GRP_OFFSET, \ > +_CNL_PORT_TX_D_GRP_OFFSET, \ > +_CNL_PORT_TX_AE_GRP_OFFSET, \ > +_CNL_PORT_TX_F_GRP_OFFSET) + \ > +4*(dw)) the math is right. I'm glad someone could see some logic on all these numbers. I with we had a basic offset and math for all the port registers, but... > +#define CNL_PORT_TX_DW_LN0(port, dw) (_PICK((port), \ who converts the offset to MMIO reg now? > +_CNL_PORT_TX_AE_LN0_OFFSET, \ > +_CNL_PORT_TX_B_LN0_OFFSET, \ > +_CNL_PORT_TX_B_LN0_OFFSET, \ > +_CNL_PORT_TX_D_LN0_OFFSET, \ > +_CNL_PORT_TX_AE_LN0_OFFSET, \ > +_CNL_PORT_TX_F_LN0_OFFSET) + \ > +4*(dw)) > + > #define _CNL_PORT_TX_DW2_GRP_AE 0x162348 > #define _CNL_PORT_TX_DW2_GRP_B 0x1623C8 > #define _CNL_PORT_TX_DW2_GRP_C 0x162B48 > -- > 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
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v3,1/4] drm: Add drm_any_plane_has_format()
== Series Details == Series: series starting with [v3,1/4] drm: Add drm_any_plane_has_format() URL : https://patchwork.freedesktop.org/series/39700/ State : failure == Summary == Possible new issues: Test kms_busy: Subgroup extended-pageflip-hang-oldfb-render-b: pass -> SKIP (shard-snb) Test kms_properties: Subgroup plane-properties-atomic: pass -> DMESG-WARN (shard-hsw) Test pm_rpm: Subgroup cursor: pass -> FAIL (shard-hsw) Subgroup cursor-dpms: pass -> FAIL (shard-hsw) Known issues: Test gem_eio: Subgroup in-flight-contexts: incomplete -> PASS (shard-apl) fdo#105341 +1 Test kms_flip: Subgroup plain-flip-ts-check-interruptible: fail -> PASS (shard-hsw) fdo#100368 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 shard-apltotal:3467 pass:1826 dwarn:1 dfail:0 fail:8 skip:1632 time:12225s shard-hswtotal:3467 pass:1769 dwarn:2 dfail:0 fail:3 skip:1692 time:11554s shard-snbtotal:3467 pass:1364 dwarn:1 dfail:0 fail:1 skip:2101 time:6936s Blacklisted hosts: shard-kbltotal:3467 pass:1950 dwarn:1 dfail:1 fail:7 skip:1508 time:9378s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8291/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] drm/i915: store all mmio bases in intel_engines
On 09/03/2018 18:47, Daniele Ceraolo Spurio wrote: On 09/03/18 01:53, Tvrtko Ursulin wrote: On 08/03/2018 18:46, Daniele Ceraolo Spurio wrote: On 08/03/18 01:31, Tvrtko Ursulin wrote: On 07/03/2018 19:45, Daniele Ceraolo Spurio wrote: The mmio bases we're currently storing in the intel_engines array are only valid for a subset of gens, so we need to ignore them and use different values in some cases. Instead of doing that, we can have a table of [starting gen, mmio base] pairs for each engine in intel_engines and select the correct one based on the gen we're running on in a consistent way. Cc: Mika Kuoppala Cc: Tvrtko Ursulin Signed-off-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/intel_engine_cs.c | 77 + drivers/gpu/drm/i915/intel_ringbuffer.c | 1 - 2 files changed, 49 insertions(+), 29 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index 4ba139c27fba..1dd92cac8d67 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -81,12 +81,16 @@ static const struct engine_class_info intel_engine_classes[] = { }, }; +#define MAX_MMIO_BASES 3 struct engine_info { unsigned int hw_id; unsigned int uabi_id; u8 class; u8 instance; - u32 mmio_base; + struct engine_mmio_base { + u32 gen : 8; + u32 base : 24; + } mmio_bases[MAX_MMIO_BASES]; unsigned irq_shift; }; It's not bad, but I am just wondering if it is too complicated versus simply duplicating the tables. Duplicated tables would certainly be much less code and complexity, but what about the size of pure data? In this patch sizeof(struct engine_info) grows by MAX_MMIO_BASES * sizeof(u32), so 12, to the total of 30 if I am not mistaken. Times NUM_ENGINES equals 240 bytes for intel_engines[] array with this scheme. we remove a u32 (the old mmio base) so we only grow 8 per engine, but the compiler rounds up to a multiple of u32 so 28 per engine, for a total of 224. Separate tables per gens would be: sizeof(struct engine_info) is 18 bytes. For < gen6 we'd need 3 engines * 18 = 54 < gen11 = 5 engines * 18 = 90 >= gen11 = 8 engines * 18 = 144 54 + 90 + 144 = 288 bytes So a little bit bigger. Hm. Plus we would need to refactor so intel_engines[] is not indexed by engine->id but is contiguous array with engine->id in the elements. Code to lookup the compact array should be simpler than combined new code from this patch, especially if you add the test as Chris suggested. So separate engine info arrays would win I think overall - when considering size of text + size of data + size of source code. Not sure. I would exclude the selftest, which is usually not compiled for released kernels, which leads to: Yes, but we cannot exclude its source since selftests for separate tables wouldn't be needed. add/remove: 0/0 grow/shrink: 3/1 up/down: 100/-7 (93) Function old new delta intel_engines 160 224 +64 __func__ 13891 13910 +19 intel_engines_init_mmio 1247 1264 +17 intel_init_bsd_ring_buffer 142 135 -7 Total: Before=1479626, After=1479719, chg +0.01% Total growth is 93, which is less then your estimation for the growth introduced by replicating the table. But on the other hand your solution might be more future proof. So I don't know. Use the crystal ball to decide? :) I think we should expect that the total engine count could grow with future gens. In this case to me adding a new entry to a unified table seems much cleaner (and uses less data) than adding a completely new table each time. Okay I was off in my estimates. But in general I was coming from the angle of thinking that every new mmio base difference in this scheme grows the size for all engines. So if just VCS grows one new base, impact is multiplied by NUM_ENGINES. But maybe separate tables are also not a solution. Perhaps pulling out mmio_base arrays to outside struct engine_info in another set of static tables, so they could be null terminated would be best of both worlds? struct engine_mmio_base { u32 gen : 8; u32 base : 24; }; static const struct engine_mmio_base vcs0_mmio_bases[] = { { .gen = 11, .base = GEN11_BSD_RING_BASE }, { .gen = 6, .base = GEN6_BSD_RING_BASE }, { .gen = 4, .base = BSD_RING_BASE }, { }, }; And then in intel_engines array, for BSD: { ... .mmio_bases = &vcs0_mmio_bases; ... }, This way we limit data growth only to engines which change their mmio bases frequently. Just an idea. I gave this a try and the code actually grows: add/remove: 8/0 grow/shrink: 2/0 up/down: 120/0 (120) Function old new delta intel_engines
Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx
On 08/03/18 17:03, Chris Wilson wrote: Quoting Antonio Argenziano (2018-03-09 00:45:42) On 08/03/18 09:13, Chris Wilson wrote: Exercise some new API that allows applications to request that individual contexts are executed within a desired frequency range. v2: Split single/continuous set_freq subtests Signed-off-by: Chris Wilson Cc: Paneri, Praveen Cc: Kamble, Sagar A Cc: Antonio Argenziano --- tests/Makefile.am | 1 + tests/Makefile.sources | 1 + tests/gem_ctx_freq.c | 604 + tests/meson.build | 1 + 4 files changed, 607 insertions(+) create mode 100644 tests/gem_ctx_freq.c + uint32_t cur, discard; + + set_freq(fd, ctx, freq, freq); + get_freq(fd, ctx, &cur, &discard); igt_assert_eq(freq, cur)? Not quite. The trick is that the interface is not strictly idempotent, since we pass in MHz, the driver converts that into freq bins and spits it back out to the nearest MHz. So cur is not strictly freq, it just happens that 50MHz is the bin size on gen9. The idea here is that we grab the adjusted freq from the driver to validate with. I see, can we enforce a tolerance? It feels like we are trusting the kernel too much, but if that is the only thing we can do... +static void smoketest(int fd, int timeout) +{ + unsigned int engines[16]; use a macro instead of magic number 16. #define THIS_IS_FAR_MORE_MAGIC_THAN_A_MEANINGLESS_BARE_NUMBER_THAT_YOU_SHOULD_NOT_BE_READING_ANYTHING_INTO 16 /rant We call that MAX_EGINES in gem_exec_schedule ;). Thanks, Antonio +static void invalid_param(int fd) +{ gem_ctx_param is going to be upset again pretty soon ;). Poor thing. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Trim gen11_gt_irq_handler
On 08/03/18 17:33, Chris Wilson wrote: Give the compiler a helping hand in mapping (bank,bit) to our struct intel_engine_cs by trading object code size for data cache: add/remove: 2/0 grow/shrink: 0/1 up/down: 48/-135 (-87) Function old new delta bank1_map - 32 +32 bank0_map - 16 +16 gen11_irq_handler706 571-135 v2: u8 arrays for tighter packing Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin Cc: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/i915_irq.c | 53 +++-- 1 file changed, 14 insertions(+), 39 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index c8c29d8ecbab..e423ec58e5d2 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -2762,44 +2762,6 @@ static void __fini_wedge(struct wedge_me *w) (W)->i915; \ __fini_wedge((W))) -static void -gen11_gt_engine_irq_handler(struct drm_i915_private * const i915, - const unsigned int bank, - const unsigned int engine_n, - const u16 iir) -{ - struct intel_engine_cs ** const engine = i915->engine; - - switch (bank) { - case 0: - switch (engine_n) { - - case GEN11_RCS0: - return gen8_cs_irq_handler(engine[RCS], iir); - - case GEN11_BCS: - return gen8_cs_irq_handler(engine[BCS], iir); - } - case 1: - switch (engine_n) { - - case GEN11_VCS(0): - return gen8_cs_irq_handler(engine[_VCS(0)], iir); - case GEN11_VCS(1): - return gen8_cs_irq_handler(engine[_VCS(1)], iir); - case GEN11_VCS(2): - return gen8_cs_irq_handler(engine[_VCS(2)], iir); - case GEN11_VCS(3): - return gen8_cs_irq_handler(engine[_VCS(3)], iir); - - case GEN11_VECS(0): - return gen8_cs_irq_handler(engine[_VECS(0)], iir); - case GEN11_VECS(1): - return gen8_cs_irq_handler(engine[_VECS(1)], iir); - } - } -} - static u32 gen11_gt_engine_intr(struct drm_i915_private * const i915, const unsigned int bank, const unsigned int bit) @@ -2836,10 +2798,23 @@ static void gen11_gt_irq_handler(struct drm_i915_private * const i915, const u32 master_ctl) { + static const u8 bank0_map[] = { + [GEN11_RCS0] = RCS, + [GEN11_BCS] = BCS, + }; + static const u8 bank1_map[] = { + [GEN11_VCS(0)] = _VCS(0), + [GEN11_VCS(1)] = _VCS(1), + [GEN11_VCS(2)] = _VCS(2), + [GEN11_VCS(3)] = _VCS(3), + [GEN11_VECS(0)] = _VECS(0), + [GEN11_VECS(1)] = _VECS(1), + }; void __iomem * const regs = i915->regs; unsigned int bank; for (bank = 0; bank < 2; bank++) { + const u8 *map = bank ? bank1_map : bank0_map; unsigned long intr_dw; unsigned int bit; @@ -2859,7 +2834,7 @@ gen11_gt_irq_handler(struct drm_i915_private * const i915, if (unlikely(!iir)) continue; - gen11_gt_engine_irq_handler(i915, bank, bit, iir); + gen8_cs_irq_handler(i915->engine[map[bit]], iir); With guc and PM interrupts we get a couple of non-engine interrupts on bank0, so this may not scale very well depending how we approach it. My vote still goes to deriving class and instance from the register (bits 16-18 and 20-25 respectively). If we return the full register value from gen11_gt_engine_intr, we can then do something like: for_each_set_bit(bit, &intr_dw, 32) { const u32 ident = gen11_gt_engine_intr(i915, bank, bit); u16 iir = ident & GEN11_INTR_ENGINE_MASK; u8 class, instance; if (unlikely(!iir)) continue; class = (ident >> 16) & (BIT(3) - 1); instance = (ident >> 20) & (BIT(GEN11_ENGINE_INSTANCE_WIDTH) - 1); gen8_cs_irq_handler(i915->engine_class[class][instance], iir); } Which saves a bit more code and is more adaptable to non-engine interrupts IMHO, since we have the class and all non-engine interrupts come under class 4. add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-137 (-137) Function old new delta gen11_irq_handler711 574-137 Total: Before=1487912, After=1487775, chg -0.01% Downside is that we have a few more inst
Re: [Intel-gfx] [RFC] drm/i915: store all mmio bases in intel_engines
On 09/03/18 01:53, Tvrtko Ursulin wrote: On 08/03/2018 18:46, Daniele Ceraolo Spurio wrote: On 08/03/18 01:31, Tvrtko Ursulin wrote: On 07/03/2018 19:45, Daniele Ceraolo Spurio wrote: The mmio bases we're currently storing in the intel_engines array are only valid for a subset of gens, so we need to ignore them and use different values in some cases. Instead of doing that, we can have a table of [starting gen, mmio base] pairs for each engine in intel_engines and select the correct one based on the gen we're running on in a consistent way. Cc: Mika Kuoppala Cc: Tvrtko Ursulin Signed-off-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/intel_engine_cs.c | 77 + drivers/gpu/drm/i915/intel_ringbuffer.c | 1 - 2 files changed, 49 insertions(+), 29 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index 4ba139c27fba..1dd92cac8d67 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -81,12 +81,16 @@ static const struct engine_class_info intel_engine_classes[] = { }, }; +#define MAX_MMIO_BASES 3 struct engine_info { unsigned int hw_id; unsigned int uabi_id; u8 class; u8 instance; - u32 mmio_base; + struct engine_mmio_base { + u32 gen : 8; + u32 base : 24; + } mmio_bases[MAX_MMIO_BASES]; unsigned irq_shift; }; It's not bad, but I am just wondering if it is too complicated versus simply duplicating the tables. Duplicated tables would certainly be much less code and complexity, but what about the size of pure data? In this patch sizeof(struct engine_info) grows by MAX_MMIO_BASES * sizeof(u32), so 12, to the total of 30 if I am not mistaken. Times NUM_ENGINES equals 240 bytes for intel_engines[] array with this scheme. we remove a u32 (the old mmio base) so we only grow 8 per engine, but the compiler rounds up to a multiple of u32 so 28 per engine, for a total of 224. Separate tables per gens would be: sizeof(struct engine_info) is 18 bytes. For < gen6 we'd need 3 engines * 18 = 54 < gen11 = 5 engines * 18 = 90 >= gen11 = 8 engines * 18 = 144 54 + 90 + 144 = 288 bytes So a little bit bigger. Hm. Plus we would need to refactor so intel_engines[] is not indexed by engine->id but is contiguous array with engine->id in the elements. Code to lookup the compact array should be simpler than combined new code from this patch, especially if you add the test as Chris suggested. So separate engine info arrays would win I think overall - when considering size of text + size of data + size of source code. Not sure. I would exclude the selftest, which is usually not compiled for released kernels, which leads to: Yes, but we cannot exclude its source since selftests for separate tables wouldn't be needed. add/remove: 0/0 grow/shrink: 3/1 up/down: 100/-7 (93) Function old new delta intel_engines 160 224 +64 __func__ 13891 13910 +19 intel_engines_init_mmio 1247 1264 +17 intel_init_bsd_ring_buffer 142 135 -7 Total: Before=1479626, After=1479719, chg +0.01% Total growth is 93, which is less then your estimation for the growth introduced by replicating the table. But on the other hand your solution might be more future proof. So I don't know. Use the crystal ball to decide? :) I think we should expect that the total engine count could grow with future gens. In this case to me adding a new entry to a unified table seems much cleaner (and uses less data) than adding a completely new table each time. Okay I was off in my estimates. But in general I was coming from the angle of thinking that every new mmio base difference in this scheme grows the size for all engines. So if just VCS grows one new base, impact is multiplied by NUM_ENGINES. But maybe separate tables are also not a solution. Perhaps pulling out mmio_base arrays to outside struct engine_info in another set of static tables, so they could be null terminated would be best of both worlds? struct engine_mmio_base { u32 gen : 8; u32 base : 24; }; static const struct engine_mmio_base vcs0_mmio_bases[] = { { .gen = 11, .base = GEN11_BSD_RING_BASE }, { .gen = 6, .base = GEN6_BSD_RING_BASE }, { .gen = 4, .base = BSD_RING_BASE }, { }, }; And then in intel_engines array, for BSD: { ... .mmio_bases = &vcs0_mmio_bases; ... }, This way we limit data growth only to engines which change their mmio bases frequently. Just an idea. I gave this a try and the code actually grows: add/remove: 8/0 grow/shrink: 2/0 up/down: 120/0 (120) Function old new delta intel_engines224 256 +32 vcs0_mmio_bases
[Intel-gfx] ✓ Fi.CI.BAT: success for Add Plane Color Properties (rev3)
== Series Details == Series: Add Plane Color Properties (rev3) URL : https://patchwork.freedesktop.org/series/30875/ State : success == Summary == Series 30875v3 Add Plane Color Properties https://patchwork.freedesktop.org/api/1.0/series/30875/revisions/3/mbox/ Known issues: Test kms_frontbuffer_tracking: Subgroup basic: pass -> FAIL (fi-cnl-y3) fdo#103167 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:426s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:427s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:375s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:508s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:279s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:495s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:490s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:484s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:471s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:407s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:576s fi-cnl-y3total:288 pass:261 dwarn:0 dfail:0 fail:1 skip:26 time:582s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:411s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:289s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:520s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:402s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:416s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:458s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:417s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:468s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:465s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:508s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:589s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:431s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:521s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:535s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:505s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:483s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:425s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:433s fi-snb-2520m total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:401s Blacklisted hosts: fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:506s fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:515s 2e2ef5a5221a7469ecd72c68ed15dd8b94e2e0c6 drm-tip: 2018y-03m-09d-14h-28m-10s UTC integration manifest f68e8e8bf982 drm/i915: Load plane color luts from atomic flip c78c5ef1ab64 drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms d950a92e81f3 drm/i915: Enable plane color features 2ef90e536d90 drm: Define helper function for plane color enabling 25248846877a drm: Add Plane Gamma properties a3b85657b9c9 drm: Add Plane CTM property f7fc900392ed drm: Add Plane Degamma properties 09fc571cdbfc drm: Add Enhanced Gamma LUT precision structure == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8297/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add Plane Color Properties (rev3)
== Series Details == Series: Add Plane Color Properties (rev3) URL : https://patchwork.freedesktop.org/series/30875/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm: Add Enhanced Gamma LUT precision structure +drivers/gpu/drm/drm_plane.c:433:10: warning: symbol 'drm_color_lut_extract_ext' was not declared. Should it be static? Commit: drm: Add Plane Degamma properties Okay! Commit: drm: Add Plane CTM property Okay! Commit: drm: Add Plane Gamma properties Okay! Commit: drm: Define helper function for plane color enabling Okay! Commit: drm/i915: Enable plane color features Okay! Commit: drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms Okay! Commit: drm/i915: Load plane color luts from atomic flip Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v3 8/8] drm/i915: Load plane color luts from atomic flip
Load plane color luts as part of atomic plane updates. This will be done only if the plane color luts are changed. Signed-off-by: Uma Shankar --- drivers/gpu/drm/i915/intel_atomic_plane.c | 4 drivers/gpu/drm/i915/intel_color.c| 8 drivers/gpu/drm/i915/intel_drv.h | 1 + 3 files changed, 13 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c b/drivers/gpu/drm/i915/intel_atomic_plane.c index 7481ce8..e519eab 100644 --- a/drivers/gpu/drm/i915/intel_atomic_plane.c +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c @@ -231,6 +231,10 @@ static void intel_plane_atomic_update(struct drm_plane *plane, intel_atomic_get_new_plane_state(state, intel_plane); struct drm_crtc *crtc = new_plane_state->base.crtc ?: old_state->crtc; + if (new_plane_state->base.color_mgmt_changed) { + intel_color_load_plane_luts(&new_plane_state->base); + } + if (new_plane_state->base.visible) { const struct intel_crtc_state *new_crtc_state = intel_atomic_get_new_crtc_state(state, to_intel_crtc(crtc)); diff --git a/drivers/gpu/drm/i915/intel_color.c b/drivers/gpu/drm/i915/intel_color.c index a40fafa..f67115b 100644 --- a/drivers/gpu/drm/i915/intel_color.c +++ b/drivers/gpu/drm/i915/intel_color.c @@ -670,6 +670,14 @@ void intel_color_load_luts(struct drm_crtc_state *crtc_state) dev_priv->display.load_luts(crtc_state); } +void intel_color_load_plane_luts(const struct drm_plane_state *plane_state) +{ + struct drm_device *dev = plane_state->plane->dev; + struct drm_i915_private *dev_priv = to_i915(dev); + + dev_priv->display.load_plane_luts(plane_state); +} + int intel_color_check(struct drm_crtc *crtc, struct drm_crtc_state *crtc_state) { diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 0a58fce..1da5a35 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -2132,6 +2132,7 @@ int intel_plane_atomic_check_with_state(const struct intel_crtc_state *old_crtc_ void intel_color_set_csc(struct drm_crtc_state *crtc_state); void intel_color_load_luts(struct drm_crtc_state *crtc_state); void intel_plane_color_init(struct drm_plane *plane); +void intel_color_load_plane_luts(const struct drm_plane_state *plane_state); /* intel_lspcon.c */ bool lspcon_init(struct intel_digital_port *intel_dig_port); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v3 7/8] drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms
Implement Plane Gamma feature for BDW and Gen9 platforms. v2: Used newly added drm_color_lut_ext structure for enhanced precision for Gamma LUT entries. Signed-off-by: Uma Shankar --- drivers/gpu/drm/i915/i915_pci.c | 5 +++- drivers/gpu/drm/i915/i915_reg.h | 24 +++ drivers/gpu/drm/i915/intel_color.c | 58 drivers/gpu/drm/i915/intel_display.c | 4 +++ drivers/gpu/drm/i915/intel_sprite.c | 4 +++ 5 files changed, 94 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c index 26e8f5c..c14b8f3 100644 --- a/drivers/gpu/drm/i915/i915_pci.c +++ b/drivers/gpu/drm/i915/i915_pci.c @@ -54,7 +54,10 @@ .cursor_offsets = { CURSOR_A_OFFSET, IVB_CURSOR_B_OFFSET, IVB_CURSOR_C_OFFSET } #define BDW_COLORS \ - .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 } + .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }, \ + .plane_color = { .plane_degamma_lut_size = 0, \ +.plane_gamma_lut_size = 16 } + #define CHV_COLORS \ .color = { .degamma_lut_size = 65, .gamma_lut_size = 257 } #define GLK_COLORS \ diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 258e86e..385c3fc 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -159,6 +159,9 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) #define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__) #define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c)) +#define _MMIO_PLANE_GAMC(plane, i, a, b) _MMIO(_PIPE(plane, a, b) + (i) * 4) +#define _MMIO_PLANE_GAMC16(plane, i, a, b) _MMIO(_PIPE(plane, a, b) + (i) * 4) + #define _MASKED_FIELD(mask, value) ({ \ if (__builtin_constant_p(mask))\ BUILD_BUG_ON_MSG(((mask) & 0x), "Incorrect mask"); \ @@ -9142,6 +9145,27 @@ enum skl_power_gate { #define PRE_CSC_GAMC_INDEX(pipe) _MMIO_PIPE(pipe, _PRE_CSC_GAMC_INDEX_A, _PRE_CSC_GAMC_INDEX_B) #define PRE_CSC_GAMC_DATA(pipe)_MMIO_PIPE(pipe, _PRE_CSC_GAMC_DATA_A, _PRE_CSC_GAMC_DATA_B) +/* Plane Gamma in Gen9+ */ +#define _PLANE_GAMC_1_A0x701d0 +#define _PLANE_GAMC_1_B0x711d0 +#define _PLANE_GAMC_2_A0x702d0 +#define _PLANE_GAMC_2_B0x712d0 +#define _PLANE_GAMC_1(pipe)_PIPE(pipe, _PLANE_GAMC_1_A, _PLANE_GAMC_1_B) +#define _PLANE_GAMC_2(pipe)_PIPE(pipe, _PLANE_GAMC_2_A, _PLANE_GAMC_2_B) +#define PLANE_GAMC(pipe, plane, i) \ + _MMIO_PLANE_GAMC(plane, i, _PLANE_GAMC_1(pipe), _PLANE_GAMC_2(pipe)) + +#define _PLANE_GAMC16_1_A 0x70210 +#define _PLANE_GAMC16_1_B 0x71210 +#define _PLANE_GAMC16_2_A 0x70310 +#define _PLANE_GAMC16_2_B 0x71310 +#define _PLANE_GAMC16_1(pipe) _PIPE(pipe, _PLANE_GAMC16_1_A, \ +_PLANE_GAMC16_1_B) +#define _PLANE_GAMC16_2(pipe) _PIPE(pipe, _PLANE_GAMC16_2_A, \ +_PLANE_GAMC16_2_B) +#define PLANE_GAMC16(pipe, plane, i) _MMIO_PLANE_GAMC16(plane, i, \ + _PLANE_GAMC16_1(pipe), _PLANE_GAMC16_2(pipe)) + /* pipe CSC & degamma/gamma LUTs on CHV */ #define _CGM_PIPE_A_CSC_COEFF01(VLV_DISPLAY_BASE + 0x67900) #define _CGM_PIPE_A_CSC_COEFF23(VLV_DISPLAY_BASE + 0x67904) diff --git a/drivers/gpu/drm/i915/intel_color.c b/drivers/gpu/drm/i915/intel_color.c index 2d38ab8..a40fafa 100644 --- a/drivers/gpu/drm/i915/intel_color.c +++ b/drivers/gpu/drm/i915/intel_color.c @@ -496,6 +496,59 @@ static void broadwell_load_luts(struct drm_crtc_state *state) I915_WRITE(PREC_PAL_INDEX(pipe), 0); } +static void bdw_load_plane_gamma_lut(const struct drm_plane_state *state, +u32 offset) +{ + struct drm_i915_private *dev_priv = to_i915(state->plane->dev); + enum pipe pipe = to_intel_plane(state->plane)->pipe; + enum plane_id plane = to_intel_plane(state->plane)->id; + uint32_t i, lut_size = + INTEL_INFO(dev_priv)->plane_color.plane_gamma_lut_size; + + if (state->gamma_lut) { + struct drm_color_lut_ext *lut = + (struct drm_color_lut_ext *) state->gamma_lut->data; + + for (i = 0; i < lut_size; i++) { + uint32_t word = + (drm_color_lut_extract(lut[i].red, 10) << 20) | + (drm_color_lut_extract(lut[i].green, 10) << 10) | + drm_color_lut_extract(lut[i].blue, 10); + + I915_WRITE(PLANE_GAMC(pipe, plane, i), word); + } + + /* Program the max register to clamp values > 1.0. */ + i = lut_size - 1; + I915_WRITE(PLANE_GAMC16(pipe, plane, 0), + drm_color_lut_extract(lut[i].red, 16)); + I915_WRITE(PLA
[Intel-gfx] [RFC v3 6/8] drm/i915: Enable plane color features
Enable and initialize plane color features. v2: Rebase and some cleanup v3: Updated intel_plane_color_init to call drm_plane_color_create_prop function, which will in turn create plane color properties. Signed-off-by: Uma Shankar --- drivers/gpu/drm/i915/i915_drv.h | 5 + drivers/gpu/drm/i915/intel_color.c | 14 ++ drivers/gpu/drm/i915/intel_device_info.h | 5 + drivers/gpu/drm/i915/intel_drv.h | 9 + 4 files changed, 33 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 7eec99d7..cfbb0e0 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -434,6 +434,11 @@ struct drm_i915_display_funcs { void (*load_csc_matrix)(struct drm_crtc_state *crtc_state); void (*load_luts)(struct drm_crtc_state *crtc_state); + /* Add Plane Color callbacks */ + void (*load_plane_csc_matrix)(const struct drm_plane_state + *plane_state); + void (*load_plane_luts)(const struct drm_plane_state + *plane_state); }; #define CSR_VERSION(major, minor) ((major) << 16 | (minor)) diff --git a/drivers/gpu/drm/i915/intel_color.c b/drivers/gpu/drm/i915/intel_color.c index 89ab0f7..2d38ab8 100644 --- a/drivers/gpu/drm/i915/intel_color.c +++ b/drivers/gpu/drm/i915/intel_color.c @@ -648,6 +648,20 @@ int intel_color_check(struct drm_crtc *crtc, return -EINVAL; } +void intel_plane_color_init(struct drm_plane *plane) +{ + struct drm_i915_private *dev_priv = to_i915(plane->dev); + + drm_plane_color_create_prop(plane->dev, plane); + + /* Enable color management support when we have degamma & gamma LUTs. */ + if (INTEL_INFO(dev_priv)->plane_color.plane_degamma_lut_size != 0 && + INTEL_INFO(dev_priv)->plane_color.plane_gamma_lut_size != 0) + drm_plane_enable_color_mgmt(plane, + INTEL_INFO(dev_priv)->plane_color.plane_degamma_lut_size, + true, INTEL_INFO(dev_priv)->plane_color.plane_gamma_lut_size); +} + void intel_color_init(struct drm_crtc *crtc) { struct drm_i915_private *dev_priv = to_i915(crtc->dev); diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h index ab5bfd3..d277926 100644 --- a/drivers/gpu/drm/i915/intel_device_info.h +++ b/drivers/gpu/drm/i915/intel_device_info.h @@ -167,6 +167,11 @@ struct intel_device_info { u16 degamma_lut_size; u16 gamma_lut_size; } color; + + struct plane_color_luts { + u16 plane_degamma_lut_size; + u16 plane_gamma_lut_size; + } plane_color; }; struct intel_driver_caps { diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 1a7c5ad..0a58fce 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -529,6 +529,14 @@ struct intel_plane_state { */ int scaler_id; + /* +* Use reduced/limited/broadcast rbg range, compressing from the full +* range fed into the crtcs. +*/ + bool limited_color_range; + /* Gamma mode programmed on the plane */ + uint32_t gamma_mode; + struct drm_intel_sprite_colorkey ckey; }; @@ -2123,6 +2131,7 @@ int intel_plane_atomic_check_with_state(const struct intel_crtc_state *old_crtc_ int intel_color_check(struct drm_crtc *crtc, struct drm_crtc_state *state); void intel_color_set_csc(struct drm_crtc_state *crtc_state); void intel_color_load_luts(struct drm_crtc_state *crtc_state); +void intel_plane_color_init(struct drm_plane *plane); /* intel_lspcon.c */ bool lspcon_init(struct intel_digital_port *intel_dig_port); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v3 3/8] drm: Add Plane CTM property
Add a blob property for plane CSC usage. v2: Rebase v3: Fixed Sean, Paul's review comments. Moved the property from mode_config to drm_plane. Created a helper function to instantiate these properties and removed from drm_mode_create_standard_properties Added property documentation as suggested by Daniel, Vetter. Signed-off-by: Uma Shankar --- Documentation/gpu/drm-kms.rst | 3 +++ drivers/gpu/drm/drm_atomic.c| 10 ++ drivers/gpu/drm/drm_atomic_helper.c | 3 +++ drivers/gpu/drm/drm_plane.c | 12 include/drm/drm_plane.h | 16 5 files changed, 44 insertions(+) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 2c943f6..69b0b56 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -541,6 +541,9 @@ Plane Color Management Properties .. kernel-doc:: drivers/gpu/drm/drm_plane.c :doc: degamma_lut_size_property +.. kernel-doc:: drivers/gpu/drm/drm_plane.c + :doc: ctm_property + Tile Group Property --- diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 409c058..f86384fa 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -771,6 +771,14 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane, val, -1, &replaced); state->color_mgmt_changed |= replaced; return ret; + } else if (property == plane->ctm_property) { + ret = drm_atomic_replace_property_blob_from_id(dev, + &state->ctm, + val, + sizeof(struct drm_color_ctm), + &replaced); + state->color_mgmt_changed |= replaced; + return ret; } else if (plane->funcs->atomic_set_property) { return plane->funcs->atomic_set_property(plane, state, property, val); @@ -837,6 +845,8 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane, } else if (property == plane->degamma_lut_property) { *val = (state->degamma_lut) ? state->degamma_lut->base.id : 0; + } else if (property == plane->ctm_property) { + *val = (state->ctm) ? state->ctm->base.id : 0; } else if (plane->funcs->atomic_get_property) { return plane->funcs->atomic_get_property(plane, state, property, val); } else { diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index d9384fd..76b4b41 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -3507,6 +3507,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane, if (state->degamma_lut) drm_property_reference_blob(state->degamma_lut); + if (state->ctm) + drm_property_reference_blob(state->ctm); state->color_mgmt_changed = false; } EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state); @@ -3554,6 +3556,7 @@ void __drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state) drm_crtc_commit_put(state->commit); drm_property_unreference_blob(state->degamma_lut); + drm_property_unreference_blob(state->ctm); } EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state); diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index 543a693..e635b63 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -485,6 +485,11 @@ int drm_mode_plane_set_obj_prop(struct drm_plane *plane, * * degamma_lut_size_property: * Range Property to indicate size of the plane degamma LUT. + * + * ctm_property: + * Blob property which allows a userspace to provide CTM coefficients + * to do color space conversion or any other enhancement by doing a + * matrix multiplication using the h/w CTM processing engine */ int drm_plane_color_create_prop(struct drm_device *dev, struct drm_plane *plane) @@ -505,6 +510,13 @@ int drm_plane_color_create_prop(struct drm_device *dev, return -ENOMEM; plane->degamma_lut_size_property = prop; + prop = drm_property_create(dev, + DRM_MODE_PROP_BLOB, + "PLANE_CTM", 0); + if (!prop) + return -ENOMEM; + plane->ctm_property = prop; + return 0; } EXPORT_SYMBOL(drm_plane_color_create_prop); diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h index 03291b1..35535c5 100644 --- a/include/drm/drm_plane.h +++ b/include/drm/drm_plane.h @@ -147,6 +147,14 @@ struct drm_plane_state { struct drm_property_blob *degamma_lut; /** +* @ctm: +* +* Color transformation matrix. See drm_plane
[Intel-gfx] [RFC v3 5/8] drm: Define helper function for plane color enabling
Define helper function to enable Plane color features to attach plane color properties to plane structure. v2: Rebase v3: Modiefied the function to use updated property names. Signed-off-by: Uma Shankar --- drivers/gpu/drm/drm_plane.c | 42 ++ include/drm/drm_color_mgmt.h | 5 + 2 files changed, 47 insertions(+) diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index b837020..bbf55c5 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -144,6 +144,48 @@ static int create_in_format_blob(struct drm_device *dev, struct drm_plane *plane } /** + * drm_plane_enable_color_mgmt - enable color management properties + * @plane: DRM Plane + * @plane_degamma_lut_size: the size of the degamma lut (before CSC) + * @plane_has_ctm: whether to attach ctm_property for CSC matrix + * @plane_gamma_lut_size: the size of the gamma lut (after CSC) + * + * This function lets the driver enable the color correction + * properties on a plane. This includes 3 degamma, csc and gamma + * properties that userspace can set and 2 size properties to inform + * the userspace of the lut sizes. Each of the properties are + * optional. The gamma and degamma properties are only attached if + * their size is not 0 and ctm_property is only attached if has_ctm is + * true. + */ +void drm_plane_enable_color_mgmt(struct drm_plane *plane, + uint plane_degamma_lut_size, + bool plane_has_ctm, + uint plane_gamma_lut_size) +{ + if (plane_degamma_lut_size) { + drm_object_attach_property(&plane->base, + plane->degamma_lut_property, 0); + drm_object_attach_property(&plane->base, + plane->degamma_lut_size_property, + plane_degamma_lut_size); + } + + if (plane_has_ctm) + drm_object_attach_property(&plane->base, + plane->ctm_property, 0); + + if (plane_gamma_lut_size) { + drm_object_attach_property(&plane->base, + plane->gamma_lut_property, 0); + drm_object_attach_property(&plane->base, + plane->gamma_lut_size_property, + plane_gamma_lut_size); + } +} +EXPORT_SYMBOL(drm_plane_enable_color_mgmt); + +/** * drm_universal_plane_init - Initialize a new universal plane object * @dev: DRM device * @plane: plane object to init diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h index b3b6d30..e220019 100644 --- a/include/drm/drm_color_mgmt.h +++ b/include/drm/drm_color_mgmt.h @@ -56,4 +56,9 @@ int drm_plane_create_color_properties(struct drm_plane *plane, u32 supported_ranges, enum drm_color_encoding default_encoding, enum drm_color_range default_range); + +void drm_plane_enable_color_mgmt(struct drm_plane *plane, +uint plane_degamma_lut_size, +bool plane_has_ctm, +uint plane_gamma_lut_size); #endif -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v3 4/8] drm: Add Plane Gamma properties
Add plane gamma as blob property and size as a range property. v2: Rebase v3: Fixed Sean, Paul's review comments. Moved the property from mode_config to drm_plane. Created a helper function to instantiate these properties and removed from drm_mode_create_standard_properties Added property documentation as suggested by Daniel, Vetter. Signed-off-by: Uma Shankar --- Documentation/gpu/drm-kms.rst | 6 ++ drivers/gpu/drm/drm_atomic.c| 8 drivers/gpu/drm/drm_atomic_helper.c | 3 +++ drivers/gpu/drm/drm_plane.c | 23 +++ include/drm/drm_plane.h | 24 5 files changed, 64 insertions(+) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 69b0b56..3561deb 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -544,6 +544,12 @@ Plane Color Management Properties .. kernel-doc:: drivers/gpu/drm/drm_plane.c :doc: ctm_property +.. kernel-doc:: drivers/gpu/drm/drm_plane.c + :doc: gamma_lut_property + +.. kernel-doc:: drivers/gpu/drm/drm_plane.c + :doc: gamma_lut_size_property + Tile Group Property --- diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index f86384fa..d636a81 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -779,6 +779,12 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane, &replaced); state->color_mgmt_changed |= replaced; return ret; + } else if (property == plane->gamma_lut_property) { + ret = drm_atomic_replace_property_blob_from_id(dev, + &state->gamma_lut, + val, -1, &replaced); + state->color_mgmt_changed |= replaced; + return ret; } else if (plane->funcs->atomic_set_property) { return plane->funcs->atomic_set_property(plane, state, property, val); @@ -847,6 +853,8 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane, state->degamma_lut->base.id : 0; } else if (property == plane->ctm_property) { *val = (state->ctm) ? state->ctm->base.id : 0; + } else if (property == plane->gamma_lut_property) { + *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0; } else if (plane->funcs->atomic_get_property) { return plane->funcs->atomic_get_property(plane, state, property, val); } else { diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 76b4b41..3337e04 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -3509,6 +3509,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane, drm_property_reference_blob(state->degamma_lut); if (state->ctm) drm_property_reference_blob(state->ctm); + if (state->gamma_lut) + drm_property_reference_blob(state->gamma_lut); state->color_mgmt_changed = false; } EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state); @@ -3557,6 +3559,7 @@ void __drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state) drm_property_unreference_blob(state->degamma_lut); drm_property_unreference_blob(state->ctm); + drm_property_unreference_blob(state->gamma_lut); } EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state); diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index e635b63..b837020 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -490,6 +490,15 @@ int drm_mode_plane_set_obj_prop(struct drm_plane *plane, * Blob property which allows a userspace to provide CTM coefficients * to do color space conversion or any other enhancement by doing a * matrix multiplication using the h/w CTM processing engine + * + * gamma_lut_property: + * Blob property which allows a userspace to provide LUT values + * to apply gamma/tone-mapping curve using the h/w plane gamma + * processing engine, thereby making the content as non-linear + * or to perform any tone mapping operation for HDR usecases. + * + * gamma_lut_size_property: + * Range Property to indicate size of the plane gamma LUT. */ int drm_plane_color_create_prop(struct drm_device *dev, struct drm_plane *plane) @@ -517,6 +526,20 @@ int drm_plane_color_create_prop(struct drm_device *dev, return -ENOMEM; plane->ctm_property = prop; + prop = drm_property_create(dev, + DRM_MODE_PROP_BLOB, + "PLANE_GAMMA_LUT", 0); + if (!prop) + return -ENOMEM; + plane->gamma_lut_property = prop; + + prop = drm_property_c
[Intel-gfx] [RFC v3 2/8] drm: Add Plane Degamma properties
Add Plane Degamma as a blob property and plane degamma size as a range property. v2: Rebase v3: Fixed Sean, Paul's review comments. Moved the property from mode_config to drm_plane. Created a helper function to instantiate these properties and removed from drm_mode_create_standard_properties Added property documentation as suggested by Daniel, Vetter. Signed-off-by: Uma Shankar --- Documentation/gpu/drm-kms.rst | 9 + drivers/gpu/drm/drm_atomic.c| 12 drivers/gpu/drm/drm_atomic_helper.c | 6 ++ drivers/gpu/drm/drm_plane.c | 35 +++ include/drm/drm_plane.h | 26 ++ 5 files changed, 88 insertions(+) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 56a3780..2c943f6 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -532,6 +532,15 @@ Color Management Properties .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c :export: +Plane Color Management Properties +--- + +.. kernel-doc:: drivers/gpu/drm/drm_plane.c + :doc: degamma_lut_property + +.. kernel-doc:: drivers/gpu/drm/drm_plane.c + :doc: degamma_lut_size_property + Tile Group Property --- diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 34b7d42..409c058 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -717,6 +717,8 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane, { struct drm_device *dev = plane->dev; struct drm_mode_config *config = &dev->mode_config; + bool replaced = false; + int ret; if (property == config->prop_fb_id) { struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL, val); @@ -763,6 +765,12 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane, state->color_encoding = val; } else if (property == plane->color_range_property) { state->color_range = val; + } else if (property == plane->degamma_lut_property) { + ret = drm_atomic_replace_property_blob_from_id(dev, + &state->degamma_lut, + val, -1, &replaced); + state->color_mgmt_changed |= replaced; + return ret; } else if (plane->funcs->atomic_set_property) { return plane->funcs->atomic_set_property(plane, state, property, val); @@ -826,6 +834,9 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane, *val = state->color_encoding; } else if (property == plane->color_range_property) { *val = state->color_range; + } else if (property == plane->degamma_lut_property) { + *val = (state->degamma_lut) ? + state->degamma_lut->base.id : 0; } else if (plane->funcs->atomic_get_property) { return plane->funcs->atomic_get_property(plane, state, property, val); } else { @@ -958,6 +969,7 @@ static void drm_atomic_plane_print_state(struct drm_printer *p, drm_get_color_encoding_name(state->color_encoding)); drm_printf(p, "\tcolor-range=%s\n", drm_get_color_range_name(state->color_range)); + drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed); if (plane->funcs->atomic_print_state) plane->funcs->atomic_print_state(p, state); diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index ae3cbfe..d9384fd 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -3504,6 +3504,10 @@ void __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane, state->fence = NULL; state->commit = NULL; + + if (state->degamma_lut) + drm_property_reference_blob(state->degamma_lut); + state->color_mgmt_changed = false; } EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state); @@ -3548,6 +3552,8 @@ void __drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state) if (state->commit) drm_crtc_commit_put(state->commit); + + drm_property_unreference_blob(state->degamma_lut); } EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state); diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index e706da6..543a693 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -474,6 +474,41 @@ int drm_mode_plane_set_obj_prop(struct drm_plane *plane, } EXPORT_SYMBOL(drm_mode_plane_set_obj_prop); +/** + * DOC: degamma_lut_property + * + * degamma_lut_property: + * Blob property which allows a userspace to provide LUT values + * to apply degamma curve using the h/w plane degamma processing + * engine, thereby m
[Intel-gfx] [RFC v3 0/8] Add Plane Color Properties
This patch series adds properties for plane color features. It adds properties for degamma used to linearize data, CSC used for gamut conversion, and gamma used to again non-linearize data as per panel supported color space. These can be utilize by user space to convert planes from one format to another, one color space to another etc. Usersapce can take smart blending decisions and utilize these hardware supported plane color features to get accurate color profile. The same can help in consistent color quality from source to panel taking advantage of advanced color features in hardware. These patches just add the property interfaces and enable helper functions. This series adds Intel Gen9 specific plane gamma feature. We can build up and add other platform/hardware specific implementation on top of this series Note: This is just to get a design feedback whether these interfaces look ok. Based on community feedback on interfaces, we will implement IGT tests to validate plane color features. This is un-tested currently. Also, userspace implementation to use these properties is currently not available. v2: Dropped legacy gamma table for plane as suggested by Maarten. Added Gen9/BDW plane gamma feature and rebase on tot. v3: Added a new drm_color_lut_ext structure to accommodate 32 bit precision entries, pointed to by Brian, Starkey for HDR usecases. Addressed Sean,Paul comments and moved plane color properties to drm_plane instead of mode_config. Added property documentation as suggested by Daniel, Vetter. Fixed a rebase fumble which occurred in v2, pointed by Emil Velikov. Uma Shankar (8): drm: Add Enhanced Gamma LUT precision structure drm: Add Plane Degamma properties drm: Add Plane CTM property drm: Add Plane Gamma properties drm: Define helper function for plane color enabling drm/i915: Enable plane color features drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms drm/i915: Load plane color luts from atomic flip Documentation/gpu/drm-kms.rst | 18 drivers/gpu/drm/drm_atomic.c | 30 +++ drivers/gpu/drm/drm_atomic_helper.c | 12 +++ drivers/gpu/drm/drm_plane.c | 131 ++ drivers/gpu/drm/i915/i915_drv.h | 5 ++ drivers/gpu/drm/i915/i915_pci.c | 5 +- drivers/gpu/drm/i915/i915_reg.h | 24 ++ drivers/gpu/drm/i915/intel_atomic_plane.c | 4 + drivers/gpu/drm/i915/intel_color.c| 80 ++ drivers/gpu/drm/i915/intel_device_info.h | 5 ++ drivers/gpu/drm/i915/intel_display.c | 4 + drivers/gpu/drm/i915/intel_drv.h | 10 +++ drivers/gpu/drm/i915/intel_sprite.c | 4 + include/drm/drm_color_mgmt.h | 5 ++ include/drm/drm_plane.h | 66 +++ include/uapi/drm/drm_mode.h | 15 16 files changed, 417 insertions(+), 1 deletion(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v3 1/8] drm: Add Enhanced Gamma LUT precision structure
Existing LUT precision structure is having only 16 bit precision. This is not enough for upcoming enhanced hardwares and advance usecases like HDR processing. Hence added a new structure with 32 bit precision values. Also added the code, for extracting the same from values passed from userspace. Signed-off-by: Uma Shankar --- drivers/gpu/drm/drm_plane.c | 19 +++ include/uapi/drm/drm_mode.h | 15 +++ 2 files changed, 34 insertions(+) diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index a5d1fc7..e706da6 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -426,6 +426,25 @@ void drm_plane_force_disable(struct drm_plane *plane) } EXPORT_SYMBOL(drm_plane_force_disable); +/* + * Added to accommodate enhanced LUT precision. + * Max LUT precision is 32 bits. + */ +uint32_t drm_color_lut_extract_ext(uint32_t user_input, uint32_t bit_precision) +{ + uint32_t val = user_input; + uint32_t max = 0x >> (32 - bit_precision); + + /* Round only if we're not using full precision. */ + if (bit_precision < 32) { + val += 1UL << (32 - bit_precision - 1); + val >>= 32 - bit_precision; + } + + return clamp_val(val, 0, max); +} +EXPORT_SYMBOL(drm_color_lut_extract_ext); + /** * drm_mode_plane_set_obj_prop - set the value of a property * @plane: drm plane object to set property value for diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index b5d7d9e..5f3ed88 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -615,6 +615,21 @@ struct drm_color_lut { __u16 reserved; }; +/* + * Creating 32 bit palette entries for better data + * precision. This will be required for HDR and + * similar color processing usecases. + */ +struct drm_color_lut_ext { + /* +* Data is U0.32 fixed point format. +*/ + __u32 red; + __u32 green; + __u32 blue; + __u32 reserved; +}; + #define DRM_MODE_PAGE_FLIP_EVENT 0x01 #define DRM_MODE_PAGE_FLIP_ASYNC 0x02 #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4 -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next
Hi Dave, Here are the -misc-next pulls for the last 2 weeks. Sorry for the hold-up last week. drm-misc-next-2018-03-09-3: drm-misc-next for 4.17: UAPI Changes: plane: Add color encoding/range properties (Jyri) nouveau: Replace iturbt_709 property with color_encoding property (Ville) Core Changes: atomic: Move plane clipping into plane check helper (Ville) property: Multiple new property checks/verification (Ville) Driver Changes: rockchip: Fixes & improvements for rk3399/chromebook plus (various) sun4i: Add H3/H5 HDMI support (Jernej) i915: Add support for limited/full-range ycbcr toggling (Ville) pl111: Add bandwidth checking/limiting (Linus) Cc: Jernej Skrabec Cc: Jyri Sarha Cc: Ville Syrjälä Cc: Linus Walleij Cheers, Sean The following changes since commit 2b91e3c43b4f3d3cd4d84a31cfbe6b165d89b70e: drm/omapdrm: Use of_find_backlight helper (2018-02-20 11:07:22 -0500) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-03-09-3 for you to fetch changes up to 60beeccc72cabefcb8874fec542b3142e262b6c2: drm/rockchip: Don't use atomic constructs for psr (2018-03-08 23:28:53 +0100) drm-misc-next for 4.17: UAPI Changes: plane: Add color encoding/range properties (Jyri) nouveau: Replace iturbt_709 property with color_encoding property (Ville) Core Changes: atomic: Move plane clipping into plane check helper (Ville) property: Multiple new property checks/verification (Ville) Driver Changes: rockchip: Fixes & improvements for rk3399/chromebook plus (various) sun4i: Add H3/H5 HDMI support (Jernej) i915: Add support for limited/full-range ycbcr toggling (Ville) pl111: Add bandwidth checking/limiting (Linus) Cc: Jernej Skrabec Cc: Jyri Sarha Cc: Ville Syrjälä Cc: Linus Walleij Arnd Bergmann (2): drm: fix drm_get_max_iomem type mismatch tinydrm: add backlight dependency Baruch Siach (1): drm: of: simplify component probe code Benjamin Gaignard (1): drm/stm: check pitch and size calculations even if !CONFIG_MMU Chris Wilson (1): drm/mm: Fix caching of leftmost node in the interval tree Christian König (2): drm/prime: fix potential race in drm_gem_map_detach drm/prime: make the pages array optional for drm_prime_sg_to_page_addr_arrays Daniel Stone (1): drm/vc4: Advertise supported modifiers for planes Jeffy Chen (10): drm/rockchip: Add device links for master and components drm/rockchip: vop: Init vskiplines in scl_vop_cal_scale() drm/bridge: analogix: Do not use device's drvdata drm/bridge: analogix_dp: Fix connector and encoder cleanup drm/rockchip: analogix_dp: Add a sanity check for rockchip_drm_psr_register() drm/rockchip: analogix_dp: reorder psr_unregister call in unbind drm/rockchip: dw-mipi-dsi: Fix connector and encoder cleanup. drm/rockchip: inno_hdmi: Fix error handling path. drm/rockchip: inno_hdmi: reorder clk_disable_unprepare call in unbind drm/rockchip: dw_hdmi: Move HDMI vpll clock enable to bind() Jernej Skrabec (8): dt-bindings: display: sun4i-drm: Add compatibles for H3 HDMI pipeline drm/sun4i: Add support for H3 display engine drm/sun4i: Add support for H3 mixer 0 drm/sun4i: Fix polarity configuration for DW HDMI PHY drm/sun4i: Add support for variants to DW HDMI PHY drm/sun4i: Move and expand DW HDMI PHY register macros drm/sun4i: Add support for H3 HDMI PHY variant drm/sun4i: Allow building on arm64 Joe Moriarty (2): drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem Jyri Sarha (1): drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane Linus Walleij (7): drm/panel: Fix ARM Versatile panel clocks bridge: Elaborate a bit on dumb VGA bridges in Kconfig drm: simple_kms_helper: Fix .mode_valid() documentation drm/pl111: Make the default BPP a per-variant variable drm/pl111: Handle the RealView variant separately drm/bridge: sii902x: Retry status read after DDI I2C drm/pl111: Use max memory bandwidth for resolution Maarten Lankhorst (1): drm/atomic: Call ww_acquire_done after drm_modeset_lock_all Marek Szyprowski (2): drm/bridge: analogix_dp: Postpone enabling runtime power management drm/bridge: analogix_dp: Don't create useless connectors Maxime Ripard (4): drm/sun4i: backend: Assign the pipes automatically drm/sun4i: Remove the plane description structure drm/sun4i: backend: Make zpos configurable drm/sun4i: backend: Remove ARGB spoofing Neil Armstrong (1): drm: bridge: dw-hdmi: Fix overflow workaround for Amlogic Meson GX SoCs Oleksandr Andrushchenko (5): drm/simple_kms_helper: Fix NU
[Intel-gfx] ✓ Fi.CI.BAT: success for Add NV12 support
== Series Details == Series: Add NV12 support URL : https://patchwork.freedesktop.org/series/39670/ State : success == Summary == Series 39670v1 Add NV12 support https://patchwork.freedesktop.org/api/1.0/series/39670/revisions/1/mbox/ Known issues: Test debugfs_test: Subgroup read_all_entries: incomplete -> PASS (fi-snb-2520m) fdo#103713 +1 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:426s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:422s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:370s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:496s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:278s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:487s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:488s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:477s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:467s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:405s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:573s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:577s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:408s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:286s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:519s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:396s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:412s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:457s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:424s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:472s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:462s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:508s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:588s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:430s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:522s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:532s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:499s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:489s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:422s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:427s fi-snb-2520m total:245 pass:211 dwarn:0 dfail:0 fail:0 skip:33 fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:390s Blacklisted hosts: fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:503s fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:520s 2e2ef5a5221a7469ecd72c68ed15dd8b94e2e0c6 drm-tip: 2018y-03m-09d-14h-28m-10s UTC integration manifest 749e844cfff1 drm/i915: Display WA 827 e6555c173591 drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg 8ca8611bf6b0 drm/i915: Add NV12 support to intel_framebuffer_init 7531f149aa78 drm/i915: Add NV12 as supported format for sprite plane 0534f14fde9e drm/i915: Add NV12 as supported format for primary plane 614617ba6b50 drm/i915: Upscale scaler max scale for NV12 5f5596d38394 drm/i915: Update format_is_yuv() to include NV12 3ff123d5f468 drm/i915: Set scaler mode for NV12 42e536b29b4c drm/i915/skl: split skl_compute_ddb function 593a17e31721 drm/i915/skl+: nv12 workaround disable WM level 1-7 e007283a4b5a drm/i915/skl+: make sure higher latency level has higher wm value 02129257ecd5 drm/i915/skl+: pass skl_wm_level struct to wm compute func 7cd21a2a8f90 drm/i915/skl+: NV12 related changes for WM 883e1369e215 drm/i915/skl+: support verification of DDB HW state for NV12 0992f20891ee drm/i915/skl+: add NV12 in skl_format_to_fourcc 5453c9d856f6 drm/i915/skl+: refactor WM calculation for NV12 48faccbb411f drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8296/issues.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 [CI,1/4] drm/i915/guc: Tidy guc_log_control
== Series Details == Series: series starting with [CI,1/4] drm/i915/guc: Tidy guc_log_control URL : https://patchwork.freedesktop.org/series/39710/ State : success == Summary == Series 39710v1 series starting with [CI,1/4] drm/i915/guc: Tidy guc_log_control https://patchwork.freedesktop.org/api/1.0/series/39710/revisions/1/mbox/ Known issues: Test debugfs_test: Subgroup read_all_entries: incomplete -> PASS (fi-snb-2520m) fdo#103713 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: pass -> DMESG-WARN (fi-cnl-y3) fdo#104951 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:421s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:425s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:370s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:501s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:277s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:490s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:493s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:482s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:468s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:403s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:581s fi-cnl-y3total:288 pass:261 dwarn:1 dfail:0 fail:0 skip:26 time:585s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:409s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:290s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:517s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:397s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:414s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:454s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:417s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:466s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:460s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:510s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:582s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:430s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:521s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:534s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:496s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:483s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:422s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:428s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:519s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:391s Blacklisted hosts: fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:508s fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:512s 2e2ef5a5221a7469ecd72c68ed15dd8b94e2e0c6 drm-tip: 2018y-03m-09d-14h-28m-10s UTC integration manifest 59dcd0fe0c8f HAX: Enable GuC for CI d4bc41a8a9d6 drm/i915/guc: Move GuC notification handling to separate function 9ab68c44f5e7 drm/i915/guc: Create common entry points for log register/unregister e0ff1976b21c drm/i915/guc: Tidy guc_log_control == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8295/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove the impedance mismatch around intel_engine_enable_signaling
Quoting Tvrtko Ursulin (2018-03-09 17:24:33) > > On 08/03/2018 14:07, Chris Wilson wrote: > > There is some redundancy between dma_fence->ops->enable_signaling (via > > i915_fence_enable_signaling) and our backend, > > intel_engine_enable_signaling() in that both levels recheck the fence > > status multiple times. If we convert intel_engine_enable_signaling() to > > return the information desired by dma_fence->ops->enable_signaling, we > > can reduce i915_fence_enable_signaling to a simple stub and avoid > > trying to reinterpret the same information. > > > > Signed-off-by: Chris Wilson > > Cc: Tvrtko Ursulin > > Cc: Mika Kuoppala > > Cc: Michal Winiarski > > --- > > drivers/gpu/drm/i915/i915_request.c | 6 +- > > drivers/gpu/drm/i915/intel_breadcrumbs.c | 21 + > > drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +- > > 3 files changed, 15 insertions(+), 14 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_request.c > > b/drivers/gpu/drm/i915/i915_request.c > > index d437beac3969..2a841800d4cf 100644 > > --- a/drivers/gpu/drm/i915/i915_request.c > > +++ b/drivers/gpu/drm/i915/i915_request.c > > @@ -59,11 +59,7 @@ static bool i915_fence_signaled(struct dma_fence *fence) > > > > static bool i915_fence_enable_signaling(struct dma_fence *fence) > > { > > - if (i915_fence_signaled(fence)) > > - return false; > > This was based on hws seqno check... > > > - > > - intel_engine_enable_signaling(to_request(fence), true); > > - return !i915_fence_signaled(fence); > > + return intel_engine_enable_signaling(to_request(fence), true); > > } > > @@ -768,11 +769,15 @@ void intel_engine_enable_signaling(struct > > i915_request *request, bool wakeup) > >*/ > > spin_lock(&b->rb_lock); > > insert_signal(b, request, seqno); > > - wakeup &= __intel_engine_add_wait(engine, &request->signaling.wait); > > + wakeup &= __intel_engine_add_wait(engine, wait); > > spin_unlock(&b->rb_lock); > > > > - if (wakeup) > > + if (wakeup) { > > wake_up_process(b->signaler); > > + return !intel_wait_complete(wait); > > ... and would now be based on breadcrumb waiter waking up and removing > itself from the tree. And don't forget the same HWS check before the waiter is inserted. So we have the same guards as before, just inside yet another spinlock. > So some potential latency where it wasn't before, well, enable-disable > signalling cycles actually. The extra steps would be the insert_signal(). Fwiw, we could reorder the insert_signal() but frankly this, dma_fence enable signaling of an inflight request, is not a fast path. More commonly we will be enabling signaling on the request as it is submitted (where wakeup is false and we know that the HWS cannot be complete). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for CNL port refactoring (rev2)
== Series Details == Series: CNL port refactoring (rev2) URL : https://patchwork.freedesktop.org/series/38334/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight-external: pass -> INCOMPLETE (shard-apl) fdo#105341 Test kms_cursor_crc: Subgroup cursor-256x256-suspend: incomplete -> PASS (shard-hsw) fdo#103375 Test kms_frontbuffer_tracking: Subgroup fbc-suspend: pass -> FAIL (shard-apl) fdo#101623 Test kms_setmode: Subgroup basic: fail -> PASS (shard-hsw) fdo#99912 Test kms_vblank: Subgroup pipe-a-ts-continuation-dpms-suspend: incomplete -> PASS (shard-hsw) fdo#103540 Test perf: Subgroup blocking: pass -> FAIL (shard-hsw) fdo#102252 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-apltotal:3381 pass:1778 dwarn:1 dfail:0 fail:9 skip:1591 time:11749s shard-hswtotal:3467 pass:1773 dwarn:1 dfail:0 fail:1 skip:1691 time:11736s shard-snbtotal:3467 pass:1363 dwarn:1 dfail:0 fail:2 skip:2101 time:6959s Blacklisted hosts: shard-kbltotal:3390 pass:1905 dwarn:1 dfail:0 fail:9 skip:1473 time:8543s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8290/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx
Quoting Tvrtko Ursulin (2018-03-09 17:06:45) > > On 09/03/2018 13:46, Chris Wilson wrote: > > Exercise some new API that allows applications to request that > > individual contexts are executed within a desired frequency range. > > > > v2: Split single/continuous set_freq subtests > > v3: Do an up/down ramp for individual freq request, check nothing > > changes after each invalid request > > > > Signed-off-by: Chris Wilson > > Cc: Paneri, Praveen > > Cc: Kamble, Sagar A > > Cc: Antonio Argenziano > > --- > > tests/Makefile.am | 1 + > > tests/Makefile.sources | 1 + > > tests/gem_ctx_freq.c | 648 > > + > > tests/meson.build | 1 + > > 4 files changed, 651 insertions(+) > > create mode 100644 tests/gem_ctx_freq.c > > > > [snip] > > > +static void check_invalid(int fd, uint32_t ctx, uint32_t min, uint32_t max) > > +{ > > + const struct test { > > + uint32_t min, max; > > + } tests[] = { > > + { min - 50, max - 50 }, > > + { min - 50, max }, > > + { min - 50, max + 50 }, > > + { min, max + 50 }, > > + { min + 50, max + 50 }, > > + > > + { min - 50, min - 50 }, > > + > > + { min - 50, min }, > > + { min + 50, min }, > > + { min, min - 50 }, > > + > > + { max + 50, max }, > > + { max, max + 50 }, > > + { max, max - 50 }, > > + > > + { max + 50, max + 50 }, > > Is unprivileged "{ max, max }" allowed? In other words pin to max > frequency by anyone? If so, what happens when all userspace learns about > this and wants to use it just so to be lower latency than the other guy? I've gone with allow, since (a) it's always constrained by the global user imposed limit and (b) userspace can already keep the gpu at max frequency by load. At the start I opined that only CAP_SYS_NICE would be allowed to raise the frequency bounds, but realised that in practice it is immaterial as they were already running at max frequency anyway. /* * As we constrain the frequency request from the * context (application) by the sysadmin imposed limits, * it is reasonable to allow the application to * specify its preferred range within those limits. * That is we do not need to restrict requesting * a higher frequency to privileged (CAP_SYS_NICE) * processes. */ > Or even on our integrated graphics, such userspace would unwisely take > away power budget from the CPU. Or could it even harm itself by > triggering too much thermal throttling and run slower than if it let the > balance be controlled by the system? It will indeed. Running at max frequency is not a sensible idea for anything but a few applications (dare we say miners? ;). I thought compositors might benefit from reduced latency by starting at max, https://bugs.freedesktop.org/show_bug.cgi?id=102199 but realistically they care more about power consumption and gain most of the latency reduction from priority sorting and preemption. On the bright side, we give them a loaded gun with which they can shoot both feet off. They have to be confident that they do know their behaviour better than the hw (which for a few will be true). We give them the means to do so, we do not say it is wise. > Or will this be tied with the cgroup work to allow only clients allowed > by sysadmin to do this? That's what I think as well. I think we will end up with everything that can be adjusted via CONTEXT_SETPARAM will be constrained by cgroup. Once again, we can only look at the integration of schedfreq and CFS as being the direction the GPUs will also eventually take. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove the impedance mismatch around intel_engine_enable_signaling
On 08/03/2018 14:07, Chris Wilson wrote: There is some redundancy between dma_fence->ops->enable_signaling (via i915_fence_enable_signaling) and our backend, intel_engine_enable_signaling() in that both levels recheck the fence status multiple times. If we convert intel_engine_enable_signaling() to return the information desired by dma_fence->ops->enable_signaling, we can reduce i915_fence_enable_signaling to a simple stub and avoid trying to reinterpret the same information. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Mika Kuoppala Cc: Michal Winiarski --- drivers/gpu/drm/i915/i915_request.c | 6 +- drivers/gpu/drm/i915/intel_breadcrumbs.c | 21 + drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +- 3 files changed, 15 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index d437beac3969..2a841800d4cf 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -59,11 +59,7 @@ static bool i915_fence_signaled(struct dma_fence *fence) static bool i915_fence_enable_signaling(struct dma_fence *fence) { - if (i915_fence_signaled(fence)) - return false; This was based on hws seqno check... - - intel_engine_enable_signaling(to_request(fence), true); - return !i915_fence_signaled(fence); + return intel_engine_enable_signaling(to_request(fence), true); } static signed long i915_fence_wait(struct dma_fence *fence, diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c b/drivers/gpu/drm/i915/intel_breadcrumbs.c index 1f79e7a47433..671a6d61e29d 100644 --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c +++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c @@ -730,10 +730,11 @@ static void insert_signal(struct intel_breadcrumbs *b, list_add(&request->signaling.link, &iter->signaling.link); } -void intel_engine_enable_signaling(struct i915_request *request, bool wakeup) +bool intel_engine_enable_signaling(struct i915_request *request, bool wakeup) { struct intel_engine_cs *engine = request->engine; struct intel_breadcrumbs *b = &engine->breadcrumbs; + struct intel_wait *wait = &request->signaling.wait; u32 seqno; /* @@ -750,12 +751,12 @@ void intel_engine_enable_signaling(struct i915_request *request, bool wakeup) seqno = i915_request_global_seqno(request); if (!seqno) /* will be enabled later upon execution */ - return; + return true; - GEM_BUG_ON(request->signaling.wait.seqno); - request->signaling.wait.tsk = b->signaler; - request->signaling.wait.request = request; - request->signaling.wait.seqno = seqno; + GEM_BUG_ON(wait->seqno); + wait->tsk = b->signaler; + wait->request = request; + wait->seqno = seqno; /* * Add ourselves into the list of waiters, but registering our @@ -768,11 +769,15 @@ void intel_engine_enable_signaling(struct i915_request *request, bool wakeup) */ spin_lock(&b->rb_lock); insert_signal(b, request, seqno); - wakeup &= __intel_engine_add_wait(engine, &request->signaling.wait); + wakeup &= __intel_engine_add_wait(engine, wait); spin_unlock(&b->rb_lock); - if (wakeup) + if (wakeup) { wake_up_process(b->signaler); + return !intel_wait_complete(wait); ... and would now be based on breadcrumb waiter waking up and removing itself from the tree. So some potential latency where it wasn't before, well, enable-disable signalling cycles actually. If I got it right.. breadcrumbs code confuses me massively these days. Regards, Tvrtko + } + + return true; } void intel_engine_cancel_signaling(struct i915_request *request) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h index 0320c2c4cfba..aa34b2ff04bc 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.h +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h @@ -939,7 +939,7 @@ bool intel_engine_add_wait(struct intel_engine_cs *engine, struct intel_wait *wait); void intel_engine_remove_wait(struct intel_engine_cs *engine, struct intel_wait *wait); -void intel_engine_enable_signaling(struct i915_request *request, bool wakeup); +bool intel_engine_enable_signaling(struct i915_request *request, bool wakeup); void intel_engine_cancel_signaling(struct i915_request *request); static inline bool intel_engine_has_waiter(const struct intel_engine_cs *engine) ___ 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: misc fixes in headers (RESEND)
== Series Details == Series: drm/i915: misc fixes in headers (RESEND) URL : https://patchwork.freedesktop.org/series/39589/ State : success == Summary == Series 39589v1 drm/i915: misc fixes in headers (RESEND) https://patchwork.freedesktop.org/api/1.0/series/39589/revisions/1/mbox/ Known issues: Test debugfs_test: Subgroup read_all_entries: incomplete -> PASS (fi-snb-2520m) fdo#103713 Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 Test kms_chamelium: Subgroup dp-edid-read: pass -> FAIL (fi-kbl-7500u) fdo#102505 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:424s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:426s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:370s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:509s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:281s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:490s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:493s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:481s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:469s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:405s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:584s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:592s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:422s fi-gdg-551 total:288 pass:180 dwarn:0 dfail:0 fail:0 skip:108 time:290s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:520s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:397s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:411s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:457s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:422s fi-kbl-7500u total:288 pass:262 dwarn:1 dfail:0 fail:1 skip:24 time:467s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:460s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:506s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:584s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:429s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:525s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:535s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:503s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:492s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:425s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:430s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:514s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:393s Blacklisted hosts: fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:511s 2e2ef5a5221a7469ecd72c68ed15dd8b94e2e0c6 drm-tip: 2018y-03m-09d-14h-28m-10s UTC integration manifest 2b518e87976b drm/i915: Move i915_gpu_error into its own header f2969e101bac drm/i915: Make header i915_pmu.h more robust 87481ecfb862 drm/i915: Change parameters order in i915_gem_batch_pool_init c055bfc9c223 drm/i915: Include i915_reg.h in intel_ringbuffer.h == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8294/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx
On 09/03/2018 13:46, Chris Wilson wrote: Exercise some new API that allows applications to request that individual contexts are executed within a desired frequency range. v2: Split single/continuous set_freq subtests v3: Do an up/down ramp for individual freq request, check nothing changes after each invalid request Signed-off-by: Chris Wilson Cc: Paneri, Praveen Cc: Kamble, Sagar A Cc: Antonio Argenziano --- tests/Makefile.am | 1 + tests/Makefile.sources | 1 + tests/gem_ctx_freq.c | 648 + tests/meson.build | 1 + 4 files changed, 651 insertions(+) create mode 100644 tests/gem_ctx_freq.c [snip] +static void check_invalid(int fd, uint32_t ctx, uint32_t min, uint32_t max) +{ + const struct test { + uint32_t min, max; + } tests[] = { + { min - 50, max - 50 }, + { min - 50, max }, + { min - 50, max + 50 }, + { min, max + 50 }, + { min + 50, max + 50 }, + + { min - 50, min - 50 }, + + { min - 50, min }, + { min + 50, min }, + { min, min - 50 }, + + { max + 50, max }, + { max, max + 50 }, + { max, max - 50 }, + + { max + 50, max + 50 }, Is unprivileged "{ max, max }" allowed? In other words pin to max frequency by anyone? If so, what happens when all userspace learns about this and wants to use it just so to be lower latency than the other guy? Or even on our integrated graphics, such userspace would unwisely take away power budget from the CPU. Or could it even harm itself by triggering too much thermal throttling and run slower than if it let the balance be controlled by the system? Or will this be tied with the cgroup work to allow only clients allowed by sysadmin to do this? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/4] drm/i915/guc: Tidy guc_log_control
From: Michał Winiarski We plan to decouple log runtime (mapping + relay) from verbosity control. Let's tidy the code now to reduce the churn in the following patches. v2: Tidy macros, keep debug messages, use helper var for enable, correct typo (Michał) Fix incorrect input validaction (Sagar) Signed-off-by: Michał Winiarski Cc: Chris Wilson Cc: Daniele Ceraolo Spurio Cc: Michal Wajdeczko Cc: Sagar Arun Kamble Reviewed-by: Sagar Arun Kamble Signed-off-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20180308154707.21716-1-michal.winiar...@intel.com --- drivers/gpu/drm/i915/i915_debugfs.c | 11 ++--- drivers/gpu/drm/i915/intel_guc_log.c | 80 +--- drivers/gpu/drm/i915/intel_guc_log.h | 3 +- 3 files changed, 53 insertions(+), 41 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 34d12522a1da..c4cc8fef11a0 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -2499,13 +2499,10 @@ static int i915_guc_log_control_get(void *data, u64 *val) { struct drm_i915_private *dev_priv = data; - if (!HAS_GUC(dev_priv)) + if (!USES_GUC(dev_priv)) return -ENODEV; - if (!dev_priv->guc.log.vma) - return -EINVAL; - - *val = i915_modparams.guc_log_level; + *val = intel_guc_log_control_get(&dev_priv->guc); return 0; } @@ -2514,10 +2511,10 @@ static int i915_guc_log_control_set(void *data, u64 val) { struct drm_i915_private *dev_priv = data; - if (!HAS_GUC(dev_priv)) + if (!USES_GUC(dev_priv)) return -ENODEV; - return intel_guc_log_control(&dev_priv->guc, val); + return intel_guc_log_control_set(&dev_priv->guc, val); } DEFINE_SIMPLE_ATTRIBUTE(i915_guc_log_control_fops, diff --git a/drivers/gpu/drm/i915/intel_guc_log.c b/drivers/gpu/drm/i915/intel_guc_log.c index c0c2e7d1c7d7..7e59fb07b06b 100644 --- a/drivers/gpu/drm/i915/intel_guc_log.c +++ b/drivers/gpu/drm/i915/intel_guc_log.c @@ -659,51 +659,63 @@ void intel_guc_log_destroy(struct intel_guc *guc) i915_vma_unpin_and_release(&guc->log.vma); } -int intel_guc_log_control(struct intel_guc *guc, u64 control_val) +int intel_guc_log_control_get(struct intel_guc *guc) +{ + GEM_BUG_ON(!guc->log.vma); + GEM_BUG_ON(i915_modparams.guc_log_level < 0); + + return i915_modparams.guc_log_level; +} + +#define GUC_LOG_LEVEL_DISABLED 0 +#define LOG_LEVEL_TO_ENABLED(x)((x) > 0) +#define LOG_LEVEL_TO_VERBOSITY(x) ({ \ + typeof(x) _x = (x); \ + LOG_LEVEL_TO_ENABLED(_x) ? _x - 1 : 0; \ +}) +#define VERBOSITY_TO_LOG_LEVEL(x) ((x) + 1) +int intel_guc_log_control_set(struct intel_guc *guc, u64 val) { struct drm_i915_private *dev_priv = guc_to_i915(guc); - bool enable_logging = control_val > 0; - u32 verbosity; + bool enabled = LOG_LEVEL_TO_ENABLED(val); int ret; - if (!guc->log.vma) - return -ENODEV; + BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN != 0); + GEM_BUG_ON(!guc->log.vma); + GEM_BUG_ON(i915_modparams.guc_log_level < 0); - BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN); - if (control_val > 1 + GUC_LOG_VERBOSITY_MAX) + /* +* GuC is recognizing log levels starting from 0 to max, we're using 0 +* as indication that logging should be disabled. +*/ + if (val < GUC_LOG_LEVEL_DISABLED || + val > VERBOSITY_TO_LOG_LEVEL(GUC_LOG_VERBOSITY_MAX)) return -EINVAL; - /* This combination doesn't make sense & won't have any effect */ - if (!enable_logging && !i915_modparams.guc_log_level) - return 0; + mutex_lock(&dev_priv->drm.struct_mutex); - verbosity = enable_logging ? control_val - 1 : 0; + if (i915_modparams.guc_log_level == val) { + ret = 0; + goto out_unlock; + } - ret = mutex_lock_interruptible(&dev_priv->drm.struct_mutex); - if (ret) - return ret; intel_runtime_pm_get(dev_priv); - ret = guc_log_control(guc, enable_logging, verbosity); + ret = guc_log_control(guc, enabled, LOG_LEVEL_TO_VERBOSITY(val)); intel_runtime_pm_put(dev_priv); - mutex_unlock(&dev_priv->drm.struct_mutex); - - if (ret < 0) { - DRM_DEBUG_DRIVER("guc_logging_control action failed %d\n", ret); - return ret; + if (ret) { + DRM_DEBUG_DRIVER("guc_log_control action failed %d\n", ret); + goto out_unlock; } - if (enable_logging) { - i915_modparams.guc_log_level = 1 + verbosity; + i915_modparams.guc_log_level = val; - /* -* If log was disabled at boot time, then the relay channel file -* wouldn't have been created by n
[Intel-gfx] [CI 2/4] drm/i915/guc: Create common entry points for log register/unregister
From: Michał Winiarski We have many functions responsible for allocating different parts of GuC log runtime called from multiple places. Let's stick with keeping everything in guc_log_register instead. v2: Use more generic intel_uc_register name, keep using "misc" suffix (Michał) s/dev_priv/i915 (Sagar) Make guc_log_relay_* static (sparse) Signed-off-by: Michał Winiarski Cc: Chris Wilson Cc: Daniele Ceraolo Spurio Cc: Michal Wajdeczko Cc: Sagar Arun Kamble Reviewed-by: Sagar Arun Kamble Signed-off-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20180308154707.21716-2-michal.winiar...@intel.com --- drivers/gpu/drm/i915/i915_drv.c | 6 +- drivers/gpu/drm/i915/intel_guc_log.c | 156 ++- drivers/gpu/drm/i915/intel_guc_log.h | 6 +- drivers/gpu/drm/i915/intel_uc.c | 41 + drivers/gpu/drm/i915/intel_uc.h | 2 + 5 files changed, 95 insertions(+), 116 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index d7c4de45644d..987c6770d1a6 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1238,9 +1238,11 @@ static void i915_driver_register(struct drm_i915_private *dev_priv) /* Reveal our presence to userspace */ if (drm_dev_register(dev, 0) == 0) { i915_debugfs_register(dev_priv); - i915_guc_log_register(dev_priv); i915_setup_sysfs(dev_priv); + /* Depends on debugfs having been initialized */ + intel_uc_register(dev_priv); + /* Depends on sysfs having been initialized */ i915_perf_register(dev_priv); } else @@ -1298,7 +1300,7 @@ static void i915_driver_unregister(struct drm_i915_private *dev_priv) i915_pmu_unregister(dev_priv); i915_teardown_sysfs(dev_priv); - i915_guc_log_unregister(dev_priv); + intel_uc_unregister(dev_priv); drm_dev_unregister(&dev_priv->drm); i915_gem_shrinker_unregister(dev_priv); diff --git a/drivers/gpu/drm/i915/intel_guc_log.c b/drivers/gpu/drm/i915/intel_guc_log.c index 7e59fb07b06b..90b395f34808 100644 --- a/drivers/gpu/drm/i915/intel_guc_log.c +++ b/drivers/gpu/drm/i915/intel_guc_log.c @@ -443,7 +443,7 @@ void intel_guc_log_init_early(struct intel_guc *guc) INIT_WORK(&guc->log.runtime.flush_work, capture_logs_work); } -int intel_guc_log_relay_create(struct intel_guc *guc) +static int guc_log_relay_create(struct intel_guc *guc) { struct drm_i915_private *dev_priv = guc_to_i915(guc); struct rchan *guc_log_relay_chan; @@ -496,7 +496,7 @@ int intel_guc_log_relay_create(struct intel_guc *guc) return ret; } -void intel_guc_log_relay_destroy(struct intel_guc *guc) +static void guc_log_relay_destroy(struct intel_guc *guc) { mutex_lock(&guc->log.runtime.relay_lock); @@ -514,49 +514,6 @@ void intel_guc_log_relay_destroy(struct intel_guc *guc) mutex_unlock(&guc->log.runtime.relay_lock); } -static int guc_log_late_setup(struct intel_guc *guc) -{ - struct drm_i915_private *dev_priv = guc_to_i915(guc); - int ret; - - if (!guc_log_has_runtime(guc)) { - /* -* If log was disabled at boot time, then setup needed to handle -* log buffer flush interrupts would not have been done yet, so -* do that now. -*/ - ret = intel_guc_log_relay_create(guc); - if (ret) - goto err; - - mutex_lock(&dev_priv->drm.struct_mutex); - intel_runtime_pm_get(dev_priv); - ret = guc_log_runtime_create(guc); - intel_runtime_pm_put(dev_priv); - mutex_unlock(&dev_priv->drm.struct_mutex); - - if (ret) - goto err_relay; - } - - ret = guc_log_relay_file_create(guc); - if (ret) - goto err_runtime; - - return 0; - -err_runtime: - mutex_lock(&dev_priv->drm.struct_mutex); - guc_log_runtime_destroy(guc); - mutex_unlock(&dev_priv->drm.struct_mutex); -err_relay: - intel_guc_log_relay_destroy(guc); -err: - /* logging will remain off */ - i915_modparams.guc_log_level = 0; - return ret; -} - static void guc_log_capture_logs(struct intel_guc *guc) { struct drm_i915_private *dev_priv = guc_to_i915(guc); @@ -576,16 +533,6 @@ static void guc_flush_logs(struct intel_guc *guc) { struct drm_i915_private *dev_priv = guc_to_i915(guc); - if (!USES_GUC_SUBMISSION(dev_priv) || !i915_modparams.guc_log_level) - return; - - /* First disable the interrupts, will be renabled afterwards */ - mutex_lock(&dev_priv->drm.struct_mutex); - intel_runtime_pm_get(dev_priv); - gen9_disable_guc_interrupts(dev_priv); - intel_runtime_pm_put(dev_priv); - mutex_unlo
[Intel-gfx] [CI 3/4] drm/i915/guc: Move GuC notification handling to separate function
From: Michal Wajdeczko To allow future code reuse. While here, fix comment style. v2: Notifications are a separate thing - rename the handler (Sagar) Suggested-by: Oscar Mateo Signed-off-by: Michal Wajdeczko Signed-off-by: Michał Winiarski Cc: Chris Wilson Cc: Daniele Ceraolo Spurio Cc: Oscar Mateo Cc: Sagar Arun Kamble Reviewed-by: Sagar Arun Kamble Signed-off-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20180308154707.21716-3-michal.winiar...@intel.com --- drivers/gpu/drm/i915/i915_irq.c | 33 ++--- drivers/gpu/drm/i915/intel_guc.c | 37 + drivers/gpu/drm/i915/intel_guc.h | 1 + 3 files changed, 40 insertions(+), 31 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index c8c29d8ecbab..828f3104488c 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -1766,37 +1766,8 @@ static void gen6_rps_irq_handler(struct drm_i915_private *dev_priv, u32 pm_iir) static void gen9_guc_irq_handler(struct drm_i915_private *dev_priv, u32 gt_iir) { - if (gt_iir & GEN9_GUC_TO_HOST_INT_EVENT) { - /* Sample the log buffer flush related bits & clear them out now -* itself from the message identity register to minimize the -* probability of losing a flush interrupt, when there are back -* to back flush interrupts. -* There can be a new flush interrupt, for different log buffer -* type (like for ISR), whilst Host is handling one (for DPC). -* Since same bit is used in message register for ISR & DPC, it -* could happen that GuC sets the bit for 2nd interrupt but Host -* clears out the bit on handling the 1st interrupt. -*/ - u32 msg, flush; - - msg = I915_READ(SOFT_SCRATCH(15)); - flush = msg & (INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED | - INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER); - if (flush) { - /* Clear the message bits that are handled */ - I915_WRITE(SOFT_SCRATCH(15), msg & ~flush); - - /* Handle flush interrupt in bottom half */ - queue_work(dev_priv->guc.log.runtime.flush_wq, - &dev_priv->guc.log.runtime.flush_work); - - dev_priv->guc.log.flush_interrupt_count++; - } else { - /* Not clearing of unhandled event bits won't result in -* re-triggering of the interrupt. -*/ - } - } + if (gt_iir & GEN9_GUC_TO_HOST_INT_EVENT) + intel_guc_to_host_event_handler(&dev_priv->guc); } static void i9xx_pipestat_irq_reset(struct drm_i915_private *dev_priv) diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index ff08ea0ebf49..25f92291fd40 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -364,6 +364,43 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len) return ret; } +void intel_guc_to_host_event_handler(struct intel_guc *guc) +{ + struct drm_i915_private *dev_priv = guc_to_i915(guc); + u32 msg, flush; + + /* +* Sample the log buffer flush related bits & clear them out now +* itself from the message identity register to minimize the +* probability of losing a flush interrupt, when there are back +* to back flush interrupts. +* There can be a new flush interrupt, for different log buffer +* type (like for ISR), whilst Host is handling one (for DPC). +* Since same bit is used in message register for ISR & DPC, it +* could happen that GuC sets the bit for 2nd interrupt but Host +* clears out the bit on handling the 1st interrupt. +*/ + + msg = I915_READ(SOFT_SCRATCH(15)); + flush = msg & (INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED | + INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER); + if (flush) { + /* Clear the message bits that are handled */ + I915_WRITE(SOFT_SCRATCH(15), msg & ~flush); + + /* Handle flush interrupt in bottom half */ + queue_work(guc->log.runtime.flush_wq, + &guc->log.runtime.flush_work); + + guc->log.flush_interrupt_count++; + } else { + /* +* Not clearing of unhandled event bits won't result in +* re-triggering of the interrupt. +*/ + } +} + 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 b9424
[Intel-gfx] [CI 4/4] HAX: Enable GuC for CI
From: Michal Wajdeczko v2: except running with HYPERVISOR --- drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/intel_uc.c| 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 430f5f9d0ff4..3deae1e22974 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -47,7 +47,7 @@ struct drm_printer; param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, -1) \ param(int, guc_log_level, 0) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 1c1a00df010b..cfa21f6058a5 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -63,6 +63,8 @@ static int __get_platform_enable_guc(struct drm_i915_private *dev_priv) enable_guc |= ENABLE_GUC_LOAD_HUC; /* Any platform specific fine-tuning can be done here */ + if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) + enable_guc = 0; return enable_guc; } -- 2.16.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 08/15] drm/i915/guc: Split relay control and GuC log level
Quoting Michał Winiarski (2018-03-09 16:30:42) > On Fri, Mar 09, 2018 at 12:00:06PM +0100, Michal Wajdeczko wrote: > > On Thu, 08 Mar 2018 16:47:00 +0100, Michał Winiarski > > wrote: > > > > > Those two concepts are really separate. Since GuC is writing data into > > > its own buffer and we even provide a way for userspace to read directly > > > from it using i915_guc_log_dump debugfs, there's no real reason to tie > > > log level with relay creation. > > > Let's create a separate debugfs, giving userspace a way to create a > > > relay on demand, when it wants to read a continuous log rather than a > > > snapshot. > > > > > > v2: Don't touch guc_log_level on relay creation error, adjust locking > > > after rebase, s/dev_priv/i915, pass guc to file->private_data (Sagar) > > > Use struct_mutex rather than runtime.lock for set_log_level > > > > > > Signed-off-by: Michał Winiarski > > > Cc: Chris Wilson > > > Cc: Daniele Ceraolo Spurio > > > Cc: Sagar Arun Kamble > > > Cc: Michal Wajdeczko > > > --- > > > > /snip/ > > > > > diff --git a/drivers/gpu/drm/i915/intel_uc.c > > > b/drivers/gpu/drm/i915/intel_uc.c > > > index 90d2f38e22c9..abce0e38528a 100644 > > > --- a/drivers/gpu/drm/i915/intel_uc.c > > > +++ b/drivers/gpu/drm/i915/intel_uc.c > > > @@ -219,28 +219,6 @@ static void guc_free_load_err_log(struct intel_guc > > > *guc) > > > i915_gem_object_put(guc->load_err_log); > > > } > > > -int intel_uc_register(struct drm_i915_private *i915) > > > -{ > > > - int ret = 0; > > > - > > > - if (!USES_GUC(i915)) > > > - return 0; > > > - > > > - if (i915_modparams.guc_log_level) > > > - ret = intel_guc_log_register(&i915->guc); > > > - > > > - return ret; > > > -} > > > - > > > -void intel_uc_unregister(struct drm_i915_private *i915) > > > -{ > > > - if (!USES_GUC(i915)) > > > - return; > > > - > > > - if (i915_modparams.guc_log_level) > > > - intel_guc_log_unregister(&i915->guc); > > > -} > > > - > > > static int guc_enable_communication(struct intel_guc *guc) > > > { > > > struct drm_i915_private *dev_priv = guc_to_i915(guc); > > > diff --git a/drivers/gpu/drm/i915/intel_uc.h > > > b/drivers/gpu/drm/i915/intel_uc.h > > > index d6af984cd789..f76d51d1ce70 100644 > > > --- a/drivers/gpu/drm/i915/intel_uc.h > > > +++ b/drivers/gpu/drm/i915/intel_uc.h > > > @@ -31,8 +31,6 @@ > > > void intel_uc_sanitize_options(struct drm_i915_private *dev_priv); > > > void intel_uc_init_early(struct drm_i915_private *dev_priv); > > > void intel_uc_init_mmio(struct drm_i915_private *dev_priv); > > > -int intel_uc_register(struct drm_i915_private *dev_priv); > > > -void intel_uc_unregister(struct drm_i915_private *dev_priv); > > > > hmm, it looks that timelines of these two functions were very short > > (from patch 2 till patch 8) - so maybe by doing some patch re-order > > can we fully skip them ? > > I could drop patch 2 entirely and go straight to the decoupling - but that > means > more code movement overall and way more content in this one. > > I don't really see a better split (but since I'm the author I'm biased :) ). > I'm open for suggestions. I can settle the argument by grabbing the first 3 patches as code movement, before we get into the details. Ok? -Chris ___ 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/uc: Sanitize uC (rev2)
== Series Details == Series: drm/i915/uc: Sanitize uC (rev2) URL : https://patchwork.freedesktop.org/series/39634/ State : success == Summary == Series 39634v2 drm/i915/uc: Sanitize uC https://patchwork.freedesktop.org/api/1.0/series/39634/revisions/2/mbox/ Known issues: Test debugfs_test: Subgroup read_all_entries: incomplete -> PASS (fi-snb-2520m) fdo#103713 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: pass -> FAIL (fi-skl-guc) fdo#103191 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:428s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:425s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:371s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:498s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:279s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:494s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:495s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:480s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:467s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:406s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:585s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:580s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:417s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:287s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:516s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:395s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:409s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:452s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:419s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:468s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:456s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:508s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:587s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:433s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:518s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:538s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:491s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:491s fi-skl-guc total:288 pass:259 dwarn:0 dfail:0 fail:1 skip:28 time:422s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:425s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:524s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:388s Blacklisted hosts: fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:511s fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:524s 2e2ef5a5221a7469ecd72c68ed15dd8b94e2e0c6 drm-tip: 2018y-03m-09d-14h-28m-10s UTC integration manifest ae3a1d7d7e62 HAX: Enable GuC for CI 11f207630fb0 drm/i915/uc: Sanitize uC together with GEM 70549b8cf2c8 drm/i915/uc: Sanitize uC options early == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8293/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 08/15] drm/i915/guc: Split relay control and GuC log level
On Fri, Mar 09, 2018 at 12:00:06PM +0100, Michal Wajdeczko wrote: > On Thu, 08 Mar 2018 16:47:00 +0100, Michał Winiarski > wrote: > > > Those two concepts are really separate. Since GuC is writing data into > > its own buffer and we even provide a way for userspace to read directly > > from it using i915_guc_log_dump debugfs, there's no real reason to tie > > log level with relay creation. > > Let's create a separate debugfs, giving userspace a way to create a > > relay on demand, when it wants to read a continuous log rather than a > > snapshot. > > > > v2: Don't touch guc_log_level on relay creation error, adjust locking > > after rebase, s/dev_priv/i915, pass guc to file->private_data (Sagar) > > Use struct_mutex rather than runtime.lock for set_log_level > > > > Signed-off-by: Michał Winiarski > > Cc: Chris Wilson > > Cc: Daniele Ceraolo Spurio > > Cc: Sagar Arun Kamble > > Cc: Michal Wajdeczko > > --- > > /snip/ > > > diff --git a/drivers/gpu/drm/i915/intel_uc.c > > b/drivers/gpu/drm/i915/intel_uc.c > > index 90d2f38e22c9..abce0e38528a 100644 > > --- a/drivers/gpu/drm/i915/intel_uc.c > > +++ b/drivers/gpu/drm/i915/intel_uc.c > > @@ -219,28 +219,6 @@ static void guc_free_load_err_log(struct intel_guc > > *guc) > > i915_gem_object_put(guc->load_err_log); > > } > > -int intel_uc_register(struct drm_i915_private *i915) > > -{ > > - int ret = 0; > > - > > - if (!USES_GUC(i915)) > > - return 0; > > - > > - if (i915_modparams.guc_log_level) > > - ret = intel_guc_log_register(&i915->guc); > > - > > - return ret; > > -} > > - > > -void intel_uc_unregister(struct drm_i915_private *i915) > > -{ > > - if (!USES_GUC(i915)) > > - return; > > - > > - if (i915_modparams.guc_log_level) > > - intel_guc_log_unregister(&i915->guc); > > -} > > - > > static int guc_enable_communication(struct intel_guc *guc) > > { > > struct drm_i915_private *dev_priv = guc_to_i915(guc); > > diff --git a/drivers/gpu/drm/i915/intel_uc.h > > b/drivers/gpu/drm/i915/intel_uc.h > > index d6af984cd789..f76d51d1ce70 100644 > > --- a/drivers/gpu/drm/i915/intel_uc.h > > +++ b/drivers/gpu/drm/i915/intel_uc.h > > @@ -31,8 +31,6 @@ > > void intel_uc_sanitize_options(struct drm_i915_private *dev_priv); > > void intel_uc_init_early(struct drm_i915_private *dev_priv); > > void intel_uc_init_mmio(struct drm_i915_private *dev_priv); > > -int intel_uc_register(struct drm_i915_private *dev_priv); > > -void intel_uc_unregister(struct drm_i915_private *dev_priv); > > hmm, it looks that timelines of these two functions were very short > (from patch 2 till patch 8) - so maybe by doing some patch re-order > can we fully skip them ? I could drop patch 2 entirely and go straight to the decoupling - but that means more code movement overall and way more content in this one. I don't really see a better split (but since I'm the author I'm biased :) ). I'm open for suggestions. -Michał > > > void intel_uc_init_fw(struct drm_i915_private *dev_priv); > > void intel_uc_fini_fw(struct drm_i915_private *dev_priv); > > int intel_uc_init_misc(struct drm_i915_private *dev_priv); ___ 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: Fix audio issue on BXT (rev2)
== Series Details == Series: drm: i915: Fix audio issue on BXT (rev2) URL : https://patchwork.freedesktop.org/series/35955/ State : failure == Summary == Series 35955v2 drm: i915: Fix audio issue on BXT https://patchwork.freedesktop.org/api/1.0/series/35955/revisions/2/mbox/ Possible new issues: Test kms_frontbuffer_tracking: Subgroup basic: pass -> INCOMPLETE (fi-bsw-n3050) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-hsw-4770) Known issues: Test debugfs_test: Subgroup read_all_entries: incomplete -> PASS (fi-snb-2520m) fdo#103713 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:425s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:424s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:380s fi-bsw-n3050 total:224 pass:194 dwarn:0 dfail:0 fail:0 skip:29 fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:279s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:501s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:485s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:473s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:408s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:576s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:581s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:415s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:289s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:516s fi-hsw-4770 total:245 pass:221 dwarn:0 dfail:0 fail:0 skip:23 fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:416s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:469s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:422s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:470s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:464s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:509s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:583s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:440s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:524s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:537s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:498s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:488s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:422s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:433s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:516s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:395s Blacklisted hosts: fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:508s fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:518s fi-bxt-dsi failed to collect. IGT log at Patchwork_8292/fi-bxt-dsi/run0.log 2e2ef5a5221a7469ecd72c68ed15dd8b94e2e0c6 drm-tip: 2018y-03m-09d-14h-28m-10s UTC integration manifest c90b8bf68afb drm: i915: Fix audio issue on BXT == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8292/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 0/4] drm/i915: misc fixes in headers (RESEND)
On Thu, Mar 08, 2018 at 04:22:55PM +0100, Michal Wajdeczko wrote: > On Thu, 08 Mar 2018 13:58:48 +0100, Petri Latvala > wrote: > > > On Thu, Mar 08, 2018 at 02:20:41PM +0200, Jani Nikula wrote: > > > On Thu, 08 Mar 2018, Chris Wilson wrote: > > > > Quoting Michal Wajdeczko (2018-03-08 09:50:33) > > > >> This is a resend, to make patchwork happy. > > > >> All patches already been reviewed. > > > > > > > > It's still being ignored. :( > > > > > > At least patchwork detected this as a series [1], often that's the > > > problem. > > > > > > Patchwork is not seeing patch 4/4, and due to its weird logic, it's > > still waiting for it instead of considering the series "incomplete". > > > > Looking at the series page, it doesn't even have a revision number. > > > > This causes the pw REST api to show the series as one with 0 patches > > when listing series, there's no series-new-revision event (CI is > > watching that), and it also causes the below: > > > > > I tried to start testing manually from patchwork, it gives me "failed!". > > > > > > Arek checked the logs and patch 4/4 hasn't been received by pw at > > all. Maybe it's still on the way, who knows. > > > > I'm not sure if this is related, but list archive decided to assign > patch 1/4 [1] to old series [2] instead new one [3] > > [1] https://lists.freedesktop.org/archives/intel-gfx/2018-March/158080.html > [2] > https://lists.freedesktop.org/archives/intel-gfx/2018-March/thread.html#157974 > [3] > https://lists.freedesktop.org/archives/intel-gfx/2018-March/thread.html#158081 > > ps. patch 4/4 is already in archive [4] > > [4] https://lists.freedesktop.org/archives/intel-gfx/2018-March/158082.html The patch got lost in time and space and has never reached patchwork's mail server. I feed the patchwork with a copy of the mail manually. Expect results soon. -- Cheers, Arek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/3] HAX: Enable GuC for CI
v2: except running with HYPERVISOR Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/intel_uc.c| 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 430f5f9..3deae1e 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -47,7 +47,7 @@ param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, -1) \ param(int, guc_log_level, 0) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index abd1f7b..cb77b0e 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -63,6 +63,8 @@ static int __get_platform_enable_guc(struct drm_i915_private *dev_priv) enable_guc |= ENABLE_GUC_LOAD_HUC; /* Any platform specific fine-tuning can be done here */ + if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) + enable_guc = 0; return enable_guc; } -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/3] drm/i915/uc: Sanitize uC options early
We are sanitizing uC related modparams together with other driver modparams in intel_sanitize_options called from i915_driver_init_hw, but this is too late for us as we will want to use USES_GUC/USES_HUC macros at earlier stage. Since our sanitizing does not require any MMIO access, we can do it in intel_uc_init_early right after we resolve firmware names. Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Chris Wilson Reviewed-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.c | 2 -- drivers/gpu/drm/i915/intel_uc.c | 6 -- drivers/gpu/drm/i915/intel_uc.h | 1 - 3 files changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index d7c4de4..5ba6d6b 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1074,8 +1074,6 @@ static void intel_sanitize_options(struct drm_i915_private *dev_priv) i915_modparams.enable_ppgtt); DRM_DEBUG_DRIVER("ppgtt mode: %i\n", i915_modparams.enable_ppgtt); - intel_uc_sanitize_options(dev_priv); - intel_gvt_sanitize_options(dev_priv); } diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index e5bf0d3..a45171c 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -83,7 +83,7 @@ static int __get_default_guc_log_level(struct drm_i915_private *dev_priv) } /** - * intel_uc_sanitize_options - sanitize uC related modparam options + * sanitize_options_early - sanitize uC related modparam options * @dev_priv: device private * * In case of "enable_guc" option this function will attempt to modify @@ -99,7 +99,7 @@ static int __get_default_guc_log_level(struct drm_i915_private *dev_priv) * unless GuC is enabled on given platform and the driver is compiled with * debug config when this modparam will default to "enable(1..4)". */ -void intel_uc_sanitize_options(struct drm_i915_private *dev_priv) +static void sanitize_options_early(struct drm_i915_private *dev_priv) { struct intel_uc_fw *guc_fw = &dev_priv->guc.fw; struct intel_uc_fw *huc_fw = &dev_priv->huc.fw; @@ -163,6 +163,8 @@ void intel_uc_init_early(struct drm_i915_private *dev_priv) { intel_guc_init_early(&dev_priv->guc); intel_huc_init_early(&dev_priv->huc); + + sanitize_options_early(dev_priv); } void intel_uc_init_fw(struct drm_i915_private *dev_priv) diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h index f76d51d..dce4813 100644 --- a/drivers/gpu/drm/i915/intel_uc.h +++ b/drivers/gpu/drm/i915/intel_uc.h @@ -28,7 +28,6 @@ #include "intel_huc.h" #include "i915_params.h" -void intel_uc_sanitize_options(struct drm_i915_private *dev_priv); void intel_uc_init_early(struct drm_i915_private *dev_priv); void intel_uc_init_mmio(struct drm_i915_private *dev_priv); void intel_uc_init_fw(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
[Intel-gfx] [PATCH v2 2/3] drm/i915/uc: Sanitize uC together with GEM
Instead of dancing around uC on reset/suspend/resume scenarios, explicitly sanitize uC when we sanitize GEM to force uC reload and start from known beginning. v2: don't forget about reset path (Daniele) sanitize uc before gem initiated full reset (Daniele) Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Cc: Sagar Arun Kamble Cc: Chris Wilson Cc: Michel Thierry --- drivers/gpu/drm/i915/i915_gem.c| 2 ++ drivers/gpu/drm/i915/intel_guc.h | 6 ++ drivers/gpu/drm/i915/intel_huc.h | 6 ++ drivers/gpu/drm/i915/intel_uc.c| 18 ++ drivers/gpu/drm/i915/intel_uc.h| 1 + drivers/gpu/drm/i915/intel_uc_fw.h | 6 ++ 6 files changed, 39 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index e58b741..05b0724 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2998,6 +2998,7 @@ int i915_gem_reset_prepare(struct drm_i915_private *dev_priv) } i915_gem_revoke_fences(dev_priv); + intel_uc_sanitize(dev_priv); return err; } @@ -4978,6 +4979,7 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv) * machines is a good idea, we don't - just in case it leaves the * machine in an unusable condition. */ + intel_uc_sanitize(dev_priv); i915_gem_sanitize(dev_priv); intel_runtime_pm_put(dev_priv); diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h index b9424ac..ec8569f 100644 --- a/drivers/gpu/drm/i915/intel_guc.h +++ b/drivers/gpu/drm/i915/intel_guc.h @@ -132,4 +132,10 @@ static inline u32 guc_ggtt_offset(struct i915_vma *vma) struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size); u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv); +static inline int intel_guc_sanitize(struct intel_guc *guc) +{ + intel_uc_fw_sanitize(&guc->fw); + return 0; +} + #endif diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h index 5d6e804..b185850 100644 --- a/drivers/gpu/drm/i915/intel_huc.h +++ b/drivers/gpu/drm/i915/intel_huc.h @@ -38,4 +38,10 @@ struct intel_huc { void intel_huc_init_early(struct intel_huc *huc); int intel_huc_auth(struct intel_huc *huc); +static inline int intel_huc_sanitize(struct intel_huc *huc) +{ + intel_uc_fw_sanitize(&huc->fw); + return 0; +} + #endif diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index a45171c..abd1f7b 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -327,6 +327,24 @@ void intel_uc_fini(struct drm_i915_private *dev_priv) intel_guc_fini(guc); } +void intel_uc_sanitize(struct drm_i915_private *i915) +{ + struct intel_guc *guc = &i915->guc; + struct intel_huc *huc = &i915->huc; + + if (!USES_GUC(i915)) + return; + + GEM_BUG_ON(!HAS_GUC(i915)); + + guc_disable_communication(guc); + + intel_huc_sanitize(huc); + intel_guc_sanitize(guc); + + __intel_uc_reset_hw(i915); +} + int intel_uc_init_hw(struct drm_i915_private *dev_priv) { struct intel_guc *guc = &dev_priv->guc; diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h index dce4813..937e611 100644 --- a/drivers/gpu/drm/i915/intel_uc.h +++ b/drivers/gpu/drm/i915/intel_uc.h @@ -34,6 +34,7 @@ void intel_uc_fini_fw(struct drm_i915_private *dev_priv); int intel_uc_init_misc(struct drm_i915_private *dev_priv); void intel_uc_fini_misc(struct drm_i915_private *dev_priv); +void intel_uc_sanitize(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_init(struct drm_i915_private *dev_priv); diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h b/drivers/gpu/drm/i915/intel_uc_fw.h index d5fd460..2601521 100644 --- a/drivers/gpu/drm/i915/intel_uc_fw.h +++ b/drivers/gpu/drm/i915/intel_uc_fw.h @@ -115,6 +115,12 @@ static inline bool intel_uc_fw_is_selected(struct intel_uc_fw *uc_fw) return uc_fw->path != NULL; } +static inline void intel_uc_fw_sanitize(struct intel_uc_fw *uc_fw) +{ + if (uc_fw->load_status == INTEL_UC_FIRMWARE_SUCCESS) + uc_fw->load_status = INTEL_UC_FIRMWARE_PENDING; +} + void intel_uc_fw_fetch(struct drm_i915_private *dev_priv, struct intel_uc_fw *uc_fw); int intel_uc_fw_upload(struct intel_uc_fw *uc_fw, -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/3] drm/i915/uc: Sanitize uC
Attempt to sanitize uC for better alignment with rest of GEM driver. v2: cover reset path and sanitize uc before gem Michal Wajdeczko (3): drm/i915/uc: Sanitize uC options early drm/i915/uc: Sanitize uC together with GEM HAX: Enable GuC for CI drivers/gpu/drm/i915/i915_drv.c| 2 -- drivers/gpu/drm/i915/i915_gem.c| 2 ++ drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/intel_guc.h | 6 ++ drivers/gpu/drm/i915/intel_huc.h | 6 ++ drivers/gpu/drm/i915/intel_uc.c| 26 -- drivers/gpu/drm/i915/intel_uc.h| 2 +- drivers/gpu/drm/i915/intel_uc_fw.h | 6 ++ 8 files changed, 46 insertions(+), 6 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: i915: Fix audio issue on BXT
On Apollolake, with stress test warm reboot, audio card was not getting enumerated after reboot. This was a spurious issue happening on Apollolake. HW codec and HD audio controller link was going out of sync for which there was a fix in i915 driver but was not getting invoked for BXT. Extending this fix to BXT as well. Bspec: 21829 Tested on apollolake chromebook by stress test warm reboot with 2500 iterations. v2: * Mention Bspec Index in commit message(Dhinakaran Pandiyan) Signed-off-by: Gaurav K Singh Reviewed-by: Dhinakaran Pandiyan --- drivers/gpu/drm/i915/intel_audio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c index 709d6ca68074..656f6c931341 100644 --- a/drivers/gpu/drm/i915/intel_audio.c +++ b/drivers/gpu/drm/i915/intel_audio.c @@ -729,7 +729,7 @@ static void i915_audio_component_codec_wake_override(struct device *kdev, struct drm_i915_private *dev_priv = kdev_to_i915(kdev); u32 tmp; - if (!IS_GEN9_BC(dev_priv)) + if (!IS_GEN9_BC(dev_priv) && !IS_BROXTON(dev_priv)) return; i915_audio_component_get_power(kdev); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/perf: enable perf support on ICL
== Series Details == Series: drm/i915/perf: enable perf support on ICL URL : https://patchwork.freedesktop.org/series/39689/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight: incomplete -> PASS (shard-apl) fdo#105341 Test kms_cursor_crc: Subgroup cursor-256x256-suspend: incomplete -> PASS (shard-hsw) fdo#103375 Test kms_vblank: Subgroup pipe-a-ts-continuation-dpms-suspend: incomplete -> PASS (shard-hsw) fdo#103540 Test pm_lpsp: Subgroup screens-disabled: pass -> FAIL (shard-hsw) fdo#104941 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941 shard-apltotal:3467 pass:1825 dwarn:1 dfail:0 fail:8 skip:1632 time:12305s shard-hswtotal:3467 pass:1772 dwarn:1 dfail:0 fail:2 skip:1691 time:11713s shard-snbtotal:3467 pass:1363 dwarn:1 dfail:0 fail:2 skip:2101 time:6906s Blacklisted hosts: shard-kbltotal:3381 pass:1882 dwarn:14 dfail:1 fail:10 skip:1473 time:8809s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8289/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 [v3,1/4] drm: Add drm_any_plane_has_format()
== Series Details == Series: series starting with [v3,1/4] drm: Add drm_any_plane_has_format() URL : https://patchwork.freedesktop.org/series/39700/ State : success == Summary == Series 39700v1 series starting with [v3,1/4] drm: Add drm_any_plane_has_format() https://patchwork.freedesktop.org/api/1.0/series/39700/revisions/1/mbox/ Known issues: Test debugfs_test: Subgroup read_all_entries: incomplete -> PASS (fi-snb-2520m) fdo#103713 Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:429s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:425s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:372s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:500s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:277s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:490s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:490s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:479s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:467s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:404s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:571s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:580s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:419s fi-gdg-551 total:288 pass:180 dwarn:0 dfail:0 fail:0 skip:108 time:288s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:516s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:395s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:407s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:466s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:421s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:469s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:463s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:504s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:578s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:431s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:521s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:534s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:495s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:493s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:425s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:431s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:524s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:388s Blacklisted hosts: fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:505s fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:513s 2e2ef5a5221a7469ecd72c68ed15dd8b94e2e0c6 drm-tip: 2018y-03m-09d-14h-28m-10s UTC integration manifest d866fde8c9bc drm/vc4: Validate framebuffer pixel format/modifier 95156651bb61 drm: Fix some coding style issues e82cc7382b48 drm/i915: Eliminate the horrendous format check code 06e78ca5ab60 drm: Add drm_any_plane_has_format() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8291/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm: Fix some coding style issues
From: Ville Syrjälä Put an empty line between the variable declarations and the code, and use tabs for alignment. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_framebuffer.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c index c0530a1af5e3..7df025669067 100644 --- a/drivers/gpu/drm/drm_framebuffer.c +++ b/drivers/gpu/drm/drm_framebuffer.c @@ -162,9 +162,10 @@ static int framebuffer_check(struct drm_device *dev, info = __drm_format_info(r->pixel_format & ~DRM_FORMAT_BIG_ENDIAN); if (!info) { struct drm_format_name_buf format_name; + DRM_DEBUG_KMS("bad framebuffer format %s\n", - drm_get_format_name(r->pixel_format, - &format_name)); + drm_get_format_name(r->pixel_format, + &format_name)); return -EINVAL; } -- 2.16.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/4] drm/i915: Eliminate the horrendous format check code
From: Ville Syrjälä Replace the messy framebuffer format/modifier validation code with a single call to drm_any_plane_has_format(). The code was extremely annoying to maintain as you had to have a lot of platform checks for different formats. The new code requires zero maintenance. v2: Nuke the modifier checks as well since the core does that too now v3: Call drm_any_plane_has_format() from the driver code Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 90 1 file changed, 8 insertions(+), 82 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 2933ad38094f..7f06fa83d894 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -13989,7 +13989,6 @@ static int intel_framebuffer_init(struct intel_framebuffer *intel_fb, { struct drm_i915_private *dev_priv = to_i915(obj->base.dev); struct drm_framebuffer *fb = &intel_fb->base; - struct drm_format_name_buf format_name; u32 pitch_limit; unsigned int tiling, stride; int ret = -EINVAL; @@ -14020,33 +14019,14 @@ static int intel_framebuffer_init(struct intel_framebuffer *intel_fb, } } - /* Passed in modifier sanity checking. */ - switch (mode_cmd->modifier[0]) { - case I915_FORMAT_MOD_Y_TILED_CCS: - case I915_FORMAT_MOD_Yf_TILED_CCS: - switch (mode_cmd->pixel_format) { - case DRM_FORMAT_XBGR: - case DRM_FORMAT_ABGR: - case DRM_FORMAT_XRGB: - case DRM_FORMAT_ARGB: - break; - default: - DRM_DEBUG_KMS("RC supported only with RGB formats\n"); - goto err; - } - /* fall through */ - case I915_FORMAT_MOD_Y_TILED: - case I915_FORMAT_MOD_Yf_TILED: - if (INTEL_GEN(dev_priv) < 9) { - DRM_DEBUG_KMS("Unsupported tiling 0x%llx!\n", - mode_cmd->modifier[0]); - goto err; - } - case DRM_FORMAT_MOD_LINEAR: - case I915_FORMAT_MOD_X_TILED: - break; - default: - DRM_DEBUG_KMS("Unsupported fb modifier 0x%llx!\n", + if (!drm_any_plane_has_format(&dev_priv->drm, + mode_cmd->pixel_format, + mode_cmd->modifier[0])) { + struct drm_format_name_buf format_name; + + DRM_DEBUG_KMS("unsupported pixel format %s / modifier 0x%llx\n", + drm_get_format_name(mode_cmd->pixel_format, + &format_name), mode_cmd->modifier[0]); goto err; } @@ -14081,60 +14061,6 @@ static int intel_framebuffer_init(struct intel_framebuffer *intel_fb, goto err; } - /* Reject formats not supported by any plane early. */ - switch (mode_cmd->pixel_format) { - case DRM_FORMAT_C8: - case DRM_FORMAT_RGB565: - case DRM_FORMAT_XRGB: - case DRM_FORMAT_ARGB: - break; - case DRM_FORMAT_XRGB1555: - if (INTEL_GEN(dev_priv) > 3) { - DRM_DEBUG_KMS("unsupported pixel format: %s\n", - drm_get_format_name(mode_cmd->pixel_format, &format_name)); - goto err; - } - break; - case DRM_FORMAT_ABGR: - if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv) && - INTEL_GEN(dev_priv) < 9) { - DRM_DEBUG_KMS("unsupported pixel format: %s\n", - drm_get_format_name(mode_cmd->pixel_format, &format_name)); - goto err; - } - break; - case DRM_FORMAT_XBGR: - case DRM_FORMAT_XRGB2101010: - case DRM_FORMAT_XBGR2101010: - if (INTEL_GEN(dev_priv) < 4) { - DRM_DEBUG_KMS("unsupported pixel format: %s\n", - drm_get_format_name(mode_cmd->pixel_format, &format_name)); - goto err; - } - break; - case DRM_FORMAT_ABGR2101010: - if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) { - DRM_DEBUG_KMS("unsupported pixel format: %s\n", - drm_get_format_name(mode_cmd->pixel_format, &format_name)); - goto err; - } - break; - case DRM_FORMAT_YUYV: - case DRM_FORMAT_UYVY: - case DRM_FORMAT_YVYU: - case DRM_FORMAT_VYUY: - if (INTEL_GEN(dev_priv) < 5 && !IS_G4X(dev_pri
[Intel-gfx] [PATCH 4/4] drm/vc4: Validate framebuffer pixel format/modifier
From: Ville Syrjälä Only create framebuffers with supported format/modifier combinations by checking that at least one plane supports the requested combination. Using drm_any_plane_has_format() is somewhat suboptimal for vc4 since the planes have (mostly) uniform capabilities. But I was lazy and didn't feel like exporting drm_plane_format_check() and hand rolling anything better. Also I really just wanted to come up with another user for drm_any_plane_has_format() ;) Compile tested only. Cc: Eric Anholt Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/vc4/vc4_kms.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c index ba60153dddb5..b6f15102dda0 100644 --- a/drivers/gpu/drm/vc4/vc4_kms.c +++ b/drivers/gpu/drm/vc4/vc4_kms.c @@ -184,6 +184,17 @@ static struct drm_framebuffer *vc4_fb_create(struct drm_device *dev, mode_cmd = &mode_cmd_local; } + if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format, + mode_cmd->modifier[0])) { + struct drm_format_name_buf format_name; + + DRM_DEBUG_KMS("unsupported pixel format %s / modifier 0x%llx\n", + drm_get_format_name(mode_cmd->pixel_format, + &format_name), + mode_cmd->modifier[0]); + return ERR_PTR(-EINVAL); + } + return drm_gem_fb_create(dev, file_priv, mode_cmd); } -- 2.16.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/4] drm: Add drm_any_plane_has_format()
From: Ville Syrjälä Add a function to check whether there is at least one plane that supports a specific format and modifier combination. Drivers can use this to reject unsupported formats/modifiers in .fb_create(). v2: Accept anyformat if the driver doesn't do planes (Eric) s/planes_have_format/any_plane_has_format/ (Eric) Check the modifier as well since we already have a function that does both v3: Don't do the check in the core since we may not know the modifier yet, instead export the function and let drivers call it themselves Cc: Eric Anholt Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_plane.c | 23 +++ include/drm/drm_mode_config.h | 6 ++ include/drm/drm_plane.h | 2 ++ 3 files changed, 31 insertions(+) diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index a5d1fc7e8a37..3b2d6f8d889d 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -578,6 +578,29 @@ int drm_plane_check_pixel_format(struct drm_plane *plane, return 0; } +/** + * drm_any_plane_has_format - Check whether any plane supports this format and modifier combination + * @dev: DRM device + * @format: pixel format (DRM_FORMAT_*) + * @modifier: data layout modifier + * + * Returns: + * Whether at least one plane supports the specified format and modifier combination. + */ +bool drm_any_plane_has_format(struct drm_device *dev, + u32 format, u64 modifier) +{ + struct drm_plane *plane; + + drm_for_each_plane(plane, dev) { + if (drm_plane_check_pixel_format(plane, format, modifier) == 0) + return true; + } + + return false; +} +EXPORT_SYMBOL(drm_any_plane_has_format); + /* * __setplane_internal - setplane handler for internal callers * diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h index 7569f22ffef6..9b894de9a75d 100644 --- a/include/drm/drm_mode_config.h +++ b/include/drm/drm_mode_config.h @@ -52,6 +52,12 @@ struct drm_mode_config_funcs { * requested metadata, but most of that is left to the driver. See * &struct drm_mode_fb_cmd2 for details. * +* To validate the pixel format and modifier drivers can use +* drm_any_plane_has_format() to make sure at least one plane supports +* the requested values. Note that the driver must first determine the +* actual modifier used if the request doesn't have it specified, +* ie. when (@mode_cmd->flags & DRM_MODE_FB_MODIFIERS) == 0. +* * If the parameters are deemed valid and the backing storage objects in * the underlying memory manager all exist, then the driver allocates * a new &drm_framebuffer structure, subclassed to contain diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h index f7bf4a48b1c3..930e8fdd90f8 100644 --- a/include/drm/drm_plane.h +++ b/include/drm/drm_plane.h @@ -683,5 +683,7 @@ static inline struct drm_plane *drm_plane_find(struct drm_device *dev, #define drm_for_each_plane(plane, dev) \ list_for_each_entry(plane, &(dev)->mode_config.plane_list, head) +bool drm_any_plane_has_format(struct drm_device *dev, + u32 format, u64 modifier); #endif -- 2.16.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH igt] igt/gem_mocs_settings: Wait for RC6 EI before polling
On Fri, Mar 09, 2018 at 10:42:40AM +, Chris Wilson wrote: > On bxt, we see that the rc6 subtest flip-flops as RC6 does not restart > within our desired interval. Improve the likelihood of the inspection > passing by idling the GPU and waiting for 2 Evaluation Intervals before > we start polling of RC6 residency. I'd stick with pure gem_quiescent_gpu() since we're already polling for waay longer than that. Either way: Reviewed-by: Michał Winiarski -Michał > > Signed-off-by: Chris Wilson > --- > tests/gem_mocs_settings.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/tests/gem_mocs_settings.c b/tests/gem_mocs_settings.c > index 9705fbfd..85fd637a 100644 > --- a/tests/gem_mocs_settings.c > +++ b/tests/gem_mocs_settings.c > @@ -336,12 +336,15 @@ static uint32_t rc6_residency(int dir) > > static void rc6_wait(int fd) > { > - int sysfs; > uint32_t residency; > + int sysfs; > > sysfs = igt_sysfs_open(fd, NULL); > igt_assert_lte(0, sysfs); > > + gem_quiescent_gpu(fd); > + usleep(320e3); /* Wait for 2 EIs before polling; should now be active */ > + > residency = rc6_residency(sysfs); > igt_require(igt_wait(rc6_residency(sysfs) != residency, 1, 2)); > > -- > 2.16.2 > > ___ > igt-dev mailing list > igt-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/igt-dev ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Only call tasklet_kill() on the first prepare_reset
Quoting Chris Wilson (2018-03-09 14:10:34) > Quoting Chris Wilson (2018-03-07 13:42:26) > > tasklet_kill() will spin waiting for the current tasklet to be executed. > > However, if tasklet_disable() has been called, then the tasklet is never > > executed but permanently put back onto the runlist until > > tasklet_enable() is called. Ergo, we cannot use tasklet_kill() inside a > > disable/enable pair. This is the case when we call set-wedge from inside > > i915_reset(), and another request was submitted to us concurrent to the > > reset. > > > > Fixes: 963ddd63c314 ("drm/i915: Suspend submission tasklets around wedging") > > Signed-off-by: Chris Wilson > > Cc: Mika Kuoppala > > --- > > drivers/gpu/drm/i915/i915_gem.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c > > b/drivers/gpu/drm/i915/i915_gem.c > > index 3b44952e089f..e75af06904b7 100644 > > --- a/drivers/gpu/drm/i915/i915_gem.c > > +++ b/drivers/gpu/drm/i915/i915_gem.c > > @@ -2941,7 +2941,8 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs > > *engine) > > * Turning off the execlists->tasklet until the reset is over > > * prevents the race. > > */ > > - tasklet_kill(&engine->execlists.tasklet); > > + if (!atomic_read(&engine->execlists.tasklet.count)) > > + tasklet_kill(&engine->execlists.tasklet); > > Note this is racy; two separate atomic operations. The only race we have > is with set-wedge vs reset, which is a rare and already contentious > issue. The upside of preventing the lockup is that we don't lose the > machine. > > +* Note that this needs to be a single atomic operation on the > +* tasklet (flush existing tasks, prevent new tasks) to prevent > +* a race between reset and set-wedged. It is not, so we do the best > +* we can atm and make sure we don't lock the machine up in the more > +* common case of recursing calling set-wedged from inside i915_reset. The alternative is to not try and do tasklet_kill() here. But that has the side-effect of leaving it spinning if it was running at the same time as the suspend. Hmm, for the moment I'll go with the comment and see how inspired we are once gem_eio stops dieing. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: enable perf support on ICL
On 09/03/18 13:49, Matthew Auld wrote: On 9 March 2018 at 11:58, Lionel Landwerlin wrote: No significant changes from either context offsets, nor report formats, nor register whitelist. Signed-off-by: Lionel Landwerlin --- The usual spiel about disabling clock-ratio-change reports, do we need it? Dammit :) So this will need the timestamp frequency stuff for gen11, should that go in before this, or don't we care? I'll wait for that to land indeed. Thanks a lot! Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Only call tasklet_kill() on the first prepare_reset
Quoting Chris Wilson (2018-03-07 13:42:26) > tasklet_kill() will spin waiting for the current tasklet to be executed. > However, if tasklet_disable() has been called, then the tasklet is never > executed but permanently put back onto the runlist until > tasklet_enable() is called. Ergo, we cannot use tasklet_kill() inside a > disable/enable pair. This is the case when we call set-wedge from inside > i915_reset(), and another request was submitted to us concurrent to the > reset. > > Fixes: 963ddd63c314 ("drm/i915: Suspend submission tasklets around wedging") > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_gem.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 3b44952e089f..e75af06904b7 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -2941,7 +2941,8 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs > *engine) > * Turning off the execlists->tasklet until the reset is over > * prevents the race. > */ > - tasklet_kill(&engine->execlists.tasklet); > + if (!atomic_read(&engine->execlists.tasklet.count)) > + tasklet_kill(&engine->execlists.tasklet); Note this is racy; two separate atomic operations. The only race we have is with set-wedge vs reset, which is a rare and already contentious issue. The upside of preventing the lockup is that we don't lose the machine. +* Note that this needs to be a single atomic operation on the +* tasklet (flush existing tasks, prevent new tasks) to prevent +* a race between reset and set-wedged. It is not, so we do the best +* we can atm and make sure we don't lock the machine up in the more +* common case of recursing calling set-wedged from inside i915_reset. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Only call tasklet_kill() on the first prepare_reset
Chris Wilson writes: > tasklet_kill() will spin waiting for the current tasklet to be executed. > However, if tasklet_disable() has been called, then the tasklet is never > executed but permanently put back onto the runlist until > tasklet_enable() is called. Ergo, we cannot use tasklet_kill() inside a > disable/enable pair. This is the case when we call set-wedge from inside > i915_reset(), and another request was submitted to us concurrent to the > reset. > > Fixes: 963ddd63c314 ("drm/i915: Suspend submission tasklets around wedging") > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_gem.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 3b44952e089f..e75af06904b7 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -2941,7 +2941,8 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs > *engine) >* Turning off the execlists->tasklet until the reset is over >* prevents the race. >*/ > - tasklet_kill(&engine->execlists.tasklet); > + if (!atomic_read(&engine->execlists.tasklet.count)) > + tasklet_kill(&engine->execlists.tasklet); As discussed in irc, this might warrant comment that it is our tasklet of which count we are racily investigating here, so the race does not matter in the path we avoid killing. Reviewed-by: Mika Kuoppala > tasklet_disable(&engine->execlists.tasklet); > > /* > -- > 2.16.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx
Exercise some new API that allows applications to request that individual contexts are executed within a desired frequency range. v2: Split single/continuous set_freq subtests v3: Do an up/down ramp for individual freq request, check nothing changes after each invalid request Signed-off-by: Chris Wilson Cc: Paneri, Praveen Cc: Kamble, Sagar A Cc: Antonio Argenziano --- tests/Makefile.am | 1 + tests/Makefile.sources | 1 + tests/gem_ctx_freq.c | 648 + tests/meson.build | 1 + 4 files changed, 651 insertions(+) create mode 100644 tests/gem_ctx_freq.c diff --git a/tests/Makefile.am b/tests/Makefile.am index dbc7be72..389f7fc7 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -104,6 +104,7 @@ drm_import_export_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS) drm_import_export_LDADD = $(LDADD) -lpthread gem_close_race_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS) gem_close_race_LDADD = $(LDADD) -lpthread +gem_ctx_freq_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la gem_ctx_thrash_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS) gem_ctx_thrash_LDADD = $(LDADD) -lpthread gem_exec_parallel_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS) diff --git a/tests/Makefile.sources b/tests/Makefile.sources index 4a81ac4a..3d079c42 100644 --- a/tests/Makefile.sources +++ b/tests/Makefile.sources @@ -58,6 +58,7 @@ TESTS_progs = \ gem_ctx_bad_exec \ gem_ctx_create \ gem_ctx_exec \ + gem_ctx_freq \ gem_ctx_isolation \ gem_ctx_param \ gem_ctx_switch \ diff --git a/tests/gem_ctx_freq.c b/tests/gem_ctx_freq.c new file mode 100644 index ..f3cee838 --- /dev/null +++ b/tests/gem_ctx_freq.c @@ -0,0 +1,648 @@ +/* + * Copyright © 2018 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 +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "igt.h" +#include "igt_perf.h" + +#define LOCAL_CONTEXT_PARAM_FREQUENCY 7 + +#define SAMPLE_PERIOD (USEC_PER_SEC / 10) + +static int __set_freq(int fd, uint32_t ctx, uint32_t min, uint32_t max) +{ + struct drm_i915_gem_context_param param = { + .ctx_id = ctx, + .param = LOCAL_CONTEXT_PARAM_FREQUENCY, + .value = (uint64_t)max << 32 | min, + }; + + return __gem_context_set_param(fd, ¶m); +} + +static void set_freq(int fd, uint32_t ctx, uint32_t min, uint32_t max) +{ + igt_assert_eq(__set_freq(fd, ctx, min, max), 0); +} + +static void get_freq(int fd, uint32_t ctx, uint32_t *min, uint32_t *max) +{ + struct drm_i915_gem_context_param param = { + .ctx_id = ctx, + .param = LOCAL_CONTEXT_PARAM_FREQUENCY, + }; + + gem_context_get_param(fd, ¶m); + + *min = param.value & 0x; + *max = param.value >> 32; +} + +static double measure_frequency(int pmu, int period_us) +{ + uint64_t data[2]; + uint64_t d_t, d_v; + + igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data)); + d_v = -data[0]; + d_t = -data[1]; + + usleep(period_us); + + igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data)); + d_v += data[0]; + d_t += data[1]; + + return d_v * 1e9 / d_t; +} + +static void single(int fd, const struct intel_execution_engine *e) +{ +#define N_STEPS 10 + const unsigned int engine = e->exec_id | e->flags; + uint32_t ctx = gem_context_create(fd); + uint32_t min, max; + double measured; + igt_spin_t *spin; + int pmu; + + get_freq(fd, ctx, &min, &max); + igt_info("Min freq: %dMHz; Max freq: %dMHz\n", min, max); + + pmu = perf_i915_open(I915_PMU_REQUESTED_FREQUENCY); + igt_require(pmu >= 0); + + for (int step = 0; step <= 2*N_STEPS; step++) { + int frac = step > N_
[Intel-gfx] ✓ Fi.CI.BAT: success for CNL port refactoring (rev2)
== Series Details == Series: CNL port refactoring (rev2) URL : https://patchwork.freedesktop.org/series/38334/ State : success == Summary == Series 38334v2 CNL port refactoring https://patchwork.freedesktop.org/api/1.0/series/38334/revisions/2/mbox/ Known issues: Test kms_frontbuffer_tracking: Subgroup basic: fail -> PASS (fi-cnl-y3) fdo#103167 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: dmesg-warn -> PASS (fi-skl-6700k2) fdo#103191 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:422s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:426s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:372s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:509s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:280s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:489s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:500s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:487s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:475s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:407s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:576s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:581s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:415s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:291s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:514s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:404s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:419s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:453s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:423s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:469s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:463s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:510s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:590s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:429s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:523s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:534s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:497s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:488s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:420s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:514s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:395s Blacklisted hosts: fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:519s 074e834cb3cccf697895a7dc471d324c2309a610 drm-tip: 2018y-03m-09d-10h-30m-56s UTC integration manifest d271c009a148 drm/i915/cnl: Kill _MMIO_PORT6 macro 5a42fe815c97 drm/i915/cnl: Replace PORT_TX register macros with new ones 08448452816c drm/i915/cnl; Add macro to get PORT_TX register == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8290/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Update ring position from request on retiring
Quoting Mika Kuoppala (2018-03-09 13:38:37) > Chris Wilson writes: > > > When wedged, we do not update the ring->tail as we submit the requests > > causing us to leak the ring->space upon cleaning up the wedged driver. > > We can just use the value stored in rq->tail, and keep the submission > > backend details away from set-wedge. > > > > Signed-off-by: Chris Wilson > > Cc: Mika Kuoppala > > --- > > drivers/gpu/drm/i915/i915_request.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_request.c > > b/drivers/gpu/drm/i915/i915_request.c > > index efa9ee557f31..69b378a323fc 100644 > > --- a/drivers/gpu/drm/i915/i915_request.c > > +++ b/drivers/gpu/drm/i915/i915_request.c > > @@ -358,7 +358,7 @@ static void advance_ring(struct i915_request *request) > >* is just about to be. Either works, if we miss the last two > >* noops - they are safe to be replayed on a reset. > >*/ > > - tail = READ_ONCE(request->ring->tail); > > + tail = READ_ONCE(request->tail); > > I tried to think if we need the READ_ONCE here anymore. I tried as well to see if the comment was still correct. It still is due to that we can retire before we see the context-switch interrupt. > But as this is the safest version, > Reviewed-by: Mika Kuoppala > > Noticed that request->tail is not cleared on i915_request_alloc. > > If we would set rq->head = rq->tail = rq->ring->emit > we could use rq->head == rq->tail to assert that > we screw up something major during the request lifetime. Heh, if we get a stray write here, we're going to get stray writes everywhere :) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Wrap engine->schedule in RCU locks for set-wedge protection
Chris Wilson writes: > Similar to the staging around handling of engine->submit_request, we > need to stop adding to the execlists->queue prior to calling > engine->cancel_requests. cancel_requests will move requests from the > queue onto the timeline, so if we add a request onto the queue after that > point, it will be lost. > > Fixes: af7a8ffad9c5 ("drm/i915: Use rcu instead of stop_machine in > set_wedged") > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_gem.c | 13 +++-- > drivers/gpu/drm/i915/i915_request.c | 2 ++ > 2 files changed, 9 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 30cd07ebcb8e..3b44952e089f 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -471,10 +471,11 @@ static void __fence_set_priority(struct dma_fence > *fence, int prio) > > rq = to_request(fence); > engine = rq->engine; > - if (!engine->schedule) > - return; > > - engine->schedule(rq, prio); > + rcu_read_lock(); > + if (engine->schedule) > + engine->schedule(rq, prio); > + rcu_read_unlock(); > } > > static void fence_set_priority(struct dma_fence *fence, int prio) > @@ -3214,8 +3215,11 @@ void i915_gem_set_wedged(struct drm_i915_private *i915) >*/ > for_each_engine(engine, i915, id) { > i915_gem_reset_prepare_engine(engine); > + > engine->submit_request = nop_submit_request; > + engine->schedule = NULL; > } > + i915->caps.scheduler = 0; > > /* >* Make sure no one is running the old callback before we proceed with > @@ -3233,11 +3237,8 @@ void i915_gem_set_wedged(struct drm_i915_private *i915) >* start to complete all requests. >*/ > engine->submit_request = nop_complete_submit_request; > - engine->schedule = NULL; > } > > - i915->caps.scheduler = 0; > - > /* >* Make sure no request can slip through without getting completed by >* either this call here to intel_engine_init_global_seqno, or the one > diff --git a/drivers/gpu/drm/i915/i915_request.c > b/drivers/gpu/drm/i915/i915_request.c > index 69b378a323fc..0258449579f8 100644 > --- a/drivers/gpu/drm/i915/i915_request.c > +++ b/drivers/gpu/drm/i915/i915_request.c > @@ -1082,8 +1082,10 @@ void __i915_request_add(struct i915_request *request, > bool flush_caches) >* decide whether to preempt the entire chain so that it is ready to >* run at the earliest possible convenience. >*/ > + rcu_read_lock(); > if (engine->schedule) > engine->schedule(request, request->ctx->priority); > + rcu_read_unlock(); > > local_bh_disable(); > i915_sw_fence_commit(&request->submit); > -- > 2.16.2 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: Include ring->emit in debugging
Chris Wilson writes: > Include ring->emit and ring->space alongside ring->(head,tail) when > printing debug information. > > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_debugfs.c| 4 ++-- > drivers/gpu/drm/i915/intel_engine_cs.c | 10 +++--- > 2 files changed, 9 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index e838c765b251..4de0a52f14a9 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -1923,8 +1923,8 @@ static int i915_gem_framebuffer_info(struct seq_file > *m, void *data) > > static void describe_ctx_ring(struct seq_file *m, struct intel_ring *ring) > { > - seq_printf(m, " (ringbuffer, space: %d, head: %u, tail: %u)", > -ring->space, ring->head, ring->tail); > + seq_printf(m, " (ringbuffer, space: %d, head: %u, tail: %u, emit: %u)", > +ring->space, ring->head, ring->tail, ring->emit); > } > > static int i915_context_status(struct seq_file *m, void *unused) > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c > b/drivers/gpu/drm/i915/intel_engine_cs.c > index 4ba139c27fba..e71bd6951d9b 100644 > --- a/drivers/gpu/drm/i915/intel_engine_cs.c > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c > @@ -1929,12 +1929,16 @@ void intel_engine_dump(struct intel_engine_cs *engine, > rq->head, rq->postfix, rq->tail, > rq->batch ? upper_32_bits(rq->batch->node.start) : > ~0u, > rq->batch ? lower_32_bits(rq->batch->node.start) : > ~0u); > - drm_printf(m, "\t\tring->start: 0x%08x\n", > + drm_printf(m, "\t\tring->start : 0x%08x\n", Please check the space before ':', seems unintentional. Reviewed-by: Mika Kuoppala > i915_ggtt_offset(rq->ring->vma)); > - drm_printf(m, "\t\tring->head: 0x%08x\n", > + drm_printf(m, "\t\tring->head: 0x%08x\n", > rq->ring->head); > - drm_printf(m, "\t\tring->tail: 0x%08x\n", > + drm_printf(m, "\t\tring->tail: 0x%08x\n", > rq->ring->tail); > + drm_printf(m, "\t\tring->emit: 0x%08x\n", > +rq->ring->emit); > + drm_printf(m, "\t\tring->space: 0x%08x\n", > +rq->ring->space); > } > > rcu_read_unlock(); > -- > 2.16.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: enable perf support on ICL
On 9 March 2018 at 11:58, Lionel Landwerlin wrote: > No significant changes from either context offsets, nor report > formats, nor register whitelist. > > Signed-off-by: Lionel Landwerlin > --- The usual spiel about disabling clock-ratio-change reports, do we need it? So this will need the timestamp frequency stuff for gen11, should that go in before this, or don't we care? Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Update ring position from request on retiring
Chris Wilson writes: > When wedged, we do not update the ring->tail as we submit the requests > causing us to leak the ring->space upon cleaning up the wedged driver. > We can just use the value stored in rq->tail, and keep the submission > backend details away from set-wedge. > > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_request.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_request.c > b/drivers/gpu/drm/i915/i915_request.c > index efa9ee557f31..69b378a323fc 100644 > --- a/drivers/gpu/drm/i915/i915_request.c > +++ b/drivers/gpu/drm/i915/i915_request.c > @@ -358,7 +358,7 @@ static void advance_ring(struct i915_request *request) >* is just about to be. Either works, if we miss the last two >* noops - they are safe to be replayed on a reset. >*/ > - tail = READ_ONCE(request->ring->tail); > + tail = READ_ONCE(request->tail); I tried to think if we need the READ_ONCE here anymore. But as this is the safest version, Reviewed-by: Mika Kuoppala Noticed that request->tail is not cleared on i915_request_alloc. If we would set rq->head = rq->tail = rq->ring->emit we could use rq->head == rq->tail to assert that we screw up something major during the request lifetime. -Mika > } else { > tail = request->postfix; > } > -- > 2.16.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Reset ring space estimate after unwinding the request
Quoting Mika Kuoppala (2018-03-09 13:17:09) > Chris Wilson writes: > > > With a series of unusual events (a sequence of interrupted request > > allocations), we could gradually leak the ring->space estimate by > > unwinding the ring back to the start of the request, but not return the > > used space back to the ring. Eventually and with great misfortune, it > > would be possible to trigger ring->space exhaustion with no requests on > > the ring. > > > > Signed-off-by: Chris Wilson > > Cc: Mika Kuoppala > > --- > > drivers/gpu/drm/i915/i915_request.c | 1 + > > drivers/gpu/drm/i915/intel_ringbuffer.c | 1 + > > 2 files changed, 2 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/i915_request.c > > b/drivers/gpu/drm/i915/i915_request.c > > index d437beac3969..efa9ee557f31 100644 > > --- a/drivers/gpu/drm/i915/i915_request.c > > +++ b/drivers/gpu/drm/i915/i915_request.c > > @@ -798,6 +798,7 @@ i915_request_alloc(struct intel_engine_cs *engine, > > struct i915_gem_context *ctx) > > > > err_unwind: > > rq->ring->emit = rq->head; > > + intel_ring_update_space(rq->ring); > > > > /* Make sure we didn't add ourselves to external state before freeing > > */ > > GEM_BUG_ON(!list_empty(&rq->active_list)); > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c > > b/drivers/gpu/drm/i915/intel_ringbuffer.c > > index 1d599524a759..88eeb64041ae 100644 > > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c > > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c > > @@ -1593,6 +1593,7 @@ static noinline int wait_for_space(struct intel_ring > > *ring, unsigned int bytes) > > if (intel_ring_update_space(ring) >= bytes) > > return 0; > > > > + GEM_BUG_ON(list_empty(&ring->request_list)); > > At some point, after long series of misfortunate events, we > will add a first request and need actually wait a space for this > and then we kaboom in here? That's the experience. However, I don't think this patch helps because we do the intel_ring_update_space() here inside wait_for_space anyway, so it should come out in the wash so long as we aren't corrupting the ring space calculation. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Reset ring space estimate after unwinding the request
Chris Wilson writes: > With a series of unusual events (a sequence of interrupted request > allocations), we could gradually leak the ring->space estimate by > unwinding the ring back to the start of the request, but not return the > used space back to the ring. Eventually and with great misfortune, it > would be possible to trigger ring->space exhaustion with no requests on > the ring. > > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_request.c | 1 + > drivers/gpu/drm/i915/intel_ringbuffer.c | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_request.c > b/drivers/gpu/drm/i915/i915_request.c > index d437beac3969..efa9ee557f31 100644 > --- a/drivers/gpu/drm/i915/i915_request.c > +++ b/drivers/gpu/drm/i915/i915_request.c > @@ -798,6 +798,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct > i915_gem_context *ctx) > > err_unwind: > rq->ring->emit = rq->head; > + intel_ring_update_space(rq->ring); > > /* Make sure we didn't add ourselves to external state before freeing */ > GEM_BUG_ON(!list_empty(&rq->active_list)); > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c > b/drivers/gpu/drm/i915/intel_ringbuffer.c > index 1d599524a759..88eeb64041ae 100644 > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c > @@ -1593,6 +1593,7 @@ static noinline int wait_for_space(struct intel_ring > *ring, unsigned int bytes) > if (intel_ring_update_space(ring) >= bytes) > return 0; > > + GEM_BUG_ON(list_empty(&ring->request_list)); At some point, after long series of misfortunate events, we will add a first request and need actually wait a space for this and then we kaboom in here? -Mika > list_for_each_entry(target, &ring->request_list, ring_link) { > /* Would completion of this request free enough space? */ > if (bytes <= __intel_ring_space(target->postfix, > -- > 2.16.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Reset ring space estimate after unwinding the request
Quoting Chris Wilson (2018-03-07 13:42:22) > With a series of unusual events (a sequence of interrupted request > allocations), we could gradually leak the ring->space estimate by > unwinding the ring back to the start of the request, but not return the > used space back to the ring. Eventually and with great misfortune, it > would be possible to trigger ring->space exhaustion with no requests on > the ring. > > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_request.c | 1 + > drivers/gpu/drm/i915/intel_ringbuffer.c | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_request.c > b/drivers/gpu/drm/i915/i915_request.c > index d437beac3969..efa9ee557f31 100644 > --- a/drivers/gpu/drm/i915/i915_request.c > +++ b/drivers/gpu/drm/i915/i915_request.c > @@ -798,6 +798,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct > i915_gem_context *ctx) > > err_unwind: > rq->ring->emit = rq->head; > + intel_ring_update_space(rq->ring); Ok, skip this one as we will correct ourselves next time we wait_for_space. It's just the next one where we weren't maintaining ring->tail that was the issue. -Chris ___ 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_chamelium: Make tests run without pipe color management support.
On Fri, Mar 09, 2018 at 12:55:24PM +0100, Maarten Lankhorst wrote: > Op 06-03-18 om 16:57 schreef Maxime Ripard: > > Hi, > > > > On Mon, Mar 05, 2018 at 07:14:16PM +0100, Maarten Lankhorst wrote: > >> Only try to set those values if the properties are supported. > >> This fixes the kms_chameium tests to run on vc4 again. > >> > >> Reported-by: Maxime Ripard > >> Cc: Paul Kocialkowski > >> Cc: Eric Anholt > >> Cc: Boris Brezillon > >> Signed-off-by: Maarten Lankhorst > > This works like a charm now, thanks! > > Tested-by: Maxime Ripard > > > > Maxime > > > Can you upgrade this to a reviewed-by so I can apply this change? Yep, of course: Reviewed-by: Maxime Ripard -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915: Finish the wait-for-wedge by retiring all the inflight requests
Chris Wilson writes: > Before we reset the GPU after marking the device as wedged, we wait for > all the remaining requests to be completed (and marked as EIO). > Afterwards, we should flush the request lists so the next batch start > with the driver in an idle start. s/start/state? > > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_gem.c | 11 --- > 1 file changed, 8 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index a5bd07338b46..30cd07ebcb8e 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -3273,7 +3273,8 @@ bool i915_gem_unset_wedged(struct drm_i915_private > *i915) > if (!test_bit(I915_WEDGED, &i915->gpu_error.flags)) > return true; > > - /* Before unwedging, make sure that all pending operations > + /* > + * Before unwedging, make sure that all pending operations >* are flushed and errored out - we may have requests waiting upon >* third party fences. We marked all inflight requests as EIO, and >* every execbuf since returned EIO, for consistency we want all > @@ -3291,7 +3292,8 @@ bool i915_gem_unset_wedged(struct drm_i915_private > *i915) > if (!rq) > continue; > > - /* We can't use our normal waiter as we want to > + /* > + * We can't use our normal waiter as we want to >* avoid recursively trying to handle the current >* reset. The basic dma_fence_default_wait() installs >* a callback for dma_fence_signal(), which is > @@ -3306,8 +3308,11 @@ bool i915_gem_unset_wedged(struct drm_i915_private > *i915) > return false; > } > } > + i915_retire_requests(i915); > + GEM_BUG_ON(i915->gt.active_requests); > > - /* Undo nop_submit_request. We prevent all new i915 requests from > + /* > + * Undo nop_submit_request. We prevent all new i915 requests from >* being queued (by disallowing execbuf whilst wedged) so having >* waited for all active requests above, we know the system is idle >* and do not have to worry about a thread being inside > -- > 2.16.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915/cnl: Replace PORT_TX register macros with new ones
This patch replaces CNL_PORT_TX register macros with new macros defined in previous patch. Signed-off-by: Mahesh Kumar --- drivers/gpu/drm/i915/i915_reg.h | 107 +--- 1 file changed, 11 insertions(+), 96 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 30ef3513dc6f..7987a3f85d04 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -1992,30 +1992,8 @@ enum i915_power_well_id { _CNL_PORT_TX_F_LN0_OFFSET) + \ 4*(dw)) -#define _CNL_PORT_TX_DW2_GRP_AE0x162348 -#define _CNL_PORT_TX_DW2_GRP_B 0x1623C8 -#define _CNL_PORT_TX_DW2_GRP_C 0x162B48 -#define _CNL_PORT_TX_DW2_GRP_D 0x162BC8 -#define _CNL_PORT_TX_DW2_GRP_F 0x162A48 -#define _CNL_PORT_TX_DW2_LN0_AE0x162448 -#define _CNL_PORT_TX_DW2_LN0_B 0x162648 -#define _CNL_PORT_TX_DW2_LN0_C 0x162C48 -#define _CNL_PORT_TX_DW2_LN0_D 0x162E48 -#define _CNL_PORT_TX_DW2_LN0_F 0x162848 -#define CNL_PORT_TX_DW2_GRP(port) _MMIO_PORT6(port, \ - _CNL_PORT_TX_DW2_GRP_AE, \ - _CNL_PORT_TX_DW2_GRP_B, \ - _CNL_PORT_TX_DW2_GRP_C, \ - _CNL_PORT_TX_DW2_GRP_D, \ - _CNL_PORT_TX_DW2_GRP_AE, \ - _CNL_PORT_TX_DW2_GRP_F) -#define CNL_PORT_TX_DW2_LN0(port) _MMIO_PORT6(port, \ - _CNL_PORT_TX_DW2_LN0_AE, \ - _CNL_PORT_TX_DW2_LN0_B, \ - _CNL_PORT_TX_DW2_LN0_C, \ - _CNL_PORT_TX_DW2_LN0_D, \ - _CNL_PORT_TX_DW2_LN0_AE, \ - _CNL_PORT_TX_DW2_LN0_F) +#define CNL_PORT_TX_DW2_GRP(port) _MMIO(CNL_PORT_TX_DW_GRP((port), 2)) +#define CNL_PORT_TX_DW2_LN0(port) _MMIO(CNL_PORT_TX_DW_LN0((port), 2)) #define SWING_SEL_UPPER(x) ((x >> 3) << 15) #define SWING_SEL_UPPER_MASK (1 << 15) #define SWING_SEL_LOWER(x) ((x & 0x7) << 11) @@ -2023,32 +2001,13 @@ enum i915_power_well_id { #define RCOMP_SCALAR(x) ((x) << 0) #define RCOMP_SCALAR_MASK(0xFF << 0) -#define _CNL_PORT_TX_DW4_GRP_AE0x162350 -#define _CNL_PORT_TX_DW4_GRP_B 0x1623D0 -#define _CNL_PORT_TX_DW4_GRP_C 0x162B50 -#define _CNL_PORT_TX_DW4_GRP_D 0x162BD0 -#define _CNL_PORT_TX_DW4_GRP_F 0x162A50 #define _CNL_PORT_TX_DW4_LN0_AE0x162450 #define _CNL_PORT_TX_DW4_LN1_AE0x1624D0 -#define _CNL_PORT_TX_DW4_LN0_B 0x162650 -#define _CNL_PORT_TX_DW4_LN0_C 0x162C50 -#define _CNL_PORT_TX_DW4_LN0_D 0x162E50 -#define _CNL_PORT_TX_DW4_LN0_F 0x162850 -#define CNL_PORT_TX_DW4_GRP(port) _MMIO_PORT6(port, \ - _CNL_PORT_TX_DW4_GRP_AE, \ - _CNL_PORT_TX_DW4_GRP_B, \ - _CNL_PORT_TX_DW4_GRP_C, \ - _CNL_PORT_TX_DW4_GRP_D, \ - _CNL_PORT_TX_DW4_GRP_AE, \ - _CNL_PORT_TX_DW4_GRP_F) -#define CNL_PORT_TX_DW4_LN(port, ln) _MMIO_PORT6_LN(port, ln,\ - _CNL_PORT_TX_DW4_LN0_AE, \ - _CNL_PORT_TX_DW4_LN1_AE, \ - _CNL_PORT_TX_DW4_LN0_B, \ - _CNL_PORT_TX_DW4_LN0_C, \ - _CNL_PORT_TX_DW4_LN0_D, \ - _CNL_PORT_TX_DW4_LN0_AE, \ - _CNL_PORT_TX_DW4_LN0_F) +#define CNL_PORT_TX_DW4_GRP(port) _MMIO(CNL_PORT_TX_DW_GRP((port), 4)) +#define CNL_PORT_TX_DW4_LN0(port) _MMIO(CNL_PORT_TX_DW_LN0((port), 4)) +#define CNL_PORT_TX_DW4_LN(port, ln) _MMIO(CNL_PORT_TX_DW_LN0((port), 4) + \ +(ln * (_CNL_PORT_TX_DW4_LN1_AE - \ + _CNL_PORT_TX_DW4_LN0_AE))) #define LOADGEN_SELECT (1 << 31) #define POST_CURSOR_1(x) ((x) << 12) #define POST_CURSOR_1_MASK (0x3F << 12) @@ -2057,30 +2016,8 @@ enum i915_power_well_id { #define CURSOR
[Intel-gfx] [PATCH 3/3] drm/i915/cnl: Kill _MMIO_PORT6 macro
This patch replaces use of remaining _MMIO_PORT6 macro and removes the macro. Signed-off-by: Mahesh Kumar --- drivers/gpu/drm/i915/i915_reg.h | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 7987a3f85d04..37742d774ba0 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -153,9 +153,6 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) #define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c)) #define _PLL(pll, a, b) ((a) + (pll)*((b)-(a))) #define _MMIO_PLL(pll, a, b) _MMIO(_PLL(pll, a, b)) -#define _MMIO_PORT6(port, a, b, c, d, e, f) _MMIO(_PICK(port, a, b, c, d, e, f)) -#define _MMIO_PORT6_LN(port, ln, a0, a1, b, c, d, e, f) \ - _MMIO(_PICK(port, a0, b, c, d, e, f) + (ln * (a1 - a0))) #define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__) #define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c)) @@ -1948,20 +1945,21 @@ enum i915_power_well_id { #define _CNL_PORT_PCS_DW1_LN0_C0x162C04 #define _CNL_PORT_PCS_DW1_LN0_D0x162E04 #define _CNL_PORT_PCS_DW1_LN0_F0x162804 -#define CNL_PORT_PCS_DW1_GRP(port) _MMIO_PORT6(port, \ +#define CNL_PORT_PCS_DW1_GRP(port) _MMIO(_PICK(port, \ _CNL_PORT_PCS_DW1_GRP_AE, \ _CNL_PORT_PCS_DW1_GRP_B, \ _CNL_PORT_PCS_DW1_GRP_C, \ _CNL_PORT_PCS_DW1_GRP_D, \ _CNL_PORT_PCS_DW1_GRP_AE, \ - _CNL_PORT_PCS_DW1_GRP_F) -#define CNL_PORT_PCS_DW1_LN0(port) _MMIO_PORT6(port, \ + _CNL_PORT_PCS_DW1_GRP_F)) + +#define CNL_PORT_PCS_DW1_LN0(port) _MMIO(_PICK(port, \ _CNL_PORT_PCS_DW1_LN0_AE, \ _CNL_PORT_PCS_DW1_LN0_B, \ _CNL_PORT_PCS_DW1_LN0_C, \ _CNL_PORT_PCS_DW1_LN0_D, \ _CNL_PORT_PCS_DW1_LN0_AE, \ - _CNL_PORT_PCS_DW1_LN0_F) + _CNL_PORT_PCS_DW1_LN0_F)) #define COMMON_KEEPER_EN (1 << 26) /* CNL Port TX registers */ -- 2.14.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/cnl; Add macro to get PORT_TX register
This patch creates a new macro to get PORT_TX register for any given DW. This will remove the need of defining register address for each port & DW. Signed-off-by: Mahesh Kumar --- drivers/gpu/drm/i915/i915_reg.h | 28 1 file changed, 28 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index e6a8c0ee7df1..30ef3513dc6f 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -1964,6 +1964,34 @@ enum i915_power_well_id { _CNL_PORT_PCS_DW1_LN0_F) #define COMMON_KEEPER_EN (1 << 26) +/* CNL Port TX registers */ +#define _CNL_PORT_TX_AE_GRP_OFFSET 0x162340 +#define _CNL_PORT_TX_B_GRP_OFFSET 0x1623C0 +#define _CNL_PORT_TX_C_GRP_OFFSET 0x162B40 +#define _CNL_PORT_TX_D_GRP_OFFSET 0x162BC0 +#define _CNL_PORT_TX_F_GRP_OFFSET 0x162A40 +#define _CNL_PORT_TX_AE_LN0_OFFSET 0x162440 +#define _CNL_PORT_TX_B_LN0_OFFSET 0x162640 +#define _CNL_PORT_TX_C_LN0_OFFSET 0x162C40 +#define _CNL_PORT_TX_D_LN0_OFFSET 0x162E40 +#define _CNL_PORT_TX_F_LN0_OFFSET 0x162840 +#define CNL_PORT_TX_DW_GRP(port, dw) (_PICK((port), \ + _CNL_PORT_TX_AE_GRP_OFFSET, \ + _CNL_PORT_TX_B_GRP_OFFSET, \ + _CNL_PORT_TX_B_GRP_OFFSET, \ + _CNL_PORT_TX_D_GRP_OFFSET, \ + _CNL_PORT_TX_AE_GRP_OFFSET, \ + _CNL_PORT_TX_F_GRP_OFFSET) + \ + 4*(dw)) +#define CNL_PORT_TX_DW_LN0(port, dw) (_PICK((port), \ + _CNL_PORT_TX_AE_LN0_OFFSET, \ + _CNL_PORT_TX_B_LN0_OFFSET, \ + _CNL_PORT_TX_B_LN0_OFFSET, \ + _CNL_PORT_TX_D_LN0_OFFSET, \ + _CNL_PORT_TX_AE_LN0_OFFSET, \ + _CNL_PORT_TX_F_LN0_OFFSET) + \ + 4*(dw)) + #define _CNL_PORT_TX_DW2_GRP_AE0x162348 #define _CNL_PORT_TX_DW2_GRP_B 0x1623C8 #define _CNL_PORT_TX_DW2_GRP_C 0x162B48 -- 2.14.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] CNL port refactoring
This series fixes CNL PORT_TX_DW5/7_LNO_D register address. This series also introduces macros to get register address of CNL_PORT_TX registers instead of defining for each DW instance. changes since V1: completely kill _MMIO_PORT6 macro Mahesh Kumar (3): drm/i915/cnl; Add macro to get PORT_TX register drm/i915/cnl: Replace PORT_TX register macros with new ones drm/i915/cnl: Kill _MMIO_PORT6 macro drivers/gpu/drm/i915/i915_reg.h | 147 1 file changed, 44 insertions(+), 103 deletions(-) -- 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: success for drm/i915/perf: enable perf support on ICL
== Series Details == Series: drm/i915/perf: enable perf support on ICL URL : https://patchwork.freedesktop.org/series/39689/ State : success == Summary == Series 39689v1 drm/i915/perf: enable perf support on ICL https://patchwork.freedesktop.org/api/1.0/series/39689/revisions/1/mbox/ Known issues: Test kms_frontbuffer_tracking: Subgroup basic: fail -> PASS (fi-cnl-y3) fdo#103167 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: dmesg-warn -> PASS (fi-skl-6700k2) fdo#103191 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:425s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:426s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:374s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:507s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:281s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:493s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:492s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:484s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:473s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:406s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:577s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:579s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:410s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:291s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:516s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:402s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:408s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:465s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:421s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:470s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:462s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:512s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:586s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:428s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:523s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:533s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:494s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:483s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:423s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:531s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:392s Blacklisted hosts: fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:509s 074e834cb3cccf697895a7dc471d324c2309a610 drm-tip: 2018y-03m-09d-10h-30m-56s UTC integration manifest 07c313f0dad2 drm/i915/perf: enable perf support on ICL == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8289/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Show GEM_TRACE when detecting a failed GPU idle (rev2)
== Series Details == Series: drm/i915: Show GEM_TRACE when detecting a failed GPU idle (rev2) URL : https://patchwork.freedesktop.org/series/39674/ State : failure == Summary == Possible new issues: Test kms_cursor_legacy: Subgroup cursorb-vs-flipb-atomic-transitions-varying-size: pass -> DMESG-WARN (shard-hsw) Test kms_frontbuffer_tracking: Subgroup fbc-1p-indfb-fliptrack: pass -> FAIL (shard-apl) Subgroup fbc-1p-offscren-pri-indfb-draw-pwrite: fail -> PASS (shard-apl) Subgroup fbc-1p-primscrn-shrfb-msflip-blt: dmesg-fail -> PASS (shard-apl) Known issues: Test gem_eio: Subgroup in-flight: incomplete -> PASS (shard-apl) fdo#105341 Test kms_atomic_transition: Subgroup 1x-modeset-transitions: pass -> FAIL (shard-apl) fdo#103207 Test kms_flip: Subgroup 2x-plain-flip-fb-recreate: fail -> PASS (shard-hsw) fdo#100368 Subgroup modeset-vs-vblank-race-interruptible: pass -> FAIL (shard-hsw) fdo#103060 Test kms_frontbuffer_tracking: Subgroup fbc-1p-pri-indfb-multidraw: fail -> PASS (shard-snb) fdo#103167 +1 Subgroup fbc-suspend: pass -> FAIL (shard-apl) fdo#101623 Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#103207 https://bugs.freedesktop.org/show_bug.cgi?id=103207 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-apltotal:3467 pass:1822 dwarn:1 dfail:0 fail:11 skip:1632 time:12231s shard-hswtotal:3467 pass:1769 dwarn:2 dfail:0 fail:4 skip:1691 time:11689s shard-snbtotal:3467 pass:1363 dwarn:1 dfail:0 fail:2 skip:2101 time:6891s Blacklisted hosts: shard-kbltotal:3381 pass:1899 dwarn:1 dfail:0 fail:9 skip:1471 time:9138s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8288/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make edp optimize config
On Thu, 08 Mar 2018, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > Previously it was assumed that eDP panels would advertise the lowest link > rate required for their singular mode to function. With the introduction > of more advanced features there are advantages to a panel advertising a > higher rate then it needs for a its given mode. For panels that did, the > driver previously used a higher rate then necessary for that mode. > > Signed-off-by: Matt Atwood > --- > drivers/gpu/drm/i915/intel_dp.c | 10 -- > 1 file changed, 10 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index a2eeede..aa6d77d 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -1758,16 +1758,6 @@ intel_dp_compute_config(struct intel_encoder *encoder, > dev_priv->vbt.edp.bpp); > bpp = dev_priv->vbt.edp.bpp; > } > - > - /* > - * Use the maximum clock and number of lanes the eDP panel > - * advertizes being capable of. The panels are generally > - * designed to support only a single clock and lane > - * configuration, and typically these values correspond to the > - * native resolution of the panel. > - */ > - min_lane_count = max_lane_count; > - min_clock = max_clock; Please see my reply to Manasi's identical patch [1]. If we apply this as-is, it will regress and will be reverted. BR, Jani. [1] http://patchwork.freedesktop.org/patch/msgid/1520579339-14745-1-git-send-email-manasi.d.nav...@intel.com > } > > for (; bpp >= 6*3; bpp -= 2*3) { -- 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/perf: enable perf support on ICL
No significant changes from either context offsets, nor report formats, nor register whitelist. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/Makefile | 3 +- drivers/gpu/drm/i915/i915_oa_icl.c | 118 + drivers/gpu/drm/i915/i915_oa_icl.h | 34 +++ drivers/gpu/drm/i915/i915_perf.c | 5 +- 4 files changed, 158 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_oa_icl.c create mode 100644 drivers/gpu/drm/i915/i915_oa_icl.h diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 4eee91a3a236..ead1e4ff1575 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -171,7 +171,8 @@ i915-y += i915_perf.o \ i915_oa_glk.o \ i915_oa_cflgt2.o \ i915_oa_cflgt3.o \ - i915_oa_cnl.o + i915_oa_cnl.o \ + i915_oa_icl.o ifeq ($(CONFIG_DRM_I915_GVT),y) i915-y += intel_gvt.o diff --git a/drivers/gpu/drm/i915/i915_oa_icl.c b/drivers/gpu/drm/i915/i915_oa_icl.c new file mode 100644 index ..a5667926e3de --- /dev/null +++ b/drivers/gpu/drm/i915/i915_oa_icl.c @@ -0,0 +1,118 @@ +/* + * Autogenerated file by GPU Top : https://github.com/rib/gputop + * DO NOT EDIT manually! + * + * + * Copyright (c) 2015 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 "i915_drv.h" +#include "i915_oa_icl.h" + +static const struct i915_oa_reg b_counter_config_test_oa[] = { + { _MMIO(0x2740), 0x }, + { _MMIO(0x2710), 0x }, + { _MMIO(0x2714), 0xf080 }, + { _MMIO(0x2720), 0x }, + { _MMIO(0x2724), 0xf080 }, + { _MMIO(0x2770), 0x0004 }, + { _MMIO(0x2774), 0x }, + { _MMIO(0x2778), 0x0003 }, + { _MMIO(0x277c), 0x }, + { _MMIO(0x2780), 0x0007 }, + { _MMIO(0x2784), 0x }, + { _MMIO(0x2788), 0x0012 }, + { _MMIO(0x278c), 0xfff7 }, + { _MMIO(0x2790), 0x0012 }, + { _MMIO(0x2794), 0xffcf }, + { _MMIO(0x2798), 0x00100082 }, + { _MMIO(0x279c), 0xffef }, + { _MMIO(0x27a0), 0x001000c2 }, + { _MMIO(0x27a4), 0xffe7 }, + { _MMIO(0x27a8), 0x0011 }, + { _MMIO(0x27ac), 0xffe7 }, +}; + +static const struct i915_oa_reg flex_eu_config_test_oa[] = { +}; + +static const struct i915_oa_reg mux_config_test_oa[] = { + { _MMIO(0xd04), 0x0200 }, + { _MMIO(0x9840), 0x }, + { _MMIO(0x9884), 0x }, + { _MMIO(0x9888), 0x1006 }, + { _MMIO(0x9888), 0x2206 }, + { _MMIO(0x9888), 0x1606 }, + { _MMIO(0x9888), 0x2406 }, + { _MMIO(0x9888), 0x1806 }, + { _MMIO(0x9888), 0x1a06 }, + { _MMIO(0x9888), 0x1206 }, + { _MMIO(0x9888), 0x1406 }, + { _MMIO(0x9888), 0x1006 }, + { _MMIO(0x9888), 0x2206 }, + { _MMIO(0x9884), 0x0003 }, + { _MMIO(0x9888), 0x1613 }, + { _MMIO(0x9888), 0x2401 }, + { _MMIO(0x9888), 0x0e130056 }, + { _MMIO(0x9888), 0x1013 }, + { _MMIO(0x9888), 0x1a13 }, + { _MMIO(0x9888), 0x541f0001 }, + { _MMIO(0x9888), 0x181f }, + { _MMIO(0x9888), 0x4c1f }, + { _MMIO(0x9888), 0x301f }, +}; + +static ssize_t +show_test_oa_id(struct device *kdev, struct device_attribute *attr, char *buf) +{ + return sprintf(buf, "1\n"); +} + +void +i915_perf_load_test_config_icl(struct drm_i915_private *dev_priv) +{ + strlcpy(dev_priv->perf.oa.test_config.uuid, + "a291665e-244b-4b76-9b9a-01de9d3c8068", + sizeof(dev_priv->perf.oa.test_config.uuid)); + dev_priv->perf.oa.test_config.id = 1; + + dev_priv->perf.oa.test_config.mux_regs = mux_config_test_oa; + dev_priv->perf.oa.test_config.mux_regs_le
Re: [Intel-gfx] [PATCH i-g-t] tests/kms_chamelium: Make tests run without pipe color management support.
Op 06-03-18 om 16:57 schreef Maxime Ripard: > Hi, > > On Mon, Mar 05, 2018 at 07:14:16PM +0100, Maarten Lankhorst wrote: >> Only try to set those values if the properties are supported. >> This fixes the kms_chameium tests to run on vc4 again. >> >> Reported-by: Maxime Ripard >> Cc: Paul Kocialkowski >> Cc: Eric Anholt >> Cc: Boris Brezillon >> Signed-off-by: Maarten Lankhorst > This works like a charm now, thanks! > Tested-by: Maxime Ripard > > Maxime > Can you upgrade this to a reviewed-by so I can apply this change? ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/uc: Sanitize uC together with GEM
On 3/9/2018 2:30 AM, Michal Wajdeczko wrote: Instead of dancing around uC on reset/suspend/resume scenarios, explicitly sanitize uC when we sanitize GEM to force uC reload and start from known beginning. Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Cc: Sagar Arun Kamble Cc: Chris Wilson Cc: Michel Thierry --- drivers/gpu/drm/i915/i915_gem.c| 2 ++ drivers/gpu/drm/i915/intel_guc.h | 6 ++ drivers/gpu/drm/i915/intel_huc.h | 6 ++ drivers/gpu/drm/i915/intel_uc.c| 18 ++ drivers/gpu/drm/i915/intel_uc.h| 1 + drivers/gpu/drm/i915/intel_uc_fw.h | 6 ++ 6 files changed, 39 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index ab88ca5..49c81ae 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -4892,6 +4892,8 @@ void i915_gem_sanitize(struct drm_i915_private *i915) */ if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915)) WARN_ON(intel_gpu_reset(i915, ALL_ENGINES)); above intel_gpu_reset also resets uC. Should we just let it reset only real engines with this change then? + + intel_uc_sanitize(i915); } int i915_gem_suspend(struct drm_i915_private *dev_priv) diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h index b9424ac..ec8569f 100644 --- a/drivers/gpu/drm/i915/intel_guc.h +++ b/drivers/gpu/drm/i915/intel_guc.h @@ -132,4 +132,10 @@ static inline u32 guc_ggtt_offset(struct i915_vma *vma) struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size); u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv); +static inline int intel_guc_sanitize(struct intel_guc *guc) +{ + intel_uc_fw_sanitize(&guc->fw); + return 0; +} + #endif diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h index 5d6e804..b185850 100644 --- a/drivers/gpu/drm/i915/intel_huc.h +++ b/drivers/gpu/drm/i915/intel_huc.h @@ -38,4 +38,10 @@ struct intel_huc { void intel_huc_init_early(struct intel_huc *huc); int intel_huc_auth(struct intel_huc *huc); +static inline int intel_huc_sanitize(struct intel_huc *huc) +{ + intel_uc_fw_sanitize(&huc->fw); + return 0; +} + #endif diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index a45171c..abd1f7b 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -327,6 +327,24 @@ void intel_uc_fini(struct drm_i915_private *dev_priv) intel_guc_fini(guc); } +void intel_uc_sanitize(struct drm_i915_private *i915) +{ + struct intel_guc *guc = &i915->guc; + struct intel_huc *huc = &i915->huc; + + if (!USES_GUC(i915)) + return; + + GEM_BUG_ON(!HAS_GUC(i915)); + + guc_disable_communication(guc); + + intel_huc_sanitize(huc); + intel_guc_sanitize(guc); + + __intel_uc_reset_hw(i915); +} + int intel_uc_init_hw(struct drm_i915_private *dev_priv) { struct intel_guc *guc = &dev_priv->guc; diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h index dce4813..937e611 100644 --- a/drivers/gpu/drm/i915/intel_uc.h +++ b/drivers/gpu/drm/i915/intel_uc.h @@ -34,6 +34,7 @@ void intel_uc_fini_fw(struct drm_i915_private *dev_priv); int intel_uc_init_misc(struct drm_i915_private *dev_priv); void intel_uc_fini_misc(struct drm_i915_private *dev_priv); +void intel_uc_sanitize(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_init(struct drm_i915_private *dev_priv); diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h b/drivers/gpu/drm/i915/intel_uc_fw.h index d5fd460..2601521 100644 --- a/drivers/gpu/drm/i915/intel_uc_fw.h +++ b/drivers/gpu/drm/i915/intel_uc_fw.h @@ -115,6 +115,12 @@ static inline bool intel_uc_fw_is_selected(struct intel_uc_fw *uc_fw) return uc_fw->path != NULL; } +static inline void intel_uc_fw_sanitize(struct intel_uc_fw *uc_fw) +{ + if (uc_fw->load_status == INTEL_UC_FIRMWARE_SUCCESS) + uc_fw->load_status = INTEL_UC_FIRMWARE_PENDING; +} + void intel_uc_fw_fetch(struct drm_i915_private *dev_priv, struct intel_uc_fw *uc_fw); int intel_uc_fw_upload(struct intel_uc_fw *uc_fw, -- Thanks, Sagar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2] tests/perf_pmu: Use absolute tolerance in accuracy tests
From: Tvrtko Ursulin We need to use absolute tolerance when asserting on percentages. Relative tolerance in this case is unfair and inaccurate since it's strictness varies with relative target busyness. v2: * Do not include spin batch edit and submit into measured time. * Open PMU before child is in test PWM phase. * No need to emit test PWM for twice as long with the new explicit synchroniazation via pipe. * Log test duration in ms for better readability. * Drop inverse assert. (Chris Wilson) Signed-off-by: Tvrtko Ursulin Cc: Chris Wilson Reviewed-by: Chris Wilson # v1 --- tests/perf_pmu.c | 33 +++-- 1 file changed, 19 insertions(+), 14 deletions(-) diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c index 9ebffc64d1f1..ff9f71540ee4 100644 --- a/tests/perf_pmu.c +++ b/tests/perf_pmu.c @@ -1459,7 +1459,15 @@ static void __rearm_spin_batch(igt_spin_t *spin) __sync_synchronize(); } -#define div_round_up(a, b) (((a) + (b) - 1) / (b)) +#define __assert_within(x, ref, tol_up, tol_down) \ + igt_assert_f((double)(x) <= ((double)(ref) + (tol_up)) && \ +(double)(x) >= ((double)(ref) - (tol_down)), \ +"%f not within +%f/-%f of %f! ('%s' vs '%s')\n", \ +(double)(x), (double)(tol_up), (double)(tol_down), \ +(double)(ref), #x, #ref) + +#define assert_within(x, ref, tolerance) \ + __assert_within(x, ref, tolerance, tolerance) static void accuracy(int gem_fd, const struct intel_execution_engine2 *e, @@ -1493,8 +1501,8 @@ accuracy(int gem_fd, const struct intel_execution_engine2 *e, while (test_us < min_test_us) test_us += busy_us + idle_us; - igt_info("calibration=%luus, test=%luus; ratio=%.2f%% (%luus/%luus)\n", -pwm_calibration_us, test_us, + igt_info("calibration=%lums, test=%lums; ratio=%.2f%% (%luus/%luus)\n", +pwm_calibration_us / 1000, test_us / 1000, (double)busy_us / (busy_us + idle_us) * 100.0, busy_us, idle_us); @@ -1507,7 +1515,7 @@ accuracy(int gem_fd, const struct intel_execution_engine2 *e, igt_fork(child, 1) { struct sched_param rt = { .sched_priority = 99 }; const unsigned long timeout[] = { - pwm_calibration_us * 1000, test_us * 2 * 1000 + pwm_calibration_us * 1000, test_us * 1000 }; struct drm_i915_gem_exec_object2 obj = {}; uint64_t total_busy_ns = 0, total_idle_ns = 0; @@ -1537,19 +1545,16 @@ accuracy(int gem_fd, const struct intel_execution_engine2 *e, igt_nsec_elapsed(&test_start); do { - struct timespec t_busy = { }; - unsigned int target_idle_us; - - igt_nsec_elapsed(&t_busy); + unsigned int target_idle_us, t_busy; /* Restart the spinbatch. */ __rearm_spin_batch(spin); __submit_spin_batch(gem_fd, &obj, e); - measured_usleep(busy_us); + t_busy = measured_usleep(busy_us); igt_spin_batch_end(spin); gem_sync(gem_fd, obj.handle); - total_busy_ns += igt_nsec_elapsed(&t_busy); + total_busy_ns += t_busy; target_idle_us = (100 * total_busy_ns / target_busy_pct - (total_busy_ns + total_idle_ns)) / 1000; @@ -1569,12 +1574,13 @@ accuracy(int gem_fd, const struct intel_execution_engine2 *e, igt_spin_batch_free(gem_fd, spin); } + fd = open_pmu(I915_PMU_ENGINE_BUSY(e->class, e->instance)); + /* Let the child run. */ read(link[0], &expected, sizeof(expected)); - assert_within_epsilon(expected, target_busy_pct/100., 0.05); + assert_within(100.0 * expected, target_busy_pct, 5); /* Collect engine busyness for an interesting part of child runtime. */ - fd = open_pmu(I915_PMU_ENGINE_BUSY(e->class, e->instance)); val[0] = __pmu_read_single(fd, &ts[0]); read(link[0], &expected, sizeof(expected)); val[1] = __pmu_read_single(fd, &ts[1]); @@ -1590,8 +1596,7 @@ accuracy(int gem_fd, const struct intel_execution_engine2 *e, igt_info("error=%.2f%% (%.2f%% vs %.2f%%)\n", __error(busy_r, expected), 100 * busy_r, 100 * expected); - assert_within_epsilon(busy_r, expected, 0.15); - assert_within_epsilon(1 - busy_r, 1 - expected, 0.15); + assert_within(100.0 * busy_r, 100.0 * expected, 2); } igt_main -- 2.14.1 ___ Intel-gfx mailing list