Re: [Intel-gfx] [PATCH v2 05/15] drm/i915/guc: Log runtime should consist of both mapping and relay
On 3/8/2018 9:16 PM, Michał Winiarski wrote: Currently, we're treating relay and mapping of GuC log as a separate concepts. We're also using inconsistent locking, sometimes using relay_lock, sometimes using struct mutex. Let's correct that. Anything touching the runtime is now serialized using runtime.lock, while we're still using struct mutex as inner lock for mapping. We're still racy in setting the log level - but we'll take care of that in the following patches. v2: Tidy locking (Sagar) Signed-off-by: Michał Winiarski Cc: Chris Wilson Cc: Daniele Ceraolo Spurio Cc: Sagar Arun Kamble Cc: Michal Wajdeczko Reviewed-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_guc_log.c | 113 +++ drivers/gpu/drm/i915/intel_guc_log.h | 3 +- 2 files changed, 36 insertions(+), 80 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc_log.c b/drivers/gpu/drm/i915/intel_guc_log.c index 89cb3939467f..4eb3ebd8d6c3 100644 --- a/drivers/gpu/drm/i915/intel_guc_log.c +++ b/drivers/gpu/drm/i915/intel_guc_log.c @@ -155,10 +155,7 @@ static int guc_log_relay_file_create(struct intel_guc *guc) struct dentry *log_dir; int ret; - if (!i915_modparams.guc_log_level) - return 0; - - mutex_lock(&guc->log.runtime.relay_lock); + lockdep_assert_held(&guc->log.runtime.lock); /* For now create the log file in /sys/kernel/debug/dri/0 dir */ log_dir = dev_priv->drm.primary->debugfs_root; @@ -177,28 +174,16 @@ static int guc_log_relay_file_create(struct intel_guc *guc) */ if (!log_dir) { DRM_ERROR("Debugfs dir not available yet for GuC log file\n"); - ret = -ENODEV; - goto out_unlock; + return -ENODEV; } ret = relay_late_setup_files(guc->log.runtime.relay_chan, "guc_log", log_dir); if (ret < 0 && ret != -EEXIST) { DRM_ERROR("Couldn't associate relay chan with file %d\n", ret); - goto out_unlock; + return ret; } - ret = 0; - -out_unlock: - mutex_unlock(&guc->log.runtime.relay_lock); - return ret; -} - -static bool guc_log_has_relay(struct intel_guc *guc) -{ - lockdep_assert_held(&guc->log.runtime.relay_lock); - - return guc->log.runtime.relay_chan != NULL; + return 0; } static void guc_move_to_next_buf(struct intel_guc *guc) @@ -209,9 +194,6 @@ static void guc_move_to_next_buf(struct intel_guc *guc) */ smp_wmb(); - if (!guc_log_has_relay(guc)) - return; - /* All data has been written, so now move the offset of sub buffer. */ relay_reserve(guc->log.runtime.relay_chan, guc->log.vma->obj->base.size); @@ -221,9 +203,6 @@ static void guc_move_to_next_buf(struct intel_guc *guc) static void *guc_get_write_buffer(struct intel_guc *guc) { - if (!guc_log_has_relay(guc)) - return NULL; - /* * Just get the base address of a new sub buffer and copy data into it * ourselves. NULL will be returned in no-overwrite mode, if all sub @@ -284,13 +263,14 @@ static void guc_read_update_log_buffer(struct intel_guc *guc) void *src_data, *dst_data; bool new_overflow; + mutex_lock(&guc->log.runtime.lock); + if (WARN_ON(!guc->log.runtime.buf_addr)) - return; + goto out_unlock; /* Get the pointer to shared GuC log buffer */ log_buf_state = src_data = guc->log.runtime.buf_addr; - mutex_lock(&guc->log.runtime.relay_lock); /* Get the pointer to local buffer to store the logs */ log_buf_snapshot_state = dst_data = guc_get_write_buffer(guc); @@ -302,9 +282,8 @@ static void guc_read_update_log_buffer(struct intel_guc *guc) */ DRM_ERROR_RATELIMITED("no sub-buffer to capture logs\n"); guc->log.capture_miss_count++; - mutex_unlock(&guc->log.runtime.relay_lock); - return; + goto out_unlock; } /* Actual logs are present from the 2nd page */ @@ -375,7 +354,8 @@ static void guc_read_update_log_buffer(struct intel_guc *guc) guc_move_to_next_buf(guc); - mutex_unlock(&guc->log.runtime.relay_lock); +out_unlock: + mutex_unlock(&guc->log.runtime.lock); } static void capture_logs_work(struct work_struct *work) @@ -391,20 +371,20 @@ static bool guc_log_has_runtime(struct intel_guc *guc) return guc->log.runtime.buf_addr != NULL; } -static int guc_log_runtime_create(struct intel_guc *guc) +static int guc_log_map(struct intel_guc *guc) { struct drm_i915_private *dev_priv = guc_to_i915(guc); void *vaddr; int ret; - lockdep_assert_held(&dev_priv->drm.struct_mutex); + lockdep_assert_held(&guc->log.runtime.lock); if (!guc->log.vma) return -ENODEV; - GEM_BUG_ON(guc_log_has_runtime(guc)); - + mutex_
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Do not set the eDP link rate/lane count to max
== Series Details == Series: drm/i915/dp: Do not set the eDP link rate/lane count to max URL : https://patchwork.freedesktop.org/series/39662/ State : success == Summary == Series 39662v1 drm/i915/dp: Do not set the eDP link rate/lane count to max https://patchwork.freedesktop.org/api/1.0/series/39662/revisions/1/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 Test prime_vgem: Subgroup basic-fence-flip: pass -> FAIL (fi-ilk-650) fdo#104008 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 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:422s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:367s 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:278s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:486s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:491s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:486s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:470s 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:572s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:578s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:416s 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:515s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:395s fi-ilk-650 total:288 pass:227 dwarn:0 dfail:0 fail:1 skip:60 time:407s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:463s 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:469s 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:509s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:580s 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:523s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:536s 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:487s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:419s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:522s 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:512s 469c28df8d66d3cc0a4a2e4e12433a5c92102022 drm-tip: 2018y-03m-08d-22h-40m-12s UTC integration manifest 80276b812f47 drm/i915/dp: Do not set the eDP link rate/lane count to max == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8286/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/6] drm/i915: Move DP modeset retry work into intel_dp
On Thu, Mar 08, 2018 at 06:41:22PM -0500, Lyude Paul wrote: > 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. > > V2: > - Remove accidental duplicate modeset_retry_work in intel_connector > > Signed-off-by: Lyude Paul > Cc: Manasi Navare > Cc: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_display.c | 23 +-- > 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, 29 insertions(+), 12 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index f424fff477f6..85d5af4e4f5b 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -15394,16 +15394,35 @@ 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; > > /* 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); > } > + > + if (connector->base.connector_type != > + DRM_MODE_CONNECTOR_DisplayPort) I know we dont fallback on eDP now but since link training is a common code between eDP and DP, this modeset retry can also be called from eDP. So we should check against DRM_MODE_CONNECTOR_eDP type as well. Other than that, I agree that it is better for this work function to be part of intel_dp struct as opposed to intel_connector. So after this change, Reviewed-by: Manasi Navare Manasi > + 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) >
Re: [Intel-gfx] [PATCH v2 03/15] drm/i915/guc: Move GuC notification handling to separate function
On 3/8/2018 9:16 PM, Michał Winiarski wrote: 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 I am suggesting update to the comments below since it is not clear the reason for clearing. Please check and incorporate in this patch itself if you feel it is right. Otherwise change looks good to me. Reviewed-by: Sagar Arun Kamble --- 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 633c18785c1e..6b0cd6bc83f8 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. This paragraph is updated as: /* * Note: Logging protocol is, GuC will set the bit in message identity register and raise the GuC to Host * interrupt and then Host will read the bit, clear it, copy the logs and send ack. * If bits are cleared after sending ack, i915 might lose next log flush interrupt if Host clear operation * happens post GuC's update to message identity register corresponding to next interrupt. * Hence, sample the log buffer flush related bits and clear them out now * itself from the message identity register before sending ack to GuC about * flush completion through guc_log_flush_complete. */ and may be we can additionally include below paragraph to explain the scenario. +* 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 2n
[Intel-gfx] [PATCH] drm/i915/dp: Do not set the eDP link rate/lane count to max
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. But some panels advertise the MAX_LINK_RATE in DPCD higher than what is required to support the native resolution. So optimize and set the link rate and lane count to the least values required by the panel to support the native resolution. This will also be an effective power saving for such eDP panels. Cc: Jani Nikula Cc: Ville Syrjala Cc: Matt Atwood Signed-off-by: Manasi Navare --- drivers/gpu/drm/i915/intel_dp.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 8d1d7af..ba1114b 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1812,15 +1812,14 @@ intel_dp_compute_config(struct intel_encoder *encoder, 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. + /* 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. But some +* panels advertise higher link rates that might not be required +* for the native resolution of the panel. So use the least +* required link rate/lane count for the panel's native +* resolution. */ - min_lane_count = max_lane_count; - min_clock = max_clock; } for (; bpp >= 6*3; bpp -= 2*3) { -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller (rev2)
== Series Details == Series: series starting with [1/2] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller (rev2) URL : https://patchwork.freedesktop.org/series/39651/ State : warning == Summary == Possible new issues: Test kms_vblank: Subgroup pipe-c-query-busy-hang: pass -> DMESG-WARN (shard-hsw) Known issues: Test gem_eio: Subgroup in-flight-contexts: pass -> INCOMPLETE (shard-apl) fdo#105341 +1 Test kms_sysfs_edid_timing: pass -> WARN (shard-apl) fdo#100047 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 shard-apltotal:3381 pass:1779 dwarn:1 dfail:0 fail:8 skip:1591 time:11740s shard-hswtotal:3381 pass:1728 dwarn:2 dfail:0 fail:1 skip:1648 time:11177s shard-snbtotal:3467 pass:1363 dwarn:1 dfail:0 fail:2 skip:2101 time:6904s Blacklisted hosts: shard-kbltotal:3308 pass:1859 dwarn:1 dfail:0 fail:9 skip:1437 time:8741s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8285/shards.html ___ 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: Remove unused DP_LINK_CHECK_TIMEOUT
On Thu, Mar 08, 2018 at 06:24:15PM -0500, Lyude Paul wrote: > Signed-off-by: Lyude Paul > Cc: Manasi Navare > Cc: Ville Syrjälä Reviewed-by: Manasi Navare > --- > drivers/gpu/drm/i915/intel_dp.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 9a4a51e79fa1..4dd1b2287dd6 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -43,7 +43,6 @@ > #include > #include "i915_drv.h" > > -#define DP_LINK_CHECK_TIMEOUT(10 * 1000) > #define DP_DPRX_ESI_LEN 14 > > /* Compliance test status bits */ > -- > 2.14.3 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 02/15] drm/i915/guc: Create common entry points for log register/unregister
On 3/8/2018 9:16 PM, Michał Winiarski wrote: 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 --- 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_unlock(&dev_priv->drm.struct_mutex); - /* * Before initiating the forceful flush, wait for
[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: make edp optimize config
== Series Details == Series: drm/i915: make edp optimize config URL : https://patchwork.freedesktop.org/series/39652/ State : warning == Summary == Possible new issues: Test kms_busy: Subgroup extended-pageflip-hang-oldfb-render-a: pass -> SKIP (shard-snb) Test kms_vblank: Subgroup pipe-a-ts-continuation-modeset: pass -> SKIP (shard-snb) Subgroup pipe-a-wait-busy-hang: pass -> SKIP (shard-snb) Known issues: Test gem_eio: Subgroup in-flight-external: pass -> INCOMPLETE (shard-apl) fdo#105341 Test kms_cursor_crc: Subgroup cursor-256x256-suspend: pass -> INCOMPLETE (shard-hsw) fdo#103375 Test kms_setmode: Subgroup basic: fail -> PASS (shard-hsw) fdo#99912 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 shard-apltotal:3381 pass:1779 dwarn:1 dfail:0 fail:9 skip:1591 time:11672s shard-hswtotal:3383 pass:1724 dwarn:1 dfail:0 fail:0 skip:1656 time:11145s shard-snbtotal:3467 pass:1360 dwarn:1 dfail:0 fail:2 skip:2104 time:6846s Blacklisted hosts: shard-kbltotal:3308 pass:1857 dwarn:1 dfail:0 fail:9 skip:1439 time:8635s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8284/shards.html ___ 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: Push irq_shift from gen8_cs_irq_handler() to caller (rev2)
== Series Details == Series: drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller (rev2) URL : https://patchwork.freedesktop.org/series/39647/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight-external: pass -> INCOMPLETE (shard-apl) fdo#105341 Test kms_atomic_transition: Subgroup 1x-modeset-transitions: pass -> FAIL (shard-apl) fdo#103207 Test kms_plane: Subgroup plane-panning-bottom-right-suspend-pipe-b-planes: pass -> FAIL (shard-apl) fdo#104164 Test pm_lpsp: Subgroup screens-disabled: pass -> FAIL (shard-hsw) fdo#104941 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#103207 https://bugs.freedesktop.org/show_bug.cgi?id=103207 fdo#104164 https://bugs.freedesktop.org/show_bug.cgi?id=104164 fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941 shard-apltotal:3381 pass:1777 dwarn:1 dfail:0 fail:11 skip:1591 time:11729s shard-hswtotal:3467 pass:1772 dwarn:1 dfail:0 fail:2 skip:1691 time:11741s shard-snbtotal:3467 pass:1363 dwarn:1 dfail:0 fail:2 skip:2101 time:6860s Blacklisted hosts: shard-kbltotal:3381 pass:1898 dwarn:1 dfail:0 fail:9 skip:1472 time:9034s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8282/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 01/15] drm/i915/guc: Tidy guc_log_control
On 3/8/2018 9:16 PM, Michał Winiarski wrote: 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 --- 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 89f7ff2c652e..fa0755fe10d0 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -2500,13 +2500,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; } @@ -2515,10 +2512,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 now and interrupts also would -* not have been enabled. Try again now, just in case. -*/ + mutex_unlock(&d
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.
== Series Details == Series: drm/i915/psr: Display WA 0884 applied broadly for more HW tracking. URL : https://patchwork.freedesktop.org/series/39648/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight-contexts: pass -> INCOMPLETE (shard-apl) fdo#105341 Test kms_flip: Subgroup 2x-plain-flip-fb-recreate: pass -> FAIL (shard-hsw) fdo#100368 Subgroup flip-vs-expired-vblank-interruptible: pass -> FAIL (shard-hsw) fdo#102887 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#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 shard-apltotal:3381 pass:1779 dwarn:1 dfail:0 fail:8 skip:1591 time:11773s shard-hswtotal:3467 pass:1771 dwarn:1 dfail:0 fail:3 skip:1691 time:11651s shard-snbtotal:3467 pass:1363 dwarn:1 dfail:0 fail:2 skip:2101 time:6889s Blacklisted hosts: shard-kbltotal:3308 pass:1858 dwarn:1 dfail:0 fail:9 skip:1438 time:8648s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8281/shards.html ___ 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: Push irq_shift from gen8_cs_irq_handler() to caller
== Series Details == Series: drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller URL : https://patchwork.freedesktop.org/series/39647/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight-contexts: pass -> INCOMPLETE (shard-hsw) fdo#105341 +1 Test gem_softpin: Subgroup noreloc-s3: skip -> PASS (shard-snb) fdo#103375 +1 Test kms_cursor_crc: Subgroup cursor-128x128-suspend: pass -> INCOMPLETE (shard-hsw) fdo#103540 Test kms_flip: Subgroup plain-flip-ts-check: pass -> FAIL (shard-hsw) fdo#100368 Test kms_frontbuffer_tracking: Subgroup fbc-suspend: fail -> PASS (shard-apl) fdo#101623 Test kms_sysfs_edid_timing: pass -> WARN (shard-apl) fdo#100047 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#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 fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941 shard-apltotal:3394 pass:1786 dwarn:1 dfail:0 fail:8 skip:1597 time:11772s shard-hswtotal:3343 pass:1707 dwarn:1 dfail:0 fail:3 skip:1629 time:10659s shard-snbtotal:3467 pass:1363 dwarn:2 dfail:0 fail:2 skip:2100 time:6925s Blacklisted hosts: shard-kbltotal:3381 pass:1899 dwarn:1 dfail:0 fail:9 skip:1471 time:8899s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8280/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
Hi Matt, Minor commit message nits. On Thu, Mar 08, 2018 at 05:17:38PM -0800, 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 s/then/than > it needs for a its given mode. Don't need "its" here. > For panels that did, the > driver previously used a higher rate then necessary for that mode. > s/then/than > Signed-off-by: Matt Atwood Tested-by: Benson Leung Tested this on a panel and system with the following source and sink rates: [1.623225] [drm:intel_dp_print_rates] source rates: 162000, 216000, 27, 324000, 432000, 54 [1.623230] [drm:intel_dp_print_rates] sink rates: 162000, 216000, 243000, 27, 324000, 432000, 54 [1.623234] [drm:intel_dp_print_rates] common rates: 162000, 216000, 27, 324000, 432000, 54 Prior to this patch, the driver would pick and train at 54: [2.865653] [drm:intel_dp_start_link_train] [CONNECTOR:76:eDP-1] Link Training Passed at Link Rate = 54, Lane count = 4 After this patch, the driver picks and trains at 324000, which is enough for the panel's native mode: [5.359499] [drm:intel_dp_start_link_train] [CONNECTOR:76:eDP-1] Link Training Passed at Link Rate = 324000, Lane count = 4 Thanks! Benson -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/3] drm/i915: store all mmio bases in intel_engines
== Series Details == Series: series starting with [v2,1/3] drm/i915: store all mmio bases in intel_engines URL : https://patchwork.freedesktop.org/series/39644/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight-contexts: pass -> INCOMPLETE (shard-apl) fdo#105341 Test kms_flip: Subgroup 2x-plain-flip-fb-recreate-interruptible: pass -> FAIL (shard-hsw) fdo#100368 Test kms_sysfs_edid_timing: pass -> WARN (shard-apl) fdo#100047 Test pm_lpsp: Subgroup screens-disabled: pass -> FAIL (shard-hsw) fdo#104941 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 fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941 shard-apltotal:3382 pass:1780 dwarn:1 dfail:0 fail:8 skip:1591 time:11735s shard-hswtotal:3468 pass:1772 dwarn:1 dfail:0 fail:3 skip:1691 time:11645s shard-snbtotal:3468 pass:1364 dwarn:1 dfail:0 fail:2 skip:2101 time:6894s Blacklisted hosts: shard-kbltotal:3382 pass:1900 dwarn:1 dfail:0 fail:9 skip:1471 time:8998s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8279/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller (rev2)
== Series Details == Series: series starting with [1/2] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller (rev2) URL : https://patchwork.freedesktop.org/series/39651/ State : success == Summary == Series 39651v2 series starting with [1/2] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller https://patchwork.freedesktop.org/api/1.0/series/39651/revisions/2/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 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:421s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:421s 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: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:491s 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:466s 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: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:290s 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:397s 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:472s 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: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:585s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:435s 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:529s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:504s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:482s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:419s 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:388s Blacklisted hosts: fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:518s 469c28df8d66d3cc0a4a2e4e12433a5c92102022 drm-tip: 2018y-03m-08d-22h-40m-12s UTC integration manifest 70282c9ebe14 drm/i915: Trim gen11_gt_irq_handler ba501078ebb6 drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8285/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 drm/i915: make edp optimize config
== Series Details == Series: drm/i915: make edp optimize config URL : https://patchwork.freedesktop.org/series/39652/ State : success == Summary == Series 39652v1 drm/i915: make edp optimize config https://patchwork.freedesktop.org/api/1.0/series/39652/revisions/1/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> DMESG-WARN (fi-cnl-y3) fdo#103191 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 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: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:499s 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:486s 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:477s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:464s 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:578s fi-cnl-y3total:288 pass:261 dwarn:1 dfail:0 fail:0 skip:26 time:573s 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:289s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:518s 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:413s 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:420s 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:461s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:513s 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:432s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:519s 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:502s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:482s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:422s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:522s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:388s Blacklisted hosts: fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:504s 469c28df8d66d3cc0a4a2e4e12433a5c92102022 drm-tip: 2018y-03m-08d-22h-40m-12s UTC integration manifest 955496d81a15 drm/i915: make edp optimize config == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8284/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/uc: Sanitize uC
== Series Details == Series: drm/i915/uc: Sanitize uC URL : https://patchwork.freedesktop.org/series/39634/ State : failure == Summary == Possible new issues: Test drv_missed_irq: pass -> SKIP (shard-apl) Test kms_vblank: Subgroup pipe-b-ts-continuation-suspend: incomplete -> PASS (shard-snb) Test perf: Subgroup gen8-unprivileged-single-ctx-counters: pass -> FAIL (shard-apl) Known issues: Test drv_selftest: Subgroup live_gtt: incomplete -> PASS (shard-apl) fdo#103927 Test gem_eio: Subgroup in-flight-contexts: incomplete -> PASS (shard-apl) fdo#105341 +2 Test kms_flip: Subgroup flip-vs-absolute-wf_vblank-interruptible: pass -> FAIL (shard-hsw) fdo#100368 Test kms_frontbuffer_tracking: Subgroup fbc-1p-pri-indfb-multidraw: pass -> FAIL (shard-apl) fdo#103167 Subgroup fbc-suspend: pass -> FAIL (shard-apl) fdo#101623 Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 Test pm_lpsp: Subgroup screens-disabled: pass -> FAIL (shard-hsw) fdo#104941 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 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 fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941 shard-apltotal:3394 pass:1777 dwarn:2 dfail:0 fail:15 skip:1598 time:11855s shard-hswtotal:3467 pass:1770 dwarn:1 dfail:0 fail:4 skip:1691 time:11626s shard-snbtotal:3467 pass:1363 dwarn:1 dfail:0 fail:2 skip:2101 time:6881s Blacklisted hosts: shard-kbltotal:3152 pass:1697 dwarn:57 dfail:1 fail:17 skip:1374 time:7710s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8278/shards.html ___ 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/psr: Kill scheduled work for Core platforms.
== Series Details == Series: drm/i915/psr: Kill scheduled work for Core platforms. URL : https://patchwork.freedesktop.org/series/39650/ State : failure == Summary == Applying: drm/i915/psr: Kill scheduled work for Core platforms. error: sha1 information is lacking or useless (drivers/gpu/drm/i915/intel_psr.c). error: could not build fake ancestor Patch failed at 0001 drm/i915/psr: Kill scheduled work for Core platforms. The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller (rev2)
== Series Details == Series: drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller (rev2) URL : https://patchwork.freedesktop.org/series/39647/ State : success == Summary == Series 39647v2 drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller https://patchwork.freedesktop.org/api/1.0/series/39647/revisions/2/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 Test prime_vgem: Subgroup basic-fence-flip: pass -> FAIL (fi-ilk-650) fdo#104008 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:423s 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:371s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:504s 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:493s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:491s 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:472s 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:578s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:574s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:413s 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:514s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:396s fi-ilk-650 total:288 pass:227 dwarn:0 dfail:0 fail:1 skip:60 time:412s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:463s 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:476s 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:509s 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:431s 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:532s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:500s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:481s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:422s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:522s 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:512s 469c28df8d66d3cc0a4a2e4e12433a5c92102022 drm-tip: 2018y-03m-08d-22h-40m-12s UTC integration manifest 976ac989162d drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8282/issues.html ___ 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
Quoting Chris Wilson (2018-03-09 01:33:08) > 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, Is there a reason why its RCS0 but BCS? And the multi-instance classes actually use VCS(x)? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Trim gen11_gt_irq_handler
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); } /* Clear must be after shared has been served for engine */ -- 2.16.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: make edp optimize config
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; } for (; bpp >= 6*3; bpp -= 2*3) { -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Trim gen11_gt_irq_handler
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: 192/-135 (57) Function old new delta bank1_map - 128+128 bank0_map - 64 +64 gen11_irq_handler706 571-135 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..5a42d8a63677 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 int bank0_map[] = { + [GEN11_RCS0] = RCS, + [GEN11_BCS] = BCS, + }; + static const int 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 int *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); } /* Clear must be after shared has been served for engine */ -- 2.16.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller
Originally we were inlining gen8_cs_irq_handler() and so expected the compiler to constant-fold away the irq_shift (so we had hardcoded it as opposed to use engine->irq_shift). However, we dropped the inline given the proliferation of gen8_cs_irq_handler()s. If we pull the shifting of the iir into the caller, we can shrink the code still further: add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-34 (-34) Function old new delta gen8_cs_irq_handler 123 118 -5 gen8_gt_irq_handler 261 248 -13 gen11_irq_handler722 706 -16 v2: Drop gen11_cs_irq_handler now that it is a simple stub around gen8_cs_irq_handler (Daniele) Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin Cc: Daniele Ceraolo Spurio Reviewed-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/i915_irq.c | 38 -- 1 file changed, 16 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index babf81cf668b..c8c29d8ecbab 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -1399,19 +1399,19 @@ static void snb_gt_irq_handler(struct drm_i915_private *dev_priv, } static void -gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir, int test_shift) +gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir) { struct intel_engine_execlists * const execlists = &engine->execlists; bool tasklet = false; - if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift)) { + if (iir & GT_CONTEXT_SWITCH_INTERRUPT) { if (READ_ONCE(engine->execlists.active)) { __set_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted); tasklet = true; } } - if (iir & (GT_RENDER_USER_INTERRUPT << test_shift)) { + if (iir & GT_RENDER_USER_INTERRUPT) { notify_ring(engine); tasklet |= USES_GUC_SUBMISSION(engine->i915); } @@ -1466,21 +1466,21 @@ static void gen8_gt_irq_handler(struct drm_i915_private *i915, { if (master_ctl & (GEN8_GT_RCS_IRQ | GEN8_GT_BCS_IRQ)) { gen8_cs_irq_handler(i915->engine[RCS], - gt_iir[0], GEN8_RCS_IRQ_SHIFT); + gt_iir[0] >> GEN8_RCS_IRQ_SHIFT); gen8_cs_irq_handler(i915->engine[BCS], - gt_iir[0], GEN8_BCS_IRQ_SHIFT); + gt_iir[0] >> GEN8_BCS_IRQ_SHIFT); } if (master_ctl & (GEN8_GT_VCS1_IRQ | GEN8_GT_VCS2_IRQ)) { gen8_cs_irq_handler(i915->engine[VCS], - gt_iir[1], GEN8_VCS1_IRQ_SHIFT); + gt_iir[1] >> GEN8_VCS1_IRQ_SHIFT); gen8_cs_irq_handler(i915->engine[VCS2], - gt_iir[1], GEN8_VCS2_IRQ_SHIFT); + gt_iir[1] >> GEN8_VCS2_IRQ_SHIFT); } if (master_ctl & GEN8_GT_VECS_IRQ) { gen8_cs_irq_handler(i915->engine[VECS], - gt_iir[3], GEN8_VECS_IRQ_SHIFT); + gt_iir[3] >> GEN8_VECS_IRQ_SHIFT); } if (master_ctl & (GEN8_GT_PM_IRQ | GEN8_GT_GUC_IRQ)) { @@ -2762,12 +2762,6 @@ static void __fini_wedge(struct wedge_me *w) (W)->i915; \ __fini_wedge((W))) -static __always_inline void -gen11_cs_irq_handler(struct intel_engine_cs * const engine, const u32 iir) -{ - gen8_cs_irq_handler(engine, iir, 0); -} - static void gen11_gt_engine_irq_handler(struct drm_i915_private * const i915, const unsigned int bank, @@ -2781,27 +2775,27 @@ gen11_gt_engine_irq_handler(struct drm_i915_private * const i915, switch (engine_n) { case GEN11_RCS0: - return gen11_cs_irq_handler(engine[RCS], iir); + return gen8_cs_irq_handler(engine[RCS], iir); case GEN11_BCS: - return gen11_cs_irq_handler(engine[BCS], iir); + return gen8_cs_irq_handler(engine[BCS], iir); } case 1: switch (engine_n) { case GEN11_VCS(0): - return gen11_cs_irq_handler(engine[_VCS(0)], iir); + return gen8_cs_irq_handler(engine[_VCS(0)], iir); case GEN11_VCS(1): - return gen11_cs_irq_handler(engine[_VCS(1)], iir); + return gen8_cs_irq_handler(engine[_VCS(1)], iir); case GEN11_VCS(2): - return gen11_cs_irq_handler(engine[_VCS(2)], iir); + return gen8_cs_irq_h
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.
== Series Details == Series: drm/i915/psr: Display WA 0884 applied broadly for more HW tracking. URL : https://patchwork.freedesktop.org/series/39648/ State : success == Summary == Series 39648v1 drm/i915/psr: Display WA 0884 applied broadly for more HW tracking. https://patchwork.freedesktop.org/api/1.0/series/39648/revisions/1/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 Test prime_vgem: Subgroup basic-fence-flip: pass -> FAIL (fi-ilk-650) fdo#104008 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 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:421s 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: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:486s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:465s 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:585s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:572s 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:291s 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:396s fi-ilk-650 total:288 pass:227 dwarn:0 dfail:0 fail:1 skip:60 time:411s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:463s 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:471s 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:505s 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:438s 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:531s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:502s 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:421s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:526s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:396s Blacklisted hosts: fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:508s 469c28df8d66d3cc0a4a2e4e12433a5c92102022 drm-tip: 2018y-03m-08d-22h-40m-12s UTC integration manifest 1888eb10d023 drm/i915/psr: Display WA 0884 applied broadly for more HW tracking. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8281/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/10] drm/i915: Disable preemption and sleeping while using the punit sideband (rev2)
== Series Details == Series: series starting with [01/10] drm/i915: Disable preemption and sleeping while using the punit sideband (rev2) URL : https://patchwork.freedesktop.org/series/39555/ State : success == Summary == Possible new issues: Test kms_vblank: Subgroup pipe-b-ts-continuation-suspend: incomplete -> PASS (shard-snb) Known issues: Test drv_selftest: Subgroup live_gtt: incomplete -> PASS (shard-apl) fdo#103927 Test gem_eio: Subgroup in-flight-external: incomplete -> PASS (shard-apl) fdo#105341 +1 Test kms_cursor_crc: Subgroup cursor-128x128-suspend: pass -> INCOMPLETE (shard-hsw) fdo#103540 Test kms_frontbuffer_tracking: Subgroup fbc-suspend: pass -> FAIL (shard-apl) fdo#101623 Test kms_sysfs_edid_timing: warn -> PASS (shard-apl) fdo#100047 Test pm_lpsp: Subgroup screens-disabled: pass -> FAIL (shard-hsw) fdo#104941 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941 shard-apltotal:3467 pass:1825 dwarn:1 dfail:0 fail:9 skip:1632 time:12161s shard-hswtotal:3429 pass:1754 dwarn:1 dfail:0 fail:2 skip:1670 time:11059s shard-snbtotal:3467 pass:1363 dwarn:1 dfail:0 fail:2 skip:2101 time:6890s Blacklisted hosts: shard-kbltotal:3467 pass:1930 dwarn:15 dfail:1 fail:9 skip:1512 time:9173s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8277/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/psr: Kill scheduled work for Core platforms.
The immediate enabling is actually not an issue for the HW perspective for core platforms that have HW tracking. HW will wait few identical idle frames before transitioning to actual psr active anyways. Note that this patch also remove the delayed activation on HSW and BDW introduced by commit 'd0ac896a477d ("drm/i915: Delay first PSR activation.")'. This was introduced to fix a blank screen on VLV/CHV and also masked some frozen screens on other core platforms. Probably the same that we are now properly hunting and fixing. Furthermore, if we stop using delayed activation on core platforms we will be able, on following up patches, to use available workarounds to make HW tracking properly exit PSR instead of the big nuke of disabling psr and re-enable on exit and activate respectively. At least on few reliable cases. v2:(DK): Remove unnecessary WARN_ONs and make some other VLV | CHV more readable. v3: Do it regardless the timer rework. Cc: Dhinakaran Pandiyan Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_debugfs.c | 17 + drivers/gpu/drm/i915/intel_psr.c| 22 ++ 2 files changed, 23 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index e838c765b251..2fd6f98364d3 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -2572,15 +2572,11 @@ static int i915_edp_psr_status(struct seq_file *m, void *data) seq_printf(m, "Active: %s\n", yesno(dev_priv->psr.active)); seq_printf(m, "Busy frontbuffer bits: 0x%03x\n", dev_priv->psr.busy_frontbuffer_bits); - seq_printf(m, "Re-enable work scheduled: %s\n", - yesno(work_busy(&dev_priv->psr.work.work))); - if (HAS_DDI(dev_priv)) { - if (dev_priv->psr.psr2_support) - enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE; - else - enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE; - } else { + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) { + seq_printf(m, "Re-enable work scheduled: %s\n", + yesno(work_busy(&dev_priv->psr.work.work))); + for_each_pipe(dev_priv, pipe) { enum transcoder cpu_transcoder = intel_pipe_to_cpu_transcoder(dev_priv, pipe); @@ -2599,6 +2595,11 @@ static int i915_edp_psr_status(struct seq_file *m, void *data) intel_display_power_put(dev_priv, power_domain); } + } else { + if (dev_priv->psr.psr2_support) + enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE; + else + enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE; } seq_printf(m, "Main link in standby mode: %s\n", diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index b0286722a72f..9705d89c5ebf 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -652,9 +652,7 @@ void intel_psr_enable(struct intel_dp *intel_dp, dev_priv->psr.enable_source(intel_dp, crtc_state); dev_priv->psr.enabled = intel_dp; - if (INTEL_GEN(dev_priv) >= 9) { - intel_psr_activate(intel_dp); - } else { + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) { /* * FIXME: Activation should happen immediately since this * function is just called after pipe is fully trained and @@ -667,6 +665,8 @@ void intel_psr_enable(struct intel_dp *intel_dp, */ schedule_delayed_work(&dev_priv->psr.work, msecs_to_jiffies(intel_dp->panel_power_cycle_delay * 5)); + } else { + intel_psr_activate(intel_dp); } unlock: @@ -1045,10 +1045,15 @@ void intel_psr_flush(struct drm_i915_private *dev_priv, } } - if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits) - if (!work_busy(&dev_priv->psr.work.work)) - schedule_delayed_work(&dev_priv->psr.work, - msecs_to_jiffies(100)); + if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits) { + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) { + if (!work_busy(&dev_priv->psr.work.work)) + schedule_delayed_work(&dev_priv->psr.work, + msecs_to_jiffies(100)); + } else { + intel_psr_activate(dev_priv->psr.enabled); + } + } mutex_unlock(&dev_priv->psr.lock); } @@ -1095,7 +1100,8 @@ void intel_psr_init(struct drm_i915_private *dev_priv) dev_
Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/frontbuffer: HW tracking for cursor moves to fix PSR lags.
On Wed, Mar 07, 2018 at 04:21:53PM -0800, Pandiyan, Dhinakaran wrote: > On Wed, 2018-03-07 at 15:43 -0800, Rodrigo Vivi wrote: > > On Wed, Mar 07, 2018 at 03:23:13PM -0800, Rodrigo Vivi wrote: > > > On Wed, Mar 07, 2018 at 11:10:35PM +, Pandiyan, Dhinakaran wrote: > > > > On Wed, 2018-03-07 at 22:53 +, Chris Wilson wrote: > > > > > Quoting Dhinakaran Pandiyan (2018-03-07 03:34:19) > > > > > > DRM_IOCTL_MODE_CURSOR results in frontbuffer flush before the cursor > > > > > > plane MMIOs are written to. But this flush should not be necessary > > > > > > for > > > > > > PSR as hardware tracking triggers PSR exit when MMIOs are written. > > > > > > As > > > > > > for FBC, the spec says "Flips or changes to plane size and panning" > > > > > > cause > > > > > > FBC to be nuked. Use origin == ORIGIN_FLIP so that features can > > > > > > ignore > > > > > > cursor updates in their frontbuffer_flush implementations. > > > > > > > > > > > > /sys/kernel/debug/dri/0/i915_fbc_status shows > > > > > > "Compressing: yes" when I move the cursor around. > > > > > > > > > > > > v3: Use ORIGIN_FLIP now that pin_to_display does not flush > > > > > > frontbuffer. > > > > > > v2: Update comment in i915_gem_object_pin_to_display_plane. (Chris) > > > > > > > > > > > > Cc: Paulo Zanoni > > > > > > Cc: Ville Syrjälä > > > > > > Cc: Chris Wilson > > > > > > Cc: Rodrigo Vivi > > > > > > Signed-off-by: Dhinakaran Pandiyan > > > > > > --- > > > > > > drivers/gpu/drm/i915/intel_display.c | 2 +- > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > > > > > b/drivers/gpu/drm/i915/intel_display.c > > > > > > index 91ce8a0522a3..18b08e263ee1 100644 > > > > > > --- a/drivers/gpu/drm/i915/intel_display.c > > > > > > +++ b/drivers/gpu/drm/i915/intel_display.c > > > > > > @@ -13176,7 +13176,7 @@ intel_legacy_cursor_update(struct drm_plane > > > > > > *plane, > > > > > > if (ret) > > > > > > goto out_unlock; > > > > > > > > > > > > - intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_DIRTYFB); > > > > > > + intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_FLIP); > > > > > > > > > > What about prepare_plane? That should reduce to ORIGIN_FLIP as well, > > > > > aiui. > > > > > -Chris > > > > > > > > > > > > That was the idea but there's a problem with not knowing if PSR exit is > > > > fully complete before we begin updating the plane registers in > > > > pipe_update_start(). > > > > > > > > Let's say PSR was active and display is in DC6. A flip comes in, without > > > > _flush(DIRTYFB) in prepare_plane_fb(), PSR exit is delayed until vblank > > > > enabling that happens in pipe_update_start. We immediately follow that > > > > with programming the plane MMIO's without checking if PSR fully exited. > > > > If PSR and DC6 happen to exit while we were in the middle of programming > > > > plane MMIO's, the resulting vblank toggle (from PSR exit) might activate > > > > partially programmed registers. _flush(DIRTYFB) gives us an opportunity > > > > to exit PSR fully by starting early. > > > > > > > > As for legacy_cursor_update(), since there is no vblank enabling > > > > involved, we avoid updating the MMIO's in the midst of PSR exit > > > > > > I don't believe you will be ever in a case that you write to any register > > > and get any flip or anything without exiting DC6 before that happens. > > > > > > Or the CSR mechanism of DC6 will be simply wrong. > > > > > > Would this be enough? > > > > ok... just ignore my previous comment... > > I believe we can move with the safest side and maybe revisit this later. > > > > From what I remember of the FBC nuke needs as well I believe this is > > the right move. > > > > Although I'm asking myself now if we are not changing the meaning of the > > ORIGINS here. Shouldn't we add a new origin and update the handling? > > > > of "flip" is a good description for this call? > > > > The action taken for this frontbuffer_flush() is the same as origin == > FLIP. I think it is better to add a new one when we want the features > (psr,fbc) to distinguish and react differently. Maybe we could change the names from ORIGIN_something to something more meaninful about the operation to be performed then... Anyways I don't want to force increase the number of origins and duplicate the code on a niptic and I don't have better suggestions for names... So I guess we move fwd with this for now... Reviewed-by: Rodrigo Vivi > > > > > > > > > > > > > > > > > > ___ > > > > > 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 v2 2/3] drm/i915/frontbuffer: HW tracking for cursor moves to fix PSR lags.
On Wed, 2018-03-07 at 15:34 -0800, Dhinakaran Pandiyan wrote: > On Wed, 2018-03-07 at 22:53 +, Chris Wilson wrote: > > Quoting Dhinakaran Pandiyan (2018-03-07 03:34:19) > > > DRM_IOCTL_MODE_CURSOR results in frontbuffer flush before the cursor > > > plane MMIOs are written to. But this flush should not be necessary for > > > PSR as hardware tracking triggers PSR exit when MMIOs are written. As > > > for FBC, the spec says "Flips or changes to plane size and panning" cause > > > FBC to be nuked. Use origin == ORIGIN_FLIP so that features can ignore > > > cursor updates in their frontbuffer_flush implementations. > > > > > > /sys/kernel/debug/dri/0/i915_fbc_status shows > > > "Compressing: yes" when I move the cursor around. > > > > > > v3: Use ORIGIN_FLIP now that pin_to_display does not flush frontbuffer. > > > v2: Update comment in i915_gem_object_pin_to_display_plane. (Chris) > > > > > > Cc: Paulo Zanoni > > > Cc: Ville Syrjälä > > > Cc: Chris Wilson > > > Cc: Rodrigo Vivi > > > Signed-off-by: Dhinakaran Pandiyan > > > --- > > > drivers/gpu/drm/i915/intel_display.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > > b/drivers/gpu/drm/i915/intel_display.c > > > index 91ce8a0522a3..18b08e263ee1 100644 > > > --- a/drivers/gpu/drm/i915/intel_display.c > > > +++ b/drivers/gpu/drm/i915/intel_display.c > > > @@ -13176,7 +13176,7 @@ intel_legacy_cursor_update(struct drm_plane > > > *plane, > > > if (ret) > > > goto out_unlock; > > > > > > - intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_DIRTYFB); > > > + intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_FLIP); > > > > What about prepare_plane? That should reduce to ORIGIN_FLIP as well, > > aiui. > > -Chris > > > That was the idea but there's a problem with not knowing if PSR exit is > fully complete before we begin updating the plane registers in > pipe_update_start(). > > Let's say PSR was active and display is in DC6. A flip comes in, without > _flush(DIRTYFB) in prepare_plane_fb(), PSR exit is delayed until vblank > enabling that happens in pipe_update_start. Correction, _flush(DIRTYFB) in prepare_plane_fb() has no effect because the gem object has no frontbuffer bits set. We should just remove that misleading call. > We immediately follow that > with programming the plane MMIO's without checking if PSR fully exited. > If PSR and DC6 happen to exit while we were in the middle of programming > plane MMIO's, the resulting vblank toggle (from PSR exit) might activate > partially programmed registers. _flush(DIRTYFB) gives us an opportunity > to exit PSR fully by starting early. > > As for legacy_cursor_update(), since there is no vblank enabling > involved, we avoid updating the MMIO's in the midst of PSR exit > > > > ___ > > 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] [PATCH v2] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller
Originally we were inlining gen8_cs_irq_handler() and so expected the compiler to constant-fold away the irq_shift (so we had hardcoded it as opposed to use engine->irq_shift). However, we dropped the inline given the proliferation of gen8_cs_irq_handler()s. If we pull the shifting of the iir into the caller, we can shrink the code still further: add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-34 (-34) Function old new delta gen8_cs_irq_handler 123 118 -5 gen8_gt_irq_handler 261 248 -13 gen11_irq_handler722 706 -16 v2: Drop gen11_cs_irq_handler now that it is a simple stub around gen8_cs_irq_handler (Daniele) Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin Cc: Daniele Ceraolo Spurio Reviewed-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/i915_irq.c | 38 -- 1 file changed, 16 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index babf81cf668b..c8c29d8ecbab 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -1399,19 +1399,19 @@ static void snb_gt_irq_handler(struct drm_i915_private *dev_priv, } static void -gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir, int test_shift) +gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir) { struct intel_engine_execlists * const execlists = &engine->execlists; bool tasklet = false; - if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift)) { + if (iir & GT_CONTEXT_SWITCH_INTERRUPT) { if (READ_ONCE(engine->execlists.active)) { __set_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted); tasklet = true; } } - if (iir & (GT_RENDER_USER_INTERRUPT << test_shift)) { + if (iir & GT_RENDER_USER_INTERRUPT) { notify_ring(engine); tasklet |= USES_GUC_SUBMISSION(engine->i915); } @@ -1466,21 +1466,21 @@ static void gen8_gt_irq_handler(struct drm_i915_private *i915, { if (master_ctl & (GEN8_GT_RCS_IRQ | GEN8_GT_BCS_IRQ)) { gen8_cs_irq_handler(i915->engine[RCS], - gt_iir[0], GEN8_RCS_IRQ_SHIFT); + gt_iir[0] >> GEN8_RCS_IRQ_SHIFT); gen8_cs_irq_handler(i915->engine[BCS], - gt_iir[0], GEN8_BCS_IRQ_SHIFT); + gt_iir[0] >> GEN8_BCS_IRQ_SHIFT); } if (master_ctl & (GEN8_GT_VCS1_IRQ | GEN8_GT_VCS2_IRQ)) { gen8_cs_irq_handler(i915->engine[VCS], - gt_iir[1], GEN8_VCS1_IRQ_SHIFT); + gt_iir[1] >> GEN8_VCS1_IRQ_SHIFT); gen8_cs_irq_handler(i915->engine[VCS2], - gt_iir[1], GEN8_VCS2_IRQ_SHIFT); + gt_iir[1] >> GEN8_VCS2_IRQ_SHIFT); } if (master_ctl & GEN8_GT_VECS_IRQ) { gen8_cs_irq_handler(i915->engine[VECS], - gt_iir[3], GEN8_VECS_IRQ_SHIFT); + gt_iir[3] >> GEN8_VECS_IRQ_SHIFT); } if (master_ctl & (GEN8_GT_PM_IRQ | GEN8_GT_GUC_IRQ)) { @@ -2762,12 +2762,6 @@ static void __fini_wedge(struct wedge_me *w) (W)->i915; \ __fini_wedge((W))) -static __always_inline void -gen11_cs_irq_handler(struct intel_engine_cs * const engine, const u32 iir) -{ - gen8_cs_irq_handler(engine, iir, 0); -} - static void gen11_gt_engine_irq_handler(struct drm_i915_private * const i915, const unsigned int bank, @@ -2781,27 +2775,27 @@ gen11_gt_engine_irq_handler(struct drm_i915_private * const i915, switch (engine_n) { case GEN11_RCS0: - return gen11_cs_irq_handler(engine[RCS], iir); + return gen8_cs_irq_handler(engine[RCS], iir); case GEN11_BCS: - return gen11_cs_irq_handler(engine[BCS], iir); + return gen8_cs_irq_handler(engine[BCS], iir); } case 1: switch (engine_n) { case GEN11_VCS(0): - return gen11_cs_irq_handler(engine[_VCS(0)], iir); + return gen8_cs_irq_handler(engine[_VCS(0)], iir); case GEN11_VCS(1): - return gen11_cs_irq_handler(engine[_VCS(1)], iir); + return gen8_cs_irq_handler(engine[_VCS(1)], iir); case GEN11_VCS(2): - return gen11_cs_irq_handler(engine[_VCS(2)], iir); + return gen8_cs_irq_h
Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx
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 > > > > > +static void single(int fd, const struct intel_execution_engine *e) > > +{ > > + 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 (uint32_t freq = min + 50; freq <= max; freq += 100) { > > Although it is done in the smoke test, it would be interesting if freq's > values were a bit randomized. It was intentionally increment only originally because the implementation was fast to upclock and slow to downclock. Given the challenge of the smoketest, I've shelved that laziness until it can pass that not particularly challenging test. I did have in mind doing an up/down ramp. We should also check that changing min while keeping max fixed should not affect a 100% load like the spinners. > > + 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. > > + > > + gem_quiescent_gpu(fd); > > + spin = __igt_spin_batch_new(fd, ctx, engine, 0); > > + usleep(1); > > I guess here we wait for the frequency changes to take effect, maybe a > small comment would help. And for the batch to be submitted. Asynchronous interfaces make it hard to pinpoint when things occur. We keep muttering about extending igt_spin_t to have an option for wait-for-exec (basically have it write out a dword that we can spin on) usleep(1); /* wait for execution + freq change */ > > +static void sandwich(int fd) > > +{ > > + uint32_t ctx = gem_context_create(fd); > > + unsigned int engine; > > + uint32_t min, max; > > + igt_spin_t *spin; > > + int pmu; > > + > > + pmu = perf_i915_open(I915_PMU_REQUESTED_FREQUENCY); > > + igt_require(pmu >= 0); > > + > > + spin = igt_spin_batch_new(fd, ctx, 0, 0); > > + get_freq(fd, ctx, &min, &max); > > + set_freq(fd, ctx, min, min); > > + for_each_physical_engine(fd, engine) { > > + struct drm_i915_gem_exec_object2 obj = { > > + .handle = spin->handle, > > + }; > > + struct drm_i915_gem_execbuffer2 eb = { > > + .buffer_count = 1, > > + .buffers_ptr = to_user_pointer(&obj), > > + .flags = engine, > > + .rsvd1 = ctx, > > + }; > > + uint32_t cur, discard; > > + double measured; > > + > > + min += 50; > > + if (min > max) > > + break; > > + > > + set_freq(fd, ctx, min, min); > > + get_freq(fd, ctx, &cur, &discard); > > + > > + gem_execbuf(fd, &eb); > > + usleep(1); > > + > > + measured = measure_frequency(pmu, SAMPLE_PERIOD); > > + igt_debugfs_dump(fd, "i915_rps_boost_info"); > > + > > + igt_info("Measured %.1fMHz, expected %dMhz\n", measured, cur); > > + igt_assert(measured > cur - 100 && measured < cur + 100); > > Does the frequency change after each execbuf? Yes. This turned into just an exercise across engines, bumping the desired freq. I wanted to try and validate the min/max bounds, but ran into the challenge that the gpu is only running at the highest frequency it can get because of the busy spinner :) > > +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 > > +static void
[Intel-gfx] [PATCH] drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.
WA 0884:bxt:all,cnl:*:A - "When FBC is enabled with eDP PSR, the CPU host modify writes may not get updated on the Display as expected. WA: Write 0x to CUR_SURFLIVE_A with every CPU host modify write to trigger PSR exit." We can also find on spec other cases where they describe bogus writes to cursor registers to force PSR exit with HW tracking. And it was confirmed by HW engineers that this Wa can be safely applied for any frontbuffer activity. So let's use this more and more here instead of forcibly disable and re-enable PSR everytime that we have a simple reliable flush case. Other commits improve the fbcon/fbdev use a lot, but this approach is the only when where we can get a fully reliable console with no slowness or missed frames and PSR still enabled and active. v2: - Rebase on drm-tip - (DK) Add a comment to explain that WA tells about writing 0 to CUR_SURFLIVE_A but we write to CUR_SURFLIVE(pipe). v3: Wa doesn't work on PSR2. Cc: Dhinakaran Pandiyan Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_reg.h | 3 +++ drivers/gpu/drm/i915/intel_psr.c | 19 +-- 2 files changed, 20 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index e6a8c0ee7df1..abdc513a9edd 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -6032,6 +6032,9 @@ enum { #define IVB_CURSOR_B_OFFSET 0x71080 #define IVB_CURSOR_C_OFFSET 0x72080 +#define _CUR_SURLIVE 0x700AC +#define CUR_SURLIVE(pipe) _CURSOR2(pipe, _CUR_SURLIVE) + /* Display A control */ #define _DSPACNTR 0x70180 #define DISPLAY_PLANE_ENABLE (1<<31) diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index 30932527e663..b0286722a72f 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -1027,8 +1027,23 @@ void intel_psr_flush(struct drm_i915_private *dev_priv, dev_priv->psr.busy_frontbuffer_bits &= ~frontbuffer_bits; /* By definition flush = invalidate + flush */ - if (frontbuffer_bits) - intel_psr_exit(dev_priv); + if (frontbuffer_bits) { + if (dev_priv->psr.psr2_support || + IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) { + intel_psr_exit(dev_priv); + } else { + /* +* Display WA #0884: all +* This documented WA for bxt can be safely applied +* broadly so we can force HW tracking to exit PSR +* instead of disabling and re-enabling. +* Workaround tells us to write 0 to CUR_SURLIVE_A, +* but it makes more sense write to the current active +* pipe. +*/ + I915_WRITE(CUR_SURLIVE(pipe), 0); + } + } if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits) if (!work_busy(&dev_priv->psr.work.work)) -- 2.13.6 ___ 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: add a selftest for the mmio_bases table
Quoting Daniele Ceraolo Spurio (2018-03-08 23:46:28) > Check that the entries are in reverse gen order and that the first entry > and all the following entries with gen > 0 have an mmio base set. > > Suggested-by: Chris Wilson > Cc: Chris Wilson > Signed-off-by: Daniele Ceraolo Spurio > --- > drivers/gpu/drm/i915/intel_engine_cs.c | 1 + > .../gpu/drm/i915/selftests/i915_mock_selftests.h | 1 + > drivers/gpu/drm/i915/selftests/intel_engine_cs.c | 48 > ++ > 3 files changed, 50 insertions(+) > create mode 100644 drivers/gpu/drm/i915/selftests/intel_engine_cs.c > > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c > b/drivers/gpu/drm/i915/intel_engine_cs.c > index 08711665061c..a33171d82aee 100644 > --- a/drivers/gpu/drm/i915/intel_engine_cs.c > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c > @@ -2131,4 +2131,5 @@ void intel_disable_engine_stats(struct intel_engine_cs > *engine) > > #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST) > #include "selftests/mock_engine.c" > +#include "selftests/intel_engine_cs.c" > #endif > diff --git a/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h > b/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h > index 9a48aa441743..2842f93ca29e 100644 > --- a/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h > +++ b/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h > @@ -23,3 +23,4 @@ selftest(vma, i915_vma_mock_selftests) > selftest(evict, i915_gem_evict_mock_selftests) > selftest(gtt, i915_gem_gtt_mock_selftests) > selftest(hugepages, i915_gem_huge_page_mock_selftests) > +selftest(engine, intel_engine_cs_mock_selftests) Plonk this after uncore. It's a lowlevel sanity check that should come before we start looking at features. > diff --git a/drivers/gpu/drm/i915/selftests/intel_engine_cs.c > b/drivers/gpu/drm/i915/selftests/intel_engine_cs.c > new file mode 100644 > index ..8ef453905520 > --- /dev/null > +++ b/drivers/gpu/drm/i915/selftests/intel_engine_cs.c > @@ -0,0 +1,48 @@ > +/* > + * SPDX-License-Identifier: GPL-2.0 > + * > + * Copyright © 2018 Intel Corporation > + */ > + > +#include "../i915_selftest.h" > + > +static int intel_mmio_bases_check(void) > +{ > + const struct engine_info *info; > + int i, j; > + u32 gen; > + s32 prev; > + > + for (i = 0; i < ARRAY_SIZE(intel_engines); i++) { > + info = &intel_engines[i]; > + > + for (prev = -1, j = MAX_MMIO_BASES -1; j >= 0; j--) { > + gen = info->mmio_bases[j].gen; > + > + if (prev >= (s32)gen) { > + pr_err("%s: engine[%d]: mmio base for gen %x " > + "is before the one for gen %x\n", > + __func__, i, gen, prev); > + return -EINVAL; > + } > + > + if ((j == 0 || gen > 0) && !info->mmio_bases[j].base) > { Ok, setting gen=0 upset us. Make that gen=1 in the previous patch. Looping backwards here definitely seems to make it harder than it needs to be. We only need to validate the array as seen by the algorithm so, u8 prev = U8_MAX; for (j = 0; j < MAX_MMIO_BASES; j++) { u8 gen = info->mmio_bases[j].gen; if (gen >= prev) { ... return -EINVAL; } if (gen == 0) break; if (!info->mmio.bases[j].base) { ... return -EINVAL; } prev = gen; } pr_info("%s: min gen supported for %s = %d\n", __func__, magic_engine_name(i), prev); I'm not sure how we could automate that check (not without hardcoding the same information twice), so just print it. > + > +int intel_engine_cs_mock_selftests(void) > +{ > + return intel_mmio_bases_check(); I'd stick this in a static const struct i915_subtest tests[] = { SUBTEST(mmio_bases_check), }; return i915_subtests(tests, NULL); just for the convenience of adding more. -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
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 +static void single(int fd, const struct intel_execution_engine *e) +{ + 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 (uint32_t freq = min + 50; freq <= max; freq += 100) { Although it is done in the smoke test, it would be interesting if freq's values were a bit randomized. + uint32_t cur, discard; + + set_freq(fd, ctx, freq, freq); + get_freq(fd, ctx, &cur, &discard); igt_assert_eq(freq, cur)? + + gem_quiescent_gpu(fd); + spin = __igt_spin_batch_new(fd, ctx, engine, 0); + usleep(1); I guess here we wait for the frequency changes to take effect, maybe a small comment would help. + + measured = measure_frequency(pmu, SAMPLE_PERIOD); + igt_debugfs_dump(fd, "i915_rps_boost_info"); + + igt_spin_batch_free(fd, spin); + igt_info("%s(single): Measured %.1fMHz, expected %dMhz\n", +e->name, measured, cur); + igt_assert(measured > cur - 100 && measured < cur + 100); + } + gem_quiescent_gpu(fd); + + close(pmu); + gem_context_destroy(fd, ctx); +} + + +static void sandwich(int fd) +{ + uint32_t ctx = gem_context_create(fd); + unsigned int engine; + uint32_t min, max; + igt_spin_t *spin; + int pmu; + + pmu = perf_i915_open(I915_PMU_REQUESTED_FREQUENCY); + igt_require(pmu >= 0); + + spin = igt_spin_batch_new(fd, ctx, 0, 0); + get_freq(fd, ctx, &min, &max); + set_freq(fd, ctx, min, min); + for_each_physical_engine(fd, engine) { + struct drm_i915_gem_exec_object2 obj = { + .handle = spin->handle, + }; + struct drm_i915_gem_execbuffer2 eb = { + .buffer_count = 1, + .buffers_ptr = to_user_pointer(&obj), + .flags = engine, + .rsvd1 = ctx, + }; + uint32_t cur, discard; + double measured; + + min += 50; + if (min > max) + break; + + set_freq(fd, ctx, min, min); + get_freq(fd, ctx, &cur, &discard); + + gem_execbuf(fd, &eb); + usleep(1); + + measured = measure_frequency(pmu, SAMPLE_PERIOD); + igt_debugfs_dump(fd, "i915_rps_boost_info"); + + igt_info("Measured %.1fMHz, expected %dMhz\n", measured, cur); + igt_assert(measured > cur - 100 && measured < cur + 100); Does the frequency change after each execbuf? + } + igt_spin_batch_free(fd, spin); + gem_quiescent_gpu(fd); + + gem_context_destroy(fd, ctx); + close(pmu); +} + +static void pwm(int fd, unsigned int *engines, unsigned int nengine, int link) +{ + uint32_t ctx[nengine]; + + fcntl(link, F_SETFL, fcntl(fd, F_GETFL) | O_NONBLOCK); + + for (unsigned int n = 0; n < nengine; n++) + ctx[n] = gem_context_create(fd); + + do { + igt_spin_t *spin; + struct { + uint32_t engine; + uint32_t min; + uint32_t max; + } req; + + while (read(link, &req, sizeof(req)) > 0) { + if ((req.engine | req.min | req.max) == 0) + goto out; + + igt_assert(req.engine < nengine); + set_freq(fd, ctx[req.engine], req.min, req.max); + } + + /* Create a 20% load using busy spinners */ + spin = __igt_spin_batch_new(fd, ctx[0], engines[0], 0); + for (unsigned int n = 1; n < nengine; n++) { + struct drm_i915_gem_exec_object2 obj = { + .handle = spin->handle, + }; + struct drm_i915_gem_execbuffer2 eb = { +
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller
== Series Details == Series: drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller URL : https://patchwork.freedesktop.org/series/39647/ State : success == Summary == Series 39647v1 drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller https://patchwork.freedesktop.org/api/1.0/series/39647/revisions/1/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 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:420s 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:377s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:499s 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:494s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:478s 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:575s 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:416s 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:396s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:410s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:467s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:420s 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:463s 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: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: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:497s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:485s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:419s 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-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:507s 469c28df8d66d3cc0a4a2e4e12433a5c92102022 drm-tip: 2018y-03m-08d-22h-40m-12s UTC integration manifest 2239b752c241 drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8280/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: store all mmio bases in intel_engines
Quoting Daniele Ceraolo Spurio (2018-03-08 23:46:27) > 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. > > v2: document that the list goes in reverse order, update starting gen > for render (Chris) > > Cc: Chris Wilson > Cc: Mika Kuoppala > Cc: Tvrtko Ursulin > Signed-off-by: Daniele Ceraolo Spurio > --- > +static u32 __engine_mmio_base(struct drm_i915_private *i915, > + const struct engine_mmio_base* bases) > +{ > + int i; > + > + for (i = 0; i < MAX_MMIO_BASES; i++) > + if (INTEL_GEN(i915) >= bases[i].gen) > + break; > + > + GEM_BUG_ON(i == MAX_MMIO_BASES); > + GEM_BUG_ON(!bases[i].base); Idly contemplating do { if (INTEL_GEN(i915) >= bases->gen) return bases->base; bases++; } while(1); given the selftest for validating adding new gen. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller
On 08/03/18 16:16, Chris Wilson wrote: Originally we were inlining gen8_cs_irq_handler() and so expected the compiler to constant-fold away the irq_shift (so we had hardcoded it as opposed to use engine->irq_shift). However, we dropped the inline given the proliferation of gen8_cs_irq_handler()s. If we pull the shifting of the iir into the caller, we can shrink the code still further: add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-34 (-34) Function old new delta gen8_cs_irq_handler 123 118 -5 gen8_gt_irq_handler 261 248 -13 gen11_irq_handler722 706 -16 Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin Cc: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/i915_irq.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index babf81cf668b..84c0043e1637 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -1399,19 +1399,19 @@ static void snb_gt_irq_handler(struct drm_i915_private *dev_priv, } static void -gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir, int test_shift) +gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir) { struct intel_engine_execlists * const execlists = &engine->execlists; bool tasklet = false; - if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift)) { + if (iir & GT_CONTEXT_SWITCH_INTERRUPT) { if (READ_ONCE(engine->execlists.active)) { __set_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted); tasklet = true; } } - if (iir & (GT_RENDER_USER_INTERRUPT << test_shift)) { + if (iir & GT_RENDER_USER_INTERRUPT) { notify_ring(engine); tasklet |= USES_GUC_SUBMISSION(engine->i915); } @@ -1466,21 +1466,21 @@ static void gen8_gt_irq_handler(struct drm_i915_private *i915, { if (master_ctl & (GEN8_GT_RCS_IRQ | GEN8_GT_BCS_IRQ)) { gen8_cs_irq_handler(i915->engine[RCS], - gt_iir[0], GEN8_RCS_IRQ_SHIFT); + gt_iir[0] >> GEN8_RCS_IRQ_SHIFT); gen8_cs_irq_handler(i915->engine[BCS], - gt_iir[0], GEN8_BCS_IRQ_SHIFT); + gt_iir[0] >> GEN8_BCS_IRQ_SHIFT); } if (master_ctl & (GEN8_GT_VCS1_IRQ | GEN8_GT_VCS2_IRQ)) { gen8_cs_irq_handler(i915->engine[VCS], - gt_iir[1], GEN8_VCS1_IRQ_SHIFT); + gt_iir[1] >> GEN8_VCS1_IRQ_SHIFT); gen8_cs_irq_handler(i915->engine[VCS2], - gt_iir[1], GEN8_VCS2_IRQ_SHIFT); + gt_iir[1] >> GEN8_VCS2_IRQ_SHIFT); } if (master_ctl & GEN8_GT_VECS_IRQ) { gen8_cs_irq_handler(i915->engine[VECS], - gt_iir[3], GEN8_VECS_IRQ_SHIFT); + gt_iir[3] >> GEN8_VECS_IRQ_SHIFT); } if (master_ctl & (GEN8_GT_PM_IRQ | GEN8_GT_GUC_IRQ)) { @@ -2765,7 +2765,7 @@ static void __fini_wedge(struct wedge_me *w) static __always_inline void gen11_cs_irq_handler(struct intel_engine_cs * const engine, const u32 iir) { - gen8_cs_irq_handler(engine, iir, 0); + gen8_cs_irq_handler(engine, iir); Could potentially drop gen11_cs_irq_handler entirely since now it is identical to gen8_cs_irq_handler, but either way: Reviewed-by: Daniele Ceraolo Spurio Daniele } static void ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: move gen8 irq shifts to intel_lrc.c
Quoting Daniele Ceraolo Spurio (2018-03-08 23:46:29) > The only usage outside the intel_lrc.c file is in the ringbuffer > init, but the irq mask calculated there is then overwritten for > all engines that have a non-zero shift, so we can drop it. > > This change is not aimed at code saving but at removing from > intel_engines information that does not apply to all gens that have > the engine. When checking without the temporary WARN_ON, code size > is basically unchanged: > > add/remove: 1/0 grow/shrink: 3/4 up/down: 70/-67 (3) > Function old new delta > logical_ring_setup 315 343 +28 > irq_shifts - 28 +28 > intel_init_render_ring_buffer258 268 +10 > reset_common_ring704 708 +4 > intel_engine_init_cmd_parser10641058 -6 > intel_engines_init_mmio 12641256 -8 > intel_ring_default_vfuncs584 563 -21 > intel_engines224 192 -32 > Total: Before=1479719, After=1479722, chg +0.00% > > Suggested-by: Michel Thierry > Signed-off-by: Daniele Ceraolo Spurio With the missing static const, Reviewed-by: Chris Wilson I had a look at restoring the use of engine->irq_shift in the irq handlers, and while that does shrink the code abit, rearranging the code brought even more savings. So I don't see a need to keep engine->irq_shift around, and we can always bring it back but unlikely if future gen do not need it. -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 series starting with [v2,1/3] drm/i915: store all mmio bases in intel_engines
== Series Details == Series: series starting with [v2,1/3] drm/i915: store all mmio bases in intel_engines URL : https://patchwork.freedesktop.org/series/39644/ State : success == Summary == Series 39644v1 series starting with [v2,1/3] drm/i915: store all mmio bases in intel_engines https://patchwork.freedesktop.org/api/1.0/series/39644/revisions/1/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 Test prime_vgem: Subgroup basic-fence-flip: pass -> FAIL (fi-ilk-650) fdo#104008 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 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:422s 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:499s 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:488s 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:481s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:466s 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:581s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:584s 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: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:394s fi-ilk-650 total:288 pass:227 dwarn:0 dfail:0 fail:1 skip:60 time:402s 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:421s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:467s 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:507s 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: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:534s 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:482s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:421s 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:391s Blacklisted hosts: fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:527s 469c28df8d66d3cc0a4a2e4e12433a5c92102022 drm-tip: 2018y-03m-08d-22h-40m-12s UTC integration manifest b70c67929415 drm/i915: move gen8 irq shifts to intel_lrc.c 879b9440fc97 drm/i915: add a selftest for the mmio_bases table ef4f215557ee drm/i915: store all mmio bases in intel_engines == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8279/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller
Originally we were inlining gen8_cs_irq_handler() and so expected the compiler to constant-fold away the irq_shift (so we had hardcoded it as opposed to use engine->irq_shift). However, we dropped the inline given the proliferation of gen8_cs_irq_handler()s. If we pull the shifting of the iir into the caller, we can shrink the code still further: add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-34 (-34) Function old new delta gen8_cs_irq_handler 123 118 -5 gen8_gt_irq_handler 261 248 -13 gen11_irq_handler722 706 -16 Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin Cc: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/i915_irq.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index babf81cf668b..84c0043e1637 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -1399,19 +1399,19 @@ static void snb_gt_irq_handler(struct drm_i915_private *dev_priv, } static void -gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir, int test_shift) +gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir) { struct intel_engine_execlists * const execlists = &engine->execlists; bool tasklet = false; - if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift)) { + if (iir & GT_CONTEXT_SWITCH_INTERRUPT) { if (READ_ONCE(engine->execlists.active)) { __set_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted); tasklet = true; } } - if (iir & (GT_RENDER_USER_INTERRUPT << test_shift)) { + if (iir & GT_RENDER_USER_INTERRUPT) { notify_ring(engine); tasklet |= USES_GUC_SUBMISSION(engine->i915); } @@ -1466,21 +1466,21 @@ static void gen8_gt_irq_handler(struct drm_i915_private *i915, { if (master_ctl & (GEN8_GT_RCS_IRQ | GEN8_GT_BCS_IRQ)) { gen8_cs_irq_handler(i915->engine[RCS], - gt_iir[0], GEN8_RCS_IRQ_SHIFT); + gt_iir[0] >> GEN8_RCS_IRQ_SHIFT); gen8_cs_irq_handler(i915->engine[BCS], - gt_iir[0], GEN8_BCS_IRQ_SHIFT); + gt_iir[0] >> GEN8_BCS_IRQ_SHIFT); } if (master_ctl & (GEN8_GT_VCS1_IRQ | GEN8_GT_VCS2_IRQ)) { gen8_cs_irq_handler(i915->engine[VCS], - gt_iir[1], GEN8_VCS1_IRQ_SHIFT); + gt_iir[1] >> GEN8_VCS1_IRQ_SHIFT); gen8_cs_irq_handler(i915->engine[VCS2], - gt_iir[1], GEN8_VCS2_IRQ_SHIFT); + gt_iir[1] >> GEN8_VCS2_IRQ_SHIFT); } if (master_ctl & GEN8_GT_VECS_IRQ) { gen8_cs_irq_handler(i915->engine[VECS], - gt_iir[3], GEN8_VECS_IRQ_SHIFT); + gt_iir[3] >> GEN8_VECS_IRQ_SHIFT); } if (master_ctl & (GEN8_GT_PM_IRQ | GEN8_GT_GUC_IRQ)) { @@ -2765,7 +2765,7 @@ static void __fini_wedge(struct wedge_me *w) static __always_inline void gen11_cs_irq_handler(struct intel_engine_cs * const engine, const u32 iir) { - gen8_cs_irq_handler(engine, iir, 0); + gen8_cs_irq_handler(engine, iir); } static void -- 2.16.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/3] drm/i915: store all mmio bases in intel_engines
== Series Details == Series: series starting with [v2,1/3] drm/i915: store all mmio bases in intel_engines URL : https://patchwork.freedesktop.org/series/39644/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: store all mmio bases in intel_engines Okay! Commit: drm/i915: add a selftest for the mmio_bases table Okay! Commit: drm/i915: move gen8 irq shifts to intel_lrc.c +drivers/gpu/drm/i915/intel_lrc.c:1581:14: warning: symbol 'irq_shifts' was not declared. Should it be static? ___ 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: add a selftest for the mmio_bases table
Check that the entries are in reverse gen order and that the first entry and all the following entries with gen > 0 have an mmio base set. Suggested-by: Chris Wilson Cc: Chris Wilson Signed-off-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/intel_engine_cs.c | 1 + .../gpu/drm/i915/selftests/i915_mock_selftests.h | 1 + drivers/gpu/drm/i915/selftests/intel_engine_cs.c | 48 ++ 3 files changed, 50 insertions(+) create mode 100644 drivers/gpu/drm/i915/selftests/intel_engine_cs.c diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index 08711665061c..a33171d82aee 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -2131,4 +2131,5 @@ void intel_disable_engine_stats(struct intel_engine_cs *engine) #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST) #include "selftests/mock_engine.c" +#include "selftests/intel_engine_cs.c" #endif diff --git a/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h b/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h index 9a48aa441743..2842f93ca29e 100644 --- a/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h +++ b/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h @@ -23,3 +23,4 @@ selftest(vma, i915_vma_mock_selftests) selftest(evict, i915_gem_evict_mock_selftests) selftest(gtt, i915_gem_gtt_mock_selftests) selftest(hugepages, i915_gem_huge_page_mock_selftests) +selftest(engine, intel_engine_cs_mock_selftests) diff --git a/drivers/gpu/drm/i915/selftests/intel_engine_cs.c b/drivers/gpu/drm/i915/selftests/intel_engine_cs.c new file mode 100644 index ..8ef453905520 --- /dev/null +++ b/drivers/gpu/drm/i915/selftests/intel_engine_cs.c @@ -0,0 +1,48 @@ +/* + * SPDX-License-Identifier: GPL-2.0 + * + * Copyright © 2018 Intel Corporation + */ + +#include "../i915_selftest.h" + +static int intel_mmio_bases_check(void) +{ + const struct engine_info *info; + int i, j; + u32 gen; + s32 prev; + + for (i = 0; i < ARRAY_SIZE(intel_engines); i++) { + info = &intel_engines[i]; + + for (prev = -1, j = MAX_MMIO_BASES -1; j >= 0; j--) { + gen = info->mmio_bases[j].gen; + + if (prev >= (s32)gen) { + pr_err("%s: engine[%d]: mmio base for gen %x " + "is before the one for gen %x\n", + __func__, i, gen, prev); + return -EINVAL; + } + + if ((j == 0 || gen > 0) && !info->mmio_bases[j].base) { + pr_err("%s: engine[%d]: invalid mmio base (%x) " + "for gen %x at entry %u\n", + __func__, i, info->mmio_bases[j].base, gen, j); + return -EINVAL; + } + + /* we can have multiple empty entries in a row */ + if (gen > 0) + prev = gen; + } + } + + return 0; +} + +int intel_engine_cs_mock_selftests(void) +{ + return intel_mmio_bases_check(); +} -- 2.16.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/3] drm/i915: move gen8 irq shifts to intel_lrc.c
The only usage outside the intel_lrc.c file is in the ringbuffer init, but the irq mask calculated there is then overwritten for all engines that have a non-zero shift, so we can drop it. This change is not aimed at code saving but at removing from intel_engines information that does not apply to all gens that have the engine. When checking without the temporary WARN_ON, code size is basically unchanged: add/remove: 1/0 grow/shrink: 3/4 up/down: 70/-67 (3) Function old new delta logical_ring_setup 315 343 +28 irq_shifts - 28 +28 intel_init_render_ring_buffer258 268 +10 reset_common_ring704 708 +4 intel_engine_init_cmd_parser10641058 -6 intel_engines_init_mmio 12641256 -8 intel_ring_default_vfuncs584 563 -21 intel_engines224 192 -32 Total: Before=1479719, After=1479722, chg +0.00% Suggested-by: Michel Thierry Signed-off-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/intel_engine_cs.c | 10 -- drivers/gpu/drm/i915/intel_lrc.c| 22 +++--- drivers/gpu/drm/i915/intel_ringbuffer.c | 4 ++-- drivers/gpu/drm/i915/intel_ringbuffer.h | 1 - 4 files changed, 21 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index a33171d82aee..dbfeff6c46a8 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -92,7 +92,6 @@ struct engine_info { u32 gen : 8; u32 base : 24; } mmio_bases[MAX_MMIO_BASES]; - unsigned irq_shift; }; static const struct engine_info intel_engines[] = { @@ -104,7 +103,6 @@ static const struct engine_info intel_engines[] = { .mmio_bases = { { .gen = 0, .base = RENDER_RING_BASE } }, - .irq_shift = GEN8_RCS_IRQ_SHIFT, }, [BCS] = { .hw_id = BCS_HW, @@ -114,7 +112,6 @@ static const struct engine_info intel_engines[] = { .mmio_bases = { { .gen = 6, .base = BLT_RING_BASE } }, - .irq_shift = GEN8_BCS_IRQ_SHIFT, }, [VCS] = { .hw_id = VCS_HW, @@ -126,7 +123,6 @@ static const struct engine_info intel_engines[] = { { .gen = 6, .base = GEN6_BSD_RING_BASE }, { .gen = 4, .base = BSD_RING_BASE } }, - .irq_shift = GEN8_VCS1_IRQ_SHIFT, }, [VCS2] = { .hw_id = VCS2_HW, @@ -137,7 +133,6 @@ static const struct engine_info intel_engines[] = { { .gen = 11, .base = GEN11_BSD2_RING_BASE }, { .gen = 8, .base = GEN8_BSD2_RING_BASE } }, - .irq_shift = GEN8_VCS2_IRQ_SHIFT, }, [VCS3] = { .hw_id = VCS3_HW, @@ -147,7 +142,6 @@ static const struct engine_info intel_engines[] = { .mmio_bases = { { .gen = 11, .base = GEN11_BSD3_RING_BASE } }, - .irq_shift = 0, /* not used */ }, [VCS4] = { .hw_id = VCS4_HW, @@ -157,7 +151,6 @@ static const struct engine_info intel_engines[] = { .mmio_bases = { { .gen = 11, .base = GEN11_BSD4_RING_BASE } }, - .irq_shift = 0, /* not used */ }, [VECS] = { .hw_id = VECS_HW, @@ -168,7 +161,6 @@ static const struct engine_info intel_engines[] = { { .gen = 11, .base = GEN11_VEBOX_RING_BASE }, { .gen = 7, .base = VEBOX_RING_BASE } }, - .irq_shift = GEN8_VECS_IRQ_SHIFT, }, [VECS2] = { .hw_id = VECS2_HW, @@ -178,7 +170,6 @@ static const struct engine_info intel_engines[] = { .mmio_bases = { { .gen = 11, .base = GEN11_VEBOX2_RING_BASE } }, - .irq_shift = 0, /* not used */ }, }; @@ -298,7 +289,6 @@ intel_engine_setup(struct drm_i915_private *dev_priv, sizeof(engine->name)); engine->hw_id = engine->guc_id = info->hw_id; engine->mmio_base = __engine_mmio_base(dev_priv, info->mmio_bases); - engine->irq_shift = info->irq_shift; engine->class = info->class; engine->instance = info->instance; diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 999d5f2539d4..1bf8e16d7fa3 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1573,6 +1573,14 @@ static u8 gtiir[] = { [VECS] = 3, };
[Intel-gfx] [PATCH v2 1/3] drm/i915: store all mmio bases in intel_engines
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. v2: document that the list goes in reverse order, update starting gen for render (Chris) Cc: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin Signed-off-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/intel_engine_cs.c | 78 + drivers/gpu/drm/i915/intel_ringbuffer.c | 1 - 2 files changed, 50 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..08711665061c 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -81,12 +81,17 @@ 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; + /* mmio bases table *must* be sorted in reverse gen order */ + struct engine_mmio_base { + u32 gen : 8; + u32 base : 24; + } mmio_bases[MAX_MMIO_BASES]; unsigned irq_shift; }; @@ -96,7 +101,9 @@ static const struct engine_info intel_engines[] = { .uabi_id = I915_EXEC_RENDER, .class = RENDER_CLASS, .instance = 0, - .mmio_base = RENDER_RING_BASE, + .mmio_bases = { + { .gen = 0, .base = RENDER_RING_BASE } + }, .irq_shift = GEN8_RCS_IRQ_SHIFT, }, [BCS] = { @@ -104,7 +111,9 @@ static const struct engine_info intel_engines[] = { .uabi_id = I915_EXEC_BLT, .class = COPY_ENGINE_CLASS, .instance = 0, - .mmio_base = BLT_RING_BASE, + .mmio_bases = { + { .gen = 6, .base = BLT_RING_BASE } + }, .irq_shift = GEN8_BCS_IRQ_SHIFT, }, [VCS] = { @@ -112,7 +121,11 @@ static const struct engine_info intel_engines[] = { .uabi_id = I915_EXEC_BSD, .class = VIDEO_DECODE_CLASS, .instance = 0, - .mmio_base = GEN6_BSD_RING_BASE, + .mmio_bases = { + { .gen = 11, .base = GEN11_BSD_RING_BASE }, + { .gen = 6, .base = GEN6_BSD_RING_BASE }, + { .gen = 4, .base = BSD_RING_BASE } + }, .irq_shift = GEN8_VCS1_IRQ_SHIFT, }, [VCS2] = { @@ -120,7 +133,10 @@ static const struct engine_info intel_engines[] = { .uabi_id = I915_EXEC_BSD, .class = VIDEO_DECODE_CLASS, .instance = 1, - .mmio_base = GEN8_BSD2_RING_BASE, + .mmio_bases = { + { .gen = 11, .base = GEN11_BSD2_RING_BASE }, + { .gen = 8, .base = GEN8_BSD2_RING_BASE } + }, .irq_shift = GEN8_VCS2_IRQ_SHIFT, }, [VCS3] = { @@ -128,7 +144,9 @@ static const struct engine_info intel_engines[] = { .uabi_id = I915_EXEC_BSD, .class = VIDEO_DECODE_CLASS, .instance = 2, - .mmio_base = GEN11_BSD3_RING_BASE, + .mmio_bases = { + { .gen = 11, .base = GEN11_BSD3_RING_BASE } + }, .irq_shift = 0, /* not used */ }, [VCS4] = { @@ -136,7 +154,9 @@ static const struct engine_info intel_engines[] = { .uabi_id = I915_EXEC_BSD, .class = VIDEO_DECODE_CLASS, .instance = 3, - .mmio_base = GEN11_BSD4_RING_BASE, + .mmio_bases = { + { .gen = 11, .base = GEN11_BSD4_RING_BASE } + }, .irq_shift = 0, /* not used */ }, [VECS] = { @@ -144,7 +164,10 @@ static const struct engine_info intel_engines[] = { .uabi_id = I915_EXEC_VEBOX, .class = VIDEO_ENHANCEMENT_CLASS, .instance = 0, - .mmio_base = VEBOX_RING_BASE, + .mmio_bases = { + { .gen = 11, .base = GEN11_VEBOX_RING_BASE }, + { .gen = 7, .base = VEBOX_RING_BASE } + }, .irq_shift = GEN8_VECS_IRQ_SHIFT, }, [VECS2] = { @@ -152,7 +175,9 @@ static const struct engine_info intel_engines[] = { .uabi_id = I915_EXEC_VEBOX, .class = VIDEO_ENHANCEMENT_CLASS, .instance = 1, - .mmio_base = GEN1
[Intel-gfx] [PATCH v2 2/6] 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. V2: - Remove accidental duplicate modeset_retry_work in intel_connector Signed-off-by: Lyude Paul Cc: Manasi Navare Cc: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 23 +-- 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, 29 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f424fff477f6..85d5af4e4f5b 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -15394,16 +15394,35 @@ 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; /* 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); } + + if (connector->base.connector_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_work(&intel_dp->modeset_retry_work); } else { DRM_ERROR("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d", intel_connector->base.base.id, diff --git
[Intel-gfx] [PATCH 3/6] 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 3700fcfddb1f..e5d3ef6754a5 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -1110,6 +1110,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 5/6] 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] [PATCH 4/6] 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 0/6] Implement proper MST fallback retraining in i915
This is the first version of my patch series to implement MST fallback retraining in i915, along with improving the stability of i915's mst retraining in general. Additionally, it also introduces helpers into DRM to help with correctly handling MST fallback retraining so that other drivers may also implement it. If your driver has a homegrown implementation of this, you should convert it to these helpers to ensure that the behavior of atomic commits and connector's link status properties in the event of requiring retraining on an MST topology remains consistent between DRM drivers. Additionally, this lets me use the DisplayPort on my dock so I can finally free up the thunderbolt 3 connector on it for more useful things. At long last :). Cc: Manasi Navare Cc: Ville Syrjälä Lyude Paul (6): drm/i915: Remove unused DP_LINK_CHECK_TIMEOUT drm/i915: Move DP modeset retry work into intel_dp drm/i915: Only use one link bw config for MST topologies drm/dp_mst: Add drm_dp_mst_topology_mgr_lower_link_rate() drm/dp_mst: Add drm_atomic_dp_mst_retrain_topology() drm/i915: Implement proper fallback training for MST drivers/gpu/drm/drm_dp_mst_topology.c | 296 - drivers/gpu/drm/i915/intel_display.c | 23 +- drivers/gpu/drm/i915/intel_dp.c | 360 +++--- drivers/gpu/drm/i915/intel_dp_link_training.c | 2 +- drivers/gpu/drm/i915/intel_dp_mst.c | 64 +++-- drivers/gpu/drm/i915/intel_drv.h | 23 +- include/drm/drm_dp_mst_helper.h | 5 + 7 files changed, 662 insertions(+), 111 deletions(-) -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/6] 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 2/6] 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 Cc: Manasi Navare Cc: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 23 +-- 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 | 9 ++--- 4 files changed, 32 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f424fff477f6..85d5af4e4f5b 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -15394,16 +15394,35 @@ 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; /* 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); } + + if (connector->base.connector_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_work(&intel_dp->modeset_retry_work); } else { DRM_ERROR("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d", intel_connector->base.base.id, diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
[Intel-gfx] [PATCH 1/6] drm/i915: Remove unused DP_LINK_CHECK_TIMEOUT
Signed-off-by: Lyude Paul Cc: Manasi Navare Cc: Ville Syrjälä --- drivers/gpu/drm/i915/intel_dp.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 9a4a51e79fa1..4dd1b2287dd6 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -43,7 +43,6 @@ #include #include "i915_drv.h" -#define DP_LINK_CHECK_TIMEOUT (10 * 1000) #define DP_DPRX_ESI_LEN 14 /* Compliance test status bits */ -- 2.14.3 ___ 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 08/03/18 13:00, 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)); + + 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); If you want to do this here for CT buffers you need to call this before resetting the GPU otherwise GuC will already be reset and won't be able to unregister the buffers. We can also just wipe the shared memory where the CT buffer info is stored but that doesn't sound too clean, although we might have to add the code for it anyway if we want to support the (unlikely) case where GuC dies on some error. Might also be interesting to release doorbells here to sync that state as well, but that's a task for a another time ;) BTW, are you planning to call this in the i915_reset flow as well or is the plan to add another dedicated function? 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] ✓ Fi.CI.BAT: success for drm/i915/uc: Sanitize uC
== Series Details == Series: drm/i915/uc: Sanitize uC URL : https://patchwork.freedesktop.org/series/39634/ State : success == Summary == Series 39634v1 drm/i915/uc: Sanitize uC https://patchwork.freedesktop.org/api/1.0/series/39634/revisions/1/mbox/ Known issues: Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-cnl-y3) fdo#104951 incomplete -> PASS (fi-snb-2520m) fdo#103713 Test prime_vgem: Subgroup basic-fence-flip: pass -> FAIL (fi-ilk-650) fdo#104008 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:423s 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:371s 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:489s 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:479s 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:409s 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:578s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:424s 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:395s fi-ilk-650 total:288 pass:227 dwarn:0 dfail:0 fail:1 skip:60 time:407s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:464s 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:467s 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: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:433s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:516s 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:499s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:486s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:419s 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:394s Blacklisted hosts: fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:19 time:524s 87ad36f3fa700da980f764c4e4184a38e1296560 drm-tip: 2018y-03m-08d-19h-40m-42s UTC integration manifest c250a776a2f9 HAX: Enable GuC for CI e27f9d79e311 drm/i915/uc: Sanitize uC together with GEM 3c79e5c3be57 drm/i915/uc: Sanitize uC options early == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8278/issues.html ___ 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
Quoting Michal Wajdeczko (2018-03-08 21:00:35) > 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 Lgtm, Reviewed-by: Chris Wilson Second opinions are welcome. > --- > 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)); I think we can say that our reset works for gen3+ well enough to use everywhere. (Certainly gen3/gen4 are no worse than gen5!) Future task for the brave. -Chris ___ 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/uc: Sanitize uC options early
Quoting Michal Wajdeczko (2018-03-08 21:00:34) > 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 -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 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 --- 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 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. 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)); + + 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, -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] drm/i915/uc: Sanitize uC
Attempt to sanitize uC for better alignment with rest of GEM driver. 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 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
Re: [Intel-gfx] [patch 1/1] drivers/gpu/drm/i915/intel_guc_log.c: work around gcc-4.4.4 union initializer issue
On Thu, 08 Mar 2018 12:06:46 +0200 Jani Nikula wrote: > On Wed, 07 Mar 2018, a...@linux-foundation.org wrote: > > From: Andrew Morton > > Subject: drivers/gpu/drm/i915/intel_guc_log.c: work around gcc-4.4.4 union > > initializer issue > > > > gcc-4.4.4 has problems with initalizers of anon unions. > > > > drivers/gpu/drm/i915/intel_guc_log.c: In function 'guc_log_control': > > drivers/gpu/drm/i915/intel_guc_log.c:64: error: unknown field > > 'logging_enabled' specified in initializer > > > > Work around this. > > Thanks for the patch, pushed to drm-intel-next-queued. > > That said, how long do we have to care about old compilers? I thought we > were converging on at the very least GCC 4.5 being required. Yes, I've seen some talk about that and it is about time for us to do it. I'm not sure what stage things are at though. ___ 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 [v2,01/15] drm/i915/guc: Tidy guc_log_control
== Series Details == Series: series starting with [v2,01/15] drm/i915/guc: Tidy guc_log_control URL : https://patchwork.freedesktop.org/series/39614/ 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 kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-spr-indfb-draw-render: fail -> PASS (shard-apl) Test perf: Subgroup gen8-unprivileged-single-ctx-counters: pass -> FAIL (shard-apl) Known issues: Test gem_eio: Subgroup in-flight: pass -> INCOMPLETE (shard-apl) fdo#105341 Test kms_chv_cursor_fail: Subgroup pipe-b-256x256-bottom-edge: dmesg-warn -> PASS (shard-snb) fdo#105185 +3 Test kms_flip: Subgroup 2x-plain-flip-ts-check: fail -> PASS (shard-hsw) fdo#100368 Test kms_frontbuffer_tracking: Subgroup fbc-1p-pri-indfb-multidraw: pass -> FAIL (shard-apl) fdo#103167 Test pm_lpsp: Subgroup screens-disabled: fail -> PASS (shard-hsw) fdo#104941 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941 shard-apltotal:3394 pass:1777 dwarn:2 dfail:0 fail:15 skip:1598 time:12071s shard-hswtotal:3467 pass:1773 dwarn:1 dfail:0 fail:1 skip:1691 time:11960s shard-snbtotal:3467 pass:1361 dwarn:3 dfail:0 fail:2 skip:2101 time:7012s Blacklisted hosts: shard-kbltotal:3397 pass:1875 dwarn:16 dfail:2 fail:16 skip:1486 time:9003s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8275/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 [01/10] drm/i915: Disable preemption and sleeping while using the punit sideband (rev2)
== Series Details == Series: series starting with [01/10] drm/i915: Disable preemption and sleeping while using the punit sideband (rev2) URL : https://patchwork.freedesktop.org/series/39555/ State : success == Summary == Series 39555v2 series starting with [01/10] drm/i915: Disable preemption and sleeping while using the punit sideband https://patchwork.freedesktop.org/api/1.0/series/39555/revisions/2/mbox/ Known issues: Test debugfs_test: Subgroup read_all_entries: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 Test kms_chamelium: Subgroup dp-crc-fast: pass -> DMESG-FAIL (fi-kbl-7500u) fdo#103841 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:423s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 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:501s 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:493s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:487s 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:468s 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:577s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:414s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:292s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:515s 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:412s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:470s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:423s fi-kbl-7500u total:288 pass:262 dwarn:1 dfail:1 fail:0 skip:24 time:467s 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:511s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:594s 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: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:498s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:484s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:422s 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:391s Blacklisted hosts: fi-cnl-drrs total:288 pass:255 dwarn:3 dfail:0 fail:2 skip:19 time:485s fi-cnl-y3 failed to collect. IGT log at Patchwork_8277/fi-cnl-y3/run0.log 87ad36f3fa700da980f764c4e4184a38e1296560 drm-tip: 2018y-03m-08d-19h-40m-42s UTC integration manifest 86da0206b71d drm/i915: Move sandybride pcode access to intel_sideband.c 80f90fac4da3 drm/i915: Merge sandybridge_pcode_(read|write) ec3612434469 drm/i915: Merge sbi read/write into a single accessor ce521d082fb6 drm/i915: Separate sideband declarations to intel_sideband.h 2c8be91bb1d3 drm/i915: Replace pcu_lock with sb_lock c07dbad89274 Revert "drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3" a76499db62c2 drm/i915: Reduce RPS update frequency on Valleyview/Cherryview 219d9d8c740e drm/i915: Lift sideband locking for vlv_punit_(read|write) 4dcb1da3ab87 drm/i915: Lift acquiring the vlv punit magic to a common sb-get 0bd6e0467372 drm/i915: Disable preemption and sleeping while using the punit sideband == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8277/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Replace pcu_lock with sb_lock
We now have two locks for sideband access. The general one covering sideband access across all generation, sb_lock, and a specific one covering sideband access via the punit on vlv/chv. After lifting the sb_lock around the punit into the callers, the pcu_lock is now redudant and can be separated from its other use to regulate RPS (essentially giving RPS a lock all of its own). v2: Extract a couple of minor bug fixes. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 47 drivers/gpu/drm/i915/i915_drv.h | 10 +-- drivers/gpu/drm/i915/i915_irq.c | 4 +- drivers/gpu/drm/i915/i915_sysfs.c | 32 +++- drivers/gpu/drm/i915/intel_cdclk.c | 28 --- drivers/gpu/drm/i915/intel_display.c| 6 -- drivers/gpu/drm/i915/intel_hdcp.c | 2 - drivers/gpu/drm/i915/intel_pm.c | 127 +++- drivers/gpu/drm/i915/intel_runtime_pm.c | 8 -- drivers/gpu/drm/i915/intel_sideband.c | 4 - 10 files changed, 93 insertions(+), 175 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 8e7820f94358..97053e0afe63 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -1074,8 +1074,6 @@ static int i915_frequency_info(struct seq_file *m, void *unused) } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) { u32 rpmodectl, freq_sts; - mutex_lock(&dev_priv->pcu_lock); - rpmodectl = I915_READ(GEN6_RP_CONTROL); seq_printf(m, "Video Turbo Mode: %s\n", yesno(rpmodectl & GEN6_RP_MEDIA_TURBO)); @@ -1110,7 +1108,6 @@ static int i915_frequency_info(struct seq_file *m, void *unused) seq_printf(m, "efficient (RPe) frequency: %d MHz\n", intel_gpu_freq(dev_priv, rps->efficient_freq)); - mutex_unlock(&dev_priv->pcu_lock); } else if (INTEL_GEN(dev_priv) >= 6) { u32 rp_state_limits; u32 gt_perf_status; @@ -1525,12 +1522,9 @@ static int gen6_drpc_info(struct seq_file *m) gen9_powergate_status = I915_READ(GEN9_PWRGT_DOMAIN_STATUS); } - if (INTEL_GEN(dev_priv) <= 7) { - mutex_lock(&dev_priv->pcu_lock); + if (INTEL_GEN(dev_priv) <= 7) sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS, &rc6vids); - mutex_unlock(&dev_priv->pcu_lock); - } seq_printf(m, "RC1e Enabled: %s\n", yesno(rcctl1 & GEN6_RC_CTL_RC1e_ENABLE)); @@ -1801,17 +1795,10 @@ static int i915_ring_freq_table(struct seq_file *m, void *unused) struct intel_rps *rps = &dev_priv->gt_pm.rps; unsigned int max_gpu_freq, min_gpu_freq; int gpu_freq, ia_freq; - int ret; if (!HAS_LLC(dev_priv)) return -ENODEV; - intel_runtime_pm_get(dev_priv); - - ret = mutex_lock_interruptible(&dev_priv->pcu_lock); - if (ret) - goto out; - min_gpu_freq = rps->min_freq; max_gpu_freq = rps->max_freq; if (IS_GEN9_BC(dev_priv) || IS_CANNONLAKE(dev_priv)) { @@ -1822,6 +1809,7 @@ static int i915_ring_freq_table(struct seq_file *m, void *unused) seq_puts(m, "GPU freq (MHz)\tEffective CPU freq (MHz)\tEffective Ring freq (MHz)\n"); + intel_runtime_pm_get(dev_priv); for (gpu_freq = min_gpu_freq; gpu_freq <= max_gpu_freq; gpu_freq++) { ia_freq = gpu_freq; sandybridge_pcode_read(dev_priv, @@ -1835,12 +1823,9 @@ static int i915_ring_freq_table(struct seq_file *m, void *unused) ((ia_freq >> 0) & 0xff) * 100, ((ia_freq >> 8) & 0xff) * 100); } - - mutex_unlock(&dev_priv->pcu_lock); - -out: intel_runtime_pm_put(dev_priv); - return ret; + + return 0; } static int i915_opregion(struct seq_file *m, void *unused) @@ -4178,7 +4163,7 @@ i915_max_freq_set(void *data, u64 val) DRM_DEBUG_DRIVER("Manually setting max freq to %llu\n", val); - ret = mutex_lock_interruptible(&dev_priv->pcu_lock); + ret = mutex_lock_interruptible(&rps->lock); if (ret) return ret; @@ -4191,8 +4176,8 @@ i915_max_freq_set(void *data, u64 val) hw_min = rps->min_freq; if (val < hw_min || val > hw_max || val < rps->min_freq_softlimit) { - mutex_unlock(&dev_priv->pcu_lock); - return -EINVAL; + ret = -EINVAL; + goto unlock; } rps->max_freq_softlimit = val; @@ -4200,9 +4185,9 @@ i915_max_freq_set(void *data, u64 val) if (intel_set_rps(dev_priv, val)) DRM_DEBUG_DRIVER("failed to update RPS to new softlimit\n"); - mutex_unlock(&dev_priv->pcu_lo
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/i915: Kick the rps worker when changing the boost frequency
Quoting Patchwork (2018-03-08 19:32:29) > == Series Details == > > Series: series starting with [CI,1/2] drm/i915: Kick the rps worker when > changing the boost frequency > URL : https://patchwork.freedesktop.org/series/39607/ > State : success > > == Summary == > > Possible new issues: > > Test kms_frontbuffer_tracking: > Subgroup fbc-1p-primscrn-spr-indfb-draw-render: > fail -> PASS (shard-apl) > > Known issues: > > Test gem_eio: > Subgroup in-flight-contexts: > pass -> INCOMPLETE (shard-apl) fdo#105341 +1 > Test kms_flip: > Subgroup flip-vs-expired-vblank: > pass -> FAIL (shard-hsw) fdo#102887 +2 > Subgroup plain-flip-fb-recreate-interruptible: > pass -> FAIL (shard-hsw) fdo#100368 > Test kms_rotation_crc: > Subgroup primary-rotation-180: > fail -> PASS (shard-snb) fdo#103925 > Subgroup sprite-rotation-90-pos-100-0: > fail -> PASS (shard-apl) fdo#105185 +3 > Test pm_lpsp: > Subgroup screens-disabled: > fail -> PASS (shard-hsw) fdo#104941 Much better. Thanks for the review, pushed and back to the main series. -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 series starting with [CI,1/2] drm/i915: Kick the rps worker when changing the boost frequency
== Series Details == Series: series starting with [CI,1/2] drm/i915: Kick the rps worker when changing the boost frequency URL : https://patchwork.freedesktop.org/series/39607/ State : success == Summary == Possible new issues: Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-spr-indfb-draw-render: fail -> PASS (shard-apl) Known issues: Test gem_eio: Subgroup in-flight-contexts: pass -> INCOMPLETE (shard-apl) fdo#105341 +1 Test kms_flip: Subgroup flip-vs-expired-vblank: pass -> FAIL (shard-hsw) fdo#102887 +2 Subgroup plain-flip-fb-recreate-interruptible: pass -> FAIL (shard-hsw) fdo#100368 Test kms_rotation_crc: Subgroup primary-rotation-180: fail -> PASS (shard-snb) fdo#103925 Subgroup sprite-rotation-90-pos-100-0: fail -> PASS (shard-apl) fdo#105185 +3 Test pm_lpsp: Subgroup screens-disabled: fail -> PASS (shard-hsw) fdo#104941 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#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925 fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185 fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941 shard-apltotal:3308 pass:1739 dwarn:1 dfail:0 fail:9 skip:1556 time:11399s shard-hswtotal:3467 pass:1769 dwarn:1 dfail:0 fail:5 skip:1691 time:11820s shard-snbtotal:3380 pass:1325 dwarn:2 dfail:0 fail:1 skip:2051 time:6805s Blacklisted hosts: shard-kbltotal:3308 pass:1829 dwarn:28 dfail:2 fail:9 skip:1438 time:8525s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8274/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)
On Thu, Mar 08, 2018 at 06:55:34PM +, Chris Wilson wrote: > Quoting Chris Wilson (2018-03-08 18:48:51) > > Quoting Matt Roper (2018-03-08 18:22:06) > > > * Option 2: Allow priority offset to be set in a much larger range > > >(e.g., [SHRT_MIN+1023,SHRT_MAX-1023]). This allows cgroups to have > > >effective priority ranges that don't overlap. cgroup ranges can also > > >be intentionally set above I915_PRIORITY_DISPLAY to allow us to > > >define classes of applications whose work is more important than > > >maintaining a stable framerate on the display. We'd also probably > > >need to shift the kernel idle context down to something like INT_MIN > > >instead of using -1024. > > > > INT_MIN+1 just to be awkward. (INT_MIN is I915_PRIORITY_INVALID.) > > > > Something to bear in mind is that I want to reserve the low 8 bits of > > ctx->priority for internal use (heuristic adjustments by the scheduler). > > Can shrink that to say 3 bits in the current scheme. > > > > 3bits for internal adjustment > > 20bits for user priority. > > 8bits for cgroup offset. > > signbit. > > > > Nothing prohibits us from moving to 64b if required. But 32b should be > > enough range for plenty of clients and cgroups, imo. Reducing cgroup > > offset to 6 bits would be nice :) > > Forgot to comment on the policy decision of I915_PRIORITY_DISPLAY. > It's naughty that it's a magic constant that isn't exposed to the > sysadmin, so I would still set it to the maximum priority possible under > the extended scheme (i.e. INT_MAX), but allow for it to be adjusted. > I915_SETPARAM *shivers* Maybe that's a topic for cgroup as well if we can > associate the pageflip with a process and find its interactivity settings. > > Can I expose just about any random policy decision through cgroup? > -Chris If the policy applies to a cgroup of processes, then we can deal with pretty much any kind of policy as long as we stick to the driver ioctl approach in this series. E.g., we could add a cgroup setting "eligible for display boost" so that only specific processes are eligible for a display boost. If we want to control a single overall system value (e.g., "set the display boost fixed value") we could technically do that by having such parameters set on the v2 hierarchy's root cgroup, but that seems a bit counterintuitive and I'm not sure if there's a benefit to doing so. Using a more general interface like I915_SETPARAM or sysfs or something seems more appropriate in that case. Matt -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Handle changing enable_psr parameter at runtime better
On Thu, Mar 08, 2018 at 10:07:05AM -0800, Pandiyan, Dhinakaran wrote: > > > > On Thu, 2018-03-08 at 18:52 +0100, Maarten Lankhorst wrote: > > Op 08-03-18 om 18:43 schreef Pandiyan, Dhinakaran: > > > > > > > > > On Thu, 2018-03-08 at 08:07 +0100, Maarten Lankhorst wrote: > > >> Op 07-03-18 om 23:22 schreef Pandiyan, Dhinakaran: > > >>> On Wed, 2018-03-07 at 17:39 +0100, Maarten Lankhorst wrote: > > Similar to enable_fbc, enable_psr was ignored at runtime if it was > > changed. The easiest fix is to pretend enable_psr is ignored at > > configure time, and never activate it for !enable_psr, so both cases > > are handled without modesets. > > >>> What about cases where psr_flush() is not called and consequently the > > >>> module parameter is not checked? With HW tracking, PSR is > > >>> enabled/disabled during modeset and the hardware is expected to exit and > > >>> activate PSR without driver intervention. > > >> It looks like intel_frontbuffer_flush always calls intel_psr_flush, > > >> so we at least get a PSR toggle after every atomic commit? > > > I have a patch to remove flush() from legacy_cursor_update(). We end up > > > with an inconsistent behavior when that patch gets merged, > > > cursor moves -> trigger psr exit but don't read module parameter > > > commits -> trigger psr exit but read module parameter > > Legacy cursor updates are special, I don't mind them not changing PSR. > > > Eventually, when we get to removing flush() from commits, then this > > > patch won't really be useful. And tests disabling/enabling PSR at > > > runtime will probably fail. > > Could we transition to debugfs for changing it at runtime? > > That does sound like a better idea. +1 > > > > > ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Remove support for legacy debugfs crc interface (rev2)
== Series Details == Series: drm/i915: Remove support for legacy debugfs crc interface (rev2) URL : https://patchwork.freedesktop.org/series/33053/ State : warning == Summary == Series 33053v2 drm/i915: Remove support for legacy debugfs crc interface https://patchwork.freedesktop.org/api/1.0/series/33053/revisions/2/mbox/ Possible new issues: Test kms_pipe_crc_basic: Subgroup bad-nb-words-1: pass -> SKIP (fi-bdw-5557u) pass -> SKIP (fi-bdw-gvtdvm) pass -> SKIP (fi-blb-e6850) pass -> SKIP (fi-bsw-n3050) pass -> SKIP (fi-bwr-2160) pass -> SKIP (fi-bxt-dsi) pass -> SKIP (fi-bxt-j4205) pass -> SKIP (fi-byt-j1900) pass -> SKIP (fi-byt-n2820) pass -> SKIP (fi-cfl-8700k) pass -> SKIP (fi-cfl-s2) pass -> SKIP (fi-cnl-y3) pass -> SKIP (fi-elk-e7500) pass -> SKIP (fi-gdg-551) pass -> SKIP (fi-glk-1) pass -> SKIP (fi-hsw-4770) pass -> SKIP (fi-ilk-650) pass -> SKIP (fi-ivb-3520m) pass -> SKIP (fi-ivb-3770) pass -> SKIP (fi-kbl-7500u) pass -> SKIP (fi-kbl-7567u) pass -> SKIP (fi-kbl-r) pass -> SKIP (fi-pnv-d510) pass -> SKIP (fi-skl-6260u) pass -> SKIP (fi-skl-6600u) pass -> SKIP (fi-skl-6700hq) pass -> SKIP (fi-skl-6700k2) pass -> SKIP (fi-skl-6770hq) pass -> SKIP (fi-skl-guc) pass -> SKIP (fi-snb-2600) Subgroup bad-nb-words-3: pass -> SKIP (fi-bdw-5557u) pass -> SKIP (fi-bdw-gvtdvm) pass -> SKIP (fi-blb-e6850) pass -> SKIP (fi-bsw-n3050) pass -> SKIP (fi-bwr-2160) pass -> SKIP (fi-bxt-dsi) pass -> SKIP (fi-bxt-j4205) pass -> SKIP (fi-byt-j1900) pass -> SKIP (fi-byt-n2820) pass -> SKIP (fi-cfl-8700k) pass -> SKIP (fi-cfl-s2) pass -> SKIP (fi-cnl-y3) pass -> SKIP (fi-elk-e7500) pass -> SKIP (fi-gdg-551) pass -> SKIP (fi-glk-1) pass -> SKIP (fi-hsw-4770) pass -> SKIP (fi-ilk-650) pass -> SKIP (fi-ivb-3520m) pass -> SKIP (fi-ivb-3770) pass -> SKIP (fi-kbl-7500u) pass -> SKIP (fi-kbl-7567u) pass -> SKIP (fi-kbl-r) pass -> SKIP (fi-pnv-d510) pass -> SKIP (fi-skl-6260u) pass -> SKIP (fi-skl-6600u) pass -> SKIP (fi-skl-6700hq) pass -> SKIP (fi-skl-6700k2) pass -> SKIP (fi-skl-6770hq) pass -> SKIP (fi-skl-guc) pass -> SKIP (fi-snb-2600) Subgroup bad-pipe: pass -> SKIP (fi-bdw-5557u) pass -> SKIP (fi-bdw-gvtdvm) pass -> SKIP (fi-blb-e6850) pass -> SKIP (fi-bsw-n3050) pass -> SKIP (fi-bwr-2160) pass -> SKIP (fi-bxt-dsi) pass -> SKIP (fi-bxt-j4205) pass -> SKIP (fi-byt-j1900) pass -> SKIP (fi-byt-n2820) pass -> SKIP (fi-cfl-8700k) pass -> SKIP (fi-cfl-s2) pass -> SKIP (fi-cnl-y3) pass -> SKIP (fi-elk-e7500) pass -> SKIP (fi-gdg-551) pass -> SKIP (fi-glk-1) pass -> SKIP (fi-hsw-4770) pass -> SKIP (fi-ilk-650) pass -> SKIP (fi-ivb-3520m) pass -> SKIP (fi-ivb-3770) pass -> SKIP (fi-kbl-7500u) pass -> SKIP (fi-kbl-7567u) pass -> SKIP (fi-kbl-r)
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove the impedance mismatch around intel_engine_enable_signaling
== Series Details == Series: drm/i915: Remove the impedance mismatch around intel_engine_enable_signaling URL : https://patchwork.freedesktop.org/series/39605/ State : success == Summary == Possible new issues: Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-spr-indfb-draw-render: fail -> PASS (shard-apl) Known issues: Test kms_chv_cursor_fail: Subgroup pipe-b-256x256-top-edge: pass -> DMESG-WARN (shard-snb) fdo#105185 +4 Test kms_flip: Subgroup 2x-plain-flip-ts-check: fail -> PASS (shard-hsw) fdo#100368 Test pm_lpsp: Subgroup screens-disabled: fail -> PASS (shard-hsw) fdo#104941 fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941 shard-apltotal:3467 pass:1824 dwarn:1 dfail:0 fail:9 skip:1632 time:12318s shard-hswtotal:3448 pass:1761 dwarn:1 dfail:0 fail:1 skip:1683 time:11697s shard-snbtotal:3467 pass:1361 dwarn:3 dfail:0 fail:2 skip:2101 time:7033s Blacklisted hosts: shard-kbltotal:3381 pass:1871 dwarn:27 dfail:2 fail:9 skip:1471 time:9014s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8273/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)
Quoting Chris Wilson (2018-03-08 18:48:51) > Quoting Matt Roper (2018-03-08 18:22:06) > > * Option 2: Allow priority offset to be set in a much larger range > >(e.g., [SHRT_MIN+1023,SHRT_MAX-1023]). This allows cgroups to have > >effective priority ranges that don't overlap. cgroup ranges can also > >be intentionally set above I915_PRIORITY_DISPLAY to allow us to > >define classes of applications whose work is more important than > >maintaining a stable framerate on the display. We'd also probably > >need to shift the kernel idle context down to something like INT_MIN > >instead of using -1024. > > INT_MIN+1 just to be awkward. (INT_MIN is I915_PRIORITY_INVALID.) > > Something to bear in mind is that I want to reserve the low 8 bits of > ctx->priority for internal use (heuristic adjustments by the scheduler). > Can shrink that to say 3 bits in the current scheme. > > 3bits for internal adjustment > 20bits for user priority. > 8bits for cgroup offset. > signbit. > > Nothing prohibits us from moving to 64b if required. But 32b should be > enough range for plenty of clients and cgroups, imo. Reducing cgroup > offset to 6 bits would be nice :) Forgot to comment on the policy decision of I915_PRIORITY_DISPLAY. It's naughty that it's a magic constant that isn't exposed to the sysadmin, so I would still set it to the maximum priority possible under the extended scheme (i.e. INT_MAX), but allow for it to be adjusted. I915_SETPARAM *shivers* Maybe that's a topic for cgroup as well if we can associate the pageflip with a process and find its interactivity settings. Can I expose just about any random policy decision through cgroup? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)
Quoting Matt Roper (2018-03-08 18:22:06) > On Thu, Mar 08, 2018 at 01:11:33PM +, Chris Wilson wrote: > > Quoting Chris Wilson (2018-03-08 11:32:04) > > > Quoting Matt Roper (2018-03-06 23:46:59) > > > > There are cases where a system integrator may wish to raise/lower the > > > > priority of GPU workloads being submitted by specific OS process(es), > > > > independently of how the software self-classifies its own priority. > > > > Exposing "priority offset" as an i915-specific cgroup parameter will > > > > enable such system-level configuration. > > > > > > > > Normally GPU contexts start with a priority value of 0 > > > > (I915_CONTEXT_DEFAULT_PRIORITY) and then may be adjusted up/down from > > > > there via other mechanisms. We'd like to provide a system-level input > > > > to the priority decision that will be taken into consideration, even > > > > when userspace later attempts to set an absolute priority value via > > > > I915_CONTEXT_PARAM_PRIORITY. The priority offset introduced here > > > > provides a base value that will always be added to (or subtracted from) > > > > the software's self-assigned priority value. > > > > > > > > This patch makes priority offset a cgroup-specific value; contexts will > > > > be created with a priority offset based on the cgroup membership of the > > > > process creating the context at the time the context is created. Note > > > > that priority offset is assigned at context creation time; migrating a > > > > process to a different cgroup or changing the offset associated with a > > > > cgroup will only affect new context creation and will not alter the > > > > behavior of existing contexts previously created by the process. > > > > > > > > v2: > > > > - Rebase onto new cgroup_priv API > > > > - Use current instead of drm_file->pid to determine which process to > > > >lookup priority for. (Chris) > > > > - Don't forget to subtract priority offset in context_getparam ioctl to > > > >make it match setparam behavior. (Chris) > > > > > > > > Signed-off-by: Matt Roper > > > > > > For ctx->priority/ctx->priority_offset > > > Reviewed-by: Chris Wilson > > > > As a reminder, we do have the question of how to bound ctx->priority + > > ctx->priority_offset. Currently, outside of the user range is privileged > > space reserved for the kernel (both above and below). Now we can move > > those even further to accommodate multiple non-overlapping cgroups. > > Yep, I mentioned this as an open question in the series coverletter. > > My understanding is that today we limit userspace-assigned priorities to > [1023,1023] and that the kernel can use the userspace range plus -1024 > (for the kernel idle context), 1024 (for boosting contexts the display > is waiting on), and INT_MAX (for the preempt context). Are there any > other special values we use today that I'm overlooking? > > I think we have the following options with how to proceed: > > * Option 1: Silently limit (priority+priority offset) to the existing >[-1023,1023] range. That means that if, for example, a user context >had a priority offset of 600 and tried to manually boost its context >priority to 600, it would simply be treated as a 1023 for scheduling >purposes. This approach is simple, but doesn't allow us to force >contexts in different cgroups into non-overlapping priority ranges >(i.e., lowest possible priority in one cgroup is still higher than >the highest possible priority in another cgroup). It also isn't >possible to define a class of applications as "more important than >display" via cgroup, which I think might be useful in some cases. Agreed, non-overlapping seems to be a useful property (apply the usual disclaimer for the rudimentary scheduler). > * Option 2: Allow priority offset to be set in a much larger range >(e.g., [SHRT_MIN+1023,SHRT_MAX-1023]). This allows cgroups to have >effective priority ranges that don't overlap. cgroup ranges can also >be intentionally set above I915_PRIORITY_DISPLAY to allow us to >define classes of applications whose work is more important than >maintaining a stable framerate on the display. We'd also probably >need to shift the kernel idle context down to something like INT_MIN >instead of using -1024. INT_MIN+1 just to be awkward. (INT_MIN is I915_PRIORITY_INVALID.) Something to bear in mind is that I want to reserve the low 8 bits of ctx->priority for internal use (heuristic adjustments by the scheduler). Can shrink that to say 3 bits in the current scheme. 3bits for internal adjustment 20bits for user priority. 8bits for cgroup offset. signbit. Nothing prohibits us from moving to 64b if required. But 32b should be enough range for plenty of clients and cgroups, imo. Reducing cgroup offset to 6 bits would be nice :) > * Option 3: No limits, leave behavior as it stands now in this patch >series (unrestricted range). If you're privileged enough to define >the
Re: [Intel-gfx] [RFC] drm/i915: store all mmio bases in intel_engines
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: add/remove: 0/0 grow/shrink: 3/1 up/down: 100/-7 (93) Function old new delta intel_engines160 224 +64 __func__ 13891 13910 +19 intel_engines_init_mmio 12471264 +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. Daniele Regards, Tvrtko @@ -96,7 +100,9 @@ static const struct engine_info intel_engines[] = { .uabi_id = I915_EXEC_RENDER, .class = RENDER_CLASS, .instance = 0, - .mmio_base = RENDER_RING_BASE, + .mmio_bases = { + { .gen = 1, .base = RENDER_RING_BASE } + }, .irq_shift = GEN8_RCS_IRQ_SHIFT, }, [BCS] = { @@ -104,7 +110,9 @@ static const struct engine_info intel_engines[] = { .uabi_id = I915_EXEC_BLT, .class = COPY_ENGINE_CLASS, .instance = 0, - .mmio_base = BLT_RING_BASE, + .mmio_bases = { + { .gen = 6, .base = BLT_RING_BASE } + }, .irq_shift = GEN8_BCS_IRQ_SHIFT, }, [VCS] = { @@ -112,7 +120,11 @@ static const struct engine_info intel_engines[] = { .uabi_id = I915_EXEC_BSD, .class = VIDEO_DECODE_CLASS, .instance = 0, - .mmio_base = GEN6_BSD_RING_BASE, + .mmio_bases = { + { .gen = 11, .base = GEN11_BSD_RING_BASE }, + { .gen = 6, .base = GEN6_BSD_RING_BASE }, + { .gen = 4, .base = BSD_RING_BASE } + }, .irq_shift = GEN8_VCS1_IRQ_SHIFT, }, [VCS2] = { @@ -120,7 +132,10 @@ static const struct engine_info intel_engines[] = { .uabi_id = I915_EXEC_BSD, .class = VIDEO_DECODE_CLASS, .instan
[Intel-gfx] [PATCH] drm/i915: Remove support for legacy debugfs crc interface
This interface is deprecated, and has been replaced by the upstream drm crc interface. Signed-off-by: Maarten Lankhorst Cc: Tomi Sarvela Cc: Petri Latvala Cc: Jani Nikula Cc: Ville Syrjälä Acked-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_debugfs.c | 7 +- drivers/gpu/drm/i915/i915_drv.h | 11 +- drivers/gpu/drm/i915/i915_irq.c | 79 ++ drivers/gpu/drm/i915/intel_drv.h | 2 - drivers/gpu/drm/i915/intel_pipe_crc.c | 446 -- 5 files changed, 24 insertions(+), 521 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 89f7ff2c652e..8f0570def4c8 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -4771,7 +4771,6 @@ static const struct i915_debugfs_files { {"i915_gpu_info", &i915_gpu_info_fops}, #endif {"i915_next_seqno", &i915_next_seqno_fops}, - {"i915_display_crc_ctl", &i915_display_crc_ctl_fops}, {"i915_pri_wm_latency", &i915_pri_wm_latency_fops}, {"i915_spr_wm_latency", &i915_spr_wm_latency_fops}, {"i915_cur_wm_latency", &i915_cur_wm_latency_fops}, @@ -4789,7 +4788,7 @@ int i915_debugfs_register(struct drm_i915_private *dev_priv) { struct drm_minor *minor = dev_priv->drm.primary; struct dentry *ent; - int ret, i; + int i; ent = debugfs_create_file("i915_forcewake_user", S_IRUSR, minor->debugfs_root, to_i915(minor->dev), @@ -4797,10 +4796,6 @@ int i915_debugfs_register(struct drm_i915_private *dev_priv) if (!ent) return -ENOMEM; - ret = intel_pipe_crc_create(minor); - if (ret) - return ret; - for (i = 0; i < ARRAY_SIZE(i915_debugfs_files); i++) { ent = debugfs_create_file(i915_debugfs_files[i].name, S_IRUGO | S_IWUSR, diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 6e740f6fe33f..0a51eae8ce27 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1525,20 +1525,11 @@ enum intel_pipe_crc_source { INTEL_PIPE_CRC_SOURCE_MAX, }; -struct intel_pipe_crc_entry { - uint32_t frame; - uint32_t crc[5]; -}; - #define INTEL_PIPE_CRC_ENTRIES_NR 128 struct intel_pipe_crc { spinlock_t lock; - bool opened;/* exclusive access to the result file */ - struct intel_pipe_crc_entry *entries; - enum intel_pipe_crc_source source; - int head, tail; - wait_queue_head_t wq; int skipped; + enum intel_pipe_crc_source source; }; struct i915_frontbuffer_tracking { diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index babf81cf668b..26c1014eb1f7 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -1620,69 +1620,34 @@ static void display_pipe_crc_irq_handler(struct drm_i915_private *dev_priv, uint32_t crc4) { struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[pipe]; - struct intel_pipe_crc_entry *entry; struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe); - struct drm_driver *driver = dev_priv->drm.driver; uint32_t crcs[5]; - int head, tail; spin_lock(&pipe_crc->lock); - if (pipe_crc->source && !crtc->base.crc.opened) { - if (!pipe_crc->entries) { - spin_unlock(&pipe_crc->lock); - DRM_DEBUG_KMS("spurious interrupt\n"); - return; - } - - head = pipe_crc->head; - tail = pipe_crc->tail; - - if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) { - spin_unlock(&pipe_crc->lock); - DRM_ERROR("CRC buffer overflowing\n"); - return; - } - - entry = &pipe_crc->entries[head]; - - entry->frame = driver->get_vblank_counter(&dev_priv->drm, pipe); - entry->crc[0] = crc0; - entry->crc[1] = crc1; - entry->crc[2] = crc2; - entry->crc[3] = crc3; - entry->crc[4] = crc4; - - head = (head + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1); - pipe_crc->head = head; - - spin_unlock(&pipe_crc->lock); - - wake_up_interruptible(&pipe_crc->wq); - } else { - /* -* For some not yet identified reason, the first CRC is -* bonkers. So let's just wait for the next vblank and read -* out the buggy result. -* -* On GEN8+ sometimes the second CRC is bonkers as well, so -* don't trust that one either. -*/ - if (pipe_crc->skipped <= 0 || -
Re: [Intel-gfx] [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)
On Thu, Mar 08, 2018 at 01:11:33PM +, Chris Wilson wrote: > Quoting Chris Wilson (2018-03-08 11:32:04) > > Quoting Matt Roper (2018-03-06 23:46:59) > > > There are cases where a system integrator may wish to raise/lower the > > > priority of GPU workloads being submitted by specific OS process(es), > > > independently of how the software self-classifies its own priority. > > > Exposing "priority offset" as an i915-specific cgroup parameter will > > > enable such system-level configuration. > > > > > > Normally GPU contexts start with a priority value of 0 > > > (I915_CONTEXT_DEFAULT_PRIORITY) and then may be adjusted up/down from > > > there via other mechanisms. We'd like to provide a system-level input > > > to the priority decision that will be taken into consideration, even > > > when userspace later attempts to set an absolute priority value via > > > I915_CONTEXT_PARAM_PRIORITY. The priority offset introduced here > > > provides a base value that will always be added to (or subtracted from) > > > the software's self-assigned priority value. > > > > > > This patch makes priority offset a cgroup-specific value; contexts will > > > be created with a priority offset based on the cgroup membership of the > > > process creating the context at the time the context is created. Note > > > that priority offset is assigned at context creation time; migrating a > > > process to a different cgroup or changing the offset associated with a > > > cgroup will only affect new context creation and will not alter the > > > behavior of existing contexts previously created by the process. > > > > > > v2: > > > - Rebase onto new cgroup_priv API > > > - Use current instead of drm_file->pid to determine which process to > > >lookup priority for. (Chris) > > > - Don't forget to subtract priority offset in context_getparam ioctl to > > >make it match setparam behavior. (Chris) > > > > > > Signed-off-by: Matt Roper > > > > For ctx->priority/ctx->priority_offset > > Reviewed-by: Chris Wilson > > As a reminder, we do have the question of how to bound ctx->priority + > ctx->priority_offset. Currently, outside of the user range is privileged > space reserved for the kernel (both above and below). Now we can move > those even further to accommodate multiple non-overlapping cgroups. Yep, I mentioned this as an open question in the series coverletter. My understanding is that today we limit userspace-assigned priorities to [1023,1023] and that the kernel can use the userspace range plus -1024 (for the kernel idle context), 1024 (for boosting contexts the display is waiting on), and INT_MAX (for the preempt context). Are there any other special values we use today that I'm overlooking? I think we have the following options with how to proceed: * Option 1: Silently limit (priority+priority offset) to the existing [-1023,1023] range. That means that if, for example, a user context had a priority offset of 600 and tried to manually boost its context priority to 600, it would simply be treated as a 1023 for scheduling purposes. This approach is simple, but doesn't allow us to force contexts in different cgroups into non-overlapping priority ranges (i.e., lowest possible priority in one cgroup is still higher than the highest possible priority in another cgroup). It also isn't possible to define a class of applications as "more important than display" via cgroup, which I think might be useful in some cases. * Option 2: Allow priority offset to be set in a much larger range (e.g., [SHRT_MIN+1023,SHRT_MAX-1023]). This allows cgroups to have effective priority ranges that don't overlap. cgroup ranges can also be intentionally set above I915_PRIORITY_DISPLAY to allow us to define classes of applications whose work is more important than maintaining a stable framerate on the display. We'd also probably need to shift the kernel idle context down to something like INT_MIN instead of using -1024. * Option 3: No limits, leave behavior as it stands now in this patch series (unrestricted range). If you're privileged enough to define the cgroup settings for a system and you decide to shoot yourself in the foot by setting them to nonsense values, that's your own fault. Thoughts? Any other options to consider? > We also have the presumption that only privileged processes can raise a > priority, but I presume the cgroup property itself is protected. > -Chris The way the code is written write now, anyone who has write access to the cgroup itself (i.e., can migrate processes into/out of the cgroup) is allowed to adjust the i915-specific cgroup settings. So this depends on how the cgroups-v2 filesystem was initially mounted and/or how the filesystem permissions were adjusted after the fact; the details may vary from system to system depending on the policy decisions of the system integrator / system administrator. But I think an off-the-shelf Linux dis
Re: [Intel-gfx] [PATCH igt] igt/drv_hangman: Check that the error state does hold the expected state
Quoting Antonio Argenziano (2018-03-05 19:10:37) > > > On 05/03/18 02:09, Chris Wilson wrote: > > Actually check the error state exists (!"No error state captured") and > > that it contains the expected engine dump. > > > > v2: Throw in some debug clues. > > > > Signed-off-by: Chris Wilson > > --- > > tests/drv_hangman.c | 12 > > 1 file changed, 12 insertions(+) > > > > diff --git a/tests/drv_hangman.c b/tests/drv_hangman.c > > index 38cb20c3..fa7becf5 100644 > > --- a/tests/drv_hangman.c > > +++ b/tests/drv_hangman.c > > @@ -129,6 +129,14 @@ static void check_error_state(const char > > *expected_ring_name, > > FILE *file = open_error(); > > char *line = NULL; > > size_t line_size = 0; > > + bool found = false; > > + > > + igt_debug("%s(expected ring name=%s, expected offset=%"PRIx64")\n", > > + __func__, expected_ring_name, expected_offset); > > + igt_debugfs_dump(device, "i915_error_state"); > > + > > + getline(&line, &line_size, file); > > + igt_assert(strcasecmp(line, "No error state captured")); > > > > while (getline(&line, &line_size, file) > 0) { > > char *dashes; > > @@ -168,12 +176,16 @@ static void check_error_state(const char > > *expected_ring_name, > >4*i, batch[i]); > > igt_assert(strstr(line, expected_line)); > > } > > + > > + found = true; > > break; > > } > > } > > > > free(line); > > fclose(file); > > + > > + igt_assert(found); > > Test changes look fine to me, failures on CI seems to be caused by the > test not waiting for reset to happen only before we would have not > caught it. > > Reviwed-by: Antonio Argenziano Fixed the kernel bug, clearing the way for this patch to land. Thanks for the review, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Handle changing enable_psr parameter at runtime better
On Thu, 2018-03-08 at 18:52 +0100, Maarten Lankhorst wrote: > Op 08-03-18 om 18:43 schreef Pandiyan, Dhinakaran: > > > > > > On Thu, 2018-03-08 at 08:07 +0100, Maarten Lankhorst wrote: > >> Op 07-03-18 om 23:22 schreef Pandiyan, Dhinakaran: > >>> On Wed, 2018-03-07 at 17:39 +0100, Maarten Lankhorst wrote: > Similar to enable_fbc, enable_psr was ignored at runtime if it was > changed. The easiest fix is to pretend enable_psr is ignored at > configure time, and never activate it for !enable_psr, so both cases > are handled without modesets. > >>> What about cases where psr_flush() is not called and consequently the > >>> module parameter is not checked? With HW tracking, PSR is > >>> enabled/disabled during modeset and the hardware is expected to exit and > >>> activate PSR without driver intervention. > >> It looks like intel_frontbuffer_flush always calls intel_psr_flush, > >> so we at least get a PSR toggle after every atomic commit? > > I have a patch to remove flush() from legacy_cursor_update(). We end up > > with an inconsistent behavior when that patch gets merged, > > cursor moves -> trigger psr exit but don't read module parameter > > commits -> trigger psr exit but read module parameter > Legacy cursor updates are special, I don't mind them not changing PSR. > > Eventually, when we get to removing flush() from commits, then this > > patch won't really be useful. And tests disabling/enabling PSR at > > runtime will probably fail. > Could we transition to debugfs for changing it at runtime? That does sound like a better idea. > > ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Only prune fences after wait-for-all
Quoting Matthew Auld (2018-03-08 17:48:48) > On 7 March 2018 at 17:13, Chris Wilson wrote: > > Currently, we only allow ourselves to prune the fences so long as > > all the waits completed (i.e. all the fences we checked were signaled), > > and that the reservation snapshot did not change across the wait. > > However, if we only waited for a subset of the reservation object, i.e. > > just waiting for the last writer to complete as opposed to all readers > > as well, then we would erroneously conclude we could prune the fences as > > indeed although all of our waits were successful, they did not represent > > the totality of the reservation object. > > > > v2: We only need to check the shared fences due to construction (i.e. > > all of the shared fences will be later than the exclusive fence, if > > any). > > > > Fixes: e54ca9774777 ("drm/i915: Remove completed fences after a wait") > > Signed-off-by: Chris Wilson > > Cc: Joonas Lahtinen > > Cc: Matthew Auld > > --- > > drivers/gpu/drm/i915/i915_gem.c | 16 > > 1 file changed, 12 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c > > b/drivers/gpu/drm/i915/i915_gem.c > > index a5bd07338b46..9b48b5101357 100644 > > --- a/drivers/gpu/drm/i915/i915_gem.c > > +++ b/drivers/gpu/drm/i915/i915_gem.c > > @@ -433,20 +433,28 @@ i915_gem_object_wait_reservation(struct > > reservation_object *resv, > > dma_fence_put(shared[i]); > > kfree(shared); > > > > + /* > > +* If both shared fences and an exclusive fence exist, > > +* then by construction the shared fences must be later > > +* than the exclusive fence. If we successfully wait for > > +* all the shared fences, we know that the exclusive fence > > +* must all be signaled. If all the shared fences are > > +* signaled, we can prune the array and recover the > > +* floating references on the fences/requests. > > +*/ > > prune_fences = count && timeout >= 0; > > } else { > > excl = reservation_object_get_excl_rcu(resv); > > } > > > > - if (excl && timeout >= 0) { > > + if (excl && timeout >= 0) > > timeout = i915_gem_object_wait_fence(excl, flags, timeout, > > rps_client); > > - prune_fences = timeout >= 0; > > - } > > > > dma_fence_put(excl); > > > > - /* Oportunistically prune the fences iff we know they have *all* > > been > > + /* > > +* Oportunistically prune the fences iff we know they have *all* > > been > Opportunistically > > Reviewed-by: Matthew Auld And a bonus spelling fix, thank you! Pushed, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Handle changing enable_psr parameter at runtime better
Op 08-03-18 om 18:43 schreef Pandiyan, Dhinakaran: > > > On Thu, 2018-03-08 at 08:07 +0100, Maarten Lankhorst wrote: >> Op 07-03-18 om 23:22 schreef Pandiyan, Dhinakaran: >>> On Wed, 2018-03-07 at 17:39 +0100, Maarten Lankhorst wrote: Similar to enable_fbc, enable_psr was ignored at runtime if it was changed. The easiest fix is to pretend enable_psr is ignored at configure time, and never activate it for !enable_psr, so both cases are handled without modesets. >>> What about cases where psr_flush() is not called and consequently the >>> module parameter is not checked? With HW tracking, PSR is >>> enabled/disabled during modeset and the hardware is expected to exit and >>> activate PSR without driver intervention. >> It looks like intel_frontbuffer_flush always calls intel_psr_flush, >> so we at least get a PSR toggle after every atomic commit? > I have a patch to remove flush() from legacy_cursor_update(). We end up > with an inconsistent behavior when that patch gets merged, > cursor moves -> trigger psr exit but don't read module parameter > commits -> trigger psr exit but read module parameter Legacy cursor updates are special, I don't mind them not changing PSR. > Eventually, when we get to removing flush() from commits, then this > patch won't really be useful. And tests disabling/enabling PSR at > runtime will probably fail. Could we transition to debugfs for changing it at runtime? ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Only prune fences after wait-for-all
On 7 March 2018 at 17:13, Chris Wilson wrote: > Currently, we only allow ourselves to prune the fences so long as > all the waits completed (i.e. all the fences we checked were signaled), > and that the reservation snapshot did not change across the wait. > However, if we only waited for a subset of the reservation object, i.e. > just waiting for the last writer to complete as opposed to all readers > as well, then we would erroneously conclude we could prune the fences as > indeed although all of our waits were successful, they did not represent > the totality of the reservation object. > > v2: We only need to check the shared fences due to construction (i.e. > all of the shared fences will be later than the exclusive fence, if > any). > > Fixes: e54ca9774777 ("drm/i915: Remove completed fences after a wait") > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen > Cc: Matthew Auld > --- > drivers/gpu/drm/i915/i915_gem.c | 16 > 1 file changed, 12 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index a5bd07338b46..9b48b5101357 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -433,20 +433,28 @@ i915_gem_object_wait_reservation(struct > reservation_object *resv, > dma_fence_put(shared[i]); > kfree(shared); > > + /* > +* If both shared fences and an exclusive fence exist, > +* then by construction the shared fences must be later > +* than the exclusive fence. If we successfully wait for > +* all the shared fences, we know that the exclusive fence > +* must all be signaled. If all the shared fences are > +* signaled, we can prune the array and recover the > +* floating references on the fences/requests. > +*/ > prune_fences = count && timeout >= 0; > } else { > excl = reservation_object_get_excl_rcu(resv); > } > > - if (excl && timeout >= 0) { > + if (excl && timeout >= 0) > timeout = i915_gem_object_wait_fence(excl, flags, timeout, > rps_client); > - prune_fences = timeout >= 0; > - } > > dma_fence_put(excl); > > - /* Oportunistically prune the fences iff we know they have *all* been > + /* > +* Oportunistically prune the fences iff we know they have *all* been Opportunistically 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] drm/i915: Handle changing enable_psr parameter at runtime better
On Thu, 2018-03-08 at 08:07 +0100, Maarten Lankhorst wrote: > Op 07-03-18 om 23:22 schreef Pandiyan, Dhinakaran: > > On Wed, 2018-03-07 at 17:39 +0100, Maarten Lankhorst wrote: > >> Similar to enable_fbc, enable_psr was ignored at runtime if it was > >> changed. The easiest fix is to pretend enable_psr is ignored at > >> configure time, and never activate it for !enable_psr, so both cases > >> are handled without modesets. > > What about cases where psr_flush() is not called and consequently the > > module parameter is not checked? With HW tracking, PSR is > > enabled/disabled during modeset and the hardware is expected to exit and > > activate PSR without driver intervention. > It looks like intel_frontbuffer_flush always calls intel_psr_flush, > so we at least get a PSR toggle after every atomic commit? I have a patch to remove flush() from legacy_cursor_update(). We end up with an inconsistent behavior when that patch gets merged, cursor moves -> trigger psr exit but don't read module parameter commits -> trigger psr exit but read module parameter Eventually, when we get to removing flush() from commits, then this patch won't really be useful. And tests disabling/enabling PSR at runtime will probably fail. > > ~Maarten > > >> Signed-off-by: Maarten Lankhorst > >> Tested-by: Benjamin Berg > >> Cc: Benjamin Berg > >> --- > >> drivers/gpu/drm/i915/intel_psr.c | 19 ++- > >> 1 file changed, 10 insertions(+), 9 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/i915/intel_psr.c > >> b/drivers/gpu/drm/i915/intel_psr.c > >> index 23175c5c4a50..ac3ce7a1c2a7 100644 > >> --- a/drivers/gpu/drm/i915/intel_psr.c > >> +++ b/drivers/gpu/drm/i915/intel_psr.c > >> @@ -502,11 +502,6 @@ void intel_psr_compute_config(struct intel_dp > >> *intel_dp, > >>if (!CAN_PSR(dev_priv)) > >>return; > >> > >> - if (!i915_modparams.enable_psr) { > >> - DRM_DEBUG_KMS("PSR disable by flag\n"); > >> - return; > >> - } > >> - > >>/* > >> * HSW spec explicitly says PSR is tied to port A. > >> * BDW+ platforms with DDI implementation of PSR have different > >> @@ -559,7 +554,10 @@ void intel_psr_compute_config(struct intel_dp > >> *intel_dp, > >> > >>crtc_state->has_psr = true; > >>crtc_state->has_psr2 = intel_psr2_config_valid(intel_dp, crtc_state); > >> - DRM_DEBUG_KMS("Enabling PSR%s\n", crtc_state->has_psr2 ? "2" : ""); > >> + if (i915_modparams.enable_psr) > >> + DRM_DEBUG_KMS("Enabling PSR%s\n", crtc_state->has_psr2 ? "2" : > >> ""); > >> + else > >> + DRM_DEBUG_KMS("PSR disable by flag\n"); > >> } > >> > >> static void intel_psr_activate(struct intel_dp *intel_dp) > >> @@ -652,7 +650,9 @@ void intel_psr_enable(struct intel_dp *intel_dp, > >>dev_priv->psr.enable_source(intel_dp, crtc_state); > >>dev_priv->psr.enabled = intel_dp; > >> > >> - if (INTEL_GEN(dev_priv) >= 9) { > >> + if (!i915_modparams.enable_psr) { > >> + DRM_DEBUG_KMS("PSR disable by flag\n"); > >> + } else if (INTEL_GEN(dev_priv) >= 9) { > >>intel_psr_activate(intel_dp); > >>} else { > >>/* > >> @@ -843,7 +843,7 @@ static void intel_psr_work(struct work_struct *work) > >> * recheck. Since psr_flush first clears this and then reschedules we > >> * won't ever miss a flush when bailing out here. > >> */ > >> - if (dev_priv->psr.busy_frontbuffer_bits) > >> + if (dev_priv->psr.busy_frontbuffer_bits || !i915_modparams.enable_psr) > >>goto unlock; > >> > >>intel_psr_activate(intel_dp); > >> @@ -1015,7 +1015,8 @@ void intel_psr_flush(struct drm_i915_private > >> *dev_priv, > >>return; > >> > >>mutex_lock(&dev_priv->psr.lock); > >> - if (!dev_priv->psr.enabled) { > >> + if (!dev_priv->psr.enabled || !i915_modparams.enable_psr) { > >> + intel_psr_exit(dev_priv); > >>mutex_unlock(&dev_priv->psr.lock); > >>return; > >>} > > ___ 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-08 17:33:11) > > > On 07/03/18 17:18, Chris Wilson wrote: > > Quoting Antonio Argenziano (2018-03-08 00:55:47) > >> > >> > >> On 07/03/18 14:49, Chris Wilson wrote: > >>> + gem_quiescent_gpu(fd); > >> > >> Check frequency has gone back to ~min. > > > > It's not that interesting a test (covered already by pmu) as we > > essentially lie anyway over idle. > > Agreed. I should mention somewhere the reason for all the gem_quiescent_gpu() spam here is because I want to make sure that no stray waitboosts affect the measurements. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Kill the remaining CHV HBR2 leftovers
On Thu, 2018-03-08 at 14:58 +0200, Ville Syrjälä wrote: > On Wed, Mar 07, 2018 at 09:41:06PM +, Pandiyan, Dhinakaran wrote: > > > > > > > > On Fri, 2018-03-02 at 11:56 +0200, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > AFAIK CHV was supposed to have HBR2 originally, but in the end the feature > > > was dropped. We still have some code leftovers from those early days. > > > Eliminate them. > > > > > > > Not much in the spec about HBR2 other than the support for TP3. Since we > > don't support HBR2 on CHV, removing the unused TPS3 bits looks correct. > > > > > > > > > The extra bit for the training pattern seems to be dead in the hardware. > > > I can set it (in fact I can set almost any reserved bit in the > > > registers) but it doesn't seem to interfere with the operation of the > > > hardware. Either that or I'm very lucky that my displays complete link > > > training with the incorrect pattern being sent out. > > > > > > > I don't think I follow this, are you saying there's no need to clear the > > TPS3 bit? Isn't it better to have the mask include 1 << 14, so that > > _intel_dp_set_link_train() clears the bit? > > I'm saying the bit doesn't actually seem to exist in hardware. In fact > most of my specs don't list it either. Looks like only the "K0" specs > have it. > Thanks for clarifying. Reviewed-by: Dhinakaran Pandiyan > > > > > > > > > Signed-off-by: Ville Syrjälä > > > --- > > > drivers/gpu/drm/i915/i915_reg.h | 2 -- > > > drivers/gpu/drm/i915/intel_dp.c | 20 > > > 2 files changed, 4 insertions(+), 18 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h > > > b/drivers/gpu/drm/i915/i915_reg.h > > > index 95a2e51ecbb0..f3efc242df2d 100644 > > > --- a/drivers/gpu/drm/i915/i915_reg.h > > > +++ b/drivers/gpu/drm/i915/i915_reg.h > > > @@ -5250,8 +5250,6 @@ enum { > > > #define DP_LINK_TRAIN_OFF (3 << 28) > > > #define DP_LINK_TRAIN_MASK (3 << 28) > > > #define DP_LINK_TRAIN_SHIFT28 > > > -#define DP_LINK_TRAIN_PAT_3_CHV(1 << 14) > > > -#define DP_LINK_TRAIN_MASK_CHV ((3 << 28)|(1<<14)) > > > > > > /* CPT Link training mode */ > > > #define DP_LINK_TRAIN_PAT_1_CPT(0 << 8) > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > > > b/drivers/gpu/drm/i915/intel_dp.c > > > index aba2f45819d8..df1772044208 100644 > > > --- a/drivers/gpu/drm/i915/intel_dp.c > > > +++ b/drivers/gpu/drm/i915/intel_dp.c > > > @@ -92,8 +92,6 @@ static const struct dp_link_dpll chv_dpll[] = { > > > { .p1 = 4, .p2 = 2, .n = 1, .m1 = 2, .m2 = 0x81a } }, > > > { 27, /* m2_int = 27, m2_fraction = 0 */ > > > { .p1 = 4, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } }, > > > - { 54, /* m2_int = 27, m2_fraction = 0 */ > > > - { .p1 = 2, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } } > > > }; > > > > > > /** > > > @@ -2908,10 +2906,7 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp, > > > } > > > > > > } else { > > > - if (IS_CHERRYVIEW(dev_priv)) > > > - *DP &= ~DP_LINK_TRAIN_MASK_CHV; > > > - else > > > - *DP &= ~DP_LINK_TRAIN_MASK; > > > + *DP &= ~DP_LINK_TRAIN_MASK; > > > > > > switch (dp_train_pat & DP_TRAINING_PATTERN_MASK) { > > > case DP_TRAINING_PATTERN_DISABLE: > > > @@ -2924,12 +2919,8 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp, > > > *DP |= DP_LINK_TRAIN_PAT_2; > > > break; > > > case DP_TRAINING_PATTERN_3: > > > - if (IS_CHERRYVIEW(dev_priv)) { > > > - *DP |= DP_LINK_TRAIN_PAT_3_CHV; > > > - } else { > > > - DRM_DEBUG_KMS("TPS3 not supported, using TPS2 > > > instead\n"); > > > - *DP |= DP_LINK_TRAIN_PAT_2; > > > - } > > > + DRM_DEBUG_KMS("TPS3 not supported, using TPS2 > > > instead\n"); > > > + *DP |= DP_LINK_TRAIN_PAT_2; > > > break; > > > } > > > } > > > @@ -3668,10 +3659,7 @@ intel_dp_link_down(struct intel_encoder *encoder, > > > DP &= ~DP_LINK_TRAIN_MASK_CPT; > > > DP |= DP_LINK_TRAIN_PAT_IDLE_CPT; > > > } else { > > > - if (IS_CHERRYVIEW(dev_priv)) > > > - DP &= ~DP_LINK_TRAIN_MASK_CHV; > > > - else > > > - DP &= ~DP_LINK_TRAIN_MASK; > > > + DP &= ~DP_LINK_TRAIN_MASK; > > > DP |= DP_LINK_TRAIN_PAT_IDLE; > > > } > > > I915_WRITE(intel_dp->output_reg, DP); > ___ 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 07/03/18 17:18, Chris Wilson wrote: Quoting Antonio Argenziano (2018-03-08 00:55:47) On 07/03/18 14:49, Chris Wilson wrote: +static void single(int fd, const struct intel_execution_engine *e) +{ + 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); + + gem_quiescent_gpu(fd); + measured = measure_frequency(pmu, 1); + igt_info("Initial (idle) freq: %.1fMHz\n",measured); + igt_require(measured >= min - 50 && measured <= min + 50); + + for (uint32_t freq = min + 50; freq <= max; freq += 100) { + set_freq(fd, ctx, freq, freq); + + gem_quiescent_gpu(fd); + spin = __igt_spin_batch_new(fd, ctx, engine, 0); + usleep(1); + + measured = measure_frequency(pmu, 5); + igt_debugfs_dump(fd, "i915_rps_boost_info"); + + igt_spin_batch_free(fd, spin); + igt_info("%s(single): Measured %.1fMHz, expected %dMhz\n", + e->name, measured, freq); + igt_assert(measured > freq - 100 && measured < freq + 100); + } + gem_quiescent_gpu(fd); Check frequency has gone back to ~min. It's not that interesting a test (covered already by pmu) as we essentially lie anyway over idle. Agreed. I would suggest to split here into two sub-tests. + spin = __igt_spin_batch_new(fd, ctx, engine, 0); + for (uint32_t freq = min + 50; freq <= max; freq += 100) { + igt_spin_t *kick; + + set_freq(fd, ctx, freq, freq); + + /* + * When requesting a new frequency on the currently + * executing context, it does not take effect until the + * next context switch. In this case, we trigger a lite + * restore. Is this enforced by the ABI? Enforced? No. The comment is precisely because it's not checked on calling whether the context is currently on the HW and trying hard to be sure that no one expects us to do that check. i.e. that set_freq() doesn't change frequency itself, but doesn't rule it out either as it may appear to have that effect due to many external factors. That is what I thought :). I see that you had a new version with more tests, I'll have a look at that. Thanks, Antonio -Chris ___ 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 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 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 ..f7e79ac3 --- /dev/null +++ b/tests/gem_ctx_freq.c @@ -0,0 +1,604 @@ +/* + * 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 8 + +#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) +{ + 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 (uint32_t freq = min + 50; freq <= max; freq += 100) { + uint32_t cur, discard; + + set_freq(fd, ctx, freq, freq); + get_freq(fd, ctx, &cur, &discard); + +
Re: [Intel-gfx] [RFC v3 09/12] drm: Add API for in-kernel clients
Den 06.03.2018 09.56, skrev Daniel Vetter: On Thu, Feb 22, 2018 at 09:06:50PM +0100, Noralf Trønnes wrote: This adds an API for writing in-kernel clients. TODO: - Flesh out and complete documentation. - Cloned displays is not tested. - Complete tiled display support and test it. - Test plug/unplug different monitors. - A runtime knob to prevent clients from attaching for debugging purposes. - Maybe a way to unbind individual client instances. - Maybe take the sysrq support in drm_fb_helper and move it here somehow. - Add suspend/resume callbacks. Does anyone know why fbdev requires suspend/resume? Signed-off-by: Noralf Trønnes The core client api I like. Some of the opens I'm seeing: - If we go with using the internal kms api directly instead of IOCTL wrappers then a huge pile of the functions you have here aren't needed (e.g. all the event stuff we can just directly use vblank events instead of all the wrapping). I'm leaning ever more into that direction, since much less code to add. Looking at drm_fb_helper once again I now see an opportunity to simplify the modesetting code by nuking drm_fb_helper_connector and stop maintaining an array of connectors. It looks to be possible to just create an array temporarily in drm_setup_crtcs() for the duration of the function. The connectors we care about are ref counted and attached to modesets. This would remove the need for drm_fb_helper_add_one_connector(). So I might be able to do struct drm_fb_helper_crtc -> drm_client_crtc and let the client API take over drm_setup_crtcs(). I'll give it a try. There is one challenge I see upfront and that's the i915 fb_helper callback in drm_setup_crtcs(). - The register/unregister model needs more thought. Allowing both clients to register whenever they want to, and drm_device instances to come and go is what fbcon has done, and the resulting locking is a horror show. I think if we require that all in-kernel drm_clients are registers when loading drm.ko (and enabled/disabled only per module options and Kconfig), then we can throw out all the locking. That avoids a lot of the headaches. 2nd, if the list of clients is static over the lifetime of drm.ko, we also don't need to iterate existing drivers. Which avoids me having to review the iterator patch (that's the other aspect where fbcon totally falls over and essentially just ignores a bunch of races). Are you talking about linking the clients into drm.ko? drivers/gpu/drm/Makefile: drm-$(CONFIG_DRM_CLIENT_BOOTSPLASH) += client/drm_bootsplash.o drivers/gpu/drm/drm_drv.c: static int __init drm_core_init(void) { + drm_bootsplash_register(); + drm_fbdev_register(); } drivers/gpu/drm/drm_internal.h: #ifdef DRM_CLIENT_BOOTSPLASH void drm_bootsplash_register(void); #else static inline void drm_bootsplash_register(void) { } #endif drivers/gpu/drm/client/drm_bootsplash.c: static const struct drm_client_funcs drm_bootsplash_funcs = { .name = "drm_bootsplash", .new = drm_bootsplash_new, .remove = drm_bootsplash_remove, .hotplug = drm_bootsplash_hotplug, }; void drm_bootsplash_register(void) { drm_client_register(&drm_bootsplash_funcs); } drivers/gpu/drm/drm_client.c: static LIST_HEAD(drm_client_funcs_list); void drm_client_register(const struct drm_client_funcs *funcs) { struct drm_client_funcs_entry *funcs_entry; funcs_entry = kzalloc(sizeof(*funcs_entry), GFP_KERNEL); if (!funcs_entry) { DRM_ERROR("Failed to register: %s\n", funcs->name); return; } funcs_entry->funcs = funcs; list_add(&funcs_entry->list, &drm_client_funcs_list); DRM_DEBUG_KMS("%s\n", funcs->name); } And each client having a runtime enable/disable knob: drivers/gpu/drm/client/drm_bootsplash.c: static bool drm_bootsplash_enabled = true; module_param_named(bootsplash_enabled, drm_bootsplash_enabled, bool, 0600); MODULE_PARM_DESC(bootsplash_enabled, "Enable bootsplash client [default=true]"); Simple USB Display A few months back while looking at the udl shmem code, I got the idea that I could turn a Raspberry Pi Zero into a $5 USB to HDMI/DSI/DPI/DBI/TV adapter. The host side would be a simple tinydrm driver using the kernel compression lib to speed up transfers. The gadget/device side would be a userspace app decompressing the buffer into an exported dumb buffer. While working with this client API I realized that I could use it and write a kernel gadget driver instead avoiding the challenge of going back and forth to userspace with the framebuffer. For such a client I would have preferred it to be a loadable module not linked into drm.ko to increase the chance that distributions would enable it. Noralf. --- drivers/gpu/drm/Kconfig |2 + drivers/gpu/drm/Makefile|3 +- drivers/gpu/drm/client/Kconfig |4 + drivers/gpu/drm/client/Makefile |1 + drivers/gpu/drm/client/drm_client.c | 161
Re: [Intel-gfx] vlv punit and sideband tidy
Quoting Rogozhkin, Dmitry V (2018-03-07 20:39:16) > On Wed, 2018-03-07 at 19:41 +, Chris Wilson wrote: > > Mika > > believes that if we keep the cpu in C0 whilst the gpu is busy, then > > it > > behaves much better -- but that is a very tough sell > > Chris, Mika, I wonder does i915 driver tries to keep CPU in C0 at the > moment already or you just consider this? That is what Mika looked at, setting C0 while the GPU is marked busy. Iirc, he was satisfied with the result, I just objected on the grounds that keeping the CPU at max frequency was unlikely to win any friends in HTPC. (Although, maybe my gut feeling here is backwards and killawatt reports differently.) > CPU while gpu is busy, could you, please, clarify what exactly and > point me to the code/key patches? Please, answer from BDW/SKL gen > perspective rather than VLV. Basically you do pm_qos_update_request() from i915_request::mark_busy(). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Handle pipe CRC around enabling/disabling pipe.
Op 08-03-18 om 17:21 schreef Ville Syrjälä: > On Thu, Mar 08, 2018 at 05:02:38PM +0100, Maarten Lankhorst wrote: >> Op 08-03-18 om 16:22 schreef Ville Syrjälä: >>> On Thu, Mar 08, 2018 at 01:02:02PM +0100, Maarten Lankhorst wrote: This will get rid of the following error: [ 74.730271] WARNING: CPU: 4 PID: 0 at drivers/gpu/drm/drm_vblank.c:614 drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0 [ 74.730311] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_intel crct10dif_pclmul snd_hda_codec crc32_pclmul snd_hwdep broadcom ghash_clmulni_intel snd_hda_core bcm_phy_lib snd_pcm tg3 lpc_ich mei_me mei prime_numbers [ 74.730353] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U 4.16.0-rc2-CI-CI_DRM_3822+ #1 [ 74.730355] Hardware name: Dell Inc. XPS 8300 /0Y2MRG, BIOS A06 10/17/2011 [ 74.730359] RIP: 0010:drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0 [ 74.730361] RSP: 0018:88022fb03d10 EFLAGS: 00010086 [ 74.730365] RAX: a0291d20 RBX: 88021a18 RCX: 0001 [ 74.730367] RDX: 820e7db8 RSI: 0001 RDI: 82068cea [ 74.730369] RBP: 88022fb03d70 R08: R09: 815d26d0 [ 74.730371] R10: R11: a0161ca0 R12: 0001 [ 74.730373] R13: 880212448008 R14: 880212448330 R15: [ 74.730376] FS: () GS:88022fb0() knlGS: [ 74.730378] CS: 0010 DS: ES: CR0: 80050033 [ 74.730380] CR2: 55edcbec9000 CR3: 02210001 CR4: 000606e0 [ 74.730382] Call Trace: [ 74.730385] [ 74.730397] drm_get_last_vbltimestamp+0x36/0x50 [ 74.730401] drm_update_vblank_count+0x64/0x240 [ 74.730409] drm_crtc_accurate_vblank_count+0x41/0x90 [ 74.730453] display_pipe_crc_irq_handler+0x176/0x220 [i915] [ 74.730497] i9xx_pipe_crc_irq_handler+0xfe/0x150 [i915] [ 74.730537] ironlake_irq_handler+0x618/0xa30 [i915] [ 74.730548] __handle_irq_event_percpu+0x3c/0x340 [ 74.730556] handle_irq_event_percpu+0x1b/0x50 [ 74.730561] handle_irq_event+0x2f/0x50 [ 74.730566] handle_edge_irq+0xe4/0x1b0 [ 74.730572] handle_irq+0x11/0x20 [ 74.730576] do_IRQ+0x5e/0x120 [ 74.730584] common_interrupt+0x84/0x84 [ 74.730586] [ 74.730591] RIP: 0010:cpuidle_enter_state+0xaa/0x350 [ 74.730593] RSP: 0018:c908beb8 EFLAGS: 0212 ORIG_RAX: ffde [ 74.730597] RAX: 880226b80040 RBX: 0031fc3e RCX: 0001 [ 74.730599] RDX: RSI: 8210fb59 RDI: 820c02e7 [ 74.730601] RBP: 0004 R08: 40af R09: 0018 [ 74.730603] R10: R11: R12: 0004 [ 74.730606] R13: e8d00430 R14: 001166120bf4 R15: 82294460 [ 74.730621] ? cpuidle_enter_state+0xa6/0x350 [ 74.730629] do_idle+0x188/0x1d0 [ 74.730636] cpu_startup_entry+0x14/0x20 [ 74.730641] start_secondary+0x129/0x160 [ 74.730646] secondary_startup_64+0xa5/0xb0 [ 74.730660] Code: e1 48 c7 c2 b8 7d 0e 82 be 01 00 00 00 48 c7 c7 ea 8c 06 82 e8 64 ec ff ff 48 8b 83 c8 07 00 00 48 83 78 28 00 0f 84 e2 fe ff ff <0f> 0b 45 31 ed e9 db fe ff ff 41 b8 d3 4d 62 10 89 c8 6a 03 41 [ 74.730754] ---[ end trace 14b1345705b68565 ]--- Changes since v1: - Don't try to apply CRC workaround when enabling pipe, it should already be enabled. Changes since v2: - Make crc functions for !DEBUGFS case inline. - Pass intel_crtc to crc functions. - Add comments to callsites. Changes since v3: - Cache selected source to pipe_crc->source. - Set pipe_crc->skipped to MIN_INT during disable to close a race condition. Changes since v4: - Handle fallout from setting pipe_crc->source in irq handler. Cc: Marta Löfstedt Reported-by: Marta Löfstedt Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105185 Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/i915_irq.c | 4 +-- drivers/gpu/drm/i915/intel_display.c | 10 +++ drivers/gpu/drm/i915/intel_drv.h | 9 ++ drivers/gpu/drm/i915/intel_pipe_crc.c | 53 ++- 4 files changed, 67 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index ce16003ef048..7807488084fe 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,01/15] drm/i915/guc: Tidy guc_log_control
== Series Details == Series: series starting with [v2,01/15] drm/i915/guc: Tidy guc_log_control URL : https://patchwork.freedesktop.org/series/39614/ State : success == Summary == Series 39614v1 series starting with [v2,01/15] drm/i915/guc: Tidy guc_log_control https://patchwork.freedesktop.org/api/1.0/series/39614/revisions/1/mbox/ Known issues: Test debugfs_test: Subgroup read_all_entries: incomplete -> PASS (fi-snb-2520m) fdo#103713 Test kms_frontbuffer_tracking: Subgroup basic: fail -> PASS (fi-cnl-y3) fdo#103167 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 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:420s 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:372s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:506s 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:488s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:494s 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: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:581s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:585s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:413s 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:401s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:410s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:471s 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:457s 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:590s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:427s 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:535s 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:485s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:424s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:522s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:396s fi-cfl-u failed to collect. IGT log at Patchwork_8275/fi-cfl-u/run0.log da319f89899feb1b6206d7092b10189a926a893c drm-tip: 2018y-03m-08d-12h-49m-27s UTC integration manifest 379600aecf1b HAX enable guc for CI 561313bdbb69 drm/i915/guc: Default to non-verbose GuC logging 9919f3c4ef62 drm/i915/guc: Allow user to control default GuC logging 7688a3d6c706 drm/i915/guc: Don't print out relay statistics when relay is disabled 4df6319cba38 drm/i915/guc: Always print log stats in i915_guc_info when using GuC d8d5b88cd0af drm/i915/guc: Get rid of GuC log runtime c6076d262079 drm/i915/guc: Move check for fast memcpy_wc to relay creation b39b496589fa drm/i915/guc: Split relay control and GuC log level b75cfe289828 drm/i915/guc: Flush directly in log unregister 538047832dbe drm/i915/guc: Merge log relay file and channel creation 1756525f1bea drm/i915/guc: Log runtime should consist of both mapping and relay db07f9ade606 drm/i915/guc: Keep GuC interrupts enabled when using GuC b1de17c10c7f drm/i915/guc: Move GuC notification handling to separate function aa0d71c08bab drm/i915/guc: Create common entry points for log register/unregister 8f3d72331b9e drm/i915/guc: Tidy guc_log_control == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8275/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: Handle pipe CRC around enabling/disabling pipe.
On Thu, Mar 08, 2018 at 05:02:38PM +0100, Maarten Lankhorst wrote: > Op 08-03-18 om 16:22 schreef Ville Syrjälä: > > On Thu, Mar 08, 2018 at 01:02:02PM +0100, Maarten Lankhorst wrote: > >> This will get rid of the following error: > >> [ 74.730271] WARNING: CPU: 4 PID: 0 at drivers/gpu/drm/drm_vblank.c:614 > >> drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0 > >> [ 74.730311] Modules linked in: vgem snd_hda_codec_hdmi > >> snd_hda_codec_realtek snd_hda_codec_generic i915 x86_pkg_temp_thermal > >> intel_powerclamp coretemp snd_hda_intel crct10dif_pclmul snd_hda_codec > >> crc32_pclmul snd_hwdep broadcom ghash_clmulni_intel snd_hda_core > >> bcm_phy_lib snd_pcm tg3 lpc_ich mei_me mei prime_numbers > >> [ 74.730353] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U > >> 4.16.0-rc2-CI-CI_DRM_3822+ #1 > >> [ 74.730355] Hardware name: Dell Inc. XPS 8300 /0Y2MRG, BIOS A06 > >> 10/17/2011 > >> [ 74.730359] RIP: 0010:drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0 > >> [ 74.730361] RSP: 0018:88022fb03d10 EFLAGS: 00010086 > >> [ 74.730365] RAX: a0291d20 RBX: 88021a18 RCX: > >> 0001 > >> [ 74.730367] RDX: 820e7db8 RSI: 0001 RDI: > >> 82068cea > >> [ 74.730369] RBP: 88022fb03d70 R08: R09: > >> 815d26d0 > >> [ 74.730371] R10: R11: a0161ca0 R12: > >> 0001 > >> [ 74.730373] R13: 880212448008 R14: 880212448330 R15: > >> > >> [ 74.730376] FS: () GS:88022fb0() > >> knlGS: > >> [ 74.730378] CS: 0010 DS: ES: CR0: 80050033 > >> [ 74.730380] CR2: 55edcbec9000 CR3: 02210001 CR4: > >> 000606e0 > >> [ 74.730382] Call Trace: > >> [ 74.730385] > >> [ 74.730397] drm_get_last_vbltimestamp+0x36/0x50 > >> [ 74.730401] drm_update_vblank_count+0x64/0x240 > >> [ 74.730409] drm_crtc_accurate_vblank_count+0x41/0x90 > >> [ 74.730453] display_pipe_crc_irq_handler+0x176/0x220 [i915] > >> [ 74.730497] i9xx_pipe_crc_irq_handler+0xfe/0x150 [i915] > >> [ 74.730537] ironlake_irq_handler+0x618/0xa30 [i915] > >> [ 74.730548] __handle_irq_event_percpu+0x3c/0x340 > >> [ 74.730556] handle_irq_event_percpu+0x1b/0x50 > >> [ 74.730561] handle_irq_event+0x2f/0x50 > >> [ 74.730566] handle_edge_irq+0xe4/0x1b0 > >> [ 74.730572] handle_irq+0x11/0x20 > >> [ 74.730576] do_IRQ+0x5e/0x120 > >> [ 74.730584] common_interrupt+0x84/0x84 > >> [ 74.730586] > >> [ 74.730591] RIP: 0010:cpuidle_enter_state+0xaa/0x350 > >> [ 74.730593] RSP: 0018:c908beb8 EFLAGS: 0212 ORIG_RAX: > >> ffde > >> [ 74.730597] RAX: 880226b80040 RBX: 0031fc3e RCX: > >> 0001 > >> [ 74.730599] RDX: RSI: 8210fb59 RDI: > >> 820c02e7 > >> [ 74.730601] RBP: 0004 R08: 40af R09: > >> 0018 > >> [ 74.730603] R10: R11: R12: > >> 0004 > >> [ 74.730606] R13: e8d00430 R14: 001166120bf4 R15: > >> 82294460 > >> [ 74.730621] ? cpuidle_enter_state+0xa6/0x350 > >> [ 74.730629] do_idle+0x188/0x1d0 > >> [ 74.730636] cpu_startup_entry+0x14/0x20 > >> [ 74.730641] start_secondary+0x129/0x160 > >> [ 74.730646] secondary_startup_64+0xa5/0xb0 > >> [ 74.730660] Code: e1 48 c7 c2 b8 7d 0e 82 be 01 00 00 00 48 c7 c7 ea 8c > >> 06 82 e8 64 ec ff ff 48 8b 83 c8 07 00 00 48 83 78 28 00 0f 84 e2 fe ff ff > >> <0f> 0b 45 31 ed e9 db fe ff ff 41 b8 d3 4d 62 10 89 c8 6a 03 41 > >> [ 74.730754] ---[ end trace 14b1345705b68565 ]--- > >> > >> Changes since v1: > >> - Don't try to apply CRC workaround when enabling pipe, it should already > >> be enabled. > >> Changes since v2: > >> - Make crc functions for !DEBUGFS case inline. > >> - Pass intel_crtc to crc functions. > >> - Add comments to callsites. > >> Changes since v3: > >> - Cache selected source to pipe_crc->source. > >> - Set pipe_crc->skipped to MIN_INT during disable to close a race > >> condition. > >> Changes since v4: > >> - Handle fallout from setting pipe_crc->source in irq handler. > >> > >> Cc: Marta Löfstedt > >> Reported-by: Marta Löfstedt > >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105185 > >> Signed-off-by: Maarten Lankhorst > >> --- > >> drivers/gpu/drm/i915/i915_irq.c | 4 +-- > >> drivers/gpu/drm/i915/intel_display.c | 10 +++ > >> drivers/gpu/drm/i915/intel_drv.h | 9 ++ > >> drivers/gpu/drm/i915/intel_pipe_crc.c | 53 > >> ++- > >> 4 files changed, 67 insertions(+), 9 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/i915/i915_irq.c > >> b/drivers/gpu/drm/i915/i915_irq.c > >> index ce16003ef048..7807488084fe 100644 > >> --- a/drivers/gpu/drm/i915/i915_irq.c > >> +++ b/drivers/gpu/drm/i915/i915_irq.c > >> @@ -1626,7 +1626,7 @@ sta
Re: [Intel-gfx] [PATCH] drm/i915: Handle pipe CRC around enabling/disabling pipe.
Op 08-03-18 om 16:22 schreef Ville Syrjälä: > On Thu, Mar 08, 2018 at 01:02:02PM +0100, Maarten Lankhorst wrote: >> This will get rid of the following error: >> [ 74.730271] WARNING: CPU: 4 PID: 0 at drivers/gpu/drm/drm_vblank.c:614 >> drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0 >> [ 74.730311] Modules linked in: vgem snd_hda_codec_hdmi >> snd_hda_codec_realtek snd_hda_codec_generic i915 x86_pkg_temp_thermal >> intel_powerclamp coretemp snd_hda_intel crct10dif_pclmul snd_hda_codec >> crc32_pclmul snd_hwdep broadcom ghash_clmulni_intel snd_hda_core bcm_phy_lib >> snd_pcm tg3 lpc_ich mei_me mei prime_numbers >> [ 74.730353] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U >> 4.16.0-rc2-CI-CI_DRM_3822+ #1 >> [ 74.730355] Hardware name: Dell Inc. XPS 8300 /0Y2MRG, BIOS A06 >> 10/17/2011 >> [ 74.730359] RIP: 0010:drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0 >> [ 74.730361] RSP: 0018:88022fb03d10 EFLAGS: 00010086 >> [ 74.730365] RAX: a0291d20 RBX: 88021a18 RCX: >> 0001 >> [ 74.730367] RDX: 820e7db8 RSI: 0001 RDI: >> 82068cea >> [ 74.730369] RBP: 88022fb03d70 R08: R09: >> 815d26d0 >> [ 74.730371] R10: R11: a0161ca0 R12: >> 0001 >> [ 74.730373] R13: 880212448008 R14: 880212448330 R15: >> >> [ 74.730376] FS: () GS:88022fb0() >> knlGS: >> [ 74.730378] CS: 0010 DS: ES: CR0: 80050033 >> [ 74.730380] CR2: 55edcbec9000 CR3: 02210001 CR4: >> 000606e0 >> [ 74.730382] Call Trace: >> [ 74.730385] >> [ 74.730397] drm_get_last_vbltimestamp+0x36/0x50 >> [ 74.730401] drm_update_vblank_count+0x64/0x240 >> [ 74.730409] drm_crtc_accurate_vblank_count+0x41/0x90 >> [ 74.730453] display_pipe_crc_irq_handler+0x176/0x220 [i915] >> [ 74.730497] i9xx_pipe_crc_irq_handler+0xfe/0x150 [i915] >> [ 74.730537] ironlake_irq_handler+0x618/0xa30 [i915] >> [ 74.730548] __handle_irq_event_percpu+0x3c/0x340 >> [ 74.730556] handle_irq_event_percpu+0x1b/0x50 >> [ 74.730561] handle_irq_event+0x2f/0x50 >> [ 74.730566] handle_edge_irq+0xe4/0x1b0 >> [ 74.730572] handle_irq+0x11/0x20 >> [ 74.730576] do_IRQ+0x5e/0x120 >> [ 74.730584] common_interrupt+0x84/0x84 >> [ 74.730586] >> [ 74.730591] RIP: 0010:cpuidle_enter_state+0xaa/0x350 >> [ 74.730593] RSP: 0018:c908beb8 EFLAGS: 0212 ORIG_RAX: >> ffde >> [ 74.730597] RAX: 880226b80040 RBX: 0031fc3e RCX: >> 0001 >> [ 74.730599] RDX: RSI: 8210fb59 RDI: >> 820c02e7 >> [ 74.730601] RBP: 0004 R08: 40af R09: >> 0018 >> [ 74.730603] R10: R11: R12: >> 0004 >> [ 74.730606] R13: e8d00430 R14: 001166120bf4 R15: >> 82294460 >> [ 74.730621] ? cpuidle_enter_state+0xa6/0x350 >> [ 74.730629] do_idle+0x188/0x1d0 >> [ 74.730636] cpu_startup_entry+0x14/0x20 >> [ 74.730641] start_secondary+0x129/0x160 >> [ 74.730646] secondary_startup_64+0xa5/0xb0 >> [ 74.730660] Code: e1 48 c7 c2 b8 7d 0e 82 be 01 00 00 00 48 c7 c7 ea 8c >> 06 82 e8 64 ec ff ff 48 8b 83 c8 07 00 00 48 83 78 28 00 0f 84 e2 fe ff ff >> <0f> 0b 45 31 ed e9 db fe ff ff 41 b8 d3 4d 62 10 89 c8 6a 03 41 >> [ 74.730754] ---[ end trace 14b1345705b68565 ]--- >> >> Changes since v1: >> - Don't try to apply CRC workaround when enabling pipe, it should already be >> enabled. >> Changes since v2: >> - Make crc functions for !DEBUGFS case inline. >> - Pass intel_crtc to crc functions. >> - Add comments to callsites. >> Changes since v3: >> - Cache selected source to pipe_crc->source. >> - Set pipe_crc->skipped to MIN_INT during disable to close a race condition. >> Changes since v4: >> - Handle fallout from setting pipe_crc->source in irq handler. >> >> Cc: Marta Löfstedt >> Reported-by: Marta Löfstedt >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105185 >> Signed-off-by: Maarten Lankhorst >> --- >> drivers/gpu/drm/i915/i915_irq.c | 4 +-- >> drivers/gpu/drm/i915/intel_display.c | 10 +++ >> drivers/gpu/drm/i915/intel_drv.h | 9 ++ >> drivers/gpu/drm/i915/intel_pipe_crc.c | 53 >> ++- >> 4 files changed, 67 insertions(+), 9 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/i915_irq.c >> b/drivers/gpu/drm/i915/i915_irq.c >> index ce16003ef048..7807488084fe 100644 >> --- a/drivers/gpu/drm/i915/i915_irq.c >> +++ b/drivers/gpu/drm/i915/i915_irq.c >> @@ -1626,7 +1626,7 @@ static void display_pipe_crc_irq_handler(struct >> drm_i915_private *dev_priv, >> int head, tail; >> >> spin_lock(&pipe_crc->lock); >> -if (pipe_crc->source) { >> +if (pipe_crc->source && !crtc->base.crc.opened) { > Hmm. This is starting to get confusing. S
[Intel-gfx] [PATCH v2 13/15] drm/i915/guc: Allow user to control default GuC logging
While both naming and actual log enable logic in GuC interface are confusing, we can simply expose the default log as yet another log level. GuC logic aside, from i915 point of view we now have the following GuC log levels: 0 Log disabled 1 Non-verbose log 2-5 Verbose log v2: Adjust naming after rebase. Signed-off-by: Michał Winiarski Cc: Chris Wilson Cc: Daniele Ceraolo Spurio Cc: Sagar Arun Kamble Cc: Michal Wajdeczko Reviewed-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_guc.c | 21 - drivers/gpu/drm/i915/intel_guc_fwif.h | 5 +++-- drivers/gpu/drm/i915/intel_guc_log.c | 18 +++--- drivers/gpu/drm/i915/intel_guc_log.h | 15 +++ drivers/gpu/drm/i915/intel_uc.c | 14 +- 5 files changed, 46 insertions(+), 27 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index 3e2f0f8503ed..fc21135e2a54 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -221,17 +221,20 @@ static u32 get_core_family(struct drm_i915_private *dev_priv) } } -static u32 get_log_verbosity_flags(void) +static u32 get_log_control_flags(void) { - if (i915_modparams.guc_log_level > 0) { - u32 verbosity = i915_modparams.guc_log_level - 1; + u32 level = i915_modparams.guc_log_level; + u32 flags = 0; - GEM_BUG_ON(verbosity > GUC_LOG_VERBOSITY_MAX); - return verbosity << GUC_LOG_VERBOSITY_SHIFT; - } + GEM_BUG_ON(level < 0); + + if (!GUC_LOG_LEVEL_TO_ENABLED(level)) + flags = GUC_LOG_DEFAULT_DISABLED | GUC_LOG_DISABLED; + else if (GUC_LOG_LEVEL_TO_VERBOSE(level)) + flags = GUC_LOG_LEVEL_TO_VERBOSITY(level) << + GUC_LOG_VERBOSITY_SHIFT; - GEM_BUG_ON(i915_modparams.enable_guc < 0); - return GUC_LOG_DISABLED; + return flags; } /* @@ -266,7 +269,7 @@ void intel_guc_init_params(struct intel_guc *guc) params[GUC_CTL_LOG_PARAMS] = guc->log.flags; - params[GUC_CTL_DEBUG] = get_log_verbosity_flags(); + params[GUC_CTL_DEBUG] = get_log_control_flags(); /* If GuC submission is enabled, set up additional parameters here */ if (USES_GUC_SUBMISSION(dev_priv)) { diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h b/drivers/gpu/drm/i915/intel_guc_fwif.h index 6a10aa6f04d3..4971685a2ea8 100644 --- a/drivers/gpu/drm/i915/intel_guc_fwif.h +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h @@ -127,7 +127,7 @@ #define GUC_PROFILE_ENABLED (1 << 7) #define GUC_WQ_TRACK_ENABLED (1 << 8) #define GUC_ADS_ENABLED (1 << 9) -#define GUC_DEBUG_RESERVED (1 << 10) +#define GUC_LOG_DEFAULT_DISABLED (1 << 10) #define GUC_ADS_ADDR_SHIFT 11 #define GUC_ADS_ADDR_MASK0xf800 @@ -539,7 +539,8 @@ union guc_log_control { u32 logging_enabled:1; u32 reserved1:3; u32 verbosity:4; - u32 reserved2:24; + u32 default_logging:1; + u32 reserved2:23; }; u32 value; } __packed; diff --git a/drivers/gpu/drm/i915/intel_guc_log.c b/drivers/gpu/drm/i915/intel_guc_log.c index a72fe4a369f4..decada3cf496 100644 --- a/drivers/gpu/drm/i915/intel_guc_log.c +++ b/drivers/gpu/drm/i915/intel_guc_log.c @@ -58,12 +58,14 @@ static int guc_log_flush(struct intel_guc *guc) return intel_guc_send(guc, action, ARRAY_SIZE(action)); } -static int guc_log_control(struct intel_guc *guc, bool enable, u32 verbosity) +static int guc_log_control(struct intel_guc *guc, bool enable, + bool default_logging, u32 verbosity) { union guc_log_control control_val = { { .logging_enabled = enable, .verbosity = verbosity, + .default_logging = default_logging, }, }; u32 action[] = { @@ -501,13 +503,6 @@ int intel_guc_log_level_get(struct intel_guc *guc) 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_level_set(struct intel_guc *guc, u64 val) { struct drm_i915_private *dev_priv = guc_to_i915(guc); @@ -522,7 +517,7 @@ int intel_guc_log_level_set(struct intel_guc *guc, u64 val) * as indication that logging should be disabled. */ if (val < GUC_LOG_LEVEL_DISABLED || - val > VERBOSITY_TO_LOG_LEVEL(GUC_LOG_VERBOSITY_MAX)) + val > GUC_VERBOSITY_TO_LOG_LEVEL(GUC_LOG_VERBOSITY_MAX)) return -EINVAL; mutex_lock(&dev_
[Intel-gfx] [PATCH v2 14/15] drm/i915/guc: Default to non-verbose GuC logging
Now that we've decoupled logging from relay, GuC log level is only controlling the GuC behavior - there shouldn't be any impact on i915 behaviour. We're only going to see a single extra interrupt when log will get half full. That, and the fact that we're seeing igt/gem_exec_nop/basic-series failing with non-verbose logging being disabled. v2: Bring back the "auto" guc_log_level, now that we fixed the log Signed-off-by: Michał Winiarski Cc: Chris Wilson Cc: Daniele Ceraolo Spurio Cc: Sagar Arun Kamble Cc: Michal Wajdeczko Reviewed-by: Sagar Arun Kamble (v1) --- drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/intel_uc.c| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 430f5f9d0ff4..c96360398072 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -48,7 +48,7 @@ struct drm_printer; param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ param(int, enable_guc, 0) \ - param(int, guc_log_level, 0) \ + param(int, guc_log_level, -1) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ param(int, mmio_debug, 0) \ diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 3fb5f75aa7c9..2f579fff58cd 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -69,7 +69,7 @@ static int __get_platform_enable_guc(struct drm_i915_private *dev_priv) static int __get_default_guc_log_level(struct drm_i915_private *dev_priv) { - int guc_log_level = 0; /* disabled */ + int guc_log_level = 1; /* non-verbose */ /* Enable if we're running on platform with GuC and debug config */ if (HAS_GUC(dev_priv) && intel_uc_is_using_guc() && -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/15] HAX enable guc for CI
--- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index c96360398072..53037b5eff22 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, -1) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 12/15] drm/i915/guc: Don't print out relay statistics when relay is disabled
If nobody has enabled the relay, we're not comunicating with GuC, which means that the stats don't have any meaning. Let's also remove interrupt counter and tidy the debugfs formatting. v2: Correct stats accounting (Sagar) Signed-off-by: Michał Winiarski Cc: Chris Wilson Cc: Daniele Ceraolo Spurio Cc: Sagar Arun Kamble Cc: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_debugfs.c | 45 drivers/gpu/drm/i915/intel_guc.c | 5 +--- drivers/gpu/drm/i915/intel_guc_log.c | 22 +- drivers/gpu/drm/i915/intel_guc_log.h | 10 4 files changed, 48 insertions(+), 34 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index d29bacb1f308..94516ab4eaed 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -2326,30 +2326,45 @@ static int i915_guc_load_status_info(struct seq_file *m, void *data) return 0; } +static const char * +stringify_guc_log_type(enum guc_log_buffer_type type) +{ + switch (type) { + case GUC_ISR_LOG_BUFFER: + return "ISR"; + case GUC_DPC_LOG_BUFFER: + return "DPC"; + case GUC_CRASH_DUMP_LOG_BUFFER: + return "CRASH"; + default: + MISSING_CASE(type); + } + + return ""; +} + static void i915_guc_log_info(struct seq_file *m, struct drm_i915_private *dev_priv) { struct intel_guc *guc = &dev_priv->guc; + enum guc_log_buffer_type type; - seq_puts(m, "GuC logging stats:\n"); - - seq_printf(m, "\tISR: flush count %10u, overflow count %10u\n", - guc->log.flush_count[GUC_ISR_LOG_BUFFER], - guc->log.total_overflow_count[GUC_ISR_LOG_BUFFER]); - - seq_printf(m, "\tDPC: flush count %10u, overflow count %10u\n", - guc->log.flush_count[GUC_DPC_LOG_BUFFER], - guc->log.total_overflow_count[GUC_DPC_LOG_BUFFER]); - - seq_printf(m, "\tCRASH: flush count %10u, overflow count %10u\n", - guc->log.flush_count[GUC_CRASH_DUMP_LOG_BUFFER], - guc->log.total_overflow_count[GUC_CRASH_DUMP_LOG_BUFFER]); + if (!intel_guc_log_relay_enabled(guc)) { + seq_puts(m, "GuC log relay disabled\n"); + return; + } - seq_printf(m, "\tTotal flush interrupt count: %u\n", - guc->log.flush_interrupt_count); + seq_puts(m, "GuC logging stats:\n"); seq_printf(m, "\tRelay full count: %u\n", guc->log.relay.full_count); + + for (type = GUC_ISR_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) { + seq_printf(m, "\t%s:\tflush count %10u, overflow count %10u\n", + stringify_guc_log_type(type), + guc->log.stats[type].flush, + guc->log.stats[type].overflow); + } } static void i915_guc_client_info(struct seq_file *m, diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index cab158e42577..3e2f0f8503ed 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -388,12 +388,9 @@ void intel_guc_to_host_event_handler(struct intel_guc *guc) spin_unlock(&guc->irq_lock); if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER | - INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED)) { + INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED)) queue_work(guc->log.relay.flush_wq, &guc->log.relay.flush_work); - - guc->log.flush_interrupt_count++; - } } int intel_guc_sample_forcewake(struct intel_guc *guc) diff --git a/drivers/gpu/drm/i915/intel_guc_log.c b/drivers/gpu/drm/i915/intel_guc_log.c index 7c4339dae534..a72fe4a369f4 100644 --- a/drivers/gpu/drm/i915/intel_guc_log.c +++ b/drivers/gpu/drm/i915/intel_guc_log.c @@ -171,22 +171,22 @@ static void *guc_get_write_buffer(struct intel_guc *guc) return relay_reserve(guc->log.relay.channel, 0); } -static bool guc_check_log_buf_overflow(struct intel_guc *guc, +static bool guc_check_log_buf_overflow(struct intel_guc_log *log, enum guc_log_buffer_type type, unsigned int full_cnt) { - unsigned int prev_full_cnt = guc->log.prev_overflow_count[type]; + unsigned int prev_full_cnt = log->stats[type].sampled_overflow; bool overflow = false; if (full_cnt != prev_full_cnt) { overflow = true; - guc->log.prev_overflow_count[type] = full_cnt; - guc->log.total_overflow_count[type] += full_cnt - prev_full_cnt; + log->stats[type].overflow = full_cnt; + log->stats[type].sampled_overflow += full_cnt - prev_full_cnt; if (full_cnt < prev_full_cnt) {
[Intel-gfx] [PATCH 11/15] drm/i915/guc: Always print log stats in i915_guc_info when using GuC
While some of the content in this file is related to GuC submission only, that's not the case with log related statistics. Signed-off-by: Michał Winiarski Cc: Chris Wilson Cc: Daniele Ceraolo Spurio Cc: Sagar Arun Kamble Cc: Michal Wajdeczko Reviewed-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/i915_debugfs.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index d7c0bf6facf6..d29bacb1f308 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -2331,7 +2331,7 @@ static void i915_guc_log_info(struct seq_file *m, { struct intel_guc *guc = &dev_priv->guc; - seq_puts(m, "\nGuC logging stats:\n"); + seq_puts(m, "GuC logging stats:\n"); seq_printf(m, "\tISR: flush count %10u, overflow count %10u\n", guc->log.flush_count[GUC_ISR_LOG_BUFFER], @@ -2379,14 +2379,19 @@ static int i915_guc_info(struct seq_file *m, void *data) struct drm_i915_private *dev_priv = node_to_i915(m->private); const struct intel_guc *guc = &dev_priv->guc; - if (!USES_GUC_SUBMISSION(dev_priv)) + if (!USES_GUC(dev_priv)) return -ENODEV; + i915_guc_log_info(m, dev_priv); + + if (!USES_GUC_SUBMISSION(dev_priv)) + return 0; + GEM_BUG_ON(!guc->execbuf_client); - seq_printf(m, "Doorbell map:\n"); + seq_printf(m, "\nDoorbell map:\n"); seq_printf(m, "\t%*pb\n", GUC_NUM_DOORBELLS, guc->doorbell_bitmap); - seq_printf(m, "Doorbell next cacheline: 0x%x\n\n", guc->db_cacheline); + seq_printf(m, "Doorbell next cacheline: 0x%x\n", guc->db_cacheline); seq_printf(m, "\nGuC execbuf client @ %p:\n", guc->execbuf_client); i915_guc_client_info(m, dev_priv, guc->execbuf_client); @@ -2396,8 +2401,6 @@ static int i915_guc_info(struct seq_file *m, void *data) i915_guc_client_info(m, dev_priv, guc->preempt_client); } - i915_guc_log_info(m, dev_priv); - /* Add more as required ... */ return 0; -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 10/15] drm/i915/guc: Get rid of GuC log runtime
Runtime is not a very good name. Let's also move counting relay overflows inside relay struct. v2: Rename things rather than remove the struct (Chris) Signed-off-by: Michał Winiarski Cc: Chris Wilson Cc: Daniele Ceraolo Spurio Cc: Sagar Arun Kamble Cc: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_debugfs.c | 4 +-- drivers/gpu/drm/i915/intel_guc.c | 12 +++ drivers/gpu/drm/i915/intel_guc_log.c | 66 ++-- drivers/gpu/drm/i915/intel_guc_log.h | 7 ++-- 4 files changed, 44 insertions(+), 45 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index f99fe9910634..d7c0bf6facf6 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -2348,8 +2348,8 @@ static void i915_guc_log_info(struct seq_file *m, seq_printf(m, "\tTotal flush interrupt count: %u\n", guc->log.flush_interrupt_count); - seq_printf(m, "\tCapture miss count: %u\n", - guc->log.capture_miss_count); + seq_printf(m, "\tRelay full count: %u\n", + guc->log.relay.full_count); } static void i915_guc_client_info(struct seq_file *m, diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index 0d92caf6a83f..cab158e42577 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -87,9 +87,9 @@ int intel_guc_init_wq(struct intel_guc *guc) * or scheduled later on resume. This way the handling of work * item can be kept same between system suspend & rpm suspend. */ - guc->log.runtime.flush_wq = alloc_ordered_workqueue("i915-guc_log", + guc->log.relay.flush_wq = alloc_ordered_workqueue("i915-guc_log", WQ_HIGHPRI | WQ_FREEZABLE); - if (!guc->log.runtime.flush_wq) { + if (!guc->log.relay.flush_wq) { DRM_ERROR("Couldn't allocate workqueue for GuC log\n"); return -ENOMEM; } @@ -112,7 +112,7 @@ int intel_guc_init_wq(struct intel_guc *guc) guc->preempt_wq = alloc_ordered_workqueue("i915-guc_preempt", WQ_HIGHPRI); if (!guc->preempt_wq) { - destroy_workqueue(guc->log.runtime.flush_wq); + destroy_workqueue(guc->log.relay.flush_wq); DRM_ERROR("Couldn't allocate workqueue for GuC " "preemption\n"); return -ENOMEM; @@ -130,7 +130,7 @@ void intel_guc_fini_wq(struct intel_guc *guc) USES_GUC_SUBMISSION(dev_priv)) destroy_workqueue(guc->preempt_wq); - destroy_workqueue(guc->log.runtime.flush_wq); + destroy_workqueue(guc->log.relay.flush_wq); } static int guc_shared_data_create(struct intel_guc *guc) @@ -389,8 +389,8 @@ void intel_guc_to_host_event_handler(struct intel_guc *guc) if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER | INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED)) { - queue_work(guc->log.runtime.flush_wq, - &guc->log.runtime.flush_work); + queue_work(guc->log.relay.flush_wq, + &guc->log.relay.flush_work); guc->log.flush_interrupt_count++; } diff --git a/drivers/gpu/drm/i915/intel_guc_log.c b/drivers/gpu/drm/i915/intel_guc_log.c index 92a7bf0fd729..7c4339dae534 100644 --- a/drivers/gpu/drm/i915/intel_guc_log.c +++ b/drivers/gpu/drm/i915/intel_guc_log.c @@ -151,10 +151,10 @@ static void guc_move_to_next_buf(struct intel_guc *guc) smp_wmb(); /* All data has been written, so now move the offset of sub buffer. */ - relay_reserve(guc->log.runtime.relay_chan, guc->log.vma->obj->base.size); + relay_reserve(guc->log.relay.channel, guc->log.vma->obj->base.size); /* Switch to the next sub buffer */ - relay_flush(guc->log.runtime.relay_chan); + relay_flush(guc->log.relay.channel); } static void *guc_get_write_buffer(struct intel_guc *guc) @@ -168,7 +168,7 @@ static void *guc_get_write_buffer(struct intel_guc *guc) * done without using relay_reserve() along with relay_write(). So its * better to use relay_reserve() alone. */ - return relay_reserve(guc->log.runtime.relay_chan, 0); + return relay_reserve(guc->log.relay.channel, 0); } static bool guc_check_log_buf_overflow(struct intel_guc *guc, @@ -219,13 +219,13 @@ static void guc_read_update_log_buffer(struct intel_guc *guc) void *src_data, *dst_data; bool new_overflow; - mutex_lock(&guc->log.runtime.lock); + mutex_lock(&guc->log.relay.lock); - if (WARN_ON(!guc->log.runtime.buf_addr)) + if (WARN_ON(!guc->log.relay.buf_addr)) goto out_unlock; /* Get the pointer to shared GuC log bu
[Intel-gfx] [PATCH v2 07/15] drm/i915/guc: Flush directly in log unregister
Having both guc_flush_logs and guc_log_flush functions is confusing. While we could just rename things, guc_flush_logs implementation is quite simple. Let's get rid of it and move its content to unregister. v2: s/dev_priv/i915 (Sagar) Signed-off-by: Michał Winiarski Cc: Chris Wilson Cc: Daniele Ceraolo Spurio Cc: Sagar Arun Kamble Cc: Michal Wajdeczko --- drivers/gpu/drm/i915/intel_guc_log.c | 34 ++ 1 file changed, 14 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc_log.c b/drivers/gpu/drm/i915/intel_guc_log.c index ee0981f5a208..5ff4b510569a 100644 --- a/drivers/gpu/drm/i915/intel_guc_log.c +++ b/drivers/gpu/drm/i915/intel_guc_log.c @@ -443,25 +443,6 @@ static void guc_log_capture_logs(struct intel_guc *guc) intel_runtime_pm_put(dev_priv); } -static void guc_flush_logs(struct intel_guc *guc) -{ - struct drm_i915_private *dev_priv = guc_to_i915(guc); - - /* -* Before initiating the forceful flush, wait for any pending/ongoing -* flush to complete otherwise forceful flush may not actually happen. -*/ - flush_work(&guc->log.runtime.flush_work); - - /* Ask GuC to update the log buffer state */ - intel_runtime_pm_get(dev_priv); - guc_log_flush(guc); - intel_runtime_pm_put(dev_priv); - - /* GuC would have updated log buffer by now, so capture it */ - guc_log_capture_logs(guc); -} - int intel_guc_log_create(struct intel_guc *guc) { struct i915_vma *vma; @@ -630,15 +611,28 @@ int intel_guc_log_register(struct intel_guc *guc) void intel_guc_log_unregister(struct intel_guc *guc) { + struct drm_i915_private *i915 = guc_to_i915(guc); + guc_log_flush_irq_disable(guc); + /* +* Before initiating the forceful flush, wait for any pending/ongoing +* flush to complete otherwise forceful flush may not actually happen. +*/ + flush_work(&guc->log.runtime.flush_work); + /* * Once logging is disabled, GuC won't generate logs & send an * interrupt. But there could be some data in the log buffer * which is yet to be captured. So request GuC to update the log * buffer state and then collect the left over logs. */ - guc_flush_logs(guc); + intel_runtime_pm_get(i915); + guc_log_flush(guc); + intel_runtime_pm_put(i915); + + /* GuC would have updated log buffer by now, so capture it */ + guc_log_capture_logs(guc); mutex_lock(&guc->log.runtime.lock); -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 08/15] drm/i915/guc: Split relay control and GuC log level
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 --- drivers/gpu/drm/i915/i915_debugfs.c | 56 ++ drivers/gpu/drm/i915/i915_drv.c | 4 -- drivers/gpu/drm/i915/intel_guc_log.c | 77 +++- drivers/gpu/drm/i915/intel_guc_log.h | 9 +++-- drivers/gpu/drm/i915/intel_uc.c | 22 --- drivers/gpu/drm/i915/intel_uc.h | 2 - 6 files changed, 85 insertions(+), 85 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index fa0755fe10d0..f99fe9910634 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -2496,32 +2496,73 @@ static int i915_guc_log_dump(struct seq_file *m, void *data) return 0; } -static int i915_guc_log_control_get(void *data, u64 *val) +static int i915_guc_log_level_get(void *data, u64 *val) { struct drm_i915_private *dev_priv = data; if (!USES_GUC(dev_priv)) return -ENODEV; - *val = intel_guc_log_control_get(&dev_priv->guc); + *val = intel_guc_log_level_get(&dev_priv->guc); return 0; } -static int i915_guc_log_control_set(void *data, u64 val) +static int i915_guc_log_level_set(void *data, u64 val) { struct drm_i915_private *dev_priv = data; if (!USES_GUC(dev_priv)) return -ENODEV; - return intel_guc_log_control_set(&dev_priv->guc, val); + return intel_guc_log_level_set(&dev_priv->guc, val); } -DEFINE_SIMPLE_ATTRIBUTE(i915_guc_log_control_fops, - i915_guc_log_control_get, i915_guc_log_control_set, +DEFINE_SIMPLE_ATTRIBUTE(i915_guc_log_level_fops, + i915_guc_log_level_get, i915_guc_log_level_set, "%lld\n"); +static int i915_guc_log_relay_open(struct inode *inode, struct file *file) +{ + struct drm_i915_private *dev_priv = inode->i_private; + + if (!USES_GUC(dev_priv)) + return -ENODEV; + + file->private_data = &dev_priv->guc; + + return intel_guc_log_relay_open(&dev_priv->guc); +} + +static ssize_t +i915_guc_log_relay_write(struct file *filp, +const char __user *ubuf, +size_t cnt, +loff_t *ppos) +{ + struct intel_guc *guc = filp->private_data; + + intel_guc_log_relay_flush(guc); + + return cnt; +} + +static int i915_guc_log_relay_release(struct inode *inode, struct file *file) +{ + struct drm_i915_private *dev_priv = inode->i_private; + + intel_guc_log_relay_close(&dev_priv->guc); + + return 0; +} + +static const struct file_operations i915_guc_log_relay_fops = { + .owner = THIS_MODULE, + .open = i915_guc_log_relay_open, + .write = i915_guc_log_relay_write, + .release = i915_guc_log_relay_release, +}; + static const char *psr2_live_status(u32 val) { static const char * const live_status[] = { @@ -4776,7 +4817,8 @@ static const struct i915_debugfs_files { {"i915_dp_test_data", &i915_displayport_test_data_fops}, {"i915_dp_test_type", &i915_displayport_test_type_fops}, {"i915_dp_test_active", &i915_displayport_test_active_fops}, - {"i915_guc_log_control", &i915_guc_log_control_fops}, + {"i915_guc_log_level", &i915_guc_log_level_fops}, + {"i915_guc_log_relay", &i915_guc_log_relay_fops}, {"i915_hpd_storm_ctl", &i915_hpd_storm_ctl_fops}, {"i915_ipc_status", &i915_ipc_status_fops}, {"i915_drrs_ctl", &i915_drrs_ctl_fops} diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 987c6770d1a6..0a238e3ed5b6 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1240,9 +1240,6 @@ static void i915_driver_register(struct drm_i915_private *dev_priv) i915_debugfs_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 @@ -1300,7 +1297,6 @@ static void i915_driver_unregister(struct drm_i915_private *dev_priv) i915_pmu_unregister(