Re: [Intel-gfx] [PATCH v2] drm/i915: Explicit the connector name for DP link training result
On Tue, Jul 18, 2017 at 12:20:36PM -0700, Manasi Navare wrote:
> On Tue, Jul 18, 2017 at 05:25:36PM +0300, Paul Kocialkowski wrote:
> > This adds the connector name when printing a debug message about the DP
> > link training result. It is useful to figure out what connector is
> > failing when multiple DP connectors are used.
> >
>
> Thanks for the patch, this does make sense during the link training
> failure debugging to know the connector name.
> While at it feel free to change "Failed", "Link Rate, Lane Count", to upper
> case
> in the failure_handling case to be consistent with the pass case.
>
> Reviewed-by: Manasi Navare
Applied, thanks.
-Daniel
>
> Manasi
>
> > Signed-off-by: Paul Kocialkowski
> > ---
> > drivers/gpu/drm/i915/intel_dp_link_training.c | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index b79c1c0e404c..05907fa8a553 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -321,12 +321,16 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
> > if (!intel_dp_link_training_channel_equalization(intel_dp))
> > goto failure_handling;
> >
> > - DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane count = %d",
> > + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training Passed at Link Rate =
> > %d, Lane count = %d",
> > + intel_connector->base.base.id,
> > + intel_connector->base.name,
> > intel_dp->link_rate, intel_dp->lane_count);
> > return;
> >
> > failure_handling:
> > - DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane count = %d",
> > + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate =
> > %d, lane count = %d",
> > + intel_connector->base.base.id,
> > + intel_connector->base.name,
> > intel_dp->link_rate, intel_dp->lane_count);
> > if (!intel_dp_get_link_train_fallback_values(intel_dp,
> > intel_dp->link_rate,
> > --
> > 2.13.2
> >
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Consistently use enum pipe for PCH transcoders
On Tue, Jul 18, 2017 at 01:48:53PM -0700, Matthias Kaehlcke wrote:
> Hi Daniel,
>
> El Tue, Jul 18, 2017 at 08:39:50AM +0200 Daniel Vetter ha dit:
>
> > On Mon, Jul 17, 2017 at 11:14:03AM -0700, Matthias Kaehlcke wrote:
> > > The current code uses in some instances enum transcoder for PCH
> > > transcoders and enum pipe in others. This is error prone and clang
> > > raises warnings like this:
> > >
> > > drivers/gpu/drm/i915/intel_dp.c:3546:51: warning: implicit conversion
> > > from enumeration type 'enum pipe' to different enumeration type
> > > 'enum transcoder' [-Wenum-conversion]
> > > intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, false);
> > >
> > > Consistently use the type enum pipe for PCH transcoders.
> > >
> > > Signed-off-by: Matthias Kaehlcke
> >
> > Somehow git apply-mbox could parse it, but manually applying using patch
> > worked. Not sure what's going on, maybe double-check it's all right.
>
> Not sure what happened, one of the patch fragments only has one '@'
> instead of two, with that fixed the patch applies.
>
> Unfortunately the manual application missed some fragments:
>
> drivers/gpu/drm/i915/intel_display.c:5350:51: warning: implicit
> conversion from enumeration type 'enum transcoder' to different
> enumeration type 'enum pipe' [-Wenum-conversion]
> intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
> ~ ^~~~
> drivers/gpu/drm/i915/intel_display.c:5436:51: warning: implicit
> conversion from enumeration type 'enum transcoder' to different
> enumeration type 'enum pipe' [-Wenum-conversion]
> intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
> ~ ^~~~
> drivers/gpu/drm/i915/intel_display.c:5534:51: warning: implicit
> conversion from enumeration type 'enum transcoder' to different
> enumeration type 'enum pipe' [-Wenum-conversion]
> intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
> ~ ^~~~
> drivers/gpu/drm/i915/intel_display.c:5563:51: warning: implicit
> conversion from enumeration type 'enum transcoder' to different
> enumeration type 'enum pipe' [-Wenum-conversion]
> intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
>
>
> What would be the best way forward from here? Revert the manual
> application and apply again, or a fixup patch?
Drat I screwed up :-( drm-intel-next-queued is non-rebasing, that means I
need a fixup patch. I should have checked more carefully that I have all
the hunks, but patch -p1 seemed happy ...
-Daniel
>
> Matthias
>
> > > ---
> > > Changes in v2:
> > > - rebased on drm-intel/drm-intel-next-queued
> > >
> > > drivers/gpu/drm/i915/i915_irq.c| 10 +-
> > > drivers/gpu/drm/i915/intel_display.c | 24 ++--
> > > drivers/gpu/drm/i915/intel_drv.h | 6 +++---
> > > drivers/gpu/drm/i915/intel_fifo_underrun.c | 6 +++---
> > > 4 files changed, 21 insertions(+), 25 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > b/drivers/gpu/drm/i915/i915_irq.c
> > > index 1d33cea01a1b..0b6f310101ee 100644
> > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -2086,10 +2086,10 @@ static void ibx_irq_handler(struct
> > > drm_i915_private *dev_priv, u32 pch_iir)
> > > DRM_DEBUG_DRIVER("PCH transcoder CRC error interrupt\n");
> > >
> > > if (pch_iir & SDE_TRANSA_FIFO_UNDER)
> > > - intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_A);
> > > + intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_A);
> > >
> > > if (pch_iir & SDE_TRANSB_FIFO_UNDER)
> > > - intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_B);
> > > + intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_B);
> > > }
> > >
> > > static void ivb_err_int_handler(struct drm_i915_private *dev_priv)
> > > @@ -2123,13 +2123,13 @@ static void cpt_serr_int_handler(struct
> > > drm_i915_private *dev_priv)
> > > DRM_ERROR("PCH poison interrupt\n");
> > >
> > > if (serr_int & SERR_INT_TRANS_A_FIFO_UNDERRUN)
> > > - intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_A);
> > > + intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_A);
> > >
> > > if (serr_int & SERR_INT_TRANS_B_FIFO_UNDERRUN)
> > > - intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_B);
> > > + intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_B);
> > >
> > > if (serr_int & SERR_INT_TRANS_C_FIFO_UNDERRUN)
> > > - intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_C);
> > > + intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_C);
> > >
> > > I915_WRITE(SERR_INT, serr_int);
> > > }
> > > diff --git a/drivers/gpu/drm/i915/
Re: [Intel-gfx] [PATCH v10] vfio: ABI for mdev display dma-buf operation
On Wed, 2017-07-19 at 00:16 +, Zhang, Tina wrote: > > -Original Message- > > From: Gerd Hoffmann [mailto:kra...@redhat.com] > > Sent: Monday, July 17, 2017 7:03 PM > > To: Kirti Wankhede ; Zhang, Tina > > ; Tian, Kevin ; linux- > > ker...@vger.kernel.org; intel-gfx@lists.freedesktop.org; > > alex.william...@redhat.com; zhen...@linux.intel.com; chris@chris- > > wilson.co.uk; Lv, Zhiyuan ; intel-gvt- > > d...@lists.freedesktop.org; Wang, Zhi A > > Subject: Re: [PATCH v10] vfio: ABI for mdev display dma-buf > > operation > > > > Hi, > > > > > No need of flag here. If vGPU driver is not loaded in the guest, > > > there > > > is no surface being managed by vGPU, in that case this size will > > > be > > > zero. > > > > Ok, we certainly have the same situation with intel. When the > > guest driver is not > > loaded (yet) there is no valid surface. > > > > We should cleanly define what the ioctl should do in that case, so > > all drivers > > behave the same way. > > > > I'd suggest that all fields defining the surface (drm_format, > > width, height, stride, > > size) should be set to zero in that case. > > Yeah, it's reasonable. How about the return value? Currently, the > ioctl also returns "-ENODEV" in that situation. I think it should not return an error. Querying the plane parameters worked fine. cheers, Gerd ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915: Add perf property support for context HW id
== Series Details == Series: series starting with [v2,1/2] drm/i915: Add perf property support for context HW id URL : https://patchwork.freedesktop.org/series/27547/ State : success == Summary == Series 27547v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/27547/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-kbl-7560u) k.org#196399 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-n2820) fdo#101705 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 k.org#196399 https://bugzilla.kernel.org/show_bug.cgi?id=196399 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:436s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:427s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:354s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:529s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:511s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:486s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:494s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:601s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:437s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:410s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:416s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:485s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:470s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:465s fi-kbl-7560u total:279 pass:268 dwarn:1 dfail:0 fail:0 skip:10 time:572s fi-kbl-r total:279 pass:260 dwarn:1 dfail:0 fail:0 skip:18 time:575s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:558s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:455s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:581s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:464s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:483s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:435s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:472s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:545s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:404s 10de1e17faaab452782e5a1baffd1b30a639a261 drm-tip: 2017y-07m-18d-10h-08m-42s UTC integration manifest 3cb4c1c drm/i915/gvt: expose vGPU context hw id ae89000 drm/i915: Add perf property support for context HW id == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5229/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: Extend KBL platform support in GVT-g
== Series Details == Series: drm/i915/gvt: Extend KBL platform support in GVT-g URL : https://patchwork.freedesktop.org/series/27546/ State : success == Summary == Series 27546v1 drm/i915/gvt: Extend KBL platform support in GVT-g https://patchwork.freedesktop.org/api/1.0/series/27546/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-kbl-7560u) k.org#196399 Test kms_flip: Subgroup basic-flip-vs-modeset: skip -> PASS (fi-skl-x1585l) fdo#101781 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 k.org#196399 https://bugzilla.kernel.org/show_bug.cgi?id=196399 fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:439s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:430s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:355s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:528s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:512s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:501s fi-byt-n2820 total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:486s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:595s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:430s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:413s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:419s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:497s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:467s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:462s fi-kbl-7560u total:279 pass:268 dwarn:1 dfail:0 fail:0 skip:10 time:570s fi-kbl-r total:279 pass:260 dwarn:1 dfail:0 fail:0 skip:18 time:580s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:564s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:455s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:581s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:468s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:478s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:432s fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:490s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:542s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:405s 10de1e17faaab452782e5a1baffd1b30a639a261 drm-tip: 2017y-07m-18d-10h-08m-42s UTC integration manifest 3d570fb drm/i915/gvt: Extend KBL platform support in GVT-g == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5228/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915: Add perf property support for context HW id
In order to support profiling for special context e.g vGPU context,
we can expose vGPU context hw id and enable i915 perf property to
get target context for profiling. This adds new perf property to
assign target context with hw id.
Jiao Pengyuan has helped to fix context reference bug in original code.
v2:
- new function for context lookup with hw id
- always require priviledged op
- fix error return value
Cc: Lionel Landwerlin
Cc: Chris Wilson
Cc: Jiao Pengyuan
Cc: Niu Bing
Signed-off-by: Zhenyu Wang
---
drivers/gpu/drm/i915/i915_perf.c | 83
include/uapi/drm/i915_drm.h | 5 +++
2 files changed, 72 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 96682fd86f82..a80a3959bc3b 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -334,7 +334,9 @@ static struct i915_oa_format
gen8_plus_oa_formats[I915_OA_FORMAT_MAX] = {
* struct perf_open_properties - for validated properties given to open a
stream
* @sample_flags: `DRM_I915_PERF_PROP_SAMPLE_*` properties are tracked as flags
* @single_context: Whether a single or all gpu contexts should be monitored
+ * @single_context_hw: Set for special context with hw id e.g vGPU
* @ctx_handle: A gem ctx handle for use with @single_context
+ * @ctx_hw_id: A ctx hw id for use with @single_context_hw
* @metrics_set: An ID for an OA unit metric set advertised via sysfs
* @oa_format: An OA unit HW report format
* @oa_periodic: Whether to enable periodic OA unit sampling
@@ -348,7 +350,9 @@ struct perf_open_properties {
u32 sample_flags;
u64 single_context:1;
+ u64 single_context_hw:1;
u64 ctx_handle;
+ u64 ctx_hw_id;
/* OA sampling state */
int metrics_set;
@@ -2482,6 +2486,29 @@ static const struct file_operations fops = {
.unlocked_ioctl = i915_perf_ioctl,
};
+static struct i915_gem_context *
+lookup_context_hw_id(struct drm_i915_private *dev_priv, unsigned int hw_id)
+{
+ struct i915_gem_context *ctx;
+ int ret;
+
+ ret = i915_mutex_lock_interruptible(&dev_priv->drm);
+ if (ret)
+ return ERR_PTR(ret);
+
+ list_for_each_entry(ctx, &dev_priv->contexts.list, link) {
+ if (!i915_gem_context_is_default(ctx))
+ continue;
+
+ if (ctx->hw_id == hw_id) {
+ ret = 1;
+ i915_gem_context_get(ctx);
+ break;
+ }
+ }
+ mutex_unlock(&dev_priv->drm.struct_mutex);
+ return ret ? ctx : NULL;
+}
/**
* i915_perf_open_ioctl_locked - DRM ioctl() for userspace to open a stream FD
@@ -2531,24 +2558,35 @@ i915_perf_open_ioctl_locked(struct drm_i915_private
*dev_priv,
ret = -ENOENT;
goto err;
}
+
+ /*
+* On Haswell the OA unit supports clock gating off for a
specific
+* context and in this mode there's no visibility of metrics
for the
+* rest of the system, which we consider acceptable for a
+* non-privileged client.
+*
+* For Gen8+ the OA unit no longer supports clock gating off
for a
+* specific context and the kernel can't securely stop the
counters
+* from updating as system-wide / global values. Even though we
can
+* filter reports based on the included context ID we can't
block
+* clients from seeing the raw / global counter values via
+* MI_REPORT_PERF_COUNT commands and so consider it a
privileged op to
+* enable the OA unit by default.
+*/
+ if (IS_HASWELL(dev_priv) && specific_ctx)
+ privileged_op = false;
}
- /*
-* On Haswell the OA unit supports clock gating off for a specific
-* context and in this mode there's no visibility of metrics for the
-* rest of the system, which we consider acceptable for a
-* non-privileged client.
-*
-* For Gen8+ the OA unit no longer supports clock gating off for a
-* specific context and the kernel can't securely stop the counters
-* from updating as system-wide / global values. Even though we can
-* filter reports based on the included context ID we can't block
-* clients from seeing the raw / global counter values via
-* MI_REPORT_PERF_COUNT commands and so consider it a privileged op to
-* enable the OA unit by default.
-*/
- if (IS_HASWELL(dev_priv) && specific_ctx)
- privileged_op = false;
+ if (props->single_context_hw) {
+ unsigned int hw_id = props->ctx_hw_id;
+
+ specific_ctx = lookup_context_hw_id(dev_priv, hw_id);
+
[Intel-gfx] [PATCH v2 2/2] drm/i915/gvt: expose vGPU context hw id
This exposes vGPU context hw id in mdev sysfs which is used to
do vGPU based profiling. Retrieved vGPU context hw id can be set
through i915 perf ioctl to set profiling for target vGPU.
Cc: Lionel Landwerlin
Cc: Chris Wilson
Cc: Jiao Pengyuan
Cc: Niu Bing
Signed-off-by: Zhenyu Wang
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index fd0c85f9ef3c..83e88c70272a 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1170,10 +1170,27 @@ vgpu_id_show(struct device *dev, struct
device_attribute *attr,
return sprintf(buf, "\n");
}
+static ssize_t
+hw_id_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct mdev_device *mdev = mdev_from_dev(dev);
+
+ if (mdev) {
+ struct intel_vgpu *vgpu = (struct intel_vgpu *)
+ mdev_get_drvdata(mdev);
+ return sprintf(buf, "%u\n",
+ vgpu->shadow_ctx->hw_id);
+ }
+ return sprintf(buf, "\n");
+}
+
static DEVICE_ATTR_RO(vgpu_id);
+static DEVICE_ATTR_RO(hw_id);
static struct attribute *intel_vgpu_attrs[] = {
&dev_attr_vgpu_id.attr,
+ &dev_attr_hw_id.attr,
NULL
};
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/gvt: Extend KBL platform support in GVT-g
Extend KBL platform support in GVT-g. Validation tests are done on KBL server and KBL NUC. Both show the same quality. Signed-off-by: Jian Jun Chen Cc: Zhenyu Wang --- drivers/gpu/drm/i915/intel_gvt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_gvt.c b/drivers/gpu/drm/i915/intel_gvt.c index 52d5b82790d9..c17ed0e62b67 100644 --- a/drivers/gpu/drm/i915/intel_gvt.c +++ b/drivers/gpu/drm/i915/intel_gvt.c @@ -45,7 +45,7 @@ static bool is_supported_device(struct drm_i915_private *dev_priv) return true; if (IS_SKYLAKE(dev_priv)) return true; - if (IS_KABYLAKE(dev_priv) && INTEL_DEVID(dev_priv) == 0x591D) + if (IS_KABYLAKE(dev_priv)) return true; return false; } -- 2.13.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: Enable KBL platform support
== Series Details == Series: drm/i915/gvt: Enable KBL platform support URL : https://patchwork.freedesktop.org/series/27545/ State : success == Summary == Series 27545v1 drm/i915/gvt: Enable KBL platform support https://patchwork.freedesktop.org/api/1.0/series/27545/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-kbl-7560u) k.org#196399 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-n2820) fdo#101705 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 k.org#196399 https://bugzilla.kernel.org/show_bug.cgi?id=196399 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:437s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:433s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:523s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:511s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:493s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:487s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:597s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:432s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:415s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:414s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:497s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:467s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:470s fi-kbl-7560u total:279 pass:268 dwarn:1 dfail:0 fail:0 skip:10 time:571s fi-kbl-r total:279 pass:260 dwarn:1 dfail:0 fail:0 skip:18 time:581s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:566s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:460s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:588s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:464s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:473s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:436s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:469s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:542s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:410s 10de1e17faaab452782e5a1baffd1b30a639a261 drm-tip: 2017y-07m-18d-10h-08m-42s UTC integration manifest e1ceb86 drm/i915/gvt: Enable KBL platform support == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5227/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gvt: Enable KBL platform support
On 2017.07.19 12:52:17 +0800, Jian Jun Chen wrote: > Enable KBL platform support in GVT-g. Validation tests > are done on KBL server and KBL NUC. Both show the same > quality. > > Signed-off-by: Jian Jun Chen > --- hmm, better to change title as this is not first try for KBL enabling, that might just confuse people.. > drivers/gpu/drm/i915/intel_gvt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_gvt.c > b/drivers/gpu/drm/i915/intel_gvt.c > index 52d5b82790d9..c17ed0e62b67 100644 > --- a/drivers/gpu/drm/i915/intel_gvt.c > +++ b/drivers/gpu/drm/i915/intel_gvt.c > @@ -45,7 +45,7 @@ static bool is_supported_device(struct drm_i915_private > *dev_priv) > return true; > if (IS_SKYLAKE(dev_priv)) > return true; > - if (IS_KABYLAKE(dev_priv) && INTEL_DEVID(dev_priv) == 0x591D) > + if (IS_KABYLAKE(dev_priv)) > return true; > return false; > } > -- > 2.13.0 > > ___ > intel-gvt-dev mailing list > intel-gvt-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gvt: Enable KBL platform support
Enable KBL platform support in GVT-g. Validation tests are done on KBL server and KBL NUC. Both show the same quality. Signed-off-by: Jian Jun Chen --- drivers/gpu/drm/i915/intel_gvt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_gvt.c b/drivers/gpu/drm/i915/intel_gvt.c index 52d5b82790d9..c17ed0e62b67 100644 --- a/drivers/gpu/drm/i915/intel_gvt.c +++ b/drivers/gpu/drm/i915/intel_gvt.c @@ -45,7 +45,7 @@ static bool is_supported_device(struct drm_i915_private *dev_priv) return true; if (IS_SKYLAKE(dev_priv)) return true; - if (IS_KABYLAKE(dev_priv) && INTEL_DEVID(dev_priv) == 0x591D) + if (IS_KABYLAKE(dev_priv)) return true; return false; } -- 2.13.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v11 1/1] vfio: ABI for mdev display dma-buf operation
On 2017.07.19 00:55:19 +, Zhang, Tina wrote: > > > > Of course we need that modifier for complete format info. Don't just think > > for > > i915 usage, there's possible modifier for other vendor driver, and it's > > required > > for e.g ADDFB2 in drm kms. Pls add it back in next version. > We definitely can add it back if it is thought to be useful. Just some > curious, as we don't produce the content in the GEM buffer (a.k.a we just > expose it here), why we need to know the tile mode. In addition, DRM API can > support the functionality to get the tile mode ot GEM buffer. > That's vendor driver specific ioctl API instead of DRM API. And besides tiling there could be other vendor's modifiers which need to be kept for complete info. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: build failure after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/vboxvideo/vbox_drv.c:235:2: error: unknown field 'set_busid'
specified in initializer
.set_busid = drm_pci_set_busid,
^
drivers/staging/vboxvideo/vbox_drv.c:235:15: error: 'drm_pci_set_busid'
undeclared here (not in a function)
.set_busid = drm_pci_set_busid,
^
drivers/staging/vboxvideo/vbox_drv.c: In function 'vbox_init':
drivers/staging/vboxvideo/vbox_drv.c:273:9: error: implicit declaration of
function 'drm_pci_init' [-Werror=implicit-function-declaration]
return drm_pci_init(&driver, &vbox_pci_driver);
^
drivers/staging/vboxvideo/vbox_drv.c: In function 'vbox_exit':
drivers/staging/vboxvideo/vbox_drv.c:278:2: error: implicit declaration of
function 'drm_pci_exit' [-Werror=implicit-function-declaration]
drm_pci_exit(&driver, &vbox_pci_driver);
^
Caused by commits
5c484cee7ef9 ("drm: Remove drm_driver->set_busid hook")
10631d724def ("drm/pci: Deprecate drm_pci_init/exit completely")
interacting with commit
dd55d44f4084 ("staging: vboxvideo: Add vboxvideo to drivers/staging")
from the staging.current tree.
I have applied the following merge fix patch - please check that it
is correct.
From: Stephen Rothwell
Date: Wed, 19 Jul 2017 11:41:01 +1000
Subject: [PATCH] drm: fixes for staging due to API changes in the drm core
Signed-off-by: Stephen Rothwell
---
drivers/staging/vboxvideo/vbox_drv.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_drv.c
b/drivers/staging/vboxvideo/vbox_drv.c
index 92ae1560a16d..6d0600c37c0c 100644
--- a/drivers/staging/vboxvideo/vbox_drv.c
+++ b/drivers/staging/vboxvideo/vbox_drv.c
@@ -232,7 +232,6 @@ static struct drm_driver driver = {
.lastclose = vbox_driver_lastclose,
.master_set = vbox_master_set,
.master_drop = vbox_master_drop,
- .set_busid = drm_pci_set_busid,
.fops = &vbox_fops,
.irq_handler = vbox_irq_handler,
@@ -270,12 +269,12 @@ static int __init vbox_init(void)
if (vbox_modeset == 0)
return -EINVAL;
- return drm_pci_init(&driver, &vbox_pci_driver);
+ return pci_register_driver(&vbox_pci_driver);
}
static void __exit vbox_exit(void)
{
- drm_pci_exit(&driver, &vbox_pci_driver);
+ pci_unregister_driver(&vbox_pci_driver);
}
module_init(vbox_init);
--
2.13.2
--
Cheers,
Stephen Rothwell
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the drm-misc tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/i915_reg.h
between commit:
c379b897ba1a ("drm/i915/cnl: Fix the CURSOR_COEFF_MASK used in DDI Vswing
Programming")
from Linus' tree and commit:
5a8dd2af31a7 ("drm/i915/cnl: Fix RMW on ddi vswing sequence.")
(which is also commit 33b92c1e1f27 in Linus' tree)
from the drm-misc tree.
I fixed it up (I just used the version from Linus' tree) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v11 1/1] vfio: ABI for mdev display dma-buf operation
> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Zhenyu Wang
> Sent: Monday, July 17, 2017 10:27 AM
> To: Zhang, Tina
> Cc: Tian, Kevin ; intel-gfx@lists.freedesktop.org;
> kwankh...@nvidia.com; zhen...@linux.intel.com; ch...@chris-wilson.co.uk;
> alex.william...@redhat.com; Lv, Zhiyuan ;
> dan...@ffwll.ch; intel-gvt-...@lists.freedesktop.org; Wang, Zhi A
> ; Gerd Hoffmann
> Subject: Re: [PATCH v11 1/1] vfio: ABI for mdev display dma-buf operation
>
> On 2017.07.17 01:10:03 +, Zhang, Tina wrote:
> > > > +struct vfio_device_gfx_plane_info {
> > > > + __u32 argsz;
> > > > + __u32 flags;
> > > > + /* in */
> > > > + __u32 drm_plane_type; /* type of plane:
> > > > DRM_PLANE_TYPE_* */
> > > > + /* out */
> > > > + __u32 drm_format; /* drm format of plane */
> > >
> > > DRM_FORMAT_*
> > >
> > > drm_format_mod is gone? Not needed?
> > > How tiled buffers are handled then?
> > Drm_format_mod is used as one of the plane's characteristics when judging
> the dma-buf of the plane is new to expose or an old exposed one. As from V10
> we leave this comparing logic to kernel, user mode might not need this field
> any
> more. If user mode wants, this can be also got though drm APIs. For example,
> eglCreateImageKHR() uses drm APIs to get the tiling format, without asking the
> invoker to explicitly use it as a parameter.
> > Do you think this field is still needed?
> >
>
> Of course we need that modifier for complete format info. Don't just think for
> i915 usage, there's possible modifier for other vendor driver, and it's
> required
> for e.g ADDFB2 in drm kms. Pls add it back in next version.
We definitely can add it back if it is thought to be useful. Just some curious,
as we don't produce the content in the GEM buffer (a.k.a we just expose it
here), why we need to know the tile mode. In addition, DRM API can support the
functionality to get the tile mode ot GEM buffer.
Thanks,
Tina
>
> --
> 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
Re: [Intel-gfx] [PATCH v10] vfio: ABI for mdev display dma-buf operation
> -Original Message- > From: Gerd Hoffmann [mailto:kra...@redhat.com] > Sent: Monday, July 17, 2017 7:03 PM > To: Kirti Wankhede ; Zhang, Tina > ; Tian, Kevin ; linux- > ker...@vger.kernel.org; intel-gfx@lists.freedesktop.org; > alex.william...@redhat.com; zhen...@linux.intel.com; chris@chris- > wilson.co.uk; Lv, Zhiyuan ; intel-gvt- > d...@lists.freedesktop.org; Wang, Zhi A > Subject: Re: [PATCH v10] vfio: ABI for mdev display dma-buf operation > > Hi, > > > No need of flag here. If vGPU driver is not loaded in the guest, there > > is no surface being managed by vGPU, in that case this size will be > > zero. > > Ok, we certainly have the same situation with intel. When the guest driver > is not > loaded (yet) there is no valid surface. > > We should cleanly define what the ioctl should do in that case, so all drivers > behave the same way. > > I'd suggest that all fields defining the surface (drm_format, width, height, > stride, > size) should be set to zero in that case. Yeah, it's reasonable. How about the return value? Currently, the ioctl also returns "-ENODEV" in that situation. thanks, Tina > > cheers, > Gerd ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] CONTRIBUTING: formalize review rules
Daniel Vetter writes: > There's a bunch of reasons why I think we should formalize and enforce > our review rules for igt patches: > > - We have a lot of new engineers joining and review helps enormously > with mentoring and learning. But right now only patches from > contributors without commit rights are consistently subjected to > review, which makes this imbalanced and removes senior contributors > from the review pool. > > - We have a much bigger team and we need to make sure we're aligned on > where igt as a tool and testsuite needs to head towards. Getting > that alignment happens through reviewing each other's submission. > Pushing a contentious patch and then dealing with a heated irc > discussion is much less effective. > > - Finally igt becomes ever more important for our testing, making sure > the code quality is high is important. Review helps with that. > > v2: Improve wording a bit (Imre). > > Acked-by: Daniel Stone > Acked-by: Jani Nikula > Acked-by: Joonas Lahtinen > Acked-by: Maarten Lankhorst > Acked-by: Petri Latvala > Acked-by: Imre Deak > Acked-by: Robert Foss > Acked-by: Ben Widawsky > Acked-by: Tvrtko Ursulin > Acked-by: Mika Kuoppala > Signed-off-by: Daniel Vetter > --- > CONTRIBUTING | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/CONTRIBUTING b/CONTRIBUTING > index d2adcf03b7c3..561c5dd80bba 100644 > --- a/CONTRIBUTING > +++ b/CONTRIBUTING > @@ -26,10 +26,11 @@ A short list of contribution guidelines: >convenience macros provided by the igt library. The semantic patch > lib/igt.cocci >can help with the more automatic conversions. > > -- There is no formal review requirement and regular contributors with commit > - access can push patches right after submitting them to the mailing lists. > But > - invasive changes, new helper libraries and contributions from newcomers > should > - go through a proper review to ensure overall consistency in the codebase. > +- Patches need to be reviewed on the mailing list. Exceptions only apply for > + testcases and tooling for drivers with just a single contributor (e.g. > vc4). > + In this case patches must still be submitted to the mailing list first. > + Testcase should preferrably be cross-reviewed by the same people who write > and > + review the kernel feature itself. Thanks for considering my case here :) Acked-by: Eric Anholt signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/4] drm/i915/psr: Account for sink CRC raciness on some panels
According to the eDP spec, when the count field in TEST_SINK_MISC
increments then the six bytes of sink CRC information in the DPCD
should be valid. Unfortunately, this doesn't seem to be the case
on some panels, and as a result we get some incorrect and inconsistent
values from the sink CRC DPCD locations at times. This problem exhibits
itself more on faster processors (relative failure rates HSW < SKL < KBL.)
In order to try and account for this, we try a lot harder to read the sink
CRC until we get consistent values twice in a row before returning what we
read and delay for a time before trying to read. We still see some
occasional failures, but reading the sink CRC is much more reliable,
particularly on SKL and KBL, with these changes than without.
v2: * Reduce number of retries when reading the sink CRC (Jani)
* Refactor to minimize changes to the code (Jani)
* Rebase
v3: * Rebase
v4: * Switch from do-while to for loop when reading CRC values (Jani)
* Rebase
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Cc: Jani Nikula
Signed-off-by: Jim Bride
---
drivers/gpu/drm/i915/intel_dp.c | 33 ++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2d42d09..c90ca1c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3906,6 +3906,11 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
u8 buf;
int count, ret;
int attempts = 6;
+ u8 old_crc[6];
+
+ if (crc == NULL) {
+ return -ENOMEM;
+ }
ret = intel_dp_sink_crc_start(intel_dp);
if (ret)
@@ -3929,11 +3934,33 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8
*crc)
goto stop;
}
- if (drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_CRC_R_CR, crc, 6) < 0) {
- ret = -EIO;
- goto stop;
+ /*
+* Sometimes it takes a while for the "real" CRC values to land in
+* the DPCD, so try several times until we get two reads in a row
+* that are the same. If we're an eDP panel, delay between reads
+* for a while since the values take a bit longer to propagate.
+*/
+ for (attempts = 0; attempts < 6; attempts++) {
+ intel_wait_for_vblank(dev_priv, intel_crtc->pipe);
+
+ if (drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_CRC_R_CR,
+crc, 6) < 0) {
+ ret = -EIO;
+ break;
+ }
+
+ if (attempts && memcmp(old_crc, crc, 6) == 0)
+ break;
+ memcpy(old_crc, crc, 6);
+
+ if (is_edp(intel_dp))
+ usleep_range(2, 25000);
}
+ if (attempts == 6) {
+ DRM_DEBUG_KMS("Failed to get CRC after 6 attempts.\n");
+ ret = -ETIMEDOUT;
+ }
stop:
intel_dp_sink_crc_stop(intel_dp);
return ret;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 4/4] drm/i915/edp: Allow alternate fixed mode for eDP if available.
Some fixed resolution panels actually support more than one mode,
with the only thing different being the refresh rate. Having this
alternate mode available to us is desirable, because it allows us to
test PSR on panels whose setup time at the preferred mode is too long.
With this patch we allow the use of the alternate mode if it's
available and it was specifically requested.
v2 and v3: Rebase
v4: * Fix up some leaky mode stuff (Chris)
* Rebase
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Cc: Jani Nikula
Cc: Chris Wilson
Signed-off-by: Jim Bride
---
drivers/gpu/drm/i915/intel_dp.c| 34 +-
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_dsi.c | 2 +-
drivers/gpu/drm/i915/intel_dvo.c | 2 +-
drivers/gpu/drm/i915/intel_lvds.c | 3 ++-
drivers/gpu/drm/i915/intel_panel.c | 6 ++
6 files changed, 41 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7c0e530..c9db0e6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1606,6 +1606,19 @@ static int intel_dp_compute_bpp(struct intel_dp
*intel_dp,
return bpp;
}
+static bool intel_edp_compare_alt_mode(struct drm_display_mode *m1,
+ struct drm_display_mode *m2)
+{
+ return (m1->hdisplay == m2->hdisplay &&
+ m1->hsync_start == m2->hsync_start &&
+ m1->hsync_end == m2->hsync_end &&
+ m1->htotal == m2->htotal &&
+ m1->vdisplay == m2->vdisplay &&
+ m1->vsync_start == m2->vsync_start &&
+ m1->vsync_end == m2->vsync_end &&
+ m1->vtotal == m2->vtotal);
+}
+
bool
intel_dp_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
@@ -1652,8 +1665,16 @@ intel_dp_compute_config(struct intel_encoder *encoder,
pipe_config->has_audio = intel_conn_state->force_audio ==
HDMI_AUDIO_ON;
if (is_edp(intel_dp) && intel_connector->panel.fixed_mode) {
- intel_fixed_panel_mode(intel_connector->panel.fixed_mode,
- adjusted_mode);
+ struct drm_display_mode *panel_mode =
+ intel_connector->panel.alt_fixed_mode;
+ struct drm_display_mode *req_mode = &pipe_config->base.mode;
+
+ if (!intel_edp_compare_alt_mode(req_mode, panel_mode))
+ panel_mode = intel_connector->panel.fixed_mode;
+
+ drm_mode_debug_printmodeline(panel_mode);
+
+ intel_fixed_panel_mode(panel_mode, adjusted_mode);
if (INTEL_GEN(dev_priv) >= 9) {
int ret;
@@ -5810,6 +5831,7 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_display_mode *fixed_mode = NULL;
+ struct drm_display_mode *alt_fixed_mode = NULL;
struct drm_display_mode *downclock_mode = NULL;
bool has_dpcd;
struct drm_display_mode *scan;
@@ -5865,13 +5887,14 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
}
intel_connector->edid = edid;
- /* prefer fixed mode from EDID if available */
+ /* prefer fixed mode from EDID if available, save an alt mode also */
list_for_each_entry(scan, &connector->probed_modes, head) {
if ((scan->type & DRM_MODE_TYPE_PREFERRED)) {
fixed_mode = drm_mode_duplicate(dev, scan);
downclock_mode = intel_dp_drrs_init(
intel_connector, fixed_mode);
- break;
+ } else if (!alt_fixed_mode) {
+ alt_fixed_mode = drm_mode_duplicate(dev, scan);
}
}
@@ -5908,7 +5931,8 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
pipe_name(pipe));
}
- intel_panel_init(&intel_connector->panel, fixed_mode, downclock_mode);
+ intel_panel_init(&intel_connector->panel, fixed_mode, alt_fixed_mode,
+downclock_mode);
intel_connector->panel.backlight.power = intel_edp_backlight_power;
intel_panel_setup_backlight(connector, pipe);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e45163a..3bd11e2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -265,6 +265,7 @@ struct intel_encoder {
struct intel_panel {
struct drm_display_mode *fixed_mode;
+ struct drm_display_mode *alt_fixed_mode;
struct drm_display_mode *downclock_mode;
/* backlight */
@@ -1698,6 +1699,7 @@ void intel_overlay_reset(struct drm_i915_private
*dev_priv);
/* intel_pa
[Intel-gfx] [PATCH v4 1/4] drm/i915/psr: Clean-up intel_enable_source_psr1()
On SKL+ there is a bit in SRD_CTL that software is not supposed to
modify, but we currently clobber that bit when we enable PSR. In
order to preserve the value of that bit, go ahead and read SRD_CTL and
do a field-wise setting of the various bits that we need to initialize
before writing the register back out. Additionally, go ahead and
explicitly disable single-frame update since we aren't currently
supporting it.
v2: * Do a field-wise init on EDP_PSR_MAX_SLEEP_TIME even though we
always set it to the max value. (Rodrigo)
* Rebase
v3-v4: * Rebase
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Cc: Wayne Boyer
Cc: Jani Nikula
Reviewed-by: Rodrigo Vivi
Signed-off-by: Jim Bride
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_psr.c | 21 +++--
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c712d01..3e62429 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3789,18 +3789,22 @@ enum {
#define EDP_PSR_MIN_LINK_ENTRY_TIME_4_LINES (1<<25)
#define EDP_PSR_MIN_LINK_ENTRY_TIME_2_LINES (2<<25)
#define EDP_PSR_MIN_LINK_ENTRY_TIME_0_LINES (3<<25)
+#define EDP_PSR_MAX_SLEEP_TIME_MASK (0x1f<<20)
#define EDP_PSR_MAX_SLEEP_TIME_SHIFT 20
#define EDP_PSR_SKIP_AUX_EXIT(1<<12)
#define EDP_PSR_TP1_TP2_SEL (0<<11)
#define EDP_PSR_TP1_TP3_SEL (1<<11)
+#define EDP_PSR_TP2_TP3_TIME_MASK (3<<8)
#define EDP_PSR_TP2_TP3_TIME_500us (0<<8)
#define EDP_PSR_TP2_TP3_TIME_100us (1<<8)
#define EDP_PSR_TP2_TP3_TIME_2500us (2<<8)
#define EDP_PSR_TP2_TP3_TIME_0us (3<<8)
+#define EDP_PSR_TP1_TIME_MASK (0x3<<4)
#define EDP_PSR_TP1_TIME_500us (0<<4)
#define EDP_PSR_TP1_TIME_100us (1<<4)
#define EDP_PSR_TP1_TIME_2500us (2<<4)
#define EDP_PSR_TP1_TIME_0us (3<<4)
+#define EDP_PSR_IDLE_FRAME_MASK (0xf<<0)
#define EDP_PSR_IDLE_FRAME_SHIFT 0
#define EDP_PSR_AUX_CTL
_MMIO(dev_priv->psr_mmio_base + 0x10)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 559f1ab..132987b 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -280,17 +280,32 @@ static void intel_enable_source_psr1(struct intel_dp
*intel_dp)
* with the 5 or 6 idle patterns.
*/
uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
- uint32_t val = EDP_PSR_ENABLE;
+ uint32_t val = I915_READ(EDP_PSR_CTL);
+ val |= EDP_PSR_ENABLE;
+
+ val &= ~EDP_PSR_MAX_SLEEP_TIME_MASK;
val |= max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT;
+
+ val &= ~EDP_PSR_IDLE_FRAME_MASK;
val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
+ val &= ~EDP_PSR_MIN_LINK_ENTRY_TIME_MASK;
if (IS_HASWELL(dev_priv))
val |= EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
- if (dev_priv->psr.link_standby)
+ if (dev_priv->psr.link_standby) {
val |= EDP_PSR_LINK_STANDBY;
+ /* SFU should only be enabled with link standby, but for
+* now we do not support it. */
+ val &= ~BDW_PSR_SINGLE_FRAME;
+ } else {
+ val &= ~EDP_PSR_LINK_STANDBY;
+ val &= ~BDW_PSR_SINGLE_FRAME;
+ }
+
+ val &= ~EDP_PSR_TP1_TIME_MASK;
if (dev_priv->vbt.psr.tp1_wakeup_time > 5)
val |= EDP_PSR_TP1_TIME_2500us;
else if (dev_priv->vbt.psr.tp1_wakeup_time > 1)
@@ -300,6 +315,7 @@ static void intel_enable_source_psr1(struct intel_dp
*intel_dp)
else
val |= EDP_PSR_TP1_TIME_0us;
+ val &= ~EDP_PSR_TP2_TP3_TIME_MASK;
if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
val |= EDP_PSR_TP2_TP3_TIME_2500us;
else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 1)
@@ -309,6 +325,7 @@ static void intel_enable_source_psr1(struct intel_dp
*intel_dp)
else
val |= EDP_PSR_TP2_TP3_TIME_0us;
+ val &= ~EDP_PSR_TP1_TP3_SEL;
if (intel_dp_source_supports_hbr2(intel_dp) &&
drm_dp_tps3_supported(intel_dp->dpcd))
val |= EDP_PSR_TP1_TP3_SEL;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 3/4] drm/i915/edp: Be less aggressive about changing link config on eDP
This set of changes has some history to them. There were several attempts
to add what was called "fast link training" to i915, which actually wasn't
fast link training as per the DP spec. These changes were
5fa836a9d859 ("drm/i915: DP link training optimization")
4e96c97742f4 ("drm/i915: eDP link training optimization")
which were eventually hand-reverted by
34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
in kernel 4.7-rc4. The eDP pieces of the above revert, however, had some
very bad side-effects on PSR functionality on Skylake. The issue at
hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
(depending on the original link configuration) in order to quickly get
the source and sink back in synchronization across the link before handing
control back to the i915. There's an assumption that none of the link
configuration information has changed (and thus it's still valid) since the
last full link training operation. The revert above was identified via a
bisect as the cause of some of Skylake's PSR woes. This patch, largely
based on
commit 4e96c97742f4201edf1b0f8e1b1b6b2ac6ff33e7
Author: Mika Kahola
Date: Wed Apr 29 09:17:39 2015 +0300
drm/i915: eDP link training optimization
puts the eDP portions of this patch back in place. None of the flickering
issues that spurred the revert have been seen, and I suspect the real
culprits here were addressed by some of the recent link training changes
that Manasi has implemented, and PSR on Skylake is definitely more happy
with these changes in-place.
v2 and v3: Rebase
v4: * Clean up accesses to train_set_valid a bit for easier reading. (Chris)
* Rebase
Cc: Chris Wilson
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Cc: Manasi D Navare
Cc: Mika Kahola
Cc: Jani Nikula
Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
Signed-off-by: Jim Bride
---
drivers/gpu/drm/i915/intel_dp.c | 4 +++-
drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++-
drivers/gpu/drm/i915/intel_drv.h | 2 ++
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c90ca1c..7c0e530 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, 27, 54
};
* If a CPU or PCH DP output is attached to an eDP panel, this function
* will return true, and false otherwise.
*/
-static bool is_edp(struct intel_dp *intel_dp)
+bool is_edp(struct intel_dp *intel_dp)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
@@ -4738,6 +4738,7 @@ intel_dp_long_pulse(struct intel_connector
*intel_connector)
intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
intel_dp->reset_link_params = false;
+ intel_dp->train_set_valid = false;
}
intel_dp_print_rates(intel_dp);
@@ -6008,6 +6009,7 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
intel_dp_set_source_rates(intel_dp);
intel_dp->reset_link_params = true;
+ intel_dp->train_set_valid = false;
intel_dp->pps_pipe = INVALID_PIPE;
intel_dp->active_pipe = INVALID_PIPE;
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index b79c1c0..d12200d 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -94,7 +94,8 @@ static bool
intel_dp_reset_link_train(struct intel_dp *intel_dp,
uint8_t dp_train_pat)
{
- memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
+ if (!intel_dp->train_set_valid)
+ memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
intel_dp_set_signal_levels(intel_dp);
return intel_dp_set_link_train(intel_dp, dp_train_pat);
}
@@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp)
DP_TRAINING_PATTERN_1 |
DP_LINK_SCRAMBLING_DISABLE)) {
DRM_ERROR("failed to enable link training\n");
+ intel_dp->train_set_valid = false;
return false;
}
+ /*
+* The initial set of link parameters are set by this point, so go
+* ahead and set intel_dp->train_set_valid to false in case any of
+* the succeeding steps fail. It will be set back to true if we were
+* able to achieve clock recovery in the specified configuration.
+*/
+ intel_dp->train_set_valid = false;
+
voltage_tries = 1;
max_vswing_tries = 0;
for (;;) {
@@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp)
if (drm_dp_clock_recovery_ok(link_status,
intel_dp->lane_count)) {
Re: [Intel-gfx] [PATCH i-g-t 1/2] tests/chamelium: Skip suspend/resume test with unreliable hotplug event
Quoting Paul Kocialkowski (2017-07-18 16:16:26) > It may occur that a hotplug uevent is detected at resume, even though it > does not indicate that an actual hotplug happened. This is the case when > link training fails on any other connector. > > There is currently no way to distinguish what connector caused a hotplug > uevent, nor what the reason for that uevent really is. This makes it > impossible to find out whether the test actually passed or not. And you may get more than one and then this skips even though the test passed. Looks like the patch is overcompensating. What you can do is repeat the test a few times, and then look at all the different errors you get. If the connector remains (no mst disappareance) once it goes bad, it should remain bad and so not generate any new uevent. Or you only repeat the test whilst link_status[old] != link_status[new]. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq
On Tue, 2017-07-18 at 19:35 +0100, Chris Wilson wrote: > Quoting Dhinakaran Pandiyan (2017-07-18 19:28:00) > > INTEL_GEN() appears to be the new way of doing these platform checks, so > > convert this i915_irq.c too. > > > > Signed-off-by: Dhinakaran Pandiyan > Reviewed-by: Chris Wilson > -Chris Thank you! > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Consistently use enum pipe for PCH transcoders
Hi Daniel,
El Tue, Jul 18, 2017 at 08:39:50AM +0200 Daniel Vetter ha dit:
> On Mon, Jul 17, 2017 at 11:14:03AM -0700, Matthias Kaehlcke wrote:
> > The current code uses in some instances enum transcoder for PCH
> > transcoders and enum pipe in others. This is error prone and clang
> > raises warnings like this:
> >
> > drivers/gpu/drm/i915/intel_dp.c:3546:51: warning: implicit conversion
> > from enumeration type 'enum pipe' to different enumeration type
> > 'enum transcoder' [-Wenum-conversion]
> > intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, false);
> >
> > Consistently use the type enum pipe for PCH transcoders.
> >
> > Signed-off-by: Matthias Kaehlcke
>
> Somehow git apply-mbox could parse it, but manually applying using patch
> worked. Not sure what's going on, maybe double-check it's all right.
Not sure what happened, one of the patch fragments only has one '@'
instead of two, with that fixed the patch applies.
Unfortunately the manual application missed some fragments:
drivers/gpu/drm/i915/intel_display.c:5350:51: warning: implicit
conversion from enumeration type 'enum transcoder' to different
enumeration type 'enum pipe' [-Wenum-conversion]
intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
~ ^~~~
drivers/gpu/drm/i915/intel_display.c:5436:51: warning: implicit
conversion from enumeration type 'enum transcoder' to different
enumeration type 'enum pipe' [-Wenum-conversion]
intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
~ ^~~~
drivers/gpu/drm/i915/intel_display.c:5534:51: warning: implicit
conversion from enumeration type 'enum transcoder' to different
enumeration type 'enum pipe' [-Wenum-conversion]
intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
~ ^~~~
drivers/gpu/drm/i915/intel_display.c:5563:51: warning: implicit
conversion from enumeration type 'enum transcoder' to different
enumeration type 'enum pipe' [-Wenum-conversion]
intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
What would be the best way forward from here? Revert the manual
application and apply again, or a fixup patch?
Matthias
> > ---
> > Changes in v2:
> > - rebased on drm-intel/drm-intel-next-queued
> >
> > drivers/gpu/drm/i915/i915_irq.c| 10 +-
> > drivers/gpu/drm/i915/intel_display.c | 24 ++--
> > drivers/gpu/drm/i915/intel_drv.h | 6 +++---
> > drivers/gpu/drm/i915/intel_fifo_underrun.c | 6 +++---
> > 4 files changed, 21 insertions(+), 25 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 1d33cea01a1b..0b6f310101ee 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2086,10 +2086,10 @@ static void ibx_irq_handler(struct drm_i915_private
> > *dev_priv, u32 pch_iir)
> > DRM_DEBUG_DRIVER("PCH transcoder CRC error interrupt\n");
> >
> > if (pch_iir & SDE_TRANSA_FIFO_UNDER)
> > - intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_A);
> > + intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_A);
> >
> > if (pch_iir & SDE_TRANSB_FIFO_UNDER)
> > - intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_B);
> > + intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_B);
> > }
> >
> > static void ivb_err_int_handler(struct drm_i915_private *dev_priv)
> > @@ -2123,13 +2123,13 @@ static void cpt_serr_int_handler(struct
> > drm_i915_private *dev_priv)
> > DRM_ERROR("PCH poison interrupt\n");
> >
> > if (serr_int & SERR_INT_TRANS_A_FIFO_UNDERRUN)
> > - intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_A);
> > + intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_A);
> >
> > if (serr_int & SERR_INT_TRANS_B_FIFO_UNDERRUN)
> > - intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_B);
> > + intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_B);
> >
> > if (serr_int & SERR_INT_TRANS_C_FIFO_UNDERRUN)
> > - intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_C);
> > + intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_C);
> >
> > I915_WRITE(SERR_INT, serr_int);
> > }
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index bb9c9c3c391f..5c7054c3be0e 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -1777,7 +1777,7 @@ static void lpt_enable_pch_transcoder(struct
> > drm_i915_private *dev_priv,
> >
> > /* FDI must be feeding us bits for PCH ports */
> > assert_fdi_tx_enabled(dev_priv, (enum pipe) cpu_transcoder
Re: [Intel-gfx] [PATCH i-g-t] CONTRIBUTING: formalize review rules
On Tue, Jul 18, 2017 at 10:34 PM, Lionel Landwerlin wrote: > Acked-by: Lionel Landwerlin > > I assume review cannot be provided by someone who doesn't already contribute > or has a number of patches in already. > > What's the criteria to become a reviewer? > Is there is going to be a list of people to go to for review? Just going out and getting the first r-b tag from the lowest bidder would indeed be a bit silly, but I don't see any issue with new contributors (who might not yet have pushed anything) doing review. Imo review is about a lot more than just code correctess, it's also really great tool for aligning a team on the ideas in a code, for mentoring and learning and all that stuff. So someone new reviewing code of someone experienced, and making the code and docs better by asking questions, sounds pretty perfect to me. Ofc two completely new contributors reviewing each another's stuff would again defeat that, but then they need at least someone slightly more experienced as committer again. tldr; totally not worried nor seeing a need for criteria for reviewers. Cheers, Daniel > - > Lionel > > > On 18/07/17 17:00, Daniel Vetter wrote: >> >> There's a bunch of reasons why I think we should formalize and enforce >> our review rules for igt patches: >> >> - We have a lot of new engineers joining and review helps enormously >>with mentoring and learning. But right now only patches from >>contributors without commit rights are consistently subjected to >>review, which makes this imbalanced and removes senior contributors >>from the review pool. >> >> - We have a much bigger team and we need to make sure we're aligned on >>where igt as a tool and testsuite needs to head towards. Getting >>that alignment happens through reviewing each other's submission. >>Pushing a contentious patch and then dealing with a heated irc >>discussion is much less effective. >> >> - Finally igt becomes ever more important for our testing, making sure >>the code quality is high is important. Review helps with that. >> >> v2: Improve wording a bit (Imre). >> >> Acked-by: Daniel Stone >> Acked-by: Jani Nikula >> Acked-by: Joonas Lahtinen >> Acked-by: Maarten Lankhorst >> Acked-by: Petri Latvala >> Acked-by: Imre Deak >> Acked-by: Robert Foss >> Acked-by: Ben Widawsky >> Acked-by: Tvrtko Ursulin >> Acked-by: Mika Kuoppala >> Signed-off-by: Daniel Vetter >> --- >> CONTRIBUTING | 9 + >> 1 file changed, 5 insertions(+), 4 deletions(-) >> >> diff --git a/CONTRIBUTING b/CONTRIBUTING >> index d2adcf03b7c3..561c5dd80bba 100644 >> --- a/CONTRIBUTING >> +++ b/CONTRIBUTING >> @@ -26,10 +26,11 @@ A short list of contribution guidelines: >> convenience macros provided by the igt library. The semantic patch >> lib/igt.cocci >> can help with the more automatic conversions. >> -- There is no formal review requirement and regular contributors with >> commit >> - access can push patches right after submitting them to the mailing >> lists. But >> - invasive changes, new helper libraries and contributions from newcomers >> should >> - go through a proper review to ensure overall consistency in the >> codebase. >> +- Patches need to be reviewed on the mailing list. Exceptions only apply >> for >> + testcases and tooling for drivers with just a single contributor (e.g. >> vc4). >> + In this case patches must still be submitted to the mailing list first. >> + Testcase should preferrably be cross-reviewed by the same people who >> write and >> + review the kernel feature itself. >> - When patches from new contributors (without commit access) are >> stuck, for >> anything related to the regular releases, issues with packaging and > > > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] CONTRIBUTING: formalize review rules
Acked-by: Lionel Landwerlin I assume review cannot be provided by someone who doesn't already contribute or has a number of patches in already. What's the criteria to become a reviewer? Is there is going to be a list of people to go to for review? - Lionel On 18/07/17 17:00, Daniel Vetter wrote: There's a bunch of reasons why I think we should formalize and enforce our review rules for igt patches: - We have a lot of new engineers joining and review helps enormously with mentoring and learning. But right now only patches from contributors without commit rights are consistently subjected to review, which makes this imbalanced and removes senior contributors from the review pool. - We have a much bigger team and we need to make sure we're aligned on where igt as a tool and testsuite needs to head towards. Getting that alignment happens through reviewing each other's submission. Pushing a contentious patch and then dealing with a heated irc discussion is much less effective. - Finally igt becomes ever more important for our testing, making sure the code quality is high is important. Review helps with that. v2: Improve wording a bit (Imre). Acked-by: Daniel Stone Acked-by: Jani Nikula Acked-by: Joonas Lahtinen Acked-by: Maarten Lankhorst Acked-by: Petri Latvala Acked-by: Imre Deak Acked-by: Robert Foss Acked-by: Ben Widawsky Acked-by: Tvrtko Ursulin Acked-by: Mika Kuoppala Signed-off-by: Daniel Vetter --- CONTRIBUTING | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/CONTRIBUTING b/CONTRIBUTING index d2adcf03b7c3..561c5dd80bba 100644 --- a/CONTRIBUTING +++ b/CONTRIBUTING @@ -26,10 +26,11 @@ A short list of contribution guidelines: convenience macros provided by the igt library. The semantic patch lib/igt.cocci can help with the more automatic conversions. -- There is no formal review requirement and regular contributors with commit - access can push patches right after submitting them to the mailing lists. But - invasive changes, new helper libraries and contributions from newcomers should - go through a proper review to ensure overall consistency in the codebase. +- Patches need to be reviewed on the mailing list. Exceptions only apply for + testcases and tooling for drivers with just a single contributor (e.g. vc4). + In this case patches must still be submitted to the mailing list first. + Testcase should preferrably be cross-reviewed by the same people who write and + review the kernel feature itself. - When patches from new contributors (without commit access) are stuck, for anything related to the regular releases, issues with packaging and ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 0/2] Unrelated hotplug uevent masking out actual test result
For the whole series Reviewed-by: Lyude will push in just a sec On Tue, 2017-07-18 at 18:16 +0300, Paul Kocialkowski wrote: > This patch introduces a workaround for a case where a uevent is > issued > by the kernel because of DP link training failing on a connector > unrelated to the current test. Since the test depends on receiving a > hotplug uevent, it previously passed even though it should not have. > > False positives also occur due to the plug/unplug events being > delayed > and issued at resume time. This is mitigated by catching and flushing > hotplugs everytime a change is made on connectors, but it is not > enough > to ensure that all hotplug events were caught and not delayed. > > The problem here is that it is not possible to find out the exact > reason > why a uevent is issued by the kernel. A possible way to fix this > would > be to introduce more fields (the connector name and some reason why > the > event is triggered would probably be sufficient). > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Cheers, Lyude ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 3/6] drm/i915: prepare pipe for YCBCR420 output
On Wed, Jul 19, 2017 at 12:46:37AM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 7/18/2017 11:42 PM, Imre Deak wrote:
> > On Mon, Jul 17, 2017 at 08:06:24PM +0530, Shashank Sharma wrote:
> > > To get HDMI YCBCR420 output, the PIPEMISC register should be
> > > programmed to:
> > > - Generate YCBCR output (bit 11)
> > > - In case of YCBCR420 outputs, it should be programmed in full
> > >blend mode to use the scaler in 5x3 ratio (bits 26 and 27)
> > >
> > > This patch:
> > > - Adds definition of these bits.
> > > - Programs PIPEMISC for YCBCR420 outputs.
> > > - Adds readouts to compare HW and SW states.
> > >
> > > V2: rebase
> > > V3: rebase
> > > V4: rebase
> > > V5: added r-b from Ander
> > > V6: Handle only YCBCR420 outputs (ville)
> > > V7: rebase
> > > V8: Addressed review comments from Ville
> > > - Add readouts for state->ycbcr420 and 420 pixel_clock.
> > > - Handle warning due to mismatch in clock for ycbcr420 clock.
> > > - Rename PIPEMISC macros to match the Bspec.
> > > - Add a debug print stating if YCBCR 4:2:0 output enabled.
> > > Added r-b from Ville
> > >
> > > Cc: Ville Syrjala
> > > Cc: Ander Conselvan de Oliveira
> > > Cc: Daniel Vetter
> > >
> > > Reviewed-by: Ander Conselvan de Oliveira
> > > Reviewed-by: Ville Syrjala
> > > Signed-off-by: Shashank Sharma
> > > ---
> > > drivers/gpu/drm/i915/i915_reg.h | 3 ++
> > > drivers/gpu/drm/i915/intel_display.c | 55
> > > ++--
> > > 2 files changed, 55 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index c712d01..6dfcdd3 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -5227,6 +5227,9 @@ enum {
> > > #define _PIPE_MISC_A0x70030
> > > #define _PIPE_MISC_B0x71030
> > > +#define PIPEMISC_YUV420_ENABLE (1<<27)
> > > +#define PIPEMISC_YUV420_MODE_BLEND (1<<26)
> > > +#define PIPEMISC_OUTPUT_YUV(1<<11)
> > Missing the rename here requested by Ville.
> Ah, I thought it was more strict on changing YCBCR->YUV, will get this done.
> > > #define PIPEMISC_DITHER_BPC_MASK (7<<5)
> > > #define PIPEMISC_DITHER_8_BPC (0<<5)
> > > #define PIPEMISC_DITHER_10_BPC(1<<5)
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index d78f1c2..788502a 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -6216,7 +6216,6 @@ static uint32_t ilk_pipe_pixel_rate(const struct
> > > intel_crtc_state *pipe_config)
> > >* We only use IF-ID interlacing. If we ever use
> > >* PF-ID we'll need to adjust the pixel_rate here.
> > >*/
> > > -
> > Extra w/s change.
> Got it.
> >
> > > if (pipe_config->pch_pfit.enabled) {
> > > uint64_t pipe_w, pipe_h, pfit_w, pfit_h;
> > > uint32_t pfit_size = pipe_config->pch_pfit.size;
> > > @@ -8076,6 +8075,7 @@ static void haswell_set_pipemisc(struct drm_crtc
> > > *crtc)
> > > {
> > > struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> > > struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > > + struct intel_crtc_state *config = intel_crtc->config;
> > > if (IS_BROADWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 9) {
> > > u32 val = 0;
> > > @@ -8101,6 +8101,12 @@ static void haswell_set_pipemisc(struct drm_crtc
> > > *crtc)
> > > if (intel_crtc->config->dither)
> > > val |= PIPEMISC_DITHER_ENABLE |
> > > PIPEMISC_DITHER_TYPE_SP;
> > > + if (config->ycbcr420) {
> > > + val |= PIPEMISC_OUTPUT_YUV |
> > > + PIPEMISC_YUV420_ENABLE |
> > > + PIPEMISC_YUV420_MODE_BLEND;
> > > + }
> > > +
> > > I915_WRITE(PIPEMISC(intel_crtc->pipe), val);
> > > }
> > > }
> > > @@ -9170,6 +9176,10 @@ static bool haswell_get_pipe_config(struct
> > > intel_crtc *crtc,
> > > pipe_config->scaler_state.scaler_users &= ~(1 <<
> > > SKL_CRTC_INDEX);
> > > }
> > > + if (IS_GEMINILAKE(dev_priv))
> > > + pipe_config->ycbcr420 = I915_READ(PIPEMISC(crtc->pipe)) &
> > > + PIPEMISC_YUV420_ENABLE;
> > > +
> > > power_domain = POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe);
> > > if (intel_display_power_get_if_enabled(dev_priv, power_domain))
> > > {
> > > power_domain_mask |= BIT_ULL(power_domain);
> > > @@ -11377,6 +11387,9 @@ static void intel_dump_pipe_config(struct
> > > intel_crtc *crtc,
> > > pipe_config->fdi_lanes,
> > > &pipe_config->fdi_m_n);
> > >
[Intel-gfx] drivers/gpu/drm/i915/intel_pm.c:4467: bad comparison ?
Hello there, drivers/gpu/drm/i915/intel_pm.c:4467]: (warning) Comparison of a boolean expression with an integer other than 0 or 1. Source code is else if ((ddb_allocation && ddb_allocation / fixed_16_16_to_u32_round_up(plane_blocks_per_line)) >= 1) Regards David Binderman ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 3/6] drm/i915: prepare pipe for YCBCR420 output
Regards
Shashank
On 7/18/2017 11:42 PM, Imre Deak wrote:
On Mon, Jul 17, 2017 at 08:06:24PM +0530, Shashank Sharma wrote:
To get HDMI YCBCR420 output, the PIPEMISC register should be
programmed to:
- Generate YCBCR output (bit 11)
- In case of YCBCR420 outputs, it should be programmed in full
blend mode to use the scaler in 5x3 ratio (bits 26 and 27)
This patch:
- Adds definition of these bits.
- Programs PIPEMISC for YCBCR420 outputs.
- Adds readouts to compare HW and SW states.
V2: rebase
V3: rebase
V4: rebase
V5: added r-b from Ander
V6: Handle only YCBCR420 outputs (ville)
V7: rebase
V8: Addressed review comments from Ville
- Add readouts for state->ycbcr420 and 420 pixel_clock.
- Handle warning due to mismatch in clock for ycbcr420 clock.
- Rename PIPEMISC macros to match the Bspec.
- Add a debug print stating if YCBCR 4:2:0 output enabled.
Added r-b from Ville
Cc: Ville Syrjala
Cc: Ander Conselvan de Oliveira
Cc: Daniel Vetter
Reviewed-by: Ander Conselvan de Oliveira
Reviewed-by: Ville Syrjala
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 3 ++
drivers/gpu/drm/i915/intel_display.c | 55 ++--
2 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c712d01..6dfcdd3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5227,6 +5227,9 @@ enum {
#define _PIPE_MISC_A 0x70030
#define _PIPE_MISC_B 0x71030
+#define PIPEMISC_YUV420_ENABLE (1<<27)
+#define PIPEMISC_YUV420_MODE_BLEND (1<<26)
+#define PIPEMISC_OUTPUT_YUV (1<<11)
Missing the rename here requested by Ville.
Ah, I thought it was more strict on changing YCBCR->YUV, will get this done.
#define PIPEMISC_DITHER_BPC_MASK(7<<5)
#define PIPEMISC_DITHER_8_BPC (0<<5)
#define PIPEMISC_DITHER_10_BPC (1<<5)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d78f1c2..788502a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6216,7 +6216,6 @@ static uint32_t ilk_pipe_pixel_rate(const struct
intel_crtc_state *pipe_config)
* We only use IF-ID interlacing. If we ever use
* PF-ID we'll need to adjust the pixel_rate here.
*/
-
Extra w/s change.
Got it.
if (pipe_config->pch_pfit.enabled) {
uint64_t pipe_w, pipe_h, pfit_w, pfit_h;
uint32_t pfit_size = pipe_config->pch_pfit.size;
@@ -8076,6 +8075,7 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_crtc_state *config = intel_crtc->config;
if (IS_BROADWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 9) {
u32 val = 0;
@@ -8101,6 +8101,12 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
if (intel_crtc->config->dither)
val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
+ if (config->ycbcr420) {
+ val |= PIPEMISC_OUTPUT_YUV |
+ PIPEMISC_YUV420_ENABLE |
+ PIPEMISC_YUV420_MODE_BLEND;
+ }
+
I915_WRITE(PIPEMISC(intel_crtc->pipe), val);
}
}
@@ -9170,6 +9176,10 @@ static bool haswell_get_pipe_config(struct intel_crtc
*crtc,
pipe_config->scaler_state.scaler_users &= ~(1 <<
SKL_CRTC_INDEX);
}
+ if (IS_GEMINILAKE(dev_priv))
+ pipe_config->ycbcr420 = I915_READ(PIPEMISC(crtc->pipe)) &
+ PIPEMISC_YUV420_ENABLE;
+
power_domain = POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe);
if (intel_display_power_get_if_enabled(dev_priv, power_domain)) {
power_domain_mask |= BIT_ULL(power_domain);
@@ -11377,6 +11387,9 @@ static void intel_dump_pipe_config(struct intel_crtc
*crtc,
pipe_config->fdi_lanes,
&pipe_config->fdi_m_n);
+ if (pipe_config->ycbcr420)
+ DRM_DEBUG_KMS("YCbCr 4:2:0 output enabled\n");
+
if (intel_crtc_has_dp_encoder(pipe_config)) {
intel_dump_m_n_config(pipe_config, "dp m_n",
pipe_config->lane_count, &pipe_config->dp_m_n);
@@ -11704,6 +11717,22 @@ intel_modeset_update_crtc_state(struct
drm_atomic_state *state)
}
}
+static bool intel_420_clock_check(int clock1, int clock2)
+{
+ int diff;
+
+ if (clock1 == clock2 * 2)
+ return true;
+
+ clock2 *= 2;
+ diff = abs(clock1 - clock2);
+
+ if (diff + clock1 + clock2) * 100)) / (clock1 + clock2)) < 105)
+ return true;
+
+ return false
Re: [Intel-gfx] [PATCH v2] drm/i915: Explicit the connector name for DP link training result
On Tue, Jul 18, 2017 at 05:25:36PM +0300, Paul Kocialkowski wrote:
> This adds the connector name when printing a debug message about the DP
> link training result. It is useful to figure out what connector is
> failing when multiple DP connectors are used.
>
Thanks for the patch, this does make sense during the link training
failure debugging to know the connector name.
While at it feel free to change "Failed", "Link Rate, Lane Count", to upper case
in the failure_handling case to be consistent with the pass case.
Reviewed-by: Manasi Navare
Manasi
> Signed-off-by: Paul Kocialkowski
> ---
> drivers/gpu/drm/i915/intel_dp_link_training.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index b79c1c0e404c..05907fa8a553 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -321,12 +321,16 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
> if (!intel_dp_link_training_channel_equalization(intel_dp))
> goto failure_handling;
>
> - DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane count = %d",
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training Passed at Link Rate =
> %d, Lane count = %d",
> + intel_connector->base.base.id,
> + intel_connector->base.name,
> intel_dp->link_rate, intel_dp->lane_count);
> return;
>
> failure_handling:
> - DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane count = %d",
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate =
> %d, lane count = %d",
> + intel_connector->base.base.id,
> + intel_connector->base.name,
> intel_dp->link_rate, intel_dp->lane_count);
> if (!intel_dp_get_link_train_fallback_values(intel_dp,
>intel_dp->link_rate,
> --
> 2.13.2
>
___
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: Enable FBC for non X-tiled FBs (rev5)
== Series Details == Series: drm/i915: Enable FBC for non X-tiled FBs (rev5) URL : https://patchwork.freedesktop.org/series/21264/ State : success == Summary == Series 21264v5 drm/i915: Enable FBC for non X-tiled FBs https://patchwork.freedesktop.org/api/1.0/series/21264/revisions/5/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-n2820) fdo#101705 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:443s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:429s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:355s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:532s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:510s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:491s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:487s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:594s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:441s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:412s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:412s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:494s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:494s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:462s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:585s fi-kbl-r total:279 pass:260 dwarn:1 dfail:0 fail:0 skip:18 time:577s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:564s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:455s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:586s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:465s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:472s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:432s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:468s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:541s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:409s 10de1e17faaab452782e5a1baffd1b30a639a261 drm-tip: 2017y-07m-18d-10h-08m-42s UTC integration manifest ee3e000 drm/i915: Fix FBC cfb stride programming for non X-tiled FB == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5226/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Add heuristic to determine better way to adjust brightness"
May be the older panel might not work well with this feature.
David/Jani, what do you think about adding check that the panel is eDP
1.4 or later in the heuristic?
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index b25cd88fc1c5..e63f2296fd34 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -292,7 +292,7 @@ intel_dp_aux_display_control_capable(struct
intel_connector *connector)
* via PWM pin or using AUX is better than using PWM pin.
*
* The heuristic to determine that using AUX pin is better than using
PWM pin is
- * that the panel support any of the feature list here.
+ * that the panel is eDP 1.4 or later and support any of the feature list here.
* - Regional backlight brightness adjustment
* - Backlight PWM frequency set
* - More than 8 bits resolution of brightness level
@@ -310,6 +310,10 @@ intel_dp_aux_display_control_heuristic(struct
intel_connector *connector)
if (!(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
return true;
+ /* Enable this for eDP 1.4 panel or later. */
+ if (intel_dp->edp_dpcd[0] < DP_EDP_14)
+ return false;
+
/* Panel supports regional backlight brightness adjustment */
if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_GENERAL_CAP_3,
®_val) != 1) {
On Mon, Jul 10, 2017 at 7:23 AM, David Weinehall
wrote:
> This reverts commit 560a758d39c616f83ac25ff6e0816a49ebe6401c.
>
> This patch has been identified to introduce a backlight regression
> on at least two different platforms; either the heuristic is broken
> (if so the patch needs to be reworked) or the in-kernel DPCD backlight
> support is broken (if so it's premature to enable DPCD backlight
> even if the platforms support it).
>
> Signed-off-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_params.c| 7 ++-
> drivers/gpu/drm/i915/i915_params.h| 1 -
> drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 61
> ++-
> 3 files changed, 6 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index 88b9d3e6713a..bec5ade371b0 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -63,7 +63,7 @@ struct i915_params i915 __read_mostly = {
> .huc_firmware_path = NULL,
> .enable_dp_mst = true,
> .inject_load_failure = 0,
> - .enable_dpcd_backlight = -1,
> + .enable_dpcd_backlight = false,
> .enable_gvt = false,
> .enable_dbc = true,
> };
> @@ -247,10 +247,9 @@ MODULE_PARM_DESC(enable_dp_mst,
> module_param_named_unsafe(inject_load_failure, i915.inject_load_failure,
> uint, 0400);
> MODULE_PARM_DESC(inject_load_failure,
> "Force an error after a number of failure check points (0:disabled
> (default), N:force failure at the Nth failure check point)");
> -module_param_named_unsafe(enable_dpcd_backlight, i915.enable_dpcd_backlight,
> int, 0600);
> +module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool,
> 0600);
> MODULE_PARM_DESC(enable_dpcd_backlight,
> - "Enable support for DPCD backlight control "
> - "(-1:auto (default), 0:force disable, 1:force enabled if supported");
> + "Enable support for DPCD backlight control (default:false)");
>
> module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
> MODULE_PARM_DESC(enable_gvt,
> diff --git a/drivers/gpu/drm/i915/i915_params.h
> b/drivers/gpu/drm/i915/i915_params.h
> index 057e203e6bda..6a88c76664db 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -53,7 +53,6 @@
> func(int, edp_vswing); \
> func(int, reset); \
> func(unsigned int, inject_load_failure); \
> - func(int, enable_dpcd_backlight); \
> /* leave bools at the end to not create holes */ \
> func(bool, alpha_support); \
> func(bool, enable_cmd_parser); \
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index b25cd88fc1c5..f32dec02e540 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -277,66 +277,15 @@ intel_dp_aux_display_control_capable(struct
> intel_connector *connector)
> /* Check the eDP Display control capabilities registers to determine
> if
> * the panel can support backlight control over the aux channel
> */
> - if ((intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP) &&
> - (intel_dp->edp_dpcd[2] &
> DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
> + if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
> + (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)
> &&
> +
Re: [Intel-gfx] [PATCH v2] drm/i915: Explicit the connector name for DP link training result
On Tue, 2017-07-18 at 17:25 +0300, Paul Kocialkowski wrote:
> This adds the connector name when printing a debug message about the DP
> link training result. It is useful to figure out what connector is
> failing when multiple DP connectors are used.
>
> Signed-off-by: Paul Kocialkowski
> ---
> drivers/gpu/drm/i915/intel_dp_link_training.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index b79c1c0e404c..05907fa8a553 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -321,12 +321,16 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
> if (!intel_dp_link_training_channel_equalization(intel_dp))
> goto failure_handling;
>
> - DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane count = %d",
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training Passed at Link Rate =
> %d, Lane count = %d",
> + intel_connector->base.base.id,
> + intel_connector->base.name,
> intel_dp->link_rate, intel_dp->lane_count);
> return;
>
> failure_handling:
> - DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane count = %d",
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate =
> %d, lane count = %d",
> + intel_connector->base.base.id,
> + intel_connector->base.name,
> intel_dp->link_rate, intel_dp->lane_count);
> if (!intel_dp_get_link_train_fallback_values(intel_dp,
>intel_dp->link_rate,
Reviewed-by: Dhinakaran Pandiyan
The choice of upper v/s lower case letters in these debug messages is a
bit odd.
Passed/failed
Link rate/link rate
Lane count/lane count
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] drm-misc-next
On Tue, Jul 18, 2017 at 2:42 PM, Sean Paul wrote: > Hi Dave, > Here's the first -misc-next pull for 4.13 err, 4.14. > , definitely the largest one I've > sent to you. There's nothing too disruptive, a bunch of clean-up series which > tidy up atomic macros, return value fixes, etc. New functionality includes 2 > new dsi > bridge drivers, async atomic commits, YCBCR 4:2:0 support, and RK3399 support > in > dw_hdmi. > > Note that there will be conflicts with Al's tree that went directly to Linus. > Laurent posted a patch to fix this: > Subject: [PATCH] drm: compat: Fix compilation breakage due to drm_vblank_wait > Message-Id: <20170710234235.25334-1-laurent.pinchart+rene...@ideasonboard.com> > > Feel free to add my Acked-by or Reviewed-by when you apply if you'd like. > > > drm-misc-next-2017-07-18: > UAPI Changes: > - Fail commits which request an event without including a crtc (Andrey) > > Core Changes: > - Add YCBCR 4:2:0 support (Shashank) > - s/drm_atomic_replace_property_blob/drm_property_replace_blob/ (Peter) > - Add proper base class for private objs instead of using void* (Ville) > - Remove pending_read/write_domains from drm_gem_object (Chris) > - Add async plane update support (ie: cursor) to atomic helpers (Gustavo) > - Add old state to .enable and rename to .atomic_enable (Laurent) > - Add drm_atomic_helper_wait_for_flip_done() (Boris) > - Remove drm_driver->set_busid hook (Daniel) > - Migrate vblank documentation into the source files (Daniel) > - Add fb_helper->lock instead of abusing modeset lock (Thierry/Daniel) > > Driver Changes: > - stm: Add STM32 DSI controller driver (Phillipe) > - amdgpu: Numerous small/misc fixes > - bridge: Add Synopsys Designware MIPI DSI host bridge driver (Phillipe) > - tinydrm: Add support for Pervasive Displays RePaper displays (Noralf) > - misc: Replace for_each_[obj]_in_state to prep for removal (Maarten) > - misc: Use .atomic_disable for atomic drivers (Laurent) > - vgem: Pin pages when mapped/exported (Chris) > - dw_hdmi: Add support for Rockchip RK3399 (Mark) > - atmel-hlcdc: Add 8-bit color look-up table format (Peter) > - vc4: Send vblank event when disabling a crtc (Boris) > - vc4: Use atomic helpers for fence waits (Eric) > - misc: drop drm_vblank_cleanup cargo-cult (Daniel) > > Cc: Daniel Vetter > Cc: Boris Brezillon > Cc: Eric Anholt > Cc: Peter Rosin > Cc: Mark Yao > Cc: Chris Wilson > Cc: Andrey Grodzovsky > Cc: Laurent Pinchart > Cc: Gustavo Padovan > Cc: Thierry Reding > Cc: Ville Syrjälä > Cc: Peter Rosin > Cc: Shashank Sharma > Cc: Philippe CORNU > > Thanks, Sean > > > The following changes since commit 6d61e70ccc21606ffb8a0a03bd3aba24f659502b: > > Backmerge tag 'v4.12-rc7' into drm-next (2017-06-27 08:28:30 +1000) > > are available in the git repository at: > > git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-2017-07-18 > > for you to fetch changes up to b1332aaabbdada327f2daffc7d69161cbf210ebf: > > drm: stm: remove "default y" in Kconfig (2017-07-18 10:03:25 +0200) > > > UAPI Changes: > - Fail commits which request an event without including a crtc (Andrey) > > Core Changes: > - Add YCBCR 4:2:0 support (Shashank) > - s/drm_atomic_replace_property_blob/drm_property_replace_blob/ (Peter) > - Add proper base class for private objs instead of using void* (Ville) > - Remove pending_read/write_domains from drm_gem_object (Chris) > - Add async plane update support (ie: cursor) to atomic helpers (Gustavo) > - Add old state to .enable and rename to .atomic_enable (Laurent) > - Add drm_atomic_helper_wait_for_flip_done() (Boris) > - Remove drm_driver->set_busid hook (Daniel) > - Migrate vblank documentation into the source files (Daniel) > - Add fb_helper->lock instead of abusing modeset lock (Thierry/Daniel) > > Driver Changes: > - stm: Add STM32 DSI controller driver (Phillipe) > - amdgpu: Numerous small/misc fixes > - bridge: Add Synopsys Designware MIPI DSI host bridge driver (Phillipe) > - tinydrm: Add support for Pervasive Displays RePaper displays (Noralf) > - misc: Replace for_each_[obj]_in_state to prep for removal (Maarten) > - misc: Use .atomic_disable for atomic drivers (Laurent) > - vgem: Pin pages when mapped/exported (Chris) > - dw_hdmi: Add support for Rockchip RK3399 (Mark) > - atmel-hlcdc: Add 8-bit color look-up table format (Peter) > - vc4: Send vblank event when disabling a crtc (Boris) > - vc4: Use atomic helpers for fence waits (Eric) > - misc: drop drm_vblank_cleanup cargo-cult (Daniel) > > Cc: Daniel Vetter > Cc: Boris Brezillon > Cc: Eric Anholt > Cc: Peter Rosin > Cc: Mark Yao > Cc: Chris Wilson > Cc: Andrey Grodzovsky > Cc: Laurent Pinchart > Cc: Gustavo Padovan > Cc: Thierry Reding > Cc: Ville Syrjälä > Cc: Peter Rosin > Cc: Shashank Sharma > Cc: Philippe CORNU > > > Alex Deucher (6): > drm/amd/powerplay/cz: print message if smc message fai
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq
== Series Details == Series: drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq URL : https://patchwork.freedesktop.org/series/27510/ State : success == Summary == Series 27510v1 drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq https://patchwork.freedesktop.org/api/1.0/series/27510/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-kbl-7560u) k.org#196399 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-b: pass -> DMESG-WARN (fi-pnv-d510) fdo#101597 Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-j1900) fdo#101705 +1 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 k.org#196399 https://bugzilla.kernel.org/show_bug.cgi?id=196399 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:440s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:426s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:354s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:530s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:508s fi-byt-j1900 total:279 pass:255 dwarn:0 dfail:0 fail:0 skip:24 time:499s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:489s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:605s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:436s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:422s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:419s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:498s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:467s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:464s fi-kbl-7560u total:279 pass:268 dwarn:1 dfail:0 fail:0 skip:10 time:574s fi-kbl-r total:279 pass:260 dwarn:1 dfail:0 fail:0 skip:18 time:579s fi-pnv-d510 total:279 pass:222 dwarn:2 dfail:0 fail:0 skip:55 time:559s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:458s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:585s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:469s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:481s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:435s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:471s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:541s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:401s 10de1e17faaab452782e5a1baffd1b30a639a261 drm-tip: 2017y-07m-18d-10h-08m-42s UTC integration manifest 3029bd6 drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5225/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5] drm/i915: Fix FBC cfb stride programming for non X-tiled FB
When FBC is enabled for linear, legacy Y-tiled and Yf-tiled
surfaces on gen9, the cfb stride must be programmed by SW as
cfb_stride = ceiling[(at least plane width in pixels)/
(32 * compression limit factor)] * 8
v2: Minor fix for a build error
v3: Fixed subject, register name and platform check (Ville)
v4: Added WA details in comment (Paulo)
v5:
- Read modified reg write to preserve other bit values (Paulo)
- Store modified stride value in reg_params (Paulo)
- Keep GLK out of the WA (Paulo)
Cc: Paulo Zanoni
Signed-off-by: Praveen Paneri
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_fbc.c | 19 +++
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c712d01..9e65f34 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6710,6 +6710,9 @@ enum {
#define CHICKEN_MISC_2 _MMIO(0x42084)
#define COMP_PWR_DOWN (1 << 23)
+#define CHICKEN_MISC_4 _MMIO(0x4208c)
+#define FBC_STRIDE_OVERRIDE (1<<13)
+
#define _CHICKEN_PIPESL_1_A0x420b0
#define _CHICKEN_PIPESL_1_B0x420b4
#define HSW_FBCQ_DIS (1 << 22)
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 860b8c2..251d3f4 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -288,9 +288,28 @@ static bool ilk_fbc_is_active(struct drm_i915_private
*dev_priv)
static void gen7_fbc_activate(struct drm_i915_private *dev_priv)
{
struct intel_fbc_reg_params *params = &dev_priv->fbc.params;
+ struct intel_fbc_state_cache *cache = &dev_priv->fbc.state_cache;
u32 dpfc_ctl;
int threshold = dev_priv->fbc.threshold;
+ /* Display WA #0529: skl, kbl, bxt but not for glk*/
+ if (IS_GEN9(dev_priv) && !IS_GEMINILAKE(dev_priv)) {
+ u32 chicken_misc4 = I915_READ(CHICKEN_MISC_4);
+
+ if (i915_gem_object_get_tiling(cache->vma->obj)
+ != I915_TILING_X) {
+ int cfb_stride = DIV_ROUND_UP(cache->plane.src_w,
+(32 * threshold)) * 8;
+ params->fb.stride = cfb_stride;
+
+ I915_WRITE(CHICKEN_MISC_4, chicken_misc4 |
+ FBC_STRIDE_OVERRIDE | cfb_stride);
+ } else {
+ I915_WRITE(CHICKEN_MISC_4, chicken_misc4 &
+ ~FBC_STRIDE_OVERRIDE);
+ }
+ }
+
dpfc_ctl = 0;
if (IS_IVYBRIDGE(dev_priv))
dpfc_ctl |= IVB_DPFC_CTL_PLANE(params->crtc.plane);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 12/14] drm/i915: Interface for controling engine stats collection
Quoting Tvrtko Ursulin (2017-07-18 15:36:16) > From: Tvrtko Ursulin > > Enables other i915 components to enable and disable > the facility as needed. > > Signed-off-by: Tvrtko Ursulin > --- > drivers/gpu/drm/i915/intel_engine_cs.c | 53 > + > drivers/gpu/drm/i915/intel_ringbuffer.h | 5 > 2 files changed, 58 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c > b/drivers/gpu/drm/i915/intel_engine_cs.c > index 3e5e08c6b5ef..03e7459bad06 100644 > --- a/drivers/gpu/drm/i915/intel_engine_cs.c > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c > @@ -29,6 +29,8 @@ > #include "intel_lrc.h" > > DEFINE_STATIC_KEY_FALSE(i915_engine_stats_key); > +static DEFINE_MUTEX(i915_engine_stats_mutex); > +static int i915_engine_stats_ref; > > /* Haswell does have the CXT_SIZE register however it does not appear to be > * valid. Now, docs explain in dwords what is in the context object. The full > @@ -1340,6 +1342,57 @@ void intel_engines_mark_idle(struct drm_i915_private > *i915) > } > } > > +int intel_enable_engine_stats(struct drm_i915_private *dev_priv) The pattern I've been trying to use here is intel_engine_* - operate on the named engine intel_engines_* - operate on all engines Long term though having a global static key is going to be a nasty wart. Joonas will definitely ask the question how much will it cost us to use an engine->bool and what we can do to minimise that cost. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next
Hi Dave, Here's the first -misc-next pull for 4.13, definitely the largest one I've sent to you. There's nothing too disruptive, a bunch of clean-up series which tidy up atomic macros, return value fixes, etc. New functionality includes 2 new dsi bridge drivers, async atomic commits, YCBCR 4:2:0 support, and RK3399 support in dw_hdmi. Note that there will be conflicts with Al's tree that went directly to Linus. Laurent posted a patch to fix this: Subject: [PATCH] drm: compat: Fix compilation breakage due to drm_vblank_wait Message-Id: <20170710234235.25334-1-laurent.pinchart+rene...@ideasonboard.com> Feel free to add my Acked-by or Reviewed-by when you apply if you'd like. drm-misc-next-2017-07-18: UAPI Changes: - Fail commits which request an event without including a crtc (Andrey) Core Changes: - Add YCBCR 4:2:0 support (Shashank) - s/drm_atomic_replace_property_blob/drm_property_replace_blob/ (Peter) - Add proper base class for private objs instead of using void* (Ville) - Remove pending_read/write_domains from drm_gem_object (Chris) - Add async plane update support (ie: cursor) to atomic helpers (Gustavo) - Add old state to .enable and rename to .atomic_enable (Laurent) - Add drm_atomic_helper_wait_for_flip_done() (Boris) - Remove drm_driver->set_busid hook (Daniel) - Migrate vblank documentation into the source files (Daniel) - Add fb_helper->lock instead of abusing modeset lock (Thierry/Daniel) Driver Changes: - stm: Add STM32 DSI controller driver (Phillipe) - amdgpu: Numerous small/misc fixes - bridge: Add Synopsys Designware MIPI DSI host bridge driver (Phillipe) - tinydrm: Add support for Pervasive Displays RePaper displays (Noralf) - misc: Replace for_each_[obj]_in_state to prep for removal (Maarten) - misc: Use .atomic_disable for atomic drivers (Laurent) - vgem: Pin pages when mapped/exported (Chris) - dw_hdmi: Add support for Rockchip RK3399 (Mark) - atmel-hlcdc: Add 8-bit color look-up table format (Peter) - vc4: Send vblank event when disabling a crtc (Boris) - vc4: Use atomic helpers for fence waits (Eric) - misc: drop drm_vblank_cleanup cargo-cult (Daniel) Cc: Daniel Vetter Cc: Boris Brezillon Cc: Eric Anholt Cc: Peter Rosin Cc: Mark Yao Cc: Chris Wilson Cc: Andrey Grodzovsky Cc: Laurent Pinchart Cc: Gustavo Padovan Cc: Thierry Reding Cc: Ville Syrjälä Cc: Peter Rosin Cc: Shashank Sharma Cc: Philippe CORNU Thanks, Sean The following changes since commit 6d61e70ccc21606ffb8a0a03bd3aba24f659502b: Backmerge tag 'v4.12-rc7' into drm-next (2017-06-27 08:28:30 +1000) are available in the git repository at: git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-2017-07-18 for you to fetch changes up to b1332aaabbdada327f2daffc7d69161cbf210ebf: drm: stm: remove "default y" in Kconfig (2017-07-18 10:03:25 +0200) UAPI Changes: - Fail commits which request an event without including a crtc (Andrey) Core Changes: - Add YCBCR 4:2:0 support (Shashank) - s/drm_atomic_replace_property_blob/drm_property_replace_blob/ (Peter) - Add proper base class for private objs instead of using void* (Ville) - Remove pending_read/write_domains from drm_gem_object (Chris) - Add async plane update support (ie: cursor) to atomic helpers (Gustavo) - Add old state to .enable and rename to .atomic_enable (Laurent) - Add drm_atomic_helper_wait_for_flip_done() (Boris) - Remove drm_driver->set_busid hook (Daniel) - Migrate vblank documentation into the source files (Daniel) - Add fb_helper->lock instead of abusing modeset lock (Thierry/Daniel) Driver Changes: - stm: Add STM32 DSI controller driver (Phillipe) - amdgpu: Numerous small/misc fixes - bridge: Add Synopsys Designware MIPI DSI host bridge driver (Phillipe) - tinydrm: Add support for Pervasive Displays RePaper displays (Noralf) - misc: Replace for_each_[obj]_in_state to prep for removal (Maarten) - misc: Use .atomic_disable for atomic drivers (Laurent) - vgem: Pin pages when mapped/exported (Chris) - dw_hdmi: Add support for Rockchip RK3399 (Mark) - atmel-hlcdc: Add 8-bit color look-up table format (Peter) - vc4: Send vblank event when disabling a crtc (Boris) - vc4: Use atomic helpers for fence waits (Eric) - misc: drop drm_vblank_cleanup cargo-cult (Daniel) Cc: Daniel Vetter Cc: Boris Brezillon Cc: Eric Anholt Cc: Peter Rosin Cc: Mark Yao Cc: Chris Wilson Cc: Andrey Grodzovsky Cc: Laurent Pinchart Cc: Gustavo Padovan Cc: Thierry Reding Cc: Ville Syrjälä Cc: Peter Rosin Cc: Shashank Sharma Cc: Philippe CORNU Alex Deucher (6): drm/amd/powerplay/cz: print message if smc message fails drm/amdgpu/psp: upper_32_bits/lower_32_bits for address setup drm/amdgpu: fix vblank_time when displays are off drm/amdgpu/cgs: always set reference clock in mode_info drm/amdgpu/gfx8: fix driver reload with KIQ drm/amdgpu/gfx9: fix driver reload with KIQ Alex Xie (
Re: [Intel-gfx] [PATCH] drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq
Quoting Dhinakaran Pandiyan (2017-07-18 19:28:00) > INTEL_GEN() appears to be the new way of doing these platform checks, so > convert this i915_irq.c too. > > Signed-off-by: Dhinakaran Pandiyan Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 3/3] drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface
Quoting Lionel Landwerlin (2017-07-18 17:50:42)
> static struct drm_driver driver = {
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 2b824f8875c4..607484737f3d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1917,6 +1917,9 @@ struct i915_oa_config {
> struct attribute_group sysfs_metric;
> struct attribute *attrs[2];
> struct device_attribute sysfs_metric_id;
> +
> + /* Only updated while holding dev_priv->perf.metrics_lock. */
> + bool in_use;
Definitely do not get warm fuzzy feeling about this.
Would making this a regular refcount be difficult? It would for example
allow removing whilst it is still in use by a stream (just removing it
from the user table so new streams cannot be created with it). And stop
me from making helpful suggestions about how in_use access is purely
atomic...
> + oa_config = kzalloc(sizeof(*oa_config), GFP_KERNEL);
> + if (!oa_config) {
> + DRM_DEBUG("Failed to allocate memory for the OA config\n");
> + return -ENOMEM;
> + }
> +
> + err = strncpy_from_user(oa_config->uuid, u64_to_user_ptr(args->uuid),
> + UUID_STRING_LEN);
So you have a fixed size buffer, why have userspace pass a pointer
rather than an array? Try char uuid[UUID_STRING_LEN] in
struct drm_i915_perf_oa_config and see which you think is eaiser to use
and, more importantly, harder to get wrong.
> + if (err < 0) {
> + DRM_DEBUG("Failed to copy uuid from OA config\n");
> + goto mux_err;
> + }
> +
> + if (!uuid_is_valid(oa_config->uuid)) {
> + DRM_DEBUG("Invalid uuid format for OA config\n");
> + err = -EINVAL;
> + goto mux_err;
> + }
> + idr_for_each_entry(&dev_priv->perf.metrics_idr, tmp, id) {
Comment that you don't expect many so this iteration shouldn't be too
costly.
> + if (!strcmp(tmp->uuid, oa_config->uuid)) {
> + DRM_DEBUG("OA config already exists with this
> uuid\n");
> + err = -EADDRINUSE;
> + goto sysfs_err;
> + }
> + }
> +
> + err = create_dynamic_oa_sysfs_entry(dev_priv, oa_config);
> + if (err) {
> + DRM_DEBUG("Failed to create sysfs entry for OA config\n");
> + goto sysfs_err;
> + }
> +
> + oa_config->id = idr_alloc(&dev_priv->perf.metrics_idr,
> + oa_config, 2,
Comment on reserving 0 for invalid and 1 for default.
> +}
> +/**
> + * Structure to upload perf dynamic configuration into the kernel.
> + */
> +struct drm_i915_perf_oa_config {
> + /** String formatted like "%08x-%04x-%04x-%04x-%012x" */
> + __u64 __user uuid;
Not a pointer, so __user is meaningless (and should generate warnings
from sparse). Equally it is nice to know in the name which of these are
encoding user pointers.
> + __u32 n_mux_regs;
> + __u32 pad0;
> + __u64 __user mux_regs;
> +
> + __u32 n_boolean_regs;
> + __u32 pad1;
> + __u64 __user boolean_regs;
> +
> + __u32 n_flex_regs;
> + __u32 pad2;
> + __u64 __user flex_regs;
With a little bit of rearranging you can reduce the padding.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq
INTEL_GEN() appears to be the new way of doing these platform checks, so
convert this i915_irq.c too.
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/i915_irq.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index eb4f1dc..4cdee95 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -275,17 +275,17 @@ void gen5_disable_gt_irq(struct drm_i915_private
*dev_priv, uint32_t mask)
static i915_reg_t gen6_pm_iir(struct drm_i915_private *dev_priv)
{
- return INTEL_INFO(dev_priv)->gen >= 8 ? GEN8_GT_IIR(2) : GEN6_PMIIR;
+ return INTEL_GEN(dev_priv) >= 8 ? GEN8_GT_IIR(2) : GEN6_PMIIR;
}
static i915_reg_t gen6_pm_imr(struct drm_i915_private *dev_priv)
{
- return INTEL_INFO(dev_priv)->gen >= 8 ? GEN8_GT_IMR(2) : GEN6_PMIMR;
+ return INTEL_GEN(dev_priv) >= 8 ? GEN8_GT_IMR(2) : GEN6_PMIMR;
}
static i915_reg_t gen6_pm_ier(struct drm_i915_private *dev_priv)
{
- return INTEL_INFO(dev_priv)->gen >= 8 ? GEN8_GT_IER(2) : GEN6_PMIER;
+ return INTEL_GEN(dev_priv) >= 8 ? GEN8_GT_IER(2) : GEN6_PMIER;
}
/**
@@ -1661,7 +1661,7 @@ static void gen6_rps_irq_handler(struct drm_i915_private
*dev_priv, u32 pm_iir)
spin_unlock(&dev_priv->irq_lock);
}
- if (INTEL_INFO(dev_priv)->gen >= 8)
+ if (INTEL_GEN(dev_priv) >= 8)
return;
if (HAS_VEBOX(dev_priv)) {
@@ -2440,7 +2440,7 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
u32 master_ctl)
ret = IRQ_HANDLED;
tmp_mask = GEN8_AUX_CHANNEL_A;
- if (INTEL_INFO(dev_priv)->gen >= 9)
+ if (INTEL_GEN(dev_priv) >= 9)
tmp_mask |= GEN9_AUX_CHANNEL_B |
GEN9_AUX_CHANNEL_C |
GEN9_AUX_CHANNEL_D;
@@ -2498,7 +2498,7 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
u32 master_ctl)
intel_check_page_flip(dev_priv, pipe);
flip_done = iir;
- if (INTEL_INFO(dev_priv)->gen >= 9)
+ if (INTEL_GEN(dev_priv) >= 9)
flip_done &= GEN9_PIPE_PLANE1_FLIP_DONE;
else
flip_done &= GEN8_PIPE_PRIMARY_FLIP_DONE;
@@ -2513,7 +2513,7 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
u32 master_ctl)
intel_cpu_fifo_underrun_irq_handler(dev_priv, pipe);
fault_errors = iir;
- if (INTEL_INFO(dev_priv)->gen >= 9)
+ if (INTEL_GEN(dev_priv) >= 9)
fault_errors &= GEN9_DE_PIPE_IRQ_FAULT_ERRORS;
else
fault_errors &= GEN8_DE_PIPE_IRQ_FAULT_ERRORS;
@@ -3492,7 +3492,7 @@ static void gen8_de_irq_postinstall(struct
drm_i915_private *dev_priv)
u32 de_misc_masked = GEN8_DE_MISC_GSE;
enum pipe pipe;
- if (INTEL_INFO(dev_priv)->gen >= 9) {
+ if (INTEL_GEN(dev_priv) >= 9) {
de_pipe_masked |= GEN9_PIPE_PLANE1_FLIP_DONE |
GEN9_DE_PIPE_IRQ_FAULT_ERRORS;
de_port_masked |= GEN9_AUX_CHANNEL_B | GEN9_AUX_CHANNEL_C |
@@ -4290,16 +4290,16 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
*
* TODO: verify if this can be reproduced on VLV,CHV.
*/
- if (INTEL_INFO(dev_priv)->gen <= 7)
+ if (INTEL_GEN(dev_priv) <= 7)
dev_priv->rps.pm_intrmsk_mbz |= GEN6_PM_RP_UP_EI_EXPIRED;
- if (INTEL_INFO(dev_priv)->gen >= 8)
+ if (INTEL_GEN(dev_priv) >= 8)
dev_priv->rps.pm_intrmsk_mbz |=
GEN8_PMINTR_DISABLE_REDIRECT_TO_GUC;
if (IS_GEN2(dev_priv)) {
/* Gen2 doesn't have a hardware frame counter */
dev->max_vblank_count = 0;
- } else if (IS_G4X(dev_priv) || INTEL_INFO(dev_priv)->gen >= 5) {
+ } else if (IS_G4X(dev_priv) || INTEL_GEN(dev_priv) >= 5) {
dev->max_vblank_count = 0x; /* full 32 bit counter */
dev->driver->get_vblank_counter = g4x_get_vblank_counter;
} else {
@@ -4346,7 +4346,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
dev->driver->enable_vblank = i965_enable_vblank;
dev->driver->disable_vblank = i965_disable_vblank;
dev_priv->display.hpd_irq_setup = i915_hpd_irq_setup;
- } else if (INTEL_INFO(dev_priv)->gen >= 8) {
+ } else if (INTEL_GEN(dev_priv) >= 8) {
dev->driver->irq_handler = gen8_irq_handler;
dev->driver->irq_preinstall = gen8_irq_reset;
dev->driver->irq_postinstall = gen8_irq_postinstall;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@l
Re: [Intel-gfx] [PATCH v4 i-g-t] igt/perf: add tests to verify create/destroy userspace configs
Quoting Lionel Landwerlin (2017-07-18 18:18:52)
> v2: Add tests regarding removing configs (Matthew)
> Add tests regarding adding/removing configs without permissions
> (Matthew)
>
> v3: Add some flex registers (Matthew)
>
> v4: memset oa_config to 0 (Lionel)
> Change error code for removing unexisting config EINVAL->ENOENT (Lionel)
>
> Signed-off-by: Lionel Landwerlin
> ---
> tests/perf.c | 208
> +++
> 1 file changed, 208 insertions(+)
>
> diff --git a/tests/perf.c b/tests/perf.c
> index 1c5cf351..66ec731a 100644
> --- a/tests/perf.c
> +++ b/tests/perf.c
> @@ -146,6 +146,36 @@ enum drm_i915_perf_record_type {
> };
> #endif /* !DRM_I915_PERF_OPEN */
>
> +#ifndef DRM_IOCTL_I915_PERF_ADD_CONFIG
> +
> +#define DRM_I915_PERF_ADD_CONFIG 0x37
> +#define DRM_I915_PERF_REMOVE_CONFIG0x38
> +
> +#define DRM_IOCTL_I915_PERF_ADD_CONFIG DRM_IOWR(DRM_COMMAND_BASE +
> DRM_I915_PERF_ADD_CONFIG, struct drm_i915_perf_oa_config)
> +#define DRM_IOCTL_I915_PERF_REMOVE_CONFIG DRM_IOWR(DRM_COMMAND_BASE +
> DRM_I915_PERF_REMOVE_CONFIG, __u64)
> +
> +/**
> + * Structure to upload perf dynamic configuration into the kernel.
> + */
> +struct drm_i915_perf_oa_config {
> + /** String formatted like "%08x-%04x-%04x-%04x-%012x" */
> + __u64 uuid;
> +
> + __u32 n_mux_regs;
> + __u32 pad0;
> + __u64 mux_regs;
> +
> + __u32 n_boolean_regs;
> + __u32 pad1;
> + __u64 boolean_regs;
> +
> + __u32 n_flex_regs;
> + __u32 pad2;
> + __u64 flex_regs;
> +};
> +
> +#endif /* !DRM_IOCTL_I915_PERF_ADD_CONFIG */
> +
> struct accumulator {
> #define MAX_RAW_OA_COUNTERS 62
> enum drm_i915_oa_format format;
> @@ -4001,6 +4031,175 @@ test_rc6_disable(void)
> igt_assert_neq(n_events_end - n_events_start, 0);
> }
>
> +static void
> +test_invalid_userspace_config_create(void)
> +{
> + struct drm_i915_perf_oa_config config;
> + const char *uuid = "01234567-0123-0123-0123-0123456789ab";
> + const char *invalid_uuid = "blablabla-wrong";
> + uint32_t mux_regs[] = { 0x9888 /* NOA_WRITE */, 0x0 };
> + uint32_t invalid_mux_regs[] = { 0x12345678 /* invalid register */,
> 0x0 };
> +
> + memset(&config, 0, sizeof(config));
> +
> + /* invalid uuid */
> + config.uuid = to_user_pointer(invalid_uuid);
> + config.n_mux_regs = 1;
> + config.mux_regs = to_user_pointer(mux_regs);
> + config.n_boolean_regs = 0;
> + config.n_flex_regs = 0;
> +
> + do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config, EINVAL);
Create little stubs like
int __i915_perf_add_config(int fd, config)
{
int err;
err = 0;
if (igt_ioctl(fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, config))
err = -errno;
return err;
}
void i915_perf_add_config(int fd, config)
{
igt_assert_eq(__i915_perf_add_config(fd, config), 0);
}
and here use igt_assert_eq(__i915_perf_add_config(fd, config), -EINVAL);
The benefit is that if you ever do hit the error, the message is much
more understandable than the macro expansion of
DRM_IOCTL_I915_PERF_ADD_CONFIG.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 3/6] drm/i915: prepare pipe for YCBCR420 output
On Mon, Jul 17, 2017 at 08:06:24PM +0530, Shashank Sharma wrote:
> To get HDMI YCBCR420 output, the PIPEMISC register should be
> programmed to:
> - Generate YCBCR output (bit 11)
> - In case of YCBCR420 outputs, it should be programmed in full
> blend mode to use the scaler in 5x3 ratio (bits 26 and 27)
>
> This patch:
> - Adds definition of these bits.
> - Programs PIPEMISC for YCBCR420 outputs.
> - Adds readouts to compare HW and SW states.
>
> V2: rebase
> V3: rebase
> V4: rebase
> V5: added r-b from Ander
> V6: Handle only YCBCR420 outputs (ville)
> V7: rebase
> V8: Addressed review comments from Ville
> - Add readouts for state->ycbcr420 and 420 pixel_clock.
> - Handle warning due to mismatch in clock for ycbcr420 clock.
> - Rename PIPEMISC macros to match the Bspec.
> - Add a debug print stating if YCBCR 4:2:0 output enabled.
> Added r-b from Ville
>
> Cc: Ville Syrjala
> Cc: Ander Conselvan de Oliveira
> Cc: Daniel Vetter
>
> Reviewed-by: Ander Conselvan de Oliveira
> Reviewed-by: Ville Syrjala
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 ++
> drivers/gpu/drm/i915/intel_display.c | 55
> ++--
> 2 files changed, 55 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index c712d01..6dfcdd3 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5227,6 +5227,9 @@ enum {
>
> #define _PIPE_MISC_A 0x70030
> #define _PIPE_MISC_B 0x71030
> +#define PIPEMISC_YUV420_ENABLE (1<<27)
> +#define PIPEMISC_YUV420_MODE_BLEND (1<<26)
> +#define PIPEMISC_OUTPUT_YUV(1<<11)
Missing the rename here requested by Ville.
> #define PIPEMISC_DITHER_BPC_MASK (7<<5)
> #define PIPEMISC_DITHER_8_BPC (0<<5)
> #define PIPEMISC_DITHER_10_BPC (1<<5)
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index d78f1c2..788502a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6216,7 +6216,6 @@ static uint32_t ilk_pipe_pixel_rate(const struct
> intel_crtc_state *pipe_config)
>* We only use IF-ID interlacing. If we ever use
>* PF-ID we'll need to adjust the pixel_rate here.
>*/
> -
Extra w/s change.
> if (pipe_config->pch_pfit.enabled) {
> uint64_t pipe_w, pipe_h, pfit_w, pfit_h;
> uint32_t pfit_size = pipe_config->pch_pfit.size;
> @@ -8076,6 +8075,7 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + struct intel_crtc_state *config = intel_crtc->config;
>
> if (IS_BROADWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 9) {
> u32 val = 0;
> @@ -8101,6 +8101,12 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
> if (intel_crtc->config->dither)
> val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
>
> + if (config->ycbcr420) {
> + val |= PIPEMISC_OUTPUT_YUV |
> + PIPEMISC_YUV420_ENABLE |
> + PIPEMISC_YUV420_MODE_BLEND;
> + }
> +
> I915_WRITE(PIPEMISC(intel_crtc->pipe), val);
> }
> }
> @@ -9170,6 +9176,10 @@ static bool haswell_get_pipe_config(struct intel_crtc
> *crtc,
> pipe_config->scaler_state.scaler_users &= ~(1 <<
> SKL_CRTC_INDEX);
> }
>
> + if (IS_GEMINILAKE(dev_priv))
> + pipe_config->ycbcr420 = I915_READ(PIPEMISC(crtc->pipe)) &
> + PIPEMISC_YUV420_ENABLE;
> +
> power_domain = POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe);
> if (intel_display_power_get_if_enabled(dev_priv, power_domain)) {
> power_domain_mask |= BIT_ULL(power_domain);
> @@ -11377,6 +11387,9 @@ static void intel_dump_pipe_config(struct intel_crtc
> *crtc,
> pipe_config->fdi_lanes,
> &pipe_config->fdi_m_n);
>
> + if (pipe_config->ycbcr420)
> + DRM_DEBUG_KMS("YCbCr 4:2:0 output enabled\n");
> +
> if (intel_crtc_has_dp_encoder(pipe_config)) {
> intel_dump_m_n_config(pipe_config, "dp m_n",
> pipe_config->lane_count, &pipe_config->dp_m_n);
> @@ -11704,6 +11717,22 @@ intel_modeset_update_crtc_state(struct
> drm_atomic_state *state)
> }
> }
>
> +static bool intel_420_clock_check(int clock1, int clock2)
> +{
> + int diff;
> +
> + if (clock1 == clock2 * 2)
> + return true;
> +
> + clock2 *= 2;
> + diff = abs(clock1 - clock2);
> +
> + if (diff + clock1 + clock2) * 100)) / (clock1 + clock2)) < 105)
> + retur
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Attach a stub pm_domain
== Series Details == Series: drm/i915/selftests: Attach a stub pm_domain URL : https://patchwork.freedesktop.org/series/27505/ State : success == Summary == Series 27505v1 drm/i915/selftests: Attach a stub pm_domain https://patchwork.freedesktop.org/api/1.0/series/27505/revisions/1/mbox/ Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-legacy: pass -> FAIL (fi-snb-2600) fdo#100215 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-j1900) fdo#101705 +1 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:442s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:430s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:359s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:537s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:505s fi-byt-j1900 total:279 pass:255 dwarn:0 dfail:0 fail:0 skip:24 time:496s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:487s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:594s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:434s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:416s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:416s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:500s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:470s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:468s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:569s fi-kbl-r total:279 pass:260 dwarn:1 dfail:0 fail:0 skip:18 time:576s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:558s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:452s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:585s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:464s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:480s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:434s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:467s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:537s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:409s 10de1e17faaab452782e5a1baffd1b30a639a261 drm-tip: 2017y-07m-18d-10h-08m-42s UTC integration manifest 4bf673b drm/i915/selftests: Attach a stub pm_domain == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5223/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Only free the oldest stale object before a fresh allocation
Inspired by Tvrtko's critique of the reaping of the stale contexts
before allocating a new one, also limit the freed object reaping to the
oldest stale object before allocating a fresh object. Unlike contexts,
objects may have radically different sizes of backing storage, but
similar to contexts, whilst we want to prevent starvation due to
excessive freed lists, we also want do not want to delay fresh
allocations for too long. Only freeing the oldest on the freed object
list before each allocation is a reasonable compromise.
v2: Only a single consumer of llist_del_first() is allowed (although
multiple llist_add are still allowed in parallel). Unlike
i915_gem_context, i915_gem_flush_free_objects() is itself not serialized
and so we need to add our own spinlock. Otherwise KASAN eventually spots
a use-after-free for the race on *first->next.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin #v1
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 14 --
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 667fb5c44483..e1c2bc66e0fd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1447,6 +1447,7 @@ struct i915_gem_mm {
*/
struct llist_head free_list;
struct work_struct free_work;
+ spinlock_t free_lock;
/** Usable portion of the GTT for GEM */
dma_addr_t stolen_base; /* limited to low memory (32-bit) */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2c2907fef612..d57603f64e96 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4542,9 +4542,18 @@ static void i915_gem_flush_free_objects(struct
drm_i915_private *i915)
{
struct llist_node *freed;
- freed = llist_del_all(&i915->mm.free_list);
- if (unlikely(freed))
+ /* Free the oldest, most stale object to keep the free_list short */
+ freed = NULL;
+ if (!llist_empty(&i915->mm.free_list)) { /* quick test for hotpath */
+ /* Only one consumer of llist_del_first() allowed */
+ spin_lock(&i915->mm.free_lock);
+ freed = llist_del_first(&i915->mm.free_list);
+ spin_unlock(&i915->mm.free_lock);
+ }
+ if (unlikely(freed)) {
+ freed->next = NULL;
__i915_gem_free_objects(i915, freed);
+ }
}
static void __i915_gem_free_work(struct work_struct *work)
@@ -5026,6 +5035,7 @@ i915_gem_load_init(struct drm_i915_private *dev_priv)
INIT_WORK(&dev_priv->mm.free_work, __i915_gem_free_work);
spin_lock_init(&dev_priv->mm.obj_lock);
+ spin_lock_init(&dev_priv->mm.free_lock);
init_llist_head(&dev_priv->mm.free_list);
INIT_LIST_HEAD(&dev_priv->mm.unbound_list);
INIT_LIST_HEAD(&dev_priv->mm.bound_list);
--
2.13.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Attach a stub pm_domain
Supply a pm_domain and its ops for our mock GEM device so that
device runtime pm doesn't complain even though we only want to mark it
permanently active!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 47613d20bba8..99c038249454 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -22,6 +22,7 @@
*
*/
+#include
#include
#include "mock_engine.h"
@@ -109,6 +110,23 @@ static void mock_idle_work_handler(struct work_struct
*work)
{
}
+static int pm_domain_resume(struct device *dev)
+{
+ return pm_generic_runtime_resume(dev);
+}
+
+static int pm_domain_suspend(struct device *dev)
+{
+ return pm_generic_runtime_suspend(dev);
+}
+
+static struct dev_pm_domain pm_domain = {
+ .ops = {
+ .runtime_suspend = pm_domain_suspend,
+ .runtime_resume = pm_domain_resume,
+ },
+};
+
struct drm_i915_private *mock_gem_device(void)
{
struct drm_i915_private *i915;
@@ -127,8 +145,10 @@ struct drm_i915_private *mock_gem_device(void)
dev_set_name(&pdev->dev, "mock");
dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
+ dev_pm_domain_set(&pdev->dev, &pm_domain);
+ pm_runtime_enable(&pdev->dev);
pm_runtime_dont_use_autosuspend(&pdev->dev);
- pm_runtime_get_sync(&pdev->dev);
+ WARN_ON(pm_runtime_get_sync(&pdev->dev));
i915 = (struct drm_i915_private *)(pdev + 1);
pci_set_drvdata(pdev, i915);
--
2.13.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 i-g-t] igt/perf: add tests to verify create/destroy userspace configs
v2: Add tests regarding removing configs (Matthew)
Add tests regarding adding/removing configs without permissions
(Matthew)
v3: Add some flex registers (Matthew)
v4: memset oa_config to 0 (Lionel)
Change error code for removing unexisting config EINVAL->ENOENT (Lionel)
Signed-off-by: Lionel Landwerlin
---
tests/perf.c | 208 +++
1 file changed, 208 insertions(+)
diff --git a/tests/perf.c b/tests/perf.c
index 1c5cf351..66ec731a 100644
--- a/tests/perf.c
+++ b/tests/perf.c
@@ -146,6 +146,36 @@ enum drm_i915_perf_record_type {
};
#endif /* !DRM_I915_PERF_OPEN */
+#ifndef DRM_IOCTL_I915_PERF_ADD_CONFIG
+
+#define DRM_I915_PERF_ADD_CONFIG 0x37
+#define DRM_I915_PERF_REMOVE_CONFIG0x38
+
+#define DRM_IOCTL_I915_PERF_ADD_CONFIG DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_PERF_ADD_CONFIG, struct drm_i915_perf_oa_config)
+#define DRM_IOCTL_I915_PERF_REMOVE_CONFIG DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_PERF_REMOVE_CONFIG, __u64)
+
+/**
+ * Structure to upload perf dynamic configuration into the kernel.
+ */
+struct drm_i915_perf_oa_config {
+ /** String formatted like "%08x-%04x-%04x-%04x-%012x" */
+ __u64 uuid;
+
+ __u32 n_mux_regs;
+ __u32 pad0;
+ __u64 mux_regs;
+
+ __u32 n_boolean_regs;
+ __u32 pad1;
+ __u64 boolean_regs;
+
+ __u32 n_flex_regs;
+ __u32 pad2;
+ __u64 flex_regs;
+};
+
+#endif /* !DRM_IOCTL_I915_PERF_ADD_CONFIG */
+
struct accumulator {
#define MAX_RAW_OA_COUNTERS 62
enum drm_i915_oa_format format;
@@ -4001,6 +4031,175 @@ test_rc6_disable(void)
igt_assert_neq(n_events_end - n_events_start, 0);
}
+static void
+test_invalid_userspace_config_create(void)
+{
+ struct drm_i915_perf_oa_config config;
+ const char *uuid = "01234567-0123-0123-0123-0123456789ab";
+ const char *invalid_uuid = "blablabla-wrong";
+ uint32_t mux_regs[] = { 0x9888 /* NOA_WRITE */, 0x0 };
+ uint32_t invalid_mux_regs[] = { 0x12345678 /* invalid register */, 0x0
};
+
+ memset(&config, 0, sizeof(config));
+
+ /* invalid uuid */
+ config.uuid = to_user_pointer(invalid_uuid);
+ config.n_mux_regs = 1;
+ config.mux_regs = to_user_pointer(mux_regs);
+ config.n_boolean_regs = 0;
+ config.n_flex_regs = 0;
+
+ do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config, EINVAL);
+
+ /* invalid mux_regs */
+ config.uuid = to_user_pointer(uuid);
+ config.n_mux_regs = 1;
+ config.mux_regs = to_user_pointer(invalid_mux_regs);
+ config.n_boolean_regs = 0;
+ config.n_flex_regs = 0;
+
+ do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config, EINVAL);
+
+ /* empty config */
+ config.uuid = to_user_pointer(uuid);
+ config.n_mux_regs = 0;
+ config.mux_regs = to_user_pointer(mux_regs);
+ config.n_boolean_regs = 0;
+ config.n_flex_regs = 0;
+
+ do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config, EINVAL);
+
+ /* empty config with null pointers */
+ config.uuid = to_user_pointer(uuid);
+ config.n_mux_regs = 1;
+ config.mux_regs = to_user_pointer(NULL);
+ config.n_boolean_regs = 2;
+ config.boolean_regs = to_user_pointer(NULL);
+ config.n_flex_regs = 3;
+ config.flex_regs = to_user_pointer(NULL);
+
+ do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config, EINVAL);
+}
+
+static void
+test_invalid_userspace_config_remove(void)
+{
+ struct drm_i915_perf_oa_config config;
+ const char *uuid = "01234567-0123-0123-0123-0123456789ab";
+ uint32_t mux_regs[] = { 0x9888 /* NOA_WRITE */, 0x0 };
+ uint64_t config_id, wrong_config_id = 9;
+ char path[512];
+ int ret;
+
+ snprintf(path, sizeof(path), "/sys/class/drm/card%d/metrics/%s/id",
card, uuid);
+
+ /* Destroy previous configuration if present */
+ if (try_read_u64_file(path, &config_id))
+ igt_assert(igt_ioctl(drm_fd, DRM_IOCTL_I915_PERF_REMOVE_CONFIG,
&config_id) == 0);
+
+ memset(&config, 0, sizeof(config));
+
+ config.uuid = to_user_pointer(uuid);
+
+ config.n_mux_regs = 1;
+ config.mux_regs = to_user_pointer(mux_regs);
+ config.n_boolean_regs = 0;
+ config.n_flex_regs = 0;
+
+ ret = igt_ioctl(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config);
+ igt_assert(ret > 0);
+ config_id = ret;
+
+ /* Removing configs without permissions should fail. */
+ igt_fork(child, 1) {
+ igt_drop_root();
+
+ do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_REMOVE_CONFIG,
&config_id, EACCES);
+ }
+ igt_waitchildren();
+
+ /* Removing invalid config ID should fail. */
+ do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_REMOVE_CONFIG,
&wrong_config_id, ENOENT);
+
+ igt_assert(igt_ioctl(drm_fd, DRM_IOCTL_I915_PERF_REMOVE_CONFIG,
&config_id) == 0);
+}
+
[Intel-gfx] [PATCH i-g-t v3 3/5] lib/igt_draw: add support for Y tiling
From: Paulo Zanoni
From: Paulo Zanoni
Most of the patch is to change the tile/untile functions so they can
work with Y-major tiling.
v2: (Praveen) No skipping on BLT for Y-tile now as we have a fix
for that.
Reviewed-by: Praveen Paneri
Signed-off-by: Paulo Zanoni
Signed-off-by: Praveen Paneri
---
lib/igt_draw.c | 171 -
1 file changed, 121 insertions(+), 50 deletions(-)
diff --git a/lib/igt_draw.c b/lib/igt_draw.c
index db55cd9..76ffb6c 100644
--- a/lib/igt_draw.c
+++ b/lib/igt_draw.c
@@ -135,71 +135,118 @@ static int swizzle_addr(int addr, int swizzle)
return addr;
}
-/* It's all in "pixel coordinates", so make sure you multiply/divide by the bpp
- * if you need to. */
-static int linear_x_y_to_tiled_pos(int x, int y, uint32_t stride, int swizzle,
- int bpp)
+static int tile(int x, int y, uint32_t x_tile_size, uint32_t y_tile_size,
+ uint32_t line_size, bool xmajor)
{
- int x_tile_size, y_tile_size;
- int x_tile_n, y_tile_n, x_tile_off, y_tile_off;
- int line_size, tile_size;
- int tile_n, tile_off;
- int tiled_pos, tiles_per_line;
- int pixel_size = bpp / 8;
+ int tile_size, tiles_per_line, x_tile_n, y_tile_n, tile_off, pos;
+ int tile_n, x_tile_off, y_tile_off;
- line_size = stride;
- x_tile_size = 512;
- y_tile_size = 8;
- tile_size = x_tile_size * y_tile_size;
tiles_per_line = line_size / x_tile_size;
+ tile_size = x_tile_size * y_tile_size;
+ x_tile_n = x / x_tile_size;
y_tile_n = y / y_tile_size;
- y_tile_off = y % y_tile_size;
+ tile_n = y_tile_n * tiles_per_line + x_tile_n;
- x_tile_n = (x * pixel_size) / x_tile_size;
- x_tile_off = (x * pixel_size) % x_tile_size;
+ x_tile_off = x % x_tile_size;
+ y_tile_off = y % y_tile_size;
- tile_n = y_tile_n * tiles_per_line + x_tile_n;
- tile_off = y_tile_off * x_tile_size + x_tile_off;
- tiled_pos = tile_n * tile_size + tile_off;
+ if (xmajor)
+ tile_off = y_tile_off * x_tile_size + x_tile_off;
+ else
+ tile_off = x_tile_off * y_tile_size + y_tile_off;
- tiled_pos = swizzle_addr(tiled_pos, swizzle);
+ pos = tile_n * tile_size + tile_off;
- return tiled_pos / pixel_size;
+ return pos;
}
-/* It's all in "pixel coordinates", so make sure you multiply/divide by the bpp
- * if you need to. */
-static void tiled_pos_to_x_y_linear(int tiled_pos, uint32_t stride,
- int swizzle, int bpp, int *x, int *y)
+static void untile(int tiled_pos, int x_tile_size, int y_tile_size,
+ uint32_t line_size, bool xmajor, int *x, int *y)
{
- int tile_n, tile_off, tiles_per_line, line_size;
+ int tile_n, tile_off, tiles_per_line;
int x_tile_off, y_tile_off;
int x_tile_n, y_tile_n;
- int x_tile_size, y_tile_size, tile_size;
- int pixel_size = bpp / 8;
-
- tiled_pos = swizzle_addr(tiled_pos, swizzle);
+ int tile_size;
- line_size = stride;
- x_tile_size = 512;
- y_tile_size = 8;
tile_size = x_tile_size * y_tile_size;
tiles_per_line = line_size / x_tile_size;
tile_n = tiled_pos / tile_size;
tile_off = tiled_pos % tile_size;
- y_tile_off = tile_off / x_tile_size;
- x_tile_off = tile_off % x_tile_size;
+ if (xmajor) {
+ y_tile_off = tile_off / x_tile_size;
+ x_tile_off = tile_off % x_tile_size;
+ } else {
+ y_tile_off = tile_off % y_tile_size;
+ x_tile_off = tile_off / y_tile_size;
+ }
x_tile_n = tile_n % tiles_per_line;
y_tile_n = tile_n / tiles_per_line;
- *x = (x_tile_n * x_tile_size + x_tile_off) / pixel_size;
+ *x = (x_tile_n * x_tile_size + x_tile_off);
*y = y_tile_n * y_tile_size + y_tile_off;
}
+static int linear_x_y_to_xtiled_pos(int x, int y, uint32_t stride, int swizzle,
+ int bpp)
+{
+ int pos;
+ int pixel_size = bpp / 8;
+
+ x *= pixel_size;
+ pos = tile(x, y, 512, 8, stride, true);
+ pos = swizzle_addr(pos, swizzle);
+ return pos / pixel_size;
+}
+
+static int linear_x_y_to_ytiled_pos(int x, int y, uint32_t stride, int swizzle,
+ int bpp)
+{
+ int ow_tile_n, pos;
+ int ow_size = 16;
+ int pixel_size = bpp / 8;
+
+ /* We have an Y tiling of OWords, so use the tile() function to get the
+* OW number, then adjust to the fact that the OW may have more than one
+* pixel. */
+ x *= pixel_size;
+ ow_tile_n = tile(x / ow_size, y, 128 / ow_size, 32,
+stride / ow_size, false);
+ pos = ow_tile_n * ow_size + (x % ow_size);
+ pos = swizzle_addr(pos, swizzle);
+
[Intel-gfx] [PATCH i-g-t v3 0/5] Add Y-tiling support into IGTs
This series adds Y-tiled buffer creation support into IGT libraries and goes on to use this capability to add support into FBC tests to use Y-tiled buffers. v2: Adressed review comments v3: Included original patches from Paulo and addressed more comments Paulo Zanoni (2): lib/igt_draw: add support for Y tiling tests/kms_draw_crc: add support for Y tiling Praveen Paneri (3): lib/igt_fb: Let others use igt_get_fb_tile_size lib/igt_fb: Add helper function for tile_to_mod igt/kms_fbc_crc.c : Add Y-tile tests lib/igt_draw.c | 171 --- lib/igt_fb.c | 41 +++- lib/igt_fb.h | 3 + tests/kms_draw_crc.c | 55 - tests/kms_fbc_crc.c | 73 +- 5 files changed, 246 insertions(+), 97 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v3 1/5] lib/igt_fb: Let others use igt_get_fb_tile_size
From: Praveen Paneri
This function can be used by igt_draw to get accurate
tile dimensions for all tile formats.
v2: Added comments to function igt_get_fb_tile_size (Daniel)
v3: Fixed errors in comments and coding style (Paulo)
Signed-off-by: Praveen Paneri
---
lib/igt_fb.c | 15 +--
lib/igt_fb.h | 2 ++
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index d2b7e9e..c94f95e 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -74,8 +74,19 @@ static struct format_desc_struct {
#define for_each_format(f) \
for (f = format_desc; f - format_desc < ARRAY_SIZE(format_desc); f++)
-static void igt_get_fb_tile_size(int fd, uint64_t tiling, int fb_bpp,
-unsigned *width_ret, unsigned *height_ret)
+/**
+ * igt_get_fb_tile_size:
+ * @fd: the DRM file descriptor
+ * @tiling: tiling layout of the framebuffer (as framebuffer modifier)
+ * @fb_bpp: bits per pixel of the framebuffer
+ * @width_ret: width of the tile in bytes
+ * @height_ret: height of the tile in lines
+ *
+ * This function returns width and height of a tile based on the given tiling
+ * format.
+ */
+void igt_get_fb_tile_size(int fd, uint64_t tiling, int fb_bpp,
+ unsigned *width_ret, unsigned *height_ret)
{
switch (tiling) {
case LOCAL_DRM_FORMAT_MOD_NONE:
diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index 4a680ce..010ed3a 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -95,6 +95,8 @@ enum igt_text_align {
align_hcenter = 0x08,
};
+void igt_get_fb_tile_size(int fd, uint64_t tiling, int fb_bpp,
+ unsigned *width_ret, unsigned *height_ret);
void igt_calc_fb_size(int fd, int width, int height, int bpp, uint64_t tiling,
unsigned *size_ret, unsigned *stride_ret);
unsigned int
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v3 5/5] igt/kms_fbc_crc.c : Add Y-tile tests
From: Praveen Paneri
Now that we have support for Y-tiled buffers, add another
iteration of tests for Y-tiled buffers.
v3:
- Iterate over tiling modifier instead of tiling constant (Paulo)
- Improved logging and fixed indentation (Paulo)
Signed-off-by: Praveen Paneri
---
tests/kms_fbc_crc.c | 69 ++---
1 file changed, 44 insertions(+), 25 deletions(-)
diff --git a/tests/kms_fbc_crc.c b/tests/kms_fbc_crc.c
index 7964e05..74debfb 100644
--- a/tests/kms_fbc_crc.c
+++ b/tests/kms_fbc_crc.c
@@ -318,12 +318,10 @@ static void prepare_crtc(data_t *data)
igt_output_set_pipe(output, data->pipe);
}
-static void create_fbs(data_t *data, bool tiled, struct igt_fb *fbs)
+static void create_fbs(data_t *data, uint64_t tiling, struct igt_fb *fbs)
{
int rc;
drmModeModeInfo *mode = igt_output_get_mode(data->output);
- uint64_t tiling = tiled ? LOCAL_I915_FORMAT_MOD_X_TILED :
- LOCAL_DRM_FORMAT_MOD_NONE;
rc = igt_create_color_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
DRM_FORMAT_XRGB, tiling,
@@ -344,8 +342,8 @@ static void get_ref_crcs(data_t *data)
struct igt_fb fbs[4];
int i;
- create_fbs(data, false, &fbs[0]);
- create_fbs(data, false, &fbs[2]);
+ create_fbs(data, LOCAL_DRM_FORMAT_MOD_NONE, &fbs[0]);
+ create_fbs(data, LOCAL_DRM_FORMAT_MOD_NONE, &fbs[2]);
fill_mmap_gtt(data, fbs[2].gem_handle, 0xff);
fill_mmap_gtt(data, fbs[3].gem_handle, 0xff);
@@ -366,7 +364,7 @@ static void get_ref_crcs(data_t *data)
igt_remove_fb(data->drm_fd, &fbs[i]);
}
-static bool prepare_test(data_t *data, enum test_mode test_mode)
+static bool prepare_test(data_t *data, enum test_mode test_mode, uint64_t
tiling)
{
igt_display_t *display = &data->display;
igt_output_t *output = data->output;
@@ -374,7 +372,7 @@ static bool prepare_test(data_t *data, enum test_mode
test_mode)
data->primary = igt_output_get_plane_type(data->output,
DRM_PLANE_TYPE_PRIMARY);
- create_fbs(data, true, data->fb);
+ create_fbs(data, tiling, data->fb);
igt_pipe_crc_free(data->pipe_crc);
data->pipe_crc = NULL;
@@ -475,6 +473,7 @@ static void run_test(data_t *data, enum test_mode mode)
{
igt_display_t *display = &data->display;
int valid_tests = 0;
+ uint64_t tiling_methods[] = {LOCAL_I915_FORMAT_MOD_X_TILED,
LOCAL_I915_FORMAT_MOD_Y_TILED};
if (mode == TEST_CONTEXT || mode == TEST_PAGE_FLIP_AND_CONTEXT) {
drm_intel_context *ctx =
drm_intel_gem_context_create(data->bufmgr);
@@ -484,32 +483,52 @@ static void run_test(data_t *data, enum test_mode mode)
reset_display(data);
- for_each_pipe_with_valid_output(display, data->pipe, data->output) {
- prepare_crtc(data);
+ for (int i=0; i < (sizeof(tiling_methods)/sizeof(tiling_methods[0]));
+i++) {
+ uint64_t tiling = tiling_methods[i];
- igt_info("Beginning %s on pipe %s, connector %s\n",
- igt_subtest_name(),
- kmstest_pipe_name(data->pipe),
- igt_output_name(data->output));
+ if(intel_gen(intel_get_drm_devid(data->drm_fd)) < 9 &&
+ tiling == LOCAL_I915_FORMAT_MOD_Y_TILED) {
+ igt_info("Y-tiling not supported for this platform\n");
+ continue;
+ }
+
+ for_each_pipe_with_valid_output(display,
+ data->pipe, data->output) {
+ const char *tiling_name =
+ (tiling ==
LOCAL_I915_FORMAT_MOD_Y_TILED) ? "x":"y";
+ prepare_crtc(data);
- if (!prepare_test(data, mode)) {
- igt_info("%s on pipe %s, connector %s: SKIPPED\n",
+ igt_info("Beginning %s on pipe %s, connector "
+ "%s, %s-tiled\n",
igt_subtest_name(),
kmstest_pipe_name(data->pipe),
- igt_output_name(data->output));
- continue;
- }
+ igt_output_name(data->output),
+ tiling_name);
- valid_tests++;
+ if (!prepare_test(data, mode, tiling)) {
+ igt_info("%s on pipe %s, connector "
+ "%s, %s-tiled: SKIPPED\n",
+ igt_subtest_name(),
+ kmstest_pipe_name(data->pipe),
+ igt_output_name(data->output),
+
[Intel-gfx] [PATCH i-g-t v3 4/5] tests/kms_draw_crc: add support for Y tiling
From: Paulo Zanoni
From: Paulo Zanoni
This is the program that's supposed to test lib/igt_draw. We just
added Y tiling support for the library, so add the tests now.
Reviewed-by: Praveen Paneri
Signed-off-by: Paulo Zanoni
Signed-off-by: Praveen Paneri
---
tests/kms_draw_crc.c | 55 ++--
1 file changed, 40 insertions(+), 15 deletions(-)
diff --git a/tests/kms_draw_crc.c b/tests/kms_draw_crc.c
index c57d3a3..906d89f 100644
--- a/tests/kms_draw_crc.c
+++ b/tests/kms_draw_crc.c
@@ -47,6 +47,13 @@ static const uint32_t formats[N_FORMATS] = {
DRM_FORMAT_XRGB2101010,
};
+#define N_TILING_METHODS 3
+static const uint64_t tilings[N_TILING_METHODS] = {
+ LOCAL_DRM_FORMAT_MOD_NONE,
+ LOCAL_I915_FORMAT_MOD_X_TILED,
+ LOCAL_I915_FORMAT_MOD_Y_TILED,
+};
+
struct base_crc {
bool set;
igt_crc_t crc;
@@ -151,6 +158,9 @@ static void draw_method_subtest(enum igt_draw_method method,
{
igt_crc_t crc;
+ if (tiling == LOCAL_I915_FORMAT_MOD_Y_TILED)
+ igt_require(intel_gen(intel_get_drm_devid(drm_fd)) >= 9);
+
/* Use IGT_DRAW_MMAP_GTT on an untiled buffer as the parameter for
* comparison. Cache the value so we don't recompute it for every single
* subtest. */
@@ -208,6 +218,11 @@ static void fill_fb_subtest(void)
get_fill_crc(LOCAL_I915_FORMAT_MOD_X_TILED, &crc);
igt_assert_crc_equal(&crc, &base_crc);
+ if (intel_gen(intel_get_drm_devid(drm_fd)) >= 9) {
+ get_fill_crc(LOCAL_I915_FORMAT_MOD_Y_TILED, &crc);
+ igt_assert_crc_equal(&crc, &base_crc);
+ }
+
igt_remove_fb(drm_fd, &fb);
}
@@ -265,28 +280,38 @@ static const char *format_str(int format_index)
}
}
+static const char *tiling_str(int tiling_index)
+{
+ switch (tilings[tiling_index]) {
+ case LOCAL_DRM_FORMAT_MOD_NONE:
+ return "untiled";
+ case LOCAL_I915_FORMAT_MOD_X_TILED:
+ return "xtiled";
+ case LOCAL_I915_FORMAT_MOD_Y_TILED:
+ return "ytiled";
+ default:
+ igt_assert(false);
+ }
+}
+
igt_main
{
enum igt_draw_method method;
- int format_index;
+ int format_idx, tiling_idx;
igt_fixture
setup_environment();
- for (format_index = 0; format_index < N_FORMATS; format_index++) {
- for (method = 0; method < IGT_DRAW_METHOD_COUNT; method++) {
- igt_subtest_f("draw-method-%s-%s-untiled",
- format_str(format_index),
- igt_draw_get_method_name(method))
- draw_method_subtest(method, format_index,
- LOCAL_DRM_FORMAT_MOD_NONE);
- igt_subtest_f("draw-method-%s-%s-tiled",
- format_str(format_index),
- igt_draw_get_method_name(method))
- draw_method_subtest(method, format_index,
- LOCAL_I915_FORMAT_MOD_X_TILED);
- }
- }
+ for (format_idx = 0; format_idx < N_FORMATS; format_idx++) {
+ for (method = 0; method < IGT_DRAW_METHOD_COUNT; method++) {
+ for (tiling_idx = 0; tiling_idx < N_TILING_METHODS; tiling_idx++) {
+ igt_subtest_f("draw-method-%s-%s-%s",
+ format_str(format_idx),
+ igt_draw_get_method_name(method),
+ tiling_str(tiling_idx))
+ draw_method_subtest(method, format_idx,
+ tilings[tiling_idx]);
+ } } }
igt_subtest("fill-fb")
fill_fb_subtest();
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v3 2/5] lib/igt_fb: Add helper function for tile_to_mod
From: Praveen Paneri
igt_get_fb_tile_size function takes modifer as an argument
This helper function will let users to convert tiling to
modifier and use igt_get_fb_tile_size()
v2: Improved code comment (Paulo)
Signed-off-by: Praveen Paneri
---
lib/igt_fb.c | 26 ++
lib/igt_fb.h | 1 +
2 files changed, 27 insertions(+)
diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index c94f95e..042b413 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -217,6 +217,32 @@ uint64_t igt_fb_mod_to_tiling(uint64_t modifier)
}
}
+/**
+ * igt_fb_tiling_to_mod:
+ * @tiling: DRM framebuffer tiling
+ *
+ * This function converts a DRM framebuffer tiling to its corresponding
+ * modifier constant.
+ *
+ * Returns:
+ * A modifier constant
+ */
+uint64_t igt_fb_tiling_to_mod(uint64_t tiling)
+{
+ switch (tiling) {
+ case I915_TILING_NONE:
+ return LOCAL_DRM_FORMAT_MOD_NONE;
+ case I915_TILING_X:
+ return LOCAL_I915_FORMAT_MOD_X_TILED;
+ case I915_TILING_Y:
+ return LOCAL_I915_FORMAT_MOD_Y_TILED;
+ case I915_TILING_Yf:
+ return LOCAL_I915_FORMAT_MOD_Yf_TILED;
+ default:
+ igt_assert(0);
+ }
+}
+
/* helpers to create nice-looking framebuffers */
static int create_bo_for_fb(int fd, int width, int height, uint32_t format,
uint64_t tiling, unsigned size, unsigned stride,
diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index 010ed3a..9b8ec8a 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -132,6 +132,7 @@ int igt_create_bo_with_dimensions(int fd, int width, int
height, uint32_t format
bool *is_dumb);
uint64_t igt_fb_mod_to_tiling(uint64_t modifier);
+uint64_t igt_fb_tiling_to_mod(uint64_t tiling);
/* cairo-based painting */
cairo_t *igt_get_cairo_ctx(int fd, struct igt_fb *fb);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Add support for loadable OA configs
== Series Details == Series: Add support for loadable OA configs URL : https://patchwork.freedesktop.org/series/27501/ State : success == Summary == Series 27501v1 Add support for loadable OA configs https://patchwork.freedesktop.org/api/1.0/series/27501/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-r) k.org#196399 Test kms_flip: Subgroup basic-flip-vs-modeset: skip -> PASS (fi-skl-x1585l) fdo#101781 k.org#196399 https://bugzilla.kernel.org/show_bug.cgi?id=196399 fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:426s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:424s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:355s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:479s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:483s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:496s fi-byt-n2820 total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:488s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:579s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:421s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:398s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:412s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:493s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:466s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:450s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:556s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:564s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:558s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:441s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:570s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:627s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:458s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:428s fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:482s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:544s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:411s 10de1e17faaab452782e5a1baffd1b30a639a261 drm-tip: 2017y-07m-18d-10h-08m-42s UTC integration manifest f6f2f20 drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface ff05eb6 drm/i915/perf: prune OA configs 7dbcc95 drm/i915/perf: fix flex eu registers programming == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5222/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 0/3] Add support for loadable OA configs
Hi, Here is a v6 of this series. There are a bunch of fixes pointed out by Matthew in patch 3. There was also a pretty big issue in v5 of patch 2, I dropped some calls to function programming OACTXCONTROL on shutting down the perf stream and that triggered failures in the oa-exponents IGT test. This is now fixed and the tests are back to stable. OACTXCONTROL is now, again, always reprogrammed on open/close of the stream. Many thanks to Matthew for his time. Cheers, Lionel Landwerlin (3): drm/i915/perf: fix flex eu registers programming drm/i915/perf: prune OA configs drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface drivers/gpu/drm/i915/i915_drv.c |2 + drivers/gpu/drm/i915/i915_drv.h | 92 +- drivers/gpu/drm/i915/i915_oa_bdw.c| 5360 + drivers/gpu/drm/i915/i915_oa_bdw.h|8 +- drivers/gpu/drm/i915/i915_oa_bxt.c| 2623 +--- drivers/gpu/drm/i915/i915_oa_bxt.h|8 +- drivers/gpu/drm/i915/i915_oa_chv.c| 2806 + drivers/gpu/drm/i915/i915_oa_chv.h|8 +- drivers/gpu/drm/i915/i915_oa_glk.c| 2535 +--- drivers/gpu/drm/i915/i915_oa_glk.h|8 +- drivers/gpu/drm/i915/i915_oa_hsw.c| 764 + drivers/gpu/drm/i915/i915_oa_hsw.h|8 +- drivers/gpu/drm/i915/i915_oa_kblgt2.c | 2971 +- drivers/gpu/drm/i915/i915_oa_kblgt2.h |8 +- drivers/gpu/drm/i915/i915_oa_kblgt3.c | 3020 +-- drivers/gpu/drm/i915/i915_oa_kblgt3.h |8 +- drivers/gpu/drm/i915/i915_oa_sklgt2.c | 3458 + drivers/gpu/drm/i915/i915_oa_sklgt2.h |8 +- drivers/gpu/drm/i915/i915_oa_sklgt3.c | 3019 +-- drivers/gpu/drm/i915/i915_oa_sklgt3.h |8 +- drivers/gpu/drm/i915/i915_oa_sklgt4.c | 3073 +-- drivers/gpu/drm/i915/i915_oa_sklgt4.h |8 +- drivers/gpu/drm/i915/i915_perf.c | 735 +++-- drivers/gpu/drm/i915/i915_reg.h |2 + include/uapi/drm/i915_drm.h | 24 + 25 files changed, 988 insertions(+), 29576 deletions(-) -- 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 3/3] drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface
The motivation behind this new interface is expose at runtime the
creation of new OA configs which can be used as part of the i915 perf
open interface. This will enable the kernel to learn new configs which
may be experimental, or otherwise not part of the core set currently
available through the i915 perf interface.
v2: Drop DRM_ERROR for userspace errors (Matthew)
Add padding to userspace structure (Matthew)
s/guid/uuid/ (Matthew)
v3: Use u32 instead of int to iterate through registers (Matthew)
v4: Lock access to dynamic config list (Lionel)
v5: by Matthew:
Fix uninitialized error values
Fix incorrect unwiding when opening perf stream
Use kmalloc_array() to store register
Use uuid_is_valid() to valid config uuids
Declare ioctls as write only
Check padding members are set to 0
by Lionel:
Return ENOENT rather than EINVAL when trying to remove non
existing config
Signed-off-by: Matthew Auld
Signed-off-by: Lionel Landwerlin
Signed-off-by: Andrzej Datczuk
---
drivers/gpu/drm/i915/i915_drv.c | 2 +
drivers/gpu/drm/i915/i915_drv.h | 48
drivers/gpu/drm/i915/i915_perf.c | 488 +++
drivers/gpu/drm/i915/i915_reg.h | 2 +
include/uapi/drm/i915_drm.h | 24 ++
5 files changed, 513 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d310d8245dca..a3d339670ec1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2730,6 +2730,8 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM,
i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM,
i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
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),
};
static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2b824f8875c4..607484737f3d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1917,6 +1917,9 @@ struct i915_oa_config {
struct attribute_group sysfs_metric;
struct attribute *attrs[2];
struct device_attribute sysfs_metric_id;
+
+ /* Only updated while holding dev_priv->perf.metrics_lock. */
+ bool in_use;
};
struct i915_perf_stream;
@@ -2043,6 +2046,25 @@ struct i915_perf_stream {
*/
struct i915_oa_ops {
/**
+* @is_valid_b_counter_reg: Validates register's address for
+* programming boolean counters for a particular platform.
+*/
+ bool (*is_valid_b_counter_reg)(struct drm_i915_private *dev_priv,
+ u32 addr);
+
+ /**
+* @is_valid_mux_reg: Validates register's address for programming mux
+* for a particular platform.
+*/
+ bool (*is_valid_mux_reg)(struct drm_i915_private *dev_priv, u32 addr);
+
+ /**
+* @is_valid_flex_reg: Validates register's address for programming
+* flex EU filtering for a particular platform.
+*/
+ bool (*is_valid_flex_reg)(struct drm_i915_private *dev_priv, u32 addr);
+
+ /**
* @init_oa_buffer: Resets the head and tail pointers of the
* circular buffer for periodic OA reports.
*
@@ -2430,10 +2452,32 @@ struct drm_i915_private {
struct kobject *metrics_kobj;
struct ctl_table_header *sysctl_header;
+ /*
+* Lock associated with adding/modifying/removing OA configs
+* in dev_priv->perf.metrics_idr.
+*/
+ struct mutex metrics_lock;
+
+ /*
+* List of dynamic configurations, you need to hold
+* dev_priv->perf.metrics_lock to access it.
+*/
+ struct idr metrics_idr;
+
+ /*
+* Lock associated with anything below within this structure
+* except exclusive_stream.
+*/
struct mutex lock;
struct list_head streams;
struct {
+ /*
+* The stream currently using the OA unit. If accessed
+* outside a syscall associated to its file
+* descriptor, you need to hold
+* dev_priv->drm.struct_mutex.
+*/
struct i915_perf_stream *exclusive_stream;
u32 specific_ctx_id;
@@ -3599,6 +3643,10 @@ i915_gem_context_lookup_timeline(struct i915_gem_context
*ctx,
int i915_perf_open
[Intel-gfx] [PATCH v6 1/3] drm/i915/perf: fix flex eu registers programming
We were reserving fewer dwords in the ring than necessary. Indeed
we're always writing all registers once, so discard the actual number
of registers given by the user and just program the whitelisted ones
once.
Fixes: 19f81df2859e ("drm/i915/perf: Add OA unit support for Gen 8+")
Reported-by: Matthew Auld
Signed-off-by: Lionel Landwerlin
Reviewed-by: Matthew Auld
Cc: # v4.12+
---
drivers/gpu/drm/i915/i915_perf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 96682fd86f82..df78bfa9e574 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1601,11 +1601,11 @@ static int gen8_emit_oa_config(struct
drm_i915_gem_request *req)
u32 *cs;
int i;
- cs = intel_ring_begin(req, n_flex_regs * 2 + 4);
+ cs = intel_ring_begin(req, ARRAY_SIZE(flex_mmio) * 2 + 4);
if (IS_ERR(cs))
return PTR_ERR(cs);
- *cs++ = MI_LOAD_REGISTER_IMM(n_flex_regs + 1);
+ *cs++ = MI_LOAD_REGISTER_IMM(ARRAY_SIZE(flex_mmio) + 1);
*cs++ = i915_mmio_reg_offset(GEN8_OACTXCONTROL);
*cs++ = (dev_priv->perf.oa.period_exponent <<
GEN8_OA_TIMER_PERIOD_SHIFT) |
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] CONTRIBUTING: formalize review rules
Acked-by: Lyude On Tue, 2017-07-18 at 18:00 +0200, Daniel Vetter wrote: > There's a bunch of reasons why I think we should formalize and > enforce > our review rules for igt patches: > > - We have a lot of new engineers joining and review helps enormously > with mentoring and learning. But right now only patches from > contributors without commit rights are consistently subjected to > review, which makes this imbalanced and removes senior contributors > from the review pool. > > - We have a much bigger team and we need to make sure we're aligned > on > where igt as a tool and testsuite needs to head towards. Getting > that alignment happens through reviewing each other's submission. > Pushing a contentious patch and then dealing with a heated irc > discussion is much less effective. > > - Finally igt becomes ever more important for our testing, making > sure > the code quality is high is important. Review helps with that. > > v2: Improve wording a bit (Imre). > > Acked-by: Daniel Stone > Acked-by: Jani Nikula > Acked-by: Joonas Lahtinen > Acked-by: Maarten Lankhorst > Acked-by: Petri Latvala > Acked-by: Imre Deak > Acked-by: Robert Foss > Acked-by: Ben Widawsky > Acked-by: Tvrtko Ursulin > Acked-by: Mika Kuoppala > Signed-off-by: Daniel Vetter > --- > CONTRIBUTING | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/CONTRIBUTING b/CONTRIBUTING > index d2adcf03b7c3..561c5dd80bba 100644 > --- a/CONTRIBUTING > +++ b/CONTRIBUTING > @@ -26,10 +26,11 @@ A short list of contribution guidelines: >convenience macros provided by the igt library. The semantic patch > lib/igt.cocci >can help with the more automatic conversions. > > -- There is no formal review requirement and regular contributors > with commit > - access can push patches right after submitting them to the mailing > lists. But > - invasive changes, new helper libraries and contributions from > newcomers should > - go through a proper review to ensure overall consistency in the > codebase. > +- Patches need to be reviewed on the mailing list. Exceptions only > apply for > + testcases and tooling for drivers with just a single contributor > (e.g. vc4). > + In this case patches must still be submitted to the mailing list > first. > + Testcase should preferrably be cross-reviewed by the same people > who write and > + review the kernel feature itself. > > - When patches from new contributors (without commit access) are > stuck, for >anything related to the regular releases, issues with packaging > and ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] CONTRIBUTING: formalize review rules
There's a bunch of reasons why I think we should formalize and enforce our review rules for igt patches: - We have a lot of new engineers joining and review helps enormously with mentoring and learning. But right now only patches from contributors without commit rights are consistently subjected to review, which makes this imbalanced and removes senior contributors from the review pool. - We have a much bigger team and we need to make sure we're aligned on where igt as a tool and testsuite needs to head towards. Getting that alignment happens through reviewing each other's submission. Pushing a contentious patch and then dealing with a heated irc discussion is much less effective. - Finally igt becomes ever more important for our testing, making sure the code quality is high is important. Review helps with that. v2: Improve wording a bit (Imre). Acked-by: Daniel Stone Acked-by: Jani Nikula Acked-by: Joonas Lahtinen Acked-by: Maarten Lankhorst Acked-by: Petri Latvala Acked-by: Imre Deak Acked-by: Robert Foss Acked-by: Ben Widawsky Acked-by: Tvrtko Ursulin Acked-by: Mika Kuoppala Signed-off-by: Daniel Vetter --- CONTRIBUTING | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/CONTRIBUTING b/CONTRIBUTING index d2adcf03b7c3..561c5dd80bba 100644 --- a/CONTRIBUTING +++ b/CONTRIBUTING @@ -26,10 +26,11 @@ A short list of contribution guidelines: convenience macros provided by the igt library. The semantic patch lib/igt.cocci can help with the more automatic conversions. -- There is no formal review requirement and regular contributors with commit - access can push patches right after submitting them to the mailing lists. But - invasive changes, new helper libraries and contributions from newcomers should - go through a proper review to ensure overall consistency in the codebase. +- Patches need to be reviewed on the mailing list. Exceptions only apply for + testcases and tooling for drivers with just a single contributor (e.g. vc4). + In this case patches must still be submitted to the mailing list first. + Testcase should preferrably be cross-reviewed by the same people who write and + review the kernel feature itself. - When patches from new contributors (without commit access) are stuck, for anything related to the regular releases, issues with packaging and -- 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 0/5] x86/io: Rely on asm-generic/io.h
On Fri, 2017-06-30 at 20:09 +0300, Andy Shevchenko wrote: > The series brings a bit of order to arch/x86/include/asm/io.h by re- > using > definitions in the generic header. > > The series has been tested on Intel Broxton hardware in 32- and 64-bit > modes. Any comments? Shall I resend this? > > Since v2: > - add cleanup patches in accordance to re-use what's defined in > generic header > - split to few patches > - hopefully nail down an issue kbuild bot complained about > - append tags (Wolfram) > > Andy Shevchenko (5): > x86/io: Define IO accessors by preprocessor > x86/io: Include asm-generic/io.h to architectural code > x86/io: Remove mem*io() duplications > x86/io: Remove xlate_dev_kmem_ptr() duplication > x86/io: Make readq() / writeq() API consistent > > arch/x86/include/asm/io.h | 98 +++--- > - > include/asm-generic/io.h | 27 + > 2 files changed, 74 insertions(+), 51 deletions(-) > -- Andy Shevchenko Intel Finland Oy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 12/14] drm/i915: Interface for controling engine stats collection
Quoting Tvrtko Ursulin (2017-07-18 15:36:16)
> +int intel_enable_engine_stats(struct drm_i915_private *dev_priv)
> +{
> + if (!i915.enable_execlists)
> + return -ENODEV;
> +
> + mutex_lock(&i915_engine_stats_mutex);
> + if (i915_engine_stats_ref++ == 0) {
> + struct intel_engine_cs *engine;
> + enum intel_engine_id id;
> +
> + for_each_engine(engine, dev_priv, id) {
> + memset(&engine->stats, 0, sizeof(engine->stats));
> + spin_lock_init(&engine->stats.lock);
> + }
> +
> + static_branch_enable(&i915_engine_stats_key);
> + }
> + mutex_unlock(&i915_engine_stats_mutex);
I don't think static_branch_enable() is a might_sleep, so it looks like
you can rewrite this avoiding the mutex and thus not requiring the
worker and then can use the error code here to decide if you need to
use the timer instead.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 12/14] drm/i915: Interface for controling engine stats collection
Quoting Tvrtko Ursulin (2017-07-18 15:36:16)
> +u64 intel_engine_get_current_busy_ns(struct intel_engine_cs *engine)
> +{
> + unsigned long flags;
> + u64 total;
> +
> + spin_lock_irqsave(&engine->stats.lock, flags);
> +
> + total = engine->stats.total;
> +
> + /*
> +* If the engine is executing something at the moment
> +* add it to the total.
> +*/
> + if (engine->stats.ref)
> + total += ktime_get_real_ns() - engine->stats.start;
> +
> + spin_unlock_irqrestore(&engine->stats.lock, flags);
Answers to another patch found here. I would say this is the other half
of the interface and should be kept together.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 11/14] drm/i915: Engine busy time tracking
Quoting Tvrtko Ursulin (2017-07-18 15:36:15)
> From: Tvrtko Ursulin
>
> Track total time requests have been executing on the hardware.
>
> To make this cheap it is hidden behind a static branch with the
> intention that it is only enabled when there is a consumer
> listening. This means that in the default off case the total
> cost of the tracking is just a few no-op instructions on the
> fast paths.
> +static inline void intel_engine_context_in(struct intel_engine_cs *engine)
> +{
> + if (static_branch_unlikely(&i915_engine_stats_key)) {
> + unsigned long flags;
> +
> + spin_lock_irqsave(&engine->stats.lock, flags);
What's the purpose of this lock? RMW is ordered by virtue of the tasklet
(only one cpu can be doing the rmw at any time). Did I miss another
user?
> + if (engine->stats.ref++ == 0)
> + engine->stats.start = ktime_get_real_ns();
Use ktime_get_raw() and leave the conversion to ns to the caller.
What is the cost of a ktime nowadays?
How do you handle the currently active case when reporting? Imagine a
continuous stream of requests, hoping between contexts without a
break.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/2] tests/chamelium: Catch and flush hotplug uevents after each plug
This adds calls to igt_hotplug_detected and igt_flush_hotplugs to catch and flush hotplugs from connector unplug (due to chamelium reset) and plug. These need to be intercepted so that they are not delayed and issued after resume, providing a false positive for the test result. In addition, the final hotplug uevent flush is brought closer to the suspend call, to decrease the likeliness of false positive. However, false positives still do happen, because it is not possible to make sure that the uevent caused by each connector's state change was caught instead of being delayed and issued at resume time. Signed-off-by: Paul Kocialkowski --- tests/chamelium.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/tests/chamelium.c b/tests/chamelium.c index 8af33aaa..0528ffb3 100644 --- a/tests/chamelium.c +++ b/tests/chamelium.c @@ -340,12 +340,16 @@ test_suspend_resume_edid_change(data_t *data, struct chamelium_port *port, reset_state(data, port); + /* Catch the event and flush all remaining ones. */ + igt_assert(igt_hotplug_detected(mon, HOTPLUG_TIMEOUT)); + igt_flush_hotplugs(mon); + /* First plug in the port */ chamelium_port_set_edid(data->chamelium, port, edid_id); chamelium_plug(data->chamelium, port); - wait_for_connector(data, port, DRM_MODE_CONNECTED); + igt_assert(igt_hotplug_detected(mon, HOTPLUG_TIMEOUT)); - igt_flush_hotplugs(mon); + wait_for_connector(data, port, DRM_MODE_CONNECTED); /* * Change the edid before we suspend. On resume, the machine should @@ -355,6 +359,8 @@ test_suspend_resume_edid_change(data_t *data, struct chamelium_port *port, get_connectors_link_status_failed(data, link_status_failed[0]); + igt_flush_hotplugs(mon); + igt_system_suspend_autoresume(state, test); igt_assert(igt_hotplug_detected(mon, HOTPLUG_TIMEOUT)); -- 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/2] tests/chamelium: Skip suspend/resume test with unreliable hotplug event
It may occur that a hotplug uevent is detected at resume, even though it
does not indicate that an actual hotplug happened. This is the case when
link training fails on any other connector.
There is currently no way to distinguish what connector caused a hotplug
uevent, nor what the reason for that uevent really is. This makes it
impossible to find out whether the test actually passed or not.
To circumvent this problem, the link status of each connector is
collected before and after suspend and compared to skip the test if
the state was good before and turned to bad after resume.
This only concerns the EDID change test, where we cannot check the
connector state (that is not supposed to have changed). For actual
hotplug tests, the tests should be safe since they check each
connector's state after receiving the uevent.
The situation described here happens with DP-VGA bridges that fail link
training after resume, as they need some more time to response on their
AUX channel.
Signed-off-by: Paul Kocialkowski
---
tests/chamelium.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/tests/chamelium.c b/tests/chamelium.c
index e26f0557..8af33aaa 100644
--- a/tests/chamelium.c
+++ b/tests/chamelium.c
@@ -87,6 +87,31 @@ get_precalculated_crc(struct chamelium_port *port, int w,
int h)
}
static void
+get_connectors_link_status_failed(data_t *data, bool *link_status_failed)
+{
+ drmModeConnector *connector;
+ uint64_t link_status;
+ drmModePropertyPtr prop;
+ int p;
+
+ for (p = 0; p < data->port_count; p++) {
+ connector = chamelium_port_get_connector(data->chamelium,
+data->ports[p], false);
+
+ igt_assert(kmstest_get_property(data->drm_fd,
+ connector->connector_id,
+ DRM_MODE_OBJECT_CONNECTOR,
+ "link-status", NULL,
+ &link_status, &prop));
+
+ link_status_failed[p] = link_status == DRM_MODE_LINK_STATUS_BAD;
+
+ drmModeFreeProperty(prop);
+ drmModeFreeConnector(connector);
+ }
+}
+
+static void
require_connector_present(data_t *data, unsigned int type)
{
int i;
@@ -310,6 +335,8 @@ test_suspend_resume_edid_change(data_t *data, struct
chamelium_port *port,
int alt_edid_id)
{
struct udev_monitor *mon = igt_watch_hotplug();
+ bool link_status_failed[2][data->port_count];
+ int p;
reset_state(data, port);
@@ -326,8 +353,16 @@ test_suspend_resume_edid_change(data_t *data, struct
chamelium_port *port,
*/
chamelium_port_set_edid(data->chamelium, port, alt_edid_id);
+ get_connectors_link_status_failed(data, link_status_failed[0]);
+
igt_system_suspend_autoresume(state, test);
+
igt_assert(igt_hotplug_detected(mon, HOTPLUG_TIMEOUT));
+
+ get_connectors_link_status_failed(data, link_status_failed[1]);
+
+ for (p = 0; p < data->port_count; p++)
+ igt_skip_on(!link_status_failed[0][p] &&
link_status_failed[1][p]);
}
static igt_output_t *
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/2] tests/chamelium: Skip suspend/resume test with unreliable hotplug event
It may occur that a hotplug uevent is detected at resume, even though it
does not indicate that an actual hotplug happened. This is the case when
link training fails on any other connector.
There is currently no way to distinguish what connector caused a hotplug
uevent, nor what the reason for that uevent really is. This makes it
impossible to find out whether the test actually passed or not.
To circumvent this problem, the link status of each connector is
collected before and after suspend and compared to skip the test if
the state was good before and turned to bad after resume.
This only concerns the EDID change test, where we cannot check the
connector state (that is not supposed to have changed). For actual
hotplug tests, the tests should be safe since they check each
connector's state after receiving the uevent.
The situation described here happens with DP-VGA bridges that fail link
training after resume, as they need some more time to response on their
AUX channel.
Signed-off-by: Paul Kocialkowski
---
tests/chamelium.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/tests/chamelium.c b/tests/chamelium.c
index e26f0557..8af33aaa 100644
--- a/tests/chamelium.c
+++ b/tests/chamelium.c
@@ -87,6 +87,31 @@ get_precalculated_crc(struct chamelium_port *port, int w,
int h)
}
static void
+get_connectors_link_status_failed(data_t *data, bool *link_status_failed)
+{
+ drmModeConnector *connector;
+ uint64_t link_status;
+ drmModePropertyPtr prop;
+ int p;
+
+ for (p = 0; p < data->port_count; p++) {
+ connector = chamelium_port_get_connector(data->chamelium,
+data->ports[p], false);
+
+ igt_assert(kmstest_get_property(data->drm_fd,
+ connector->connector_id,
+ DRM_MODE_OBJECT_CONNECTOR,
+ "link-status", NULL,
+ &link_status, &prop));
+
+ link_status_failed[p] = link_status == DRM_MODE_LINK_STATUS_BAD;
+
+ drmModeFreeProperty(prop);
+ drmModeFreeConnector(connector);
+ }
+}
+
+static void
require_connector_present(data_t *data, unsigned int type)
{
int i;
@@ -310,6 +335,8 @@ test_suspend_resume_edid_change(data_t *data, struct
chamelium_port *port,
int alt_edid_id)
{
struct udev_monitor *mon = igt_watch_hotplug();
+ bool link_status_failed[2][data->port_count];
+ int p;
reset_state(data, port);
@@ -326,8 +353,16 @@ test_suspend_resume_edid_change(data_t *data, struct
chamelium_port *port,
*/
chamelium_port_set_edid(data->chamelium, port, alt_edid_id);
+ get_connectors_link_status_failed(data, link_status_failed[0]);
+
igt_system_suspend_autoresume(state, test);
+
igt_assert(igt_hotplug_detected(mon, HOTPLUG_TIMEOUT));
+
+ get_connectors_link_status_failed(data, link_status_failed[1]);
+
+ for (p = 0; p < data->port_count; p++)
+ igt_skip_on(!link_status_failed[0][p] &&
link_status_failed[1][p]);
}
static igt_output_t *
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 0/2] Unrelated hotplug uevent masking out actual test result
This patch introduces a workaround for a case where a uevent is issued by the kernel because of DP link training failing on a connector unrelated to the current test. Since the test depends on receiving a hotplug uevent, it previously passed even though it should not have. False positives also occur due to the plug/unplug events being delayed and issued at resume time. This is mitigated by catching and flushing hotplugs everytime a change is made on connectors, but it is not enough to ensure that all hotplug events were caught and not delayed. The problem here is that it is not possible to find out the exact reason why a uevent is issued by the kernel. A possible way to fix this would be to introduce more fields (the connector name and some reason why the event is triggered would probably be sufficient). ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Allow null render state batchbuffers bigger than one page
On 07/14/2017 08:08 AM, Chris Wilson wrote: Quoting Oscar Mateo (2017-07-14 15:52:59) On 07/13/2017 03:28 PM, Rodrigo Vivi wrote: On Wed, May 3, 2017 at 9:31 AM, Chris Wilson wrote: On Wed, May 03, 2017 at 09:12:18AM +, Oscar Mateo wrote: On 05/03/2017 08:52 AM, Mika Kuoppala wrote: Oscar Mateo [1] writes: On 05/02/2017 09:17 AM, Mika Kuoppala wrote: Chris Wilson [2] writes: On Fri, Apr 28, 2017 at 09:11:06AM +, Oscar Mateo wrote: The new batchbuffer for CNL surpasses the 4096 byte mark. Cc: Mika Kuoppala [3] Cc: Ben Widawsky [4] Signed-off-by: Oscar Mateo [5] Evil, 4k+ of nothing-ness that userspace then has to configure for itself for correctness anyway. Patch looks ok, but still question the sanity. Is there a requirement for CNL to init the renderstate? I would like to drop the render state init from CNL if we can't find evidence that it needs it. Bspec indicates that it doesnt. I'd like to drop as well, and I was hearing people around telling we didn't need anymore, however without this during power on I had bad failures... The best I could get from architecture (+Raf) is that setting valid and coherent values for the whole render state is required as soon as the context is created, no matter who does it. If you see failures when the KMD does not do it, that means the UMD must be missing something, right? That is my initial response as well. The kernel does load one context, just so that the hardware always has space to write to on power saving. The only batch executed for it is the golden render state. Easy enough to only initialise that kernel context to isolate whether it is self-inflicted or that userspace overlooked something in its state management. (I have the view that even if userspace doesn't think it needs to use a particular bit of state today, tomorrow it will so will need it anyway!) -Chris Rodrigo, you have access to a CNL: can you make this test? The idea is to find out if the root cause for the failures you were seeing is the kernel default context or in the UMD-created contexts. Thanks, Oscar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for i915 PMU and engine busy stats
== Series Details == Series: i915 PMU and engine busy stats URL : https://patchwork.freedesktop.org/series/27488/ State : success == Summary == Series 27488v1 i915 PMU and engine busy stats https://patchwork.freedesktop.org/api/1.0/series/27488/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-n2820) fdo#101705 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:443s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:431s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:357s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:525s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:516s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:494s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:481s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:595s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:432s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:411s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:411s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:500s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:473s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:463s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:570s fi-kbl-r total:279 pass:260 dwarn:1 dfail:0 fail:0 skip:18 time:578s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:562s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:456s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:585s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:472s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:473s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:439s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:475s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:537s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:405s 10de1e17faaab452782e5a1baffd1b30a639a261 drm-tip: 2017y-07m-18d-10h-08m-42s UTC integration manifest 6601a6c drm/i915/pmu: Wire up engine busy stats to PMU 7d7d26e drm/i915: Export engine busy stats in debugfs f4fddc8 drm/i915: Interface for controling engine stats collection 559f3b2 drm/i915: Engine busy time tracking d02886e drm/i915: Wrap context schedule notification cdcdd9f drm/i915/pmu: Suspend sampling when GPU is idle c436b20 drm/i915/pmu: Expose events in sysfs c0efa43 drm/i915/pmu: Add fake regs da03ba4 drm/i915/pmu: Only sample enabled samplers afea896 drm/i915/pmu: Helper to extract engine and sampler from PMU config 2ff9a43 drm/i915/pmu: Decouple uAPI engine ids 8a3ac8e drm/i915/pmu: Add queued samplers to the PMU uAPI 278c42b drm/i915/pmu: Add VCS2 engine to the PMU uAPI dc1f338 RFC drm/i915: Expose a PMU interface for perf queries == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5221/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915/execlists: Read the context-status buffer from the HWSP
Quoting Mika Kuoppala (2017-07-18 15:36:46)
> Chris Wilson writes:
>
> > The engine provides a mirror of the CSB in the HWSP. If we use the
> > cacheable reads from the HWSP, we can shave off a few mmio reads per
> > context-switch interrupt (which are quite frequent!). Just removing a
> > couple of mmio is not enough to actually reduce any latency, but a small
> > reduction in overall cpu usage.
> >
> > Much appreciation for Ben dropping the bombshell that the CSB was in the
> > HWSP and for Michel in digging out the details.
> >
> > v2: Don't be lazy, add the defines for the indices.
> > v3: Include the HWSP in debugfs/i915_engine_info
> > v4: Check for GVT-g, it currently depends on intercepting CSB mmio
> > v5: Fixup GVT-g mmio path
> >
> > Suggested-by: Ben Widawsky
> > Signed-off-by: Chris Wilson
> > Cc: Michel Thierry
> > Cc: Tvrtko Ursulin
> > Cc: Mika Kuoppala
> > Cc: Daniele Ceraolo Spurio
> > Cc: Zhenyu Wang
> > Cc: Zhi Wang
> > Acked-by: Michel Thierry
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 7 +--
> > drivers/gpu/drm/i915/intel_lrc.c| 16 +++-
> > drivers/gpu/drm/i915/intel_ringbuffer.h | 2 ++
> > 3 files changed, 18 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 620c9218d1c1..5fd01c14a3ec 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -3384,6 +3384,7 @@ static int i915_engine_info(struct seq_file *m, void
> > *unused)
> > upper_32_bits(addr), lower_32_bits(addr));
> >
> > if (i915.enable_execlists) {
> > + const u32 *hws =
> > &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
> > u32 ptr, read, write;
> > unsigned int idx;
> >
> > @@ -3404,10 +3405,12 @@ static int i915_engine_info(struct seq_file *m,
> > void *unused)
> > write += GEN8_CSB_ENTRIES;
> > while (read < write) {
> > idx = ++read % GEN8_CSB_ENTRIES;
> > - seq_printf(m, "Execlist CSB[%d]: 0x%08x,
> > context: %d\n",
> > + seq_printf(m, "Execlist CSB[%d]: 0x%08x
> > [0x%08x in hwsp], context: %d [%d in hwsp]\n",
> > idx,
> >
> > I915_READ(RING_CONTEXT_STATUS_BUF_LO(engine, idx)),
> > -
> > I915_READ(RING_CONTEXT_STATUS_BUF_HI(engine, idx)));
> > +hws[idx * 2],
> > +
> > I915_READ(RING_CONTEXT_STATUS_BUF_HI(engine, idx)),
> > +hws[idx * 2 + 1]);
> > }
> >
> > rcu_read_lock();
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 3469badedbe0..41dc04eb6097 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -547,10 +547,17 @@ static void intel_lrc_irq_handler(unsigned long data)
> > while (test_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted)) {
> > u32 __iomem *csb_mmio =
> > dev_priv->regs +
> > i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine));
> > - u32 __iomem *buf =
> > - dev_priv->regs +
> > i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0));
> > + /* The HWSP contains a (cacheable) mirror of the CSB */
> > + const u32 *buf =
> > +
> > &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
>
> Could be also const u32 * const buf = ...
> as in debugfs counterpart. Value added is quite thin tho vs clutter so
> not insisting.
> > unsigned int head, tail;
> >
> > + /* However GVT emulation depends upon intercepting CSB mmio */
> > + if (unlikely(intel_vgpu_active(dev_priv))) {
> > + buf = (u32 * __force)
> > + (dev_priv->regs +
> > i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
> > + }
Hence why we can't use const u32 *const buf ;-)
> > +
> > /* The write will be ordered by the uncached read (itself
> >* a memory barrier), so we do not need another in the form
> >* of a locked instruction. The race between the interrupt
> > @@ -590,13 +597,12 @@ static void intel_lrc_irq_handler(unsigned long data)
> >* status notifier.
> >*/
> >
> > - status = readl(buf + 2 * head);
> > + status = buf[2 * head];
> > if (!(status & GEN8_CTX_STATUS_COMPLETED_MASK))
> > continue;
Re: [Intel-gfx] [PATCH v4 3/3] drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface
On 18/07/17 11:09, Matthew Auld wrote:
On 07/17, Lionel Landwerlin wrote:
The motivation behind this new interface is expose at runtime the
creation of new OA configs which can be used as part of the i915 perf
open interface. This will enable the kernel to learn new configs which
may be experimental, or otherwise not part of the core set currently
available through the i915 perf interface.
This will relieve the kernel from holding all the possible configs, so
we can leave only the test configs here.
v2: Drop DRM_ERROR for userspace errors (Matthew)
Add padding to userspace structure (Matthew)
s/guid/uuid/ (Matthew)
v3: Use u32 instead of int to iterate through registers (Matthew)
v4: Lock access to dynamic config list (Lionel)
Signed-off-by: Matthew Auld
Signed-off-by: Lionel Landwerlin
Signed-off-by: Andrzej Datczuk
---
drivers/gpu/drm/i915/i915_drv.c | 2 +
drivers/gpu/drm/i915/i915_drv.h | 48 +
drivers/gpu/drm/i915/i915_perf.c | 413 +--
drivers/gpu/drm/i915/i915_reg.h | 2 +
include/uapi/drm/i915_drm.h | 24 +++
5 files changed, 475 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d310d8245dca..a3d339670ec1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2730,6 +2730,8 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM,
i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM,
i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
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),
};
static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2b824f8875c4..607484737f3d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1917,6 +1917,9 @@ struct i915_oa_config {
struct attribute_group sysfs_metric;
struct attribute *attrs[2];
struct device_attribute sysfs_metric_id;
+
+ /* Only updated while holding dev_priv->perf.metrics_lock. */
+ bool in_use;
};
struct i915_perf_stream;
@@ -2043,6 +2046,25 @@ struct i915_perf_stream {
*/
struct i915_oa_ops {
/**
+* @is_valid_b_counter_reg: Validates register's address for
+* programming boolean counters for a particular platform.
+*/
+ bool (*is_valid_b_counter_reg)(struct drm_i915_private *dev_priv,
+ u32 addr);
+
+ /**
+* @is_valid_mux_reg: Validates register's address for programming mux
+* for a particular platform.
+*/
+ bool (*is_valid_mux_reg)(struct drm_i915_private *dev_priv, u32 addr);
+
+ /**
+* @is_valid_flex_reg: Validates register's address for programming
+* flex EU filtering for a particular platform.
+*/
+ bool (*is_valid_flex_reg)(struct drm_i915_private *dev_priv, u32 addr);
+
+ /**
* @init_oa_buffer: Resets the head and tail pointers of the
* circular buffer for periodic OA reports.
*
@@ -2430,10 +2452,32 @@ struct drm_i915_private {
struct kobject *metrics_kobj;
struct ctl_table_header *sysctl_header;
+ /*
+* Lock associated with adding/modifying/removing OA configs
+* in dev_priv->perf.metrics_idr.
+*/
+ struct mutex metrics_lock;
+
+ /*
+* List of dynamic configurations, you need to hold
+* dev_priv->perf.metrics_lock to access it.
+*/
+ struct idr metrics_idr;
+
+ /*
+* Lock associated with anything below within this structure
+* except exclusive_stream.
+*/
struct mutex lock;
struct list_head streams;
struct {
+ /*
+* The stream currently using the OA unit. If accessed
+* outside a syscall associated to its file
+* descriptor, you need to hold
+* dev_priv->drm.struct_mutex.
+*/
struct i915_perf_stream *exclusive_stream;
u32 specific_ctx_id;
@@ -3599,6 +3643,10 @@ i915_gem_context_lookup_timeline(struct i915_gem_context
*ctx,
int i915_perf_open_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
+int i915_perf_add_config_ioctl(struct drm_device *dev, void *data,
+
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Explicit the connector name for DP link training result (rev2)
== Series Details == Series: drm/i915: Explicit the connector name for DP link training result (rev2) URL : https://patchwork.freedesktop.org/series/27410/ State : success == Summary == Series 27410v2 drm/i915: Explicit the connector name for DP link training result https://patchwork.freedesktop.org/api/1.0/series/27410/revisions/2/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-kbl-7560u) k.org#196399 +1 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> DMESG-WARN (fi-pnv-d510) fdo#101597 k.org#196399 https://bugzilla.kernel.org/show_bug.cgi?id=196399 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:444s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:434s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:353s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:536s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:514s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:495s fi-byt-n2820 total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:491s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:593s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:437s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:410s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:415s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:490s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:494s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:469s fi-kbl-7560u total:279 pass:268 dwarn:1 dfail:0 fail:0 skip:10 time:572s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:592s fi-pnv-d510 total:279 pass:222 dwarn:2 dfail:0 fail:0 skip:55 time:559s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:458s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:582s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:469s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:482s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:441s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:466s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:547s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:405s 10de1e17faaab452782e5a1baffd1b30a639a261 drm-tip: 2017y-07m-18d-10h-08m-42s UTC integration manifest 53ca378 drm/i915: Explicit the connector name for DP link training result == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5220/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915/execlists: Read the context-status buffer from the HWSP
Chris Wilson writes:
> The engine provides a mirror of the CSB in the HWSP. If we use the
> cacheable reads from the HWSP, we can shave off a few mmio reads per
> context-switch interrupt (which are quite frequent!). Just removing a
> couple of mmio is not enough to actually reduce any latency, but a small
> reduction in overall cpu usage.
>
> Much appreciation for Ben dropping the bombshell that the CSB was in the
> HWSP and for Michel in digging out the details.
>
> v2: Don't be lazy, add the defines for the indices.
> v3: Include the HWSP in debugfs/i915_engine_info
> v4: Check for GVT-g, it currently depends on intercepting CSB mmio
> v5: Fixup GVT-g mmio path
>
> Suggested-by: Ben Widawsky
> Signed-off-by: Chris Wilson
> Cc: Michel Thierry
> Cc: Tvrtko Ursulin
> Cc: Mika Kuoppala
> Cc: Daniele Ceraolo Spurio
> Cc: Zhenyu Wang
> Cc: Zhi Wang
> Acked-by: Michel Thierry
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 7 +--
> drivers/gpu/drm/i915/intel_lrc.c| 16 +++-
> drivers/gpu/drm/i915/intel_ringbuffer.h | 2 ++
> 3 files changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 620c9218d1c1..5fd01c14a3ec 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3384,6 +3384,7 @@ static int i915_engine_info(struct seq_file *m, void
> *unused)
> upper_32_bits(addr), lower_32_bits(addr));
>
> if (i915.enable_execlists) {
> + const u32 *hws =
> &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
> u32 ptr, read, write;
> unsigned int idx;
>
> @@ -3404,10 +3405,12 @@ static int i915_engine_info(struct seq_file *m, void
> *unused)
> write += GEN8_CSB_ENTRIES;
> while (read < write) {
> idx = ++read % GEN8_CSB_ENTRIES;
> - seq_printf(m, "\tExeclist CSB[%d]: 0x%08x,
> context: %d\n",
> + seq_printf(m, "\tExeclist CSB[%d]: 0x%08x
> [0x%08x in hwsp], context: %d [%d in hwsp]\n",
> idx,
>
> I915_READ(RING_CONTEXT_STATUS_BUF_LO(engine, idx)),
> -
> I915_READ(RING_CONTEXT_STATUS_BUF_HI(engine, idx)));
> +hws[idx * 2],
> +
> I915_READ(RING_CONTEXT_STATUS_BUF_HI(engine, idx)),
> +hws[idx * 2 + 1]);
> }
>
> rcu_read_lock();
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 3469badedbe0..41dc04eb6097 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -547,10 +547,17 @@ static void intel_lrc_irq_handler(unsigned long data)
> while (test_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted)) {
> u32 __iomem *csb_mmio =
> dev_priv->regs +
> i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine));
> - u32 __iomem *buf =
> - dev_priv->regs +
> i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0));
> + /* The HWSP contains a (cacheable) mirror of the CSB */
> + const u32 *buf =
> + &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
Could be also const u32 * const buf = ...
as in debugfs counterpart. Value added is quite thin tho vs clutter so
not insisting.
> unsigned int head, tail;
>
> + /* However GVT emulation depends upon intercepting CSB mmio */
> + if (unlikely(intel_vgpu_active(dev_priv))) {
> + buf = (u32 * __force)
> + (dev_priv->regs +
> i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
> + }
> +
> /* The write will be ordered by the uncached read (itself
>* a memory barrier), so we do not need another in the form
>* of a locked instruction. The race between the interrupt
> @@ -590,13 +597,12 @@ static void intel_lrc_irq_handler(unsigned long data)
>* status notifier.
>*/
>
> - status = readl(buf + 2 * head);
> + status = buf[2 * head];
> if (!(status & GEN8_CTX_STATUS_COMPLETED_MASK))
> continue;
>
> /* Check the context/desc id for this event matches */
> - GEM_DEBUG_BUG_ON(readl(buf + 2 * head + 1) !=
> - port->context_id);
> + GEM_DEBUG_BUG_ON(buf[2 * head + 1] != port->context_id);
In here I wonder if GE
[Intel-gfx] [RFC 14/14] drm/i915/pmu: Wire up engine busy stats to PMU
From: Tvrtko Ursulin
We can use engine busy stats instead of the MMIO sampling timer
for better efficiency.
As minimum this saves period * num_engines / sec mmio reads,
and in a better case, when only engine busy samplers are active,
it enables us to not kick off the sampling timer at all.
It is also more accurate since it doesn't rely on sampling.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++
drivers/gpu/drm/i915/i915_pmu.c | 64 +
2 files changed, 61 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f1fded6dd9cf..2986a01660d8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2603,8 +2603,11 @@ struct drm_i915_private {
spinlock_t lock;
struct hrtimer timer;
bool timer_enabled;
+ bool busy_stats;
u64 enable;
u64 sample[__I915_NUM_PMU_SAMPLERS];
+ struct work_struct enable_busy_stats;
+ struct delayed_work disable_busy_stats;
} pmu;
/*
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 4b113cad40d1..996612843594 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -29,12 +29,23 @@ static const unsigned int user_engine_map[I915_NUM_ENGINES]
= {
[I915_SAMPLE_VECS] = VECS,
};
+#define ENGINE_BUSY_BITS \
+ (BIT_ULL(I915_PMU_COUNT_RCS_BUSY) | \
+BIT_ULL(I915_PMU_COUNT_BCS_BUSY) | \
+BIT_ULL(I915_PMU_COUNT_VCS_BUSY) | \
+BIT_ULL(I915_PMU_COUNT_VCS2_BUSY) | \
+BIT_ULL(I915_PMU_COUNT_VECS_BUSY))
+
static bool pmu_needs_timer(struct drm_i915_private *i915, bool gpu_active)
{
- if (gpu_active)
- return i915->pmu.enable;
- else
- return i915->pmu.enable >> 32;
+ u64 mask = i915->pmu.enable;
+
+ if (!gpu_active)
+ mask >>= 32;
+ else if (i915->pmu.busy_stats)
+ mask &= ~ENGINE_BUSY_BITS;
+
+ return mask;
}
void i915_pmu_gt_idle(struct drm_i915_private *i915)
@@ -110,7 +121,8 @@ static void engines_sample(struct drm_i915_private
*dev_priv)
if (sample_mask & BIT(I915_SAMPLE_QUEUED))
engine->pmu_sample[I915_SAMPLE_QUEUED] += PERIOD;
- if (sample_mask & BIT(I915_SAMPLE_BUSY)) {
+ if ((sample_mask & BIT(I915_SAMPLE_BUSY)) &&
+ !dev_priv->pmu.busy_stats) {
fw = grab_forcewake(dev_priv, fw);
val = I915_READ_FW(RING_MI_MODE(engine->mmio_base));
if (!(val & MODE_IDLE))
@@ -337,6 +349,11 @@ static void i915_pmu_timer_cancel(struct perf_event *event)
hrtimer_cancel(&hwc->hrtimer);
}
+static bool supports_busy_stats(void)
+{
+ return i915.enable_execlists;
+}
+
static void i915_pmu_enable(struct perf_event *event)
{
struct drm_i915_private *i915 =
@@ -345,6 +362,13 @@ static void i915_pmu_enable(struct perf_event *event)
spin_lock_irqsave(&i915->pmu.lock, flags);
+ if (pmu_config_sampler(event->attr.config) == I915_SAMPLE_BUSY &&
+ supports_busy_stats() && !i915->pmu.busy_stats) {
+ i915->pmu.busy_stats = true;
+ if (!cancel_delayed_work(&i915->pmu.disable_busy_stats))
+ queue_work(i915->wq, &i915->pmu.enable_busy_stats);
+ }
+
i915->pmu.enable |= BIT_ULL(event->attr.config);
if (pmu_needs_timer(i915, true) && !i915->pmu.timer_enabled) {
hrtimer_start_range_ns(&i915->pmu.timer,
@@ -367,6 +391,11 @@ static void i915_pmu_disable(struct perf_event *event)
spin_lock_irqsave(&i915->pmu.lock, flags);
i915->pmu.enable &= ~BIT_ULL(event->attr.config);
i915->pmu.timer_enabled &= pmu_needs_timer(i915, true);
+ if (!(i915->pmu.enable & ENGINE_BUSY_BITS) && i915->pmu.busy_stats) {
+ i915->pmu.busy_stats = false;
+ queue_delayed_work(i915->wq, &i915->pmu.disable_busy_stats,
+ round_jiffies_up_relative(2 * HZ));
+ }
spin_unlock_irqrestore(&i915->pmu.lock, flags);
i915_pmu_timer_cancel(event);
@@ -471,7 +500,12 @@ static void i915_pmu_event_read(struct perf_event *event)
/* Do nothing */
} else {
enum intel_engine_id id = user_engine_map[user_engine];
- val = i915->engine[id]->pmu_sample[sample];
+ struct intel_engine_cs *engine = i915->engine[id];
+
+ if (i915->pmu.busy_stats && sample == I915_SAMPLE_BUSY)
+ val = intel_engine_get_current_busy_ns(engine);
+ else
+ val = engine->pmu_sample[sample];
[Intel-gfx] [RFC 10/14] drm/i915: Wrap context schedule notification
From: Tvrtko Ursulin
No functional change just something which will be handy in the
following patch.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 699868d81de8..89aa29f23a92 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -307,6 +307,18 @@ execlists_context_status_change(struct
drm_i915_gem_request *rq,
status, rq);
}
+static inline void
+execlists_context_schedule_in(struct drm_i915_gem_request *rq)
+{
+ execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
+}
+
+static inline void
+execlists_context_schedule_out(struct drm_i915_gem_request *rq)
+{
+ execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_OUT);
+}
+
static void
execlists_update_context_pdps(struct i915_hw_ppgtt *ppgtt, u32 *reg_state)
{
@@ -352,7 +364,7 @@ static void execlists_submit_ports(struct intel_engine_cs
*engine)
if (rq) {
GEM_BUG_ON(count > !n);
if (!count++)
- execlists_context_status_change(rq,
INTEL_CONTEXT_SCHEDULE_IN);
+ execlists_context_schedule_in(rq);
port_set(&port[n], port_pack(rq, count));
desc = execlists_update_context(rq);
GEM_DEBUG_EXEC(port[n].context_id =
upper_32_bits(desc));
@@ -603,8 +615,7 @@ static void intel_lrc_irq_handler(unsigned long data)
if (--count == 0) {
GEM_BUG_ON(status & GEN8_CTX_STATUS_PREEMPTED);
GEM_BUG_ON(!i915_gem_request_completed(rq));
- execlists_context_status_change(rq,
INTEL_CONTEXT_SCHEDULE_OUT);
-
+ execlists_context_schedule_out(rq);
trace_i915_gem_request_out(rq);
i915_gem_request_put(rq);
--
2.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 09/14] drm/i915/pmu: Suspend sampling when GPU is idle
From: Tvrtko Ursulin
If only a subset of events is enabled we can afford to suspend
the sampling timer when the GPU is idle and so save some cycles
and power.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 6
drivers/gpu/drm/i915/i915_gem.c | 1 +
drivers/gpu/drm/i915/i915_gem_request.c | 1 +
drivers/gpu/drm/i915/i915_pmu.c | 52 +++--
4 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index de518503e033..f1fded6dd9cf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2600,7 +2600,9 @@ struct drm_i915_private {
struct {
struct pmu base;
+ spinlock_t lock;
struct hrtimer timer;
+ bool timer_enabled;
u64 enable;
u64 sample[__I915_NUM_PMU_SAMPLERS];
} pmu;
@@ -3778,9 +3780,13 @@ extern void i915_perf_unregister(struct drm_i915_private
*dev_priv);
#ifdef CONFIG_PERF_EVENTS
extern void i915_pmu_register(struct drm_i915_private *i915);
extern void i915_pmu_unregister(struct drm_i915_private *i915);
+extern void i915_pmu_gt_idle(struct drm_i915_private *i915);
+extern void i915_pmu_gt_active(struct drm_i915_private *i915);
#else
static inline void i915_pmu_register(struct drm_i915_private *i915) {}
static inline void i915_pmu_unregister(struct drm_i915_private *i915) {}
+static inline void i915_pmu_gt_idle(struct drm_i915_private *i915) {}
+static inline void i915_pmu_gt_active(struct drm_i915_private *i915) {}
#endif
/* i915_suspend.c */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1b2dfa8bdeef..bb81c1fcbc40 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3235,6 +3235,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
intel_engines_mark_idle(dev_priv);
i915_gem_timelines_mark_idle(dev_priv);
+ i915_pmu_gt_idle(dev_priv);
GEM_BUG_ON(!dev_priv->gt.awake);
dev_priv->gt.awake = false;
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
b/drivers/gpu/drm/i915/i915_gem_request.c
index 483af8921060..569c44a6ba2a 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -876,6 +876,7 @@ static void i915_gem_mark_busy(const struct intel_engine_cs
*engine)
i915_update_gfx_val(dev_priv);
if (INTEL_GEN(dev_priv) >= 6)
gen6_rps_busy(dev_priv);
+ i915_pmu_gt_active(dev_priv);
queue_delayed_work(dev_priv->wq,
&dev_priv->gt.retire_work,
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 7ea84a191876..4b113cad40d1 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -29,6 +29,40 @@ static const unsigned int user_engine_map[I915_NUM_ENGINES]
= {
[I915_SAMPLE_VECS] = VECS,
};
+static bool pmu_needs_timer(struct drm_i915_private *i915, bool gpu_active)
+{
+ if (gpu_active)
+ return i915->pmu.enable;
+ else
+ return i915->pmu.enable >> 32;
+}
+
+void i915_pmu_gt_idle(struct drm_i915_private *i915)
+{
+ spin_lock_irq(&i915->pmu.lock);
+ /*
+* Signal sampling timer to stop if only engine events are enabled and
+* GPU went idle.
+*/
+ i915->pmu.timer_enabled = pmu_needs_timer(i915, false);
+ spin_unlock_irq(&i915->pmu.lock);
+}
+
+void i915_pmu_gt_active(struct drm_i915_private *i915)
+{
+ spin_lock_irq(&i915->pmu.lock);
+ /*
+* Re-enable sampling timer when GPU goes active.
+*/
+ if (!i915->pmu.timer_enabled && pmu_needs_timer(i915, true)) {
+ hrtimer_start_range_ns(&i915->pmu.timer,
+ ns_to_ktime(PERIOD), 0,
+ HRTIMER_MODE_REL_PINNED);
+ i915->pmu.timer_enabled = true;
+ }
+ spin_unlock_irq(&i915->pmu.lock);
+}
+
static bool grab_forcewake(struct drm_i915_private *i915, bool fw)
{
if (!fw)
@@ -133,7 +167,7 @@ static enum hrtimer_restart i915_sample(struct hrtimer
*hrtimer)
struct drm_i915_private *i915 =
container_of(hrtimer, struct drm_i915_private, pmu.timer);
- if (i915->pmu.enable == 0)
+ if (!READ_ONCE(i915->pmu.timer_enabled))
return HRTIMER_NORESTART;
engines_sample(i915);
@@ -307,13 +341,19 @@ static void i915_pmu_enable(struct perf_event *event)
{
struct drm_i915_private *i915 =
container_of(event->pmu, typeof(*i915), pmu.base);
+ unsigned long flags;
+
+ spin_lock_irqsave(&i915->pmu.lock, flags);
- if (i915->pmu.enable == 0)
+ i915->pmu.enable |= BIT_ULL(event->attr.config);
+ if (pmu_needs_timer(i915, true) && !i915->pmu.t
[Intel-gfx] [RFC 03/14] drm/i915/pmu: Add queued samplers to the PMU uAPI
From: Tvrtko Ursulin
This is also partially missing in the original patch.
Signed-off-by: Tvrtko Ursulin
---
include/uapi/drm/i915_drm.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 67e63757b35d..7003599a460e 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -103,22 +103,27 @@ enum i915_mocs_table_index {
#define __I915_PMU_COUNT(ring, id) ((ring) << 2 | (id))
+#define I915_PMU_COUNT_RCS_QUEUED __I915_PMU_COUNT(I915_SAMPLE_RCS,
I915_SAMPLE_QUEUED)
#define I915_PMU_COUNT_RCS_BUSY __I915_PMU_COUNT(I915_SAMPLE_RCS,
I915_SAMPLE_BUSY)
#define I915_PMU_COUNT_RCS_WAIT __I915_PMU_COUNT(I915_SAMPLE_RCS,
I915_SAMPLE_WAIT)
#define I915_PMU_COUNT_RCS_SEMA __I915_PMU_COUNT(I915_SAMPLE_RCS,
I915_SAMPLE_SEMA)
+#define I915_PMU_COUNT_VCS_QUEUED __I915_PMU_COUNT(I915_SAMPLE_VCS,
I915_SAMPLE_QUEUED)
#define I915_PMU_COUNT_VCS_BUSY __I915_PMU_COUNT(I915_SAMPLE_VCS,
I915_SAMPLE_BUSY)
#define I915_PMU_COUNT_VCS_WAIT __I915_PMU_COUNT(I915_SAMPLE_VCS,
I915_SAMPLE_WAIT)
#define I915_PMU_COUNT_VCS_SEMA __I915_PMU_COUNT(I915_SAMPLE_VCS,
I915_SAMPLE_SEMA)
+#define I915_PMU_COUNT_VCS2_QUEUED __I915_PMU_COUNT(I915_SAMPLE_VCS2,
I915_SAMPLE_QUEUED)
#define I915_PMU_COUNT_VCS2_BUSY __I915_PMU_COUNT(I915_SAMPLE_VCS2,
I915_SAMPLE_BUSY)
#define I915_PMU_COUNT_VCS2_WAIT __I915_PMU_COUNT(I915_SAMPLE_VCS2,
I915_SAMPLE_WAIT)
#define I915_PMU_COUNT_VCS2_SEMA __I915_PMU_COUNT(I915_SAMPLE_VCS2,
I915_SAMPLE_SEMA)
+#define I915_PMU_COUNT_BCS_QUEUED __I915_PMU_COUNT(I915_SAMPLE_BCS,
I915_SAMPLE_QUEUED)
#define I915_PMU_COUNT_BCS_BUSY __I915_PMU_COUNT(I915_SAMPLE_BCS,
I915_SAMPLE_BUSY)
#define I915_PMU_COUNT_BCS_WAIT __I915_PMU_COUNT(I915_SAMPLE_BCS,
I915_SAMPLE_WAIT)
#define I915_PMU_COUNT_BCS_SEMA __I915_PMU_COUNT(I915_SAMPLE_BCS,
I915_SAMPLE_SEMA)
+#define I915_PMU_COUNT_VECS_QUEUED __I915_PMU_COUNT(I915_SAMPLE_VECS,
I915_SAMPLE_QUEUED)
#define I915_PMU_COUNT_VECS_BUSY __I915_PMU_COUNT(I915_SAMPLE_VECS,
I915_SAMPLE_BUSY)
#define I915_PMU_COUNT_VECS_WAIT __I915_PMU_COUNT(I915_SAMPLE_VECS,
I915_SAMPLE_WAIT)
#define I915_PMU_COUNT_VECS_SEMA __I915_PMU_COUNT(I915_SAMPLE_VECS,
I915_SAMPLE_SEMA)
--
2.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 06/14] drm/i915/pmu: Only sample enabled samplers
From: Tvrtko Ursulin
Save some execution time by not reading the MMIO registers
for the samplers which are not enabled.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_pmu.c | 49 +++--
1 file changed, 33 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index d80e673477b5..4d61a1e72ee6 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -29,6 +29,14 @@ static const unsigned int user_engine_map[I915_NUM_ENGINES]
= {
[I915_SAMPLE_VECS] = VECS,
};
+static bool grab_forcewake(struct drm_i915_private *i915, bool fw)
+{
+ if (!fw)
+ intel_uncore_forcewake_get(i915, FORCEWAKE_ALL);
+
+ return true;
+}
+
static void engines_sample(struct drm_i915_private *dev_priv)
{
struct intel_engine_cs *engine;
@@ -46,6 +54,7 @@ static void engines_sample(struct drm_i915_private *dev_priv)
for_each_engine(engine, dev_priv, id) {
unsigned int user_engine = engine_map[id];
+ u8 sample_mask;
u32 val;
if (WARN_ON_ONCE(id >= ARRAY_SIZE(engine_map)))
@@ -53,30 +62,38 @@ static void engines_sample(struct drm_i915_private
*dev_priv)
else
user_engine = engine_map[id];
- if (!(dev_priv->pmu.enable &
- (ENGINE_SAMPLE_MASK << (ENGINE_SAMPLE_BITS * user_engine
+ sample_mask = (dev_priv->pmu.enable >>
+ (ENGINE_SAMPLE_BITS * user_engine)) &
+ ENGINE_SAMPLE_MASK;
+
+ if (!sample_mask)
continue;
if (i915_seqno_passed(intel_engine_get_seqno(engine),
intel_engine_last_submit(engine)))
continue;
- if (!fw) {
- intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
- fw = true;
- }
-
- engine->pmu_sample[I915_SAMPLE_QUEUED] += PERIOD;
+ if (sample_mask & BIT(I915_SAMPLE_QUEUED))
+ engine->pmu_sample[I915_SAMPLE_QUEUED] += PERIOD;
- val = I915_READ_FW(RING_MI_MODE(engine->mmio_base));
- if (!(val & MODE_IDLE))
- engine->pmu_sample[I915_SAMPLE_BUSY] += PERIOD;
+ if (sample_mask & BIT(I915_SAMPLE_BUSY)) {
+ fw = grab_forcewake(dev_priv, fw);
+ val = I915_READ_FW(RING_MI_MODE(engine->mmio_base));
+ if (!(val & MODE_IDLE))
+ engine->pmu_sample[I915_SAMPLE_BUSY] += PERIOD;
+ }
- val = I915_READ_FW(RING_CTL(engine->mmio_base));
- if (val & RING_WAIT)
- engine->pmu_sample[I915_SAMPLE_WAIT] += PERIOD;
- if (val & RING_WAIT_SEMAPHORE)
- engine->pmu_sample[I915_SAMPLE_SEMA] += PERIOD;
+ if (sample_mask &
+ (BIT(I915_SAMPLE_WAIT) | BIT(I915_SAMPLE_SEMA))) {
+ fw = grab_forcewake(dev_priv, fw);
+ val = I915_READ_FW(RING_CTL(engine->mmio_base));
+ if ((sample_mask & BIT(I915_SAMPLE_WAIT)) &&
+ (val & RING_WAIT))
+ engine->pmu_sample[I915_SAMPLE_WAIT] += PERIOD;
+ if ((sample_mask & BIT(I915_SAMPLE_SEMA)) &&
+ (val & RING_WAIT_SEMAPHORE))
+ engine->pmu_sample[I915_SAMPLE_SEMA] += PERIOD;
+ }
}
if (fw)
--
2.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 08/14] drm/i915/pmu: Expose events in sysfs
From: Tvrtko Ursulin
This makes then visible to "perf list".
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_pmu.c | 89 +
1 file changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 4195d89b1c82..7ea84a191876 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -474,11 +474,100 @@ static int i915_pmu_event_event_idx(struct perf_event
*event)
return 0;
}
+static ssize_t i915_pmu_format_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+struct dev_ext_attribute *eattr;
+
+eattr = container_of(attr, struct dev_ext_attribute, attr);
+return sprintf(buf, "%s\n", (char *) eattr->var);
+}
+
+#define I915_PMU_FORMAT_ATTR(_name, _config) \
+(&((struct dev_ext_attribute[]) { \
+{ .attr = __ATTR(_name, S_IRUGO, i915_pmu_format_show, NULL), \
+ .var = (void *) _config, }\
+})[0].attr.attr)
+
+static struct attribute *i915_pmu_format_attrs[] = {
+I915_PMU_FORMAT_ATTR(i915_eventid, "config:0-42"),
+NULL,
+};
+
+static const struct attribute_group i915_pmu_format_attr_group = {
+.name = "format",
+.attrs = i915_pmu_format_attrs,
+};
+
+static ssize_t i915_pmu_event_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+struct dev_ext_attribute *eattr;
+
+eattr = container_of(attr, struct dev_ext_attribute, attr);
+return sprintf(buf, "config=0x%lx\n", (unsigned long) eattr->var);
+}
+
+#define I915_PMU_EVENT_ATTR(_name, _config)\
+(&((struct dev_ext_attribute[]) { \
+{ .attr = __ATTR(_name, S_IRUGO, i915_pmu_event_show, NULL), \
+ .var = (void *) _config, }\
+ })[0].attr.attr)
+
+static struct attribute *i915_pmu_events_attrs[] = {
+I915_PMU_EVENT_ATTR(rcs-queued,I915_PMU_COUNT_RCS_QUEUED),
+I915_PMU_EVENT_ATTR(rcs-busy, I915_PMU_COUNT_RCS_BUSY),
+I915_PMU_EVENT_ATTR(rcs-wait, I915_PMU_COUNT_RCS_WAIT),
+I915_PMU_EVENT_ATTR(rcs-sema, I915_PMU_COUNT_RCS_SEMA),
+
+I915_PMU_EVENT_ATTR(bcs-queued,I915_PMU_COUNT_BCS_QUEUED),
+I915_PMU_EVENT_ATTR(bcs-busy, I915_PMU_COUNT_BCS_BUSY),
+I915_PMU_EVENT_ATTR(bcs-wait, I915_PMU_COUNT_BCS_WAIT),
+I915_PMU_EVENT_ATTR(bcs-sema, I915_PMU_COUNT_BCS_SEMA),
+
+I915_PMU_EVENT_ATTR(vcs-queued,I915_PMU_COUNT_VCS_QUEUED),
+I915_PMU_EVENT_ATTR(vcs-busy, I915_PMU_COUNT_VCS_BUSY),
+I915_PMU_EVENT_ATTR(vcs-wait, I915_PMU_COUNT_VCS_WAIT),
+I915_PMU_EVENT_ATTR(vcs-sema, I915_PMU_COUNT_VCS_SEMA),
+
+I915_PMU_EVENT_ATTR(vcs2-queued, I915_PMU_COUNT_VCS2_QUEUED),
+I915_PMU_EVENT_ATTR(vcs2-busy, I915_PMU_COUNT_VCS2_BUSY),
+I915_PMU_EVENT_ATTR(vcs2-wait, I915_PMU_COUNT_VCS2_WAIT),
+I915_PMU_EVENT_ATTR(vcs2-sema, I915_PMU_COUNT_VCS2_SEMA),
+
+I915_PMU_EVENT_ATTR(vecs-queued, I915_PMU_COUNT_VECS_QUEUED),
+I915_PMU_EVENT_ATTR(vecs-busy, I915_PMU_COUNT_VECS_BUSY),
+I915_PMU_EVENT_ATTR(vecs-wait, I915_PMU_COUNT_VECS_WAIT),
+I915_PMU_EVENT_ATTR(vecs-sema, I915_PMU_COUNT_VECS_SEMA),
+
+I915_PMU_EVENT_ATTR(actual-frequency, I915_PMU_ACTUAL_FREQUENCY),
+I915_PMU_EVENT_ATTR(requested-frequency, I915_PMU_REQUESTED_FREQUENCY),
+I915_PMU_EVENT_ATTR(energy, I915_PMU_ENERGY),
+I915_PMU_EVENT_ATTR(interrupts, I915_PMU_INTERRUPTS),
+I915_PMU_EVENT_ATTR(rc6-residency, I915_PMU_RC6_RESIDENCY),
+I915_PMU_EVENT_ATTR(rc6p-residency, I915_PMU_RC6p_RESIDENCY),
+I915_PMU_EVENT_ATTR(rc6pp-residency,I915_PMU_RC6pp_RESIDENCY),
+
+NULL,
+};
+
+static const struct attribute_group i915_pmu_events_attr_group = {
+.name = "events",
+.attrs = i915_pmu_events_attrs,
+};
+
+static const struct attribute_group *i915_pmu_attr_groups[] = {
+&i915_pmu_format_attr_group,
+&i915_pmu_events_attr_group,
+NULL
+};
+
void i915_pmu_register(struct drm_i915_private *i915)
{
if (INTEL_GEN(i915) <= 2)
return;
+ i915->pmu.base.attr_groups = i915_pmu_attr_groups;
i915->pmu.base.task_ctx_nr = perf_sw_context;
i915->pmu.base.event_init = i915_pmu_event_init;
i915->pmu.base.add = i915_pmu_event_add;
--
2.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 07/14] drm/i915/pmu: Add fake regs
From: Tvrtko Ursulin
Without this I can get a null ptr deref when trying to access
our events with perf.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_pmu.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 4d61a1e72ee6..4195d89b1c82 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -183,8 +183,11 @@ static int engine_event_init(struct perf_event *event)
return 0;
}
+static DEFINE_PER_CPU(struct pt_regs, i915_pmu_pt_regs);
+
static enum hrtimer_restart hrtimer_sample(struct hrtimer *hrtimer)
{
+ struct pt_regs *regs = this_cpu_ptr(&i915_pmu_pt_regs);
struct perf_sample_data data;
struct perf_event *event;
u64 period;
@@ -196,7 +199,7 @@ static enum hrtimer_restart hrtimer_sample(struct hrtimer
*hrtimer)
event->pmu->read(event);
perf_sample_data_init(&data, 0, event->hw.last_period);
- perf_event_overflow(event, &data, NULL);
+ perf_event_overflow(event, &data, regs);
period = max_t(u64, 1, event->hw.sample_period);
hrtimer_forward_now(hrtimer, ns_to_ktime(period));
--
2.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 04/14] drm/i915/pmu: Decouple uAPI engine ids
From: Tvrtko Ursulin
As elsewhere in the code we have to decouple the binary
engine identifiers for easier maintenance.
Also the sampler mask was incorrect in the timer callback.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_pmu.c | 44 -
1 file changed, 39 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index f03ddad44da6..9a8208dba7a9 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -10,6 +10,25 @@
#define RING_MASK 0x
#define RING_MAX 32
+#define ENGINE_SAMPLE_MASK (0xf)
+#define ENGINE_SAMPLE_BITS (4)
+
+static const unsigned int engine_map[I915_NUM_ENGINES] = {
+ [RCS] = I915_SAMPLE_RCS,
+ [BCS] = I915_SAMPLE_BCS,
+ [VCS] = I915_SAMPLE_VCS,
+ [VCS2] = I915_SAMPLE_VCS2,
+ [VECS] = I915_SAMPLE_VECS,
+};
+
+static const unsigned int user_engine_map[I915_NUM_ENGINES] = {
+ [I915_SAMPLE_RCS] = RCS,
+ [I915_SAMPLE_BCS] = BCS,
+ [I915_SAMPLE_VCS] = VCS,
+ [I915_SAMPLE_VCS2] = VCS2,
+ [I915_SAMPLE_VECS] = VECS,
+};
+
static void engines_sample(struct drm_i915_private *dev_priv)
{
struct intel_engine_cs *engine;
@@ -26,9 +45,16 @@ static void engines_sample(struct drm_i915_private *dev_priv)
return;
for_each_engine(engine, dev_priv, id) {
+ unsigned int user_engine = engine_map[id];
u32 val;
- if ((dev_priv->pmu.enable & (0x7 << (4*id))) == 0)
+ if (WARN_ON_ONCE(id >= ARRAY_SIZE(engine_map)))
+ continue;
+ else
+ user_engine = engine_map[id];
+
+ if (!(dev_priv->pmu.enable &
+ (ENGINE_SAMPLE_MASK << (ENGINE_SAMPLE_BITS * user_engine
continue;
if (i915_seqno_passed(intel_engine_get_seqno(engine),
@@ -112,6 +138,11 @@ static int engine_event_init(struct perf_event *event)
int engine = event->attr.config >> 2;
int sample = event->attr.config & 3;
+ if (WARN_ON_ONCE(engine >= ARRAY_SIZE(user_engine_map)))
+ return -ENOENT;
+ else
+ engine = user_engine_map[engine];
+
switch (sample) {
case I915_SAMPLE_QUEUED:
case I915_SAMPLE_BUSY:
@@ -125,9 +156,6 @@ static int engine_event_init(struct perf_event *event)
return -ENOENT;
}
- if (engine >= I915_NUM_ENGINES)
- return -ENOENT;
-
if (!i915->engine[engine])
return -ENODEV;
@@ -369,7 +397,13 @@ static void i915_pmu_event_read(struct perf_event *event)
if (event->attr.config < 32) {
int engine = event->attr.config >> 2;
int sample = event->attr.config & 3;
- val = i915->engine[engine]->pmu_sample[sample];
+
+ if (WARN_ON_ONCE(engine >= ARRAY_SIZE(user_engine_map))) {
+ /* Do nothing */
+ } else {
+ engine = user_engine_map[engine];
+ val = i915->engine[engine]->pmu_sample[sample];
+ }
} else switch (event->attr.config) {
case I915_PMU_ACTUAL_FREQUENCY:
val = i915->pmu.sample[__I915_SAMPLE_FREQ_ACT];
--
2.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 12/14] drm/i915: Interface for controling engine stats collection
From: Tvrtko Ursulin
Enables other i915 components to enable and disable
the facility as needed.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 53 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 5
2 files changed, 58 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 3e5e08c6b5ef..03e7459bad06 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -29,6 +29,8 @@
#include "intel_lrc.h"
DEFINE_STATIC_KEY_FALSE(i915_engine_stats_key);
+static DEFINE_MUTEX(i915_engine_stats_mutex);
+static int i915_engine_stats_ref;
/* Haswell does have the CXT_SIZE register however it does not appear to be
* valid. Now, docs explain in dwords what is in the context object. The full
@@ -1340,6 +1342,57 @@ void intel_engines_mark_idle(struct drm_i915_private
*i915)
}
}
+int intel_enable_engine_stats(struct drm_i915_private *dev_priv)
+{
+ if (!i915.enable_execlists)
+ return -ENODEV;
+
+ mutex_lock(&i915_engine_stats_mutex);
+ if (i915_engine_stats_ref++ == 0) {
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ for_each_engine(engine, dev_priv, id) {
+ memset(&engine->stats, 0, sizeof(engine->stats));
+ spin_lock_init(&engine->stats.lock);
+ }
+
+ static_branch_enable(&i915_engine_stats_key);
+ }
+ mutex_unlock(&i915_engine_stats_mutex);
+
+ return 0;
+}
+
+void intel_disable_engine_stats(void)
+{
+ mutex_lock(&i915_engine_stats_mutex);
+ if (--i915_engine_stats_ref == 0)
+ static_branch_disable(&i915_engine_stats_key);
+ mutex_unlock(&i915_engine_stats_mutex);
+}
+
+u64 intel_engine_get_current_busy_ns(struct intel_engine_cs *engine)
+{
+ unsigned long flags;
+ u64 total;
+
+ spin_lock_irqsave(&engine->stats.lock, flags);
+
+ total = engine->stats.total;
+
+ /*
+* If the engine is executing something at the moment
+* add it to the total.
+*/
+ if (engine->stats.ref)
+ total += ktime_get_real_ns() - engine->stats.start;
+
+ spin_unlock_irqrestore(&engine->stats.lock, flags);
+
+ return total;
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/mock_engine.c"
#endif
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 2eb1e970ad06..e0f495a6d0d9 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -776,4 +776,9 @@ static inline void intel_engine_context_out(struct
intel_engine_cs *engine)
}
}
+int intel_enable_engine_stats(struct drm_i915_private *i915);
+void intel_disable_engine_stats(void);
+
+u64 intel_engine_get_current_busy_ns(struct intel_engine_cs *engine);
+
#endif /* _INTEL_RINGBUFFER_H_ */
--
2.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 11/14] drm/i915: Engine busy time tracking
From: Tvrtko Ursulin
Track total time requests have been executing on the hardware.
To make this cheap it is hidden behind a static branch with the
intention that it is only enabled when there is a consumer
listening. This means that in the default off case the total
cost of the tracking is just a few no-op instructions on the
fast paths.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 6 +
drivers/gpu/drm/i915/intel_lrc.c| 2 ++
drivers/gpu/drm/i915/intel_ringbuffer.h | 39 +
3 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 24db316e0fd1..3e5e08c6b5ef 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -22,10 +22,14 @@
*
*/
+#include
+
#include "i915_drv.h"
#include "intel_ringbuffer.h"
#include "intel_lrc.h"
+DEFINE_STATIC_KEY_FALSE(i915_engine_stats_key);
+
/* Haswell does have the CXT_SIZE register however it does not appear to be
* valid. Now, docs explain in dwords what is in the context object. The full
* size is 70720 bytes, however, the power context and execlist context will
@@ -223,6 +227,8 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
/* Nothing to do here, execute in order of dependencies */
engine->schedule = NULL;
+ spin_lock_init(&engine->stats.lock);
+
ATOMIC_INIT_NOTIFIER_HEAD(&engine->context_status_notifier);
dev_priv->engine[id] = engine;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 89aa29f23a92..b72a2d7cd44c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -310,12 +310,14 @@ execlists_context_status_change(struct
drm_i915_gem_request *rq,
static inline void
execlists_context_schedule_in(struct drm_i915_gem_request *rq)
{
+ intel_engine_context_in(rq->engine);
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
}
static inline void
execlists_context_schedule_out(struct drm_i915_gem_request *rq)
{
+ intel_engine_context_out(rq->engine);
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_OUT);
}
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 0877b151239d..2eb1e970ad06 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -443,6 +443,13 @@ struct intel_engine_cs {
* certain bits to encode the command length in the header).
*/
u32 (*get_cmd_length_mask)(u32 cmd_header);
+
+ struct {
+ spinlock_t lock;
+ unsigned int ref;
+ u64 start; /* Timestamp of the last idle to active transition.
*/
+ u64 total; /* Total time engined was busy. */
+ } stats;
};
static inline unsigned int
@@ -737,4 +744,36 @@ bool intel_engines_are_idle(struct drm_i915_private
*dev_priv);
void intel_engines_mark_idle(struct drm_i915_private *i915);
void intel_engines_reset_default_submission(struct drm_i915_private *i915);
+DECLARE_STATIC_KEY_FALSE(i915_engine_stats_key);
+
+static inline void intel_engine_context_in(struct intel_engine_cs *engine)
+{
+ if (static_branch_unlikely(&i915_engine_stats_key)) {
+ unsigned long flags;
+
+ spin_lock_irqsave(&engine->stats.lock, flags);
+ if (engine->stats.ref++ == 0)
+ engine->stats.start = ktime_get_real_ns();
+ GEM_BUG_ON(engine->stats.ref == 0);
+ spin_unlock_irqrestore(&engine->stats.lock, flags);
+ }
+}
+
+static inline void intel_engine_context_out(struct intel_engine_cs *engine)
+{
+ if (static_branch_unlikely(&i915_engine_stats_key)) {
+ unsigned long flags;
+
+ spin_lock_irqsave(&engine->stats.lock, flags);
+ /*
+* After turning on the static key context out might be the
+* first event which then needs to be ignored (ref == 0).
+*/
+ if (engine->stats.ref && --engine->stats.ref == 0)
+ engine->stats.total += ktime_get_real_ns() -
+ engine->stats.start;
+ spin_unlock_irqrestore(&engine->stats.lock, flags);
+ }
+}
+
#endif /* _INTEL_RINGBUFFER_H_ */
--
2.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 13/14] drm/i915: Export engine busy stats in debugfs
From: Tvrtko Ursulin
Export the stats added in the previous patch in debugfs.
Number of active clients reading this data is tracked and the
static key is only enabled whilst there are some.
Userspace is intended to keep the file descriptor open, seeking
to the beginning of the file periodically, and re-reading the
stats.
This is because the underlying implementation is costly on every
first open/last close transition, and also, because the stats
exported mostly make sense when they are considered relative to
the previous sample.
File lists nanoseconds each engine was active since the tracking
has started.
v2: Rebase.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 89 +
1 file changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2ef75c1a6119..5a425cc225df 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4848,6 +4848,89 @@ static const struct file_operations
i915_hpd_storm_ctl_fops = {
.write = i915_hpd_storm_ctl_write
};
+struct i915_engine_stats_buf {
+ unsigned int len;
+ size_t available;
+ char buf[0];
+};
+
+static int i915_engine_stats_open(struct inode *inode, struct file *file)
+{
+ struct drm_i915_private *i915 = file->f_inode->i_private;
+ const unsigned int engine_name_len =
+ sizeof(((struct intel_engine_cs *)0)->name);
+ struct i915_engine_stats_buf *buf;
+ const unsigned int buf_size =
+ (engine_name_len + 2 + 19 + 1) * I915_NUM_ENGINES + 1 +
+ sizeof(*buf);
+ int ret;
+
+ buf = kzalloc(buf_size, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ ret = intel_enable_engine_stats(i915);
+ if (ret) {
+ kfree(buf);
+ return ret;
+ }
+
+ buf->len = buf_size;
+ file->private_data = buf;
+
+ return 0;
+}
+
+static int i915_engine_stats_release(struct inode *inode, struct file *file)
+{
+ intel_disable_engine_stats();
+ kfree(file->private_data);
+
+ return 0;
+}
+
+static ssize_t i915_engine_stats_read(struct file *file, char __user *ubuf,
+ size_t count, loff_t *pos)
+{
+ struct i915_engine_stats_buf *buf =
+ (struct i915_engine_stats_buf *)file->private_data;
+
+ if (*pos == 0) {
+ struct drm_i915_private *dev_priv = file->f_inode->i_private;
+ char *ptr = &buf->buf[0];
+ int left = buf->len;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ buf->available = 0;
+
+ for_each_engine(engine, dev_priv, id) {
+ u64 total = intel_engine_get_current_busy_ns(engine);
+ int len;
+
+ len = snprintf(ptr, left, "%s: %llu\n",
+ engine->name, total);
+ buf->available += len;
+ left -= len;
+ ptr += len;
+
+ if (len == 0)
+ return -EFBIG;
+ }
+ }
+
+ return simple_read_from_buffer(ubuf, count, pos, &buf->buf[0],
+ buf->available);
+}
+
+static const struct file_operations i915_engine_stats_fops = {
+ .owner = THIS_MODULE,
+ .open = i915_engine_stats_open,
+ .release = i915_engine_stats_release,
+ .read = i915_engine_stats_read,
+ .llseek = default_llseek,
+};
+
static const struct drm_info_list i915_debugfs_list[] = {
{"i915_capabilities", i915_capabilities, 0},
{"i915_gem_objects", i915_gem_object_info, 0},
@@ -4938,6 +5021,12 @@ int i915_debugfs_register(struct drm_i915_private
*dev_priv)
struct dentry *ent;
int ret, i;
+ ent = debugfs_create_file("i915_engine_stats", S_IRUGO,
+ minor->debugfs_root, to_i915(minor->dev),
+ &i915_engine_stats_fops);
+ if (!ent)
+ return -ENOMEM;
+
ent = debugfs_create_file("i915_forcewake_user", S_IRUSR,
minor->debugfs_root, to_i915(minor->dev),
&i915_forcewake_fops);
--
2.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 05/14] drm/i915/pmu: Helper to extract engine and sampler from PMU config
From: Tvrtko Ursulin
Less hardcoded shifts and ands in the code is better.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_pmu.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 9a8208dba7a9..d80e673477b5 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -131,17 +131,21 @@ static void i915_pmu_event_destroy(struct perf_event
*event)
WARN_ON(event->parent);
}
+#define pmu_config_engine(config) ((config) >> 2)
+#define pmu_config_sampler(config) ((config) & 3)
+
static int engine_event_init(struct perf_event *event)
{
struct drm_i915_private *i915 =
container_of(event->pmu, typeof(*i915), pmu.base);
- int engine = event->attr.config >> 2;
- int sample = event->attr.config & 3;
+ unsigned int user_engine = pmu_config_engine(event->attr.config);
+ unsigned int sample = pmu_config_sampler(event->attr.config);
+ enum intel_engine_id engine_id;
- if (WARN_ON_ONCE(engine >= ARRAY_SIZE(user_engine_map)))
+ if (WARN_ON_ONCE(user_engine >= ARRAY_SIZE(user_engine_map)))
return -ENOENT;
else
- engine = user_engine_map[engine];
+ engine_id = user_engine_map[user_engine];
switch (sample) {
case I915_SAMPLE_QUEUED:
@@ -156,7 +160,7 @@ static int engine_event_init(struct perf_event *event)
return -ENOENT;
}
- if (!i915->engine[engine])
+ if (!i915->engine[engine_id])
return -ENODEV;
return 0;
@@ -395,14 +399,14 @@ static void i915_pmu_event_read(struct perf_event *event)
u64 val = 0;
if (event->attr.config < 32) {
- int engine = event->attr.config >> 2;
- int sample = event->attr.config & 3;
+ unsigned int user_engine =
pmu_config_engine(event->attr.config);
+ unsigned int sample = pmu_config_sampler(event->attr.config);
- if (WARN_ON_ONCE(engine >= ARRAY_SIZE(user_engine_map))) {
+ if (WARN_ON_ONCE(user_engine >= ARRAY_SIZE(user_engine_map))) {
/* Do nothing */
} else {
- engine = user_engine_map[engine];
- val = i915->engine[engine]->pmu_sample[sample];
+ enum intel_engine_id id = user_engine_map[user_engine];
+ val = i915->engine[id]->pmu_sample[sample];
}
} else switch (event->attr.config) {
case I915_PMU_ACTUAL_FREQUENCY:
--
2.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 00/14] i915 PMU and engine busy stats
From: Tvrtko Ursulin Rough sketch of the idea I mentioned a few times to various people - merging the engine busyness tracking with Chris i915 PMU RFC. First patch is the actual PMU RFC by Chris. It is followed by some cleanup patches, then come a few improvements, cheap execlists engine busyness tracking, debugfs view for the same, and finally the i915 PMU is extended to use this instead of timer based mmio sampling. This makes it cheaper and also more accurate since engine busyness is not derived via sampling. But I haven't figure out the perf API yet. For example is it possible to access our events in an usable fashion via perf top/stat or something? Do we want to make the events discoverable as I did (patch 8). I could not find much (any?) kernel API level documentation for perf. Btw patch series actually works since intel-gpu-overlay can use these events when they are available. Chris Wilson (1): RFC drm/i915: Expose a PMU interface for perf queries Tvrtko Ursulin (13): drm/i915/pmu: Add VCS2 engine to the PMU uAPI drm/i915/pmu: Add queued samplers to the PMU uAPI drm/i915/pmu: Decouple uAPI engine ids drm/i915/pmu: Helper to extract engine and sampler from PMU config drm/i915/pmu: Only sample enabled samplers drm/i915/pmu: Add fake regs drm/i915/pmu: Expose events in sysfs drm/i915/pmu: Suspend sampling when GPU is idle drm/i915: Wrap context schedule notification drm/i915: Engine busy time tracking drm/i915: Interface for controling engine stats collection drm/i915: Export engine busy stats in debugfs drm/i915/pmu: Wire up engine busy stats to PMU drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_debugfs.c | 89 drivers/gpu/drm/i915/i915_drv.c | 2 + drivers/gpu/drm/i915/i915_drv.h | 32 ++ drivers/gpu/drm/i915/i915_gem.c | 1 + drivers/gpu/drm/i915/i915_gem_request.c | 1 + drivers/gpu/drm/i915/i915_pmu.c | 697 drivers/gpu/drm/i915/intel_engine_cs.c | 59 +++ drivers/gpu/drm/i915/intel_lrc.c| 19 +- drivers/gpu/drm/i915/intel_ringbuffer.h | 46 +++ include/uapi/drm/i915_drm.h | 51 +++ kernel/events/core.c| 1 + 12 files changed, 996 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_pmu.c -- 2.9.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 02/14] drm/i915/pmu: Add VCS2 engine to the PMU uAPI
From: Tvrtko Ursulin
It is missing from the original patch.
Signed-off-by: Tvrtko Ursulin
---
include/uapi/drm/i915_drm.h | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 733774f19a0b..67e63757b35d 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -96,9 +96,10 @@ enum i915_mocs_table_index {
#define I915_SAMPLE_SEMA 3
#define I915_SAMPLE_RCS0
-#define I915_SAMPLE_VCS1
-#define I915_SAMPLE_BCS2
-#define I915_SAMPLE_VECS 3
+#define I915_SAMPLE_BCS1
+#define I915_SAMPLE_VCS2
+#define I915_SAMPLE_VCS2 3
+#define I915_SAMPLE_VECS 4
#define __I915_PMU_COUNT(ring, id) ((ring) << 2 | (id))
@@ -110,6 +111,10 @@ enum i915_mocs_table_index {
#define I915_PMU_COUNT_VCS_WAIT __I915_PMU_COUNT(I915_SAMPLE_VCS,
I915_SAMPLE_WAIT)
#define I915_PMU_COUNT_VCS_SEMA __I915_PMU_COUNT(I915_SAMPLE_VCS,
I915_SAMPLE_SEMA)
+#define I915_PMU_COUNT_VCS2_BUSY __I915_PMU_COUNT(I915_SAMPLE_VCS2,
I915_SAMPLE_BUSY)
+#define I915_PMU_COUNT_VCS2_WAIT __I915_PMU_COUNT(I915_SAMPLE_VCS2,
I915_SAMPLE_WAIT)
+#define I915_PMU_COUNT_VCS2_SEMA __I915_PMU_COUNT(I915_SAMPLE_VCS2,
I915_SAMPLE_SEMA)
+
#define I915_PMU_COUNT_BCS_BUSY __I915_PMU_COUNT(I915_SAMPLE_BCS,
I915_SAMPLE_BUSY)
#define I915_PMU_COUNT_BCS_WAIT __I915_PMU_COUNT(I915_SAMPLE_BCS,
I915_SAMPLE_WAIT)
#define I915_PMU_COUNT_BCS_SEMA __I915_PMU_COUNT(I915_SAMPLE_BCS,
I915_SAMPLE_SEMA)
--
2.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 01/14] RFC drm/i915: Expose a PMU interface for perf queries
From: Chris Wilson
The first goal is to be able to measure GPU (and invidual ring) busyness
without having to poll registers from userspace. (Which not only incurs
holding the forcewake lock indefinitely, perturbing the system, but also
runs the risk of hanging the machine.) As an alternative we can use the
perf event counter interface to sample the ring registers periodically
and send those results to userspace.
To be able to do so, we need to export the two symbols from
kernel/events/core.c to register and unregister a PMU device.
v2: Use a common timer for the ring sampling.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.c | 2 +
drivers/gpu/drm/i915/i915_drv.h | 23 ++
drivers/gpu/drm/i915/i915_pmu.c | 452
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +
include/uapi/drm/i915_drm.h | 41 +++
kernel/events/core.c| 1 +
7 files changed, 522 insertions(+)
create mode 100644 drivers/gpu/drm/i915/i915_pmu.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index f8227318dcaf..1c720013dc42 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -26,6 +26,7 @@ i915-y := i915_drv.o \
i915-$(CONFIG_COMPAT) += i915_ioc32.o
i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o intel_pipe_crc.o
+i915-$(CONFIG_PERF_EVENTS) += i915_pmu.o
# GEM code
i915-y += i915_cmd_parser.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d310d8245dca..f18ce519f6a2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1194,6 +1194,7 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
struct drm_device *dev = &dev_priv->drm;
i915_gem_shrinker_init(dev_priv);
+ i915_pmu_register(dev_priv);
/*
* Notify a valid surface after modesetting,
@@ -1247,6 +1248,7 @@ static void i915_driver_unregister(struct
drm_i915_private *dev_priv)
intel_opregion_unregister(dev_priv);
i915_perf_unregister(dev_priv);
+ i915_pmu_unregister(dev_priv);
i915_teardown_sysfs(dev_priv);
i915_guc_log_unregister(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7c6fab08a2e6..de518503e033 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2093,6 +2094,12 @@ struct intel_cdclk_state {
unsigned int cdclk, vco, ref;
};
+enum {
+ __I915_SAMPLE_FREQ_ACT = 0,
+ __I915_SAMPLE_FREQ_REQ,
+ __I915_NUM_PMU_SAMPLERS
+};
+
struct drm_i915_private {
struct drm_device drm;
@@ -2591,6 +2598,13 @@ struct drm_i915_private {
int irq;
} lpe_audio;
+ struct {
+ struct pmu base;
+ struct hrtimer timer;
+ u64 enable;
+ u64 sample[__I915_NUM_PMU_SAMPLERS];
+ } pmu;
+
/*
* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
* will be rejected. Instead look for a better place.
@@ -3760,6 +3774,15 @@ 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_pmu.c */
+#ifdef CONFIG_PERF_EVENTS
+extern void i915_pmu_register(struct drm_i915_private *i915);
+extern void i915_pmu_unregister(struct drm_i915_private *i915);
+#else
+static inline void i915_pmu_register(struct drm_i915_private *i915) {}
+static inline void i915_pmu_unregister(struct drm_i915_private *i915) {}
+#endif
+
/* 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_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
new file mode 100644
index ..f03ddad44da6
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -0,0 +1,452 @@
+#include
+#include
+
+#include "i915_drv.h"
+#include "intel_ringbuffer.h"
+
+#define FREQUENCY 200
+#define PERIOD max_t(u64, 1, NSEC_PER_SEC / FREQUENCY)
+
+#define RING_MASK 0x
+#define RING_MAX 32
+
+static void engines_sample(struct drm_i915_private *dev_priv)
+{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ bool fw = false;
+
+ if ((dev_priv->pmu.enable & RING_MASK) == 0)
+ return;
+
+ if (!dev_priv->gt.awake)
+ return;
+
+ if (!intel_runtime_pm_get_if_in_use(dev_priv))
+ return;
+
+ for_each_engine(engine, dev_priv, id) {
+ u32 val;
+
+ if ((dev_priv->pmu.enable & (0x7 << (4*id))) == 0)
+ continue;
+
+
[Intel-gfx] [PATCH v2] drm/i915: Explicit the connector name for DP link training result
This adds the connector name when printing a debug message about the DP
link training result. It is useful to figure out what connector is
failing when multiple DP connectors are used.
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/i915/intel_dp_link_training.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index b79c1c0e404c..05907fa8a553 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -321,12 +321,16 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
if (!intel_dp_link_training_channel_equalization(intel_dp))
goto failure_handling;
- DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane count = %d",
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training Passed at Link Rate =
%d, Lane count = %d",
+ intel_connector->base.base.id,
+ intel_connector->base.name,
intel_dp->link_rate, intel_dp->lane_count);
return;
failure_handling:
- DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane count = %d",
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate =
%d, lane count = %d",
+ intel_connector->base.base.id,
+ intel_connector->base.name,
intel_dp->link_rate, intel_dp->lane_count);
if (!intel_dp_get_link_train_fallback_values(intel_dp,
intel_dp->link_rate,
--
2.13.2
___
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: Drain the device workqueue on unload (rev2)
== Series Details == Series: drm/i915: Drain the device workqueue on unload (rev2) URL : https://patchwork.freedesktop.org/series/26494/ State : success == Summary == Series 26494v2 drm/i915: Drain the device workqueue on unload https://patchwork.freedesktop.org/api/1.0/series/26494/revisions/2/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-kbl-7560u) k.org#196399 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: pass -> FAIL (fi-snb-2600) fdo#100215 Test kms_flip: Subgroup basic-flip-vs-modeset: skip -> PASS (fi-skl-x1585l) fdo#101781 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> DMESG-WARN (fi-pnv-d510) fdo#101597 Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-j1900) fdo#101705 k.org#196399 https://bugzilla.kernel.org/show_bug.cgi?id=196399 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:440s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:426s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:353s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:533s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:505s fi-byt-j1900 total:279 pass:255 dwarn:0 dfail:0 fail:0 skip:24 time:493s fi-byt-n2820 total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:488s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:610s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:440s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:414s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:414s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:502s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:470s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:468s fi-kbl-7560u total:279 pass:268 dwarn:1 dfail:0 fail:0 skip:10 time:569s fi-kbl-r total:279 pass:260 dwarn:1 dfail:0 fail:0 skip:18 time:579s fi-pnv-d510 total:279 pass:222 dwarn:2 dfail:0 fail:0 skip:55 time:569s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:452s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:585s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:467s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:472s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:441s fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:482s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:539s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:411s 10de1e17faaab452782e5a1baffd1b30a639a261 drm-tip: 2017y-07m-18d-10h-08m-42s UTC integration manifest b859b5d drm/i915: Drain the device workqueue on unload == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5219/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Drain the device workqueue on unload
Workers on the i915->wq may rearm themselves so for completeness we need
to replace our flush_workqueue() with a call to drain_workqueue() before
unloading the device.
v2: Reinforce the drain_workqueue with an preceeding rcu_barrier() as a
few of the tasks that need to be drained may first be armed by RCU.
References: https://bugs.freedesktop.org/show_bug.cgi?id=101627
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.c | 6 ++
drivers/gpu/drm/i915/i915_drv.h | 20
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
3 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4b62fd012877..41c5b11a7c8f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -596,7 +596,8 @@ static const struct vga_switcheroo_client_ops
i915_switcheroo_ops = {
static void i915_gem_fini(struct drm_i915_private *dev_priv)
{
- flush_workqueue(dev_priv->wq);
+ /* Flush any outstanding unpin_work. */
+ i915_gem_drain_workqueue(dev_priv);
mutex_lock(&dev_priv->drm.struct_mutex);
intel_uc_fini_hw(dev_priv);
@@ -1409,9 +1410,6 @@ void i915_driver_unload(struct drm_device *dev)
cancel_delayed_work_sync(&dev_priv->gpu_error.hangcheck_work);
i915_reset_error_state(dev_priv);
- /* Flush any outstanding unpin_work. */
- drain_workqueue(dev_priv->wq);
-
i915_gem_fini(dev_priv);
intel_uc_fini_fw(dev_priv);
intel_fbc_cleanup_cfb(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 667fb5c44483..e9a4b96dc775 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3300,6 +3300,26 @@ static inline void i915_gem_drain_freed_objects(struct
drm_i915_private *i915)
} while (flush_work(&i915->mm.free_work));
}
+static inline void i915_gem_drain_workqueue(struct drm_i915_private *i915)
+{
+ /*
+* Similar to objects above (see i915_gem_drain_freed-objects), in
+* general we have workers that are armed by RCU and then rearm
+* themselves in their callbacks. To be paranoid, we need to
+* drain the workqueue a second time after waiting for the RCU
+* grace period so that we catch work queued via RCU from the first
+* pass. As neither drain_workqueue() nor flush_workqueue() report
+* a result, we make an assumption that we only don't require more
+* than 2 passes to catch all recursive RCU delayed work.
+*
+*/
+ int pass = 2;
+ do {
+ rcu_barrier();
+ drain_workqueue(i915->wq);
+ } while (--pass);
+}
+
struct i915_vma * __must_check
i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
const struct i915_ggtt_view *view,
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 47613d20bba8..7a468cb30946 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -57,7 +57,7 @@ static void mock_device_release(struct drm_device *dev)
cancel_delayed_work_sync(&i915->gt.retire_work);
cancel_delayed_work_sync(&i915->gt.idle_work);
- flush_workqueue(i915->wq);
+ i915_gem_drain_workqueue(i915);
mutex_lock(&i915->drm.struct_mutex);
for_each_engine(engine, i915, id)
--
2.13.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 Fixed16.16 wrapper cleanup & wm optimization (rev6)
== Series Details == Series: Fixed16.16 wrapper cleanup & wm optimization (rev6) URL : https://patchwork.freedesktop.org/series/25692/ State : success == Summary == Series 25692v6 Fixed16.16 wrapper cleanup & wm optimization https://patchwork.freedesktop.org/api/1.0/series/25692/revisions/6/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-kbl-7560u) k.org#196399 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-j1900) fdo#101705 +1 k.org#196399 https://bugzilla.kernel.org/show_bug.cgi?id=196399 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:439s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:429s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:358s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:535s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:504s fi-byt-j1900 total:279 pass:255 dwarn:0 dfail:0 fail:0 skip:24 time:492s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:490s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:598s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:443s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:417s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:414s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:499s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:466s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:463s fi-kbl-7560u total:279 pass:268 dwarn:1 dfail:0 fail:0 skip:10 time:571s fi-kbl-r total:279 pass:260 dwarn:1 dfail:0 fail:0 skip:18 time:578s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:563s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:453s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:586s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:467s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:475s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:441s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:463s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:548s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:399s 10de1e17faaab452782e5a1baffd1b30a639a261 drm-tip: 2017y-07m-18d-10h-08m-42s UTC integration manifest e6dea33 drm/i915/skl+: debugfs entry to control IPC 38552712 drm/i915/bxt+: Enable IPC support 1564688 drm/i915/gen9+: Add has_ipc flag in device info structure fac25d3 drm/i915/cnl: Extend WM workaround with IPC for CNL c99e00c drm/i915/glk: IPC linetime watermark workaround for GLK c549418 drm/i915/gen10: Calculate and enable transition WM a180ccf drm/i915/skl+: Optimize WM calculation 10e25f6 drm/i915: Fixed point fixed16 wrapper cleanup == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5218/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/8] drm/i915/bxt+: Enable IPC support
From: "Kumar, Mahesh"
This patch adds IPC support. This patch also enables IPC in all supported
platforms based on has_ipc flag.
IPC (Isochronous Priority Control) is the hardware feature, which
dynamically controls the memory read priority of Display.
When IPC is enabled, plane read requests are sent at high priority until
filling above the transition watermark, then the requests are sent at
lower priority until dropping below the level 0 watermark.
The lower priority requests allow other memory clients to have better
memory access. When IPC is disabled, all plane read requests are sent at
high priority.
Changes since V1:
- Remove commandline parameter to disable ipc
- Address Paulo's comments
Changes since V2:
- Address review comments
- Set ipc_enabled flag
Changes since V3:
- move ipc_enabled flag assignment inside intel_ipc_enable function
Changes since V4:
- Re-enable IPC after suspend/resume
Changes since V5:
- Enable IPC for all gen >=9 except SKL
Changes since V6:
- fix commit msg
- after resume program IPC based on SW state.
Changes since V7:
- Modify IPC support check based on HAS_IPC macro (suggested by Chris)
Signed-off-by: Mahesh Kumar
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 4 +++-
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_pm.c | 24
5 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d310d8245dca..c69958b55ee2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1338,7 +1338,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct
pci_device_id *ent)
intel_runtime_pm_enable(dev_priv);
- dev_priv->ipc_enabled = false;
+ intel_init_ipc(dev_priv);
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG))
DRM_INFO("DRM_I915_DEBUG enabled\n");
@@ -2602,6 +2602,8 @@ static int intel_runtime_resume(struct device *kdev)
if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
intel_hpd_init(dev_priv);
+ intel_enable_ipc(dev_priv);
+
enable_rpm_wakeref_asserts(dev_priv);
if (ret)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c712d01f92ab..4ceda0fc1baf 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6728,6 +6728,7 @@ enum {
#define DISP_FBC_WM_DIS (1<<15)
#define DISP_ARB_CTL2 _MMIO(0x45004)
#define DISP_DATA_PARTITION_5_6 (1<<6)
+#define DISP_IPC_ENABLE (1<<3)
#define DBUF_CTL _MMIO(0x45008)
#define DBUF_POWER_REQUEST(1<<31)
#define DBUF_POWER_STATE (1<<30)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0ed454a23e34..0a5d6ba64925 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15733,6 +15733,7 @@ void intel_display_resume(struct drm_device *dev)
if (!ret)
ret = __intel_display_resume(dev, state, &ctx);
+ intel_enable_ipc(dev_priv);
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0902d7cb48d9..7b0e834a61f9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1883,6 +1883,8 @@ bool ilk_disable_lp_wm(struct drm_device *dev);
int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
int skl_check_pipe_max_pixel_rate(struct intel_crtc *intel_crtc,
struct intel_crtc_state *cstate);
+void intel_init_ipc(struct drm_i915_private *dev_priv);
+void intel_enable_ipc(struct drm_i915_private *dev_priv);
static inline int intel_enable_rc6(void)
{
return i915.enable_rc6;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f2794d29f217..70f59df09e75 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5772,6 +5772,30 @@ void intel_update_watermarks(struct intel_crtc *crtc)
dev_priv->display.update_wm(crtc);
}
+void intel_enable_ipc(struct drm_i915_private *dev_priv)
+{
+ u32 val;
+
+ val = I915_READ(DISP_ARB_CTL2);
+
+ if (dev_priv->ipc_enabled)
+ val |= DISP_IPC_ENABLE;
+ else
+ val &= ~DISP_IPC_ENABLE;
+
+ I915_WRITE(DISP_ARB_CTL2, val);
+}
+
+void intel_init_ipc(struct drm_i915_private *dev_priv)
+{
+ dev_priv->ipc_enabled = false;
+ if (!HAS_IPC(dev_priv))
+ return;
+
+ dev_priv->ipc_enabled = true;
+ intel_enable_ipc(dev_priv);
+}
+
/*
* Lock protecting IPS related data structures
*/
--
2.13.0
___
Inte
[Intel-gfx] [PATCH 8/8] drm/i915/skl+: debugfs entry to control IPC
From: "Kumar, Mahesh"
This patch creates an entry in debugfs to check the status of IPC.
This can also be used to enable/disable IPC in supported platforms.
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/i915_debugfs.c | 73 -
1 file changed, 72 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2ef75c1a6119..368f64de0fdc 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3592,6 +3592,76 @@ static int i915_wa_registers(struct seq_file *m, void
*unused)
return 0;
}
+static int i915_ipc_status_show(struct seq_file *m, void *data)
+{
+ struct drm_i915_private *dev_priv = m->private;
+
+ seq_printf(m, "Isochronous Priority Control: %s\n",
+ enableddisabled(dev_priv->ipc_enabled));
+ return 0;
+}
+
+static int i915_ipc_status_open(struct inode *inode, struct file *file)
+{
+ struct drm_i915_private *dev_priv = inode->i_private;
+
+ if (HAS_IPC(dev_priv))
+ return -ENODEV;
+
+ return single_open(file, i915_ipc_status_show, dev_priv);
+}
+
+static ssize_t i915_ipc_status_write(struct file *file, const char __user
*ubuf,
+size_t len, loff_t *offp)
+{
+ struct seq_file *m = file->private_data;
+ struct drm_i915_private *dev_priv = m->private;
+ char *newline;
+ char tmp[16];
+ bool enable;
+
+ if (HAS_IPC(dev_priv))
+ return -ENODEV;
+
+ if (len >= sizeof(tmp))
+ return -EINVAL;
+
+ if (copy_from_user(tmp, ubuf, len))
+ return -EFAULT;
+
+ tmp[len] = '\0';
+
+ /* Strip newline, if any */
+ newline = strchr(tmp, '\n');
+ if (newline)
+ *newline = '\0';
+
+ if (strcmp(tmp, "0") == 0 || strcmp(tmp, "disable") == 0 ||
+ strcmp(tmp, "off") == 0 || strcmp(tmp, "dis") == 0)
+ enable = false;
+ else if (strcmp(tmp, "1") == 0 || strcmp(tmp, "enable") == 0 ||
+ strcmp(tmp, "on") == 0 || strcmp(tmp, "en") == 0)
+ enable = true;
+ else
+ return -EINVAL;
+
+ intel_runtime_pm_get(dev_priv);
+ dev_priv->ipc_enabled = enable;
+ intel_enable_ipc(dev_priv);
+ intel_runtime_pm_put(dev_priv);
+
+ return len;
+}
+
+static const struct file_operations i915_ipc_status_fops = {
+ .owner = THIS_MODULE,
+ .open = i915_ipc_status_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+ .write = i915_ipc_status_write
+};
+
static int i915_ddb_info(struct seq_file *m, void *unused)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -4929,7 +4999,8 @@ static const struct i915_debugfs_files {
{"i915_dp_test_type", &i915_displayport_test_type_fops},
{"i915_dp_test_active", &i915_displayport_test_active_fops},
{"i915_guc_log_control", &i915_guc_log_control_fops},
- {"i915_hpd_storm_ctl", &i915_hpd_storm_ctl_fops}
+ {"i915_hpd_storm_ctl", &i915_hpd_storm_ctl_fops},
+ {"i915_ipc_status", &i915_ipc_status_fops}
};
int i915_debugfs_register(struct drm_i915_private *dev_priv)
--
2.13.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/8] drm/i915/glk: IPC linetime watermark workaround for GLK
From: "Kumar, Mahesh" IF IPC is enabled LINETIME_WM value should be half of calculated value line time = ROUNDDOWN(1/2 * Calculated Line Time) Earlier code was rounding-up the value, But updated Bspec says we should take the ROUNDDOWN. This patch corrects that as well. Signed-off-by: Mahesh Kumar --- drivers/gpu/drm/i915/intel_pm.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 9a2ed1b734d5..dac0fcf8b54e 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4571,9 +4571,10 @@ skl_compute_linetime_wm(struct intel_crtc_state *cstate) linetime_wm = fixed16_to_u32_round_up(mul_u32_fixed16(8, linetime_us)); - /* Display WA #1135: bxt. */ - if (IS_BROXTON(dev_priv) && dev_priv->ipc_enabled) - linetime_wm = DIV_ROUND_UP(linetime_wm, 2); + /* Display WA #1135: bxt:ALL GLK:ALL */ + if ((IS_BROXTON(dev_priv) || IS_GEMINILAKE(dev_priv)) && + dev_priv->ipc_enabled) + linetime_wm /= 2; return linetime_wm; } -- 2.13.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/8] drm/i915/cnl: Extend WM workaround with IPC for CNL
From: "Kumar, Mahesh" CNL:A & CNL:B have same workaround as KBL to increase wm level latency by 4us if IPC is enabled. Signed-off-by: Mahesh Kumar --- drivers/gpu/drm/i915/intel_pm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index dac0fcf8b54e..f2794d29f217 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4447,7 +4447,8 @@ static int skl_compute_plane_wm(const struct drm_i915_private *dev_priv, } /* Display WA #1141: kbl,cfl */ - if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv)) && + if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) || + IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_B0)) && dev_priv->ipc_enabled) latency += 4; -- 2.13.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/8] drm/i915/gen9+: Add has_ipc flag in device info structure
From: "Kumar, Mahesh"
New Isochronous Priority Control (IPC) capability is introduced in newer
GEN platforms. This patch adds a device info flag to indicate if platform
supports IPC. Patch also sets this flag in supported platforms.
Signed-off-by: Mahesh Kumar
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 5 -
drivers/gpu/drm/i915/i915_pci.c | 4
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 62ba18d6717f..47745e3de841 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -784,7 +784,8 @@ struct intel_csr {
func(cursor_needs_physical); \
func(hws_needs_physical); \
func(overlay_needs_physical); \
- func(supports_tv);
+ func(supports_tv); \
+ func(has_ipc);
struct sseu_dev_info {
u8 slice_mask;
@@ -3011,6 +3012,8 @@ intel_info(const struct drm_i915_private *dev_priv)
#define HAS_RUNTIME_PM(dev_priv) ((dev_priv)->info.has_runtime_pm)
#define HAS_64BIT_RELOC(dev_priv) ((dev_priv)->info.has_64bit_reloc)
+#define HAS_IPC(dev_priv) ((dev_priv)->info.has_ipc)
+
/*
* For now, anything with a GuC requires uCode loading, and then supports
* command submission once loaded. But these are logically independent
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index a1e6b696bcfa..0dbdfe0f32a5 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -390,6 +390,7 @@ static const struct intel_device_info
intel_skylake_gt3_info = {
.has_full_ppgtt = 1, \
.has_full_48bit_ppgtt = 1, \
.has_reset_engine = 1, \
+ .has_ipc = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
IVB_CURSOR_OFFSETS, \
BDW_COLORS
@@ -413,6 +414,7 @@ static const struct intel_device_info intel_geminilake_info
= {
.platform = INTEL_KABYLAKE, \
.has_csr = 1, \
.has_guc = 1, \
+ .has_ipc = 1, \
.ddb_size = 896
static const struct intel_device_info intel_kabylake_info = {
@@ -431,6 +433,7 @@ static const struct intel_device_info
intel_kabylake_gt3_info = {
.platform = INTEL_COFFEELAKE, \
.has_csr = 1, \
.has_guc = 1, \
+ .has_ipc = 1, \
.ddb_size = 896
static const struct intel_device_info intel_coffeelake_info = {
@@ -449,6 +452,7 @@ static const struct intel_device_info intel_cannonlake_info
= {
.gen = 10,
.ddb_size = 1024,
.has_csr = 1,
+ .has_ipc = 1,
.color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
};
--
2.13.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/8] drm/i915/skl+: Optimize WM calculation
From: "Kumar, Mahesh"
Plane configuration parameters doesn't change for each WM-level
calculation. Currently we compute same parameters 8 times for each
wm-level.
This patch optimizes it by calculating these parameters in beginning
& reuse during each level-wm calculation.
Signed-off-by: Mahesh Kumar
Acked-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_drv.h | 13 +++
drivers/gpu/drm/i915/intel_pm.c | 179 ++--
2 files changed, 111 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 96edced67e10..62ba18d6717f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1790,6 +1790,19 @@ struct skl_wm_level {
uint8_t plane_res_l;
};
+/* Stores plane specific WM parameters */
+struct skl_wm_params{
+ bool x_tiled, y_tiled;
+ uint32_t width;
+ uint8_t cpp;
+ uint32_t plane_pixel_rate;
+ uint32_t y_min_scanlines;
+ uint32_t plane_bytes_per_line;
+ uint_fixed_16_16_t plane_blocks_per_line;
+ uint_fixed_16_16_t y_tile_minimum;
+ uint32_t linetime_us;
+};
+
/*
* This struct helps tracking the state needed for runtime PM, which puts the
* device in PCI D3 state. Notice that when this happens, nothing on the
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ee2a349cfe68..b2bd65847d9b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4341,128 +4341,135 @@ skl_adjusted_plane_pixel_rate(const struct
intel_crtc_state *cstate,
downscale_amount);
}
-static int skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
- struct intel_crtc_state *cstate,
- const struct intel_plane_state *intel_pstate,
- uint16_t ddb_allocation,
- int level,
- uint16_t *out_blocks, /* out */
- uint8_t *out_lines, /* out */
- bool *enabled /* out */)
+static int
+skl_compute_plane_wm_params(const struct drm_i915_private *dev_priv,
+ struct intel_crtc_state *cstate,
+ const struct intel_plane_state *intel_pstate,
+ struct skl_wm_params *wp)
{
struct intel_plane *plane = to_intel_plane(intel_pstate->base.plane);
const struct drm_plane_state *pstate = &intel_pstate->base;
const struct drm_framebuffer *fb = pstate->fb;
- uint32_t latency = dev_priv->wm.skl_latency[level];
- uint_fixed_16_16_t method1, method2;
- uint_fixed_16_16_t plane_blocks_per_line;
- uint_fixed_16_16_t selected_result;
uint32_t interm_pbpl;
- uint32_t plane_bytes_per_line;
- uint32_t res_blocks, res_lines;
- uint8_t cpp;
- uint32_t width = 0;
- uint32_t plane_pixel_rate;
- uint_fixed_16_16_t y_tile_minimum;
- uint32_t y_min_scanlines;
struct intel_atomic_state *state =
to_intel_atomic_state(cstate->base.state);
bool apply_memory_bw_wa = skl_needs_memory_bw_wa(state);
- bool y_tiled, x_tiled;
- if (latency == 0 ||
- !intel_wm_plane_visible(cstate, intel_pstate)) {
- *enabled = false;
+ if (!intel_wm_plane_visible(cstate, intel_pstate))
return 0;
- }
- y_tiled = fb->modifier == I915_FORMAT_MOD_Y_TILED ||
- fb->modifier == I915_FORMAT_MOD_Yf_TILED;
- x_tiled = fb->modifier == I915_FORMAT_MOD_X_TILED;
-
- /* Display WA #1141: kbl,cfl */
- if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv)) &&
- dev_priv->ipc_enabled)
- latency += 4;
-
- if (apply_memory_bw_wa && x_tiled)
- latency += 15;
+ wp->y_tiled = fb->modifier == I915_FORMAT_MOD_Y_TILED ||
+ fb->modifier == I915_FORMAT_MOD_Yf_TILED;
+ wp->x_tiled = fb->modifier == I915_FORMAT_MOD_X_TILED;
if (plane->id == PLANE_CURSOR) {
- width = intel_pstate->base.crtc_w;
+ wp->width = intel_pstate->base.crtc_w;
} else {
/*
* Src coordinates are already rotated by 270 degrees for
* the 90/270 degree plane rotation cases (to match the
* GTT mapping), hence no need to account for rotation here.
*/
- width = drm_rect_width(&intel_pstate->base.src) >> 16;
+ wp->width = drm_rect_width(&intel_pstate->base.src) >> 16;
}
- cpp = (fb->format->format == DRM_FORMAT_NV12) ? fb->format->cpp[1] :
- fb->format->cpp[0];
- plane_pixel_rate = skl_adjusted_plane_pixel_rate(cstate, intel_pstate);
+ w
[Intel-gfx] [PATCH 3/8] drm/i915/gen10: Calculate and enable transition WM
From: "Kumar, Mahesh"
GEN > 9 require transition WM to be programmed if IPC is enabled.
This patch calculates & enable transition WM for supported platforms.
If transition WM is enabled, Plane read requests are sent at high
priority until filling above the transition watermark, then the
requests are sent at lower priority until dropping below the level-0 WM.
The lower priority requests allow other memory clients to have better
memory access.
transition minimum is the minimum amount needed for trans_wm to work to
ensure the demote does not happen before enough data has been read to
meet the level 0 watermark requirements.
transition amount is configurable value. Higher values will
tend to cause longer periods of high priority reads followed by longer
periods of lower priority reads. Tuning to lower values will tend to
cause shorter periods of high and lower priority reads.
Keeping transition amount to 10 in this patch, as suggested by HW team.
Signed-off-by: Mahesh Kumar
Acked-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_pm.c | 51 +++--
1 file changed, 49 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b2bd65847d9b..9a2ed1b734d5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4579,12 +4579,55 @@ skl_compute_linetime_wm(struct intel_crtc_state *cstate)
}
static void skl_compute_transition_wm(struct intel_crtc_state *cstate,
+ struct skl_wm_params *wp,
+ struct skl_wm_level *wm_l0,
+ uint16_t ddb_allocation,
struct skl_wm_level *trans_wm /* out */)
{
+ struct drm_device *dev = cstate->base.crtc->dev;
+ const struct drm_i915_private *dev_priv = to_i915(dev);
+ uint16_t trans_min, trans_y_tile_min;
+ uint16_t trans_amount = 10; /* This is configurable amount */
+ uint16_t trans_offset_b, res_blocks;
+
if (!cstate->base.active)
+ goto exit;
+
+ /* Transition WM are not recommended by HW team for GEN9 */
+ if (INTEL_GEN(dev_priv) <= 9)
+ goto exit;
+
+ /* Transition WM don't make any sense if ipc is disabled */
+ if (!dev_priv->ipc_enabled)
+ goto exit;
+
+ if (INTEL_GEN(dev_priv) >= 10)
+ trans_min = 4;
+
+ trans_offset_b = trans_min + trans_amount;
+ trans_y_tile_min = (uint16_t) mul_round_up_u32_fixed16(2,
+ wp->y_tile_minimum);
+
+ if (wp->y_tiled) {
+ res_blocks = max(wm_l0->plane_res_b, trans_y_tile_min) +
+ trans_offset_b;
+ } else {
+ res_blocks = wm_l0->plane_res_b + trans_offset_b;
+ }
+
+ res_blocks += 1;
+
+ /* WA BUG:1938466 add one block for non y-tile planes */
+ if (!wp->y_tiled && IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_A0))
+ res_blocks += 1;
+
+ if (res_blocks < ddb_allocation) {
+ trans_wm->plane_res_b = res_blocks;
+ trans_wm->plane_en = true;
return;
+ }
- /* Until we know more, just disable transition WMs */
+exit:
trans_wm->plane_en = false;
}
@@ -4611,8 +4654,11 @@ static int skl_build_pipe_wm(struct intel_crtc_state
*cstate,
to_intel_plane_state(pstate);
enum plane_id plane_id = to_intel_plane(plane)->id;
struct skl_wm_params wm_params;
+ enum pipe pipe = to_intel_crtc(cstate->base.crtc)->pipe;
+ uint16_t ddb_blocks;
wm = &pipe_wm->planes[plane_id];
+ ddb_blocks = skl_ddb_entry_size(&ddb->plane[pipe][plane_id]);
memset(&wm_params, 0, sizeof(struct skl_wm_params));
ret = skl_compute_plane_wm_params(dev_priv, cstate,
@@ -4624,7 +4670,8 @@ static int skl_build_pipe_wm(struct intel_crtc_state
*cstate,
intel_pstate, &wm_params, wm);
if (ret)
return ret;
- skl_compute_transition_wm(cstate, &wm->trans_wm);
+ skl_compute_transition_wm(cstate, &wm_params, &wm->wm[0],
+ ddb_blocks, &wm->trans_wm);
}
pipe_wm->linetime = skl_compute_linetime_wm(cstate);
--
2.13.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
