Re: [Intel-gfx] [PATCH 3/5] drm/vblank: Do not update vblank count if interrupts are already disabled.
On Fri, Jan 12, 2018 at 09:57:05PM +, Dhinakaran Pandiyan wrote: > Updating vblank counts requires register reads and these reads may not > return meaningful values if the device was in a low power state after > vblank interrupts were last disabled. So, update the count only if vblank > interrupts are enabled. Secondly, this means the registers should be read > before disabling vblank interrupts. > > v2: Don't check vblank->enabled outside it's lock (Chris) > > Cc: Chris Wilson > Cc: Daniel Vetter > Cc: Michel Dänzer > Signed-off-by: Dhinakaran Pandiyan > --- > drivers/gpu/drm/drm_vblank.c | 18 ++ > 1 file changed, 10 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > index f2bf1f5dbaa5..2559d2d7b907 100644 > --- a/drivers/gpu/drm/drm_vblank.c > +++ b/drivers/gpu/drm/drm_vblank.c > @@ -347,23 +347,25 @@ void drm_vblank_disable_and_save(struct drm_device > *dev, unsigned int pipe) > spin_lock_irqsave(&dev->vblank_time_lock, irqflags); > > /* > - * Only disable vblank interrupts if they're enabled. This avoids > - * calling the ->disable_vblank() operation in atomic context with the > - * hardware potentially runtime suspended. > + * Update vblank count and disable vblank interrupts only if the > + * interrupts were enabled. This avoids calling the ->disable_vblank() > + * operation in atomic context with the hardware potentially runtime > + * suspended. >*/ > - if (vblank->enabled) { > - __disable_vblank(dev, pipe); > - vblank->enabled = false; > - } > + if (!vblank->enabled) > + goto out; > > /* > - * Always update the count and timestamp to maintain the > + * Update the count and timestamp to maintain the >* appearance that the counter has been ticking all along until >* this time. This makes the count account for the entire time >* between drm_crtc_vblank_on() and drm_crtc_vblank_off(). >*/ I feel that this entire comment can be simply removed now... The approach looks good and right to me so you can use Reviewed-by: Rodrigo Vivi but please ping Ville to take a look here since he introduced this approach with 4dfd64862ff8 ("drm: Use vblank timestamps to guesstimate how many vblanks were missed") > drm_update_vblank_count(dev, pipe, false); > + __disable_vblank(dev, pipe); > + vblank->enabled = false; > > +out: > spin_unlock_irqrestore(&dev->vblank_time_lock, irqflags); > } > > -- > 2.11.0 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/vblank: Fix data type width for drm_crtc_arm_vblank_event()
On Fri, Jan 12, 2018 at 09:57:04PM +, Dhinakaran Pandiyan wrote: > Now that drm_vblank_count() returns all bits of the vblank count, update > drm_crtc_arm_vblank_event() so that it queues the correct sequence. > Otherwise, this leads to prolonged waits for a vblank sequence when the > current count is >=2^32. This could be probably squashed to the previous patch... Specially if you apply the Fixes tag. Anyways, in case you decide to go with 2 patches: Reviewed-by: Rodrigo Vivi > > Cc: Keith Packard > Cc: Michel Dänzer > Cc: Daniel Vetter > Signed-off-by: Dhinakaran Pandiyan > --- > drivers/gpu/drm/drm_vblank.c | 4 ++-- > include/drm/drm_vblank.h | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > index 768a8e44d99b..f2bf1f5dbaa5 100644 > --- a/drivers/gpu/drm/drm_vblank.c > +++ b/drivers/gpu/drm/drm_vblank.c > @@ -292,11 +292,11 @@ static u64 drm_vblank_count(struct drm_device *dev, > unsigned int pipe) > * This is mostly useful for hardware that can obtain the scanout position, > but > * doesn't have a hardware frame counter. > */ > -u32 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc) > +u64 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc) > { > struct drm_device *dev = crtc->dev; > unsigned int pipe = drm_crtc_index(crtc); > - u32 vblank; > + u64 vblank; > unsigned long flags; > > WARN_ONCE(drm_debug & DRM_UT_VBL && !dev->driver->get_vblank_timestamp, > diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h > index 848b463a0af5..a4c3b0a0a197 100644 > --- a/include/drm/drm_vblank.h > +++ b/include/drm/drm_vblank.h > @@ -179,7 +179,7 @@ void drm_crtc_wait_one_vblank(struct drm_crtc *crtc); > void drm_crtc_vblank_off(struct drm_crtc *crtc); > void drm_crtc_vblank_reset(struct drm_crtc *crtc); > void drm_crtc_vblank_on(struct drm_crtc *crtc); > -u32 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc); > +u64 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc); > > bool drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev, > unsigned int pipe, int *max_error, > -- > 2.11.0 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/vblank: Fix return type for drm_vblank_count()
On Fri, Jan 12, 2018 at 09:57:03PM +, Dhinakaran Pandiyan wrote: > drm_vblank_count() has a u32 type returning what is a 64-bit vblank count. > The effect of this is when drm_wait_vblank_ioctl() tries to widen the user > space requested vblank sequence using this clipped 32-bit count(when the > value is >= 2^32) as reference, the requested sequence remains a 32-bit > value and gets queued like that. However, the code that checks if the > requested sequence has passed compares this against the 64-bit vblank > count. Worth to mention and probably Fixes: 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") btw, I spotted at least one more place even with the series applied. 32 current_vblank; at drm_mode_page_flip_ioctl... so, probably worth to do a deeper check down to all paths... anayway, for this patch: Reviewed-by: Rodrigo Vivi > > Cc: Keith Packard > Cc: Michel Dänzer > Cc: Daniel Vetter > Signed-off-by: Dhinakaran Pandiyan > --- > drivers/gpu/drm/drm_vblank.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > index 32d9bcf5be7f..768a8e44d99b 100644 > --- a/drivers/gpu/drm/drm_vblank.c > +++ b/drivers/gpu/drm/drm_vblank.c > @@ -271,7 +271,7 @@ static void drm_update_vblank_count(struct drm_device > *dev, unsigned int pipe, > store_vblank(dev, pipe, diff, t_vblank, cur_vblank); > } > > -static u32 drm_vblank_count(struct drm_device *dev, unsigned int pipe) > +static u64 drm_vblank_count(struct drm_device *dev, unsigned int pipe) > { > struct drm_vblank_crtc *vblank = &dev->vblank[pipe]; > > -- > 2.11.0 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Estimate and update missed vblanks.
On Fri, Jan 12, 2018 at 09:57:07PM +, Dhinakaran Pandiyan wrote: > The frame counter may have got reset between disabling and enabling vblank > interrupts due to DMC putting the hardware to DC5/6 state if PSR was > active. The frame counter also could have stalled if PSR is active in cases > where there is no DMC. The frame counter resetting as a user visible impact > of screen freezes. Use drm_vblank_restore() to compute missed vblanks > in the duration for which vblank interrupts are disabled. There's no need > particularly check if PSR was active in the interrupt disabled duration. > > Enabling vblank interrupts wakes up the hardware from DC5/6 and prevents it > from going back again as long as the there are pending interrupts. So, we > don't have to explicity disallow DC5/6 after enabling vblank interrupts > to keep the counter running. > > Let's not apply this to CHV for now, as enabling interrupts does not > prevent the hardware from activating PSR and thereby stalling the counter. > > Cc: Rodrigo Vivi > Signed-off-by: Dhinakaran Pandiyan > --- > drivers/gpu/drm/i915/i915_irq.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c > index 3517c6548e2c..db3466ec6faa 100644 > --- a/drivers/gpu/drm/i915/i915_irq.c > +++ b/drivers/gpu/drm/i915/i915_irq.c > @@ -2956,6 +2956,9 @@ static int ironlake_enable_vblank(struct drm_device > *dev, unsigned int pipe) > ilk_enable_display_irq(dev_priv, bit); > spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags); > > + if (HAS_PSR(dev_priv)) > + drm_vblank_restore(dev, pipe); > + I don't believe we need this one here. pre-gen9 platform has psr but not dmc, so the case where we need to restore the counter doesn't exist. > return 0; > } > > @@ -2968,6 +2971,9 @@ static int gen8_enable_vblank(struct drm_device *dev, > unsigned int pipe) > bdw_enable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK); > spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags); > > + if (HAS_PSR(dev_priv)) HAS_PSR(dev_priv) && HAS_CSR(dev_priv) maybe? So it gets clear that it is not because PSR that we need to restore the counter, but also don't do it when not needed. > + drm_vblank_restore(dev, pipe); > + > return 0; > } > > -- > 2.11.0 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v7,1/6] drm/i915/guc: Move GuC WOPCM related code into separate files
== Series Details == Series: series starting with [v7,1/6] drm/i915/guc: Move GuC WOPCM related code into separate files URL : https://patchwork.freedesktop.org/series/36748/ State : failure == Summary == Series 36748v1 series starting with [v7,1/6] drm/i915/guc: Move GuC WOPCM related code into separate files https://patchwork.freedesktop.org/api/1.0/series/36748/revisions/1/mbox/ Test core_auth: Subgroup basic-auth: pass -> SKIP (fi-skl-gvtdvm) Test core_prop_blob: Subgroup basic: pass -> SKIP (fi-skl-gvtdvm) Test debugfs_test: Subgroup read_all_entries: dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989 incomplete -> PASS (fi-snb-2520m) fdo#103713 pass -> DMESG-WARN (fi-skl-6260u) pass -> DMESG-WARN (fi-skl-6600u) pass -> DMESG-WARN (fi-skl-6700hq) pass -> DMESG-WARN (fi-skl-6700k2) pass -> DMESG-WARN (fi-skl-6770hq) pass -> SKIP (fi-skl-gvtdvm) pass -> DMESG-WARN (fi-bxt-dsi) pass -> DMESG-WARN (fi-bxt-j4205) pass -> DMESG-WARN (fi-kbl-7500u) pass -> DMESG-WARN (fi-kbl-7560u) pass -> DMESG-WARN (fi-kbl-7567u) pass -> DMESG-WARN (fi-kbl-r) Test drv_getparams_basic: Subgroup basic-eu-total: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-subslice-total: pass -> SKIP (fi-skl-gvtdvm) Test drv_hangman: Subgroup error-state-basic: pass -> SKIP (fi-skl-gvtdvm) Test gem_basic: Subgroup bad-close: pass -> SKIP (fi-skl-gvtdvm) Subgroup create-close: pass -> SKIP (fi-skl-gvtdvm) Subgroup create-fd-close: pass -> SKIP (fi-skl-gvtdvm) Test gem_busy: Subgroup basic-busy-default: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-hang-default: pass -> SKIP (fi-skl-gvtdvm) fdo#104108 +6 Test gem_close_race: Subgroup basic-process: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-threads: pass -> DMESG-WARN (fi-skl-6260u) pass -> DMESG-WARN (fi-skl-6600u) pass -> DMESG-WARN (fi-skl-6700hq) pass -> DMESG-WARN (fi-skl-6700k2) pass -> DMESG-WARN (fi-skl-6770hq) pass -> SKIP (fi-skl-gvtdvm) pass -> DMESG-WARN (fi-bxt-dsi) pass -> DMESG-WARN (fi-bxt-j4205) pass -> DMESG-WARN (fi-kbl-7500u) pass -> DMESG-WARN (fi-kbl-7560u) pass -> DMESG-WARN (fi-kbl-7567u) pass -> DMESG-WARN (fi-kbl-r) Test gem_cpu_reloc: Subgroup basic: pass -> SKIP (fi-skl-gvtdvm) Test gem_cs_tlb: Subgroup basic-default: pass -> DMESG-WARN (fi-skl-6600u) pass -> DMESG-WARN (fi-skl-6700hq) pass -> SKIP (fi-skl-gvtdvm) pass -> DMESG-WARN (fi-bxt-dsi) pass -> DMESG-WARN (fi-bxt-j4205) pass -> DMESG-WARN (fi-kbl-7567u) Test gem_ctx_create: Subgroup basic: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-files: pass -> DMESG-WARN (fi-skl-6260u) pass -> DMESG-WARN (fi-skl-6600u) pass -> DMESG-WARN (fi-skl-6700hq) pass -> DMESG-WARN (fi-skl-6700k2) pass -> DMESG-WARN (fi-skl-6770hq) pass -> SKIP (fi-skl-gvtdvm) pass -> DMESG-WARN (fi-bxt-dsi) pass -> DMESG-WARN (fi-bxt-j4205) pass -> DMESG-WARN (fi-kbl-7500u) pass -> DMESG-WARN (fi-kbl-7560u) pass -> DMESG-WARN (fi-kbl-7567u) pass -> DMESG-WARN (fi-kbl-r) Test gem_ctx_exec: Subgroup basic: pass -> SKIP (fi-skl-gvtdvm) Test gem_ctx_param: Subgroup basic: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-default: pass -> SKIP (fi-skl-gvtdvm) Test gem_ctx_switch: Subgroup basic-default: pass -> DMESG-WARN (fi-skl-6260u) pass -> DMESG-WARN (fi-skl-6600u) WARNING: Long output truncated d68aaa919e474b82f41514e5c3b87cb6dfe86f57 drm-tip: 2018y-01m-19d-05h-41m-44s UTC integration manifest 26a52553d057 HAX Enable GuC Submiss
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Nuke intel_dp->channel_eq_status
On Wed, Jan 17, 2018 at 07:21:48PM +, Ville Syrjala wrote: > From: Ville Syrjälä > > intel_dp->channel_eq_status is used in exactly one function, and we > don't need it to persist between calls. So just go back to using a > local variable instead. > > Signed-off-by: Ville Syrjälä Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_dp_link_training.c | 6 +++--- > drivers/gpu/drm/i915/intel_drv.h | 1 - > 2 files changed, 3 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c > b/drivers/gpu/drm/i915/intel_dp_link_training.c > index 05907fa8a553..1314f5d87d7d 100644 > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c > @@ -248,6 +248,7 @@ intel_dp_link_training_channel_equalization(struct > intel_dp *intel_dp) > int tries; > u32 training_pattern; > uint8_t link_status[DP_LINK_STATUS_SIZE]; > + bool channel_eq = false; > > training_pattern = intel_dp_training_pattern(intel_dp); > > @@ -259,7 +260,6 @@ intel_dp_link_training_channel_equalization(struct > intel_dp *intel_dp) > return false; > } > > - intel_dp->channel_eq_status = false; > for (tries = 0; tries < 5; tries++) { > > drm_dp_link_train_channel_eq_delay(intel_dp->dpcd); > @@ -279,7 +279,7 @@ intel_dp_link_training_channel_equalization(struct > intel_dp *intel_dp) > > if (drm_dp_channel_eq_ok(link_status, >intel_dp->lane_count)) { > - intel_dp->channel_eq_status = true; > + channel_eq = true; > DRM_DEBUG_KMS("Channel EQ done. DP Training " > "successful\n"); > break; > @@ -301,7 +301,7 @@ intel_dp_link_training_channel_equalization(struct > intel_dp *intel_dp) > > intel_dp_set_idle_link_train(intel_dp); > > - return intel_dp->channel_eq_status; > + return channel_eq; > > } > > diff --git a/drivers/gpu/drm/i915/intel_drv.h > b/drivers/gpu/drm/i915/intel_drv.h > index ddf28a442cd7..1d018869ad02 100644 > --- a/drivers/gpu/drm/i915/intel_drv.h > +++ b/drivers/gpu/drm/i915/intel_drv.h > @@ -1045,7 +1045,6 @@ struct intel_dp { > bool link_mst; > bool has_audio; > bool detect_done; > - bool channel_eq_status; > bool reset_link_params; > uint8_t dpcd[DP_RECEIVER_CAP_SIZE]; > uint8_t psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE]; > -- > 2.13.6 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Use the engine name directly in the error_state file (rev3)
== Series Details == Series: drm/i915: Use the engine name directly in the error_state file (rev3) URL : https://patchwork.freedesktop.org/series/36215/ State : warning == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-2p-scndscrn-pri-shrfb-draw-mmap-cpu: pass -> DMESG-WARN (shard-hsw) Subgroup fbc-1p-offscren-pri-shrfb-draw-render: skip -> FAIL (shard-snb) fdo#101623 +1 Test kms_flip: Subgroup vblank-vs-suspend: pass -> FAIL (shard-snb) fdo#102365 Subgroup vblank-vs-dpms-suspend: pass -> INCOMPLETE (shard-hsw) fdo#103540 Subgroup flip-vs-modeset-vs-hang: pass -> DMESG-WARN (shard-snb) fdo#103821 Test drv_suspend: Subgroup sysfs-reader: pass -> SKIP (shard-snb) Test kms_setmode: Subgroup invalid-clone-single-crtc-stealing: warn -> PASS (shard-snb) Test kms_chv_cursor_fail: Subgroup pipe-a-64x64-left-edge: skip -> PASS (shard-snb) fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821 shard-hswtotal:2685 pass:1686 dwarn:2 dfail:0 fail:10 skip:985 time:14788s shard-snbtotal:2753 pass:1315 dwarn:2 dfail:0 fail:12 skip:1424 time:7909s Blacklisted hosts: shard-apltotal:2731 pass:1692 dwarn:1 dfail:0 fail:22 skip:1015 time:13607s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7714/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: II stage HDCP auth for repeater only
> -Original Message- > From: Sean Paul [mailto:seanp...@chromium.org] > Sent: Friday, January 19, 2018 3:54 AM > To: C, Ramalingam > Cc: intel-gfx@lists.freedesktop.org; seanp...@chromium.org; > daniel.vet...@ffwll.ch; Vivi, Rodrigo ; Sharma, > Shashank > Subject: Re: [PATCH 2/4] drm/i915: II stage HDCP auth for repeater only > > On Thu, Jan 18, 2018 at 11:18:06AM +0530, Ramalingam C wrote: > > Second stage of HDCP authentication required only if the HDCP sink is > > a repeater. > > > > This patch imposes above condition on second stage HDCP authentication. > > Hi Ram, > This is already enforced in intel_hdcp_auth_downstream() I am not able to locate any check for repeater capability at start of downstream auth. I am not sure whether you are referring to number of downstream device count check. That is valid after poll for ksv_fifo ready. We don't want to wait for 5Sec timeout in poll to detect the repeater cap. And since the caller is handy with the flag for repeater cap, it is best to decide on the call for downstream auth itself. Thanks --Ram > > Thanks, > Sean > > > > > Signed-off-by: Ramalingam C > > --- > > drivers/gpu/drm/i915/intel_hdcp.c | 5 - > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_hdcp.c > > b/drivers/gpu/drm/i915/intel_hdcp.c > > index 6ce6559897a6..b48c72cd0906 100644 > > --- a/drivers/gpu/drm/i915/intel_hdcp.c > > +++ b/drivers/gpu/drm/i915/intel_hdcp.c > > @@ -493,7 +493,10 @@ static int intel_hdcp_auth(struct intel_digital_port > *intel_dig_port, > > * on those as well. > > */ > > > > - return intel_hdcp_auth_downstream(intel_dig_port, shim); > > + if (repeater_present) > > + return intel_hdcp_auth_downstream(intel_dig_port, shim); > > + > > + return 0; > > } > > > > static > > -- > > 2.7.4 > > > > -- > Sean Paul, Software Engineer, Google / Chromium OS ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4] HDCP1.4 implementation enhancement
On Wed, Jan 17, 2018 at 9:48 PM, Ramalingam C wrote: > This series extends the HDCP1.4 support for few more intel platforms. > And also addresses few gaps found in the base HDCP1.4 implementation w.r.t > HDCP1.4 specification. > Thanks for the patches, Ram. I've applied them with a couple of checkpatch fixes around alignment + an extra line. Sean > Ramalingam C (4): > drm/i915: Extending HDCP for HSW, BDW and BXT+ > drm/i915: II stage HDCP auth for repeater only > drm/i915: Start repeater auth on READY/CP_IRQ > drm/i915: Check for downstream topology errors > > drivers/gpu/drm/i915/i915_reg.h | 1 + > drivers/gpu/drm/i915/intel_dp.c | 2 +- > drivers/gpu/drm/i915/intel_drv.h | 1 + > drivers/gpu/drm/i915/intel_hdcp.c | 65 > ++- > drivers/gpu/drm/i915/intel_hdmi.c | 3 +- > include/drm/drm_hdcp.h| 2 ++ > 6 files changed, 57 insertions(+), 17 deletions(-) > > -- > 2.7.4 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 2/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset
GuC related exported functions should start with "intel_guc_" prefix and pass intel_guc as the first parameter since its guc related. Current guc_ggtt_offset() failed to follow this code convention. This patch renames the guc_ggtt_offset to intel_guc_ggtt_offset and updates the related code to pass intel_guc pointer to this function call. so that we have a unified coding style for GuC code. Cc: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Chris Wilson Cc: Joonas Lahtinen Signed-off-by: Jackie Li --- drivers/gpu/drm/i915/intel_guc.c| 12 +++- drivers/gpu/drm/i915/intel_guc.h| 10 -- drivers/gpu/drm/i915/intel_guc_ads.c| 25 + drivers/gpu/drm/i915/intel_guc_ct.c | 5 +++-- drivers/gpu/drm/i915/intel_guc_fw.c | 2 +- drivers/gpu/drm/i915/intel_guc_log.c| 2 +- drivers/gpu/drm/i915/intel_guc_submission.c | 10 +- drivers/gpu/drm/i915/intel_huc.c| 6 -- 8 files changed, 42 insertions(+), 30 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index b8b6d4a..e70885b 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -264,8 +264,10 @@ void intel_guc_init_params(struct intel_guc *guc) /* If GuC submission is enabled, set up additional parameters here */ if (USES_GUC_SUBMISSION(dev_priv)) { - u32 ads = guc_ggtt_offset(guc->ads_vma) >> PAGE_SHIFT; - u32 pgs = guc_ggtt_offset(dev_priv->guc.stage_desc_pool); + u32 ads = intel_guc_ggtt_offset(guc, + guc->ads_vma) >> PAGE_SHIFT; + u32 pgs = intel_guc_ggtt_offset(guc, + dev_priv->guc.stage_desc_pool); u32 ctx_in_16 = GUC_MAX_STAGE_DESCRIPTORS / 16; params[GUC_CTL_DEBUG] |= ads << GUC_ADS_ADDR_SHIFT; @@ -413,7 +415,7 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv) data[0] = INTEL_GUC_ACTION_ENTER_S_STATE; /* any value greater than GUC_POWER_D0 */ data[1] = GUC_POWER_D1; - data[2] = guc_ggtt_offset(guc->shared_data); + data[2] = intel_guc_ggtt_offset(guc, guc->shared_data); return intel_guc_send(guc, data, ARRAY_SIZE(data)); } @@ -436,7 +438,7 @@ int intel_guc_reset_engine(struct intel_guc *guc, data[3] = 0; data[4] = 0; data[5] = guc->execbuf_client->stage_id; - data[6] = guc_ggtt_offset(guc->shared_data); + data[6] = intel_guc_ggtt_offset(guc, guc->shared_data); return intel_guc_send(guc, data, ARRAY_SIZE(data)); } @@ -458,7 +460,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv) data[0] = INTEL_GUC_ACTION_EXIT_S_STATE; data[1] = GUC_POWER_D0; - data[2] = guc_ggtt_offset(guc->shared_data); + data[2] = intel_guc_ggtt_offset(guc, guc->shared_data); return intel_guc_send(guc, data, ARRAY_SIZE(data)); } diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h index 9e0a97e..b7e2a18 100644 --- a/drivers/gpu/drm/i915/intel_guc.h +++ b/drivers/gpu/drm/i915/intel_guc.h @@ -101,13 +101,19 @@ static inline void intel_guc_notify(struct intel_guc *guc) guc->notify(guc); } -/* +/* intel_guc_ggtt_offset() - Get the GGTT offset of @vma. + * @guc: intel guc. + * @vma: i915 graphics virtual memory area. + * * GuC does not allow any gfx GGTT address that falls into range [0, WOPCM_TOP), * which is reserved for Boot ROM, SRAM and WOPCM. Currently this top address is * 512K. In order to exclude 0-512K address space from GGTT, all gfx objects * used by GuC is pinned with PIN_OFFSET_BIAS along with size of WOPCM. + * + * Return: GGTT offset that meets the GuC gfx address requirement. */ -static inline u32 guc_ggtt_offset(struct i915_vma *vma) +static inline u32 intel_guc_ggtt_offset(struct intel_guc *guc, + struct i915_vma *vma) { u32 offset = i915_ggtt_offset(vma); diff --git a/drivers/gpu/drm/i915/intel_guc_ads.c b/drivers/gpu/drm/i915/intel_guc_ads.c index ac62753..7215594 100644 --- a/drivers/gpu/drm/i915/intel_guc_ads.c +++ b/drivers/gpu/drm/i915/intel_guc_ads.c @@ -113,17 +113,6 @@ int intel_guc_ads_create(struct intel_guc *guc) blob->reg_state.white_list[engine->guc_id].count = 0; } - /* -* The GuC requires a "Golden Context" when it reinitialises -* engines after a reset. Here we use the Render ring default -* context, which must already exist and be pinned in the GGTT, -* so its address won't change after we've told the GuC where -* to find it. Note that we have to skip our header (1 page), -* because our GuC shared data is there. -*/ - blob->ads.golden_context_lrca = - guc_ggtt_offset(dev_priv->kernel_context->engine[RCS].stat
[Intel-gfx] [PATCH v7 1/6] drm/i915/guc: Move GuC WOPCM related code into separate files
intel_guc_reg.h should only include definition for GuC registers and related register bits. GuC WOPCM related values should not be defined in intel_guc_reg.h This patch creates a better file structure by moving GuC WOPCM related definitions int to a new header intel_guc_wopcm.h and moving GuC WOPCM related functions to a new source file intel_guc_wopcm.c Cc: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Chris Wilson Cc: Joonas Lahtinen Signed-off-by: Jackie Li --- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/intel_guc.c | 11 drivers/gpu/drm/i915/intel_guc.h | 2 +- drivers/gpu/drm/i915/intel_guc_reg.h | 4 --- drivers/gpu/drm/i915/intel_guc_wopcm.c | 47 ++ drivers/gpu/drm/i915/intel_guc_wopcm.h | 39 drivers/gpu/drm/i915/intel_uc.c| 2 +- drivers/gpu/drm/i915/intel_uc_fw.c | 2 +- 8 files changed, 90 insertions(+), 18 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_guc_wopcm.c create mode 100644 drivers/gpu/drm/i915/intel_guc_wopcm.h diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 3bddd8a..1dc9988 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -88,6 +88,7 @@ i915-y += intel_uc.o \ intel_guc_fw.o \ intel_guc_log.o \ intel_guc_submission.o \ + intel_guc_wopcm.o \ intel_huc.o # autogenerated null render state diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index ea30e7c..b8b6d4a 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -504,14 +504,3 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size) i915_gem_object_put(obj); return vma; } - -u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv) -{ - u32 wopcm_size = GUC_WOPCM_TOP; - - /* On BXT, the top of WOPCM is reserved for RC6 context */ - if (IS_GEN9_LP(dev_priv)) - wopcm_size -= BXT_GUC_WOPCM_RC6_RESERVED; - - return wopcm_size; -} diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h index 52856a9..9e0a97e 100644 --- a/drivers/gpu/drm/i915/intel_guc.h +++ b/drivers/gpu/drm/i915/intel_guc.h @@ -31,6 +31,7 @@ #include "intel_guc_ct.h" #include "intel_guc_log.h" #include "intel_guc_reg.h" +#include "intel_guc_wopcm.h" #include "intel_uc_fw.h" #include "i915_vma.h" @@ -130,6 +131,5 @@ int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset); int intel_guc_suspend(struct drm_i915_private *dev_priv); int intel_guc_resume(struct drm_i915_private *dev_priv); struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size); -u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv); #endif diff --git a/drivers/gpu/drm/i915/intel_guc_reg.h b/drivers/gpu/drm/i915/intel_guc_reg.h index 19a9247..1f52fb8 100644 --- a/drivers/gpu/drm/i915/intel_guc_reg.h +++ b/drivers/gpu/drm/i915/intel_guc_reg.h @@ -68,7 +68,6 @@ #define DMA_GUC_WOPCM_OFFSET _MMIO(0xc340) #define HUC_LOADING_AGENT_VCR (0<<1) #define HUC_LOADING_AGENT_GUC (1<<1) -#define GUC_WOPCM_OFFSET_VALUE 0x8 /* 512KB */ #define GUC_MAX_IDLE_COUNT _MMIO(0xC3E4) #define HUC_STATUS2 _MMIO(0xD3B0) @@ -76,9 +75,6 @@ /* Defines WOPCM space available to GuC firmware */ #define GUC_WOPCM_SIZE _MMIO(0xc050) -/* GuC addresses below GUC_WOPCM_TOP don't map through the GTT */ -#define GUC_WOPCM_TOP (0x80 << 12) /* 512KB */ -#define BXT_GUC_WOPCM_RC6_RESERVED (0x10 << 12) /* 64KB */ /* GuC addresses above GUC_GGTT_TOP also don't map through the GTT */ #define GUC_GGTT_TOP 0xFEE0 diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c b/drivers/gpu/drm/i915/intel_guc_wopcm.c new file mode 100644 index 000..87643a0 --- /dev/null +++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c @@ -0,0 +1,47 @@ +/* + * Copyright © 2017 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHA
[Intel-gfx] [PATCH v7 4/6] drm/i915/guc: Add WOPCM partitioning support for CNL
CNL has different WOPCM size and hardware restriction on GuC WOPCM size. This patch returns the correct WOPCM reserved size on CNL and adds the GuC WOPCM size check for CNL. v6: - Extended HuC FW size check against GuC WOPCM size to all Gen9 and CNL A0 platforms v7: - Fixed patch format issues Cc: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: John Spotswood Cc: Jeff McGee Cc: Chris Wilson Cc: Joonas Lahtinen Signed-off-by: Jackie Li --- drivers/gpu/drm/i915/intel_guc_wopcm.c | 23 ++- drivers/gpu/drm/i915/intel_guc_wopcm.h | 4 2 files changed, 26 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c b/drivers/gpu/drm/i915/intel_guc_wopcm.c index 0532714..ed3096c 100644 --- a/drivers/gpu/drm/i915/intel_guc_wopcm.c +++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c @@ -33,6 +33,24 @@ static inline u32 guc_reserved_wopcm_size(struct intel_guc *guc) if (IS_GEN9_LP(i915)) return BXT_WOPCM_RC6_RESERVED; + if (IS_GEN10(i915)) + return CNL_WOPCM_RESERVED; + + return 0; +} + +/* + * On Gen9 & CNL A0, hardware requires GuC size to be larger than or equal to + * HuC kernel size. + */ +static inline int wopcm_huc_size_check(struct drm_i915_private *i915) +{ + struct intel_guc_wopcm *wopcm = &i915->guc.wopcm; + u32 huc_size = intel_uc_fw_get_size(&i915->huc.fw); + + if (unlikely(wopcm->size - GUC_WOPCM_RESERVED < huc_size)) + return -E2BIG; + return 0; } @@ -55,7 +73,7 @@ static inline int gen9_wocpm_size_check(struct drm_i915_private *i915) if (unlikely(delta < GEN9_GUC_WOPCM_DELTA)) return -E2BIG; - return 0; + return wopcm_huc_size_check(i915); } static inline int guc_wopcm_size_check(struct intel_guc *guc) @@ -65,6 +83,9 @@ static inline int guc_wopcm_size_check(struct intel_guc *guc) if (IS_GEN9(i915)) return gen9_wocpm_size_check(i915); + if (IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0)) + return wopcm_huc_size_check(i915); + return 0; } diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.h b/drivers/gpu/drm/i915/intel_guc_wopcm.h index 352cf3d..5306175 100644 --- a/drivers/gpu/drm/i915/intel_guc_wopcm.h +++ b/drivers/gpu/drm/i915/intel_guc_wopcm.h @@ -37,8 +37,12 @@ struct intel_guc; #define WOPCM_OFFSET_ALIGNMENT (0x4000) /* 8KB stack reserved for GuC FW*/ #define GUC_WOPCM_STACK_RESERVED (0x2000) +/* 16KB reserved at the beginning of GuC WOPCM */ +#define GUC_WOPCM_RESERVED (0x4000) /* 24KB WOPCM reserved for RC6 CTX on BXT */ #define BXT_WOPCM_RC6_RESERVED (0x6000) +/* 36KB WOPCM reserved on CNL */ +#define CNL_WOPCM_RESERVED (0x9000) #define GEN9_GUC_WOPCM_DELTA 4 #define GEN9_GUC_WOPCM_OFFSET (0x24000) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/vblank: Fix return type for drm_vblank_count()
ping for review. Let me know if there's anything that needs to be done, thanks! On Fri, 2018-01-12 at 13:57 -0800, Dhinakaran Pandiyan wrote: > drm_vblank_count() has a u32 type returning what is a 64-bit vblank count. > The effect of this is when drm_wait_vblank_ioctl() tries to widen the user > space requested vblank sequence using this clipped 32-bit count(when the > value is >= 2^32) as reference, the requested sequence remains a 32-bit > value and gets queued like that. However, the code that checks if the > requested sequence has passed compares this against the 64-bit vblank > count. > > Cc: Keith Packard > Cc: Michel Dänzer > Cc: Daniel Vetter > Signed-off-by: Dhinakaran Pandiyan > --- > drivers/gpu/drm/drm_vblank.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > index 32d9bcf5be7f..768a8e44d99b 100644 > --- a/drivers/gpu/drm/drm_vblank.c > +++ b/drivers/gpu/drm/drm_vblank.c > @@ -271,7 +271,7 @@ static void drm_update_vblank_count(struct drm_device > *dev, unsigned int pipe, > store_vblank(dev, pipe, diff, t_vblank, cur_vblank); > } > > -static u32 drm_vblank_count(struct drm_device *dev, unsigned int pipe) > +static u64 drm_vblank_count(struct drm_device *dev, unsigned int pipe) > { > struct drm_vblank_crtc *vblank = &dev->vblank[pipe]; > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 5/6] drm/i915/guc: Check the locking status of GuC WOPCM registers
GuC WOPCM registers are write-once registers. Current driver code accesses these registers without checking the accessibility to these registers, this will lead unpredictable driver behaviors if these registers were touch by other components (such as faulty BIOS code). This patch moves the GuC WOPCM register updating operations into intel_guc_wopcm.c and adds checks before and after the write to GuC WOPCM registers to make sure the driver is in a known state before and after writing to these write-once registers. v6: - Made sure module reloading won't bug the kernel while doing locking status checking v7: - Fixed patch format issues Cc: Michal Wajdeczko Cc: Chris Wilson Cc: Joonas Lahtinen Signed-off-by: Jackie Li --- drivers/gpu/drm/i915/intel_guc.h | 2 +- drivers/gpu/drm/i915/intel_guc_reg.h | 4 +- drivers/gpu/drm/i915/intel_guc_wopcm.c | 91 -- drivers/gpu/drm/i915/intel_guc_wopcm.h | 14 +- drivers/gpu/drm/i915/intel_uc.c| 5 +- 5 files changed, 106 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h index ea35911..7ed0c17 100644 --- a/drivers/gpu/drm/i915/intel_guc.h +++ b/drivers/gpu/drm/i915/intel_guc.h @@ -118,7 +118,7 @@ static inline u32 intel_guc_ggtt_offset(struct intel_guc *guc, { u32 offset = i915_ggtt_offset(vma); - GEM_BUG_ON(!guc->wopcm.valid); + GEM_BUG_ON(!(guc->wopcm.flags & INTEL_GUC_WOPCM_VALID)); GEM_BUG_ON(offset < guc->wopcm.top); GEM_BUG_ON(range_overflows_t(u64, offset, vma->size, GUC_GGTT_TOP)); diff --git a/drivers/gpu/drm/i915/intel_guc_reg.h b/drivers/gpu/drm/i915/intel_guc_reg.h index 9109be7..ee2b33ba 100644 --- a/drivers/gpu/drm/i915/intel_guc_reg.h +++ b/drivers/gpu/drm/i915/intel_guc_reg.h @@ -66,6 +66,7 @@ #define UOS_MOVE (1<<4) #define START_DMA (1<<0) #define DMA_GUC_WOPCM_OFFSET _MMIO(0xc340) +#define DMA_GUC_WOPCM_OFFSET_MASK (0xc000) #define HUC_LOADING_AGENT_VCR (0<<1) #define HUC_LOADING_AGENT_GUC (1<<1) #define GUC_MAX_IDLE_COUNT _MMIO(0xC3E4) @@ -75,7 +76,8 @@ /* Defines WOPCM space available to GuC firmware */ #define GUC_WOPCM_SIZE _MMIO(0xc050) -#define GUC_WOPCM_SIZE_MASK(0xf000) +#define GUC_WOPCM_SIZE_MASK(0xf000) +#define GUC_WOPCM_REG_LOCKED BIT(0) /* GuC addresses above GUC_GGTT_TOP also don't map through the GTT */ #define GUC_GGTT_TOP 0xFEE0 diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c b/drivers/gpu/drm/i915/intel_guc_wopcm.c index ed3096c..236fc32 100644 --- a/drivers/gpu/drm/i915/intel_guc_wopcm.c +++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c @@ -89,6 +89,53 @@ static inline int guc_wopcm_size_check(struct intel_guc *guc) return 0; } +static inline bool __reg_locked(struct drm_i915_private *dev_priv, + i915_reg_t reg) +{ + return !!(I915_READ(reg) & GUC_WOPCM_REG_LOCKED); +} + +static inline bool guc_wopcm_locked(struct intel_guc *guc) +{ + struct drm_i915_private *i915 = guc_to_i915(guc); + bool size_reg_locked = __reg_locked(i915, GUC_WOPCM_SIZE); + bool offset_reg_locked = __reg_locked(i915, DMA_GUC_WOPCM_OFFSET); + + return size_reg_locked && offset_reg_locked; +} + +static inline void guc_wopcm_hw_update(struct intel_guc *guc) +{ + struct drm_i915_private *dev_priv = guc_to_i915(guc); + + /* GuC WOPCM registers should be unlocked at this point. */ + GEM_BUG_ON(__reg_locked(dev_priv, GUC_WOPCM_SIZE)); + GEM_BUG_ON(__reg_locked(dev_priv, DMA_GUC_WOPCM_OFFSET)); + + I915_WRITE(GUC_WOPCM_SIZE, guc->wopcm.size); + I915_WRITE(DMA_GUC_WOPCM_OFFSET, + guc->wopcm.offset | HUC_LOADING_AGENT_GUC); + + GEM_BUG_ON(!__reg_locked(dev_priv, GUC_WOPCM_SIZE)); + GEM_BUG_ON(!__reg_locked(dev_priv, DMA_GUC_WOPCM_OFFSET)); +} + +static inline bool guc_wopcm_regs_valid(struct intel_guc *guc) +{ + struct drm_i915_private *dev_priv = guc_to_i915(guc); + u32 size, offset; + bool guc_loads_huc; + + size = I915_READ(GUC_WOPCM_SIZE) & GUC_WOPCM_SIZE_MASK; + offset = I915_READ(DMA_GUC_WOPCM_OFFSET); + + guc_loads_huc = !!(offset & HUC_LOADING_AGENT_GUC); + offset &= DMA_GUC_WOPCM_OFFSET_MASK; + + return guc_loads_huc && (size == guc->wopcm.size) && + (offset == guc->wopcm.offset); +} + /* * intel_guc_wopcm_init() - Initialize the GuC WOPCM partition. * @guc: intel guc. @@ -107,8 +154,7 @@ int intel_guc_wopcm_init(struct intel_guc *guc, u32 guc_fw_size, u32 offset, size, top; int err; - if (guc->wopcm.valid) - return 0; + GEM_BUG_ON(guc->wopcm.flags & INTEL_GUC_WOPCM_VALID); if (!guc_fw_size) return -EINVAL; @@ -14
[Intel-gfx] [PATCH v7 3/6] drm/i915/guc: Implement dynamic GuC WOPCM offset and size
Hardware may have specific restrictions on GuC WOPCM size versus HuC firmware size. With static GuC WOPCM size, there's no way to adjust the GuC WOPCM partition size based on the actual HuC firmware size, so that GuC/HuC loading failure would occur even if there was enough WOPCM space for both GuC and HuC firmware. This patch enables the dynamic calculation of the GuC WOPCM aperture size used by GuC and HuC firmware. GuC WOPCM offset is set to HuC size + reserved WOPCM size. GuC WOPCM size is set to total WOPCM size - GuC WOPCM offset - RC6CTX size. In this case, GuC WOPCM offset will be updated based on the size of HuC firmware while GuC WOPCM size will be set to use all the remaining WOPCM space. v2: - Removed intel_wopcm_init (Ville/Sagar/Joonas) - Renamed and Moved the intel_wopcm_partition into intel_guc (Sagar) - Removed unnecessary function calls (Joonas) - Init GuC WOPCM partition as soon as firmware fetching is completed v3: - Fixed indentation issues (Chris) - Removed layering violation code (Chris/Michal) - Created separat files for GuC wopcm code (Michal) - Used inline function to avoid code duplication (Michal) v4: - Preset the GuC WOPCM top during early GuC init (Chris) - Fail intel_uc_init_hw() as soon as GuC WOPCM partitioning failed v5: - Moved GuC DMA WOPCM register updating code into intel_guc_wopcm.c - Took care of the locking status before writing to GuC DMA Write-Once registers. (Joonas) v6: - Made sure the GuC WOPCM size to be multiple of 4K (4K aligned) Cc: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Sujaritha Sundaresan Cc: Daniele Ceraolo Spurio Cc: John Spotswood Cc: Oscar Mateo Cc: Chris Wilson Cc: Joonas Lahtinen Signed-off-by: Jackie Li --- drivers/gpu/drm/i915/i915_gem_context.c | 9 +-- drivers/gpu/drm/i915/intel_guc.c| 5 +- drivers/gpu/drm/i915/intel_guc.h| 12 ++-- drivers/gpu/drm/i915/intel_guc_reg.h| 1 + drivers/gpu/drm/i915/intel_guc_wopcm.c | 108 +--- drivers/gpu/drm/i915/intel_guc_wopcm.h | 40 ++-- drivers/gpu/drm/i915/intel_huc.c| 2 +- drivers/gpu/drm/i915/intel_uc.c | 11 +++- drivers/gpu/drm/i915/intel_uc_fw.c | 11 +++- drivers/gpu/drm/i915/intel_uc_fw.h | 16 + 10 files changed, 183 insertions(+), 32 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index 648e753..b485794 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -312,12 +312,13 @@ __create_hw_context(struct drm_i915_private *dev_priv, ctx->desc_template = default_desc_template(dev_priv, dev_priv->mm.aliasing_ppgtt); - /* GuC requires the ring to be placed above GUC_WOPCM_TOP. If GuC is not -* present or not in use we still need a small bias as ring wraparound -* at offset 0 sometimes hangs. No idea why. + /* +* GuC requires the ring to be placed above GuC WOPCM top. If GuC is not +- * present or not in use we still need a small bias as ring wraparound +- * at offset 0 sometimes hangs. No idea why. */ if (USES_GUC(dev_priv)) - ctx->ggtt_offset_bias = GUC_WOPCM_TOP; + ctx->ggtt_offset_bias = dev_priv->guc.wopcm.top; else ctx->ggtt_offset_bias = I915_GTT_PAGE_SIZE; diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index e70885b..3521beb 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -64,6 +64,7 @@ void intel_guc_init_early(struct intel_guc *guc) { intel_guc_fw_init_early(guc); intel_guc_ct_init_early(&guc->ct); + intel_guc_wopcm_init_early(&guc->wopcm); mutex_init(&guc->send_mutex); guc->send = intel_guc_send_nop; @@ -473,7 +474,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv) * This is a wrapper to create an object for use with the GuC. In order to * use it inside the GuC, an object needs to be pinned lifetime, so we allocate * both some backing storage and a range inside the Global GTT. We must pin - * it in the GGTT somewhere other than than [0, GUC_WOPCM_TOP) because that + * it in the GGTT somewhere other than than [0, GuC WOPCM top) because that * range is reserved inside GuC. * * Return: A i915_vma if successful, otherwise an ERR_PTR. @@ -494,7 +495,7 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size) goto err; ret = i915_vma_pin(vma, 0, PAGE_SIZE, - PIN_GLOBAL | PIN_OFFSET_BIAS | GUC_WOPCM_TOP); + PIN_GLOBAL | PIN_OFFSET_BIAS | guc->wopcm.top); if (ret) { vma = ERR_PTR(ret); goto err; diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h index b7e2a18..ea35911 100644 --- a/drivers/gpu/drm/i915/intel_guc.h +
[Intel-gfx] ✗ Fi.CI.IGT: warning for perf: Allow fine-grained PMU access control
== Series Details == Series: perf: Allow fine-grained PMU access control URL : https://patchwork.freedesktop.org/series/36723/ State : warning == Summary == Test kms_flip: Subgroup vblank-vs-modeset-suspend-interruptible: pass -> SKIP (shard-hsw) fdo#103540 Test drv_suspend: Subgroup sysfs-reader: pass -> SKIP (shard-hsw) Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-render: pass -> FAIL (shard-snb) fdo#101623 Test gem_exec_suspend: Subgroup basic-s3: skip -> PASS (shard-snb) fdo#103880 Test gem_eio: Subgroup in-flight: pass -> DMESG-WARN (shard-snb) fdo#104058 Test perf: Subgroup blocking: fail -> PASS (shard-hsw) fdo#102252 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 fdo#103880 https://bugs.freedesktop.org/show_bug.cgi?id=103880 fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-hswtotal:2676 pass:1678 dwarn:1 dfail:0 fail:10 skip:986 time:14901s shard-snbtotal:2753 pass:1317 dwarn:2 dfail:0 fail:11 skip:1423 time:7963s Blacklisted hosts: shard-apltotal:2753 pass:1714 dwarn:1 dfail:0 fail:23 skip:1015 time:14083s shard-kbltotal:2745 pass:1831 dwarn:1 dfail:0 fail:22 skip:890 time:10555s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7715/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 6/6] HAX Enable GuC Submission for CI
Signed-off-by: Jackie Li --- drivers/gpu/drm/i915/i915_gem_gtt.c| 4 ++-- drivers/gpu/drm/i915/i915_params.c | 2 +- drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/intel_guc_wopcm.c | 6 ++ 4 files changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 26dee5e..fed472a 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -3561,7 +3561,7 @@ int i915_ggtt_enable_hw(struct drm_i915_private *dev_priv) void i915_ggtt_enable_guc(struct drm_i915_private *i915) { - GEM_BUG_ON(i915->ggtt.invalidate != gen6_ggtt_invalidate); +// GEM_BUG_ON(i915->ggtt.invalidate != gen6_ggtt_invalidate); i915->ggtt.invalidate = guc_ggtt_invalidate; @@ -3571,7 +3571,7 @@ void i915_ggtt_enable_guc(struct drm_i915_private *i915) void i915_ggtt_disable_guc(struct drm_i915_private *i915) { /* We should only be called after i915_ggtt_enable_guc() */ - GEM_BUG_ON(i915->ggtt.invalidate != guc_ggtt_invalidate); +// GEM_BUG_ON(i915->ggtt.invalidate != guc_ggtt_invalidate); i915->ggtt.invalidate = gen6_ggtt_invalidate; diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index 0b553a8..b33d364 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -152,7 +152,7 @@ i915_param_named_unsafe(edp_vswing, int, 0400, i915_param_named_unsafe(enable_guc, int, 0400, "Enable GuC load for GuC submission and/or HuC load. " "Required functionality can be selected using bitmask values. " - "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)"); + "(-1=auto [default], 0=disable, 1=GuC submission, 2=HuC load)"); i915_param_named(guc_log_level, int, 0400, "GuC firmware logging level. Requires GuC to be loaded. " diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index c963603..53037b5 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) \ diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c b/drivers/gpu/drm/i915/intel_guc_wopcm.c index 236fc32..e972b7b 100644 --- a/drivers/gpu/drm/i915/intel_guc_wopcm.c +++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c @@ -154,6 +154,9 @@ int intel_guc_wopcm_init(struct intel_guc *guc, u32 guc_fw_size, u32 offset, size, top; int err; + DRM_DEBUG_DRIVER("guc_fw size %u, huc_fw_size %u\n", guc_fw_size, +huc_fw_size); + GEM_BUG_ON(guc->wopcm.flags & INTEL_GUC_WOPCM_VALID); if (!guc_fw_size) @@ -213,6 +216,9 @@ void intel_guc_wopcm_init_hw(struct intel_guc *guc) { u32 locked = guc_wopcm_locked(guc); + DRM_DEBUG_DRIVER("locked = %s, flags = %#x\n", yesno(locked), +guc->wopcm.flags); + GEM_BUG_ON(!(guc->wopcm.flags & INTEL_GUC_WOPCM_VALID)); /* -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: II stage HDCP auth for repeater only
On Thu, Jan 18, 2018 at 7:50 PM, C, Ramalingam wrote: >> -Original Message- >> From: Sean Paul [mailto:seanp...@chromium.org] >> Sent: Friday, January 19, 2018 3:54 AM >> To: C, Ramalingam >> Cc: intel-gfx@lists.freedesktop.org; seanp...@chromium.org; >> daniel.vet...@ffwll.ch; Vivi, Rodrigo ; Sharma, >> Shashank >> Subject: Re: [PATCH 2/4] drm/i915: II stage HDCP auth for repeater only >> >> On Thu, Jan 18, 2018 at 11:18:06AM +0530, Ramalingam C wrote: >> > Second stage of HDCP authentication required only if the HDCP sink is >> > a repeater. >> > >> > This patch imposes above condition on second stage HDCP authentication. >> >> Hi Ram, >> This is already enforced in intel_hdcp_auth_downstream() > > I am not able to locate any check for repeater capability at start of > downstream auth. > > I am not sure whether you are referring to number of downstream device count > check. > That is valid after poll for ksv_fifo ready. We don't want to wait for 5Sec > timeout in poll to detect the repeater cap. > > And since the caller is handy with the flag for repeater cap, it is best to > decide on the call for downstream auth itself. > Thanks for clarifying, makes sense with the other patches in the set. Sean > Thanks > --Ram >> >> Thanks, >> Sean >> >> > >> > Signed-off-by: Ramalingam C >> > --- >> > drivers/gpu/drm/i915/intel_hdcp.c | 5 - >> > 1 file changed, 4 insertions(+), 1 deletion(-) >> > >> > diff --git a/drivers/gpu/drm/i915/intel_hdcp.c >> > b/drivers/gpu/drm/i915/intel_hdcp.c >> > index 6ce6559897a6..b48c72cd0906 100644 >> > --- a/drivers/gpu/drm/i915/intel_hdcp.c >> > +++ b/drivers/gpu/drm/i915/intel_hdcp.c >> > @@ -493,7 +493,10 @@ static int intel_hdcp_auth(struct intel_digital_port >> *intel_dig_port, >> > * on those as well. >> > */ >> > >> > - return intel_hdcp_auth_downstream(intel_dig_port, shim); >> > + if (repeater_present) >> > + return intel_hdcp_auth_downstream(intel_dig_port, shim); >> > + >> > + return 0; >> > } >> > >> > static >> > -- >> > 2.7.4 >> > >> >> -- >> Sean Paul, Software Engineer, Google / Chromium OS ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: II stage HDCP auth for repeater only
On Thu, Jan 18, 2018 at 11:18:06AM +0530, Ramalingam C wrote: > Second stage of HDCP authentication required only if the HDCP > sink is a repeater. > > This patch imposes above condition on second stage HDCP authentication. Hi Ram, This is already enforced in intel_hdcp_auth_downstream() Thanks, Sean > > Signed-off-by: Ramalingam C > --- > drivers/gpu/drm/i915/intel_hdcp.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_hdcp.c > b/drivers/gpu/drm/i915/intel_hdcp.c > index 6ce6559897a6..b48c72cd0906 100644 > --- a/drivers/gpu/drm/i915/intel_hdcp.c > +++ b/drivers/gpu/drm/i915/intel_hdcp.c > @@ -493,7 +493,10 @@ static int intel_hdcp_auth(struct intel_digital_port > *intel_dig_port, >* on those as well. >*/ > > - return intel_hdcp_auth_downstream(intel_dig_port, shim); > + if (repeater_present) > + return intel_hdcp_auth_downstream(intel_dig_port, shim); > + > + return 0; > } > > static > -- > 2.7.4 > -- Sean Paul, Software Engineer, Google / Chromium OS ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-misc-fixes tree
Hi, Stephen, That would be me. I've historically only added my signed-off-by:s on commits I've (co-) authored myself, as the committer info is already registered, But I take it that's not the correct approach? /Thomas On 01/18/2018 09:23 PM, Stephen Rothwell wrote: Hi all, Commit 8a510a5c7526 ("drm/vmwgfx: fix memory corruption with legacy/sou connectors") is missing a Signed-off-by from its committer. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-misc-fixes tree
Hi Thomas, On Thu, 18 Jan 2018 22:18:48 +0100 Thomas Hellstrom wrote: > > That would be me. > I've historically only added my signed-off-by:s on commits I've (co-) > authored myself, as the committer info is already registered, > > But I take it that's not the correct approach? Please read "Developer's Certificate of Origin 1.1" in Documentation/process/submitting-patches.rst. Basically, if you handle the patch on its way to Linus (e.g. commit it to a branch of a git tree that Linus (or someone else along the path) merges) then you need to add a Signed-off-by tag. -- Cheers, Stephen Rothwell ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v2 6/8] drm: Handle fbdev emulation in core
[oops, this was stuck in my draft folder, sry] On Thu, Jan 11, 2018 at 3:09 PM, Noralf Trønnes wrote: > > Den 11.01.2018 08.45, skrev Daniel Vetter: >> >> On Wed, Jan 10, 2018 at 06:02:38PM +0100, Noralf Trønnes wrote: >>> >>> Den 09.01.2018 11.38, skrev Daniel Vetter: On Wed, Jan 03, 2018 at 11:21:08PM +0100, Noralf Trønnes wrote: > > Prepare for generic fbdev emulation by letting DRM core work directly > with the fbdev compatibility layer. This is done by adding new fbdev > helper vtable callbacks for restore, hotplug_event, unregister and > release. > > Signed-off-by: Noralf Trønnes No clue whether my idea is any good, but inspired by the bootsplash discussion, and the prospect that we might get other in-kernel drm/kms clients I'm wondering whether we should make this a bit more generic and tie it to drm_file? The idea would be to have a list of internal drm clients by putting all the internal drm_files onto a list (same way we do with the userspace ones). Then we'd just walk that list and call ->hotplug, ->unregister and ->release at the right places. ->restore would be a bit different, I guess for that we'd only call the ->restore callback of the very first kernel-internal client. With that we could then add/remove kernel-internal drm clients like normal userspace clients, which should make integration of emergency consoles, boot splashes and whatever else real easy. And I think it would be a lot cleaner than leaking fb_helper knowledge into the drm core, which feels a rather backwards. Otoh that feels a bit overengineered (but at least it shouldn't be a lot more code really). If the list is too much work we could start with 1 drm_file * pointer for internal stuff (but would still need locking, so list_head is probably easier). Thoughts? >>> >>> I prefer to have a proper in-kernel client API from the get go, instead >>> of fixing it up later. The reason I skipped spending time on it in this >>> RFC, was that I didn't know if I was on the right track at the right time >>> to get the necessary attention to make this dumb_buffer idea happen. >>> >>> With a drm_file centric approach, are you thinking something like this: >>> >>> struct drm_device { >>> +struct list_head filelist_internal; >>> }; >>> >>> +struct drm_file_funcs { >>> +int (*restore)(struct drm_file *file); >>> +void (*hotplug)(struct drm_file *file); >>> +void (*unregister)(struct drm_file *file); >> >> I guess we still need a cleanup callback here? For the usual two-stage >> driver unload sequence of 1. unregister 2. cleanup. > > > There's no need for a cleanup callback in this scenario. > The client holds a ref on drm_device through drm_internal_open() and if > it can't release the drm_file on .unregister, there won't be any cleanup. > When the client is in a position to release drm_file (fb_close), it will > do so and the ref is dropped. But when will we clean up fbdev helper allocations and things like that? If we do that through a ->release callback I think we can avoid a few special cases. Hm right, drm_file holds a full ref, so we won't ever enter that case. That's annoying, since this means there's no clear place for us to release stuff again Should we perhaps try to drop the references in ->unregister, but keep the drm_file on the list for ->release time? I'd assume that trying to guess when exactly it's safe to release all the fbdev allocated resources is otherwise going to be somewhat tricky. Or maybe I'm just seeing monsters when there's actually no problem at all :-) > If for some reason we can't take a ref, then we need to use > drm_device.open_count to avoid drm_device going away in drm_dev_unplug(). open_count also holds a drm_get_dev reference (but implicitly). -Daniel > > Noralf. > > >> >>> +}; >>> >>> struct drm_file { >>> +struct drm_device *dev; >>> +const struct drm_file_funcs *funcs; >>> }; >>> >>> struct drm_file *drm_file_alloc(struct drm_minor *minor) >>> { >>> +file->dev = dev; >>> } >>> >>> struct drm_file* drm_internal_open(struct drm_device *dev, >>> const struct drm_file_funcs *funcs) >>> struct drm_file *file; >>> int ret; >>> >>> if (!try_module_get(dev->driver->fops->owner)) >>> return ERR_PTR(-ENODEV); >>> >>> drm_dev_ref(dev); >>> >>> file = drm_file_alloc(dev); >>> if (IS_ERR(file)) { >>> drm_dev_unref(dev); >>> module_put(dev->driver->fops->owner); >>> return file; >>> } >>> >>> file->funcs = funcs; >>> >>> mutex_lock(&dev->filelist_mutex); >>> list_add(&file->lhead, &dev->filelist_internal); >>> mutex_unlock(&dev->filelist_mutex); >>> >>> return file; >>> } >>> >>> void drm_internal_release(struct drm_file *file) >>> { >>> struct drm_device *dev = f
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dp: Fix compilation of intel_dp_hdcp_check_link
== Series Details == Series: drm/i915/dp: Fix compilation of intel_dp_hdcp_check_link URL : https://patchwork.freedesktop.org/series/36707/ State : failure == Summary == Test kms_flip: Subgroup vblank-vs-modeset-suspend-interruptible: pass -> SKIP (shard-snb) pass -> SKIP (shard-hsw) fdo#103540 Subgroup 2x-vblank-vs-suspend-interruptible: pass -> INCOMPLETE (shard-hsw) Subgroup flip-vs-modeset-vs-hang-interruptible: dmesg-warn -> PASS (shard-snb) fdo#104311 Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-render: fail -> PASS (shard-snb) fdo#101623 +1 Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 Test kms_draw_crc: Subgroup draw-method-xrgb-mmap-cpu-untiled: skip -> PASS (shard-snb) Subgroup draw-method-rgb565-blt-untiled: skip -> PASS (shard-snb) Test kms_chv_cursor_fail: Subgroup pipe-a-256x256-bottom-edge: skip -> PASS (shard-snb) Test kms_universal_plane: Subgroup disable-primary-vs-flip-pipe-b: skip -> PASS (shard-snb) Test drv_suspend: Subgroup sysfs-reader: pass -> SKIP (shard-hsw) fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#104311 https://bugs.freedesktop.org/show_bug.cgi?id=104311 fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-hswtotal:2723 pass:1703 dwarn:1 dfail:0 fail:11 skip:1006 time:14599s shard-snbtotal:2753 pass:1318 dwarn:1 dfail:0 fail:10 skip:1424 time:7892s Blacklisted hosts: shard-apltotal:2753 pass:1716 dwarn:1 dfail:0 fail:21 skip:1015 time:13886s shard-kbltotal:2745 pass:1829 dwarn:2 dfail:0 fail:22 skip:891 time:10483s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7713/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-misc-fixes tree
Hi all, Commit 8a510a5c7526 ("drm/vmwgfx: fix memory corruption with legacy/sou connectors") is missing a Signed-off-by from its committer. -- Cheers, Stephen Rothwell ___ 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/bios: add DP max link rate to VBT child device struct (rev2)
== Series Details == Series: drm/i915/bios: add DP max link rate to VBT child device struct (rev2) URL : https://patchwork.freedesktop.org/series/36701/ State : failure == Summary == Warning: bzip Patchwork_7712/shard-hsw1/results34.json.bz2 wasn't in correct JSON format Test perf: Subgroup blocking: pass -> FAIL (shard-hsw) fdo#102252 Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-render: fail -> PASS (shard-snb) fdo#101623 Test kms_flip: Subgroup 2x-plain-flip-fb-recreate-interruptible: pass -> FAIL (shard-hsw) Subgroup flip-vs-modeset-vs-hang-interruptible: dmesg-warn -> PASS (shard-snb) fdo#104311 Subgroup plain-flip-fb-recreate-interruptible: pass -> FAIL (shard-hsw) fdo#100368 Test kms_flip_event_leak: pass -> SKIP (shard-snb) Test kms_draw_crc: Subgroup draw-method-xrgb-mmap-cpu-untiled: skip -> PASS (shard-snb) Subgroup draw-method-rgb565-blt-untiled: skip -> PASS (shard-snb) Test kms_chv_cursor_fail: Subgroup pipe-a-256x256-bottom-edge: skip -> PASS (shard-snb) Test kms_universal_plane: Subgroup disable-primary-vs-flip-pipe-b: skip -> PASS (shard-snb) Test drv_suspend: Subgroup sysfs-reader: pass -> SKIP (shard-hsw) fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 fdo#104311 https://bugs.freedesktop.org/show_bug.cgi?id=104311 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 shard-hswtotal:2676 pass:1679 dwarn:1 dfail:0 fail:12 skip:983 time:15183s shard-snbtotal:2753 pass:1317 dwarn:1 dfail:0 fail:11 skip:1424 time:7929s Blacklisted hosts: shard-apltotal:2753 pass:1716 dwarn:1 dfail:0 fail:21 skip:1015 time:13942s shard-kbltotal:2745 pass:1829 dwarn:1 dfail:0 fail:24 skip:890 time:10330s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7712/shards.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/bios: add DP max link rate to VBT child device struct
On Thu, Jan 18, 2018 at 08:12:18PM +, Rodrigo Vivi wrote: > On Thu, Jan 18, 2018 at 03:33:10PM +, Jani Nikula wrote: > > Update VBT defs to reflect revision 216. While at it, default the > > expected child device struct size to sizeof the size rather than a > > hardcoded value. > > > > v2: Fix bit order (David) > > > > Cc: Rodrigo Vivi > > Signed-off-by: Jani Nikula > > Reviewed-by: Rodrigo Vivi and merged... thanks > > > > --- > > drivers/gpu/drm/i915/intel_bios.c | 8 +--- > > drivers/gpu/drm/i915/intel_vbt_defs.h | 2 ++ > > 2 files changed, 7 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_bios.c > > b/drivers/gpu/drm/i915/intel_bios.c > > index 51108ffc28d1..b820d595ebc8 100644 > > --- a/drivers/gpu/drm/i915/intel_bios.c > > +++ b/drivers/gpu/drm/i915/intel_bios.c > > @@ -1323,11 +1323,13 @@ parse_general_definitions(struct drm_i915_private > > *dev_priv, > > expected_size = LEGACY_CHILD_DEVICE_CONFIG_SIZE; > > } else if (bdb->version == 195) { > > expected_size = 37; > > - } else if (bdb->version <= 197) { > > + } else if (bdb->version <= 215) { > > expected_size = 38; > > + } else if (bdb->version <= 216) { > > + expected_size = 39; > > } else { > > - expected_size = 38; > > - BUILD_BUG_ON(sizeof(*child) < 38); > > + expected_size = sizeof(*child); > > + BUILD_BUG_ON(sizeof(*child) < 39); > > DRM_DEBUG_DRIVER("Expected child device config size for VBT > > version %u not known; assuming %u\n", > > bdb->version, expected_size); > > } > > diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h > > b/drivers/gpu/drm/i915/intel_vbt_defs.h > > index e3d7745a9151..98dff6058d3c 100644 > > --- a/drivers/gpu/drm/i915/intel_vbt_defs.h > > +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h > > @@ -412,6 +412,8 @@ struct child_device_config { > > u16 dp_gpio_pin_num;/* 195 */ > > u8 dp_iboost_level:4; /* 196 */ > > u8 hdmi_iboost_level:4; /* 196 */ > > + u8 dp_max_link_rate:2; /* 216 CNL+ */ > > + u8 dp_max_link_rate_reserved:6; /* 216 */ > > } __packed; > > > > struct bdb_general_definitions { > > -- > > 2.11.0 > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/bios: add DP max link rate to VBT child device struct
On Thu, Jan 18, 2018 at 03:33:10PM +, Jani Nikula wrote: > Update VBT defs to reflect revision 216. While at it, default the > expected child device struct size to sizeof the size rather than a > hardcoded value. > > v2: Fix bit order (David) > > Cc: Rodrigo Vivi > Signed-off-by: Jani Nikula Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_bios.c | 8 +--- > drivers/gpu/drm/i915/intel_vbt_defs.h | 2 ++ > 2 files changed, 7 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_bios.c > b/drivers/gpu/drm/i915/intel_bios.c > index 51108ffc28d1..b820d595ebc8 100644 > --- a/drivers/gpu/drm/i915/intel_bios.c > +++ b/drivers/gpu/drm/i915/intel_bios.c > @@ -1323,11 +1323,13 @@ parse_general_definitions(struct drm_i915_private > *dev_priv, > expected_size = LEGACY_CHILD_DEVICE_CONFIG_SIZE; > } else if (bdb->version == 195) { > expected_size = 37; > - } else if (bdb->version <= 197) { > + } else if (bdb->version <= 215) { > expected_size = 38; > + } else if (bdb->version <= 216) { > + expected_size = 39; > } else { > - expected_size = 38; > - BUILD_BUG_ON(sizeof(*child) < 38); > + expected_size = sizeof(*child); > + BUILD_BUG_ON(sizeof(*child) < 39); > DRM_DEBUG_DRIVER("Expected child device config size for VBT > version %u not known; assuming %u\n", >bdb->version, expected_size); > } > diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h > b/drivers/gpu/drm/i915/intel_vbt_defs.h > index e3d7745a9151..98dff6058d3c 100644 > --- a/drivers/gpu/drm/i915/intel_vbt_defs.h > +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h > @@ -412,6 +412,8 @@ struct child_device_config { > u16 dp_gpio_pin_num;/* 195 */ > u8 dp_iboost_level:4; /* 196 */ > u8 hdmi_iboost_level:4; /* 196 */ > + u8 dp_max_link_rate:2; /* 216 CNL+ */ > + u8 dp_max_link_rate_reserved:6; /* 216 */ > } __packed; > > struct bdb_general_definitions { > -- > 2.11.0 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnl: apply Display WA #1178 to fix type C dongles
On Thu, Jan 18, 2018 at 07:39:51PM +, Rodrigo Vivi wrote: > On Tue, Nov 28, 2017 at 10:05:53PM +, Lucas De Marchi wrote: > > Display WA #1178 is meant to fix Aux channel voltage swing too low with > > some type C dongles. Although it is for type C, HW engineers reported > > that it can be applied to all external ports even if they are not going > > to type C. > > > > For CNL we apply the workaround every time Aux B, C and D are powering > > up since they will lose the configuration when powered down. > > > > v2: Use common tag for WA > > > > Cc: Rodrigo Vivi > > Cc: Arthur J Runyan > > Cc: Ville Syrjälä > > Signed-off-by: Lucas De Marchi > > we got all confirmations that we need. Thanks Art. > > Reviewed-by: Rodrigo Vivi merged. Thanks for the patch. > > > --- > > drivers/gpu/drm/i915/i915_reg.h | 11 +++ > > drivers/gpu/drm/i915/intel_runtime_pm.c | 9 + > > 2 files changed, 20 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h > > b/drivers/gpu/drm/i915/i915_reg.h > > index 09bf043c1c2e..0214327d8af7 100644 > > --- a/drivers/gpu/drm/i915/i915_reg.h > > +++ b/drivers/gpu/drm/i915/i915_reg.h > > @@ -8335,6 +8335,17 @@ enum skl_power_gate { > > #define SKL_PW_TO_PG(pw) ((pw) - SKL_DISP_PW_1 + SKL_PG1) > > #define SKL_FUSE_PG_DIST_STATUS(pg) (1 << (27 - (pg))) > > > > +#define _CNL_AUX_REG_IDX(pw) ((pw - 1) >> 4) > > +#define _CNL_AUX_ANAOVRD1_B0x162250 > > +#define _CNL_AUX_ANAOVRD1_C0x162210 > > +#define _CNL_AUX_ANAOVRD1_D0x1622D0 > > +#define CNL_AUX_ANAOVRD1(pw) > > _MMIO(_PICK(_CNL_AUX_REG_IDX(pw), \ > > + _CNL_AUX_ANAOVRD1_B, \ > > + _CNL_AUX_ANAOVRD1_C, \ > > + _CNL_AUX_ANAOVRD1_D)) > > +#define CNL_AUX_ANAOVRD1_ENABLE (1<<16) > > +#define CNL_AUX_ANAOVRD1_LDO_BYPASS (1<<23) > > + > > /* Per-pipe DDI Function Control */ > > #define _TRANS_DDI_FUNC_CTL_A 0x60400 > > #define _TRANS_DDI_FUNC_CTL_B 0x61400 > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c > > b/drivers/gpu/drm/i915/intel_runtime_pm.c > > index 8315499452dc..29f14e724f41 100644 > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c > > @@ -388,6 +388,15 @@ static void hsw_power_well_enable(struct > > drm_i915_private *dev_priv, > > I915_WRITE(HSW_PWR_WELL_CTL_DRIVER(id), val | HSW_PWR_WELL_CTL_REQ(id)); > > hsw_wait_for_power_well_enable(dev_priv, power_well); > > > > + /* Display WA #1178: cnl */ > > + if (IS_CANNONLAKE(dev_priv) && > > + (id == CNL_DISP_PW_AUX_B || id == CNL_DISP_PW_AUX_C || > > +id == CNL_DISP_PW_AUX_D)) { > > + val = I915_READ(CNL_AUX_ANAOVRD1(id)); > > + val |= CNL_AUX_ANAOVRD1_ENABLE | CNL_AUX_ANAOVRD1_LDO_BYPASS; > > + I915_WRITE(CNL_AUX_ANAOVRD1(id), val); > > + } > > + > > if (wait_fuses) > > gen9_wait_for_power_well_fuses(dev_priv, pg); > > > > -- > > 2.14.3 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: vbt defs typo fixes
== Series Details == Series: drm/i915: vbt defs typo fixes URL : https://patchwork.freedesktop.org/series/36702/ State : warning == Summary == Warning: bzip Patchwork_7711/shard-hsw6/results34.json.bz2 wasn't in correct JSON format Test kms_flip: Subgroup plain-flip-fb-recreate-interruptible: pass -> FAIL (shard-hsw) fdo#100368 Subgroup flip-vs-modeset-vs-hang-interruptible: dmesg-warn -> PASS (shard-snb) fdo#104311 Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-spr-indfb-draw-mmap-wc: pass -> SKIP (shard-snb) fdo#101623 +2 Test kms_draw_crc: Subgroup draw-method-xrgb-mmap-cpu-untiled: skip -> PASS (shard-snb) Subgroup draw-method-rgb565-blt-untiled: skip -> PASS (shard-snb) Test kms_chv_cursor_fail: Subgroup pipe-a-256x256-bottom-edge: skip -> PASS (shard-snb) Test kms_universal_plane: Subgroup disable-primary-vs-flip-pipe-b: skip -> PASS (shard-snb) Test drv_suspend: Subgroup sysfs-reader: pass -> SKIP (shard-hsw) fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#104311 https://bugs.freedesktop.org/show_bug.cgi?id=104311 fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 shard-hswtotal:2676 pass:1681 dwarn:1 dfail:0 fail:10 skip:983 time:15243s shard-snbtotal:2753 pass:1318 dwarn:1 dfail:0 fail:10 skip:1424 time:7913s Blacklisted hosts: shard-apltotal:2753 pass:1715 dwarn:1 dfail:0 fail:22 skip:1015 time:13891s shard-kbltotal:2745 pass:1827 dwarn:1 dfail:0 fail:23 skip:893 time:10351s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7711/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/cnl: apply Display WA #1178 to fix type C dongles
On Tue, Nov 28, 2017 at 10:05:53PM +, Lucas De Marchi wrote: > Display WA #1178 is meant to fix Aux channel voltage swing too low with > some type C dongles. Although it is for type C, HW engineers reported > that it can be applied to all external ports even if they are not going > to type C. > > For CNL we apply the workaround every time Aux B, C and D are powering > up since they will lose the configuration when powered down. > > v2: Use common tag for WA > > Cc: Rodrigo Vivi > Cc: Arthur J Runyan > Cc: Ville Syrjälä > Signed-off-by: Lucas De Marchi we got all confirmations that we need. Thanks Art. Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/i915_reg.h | 11 +++ > drivers/gpu/drm/i915/intel_runtime_pm.c | 9 + > 2 files changed, 20 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 09bf043c1c2e..0214327d8af7 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -8335,6 +8335,17 @@ enum skl_power_gate { > #define SKL_PW_TO_PG(pw)((pw) - SKL_DISP_PW_1 + SKL_PG1) > #define SKL_FUSE_PG_DIST_STATUS(pg) (1 << (27 - (pg))) > > +#define _CNL_AUX_REG_IDX(pw) ((pw - 1) >> 4) > +#define _CNL_AUX_ANAOVRD1_B 0x162250 > +#define _CNL_AUX_ANAOVRD1_C 0x162210 > +#define _CNL_AUX_ANAOVRD1_D 0x1622D0 > +#define CNL_AUX_ANAOVRD1(pw) _MMIO(_PICK(_CNL_AUX_REG_IDX(pw), \ > + _CNL_AUX_ANAOVRD1_B, \ > + _CNL_AUX_ANAOVRD1_C, \ > + _CNL_AUX_ANAOVRD1_D)) > +#define CNL_AUX_ANAOVRD1_ENABLE(1<<16) > +#define CNL_AUX_ANAOVRD1_LDO_BYPASS(1<<23) > + > /* Per-pipe DDI Function Control */ > #define _TRANS_DDI_FUNC_CTL_A0x60400 > #define _TRANS_DDI_FUNC_CTL_B0x61400 > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c > b/drivers/gpu/drm/i915/intel_runtime_pm.c > index 8315499452dc..29f14e724f41 100644 > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c > @@ -388,6 +388,15 @@ static void hsw_power_well_enable(struct > drm_i915_private *dev_priv, > I915_WRITE(HSW_PWR_WELL_CTL_DRIVER(id), val | HSW_PWR_WELL_CTL_REQ(id)); > hsw_wait_for_power_well_enable(dev_priv, power_well); > > + /* Display WA #1178: cnl */ > + if (IS_CANNONLAKE(dev_priv) && > + (id == CNL_DISP_PW_AUX_B || id == CNL_DISP_PW_AUX_C || > + id == CNL_DISP_PW_AUX_D)) { > + val = I915_READ(CNL_AUX_ANAOVRD1(id)); > + val |= CNL_AUX_ANAOVRD1_ENABLE | CNL_AUX_ANAOVRD1_LDO_BYPASS; > + I915_WRITE(CNL_AUX_ANAOVRD1(id), val); > + } > + > if (wait_fuses) > gen9_wait_for_power_well_fuses(dev_priv, pg); > > -- > 2.14.3 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for perf: Allow fine-grained PMU access control
== Series Details == Series: perf: Allow fine-grained PMU access control URL : https://patchwork.freedesktop.org/series/36723/ State : success == Summary == Series 36723v1 perf: Allow fine-grained PMU access control https://patchwork.freedesktop.org/api/1.0/series/36723/revisions/1/mbox/ Test kms_force_connector_basic: Subgroup prune-stale-modes: skip -> PASS (fi-snb-2520m) fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:419s 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:379s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:483s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:280s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:482s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:481s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:464s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:456s fi-elk-e7500 total:224 pass:168 dwarn:10 dfail:0 fail:0 skip:45 fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:275s 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:392s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:398s 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:451s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:415s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:458s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:497s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:451s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:499s 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:426s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:511s 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:485s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:470s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:433s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:523s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:400s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:568s fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:473s fi-skl-guc total:288 pass:214 dwarn:46 dfail:0 fail:0 skip:28 time:413s a9c74eaa2b1cf3a3aa9f0efcfde34c0f4fefe8ac drm-tip: 2018y-01m-18d-18h-18m-07s UTC integration manifest 05467a39a151 perf: Allow fine-grained PMU access control == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7715/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC] perf: Allow fine-grained PMU access control
From: Tvrtko Ursulin For situations where sysadmins might want to allow different level of of access control for different PMUs, we start creating per-PMU perf_event_paranoid controls in sysfs. These work in equivalent fashion as the existing perf_event_paranoid sysctl, which now becomes the parent control for each PMU. On PMU registration the global/parent value will be inherited by each PMU, as it will be propagated to all registered PMUs when the sysctl is updated. At any later point individual PMU access controls, located in /device//perf_event_paranoid, can be adjusted to achieve fine grained access control. Signed-off-by: Tvrtko Ursulin Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Namhyung Kim Cc: linux-ker...@vger.kernel.org --- arch/x86/events/intel/bts.c | 2 +- arch/x86/events/intel/core.c| 2 +- arch/x86/events/intel/p4.c | 2 +- include/linux/perf_event.h | 18 +--- kernel/events/core.c| 99 ++--- kernel/sysctl.c | 4 +- kernel/trace/trace_event_perf.c | 6 ++- 7 files changed, 105 insertions(+), 28 deletions(-) diff --git a/arch/x86/events/intel/bts.c b/arch/x86/events/intel/bts.c index 24ffa1e88cf9..e416c9e2400a 100644 --- a/arch/x86/events/intel/bts.c +++ b/arch/x86/events/intel/bts.c @@ -555,7 +555,7 @@ static int bts_event_init(struct perf_event *event) * Note that the default paranoia setting permits unprivileged * users to profile the kernel. */ - if (event->attr.exclude_kernel && perf_paranoid_kernel() && + if (event->attr.exclude_kernel && perf_paranoid_kernel(event->pmu) && !capable(CAP_SYS_ADMIN)) return -EACCES; diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index 731153a4681e..d623db13f212 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -3009,7 +3009,7 @@ static int intel_pmu_hw_config(struct perf_event *event) if (x86_pmu.version < 3) return -EINVAL; - if (perf_paranoid_cpu() && !capable(CAP_SYS_ADMIN)) + if (perf_paranoid_cpu(event->pmu) && !capable(CAP_SYS_ADMIN)) return -EACCES; event->hw.config |= ARCH_PERFMON_EVENTSEL_ANY; diff --git a/arch/x86/events/intel/p4.c b/arch/x86/events/intel/p4.c index d32c0eed38ca..878451ef1ace 100644 --- a/arch/x86/events/intel/p4.c +++ b/arch/x86/events/intel/p4.c @@ -776,7 +776,7 @@ static int p4_validate_raw_event(struct perf_event *event) * the user needs special permissions to be able to use it */ if (p4_ht_active() && p4_event_bind_map[v].shared) { - if (perf_paranoid_cpu() && !capable(CAP_SYS_ADMIN)) + if (perf_paranoid_cpu(event->pmu) && !capable(CAP_SYS_ADMIN)) return -EACCES; } diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h index 7546822a1d74..1cb4e00d7f96 100644 --- a/include/linux/perf_event.h +++ b/include/linux/perf_event.h @@ -271,6 +271,9 @@ struct pmu { /* number of address filters this PMU can do */ unsigned intnr_addr_filters; + /* fine grained access control */ + int perf_event_paranoid; + /* * Fully disable/enable this PMU, can be used to protect from the PMI * as well as for lazy/batch writing of the MSRs. @@ -1141,6 +1144,9 @@ extern int sysctl_perf_cpu_time_max_percent; extern void perf_sample_event_took(u64 sample_len_ns); +extern int perf_proc_paranoid_handler(struct ctl_table *table, int write, + void __user *buffer, size_t *lenp, + loff_t *ppos); extern int perf_proc_update_handler(struct ctl_table *table, int write, void __user *buffer, size_t *lenp, loff_t *ppos); @@ -1151,19 +1157,19 @@ extern int perf_cpu_time_max_percent_handler(struct ctl_table *table, int write, int perf_event_max_stack_handler(struct ctl_table *table, int write, void __user *buffer, size_t *lenp, loff_t *ppos); -static inline bool perf_paranoid_tracepoint_raw(void) +static inline bool perf_paranoid_tracepoint_raw(const struct pmu *pmu) { - return sysctl_perf_event_paranoid > -1; + return pmu->perf_event_paranoid > -1; } -static inline bool perf_paranoid_cpu(void) +static inline bool perf_paranoid_cpu(const struct pmu *pmu) { - return sysctl_perf_event_paranoid > 0; + return pmu->perf_event_paranoid > 0; } -static inline bool perf_paranoid_kernel(void) +static inline bool perf_paranoid_kernel(const struct pmu *pmu) { - return sysctl_perf_event_paranoid > 1; + return pmu->perf_event_paranoid > 1; } extern void perf_event_init(void); diff --git a/kernel/events/core.c b/kernel/events/core.c index b4152da656fa..21fd4430df66 100644 --- a/ke
Re: [Intel-gfx] [PULL] gvt-next fixes for 4.16
On Thu, Jan 18, 2018 at 02:23:13AM +, Zhenyu Wang wrote: > On 2018.01.17 08:03:49 -0800, Rodrigo Vivi wrote: > > > > > > Zhenyu Wang (2): > > > drm/i915/gvt: cancel virtual vblank timer when no vGPU exists > > > drm/i915/gvt: cancel scheduler timer when no vGPU exists > > > > dim: ERROR: 0eb582541cfd7a17b6fcf9282c966c0e59efd02f is lacking mandatory > > review, aborting > > > > Is it possible to get someone to quickly review it and fix the original > > commit, like last time? > > > > yeah that two have been on gvt list for a while and seems people > are fine with it and no regression for nightly test, I'll ask Zhi > to ack and should be able to resend pull today. I need to update > gvt tool to apply that rule as well. Thanks for taking care of that. applied now. > > thanks > > -- > Open Source Technology Center, Intel ltd. > > $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: expose RCS topology to userspace
== Series Details == Series: drm/i915: expose RCS topology to userspace URL : https://patchwork.freedesktop.org/series/36696/ State : failure == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-blt: pass -> FAIL (shard-snb) fdo#101623 Test kms_flip: Subgroup vblank-vs-suspend: skip -> PASS (shard-snb) fdo#102365 Subgroup flip-vs-expired-vblank-interruptible: pass -> FAIL (shard-snb) Subgroup 2x-blt-wf_vblank-vs-dpms: dmesg-warn -> PASS (shard-hsw) Test perf: Subgroup invalid-open-flags: pass -> INCOMPLETE (shard-hsw) Subgroup blocking: pass -> FAIL (shard-hsw) fdo#102252 Test drv_suspend: Subgroup sysfs-reader: pass -> SKIP (shard-hsw) fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-hswtotal:2731 pass:1712 dwarn:1 dfail:0 fail:11 skip:1005 time:15233s shard-snbtotal:2753 pass:1317 dwarn:1 dfail:0 fail:12 skip:1423 time:7896s Blacklisted hosts: shard-apltotal:2753 pass:1714 dwarn:1 dfail:0 fail:23 skip:1015 time:13842s shard-kbltotal:2706 pass:1799 dwarn:1 dfail:0 fail:23 skip:881 time:10288s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7710/shards.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: Use the engine name directly in the error_state file
Quoting Michel Thierry (2018-01-10 01:21:51) > Instead of using local string names that we will have to keep > maintaining, use the engine->name directly. > > v2: Better invalid engine_id handling, capture_bo will not be able know > the engine_id and end up with -1 (Michal). > > Suggested-by: Michal Wajdeczko > Signed-off-by: Michel Thierry > Cc: Michal Wajdeczko > Cc: Chris Wilson Massaged the patch just ever so slightly and applied. Thanks for the patch and review, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use the engine name directly in the error_state file (rev3)
== Series Details == Series: drm/i915: Use the engine name directly in the error_state file (rev3) URL : https://patchwork.freedesktop.org/series/36215/ State : success == Summary == Series 36215v3 drm/i915: Use the engine name directly in the error_state file https://patchwork.freedesktop.org/api/1.0/series/36215/revisions/3/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: incomplete -> PASS (fi-bdw-5557u) fdo#104162 fdo#104162 https://bugs.freedesktop.org/show_bug.cgi?id=104162 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:419s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:427s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:371s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:489s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:281s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:483s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:484s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:465s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:450s fi-elk-e7500 total:224 pass:168 dwarn:10 dfail:0 fail:0 skip:45 fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:277s 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:390s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:400s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:409s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:459s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:414s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:460s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:502s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:452s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:499s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:582s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:430s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:512s 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:485s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:471s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:429s 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:395s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:576s fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:474s fi-skl-guc total:288 pass:214 dwarn:45 dfail:1 fail:0 skip:28 time:419s c742f2aed9f3a6bbd8de7f357eb11a6579de526a drm-tip: 2018y-01m-18d-17h-17m-33s UTC integration manifest 542fe01b9ef2 drm/i915: Use the engine name directly in the error_state file == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7714/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/10] drm/i915: Only signal from interrupt when requested
Quoting Tvrtko Ursulin (2018-01-17 12:22:33) > > On 15/01/2018 21:24, Chris Wilson wrote: > > Avoid calling dma_fence_signal() from inside the interrupt if we haven't > > enabled signaling on the request. > > > > Signed-off-by: Chris Wilson > > --- > > drivers/gpu/drm/i915/i915_gem_request.c | 2 +- > > drivers/gpu/drm/i915/i915_irq.c | 3 ++- > > drivers/gpu/drm/i915/intel_ringbuffer.h | 5 ++--- > > 3 files changed, 5 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_gem_request.c > > b/drivers/gpu/drm/i915/i915_gem_request.c > > index 08bbd56277e5..46848aef1648 100644 > > --- a/drivers/gpu/drm/i915/i915_gem_request.c > > +++ b/drivers/gpu/drm/i915/i915_gem_request.c > > @@ -1214,7 +1214,7 @@ long i915_wait_request(struct drm_i915_gem_request > > *req, > > if (flags & I915_WAIT_LOCKED) > > add_wait_queue(errq, &reset); > > > > - intel_wait_init(&wait, req); > > + intel_wait_init(&wait); > > > > restart: > > do { > > diff --git a/drivers/gpu/drm/i915/i915_irq.c > > b/drivers/gpu/drm/i915/i915_irq.c > > index e5f76d580010..ea290f102784 100644 > > --- a/drivers/gpu/drm/i915/i915_irq.c > > +++ b/drivers/gpu/drm/i915/i915_irq.c > > @@ -1093,7 +1093,8 @@ static void notify_ring(struct intel_engine_cs > > *engine) > > if (i915_seqno_passed(seqno, wait->seqno)) { > > struct drm_i915_gem_request *waiter = wait->request; > > > > - if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, > > + if (waiter && > > + !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, > > &waiter->fence.flags) && > > intel_wait_check_request(wait, waiter)) > > rq = i915_gem_request_get(waiter); > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h > > b/drivers/gpu/drm/i915/intel_ringbuffer.h > > index f406d0ff4612..cea2092d25d9 100644 > > --- a/drivers/gpu/drm/i915/intel_ringbuffer.h > > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h > > @@ -874,11 +874,10 @@ static inline u32 > > intel_hws_preempt_done_address(struct intel_engine_cs *engine) > > /* intel_breadcrumbs.c -- user interrupt bottom-half for waiters */ > > int intel_engine_init_breadcrumbs(struct intel_engine_cs *engine); > > > > -static inline void intel_wait_init(struct intel_wait *wait, > > -struct drm_i915_gem_request *rq) > > +static inline void intel_wait_init(struct intel_wait *wait) > > { > > wait->tsk = current; > > - wait->request = rq; > > + wait->request = NULL; > > Unless it is in this patch series, I can't see that this now leaves any > code path which sets wait->request? The signaler is now the only entity that sets up wait.request. > It's strange anyway - is this guarding against null ptr deref or what? Uninitialized pointer deref in the irq handler, yup. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/10] drm/i915: Reduce spinlock hold time during notify_ring() interrupt
Quoting Tvrtko Ursulin (2018-01-17 10:45:16) > > On 15/01/2018 21:24, Chris Wilson wrote: > > - if (wakeup) > > - wake_up_process(wait->tsk); > > + tsk = wait->tsk; > > + } else { > > + if (engine->irq_seqno_barrier && > > + i915_seqno_passed(seqno, wait->seqno - 1)) > > Hm what is this about? Why -1 on platforms with coherency issues and not > some other number? Needs a comment as minimum but still is a behaviour > change which I did not immediately figure out how it goes with the > commit message. If it is some additional optimization it needs to be > split out into a separate patch. It's a finger in the air statement that I don't expect to be more than one seqno behind in the interrupt-vs-breadcrumb race. So far I haven't been disappointed. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/10] drm/i915: Reduce spinlock hold time during notify_ring() interrupt
Quoting Tvrtko Ursulin (2018-01-17 10:45:16) > > On 15/01/2018 21:24, Chris Wilson wrote: > > By taking advantage of the RCU protection of the task struct, we can find > > the appropriate signaler under the spinlock and then release the spinlock > > before waking the task and signaling the fence. > > > > Signed-off-by: Chris Wilson > > --- > > drivers/gpu/drm/i915/i915_irq.c | 29 +++-- > > 1 file changed, 19 insertions(+), 10 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c > > b/drivers/gpu/drm/i915/i915_irq.c > > index 3517c6548e2c..0b272501b738 100644 > > --- a/drivers/gpu/drm/i915/i915_irq.c > > +++ b/drivers/gpu/drm/i915/i915_irq.c > > @@ -1065,21 +1065,24 @@ static void ironlake_rps_change_irq_handler(struct > > drm_i915_private *dev_priv) > > > > static void notify_ring(struct intel_engine_cs *engine) > > { > > + const u32 seqno = intel_engine_get_seqno(engine); > > struct drm_i915_gem_request *rq = NULL; > > + struct task_struct *tsk = NULL; > > struct intel_wait *wait; > > > > - if (!engine->breadcrumbs.irq_armed) > > + if (unlikely(!engine->breadcrumbs.irq_armed)) > > return; > > It isn't unlikely in GuC mode, just sayin'... Already taken care of, guc now "pins" the irq as opposed to arming it. So we should be able to equate irq_armed to mean "has waiters". -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Shrink the GEM kmem_caches upon idling
Quoting Tvrtko Ursulin (2018-01-17 10:18:38) > > On 16/01/2018 17:36, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-01-16 17:25:25) > >> > >> On 16/01/2018 15:21, Chris Wilson wrote: > >>> Quoting Tvrtko Ursulin (2018-01-16 15:12:43) > > On 16/01/2018 13:05, Chris Wilson wrote: > > + > > + if (!new_requests_since_last_retire(dev_priv)) { > > + __i915_gem_free_work(&dev_priv->mm.free_work); > >> > >> ... you wouldn't want to pull this up under the struct mutex section? It > >> would need a different flavour of a function to be called, and some > >> refactoring of the existing ones. > > > > "Some". I don't think that improves anything? > > > > The statement of intent to me is that we only throw away the caches and > > excess memory if and only if we are idle. The presumption is that under > > active conditions those caches are important, but if we are about to > > sleep for long periods of time, we should be proactive in releasing > > resources. > > > > I can hear you about to ask if we could add a timer and wake up in 10s to > > prove we were idle! > > No, pointless since this proposal already runs outside this guarantee, > and anyway, this was or the other there is potential to disrupt the next > client. > > How about sticking in a break on new_request_since_last_retire() into > __i915_gem_free_work()? Would that defeat the backlog cleaning? Maybe > conditional only when called from the idle handler? __i915_gem_free_work() is a distraction, since it is just clearing the backlog of freed objects and shouldn't be affecting the cache optimisations for the next/concurrent client. Let me try rearranging the flow here. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/guc: Change values for i915_guc_log_control
Quoting Chris Wilson (2018-01-18 17:21:57) > Quoting Sagar Arun Kamble (2018-01-12 05:53:28) > > > > > > On 1/11/2018 8:54 PM, Michal Wajdeczko wrote: > > > Today we have format mismatch between read/write operations > > > of i915_guc_log_control entry. For read we return (0, 1..4) > > > that represents disable/verbosity levels, but for write we > > > force user to follow internal structure format (0,1,9,11,13). > > 0x0, 0x1, 0x11, 0x21, 0x31 > > > Let's hide internals from the user and accept same values > > > as we support for read and related guc_log_level modparam. > > > > > > Signed-off-by: Michal Wajdeczko > > > Cc: Sagar Arun Kamble > > > Cc: Daniele Ceraolo Spurio > > > Cc: Tvrtko Ursulin > > > Cc: Joonas Lahtinen > > > Cc: Chris Wilson > > Reviewed-by: Sagar Arun Kamble > > Thanks for the patches and review, pushed. Oh darn it, 30.062893] == [ 30.062894] WARNING: possible circular locking dependency detected [ 30.062895] 4.15.0-rc8-CI-CI_DRM_3648+ #1 Tainted: G U [ 30.062896] -- [ 30.062897] debugfs_test/1268 is trying to acquire lock: [ 30.062898] (&dev->struct_mutex){+.+.}, at: [] i915_mutex_lock_interruptible+0x47/0x130 [i915] [ 30.062921] but task is already holding lock: [ 30.062921] (&mm->mmap_sem){}, at: [ ] __do_page_fault+0x106/0x560 [ 30.062924] which lock already depends on the new lock. [ 30.062925] the existing dependency chain (in reverse order) is: [ 30.062926] -> #3 (&mm->mmap_sem){}: [ 30.062930]_copy_to_user+0x1e/0x70 [ 30.062932]filldir+0x8c/0xf0 [ 30.062934]dcache_readdir+0xeb/0x160 [ 30.062935]iterate_dir+0xdc/0x140 [ 30.062936]SyS_getdents+0xa0/0x130 [ 30.062938]entry_SYSCALL_64_fastpath+0x22/0x8f [ 30.062939] -> #2 (&sb->s_type->i_mutex_key#3){}: [ 30.062942]start_creating+0x59/0x110 [ 30.062944]__debugfs_create_file+0x2e/0xe0 [ 30.062946]relay_create_buf_file+0x62/0x80 [ 30.062947]relay_late_setup_files+0x84/0x250 [ 30.062967]guc_log_late_setup+0x52/0x110 [i915] [ 30.062985]i915_guc_log_register+0x3a/0x60 [i915] [ 30.062997]i915_driver_load+0x7b6/0x1720 [i915] [ 30.063014]i915_pci_probe+0x2e/0x90 [i915] [ 30.063017]pci_device_probe+0x9c/0x120 [ 30.063018]driver_probe_device+0x2a3/0x480 [ 30.063020]__driver_attach+0xd9/0xe0 [ 30.063021]bus_for_each_dev+0x57/0x90 [ 30.063022]bus_add_driver+0x168/0x260 [ 30.063023]driver_register+0x52/0xc0 [ 30.063024]do_one_initcall+0x39/0x150 [ 30.063025]do_init_module+0x56/0x1ef [ 30.063026]load_module+0x231c/0x2d70 [ 30.063027]SyS_finit_module+0xa5/0xe0 [ 30.063028]do_syscall_64+0x59/0x1a0 [ 30.063030]return_from_SYSCALL_64+0x0/0x75 [ 30.063030] -> #1 (relay_channels_mutex){+.+.}: [ 30.063034]relay_open+0x12c/0x2b0 [ 30.063051]guc_log_runtime_create+0xa0/0x220 [i915] [ 30.063067]intel_guc_log_create+0xec/0x1c0 [i915] [ 30.063083]intel_guc_init+0x5d/0x100 [i915] [ 30.063100]intel_uc_init+0x29/0xa0 [i915] [ 30.063116]i915_gem_init+0x18a/0x540 [i915] [ 30.063128]i915_driver_load+0xaa9/0x1720 [i915] [ 30.063140]i915_pci_probe+0x2e/0x90 [i915] [ 30.063141]pci_device_probe+0x9c/0x120 [ 30.063143]driver_probe_device+0x2a3/0x480 [ 30.063144]__driver_attach+0xd9/0xe0 [ 30.063145]bus_for_each_dev+0x57/0x90 [ 30.063146]bus_add_driver+0x168/0x260 [ 30.063147]driver_register+0x52/0xc0 [ 30.063148]do_one_initcall+0x39/0x150 [ 30.063149]do_init_module+0x56/0x1ef [ 30.063150]load_module+0x231c/0x2d70 [ 30.063151]SyS_finit_module+0xa5/0xe0 [ 30.063152]do_syscall_64+0x59/0x1a0 [ 30.063153]return_from_SYSCALL_64+0x0/0x75 [ 30.063154] -> #0 (&dev->struct_mutex){+.+.}: [ 30.063156]__mutex_lock+0x81/0x9b0 [ 30.063172]i915_mutex_lock_interruptible+0x47/0x130 [i915] [ 30.063187]i915_gem_fault+0x201/0x790 [i915] [ 30.063190]__do_fault+0x15/0x70 [ 30.063191]__handle_mm_fault+0x677/0xdc0 [ 30.063193]handle_mm_fault+0x14f/0x2f0 [ 30.063194]__do_page_fault+0x2d1/0x560 [ 30.063195]page_fault+0x4c/0x60 [ 30.063196] other info that might help us debug this: [ 30.063197] Chain exists of: &dev->struct_mutex --> &sb->s_type->i_mutex_key#3 --> &mm->mmap_sem [ 30.063200] Possible unsafe locking scenario: [ 30.063201]CPU0CPU1 [ 30.063201]
[Intel-gfx] [CI] drm/i915: Use the engine name directly in the error_state file
From: Michel Thierry Instead of using local string names that we will have to keep maintaining, use the engine->name directly. v2: Better invalid engine_id handling, capture_bo will not be able know the engine_id and end up with -1 (Michal). Suggested-by: Michal Wajdeczko Signed-off-by: Michel Thierry Cc: Michal Wajdeczko Cc: Chris Wilson Reviewed-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20180110012151.28261-1-michel.thie...@intel.com [ickle: minor massaging of function names] Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gpu_error.c | 36 ++- 1 file changed, 23 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c index 06577574296b..a81351d9e3a6 100644 --- a/drivers/gpu/drm/i915/i915_gpu_error.c +++ b/drivers/gpu/drm/i915/i915_gpu_error.c @@ -34,16 +34,25 @@ #include "i915_drv.h" -static const char *engine_str(int engine) -{ - switch (engine) { - case RCS: return "render"; - case VCS: return "bsd"; - case BCS: return "blt"; - case VECS: return "vebox"; - case VCS2: return "bsd2"; - default: return ""; - } +static inline const struct intel_engine_cs * +engine_lookup(const struct drm_i915_private *i915, unsigned int id) +{ + if (id >= I915_NUM_ENGINES) + return NULL; + + return i915->engine[id]; +} + +static inline const char * +__engine_name(const struct intel_engine_cs *engine) +{ + return engine ? engine->name : ""; +} + +static const char * +engine_name(const struct drm_i915_private *i915, unsigned int id) +{ + return __engine_name(engine_lookup(i915, id)); } static const char *tiling_flag(int tiling) @@ -345,7 +354,7 @@ static void print_error_buffers(struct drm_i915_error_state_buf *m, err_puts(m, purgeable_flag(err->purgeable)); err_puts(m, err->userptr ? " userptr" : ""); err_puts(m, err->engine != -1 ? " " : ""); - err_puts(m, engine_str(err->engine)); + err_puts(m, engine_name(m->i915, err->engine)); err_puts(m, i915_cache_level_str(m->i915, err->cache_level)); if (err->name) @@ -415,7 +424,8 @@ static void error_print_engine(struct drm_i915_error_state_buf *m, { int n; - err_printf(m, "%s command stream:\n", engine_str(ee->engine_id)); + err_printf(m, "%s command stream:\n", + engine_name(m->i915, ee->engine_id)); err_printf(m, " IDLE?: %s\n", yesno(ee->idle)); err_printf(m, " START: 0x%08x\n", ee->start); err_printf(m, " HEAD: 0x%08x [0x%08x]\n", ee->head, ee->rq_head); @@ -635,7 +645,7 @@ int i915_error_state_to_str(struct drm_i915_error_state_buf *m, if (error->engine[i].hangcheck_stalled && error->engine[i].context.pid) { err_printf(m, "Active process (on ring %s): %s [%d], score %d\n", - engine_str(i), + engine_name(m->i915, i), error->engine[i].context.comm, error->engine[i].context.pid, error->engine[i].context.ban_score); -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 20/99] ida: Convert to XArray
Hi Matthew! On 01/17/2018 09:20 PM, Matthew Wilcox wrote: > Use the xarray infrstructure like we used the radix tree infrastructure. > This lets us get rid of idr_get_free() from the radix tree code. There's a typo: infrstructure => infratructure Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] intel: Future-proof ring names for aubinator_error_decode
Quoting Michel Thierry (2018-01-18 16:44:18) > On 1/17/2018 7:47 AM, Chris Wilson wrote: > > The kernel is moving to a $class$instance naming scheme in preparation > > for accommodating more rings in the future in a consistent manner. It is > > already using the naming scheme internally, and now we are looking at > > updating some soft-ABI such as the error state to use the new naming > > scheme. This of course means we need to teach aubinator_error_decode how > > to map both sets of ring names onto its register maps. > > > > Signed-off-by: Chris Wilson > > Cc: Michel Thierry > > Cc: Michal Wajdeczko > > Cc: Tvrtko Ursulin > > Cc: Lionel Landwerlin > > Cc: Kenneth Graunke > > --- > > src/intel/tools/aubinator_error_decode.c | 122 > > +-- > > 1 file changed, 98 insertions(+), 24 deletions(-) > > > > diff --git a/src/intel/tools/aubinator_error_decode.c > > b/src/intel/tools/aubinator_error_decode.c > > index 9dd70790e1..01c6a7a365 100644 > > --- a/src/intel/tools/aubinator_error_decode.c > > +++ b/src/intel/tools/aubinator_error_decode.c > > @@ -74,40 +74,95 @@ print_register(struct gen_spec *spec, const char *name, > > uint32_t reg) > > } > > > > struct ring_register_mapping { > > - const char *ring_name; > > + unsigned ring_class; > > + unsigned ring_instance; > > const char *register_name; > > }; > > > > +enum { > > + RCS, > > + BCS, > > + VCS, > > + VECS, > > +}; > > + > > static const struct ring_register_mapping acthd_registers[] = { > > - { "blt", "BCS_ACTHD_UDW" }, > > - { "bsd", "VCS_ACTHD_UDW" }, > > - { "bsd2", "VCS2_ACTHD_UDW" }, > > - { "render", "ACTHD_UDW" }, > > - { "vebox", "VECS_ACTHD_UDW" }, > > + { BCS, 0, "BCS_ACTHD_UDW" }, > > + { VCS, 0, "VCS_ACTHD_UDW" }, > > + { VCS, 1, "VCS2_ACTHD_UDW" }, > > + { RCS, 0, "ACTHD_UDW" }, > > + { VECS, 0, "VECS_ACTHD_UDW" }, > > }; > > > > static const struct ring_register_mapping ctl_registers[] = { > > - { "blt", "BCS_RING_BUFFER_CTL" }, > > - { "bsd", "VCS_RING_BUFFER_CTL" }, > > - { "bsd2", "VCS2_RING_BUFFER_CTL" }, > > - { "render", "RCS_RING_BUFFER_CTL" }, > > - { "vebox", "VECS_RING_BUFFER_CTL" }, > > + { BCS, 0, "BCS_RING_BUFFER_CTL" }, > > + { VCS, 0, "VCS_RING_BUFFER_CTL" }, > > + { VCS, 1, "VCS2_RING_BUFFER_CTL" }, > > + { RCS, 0, "RCS_RING_BUFFER_CTL" }, > > + { VECS, 0, "VECS_RING_BUFFER_CTL" }, > > }; > > > > static const struct ring_register_mapping fault_registers[] = { > > - { "blt", "BCS_FAULT_REG" }, > > - { "bsd", "VCS_FAULT_REG" }, > > - { "render", "RCS_FAULT_REG" }, > > - { "vebox", "VECS_FAULT_REG" }, > > + { BCS, 0, "BCS_FAULT_REG" }, > > + { VCS, 0, "VCS_FAULT_REG" }, > > + { RCS, 0, "RCS_FAULT_REG" }, > > + { VECS, 0, "VECS_FAULT_REG" }, > > }; > > > > +static int ring_name_to_class(const char *ring_name, > > + unsigned int *class) > > +{ > > + static const char *class_names[] = { > > + [RCS] = "rcs", > > + [BCS] = "bcs", > > + [VCS] = "vcs", > > + [VECS] = "vecs", > > + }; > > This will match the new names in the error state, e.g. > > rcs0 command stream: > ... > bcs0 command stream: > ... > vcs0 command stream: > ... > vcs1 command stream: > ... > vecs0 command stream: > ... > > > + for (size_t i = 0; i < ARRAY_SIZE(class_names); i++) { > > + if (strcmp(ring_name, class_names[i])) > > + continue; > > + > > + *class = i; > > + return atoi(ring_name + strlen(class_names[i])); > > + } > > + > > + static const struct { > > + const char *name; > > + unsigned int class; > > + int instance; > > + } legacy_names[] = { > > + { "render", RCS, 0 }, > > + { "blt", BCS, 0 }, > > + { "bsd", VCS, 0 }, > > + { "bsd2", VCS, 1 }, > > + { "vebox", VECS, 0 }, > > + }; > > And these are the current ones, so also > > Reviewed-by: Michel Thierry Thanks for sanity checking my string handling, pushed. We should be ready now to use the new naming scheme in the error state, I believe. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/guc: Change values for i915_guc_log_control
Quoting Sagar Arun Kamble (2018-01-12 05:53:28) > > > On 1/11/2018 8:54 PM, Michal Wajdeczko wrote: > > Today we have format mismatch between read/write operations > > of i915_guc_log_control entry. For read we return (0, 1..4) > > that represents disable/verbosity levels, but for write we > > force user to follow internal structure format (0,1,9,11,13). > 0x0, 0x1, 0x11, 0x21, 0x31 > > Let's hide internals from the user and accept same values > > as we support for read and related guc_log_level modparam. > > > > Signed-off-by: Michal Wajdeczko > > Cc: Sagar Arun Kamble > > Cc: Daniele Ceraolo Spurio > > Cc: Tvrtko Ursulin > > Cc: Joonas Lahtinen > > Cc: Chris Wilson > Reviewed-by: Sagar Arun Kamble Thanks for the patches and review, pushed. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Avoid waitboosting on the active request (rev3)
Quoting Patchwork (2018-01-18 16:56:55) > == Series Details == > > Series: drm/i915: Avoid waitboosting on the active request (rev3) > URL : https://patchwork.freedesktop.org/series/36453/ > State : success > > == Summary == > > Test kms_frontbuffer_tracking: > Subgroup fbc-1p-offscren-pri-shrfb-draw-blt: > pass -> FAIL (shard-snb) fdo#101623 +1 > Test kms_flip: > Subgroup vblank-vs-modeset-suspend-interruptible: > pass -> SKIP (shard-hsw) fdo#103540 > Subgroup plain-flip-ts-check: > fail -> PASS (shard-hsw) fdo#100368 Added Joonas' r-b from earlier, and pushed. Thanks all, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next-fixes
Hi Dave, A few fixes for 4.16. Please pull. Thanks. drm-misc-next-fixes-2018-01-18: Fixes for 4.16: Fixes one Kconfig issue and a enable some panels to work properly. There is also a fix of error code return in sun4i. The following changes since commit a1c55bccf6004ec9fbcf892328f9658767aa22bb: drm/panel: lvds: Add support for the power-supply property (2018-01-05 10:00:14 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2018-01-18 for you to fetch changes up to 341a0ffceaa44660c43d219a3b2569ebbd7d3ad1: drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig (2018-01-17 10:10:18 +0100) Fixes for 4.16: Fixes one Kconfig issue and a enable some panels to work properly. There is also a fix of error code return in sun4i. Dan Carpenter (1): drm/sun4i: Fix error code in sun4i_tcon_bind() Hans de Goede (1): drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig Maxime Ripard (1): drm/panel: lvds: Handle the optional regulator case properly drivers/gpu/drm/Kconfig| 8 drivers/gpu/drm/panel/panel-lvds.c | 11 +-- drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 +- 3 files changed, 14 insertions(+), 7 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 00/99] XArray version 6
On Thu, Jan 18, 2018 at 05:56:12PM +0100, David Sterba wrote: > On Thu, Jan 18, 2018 at 08:48:43AM -0800, Matthew Wilcox wrote: > > Thank you! I shall attempt to debug. Was this with a btrfs root > > filesystem? I'm most suspicious of those patches right now, since they've > > received next to no testing. I'm going to put together a smaller patchset > > which just does the page cache conversion and nothing else in the hope > > that we can get that merged this year. > > No, the root is ext3 and there was no btrfs filesytem mounted at the > time. Found it; I was missing a prerequisite patch. New (smaller) patch series coming soon. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Fix compilation of intel_dp_hdcp_check_link
On Thu, Jan 18, 2018 at 04:10:25PM +, Chris Wilson wrote: > drivers/gpu/drm/i915/intel_dp.c: In function ‘intel_dp_hdcp_check_link’: > drivers/gpu/drm/i915/intel_dp.c:5191:26: error: ?: using integer constants in > boolean context [-Werror=int-in-bool-context] >return ret >= 0 ? -EIO : ret; > > Fixes: 20f24d776d1b ("drm/i915: Implement HDCP for DisplayPort") > Signed-off-by: Chris Wilson Thanks for the patch! Applied to the topic branch. Sean > Cc: Daniel Vetter > Cc: Ramalingam C > Cc: Sean Paul > Cc: Jani Nikula > --- > drivers/gpu/drm/i915/intel_dp.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 68229f53d5b8..0f2290c7bede 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -5184,12 +5184,14 @@ bool intel_dp_hdcp_check_link(struct > intel_digital_port *intel_dig_port) > { > ssize_t ret; > u8 bstatus; > + > ret = drm_dp_dpcd_read(&intel_dig_port->dp.aux, DP_AUX_HDCP_BSTATUS, > &bstatus, 1); > if (ret != 1) { > DRM_ERROR("Read bstatus from DP/AUX failed (%zd)\n", ret); > - return ret >= 0 ? -EIO : ret; > + return false; > } > + > return !(bstatus & (DP_BSTATUS_LINK_FAILURE | DP_BSTATUS_REAUTH_REQ)); > } > > -- > 2.15.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Sean Paul, Software Engineer, Google / Chromium OS ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 00/99] XArray version 6
On Thu, Jan 18, 2018 at 08:48:43AM -0800, Matthew Wilcox wrote: > Thank you! I shall attempt to debug. Was this with a btrfs root > filesystem? I'm most suspicious of those patches right now, since they've > received next to no testing. I'm going to put together a smaller patchset > which just does the page cache conversion and nothing else in the hope > that we can get that merged this year. No, the root is ext3 and there was no btrfs filesytem mounted at the time. ___ 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: Avoid waitboosting on the active request (rev3)
== Series Details == Series: drm/i915: Avoid waitboosting on the active request (rev3) URL : https://patchwork.freedesktop.org/series/36453/ State : success == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-blt: pass -> FAIL (shard-snb) fdo#101623 +1 Test kms_flip: Subgroup vblank-vs-modeset-suspend-interruptible: pass -> SKIP (shard-hsw) fdo#103540 Subgroup plain-flip-ts-check: fail -> PASS (shard-hsw) fdo#100368 fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 shard-hswtotal:2753 pass:1725 dwarn:1 dfail:0 fail:10 skip:1016 time:15283s shard-snbtotal:2753 pass:1318 dwarn:1 dfail:0 fail:11 skip:1423 time:7925s Blacklisted hosts: shard-apltotal:2753 pass:1716 dwarn:1 dfail:0 fail:21 skip:1015 time:14045s shard-kbltotal:2745 pass:1830 dwarn:1 dfail:0 fail:22 skip:891 time:10410s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7708/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 00/99] XArray version 6
On Thu, Jan 18, 2018 at 05:07:50PM +0100, David Sterba wrote: > On Wed, Jan 17, 2018 at 12:20:24PM -0800, Matthew Wilcox wrote: > > From: Matthew Wilcox > > > > This version of the XArray has no known bugs. > > I've booted this patchset on 2 boxes, both had random problems during > boot. On one I was not able to diagnose what went wrong. On the other > one the system booted up to userspace and failed to set up networking. > Serial console worked and the network service complained about wrong > format of /usr/share/wicked/schema/team.xml . That's supposed to be a > text file, though hexdump showed me lots of zeros. Trimmed output: > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > (similar output here) > * > 0a10 00 00 00 00 00 00 00 00 11 03 00 00 00 00 00 00 || > 0a20 20 8b 7f 01 00 00 00 00 a0 84 7d 01 00 00 00 00 | .}.| > 0a30 00 00 00 00 00 00 00 00 10 89 7f 01 00 00 00 00 || > 0a40 a0 84 7d 01 00 00 00 00 00 00 00 00 00 00 00 00 |..}.| > 0a50 80 8a 7f 01 00 00 00 00 e0 cf 7d 01 00 00 00 00 |..}.| > 0a60 00 00 00 00 00 00 00 00 60 8a 7f 01 00 00 00 00 |`...| > 0a70 a0 84 7d 01 00 00 00 00 00 00 00 00 00 00 00 00 |..}.| > 0a80 30 89 7f 01 00 00 00 00 a0 84 7d 01 00 00 00 00 |0.}.| > 0a90 00 00 00 00 00 00 00 00 60 f2 7f 01 00 00 00 00 |`...| > 0aa0 40 fd 7e 01 00 00 00 00 00 00 00 00 00 00 00 00 |@.~.| > 0ab0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 1000 3e 0a 20 20 3c 2f 6d 65 74 68 6f 64 3e 0a 3c 2f |>. . 1010 73 65 72 76 69 63 65 3e 0a |service>.| > > There's something at the end of the file that does look like a xml fragment. > The file size is 4121. This looks to me like exactly the first page of the > file > was not read correctly. > > The xml file is supposed to be read-only during startup, so there was no write > in flight. 'rpm -Vv' reported only this file corrupted. Booting to other > kernels was fine, network up, and the file was ok again. So the > corruption happened only in memory, which leads me to conclusion that > there is an unknown bug in your patchset. Thank you! I shall attempt to debug. Was this with a btrfs root filesystem? I'm most suspicious of those patches right now, since they've received next to no testing. I'm going to put together a smaller patchset which just does the page cache conversion and nothing else in the hope that we can get that merged this year. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] intel: Future-proof ring names for aubinator_error_decode
On 1/17/2018 7:47 AM, Chris Wilson wrote: The kernel is moving to a $class$instance naming scheme in preparation for accommodating more rings in the future in a consistent manner. It is already using the naming scheme internally, and now we are looking at updating some soft-ABI such as the error state to use the new naming scheme. This of course means we need to teach aubinator_error_decode how to map both sets of ring names onto its register maps. Signed-off-by: Chris Wilson Cc: Michel Thierry Cc: Michal Wajdeczko Cc: Tvrtko Ursulin Cc: Lionel Landwerlin Cc: Kenneth Graunke --- src/intel/tools/aubinator_error_decode.c | 122 +-- 1 file changed, 98 insertions(+), 24 deletions(-) diff --git a/src/intel/tools/aubinator_error_decode.c b/src/intel/tools/aubinator_error_decode.c index 9dd70790e1..01c6a7a365 100644 --- a/src/intel/tools/aubinator_error_decode.c +++ b/src/intel/tools/aubinator_error_decode.c @@ -74,40 +74,95 @@ print_register(struct gen_spec *spec, const char *name, uint32_t reg) } struct ring_register_mapping { - const char *ring_name; + unsigned ring_class; + unsigned ring_instance; const char *register_name; }; +enum { + RCS, + BCS, + VCS, + VECS, +}; + static const struct ring_register_mapping acthd_registers[] = { - { "blt", "BCS_ACTHD_UDW" }, - { "bsd", "VCS_ACTHD_UDW" }, - { "bsd2", "VCS2_ACTHD_UDW" }, - { "render", "ACTHD_UDW" }, - { "vebox", "VECS_ACTHD_UDW" }, + { BCS, 0, "BCS_ACTHD_UDW" }, + { VCS, 0, "VCS_ACTHD_UDW" }, + { VCS, 1, "VCS2_ACTHD_UDW" }, + { RCS, 0, "ACTHD_UDW" }, + { VECS, 0, "VECS_ACTHD_UDW" }, }; static const struct ring_register_mapping ctl_registers[] = { - { "blt", "BCS_RING_BUFFER_CTL" }, - { "bsd", "VCS_RING_BUFFER_CTL" }, - { "bsd2", "VCS2_RING_BUFFER_CTL" }, - { "render", "RCS_RING_BUFFER_CTL" }, - { "vebox", "VECS_RING_BUFFER_CTL" }, + { BCS, 0, "BCS_RING_BUFFER_CTL" }, + { VCS, 0, "VCS_RING_BUFFER_CTL" }, + { VCS, 1, "VCS2_RING_BUFFER_CTL" }, + { RCS, 0, "RCS_RING_BUFFER_CTL" }, + { VECS, 0, "VECS_RING_BUFFER_CTL" }, }; static const struct ring_register_mapping fault_registers[] = { - { "blt", "BCS_FAULT_REG" }, - { "bsd", "VCS_FAULT_REG" }, - { "render", "RCS_FAULT_REG" }, - { "vebox", "VECS_FAULT_REG" }, + { BCS, 0, "BCS_FAULT_REG" }, + { VCS, 0, "VCS_FAULT_REG" }, + { RCS, 0, "RCS_FAULT_REG" }, + { VECS, 0, "VECS_FAULT_REG" }, }; +static int ring_name_to_class(const char *ring_name, + unsigned int *class) +{ + static const char *class_names[] = { + [RCS] = "rcs", + [BCS] = "bcs", + [VCS] = "vcs", + [VECS] = "vecs", + }; This will match the new names in the error state, e.g. rcs0 command stream: ... bcs0 command stream: ... vcs0 command stream: ... vcs1 command stream: ... vecs0 command stream: ... + for (size_t i = 0; i < ARRAY_SIZE(class_names); i++) { + if (strcmp(ring_name, class_names[i])) + continue; + + *class = i; + return atoi(ring_name + strlen(class_names[i])); + } + + static const struct { + const char *name; + unsigned int class; + int instance; + } legacy_names[] = { + { "render", RCS, 0 }, + { "blt", BCS, 0 }, + { "bsd", VCS, 0 }, + { "bsd2", VCS, 1 }, + { "vebox", VECS, 0 }, + }; And these are the current ones, so also Reviewed-by: Michel Thierry + for (size_t i = 0; i < ARRAY_SIZE(legacy_names); i++) { + if (strcmp(ring_name, legacy_names[i].name)) + continue; + + *class = legacy_names[i].class; + return legacy_names[i].instance; + } + + return -1; +} + static const char * register_name_from_ring(const struct ring_register_mapping *mapping, unsigned nb_mapping, const char *ring_name) { + unsigned int class; + int instance; + + instance = ring_name_to_class(ring_name, &class); + if (instance < 0) + return NULL; + for (unsigned i = 0; i < nb_mapping; i++) { - if (strcmp(mapping[i].ring_name, ring_name) == 0) + if (mapping[i].ring_class == class && + mapping[i].ring_instance == instance) return mapping[i].register_name; } return NULL; @@ -117,16 +172,35 @@ static const char * instdone_register_for_ring(const struct gen_device_info *devinfo, const char *ring_name) { - if (strcmp(ring_name, "blt") == 0) - return "BCS_INSTDONE"; - else if (strcmp(ring_name, "vebox") == 0) - return "VECS_INSTDONE"; - else if (strcmp(ring_name, "bsd") == 0) - return "VCS_INSTDONE"; - else if (strcmp(ring_name, "render") == 0) { + unsigned int class; + int instance; + + instance = ring_name_to_class(ring_name, &class); + if (instance < 0) + return NULL; + + switch (class) { + case RCS: if (devinfo->gen == 6) return "INSTDONE_2"; - return "IN
Re: [Intel-gfx] [PATCH] drm/i915: vbt defs typo fixes
On Thu, 2018-01-18 at 17:06 +0200, Jani Nikula wrote: > No more sing-a-ling. > > Reported-by: Adam Jackson Why'd you omit the typos I reported in tools/intel_vbt_decode.c ? - ajax ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bios: add DP max link rate to VBT child device struct (rev2)
== Series Details == Series: drm/i915/bios: add DP max link rate to VBT child device struct (rev2) URL : https://patchwork.freedesktop.org/series/36701/ State : success == Summary == Series 36701v2 drm/i915/bios: add DP max link rate to VBT child device struct https://patchwork.freedesktop.org/api/1.0/series/36701/revisions/2/mbox/ Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989 Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 Test kms_chamelium: Subgroup dp-crc-fast: dmesg-fail -> PASS (fi-kbl-7500u) fdo#103841 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 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:420s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:429s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:373s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:483s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:281s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:485s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:490s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:465s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:466s fi-elk-e7500 total:224 pass:168 dwarn:9 dfail:1 fail:0 skip:45 fi-gdg-551 total:288 pass:180 dwarn:0 dfail:0 fail:0 skip:108 time:277s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:511s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:398s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:399s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:411s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:456s 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:462s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:501s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:454s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:500s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:588s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:428s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:507s 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:487s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:476s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:432s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:525s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:398s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:576s fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:469s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:420s 2c42c3d90f29dc7e0914c7b4498f4da93f0e5ac8 drm-tip: 2018y-01m-18d-15h-19m-38s UTC integration manifest ee2e24cadbf7 drm/i915/bios: add DP max link rate to VBT child device struct == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7712/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 7/7] drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON
Regards Shashank On 1/18/2018 3:00 PM, Maarten Lankhorst wrote: Op 18-01-18 om 07:27 schreef Sharma, Shashank: Regards Shashank On 1/17/2018 11:57 PM, Ville Syrjälä wrote: On Fri, Jan 05, 2018 at 03:15:35PM +0530, Shashank Sharma wrote: LSPCON chips can generate YCBCR outputs, if asked nicely :). In order to generate YCBCR 4:2:0 outputs, a source must: - send YCBCR 4:4:4 signals to LSPCON - program color space as 4:2:0 in AVI infoframes Whereas for YCBCR 4:4:4 outputs, the source must: - send YCBCR 4:4:4 signals to LSPCON - program color space as 4:4:4 in AVI infoframes So for both 4:2:0 as well as 4:4:4 outputs, we are driving the pipe for YCBCR 4:4:4 output, but AVI infoframe's color space information indicates LSPCON FW to start scaling down from YCBCR 4:4:4 and generate YCBCR 4:2:0 output. As the scaling is done by LSPCON device, we need not to reserve a scaler for 4:2:0 outputs. V2: rebase V3: Addressed review comments from Ville - add enum crtc_output_format instead of bool ycbcr420 - use crtc_output_format=4:4:4 for modeset of LSPCON 4:2:0 output cases in this way we will have YCBCR 4:4:4 framework ready (except the ABI part) Cc: Ville Syrjala Cc: Maarten Lankhorst Signed-off-by: Shashank Sharma --- drivers/gpu/drm/i915/i915_reg.h | 2 ++ drivers/gpu/drm/i915/intel_ddi.c| 7 +++ drivers/gpu/drm/i915/intel_dp.c | 10 ++ drivers/gpu/drm/i915/intel_drv.h| 2 ++ drivers/gpu/drm/i915/intel_lspcon.c | 28 5 files changed, 49 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 966e4df..45ee264 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -8547,6 +8547,8 @@ enum skl_power_gate { #define TRANS_MSA_MISC(tran) _MMIO_TRANS2(tran, _TRANSA_MSA_MISC) #define TRANS_MSA_SYNC_CLK(1<<0) +#define TRANS_MSA_SAMPLING_444(2<<1) +#define TRANS_MSA_CLRSP_YCBCR(2<<3) #define TRANS_MSA_6_BPC(0<<5) #define TRANS_MSA_8_BPC(1<<5) #define TRANS_MSA_10_BPC(2<<5) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index 7b89f2a..7616f6f 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -1499,6 +1499,13 @@ void intel_ddi_set_pipe_settings(const struct intel_crtc_state *crtc_state) break; } +/* + * As per DP 1.2 spec section 2.3.4.3 while sending + * YCBCR 444 signals we should program MSA MISC1/0 fields with + * colorspace information. + */ +if (crtc_state->output_format == CRTC_OUTPUT_YCBCR444) +temp |= TRANS_MSA_SAMPLING_444 | TRANS_MSA_CLRSP_YCBCR; This fails to state that we're indicating BT.601 encoding. I think we should spell that out explicitly. Agree, I will add this in comments. I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp); } diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 35c5299..3bf82ea 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1613,6 +1613,7 @@ intel_dp_compute_config(struct intel_encoder *encoder, struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); struct drm_display_mode *adjusted_mode = &pipe_config->base.adjusted_mode; struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base); +struct intel_lspcon *lspcon = enc_to_intel_lspcon(&encoder->base); enum port port = encoder->port; struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc); struct intel_connector *intel_connector = intel_dp->attached_connector; @@ -1642,6 +1643,15 @@ intel_dp_compute_config(struct intel_encoder *encoder, if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv) && port != PORT_A) pipe_config->has_pch_encoder = true; +if (lspcon->active) { +struct drm_connector *connector = &intel_connector->base; + +if (lspcon_ycbcr420_config(connector, pipe_config)) { +pipe_config->output_format = CRTC_OUTPUT_YCBCR444; I think I'd like to see all compute_config hooks explicitly set the outout_format (to RGB usually obviously). That's the one I was talking about in previous patch. If we keep output_format_RGB = 0, we need not to do this, as reset of the pipe_config will automatically make it RGB. +lspcon->output_format = CRTC_OUTPUT_YCBCR420; You should not modify any non-atomic state like that in compute_config. Please help me to understand this better, Can you elaborate a bit more on: - Why is this a non-atomic state ? Because lspcon->output_format is modified even if a commit is TEST_ONLY.. This will break if you do a nonblocking modeset vs TEST_ONLY, it could commit the wrong lspcon->output_format. :) - What is the right place we should modify it ? intel_digital_connector_state probably. ~Maarten Thanks for the explan
[Intel-gfx] [PATCH] drm/i915/dp: Fix compilation of intel_dp_hdcp_check_link
drivers/gpu/drm/i915/intel_dp.c: In function ‘intel_dp_hdcp_check_link’: drivers/gpu/drm/i915/intel_dp.c:5191:26: error: ?: using integer constants in boolean context [-Werror=int-in-bool-context] return ret >= 0 ? -EIO : ret; Fixes: 20f24d776d1b ("drm/i915: Implement HDCP for DisplayPort") Signed-off-by: Chris Wilson Cc: Daniel Vetter Cc: Ramalingam C Cc: Sean Paul Cc: Jani Nikula --- drivers/gpu/drm/i915/intel_dp.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 68229f53d5b8..0f2290c7bede 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -5184,12 +5184,14 @@ bool intel_dp_hdcp_check_link(struct intel_digital_port *intel_dig_port) { ssize_t ret; u8 bstatus; + ret = drm_dp_dpcd_read(&intel_dig_port->dp.aux, DP_AUX_HDCP_BSTATUS, &bstatus, 1); if (ret != 1) { DRM_ERROR("Read bstatus from DP/AUX failed (%zd)\n", ret); - return ret >= 0 ? -EIO : ret; + return false; } + return !(bstatus & (DP_BSTATUS_LINK_FAILURE | DP_BSTATUS_REAUTH_REQ)); } -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 00/99] XArray version 6
On Wed, Jan 17, 2018 at 12:20:24PM -0800, Matthew Wilcox wrote: > From: Matthew Wilcox > > This version of the XArray has no known bugs. I've booted this patchset on 2 boxes, both had random problems during boot. On one I was not able to diagnose what went wrong. On the other one the system booted up to userspace and failed to set up networking. Serial console worked and the network service complained about wrong format of /usr/share/wicked/schema/team.xml . That's supposed to be a text file, though hexdump showed me lots of zeros. Trimmed output: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * (similar output here) * 0a10 00 00 00 00 00 00 00 00 11 03 00 00 00 00 00 00 || 0a20 20 8b 7f 01 00 00 00 00 a0 84 7d 01 00 00 00 00 | .}.| 0a30 00 00 00 00 00 00 00 00 10 89 7f 01 00 00 00 00 || 0a40 a0 84 7d 01 00 00 00 00 00 00 00 00 00 00 00 00 |..}.| 0a50 80 8a 7f 01 00 00 00 00 e0 cf 7d 01 00 00 00 00 |..}.| 0a60 00 00 00 00 00 00 00 00 60 8a 7f 01 00 00 00 00 |`...| 0a70 a0 84 7d 01 00 00 00 00 00 00 00 00 00 00 00 00 |..}.| 0a80 30 89 7f 01 00 00 00 00 a0 84 7d 01 00 00 00 00 |0.}.| 0a90 00 00 00 00 00 00 00 00 60 f2 7f 01 00 00 00 00 |`...| 0aa0 40 fd 7e 01 00 00 00 00 00 00 00 00 00 00 00 00 |@.~.| 0ab0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 1000 3e 0a 20 20 3c 2f 6d 65 74 68 6f 64 3e 0a 3c 2f |>. ..| There's something at the end of the file that does look like a xml fragment. The file size is 4121. This looks to me like exactly the first page of the file was not read correctly. The xml file is supposed to be read-only during startup, so there was no write in flight. 'rpm -Vv' reported only this file corrupted. Booting to other kernels was fine, network up, and the file was ok again. So the corruption happened only in memory, which leads me to conclusion that there is an unknown bug in your patchset. ___ 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: vbt defs typo fixes
== Series Details == Series: drm/i915: vbt defs typo fixes URL : https://patchwork.freedesktop.org/series/36702/ State : success == Summary == Series 36702v1 drm/i915: vbt defs typo fixes https://patchwork.freedesktop.org/api/1.0/series/36702/revisions/1/mbox/ Test kms_chamelium: Subgroup dp-crc-fast: dmesg-fail -> PASS (fi-kbl-7500u) fdo#103841 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:418s 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:374s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:486s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:281s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:486s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:484s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:464s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:462s fi-elk-e7500 total:224 pass:168 dwarn:10 dfail:0 fail:0 skip:45 fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:277s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:507s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:390s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:400s 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:459s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:423s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:459s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:499s 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:502s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:586s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:426s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:517s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:527s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:485s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:494s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:431s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:526s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:396s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:565s fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:470s fi-skl-guc total:288 pass:259 dwarn:0 dfail:0 fail:1 skip:28 time:418s 2c42c3d90f29dc7e0914c7b4498f4da93f0e5ac8 drm-tip: 2018y-01m-18d-15h-19m-38s UTC integration manifest ce05759810f7 drm/i915: vbt defs typo fixes == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7711/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 6/6] drm/i915: expose rcs topology through query uAPI
On 18/01/18 15:36, Chris Wilson wrote: Quoting Lionel Landwerlin (2018-01-18 15:22:27) On 18/01/18 15:18, Chris Wilson wrote: Quoting Lionel Landwerlin (2018-01-18 14:45:31) +static int query_slice_info(struct drm_i915_private *dev_priv, + struct drm_i915_query_item *query_item) +{ + const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu; + struct drm_i915_query_slice_info slice_info; + + if (query_item->flags != 0) + return -EINVAL; + + if (sseu->max_slices == 0) + return -ENODEV; So conclusion was to cancel all queries and not report a 0-length result for unsupported? :) -Chris Looking at GETPARAM, some queries return ENODEV if not supported (look at SLICE_MASK, so did the same here). Error are now reported in the s32 length field of the query item. Unless you've screwed up the pointer to the items, in which case you'll get an error through the ioctl() return value. Does that sounds sensible? It does, my fault for overlooking you had made the change. And even added it to the ioctl comments, making me look twice as bad ;) -Chris One could hope that one day we have better tools than emails to review changes :) Cheers, - Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 7/7] drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON
Regards Shashank On 1/18/2018 9:05 PM, Ville Syrjälä wrote: On Thu, Jan 18, 2018 at 09:00:50PM +0530, Sharma, Shashank wrote: Regards Shashank On 1/18/2018 7:33 PM, Ville Syrjälä wrote: On Thu, Jan 18, 2018 at 11:57:09AM +0530, Sharma, Shashank wrote: Regards Shashank On 1/17/2018 11:57 PM, Ville Syrjälä wrote: On Fri, Jan 05, 2018 at 03:15:35PM +0530, Shashank Sharma wrote: LSPCON chips can generate YCBCR outputs, if asked nicely :). In order to generate YCBCR 4:2:0 outputs, a source must: - send YCBCR 4:4:4 signals to LSPCON - program color space as 4:2:0 in AVI infoframes Whereas for YCBCR 4:4:4 outputs, the source must: - send YCBCR 4:4:4 signals to LSPCON - program color space as 4:4:4 in AVI infoframes So for both 4:2:0 as well as 4:4:4 outputs, we are driving the pipe for YCBCR 4:4:4 output, but AVI infoframe's color space information indicates LSPCON FW to start scaling down from YCBCR 4:4:4 and generate YCBCR 4:2:0 output. As the scaling is done by LSPCON device, we need not to reserve a scaler for 4:2:0 outputs. V2: rebase V3: Addressed review comments from Ville - add enum crtc_output_format instead of bool ycbcr420 - use crtc_output_format=4:4:4 for modeset of LSPCON 4:2:0 output cases in this way we will have YCBCR 4:4:4 framework ready (except the ABI part) Cc: Ville Syrjala Cc: Maarten Lankhorst Signed-off-by: Shashank Sharma --- drivers/gpu/drm/i915/i915_reg.h | 2 ++ drivers/gpu/drm/i915/intel_ddi.c| 7 +++ drivers/gpu/drm/i915/intel_dp.c | 10 ++ drivers/gpu/drm/i915/intel_drv.h| 2 ++ drivers/gpu/drm/i915/intel_lspcon.c | 28 5 files changed, 49 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 966e4df..45ee264 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -8547,6 +8547,8 @@ enum skl_power_gate { #define TRANS_MSA_MISC(tran) _MMIO_TRANS2(tran, _TRANSA_MSA_MISC) #define TRANS_MSA_SYNC_CLK (1<<0) +#define TRANS_MSA_SAMPLING_444(2<<1) +#define TRANS_MSA_CLRSP_YCBCR (2<<3) #define TRANS_MSA_6_BPC(0<<5) #define TRANS_MSA_8_BPC(1<<5) #define TRANS_MSA_10_BPC (2<<5) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index 7b89f2a..7616f6f 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -1499,6 +1499,13 @@ void intel_ddi_set_pipe_settings(const struct intel_crtc_state *crtc_state) break; } + /* +* As per DP 1.2 spec section 2.3.4.3 while sending +* YCBCR 444 signals we should program MSA MISC1/0 fields with +* colorspace information. +*/ + if (crtc_state->output_format == CRTC_OUTPUT_YCBCR444) + temp |= TRANS_MSA_SAMPLING_444 | TRANS_MSA_CLRSP_YCBCR; This fails to state that we're indicating BT.601 encoding. I think we should spell that out explicitly. Agree, I will add this in comments. I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp); } diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 35c5299..3bf82ea 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1613,6 +1613,7 @@ intel_dp_compute_config(struct intel_encoder *encoder, struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); struct drm_display_mode *adjusted_mode = &pipe_config->base.adjusted_mode; struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base); + struct intel_lspcon *lspcon = enc_to_intel_lspcon(&encoder->base); enum port port = encoder->port; struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc); struct intel_connector *intel_connector = intel_dp->attached_connector; @@ -1642,6 +1643,15 @@ intel_dp_compute_config(struct intel_encoder *encoder, if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv) && port != PORT_A) pipe_config->has_pch_encoder = true; + if (lspcon->active) { + struct drm_connector *connector = &intel_connector->base; + + if (lspcon_ycbcr420_config(connector, pipe_config)) { + pipe_config->output_format = CRTC_OUTPUT_YCBCR444; I think I'd like to see all compute_config hooks explicitly set the outout_format (to RGB usually obviously). That's the one I was talking about in previous patch. If we keep output_format_RGB = 0, we need not to do this, as reset of the pipe_config will automatically make it RGB. IMO either we have INVALID=0 so that we use it to catch readout fails, or we have no INVALID. Other options make little sense to me. Its a minor thing, and doesn't really matter. I can change this. + lspcon->output_format = CRTC_OUTPUT_YCBCR420; You should not modify any non-atomic state
Re: [Intel-gfx] [PATCH] drm/i915/bios: add DP max link rate to VBT child device struct
On Thu, Jan 18, 2018 at 05:31:45PM +0200, Jani Nikula wrote: > On Thu, 18 Jan 2018, David Weinehall wrote: > > On Thu, Jan 18, 2018 at 05:04:59PM +0200, Jani Nikula wrote: > >> Update VBT defs to reflect revision 216. While at it, default the > >> expected child device struct size to sizeof the size rather than a > >> hardcoded value. > >> > >> Cc: Rodrigo Vivi > >> Signed-off-by: Jani Nikula > > > > > >> --- > >> drivers/gpu/drm/i915/intel_bios.c | 8 +--- > >> drivers/gpu/drm/i915/intel_vbt_defs.h | 2 ++ > >> 2 files changed, 7 insertions(+), 3 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/i915/intel_bios.c > >> b/drivers/gpu/drm/i915/intel_bios.c > >> index 51108ffc28d1..b820d595ebc8 100644 > >> --- a/drivers/gpu/drm/i915/intel_bios.c > >> +++ b/drivers/gpu/drm/i915/intel_bios.c > >> @@ -1323,11 +1323,13 @@ parse_general_definitions(struct drm_i915_private > >> *dev_priv, > >>expected_size = LEGACY_CHILD_DEVICE_CONFIG_SIZE; > >>} else if (bdb->version == 195) { > >>expected_size = 37; > >> - } else if (bdb->version <= 197) { > >> + } else if (bdb->version <= 215) { > >>expected_size = 38; > >> + } else if (bdb->version <= 216) { > >> + expected_size = 39; > >>} else { > >> - expected_size = 38; > >> - BUILD_BUG_ON(sizeof(*child) < 38); > >> + expected_size = sizeof(*child); > >> + BUILD_BUG_ON(sizeof(*child) < 39); > >>DRM_DEBUG_DRIVER("Expected child device config size for VBT > >> version %u not known; assuming %u\n", > >> bdb->version, expected_size); > >>} > >> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h > >> b/drivers/gpu/drm/i915/intel_vbt_defs.h > >> index e3d7745a9151..bbb173e116b3 100644 > >> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h > >> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h > >> @@ -412,6 +412,8 @@ struct child_device_config { > >>u16 dp_gpio_pin_num;/* 195 */ > >>u8 dp_iboost_level:4; /* 196 */ > >>u8 hdmi_iboost_level:4; /* 196 */ > >> + u8 dp_max_link_rate_reserved:6; /* 216 */ > >> + u8 dp_max_link_rate:2; /* 216 CNL+ */ > > > > Isn't the bitorder wrong here? > > *facepalm* Maybe we should add a comment specifying how we expect them bitfields to work here. I can never remember which way they go. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 6/6] drm/i915: expose rcs topology through query uAPI
Quoting Lionel Landwerlin (2018-01-18 15:22:27) > On 18/01/18 15:18, Chris Wilson wrote: > > Quoting Lionel Landwerlin (2018-01-18 14:45:31) > >> +static int query_slice_info(struct drm_i915_private *dev_priv, > >> + struct drm_i915_query_item *query_item) > >> +{ > >> + const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu; > >> + struct drm_i915_query_slice_info slice_info; > >> + > >> + if (query_item->flags != 0) > >> + return -EINVAL; > >> + > >> + if (sseu->max_slices == 0) > >> + return -ENODEV; > > So conclusion was to cancel all queries and not report a 0-length result > > for unsupported? :) > > -Chris > > > Looking at GETPARAM, some queries return ENODEV if not supported (look > at SLICE_MASK, so did the same here). > Error are now reported in the s32 length field of the query item. > Unless you've screwed up the pointer to the items, in which case you'll > get an error through the ioctl() return value. > > Does that sounds sensible? It does, my fault for overlooking you had made the change. And even added it to the ioctl comments, making me look twice as bad ;) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 7/7] drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON
On Thu, Jan 18, 2018 at 09:00:50PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 1/18/2018 7:33 PM, Ville Syrjälä wrote: > > On Thu, Jan 18, 2018 at 11:57:09AM +0530, Sharma, Shashank wrote: > >> Regards > >> > >> Shashank > >> > >> > >> On 1/17/2018 11:57 PM, Ville Syrjälä wrote: > >>> On Fri, Jan 05, 2018 at 03:15:35PM +0530, Shashank Sharma wrote: > LSPCON chips can generate YCBCR outputs, if asked nicely :). > > In order to generate YCBCR 4:2:0 outputs, a source must: > - send YCBCR 4:4:4 signals to LSPCON > - program color space as 4:2:0 in AVI infoframes > > Whereas for YCBCR 4:4:4 outputs, the source must: > - send YCBCR 4:4:4 signals to LSPCON > - program color space as 4:4:4 in AVI infoframes > > So for both 4:2:0 as well as 4:4:4 outputs, we are driving the > pipe for YCBCR 4:4:4 output, but AVI infoframe's color space > information indicates LSPCON FW to start scaling down from YCBCR > 4:4:4 and generate YCBCR 4:2:0 output. As the scaling is done by > LSPCON device, we need not to reserve a scaler for 4:2:0 outputs. > > V2: rebase > V3: Addressed review comments from Ville > - add enum crtc_output_format instead of bool ycbcr420 > - use crtc_output_format=4:4:4 for modeset of LSPCON 4:2:0 output > cases in this way we will have YCBCR 4:4:4 framework ready > (except > the ABI part) > > Cc: Ville Syrjala > Cc: Maarten Lankhorst > Signed-off-by: Shashank Sharma > --- > drivers/gpu/drm/i915/i915_reg.h | 2 ++ > drivers/gpu/drm/i915/intel_ddi.c| 7 +++ > drivers/gpu/drm/i915/intel_dp.c | 10 ++ > drivers/gpu/drm/i915/intel_drv.h| 2 ++ > drivers/gpu/drm/i915/intel_lspcon.c | 28 > 5 files changed, 49 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_reg.h > b/drivers/gpu/drm/i915/i915_reg.h > index 966e4df..45ee264 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -8547,6 +8547,8 @@ enum skl_power_gate { > #define TRANS_MSA_MISC(tran) _MMIO_TRANS2(tran, _TRANSA_MSA_MISC) > > #define TRANS_MSA_SYNC_CLK (1<<0) > +#define TRANS_MSA_SAMPLING_444(2<<1) > +#define TRANS_MSA_CLRSP_YCBCR (2<<3) > #define TRANS_MSA_6_BPC (0<<5) > #define TRANS_MSA_8_BPC (1<<5) > #define TRANS_MSA_10_BPC (2<<5) > diff --git a/drivers/gpu/drm/i915/intel_ddi.c > b/drivers/gpu/drm/i915/intel_ddi.c > index 7b89f2a..7616f6f 100644 > --- a/drivers/gpu/drm/i915/intel_ddi.c > +++ b/drivers/gpu/drm/i915/intel_ddi.c > @@ -1499,6 +1499,13 @@ void intel_ddi_set_pipe_settings(const struct > intel_crtc_state *crtc_state) > break; > } > > +/* > + * As per DP 1.2 spec section 2.3.4.3 while sending > + * YCBCR 444 signals we should program MSA MISC1/0 fields with > + * colorspace information. > + */ > +if (crtc_state->output_format == CRTC_OUTPUT_YCBCR444) > +temp |= TRANS_MSA_SAMPLING_444 | TRANS_MSA_CLRSP_YCBCR; > >>> This fails to state that we're indicating BT.601 encoding. I think we > >>> should spell that out explicitly. > >> Agree, I will add this in comments. > I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp); > } > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > b/drivers/gpu/drm/i915/intel_dp.c > index 35c5299..3bf82ea 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -1613,6 +1613,7 @@ intel_dp_compute_config(struct intel_encoder > *encoder, > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); > struct drm_display_mode *adjusted_mode = > &pipe_config->base.adjusted_mode; > struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base); > +struct intel_lspcon *lspcon = > enc_to_intel_lspcon(&encoder->base); > enum port port = encoder->port; > struct intel_crtc *intel_crtc = > to_intel_crtc(pipe_config->base.crtc); > struct intel_connector *intel_connector = > intel_dp->attached_connector; > @@ -1642,6 +1643,15 @@ intel_dp_compute_config(struct intel_encoder > *encoder, > if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv) && port != > PORT_A) > pipe_config->has_pch_encoder = true; > > +if (lspcon->active) { > +struct drm_connector *connector = > &intel_connector->base; > + > +if (lspcon_ycbcr42
Re: [Intel-gfx] [PATCH v3 7/7] drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON
Regards Shashank On 1/18/2018 7:33 PM, Ville Syrjälä wrote: On Thu, Jan 18, 2018 at 11:57:09AM +0530, Sharma, Shashank wrote: Regards Shashank On 1/17/2018 11:57 PM, Ville Syrjälä wrote: On Fri, Jan 05, 2018 at 03:15:35PM +0530, Shashank Sharma wrote: LSPCON chips can generate YCBCR outputs, if asked nicely :). In order to generate YCBCR 4:2:0 outputs, a source must: - send YCBCR 4:4:4 signals to LSPCON - program color space as 4:2:0 in AVI infoframes Whereas for YCBCR 4:4:4 outputs, the source must: - send YCBCR 4:4:4 signals to LSPCON - program color space as 4:4:4 in AVI infoframes So for both 4:2:0 as well as 4:4:4 outputs, we are driving the pipe for YCBCR 4:4:4 output, but AVI infoframe's color space information indicates LSPCON FW to start scaling down from YCBCR 4:4:4 and generate YCBCR 4:2:0 output. As the scaling is done by LSPCON device, we need not to reserve a scaler for 4:2:0 outputs. V2: rebase V3: Addressed review comments from Ville - add enum crtc_output_format instead of bool ycbcr420 - use crtc_output_format=4:4:4 for modeset of LSPCON 4:2:0 output cases in this way we will have YCBCR 4:4:4 framework ready (except the ABI part) Cc: Ville Syrjala Cc: Maarten Lankhorst Signed-off-by: Shashank Sharma --- drivers/gpu/drm/i915/i915_reg.h | 2 ++ drivers/gpu/drm/i915/intel_ddi.c| 7 +++ drivers/gpu/drm/i915/intel_dp.c | 10 ++ drivers/gpu/drm/i915/intel_drv.h| 2 ++ drivers/gpu/drm/i915/intel_lspcon.c | 28 5 files changed, 49 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 966e4df..45ee264 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -8547,6 +8547,8 @@ enum skl_power_gate { #define TRANS_MSA_MISC(tran) _MMIO_TRANS2(tran, _TRANSA_MSA_MISC) #define TRANS_MSA_SYNC_CLK (1<<0) +#define TRANS_MSA_SAMPLING_444(2<<1) +#define TRANS_MSA_CLRSP_YCBCR (2<<3) #define TRANS_MSA_6_BPC (0<<5) #define TRANS_MSA_8_BPC (1<<5) #define TRANS_MSA_10_BPC(2<<5) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index 7b89f2a..7616f6f 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -1499,6 +1499,13 @@ void intel_ddi_set_pipe_settings(const struct intel_crtc_state *crtc_state) break; } + /* +* As per DP 1.2 spec section 2.3.4.3 while sending +* YCBCR 444 signals we should program MSA MISC1/0 fields with +* colorspace information. +*/ + if (crtc_state->output_format == CRTC_OUTPUT_YCBCR444) + temp |= TRANS_MSA_SAMPLING_444 | TRANS_MSA_CLRSP_YCBCR; This fails to state that we're indicating BT.601 encoding. I think we should spell that out explicitly. Agree, I will add this in comments. I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp); } diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 35c5299..3bf82ea 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1613,6 +1613,7 @@ intel_dp_compute_config(struct intel_encoder *encoder, struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); struct drm_display_mode *adjusted_mode = &pipe_config->base.adjusted_mode; struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base); + struct intel_lspcon *lspcon = enc_to_intel_lspcon(&encoder->base); enum port port = encoder->port; struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc); struct intel_connector *intel_connector = intel_dp->attached_connector; @@ -1642,6 +1643,15 @@ intel_dp_compute_config(struct intel_encoder *encoder, if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv) && port != PORT_A) pipe_config->has_pch_encoder = true; + if (lspcon->active) { + struct drm_connector *connector = &intel_connector->base; + + if (lspcon_ycbcr420_config(connector, pipe_config)) { + pipe_config->output_format = CRTC_OUTPUT_YCBCR444; I think I'd like to see all compute_config hooks explicitly set the outout_format (to RGB usually obviously). That's the one I was talking about in previous patch. If we keep output_format_RGB = 0, we need not to do this, as reset of the pipe_config will automatically make it RGB. IMO either we have INVALID=0 so that we use it to catch readout fails, or we have no INVALID. Other options make little sense to me. Its a minor thing, and doesn't really matter. I can change this. + lspcon->output_format = CRTC_OUTPUT_YCBCR420; You should not modify any non-atomic state like that in compute_config. Please help me to understand this better, Can you elaborate a bit more on: - Why is this a non-atomic state ? - What i
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: expose RCS topology to userspace
== Series Details == Series: drm/i915: expose RCS topology to userspace URL : https://patchwork.freedesktop.org/series/36696/ State : success == Summary == Series 36696v1 drm/i915: expose RCS topology to userspace https://patchwork.freedesktop.org/api/1.0/series/36696/revisions/1/mbox/ Test debugfs_test: Subgroup read_all_entries: pass -> DMESG-FAIL (fi-elk-e7500) fdo#103989 Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:422s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:427s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:374s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:489s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:282s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:485s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:493s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:470s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:459s fi-elk-e7500 total:224 pass:168 dwarn:9 dfail:1 fail:0 skip:45 fi-gdg-551 total:288 pass:180 dwarn:0 dfail:0 fail:0 skip:108 time:277s 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:393s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:402s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:411s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:448s 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:457s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:499s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:455s 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:582s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:434s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:511s 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:490s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:491s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:434s 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:403s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:573s fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:474s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:418s 88e8ed1dc6915fcc801fba00955ef83853942f62 drm-tip: 2018y-01m-18d-14h-19m-46s UTC integration manifest 3a4d9e4e691e drm/i915: expose rcs topology through query uAPI 8d15a5ac9362 drm/i915: add query uAPI 7a9757bcc564 drm/i915: add rcs topology to error state 2db7c14bff41 drm/i915/debugfs: add rcs topology entry b28cd91603d5 drm/i915/debugfs: reuse max slice/subslices already stored in sseu dff5d7cb8214 drm/i915: store all subslice masks == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7710/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/bios: add DP max link rate to VBT child device struct
Update VBT defs to reflect revision 216. While at it, default the expected child device struct size to sizeof the size rather than a hardcoded value. v2: Fix bit order (David) Cc: Rodrigo Vivi Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_bios.c | 8 +--- drivers/gpu/drm/i915/intel_vbt_defs.h | 2 ++ 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c index 51108ffc28d1..b820d595ebc8 100644 --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -1323,11 +1323,13 @@ parse_general_definitions(struct drm_i915_private *dev_priv, expected_size = LEGACY_CHILD_DEVICE_CONFIG_SIZE; } else if (bdb->version == 195) { expected_size = 37; - } else if (bdb->version <= 197) { + } else if (bdb->version <= 215) { expected_size = 38; + } else if (bdb->version <= 216) { + expected_size = 39; } else { - expected_size = 38; - BUILD_BUG_ON(sizeof(*child) < 38); + expected_size = sizeof(*child); + BUILD_BUG_ON(sizeof(*child) < 39); DRM_DEBUG_DRIVER("Expected child device config size for VBT version %u not known; assuming %u\n", bdb->version, expected_size); } diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h b/drivers/gpu/drm/i915/intel_vbt_defs.h index e3d7745a9151..98dff6058d3c 100644 --- a/drivers/gpu/drm/i915/intel_vbt_defs.h +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h @@ -412,6 +412,8 @@ struct child_device_config { u16 dp_gpio_pin_num;/* 195 */ u8 dp_iboost_level:4; /* 196 */ u8 hdmi_iboost_level:4; /* 196 */ + u8 dp_max_link_rate:2; /* 216 CNL+ */ + u8 dp_max_link_rate_reserved:6; /* 216 */ } __packed; struct bdb_general_definitions { -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bios: add DP max link rate to VBT child device struct
On Thu, 18 Jan 2018, David Weinehall wrote: > On Thu, Jan 18, 2018 at 05:04:59PM +0200, Jani Nikula wrote: >> Update VBT defs to reflect revision 216. While at it, default the >> expected child device struct size to sizeof the size rather than a >> hardcoded value. >> >> Cc: Rodrigo Vivi >> Signed-off-by: Jani Nikula > > >> --- >> drivers/gpu/drm/i915/intel_bios.c | 8 +--- >> drivers/gpu/drm/i915/intel_vbt_defs.h | 2 ++ >> 2 files changed, 7 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_bios.c >> b/drivers/gpu/drm/i915/intel_bios.c >> index 51108ffc28d1..b820d595ebc8 100644 >> --- a/drivers/gpu/drm/i915/intel_bios.c >> +++ b/drivers/gpu/drm/i915/intel_bios.c >> @@ -1323,11 +1323,13 @@ parse_general_definitions(struct drm_i915_private >> *dev_priv, >> expected_size = LEGACY_CHILD_DEVICE_CONFIG_SIZE; >> } else if (bdb->version == 195) { >> expected_size = 37; >> -} else if (bdb->version <= 197) { >> +} else if (bdb->version <= 215) { >> expected_size = 38; >> +} else if (bdb->version <= 216) { >> +expected_size = 39; >> } else { >> -expected_size = 38; >> -BUILD_BUG_ON(sizeof(*child) < 38); >> +expected_size = sizeof(*child); >> +BUILD_BUG_ON(sizeof(*child) < 39); >> DRM_DEBUG_DRIVER("Expected child device config size for VBT >> version %u not known; assuming %u\n", >> bdb->version, expected_size); >> } >> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h >> b/drivers/gpu/drm/i915/intel_vbt_defs.h >> index e3d7745a9151..bbb173e116b3 100644 >> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h >> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h >> @@ -412,6 +412,8 @@ struct child_device_config { >> u16 dp_gpio_pin_num;/* 195 */ >> u8 dp_iboost_level:4; /* 196 */ >> u8 hdmi_iboost_level:4; /* 196 */ >> +u8 dp_max_link_rate_reserved:6; /* 216 */ >> +u8 dp_max_link_rate:2; /* 216 CNL+ */ > > Isn't the bitorder wrong here? *facepalm* > >> } __packed; >> >> struct bdb_general_definitions { >> -- >> 2.11.0 >> >> ___ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 6/6] drm/i915: expose rcs topology through query uAPI
On 18/01/18 15:18, Chris Wilson wrote: Quoting Lionel Landwerlin (2018-01-18 14:45:31) +static int query_slice_info(struct drm_i915_private *dev_priv, + struct drm_i915_query_item *query_item) +{ + const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu; + struct drm_i915_query_slice_info slice_info; + + if (query_item->flags != 0) + return -EINVAL; + + if (sseu->max_slices == 0) + return -ENODEV; So conclusion was to cancel all queries and not report a 0-length result for unsupported? :) -Chris Looking at GETPARAM, some queries return ENODEV if not supported (look at SLICE_MASK, so did the same here). Error are now reported in the s32 length field of the query item. Unless you've screwed up the pointer to the items, in which case you'll get an error through the ioctl() return value. Does that sounds sensible? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 6/6] drm/i915: expose rcs topology through query uAPI
Quoting Lionel Landwerlin (2018-01-18 14:45:31) > +static int query_slice_info(struct drm_i915_private *dev_priv, > + struct drm_i915_query_item *query_item) > +{ > + const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu; > + struct drm_i915_query_slice_info slice_info; > + > + if (query_item->flags != 0) > + return -EINVAL; > + > + if (sseu->max_slices == 0) > + return -ENODEV; So conclusion was to cancel all queries and not report a 0-length result for unsupported? :) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: vbt defs typo fixes
On Thu, Jan 18, 2018 at 05:06:13PM +0200, Jani Nikula wrote: > No more sing-a-ling. LOL, well spotted. > Reported-by: Adam Jackson > Signed-off-by: Jani Nikula Reviewed-by: David Weinehall > --- > drivers/gpu/drm/i915/intel_vbt_defs.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h > b/drivers/gpu/drm/i915/intel_vbt_defs.h > index bbb173e116b3..fa4f67d3f261 100644 > --- a/drivers/gpu/drm/i915/intel_vbt_defs.h > +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h > @@ -227,7 +227,7 @@ struct bdb_general_features { > #define DEVICE_TYPE_COMPOSITE_OUTPUT (1 << 9) > #define DEVICE_TYPE_DUAL_CHANNEL (1 << 8) > #define DEVICE_TYPE_HIGH_SPEED_LINK (1 << 6) > -#define DEVICE_TYPE_LVDS_SINGALING (1 << 5) > +#define DEVICE_TYPE_LVDS_SIGNALING (1 << 5) > #define DEVICE_TYPE_TMDS_DVI_SIGNALING (1 << 4) > #define DEVICE_TYPE_VIDEO_SIGNALING (1 << 3) > #define DEVICE_TYPE_DISPLAYPORT_OUTPUT (1 << 2) > @@ -243,7 +243,7 @@ struct bdb_general_features { >DEVICE_TYPE_MIPI_OUTPUT | \ >DEVICE_TYPE_COMPOSITE_OUTPUT | \ >DEVICE_TYPE_DUAL_CHANNEL | \ > - DEVICE_TYPE_LVDS_SINGALING | \ > + DEVICE_TYPE_LVDS_SIGNALING | \ >DEVICE_TYPE_TMDS_DVI_SIGNALING | \ >DEVICE_TYPE_VIDEO_SIGNALING | \ >DEVICE_TYPE_DISPLAYPORT_OUTPUT | \ > @@ -253,7 +253,7 @@ struct bdb_general_features { > (DEVICE_TYPE_INTERNAL_CONNECTOR | \ >DEVICE_TYPE_MIPI_OUTPUT | \ >DEVICE_TYPE_COMPOSITE_OUTPUT | \ > - DEVICE_TYPE_LVDS_SINGALING | \ > + DEVICE_TYPE_LVDS_SIGNALING | \ >DEVICE_TYPE_TMDS_DVI_SIGNALING | \ >DEVICE_TYPE_VIDEO_SIGNALING | \ >DEVICE_TYPE_DISPLAYPORT_OUTPUT | \ > -- > 2.11.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 6/6] drm/i915: expose rcs topology through query uAPI
On 18/01/18 12:46, Tvrtko Ursulin wrote: On 17/01/2018 15:39, Lionel Landwerlin wrote: With the introduction of asymmetric slices in CNL, we cannot rely on the previous SUBSLICE_MASK getparam to tell userspace what subslices are available. Here we introduce a more detailed way of querying the Gen's GPU topology that doesn't aggregate numbers. This is essential for monitoring parts of the GPU with the OA unit, because counters need to be normalized to the number of EUs/subslices/slices. The current aggregated numbers like EU_TOTAL do not gives us sufficient information. As a bonus we can draw representations of the GPU : https://imgur.com/a/vuqpa v2: Rename uapi struct s/_mask/_info/ (Tvrtko) Report max_slice/subslice/eus_per_subslice rather than strides (Tvrtko) Add uapi macros to read data from *_info structs (Tvrtko) v3: Use !!(v & DRM_I915_BIT()) for uapi macros instead of custom shifts (Tvrtko) v4: factorize query item writting (Tvrtko) tweak uapi struct/define names (Tvrtko) v5: Replace ALIGN() macro (Chris) v6: Updated uapi comments (Tvrtko) Moved flags != 0 checks into vfuncs (Tvrtko) Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_query.c | 105 ++ include/uapi/drm/i915_drm.h | 68 2 files changed, 173 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c index 5aa886313cf9..5d1386db8e7b 100644 --- a/drivers/gpu/drm/i915/i915_query.c +++ b/drivers/gpu/drm/i915/i915_query.c @@ -25,8 +25,113 @@ #include "i915_drv.h" #include +static int copy_query_data(struct drm_i915_query_item *query_item, + const void *item_ptr, u32 item_length, + const void *data_ptr, u32 data_length) +{ + u32 total_length = item_length + data_length; + + BUG_ON(add_overflows(item_length, data_length)); Please change to if (WARN_ON_ONCE(...)) return -EINVAL;. Or even GEM_WARN_ON. This can only happen during development so is enough. Thanks, done. + + if (query_item->length == 0) + return total_length; + + if (query_item->length < total_length) + return -EINVAL; Did we talk about whether this check should be != or < yet? != would sound safer to me, or you want to allow extending the queries in the future and keeping the same id? Like Chris said :) + + if (copy_to_user(u64_to_user_ptr(query_item->data_ptr), + item_ptr, item_length)) + return -EFAULT; + + if (copy_to_user(u64_to_user_ptr(query_item->data_ptr + item_length), + data_ptr, data_length)) + return -EFAULT; + + return total_length; +} + +static int query_slice_info(struct drm_i915_private *dev_priv, + struct drm_i915_query_item *query_item) +{ + const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu; + struct drm_i915_query_slice_info slice_info; + + if (query_item->flags != 0) + return -EINVAL; + + if (sseu->max_slices == 0) + return -ENODEV; + + /* + * If we ever change the internal slice mask data type, we'll need to + * update this function. + */ + BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask)); + + memset(&slice_info, 0, sizeof(slice_info)); + slice_info.max_slices = sseu->max_slices; + + return copy_query_data(query_item, &slice_info, sizeof(slice_info), + &sseu->slice_mask, sizeof(sseu->slice_mask)); +} + +static int query_subslice_info(struct drm_i915_private *dev_priv, + struct drm_i915_query_item *query_item) +{ + const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu; + struct drm_i915_query_subslice_info subslice_info; + u32 data_length; + + if (query_item->flags != 0) + return -EINVAL; + + if (sseu->max_slices == 0) + return -ENODEV; + + memset(&subslice_info, 0, sizeof(subslice_info)); + subslice_info.max_slices = sseu->max_slices; + subslice_info.max_subslices = sseu->max_subslices; + + data_length = subslice_info.max_slices * + DIV_ROUND_UP(subslice_info.max_subslices, + sizeof(sseu->subslice_mask[0]) * BITS_PER_BYTE); + + return copy_query_data(query_item, + &subslice_info, sizeof(subslice_info), + sseu->subslice_mask, data_length); +} + +static int query_eu_info(struct drm_i915_private *dev_priv, + struct drm_i915_query_item *query_item) +{ + const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu; + struct drm_i915_query_eu_info eu_info; + u32 data_length; + + if (query_item->flags != 0) + return -EINVAL; + + if (sseu->max_slices == 0) + return -ENODEV; + + memset(&eu_info, 0, sizeof(eu_info)); + eu_info.max_slices = sseu->max_slices; + eu_info.max_subslices = sseu->max_subslices; + eu_info.max_eus_per_subslice = sseu->max_eus_per_subslice; + + data_length = eu
Re: [Intel-gfx] [PATCH] drm/i915: vbt defs typo fixes
Quoting Jani Nikula (2018-01-18 15:06:13) > No more sing-a-ling. > > Reported-by: Adam Jackson > Signed-off-by: Jani Nikula You're-my-ding-a-ling-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/bios: add DP max link rate to VBT child device struct
On Thu, Jan 18, 2018 at 05:04:59PM +0200, Jani Nikula wrote: > Update VBT defs to reflect revision 216. While at it, default the > expected child device struct size to sizeof the size rather than a > hardcoded value. > > Cc: Rodrigo Vivi > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_bios.c | 8 +--- > drivers/gpu/drm/i915/intel_vbt_defs.h | 2 ++ > 2 files changed, 7 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_bios.c > b/drivers/gpu/drm/i915/intel_bios.c > index 51108ffc28d1..b820d595ebc8 100644 > --- a/drivers/gpu/drm/i915/intel_bios.c > +++ b/drivers/gpu/drm/i915/intel_bios.c > @@ -1323,11 +1323,13 @@ parse_general_definitions(struct drm_i915_private > *dev_priv, > expected_size = LEGACY_CHILD_DEVICE_CONFIG_SIZE; > } else if (bdb->version == 195) { > expected_size = 37; > - } else if (bdb->version <= 197) { > + } else if (bdb->version <= 215) { > expected_size = 38; > + } else if (bdb->version <= 216) { > + expected_size = 39; > } else { > - expected_size = 38; > - BUILD_BUG_ON(sizeof(*child) < 38); > + expected_size = sizeof(*child); > + BUILD_BUG_ON(sizeof(*child) < 39); > DRM_DEBUG_DRIVER("Expected child device config size for VBT > version %u not known; assuming %u\n", >bdb->version, expected_size); > } > diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h > b/drivers/gpu/drm/i915/intel_vbt_defs.h > index e3d7745a9151..bbb173e116b3 100644 > --- a/drivers/gpu/drm/i915/intel_vbt_defs.h > +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h > @@ -412,6 +412,8 @@ struct child_device_config { > u16 dp_gpio_pin_num;/* 195 */ > u8 dp_iboost_level:4; /* 196 */ > u8 hdmi_iboost_level:4; /* 196 */ > + u8 dp_max_link_rate_reserved:6; /* 216 */ > + u8 dp_max_link_rate:2; /* 216 CNL+ */ Isn't the bitorder wrong here? > } __packed; > > struct bdb_general_definitions { > -- > 2.11.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: vbt defs typo fixes
No more sing-a-ling. Reported-by: Adam Jackson Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_vbt_defs.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h b/drivers/gpu/drm/i915/intel_vbt_defs.h index bbb173e116b3..fa4f67d3f261 100644 --- a/drivers/gpu/drm/i915/intel_vbt_defs.h +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h @@ -227,7 +227,7 @@ struct bdb_general_features { #define DEVICE_TYPE_COMPOSITE_OUTPUT (1 << 9) #define DEVICE_TYPE_DUAL_CHANNEL (1 << 8) #define DEVICE_TYPE_HIGH_SPEED_LINK(1 << 6) -#define DEVICE_TYPE_LVDS_SINGALING (1 << 5) +#define DEVICE_TYPE_LVDS_SIGNALING (1 << 5) #define DEVICE_TYPE_TMDS_DVI_SIGNALING (1 << 4) #define DEVICE_TYPE_VIDEO_SIGNALING(1 << 3) #define DEVICE_TYPE_DISPLAYPORT_OUTPUT (1 << 2) @@ -243,7 +243,7 @@ struct bdb_general_features { DEVICE_TYPE_MIPI_OUTPUT | \ DEVICE_TYPE_COMPOSITE_OUTPUT | \ DEVICE_TYPE_DUAL_CHANNEL | \ -DEVICE_TYPE_LVDS_SINGALING | \ +DEVICE_TYPE_LVDS_SIGNALING | \ DEVICE_TYPE_TMDS_DVI_SIGNALING | \ DEVICE_TYPE_VIDEO_SIGNALING | \ DEVICE_TYPE_DISPLAYPORT_OUTPUT | \ @@ -253,7 +253,7 @@ struct bdb_general_features { (DEVICE_TYPE_INTERNAL_CONNECTOR | \ DEVICE_TYPE_MIPI_OUTPUT | \ DEVICE_TYPE_COMPOSITE_OUTPUT | \ -DEVICE_TYPE_LVDS_SINGALING | \ +DEVICE_TYPE_LVDS_SIGNALING | \ DEVICE_TYPE_TMDS_DVI_SIGNALING | \ DEVICE_TYPE_VIDEO_SIGNALING | \ DEVICE_TYPE_DISPLAYPORT_OUTPUT | \ -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/bios: add DP max link rate to VBT child device struct
Update VBT defs to reflect revision 216. While at it, default the expected child device struct size to sizeof the size rather than a hardcoded value. Cc: Rodrigo Vivi Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_bios.c | 8 +--- drivers/gpu/drm/i915/intel_vbt_defs.h | 2 ++ 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c index 51108ffc28d1..b820d595ebc8 100644 --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -1323,11 +1323,13 @@ parse_general_definitions(struct drm_i915_private *dev_priv, expected_size = LEGACY_CHILD_DEVICE_CONFIG_SIZE; } else if (bdb->version == 195) { expected_size = 37; - } else if (bdb->version <= 197) { + } else if (bdb->version <= 215) { expected_size = 38; + } else if (bdb->version <= 216) { + expected_size = 39; } else { - expected_size = 38; - BUILD_BUG_ON(sizeof(*child) < 38); + expected_size = sizeof(*child); + BUILD_BUG_ON(sizeof(*child) < 39); DRM_DEBUG_DRIVER("Expected child device config size for VBT version %u not known; assuming %u\n", bdb->version, expected_size); } diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h b/drivers/gpu/drm/i915/intel_vbt_defs.h index e3d7745a9151..bbb173e116b3 100644 --- a/drivers/gpu/drm/i915/intel_vbt_defs.h +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h @@ -412,6 +412,8 @@ struct child_device_config { u16 dp_gpio_pin_num;/* 195 */ u8 dp_iboost_level:4; /* 196 */ u8 hdmi_iboost_level:4; /* 196 */ + u8 dp_max_link_rate_reserved:6; /* 216 */ + u8 dp_max_link_rate:2; /* 216 CNL+ */ } __packed; struct bdb_general_definitions { -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/15] drm/i915: Add NV12 support to intel_framebuffer_init
Op 18-01-18 om 15:21 schreef Maarten Lankhorst: > Op 20-01-18 om 22:45 schreef Vidya Srinivas: >> From: Chandra Konduru >> >> This patch adds NV12 as supported format >> to intel_framebuffer_init and performs various checks. >> >> v2: >> -Fix an issue in checks added (Chandra Konduru) >> >> v3: rebased (me) >> >> v4: Review comments by Ville addressed >> Added platform check for NV12 in intel_framebuffer_init >> Removed offset checks for NV12 case >> >> v5: Addressed review comments by Clinton A Taylor >> This NV12 support only correctly works on SKL. >> Plane color space conversion is different on GLK and later platforms >> causing the colors to display incorrectly. >> Ville's plane color space property patch series >> in review will fix this issue. >> - Restricted the NV12 case in intel_framebuffer_init to >> SKL and BXT only. >> >> v6: Rebased (me) >> >> v7: Addressed review comments by Ville >> Restricting the NV12 to BXT for now. >> >> v8: Rebased (me) >> Restricting the NV12 changes to BXT and KBL for now. >> >> v9: Rebased (me) >> >> Tested-by: Clinton Taylor >> Reviewed-by: Clinton Taylor >> Signed-off-by: Chandra Konduru >> Signed-off-by: Nabendu Maiti >> Signed-off-by: Vidya Srinivas >> --- >> drivers/gpu/drm/i915/intel_display.c | 8 >> 1 file changed, 8 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/intel_display.c >> b/drivers/gpu/drm/i915/intel_display.c >> index 88bc750..db42448 100644 >> --- a/drivers/gpu/drm/i915/intel_display.c >> +++ b/drivers/gpu/drm/i915/intel_display.c >> @@ -14005,6 +14005,14 @@ static int intel_framebuffer_init(struct >> intel_framebuffer *intel_fb, >> goto err; >> } >> break; >> +case DRM_FORMAT_NV12: >> +if (!IS_BROXTON(dev_priv) && !IS_KABYLAKE(dev_priv)) { >> +DRM_DEBUG_KMS("unsupported pixel format: %s\n", >> + drm_get_format_name(mode_cmd->pixel_format, >> +&format_name)); >> +goto err; >> +} >> +break; > I started implementing the IGT side of this but as far as I can tell, the > specification will allow you to set different handles for each plane. But > intel doesn't support this right now.. > > Could this assumption be fixed first? There's nothing stopping the drm core > or applications from having separate buffer objects, and for blitting it > would make sense to have a R8 plane for Y', and a R8G8 plane for Cb'Cr' > > Probably needs i915 to compile with something like below, then handling all > corner cases.. Never mind, seems this is a hardware limitation that bo for plane2 must be higher mapped than plane1 so having separate bo's won't do much. And there was already a check for handles[i] == handles[0]. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 5/6] drm/i915: add query uAPI
There are a number of information that are readable from hardware registers and that we would like to make accessible to userspace. One particular example is the topology of the execution units (how are execution units grouped in subslices and slices and also which ones have been fused off for die recovery). At the moment the GET_PARAM ioctl covers some basic needs, but generally is only able to return a single value for each defined parameter. This is a bit problematic with topology descriptions which are array/maps of available units. This change introduces a new ioctl that can deal with requests to fill structures of potentially variable lengths. The user is expected fill a query with length fields set at 0 on the first call, the kernel then sets the length fields to the their expected values. A second call to the kernel with length fields at their expected values will trigger a copy of the data to the pointed memory locations. The scope of this uAPI is only to provide information to userspace, not to allow configuration of the device. v2: Simplify dispatcher code iteration (Tvrtko) Tweak uapi drm_i915_query_item structure (Tvrtko) v3: Rename pad fields into flags (Chris) Return error on flags field != 0 (Chris) Only copy length back to userspace in drm_i915_query_item (Chris) v4: Use array of functions instead of switch (Chris) v5: More comments in uapi (Tvrtko) Return query item errors in length field (All) Signed-off-by: Lionel Landwerlin Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_drv.c | 1 + drivers/gpu/drm/i915/i915_drv.h | 3 ++ drivers/gpu/drm/i915/i915_query.c | 67 +++ include/uapi/drm/i915_drm.h | 37 + 5 files changed, 109 insertions(+) create mode 100644 drivers/gpu/drm/i915/i915_query.c diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 3bddd8a06806..b0415a3e2d59 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -69,6 +69,7 @@ i915-y += i915_cmd_parser.o \ i915_gem_timeline.o \ i915_gem_userptr.o \ i915_gemfs.o \ + i915_query.o \ i915_trace_points.o \ i915_vma.o \ intel_breadcrumbs.o \ diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index a4cf6858e39c..e7098cf07ef5 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -2826,6 +2826,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = { DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, DRM_RENDER_ALLOW), DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW), DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG, i915_perf_remove_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW), + DRM_IOCTL_DEF_DRV(I915_QUERY, i915_query_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW), }; static struct drm_driver driver = { diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 317953484fec..b7ca9588b993 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -3622,6 +3622,9 @@ extern void i915_perf_fini(struct drm_i915_private *dev_priv); extern void i915_perf_register(struct drm_i915_private *dev_priv); extern void i915_perf_unregister(struct drm_i915_private *dev_priv); +/* i915_query.c */ +int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file); + /* i915_suspend.c */ extern int i915_save_state(struct drm_i915_private *dev_priv); extern int i915_restore_state(struct drm_i915_private *dev_priv); diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c new file mode 100644 index ..5aa886313cf9 --- /dev/null +++ b/drivers/gpu/drm/i915/i915_query.c @@ -0,0 +1,67 @@ +/* + * Copyright © 2017 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM,
[Intel-gfx] [PATCH v9 4/6] drm/i915: add rcs topology to error state
This might be useful information for developers looking at an error state. v2: Place topology towards the end of the error state (Chris) v3: Reuse common printing code (Michal) v4: Make this a one-liner (Chris) Signed-off-by: Lionel Landwerlin Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gpu_error.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c index 06577574296b..5920a1bb1828 100644 --- a/drivers/gpu/drm/i915/i915_gpu_error.c +++ b/drivers/gpu/drm/i915/i915_gpu_error.c @@ -568,6 +568,7 @@ static void err_print_capabilities(struct drm_i915_error_state_buf *m, struct drm_printer p = i915_error_printer(m); intel_device_info_dump_flags(info, &p); + intel_device_info_dump_topology(&info->sseu, &p); } static void err_print_params(struct drm_i915_error_state_buf *m, -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 6/6] drm/i915: expose rcs topology through query uAPI
With the introduction of asymmetric slices in CNL, we cannot rely on the previous SUBSLICE_MASK getparam to tell userspace what subslices are available. Here we introduce a more detailed way of querying the Gen's GPU topology that doesn't aggregate numbers. This is essential for monitoring parts of the GPU with the OA unit, because counters need to be normalized to the number of EUs/subslices/slices. The current aggregated numbers like EU_TOTAL do not gives us sufficient information. As a bonus we can draw representations of the GPU : https://imgur.com/a/vuqpa v2: Rename uapi struct s/_mask/_info/ (Tvrtko) Report max_slice/subslice/eus_per_subslice rather than strides (Tvrtko) Add uapi macros to read data from *_info structs (Tvrtko) v3: Use !!(v & DRM_I915_BIT()) for uapi macros instead of custom shifts (Tvrtko) v4: factorize query item writting (Tvrtko) tweak uapi struct/define names (Tvrtko) v5: Replace ALIGN() macro (Chris) v6: Updated uapi comments (Tvrtko) Moved flags != 0 checks into vfuncs (Tvrtko) v7: Use access_ok() before copying anything, to avoid overflows (Chris) Switch BUG_ON() to GEM_WARN_ON() (Tvrtko) Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_query.c | 110 ++ include/uapi/drm/i915_drm.h | 68 +++ 2 files changed, 178 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c index 5aa886313cf9..ff87ec8a321a 100644 --- a/drivers/gpu/drm/i915/i915_query.c +++ b/drivers/gpu/drm/i915/i915_query.c @@ -25,8 +25,118 @@ #include "i915_drv.h" #include +static int copy_query_data(struct drm_i915_query_item *query_item, + const void *item_ptr, u32 item_length, + const void *data_ptr, u32 data_length) +{ + u32 total_length = item_length + data_length; + + if (GEM_WARN_ON(add_overflows(item_length, data_length))) + return -EINVAL; + + if (query_item->length == 0) + return total_length; + + if (query_item->length < total_length) + return -EINVAL; + + if (!access_ok(VERIFY_WRITE, u64_to_user_ptr(query_item->data_ptr), + total_length)) + return -EFAULT; + + if (__copy_to_user(u64_to_user_ptr(query_item->data_ptr), + item_ptr, item_length)) + return -EFAULT; + + if (__copy_to_user(u64_to_user_ptr(query_item->data_ptr + item_length), + data_ptr, data_length)) + return -EFAULT; + + return total_length; +} + +static int query_slice_info(struct drm_i915_private *dev_priv, + struct drm_i915_query_item *query_item) +{ + const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu; + struct drm_i915_query_slice_info slice_info; + + if (query_item->flags != 0) + return -EINVAL; + + if (sseu->max_slices == 0) + return -ENODEV; + + /* +* If we ever change the internal slice mask data type, we'll need to +* update this function. +*/ + BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask)); + + memset(&slice_info, 0, sizeof(slice_info)); + slice_info.max_slices = sseu->max_slices; + + return copy_query_data(query_item, &slice_info, sizeof(slice_info), + &sseu->slice_mask, sizeof(sseu->slice_mask)); +} + +static int query_subslice_info(struct drm_i915_private *dev_priv, + struct drm_i915_query_item *query_item) +{ + const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu; + struct drm_i915_query_subslice_info subslice_info; + u32 data_length; + + if (query_item->flags != 0) + return -EINVAL; + + if (sseu->max_slices == 0) + return -ENODEV; + + memset(&subslice_info, 0, sizeof(subslice_info)); + subslice_info.max_slices = sseu->max_slices; + subslice_info.max_subslices = sseu->max_subslices; + + data_length = subslice_info.max_slices * + DIV_ROUND_UP(subslice_info.max_subslices, +sizeof(sseu->subslice_mask[0]) * BITS_PER_BYTE); + + return copy_query_data(query_item, + &subslice_info, sizeof(subslice_info), + sseu->subslice_mask, data_length); +} + +static int query_eu_info(struct drm_i915_private *dev_priv, +struct drm_i915_query_item *query_item) +{ + const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu; + struct drm_i915_query_eu_info eu_info; + u32 data_length; + + if (query_item->flags != 0) + return -EINVAL; + + if (sseu->max_slices == 0) + return -ENODEV; + + memset(&eu_info, 0, sizeof(eu_info)); + eu_info.max_slices =
[Intel-gfx] [PATCH v9 3/6] drm/i915/debugfs: add rcs topology entry
While the end goal is to make this information available to userspace through a new ioctl, there is no reason we can't display it in a human readable fashion through debugfs. slice0: 3 subslice(s) (0x7): subslice0: 8 EUs (0xff) subslice1: 8 EUs (0xff) subslice2: 8 EUs (0xff) subslice3: 0 EUs (0x0) slice1: 3 subslice(s) (0x7): subslice0: 8 EUs (0xff) subslice1: 8 EUs (0xff) subslice2: 8 EUs (0xff) subslice3: 0 EUs (0x0) slice2: 3 subslice(s) (0x7): subslice0: 8 EUs (0xff) subslice1: 8 EUs (0xff) subslice2: 8 EUs (0xff) subslice3: 0 EUs (0x0) v2: Reformat debugfs printing (Tvrtko) Use the new EU mask helper (Tvrtko) v3: Move printing code to intel_device_info.c to be shared with error state (Michal) Suggested-by: Chris Wilson Signed-off-by: Lionel Landwerlin Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_debugfs.c | 11 +++ drivers/gpu/drm/i915/intel_device_info.c | 25 + drivers/gpu/drm/i915/intel_device_info.h | 2 ++ 3 files changed, 38 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index e41a19b7d7bb..c3a44a54a0ba 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -3166,6 +3166,16 @@ static int i915_engine_info(struct seq_file *m, void *unused) return 0; } +static int i915_rcs_topology(struct seq_file *m, void *unused) +{ + struct drm_i915_private *dev_priv = node_to_i915(m->private); + struct drm_printer p = drm_seq_file_printer(m); + + intel_device_info_dump_topology(&INTEL_INFO(dev_priv)->sseu, &p); + + return 0; +} + static int i915_shrinker_info(struct seq_file *m, void *unused) { struct drm_i915_private *i915 = node_to_i915(m->private); @@ -4696,6 +4706,7 @@ static const struct drm_info_list i915_debugfs_list[] = { {"i915_dmc_info", i915_dmc_info, 0}, {"i915_display_info", i915_display_info, 0}, {"i915_engine_info", i915_engine_info, 0}, + {"i915_rcs_topology", i915_rcs_topology, 0}, {"i915_shrinker_info", i915_shrinker_info, 0}, {"i915_shared_dplls_info", i915_shared_dplls_info, 0}, {"i915_dp_mst_info", i915_dp_mst_info, 0}, diff --git a/drivers/gpu/drm/i915/intel_device_info.c b/drivers/gpu/drm/i915/intel_device_info.c index ed14994527fc..bc08a5ef0ba2 100644 --- a/drivers/gpu/drm/i915/intel_device_info.c +++ b/drivers/gpu/drm/i915/intel_device_info.c @@ -123,6 +123,31 @@ void intel_device_info_dump(const struct intel_device_info *info, intel_device_info_dump_flags(info, p); } +void intel_device_info_dump_topology(const struct sseu_dev_info *sseu, +struct drm_printer *p) +{ + int s, ss; + + if (sseu->max_slices == 0) { + drm_printf(p, "Unavailable\n"); + return; + } + + for (s = 0; s < sseu->max_slices; s++) { + drm_printf(p, "slice%d: %u subslice(s) (0x%hhx):\n", + s, hweight8(sseu->subslice_mask[s]), + sseu->subslice_mask[s]); + + for (ss = 0; ss < sseu->max_subslices; ss++) { + u8 enabled_eus = sseu_get_eus(sseu, s, ss); + + drm_printf(p, "\tsubslice%d: %u EUs (0x%hhx)\n", + ss, hweight8(enabled_eus), enabled_eus); + } + } +} + + static u16 compute_eu_total(const struct sseu_dev_info *sseu) { u16 i, total = 0; diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h index 36e0df87862d..701888162944 100644 --- a/drivers/gpu/drm/i915/intel_device_info.h +++ b/drivers/gpu/drm/i915/intel_device_info.h @@ -220,5 +220,7 @@ void intel_device_info_dump_flags(const struct intel_device_info *info, struct drm_printer *p); void intel_device_info_dump_runtime(const struct intel_device_info *info, struct drm_printer *p); +void intel_device_info_dump_topology(const struct sseu_dev_info *sseu, +struct drm_printer *p); #endif -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 2/6] drm/i915/debugfs: reuse max slice/subslices already stored in sseu
Now that we have that information in topology fields, let's just reused it. v2: Style tweaks (Tvrtko) Signed-off-by: Lionel Landwerlin Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_debugfs.c | 27 +++ 1 file changed, 11 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 684551114965..e41a19b7d7bb 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -4304,11 +4304,11 @@ static void gen10_sseu_device_status(struct drm_i915_private *dev_priv, struct sseu_dev_info *sseu) { const struct intel_device_info *info = INTEL_INFO(dev_priv); - int s_max = 6, ss_max = 4; int s, ss; - u32 s_reg[s_max], eu_reg[2 * s_max], eu_mask[2]; + u32 s_reg[info->sseu.max_slices]; + u32 eu_reg[2 * info->sseu.max_subslices], eu_mask[2]; - for (s = 0; s < s_max; s++) { + for (s = 0; s < info->sseu.max_slices; s++) { /* * FIXME: Valid SS Mask respects the spec and read * only valid bits for those registers, excluding reserverd @@ -4330,7 +4330,7 @@ static void gen10_sseu_device_status(struct drm_i915_private *dev_priv, GEN9_PGCTL_SSB_EU210_ACK | GEN9_PGCTL_SSB_EU311_ACK; - for (s = 0; s < s_max; s++) { + for (s = 0; s < info->sseu.max_slices; s++) { if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0) /* skip disabled slice */ continue; @@ -4338,7 +4338,7 @@ static void gen10_sseu_device_status(struct drm_i915_private *dev_priv, sseu->slice_mask |= BIT(s); sseu->subslice_mask[s] = info->sseu.subslice_mask[s]; - for (ss = 0; ss < ss_max; ss++) { + for (ss = 0; ss < info->sseu.max_subslices; ss++) { unsigned int eu_cnt; if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss @@ -4358,17 +4358,12 @@ static void gen10_sseu_device_status(struct drm_i915_private *dev_priv, static void gen9_sseu_device_status(struct drm_i915_private *dev_priv, struct sseu_dev_info *sseu) { - int s_max = 3, ss_max = 4; + const struct intel_device_info *info = INTEL_INFO(dev_priv); int s, ss; - u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2]; - - /* BXT has a single slice and at most 3 subslices. */ - if (IS_GEN9_LP(dev_priv)) { - s_max = 1; - ss_max = 3; - } + u32 s_reg[info->sseu.max_slices]; + u32 eu_reg[2 * info->sseu.max_subslices], eu_mask[2]; - for (s = 0; s < s_max; s++) { + for (s = 0; s < info->sseu.max_slices; s++) { s_reg[s] = I915_READ(GEN9_SLICE_PGCTL_ACK(s)); eu_reg[2*s] = I915_READ(GEN9_SS01_EU_PGCTL_ACK(s)); eu_reg[2*s + 1] = I915_READ(GEN9_SS23_EU_PGCTL_ACK(s)); @@ -4383,7 +4378,7 @@ static void gen9_sseu_device_status(struct drm_i915_private *dev_priv, GEN9_PGCTL_SSB_EU210_ACK | GEN9_PGCTL_SSB_EU311_ACK; - for (s = 0; s < s_max; s++) { + for (s = 0; s < info->sseu.max_slices; s++) { if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0) /* skip disabled slice */ continue; @@ -4394,7 +4389,7 @@ static void gen9_sseu_device_status(struct drm_i915_private *dev_priv, sseu->subslice_mask[s] = INTEL_INFO(dev_priv)->sseu.subslice_mask[s]; - for (ss = 0; ss < ss_max; ss++) { + for (ss = 0; ss < info->sseu.max_subslices; ss++) { unsigned int eu_cnt; if (IS_GEN9_LP(dev_priv)) { -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 1/6] drm/i915: store all subslice masks
Up to now, subslice mask was assumed to be uniform across slices. But starting with Cannonlake, slices can be asymmetric (for example slice0 has different number of subslices as slice1+). This change stores all subslices masks for all slices rather than having a single mask that applies to all slices. v2: Rework how we store total numbers in sseu_dev_info (Tvrtko) Fix CHV eu masks, was reading disabled as enabled (Tvrtko) Readability changes (Tvrtko) Add EU index helper (Tvrtko) v3: Turn ALIGN(v, 8) / 8 into DIV_ROUND_UP(v, BITS_PER_BYTE) (Tvrtko) Reuse sseu_eu_idx() for setting eu_mask on CHV (Tvrtko) Reformat debug prints for subslices (Tvrtko) v4: Change eu_mask helper into sseu_set_eus() (Tvrtko) Signed-off-by: Lionel Landwerlin Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_debugfs.c | 25 ++-- drivers/gpu/drm/i915/i915_drv.c | 2 +- drivers/gpu/drm/i915/intel_device_info.c | 201 +++ drivers/gpu/drm/i915/intel_device_info.h | 47 +++- drivers/gpu/drm/i915/intel_lrc.c | 2 +- drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +- 6 files changed, 216 insertions(+), 63 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index cc659b4b2a45..684551114965 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -4289,7 +4289,7 @@ static void cherryview_sseu_device_status(struct drm_i915_private *dev_priv, continue; sseu->slice_mask = BIT(0); - sseu->subslice_mask |= BIT(ss); + sseu->subslice_mask[0] |= BIT(ss); eu_cnt = ((sig1[ss] & CHV_EU08_PG_ENABLE) ? 0 : 2) + ((sig1[ss] & CHV_EU19_PG_ENABLE) ? 0 : 2) + ((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) + @@ -4336,7 +4336,7 @@ static void gen10_sseu_device_status(struct drm_i915_private *dev_priv, continue; sseu->slice_mask |= BIT(s); - sseu->subslice_mask = info->sseu.subslice_mask; + sseu->subslice_mask[s] = info->sseu.subslice_mask[s]; for (ss = 0; ss < ss_max; ss++) { unsigned int eu_cnt; @@ -4391,8 +4391,8 @@ static void gen9_sseu_device_status(struct drm_i915_private *dev_priv, sseu->slice_mask |= BIT(s); if (IS_GEN9_BC(dev_priv)) - sseu->subslice_mask = - INTEL_INFO(dev_priv)->sseu.subslice_mask; + sseu->subslice_mask[s] = + INTEL_INFO(dev_priv)->sseu.subslice_mask[s]; for (ss = 0; ss < ss_max; ss++) { unsigned int eu_cnt; @@ -4402,7 +4402,7 @@ static void gen9_sseu_device_status(struct drm_i915_private *dev_priv, /* skip disabled subslice */ continue; - sseu->subslice_mask |= BIT(ss); + sseu->subslice_mask[s] |= BIT(ss); } eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] & @@ -4424,9 +4424,12 @@ static void broadwell_sseu_device_status(struct drm_i915_private *dev_priv, sseu->slice_mask = slice_info & GEN8_LSLICESTAT_MASK; if (sseu->slice_mask) { - sseu->subslice_mask = INTEL_INFO(dev_priv)->sseu.subslice_mask; sseu->eu_per_subslice = INTEL_INFO(dev_priv)->sseu.eu_per_subslice; + for (s = 0; s < fls(sseu->slice_mask); s++) { + sseu->subslice_mask[s] = + INTEL_INFO(dev_priv)->sseu.subslice_mask[s]; + } sseu->eu_total = sseu->eu_per_subslice * sseu_subslice_total(sseu); @@ -4445,6 +4448,7 @@ static void i915_print_sseu_info(struct seq_file *m, bool is_available_info, { struct drm_i915_private *dev_priv = node_to_i915(m->private); const char *type = is_available_info ? "Available" : "Enabled"; + int s; seq_printf(m, " %s Slice Mask: %04x\n", type, sseu->slice_mask); @@ -4452,10 +4456,11 @@ static void i915_print_sseu_info(struct seq_file *m, bool is_available_info, hweight8(sseu->slice_mask)); seq_printf(m, " %s Subslice Total: %u\n", type, sseu_subslice_total(sseu)); - seq_printf(m, " %s Subslice Mask: %04x\n", type, - sseu->subslice_mask); - seq_printf(m, " %s Subslice Per Slice: %u\n", type, - hweight8(sseu->subslice_mask)); + for (s = 0; s < fls(sseu->slice_mask); s++) { + seq_printf(m, " %s Slice%i %u subslices, mask=%04x\n", type, + s, hweight8(sseu->subslice_mask[s]
[Intel-gfx] [PATCH v9 0/6] drm/i915: expose RCS topology to userspace
Hi all, This looks like the last iteration :) Cheers, Lionel Landwerlin (6): drm/i915: store all subslice masks drm/i915/debugfs: reuse max slice/subslices already stored in sseu drm/i915/debugfs: add rcs topology entry drm/i915: add rcs topology to error state drm/i915: add query uAPI drm/i915: expose rcs topology through query uAPI drivers/gpu/drm/i915/Makefile| 1 + drivers/gpu/drm/i915/i915_debugfs.c | 63 + drivers/gpu/drm/i915/i915_drv.c | 3 +- drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_gpu_error.c| 1 + drivers/gpu/drm/i915/i915_query.c| 177 drivers/gpu/drm/i915/intel_device_info.c | 226 --- drivers/gpu/drm/i915/intel_device_info.h | 49 ++- drivers/gpu/drm/i915/intel_lrc.c | 2 +- drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +- include/uapi/drm/i915_drm.h | 105 ++ 11 files changed, 553 insertions(+), 79 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_query.c -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH] igt/core: Initial simple interleaved kmsg filtering
Needs to be beefed up so that dmesg warning (and worse) are re-emmitted as IGT_LOG_WARN. But only if they match one of our filters (which we should probably allow to be extended, e.g. depending upon which driver has been openened). This also requires that we at least parse the basic of kmsg lines (adjusting the timestamp to match our own would be real cool). v2: - Seek to the end of the kmsg buffer before starting the capturing. - Increase linebuffer to avoid dmesg drowning out all the tests messages. v3: Unlazy slightly and implement semi-correct kmsg parsing. Signed-off-by: Daniel Vetter --- lib/igt_core.c | 56 +++- 1 file changed, 55 insertions(+), 1 deletion(-) diff --git a/lib/igt_core.c b/lib/igt_core.c index aaafc1df6b46..bcdc8abb41a7 100644 --- a/lib/igt_core.c +++ b/lib/igt_core.c @@ -293,7 +293,7 @@ static const char *command_str; static char* igt_debug_log_domain_filter; static struct { - char *entries[256]; + char *entries[2000]; uint8_t start, end; } log_buffer; static pthread_mutex_t log_buffer_mutex = PTHREAD_MUTEX_INITIALIZER; @@ -581,6 +581,58 @@ static void oom_adjust_for_doom(void) } +static void *kmsg_capture(void *arg) +{ + int kmsg_capture_fd = (uintptr_t) arg; + FILE *kmsg_file = fdopen(kmsg_capture_fd, "r"); + char *line = NULL; + size_t line_len = 0; + ssize_t read; + + while ((read = getline(&line, &line_len, kmsg_file))) { + unsigned flags; + unsigned long long seq, ts_usec; + char continuation; + enum igt_log_level level; + + sscanf(line, "%u,%llu,%llu,%c;", &flags, + &seq, &ts_usec, &continuation); + + if ((flags & 0x7) <= 4) + level = IGT_LOG_WARN; + else + level = IGT_LOG_DEBUG; + + igt_log("dmesg", level, "[%llu.%06llu], %s", + ts_usec / 100, + ts_usec % 100, + index(line, ';') + 1); + } + + igt_warn("ran out of dmesg, this shouldn't happen\n"); + + return NULL; +} + +static void start_kmsg_recording(void) +{ + static pthread_t kmsg_capture_thread; + int kmsg_capture_fd; + + kmsg_capture_fd = open("/dev/kmsg", + O_RDONLY | O_CLOEXEC); + + if (kmsg_capture_fd < 0) { + igt_info("no dmesg capturing\n"); + return; + } + + lseek(kmsg_capture_fd, 0, SEEK_END); + + pthread_create(&kmsg_capture_thread, NULL, + kmsg_capture, (void *)(uintptr_t) kmsg_capture_fd); +} + #ifdef HAVE_GLIB static void common_init_config(void) { @@ -814,6 +866,8 @@ out: kmsg(KERN_INFO "[IGT] %s: executing\n", command_str); print_version(); + start_kmsg_recording(); + sync(); oom_adjust_for_doom(); ftrace_dump_on_oops(true); -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 85/99] btrfs: Remove unused spinlock
On Wed, Jan 17, 2018 at 12:21:49PM -0800, Matthew Wilcox wrote: > From: Matthew Wilcox > > The reada_lock in struct btrfs_device was only initialised, and not > actually used. That's good because there's another lock also called > reada_lock in the btrfs_fs_info that was quite heavily used. Remove > this one. > > Signed-off-by: Matthew Wilcox I'll pick this one now, thanks. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add tracking for CDCLK bypass frequency
On Wed, Jan 17, 2018 at 07:56:22PM +0200, Ville Syrjälä wrote: > On Wed, Jan 17, 2018 at 07:25:08PM +0200, Imre Deak wrote: > > The CDCLK bypass frequency can vary on upcoming platforms, so prepare > > for that now by tracking its value in the CDCLK state. > > > > Currently on BDW+ the bypass frequency is always the reference clock and > > I didn't bother with earlier platforms since it's not all that clear > > what's the bypass clock on those. > > > > I also didn't bother adding support for changing this frequency, since > > atm I don't see any need for it. > > > > Suggested-by: Ville Syrjälä > > Cc: Ville Syrjälä > > Signed-off-by: Imre Deak > > --- > > drivers/gpu/drm/i915/i915_drv.h| 2 +- > > drivers/gpu/drm/i915/intel_cdclk.c | 35 ++- > > 2 files changed, 19 insertions(+), 18 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h > > b/drivers/gpu/drm/i915/i915_drv.h > > index c42015b05b47..49ccfc397feb 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.h > > +++ b/drivers/gpu/drm/i915/i915_drv.h > > @@ -1791,7 +1791,7 @@ struct i915_oa_ops { > > }; > > > > struct intel_cdclk_state { > > - unsigned int cdclk, vco, ref; > > + unsigned int cdclk, vco, ref, bypass; > > u8 voltage_level; > > }; > > > > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c > > b/drivers/gpu/drm/i915/intel_cdclk.c > > index ca36321eafac..f46a61d423a1 100644 > > --- a/drivers/gpu/drm/i915/intel_cdclk.c > > +++ b/drivers/gpu/drm/i915/intel_cdclk.c > > @@ -858,7 +858,7 @@ static void skl_get_cdclk(struct drm_i915_private > > *dev_priv, > > > > skl_dpll0_update(dev_priv, cdclk_state); > > > > - cdclk_state->cdclk = cdclk_state->ref; > > + cdclk_state->cdclk = cdclk_state->bypass = cdclk_state->ref; > > My first instinct would have been to populate bypass in the PLL > readout function. I guess I just think of the bypass clock more > as a feature of the PLL. But I suppose it really doesn't matter > where we do this. > > Reviewed-by: Ville Syrjälä My thinking was that it's CDCLK choosing either the PLL output or the bypass clock as a source (while refclk is connected directly both to the PLL and the CDCLK as a source); but yes doesn't matter in practice where it's inited, I leave it as-is for now. Thanks for the review, pushed to drm-tip. --Imre > > > > > if (cdclk_state->vco == 0) > > goto out; > > @@ -1006,7 +1006,7 @@ static void skl_set_cdclk(struct drm_i915_private > > *dev_priv, > > /* Choose frequency for this cdclk */ > > switch (cdclk) { > > default: > > - WARN_ON(cdclk != dev_priv->cdclk.hw.ref); > > + WARN_ON(cdclk != dev_priv->cdclk.hw.bypass); > > WARN_ON(vco != 0); > > /* fall through */ > > case 308571: > > @@ -1085,7 +1085,7 @@ static void skl_sanitize_cdclk(struct > > drm_i915_private *dev_priv) > > > > /* Is PLL enabled and locked ? */ > > if (dev_priv->cdclk.hw.vco == 0 || > > - dev_priv->cdclk.hw.cdclk == dev_priv->cdclk.hw.ref) > > + dev_priv->cdclk.hw.cdclk == dev_priv->cdclk.hw.bypass) > > goto sanitize; > > > > /* DPLL okay; verify the cdclock > > @@ -1159,7 +1159,7 @@ void skl_uninit_cdclk(struct drm_i915_private > > *dev_priv) > > { > > struct intel_cdclk_state cdclk_state = dev_priv->cdclk.hw; > > > > - cdclk_state.cdclk = cdclk_state.ref; > > + cdclk_state.cdclk = cdclk_state.bypass; > > cdclk_state.vco = 0; > > cdclk_state.voltage_level = skl_calc_voltage_level(cdclk_state.cdclk); > > > > @@ -1199,7 +1199,7 @@ static int bxt_de_pll_vco(struct drm_i915_private > > *dev_priv, int cdclk) > > { > > int ratio; > > > > - if (cdclk == dev_priv->cdclk.hw.ref) > > + if (cdclk == dev_priv->cdclk.hw.bypass) > > return 0; > > > > switch (cdclk) { > > @@ -1224,7 +1224,7 @@ static int glk_de_pll_vco(struct drm_i915_private > > *dev_priv, int cdclk) > > { > > int ratio; > > > > - if (cdclk == dev_priv->cdclk.hw.ref) > > + if (cdclk == dev_priv->cdclk.hw.bypass) > > return 0; > > > > switch (cdclk) { > > @@ -1268,7 +1268,7 @@ static void bxt_get_cdclk(struct drm_i915_private > > *dev_priv, > > > > bxt_de_pll_update(dev_priv, cdclk_state); > > > > - cdclk_state->cdclk = cdclk_state->ref; > > + cdclk_state->cdclk = cdclk_state->bypass = cdclk_state->ref; > > > > if (cdclk_state->vco == 0) > > goto out; > > @@ -1352,7 +1352,7 @@ static void bxt_set_cdclk(struct drm_i915_private > > *dev_priv, > > /* cdclk = vco / 2 / div{1,1.5,2,4} */ > > switch (DIV_ROUND_CLOSEST(vco, cdclk)) { > > default: > > - WARN_ON(cdclk != dev_priv->cdclk.hw.ref); > > + WARN_ON(cdclk != dev_priv->cdclk.hw.bypass); > > WARN_ON(vco != 0); > > /* fall through */ > > case 2: > > @@ -1425,7 +1425,7 @@ static void bxt_sanitize_cdclk(struct > > drm_i915_private *dev_priv) > >
Re: [Intel-gfx] [PATCH 15/15] drm/i915: Add NV12 support to intel_framebuffer_init
Op 20-01-18 om 22:45 schreef Vidya Srinivas: > From: Chandra Konduru > > This patch adds NV12 as supported format > to intel_framebuffer_init and performs various checks. > > v2: > -Fix an issue in checks added (Chandra Konduru) > > v3: rebased (me) > > v4: Review comments by Ville addressed > Added platform check for NV12 in intel_framebuffer_init > Removed offset checks for NV12 case > > v5: Addressed review comments by Clinton A Taylor > This NV12 support only correctly works on SKL. > Plane color space conversion is different on GLK and later platforms > causing the colors to display incorrectly. > Ville's plane color space property patch series > in review will fix this issue. > - Restricted the NV12 case in intel_framebuffer_init to > SKL and BXT only. > > v6: Rebased (me) > > v7: Addressed review comments by Ville > Restricting the NV12 to BXT for now. > > v8: Rebased (me) > Restricting the NV12 changes to BXT and KBL for now. > > v9: Rebased (me) > > Tested-by: Clinton Taylor > Reviewed-by: Clinton Taylor > Signed-off-by: Chandra Konduru > Signed-off-by: Nabendu Maiti > Signed-off-by: Vidya Srinivas > --- > drivers/gpu/drm/i915/intel_display.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 88bc750..db42448 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -14005,6 +14005,14 @@ static int intel_framebuffer_init(struct > intel_framebuffer *intel_fb, > goto err; > } > break; > + case DRM_FORMAT_NV12: > + if (!IS_BROXTON(dev_priv) && !IS_KABYLAKE(dev_priv)) { > + DRM_DEBUG_KMS("unsupported pixel format: %s\n", > + drm_get_format_name(mode_cmd->pixel_format, > + &format_name)); > + goto err; > + } > + break; I started implementing the IGT side of this but as far as I can tell, the specification will allow you to set different handles for each plane. But intel doesn't support this right now.. Could this assumption be fixed first? There's nothing stopping the drm core or applications from having separate buffer objects, and for blitting it would make sense to have a R8 plane for Y', and a R8G8 plane for Cb'Cr' Probably needs i915 to compile with something like below, then handling all corner cases.. --- diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 39c3bfa74d67..4eeb94fbfdd6 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -186,7 +186,7 @@ enum intel_output_type { struct intel_framebuffer { struct drm_framebuffer base; - struct drm_i915_gem_object *obj; + struct drm_i915_gem_object *objs[2]; struct intel_rotation_info rot_info; /* for each plane in the normal GTT view */ @@ -996,7 +996,7 @@ struct cxsr_latency { #define to_intel_framebuffer(x) container_of(x, struct intel_framebuffer, base) #define to_intel_plane(x) container_of(x, struct intel_plane, base) #define to_intel_plane_state(x) container_of(x, struct intel_plane_state, base) -#define intel_fb_obj(x) (x ? to_intel_framebuffer(x)->obj : NULL) +#define intel_fb_obj(x, n) (x ? to_intel_framebuffer(x)->objs[n] : NULL) struct intel_hdmi { i915_reg_t hdmi_reg; ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 7/7] drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON
On Thu, Jan 18, 2018 at 11:57:09AM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 1/17/2018 11:57 PM, Ville Syrjälä wrote: > > On Fri, Jan 05, 2018 at 03:15:35PM +0530, Shashank Sharma wrote: > >> LSPCON chips can generate YCBCR outputs, if asked nicely :). > >> > >> In order to generate YCBCR 4:2:0 outputs, a source must: > >> - send YCBCR 4:4:4 signals to LSPCON > >> - program color space as 4:2:0 in AVI infoframes > >> > >> Whereas for YCBCR 4:4:4 outputs, the source must: > >> - send YCBCR 4:4:4 signals to LSPCON > >> - program color space as 4:4:4 in AVI infoframes > >> > >> So for both 4:2:0 as well as 4:4:4 outputs, we are driving the > >> pipe for YCBCR 4:4:4 output, but AVI infoframe's color space > >> information indicates LSPCON FW to start scaling down from YCBCR > >> 4:4:4 and generate YCBCR 4:2:0 output. As the scaling is done by > >> LSPCON device, we need not to reserve a scaler for 4:2:0 outputs. > >> > >> V2: rebase > >> V3: Addressed review comments from Ville > >> - add enum crtc_output_format instead of bool ycbcr420 > >> - use crtc_output_format=4:4:4 for modeset of LSPCON 4:2:0 output > >>cases in this way we will have YCBCR 4:4:4 framework ready (except > >>the ABI part) > >> > >> Cc: Ville Syrjala > >> Cc: Maarten Lankhorst > >> Signed-off-by: Shashank Sharma > >> --- > >> drivers/gpu/drm/i915/i915_reg.h | 2 ++ > >> drivers/gpu/drm/i915/intel_ddi.c| 7 +++ > >> drivers/gpu/drm/i915/intel_dp.c | 10 ++ > >> drivers/gpu/drm/i915/intel_drv.h| 2 ++ > >> drivers/gpu/drm/i915/intel_lspcon.c | 28 > >> 5 files changed, 49 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/i915/i915_reg.h > >> b/drivers/gpu/drm/i915/i915_reg.h > >> index 966e4df..45ee264 100644 > >> --- a/drivers/gpu/drm/i915/i915_reg.h > >> +++ b/drivers/gpu/drm/i915/i915_reg.h > >> @@ -8547,6 +8547,8 @@ enum skl_power_gate { > >> #define TRANS_MSA_MISC(tran) _MMIO_TRANS2(tran, _TRANSA_MSA_MISC) > >> > >> #define TRANS_MSA_SYNC_CLK (1<<0) > >> +#define TRANS_MSA_SAMPLING_444(2<<1) > >> +#define TRANS_MSA_CLRSP_YCBCR(2<<3) > >> #define TRANS_MSA_6_BPC (0<<5) > >> #define TRANS_MSA_8_BPC (1<<5) > >> #define TRANS_MSA_10_BPC(2<<5) > >> diff --git a/drivers/gpu/drm/i915/intel_ddi.c > >> b/drivers/gpu/drm/i915/intel_ddi.c > >> index 7b89f2a..7616f6f 100644 > >> --- a/drivers/gpu/drm/i915/intel_ddi.c > >> +++ b/drivers/gpu/drm/i915/intel_ddi.c > >> @@ -1499,6 +1499,13 @@ void intel_ddi_set_pipe_settings(const struct > >> intel_crtc_state *crtc_state) > >>break; > >>} > >> > >> + /* > >> + * As per DP 1.2 spec section 2.3.4.3 while sending > >> + * YCBCR 444 signals we should program MSA MISC1/0 fields with > >> + * colorspace information. > >> + */ > >> + if (crtc_state->output_format == CRTC_OUTPUT_YCBCR444) > >> + temp |= TRANS_MSA_SAMPLING_444 | TRANS_MSA_CLRSP_YCBCR; > > This fails to state that we're indicating BT.601 encoding. I think we > > should spell that out explicitly. > Agree, I will add this in comments. > >>I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp); > >> } > >> > >> diff --git a/drivers/gpu/drm/i915/intel_dp.c > >> b/drivers/gpu/drm/i915/intel_dp.c > >> index 35c5299..3bf82ea 100644 > >> --- a/drivers/gpu/drm/i915/intel_dp.c > >> +++ b/drivers/gpu/drm/i915/intel_dp.c > >> @@ -1613,6 +1613,7 @@ intel_dp_compute_config(struct intel_encoder > >> *encoder, > >>struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); > >>struct drm_display_mode *adjusted_mode = > >> &pipe_config->base.adjusted_mode; > >>struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base); > >> + struct intel_lspcon *lspcon = enc_to_intel_lspcon(&encoder->base); > >>enum port port = encoder->port; > >>struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc); > >>struct intel_connector *intel_connector = intel_dp->attached_connector; > >> @@ -1642,6 +1643,15 @@ intel_dp_compute_config(struct intel_encoder > >> *encoder, > >>if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv) && port != PORT_A) > >>pipe_config->has_pch_encoder = true; > >> > >> + if (lspcon->active) { > >> + struct drm_connector *connector = &intel_connector->base; > >> + > >> + if (lspcon_ycbcr420_config(connector, pipe_config)) { > >> + pipe_config->output_format = CRTC_OUTPUT_YCBCR444; > > I think I'd like to see all compute_config hooks explicitly set the > > outout_format (to RGB usually obviously). > That's the one I was talking about in previous patch. If we keep > output_format_RGB = 0, we need > not to do this, as reset of the pipe_config will automatically make it RGB. IMO either we have INVALID=0 so that we use it to catch readout fails, or we have no INVALID. Other options make little sense to me. > >> +
[Intel-gfx] ✓ Fi.CI.BAT: success for khungtaskd: Kick stuck processes
== Series Details == Series: khungtaskd: Kick stuck processes URL : https://patchwork.freedesktop.org/series/36677/ State : success == Summary == Series 36677v1 khungtaskd: Kick stuck processes https://patchwork.freedesktop.org/api/1.0/series/36677/revisions/1/mbox/ Test debugfs_test: Subgroup read_all_entries: dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989 incomplete -> PASS (fi-snb-2520m) fdo#103713 +1 Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:418s 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:486s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:280s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:486s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:486s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:473s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:452s fi-elk-e7500 total:224 pass:168 dwarn:10 dfail:0 fail:0 skip:45 fi-gdg-551 total:288 pass:180 dwarn:0 dfail:0 fail:0 skip:108 time:276s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:512s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:392s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:410s 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:461s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:411s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:457s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:503s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:453s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:503s 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:431s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:508s 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:484s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:484s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:430s 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:399s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:563s fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:466s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:418s 68669ade8e500355455124fe96b34614ddc1777b drm-tip: 2018y-01m-18d-12h-01m-38s UTC integration manifest 8e187851b2da khungtaskd: Kick stuck processes == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7709/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 5/5] lib/core: report subtests that hit an igt_warning as WARNING
This is another piece of prep work to push the detection of dmesg warnings into igt itself, so that we can correctly report dmesg issue on a per-subtest basis even when running the entire binary. Signed-off-by: Daniel Vetter --- lib/igt_core.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/lib/igt_core.c b/lib/igt_core.c index 65b394581e8f..d61d32295bb2 100644 --- a/lib/igt_core.c +++ b/lib/igt_core.c @@ -1021,6 +1021,7 @@ void __igt_subtest_group_restore(int save) static bool skipped_one = false; static bool succeeded_one = false; static bool failed_one = false; +static bool warned = false; static void exit_subtest(const char *) __attribute__((noreturn)); static void exit_subtest(const char *result) @@ -1037,6 +1038,7 @@ static void exit_subtest(const char *result) igt_terminate_spin_batches(); in_subtest = NULL; + warned = false; siglongjmp(igt_subtest_jmpbuf, 1); } @@ -1126,7 +1128,7 @@ void igt_success(void) { succeeded_one = true; if (in_subtest) - exit_subtest("SUCCESS"); + exit_subtest(warned ? "WARNING" : "SUCCESS"); } /** @@ -2120,6 +2122,9 @@ void igt_vlog(const char *domain, enum igt_log_level level, const char *format, if (list_subtests && level <= IGT_LOG_WARN) return; + if (level >= IGT_LOG_WARN) + warned = true; + if (vasprintf(&line, format, args) == -1) return; -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 4/5] igt/core: Initial simple interleaved kmsg filtering
Needs to be beefed up so that dmesg warning (and worse) are re-emmitted as IGT_LOG_WARN. But only if they match one of our filters (which we should probably allow to be extended, e.g. depending upon which driver has been openened). This also requires that we at least parse the basic of kmsg lines (adjusting the timestamp to match our own would be real cool). v2: - Seek to the end of the kmsg buffer before starting the capturing. - Increase linebuffer to avoid dmesg drowning out all the tests messages. Signed-off-by: Daniel Vetter --- lib/igt_core.c | 41 - 1 file changed, 40 insertions(+), 1 deletion(-) diff --git a/lib/igt_core.c b/lib/igt_core.c index aaafc1df6b46..65b394581e8f 100644 --- a/lib/igt_core.c +++ b/lib/igt_core.c @@ -293,7 +293,7 @@ static const char *command_str; static char* igt_debug_log_domain_filter; static struct { - char *entries[256]; + char *entries[2000]; uint8_t start, end; } log_buffer; static pthread_mutex_t log_buffer_mutex = PTHREAD_MUTEX_INITIALIZER; @@ -581,6 +581,43 @@ static void oom_adjust_for_doom(void) } +static void *kmsg_capture(void *arg) +{ + int kmsg_capture_fd = (uintptr_t) arg; + FILE *kmsg_file = fdopen(kmsg_capture_fd, "r"); + char *line = NULL; + size_t line_len = 0; + ssize_t read; + + while ((read = getline(&line, &line_len, kmsg_file))) { + /* FIXME: Set IGT_LOG_WARN for dmesg-warnings */ + igt_log("dmesg", IGT_LOG_DEBUG, "%i, %s", line[0], line+1); + } + + igt_warn("ran out of dmesg, this shouldn't happen\n"); + + return NULL; +} + +static void start_kmsg_recording(void) +{ + static pthread_t kmsg_capture_thread; + int kmsg_capture_fd; + + kmsg_capture_fd = open("/dev/kmsg", + O_RDONLY | O_CLOEXEC); + + if (kmsg_capture_fd < 0) { + igt_info("no dmesg capturing\n"); + return; + } + + lseek(kmsg_capture_fd, 0, SEEK_END); + + pthread_create(&kmsg_capture_thread, NULL, + kmsg_capture, (void *)(uintptr_t) kmsg_capture_fd); +} + #ifdef HAVE_GLIB static void common_init_config(void) { @@ -814,6 +851,8 @@ out: kmsg(KERN_INFO "[IGT] %s: executing\n", command_str); print_version(); + start_kmsg_recording(); + sync(); oom_adjust_for_doom(); ftrace_dump_on_oops(true); -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 1/5] tests/sw_sync: use igt_fork_helper
I'll need to wrap a bit of magic around all the fork() calls in our tests. Simplest way to get there is to roll out the existing helpers, which even saves a bit of boilerplate code. Cc: Robert Foss Signed-off-by: Daniel Vetter --- tests/sw_sync.c | 54 ++ 1 file changed, 18 insertions(+), 36 deletions(-) diff --git a/tests/sw_sync.c b/tests/sw_sync.c index 20dfbbb98f58..24974a2f5e4e 100644 --- a/tests/sw_sync.c +++ b/tests/sw_sync.c @@ -175,6 +175,7 @@ static void test_sync_busy_fork_unixsocket(void) int timeline; int skip = 0; int sv[2]; + struct igt_helper_process proc; timeline = sw_sync_timeline_create(); @@ -185,9 +186,7 @@ static void test_sync_busy_fork_unixsocket(void) goto out; } - switch (fork()) { - case 0: - { + igt_fork_helper(&proc) { /* Child process */ int socket = sv[1]; int socket_timeline; @@ -213,17 +212,8 @@ static void test_sync_busy_fork_unixsocket(void) /* Advance timeline from 0 -> 1 */ sw_sync_timeline_inc(socket_timeline, 1); - - _Exit(0); - break; - } - case -1: - { - /* Failed fork */ - skip = 1; - break; } - default: + { /* Parent process */ int socket = sv[0]; @@ -252,15 +242,14 @@ static void test_sync_busy_fork_unixsocket(void) if (sendmsg(socket, &msg, 0) < 0) { skip = 1; - goto out; + } else { + igt_assert_f(sync_fence_wait(fence, 2*1000) == 0, +"Fence not signaled (timeline value 1 fence seqno 1)\n"); } - - igt_assert_f(sync_fence_wait(fence, 2*1000) == 0, -"Fence not signaled (timeline value 1 fence seqno 1)\n"); - break; - } } + igt_stop_helper(&proc); + out: close(fence); close(timeline); @@ -272,32 +261,25 @@ static void test_sync_busy_fork(void) int fence; int timeline; int skip = 0; + struct igt_helper_process proc; timeline = sw_sync_timeline_create(); fence = sw_sync_timeline_create_fence(timeline, 1); - switch (fork()) { - case 0: - /* Child process */ + igt_fork_helper(&proc) { usleep(1*1000*1000); /* Advance timeline from 0 -> 1 */ sw_sync_timeline_inc(timeline, 1); - _Exit(0); - break; - case -1: - /* Failed fork */ - skip = 1; - break; - default: - /* Parent process */ - igt_assert_f(sync_fence_wait(fence, 0) == -ETIME, -"Fence signaled (it should not have been signalled yet)\n"); - - igt_assert_f(sync_fence_wait(fence, 2*1000) == 0, -"Fence not signaled (timeline value 1 fence seqno 1)\n"); - break; } + igt_assert_f(sync_fence_wait(fence, 0) == -ETIME, +"Fence signaled (it should not have been signalled yet)\n"); + + igt_assert_f(sync_fence_wait(fence, 2*1000) == 0, +"Fence not signaled (timeline value 1 fence seqno 1)\n"); + + igt_stop_helper(&proc); + close(fence); close(timeline); igt_require(!skip); -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 2/5] lib/core: make logging pthread vs. fork safe
fork() is a pretty thing in a multithreaded program, it's essentially as bad as handling signals: When we fork the memory snapshot we can interrupts all other threads at any place, including while they're holding mutexes and other fun stuff. libc itself has some internal fork handlers to clear caches and make sure locks stay in a safe place (we've had plenty of fun with e.g. the pid/tid caches when a signal happens too fast). I want to put dmesg capture into igt, into a separate thread (so that dmesg capture nicely interleaves what the test is doing, +/- races), and stuff all the dmesg output into the igt logger. Which means we need to make sure that the log_buffer_mutex is in a predictable state. Since we have 2 calls to fork() extract a little helper for this. v2: Stop using fflush(NULL) - somehow this manages to hit a bug in libc when using a FILE in a separate thread (for capturing dmesg). Instead explicitly flush stderr and stdout only. Signed-off-by: Daniel Vetter --- lib/igt_core.c | 25 + 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/lib/igt_core.c b/lib/igt_core.c index 558a538d35e8..8e7f0da8a44b 100644 --- a/lib/igt_core.c +++ b/lib/igt_core.c @@ -1518,6 +1518,21 @@ static void fork_helper_exit_handler(int sig) assert(helper_process_count == 0); } +static pid_t __igt_fork_wrapper(void) +{ + pid_t ret; + + /* ensure any buffers are flushed before fork */ + fflush(stdout); + fflush(stderr); + + pthread_mutex_lock(&log_buffer_mutex); + ret = fork(); + pthread_mutex_unlock(&log_buffer_mutex); + + return ret; +} + bool __igt_fork_helper(struct igt_helper_process *proc) { pid_t pid; @@ -1540,10 +1555,7 @@ bool __igt_fork_helper(struct igt_helper_process *proc) tmp_count = exit_handler_count; exit_handler_count = 0; - /* ensure any buffers are flushed before fork */ - fflush(NULL); - - switch (pid = fork()) { + switch (pid = __igt_fork_wrapper()) { case -1: exit_handler_count = tmp_count; igt_assert(0); @@ -1642,10 +1654,7 @@ bool __igt_fork(void) igt_assert(test_children); } - /* ensure any buffers are flushed before fork */ - fflush(NULL); - - switch (test_children[num_test_children++] = fork()) { + switch (test_children[num_test_children++] = __igt_fork_wrapper()) { case -1: igt_assert(0); case 0: -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 3/5] lib/core: Don't hide non-debug message when filtering for a debug log domain
I think this is the more sensible semantics, since this allows you to still follow what's going on with the test at a high level, while filtering for a specific (or multiple specific) debug log domains. For non-debug messages log-domains technically exist, but we're not making much use of them really. Signed-off-by: Daniel Vetter --- lib/igt_core.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/lib/igt_core.c b/lib/igt_core.c index 8e7f0da8a44b..aaafc1df6b46 100644 --- a/lib/igt_core.c +++ b/lib/igt_core.c @@ -291,7 +291,7 @@ enum { static int igt_exitcode = IGT_EXIT_SUCCESS; static const char *command_str; -static char* igt_log_domain_filter; +static char* igt_debug_log_domain_filter; static struct { char *entries[256]; uint8_t start, end; @@ -757,7 +757,7 @@ static int common_init(int *argc, char **argv, case OPT_DEBUG: igt_log_level = IGT_LOG_DEBUG; if (optarg && strlen(optarg) > 0) - igt_log_domain_filter = strdup(optarg); + igt_debug_log_domain_filter = strdup(optarg); break; case OPT_LIST_SUBTESTS: if (!run_single_subtest) @@ -2104,12 +2104,12 @@ void igt_vlog(const char *domain, enum igt_log_level level, const char *format, goto out; /* check domain filter */ - if (igt_log_domain_filter) { + if (level == IGT_LOG_DEBUG && igt_debug_log_domain_filter) { /* if null domain and filter is not "application", return */ - if (!domain && strcmp(igt_log_domain_filter, "application")) + if (!domain && strcmp(igt_debug_log_domain_filter, "application")) goto out; /* else if domain and filter do not match, return */ - else if (domain && strcmp(igt_log_domain_filter, domain)) + else if (domain && strcmp(igt_debug_log_domain_filter, domain)) goto out; } -- 2.14.3 ___ 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: Avoid waitboosting on the active request (rev3)
== Series Details == Series: drm/i915: Avoid waitboosting on the active request (rev3) URL : https://patchwork.freedesktop.org/series/36453/ State : success == Summary == Series 36453v3 drm/i915: Avoid waitboosting on the active request https://patchwork.freedesktop.org/api/1.0/series/36453/revisions/3/mbox/ Test debugfs_test: Subgroup read_all_entries: incomplete -> PASS (fi-snb-2520m) fdo#103713 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:424s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:427s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:371s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:491s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:280s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:484s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:465s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:452s fi-elk-e7500 total:224 pass:168 dwarn:9 dfail:1 fail:0 skip:45 fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:276s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:509s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:396s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:399s 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:458s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:411s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:460s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:496s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:454s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:503s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:578s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:440s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:508s 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:487s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:488s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:432s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:531s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:403s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:573s fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:475s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:420s fi-bxt-j4205 failed to collect. IGT log at Patchwork_7708/fi-bxt-j4205/igt.log 68669ade8e500355455124fe96b34614ddc1777b drm-tip: 2018y-01m-18d-12h-01m-38s UTC integration manifest 8acc1a2efd04 drm/i915: Avoid waitboosting on the active request == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7708/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 HDCP1.4 implementation enhancement
== Series Details == Series: HDCP1.4 implementation enhancement URL : https://patchwork.freedesktop.org/series/36671/ State : success == Summary == Test gem_tiled_swapping: Subgroup non-threaded: incomplete -> DMESG-FAIL (shard-hsw) fdo#104218 +1 Test kms_cursor_crc: Subgroup cursor-256x256-suspend: pass -> SKIP (shard-snb) fdo#103375 +1 Subgroup cursor-128x128-suspend: skip -> PASS (shard-hsw) fdo#103540 Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-shrfb-pgflip-blt: skip -> PASS (shard-snb) fdo#101623 +1 Test kms_atomic_interruptible: Subgroup legacy-setmode: skip -> PASS (shard-snb) Test pm_rc6_residency: Subgroup rc6-accuracy: skip -> PASS (shard-snb) Test perf: Subgroup polling: fail -> PASS (shard-hsw) fdo#102252 fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-hswtotal:2680 pass:1674 dwarn:1 dfail:1 fail:11 skip:991 time:14906s shard-snbtotal:2675 pass:1287 dwarn:1 dfail:0 fail:10 skip:1377 time:7570s Blacklisted hosts: shard-apltotal:2753 pass:1716 dwarn:1 dfail:0 fail:21 skip:1015 time:13811s shard-kbltotal:2735 pass:1811 dwarn:10 dfail:0 fail:23 skip:890 time:10516s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7706/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 6/6] drm/i915: expose rcs topology through query uAPI
On 18/01/2018 13:04, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-01-18 12:46:55) On 17/01/2018 15:39, Lionel Landwerlin wrote: + + if (query_item->length == 0) + return total_length; + + if (query_item->length < total_length) + return -EINVAL; Did we talk about whether this check should be != or < yet? != would sound safer to me, or you want to allow extending the queries in the future and keeping the same id? This is me, because I like read(buf, len) style behaviour that lets me pass in a preallocated buffer that should be big enough without having to worry and do a 2-pass approach to find out the length of the buffer to allocate first. '!=' style I have found much more painful to handle in userspace. Yeah that's fine by me. Doesn't preclude kernel returning you some new fields you don't know about either. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915: Avoid waitboosting on the active request
Watching a light workload on Baytrail (running glxgears and a 1080p decode), instead of the system remaining at low frequency, the glxgears would regularly trigger waitboosting after which it would have to spend a few seconds throttling back down. In this case, the waitboosting is counter productive as the minimal wait for glxgears doesn't prevent it from functioning correctly and delivering frames on time. In this case, glxgears happens to almost always be waiting on the current request, which we already expect to complete quickly (see i915_spin_request) and so avoiding the waitboost on the active request and spinning instead provides the best latency without overcommitting to upclocking. However, if the system falls behind we still force the waitboost. Similarly, we will also trigger upclocking if we detect the system is not delivering frames on time - again using a mechanism that tries to detect a miss and not preemptively upclock. v2: Also skip boosting for after missed vblank if the desired request is already active. Signed-off-by: Chris Wilson Cc: Joonas Lahtinen Cc: Tvrtko Ursulin Cc: Radoslaw Szwichtenberg --- drivers/gpu/drm/i915/i915_gem.c | 7 +++ drivers/gpu/drm/i915/i915_gem_request.h | 13 + drivers/gpu/drm/i915/intel_display.c| 8 +++- 3 files changed, 23 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index b2ba685cb144..7f0684ccc724 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -369,7 +369,8 @@ i915_gem_object_wait_fence(struct dma_fence *fence, if (i915_gem_request_completed(rq)) goto out; - /* This client is about to stall waiting for the GPU. In many cases + /* +* This client is about to stall waiting for the GPU. In many cases * this is undesirable and limits the throughput of the system, as * many clients cannot continue processing user input/output whilst * blocked. RPS autotuning may take tens of milliseconds to respond @@ -384,11 +385,9 @@ i915_gem_object_wait_fence(struct dma_fence *fence, * forcing the clocks too high for the whole system, we only allow * each client to waitboost once in a busy period. */ - if (rps_client) { + if (rps_client && !i915_gem_request_started(rq)) { if (INTEL_GEN(rq->i915) >= 6) gen6_rps_boost(rq, rps_client); - else - rps_client = NULL; } timeout = i915_wait_request(rq, flags, timeout); diff --git a/drivers/gpu/drm/i915/i915_gem_request.h b/drivers/gpu/drm/i915/i915_gem_request.h index 6c607f8dbf92..2236e9188c5c 100644 --- a/drivers/gpu/drm/i915/i915_gem_request.h +++ b/drivers/gpu/drm/i915/i915_gem_request.h @@ -329,6 +329,19 @@ i915_gem_request_completed(const struct drm_i915_gem_request *req) return __i915_gem_request_completed(req, seqno); } +static inline bool +i915_gem_request_started(const struct drm_i915_gem_request *req) +{ + u32 seqno; + + seqno = i915_gem_request_global_seqno(req); + if (!seqno) + return false; + + return i915_seqno_passed(intel_engine_get_seqno(req->engine), +seqno - 1); +} + static inline bool i915_priotree_signaled(const struct i915_priotree *pt) { const struct drm_i915_gem_request *rq = diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 221e3a183d36..6b080e221004 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -12519,7 +12519,13 @@ static int do_rps_boost(struct wait_queue_entry *_wait, struct wait_rps_boost *wait = container_of(_wait, typeof(*wait), wait); struct drm_i915_gem_request *rq = wait->request; - gen6_rps_boost(rq, NULL); + /* +* If we missed the vblank, but the request is already running it +* is reasonable to assume that it will complete before the next +* vblank without our intervention, so leave RPS alone. +*/ + if (!i915_gem_request_started(rq)) + gen6_rps_boost(rq, NULL); i915_gem_request_put(rq); drm_crtc_vblank_put(wait->crtc); -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 6/6] drm/i915: expose rcs topology through query uAPI
Quoting Tvrtko Ursulin (2018-01-18 12:46:55) > > On 17/01/2018 15:39, Lionel Landwerlin wrote: > > + > > + if (query_item->length == 0) > > + return total_length; > > + > > + if (query_item->length < total_length) > > + return -EINVAL; > > Did we talk about whether this check should be != or < yet? != would > sound safer to me, or you want to allow extending the queries in the > future and keeping the same id? This is me, because I like read(buf, len) style behaviour that lets me pass in a preallocated buffer that should be big enough without having to worry and do a 2-pass approach to find out the length of the buffer to allocate first. '!=' style I have found much more painful to handle in userspace. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx