[Intel-gfx] ✓ Fi.CI.BAT: success for TGL TC enabling v2-CI (rev2)
== Series Details ==
Series: TGL TC enabling v2-CI (rev2)
URL : https://patchwork.freedesktop.org/series/67022/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6932 -> Patchwork_14486
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14486/
Known issues
Here are the changes found in Patchwork_14486 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_param@basic:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +2
similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6932/fi-icl-u3/igt@gem_ctx_pa...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14486/fi-icl-u3/igt@gem_ctx_pa...@basic.html
Possible fixes
* igt@gem_exec_suspend@basic:
- {fi-icl-u4}:[FAIL][3] ([fdo#111699]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6932/fi-icl-u4/igt@gem_exec_susp...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14486/fi-icl-u4/igt@gem_exec_susp...@basic.html
* igt@gem_mmap_gtt@basic-small-bo:
- fi-icl-u3: [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6932/fi-icl-u3/igt@gem_mmap_...@basic-small-bo.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14486/fi-icl-u3/igt@gem_mmap_...@basic-small-bo.html
* igt@i915_module_load@reload:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724] / [fdo#111214]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6932/fi-icl-u3/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14486/fi-icl-u3/igt@i915_module_l...@reload.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][9] ([fdo#109483]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6932/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14486/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][11] ([fdo#111407]) -> [FAIL][12] ([fdo#111045]
/ [fdo#111096])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6932/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14486/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#105763]: https://bugs.freedesktop.org/show_bug.cgi?id=105763
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111699]: https://bugs.freedesktop.org/show_bug.cgi?id=111699
Participating hosts (54 -> 48)
--
Additional (1): fi-tgl-u2
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6932 -> Patchwork_14486
CI-20190529: 20190529
CI_DRM_6932: f539beb004edb5b82925c10324f7cf4c5b4dbcc5 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5195: ea29372bb4e261a0a8da371a1f434131750f18e0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14486: c58daa59cae523d8718750d0654e95c0c804ea5d @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
c58daa59cae5 drm/i915/tgl: Check the UC health of tc controllers after power on
4afd3248a8aa drm/i915/icl: Unify disable and enable phy clock gating functions
0c886504b50c drm/i915/tgl: Add dkl phy registers
3ef7487b0704 drm/i915/tgl/pll: Set update_active_dpll
fce11fcea1ff drm/i915/tgl: Finish modular FIA support on registers
dfbb456a4492 drm/i915/tgl: Add missing ddi clock select during DP init sequence
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14486/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 08/13] drm/i915/tgl: Add dkl phy programming sequences
On Fri, 2019-09-20 at 14:44 -0700, Lucas De Marchi wrote:
> On Wed, Sep 18, 2019 at 5:07 PM José Roberto de Souza
> wrote:
> > From: Clinton A Taylor
> >
> > Added DKL Phy sequences and helpers functions to program voltage
> > swing, clock gating and dp mode.
> >
> > It is not written in DP enabling sequence but "PHY Clockgating
> > programming" states that clock gating should be enabled after the
> > link training but doing so causes all the following trainings to
> > fail
> > so not enabling it for.
> >
> > v2:
> > Setting the right HIP_INDEX_REG bits (José)
> >
> > BSpec: 49292
> > BSpec: 49190
> >
> > Signed-off-by: José Roberto de Souza
> > Signed-off-by: Clinton A Taylor
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 246
> > +--
> > 1 file changed, 234 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 81792a04e0aa..fd271118d1f5 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -586,6 +586,25 @@ static const struct icl_mg_phy_ddi_buf_trans
> > icl_mg_phy_ddi_translations[] = {
> > { 0x0, 0x00, 0x00 },/* 3 0 */
> > };
> >
> > +struct tgl_dkl_phy_ddi_buf_trans {
> > + u32 dkl_vswing_control;
> > + u32 dkl_preshoot_control;
> > + u32 dkl_de_emphasis_control;
> > +};
> > +
> > +static const struct tgl_dkl_phy_ddi_buf_trans
> > tgl_dkl_phy_ddi_translations[] = {
>
> comment here like in the icl version with the meaning of the comments
> would be good
Okay
>
> > + { 0x7, 0x0, 0x00 }, /* 0 0 400mV 0 dB */
> > + { 0x5, 0x0, 0x03 }, /* 0 1 400mV 3.5 dB */
> > + { 0x2, 0x0, 0x0b }, /* 0 2 400mV 6 dB */
> > + { 0x0, 0x0, 0x19 }, /* 0 3 400mV 9.5 dB */
> > + { 0x5, 0x0, 0x00 }, /* 1 0 600mV 0 dB */
>
> pre-emphasis here is 1. And the others below are wrong, too.
I thought that too but based on the index_to_dp_signal_levels table and
the values on "Pre-emphasis dB" column is mostly likely that BSpec has
a typo, issue was already open for that on BSpec.
>
> > + { 0x2, 0x0, 0x03 }, /* 1 1 600mV 3.5 dB */
> > + { 0x0, 0x0, 0x14 }, /* 1 2 600mV 6 dB */
> > + { 0x2, 0x0, 0x00 }, /* 2 0 800mV 0 dB */
> > + { 0x0, 0x0, 0x0B }, /* 2 1 800mV 3.5 dB */
> > + { 0x0, 0x0, 0x00 }, /* 3 0 1200mV 0 dBHDMI
> > Default */
> > +};
> > +
> > static const struct ddi_buf_trans *
> > bdw_get_buf_trans_edp(struct drm_i915_private *dev_priv, int
> > *n_entries)
> > {
> > @@ -873,11 +892,15 @@ static int intel_ddi_hdmi_level(struct
> > drm_i915_private *dev_priv, enum port por
> > level = dev_priv->vbt.ddi_port_info[port].hdmi_level_shift;
> >
> > if (INTEL_GEN(dev_priv) >= 11) {
> > - if (intel_phy_is_combo(dev_priv, phy))
> > + if (intel_phy_is_combo(dev_priv, phy)) {
> > icl_get_combo_buf_trans(dev_priv,
> > INTEL_OUTPUT_HDMI,
> > 0, _entries);
> > - else
> > - n_entries =
> > ARRAY_SIZE(icl_mg_phy_ddi_translations);
> > + } else {
> > + if (INTEL_GEN(dev_priv) >= 12)
> > + n_entries =
> > ARRAY_SIZE(tgl_dkl_phy_ddi_translations);
> > + else
> > + n_entries =
> > ARRAY_SIZE(icl_mg_phy_ddi_translations);
> > + }
> > default_entry = n_entries - 1;
>
> I think plain ladder would be better. Just add one for
> INTEL_GEN(dev_priv) >= 12)
Okay
>
> > } else if (IS_CANNONLAKE(dev_priv)) {
> > cnl_get_buf_trans_hdmi(dev_priv, _entries);
> > @@ -2308,11 +2331,15 @@ u8 intel_ddi_dp_voltage_max(struct
> > intel_encoder *encoder)
> > int n_entries;
> >
> > if (INTEL_GEN(dev_priv) >= 11) {
> > - if (intel_phy_is_combo(dev_priv, phy))
> > + if (intel_phy_is_combo(dev_priv, phy)) {
> > icl_get_combo_buf_trans(dev_priv, encoder-
> > >type,
> > intel_dp-
> > >link_rate, _entries);
> > - else
> > - n_entries =
> > ARRAY_SIZE(icl_mg_phy_ddi_translations);
> > + } else {
> > + if (INTEL_GEN(dev_priv) >= 12)
> > + n_entries =
> > ARRAY_SIZE(tgl_dkl_phy_ddi_translations);
> > + else
> > + n_entries =
> > ARRAY_SIZE(icl_mg_phy_ddi_translations);
> > + }
>
> ditto
Okay
>
> > } else if (IS_CANNONLAKE(dev_priv)) {
> > if (encoder->type == INTEL_OUTPUT_EDP)
> >
[Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Check for scheduling bonded-pairs on the same engine
The expectation for bonded submission is that they are run concurrently,
in parallel on multiple engines. However, given a lack of constraints in
the scheduler's selection combined with timeslicing could mean that the
bonded requests could be run in opposite order on the same engine. With
just the right pair of requests, this can cause a GPU hang (or at least
trigger hangchecker), best (worst) case would be execution running
several times slower than ideal.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_exec_balancer.c | 151 +
1 file changed, 151 insertions(+)
diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
index 407dc0eca..e4fe75747 100644
--- a/tests/i915/gem_exec_balancer.c
+++ b/tests/i915/gem_exec_balancer.c
@@ -30,6 +30,15 @@
IGT_TEST_DESCRIPTION("Exercise in-kernel load-balancing");
+#define MI_SEMAPHORE_WAIT (0x1c << 23)
+#define MI_SEMAPHORE_POLL (1 << 15)
+#define MI_SEMAPHORE_SAD_GT_SDD (0 << 12)
+#define MI_SEMAPHORE_SAD_GTE_SDD (1 << 12)
+#define MI_SEMAPHORE_SAD_LT_SDD (2 << 12)
+#define MI_SEMAPHORE_SAD_LTE_SDD (3 << 12)
+#define MI_SEMAPHORE_SAD_EQ_SDD (4 << 12)
+#define MI_SEMAPHORE_SAD_NEQ_SDD (5 << 12)
+
#define INSTANCE_COUNT (1 << I915_PMU_SAMPLE_INSTANCE_BITS)
static size_t sizeof_load_balance(int count)
@@ -694,6 +703,145 @@ static void bonded(int i915, unsigned int flags)
gem_context_destroy(i915, master);
}
+static unsigned int offset_in_page(void *addr)
+{
+ return (uintptr_t)addr & 4095;
+}
+
+static uint32_t create_semaphore_to_spinner(int i915, igt_spin_t *spin)
+{
+ uint32_t *cs, *map;
+ uint32_t handle;
+
+ handle = gem_create(i915, 4096);
+ cs = map = gem_mmap__cpu(i915, handle, 0, 4096, PROT_WRITE);
+
+ /* Wait until the spinner is running */
+ *cs++ = MI_SEMAPHORE_WAIT |
+ MI_SEMAPHORE_POLL |
+ MI_SEMAPHORE_SAD_NEQ_SDD |
+ (4 - 2);
+ *cs++ = 0;
+ *cs++ = spin->obj[0].offset + 4 * SPIN_POLL_START_IDX;
+ *cs++ = 0;
+
+ /* Then cancel the spinner */
+ *cs++ = MI_STORE_DWORD_IMM;
+ *cs++ = spin->obj[IGT_SPIN_BATCH].offset +
+ offset_in_page(spin->condition);
+ *cs++ = 0;
+ *cs++ = MI_BATCH_BUFFER_END;
+
+ *cs++ = MI_BATCH_BUFFER_END;
+ munmap(map, 4096);
+
+ return handle;
+}
+
+static void bonded_slice(int i915)
+{
+ uint32_t ctx;
+ int *stop;
+
+ igt_require(gem_scheduler_has_semaphores(i915));
+
+ stop = mmap(0, 4096, PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0);
+ igt_assert(stop != MAP_FAILED);
+
+ ctx = gem_context_create(i915);
+
+ for (int class = 0; class < 32; class++) {
+ struct i915_engine_class_instance *siblings;
+ struct drm_i915_gem_exec_object2 obj[3] = {};
+ struct drm_i915_gem_execbuffer2 eb = {};
+ unsigned int count;
+ igt_spin_t *spin;
+
+ siblings = list_engines(i915, 1u << class, );
+ if (!siblings)
+ continue;
+
+ if (count < 2) {
+ free(siblings);
+ continue;
+ }
+
+ /*
+* A: semaphore wait on spinner; cancel spinner
+* B: unpreemptable spinner
+*
+* A waits for running ack from B, if scheduled on the same
+* engine -> hang.
+*
+* C+: background load across engines
+*/
+
+ set_load_balancer(i915, ctx, siblings, count, NULL);
+
+ spin = __igt_spin_new(i915,
+ .ctx = ctx,
+ .flags = (IGT_SPIN_NO_PREEMPTION |
+ IGT_SPIN_POLL_RUN));
+ igt_spin_end(spin); /* we just want its address for later */
+ gem_sync(i915, spin->handle);
+ igt_spin_reset(spin);
+
+ obj[0] = spin->obj[0];
+ obj[1] = spin->obj[1];
+ obj[2].handle = create_semaphore_to_spinner(i915, spin);
+
+ eb.buffers_ptr = to_user_pointer(obj);
+ eb.rsvd1 = ctx;
+
+ *stop = 0;
+ igt_fork(child, count + 1) {
+ igt_list_del(>link);
+
+ ctx = gem_context_clone(i915, ctx,
+ I915_CONTEXT_CLONE_ENGINES, 0);
+
+ while (!READ_ONCE(*stop)) {
+ spin = igt_spin_new(i915,
+ .ctx = ctx,
+ .engine = (1 + rand() %
count),
+ .flags =
[Intel-gfx] ✗ Fi.CI.BAT: failure for TGL TC enabling v2-CI
== Series Details ==
Series: TGL TC enabling v2-CI
URL : https://patchwork.freedesktop.org/series/67022/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6932 -> Patchwork_14485
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14485 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14485, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14485/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14485:
### IGT changes ###
Possible regressions
* igt@gem_exec_suspend@basic-s3:
- fi-kbl-r: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6932/fi-kbl-r/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14485/fi-kbl-r/igt@gem_exec_susp...@basic-s3.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_suspend@basic-s3:
- {fi-cml-s}: [PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6932/fi-cml-s/igt@gem_exec_susp...@basic-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14485/fi-cml-s/igt@gem_exec_susp...@basic-s3.html
* igt@runner@aborted:
- {fi-cml-s}: NOTRUN -> [FAIL][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14485/fi-cml-s/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_14485 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_switch@legacy-render:
- fi-bxt-dsi: [PASS][6] -> [INCOMPLETE][7] ([fdo#103927] /
[fdo#111381])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6932/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14485/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
* igt@i915_module_load@reload-no-display:
- fi-icl-u3: [PASS][8] -> [DMESG-WARN][9] ([fdo#107724]) +2
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6932/fi-icl-u3/igt@i915_module_l...@reload-no-display.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14485/fi-icl-u3/igt@i915_module_l...@reload-no-display.html
* igt@kms_chamelium@dp-edid-read:
- fi-icl-u2: [PASS][10] -> [FAIL][11] ([fdo#109483] / [fdo#109635
])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6932/fi-icl-u2/igt@kms_chamel...@dp-edid-read.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14485/fi-icl-u2/igt@kms_chamel...@dp-edid-read.html
Possible fixes
* igt@gem_exec_suspend@basic:
- {fi-icl-u4}:[FAIL][12] ([fdo#111699]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6932/fi-icl-u4/igt@gem_exec_susp...@basic.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14485/fi-icl-u4/igt@gem_exec_susp...@basic.html
* igt@gem_mmap_gtt@basic-small-bo:
- fi-icl-u3: [DMESG-WARN][14] ([fdo#107724]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6932/fi-icl-u3/igt@gem_mmap_...@basic-small-bo.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14485/fi-icl-u3/igt@gem_mmap_...@basic-small-bo.html
* igt@i915_module_load@reload:
- fi-icl-u3: [DMESG-WARN][16] ([fdo#107724] / [fdo#111214]) ->
[PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6932/fi-icl-u3/igt@i915_module_l...@reload.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14485/fi-icl-u3/igt@i915_module_l...@reload.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][18] ([fdo#109483]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6932/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14485/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][20] ([fdo#111407]) -> [FAIL][21] ([fdo#111045]
/ [fdo#111096])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6932/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14485/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107713]:
Re: [Intel-gfx] [PATCH v2 08/13] drm/i915/tgl: Add dkl phy programming sequences
On Wed, Sep 18, 2019 at 5:07 PM José Roberto de Souza
wrote:
>
> From: Clinton A Taylor
>
> Added DKL Phy sequences and helpers functions to program voltage
> swing, clock gating and dp mode.
>
> It is not written in DP enabling sequence but "PHY Clockgating
> programming" states that clock gating should be enabled after the
> link training but doing so causes all the following trainings to fail
> so not enabling it for.
>
> v2:
> Setting the right HIP_INDEX_REG bits (José)
>
> BSpec: 49292
> BSpec: 49190
>
> Signed-off-by: José Roberto de Souza
> Signed-off-by: Clinton A Taylor
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 246 +--
> 1 file changed, 234 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 81792a04e0aa..fd271118d1f5 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -586,6 +586,25 @@ static const struct icl_mg_phy_ddi_buf_trans
> icl_mg_phy_ddi_translations[] = {
> { 0x0, 0x00, 0x00 },/* 3 0 */
> };
>
> +struct tgl_dkl_phy_ddi_buf_trans {
> + u32 dkl_vswing_control;
> + u32 dkl_preshoot_control;
> + u32 dkl_de_emphasis_control;
> +};
> +
> +static const struct tgl_dkl_phy_ddi_buf_trans tgl_dkl_phy_ddi_translations[]
> = {
comment here like in the icl version with the meaning of the comments
would be good
> + { 0x7, 0x0, 0x00 }, /* 0 0 400mV 0 dB */
> + { 0x5, 0x0, 0x03 }, /* 0 1 400mV 3.5 dB */
> + { 0x2, 0x0, 0x0b }, /* 0 2 400mV 6 dB */
> + { 0x0, 0x0, 0x19 }, /* 0 3 400mV 9.5 dB */
> + { 0x5, 0x0, 0x00 }, /* 1 0 600mV 0 dB */
pre-emphasis here is 1. And the others below are wrong, too.
> + { 0x2, 0x0, 0x03 }, /* 1 1 600mV 3.5 dB */
> + { 0x0, 0x0, 0x14 }, /* 1 2 600mV 6 dB */
> + { 0x2, 0x0, 0x00 }, /* 2 0 800mV 0 dB */
> + { 0x0, 0x0, 0x0B }, /* 2 1 800mV 3.5 dB */
> + { 0x0, 0x0, 0x00 }, /* 3 0 1200mV 0 dBHDMI Default */
> +};
> +
> static const struct ddi_buf_trans *
> bdw_get_buf_trans_edp(struct drm_i915_private *dev_priv, int *n_entries)
> {
> @@ -873,11 +892,15 @@ static int intel_ddi_hdmi_level(struct drm_i915_private
> *dev_priv, enum port por
> level = dev_priv->vbt.ddi_port_info[port].hdmi_level_shift;
>
> if (INTEL_GEN(dev_priv) >= 11) {
> - if (intel_phy_is_combo(dev_priv, phy))
> + if (intel_phy_is_combo(dev_priv, phy)) {
> icl_get_combo_buf_trans(dev_priv, INTEL_OUTPUT_HDMI,
> 0, _entries);
> - else
> - n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations);
> + } else {
> + if (INTEL_GEN(dev_priv) >= 12)
> + n_entries =
> ARRAY_SIZE(tgl_dkl_phy_ddi_translations);
> + else
> + n_entries =
> ARRAY_SIZE(icl_mg_phy_ddi_translations);
> + }
> default_entry = n_entries - 1;
I think plain ladder would be better. Just add one for
INTEL_GEN(dev_priv) >= 12)
> } else if (IS_CANNONLAKE(dev_priv)) {
> cnl_get_buf_trans_hdmi(dev_priv, _entries);
> @@ -2308,11 +2331,15 @@ u8 intel_ddi_dp_voltage_max(struct intel_encoder
> *encoder)
> int n_entries;
>
> if (INTEL_GEN(dev_priv) >= 11) {
> - if (intel_phy_is_combo(dev_priv, phy))
> + if (intel_phy_is_combo(dev_priv, phy)) {
> icl_get_combo_buf_trans(dev_priv, encoder->type,
> intel_dp->link_rate,
> _entries);
> - else
> - n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations);
> + } else {
> + if (INTEL_GEN(dev_priv) >= 12)
> + n_entries =
> ARRAY_SIZE(tgl_dkl_phy_ddi_translations);
> + else
> + n_entries =
> ARRAY_SIZE(icl_mg_phy_ddi_translations);
> + }
ditto
> } else if (IS_CANNONLAKE(dev_priv)) {
> if (encoder->type == INTEL_OUTPUT_EDP)
> cnl_get_buf_trans_edp(dev_priv, _entries);
> @@ -2749,6 +2776,66 @@ static void icl_ddi_vswing_sequence(struct
> intel_encoder *encoder,
> icl_mg_phy_ddi_vswing_sequence(encoder, link_clock, level);
> }
>
> +static void
> +tgl_dkl_phy_ddi_vswing_sequence(struct intel_encoder *encoder, int
> link_clock,
> + u32 level)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + enum tc_port tc_port = intel_port_to_tc(dev_priv, encoder->port);
> + const struct
Re: [Intel-gfx] [PATCH] drm/i915: Allow set context SSEU on platforms after gen 11
On Fri, 2019-09-20 at 22:29 +0100, Chris Wilson wrote: > Quoting Summers, Stuart (2019-09-20 22:09:46) > > On Thu, 2019-09-19 at 08:00 +0100, Tvrtko Ursulin wrote: > > > On 18/09/2019 18:31, Stuart Summers wrote: > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110559 > > > > > > Unless there was some discussion I missed we can't just turn it > > > on > > > to > > > work around a SKIP in IGT. Feature was deliberately limited to > > > Icelake > > > and even there just to a sub-set of possible configurations. > > > > No conversation was missed, or at least none I was a part of. Is > > there > > a reason we don't allow this on future platforms? > > > > We do claim powergate support on TGL, so I assumed it would be good > > to > > take this path on that platform. Maybe I'm misunderstanding > > something > > here though. > > The current interface is purely to work around a silicon issue on > icl. > It was not developed into a fully reconfigurable sseu interface > mostly > due to a lack of demonstrable need and a lack of appreciation of the > tradeoffs between different system users (along with the claim that > this > is all meant to be handled by instructions in the command stream...). > Another team did try to autoadjust sseu but also did not produce the > rationale nor attempt to integrate with the existing code. Ok that makes sense then and thanks for the explanations here. Please consider my patch dropped :) -Stuart > -Chris smime.p7s Description: S/MIME cryptographic signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Allow set context SSEU on platforms after gen 11
Quoting Summers, Stuart (2019-09-20 22:09:46) > On Thu, 2019-09-19 at 08:00 +0100, Tvrtko Ursulin wrote: > > On 18/09/2019 18:31, Stuart Summers wrote: > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110559 > > > > Unless there was some discussion I missed we can't just turn it on > > to > > work around a SKIP in IGT. Feature was deliberately limited to > > Icelake > > and even there just to a sub-set of possible configurations. > > No conversation was missed, or at least none I was a part of. Is there > a reason we don't allow this on future platforms? > > We do claim powergate support on TGL, so I assumed it would be good to > take this path on that platform. Maybe I'm misunderstanding something > here though. The current interface is purely to work around a silicon issue on icl. It was not developed into a fully reconfigurable sseu interface mostly due to a lack of demonstrable need and a lack of appreciation of the tradeoffs between different system users (along with the claim that this is all meant to be handled by instructions in the command stream...). Another team did try to autoadjust sseu but also did not produce the rationale nor attempt to integrate with the existing code. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/selftests: Verify the LRC register layout between init and HW
Quoting Patchwork (2019-09-20 22:08:48) > == Series Details == > > Series: series starting with [1/2] drm/i915/selftests: Verify the LRC > register layout between init and HW > URL : https://patchwork.freedesktop.org/series/67018/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_6932 -> Patchwork_14484 > > > Summary > --- > > **SUCCESS** > > No regressions found. But still tgl is dead. False hope. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Allow set context SSEU on platforms after gen 11
On Wed, 2019-09-18 at 13:39 -0700, Daniele Ceraolo Spurio wrote: > > On 9/18/19 10:31 AM, Stuart Summers wrote: > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110559 > > > > What's the planned usage here? TGL HW only supports slice-level > power-gating and with only 1 slice on TGL we don't really have a > choice > of what to program, do we? Well, we do claim powergate support on TGL, so I assumed we'd want to enable this path. Maybe I'm missing something though. Had a similar response to Tvrtko. Thanks, Stuart > > Daniele > > > Cc: Tvrtko Ursulin > > Signed-off-by: Stuart Summers > > --- > > drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c > > b/drivers/gpu/drm/i915/gem/i915_gem_context.c > > index f1c0e5d958f3..39af4c81b29a 100644 > > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c > > @@ -1310,7 +1310,7 @@ static int set_sseu(struct i915_gem_context > > *ctx, > > if (args->size < sizeof(user_sseu)) > > return -EINVAL; > > > > - if (!IS_GEN(i915, 11)) > > + if (INTEL_GEN(i915) < 11) > > return -ENODEV; > > > > if (copy_from_user(_sseu, u64_to_user_ptr(args->value), > > smime.p7s Description: S/MIME cryptographic signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Allow set context SSEU on platforms after gen 11
On Thu, 2019-09-19 at 08:00 +0100, Tvrtko Ursulin wrote: > On 18/09/2019 18:31, Stuart Summers wrote: > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110559 > > Unless there was some discussion I missed we can't just turn it on > to > work around a SKIP in IGT. Feature was deliberately limited to > Icelake > and even there just to a sub-set of possible configurations. No conversation was missed, or at least none I was a part of. Is there a reason we don't allow this on future platforms? We do claim powergate support on TGL, so I assumed it would be good to take this path on that platform. Maybe I'm misunderstanding something here though. Thanks, Stuart > > Regards, > > Tvrtko > > > Cc: Tvrtko Ursulin > > Signed-off-by: Stuart Summers > > --- > > drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c > > b/drivers/gpu/drm/i915/gem/i915_gem_context.c > > index f1c0e5d958f3..39af4c81b29a 100644 > > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c > > @@ -1310,7 +1310,7 @@ static int set_sseu(struct i915_gem_context > > *ctx, > > if (args->size < sizeof(user_sseu)) > > return -EINVAL; > > > > - if (!IS_GEN(i915, 11)) > > + if (INTEL_GEN(i915) < 11) > > return -ENODEV; > > > > if (copy_from_user(_sseu, u64_to_user_ptr(args->value), > > smime.p7s Description: S/MIME cryptographic signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/selftests: Verify the LRC register layout between init and HW
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Verify the LRC register
layout between init and HW
URL : https://patchwork.freedesktop.org/series/67018/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6932 -> Patchwork_14484
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14484/
New tests
-
New tests have been introduced between CI_DRM_6932 and Patchwork_14484:
### New IGT tests (1) ###
* igt@i915_selftest@live_gt_lrc:
- Statuses : 43 pass(s)
- Exec time: [0.41, 2.16] s
Known issues
Here are the changes found in Patchwork_14484 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6932/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14484/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
* igt@gem_flink_basic@basic:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) +2
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6932/fi-icl-u3/igt@gem_flink_ba...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14484/fi-icl-u3/igt@gem_flink_ba...@basic.html
Possible fixes
* igt@gem_mmap_gtt@basic-small-bo:
- fi-icl-u3: [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6932/fi-icl-u3/igt@gem_mmap_...@basic-small-bo.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14484/fi-icl-u3/igt@gem_mmap_...@basic-small-bo.html
* igt@i915_module_load@reload:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724] / [fdo#111214]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6932/fi-icl-u3/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14484/fi-icl-u3/igt@i915_module_l...@reload.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][9] ([fdo#109483]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6932/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14484/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
[fdo#111593]: https://bugs.freedesktop.org/show_bug.cgi?id=111593
Participating hosts (54 -> 46)
--
Additional (1): fi-tgl-u2
Missing(9): fi-icl-u4 fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-icl-y fi-byt-clapper fi-bdw-samus fi-kbl-r
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6932 -> Patchwork_14484
CI-20190529: 20190529
CI_DRM_6932: f539beb004edb5b82925c10324f7cf4c5b4dbcc5 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5195: ea29372bb4e261a0a8da371a1f434131750f18e0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14484: 84cf867421912f914e55ef039cc57741067f061f @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
84cf86742191 drm/i915/tgl: Swap engines for rc6/powersaving
2b9117e29756 drm/i915/selftests: Verify the LRC register layout between init
and HW
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14484/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 07/13] drm/i915/tgl: TC helper function to return pin mapping
On Fri, Sep 20, 2019 at 1:54 PM Lucas De Marchi
wrote:
>
> On Wed, Sep 18, 2019 at 5:07 PM José Roberto de Souza
> wrote:
> >
> > From: Clinton A Taylor
> >
> > Add a helper function to return pin map for use during dkl phy
> > DP_MODE settings, PORT_TX_DFLEXPA1 exist on ICL but we don't need it.
> >
> > The user of this function will come in future TC patches.
> >
> > Signed-off-by: Clinton A Taylor
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_tc.c | 15 +++
> > drivers/gpu/drm/i915/display/intel_tc.h | 1 +
> > drivers/gpu/drm/i915/i915_reg.h | 5 +
> > 3 files changed, 21 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> > b/drivers/gpu/drm/i915/display/intel_tc.c
> > index 20fbb084830e..5d9577588e91 100644
> > --- a/drivers/gpu/drm/i915/display/intel_tc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> > @@ -70,6 +70,21 @@ u32 intel_tc_port_get_lane_mask(struct
> > intel_digital_port *dig_port)
> >DP_LANE_ASSIGNMENT_SHIFT(dig_port->tc_phy_fia_idx);
> > }
> >
> > +u32 intel_tc_port_get_pin_assignment_mask(struct intel_digital_port
> > *dig_port)
> > +{
> > + struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> > + struct intel_uncore *uncore = >uncore;
> > + u32 pin_mask;
> > +
> > + pin_mask = intel_uncore_read(uncore,
> > +
> > PORT_TX_DFLEXPA1(dig_port->tc_phy_fia));
> > +
> > + WARN_ON(pin_mask == 0x);
> > +
> > + return (pin_mask &
> > DP_PIN_ASSIGNMENT_MASK(dig_port->tc_phy_fia_idx)) >>
> > + DP_PIN_ASSIGNMENT_SHIFT(dig_port->tc_phy_fia_idx);
>
> AFAICS this is tc_port-based, not tc_phy_fia_idx. tc_phy_fia_idx
> should only ever be used
> together with the HIP_INDEX.
humn... scratch that. That spec is for non-modular FIA. If it's
correct that it applies for all the FIA registers, then this
implementation is correct,
even if it doesn't match the spec.
Reviewed-by: Lucas De Marchi
Lucas De Marchi
>
> Lucas De Marchi
>
> > +}
> > +
> > int intel_tc_port_fia_max_lane_count(struct intel_digital_port *dig_port)
> > {
> > struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> > diff --git a/drivers/gpu/drm/i915/display/intel_tc.h
> > b/drivers/gpu/drm/i915/display/intel_tc.h
> > index 944d84c8cce1..1b8638dd340a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_tc.h
> > +++ b/drivers/gpu/drm/i915/display/intel_tc.h
> > @@ -14,6 +14,7 @@ struct drm_i915_private;
> >
> > bool intel_tc_port_connected(struct intel_digital_port *dig_port);
> > u32 intel_tc_port_get_lane_mask(struct intel_digital_port *dig_port);
> > +u32 intel_tc_port_get_pin_assignment_mask(struct intel_digital_port
> > *dig_port);
> > int intel_tc_port_fia_max_lane_count(struct intel_digital_port *dig_port);
> > void intel_tc_port_set_fia_lane_count(struct intel_digital_port *dig_port,
> > int required_lanes);
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 32f98d0e0e9c..91a79e809dd2 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -11845,4 +11845,9 @@ enum skl_power_gate {
> > #define PORT_TX_DFLEXDPCSSS(fia) _MMIO_FIA((fia), 0x00894)
> > #define DP_PHY_MODE_STATUS_NOT_SAFE(idx) (1 << (idx))
> >
> > +#define PORT_TX_DFLEXPA1(fia) _MMIO_FIA((fia), 0x00880)
> > +#define DP_PIN_ASSIGNMENT_SHIFT(idx) ((idx) * 4)
> > +#define DP_PIN_ASSIGNMENT_MASK(idx) (0xf << ((idx) * 4))
> > +#define DP_PIN_ASSIGNMENT(idx, x)((x) << ((idx) * 4))
> > +
> > #endif /* _I915_REG_H_ */
> > --
> > 2.23.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> --
> Lucas De Marchi
--
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH CI 2/6] drm/i915/tgl: Finish modular FIA support on registers
If platform supports and has modular FIA is enabled, the registers
bits also change, example: reading TC3 registers with modular FIA
enabled, driver should read from FIA2 but with TC1 bits offsets.
It is described in BSpec 50231 for DFLEXDPSP, other registers don't
have the BSpec description but testing in real hardware have proven
that it had moved for all other registers too.
v2:
- Caching index in tc_phy_fia_idx, instead of calculate it each time
v3:
- Setting tc_phy_fia and tc_phy_fia_idx in the same function
Cc: Lucas De Marchi
Reviewed-by: Lucas De Marchi
Signed-off-by: José Roberto de Souza
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_tc.c | 72 ++-
drivers/gpu/drm/i915/i915_reg.h | 28
3 files changed, 53 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index d5cc4b810d9e..d258a48f77d3 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1285,6 +1285,7 @@ struct intel_digital_port {
char tc_port_name[8];
enum tc_port_mode tc_mode;
enum phy_fia tc_phy_fia;
+ u8 tc_phy_fia_idx;
void (*write_infoframe)(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index 85743a43bee2..f923f9cbd33c 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -23,32 +23,38 @@ static const char *tc_port_mode_name(enum tc_port_mode mode)
return names[mode];
}
-static bool has_modular_fia(struct drm_i915_private *i915)
-{
- if (!INTEL_INFO(i915)->display.has_modular_fia)
- return false;
-
- return intel_uncore_read(>uncore,
-PORT_TX_DFLEXDPSP(FIA1)) & MODULAR_FIA_MASK;
-}
-
-static enum phy_fia tc_port_to_fia(struct drm_i915_private *i915,
- enum tc_port tc_port)
+static void
+tc_port_load_fia_params(struct drm_i915_private *i915,
+ struct intel_digital_port *dig_port)
{
- if (!has_modular_fia(i915))
- return FIA1;
+ enum port port = dig_port->base.port;
+ enum tc_port tc_port = intel_port_to_tc(i915, port);
+ u32 modular_fia;
+
+ if (INTEL_INFO(i915)->display.has_modular_fia) {
+ modular_fia = intel_uncore_read(>uncore,
+ PORT_TX_DFLEXDPSP(FIA1));
+ modular_fia &= MODULAR_FIA_MASK;
+ } else {
+ modular_fia = 0;
+ }
/*
* Each Modular FIA instance houses 2 TC ports. In SOC that has more
* than two TC ports, there are multiple instances of Modular FIA.
*/
- return tc_port / 2;
+ if (modular_fia) {
+ dig_port->tc_phy_fia = tc_port / 2;
+ dig_port->tc_phy_fia_idx = tc_port % 2;
+ } else {
+ dig_port->tc_phy_fia = FIA1;
+ dig_port->tc_phy_fia_idx = tc_port;
+ }
}
u32 intel_tc_port_get_lane_mask(struct intel_digital_port *dig_port)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- enum tc_port tc_port = intel_port_to_tc(i915, dig_port->base.port);
struct intel_uncore *uncore = >uncore;
u32 lane_mask;
@@ -57,8 +63,8 @@ u32 intel_tc_port_get_lane_mask(struct intel_digital_port
*dig_port)
WARN_ON(lane_mask == 0x);
- return (lane_mask & DP_LANE_ASSIGNMENT_MASK(tc_port)) >>
- DP_LANE_ASSIGNMENT_SHIFT(tc_port);
+ lane_mask &= DP_LANE_ASSIGNMENT_MASK(dig_port->tc_phy_fia_idx);
+ return lane_mask >> DP_LANE_ASSIGNMENT_SHIFT(dig_port->tc_phy_fia_idx);
}
int intel_tc_port_fia_max_lane_count(struct intel_digital_port *dig_port)
@@ -95,7 +101,6 @@ void intel_tc_port_set_fia_lane_count(struct
intel_digital_port *dig_port,
int required_lanes)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- enum tc_port tc_port = intel_port_to_tc(i915, dig_port->base.port);
bool lane_reversal = dig_port->saved_port_bits & DDI_BUF_PORT_REVERSAL;
struct intel_uncore *uncore = >uncore;
u32 val;
@@ -104,19 +109,21 @@ void intel_tc_port_set_fia_lane_count(struct
intel_digital_port *dig_port,
val = intel_uncore_read(uncore,
PORT_TX_DFLEXDPMLE1(dig_port->tc_phy_fia));
- val &= ~DFLEXDPMLE1_DPMLETC_MASK(tc_port);
+ val &= ~DFLEXDPMLE1_DPMLETC_MASK(dig_port->tc_phy_fia_idx);
switch (required_lanes) {
case 1:
- val |= lane_reversal ? DFLEXDPMLE1_DPMLETC_ML3(tc_port) :
-
[Intel-gfx] [PATCH CI 1/6] drm/i915/tgl: Add missing ddi clock select during DP init sequence
From: Clinton A Taylor Step 4.b was complete missed because it is only required to TC and TBT. Bspec: 49190 Reviewed-by: Imre Deak Reviewed-by: Lucas De Marchi Signed-off-by: Clinton A Taylor Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_ddi.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index 0c0da9f6c2e8..dfd6b064cbc3 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -3230,11 +3230,14 @@ static void tgl_ddi_pre_enable_dp(struct intel_encoder *encoder, intel_edp_panel_on(intel_dp); /* -* 1.b, 3. and 4. is done before tgl_ddi_pre_enable_dp() by: +* 1.b, 3. and 4.a is done before tgl_ddi_pre_enable_dp() by: * haswell_crtc_enable()->intel_encoders_pre_pll_enable() and * haswell_crtc_enable()->intel_enable_shared_dpll() */ + /* 4.b */ + intel_ddi_clk_select(encoder, crtc_state); + /* 5. */ if (!intel_phy_is_tc(dev_priv, phy) || dig_port->tc_mode != TC_PORT_TBT_ALT) -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH CI 0/6] TGL TC enabling v2-CI
Patches from https://patchwork.freedesktop.org/series/66695/#rev2 that got rv-b and don't have dependencies over other patches, for CI testing. Clinton A Taylor (2): drm/i915/tgl: Add missing ddi clock select during DP init sequence drm/i915/tgl/pll: Set update_active_dpll José Roberto de Souza (3): drm/i915/tgl: Finish modular FIA support on registers drm/i915/icl: Unify disable and enable phy clock gating functions drm/i915/tgl: Check the UC health of tc controllers after power on Vandita Kulkarni (1): drm/i915/tgl: Add dkl phy registers drivers/gpu/drm/i915/display/intel_ddi.c | 78 +++ .../drm/i915/display/intel_display_power.c| 13 ++ .../drm/i915/display/intel_display_types.h| 1 + drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 1 + drivers/gpu/drm/i915/display/intel_tc.c | 72 +++ drivers/gpu/drm/i915/i915_reg.h | 190 -- 6 files changed, 256 insertions(+), 99 deletions(-) -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH CI 5/6] drm/i915/icl: Unify disable and enable phy clock gating functions
Adding a enable parameters allow us to share most of the code between
enable and disable functions.
v3:
Renamed icl_phy_clock_gating() to icl_phy_set_clock_gating()
Reviewed-by: Lucas De Marchi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 73
1 file changed, 23 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index dfd6b064cbc3..33cd766f9eea 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3033,67 +3033,40 @@ static void intel_ddi_clk_disable(struct intel_encoder
*encoder)
}
}
-static void icl_enable_phy_clock_gating(struct intel_digital_port *dig_port)
+static void
+icl_phy_set_clock_gating(struct intel_digital_port *dig_port, bool enable)
{
struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
enum port port = dig_port->base.port;
enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
- u32 val;
+ u32 val, bits;
int ln;
if (tc_port == PORT_TC_NONE)
return;
- for (ln = 0; ln < 2; ln++) {
- val = I915_READ(MG_DP_MODE(ln, port));
- val |= MG_DP_MODE_CFG_TR2PWR_GATING |
- MG_DP_MODE_CFG_TRPWR_GATING |
- MG_DP_MODE_CFG_CLNPWR_GATING |
- MG_DP_MODE_CFG_DIGPWR_GATING |
- MG_DP_MODE_CFG_GAONPWR_GATING;
- I915_WRITE(MG_DP_MODE(ln, port), val);
- }
-
- val = I915_READ(MG_MISC_SUS0(tc_port));
- val |= MG_MISC_SUS0_SUSCLK_DYNCLKGATE_MODE(3) |
- MG_MISC_SUS0_CFG_TR2PWR_GATING |
- MG_MISC_SUS0_CFG_CL2PWR_GATING |
- MG_MISC_SUS0_CFG_GAONPWR_GATING |
- MG_MISC_SUS0_CFG_TRPWR_GATING |
- MG_MISC_SUS0_CFG_CL1PWR_GATING |
- MG_MISC_SUS0_CFG_DGPWR_GATING;
- I915_WRITE(MG_MISC_SUS0(tc_port), val);
-}
-
-static void icl_disable_phy_clock_gating(struct intel_digital_port *dig_port)
-{
- struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
- enum port port = dig_port->base.port;
- enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
- u32 val;
- int ln;
-
- if (tc_port == PORT_TC_NONE)
- return;
+ bits = MG_DP_MODE_CFG_TR2PWR_GATING | MG_DP_MODE_CFG_TRPWR_GATING |
+ MG_DP_MODE_CFG_CLNPWR_GATING | MG_DP_MODE_CFG_DIGPWR_GATING |
+ MG_DP_MODE_CFG_GAONPWR_GATING;
for (ln = 0; ln < 2; ln++) {
val = I915_READ(MG_DP_MODE(ln, port));
- val &= ~(MG_DP_MODE_CFG_TR2PWR_GATING |
-MG_DP_MODE_CFG_TRPWR_GATING |
-MG_DP_MODE_CFG_CLNPWR_GATING |
-MG_DP_MODE_CFG_DIGPWR_GATING |
-MG_DP_MODE_CFG_GAONPWR_GATING);
+ if (enable)
+ val |= bits;
+ else
+ val &= ~bits;
I915_WRITE(MG_DP_MODE(ln, port), val);
}
+ bits = MG_MISC_SUS0_CFG_TR2PWR_GATING | MG_MISC_SUS0_CFG_CL2PWR_GATING |
+ MG_MISC_SUS0_CFG_GAONPWR_GATING | MG_MISC_SUS0_CFG_TRPWR_GATING |
+ MG_MISC_SUS0_CFG_CL1PWR_GATING | MG_MISC_SUS0_CFG_DGPWR_GATING;
+
val = I915_READ(MG_MISC_SUS0(tc_port));
- val &= ~(MG_MISC_SUS0_SUSCLK_DYNCLKGATE_MODE_MASK |
-MG_MISC_SUS0_CFG_TR2PWR_GATING |
-MG_MISC_SUS0_CFG_CL2PWR_GATING |
-MG_MISC_SUS0_CFG_GAONPWR_GATING |
-MG_MISC_SUS0_CFG_TRPWR_GATING |
-MG_MISC_SUS0_CFG_CL1PWR_GATING |
-MG_MISC_SUS0_CFG_DGPWR_GATING);
+ if (enable)
+ val |= (bits | MG_MISC_SUS0_SUSCLK_DYNCLKGATE_MODE(3));
+ else
+ val &= ~(bits | MG_MISC_SUS0_SUSCLK_DYNCLKGATE_MODE_MASK);
I915_WRITE(MG_MISC_SUS0(tc_port), val);
}
@@ -3258,7 +3231,7 @@ static void tgl_ddi_pre_enable_dp(struct intel_encoder
*encoder,
intel_ddi_config_transcoder_func(crtc_state);
/* 7.d */
- icl_disable_phy_clock_gating(dig_port);
+ icl_phy_set_clock_gating(dig_port, false);
/* 7.e */
icl_ddi_vswing_sequence(encoder, crtc_state->port_clock, level,
@@ -3328,7 +3301,7 @@ static void hsw_ddi_pre_enable_dp(struct intel_encoder
*encoder,
dig_port->ddi_io_power_domain);
icl_program_mg_dp_mode(dig_port);
- icl_disable_phy_clock_gating(dig_port);
+ icl_phy_set_clock_gating(dig_port, false);
if (INTEL_GEN(dev_priv) >= 11)
icl_ddi_vswing_sequence(encoder, crtc_state->port_clock,
@@ -3361,7 +3334,7 @@ static void hsw_ddi_pre_enable_dp(struct intel_encoder
*encoder,
intel_ddi_enable_fec(encoder, crtc_state);
-
[Intel-gfx] [PATCH CI 3/6] drm/i915/tgl/pll: Set update_active_dpll
From: Clinton A Taylor
Commit 24a7bfe0c2d7 ("drm/i915: Keep the TypeC port mode fixed when the
port is active") added this new hook while in parallel TGL upstream was
happening and this was missed.
Without this driver will crash when TC DDI is added and driver is
preparing to do a full modeset.
Cc: Lucas De Marchi
Cc: Imre Deak
Reviewed-by: Lucas De Marchi
Signed-off-by: Clinton A Taylor
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index 98288edf88f0..84e734d44828 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -3479,6 +3479,7 @@ static const struct intel_dpll_mgr tgl_pll_mgr = {
.dpll_info = tgl_plls,
.get_dplls = icl_get_dplls,
.put_dplls = icl_put_dplls,
+ .update_active_dpll = icl_update_active_dpll,
.dump_hw_state = icl_dump_hw_state,
};
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH CI 4/6] drm/i915/tgl: Add dkl phy registers
From: Vandita Kulkarni
These are the registers needed to program Dekel phy. Some register
definitions will be reused from MG PHY definitions, so adding a
comment on those.
Bspec: 49295
Reviewed-by: Lucas De Marchi
Signed-off-by: Vandita Kulkarni
Signed-off-by: Clinton A Taylor
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_reg.h | 162
1 file changed, 162 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a6acda945e56..b82cf4725c05 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10111,6 +10111,168 @@ enum skl_power_gate {
_TGL_DPLL1_CFGCR1, \
_TGL_TBTPLL_CFGCR1)
+#define _DKL_PHY1_BASE 0x168000
+#define _DKL_PHY2_BASE 0x169000
+#define _DKL_PHY3_BASE 0x16A000
+#define _DKL_PHY4_BASE 0x16B000
+#define _DKL_PHY5_BASE 0x16C000
+#define _DKL_PHY6_BASE 0x16D000
+
+/* DEKEL PHY MMIO Address = Phy base + (internal address & ~index_mask) */
+#define _DKL_PLL_DIV0 0x200
+#define DKL_PLL_DIV0_INTEG_COEFF(x) ((x) << 16)
+#define DKL_PLL_DIV0_INTEG_COEFF_MASK(0x1F << 16)
+#define DKL_PLL_DIV0_PROP_COEFF(x) ((x) << 12)
+#define DKL_PLL_DIV0_PROP_COEFF_MASK (0xF << 12)
+#define DKL_PLL_DIV0_FBPREDIV_SHIFT (8)
+#define DKL_PLL_DIV0_FBPREDIV(x) ((x) << DKL_PLL_DIV0_FBPREDIV_SHIFT)
+#define DKL_PLL_DIV0_FBPREDIV_MASK (0xF << DKL_PLL_DIV0_FBPREDIV_SHIFT)
+#define DKL_PLL_DIV0_FBDIV_INT(x)((x) << 0)
+#define DKL_PLL_DIV0_FBDIV_INT_MASK (0xFF << 0)
+#define DKL_PLL_DIV0(tc_port) _MMIO(_PORT(tc_port, _DKL_PHY1_BASE, \
+ _DKL_PHY2_BASE) + \
+ _DKL_PLL_DIV0)
+
+#define _DKL_PLL_DIV1 0x204
+#define DKL_PLL_DIV1_IREF_TRIM(x)((x) << 16)
+#define DKL_PLL_DIV1_IREF_TRIM_MASK (0x1F << 16)
+#define DKL_PLL_DIV1_TDC_TARGET_CNT(x) ((x) << 0)
+#define DKL_PLL_DIV1_TDC_TARGET_CNT_MASK (0xFF << 0)
+#define DKL_PLL_DIV1(tc_port) _MMIO(_PORT(tc_port, _DKL_PHY1_BASE, \
+ _DKL_PHY2_BASE) + \
+ _DKL_PLL_DIV1)
+
+#define _DKL_PLL_SSC 0x210
+#define DKL_PLL_SSC_IREF_NDIV_RATIO(x) ((x) << 29)
+#define DKL_PLL_SSC_IREF_NDIV_RATIO_MASK (0x7 << 29)
+#define DKL_PLL_SSC_STEP_LEN(x) ((x) << 16)
+#define DKL_PLL_SSC_STEP_LEN_MASK(0xFF << 16)
+#define DKL_PLL_SSC_STEP_NUM(x) ((x) << 11)
+#define DKL_PLL_SSC_STEP_NUM_MASK(0x7 << 11)
+#define DKL_PLL_SSC_EN (1 << 9)
+#define DKL_PLL_SSC(tc_port) _MMIO(_PORT(tc_port, _DKL_PHY1_BASE, \
+ _DKL_PHY2_BASE) + \
+ _DKL_PLL_SSC)
+
+#define _DKL_PLL_BIAS 0x214
+#define DKL_PLL_BIAS_FRAC_EN_H (1 << 30)
+#define DKL_PLL_BIAS_FBDIV_SHIFT (8)
+#define DKL_PLL_BIAS_FBDIV_FRAC(x) ((x) << DKL_PLL_BIAS_FBDIV_SHIFT)
+#define DKL_PLL_BIAS_FBDIV_FRAC_MASK (0x3F << DKL_PLL_BIAS_FBDIV_SHIFT)
+#define DKL_PLL_BIAS(tc_port) _MMIO(_PORT(tc_port, _DKL_PHY1_BASE, \
+ _DKL_PHY2_BASE) + \
+ _DKL_PLL_BIAS)
+
+#define _DKL_PLL_TDC_COLDST_BIAS 0x218
+#define DKL_PLL_TDC_SSC_STEP_SIZE(x) ((x) << 8)
+#define DKL_PLL_TDC_SSC_STEP_SIZE_MASK (0xFF << 8)
+#define DKL_PLL_TDC_FEED_FWD_GAIN(x) ((x) << 0)
+#define DKL_PLL_TDC_FEED_FWD_GAIN_MASK (0xFF << 0)
+#define DKL_PLL_TDC_COLDST_BIAS(tc_port) _MMIO(_PORT(tc_port, \
+_DKL_PHY1_BASE, \
+_DKL_PHY2_BASE) + \
+_DKL_PLL_TDC_COLDST_BIAS)
+
+#define _DKL_REFCLKIN_CTL 0x12C
+/* Bits are the same as MG_REFCLKIN_CTL */
+#define DKL_REFCLKIN_CTL(tc_port) _MMIO(_PORT(tc_port, \
+ _DKL_PHY1_BASE, \
+ _DKL_PHY2_BASE) + \
+ _DKL_REFCLKIN_CTL)
+
+#define _DKL_CLKTOP2_HSCLKCTL 0xD4
+/* Bits are the same as MG_CLKTOP2_HSCLKCTL */
+#define DKL_CLKTOP2_HSCLKCTL(tc_port) _MMIO(_PORT(tc_port, \
+ _DKL_PHY1_BASE, \
+ _DKL_PHY2_BASE) + \
+
[Intel-gfx] [PATCH CI 6/6] drm/i915/tgl: Check the UC health of tc controllers after power on
New step added for TGL, required for us to check the TC
microcontroller health after power on TC aux.
BSpec: 49294
Reviewed-by: Imre Deak
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display_power.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index ce88a27229ef..f1186bc23542 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -562,6 +562,8 @@ static void icl_tc_port_assert_ref_held(struct
drm_i915_private *dev_priv,
#endif
+#define TGL_AUX_PW_TO_TC_PORT(pw_idx) ((pw_idx) - TGL_PW_CTL_IDX_AUX_TC1)
+
static void
icl_tc_phy_aux_power_well_enable(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
@@ -578,6 +580,17 @@ icl_tc_phy_aux_power_well_enable(struct drm_i915_private
*dev_priv,
I915_WRITE(DP_AUX_CH_CTL(aux_ch), val);
hsw_power_well_enable(dev_priv, power_well);
+
+ if (INTEL_GEN(dev_priv) >= 12 && !power_well->desc->hsw.is_tc_tbt) {
+ enum tc_port tc_port;
+
+ tc_port = TGL_AUX_PW_TO_TC_PORT(power_well->desc->hsw.idx);
+ I915_WRITE(HIP_INDEX_REG(tc_port), HIP_INDEX_VAL(tc_port, 0x2));
+
+ if (intel_de_wait_for_set(dev_priv, DKL_CMN_UC_DW_27(tc_port),
+ DKL_CMN_UC_DW27_UC_HEALTH, 1))
+ DRM_WARN("Timeout waiting TC uC health\n");
+ }
}
static void
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 07/13] drm/i915/tgl: TC helper function to return pin mapping
On Wed, Sep 18, 2019 at 5:07 PM José Roberto de Souza
wrote:
>
> From: Clinton A Taylor
>
> Add a helper function to return pin map for use during dkl phy
> DP_MODE settings, PORT_TX_DFLEXPA1 exist on ICL but we don't need it.
>
> The user of this function will come in future TC patches.
>
> Signed-off-by: Clinton A Taylor
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 15 +++
> drivers/gpu/drm/i915/display/intel_tc.h | 1 +
> drivers/gpu/drm/i915/i915_reg.h | 5 +
> 3 files changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 20fbb084830e..5d9577588e91 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -70,6 +70,21 @@ u32 intel_tc_port_get_lane_mask(struct intel_digital_port
> *dig_port)
>DP_LANE_ASSIGNMENT_SHIFT(dig_port->tc_phy_fia_idx);
> }
>
> +u32 intel_tc_port_get_pin_assignment_mask(struct intel_digital_port
> *dig_port)
> +{
> + struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> + struct intel_uncore *uncore = >uncore;
> + u32 pin_mask;
> +
> + pin_mask = intel_uncore_read(uncore,
> +PORT_TX_DFLEXPA1(dig_port->tc_phy_fia));
> +
> + WARN_ON(pin_mask == 0x);
> +
> + return (pin_mask & DP_PIN_ASSIGNMENT_MASK(dig_port->tc_phy_fia_idx))
> >>
> + DP_PIN_ASSIGNMENT_SHIFT(dig_port->tc_phy_fia_idx);
AFAICS this is tc_port-based, not tc_phy_fia_idx. tc_phy_fia_idx
should only ever be used
together with the HIP_INDEX.
Lucas De Marchi
> +}
> +
> int intel_tc_port_fia_max_lane_count(struct intel_digital_port *dig_port)
> {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.h
> b/drivers/gpu/drm/i915/display/intel_tc.h
> index 944d84c8cce1..1b8638dd340a 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.h
> +++ b/drivers/gpu/drm/i915/display/intel_tc.h
> @@ -14,6 +14,7 @@ struct drm_i915_private;
>
> bool intel_tc_port_connected(struct intel_digital_port *dig_port);
> u32 intel_tc_port_get_lane_mask(struct intel_digital_port *dig_port);
> +u32 intel_tc_port_get_pin_assignment_mask(struct intel_digital_port
> *dig_port);
> int intel_tc_port_fia_max_lane_count(struct intel_digital_port *dig_port);
> void intel_tc_port_set_fia_lane_count(struct intel_digital_port *dig_port,
> int required_lanes);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 32f98d0e0e9c..91a79e809dd2 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -11845,4 +11845,9 @@ enum skl_power_gate {
> #define PORT_TX_DFLEXDPCSSS(fia) _MMIO_FIA((fia), 0x00894)
> #define DP_PHY_MODE_STATUS_NOT_SAFE(idx) (1 << (idx))
>
> +#define PORT_TX_DFLEXPA1(fia) _MMIO_FIA((fia), 0x00880)
> +#define DP_PIN_ASSIGNMENT_SHIFT(idx) ((idx) * 4)
> +#define DP_PIN_ASSIGNMENT_MASK(idx) (0xf << ((idx) * 4))
> +#define DP_PIN_ASSIGNMENT(idx, x)((x) << ((idx) * 4))
> +
> #endif /* _I915_REG_H_ */
> --
> 2.23.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 06/13] drm/i915/tgl: Add support for dkl pll write
On Wed, Sep 18, 2019 at 5:07 PM José Roberto de Souza
wrote:
>
> From: Vandita Kulkarni
>
> Add a new function to write to dkl phy pll registers. As per the
> bspec all the registers are read modify write.
>
> Signed-off-by: Vandita Kulkarni
> Signed-off-by: José Roberto de Souza
> Signed-off-by: Lucas De Marchi
Reviewed-by: Lucas De Marchi
Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 65 ++-
> 1 file changed, 64 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> index 46dde614bfb5..21249997940d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -3293,7 +3293,70 @@ static void icl_mg_pll_write(struct drm_i915_private
> *dev_priv,
> static void dkl_pll_write(struct drm_i915_private *dev_priv,
> struct intel_shared_dpll *pll)
> {
> - /* TODO */
> + struct intel_dpll_hw_state *hw_state = >state.hw_state;
> + enum tc_port tc_port = icl_pll_id_to_tc_port(pll->info->id);
> + u32 val;
> +
> + /*
> +* All registers programmed here have the same HIP_INDEX_REG even
> +* though on different building block
> +*/
> + I915_WRITE(HIP_INDEX_REG(tc_port), HIP_INDEX_VAL(tc_port, 0x2));
> +
> + /* All the registers are RMW */
> + val = I915_READ(DKL_REFCLKIN_CTL(tc_port));
> + val &= ~MG_REFCLKIN_CTL_OD_2_MUX_MASK;
> + val |= hw_state->mg_refclkin_ctl;
> + I915_WRITE(DKL_REFCLKIN_CTL(tc_port), val);
> +
> + val = I915_READ(DKL_CLKTOP2_CORECLKCTL1(tc_port));
> + val &= ~MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO_MASK;
> + val |= hw_state->mg_clktop2_coreclkctl1;
> + I915_WRITE(DKL_CLKTOP2_CORECLKCTL1(tc_port), val);
> +
> + val = I915_READ(DKL_CLKTOP2_HSCLKCTL(tc_port));
> + val &= ~(MG_CLKTOP2_HSCLKCTL_TLINEDRV_CLKSEL_MASK |
> + MG_CLKTOP2_HSCLKCTL_CORE_INPUTSEL_MASK |
> + MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_MASK |
> + MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_MASK);
> + val |= hw_state->mg_clktop2_hsclkctl;
> + I915_WRITE(DKL_CLKTOP2_HSCLKCTL(tc_port), val);
> +
> + val = I915_READ(DKL_PLL_DIV0(tc_port));
> + val &= ~(DKL_PLL_DIV0_INTEG_COEFF_MASK |
> + DKL_PLL_DIV0_PROP_COEFF_MASK |
> + DKL_PLL_DIV0_FBPREDIV_MASK |
> + DKL_PLL_DIV0_FBDIV_INT_MASK);
> + val |= hw_state->mg_pll_div0;
> + I915_WRITE(DKL_PLL_DIV0(tc_port), val);
> +
> + val = I915_READ(DKL_PLL_DIV1(tc_port));
> + val &= ~(DKL_PLL_DIV1_IREF_TRIM_MASK |
> +DKL_PLL_DIV1_TDC_TARGET_CNT_MASK);
> + val |= hw_state->mg_pll_div1;
> + I915_WRITE(DKL_PLL_DIV1(tc_port), val);
> +
> + val = I915_READ(DKL_PLL_SSC(tc_port));
> + val &= ~(DKL_PLL_SSC_IREF_NDIV_RATIO_MASK |
> + DKL_PLL_SSC_STEP_LEN_MASK |
> + DKL_PLL_SSC_STEP_NUM_MASK |
> + DKL_PLL_SSC_EN);
> + val |= hw_state->mg_pll_ssc;
> + I915_WRITE(DKL_PLL_SSC(tc_port), val);
> +
> + val = I915_READ(DKL_PLL_BIAS(tc_port));
> + val &= ~(DKL_PLL_BIAS_FRAC_EN_H |
> + DKL_PLL_BIAS_FBDIV_FRAC_MASK);
> + val |= hw_state->mg_pll_bias;
> + I915_WRITE(DKL_PLL_BIAS(tc_port), val);
> +
> + val = I915_READ(DKL_PLL_TDC_COLDST_BIAS(tc_port));
> + val &= ~(DKL_PLL_TDC_SSC_STEP_SIZE_MASK |
> + DKL_PLL_TDC_FEED_FWD_GAIN_MASK);
> + val |= hw_state->mg_pll_tdc_coldst_bias;
> + I915_WRITE(DKL_PLL_TDC_COLDST_BIAS(tc_port), val);
> +
> + POSTING_READ(DKL_PLL_TDC_COLDST_BIAS(tc_port));
> }
>
> static void icl_pll_power_enable(struct drm_i915_private *dev_priv,
> --
> 2.23.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/selftests: Verify the LRC register layout between init and HW
== Series Details == Series: series starting with [1/2] drm/i915/selftests: Verify the LRC register layout between init and HW URL : https://patchwork.freedesktop.org/series/67018/ State : warning == Summary == $ dim checkpatch origin/drm-tip 2b9117e29756 drm/i915/selftests: Verify the LRC register layout between init and HW -:61: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'x' - possible side-effects? #61: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:474: +#define REG(x) (((x) >> 2) | BUILD_BUG_ON_ZERO(x >= 0x200)) -:62: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses #62: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:475: +#define REG16(x) \ + (((x) >> 9) | BIT(7) | BUILD_BUG_ON_ZERO(x >= 0x1)), \ + (((x) >> 2) & 0x7f) -:62: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'x' - possible side-effects? #62: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:475: +#define REG16(x) \ + (((x) >> 9) | BIT(7) | BUILD_BUG_ON_ZERO(x >= 0x1)), \ + (((x) >> 2) & 0x7f) total: 1 errors, 0 warnings, 2 checks, 1125 lines checked 84cf86742191 drm/i915/tgl: Swap engines for rc6/powersaving ___ 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/6] drm/i915: add i915_driver_modeset_remove()
== Series Details ==
Series: series starting with [v2,1/6] drm/i915: add i915_driver_modeset_remove()
URL : https://patchwork.freedesktop.org/series/67013/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6931 -> Patchwork_14483
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14483/
Known issues
Here are the changes found in Patchwork_14483 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic-small-bo-tiledy:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6931/fi-icl-u3/igt@gem_mmap_...@basic-small-bo-tiledy.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14483/fi-icl-u3/igt@gem_mmap_...@basic-small-bo-tiledy.html
* igt@i915_module_load@reload:
- fi-blb-e6850: [PASS][3] -> [INCOMPLETE][4] ([fdo#107718])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6931/fi-blb-e6850/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14483/fi-blb-e6850/igt@i915_module_l...@reload.html
* igt@kms_flip@basic-flip-vs-dpms:
- fi-hsw-4770r: [PASS][5] -> [DMESG-WARN][6] ([fdo#105602])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6931/fi-hsw-4770r/igt@kms_f...@basic-flip-vs-dpms.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14483/fi-hsw-4770r/igt@kms_f...@basic-flip-vs-dpms.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3: [PASS][7] -> [FAIL][8] ([fdo#103167])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6931/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14483/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
Participating hosts (54 -> 46)
--
Additional (1): fi-pnv-d510
Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-apl-guc fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6931 -> Patchwork_14483
CI-20190529: 20190529
CI_DRM_6931: 6630d2e2a6458d4efc634af20c294e456caff22e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5195: ea29372bb4e261a0a8da371a1f434131750f18e0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14483: 709d34d7c748302f590792303f82ab156c74f9d2 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
709d34d7c748 drm/i915: pass i915 to intel_modeset_init() and
intel_modeset_init_hw()
2e6e7c1d9781 drm/i915: abstract intel_mode_config_init() from
intel_modeset_init()
8c8f16a1edf8 drm/i915: abstract intel_panel_sanitize_ssc() from
intel_modeset_init()
27e4489c32d9 drm/i915: pass i915 to intel_modeset_driver_remove()
78b6e3b96f95 drm/i915: pass i915 to i915_driver_modeset_probe()
4f0318a8e293 drm/i915: add i915_driver_modeset_remove()
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14483/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/tgl: Swap engines for rc6/powersaving
Disable rc6 to re-enable all engines. It seems that the multi-engine
machine lockup is tied to rc6; disabling it makes a gem-sync --run
basic-store-all survive for a few hours, whereas without we expect it to
die within seconds. The only question is how does CI fare with the
exchange?
For testing purpose, having all the engines is more valuable than
enabling powersaving (both have to work of course, but many more features
depend on having the extra engines).
Note disabling rc6 has the knock-on effect of disabling our runtime
power management -- the issue might not be local to our rc6 programming.
Signed-off-by: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index fe6941c8fc99..698116276441 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -797,7 +797,7 @@ static const struct intel_device_info
intel_tigerlake_12_info = {
.display.has_modular_fia = 1,
.engine_mask =
BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
- .engine_mask = BIT(RCS0), /* XXX reduced for debugging */
+ .has_rc6 = false, /* XXX disabled for debugging */
};
#undef GEN
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/selftests: Verify the LRC register layout between init and HW
Before we submit the first context to HW, we need to construct a valid
image of the register state. This layout is defined by the HW and should
match the layout generated by HW when it saves the context image.
Asserting that this should be equivalent should help avoid any undefined
behaviour and verify that we haven't missed anything important!
Of course, having insisted that the initial register state within the
LRC should match that returned by HW, we need to ensure that it does.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 669 --
drivers/gpu/drm/i915/gt/intel_lrc_reg.h | 62 +-
drivers/gpu/drm/i915/gt/selftest_lrc.c| 142
drivers/gpu/drm/i915/i915_perf.c | 35 +-
drivers/gpu/drm/i915/i915_perf.h | 5 +-
.../drm/i915/selftests/i915_live_selftests.h | 1 +
7 files changed, 649 insertions(+), 267 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 4a34c4f62065..f7ba0935ed67 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1115,7 +1115,7 @@ static int gen8_emit_rpcs_config(struct i915_request *rq,
offset = i915_ggtt_offset(ce->state) +
LRC_STATE_PN * PAGE_SIZE +
-(CTX_R_PWR_CLK_STATE + 1) * 4;
+CTX_R_PWR_CLK_STATE * 4;
*cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
*cs++ = lower_32_bits(offset);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 1a2b71157f08..864cffd9bcf8 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -230,9 +230,10 @@ static int __execlists_context_alloc(struct intel_context
*ce,
struct intel_engine_cs *engine);
static void execlists_init_reg_state(u32 *reg_state,
-struct intel_context *ce,
-struct intel_engine_cs *engine,
-struct intel_ring *ring);
+const struct intel_context *ce,
+const struct intel_engine_cs *engine,
+const struct intel_ring *ring,
+bool close);
static inline u32 intel_hws_preempt_address(struct intel_engine_cs *engine)
{
@@ -464,6 +465,411 @@ lrc_descriptor(struct intel_context *ce, struct
intel_engine_cs *engine)
return desc;
}
+static u32 *set_offsets(u32 *regs,
+ const u8 *data,
+ const struct intel_engine_cs *engine)
+#define NOP(x) (BIT(7) | (x))
+#define LRI(count, flags) ((flags) << 6 | (count))
+#define POSTED BIT(0)
+#define REG(x) (((x) >> 2) | BUILD_BUG_ON_ZERO(x >= 0x200))
+#define REG16(x) \
+ (((x) >> 9) | BIT(7) | BUILD_BUG_ON_ZERO(x >= 0x1)), \
+ (((x) >> 2) & 0x7f)
+#define END() 0
+{
+ const u32 base = engine->mmio_base;
+
+ while (*data) {
+ u8 count, flags;
+
+ if (*data & BIT(7)) { /* skip */
+ regs += *data++ & ~BIT(7);
+ continue;
+ }
+
+ count = *data & 0x3f;
+ flags = *data >> 6;
+ data++;
+
+ *regs = MI_LOAD_REGISTER_IMM(count);
+ if (flags & POSTED)
+ *regs |= MI_LRI_FORCE_POSTED;
+ if (INTEL_GEN(engine->i915) >= 11)
+ *regs |= MI_LRI_CS_MMIO;
+ regs++;
+
+ GEM_BUG_ON(!count);
+ do {
+ u32 offset = 0;
+ u8 v;
+
+ do {
+ v = *data++;
+ offset <<= 7;
+ offset |= v & ~BIT(7);
+ } while (v & BIT(7));
+
+ *regs = base + (offset << 2);
+ regs += 2;
+ } while (--count);
+ }
+
+ return regs;
+}
+
+static const u8 gen8_xcs_offsets[] = {
+ NOP(1),
+ LRI(11, 0),
+ REG16(0x244),
+ REG(0x034),
+ REG(0x030),
+ REG(0x038),
+ REG(0x03c),
+ REG(0x168),
+ REG(0x140),
+ REG(0x110),
+ REG(0x11c),
+ REG(0x114),
+ REG(0x118),
+
+ NOP(9),
+ LRI(9, 0),
+ REG16(0x3a8),
+ REG16(0x28c),
+ REG16(0x288),
+ REG16(0x284),
+ REG16(0x280),
+ REG16(0x27c),
+ REG16(0x278),
+ REG16(0x274),
+ REG16(0x270),
+
+ NOP(13),
+ LRI(2, 0),
+ REG16(0x200),
+ REG(0x028),
+
+ END(),
+};
+
+static const u8 gen9_xcs_offsets[] = {
+ NOP(1),
+
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/6] drm/i915: add i915_driver_modeset_remove()
== Series Details == Series: series starting with [v2,1/6] drm/i915: add i915_driver_modeset_remove() URL : https://patchwork.freedesktop.org/series/67013/ State : warning == Summary == $ dim checkpatch origin/drm-tip 4f0318a8e293 drm/i915: add i915_driver_modeset_remove() 78b6e3b96f95 drm/i915: pass i915 to i915_driver_modeset_probe() 27e4489c32d9 drm/i915: pass i915 to intel_modeset_driver_remove() 8c8f16a1edf8 drm/i915: abstract intel_panel_sanitize_ssc() from intel_modeset_init() 2e6e7c1d9781 drm/i915: abstract intel_mode_config_init() from intel_modeset_init() 709d34d7c748 drm/i915: pass i915 to intel_modeset_init() and intel_modeset_init_hw() -:41: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided #41: FILE: drivers/gpu/drm/i915/display/intel_display.c:16028: + i915->cdclk.logical = i915->cdclk.actual = i915->cdclk.hw; total: 0 errors, 0 warnings, 1 checks, 155 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl: Swap engines for rc6/powersaving
Quoting Patchwork (2019-09-20 20:52:03) > == Series Details == > > Series: drm/i915/tgl: Swap engines for rc6/powersaving > URL : https://patchwork.freedesktop.org/series/67010/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_6931 -> Patchwork_14482 > > > Summary > --- > > **SUCCESS** > > No regressions found. > > External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14482/ Grr, so what this is not telling us is "nope, tgl died again". Seriously we need to stop suppressing failures once they are resolved. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl: Swap engines for rc6/powersaving
== Series Details ==
Series: drm/i915/tgl: Swap engines for rc6/powersaving
URL : https://patchwork.freedesktop.org/series/67010/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6931 -> Patchwork_14482
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14482/
Known issues
Here are the changes found in Patchwork_14482 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_flink_basic@double-flink:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6931/fi-icl-u3/igt@gem_flink_ba...@double-flink.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14482/fi-icl-u3/igt@gem_flink_ba...@double-flink.html
* igt@i915_module_load@reload:
- fi-blb-e6850: [PASS][3] -> [INCOMPLETE][4] ([fdo#107718])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6931/fi-blb-e6850/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14482/fi-blb-e6850/igt@i915_module_l...@reload.html
- fi-icl-u3: [PASS][5] -> [DMESG-WARN][6] ([fdo#107724] /
[fdo#111214])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6931/fi-icl-u3/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14482/fi-icl-u3/igt@i915_module_l...@reload.html
Possible fixes
* igt@gem_basic@create-close:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6931/fi-icl-u3/igt@gem_ba...@create-close.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14482/fi-icl-u3/igt@gem_ba...@create-close.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
[fdo#111593]: https://bugs.freedesktop.org/show_bug.cgi?id=111593
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
Participating hosts (54 -> 47)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6931 -> Patchwork_14482
CI-20190529: 20190529
CI_DRM_6931: 6630d2e2a6458d4efc634af20c294e456caff22e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5195: ea29372bb4e261a0a8da371a1f434131750f18e0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14482: f2c53fe56b36c109984633b0869df87aeb8b3a03 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
f2c53fe56b36 drm/i915/tgl: Swap engines for rc6/powersaving
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14482/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: pass i915 to intel_modeset_init() and intel_modeset_init_hw()
On Fri, 20 Sep 2019, Jani Nikula wrote:
> In general, prefer struct drm_i915_private * over struct drm_device *
> when either will do. Rename the local variables to i915. No functional
> changes.
This one was also already
Reviewed-by: Chris Wilson
in
http://mid.mail-archive.com/156890721641.1196.17548415265398501279@skylake-alporthouse-com
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 69 ++--
> drivers/gpu/drm/i915/display/intel_display.h | 4 +-
> drivers/gpu/drm/i915/i915_drv.c | 4 +-
> 3 files changed, 37 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 9c26228737a0..f9f116c89bcc 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4360,7 +4360,7 @@ void intel_finish_reset(struct drm_i915_private
> *dev_priv)
>* so need a full re-initialization.
>*/
> intel_pps_unlock_regs_wa(dev_priv);
> - intel_modeset_init_hw(dev);
> + intel_modeset_init_hw(dev_priv);
> intel_init_clock_gating(dev_priv);
>
> spin_lock_irq(_priv->irq_lock);
> @@ -15983,13 +15983,11 @@ static void i915_disable_vga(struct
> drm_i915_private *dev_priv)
> POSTING_READ(vga_reg);
> }
>
> -void intel_modeset_init_hw(struct drm_device *dev)
> +void intel_modeset_init_hw(struct drm_i915_private *i915)
> {
> - struct drm_i915_private *dev_priv = to_i915(dev);
> -
> - intel_update_cdclk(dev_priv);
> - intel_dump_cdclk_state(_priv->cdclk.hw, "Current CDCLK");
> - dev_priv->cdclk.logical = dev_priv->cdclk.actual = dev_priv->cdclk.hw;
> + intel_update_cdclk(i915);
> + intel_dump_cdclk_state(>cdclk.hw, "Current CDCLK");
> + i915->cdclk.logical = i915->cdclk.actual = i915->cdclk.hw;
> }
>
> /*
> @@ -16195,42 +16193,42 @@ static void intel_mode_config_init(struct
> drm_i915_private *i915)
> }
> }
>
> -int intel_modeset_init(struct drm_device *dev)
> +int intel_modeset_init(struct drm_i915_private *i915)
> {
> - struct drm_i915_private *dev_priv = to_i915(dev);
> + struct drm_device *dev = >drm;
> enum pipe pipe;
> struct intel_crtc *crtc;
> int ret;
>
> - dev_priv->modeset_wq = alloc_ordered_workqueue("i915_modeset", 0);
> - dev_priv->flip_wq = alloc_workqueue("i915_flip", WQ_HIGHPRI |
> - WQ_UNBOUND, WQ_UNBOUND_MAX_ACTIVE);
> + i915->modeset_wq = alloc_ordered_workqueue("i915_modeset", 0);
> + i915->flip_wq = alloc_workqueue("i915_flip", WQ_HIGHPRI |
> + WQ_UNBOUND, WQ_UNBOUND_MAX_ACTIVE);
>
> - intel_mode_config_init(dev_priv);
> + intel_mode_config_init(i915);
>
> - ret = intel_bw_init(dev_priv);
> + ret = intel_bw_init(i915);
> if (ret)
> return ret;
>
> - init_llist_head(_priv->atomic_helper.free_list);
> - INIT_WORK(_priv->atomic_helper.free_work,
> + init_llist_head(>atomic_helper.free_list);
> + INIT_WORK(>atomic_helper.free_work,
> intel_atomic_helper_free_state_worker);
>
> - intel_init_quirks(dev_priv);
> + intel_init_quirks(i915);
>
> - intel_fbc_init(dev_priv);
> + intel_fbc_init(i915);
>
> - intel_init_pm(dev_priv);
> + intel_init_pm(i915);
>
> - intel_panel_sanitize_ssc(dev_priv);
> + intel_panel_sanitize_ssc(i915);
>
> DRM_DEBUG_KMS("%d display pipe%s available.\n",
> - INTEL_NUM_PIPES(dev_priv),
> - INTEL_NUM_PIPES(dev_priv) > 1 ? "s" : "");
> + INTEL_NUM_PIPES(i915),
> + INTEL_NUM_PIPES(i915) > 1 ? "s" : "");
>
> - if (HAS_DISPLAY(dev_priv) && INTEL_DISPLAY_ENABLED(dev_priv)) {
> - for_each_pipe(dev_priv, pipe) {
> - ret = intel_crtc_init(dev_priv, pipe);
> + if (HAS_DISPLAY(i915) && INTEL_DISPLAY_ENABLED(i915)) {
> + for_each_pipe(i915, pipe) {
> + ret = intel_crtc_init(i915, pipe);
> if (ret) {
> drm_mode_config_cleanup(dev);
> return ret;
> @@ -16239,19 +16237,19 @@ int intel_modeset_init(struct drm_device *dev)
> }
>
> intel_shared_dpll_init(dev);
> - intel_update_fdi_pll_freq(dev_priv);
> + intel_update_fdi_pll_freq(i915);
>
> - intel_update_czclk(dev_priv);
> - intel_modeset_init_hw(dev);
> + intel_update_czclk(i915);
> + intel_modeset_init_hw(i915);
>
> - intel_hdcp_component_init(dev_priv);
> + intel_hdcp_component_init(i915);
>
> - if (dev_priv->max_cdclk_freq == 0)
> - intel_update_max_cdclk(dev_priv);
> + if (i915->max_cdclk_freq == 0)
> + intel_update_max_cdclk(i915);
>
>
Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: add i915_driver_modeset_remove()
Please ignore the two patches here. Critical fumble.
BR,
Jani.
On Fri, 20 Sep 2019, Jani Nikula wrote:
> For completeness, add counterpart to i915_driver_modeset_probe() and
> remove the asymmetry in the probe/remove parts. No functional changes.
>
> Reviewed-by: Chris Wilson
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.c | 25 +++--
> 1 file changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 9904f762f4bb..4cb95fd9b35d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -422,6 +422,20 @@ static int i915_driver_modeset_probe(struct drm_device
> *dev)
> return ret;
> }
>
> +static void i915_driver_modeset_remove(struct drm_i915_private *i915)
> +{
> + struct pci_dev *pdev = i915->drm.pdev;
> +
> + intel_modeset_driver_remove(>drm);
> +
> + intel_bios_driver_remove(i915);
> +
> + vga_switcheroo_unregister_client(pdev);
> + vga_client_register(pdev, NULL, NULL, NULL);
> +
> + intel_csr_ucode_fini(i915);
> +}
> +
> static void intel_init_dpio(struct drm_i915_private *dev_priv)
> {
> /*
> @@ -1586,8 +1600,6 @@ int i915_driver_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
>
> void i915_driver_remove(struct drm_i915_private *i915)
> {
> - struct pci_dev *pdev = i915->drm.pdev;
> -
> disable_rpm_wakeref_asserts(>runtime_pm);
>
> i915_driver_unregister(i915);
> @@ -1608,14 +1620,7 @@ void i915_driver_remove(struct drm_i915_private *i915)
>
> intel_gvt_driver_remove(i915);
>
> - intel_modeset_driver_remove(>drm);
> -
> - intel_bios_driver_remove(i915);
> -
> - vga_switcheroo_unregister_client(pdev);
> - vga_client_register(pdev, NULL, NULL, NULL);
> -
> - intel_csr_ucode_fini(i915);
> + i915_driver_modeset_remove(i915);
>
> /* Free error state after interrupts are fully disabled. */
> cancel_delayed_work_sync(>gt.hangcheck.work);
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 6/6] drm/i915: pass i915 to intel_modeset_init() and intel_modeset_init_hw()
In general, prefer struct drm_i915_private * over struct drm_device *
when either will do. Rename the local variables to i915. No functional
changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 69 ++--
drivers/gpu/drm/i915/display/intel_display.h | 4 +-
drivers/gpu/drm/i915/i915_drv.c | 4 +-
3 files changed, 37 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 9c26228737a0..f9f116c89bcc 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4360,7 +4360,7 @@ void intel_finish_reset(struct drm_i915_private *dev_priv)
* so need a full re-initialization.
*/
intel_pps_unlock_regs_wa(dev_priv);
- intel_modeset_init_hw(dev);
+ intel_modeset_init_hw(dev_priv);
intel_init_clock_gating(dev_priv);
spin_lock_irq(_priv->irq_lock);
@@ -15983,13 +15983,11 @@ static void i915_disable_vga(struct drm_i915_private
*dev_priv)
POSTING_READ(vga_reg);
}
-void intel_modeset_init_hw(struct drm_device *dev)
+void intel_modeset_init_hw(struct drm_i915_private *i915)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
-
- intel_update_cdclk(dev_priv);
- intel_dump_cdclk_state(_priv->cdclk.hw, "Current CDCLK");
- dev_priv->cdclk.logical = dev_priv->cdclk.actual = dev_priv->cdclk.hw;
+ intel_update_cdclk(i915);
+ intel_dump_cdclk_state(>cdclk.hw, "Current CDCLK");
+ i915->cdclk.logical = i915->cdclk.actual = i915->cdclk.hw;
}
/*
@@ -16195,42 +16193,42 @@ static void intel_mode_config_init(struct
drm_i915_private *i915)
}
}
-int intel_modeset_init(struct drm_device *dev)
+int intel_modeset_init(struct drm_i915_private *i915)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_device *dev = >drm;
enum pipe pipe;
struct intel_crtc *crtc;
int ret;
- dev_priv->modeset_wq = alloc_ordered_workqueue("i915_modeset", 0);
- dev_priv->flip_wq = alloc_workqueue("i915_flip", WQ_HIGHPRI |
- WQ_UNBOUND, WQ_UNBOUND_MAX_ACTIVE);
+ i915->modeset_wq = alloc_ordered_workqueue("i915_modeset", 0);
+ i915->flip_wq = alloc_workqueue("i915_flip", WQ_HIGHPRI |
+ WQ_UNBOUND, WQ_UNBOUND_MAX_ACTIVE);
- intel_mode_config_init(dev_priv);
+ intel_mode_config_init(i915);
- ret = intel_bw_init(dev_priv);
+ ret = intel_bw_init(i915);
if (ret)
return ret;
- init_llist_head(_priv->atomic_helper.free_list);
- INIT_WORK(_priv->atomic_helper.free_work,
+ init_llist_head(>atomic_helper.free_list);
+ INIT_WORK(>atomic_helper.free_work,
intel_atomic_helper_free_state_worker);
- intel_init_quirks(dev_priv);
+ intel_init_quirks(i915);
- intel_fbc_init(dev_priv);
+ intel_fbc_init(i915);
- intel_init_pm(dev_priv);
+ intel_init_pm(i915);
- intel_panel_sanitize_ssc(dev_priv);
+ intel_panel_sanitize_ssc(i915);
DRM_DEBUG_KMS("%d display pipe%s available.\n",
- INTEL_NUM_PIPES(dev_priv),
- INTEL_NUM_PIPES(dev_priv) > 1 ? "s" : "");
+ INTEL_NUM_PIPES(i915),
+ INTEL_NUM_PIPES(i915) > 1 ? "s" : "");
- if (HAS_DISPLAY(dev_priv) && INTEL_DISPLAY_ENABLED(dev_priv)) {
- for_each_pipe(dev_priv, pipe) {
- ret = intel_crtc_init(dev_priv, pipe);
+ if (HAS_DISPLAY(i915) && INTEL_DISPLAY_ENABLED(i915)) {
+ for_each_pipe(i915, pipe) {
+ ret = intel_crtc_init(i915, pipe);
if (ret) {
drm_mode_config_cleanup(dev);
return ret;
@@ -16239,19 +16237,19 @@ int intel_modeset_init(struct drm_device *dev)
}
intel_shared_dpll_init(dev);
- intel_update_fdi_pll_freq(dev_priv);
+ intel_update_fdi_pll_freq(i915);
- intel_update_czclk(dev_priv);
- intel_modeset_init_hw(dev);
+ intel_update_czclk(i915);
+ intel_modeset_init_hw(i915);
- intel_hdcp_component_init(dev_priv);
+ intel_hdcp_component_init(i915);
- if (dev_priv->max_cdclk_freq == 0)
- intel_update_max_cdclk(dev_priv);
+ if (i915->max_cdclk_freq == 0)
+ intel_update_max_cdclk(i915);
/* Just disable it once at startup */
- i915_disable_vga(dev_priv);
- intel_setup_outputs(dev_priv);
+ i915_disable_vga(i915);
+ intel_setup_outputs(i915);
drm_modeset_lock_all(dev);
intel_modeset_setup_hw_state(dev, dev->mode_config.acquire_ctx);
@@
[Intel-gfx] [PATCH v2 4/6] drm/i915: abstract intel_panel_sanitize_ssc() from intel_modeset_init()
The code is too specific and detailed to have open in a high level
function. Abstract away. As a drive-by improvement switch to using
enableddisabled() in logging and git rid of a redundant !!. No
functional changes.
v2: drop the !! while at it too (Chris)
Reviewed-by: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 39 +++-
1 file changed, 22 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 538a33adbc0e..9e68df8a9945 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7552,6 +7552,27 @@ intel_link_compute_m_n(u16 bits_per_pixel, int nlanes,
constant_n);
}
+static void intel_panel_sanitize_ssc(struct drm_i915_private *dev_priv)
+{
+ /*
+* There may be no VBT; and if the BIOS enabled SSC we can
+* just keep using it to avoid unnecessary flicker. Whereas if the
+* BIOS isn't using it, don't assume it will work even if the VBT
+* indicates as much.
+*/
+ if (HAS_PCH_IBX(dev_priv) || HAS_PCH_CPT(dev_priv)) {
+ bool bios_lvds_use_ssc = I915_READ(PCH_DREF_CONTROL) &
+ DREF_SSC1_ENABLE;
+
+ if (dev_priv->vbt.lvds_use_ssc != bios_lvds_use_ssc) {
+ DRM_DEBUG_KMS("SSC %s by BIOS, overriding VBT which
says %s\n",
+ enableddisabled(bios_lvds_use_ssc),
+
enableddisabled(dev_priv->vbt.lvds_use_ssc));
+ dev_priv->vbt.lvds_use_ssc = bios_lvds_use_ssc;
+ }
+ }
+}
+
static inline bool intel_panel_use_ssc(struct drm_i915_private *dev_priv)
{
if (i915_modparams.panel_use_ssc >= 0)
@@ -16165,23 +16186,7 @@ int intel_modeset_init(struct drm_device *dev)
intel_init_pm(dev_priv);
- /*
-* There may be no VBT; and if the BIOS enabled SSC we can
-* just keep using it to avoid unnecessary flicker. Whereas if the
-* BIOS isn't using it, don't assume it will work even if the VBT
-* indicates as much.
-*/
- if (HAS_PCH_IBX(dev_priv) || HAS_PCH_CPT(dev_priv)) {
- bool bios_lvds_use_ssc = !!(I915_READ(PCH_DREF_CONTROL) &
- DREF_SSC1_ENABLE);
-
- if (dev_priv->vbt.lvds_use_ssc != bios_lvds_use_ssc) {
- DRM_DEBUG_KMS("SSC %sabled by BIOS, overriding VBT
which says %sabled\n",
-bios_lvds_use_ssc ? "en" : "dis",
-dev_priv->vbt.lvds_use_ssc ? "en" : "dis");
- dev_priv->vbt.lvds_use_ssc = bios_lvds_use_ssc;
- }
- }
+ intel_panel_sanitize_ssc(dev_priv);
/*
* Maximum framebuffer dimensions, chosen to match
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/6] drm/i915: add i915_driver_modeset_remove()
For completeness, add counterpart to i915_driver_modeset_probe() and
remove the asymmetry in the probe/remove parts. No functional changes.
Reviewed-by: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9904f762f4bb..4cb95fd9b35d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -422,6 +422,20 @@ static int i915_driver_modeset_probe(struct drm_device
*dev)
return ret;
}
+static void i915_driver_modeset_remove(struct drm_i915_private *i915)
+{
+ struct pci_dev *pdev = i915->drm.pdev;
+
+ intel_modeset_driver_remove(>drm);
+
+ intel_bios_driver_remove(i915);
+
+ vga_switcheroo_unregister_client(pdev);
+ vga_client_register(pdev, NULL, NULL, NULL);
+
+ intel_csr_ucode_fini(i915);
+}
+
static void intel_init_dpio(struct drm_i915_private *dev_priv)
{
/*
@@ -1586,8 +1600,6 @@ int i915_driver_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
void i915_driver_remove(struct drm_i915_private *i915)
{
- struct pci_dev *pdev = i915->drm.pdev;
-
disable_rpm_wakeref_asserts(>runtime_pm);
i915_driver_unregister(i915);
@@ -1608,14 +1620,7 @@ void i915_driver_remove(struct drm_i915_private *i915)
intel_gvt_driver_remove(i915);
- intel_modeset_driver_remove(>drm);
-
- intel_bios_driver_remove(i915);
-
- vga_switcheroo_unregister_client(pdev);
- vga_client_register(pdev, NULL, NULL, NULL);
-
- intel_csr_ucode_fini(i915);
+ i915_driver_modeset_remove(i915);
/* Free error state after interrupts are fully disabled. */
cancel_delayed_work_sync(>gt.hangcheck.work);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/6] drm/i915: pass i915 to i915_driver_modeset_probe()
In general, prefer struct drm_i915_private * over struct drm_device *
when either will do. Rename the local variable to i915. No functional
changes.
Reviewed-by: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 59 -
1 file changed, 29 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4cb95fd9b35d..3e4ea5d6fcc2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -329,23 +329,22 @@ static const struct vga_switcheroo_client_ops
i915_switcheroo_ops = {
.can_switch = i915_switcheroo_can_switch,
};
-static int i915_driver_modeset_probe(struct drm_device *dev)
+static int i915_driver_modeset_probe(struct drm_i915_private *i915)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_dev *pdev = i915->drm.pdev;
int ret;
- if (i915_inject_probe_failure(dev_priv))
+ if (i915_inject_probe_failure(i915))
return -ENODEV;
- if (HAS_DISPLAY(dev_priv) && INTEL_DISPLAY_ENABLED(dev_priv)) {
- ret = drm_vblank_init(_priv->drm,
- INTEL_NUM_PIPES(dev_priv));
+ if (HAS_DISPLAY(i915) && INTEL_DISPLAY_ENABLED(i915)) {
+ ret = drm_vblank_init(>drm,
+ INTEL_NUM_PIPES(i915));
if (ret)
goto out;
}
- intel_bios_init(dev_priv);
+ intel_bios_init(i915);
/* If we have > 1 VGA cards, then we need to arbitrate access
* to the common VGA resources.
@@ -354,7 +353,7 @@ static int i915_driver_modeset_probe(struct drm_device *dev)
* then we do not take part in VGA arbitration and the
* vga_client_register() fails with -ENODEV.
*/
- ret = vga_client_register(pdev, dev_priv, NULL, i915_vga_set_decode);
+ ret = vga_client_register(pdev, i915, NULL, i915_vga_set_decode);
if (ret && ret != -ENODEV)
goto out;
@@ -365,56 +364,56 @@ static int i915_driver_modeset_probe(struct drm_device
*dev)
goto cleanup_vga_client;
/* must happen before intel_power_domains_init_hw() on VLV/CHV */
- intel_update_rawclk(dev_priv);
+ intel_update_rawclk(i915);
- intel_power_domains_init_hw(dev_priv, false);
+ intel_power_domains_init_hw(i915, false);
- intel_csr_ucode_init(dev_priv);
+ intel_csr_ucode_init(i915);
- ret = intel_irq_install(dev_priv);
+ ret = intel_irq_install(i915);
if (ret)
goto cleanup_csr;
- intel_gmbus_setup(dev_priv);
+ intel_gmbus_setup(i915);
/* Important: The output setup functions called by modeset_init need
* working irqs for e.g. gmbus and dp aux transfers. */
- ret = intel_modeset_init(dev);
+ ret = intel_modeset_init(>drm);
if (ret)
goto cleanup_irq;
- ret = i915_gem_init(dev_priv);
+ ret = i915_gem_init(i915);
if (ret)
goto cleanup_modeset;
- intel_overlay_setup(dev_priv);
+ intel_overlay_setup(i915);
- if (!HAS_DISPLAY(dev_priv) || !INTEL_DISPLAY_ENABLED(dev_priv))
+ if (!HAS_DISPLAY(i915) || !INTEL_DISPLAY_ENABLED(i915))
return 0;
- ret = intel_fbdev_init(dev);
+ ret = intel_fbdev_init(>drm);
if (ret)
goto cleanup_gem;
/* Only enable hotplug handling once the fbdev is fully set up. */
- intel_hpd_init(dev_priv);
+ intel_hpd_init(i915);
- intel_init_ipc(dev_priv);
+ intel_init_ipc(i915);
return 0;
cleanup_gem:
- i915_gem_suspend(dev_priv);
- i915_gem_driver_remove(dev_priv);
- i915_gem_driver_release(dev_priv);
+ i915_gem_suspend(i915);
+ i915_gem_driver_remove(i915);
+ i915_gem_driver_release(i915);
cleanup_modeset:
- intel_modeset_driver_remove(dev);
+ intel_modeset_driver_remove(>drm);
cleanup_irq:
- intel_irq_uninstall(dev_priv);
- intel_gmbus_teardown(dev_priv);
+ intel_irq_uninstall(i915);
+ intel_gmbus_teardown(i915);
cleanup_csr:
- intel_csr_ucode_fini(dev_priv);
- intel_power_domains_driver_remove(dev_priv);
+ intel_csr_ucode_fini(i915);
+ intel_power_domains_driver_remove(i915);
vga_switcheroo_unregister_client(pdev);
cleanup_vga_client:
vga_client_register(pdev, NULL, NULL, NULL);
@@ -1570,7 +1569,7 @@ int i915_driver_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
if (ret < 0)
goto out_cleanup_mmio;
- ret = i915_driver_modeset_probe(_priv->drm);
+ ret = i915_driver_modeset_probe(dev_priv);
if (ret < 0)
goto out_cleanup_hw;
--
2.20.1
[Intel-gfx] [PATCH v2 3/6] drm/i915: pass i915 to intel_modeset_driver_remove()
In general, prefer struct drm_i915_private * over struct drm_device *
when either will do. Rename the local variable to i915. Also propagate
to intel_hpd_poll_fini(). No functional changes.
Reviewed-by: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 38 ++--
drivers/gpu/drm/i915/display/intel_display.h | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 4 +--
3 files changed, 21 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index e0033d99f6e3..538a33adbc0e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -17076,13 +17076,13 @@ void intel_display_resume(struct drm_device *dev)
drm_atomic_state_put(state);
}
-static void intel_hpd_poll_fini(struct drm_device *dev)
+static void intel_hpd_poll_fini(struct drm_i915_private *i915)
{
struct intel_connector *connector;
struct drm_connector_list_iter conn_iter;
/* Kill all the work that may have been queued by hpd. */
- drm_connector_list_iter_begin(dev, _iter);
+ drm_connector_list_iter_begin(>drm, _iter);
for_each_intel_connector_iter(connector, _iter) {
if (connector->modeset_retry_work.func)
cancel_work_sync(>modeset_retry_work);
@@ -17094,51 +17094,49 @@ static void intel_hpd_poll_fini(struct drm_device
*dev)
drm_connector_list_iter_end(_iter);
}
-void intel_modeset_driver_remove(struct drm_device *dev)
+void intel_modeset_driver_remove(struct drm_i915_private *i915)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
-
- flush_workqueue(dev_priv->flip_wq);
- flush_workqueue(dev_priv->modeset_wq);
+ flush_workqueue(i915->flip_wq);
+ flush_workqueue(i915->modeset_wq);
- flush_work(_priv->atomic_helper.free_work);
- WARN_ON(!llist_empty(_priv->atomic_helper.free_list));
+ flush_work(>atomic_helper.free_work);
+ WARN_ON(!llist_empty(>atomic_helper.free_list));
/*
* Interrupts and polling as the first thing to avoid creating havoc.
* Too much stuff here (turning of connectors, ...) would
* experience fancy races otherwise.
*/
- intel_irq_uninstall(dev_priv);
+ intel_irq_uninstall(i915);
/*
* Due to the hpd irq storm handling the hotplug work can re-arm the
* poll handlers. Hence disable polling after hpd handling is shut down.
*/
- intel_hpd_poll_fini(dev);
+ intel_hpd_poll_fini(i915);
/* poll work can call into fbdev, hence clean that up afterwards */
- intel_fbdev_fini(dev_priv);
+ intel_fbdev_fini(i915);
intel_unregister_dsm_handler();
- intel_fbc_global_disable(dev_priv);
+ intel_fbc_global_disable(i915);
/* flush any delayed tasks or pending work */
flush_scheduled_work();
- intel_hdcp_component_fini(dev_priv);
+ intel_hdcp_component_fini(i915);
- drm_mode_config_cleanup(dev);
+ drm_mode_config_cleanup(>drm);
- intel_overlay_cleanup(dev_priv);
+ intel_overlay_cleanup(i915);
- intel_gmbus_teardown(dev_priv);
+ intel_gmbus_teardown(i915);
- destroy_workqueue(dev_priv->flip_wq);
- destroy_workqueue(dev_priv->modeset_wq);
+ destroy_workqueue(i915->flip_wq);
+ destroy_workqueue(i915->modeset_wq);
- intel_fbc_cleanup_cfb(dev_priv);
+ intel_fbc_cleanup_cfb(i915);
}
/*
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index b1ae0e59c715..933cbe36bb59 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -578,7 +578,7 @@ void intel_display_print_error_state(struct
drm_i915_error_state_buf *e,
/* modesetting */
void intel_modeset_init_hw(struct drm_device *dev);
int intel_modeset_init(struct drm_device *dev);
-void intel_modeset_driver_remove(struct drm_device *dev);
+void intel_modeset_driver_remove(struct drm_i915_private *i915);
int intel_modeset_vga_set_state(struct drm_i915_private *dev_priv, bool state);
void intel_display_resume(struct drm_device *dev);
void i915_redisable_vga(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3e4ea5d6fcc2..d9b9e9644f5c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -407,7 +407,7 @@ static int i915_driver_modeset_probe(struct
drm_i915_private *i915)
i915_gem_driver_remove(i915);
i915_gem_driver_release(i915);
cleanup_modeset:
- intel_modeset_driver_remove(>drm);
+ intel_modeset_driver_remove(i915);
cleanup_irq:
intel_irq_uninstall(i915);
intel_gmbus_teardown(i915);
@@ -425,7 +425,7 @@ static void
[Intel-gfx] [PATCH v2 5/6] drm/i915: abstract intel_mode_config_init() from intel_modeset_init()
The i915 specific mode config init code is too specific and detailed to
have open in a high level function. Abstract away. No functional
changes.
v2: nest drm_mode_config_init() in the function too (Chris)
Reviewed-by: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 87 +++-
1 file changed, 47 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 9e68df8a9945..9c26228737a0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -16149,6 +16149,52 @@ static int intel_initial_commit(struct drm_device *dev)
return ret;
}
+static void intel_mode_config_init(struct drm_i915_private *i915)
+{
+ struct drm_mode_config *mode_config = >drm.mode_config;
+
+ drm_mode_config_init(>drm);
+
+ mode_config->min_width = 0;
+ mode_config->min_height = 0;
+
+ mode_config->preferred_depth = 24;
+ mode_config->prefer_shadow = 1;
+
+ mode_config->allow_fb_modifiers = true;
+
+ mode_config->funcs = _mode_funcs;
+
+ /*
+* Maximum framebuffer dimensions, chosen to match
+* the maximum render engine surface size on gen4+.
+*/
+ if (INTEL_GEN(i915) >= 7) {
+ mode_config->max_width = 16384;
+ mode_config->max_height = 16384;
+ } else if (INTEL_GEN(i915) >= 4) {
+ mode_config->max_width = 8192;
+ mode_config->max_height = 8192;
+ } else if (IS_GEN(i915, 3)) {
+ mode_config->max_width = 4096;
+ mode_config->max_height = 4096;
+ } else {
+ mode_config->max_width = 2048;
+ mode_config->max_height = 2048;
+ }
+
+ if (IS_I845G(i915) || IS_I865G(i915)) {
+ mode_config->cursor_width = IS_I845G(i915) ? 64 : 512;
+ mode_config->cursor_height = 1023;
+ } else if (IS_GEN(i915, 2)) {
+ mode_config->cursor_width = 64;
+ mode_config->cursor_height = 64;
+ } else {
+ mode_config->cursor_width = 256;
+ mode_config->cursor_height = 256;
+ }
+}
+
int intel_modeset_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -16160,22 +16206,12 @@ int intel_modeset_init(struct drm_device *dev)
dev_priv->flip_wq = alloc_workqueue("i915_flip", WQ_HIGHPRI |
WQ_UNBOUND, WQ_UNBOUND_MAX_ACTIVE);
- drm_mode_config_init(dev);
+ intel_mode_config_init(dev_priv);
ret = intel_bw_init(dev_priv);
if (ret)
return ret;
- dev->mode_config.min_width = 0;
- dev->mode_config.min_height = 0;
-
- dev->mode_config.preferred_depth = 24;
- dev->mode_config.prefer_shadow = 1;
-
- dev->mode_config.allow_fb_modifiers = true;
-
- dev->mode_config.funcs = _mode_funcs;
-
init_llist_head(_priv->atomic_helper.free_list);
INIT_WORK(_priv->atomic_helper.free_work,
intel_atomic_helper_free_state_worker);
@@ -16188,35 +16224,6 @@ int intel_modeset_init(struct drm_device *dev)
intel_panel_sanitize_ssc(dev_priv);
- /*
-* Maximum framebuffer dimensions, chosen to match
-* the maximum render engine surface size on gen4+.
-*/
- if (INTEL_GEN(dev_priv) >= 7) {
- dev->mode_config.max_width = 16384;
- dev->mode_config.max_height = 16384;
- } else if (INTEL_GEN(dev_priv) >= 4) {
- dev->mode_config.max_width = 8192;
- dev->mode_config.max_height = 8192;
- } else if (IS_GEN(dev_priv, 3)) {
- dev->mode_config.max_width = 4096;
- dev->mode_config.max_height = 4096;
- } else {
- dev->mode_config.max_width = 2048;
- dev->mode_config.max_height = 2048;
- }
-
- if (IS_I845G(dev_priv) || IS_I865G(dev_priv)) {
- dev->mode_config.cursor_width = IS_I845G(dev_priv) ? 64 : 512;
- dev->mode_config.cursor_height = 1023;
- } else if (IS_GEN(dev_priv, 2)) {
- dev->mode_config.cursor_width = 64;
- dev->mode_config.cursor_height = 64;
- } else {
- dev->mode_config.cursor_width = 256;
- dev->mode_config.cursor_height = 256;
- }
-
DRM_DEBUG_KMS("%d display pipe%s available.\n",
INTEL_NUM_PIPES(dev_priv),
INTEL_NUM_PIPES(dev_priv) > 1 ? "s" : "");
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/6] drm/i915: add i915_driver_modeset_remove()
For completeness, add counterpart to i915_driver_modeset_probe() and
remove the asymmetry in the probe/remove parts. No functional changes.
Reviewed-by: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9904f762f4bb..4cb95fd9b35d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -422,6 +422,20 @@ static int i915_driver_modeset_probe(struct drm_device
*dev)
return ret;
}
+static void i915_driver_modeset_remove(struct drm_i915_private *i915)
+{
+ struct pci_dev *pdev = i915->drm.pdev;
+
+ intel_modeset_driver_remove(>drm);
+
+ intel_bios_driver_remove(i915);
+
+ vga_switcheroo_unregister_client(pdev);
+ vga_client_register(pdev, NULL, NULL, NULL);
+
+ intel_csr_ucode_fini(i915);
+}
+
static void intel_init_dpio(struct drm_i915_private *dev_priv)
{
/*
@@ -1586,8 +1600,6 @@ int i915_driver_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
void i915_driver_remove(struct drm_i915_private *i915)
{
- struct pci_dev *pdev = i915->drm.pdev;
-
disable_rpm_wakeref_asserts(>runtime_pm);
i915_driver_unregister(i915);
@@ -1608,14 +1620,7 @@ void i915_driver_remove(struct drm_i915_private *i915)
intel_gvt_driver_remove(i915);
- intel_modeset_driver_remove(>drm);
-
- intel_bios_driver_remove(i915);
-
- vga_switcheroo_unregister_client(pdev);
- vga_client_register(pdev, NULL, NULL, NULL);
-
- intel_csr_ucode_fini(i915);
+ i915_driver_modeset_remove(i915);
/* Free error state after interrupts are fully disabled. */
cancel_delayed_work_sync(>gt.hangcheck.work);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/6] drm/i915: pass i915 to i915_driver_modeset_probe()
In general, prefer struct drm_i915_private * over struct drm_device *
when either will do. Rename the local variable to i915. No functional
changes.
Reviewed-by: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 59 -
1 file changed, 29 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4cb95fd9b35d..3e4ea5d6fcc2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -329,23 +329,22 @@ static const struct vga_switcheroo_client_ops
i915_switcheroo_ops = {
.can_switch = i915_switcheroo_can_switch,
};
-static int i915_driver_modeset_probe(struct drm_device *dev)
+static int i915_driver_modeset_probe(struct drm_i915_private *i915)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_dev *pdev = i915->drm.pdev;
int ret;
- if (i915_inject_probe_failure(dev_priv))
+ if (i915_inject_probe_failure(i915))
return -ENODEV;
- if (HAS_DISPLAY(dev_priv) && INTEL_DISPLAY_ENABLED(dev_priv)) {
- ret = drm_vblank_init(_priv->drm,
- INTEL_NUM_PIPES(dev_priv));
+ if (HAS_DISPLAY(i915) && INTEL_DISPLAY_ENABLED(i915)) {
+ ret = drm_vblank_init(>drm,
+ INTEL_NUM_PIPES(i915));
if (ret)
goto out;
}
- intel_bios_init(dev_priv);
+ intel_bios_init(i915);
/* If we have > 1 VGA cards, then we need to arbitrate access
* to the common VGA resources.
@@ -354,7 +353,7 @@ static int i915_driver_modeset_probe(struct drm_device *dev)
* then we do not take part in VGA arbitration and the
* vga_client_register() fails with -ENODEV.
*/
- ret = vga_client_register(pdev, dev_priv, NULL, i915_vga_set_decode);
+ ret = vga_client_register(pdev, i915, NULL, i915_vga_set_decode);
if (ret && ret != -ENODEV)
goto out;
@@ -365,56 +364,56 @@ static int i915_driver_modeset_probe(struct drm_device
*dev)
goto cleanup_vga_client;
/* must happen before intel_power_domains_init_hw() on VLV/CHV */
- intel_update_rawclk(dev_priv);
+ intel_update_rawclk(i915);
- intel_power_domains_init_hw(dev_priv, false);
+ intel_power_domains_init_hw(i915, false);
- intel_csr_ucode_init(dev_priv);
+ intel_csr_ucode_init(i915);
- ret = intel_irq_install(dev_priv);
+ ret = intel_irq_install(i915);
if (ret)
goto cleanup_csr;
- intel_gmbus_setup(dev_priv);
+ intel_gmbus_setup(i915);
/* Important: The output setup functions called by modeset_init need
* working irqs for e.g. gmbus and dp aux transfers. */
- ret = intel_modeset_init(dev);
+ ret = intel_modeset_init(>drm);
if (ret)
goto cleanup_irq;
- ret = i915_gem_init(dev_priv);
+ ret = i915_gem_init(i915);
if (ret)
goto cleanup_modeset;
- intel_overlay_setup(dev_priv);
+ intel_overlay_setup(i915);
- if (!HAS_DISPLAY(dev_priv) || !INTEL_DISPLAY_ENABLED(dev_priv))
+ if (!HAS_DISPLAY(i915) || !INTEL_DISPLAY_ENABLED(i915))
return 0;
- ret = intel_fbdev_init(dev);
+ ret = intel_fbdev_init(>drm);
if (ret)
goto cleanup_gem;
/* Only enable hotplug handling once the fbdev is fully set up. */
- intel_hpd_init(dev_priv);
+ intel_hpd_init(i915);
- intel_init_ipc(dev_priv);
+ intel_init_ipc(i915);
return 0;
cleanup_gem:
- i915_gem_suspend(dev_priv);
- i915_gem_driver_remove(dev_priv);
- i915_gem_driver_release(dev_priv);
+ i915_gem_suspend(i915);
+ i915_gem_driver_remove(i915);
+ i915_gem_driver_release(i915);
cleanup_modeset:
- intel_modeset_driver_remove(dev);
+ intel_modeset_driver_remove(>drm);
cleanup_irq:
- intel_irq_uninstall(dev_priv);
- intel_gmbus_teardown(dev_priv);
+ intel_irq_uninstall(i915);
+ intel_gmbus_teardown(i915);
cleanup_csr:
- intel_csr_ucode_fini(dev_priv);
- intel_power_domains_driver_remove(dev_priv);
+ intel_csr_ucode_fini(i915);
+ intel_power_domains_driver_remove(i915);
vga_switcheroo_unregister_client(pdev);
cleanup_vga_client:
vga_client_register(pdev, NULL, NULL, NULL);
@@ -1570,7 +1569,7 @@ int i915_driver_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
if (ret < 0)
goto out_cleanup_mmio;
- ret = i915_driver_modeset_probe(_priv->drm);
+ ret = i915_driver_modeset_probe(dev_priv);
if (ret < 0)
goto out_cleanup_hw;
--
2.20.1
Re: [Intel-gfx] [PATCH 00/12] drm/i915: YCbCr output fixes and prep work for YCbCr 4:4:4 output
On Thu, Jul 18, 2019 at 05:50:41PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > I was playing around with YCbCr 4:4:4 output and noticed several > things wrong in our code. So I fixed it all and tossed in the > prep work for YCbCr 4:4:4 output on ilk+. > > Ville Syrjälä (12): > drm/dp: Add definitons for MSA MISC bits ^ pushed to drm-misc-next > drm/i915: Switch to using DP_MSA_MISC_* defines ^ on hold until the first patch propagates to dinq. > drm/i915: Fix HSW+ DP MSA YCbCr colorspace indication > drm/i915: Fix AVI infoframe quantization range for YCbCr output > drm/i915: Extract intel_hdmi_limited_color_range() > drm/i915: Never set limited_color_range=true for YCbCr output > drm/i915: Don't look at unrelated PIPECONF bits for interlaced readout > drm/i915: Simplify intel_get_crtc_ycbcr_config() > drm/i915: Add PIPECONF YCbCr 4:4:4 programming for HSW > drm/i915: Document ILK+ pipe csc matrix better > drm/i915: Set up ILK/SNB csc unit properly for YCbCr output > drm/i915: Add PIPECONF YCbCr 4:4:4 programming for ILK-IVB The rest pushed to dinq, with typos fixed. Thanks for the review. > > drivers/gpu/drm/i915/display/intel_color.c | 51 ++-- > drivers/gpu/drm/i915/display/intel_ddi.c | 28 +++-- > drivers/gpu/drm/i915/display/intel_display.c | 120 --- > drivers/gpu/drm/i915/display/intel_dp.c | 10 ++ > drivers/gpu/drm/i915/display/intel_hdmi.c| 61 +++--- > drivers/gpu/drm/i915/i915_reg.h | 31 ++--- > include/drm/drm_dp_helper.h | 42 +++ > 7 files changed, 247 insertions(+), 96 deletions(-) > > -- > 2.21.0 -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,v2,1/6] drm/i915/display/icl: Save Master transcoder in slave's crtc_state for Transcoder Port Sync (rev2)
== Series Details == Series: series starting with [CI,v2,1/6] drm/i915/display/icl: Save Master transcoder in slave's crtc_state for Transcoder Port Sync (rev2) URL : https://patchwork.freedesktop.org/series/66956/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6929 -> Patchwork_14481 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14481 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14481, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14481/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_14481: ### IGT changes ### Possible regressions * igt@kms_busy@basic-flip-a: - fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6929/fi-icl-u3/igt@kms_b...@basic-flip-a.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14481/fi-icl-u3/igt@kms_b...@basic-flip-a.html - fi-icl-u2: NOTRUN -> [DMESG-WARN][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14481/fi-icl-u2/igt@kms_b...@basic-flip-a.html Known issues Here are the changes found in Patchwork_14481 that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap_gtt@basic-write: - fi-icl-u3: [PASS][4] -> [DMESG-WARN][5] ([fdo#107724]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6929/fi-icl-u3/igt@gem_mmap_...@basic-write.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14481/fi-icl-u3/igt@gem_mmap_...@basic-write.html Possible fixes * igt@gem_ctx_switch@legacy-render: - fi-icl-u2: [INCOMPLETE][6] ([fdo#107713] / [fdo#111381]) -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6929/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14481/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html - fi-bxt-dsi: [INCOMPLETE][8] ([fdo#103927] / [fdo#111381]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6929/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14481/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html * igt@gem_mmap_gtt@basic-small-bo-tiledy: - fi-icl-u3: [DMESG-WARN][10] ([fdo#107724]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6929/fi-icl-u3/igt@gem_mmap_...@basic-small-bo-tiledy.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14481/fi-icl-u3/igt@gem_mmap_...@basic-small-bo-tiledy.html Warnings * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][12] ([fdo#111407]) -> [FAIL][13] ([fdo#111045] / [fdo#111096]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6929/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14481/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045 [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096 [fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 Participating hosts (55 -> 47) -- Missing(8): fi-icl-u4 fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6929 -> Patchwork_14481 CI-20190529: 20190529 CI_DRM_6929: fceeceeb45e97b2e6e635c0e4459e4217f9f35a4 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5195: ea29372bb4e261a0a8da371a1f434131750f18e0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14481: dec0139687417a2aae3f1cc79f81282f1d34817a @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == dec013968741 drm/i915/display/icl: In port sync mode disable slaves first then master fb75692e7764 drm/i915/display/icl: Disable transcoder port sync as part of crtc_disable() sequence 92d6d741851b drm/i915/display/icl: Enable master-slaves in trans port sync 91d5494eec0a drm/i915/display/icl: HW state readout for transcoder port sync config a8e0571f3ea6 drm/i915/display/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports 46735a5193f0 drm/i915/display/icl: Save Master transcoder in slave's crtc_state
[Intel-gfx] [PATCH] drm/i915/tgl: Swap engines for rc6/powersaving
Disable rc6 to re-enable all engines. It seems that the multi-engine
machine lockup is tied to rc6; disabling it makes a gem-sync --run
basic-store-all survive for a few hours, whereas without we expect it to
die within seconds. The only question is how does CI fare with the
exchange?
For testing purpose, having all the engines is more valuable than
enabling powersaving (both have to work of course, but many more features
depend on having the extra engines).
Note disabling rc6 has the knock-on effect of disabling our runtime
power management -- the issue might not be local to our rc6 programming.
Signed-off-by: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index fe6941c8fc99..698116276441 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -797,7 +797,7 @@ static const struct intel_device_info
intel_tigerlake_12_info = {
.display.has_modular_fia = 1,
.engine_mask =
BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
- .engine_mask = BIT(RCS0), /* XXX reduced for debugging */
+ .has_rc6 = false, /* XXX disabled for debugging */
};
#undef GEN
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 09/13] drm/i915/icl: Unify disable and enable phy clock gating functions
On Wed, Sep 18, 2019 at 5:07 PM José Roberto de Souza
wrote:
>
> Adding a enable parameters allow us to share most of the code between
> enable and disable functions.
>
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 71
> 1 file changed, 22 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index fd271118d1f5..78c6974a52d4 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3145,67 +3145,40 @@ tgl_phy_clock_gating(struct intel_digital_port
> *dig_port, bool enable)
> }
> }
>
> -static void icl_enable_phy_clock_gating(struct intel_digital_port *dig_port)
> +static void
> +icl_phy_clock_gating(struct intel_digital_port *dig_port, bool enable)
name is confusing: is it a getter or setter?
icl_phy_set_clock_gating()?
> {
> struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> enum port port = dig_port->base.port;
> enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
> - u32 val;
> + u32 val, regs;
s/regs/bits/
With some additional effort we could even migrate this to intel_tc.c.
Not for this patch though.
With the changes above:
Reviewed-by: Lucas De Marchi
Lucas De Marchi
> int ln;
>
> if (tc_port == PORT_TC_NONE)
> return;
>
> - for (ln = 0; ln < 2; ln++) {
> - val = I915_READ(MG_DP_MODE(ln, port));
> - val |= MG_DP_MODE_CFG_TR2PWR_GATING |
> - MG_DP_MODE_CFG_TRPWR_GATING |
> - MG_DP_MODE_CFG_CLNPWR_GATING |
> - MG_DP_MODE_CFG_DIGPWR_GATING |
> - MG_DP_MODE_CFG_GAONPWR_GATING;
> - I915_WRITE(MG_DP_MODE(ln, port), val);
> - }
> -
> - val = I915_READ(MG_MISC_SUS0(tc_port));
> - val |= MG_MISC_SUS0_SUSCLK_DYNCLKGATE_MODE(3) |
> - MG_MISC_SUS0_CFG_TR2PWR_GATING |
> - MG_MISC_SUS0_CFG_CL2PWR_GATING |
> - MG_MISC_SUS0_CFG_GAONPWR_GATING |
> - MG_MISC_SUS0_CFG_TRPWR_GATING |
> - MG_MISC_SUS0_CFG_CL1PWR_GATING |
> - MG_MISC_SUS0_CFG_DGPWR_GATING;
> - I915_WRITE(MG_MISC_SUS0(tc_port), val);
> -}
> -
> -static void icl_disable_phy_clock_gating(struct intel_digital_port *dig_port)
> -{
> - struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> - enum port port = dig_port->base.port;
> - enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
> - u32 val;
> - int ln;
> -
> - if (tc_port == PORT_TC_NONE)
> - return;
> + regs = MG_DP_MODE_CFG_TR2PWR_GATING | MG_DP_MODE_CFG_TRPWR_GATING |
> + MG_DP_MODE_CFG_CLNPWR_GATING | MG_DP_MODE_CFG_DIGPWR_GATING |
> + MG_DP_MODE_CFG_GAONPWR_GATING;
>
> for (ln = 0; ln < 2; ln++) {
> val = I915_READ(MG_DP_MODE(ln, port));
> - val &= ~(MG_DP_MODE_CFG_TR2PWR_GATING |
> -MG_DP_MODE_CFG_TRPWR_GATING |
> -MG_DP_MODE_CFG_CLNPWR_GATING |
> -MG_DP_MODE_CFG_DIGPWR_GATING |
> -MG_DP_MODE_CFG_GAONPWR_GATING);
> + if (enable)
> + val |= regs;
> + else
> + val &= ~regs;
> I915_WRITE(MG_DP_MODE(ln, port), val);
> }
>
> + regs = MG_MISC_SUS0_CFG_TR2PWR_GATING |
> MG_MISC_SUS0_CFG_CL2PWR_GATING |
> + MG_MISC_SUS0_CFG_GAONPWR_GATING |
> MG_MISC_SUS0_CFG_TRPWR_GATING |
> + MG_MISC_SUS0_CFG_CL1PWR_GATING | MG_MISC_SUS0_CFG_DGPWR_GATING;
> +
> val = I915_READ(MG_MISC_SUS0(tc_port));
> - val &= ~(MG_MISC_SUS0_SUSCLK_DYNCLKGATE_MODE_MASK |
> -MG_MISC_SUS0_CFG_TR2PWR_GATING |
> -MG_MISC_SUS0_CFG_CL2PWR_GATING |
> -MG_MISC_SUS0_CFG_GAONPWR_GATING |
> -MG_MISC_SUS0_CFG_TRPWR_GATING |
> -MG_MISC_SUS0_CFG_CL1PWR_GATING |
> -MG_MISC_SUS0_CFG_DGPWR_GATING);
> + if (enable)
> + val |= (regs | MG_MISC_SUS0_SUSCLK_DYNCLKGATE_MODE(3));
> + else
> + val &= ~(regs | MG_MISC_SUS0_SUSCLK_DYNCLKGATE_MODE_MASK);
> I915_WRITE(MG_MISC_SUS0(tc_port), val);
> }
>
> @@ -3538,7 +3511,7 @@ static void hsw_ddi_pre_enable_dp(struct intel_encoder
> *encoder,
> dig_port->ddi_io_power_domain);
>
> icl_program_mg_dp_mode(dig_port);
> - icl_disable_phy_clock_gating(dig_port);
> + icl_phy_clock_gating(dig_port, false);
>
> if (INTEL_GEN(dev_priv) >= 11)
> icl_ddi_vswing_sequence(encoder, crtc_state->port_clock,
> @@ -3571,7 +3544,7 @@ static void hsw_ddi_pre_enable_dp(struct intel_encoder
Re: [Intel-gfx] [drm-intel:drm-intel-next-queued 6/7] drivers/gpu/drm/i915/display/intel_color.c:1576 ilk_read_lut_10() error: potential null dereference 'blob'. (drm_property_create_blob returns null
On Sat, Sep 21, 2019 at 01:55:25AM +0800, kbuild test robot wrote:
> tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
> head: 4bb6a9d5d9a8289673c4cb0786d44be8a63c21db
> commit: 6b97b118d4d542c7bc25b725c6de3947fffb921b [6/7] drm/i915/display:
> Extract ilk_read_luts()
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot
>
> New smatch warnings:
> drivers/gpu/drm/i915/display/intel_color.c:1576 ilk_read_lut_10() error:
> potential null dereference 'blob'. (drm_property_create_blob returns null)
It never returns null. Not sure why this thing thinks otherwise.
>
> Old smatch warnings:
> drivers/gpu/drm/i915/display/intel_color.c:1535 i9xx_read_lut_8() error:
> potential null dereference 'blob'. (drm_property_create_blob returns null)
>
> vim +/blob +1576 drivers/gpu/drm/i915/display/intel_color.c
>
> 1558
> 1559static struct drm_property_blob *
> 1560ilk_read_lut_10(const struct intel_crtc_state *crtc_state)
> 1561{
> 1562struct intel_crtc *crtc =
> to_intel_crtc(crtc_state->base.crtc);
> 1563struct drm_i915_private *dev_priv =
> to_i915(crtc->base.dev);
> 1564u32 lut_size =
> INTEL_INFO(dev_priv)->color.gamma_lut_size;
> 1565enum pipe pipe = crtc->pipe;
> 1566struct drm_property_blob *blob;
> 1567struct drm_color_lut *blob_data;
> 1568u32 i, val;
> 1569
> 1570blob = drm_property_create_blob(_priv->drm,
> 1571sizeof(struct
> drm_color_lut) * lut_size,
> 1572NULL);
> 1573if (IS_ERR(blob))
> 1574return NULL;
> 1575
> > 1576blob_data = blob->data;
> 1577
> 1578for (i = 0; i < lut_size; i++) {
> 1579val = I915_READ(PREC_PALETTE(pipe, i));
> 1580
> 1581blob_data[i].red =
> intel_color_lut_pack(REG_FIELD_GET(
> 1582
> PREC_PALETTE_RED_MASK, val), 10);
> 1583blob_data[i].green =
> intel_color_lut_pack(REG_FIELD_GET(
> 1584
> PREC_PALETTE_GREEN_MASK, val), 10);
> 1585blob_data[i].blue =
> intel_color_lut_pack(REG_FIELD_GET(
> 1586
> PREC_PALETTE_BLUE_MASK, val), 10);
> 1587}
> 1588
> 1589return blob;
> 1590}
> 1591
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,v2,1/6] drm/i915/display/icl: Save Master transcoder in slave's crtc_state for Transcoder Port Sync (rev2)
== Series Details == Series: series starting with [CI,v2,1/6] drm/i915/display/icl: Save Master transcoder in slave's crtc_state for Transcoder Port Sync (rev2) URL : https://patchwork.freedesktop.org/series/66956/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.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 series starting with [CI,1/2] drm/i915/guc: Enable guc logging on guc log relay write
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/guc: Enable guc logging on guc
log relay write
URL : https://patchwork.freedesktop.org/series/67009/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6929 -> Patchwork_14480
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14480/
Known issues
Here are the changes found in Patchwork_14480 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_exec@basic:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6929/fi-icl-u3/igt@gem_ctx_e...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14480/fi-icl-u3/igt@gem_ctx_e...@basic.html
Possible fixes
* igt@debugfs_test@read_all_entries:
- {fi-tgl-u2}:[DMESG-WARN][3] ([fdo#111600]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6929/fi-tgl-u2/igt@debugfs_test@read_all_entries.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14480/fi-tgl-u2/igt@debugfs_test@read_all_entries.html
* igt@gem_ctx_create@basic-files:
- {fi-icl-guc}: [INCOMPLETE][5] ([fdo#107713] / [fdo#109100]) ->
[PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6929/fi-icl-guc/igt@gem_ctx_cre...@basic-files.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14480/fi-icl-guc/igt@gem_ctx_cre...@basic-files.html
* igt@gem_ctx_switch@legacy-render:
- fi-icl-u2: [INCOMPLETE][7] ([fdo#107713] / [fdo#111381]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6929/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14480/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
- fi-bxt-dsi: [INCOMPLETE][9] ([fdo#103927] / [fdo#111381]) ->
[PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6929/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14480/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
* igt@gem_mmap_gtt@basic-small-bo-tiledy:
- fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6929/fi-icl-u3/igt@gem_mmap_...@basic-small-bo-tiledy.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14480/fi-icl-u3/igt@gem_mmap_...@basic-small-bo-tiledy.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
Participating hosts (55 -> 46)
--
Missing(9): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ivb-3770 fi-icl-y fi-blb-e6850 fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6929 -> Patchwork_14480
CI-20190529: 20190529
CI_DRM_6929: fceeceeb45e97b2e6e635c0e4459e4217f9f35a4 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5195: ea29372bb4e261a0a8da371a1f434131750f18e0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14480: b1abc3243ba9e19d46a9eb0b431de8d8a31b997e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
b1abc3243ba9 HAX: force enable_guc=2
46eb3a716fff drm/i915/guc: Enable guc logging on guc log relay write
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14480/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/2] drm/i915/uc: Update HuC firmware naming convention and load latest HuC
On 9/20/19 5:51 AM, Patchwork wrote: == Series Details == Series: series starting with [CI,1/2] drm/i915/uc: Update HuC firmware naming convention and load latest HuC URL : https://patchwork.freedesktop.org/series/66955/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6925_full -> Patchwork_14466_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14466_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14466_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_14466_full: ### IGT changes ### Possible regressions * igt@i915_suspend@debugfs-reader: - shard-iclb: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-iclb5/igt@i915_susp...@debugfs-reader.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-iclb4/igt@i915_susp...@debugfs-reader.html https://bugs.freedesktop.org/show_bug.cgi?id=65 once again. I've manually double-checked the new HuC binaries loaded fine and pushed. Daniele Known issues Here are the changes found in Patchwork_14466_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +14 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-kbl2/igt@gem_ctx_isolat...@rcs0-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-kbl2/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#110854]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-iclb4/igt@gem_exec_balan...@smoke.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-iclb7/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#111325]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-iclb3/igt@gem_exec_sched...@preempt-other-chain-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +16 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-iclb1/igt@gem_exec_sched...@preempt-queue-bsd1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-iclb3/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +10 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-apl2/igt@gem_workarou...@suspend-resume-context.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-apl1/igt@gem_workarou...@suspend-resume-context.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-skl: [PASS][13] -> [SKIP][14] ([fdo#109271]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-skl10/igt@i915_pm_rc6_reside...@rc6-accuracy.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-skl5/igt@i915_pm_rc6_reside...@rc6-accuracy.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#105363]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-skl1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-skl6/igt@kms_f...@flip-vs-expired-vblank-interruptible.html - shard-glk: [PASS][17] -> [FAIL][18] ([fdo#105363]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-glk5/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-glk1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([fdo#109507]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-skl6/igt@kms_f...@flip-vs-suspend-interruptible.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-skl4/igt@kms_f...@flip-vs-suspend-interruptible.html - shard-hsw: [PASS][21] -> [INCOMPLETE][22] ([fdo#103540]) [21]:
[Intel-gfx] [drm-intel:drm-intel-next-queued 6/7] drivers/gpu/drm/i915/display/intel_color.c:1576 ilk_read_lut_10() error: potential null dereference 'blob'. (drm_property_create_blob returns null)
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: 4bb6a9d5d9a8289673c4cb0786d44be8a63c21db
commit: 6b97b118d4d542c7bc25b725c6de3947fffb921b [6/7] drm/i915/display:
Extract ilk_read_luts()
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
New smatch warnings:
drivers/gpu/drm/i915/display/intel_color.c:1576 ilk_read_lut_10() error:
potential null dereference 'blob'. (drm_property_create_blob returns null)
Old smatch warnings:
drivers/gpu/drm/i915/display/intel_color.c:1535 i9xx_read_lut_8() error:
potential null dereference 'blob'. (drm_property_create_blob returns null)
vim +/blob +1576 drivers/gpu/drm/i915/display/intel_color.c
1558
1559 static struct drm_property_blob *
1560 ilk_read_lut_10(const struct intel_crtc_state *crtc_state)
1561 {
1562 struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
1563 struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
1564 u32 lut_size = INTEL_INFO(dev_priv)->color.gamma_lut_size;
1565 enum pipe pipe = crtc->pipe;
1566 struct drm_property_blob *blob;
1567 struct drm_color_lut *blob_data;
1568 u32 i, val;
1569
1570 blob = drm_property_create_blob(_priv->drm,
1571 sizeof(struct drm_color_lut) *
lut_size,
1572 NULL);
1573 if (IS_ERR(blob))
1574 return NULL;
1575
> 1576 blob_data = blob->data;
1577
1578 for (i = 0; i < lut_size; i++) {
1579 val = I915_READ(PREC_PALETTE(pipe, i));
1580
1581 blob_data[i].red = intel_color_lut_pack(REG_FIELD_GET(
1582
PREC_PALETTE_RED_MASK, val), 10);
1583 blob_data[i].green = intel_color_lut_pack(REG_FIELD_GET(
1584
PREC_PALETTE_GREEN_MASK, val), 10);
1585 blob_data[i].blue = intel_color_lut_pack(REG_FIELD_GET(
1586
PREC_PALETTE_BLUE_MASK, val), 10);
1587 }
1588
1589 return blob;
1590 }
1591
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/2] drm/i915/guc: Enable guc logging on guc log relay write
== Series Details == Series: series starting with [CI,1/2] drm/i915/guc: Enable guc logging on guc log relay write URL : https://patchwork.freedesktop.org/series/67009/ State : warning == Summary == $ dim checkpatch origin/drm-tip 46eb3a716fff drm/i915/guc: Enable guc logging on guc log relay write b1abc3243ba9 HAX: force enable_guc=2 -:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one total: 0 errors, 1 warnings, 0 checks, 8 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for treewide: remove unused argument in lock_release()
== Series Details == Series: treewide: remove unused argument in lock_release() URL : https://patchwork.freedesktop.org/series/67007/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h AR drivers/gpu/drm/i915/built-in.a CC [M] drivers/gpu/drm/i915/gt/intel_gt_pm.o drivers/gpu/drm/i915/gt/intel_gt_pm.c: In function ‘intel_gt_resume’: drivers/gpu/drm/i915/gt/intel_gt_pm.c:186:54: error: macro "mutex_release" passed 3 arguments, but takes just 2 mutex_release(>pin_mutex.dep_map, 0, _THIS_IP_); ^ drivers/gpu/drm/i915/gt/intel_gt_pm.c:186:4: error: ‘mutex_release’ undeclared (first use in this function); did you mean ‘seq_release’? mutex_release(>pin_mutex.dep_map, 0, _THIS_IP_); ^ seq_release drivers/gpu/drm/i915/gt/intel_gt_pm.c:186:4: note: each undeclared identifier is reported only once for each function it appears in scripts/Makefile.build:280: recipe for target 'drivers/gpu/drm/i915/gt/intel_gt_pm.o' failed make[4]: *** [drivers/gpu/drm/i915/gt/intel_gt_pm.o] Error 1 scripts/Makefile.build:497: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:497: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:497: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1087: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from overtaking each other on preemption
> -Original Message- > From: Chris Wilson > Sent: Friday, September 20, 2019 9:04 AM > To: Bloomfield, Jon ; intel- > g...@lists.freedesktop.org; Tvrtko Ursulin > Subject: RE: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from > overtaking each other on preemption > > Quoting Bloomfield, Jon (2019-09-20 16:50:57) > > > -Original Message- > > > From: Intel-gfx On Behalf Of > Tvrtko > > > Ursulin > > > Sent: Friday, September 20, 2019 8:12 AM > > > To: Chris Wilson ; > > > intel-gfx@lists.freedesktop.org > > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from > > > overtaking each other on preemption > > > > > > > > > On 20/09/2019 15:57, Chris Wilson wrote: > > > > Quoting Chris Wilson (2019-09-20 09:36:24) > > > >> Force bonded requests to run on distinct engines so that they cannot be > > > >> shuffled onto the same engine where timeslicing will reverse the order. > > > >> A bonded request will often wait on a semaphore signaled by its master, > > > >> creating an implicit dependency -- if we ignore that implicit > > > >> dependency > > > >> and allow the bonded request to run on the same engine and before its > > > >> master, we will cause a GPU hang. > > > > > > > > Thinking more, it should not directly cause a GPU hang, as the stuck > request > > > > should be timesliced away, and each preemption should be enough to > keep > > > > hangcheck at bay (though we have evidence it may not). So at best it > > > > runs > > > > at half-speed, at worst a third (if my model is correct). > > > > > > But I think it is still correct to do since we don't have the coupling > > > information on re-submit. Hm.. but don't we need to prevent slave from > > > changing engines as well? > > > > Unless I'm missing something, the proposal here is to set the engines in > > stone > at first submission, and never change them? > > For submission here, think execution (submission to actual HW). (We have > 2 separate phases that all like to be called submit()!) > > > If so, that does sound overly restrictive, and will prevent any kind of > rebalancing as workloads (of varying slave counts) come and go. > > We are only restricting this request, not the contexts. We still have > balancing overall, just not instantaneous balancing if we timeslice out > of this request -- we put it back onto the "same" engine and not another. > Which is in some ways is less than ideal, although strictly we are only > saying don't put it back onto an engine we have earmarked for our bonded > request, and so we avoid contending with our parallel request reducing > that to serial (and often bad) behaviour. > > [So at the end of this statement, I'm more happy with the restriction ;] > > > During the original design it was called out that the workloads should be > > pre- > empted atomically. That allows the entire bonding mask to be re-evaluated at > every context switch and so we can then rebalance. Still not easy to achieve I > agree :-( > > The problem with that statement is that atomic implies a global > scheduling decision. Blood, sweat and tears. Agreed - It isn't fun. Perhaps it doesn't matter anyway. Once GuC is offloading the scheduling it should be able to do a little more wrt rebalancing. Let's make it a GuC headache instead. > > Of course, with your endless scheme, scheduling is all in the purview of > the user :) Hey, don't tarnish me with that brush. I don't like it either. Actually, it's your scheme technically. I just asked for a way to enable HPC workloads, and you enthusiastically offered heartbeats So shall history be written :-) > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/2] HAX: force enable_guc=2
From: Anusha Srivatsa Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index d29ade3b7de6..f9fbb1f2fabf 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -54,7 +54,7 @@ struct drm_printer; param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, 2) \ param(int, guc_log_level, -1) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ -- 2.21.0.5.gaeb582a983 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/2] drm/i915/guc: Enable guc logging on guc log relay write
Creating and opening the GuC log relay file enables and starts
the relay potentially before the caller is ready to consume logs.
Change the behavior so that relay starts only on an explicit call
to the write function (with a value of '1'). Other values flush
the log relay as before.
v2: Style changes and fix typos. Add guc_log_relay_stop()
function. (Daniele)
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Signed-off-by: Robert M. Fosha
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 53 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_log.h | 4 +-
drivers/gpu/drm/i915/i915_debugfs.c| 22 +++--
3 files changed, 62 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index 36332064de9c..e26c7748358b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -226,7 +226,7 @@ static void guc_read_update_log_buffer(struct intel_guc_log
*log)
mutex_lock(>relay.lock);
- if (WARN_ON(!intel_guc_log_relay_enabled(log)))
+ if (WARN_ON(!intel_guc_log_relay_created(log)))
goto out_unlock;
/* Get the pointer to shared GuC log buffer */
@@ -361,6 +361,7 @@ void intel_guc_log_init_early(struct intel_guc_log *log)
{
mutex_init(>relay.lock);
INIT_WORK(>relay.flush_work, capture_logs_work);
+ log->relay.started = false;
}
static int guc_log_relay_create(struct intel_guc_log *log)
@@ -546,7 +547,7 @@ int intel_guc_log_set_level(struct intel_guc_log *log, u32
level)
return ret;
}
-bool intel_guc_log_relay_enabled(const struct intel_guc_log *log)
+bool intel_guc_log_relay_created(const struct intel_guc_log *log)
{
return log->relay.buf_addr;
}
@@ -560,7 +561,7 @@ int intel_guc_log_relay_open(struct intel_guc_log *log)
mutex_lock(>relay.lock);
- if (intel_guc_log_relay_enabled(log)) {
+ if (intel_guc_log_relay_created(log)) {
ret = -EEXIST;
goto out_unlock;
}
@@ -585,6 +586,21 @@ int intel_guc_log_relay_open(struct intel_guc_log *log)
mutex_unlock(>relay.lock);
+ return 0;
+
+out_relay:
+ guc_log_relay_destroy(log);
+out_unlock:
+ mutex_unlock(>relay.lock);
+
+ return ret;
+}
+
+int intel_guc_log_relay_start(struct intel_guc_log *log)
+{
+ if (log->relay.started)
+ return -EEXIST;
+
guc_log_enable_flush_events(log);
/*
@@ -594,14 +610,9 @@ int intel_guc_log_relay_open(struct intel_guc_log *log)
*/
queue_work(system_highpri_wq, >relay.flush_work);
- return 0;
-
-out_relay:
- guc_log_relay_destroy(log);
-out_unlock:
- mutex_unlock(>relay.lock);
+ log->relay.started = true;
- return ret;
+ return 0;
}
void intel_guc_log_relay_flush(struct intel_guc_log *log)
@@ -610,6 +621,9 @@ void intel_guc_log_relay_flush(struct intel_guc_log *log)
struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
intel_wakeref_t wakeref;
+ if (!log->relay.started)
+ return;
+
/*
* Before initiating the forceful flush, wait for any pending/ongoing
* flush to complete otherwise forceful flush may not actually happen.
@@ -623,18 +637,33 @@ void intel_guc_log_relay_flush(struct intel_guc_log *log)
guc_log_capture_logs(log);
}
-void intel_guc_log_relay_close(struct intel_guc_log *log)
+/*
+ * Stops the relay log. Called from intel_guc_log_relay_close(), so no
+ * possibility of race with start/flush since relay_write cannot race
+ * relay_close.
+ */
+static void guc_log_relay_stop(struct intel_guc_log *log)
{
struct intel_guc *guc = log_to_guc(log);
struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ if (!log->relay.started)
+ return;
+
guc_log_disable_flush_events(log);
intel_synchronize_irq(i915);
flush_work(>relay.flush_work);
+ log->relay.started = false;
+}
+
+void intel_guc_log_relay_close(struct intel_guc_log *log)
+{
+ guc_log_relay_stop(log);
+
mutex_lock(>relay.lock);
- GEM_BUG_ON(!intel_guc_log_relay_enabled(log));
+ GEM_BUG_ON(!intel_guc_log_relay_created(log));
guc_log_unmap(log);
guc_log_relay_destroy(log);
mutex_unlock(>relay.lock);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
index 6f764879acb1..c252c022c5fc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
@@ -47,6 +47,7 @@ struct intel_guc_log {
struct i915_vma *vma;
struct {
void *buf_addr;
+ bool started;
struct work_struct flush_work;
struct rchan *channel;
struct mutex lock;
@@ -65,8 +66,9
Re: [Intel-gfx] [PATCH 01/23] drm/i915/dp: Fix dsc bpp calculations, v2.
On Fri, Sep 20, 2019 at 01:42:13PM +0200, Maarten Lankhorst wrote:
> There was a integer wraparound when mode_clock became too high,
> and we didn't correct for the FEC overhead factor when dividing,
> with the calculations breaking at HBR3.
>
> As a result our calculated bpp was way too high, and the link width
> limitation never came into effect.
>
> Print out the resulting bpp calcululations as a sanity check, just
> in case we ever have to debug it later on again.
>
> We also used the wrong factor for FEC. While bspec mentions 2.4%,
> all the calculations use 1/0.972261, and the same ratio should be
> applied to data M/N as well, so use it there when FEC is enabled.
>
> Make sure we don't break hw readout, and read out FEC enable state
> and correct the DDI clock readout for the new values.
>
> Together with the next commit, this causes FEC to work correctly
> with big joiner, while also having the correct refresh rate
> reported in kms_setmode.basic.
>
> Signed-off-by: Maarten Lankhorst
> Fixes: d9218c8f6cf4 ("drm/i915/dp: Add helpers for Compressed BPP and Slice
> Count for DSC")
> Cc: # v5.0+
> Cc: Manasi Navare
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 19 +-
> drivers/gpu/drm/i915/display/intel_display.c | 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 195 ++-
> drivers/gpu/drm/i915/display/intel_dp.h | 6 +-
> 4 files changed, 128 insertions(+), 93 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 3e6394139964..1b59b852874b 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -1479,6 +1479,10 @@ static void ddi_dotclock_get(struct intel_crtc_state
> *pipe_config)
> if (pipe_config->pixel_multiplier)
> dotclock /= pipe_config->pixel_multiplier;
>
> + /* fec adds overhead to the data M/N values, correct for it */
> + if (pipe_config->fec_enable)
> + dotclock = intel_dp_fec_to_mode_clock(dotclock);
> +
> pipe_config->base.adjusted_mode.crtc_clock = dotclock;
> }
>
> @@ -4031,7 +4035,9 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
> case TRANS_DDI_MODE_SELECT_FDI:
> pipe_config->output_types |= BIT(INTEL_OUTPUT_ANALOG);
> break;
> - case TRANS_DDI_MODE_SELECT_DP_SST:
> + case TRANS_DDI_MODE_SELECT_DP_SST: {
> + struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> +
> if (encoder->type == INTEL_OUTPUT_EDP)
> pipe_config->output_types |= BIT(INTEL_OUTPUT_EDP);
> else
> @@ -4039,7 +4045,18 @@ void intel_ddi_get_config(struct intel_encoder
> *encoder,
> pipe_config->lane_count =
> ((temp & DDI_PORT_WIDTH_MASK) >> DDI_PORT_WIDTH_SHIFT)
> + 1;
> intel_dp_get_m_n(intel_crtc, pipe_config);
> +
> + if (INTEL_GEN(dev_priv) >= 11) {
> + pipe_config->fec_enable =
> + I915_READ(intel_dp->regs.dp_tp_ctl) &
> + DP_TP_CTL_FEC_ENABLE;
Side note: That looks broken for the init/resume readout.
I knew there was a reason I didn't quite like the idea of
intel_dp->regs...
> + DRM_DEBUG_KMS("[ENCODER:%d:%s] Fec status: %u\n",
> + encoder->base.base.id, encoder->base.name,
> + pipe_config->fec_enable);
> + }
> +
> break;
> + }
> case TRANS_DDI_MODE_SELECT_DP_MST:
> pipe_config->output_types |= BIT(INTEL_OUTPUT_DP_MST);
> pipe_config->lane_count =
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index e0033d99f6e3..7996864e6f7c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -12773,6 +12773,7 @@ intel_pipe_config_compare(const struct
> intel_crtc_state *current_config,
> PIPE_CONF_CHECK_BOOL(hdmi_scrambling);
> PIPE_CONF_CHECK_BOOL(hdmi_high_tmds_clock_ratio);
> PIPE_CONF_CHECK_BOOL(has_infoframe);
> + PIPE_CONF_CHECK_BOOL(fec_enable);
>
> PIPE_CONF_CHECK_BOOL_INCOMPLETE(has_audio);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index ccaf9f00b747..4dfb78dc7fa2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -76,8 +76,8 @@
> #define DP_DSC_MAX_ENC_THROUGHPUT_0 34
> #define DP_DSC_MAX_ENC_THROUGHPUT_1 40
>
> -/* DP DSC FEC Overhead factor = (100 - 2.4)/100 */
> -#define DP_DSC_FEC_OVERHEAD_FACTOR 976
> +/* DP DSC FEC Overhead factor = 1/(0.972261) */
> +#define DP_DSC_FEC_OVERHEAD_FACTOR 972261
>
> /* Compliance test status bits */
> #define
Re: [Intel-gfx] [PATCH -next] treewide: remove unused argument in lock_release()
On Fri, Sep 20, 2019 at 08:50:36AM -0400, Qian Cai wrote:
> On Fri, 2019-09-20 at 10:38 +0100, Will Deacon wrote:
> > On Thu, Sep 19, 2019 at 12:09:40PM -0400, Qian Cai wrote:
> > > Since the commit b4adfe8e05f1 ("locking/lockdep: Remove unused argument
> > > in __lock_release"), @nested is no longer used in lock_release(), so
> > > remove it from all lock_release() calls and friends.
> > >
> > > Signed-off-by: Qian Cai
> > > ---
> >
> > Although this looks fine to me at a first glance, it might be slightly
> > easier to manage if you hit {spin,rwlock,seqcount,mutex,rwsem}_release()
> > first with coccinelle scripts, and then hack lock_release() as a final
> > patch. That way it's easy to regenerate things if needed.
>
> I am not sure if it worth the extra efforts where I have to retest it on all
> architectures, and the patch is really simple, but I can certainly do that if
> you insist.
I'm not insisting, just thought it might be easier to get it merged that
way. If you prefer to go with the big diff,
Acked-by: Will Deacon
Will
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH -next] treewide: remove unused argument in lock_release()
On Thu, Sep 19, 2019 at 12:09:40PM -0400, Qian Cai wrote:
> Since the commit b4adfe8e05f1 ("locking/lockdep: Remove unused argument
> in __lock_release"), @nested is no longer used in lock_release(), so
> remove it from all lock_release() calls and friends.
>
> Signed-off-by: Qian Cai
> ---
Although this looks fine to me at a first glance, it might be slightly
easier to manage if you hit {spin,rwlock,seqcount,mutex,rwsem}_release()
first with coccinelle scripts, and then hack lock_release() as a final
patch. That way it's easy to regenerate things if needed.
Cheers,
Will
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH -next] treewide: remove unused argument in lock_release()
On Fri, 2019-09-20 at 10:38 +0100, Will Deacon wrote:
> On Thu, Sep 19, 2019 at 12:09:40PM -0400, Qian Cai wrote:
> > Since the commit b4adfe8e05f1 ("locking/lockdep: Remove unused argument
> > in __lock_release"), @nested is no longer used in lock_release(), so
> > remove it from all lock_release() calls and friends.
> >
> > Signed-off-by: Qian Cai
> > ---
>
> Although this looks fine to me at a first glance, it might be slightly
> easier to manage if you hit {spin,rwlock,seqcount,mutex,rwsem}_release()
> first with coccinelle scripts, and then hack lock_release() as a final
> patch. That way it's easy to regenerate things if needed.
I am not sure if it worth the extra efforts where I have to retest it on all
architectures, and the patch is really simple, but I can certainly do that if
you insist.
I have just confirmed the patch [1] also applied correctly to the latest
mainline, so it might be the best time just for Linus to merge it directly so it
does not introduce build errors later on?
[1]
https://lore.kernel.org/lkml/1568909380-32199-1-git-send-email-...@lca.pw/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH -next] treewide: remove unused argument in lock_release()
Since the commit b4adfe8e05f1 ("locking/lockdep: Remove unused argument
in __lock_release"), @nested is no longer used in lock_release(), so
remove it from all lock_release() calls and friends.
Signed-off-by: Qian Cai
---
drivers/gpu/drm/drm_connector.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 6 +++---
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +-
drivers/gpu/drm/i915/i915_request.c | 2 +-
drivers/tty/tty_ldsem.c | 8
fs/dcache.c | 2 +-
fs/jbd2/transaction.c | 4 ++--
fs/kernfs/dir.c | 4 ++--
fs/ocfs2/dlmglue.c| 2 +-
include/linux/jbd2.h | 2 +-
include/linux/lockdep.h | 21 ++---
include/linux/percpu-rwsem.h | 4 ++--
include/linux/rcupdate.h | 2 +-
include/linux/rwlock_api_smp.h| 16
include/linux/seqlock.h | 4 ++--
include/linux/spinlock_api_smp.h | 8
include/linux/ww_mutex.h | 2 +-
include/net/sock.h| 2 +-
kernel/bpf/stackmap.c | 2 +-
kernel/cpu.c | 2 +-
kernel/locking/lockdep.c | 3 +--
kernel/locking/mutex.c| 4 ++--
kernel/locking/rtmutex.c | 6 +++---
kernel/locking/rwsem.c| 10 +-
kernel/printk/printk.c| 10 +-
kernel/sched/core.c | 2 +-
lib/locking-selftest.c| 24
mm/memcontrol.c | 2 +-
net/core/sock.c | 2 +-
tools/lib/lockdep/include/liblockdep/common.h | 3 +--
tools/lib/lockdep/include/liblockdep/mutex.h | 2 +-
tools/lib/lockdep/include/liblockdep/rwlock.h | 2 +-
tools/lib/lockdep/preload.c | 16
33 files changed, 90 insertions(+), 93 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4c766624b20d..4a8b2e5c2af6 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -719,7 +719,7 @@ void drm_connector_list_iter_end(struct
drm_connector_list_iter *iter)
__drm_connector_put_safe(iter->conn);
spin_unlock_irqrestore(>connector_list_lock, flags);
}
- lock_release(_list_iter_dep_map, 0, _RET_IP_);
+ lock_release(_list_iter_dep_map, _RET_IP_);
}
EXPORT_SYMBOL(drm_connector_list_iter_end);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index edd21d14e64f..1a51b3598d63 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -509,14 +509,14 @@ void i915_gem_shrinker_taints_mutex(struct
drm_i915_private *i915,
I915_MM_SHRINKER, 0, _RET_IP_);
mutex_acquire(>dep_map, 0, 0, _RET_IP_);
- mutex_release(>dep_map, 0, _RET_IP_);
+ mutex_release(>dep_map, _RET_IP_);
- mutex_release(>drm.struct_mutex.dep_map, 0, _RET_IP_);
+ mutex_release(>drm.struct_mutex.dep_map, _RET_IP_);
fs_reclaim_release(GFP_KERNEL);
if (unlock)
- mutex_release(>drm.struct_mutex.dep_map, 0, _RET_IP_);
+ mutex_release(>drm.struct_mutex.dep_map, _RET_IP_);
}
#define obj_to_i915(obj__) to_i915((obj__)->base.dev)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 65b5ca74b394..7f647243b3b9 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -52,7 +52,7 @@ static inline unsigned long __timeline_mark_lock(struct
intel_context *ce)
static inline void __timeline_mark_unlock(struct intel_context *ce,
unsigned long flags)
{
- mutex_release(>timeline->mutex.dep_map, 0, _THIS_IP_);
+ mutex_release(>timeline->mutex.dep_map, _THIS_IP_);
local_irq_restore(flags);
}
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index a53777dd371c..e1f1be4d0531 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1456,7 +1456,7 @@ long i915_request_wait(struct i915_request *rq,
dma_fence_remove_callback(>fence, );
out:
- mutex_release(>engine->gt->reset.mutex.dep_map, 0, _THIS_IP_);
+ mutex_release(>engine->gt->reset.mutex.dep_map, _THIS_IP_);
trace_i915_request_wait_end(rq);
return timeout;
}
diff --git a/drivers/tty/tty_ldsem.c b/drivers/tty/tty_ldsem.c
index 60ff236a3d63..ce8291053af3 100644
---
Re: [Intel-gfx] [PATCH 12/21] drm/i915: Mark up address spaces that may need to allocate
Quoting Tvrtko Ursulin (2019-09-20 17:22:42) > > On 02/09/2019 05:02, Chris Wilson wrote: > > Since we cannot allocate underneath the vm->mutex (it is used in the > > direct-reclaim paths), we need to shift the allocations off into a > > mutexless worker with fence recursion prevention. To know when we need > > this protection, we mark up the address spaces that do allocate before > > insertion. > > > > Signed-off-by: Chris Wilson > > --- > > drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +++ > > drivers/gpu/drm/i915/i915_gem_gtt.h | 2 ++ > > 2 files changed, 5 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c > > b/drivers/gpu/drm/i915/i915_gem_gtt.c > > index 9095f017162e..56d27cf09a3d 100644 > > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c > > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c > > @@ -1500,6 +1500,7 @@ static struct i915_ppgtt *gen8_ppgtt_create(struct > > drm_i915_private *i915) > > goto err_free_pd; > > } > > > > + ppgtt->vm.bind_alloc = I915_VMA_LOCAL_BIND; > > So this is re-using I915_VMA_LOCAL_BIND as a trick? Is it clear how that > works from these call sites? Should it be called bind_alloc*s*? > bind_allocates? Or be a boolean which is converted to a trick flag in > i915_vma_bind where a comment can be put explaining the trick? Is it a trick? We need to differentiate between requests for LOCAL_BIND, GLOBAL_BIND, LOCAL_BIND | GLOBAL_BIND, for different types of vm. Then I have a plan on using the worker for GLOBAL_BIND on bsw/bxt to defer the stop_machine(). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/21] drm/i915: Coordinate i915_active with its own mutex
Quoting Tvrtko Ursulin (2019-09-20 17:14:43)
>
> On 02/09/2019 05:02, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/gt/intel_timeline_types.h
> > b/drivers/gpu/drm/i915/gt/intel_timeline_types.h
> > index 2b1baf2fcc8e..6d7ac129ce8a 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_timeline_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_timeline_types.h
> > @@ -63,7 +63,7 @@ struct intel_timeline {
> >* the request using i915_active_request_get_request_rcu(), or hold
> > the
>
> Looks like a stale comment.
>
> >* struct_mutex.
> >*/
> > - struct i915_active_request last_request;
> > + struct i915_active_fence last_request;
>
> Worth renaming to last_fence now that request naming is otherwise gone
> from i915_active?
Hmm, although i915_active is taking on more generic dma-fences, this is
still assumed to be a i915_request in a couple of places.
There's good arguments for either last_request or last_fence. If I throw
a GEM_BUG_ON(!is_request()) around, that probably swings the debate in
favour of last_request. At least tries to capture that we do assume in
some places this is i915_request.
> > void i915_active_set_exclusive(struct i915_active *ref, struct dma_fence
> > *f)
> > {
> > GEM_BUG_ON(i915_active_is_idle(ref));
> >
> > - dma_fence_get(f);
> > -
> > - rcu_read_lock();
> > - if (rcu_access_pointer(ref->excl)) {
> > - struct dma_fence *old;
> > -
> > - old = dma_fence_get_rcu_safe(>excl);
> > - if (old) {
> > - if (dma_fence_remove_callback(old, >excl_cb))
> > - atomic_dec(>count);
> > - dma_fence_put(old);
> > - }
> > - }
> > - rcu_read_unlock();
> > -
> > - atomic_inc(>count);
> > - rcu_assign_pointer(ref->excl, f);
> > + mutex_acquire(>mutex.dep_map, 0, 0, _THIS_IP_);
>
> This just lockdep annotation? Probably deserves a comment.
Yup.
>
> > + if (!__i915_active_fence_set(>excl, f))
> > + atomic_inc(>count);
>
> Refcount management is not better done from inside __i915_active_fence_set?
No, The active counting is on i915_active; i915_active_fence is just a
component.
E.g. other users want to know the fence that used to be in the
i915_active_fence:
int i915_active_fence_set(struct i915_active_fence *active,
struct i915_request *rq)
{
struct dma_fence *fence;
int err;
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
lockdep_assert_held(active->lock);
#endif
/* Must maintain ordering wrt previous active requests */
rcu_read_lock();
fence = __i915_active_fence_set(active, >fence);
if (fence)
fence = dma_fence_get_rcu(fence);
rcu_read_unlock();
if (fence) {
err = i915_request_await_dma_fence(rq, fence);
dma_fence_put(fence);
if (err)
return err;
}
return 0;
}
and similarly in __i915_request_add_to_timeline()
> > +struct dma_fence *
> > +__i915_active_fence_set(struct i915_active_fence *active,
> > + struct dma_fence *fence)
> > +{
> > + struct dma_fence *prev;
> > + unsigned long flags;
> > +
> > + /* NB: updates must be serialised by an outer timeline mutex */
> > + spin_lock_irqsave(fence->lock, flags);
> > + GEM_BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags));
> > +
> > + prev = rcu_dereference_protected(active->fence,
> > active_is_held(active));
> > + if (prev) {
> > + spin_lock_nested(prev->lock, SINGLE_DEPTH_NESTING);
> > + __list_del_entry(>cb.node);
> > + spin_unlock(prev->lock); /* serialise with prev->cb_list */
> > + prev = rcu_access_pointer(active->fence);
>
> Why it is important to re-read active->fence and does it then need a
> comment?
Because we have to serialise with the prev->cb_list. ;)
The write to active->fence is made on signaling, and that is performed
under the prev->lock. So we have to take the prev->lock ourselves to
flush any concurrent callbacks before we know whether they ran (having
taken the lock, we remove the cb from the list and so now that if it
has not run, it can not run).
> How does it tie with i915_active->count refcounting which is done on the
> basis of return value from this function?
Same as above, we have to flush the signal callback to determine whether
or not we need to increment the active count.
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 3eed2efa8d13..1aadab1cdd24 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -900,28 +900,38 @@ wait_for_timelines(struct drm_i915_private *i915,
> >
> > spin_lock_irqsave(>lock, flags);
> > list_for_each_entry(tl, >active_list, link) {
> > - struct
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Mark contents as dirty on a write fault
== Series Details ==
Series: drm/i915: Mark contents as dirty on a write fault
URL : https://patchwork.freedesktop.org/series/67000/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6928 -> Patchwork_14478
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14478 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14478, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14478/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14478:
### IGT changes ###
Possible regressions
* igt@i915_module_load@reload-with-fault-injection:
- fi-skl-6700k2: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-skl-6700k2/igt@i915_module_l...@reload-with-fault-injection.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14478/fi-skl-6700k2/igt@i915_module_l...@reload-with-fault-injection.html
Known issues
Here are the changes found in Patchwork_14478 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) +1
similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@gem_mmap_...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14478/fi-icl-u3/igt@gem_mmap_...@basic.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([fdo#111407])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14478/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@gem_ctx_switch@legacy-render:
- fi-icl-u2: [INCOMPLETE][7] ([fdo#107713] / [fdo#111381]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14478/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
* igt@i915_module_load@reload:
- fi-blb-e6850: [INCOMPLETE][9] ([fdo#107718]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-blb-e6850/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14478/fi-blb-e6850/igt@i915_module_l...@reload.html
* igt@kms_addfb_basic@addfb25-x-tiled:
- fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14478/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
Participating hosts (54 -> 46)
--
Additional (1): fi-hsw-4770r
Missing(9): fi-ilk-m540 fi-tgl-u fi-hsw-4200u fi-byt-j1900 fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6928 -> Patchwork_14478
CI-20190529: 20190529
CI_DRM_6928: 74bb5b031ca11c7036f7be21f42a73a057fc8da8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5194: 531d3d02d5e7a2a84d61b92b28fa01b822afc399 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14478: 9da082235386c02590d12100f6f40eb8002b5019 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
9da082235386 drm/i915: Mark contents as dirty on a write fault
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14478/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/21] drm/i915: Mark up address spaces that may need to allocate
On 02/09/2019 05:02, Chris Wilson wrote:
Since we cannot allocate underneath the vm->mutex (it is used in the
direct-reclaim paths), we need to shift the allocations off into a
mutexless worker with fence recursion prevention. To know when we need
this protection, we mark up the address spaces that do allocate before
insertion.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +++
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 9095f017162e..56d27cf09a3d 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1500,6 +1500,7 @@ static struct i915_ppgtt *gen8_ppgtt_create(struct
drm_i915_private *i915)
goto err_free_pd;
}
+ ppgtt->vm.bind_alloc = I915_VMA_LOCAL_BIND;
So this is re-using I915_VMA_LOCAL_BIND as a trick? Is it clear how that
works from these call sites? Should it be called bind_alloc*s*?
bind_allocates? Or be a boolean which is converted to a trick flag in
i915_vma_bind where a comment can be put explaining the trick?
Regards,
Tvrtko
ppgtt->vm.insert_entries = gen8_ppgtt_insert;
ppgtt->vm.allocate_va_range = gen8_ppgtt_alloc;
ppgtt->vm.clear_range = gen8_ppgtt_clear;
@@ -1947,6 +1948,7 @@ static struct i915_ppgtt *gen6_ppgtt_create(struct
drm_i915_private *i915)
ppgtt_init(>base, >gt);
ppgtt->base.vm.top = 1;
+ ppgtt->base.vm.bind_alloc = I915_VMA_LOCAL_BIND;
ppgtt->base.vm.allocate_va_range = gen6_alloc_va_range;
ppgtt->base.vm.clear_range = gen6_ppgtt_clear_range;
ppgtt->base.vm.insert_entries = gen6_ppgtt_insert_entries;
@@ -2578,6 +2580,7 @@ static int init_aliasing_ppgtt(struct i915_ggtt *ggtt)
goto err_ppgtt;
ggtt->alias = ppgtt;
+ ggtt->vm.bind_alloc |= ppgtt->vm.bind_alloc;
GEM_BUG_ON(ggtt->vm.vma_ops.bind_vma != ggtt_bind_vma);
ggtt->vm.vma_ops.bind_vma = aliasing_gtt_bind_vma;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 57d27898639a..007bdaf4ba00 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -305,6 +305,8 @@ struct i915_address_space {
u64 total; /* size addr space maps (ex. 2GB for ggtt) */
u64 reserved; /* size addr space reserved */
+ unsigned int bind_alloc;
+
bool closed;
struct mutex mutex; /* protects vma and our lists */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/21] drm/i915: Move idle barrier cleanup into engine-pm
On 02/09/2019 05:02, Chris Wilson wrote:
Now that we now longer need to guarantee that the active callback is
under the struct_mutex, we can lift it out of the i915_gem_park() and
into the engine parking itself.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 19 ---
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 15 +++
drivers/gpu/drm/i915/i915_active.c| 1 +
3 files changed, 16 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 92558fa47108..6e4cc177cc7a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -11,29 +11,10 @@
#include "i915_drv.h"
#include "i915_globals.h"
-static void call_idle_barriers(struct intel_engine_cs *engine)
-{
- struct llist_node *node, *next;
-
- llist_for_each_safe(node, next, llist_del_all(>barrier_tasks)) {
- struct dma_fence_cb *cb =
- container_of((struct list_head *)node,
-typeof(*cb), node);
-
- cb->func(NULL, cb);
- }
-}
-
static void i915_gem_park(struct drm_i915_private *i915)
{
- struct intel_engine_cs *engine;
- enum intel_engine_id id;
-
lockdep_assert_held(>drm.struct_mutex);
- for_each_engine(engine, i915, id)
- call_idle_barriers(engine); /* cleanup after wedging */
-
i915_vma_parked(i915);
i915_globals_park();
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 65b5ca74b394..472b2259f629 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -123,6 +123,19 @@ static bool switch_to_kernel_context(struct
intel_engine_cs *engine)
return result;
}
+static void call_idle_barriers(struct intel_engine_cs *engine)
+{
+ struct llist_node *node, *next;
+
+ llist_for_each_safe(node, next, llist_del_all(>barrier_tasks)) {
+ struct dma_fence_cb *cb =
+ container_of((struct list_head *)node,
+typeof(*cb), node);
+
+ cb->func(NULL, cb);
+ }
+}
+
static int __engine_park(struct intel_wakeref *wf)
{
struct intel_engine_cs *engine =
@@ -142,6 +155,8 @@ static int __engine_park(struct intel_wakeref *wf)
GEM_TRACE("%s\n", engine->name);
+ call_idle_barriers(engine); /* cleanup after wedging */
+
intel_engine_disarm_breadcrumbs(engine);
intel_engine_pool_park(>pool);
diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/i915_active.c
index 2e2ab8176620..dcf5bc1d87e6 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -679,6 +679,7 @@ void i915_active_acquire_barrier(struct i915_active *ref)
rb_link_node(>node, parent, p);
rb_insert_color(>node, >tree);
+ GEM_BUG_ON(!intel_engine_pm_is_awake(engine));
llist_add(barrier_to_ll(node), >barrier_tasks);
intel_engine_pm_put(engine);
}
If the rest plays out this is simple. :)
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/21] drm/i915: Coordinate i915_active with its own mutex
On 02/09/2019 05:02, Chris Wilson wrote:
Forgo the struct_mutex serialisation for i915_active, and interpose its
own mutex handling for active/retire.
This is a multi-layered sleight-of-hand. First, we had to ensure that no
active/retire callbacks accidentally inverted the mutex ordering rules,
nor assumed that they were themselves serialised by struct_mutex. More
challenging though, is the rule over updating elements of the active
rbtree. Instead of the whole i915_active now being serialised by
struct_mutex, allocations/rotations of the tree are serialised by the
i915_active.mutex and individual nodes are serialised by the caller
using the i915_timeline.mutex (we need to use nested spinlocks to
interact with the dma_fence callback lists).
The pain point here is that instead of a single mutex around execbuf, we
now have to take a mutex for active tracker (one for each vma, context,
etc) and a couple of spinlocks for each fence update. The improvement in
fine grained locking allowing for multiple concurrent clients
(eventually!) should be worth it in typical loads.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/display/intel_frontbuffer.c | 2 +-
drivers/gpu/drm/i915/display/intel_overlay.c | 5 +-
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 9 +-
drivers/gpu/drm/i915/gt/intel_context.c | 6 +-
drivers/gpu/drm/i915/gt/intel_engine_pool.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_pool.h | 2 +-
drivers/gpu/drm/i915/gt/intel_reset.c | 10 +-
drivers/gpu/drm/i915/gt/intel_timeline.c | 9 +-
.../gpu/drm/i915/gt/intel_timeline_types.h| 2 +-
drivers/gpu/drm/i915/gt/selftest_context.c| 16 +-
drivers/gpu/drm/i915/gt/selftest_lrc.c| 10 +-
.../gpu/drm/i915/gt/selftests/mock_timeline.c | 2 +-
drivers/gpu/drm/i915/gvt/scheduler.c | 3 -
drivers/gpu/drm/i915/i915_active.c| 291 +++-
drivers/gpu/drm/i915/i915_active.h| 318 --
drivers/gpu/drm/i915/i915_active_types.h | 23 +-
drivers/gpu/drm/i915/i915_gem.c | 42 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 4 +-
drivers/gpu/drm/i915/i915_request.c | 39 +--
drivers/gpu/drm/i915/i915_request.h | 1 -
drivers/gpu/drm/i915/i915_vma.c | 8 +-
drivers/gpu/drm/i915/selftests/i915_active.c | 36 +-
26 files changed, 274 insertions(+), 580 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
index 6428b8dd70d3..84b164f31895 100644
--- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
@@ -257,7 +257,7 @@ intel_frontbuffer_get(struct drm_i915_gem_object *obj)
front->obj = obj;
kref_init(>ref);
atomic_set(>bits, 0);
- i915_active_init(i915, >write,
+ i915_active_init(>write,
frontbuffer_active,
i915_active_may_sleep(frontbuffer_retire));
diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c b/drivers/gpu/drm/i915/display/intel_overlay.c
index 4f36557b3f3b..544e953342ea 100644
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -230,7 +230,7 @@ alloc_request(struct intel_overlay *overlay, void
(*fn)(struct intel_overlay *))
if (IS_ERR(rq))
return rq;
- err = i915_active_ref(>last_flip, rq->timeline, rq);
+ err = i915_active_ref(>last_flip, rq->timeline, >fence);
if (err) {
i915_request_add(rq);
return ERR_PTR(err);
@@ -1360,8 +1360,7 @@ void intel_overlay_setup(struct drm_i915_private
*dev_priv)
overlay->contrast = 75;
overlay->saturation = 146;
- i915_active_init(dev_priv,
->last_flip,
+ i915_active_init(>last_flip,
NULL, intel_overlay_last_flip_retire);
ret = get_registers(overlay, OVERLAY_NEEDS_PHYSICAL(dev_priv));
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index 9e72b42a86f5..ace50bb9ee1f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -160,7 +160,7 @@ static int move_to_active(struct i915_vma *vma, struct
i915_request *rq)
if (err)
return err;
- return i915_active_ref(>active, rq->timeline, rq);
+ return i915_active_ref(>active, rq->timeline, >fence);
}
static void clear_pages_worker(struct work_struct *work)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
Re: [Intel-gfx] [PATCH] video/hdmi: Fix AVI bar unpack
On Fri, Sep 20, 2019 at 04:58:53PM +0200, Thierry Reding wrote:
> On Thu, Sep 19, 2019 at 04:28:53PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The bar values are little endian, not big endian. The pack
> > function did it right but the unpack got it wrong. Fix it.
> >
> > Cc: sta...@vger.kernel.org
> > Cc: linux-me...@vger.kernel.org
> > Cc: Martin Bugge
> > Cc: Hans Verkuil
> > Cc: Thierry Reding
> > Cc: Mauro Carvalho Chehab
> > Fixes: 2c676f378edb ("[media] hdmi: added unpack and logging functions for
> > InfoFrames")
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/video/hdmi.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
>
> Reviewed-by: Thierry Reding
Thanks. Pushed to drm-misc-next.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 0/8] drm/i915/dp: Support for DP HDR outputs
On Thu, Sep 19, 2019 at 10:53:03PM +0300, Gwan-gyeong Mun wrote: > Support for HDR10 video was introduced in DisplayPort 1.4. > On GLK+ platform, in order to use DisplayPort HDR10, we need to support > BT.2020 colorimetry and HDR Static metadata. > It implements the CTA-861-G standard for transport of static HDR metadata. > It enables writing of HDR metadata infoframe SDP to the panel. > The HDR Metadata will be provided by userspace compositors, based on > blending policies and passed to the driver through a blob property. > And It refactors, renames and extends a function which handled vsc sdp > header and data block setup for supporting colorimetry format. > And It attaches the colorspace connector property and HDR metadata property > to a DisplayPort connector. > > These patches tested on below test environment. > Test Environment: > - Tested System: GLK and Gen11 platform. > - Monitor: Dell UP2718Q 4K HDR Monitor. > - In order to test DP HDR10, test environment uses patched Kodi-gbm, >patched Media driver and HDR10 video. > >You can find these on below. >[patched Kodi-gbm] > - repo: https://github.com/Kwiboo/xbmc/tree/drmprime-hdr >[download 4K HDR video file] > - link: https://4kmedia.org/lg-new-york-hdr-uhd-4k-demo/ >[Media Driver for GLK] > - repo https://gitlab.freedesktop.org/emersion/intel-vaapi-driver > master branch >[Media Driver for ICL] > - repo: https://github.com/harishkrupo/media-driver/tree/p010_composite > > v2: > - Add a missed blank line after function declaration. > - Remove useless parentheses. > - Minor style fix. > > v3: > - Remove not handled return values from >intel_dp_setup_hdr_metadata_infoframe_sdp(). [Uma] > - Add handling of different register size for >HDMI_PACKET_TYPE_GAMUT_METADATA on hsw_dip_data_size() for each GEN >platforms [Uma] > - Add new colorimetry options for DP 1.4a spec. [Ville] > - Separate set of colorimetry enum values for DP. [Ville] > - In order to checking output format and output colorspace on >intel_dp_needs_vsc_sdp(), it passes entire intel_crtc_state > stucture.[Ville] > - Remove a pointless variable. [Ville] > > v4: > - Add additional comments to struct drm_prop_enum_list. > - Polishing an enum string of struct drm_prop_enum_list. > > v5: > - Change definitions of DRM_MODE_COLORIMETRYs to follow HDMI prefix and >DP abbreviations. > - Add missed variables on dp_colorspaces. > - Fix typo. [Uma] > > v6: > - Addressed review comments from Ilia and Ville >Split drm_mode_create_colorspace_property() to DP and HDMI connector. >Becasue between HDMI and DP have different colorspaces, it renames >drm_mode_create_colorspace_property() function to >drm_mode_create_hdmi_colorspace_property() function for HDMI connector. >And it adds drm_mode_create_dp_colorspace_property() function for >creating of DP colorspace property. >In order to apply changed and added drm api, i915 driver has channged. > > v7: > - Fix typo [Jani Saarinen] > - Fix white space. > > v8: > - Addressed review comments from Ville >Drop colorimetries which have another way to distinguish or which would >not be used. > > v9: > - Addressed review comments from Ville > - Remove a duplicated output color space from intel_crtc_state. > - In order to handle colorspace of drm_connector_state, it moves a calling >of intel_ddi_set_pipe_settings() function into intel_ddi_pre_enable_dp() > - Split hunk into renaming and adding of code. > - Add a handling of drm_mode_create_dp_colorspace_property() to >intel_attach_colorspace_property(). > - Add WARN_ON() when buffer size if larger than register size. > - Add BUILD_BUG_ON to check a changing of struct dp_sdp size. > - Change a passed size toward write_infoframe() for DP infoframe sdp >packet for HDR static metadata. > > > Gwan-gyeong Mun (8): > drm/i915/dp: Extend program of VSC Header and DB for Colorimetry > Format > drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA > drm: Rename HDMI colorspace property creation function > drm: Add DisplayPort colorspace property creation function > drm/i915/dp: Attach colorspace property > drm/i915: Add new GMP register size for GEN11 > drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static > Metadata > drm/i915/dp: Attach HDR metadata property to DP connector Thanks. The series lgtm. I've pushed the core bits into drm-misc-next. We can proceed with the rest once those make their way back into dinq. > > drivers/gpu/drm/drm_connector.c | 101 +++-- > .../gpu/drm/i915/display/intel_connector.c| 21 +- > drivers/gpu/drm/i915/display/intel_ddi.c | 17 +- > drivers/gpu/drm/i915/display/intel_ddi.h | 3 +- > drivers/gpu/drm/i915/display/intel_display.c | 1 - > drivers/gpu/drm/i915/display/intel_display.h | 2 - > drivers/gpu/drm/i915/display/intel_dp.c | 196
Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from overtaking each other on preemption
Quoting Chris Wilson (2019-09-20 17:03:34) > Quoting Bloomfield, Jon (2019-09-20 16:50:57) > > > -Original Message- > > > From: Intel-gfx On Behalf Of > > > Tvrtko > > > Ursulin > > > Sent: Friday, September 20, 2019 8:12 AM > > > To: Chris Wilson ; > > > intel-gfx@lists.freedesktop.org > > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from > > > overtaking each other on preemption > > > > > > > > > On 20/09/2019 15:57, Chris Wilson wrote: > > > > Quoting Chris Wilson (2019-09-20 09:36:24) > > > >> Force bonded requests to run on distinct engines so that they cannot be > > > >> shuffled onto the same engine where timeslicing will reverse the order. > > > >> A bonded request will often wait on a semaphore signaled by its master, > > > >> creating an implicit dependency -- if we ignore that implicit > > > >> dependency > > > >> and allow the bonded request to run on the same engine and before its > > > >> master, we will cause a GPU hang. > > > > > > > > Thinking more, it should not directly cause a GPU hang, as the stuck > > > > request > > > > should be timesliced away, and each preemption should be enough to keep > > > > hangcheck at bay (though we have evidence it may not). So at best it > > > > runs > > > > at half-speed, at worst a third (if my model is correct). > > > > > > But I think it is still correct to do since we don't have the coupling > > > information on re-submit. Hm.. but don't we need to prevent slave from > > > changing engines as well? > > > > Unless I'm missing something, the proposal here is to set the engines in > > stone at first submission, and never change them? > > For submission here, think execution (submission to actual HW). (We have > 2 separate phases that all like to be called submit()!) s/2/3/ -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from overtaking each other on preemption
Quoting Bloomfield, Jon (2019-09-20 16:50:57) > > -Original Message- > > From: Intel-gfx On Behalf Of > > Tvrtko > > Ursulin > > Sent: Friday, September 20, 2019 8:12 AM > > To: Chris Wilson ; intel-gfx@lists.freedesktop.org > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from > > overtaking each other on preemption > > > > > > On 20/09/2019 15:57, Chris Wilson wrote: > > > Quoting Chris Wilson (2019-09-20 09:36:24) > > >> Force bonded requests to run on distinct engines so that they cannot be > > >> shuffled onto the same engine where timeslicing will reverse the order. > > >> A bonded request will often wait on a semaphore signaled by its master, > > >> creating an implicit dependency -- if we ignore that implicit dependency > > >> and allow the bonded request to run on the same engine and before its > > >> master, we will cause a GPU hang. > > > > > > Thinking more, it should not directly cause a GPU hang, as the stuck > > > request > > > should be timesliced away, and each preemption should be enough to keep > > > hangcheck at bay (though we have evidence it may not). So at best it runs > > > at half-speed, at worst a third (if my model is correct). > > > > But I think it is still correct to do since we don't have the coupling > > information on re-submit. Hm.. but don't we need to prevent slave from > > changing engines as well? > > Unless I'm missing something, the proposal here is to set the engines in > stone at first submission, and never change them? For submission here, think execution (submission to actual HW). (We have 2 separate phases that all like to be called submit()!) > If so, that does sound overly restrictive, and will prevent any kind of > rebalancing as workloads (of varying slave counts) come and go. We are only restricting this request, not the contexts. We still have balancing overall, just not instantaneous balancing if we timeslice out of this request -- we put it back onto the "same" engine and not another. Which is in some ways is less than ideal, although strictly we are only saying don't put it back onto an engine we have earmarked for our bonded request, and so we avoid contending with our parallel request reducing that to serial (and often bad) behaviour. [So at the end of this statement, I'm more happy with the restriction ;] > During the original design it was called out that the workloads should be > pre-empted atomically. That allows the entire bonding mask to be re-evaluated > at every context switch and so we can then rebalance. Still not easy to > achieve I agree :-( The problem with that statement is that atomic implies a global scheduling decision. Blood, sweat and tears. Of course, with your endless scheme, scheduling is all in the purview of the user :) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 04/10] drm/i915/dsb: Indexed register write function for DSB.
On 9/20/2019 5:48 PM, Jani Nikula wrote:
On Fri, 20 Sep 2019, Animesh Manna wrote:
DSB can program large set of data through indexed register write
(opcode 0x9) in one shot. DSB feature can be used for bulk register
programming e.g. gamma lut programming, HDR meta data programming.
v1: initial version.
v2: simplified code by using ALIGN(). (Chris)
v3: ascii table added as code comment. (Shashank)
v4: cosmetic changes done. (Shashank)
v5: reset ins_start_offset. (Jani)
v6: update ins_start_offset in inel_dsb_reg_write.
Cc: Shashank Sharma
Cc: Imre Deak
Cc: Jani Nikula
Cc: Rodrigo Vivi
Reviewed-by: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 68
drivers/gpu/drm/i915/display/intel_dsb.h | 9
2 files changed, 77 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index f94cd6dc98b6..faa853b08458 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -12,8 +12,10 @@
/* DSB opcodes. */
#define DSB_OPCODE_SHIFT 24
#define DSB_OPCODE_MMIO_WRITE 0x1
+#define DSB_OPCODE_INDEXED_WRITE 0x9
#define DSB_BYTE_EN 0xF
#define DSB_BYTE_EN_SHIFT 20
+#define DSB_REG_VALUE_MASK 0xf
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc)
@@ -83,9 +85,74 @@ void intel_dsb_put(struct intel_dsb *dsb)
mutex_unlock(>drm.struct_mutex);
dsb->cmd_buf = NULL;
dsb->free_pos = 0;
+ dsb->ins_start_offset = 0;
}
}
+void intel_dsb_indexed_reg_write(struct intel_dsb *dsb, i915_reg_t reg,
+u32 val)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ u32 *buf = dsb->cmd_buf;
+ u32 reg_val;
+
+ if (!buf) {
+ I915_WRITE(reg, val);
+ return;
+ }
+
+ if (WARN_ON(dsb->free_pos >= DSB_BUF_SIZE)) {
+ DRM_DEBUG_KMS("DSB buffer overflow\n");
+ return;
+ }
+
+ /*
+* For example the buffer will look like below for 3 dwords for auto
+* increment register:
+* ++
+* | size = 3 | offset &| value1 | value2 | value3 | zero |
+* | | opcode |||||
+* ++
+* + + +++++
+* 0 4 812 16 20 24
+* Byte
+*
+* As every instruction is 8 byte aligned the index of dsb instruction
+* will start always from even number while dealing with u32 array. If
+* we are writing odd no of dwords, Zeros will be added in the end for
+* padding.
+*/
+ reg_val = buf[dsb->ins_start_offset + 1] & DSB_REG_VALUE_MASK;
+ if (reg_val != i915_mmio_reg_offset(reg)) {
+ /* Every instruction should be 8 byte aligned. */
+ dsb->free_pos = ALIGN(dsb->free_pos, 2);
+
+ dsb->ins_start_offset = dsb->free_pos;
+
+ /* Update the size. */
+ buf[dsb->free_pos++] = 1;
+
+ /* Update the opcode and reg. */
+ buf[dsb->free_pos++] = (DSB_OPCODE_INDEXED_WRITE <<
+ DSB_OPCODE_SHIFT) |
+ i915_mmio_reg_offset(reg);
+
+ /* Update the value. */
+ buf[dsb->free_pos++] = val;
+ } else {
+ /* Update the new value. */
+ buf[dsb->free_pos++] = val;
+
+ /* Update the size. */
+ buf[dsb->ins_start_offset]++;
+ }
+
+ /* if number of data words is odd, then the last dword should be 0.*/
+ if (dsb->free_pos & 0x1)
+ buf[dsb->free_pos] = 0;
+}
+
void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val)
{
struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
@@ -102,6 +169,7 @@ void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t
reg, u32 val)
return;
}
+ dsb->ins_start_offset = dsb->free_pos;
Okay, I'm being a pedant, but that's kind of part of the job
description, I'm afraid.
What if:
intel_dsb_get()
intel_dsb_reg_write(dsb, FOO, 0);
intel_dsb_indexed_reg_write(dsb, FOO, 0);
intel_dsb_commit()
intel_dsb_put()
Hi Jani,
I am trying to think a scenario where may write the same register which
is having auto-increment capability using both intel_dsb_reg_write and
intel_dsb_indexed_reg_write.
To set the auto increment mode we may need to write a different register
to control auto-increment mode.
If there
Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from overtaking each other on preemption
Quoting Tvrtko Ursulin (2019-09-20 16:12:23) > > On 20/09/2019 15:57, Chris Wilson wrote: > > Quoting Chris Wilson (2019-09-20 09:36:24) > >> Force bonded requests to run on distinct engines so that they cannot be > >> shuffled onto the same engine where timeslicing will reverse the order. > >> A bonded request will often wait on a semaphore signaled by its master, > >> creating an implicit dependency -- if we ignore that implicit dependency > >> and allow the bonded request to run on the same engine and before its > >> master, we will cause a GPU hang. > > > > Thinking more, it should not directly cause a GPU hang, as the stuck request > > should be timesliced away, and each preemption should be enough to keep > > hangcheck at bay (though we have evidence it may not). So at best it runs > > at half-speed, at worst a third (if my model is correct). > > But I think it is still correct to do since we don't have the coupling > information on re-submit. Hm.. but don't we need to prevent slave from > changing engines as well? Yes, it still looks like a sensible enough patch (even if I am biased because I think it is cute), especially in light of how we only run the bond_execute once and do not reconfigure the execution_mask on unsubmit. Still working on the test cases to exercise timeslicing + submit/bonding. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from overtaking each other on preemption
> -Original Message- > From: Intel-gfx On Behalf Of Tvrtko > Ursulin > Sent: Friday, September 20, 2019 8:12 AM > To: Chris Wilson ; intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from > overtaking each other on preemption > > > On 20/09/2019 15:57, Chris Wilson wrote: > > Quoting Chris Wilson (2019-09-20 09:36:24) > >> Force bonded requests to run on distinct engines so that they cannot be > >> shuffled onto the same engine where timeslicing will reverse the order. > >> A bonded request will often wait on a semaphore signaled by its master, > >> creating an implicit dependency -- if we ignore that implicit dependency > >> and allow the bonded request to run on the same engine and before its > >> master, we will cause a GPU hang. > > > > Thinking more, it should not directly cause a GPU hang, as the stuck request > > should be timesliced away, and each preemption should be enough to keep > > hangcheck at bay (though we have evidence it may not). So at best it runs > > at half-speed, at worst a third (if my model is correct). > > But I think it is still correct to do since we don't have the coupling > information on re-submit. Hm.. but don't we need to prevent slave from > changing engines as well? Unless I'm missing something, the proposal here is to set the engines in stone at first submission, and never change them? If so, that does sound overly restrictive, and will prevent any kind of rebalancing as workloads (of varying slave counts) come and go. During the original design it was called out that the workloads should be pre-empted atomically. That allows the entire bonding mask to be re-evaluated at every context switch and so we can then rebalance. Still not easy to achieve I agree :-( > > Regards, > > Tvrtko > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for DSB enablement. (rev9)
== Series Details == Series: DSB enablement. (rev9) URL : https://patchwork.freedesktop.org/series/63013/ State : success == Summary == CI Bug Log - changes from CI_DRM_6928 -> Patchwork_14477 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14477/ Known issues Here are the changes found in Patchwork_14477 that come from known issues: ### IGT changes ### Issues hit * igt@gem_flink_basic@bad-open: - fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@gem_flink_ba...@bad-open.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14477/fi-icl-u3/igt@gem_flink_ba...@bad-open.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([fdo#111407]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14477/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html Possible fixes * igt@gem_ctx_switch@legacy-render: - fi-icl-u2: [INCOMPLETE][5] ([fdo#107713] / [fdo#111381]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14477/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html * igt@i915_module_load@reload: - fi-blb-e6850: [INCOMPLETE][7] ([fdo#107718]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-blb-e6850/igt@i915_module_l...@reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14477/fi-blb-e6850/igt@i915_module_l...@reload.html * igt@kms_addfb_basic@addfb25-x-tiled: - fi-icl-u3: [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10] +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14477/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 Participating hosts (54 -> 48) -- Additional (1): fi-hsw-4770r Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6928 -> Patchwork_14477 CI-20190529: 20190529 CI_DRM_6928: 74bb5b031ca11c7036f7be21f42a73a057fc8da8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5194: 531d3d02d5e7a2a84d61b92b28fa01b822afc399 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14477: 89ca6c89252aa3e8b3e3fe65ce0d39cf953e642b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 89ca6c89252a drm/i915/dsb: Documentation for DSB. 6ccd2217aa11 drm/i915/dsb: Enable DSB for gen12. dc74e0b1bce3 drm/i915/dsb: Enable gamma lut programming using DSB. f3f9d6a4f641 drm/i915/dsb: function to trigger workload execution of DSB. c6d05e53a15d drm/i915/dsb: functions to enable/disable DSB engine. 82006824a268 drm/i915/dsb: Check DSB engine status. 6cebb40b0c3d drm/i915/dsb: Indexed register write function for DSB. 32156cd99f53 drm/i915/dsb: single register write function for DSB. 5a60554c2d5d drm/i915/dsb: DSB context creation. 396d115d8cc6 drm/i915/dsb: feature flag added for display state buffer. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14477/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for DSB enablement. (rev9)
== Series Details == Series: DSB enablement. (rev9) URL : https://patchwork.freedesktop.org/series/63013/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: drm/i915/dsb: feature flag added for display state buffer. Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for DSB enablement. (rev9)
== Series Details == Series: DSB enablement. (rev9) URL : https://patchwork.freedesktop.org/series/63013/ State : warning == Summary == $ dim checkpatch origin/drm-tip 396d115d8cc6 drm/i915/dsb: feature flag added for display state buffer. 5a60554c2d5d drm/i915/dsb: DSB context creation. -:63: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #63: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 134 lines checked 32156cd99f53 drm/i915/dsb: single register write function for DSB. 6cebb40b0c3d drm/i915/dsb: Indexed register write function for DSB. 82006824a268 drm/i915/dsb: Check DSB engine status. c6d05e53a15d drm/i915/dsb: functions to enable/disable DSB engine. f3f9d6a4f641 drm/i915/dsb: function to trigger workload execution of DSB. dc74e0b1bce3 drm/i915/dsb: Enable gamma lut programming using DSB. 6ccd2217aa11 drm/i915/dsb: Enable DSB for gen12. 89ca6c89252a drm/i915/dsb: Documentation for DSB. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/23] drm/i915/dp: Fix dsc bpp calculations, v2.
== Series Details ==
Series: series starting with [01/23] drm/i915/dp: Fix dsc bpp calculations, v2.
URL : https://patchwork.freedesktop.org/series/66998/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6928 -> Patchwork_14476
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14476/
Known issues
Here are the changes found in Patchwork_14476 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724] /
[fdo#111214])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14476/fi-icl-u3/igt@i915_module_l...@reload.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([fdo#111407])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14476/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@gem_ctx_switch@legacy-render:
- fi-icl-u2: [INCOMPLETE][5] ([fdo#107713] / [fdo#111381]) ->
[PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14476/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
* igt@i915_module_load@reload:
- fi-blb-e6850: [INCOMPLETE][7] ([fdo#107718]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-blb-e6850/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14476/fi-blb-e6850/igt@i915_module_l...@reload.html
* igt@kms_addfb_basic@addfb25-x-tiled:
- fi-icl-u3: [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10] +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14476/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#105763]: https://bugs.freedesktop.org/show_bug.cgi?id=105763
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
Participating hosts (54 -> 45)
--
Additional (1): fi-hsw-4770r
Missing(10): fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-glk-dsi
fi-byt-squawks fi-bsw-cyan fi-pnv-d510 fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6928 -> Patchwork_14476
CI-20190529: 20190529
CI_DRM_6928: 74bb5b031ca11c7036f7be21f42a73a057fc8da8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5194: 531d3d02d5e7a2a84d61b92b28fa01b822afc399 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14476: 4fc8d6917d9641566f066833c6cd4a367858864a @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
4fc8d6917d96 HAX to make it work on the icelake test system
6841b8e381a7 drm/i915: Add debugfs dumping for bigjoiner.
2f481b21d19e drm/i915: Make sure watermarks work correctly with bigjoiner as
well.
00bf77afbf1c drm/i915: Make prepare_plane_fb() work with bigjoiner planes
b38045c74b32 drm/i915: Prepare atomic plane check for bigjoiner planes
fda4e645a05a drm/i915: Disable FBC in bigjoiner configuration.
a4c555a8c16c drm/i915: Add intel_update_bigjoiner handling.
dfcb59743ad5 drm/i915: Program planes in bigjoiner mode.
5c48f75472bd drm/i915: Link planes in a bigjoiner configuration.
87f053dd9d78 drm/i915: Prepare update_slave() for bigjoiner plane updates
0334bd232823 drm/i915: Make hardware readout work on i915.
fe1d38cc6ac9 drm/i915: Enable big joiner support in enable and disable
sequences.
02ae546be7ff drm/i915: Try to make bigjoiner work in atomic check.
c5ac35a82acd drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid()
11b08875cb14 drm/i915: Do not add all planes when checking scalers on glk+
35e0e945926a drm/i915: Rename planar linked plane variables
1997dbaaa507 drm/i915: Remove begin/finish_crtc_commit.
89bdbc955927 drm/i915: Get rid of crtc_state->fb_changed
fb10f9c4dae1 drm/i915: Complete sw/hw split
8fa117d4a277 drm/i915: Handle a few more cases for hw/sw split
2bb73b0ec47e drm/i915: Prepare to split crtc
Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from overtaking each other on preemption
On 20/09/2019 15:57, Chris Wilson wrote: Quoting Chris Wilson (2019-09-20 09:36:24) Force bonded requests to run on distinct engines so that they cannot be shuffled onto the same engine where timeslicing will reverse the order. A bonded request will often wait on a semaphore signaled by its master, creating an implicit dependency -- if we ignore that implicit dependency and allow the bonded request to run on the same engine and before its master, we will cause a GPU hang. Thinking more, it should not directly cause a GPU hang, as the stuck request should be timesliced away, and each preemption should be enough to keep hangcheck at bay (though we have evidence it may not). So at best it runs at half-speed, at worst a third (if my model is correct). But I think it is still correct to do since we don't have the coupling information on re-submit. Hm.. but don't we need to prevent slave from changing engines as well? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from overtaking each other on preemption
Quoting Tvrtko Ursulin (2019-09-20 15:51:35)
>
> On 20/09/2019 13:42, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-09-20 13:24:47)
> >>
> >> On 20/09/2019 09:36, Chris Wilson wrote:
> >>> Force bonded requests to run on distinct engines so that they cannot be
> >>> shuffled onto the same engine where timeslicing will reverse the order.
> >>> A bonded request will often wait on a semaphore signaled by its master,
> >>> creating an implicit dependency -- if we ignore that implicit dependency
> >>> and allow the bonded request to run on the same engine and before its
> >>> master, we will cause a GPU hang.
> >>>
> >>> We can prevent this inversion by restricting which engines we allow
> >>> ourselves to jump to upon preemption, i.e. baking in the arrangement
> >>> established at first execution. (We should also consider capturing the
> >>> implicit dependency using i915_sched_add_dependency(), but first we need
> >>> to think about the constraints that requires on the execution/retirement
> >>> ordering.)
> >>>
> >>> Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
> >>> References: ee1136908e9b ("drm/i915/execlists: Virtual engine bonding")
> >>> Signed-off-by: Chris Wilson
> >>> Cc: Mika Kuoppala
> >>> Cc: Tvrtko Ursulin
> >>> ---
> >>>drivers/gpu/drm/i915/gt/intel_lrc.c | 19 +++
> >>>1 file changed, 11 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> index a99166a2d2eb..7920649e4d87 100644
> >>> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> @@ -3755,18 +3755,21 @@ static void
> >>>virtual_bond_execute(struct i915_request *rq, struct dma_fence *signal)
> >>>{
> >>>struct virtual_engine *ve = to_virtual_engine(rq->engine);
> >>> + intel_engine_mask_t allowed, exec;
> >>>struct ve_bond *bond;
> >>>
> >>>bond = virtual_find_bond(ve, to_request(signal)->engine);
> >>> - if (bond) {
> >>> - intel_engine_mask_t old, new, cmp;
> >>> + if (!bond)
> >>> + return;
> >>>
> >>> - cmp = READ_ONCE(rq->execution_mask);
> >>> - do {
> >>> - old = cmp;
> >>> - new = cmp & bond->sibling_mask;
> >>> - } while ((cmp = cmpxchg(>execution_mask, old, new)) !=
> >>> old);
> >>> - }
> >>> + /* Restrict the bonded request to run on only the slaved engines */
> >>> + allowed = bond->sibling_mask & ~to_request(signal)->engine->mask;
> >>
> >> Hmm.. isn't it a miss on the uapi level that we allow master to be
> >> mentioned in the list of bonds? That's the only scenario where this line
> >> does something I think. So should we just forbid this setup on the uapi
> >> level?
> >
> > That's just a lot of digging!
>
> It's simple, in set_engines__bond in the bonds loop we just do "if
> (master == bond) oh_no_you_wont". Am I missing something?
There doesn't even need to be a bond, which is something I forgot
to handle. So I'm looking at something more like
static void
virtual_bond_execute(struct i915_request *rq, struct dma_fence *signal)
{
struct virtual_engine *ve = to_virtual_engine(rq->engine);
intel_engine_mask_t allowed, exec;
struct ve_bond *bond;
allowed = ~to_request(signal)->engine->mask;
bond = virtual_find_bond(ve, to_request(signal)->engine);
if (bond)
allowed &= bond->sibling_mask;
/* Restrict the bonded request to run on only the available engines */
exec = READ_ONCE(rq->execution_mask);
while (!try_cmpxchg(>execution_mask, , exec & allowed))
;
/* Prevent the master from being re-run on the bonded engines */
to_request(signal)->execution_mask &= ~allowed;
}
(The joy of trying to write a test case.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/23] drm/i915/dp: Fix dsc bpp calculations, v2.
== Series Details == Series: series starting with [01/23] drm/i915/dp: Fix dsc bpp calculations, v2. URL : https://patchwork.freedesktop.org/series/66998/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: drm/i915/dp: Fix dsc bpp calculations, v2. Okay! Commit: HAX drm/i915: Disable FEC entirely for now Okay! Commit: drm/i915: Prepare to split crtc state in uapi and hw state Okay! Commit: drm/i915: Handle a few more cases for hw/sw split Okay! Commit: drm/i915: Complete sw/hw split Okay! Commit: drm/i915: Get rid of crtc_state->fb_changed Okay! Commit: drm/i915: Remove begin/finish_crtc_commit. Okay! Commit: drm/i915: Rename planar linked plane variables Okay! Commit: drm/i915: Do not add all planes when checking scalers on glk+ Okay! Commit: drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid() Okay! Commit: drm/i915: Try to make bigjoiner work in atomic check. Okay! Commit: drm/i915: Enable big joiner support in enable and disable sequences. Okay! Commit: drm/i915: Make hardware readout work on i915. Okay! Commit: drm/i915: Prepare update_slave() for bigjoiner plane updates Okay! Commit: drm/i915: Link planes in a bigjoiner configuration. Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] video/hdmi: Fix AVI bar unpack
On Thu, Sep 19, 2019 at 04:28:53PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The bar values are little endian, not big endian. The pack
> function did it right but the unpack got it wrong. Fix it.
>
> Cc: sta...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: Martin Bugge
> Cc: Hans Verkuil
> Cc: Thierry Reding
> Cc: Mauro Carvalho Chehab
> Fixes: 2c676f378edb ("[media] hdmi: added unpack and logging functions for
> InfoFrames")
> Signed-off-by: Ville Syrjälä
> ---
> drivers/video/hdmi.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
Reviewed-by: Thierry Reding
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from overtaking each other on preemption
Quoting Chris Wilson (2019-09-20 09:36:24) > Force bonded requests to run on distinct engines so that they cannot be > shuffled onto the same engine where timeslicing will reverse the order. > A bonded request will often wait on a semaphore signaled by its master, > creating an implicit dependency -- if we ignore that implicit dependency > and allow the bonded request to run on the same engine and before its > master, we will cause a GPU hang. Thinking more, it should not directly cause a GPU hang, as the stuck request should be timesliced away, and each preemption should be enough to keep hangcheck at bay (though we have evidence it may not). So at best it runs at half-speed, at worst a third (if my model is correct). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/23] drm/i915/dp: Fix dsc bpp calculations, v2.
== Series Details ==
Series: series starting with [01/23] drm/i915/dp: Fix dsc bpp calculations, v2.
URL : https://patchwork.freedesktop.org/series/66998/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5a06a0350a83 drm/i915/dp: Fix dsc bpp calculations, v2.
30142b729b5c HAX drm/i915: Disable FEC entirely for now
-:14: WARNING:BAD_SIGN_OFF: 'Not-signed-off-by:' is the preferred signature form
#14:
Not-Signed-off-by: Maarten Lankhorst
-:40: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)
total: 1 errors, 1 warnings, 0 checks, 19 lines checked
2bb73b0ec47e drm/i915: Prepare to split crtc state in uapi and hw state
-:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#11:
- crtc, *_changed flags, event, commit, state, mode_blob,
(plane/connector/encoder)_mask.
-:2112: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#2112: FILE: drivers/gpu/drm/i915/display/intel_display.c:11201:
+ crtc_state->uapi.active = crtc_state->uapi.enable = true;
-:2810: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#2810: FILE: drivers/gpu/drm/i915/display/intel_display.c:16692:
+ crtc_state->hw.active = crtc_state->hw.enable =
-:3965: ERROR:CODE_INDENT: code indent should use tabs where possible
#3965: FILE: drivers/gpu/drm/i915/display/intel_sprite.c:211:
+^I^I^I^I new_crtc_state->uapi.event);$
-:3965: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#3965: FILE: drivers/gpu/drm/i915/display/intel_sprite.c:211:
+ drm_crtc_arm_vblank_event(>base,
+ new_crtc_state->uapi.event);
total: 1 errors, 1 warnings, 3 checks, 4348 lines checked
8fa117d4a277 drm/i915: Handle a few more cases for hw/sw split
fb10f9c4dae1 drm/i915: Complete sw/hw split
89bdbc955927 drm/i915: Get rid of crtc_state->fb_changed
1997dbaaa507 drm/i915: Remove begin/finish_crtc_commit.
35e0e945926a drm/i915: Rename planar linked plane variables
11b08875cb14 drm/i915: Do not add all planes when checking scalers on glk+
c5ac35a82acd drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid()
02ae546be7ff drm/i915: Try to make bigjoiner work in atomic check.
-:143: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#143: FILE: drivers/gpu/drm/i915/display/intel_display.c:11826:
+ intel_atomic_get_new_crtc_state(state,
+ crtc_state->bigjoiner_linked_crtc);
-:191: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#191: FILE: drivers/gpu/drm/i915/display/intel_display.c:12326:
+ crtc_state->nv12_planes = crtc_state->c8_planes =
crtc_state->update_planes = 0;
-:217: WARNING:LONG_LINE: line over 100 characters
#217: FILE: drivers/gpu/drm/i915/display/intel_display.c:13625:
+ struct intel_crtc_state *old_crtc_state, *new_crtc_state,
*slave_crtc_state, *master_crtc_state;
-:280: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#280: FILE: drivers/gpu/drm/i915/display/intel_display.c:13688:
+ slave = new_crtc_state->bigjoiner_linked_crtc =
-:290: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or
return
#290: FILE: drivers/gpu/drm/i915/display/intel_display.c:13698:
+ return -EINVAL;
+ } else {
-:348: ERROR:OPEN_BRACE: that open brace { should be on the previous line
#348: FILE: drivers/gpu/drm/i915/display/intel_display.c:13930:
+ if (new_crtc_state->bigjoiner)
+ {/* Not supported yet */}
total: 1 errors, 2 warnings, 3 checks, 391 lines checked
fe1d38cc6ac9 drm/i915: Enable big joiner support in enable and disable
sequences.
-:121: WARNING:LONG_LINE_COMMENT: line over 100 characters
#121: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:4087:
+/* Our own transcoder needs to be disabled when reading it in
intel_ddi_read_func_ctl() */
-:123: WARNING:LONG_LINE: line over 100 characters
#123: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:4089:
+ pipe_config->cpu_transcoder = (enum
transcoder)pipe_config->bigjoiner_linked_crtc->pipe;
-:231: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#231: FILE: drivers/gpu/drm/i915/display/intel_display.c:6527:
+ I915_WRITE(PIPE_MULT(cpu_transcoder),
+ pipe_config->pixel_multiplier - 1);
-:239: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#239: FILE: drivers/gpu/drm/i915/display/intel_display.c:6531:
+ intel_cpu_transcoder_set_m_n(pipe_config,
+ _config->fdi_m_n,
NULL);
-:348: WARNING:BLOCK_COMMENT_STYLE: Block comments should align the * on each
line
#348: FILE: drivers/gpu/drm/i915/display/intel_display.c:8353:
+ /*
+ *
Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from overtaking each other on preemption
On 20/09/2019 13:42, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-09-20 13:24:47)
On 20/09/2019 09:36, Chris Wilson wrote:
Force bonded requests to run on distinct engines so that they cannot be
shuffled onto the same engine where timeslicing will reverse the order.
A bonded request will often wait on a semaphore signaled by its master,
creating an implicit dependency -- if we ignore that implicit dependency
and allow the bonded request to run on the same engine and before its
master, we will cause a GPU hang.
We can prevent this inversion by restricting which engines we allow
ourselves to jump to upon preemption, i.e. baking in the arrangement
established at first execution. (We should also consider capturing the
implicit dependency using i915_sched_add_dependency(), but first we need
to think about the constraints that requires on the execution/retirement
ordering.)
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
References: ee1136908e9b ("drm/i915/execlists: Virtual engine bonding")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index a99166a2d2eb..7920649e4d87 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -3755,18 +3755,21 @@ static void
virtual_bond_execute(struct i915_request *rq, struct dma_fence *signal)
{
struct virtual_engine *ve = to_virtual_engine(rq->engine);
+ intel_engine_mask_t allowed, exec;
struct ve_bond *bond;
bond = virtual_find_bond(ve, to_request(signal)->engine);
- if (bond) {
- intel_engine_mask_t old, new, cmp;
+ if (!bond)
+ return;
- cmp = READ_ONCE(rq->execution_mask);
- do {
- old = cmp;
- new = cmp & bond->sibling_mask;
- } while ((cmp = cmpxchg(>execution_mask, old, new)) != old);
- }
+ /* Restrict the bonded request to run on only the slaved engines */
+ allowed = bond->sibling_mask & ~to_request(signal)->engine->mask;
Hmm.. isn't it a miss on the uapi level that we allow master to be
mentioned in the list of bonds? That's the only scenario where this line
does something I think. So should we just forbid this setup on the uapi
level?
That's just a lot of digging!
It's simple, in set_engines__bond in the bonds loop we just do "if
(master == bond) oh_no_you_wont". Am I missing something?
+ exec = READ_ONCE(rq->execution_mask);
+ while (!try_cmpxchg(>execution_mask, , exec & allowed))
+ ;
+
+ /* Prevent the master from being re-run on the slaved engines */
+ to_request(signal)->execution_mask &= ~allowed;
This sounds unfortunate for future scheduling. There shouldn't be a
fundamental reason why next execution for the master couldn't be on an
engine which can also be a slave. So if we have:
Note though that we do not reset the execution_mask at any point :)
That's actually harder to do than it sounds, as after the bonded
execution, they are no longer linked. :|
master
.veng=vcs0,vcs1
slave
.veng=vcs0,vcs1
.bond(master=vcs0, mask=vcs1)
.bond(master=vcs1, mask=vcs0)
This should be allowed setup but with this change it would fix the
master to only be one of the options.
It would fix it to the first one it selected and executed on. It can
still pick either vcs0 or vcs1 and the slave would then be on vcs1 or
vcs0 respectively.
Is the real problem that after preemption for timeslicing and subsequent
re-submit we miss some hooks to re-evaluate the bonded relationship?
That doesn't exist, yes. But it's more than that, as we don't have the
notion of global preemption -- we don't evaluate between engines whether
or not there are cross dependencies.
I guess looking would be hard to do any peeking from one submission
tasklet to another (different engines) to check if one of the pair is
already executing again and so to pick the other end correctly?
Hard indeed. I would throw a flag onto the request that says if you
preempt me, stop the world (intel_engine_mask_t perhaps). Even that
requires some tricks we don't yet have. But we can't touch the other
engines within the tasklet unless we can come up with a lockless
strategy (hence the strategy of punting to a supreme thread with
oversight of all engines, gah.)
I think in practical terms for media this work since they are not
setting it up like my sketch shows. So it could be just fine in practice
for current users.
I think your example works better than you think -- we just end up
concreted into our first choice and can't jump around hogs in the
system. (For example, to prove the above, we can launch two such tasks,
with a spinner as both masters and the system should get stuck on both
spinners.)
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Restrict qgv points which don't have enough bandwidth. (rev2)
== Series Details ==
Series: drm/i915: Restrict qgv points which don't have enough bandwidth. (rev2)
URL : https://patchwork.freedesktop.org/series/66993/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6928 -> Patchwork_14475
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14475/
Known issues
Here are the changes found in Patchwork_14475 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic-read-write-distinct:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@gem_mmap_...@basic-read-write-distinct.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14475/fi-icl-u3/igt@gem_mmap_...@basic-read-write-distinct.html
* igt@i915_module_load@reload:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724] /
[fdo#111214])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14475/fi-icl-u3/igt@i915_module_l...@reload.html
* igt@i915_selftest@live_gem_contexts:
- fi-skl-6770hq: [PASS][5] -> [INCOMPLETE][6] ([fdo#111519] /
[fdo#111700])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-skl-6770hq/igt@i915_selftest@live_gem_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14475/fi-skl-6770hq/igt@i915_selftest@live_gem_contexts.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][7] -> [FAIL][8] ([fdo#111045] / [fdo#111096])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14475/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@gem_ctx_switch@legacy-render:
- fi-icl-u2: [INCOMPLETE][9] ([fdo#107713] / [fdo#111381]) ->
[PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14475/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
* igt@i915_module_load@reload:
- fi-blb-e6850: [INCOMPLETE][11] ([fdo#107718]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-blb-e6850/igt@i915_module_l...@reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14475/fi-blb-e6850/igt@i915_module_l...@reload.html
* igt@kms_addfb_basic@addfb25-x-tiled:
- fi-icl-u3: [DMESG-WARN][13] ([fdo#107724]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14475/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111519]: https://bugs.freedesktop.org/show_bug.cgi?id=111519
[fdo#111700]: https://bugs.freedesktop.org/show_bug.cgi?id=111700
Participating hosts (54 -> 47)
--
Additional (1): fi-hsw-4770r
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-skl-guc fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6928 -> Patchwork_14475
CI-20190529: 20190529
CI_DRM_6928: 74bb5b031ca11c7036f7be21f42a73a057fc8da8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5194: 531d3d02d5e7a2a84d61b92b28fa01b822afc399 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14475: 58676dcb1195c94dc8f6db8978ac7651e16e5a54 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
58676dcb1195 drm/i915: Restrict qgv points which don't have enough bandwidth.
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14475/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/12] drm/i915: Document ILK+ pipe csc matrix better
On Fri, Sep 20, 2019 at 02:24:32PM +, Mun, Gwan-gyeong wrote:
> On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Add comments to explain the ilk pipe csc operation a bit better.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_color.c | 26 +---
> > --
> > 1 file changed, 21 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index 23a84dd7989f..736c42720daf 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -42,6 +42,21 @@
> >
> > #define LEGACY_LUT_LENGTH 256
> >
> > +/*
> > + * ILK+ csc matrix:
> > + *
> > + * |R/Cr| | c0 c1 c2 | ( |R/Cr| |preoff0| ) |postoff0|
> > + * |G/Y | = | c3 c4 c5 | x ( |G/Y | + |preoff1| ) + |postoff1|
> > + * |B/Cb| | c6 c7 c8 | ( |B/Cb| |preoff2| ) |postoff2|
> > + *
> > + * ILK/SNB don't have explicit post offsets, and instead
> > + * CSC_MODE_YUV_TO_RGB and CSC_BLACK_SCREEN_OFFSET are used:
> > + * CSC_MODE_YUV_TO_RGB=0 + CSC_BLACK_SCREEN_OFFSET=0 -> 1/2, 0, 1/2
> > + * CSC_MODE_YUV_TO_RGB=0 + CSC_BLACK_SCREEN_OFFSET=1 -> 1/2, 1/16,
> > 1/2
> It seems that the calculated values are assumes ITU-R BT.709 spec,
> if you don't mind, can we add some comments which is based on ITU-R
> BT.709?
> > + * CSC_MODE_YUV_TO_RGB=1 + CSC_BLACK_SCREEN_OFFSET=0 -> 0, 0, 0
> > + * CSC_MODE_YUV_TO_RGB=1 + CSC_BLACK_SCREEN_OFFSET=1 -> 1/16, 1/16,
> > 1/16
> > + */
> > +
> > /*
> > * Extract the CSC coefficient from a CTM coefficient (in U32.32
> > fixed point
> > * format). This macro takes the coefficient we want transformed and
> > the
> > @@ -59,37 +74,38 @@
> >
> > #define ILK_CSC_POSTOFF_LIMITED_RANGE (16 * (1 << 12) / 255)
> >
> > +/* Nop pre/post offsets */
> > static const u16 ilk_csc_off_zero[3] = {};
> >
> > +/* Identity matrix */
> > static const u16 ilk_csc_coeff_identity[9] = {
> > ILK_CSC_COEFF_1_0, 0, 0,
> > 0, ILK_CSC_COEFF_1_0, 0,
> > 0, 0, ILK_CSC_COEFF_1_0,
> > };
> >
> > +/* Limited range RGB post offsets */
> > static const u16 ilk_csc_postoff_limited_range[3] = {
> > ILK_CSC_POSTOFF_LIMITED_RANGE,
> > ILK_CSC_POSTOFF_LIMITED_RANGE,
> > ILK_CSC_POSTOFF_LIMITED_RANGE,
> > };
> >
> > +/* Full range RGB -> limited range RGB matrix */
> > static const u16 ilk_csc_coeff_limited_range[9] = {
> > ILK_CSC_COEFF_LIMITED_RANGE, 0, 0,
> > 0, ILK_CSC_COEFF_LIMITED_RANGE, 0,
> > 0, 0, ILK_CSC_COEFF_LIMITED_RANGE,
> > };
> >
> > -/*
> > - * These values are direct register values specified in the Bspec,
> > - * for RGB->YUV conversion matrix (colorspace BT709)
> > - */
> > +/* BT.709 full range RGB -> limited range YCbCr matrix */
The comment is here ^
> > static const u16 ilk_csc_coeff_rgb_to_ycbcr[9] = {
> > 0x1e08, 0x9cc0, 0xb528,
> > 0x2ba8, 0x09d8, 0x37e8,
> > 0xbce8, 0x9ad8, 0x1e08,
> > };
> >
> > -/* Post offset values for RGB->YCBCR conversion */
> > +/* Limited range YCbCr post offsets */
> > static const u16 ilk_csc_postoff_rgb_to_ycbcr[3] = {
> > 0x0800, 0x0100, 0x0800,
> > };
> The changes look good to me.
> Reviewed-by: Gwan-gyeong Mun
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Restrict qgv points which don't have enough bandwidth. (rev2)
== Series Details ==
Series: drm/i915: Restrict qgv points which don't have enough bandwidth. (rev2)
URL : https://patchwork.freedesktop.org/series/66993/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
58676dcb1195 drm/i915: Restrict qgv points which don't have enough bandwidth.
-:46: CHECK:LINE_SPACING: Please don't use multiple blank lines
#46: FILE: drivers/gpu/drm/i915/display/intel_bw.c:109:
+
+
-:70: WARNING:BRACES: braces {} are not necessary for single statement blocks
#70: FILE: drivers/gpu/drm/i915/display/intel_bw.c:416:
+ if (ret < 0) {
+ goto fallback;
+ }
-:80: CHECK:BRACES: Unbalanced braces around else statement
#80: FILE: drivers/gpu/drm/i915/display/intel_bw.c:426:
+ } else
total: 0 errors, 1 warnings, 2 checks, 93 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/12] drm/i915: Document ILK+ pipe csc matrix better
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add comments to explain the ilk pipe csc operation a bit better.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 26 +---
> --
> 1 file changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 23a84dd7989f..736c42720daf 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -42,6 +42,21 @@
>
> #define LEGACY_LUT_LENGTH256
>
> +/*
> + * ILK+ csc matrix:
> + *
> + * |R/Cr| | c0 c1 c2 | ( |R/Cr| |preoff0| ) |postoff0|
> + * |G/Y | = | c3 c4 c5 | x ( |G/Y | + |preoff1| ) + |postoff1|
> + * |B/Cb| | c6 c7 c8 | ( |B/Cb| |preoff2| ) |postoff2|
> + *
> + * ILK/SNB don't have explicit post offsets, and instead
> + * CSC_MODE_YUV_TO_RGB and CSC_BLACK_SCREEN_OFFSET are used:
> + * CSC_MODE_YUV_TO_RGB=0 + CSC_BLACK_SCREEN_OFFSET=0 -> 1/2, 0, 1/2
> + * CSC_MODE_YUV_TO_RGB=0 + CSC_BLACK_SCREEN_OFFSET=1 -> 1/2, 1/16,
> 1/2
It seems that the calculated values are assumes ITU-R BT.709 spec,
if you don't mind, can we add some comments which is based on ITU-R
BT.709?
> + * CSC_MODE_YUV_TO_RGB=1 + CSC_BLACK_SCREEN_OFFSET=0 -> 0, 0, 0
> + * CSC_MODE_YUV_TO_RGB=1 + CSC_BLACK_SCREEN_OFFSET=1 -> 1/16, 1/16,
> 1/16
> + */
> +
> /*
> * Extract the CSC coefficient from a CTM coefficient (in U32.32
> fixed point
> * format). This macro takes the coefficient we want transformed and
> the
> @@ -59,37 +74,38 @@
>
> #define ILK_CSC_POSTOFF_LIMITED_RANGE (16 * (1 << 12) / 255)
>
> +/* Nop pre/post offsets */
> static const u16 ilk_csc_off_zero[3] = {};
>
> +/* Identity matrix */
> static const u16 ilk_csc_coeff_identity[9] = {
> ILK_CSC_COEFF_1_0, 0, 0,
> 0, ILK_CSC_COEFF_1_0, 0,
> 0, 0, ILK_CSC_COEFF_1_0,
> };
>
> +/* Limited range RGB post offsets */
> static const u16 ilk_csc_postoff_limited_range[3] = {
> ILK_CSC_POSTOFF_LIMITED_RANGE,
> ILK_CSC_POSTOFF_LIMITED_RANGE,
> ILK_CSC_POSTOFF_LIMITED_RANGE,
> };
>
> +/* Full range RGB -> limited range RGB matrix */
> static const u16 ilk_csc_coeff_limited_range[9] = {
> ILK_CSC_COEFF_LIMITED_RANGE, 0, 0,
> 0, ILK_CSC_COEFF_LIMITED_RANGE, 0,
> 0, 0, ILK_CSC_COEFF_LIMITED_RANGE,
> };
>
> -/*
> - * These values are direct register values specified in the Bspec,
> - * for RGB->YUV conversion matrix (colorspace BT709)
> - */
> +/* BT.709 full range RGB -> limited range YCbCr matrix */
> static const u16 ilk_csc_coeff_rgb_to_ycbcr[9] = {
> 0x1e08, 0x9cc0, 0xb528,
> 0x2ba8, 0x09d8, 0x37e8,
> 0xbce8, 0x9ad8, 0x1e08,
> };
>
> -/* Post offset values for RGB->YCBCR conversion */
> +/* Limited range YCbCr post offsets */
> static const u16 ilk_csc_postoff_rgb_to_ycbcr[3] = {
> 0x0800, 0x0100, 0x0800,
> };
The changes look good to me.
Reviewed-by: Gwan-gyeong Mun
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Docs: fix incorrect use of kernel-doc format in structure description. (rev2)
== Series Details ==
Series: Docs: fix incorrect use of kernel-doc format in structure description.
(rev2)
URL : https://patchwork.freedesktop.org/series/66922/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6928 -> Patchwork_14474
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14474/
Known issues
Here are the changes found in Patchwork_14474 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_gem_contexts:
- fi-cfl-guc: [PASS][1] -> [INCOMPLETE][2] ([fdo#106070] /
[fdo#111514] / [fdo#111700])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14474/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
* igt@kms_addfb_basic@unused-pitches:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) +1
similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@kms_addfb_ba...@unused-pitches.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14474/fi-icl-u3/igt@kms_addfb_ba...@unused-pitches.html
Possible fixes
* igt@gem_ctx_switch@legacy-render:
- fi-icl-u2: [INCOMPLETE][5] ([fdo#107713] / [fdo#111381]) ->
[PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14474/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
* igt@kms_addfb_basic@addfb25-x-tiled:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] +1
similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14474/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111514]: https://bugs.freedesktop.org/show_bug.cgi?id=111514
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
[fdo#111700]: https://bugs.freedesktop.org/show_bug.cgi?id=111700
Participating hosts (54 -> 47)
--
Additional (1): fi-hsw-4770r
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-pnv-d510 fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6928 -> Patchwork_14474
CI-20190529: 20190529
CI_DRM_6928: 74bb5b031ca11c7036f7be21f42a73a057fc8da8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5194: 531d3d02d5e7a2a84d61b92b28fa01b822afc399 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14474: 29ef170afc02532d30519ca6ec280ea67a7ef443 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
29ef170afc02 drm/i915/perf: Fix use of kernel-doc format in structure members.
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14474/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add TigerLake bandwidth checking (rev5)
== Series Details == Series: drm/i915: Add TigerLake bandwidth checking (rev5) URL : https://patchwork.freedesktop.org/series/66817/ State : success == Summary == CI Bug Log - changes from CI_DRM_6928 -> Patchwork_14473 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14473/ Known issues Here are the changes found in Patchwork_14473 that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap@basic-small-bo: - fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@gem_m...@basic-small-bo.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14473/fi-icl-u3/igt@gem_m...@basic-small-bo.html * igt@i915_selftest@live_gem_contexts: - fi-cfl-guc: [PASS][3] -> [INCOMPLETE][4] ([fdo#106070] / [fdo#111514] / [fdo#111700]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14473/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([fdo#111407]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14473/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-blb-e6850: [PASS][7] -> [INCOMPLETE][8] ([fdo#107718]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14473/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html Possible fixes * igt@gem_ctx_switch@legacy-render: - fi-icl-u2: [INCOMPLETE][9] ([fdo#107713] / [fdo#111381]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14473/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html * igt@kms_addfb_basic@addfb25-x-tiled: - fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12] +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14473/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html [fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 [fdo#111514]: https://bugs.freedesktop.org/show_bug.cgi?id=111514 [fdo#111700]: https://bugs.freedesktop.org/show_bug.cgi?id=111700 Participating hosts (54 -> 46) -- Additional (1): fi-hsw-4770r Missing(9): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-hsw-4770 fi-icl-y fi-bsw-kefka fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6928 -> Patchwork_14473 CI-20190529: 20190529 CI_DRM_6928: 74bb5b031ca11c7036f7be21f42a73a057fc8da8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5194: 531d3d02d5e7a2a84d61b92b28fa01b822afc399 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14473: 81aa9b483640803e2090893356912534fd416e28 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 81aa9b483640 drm/i915: Add TigerLake bandwidth checking == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14473/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Restrict qgv points which don't have enough bandwidth.
On Fri, 2019-09-20 at 16:19 +0300, Ville Syrjälä wrote:
> On Fri, Sep 20, 2019 at 01:44:13PM +0300, Stanislav Lisovskiy wrote:
> > According to BSpec 53998, we should try to
> > restrict qgv points, which can't provide
> > enough bandwidth for desired display configuration.
> >
> > Currently we are just comparing against all of
> > those and take minimum(worst case).
> >
> > v2: Fixed wrong PCode reply mask, removed hardcoded
> > values.
> >
> > Signed-off-by: Stanislav Lisovskiy
> > ---
> > drivers/gpu/drm/i915/display/intel_bw.c | 58
> > +++--
> > drivers/gpu/drm/i915/i915_reg.h | 3 ++
> > 2 files changed, 58 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> > b/drivers/gpu/drm/i915/display/intel_bw.c
> > index cd58e47ab7b2..7653cbdb0ee4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bw.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> > @@ -90,6 +90,26 @@ static int icl_pcode_read_qgv_point_info(struct
> > drm_i915_private *dev_priv,
> > return 0;
> > }
> >
> > +static int icl_pcode_restrict_qgv_points(struct drm_i915_private
> > *dev_priv, u32 points_mask)
> > +{
> > + int ret;
> > +
> > + /* bspec says to keep retrying for at least 1 ms */
> > + ret = skl_pcode_request(dev_priv,
> > ICL_PCODE_SAGV_DE_MEM_SS_CONFIG,
> > + points_mask,
> > + GEN11_PCODE_POINTS_RESTRICTED_MASK,
> > + GEN11_PCODE_POINTS_RESTRICTED,
> > + 1);
> > +
> > + if (ret < 0) {
> > + DRM_ERROR("Failed to disable qgv points (%d)\n", ret);
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +
> > static int icl_get_qgv_points(struct drm_i915_private *dev_priv,
> > struct intel_qgv_info *qi)
> > {
> > @@ -354,7 +374,9 @@ int intel_bw_atomic_check(struct
> > intel_atomic_state *state)
> > unsigned int data_rate, max_data_rate;
> > unsigned int num_active_planes;
> > struct intel_crtc *crtc;
> > - int i;
> > + int i, ret;
> > + struct intel_qgv_info qi = {};
> > + u32 points_mask = 0;
> >
> > /* FIXME earlier gens need some checks too */
> > if (INTEL_GEN(dev_priv) < 11)
> > @@ -398,10 +420,40 @@ int intel_bw_atomic_check(struct
> > intel_atomic_state *state)
> > data_rate = intel_bw_data_rate(dev_priv, bw_state);
> > num_active_planes = intel_bw_num_active_planes(dev_priv,
> > bw_state);
> >
> > - max_data_rate = intel_max_data_rate(dev_priv,
> > num_active_planes);
> > -
> > data_rate = DIV_ROUND_UP(data_rate, 1000);
> >
> > + ret = icl_get_qgv_points(dev_priv, );
> > + if (ret < 0) {
> > + goto fallback;
>
> If we don't have that we don't have any idea about bw limits. So
> probably just return 0 here.
>
> > + }
> > +
> > + for (i = 0; i < qi.num_points; i++) {
> > + max_data_rate = icl_max_bw(dev_priv, num_active_planes,
> > i);
> > + if (max_data_rate < data_rate) {
> > + DRM_DEBUG_KMS("QGV point %d: max bw %d required
> > %d restricted\n",
> > + i, max_data_rate, data_rate);
> > + points_mask |= 1 << i;
>
> I think just marking the accepted levels in the mask would make
> things
> simpler...
>
> > + } else
> > + DRM_DEBUG_KMS("QGV point %d: max bw %d required
> > %d unrestricted\n",
> > + i, max_data_rate, data_rate);
> > + }
> > +
> > + if (points_mask >= ((1 << qi.num_points) - 1)) {
>
> ... eg. this can then just be 'if (points_mask == 0)'
>
> > + DRM_DEBUG_KMS("Could not find any suitable QGV
> > points\n");
> > + return -EINVAL;
> > + }
> > +
> > + ret = icl_pcode_restrict_qgv_points(dev_priv, points_mask);
> > + if (ret < 0) {
> > + DRM_DEBUG_KMS("Could not restrict required gqv
> > points(%d)\n", ret);
> > + goto fallback;
>
> Seems like dead code to me.
>
> We'll need to account for the SAGV yes/no in here as well. That is,
> if
> SAGV is off due to watermarks we'll need to restrict things to the
> highest QGV point only. Also using both the QGV point restriction
> pcode command and the legacy SAGV pcode command at the same time
> sounds
> rather risky to me. I suspect pcode might not expect that. So we need
> to rework this on a slightly bigger scale.
Well, I suspected that it's not going to be that easy..
Probably you mean that this has to be somehow put in sync with
intel_disable_sagv calls, so we need to mutually exclude those
and/or take into account.
>
> > + }
> > +
> > + return 0;
> > +
> > +fallback:
> > + max_data_rate = intel_max_data_rate(dev_priv,
> > num_active_planes);
> > +
> > if (data_rate > max_data_rate) {
> > DRM_DEBUG_KMS("Bandwidth %u MB/s exceeds max available
> > %d MB/s (%d active planes)\n",
> > data_rate,
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Add memory type decoding for bandwidth checking
On Fri, Sep 20, 2019 at 03:29:06PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 19, 2019 at 03:16:40PM -0700, James Ausmus wrote:
> > The memory type values have changed in TGL, so we need to translate them
> > differently than ICL.
> >
> > BSpec: 53998
> >
> > Cc: Ville Syrjälä
> > Cc: Stanislav Lisovskiy
> > Signed-off-by: James Ausmus
> > ---
> > drivers/gpu/drm/i915/display/intel_bw.c | 59 ++---
> > 1 file changed, 43 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> > b/drivers/gpu/drm/i915/display/intel_bw.c
> > index 688858ebe4d0..11224d9a6752 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bw.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> > @@ -35,22 +35,49 @@ static int icl_pcode_read_mem_global_info(struct
> > drm_i915_private *dev_priv,
> > if (ret)
> > return ret;
> >
> > - switch (val & 0xf) {
> > - case 0:
> > - qi->dram_type = INTEL_DRAM_DDR4;
> > - break;
> > - case 1:
> > - qi->dram_type = INTEL_DRAM_DDR3;
> > - break;
> > - case 2:
> > - qi->dram_type = INTEL_DRAM_LPDDR3;
> > - break;
> > - case 3:
> > - qi->dram_type = INTEL_DRAM_LPDDR3;
>
> This should be LPDDR4 actually. Doesn't really matter but would be nice
> to fix as well.
Either my git send-email config or the ML seems to be eating my original
patch mail, and it's not hitting the list, patchwork, or CI, so will
have to send a v2 anyway and I will fix this up in that.
>
> > - break;
> > - default:
> > - MISSING_CASE(val & 0xf);
> > - break;
> > + if (IS_GEN(dev_priv, 12)) {
> > + switch (val & 0xf) {
> > + case 0:
> > + qi->dram_type = INTEL_DRAM_DDR4;
> > + break;
> > + case 3:
> > + qi->dram_type = INTEL_DRAM_LPDDR4;
> > + break;
> > + case 4:
> > + qi->dram_type = INTEL_DRAM_DDR3;
> > + break;
> > + case 5:
> > + qi->dram_type = INTEL_DRAM_LPDDR3;
> > + break;
> > + case 1:
> > + case 2:
> > + /* Unimplemented */
>
> Seems pointless to list these.
Will drop in v2.
>
> The numbers match bspec. Unfortunatley I can't get tgl
> configdb to cooperate so can't double check against the
> MC register definition.
>
> Reviewed-by: Ville Syrjälä
Thanks!
-James
>
> > + /* fall through */
> > + default:
> > + MISSING_CASE(val & 0xf);
> > + break;
> > + }
> > + } else if (IS_GEN(dev_priv, 11)) {
> > + switch (val & 0xf) {
> > + case 0:
> > + qi->dram_type = INTEL_DRAM_DDR4;
> > + break;
> > + case 1:
> > + qi->dram_type = INTEL_DRAM_DDR3;
> > + break;
> > + case 2:
> > + qi->dram_type = INTEL_DRAM_LPDDR3;
> > + break;
> > + case 3:
> > + qi->dram_type = INTEL_DRAM_LPDDR3;
> > + break;
> > + default:
> > + MISSING_CASE(val & 0xf);
> > + break;
> > + }
> > + } else {
> > + MISSING_CASE(INTEL_GEN(dev_priv));
> > + qi->dram_type = INTEL_DRAM_LPDDR3; /* Conservative default */
> > }
> >
> > qi->num_channels = (val & 0xf0) >> 4;
> > --
> > 2.22.1
>
> --
> Ville Syrjälä
> Intel
___
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: save AUD_FREQ_CNTRL state at audio domain suspend
== Series Details == Series: drm/i915: save AUD_FREQ_CNTRL state at audio domain suspend URL : https://patchwork.freedesktop.org/series/66991/ State : success == Summary == CI Bug Log - changes from CI_DRM_6928 -> Patchwork_14472 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14472/ Known issues Here are the changes found in Patchwork_14472 that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap_gtt@basic-small-bo: - fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@gem_mmap_...@basic-small-bo.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14472/fi-icl-u3/igt@gem_mmap_...@basic-small-bo.html * igt@i915_module_load@reload: - fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724] / [fdo#111214]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@i915_module_l...@reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14472/fi-icl-u3/igt@i915_module_l...@reload.html * igt@kms_chamelium@dp-edid-read: - fi-kbl-7500u: [PASS][5] -> [WARN][6] ([fdo#109483]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14472/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html Possible fixes * igt@gem_ctx_switch@legacy-render: - fi-icl-u2: [INCOMPLETE][7] ([fdo#107713] / [fdo#111381]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14472/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html * igt@i915_module_load@reload: - fi-blb-e6850: [INCOMPLETE][9] ([fdo#107718]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-blb-e6850/igt@i915_module_l...@reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14472/fi-blb-e6850/igt@i915_module_l...@reload.html * igt@kms_addfb_basic@addfb25-x-tiled: - fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12] +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14472/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483 [fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214 [fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381 Participating hosts (54 -> 47) -- Additional (1): fi-hsw-4770r Missing(8): fi-ilk-m540 fi-hsw-4200u fi-skl-guc fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6928 -> Patchwork_14472 CI-20190529: 20190529 CI_DRM_6928: 74bb5b031ca11c7036f7be21f42a73a057fc8da8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5194: 531d3d02d5e7a2a84d61b92b28fa01b822afc399 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14472: 475f7d6ead72e2bbce59c1e39d52e7b8701bebaa @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 475f7d6ead72 drm/i915: save AUD_FREQ_CNTRL state at audio domain suspend == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14472/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Restrict qgv points which don't have enough bandwidth.
On Fri, Sep 20, 2019 at 01:44:13PM +0300, Stanislav Lisovskiy wrote:
> According to BSpec 53998, we should try to
> restrict qgv points, which can't provide
> enough bandwidth for desired display configuration.
>
> Currently we are just comparing against all of
> those and take minimum(worst case).
>
> v2: Fixed wrong PCode reply mask, removed hardcoded
> values.
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 58 +++--
> drivers/gpu/drm/i915/i915_reg.h | 3 ++
> 2 files changed, 58 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index cd58e47ab7b2..7653cbdb0ee4 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -90,6 +90,26 @@ static int icl_pcode_read_qgv_point_info(struct
> drm_i915_private *dev_priv,
> return 0;
> }
>
> +static int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
> u32 points_mask)
> +{
> + int ret;
> +
> + /* bspec says to keep retrying for at least 1 ms */
> + ret = skl_pcode_request(dev_priv, ICL_PCODE_SAGV_DE_MEM_SS_CONFIG,
> + points_mask,
> + GEN11_PCODE_POINTS_RESTRICTED_MASK,
> + GEN11_PCODE_POINTS_RESTRICTED,
> + 1);
> +
> + if (ret < 0) {
> + DRM_ERROR("Failed to disable qgv points (%d)\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +
> static int icl_get_qgv_points(struct drm_i915_private *dev_priv,
> struct intel_qgv_info *qi)
> {
> @@ -354,7 +374,9 @@ int intel_bw_atomic_check(struct intel_atomic_state
> *state)
> unsigned int data_rate, max_data_rate;
> unsigned int num_active_planes;
> struct intel_crtc *crtc;
> - int i;
> + int i, ret;
> + struct intel_qgv_info qi = {};
> + u32 points_mask = 0;
>
> /* FIXME earlier gens need some checks too */
> if (INTEL_GEN(dev_priv) < 11)
> @@ -398,10 +420,40 @@ int intel_bw_atomic_check(struct intel_atomic_state
> *state)
> data_rate = intel_bw_data_rate(dev_priv, bw_state);
> num_active_planes = intel_bw_num_active_planes(dev_priv, bw_state);
>
> - max_data_rate = intel_max_data_rate(dev_priv, num_active_planes);
> -
> data_rate = DIV_ROUND_UP(data_rate, 1000);
>
> + ret = icl_get_qgv_points(dev_priv, );
> + if (ret < 0) {
> + goto fallback;
If we don't have that we don't have any idea about bw limits. So
probably just return 0 here.
> + }
> +
> + for (i = 0; i < qi.num_points; i++) {
> + max_data_rate = icl_max_bw(dev_priv, num_active_planes, i);
> + if (max_data_rate < data_rate) {
> + DRM_DEBUG_KMS("QGV point %d: max bw %d required %d
> restricted\n",
> + i, max_data_rate, data_rate);
> + points_mask |= 1 << i;
I think just marking the accepted levels in the mask would make things
simpler...
> + } else
> + DRM_DEBUG_KMS("QGV point %d: max bw %d required %d
> unrestricted\n",
> + i, max_data_rate, data_rate);
> + }
> +
> + if (points_mask >= ((1 << qi.num_points) - 1)) {
... eg. this can then just be 'if (points_mask == 0)'
> + DRM_DEBUG_KMS("Could not find any suitable QGV points\n");
> + return -EINVAL;
> + }
> +
> + ret = icl_pcode_restrict_qgv_points(dev_priv, points_mask);
> + if (ret < 0) {
> + DRM_DEBUG_KMS("Could not restrict required gqv points(%d)\n",
> ret);
> + goto fallback;
Seems like dead code to me.
We'll need to account for the SAGV yes/no in here as well. That is, if
SAGV is off due to watermarks we'll need to restrict things to the
highest QGV point only. Also using both the QGV point restriction
pcode command and the legacy SAGV pcode command at the same time sounds
rather risky to me. I suspect pcode might not expect that. So we need
to rework this on a slightly bigger scale.
> + }
> +
> + return 0;
> +
> +fallback:
> + max_data_rate = intel_max_data_rate(dev_priv, num_active_planes);
> +
> if (data_rate > max_data_rate) {
> DRM_DEBUG_KMS("Bandwidth %u MB/s exceeds max available %d MB/s
> (%d active planes)\n",
> data_rate, max_data_rate, num_active_planes);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index bf37ecebc82f..fe327fee8781 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8845,6 +8845,7 @@ enum {
> #define ICL_PCODE_MEM_SUBSYSYSTEM_INFO 0xd
> #define ICL_PCODE_MEM_SS_READ_GLOBAL_INFO(0x0 << 8)
> #define ICL_PCODE_MEM_SS_READ_QGV_POINT_INFO(point)
[Intel-gfx] status of the " CRTC background color" series
Hi all, Any update on this series ? Last time I looked, everything looked ready and waiting to be merged. JJ ___ 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: Prevent bonded requests from overtaking each other on preemption
== Series Details == Series: drm/i915: Prevent bonded requests from overtaking each other on preemption URL : https://patchwork.freedesktop.org/series/66990/ State : success == Summary == CI Bug Log - changes from CI_DRM_6928 -> Patchwork_14471 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14471/ Known issues Here are the changes found in Patchwork_14471 that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_switch@legacy-render: - fi-bxt-dsi: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927] / [fdo#111381]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14471/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([fdo#111407]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14471/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html * igt@prime_self_import@basic-with_fd_dup: - fi-icl-u3: [PASS][5] -> [DMESG-WARN][6] ([fdo#107724]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@prime_self_import@basic-with_fd_dup.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14471/fi-icl-u3/igt@prime_self_import@basic-with_fd_dup.html Possible fixes * igt@gem_ctx_switch@legacy-render: - fi-icl-u2: [INCOMPLETE][7] ([fdo#107713] / [fdo#111381]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14471/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html * igt@i915_module_load@reload: - fi-blb-e6850: [INCOMPLETE][9] ([fdo#107718]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-blb-e6850/igt@i915_module_l...@reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14471/fi-blb-e6850/igt@i915_module_l...@reload.html * igt@kms_addfb_basic@addfb25-x-tiled: - fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12] +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14471/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 Participating hosts (54 -> 48) -- Additional (1): fi-hsw-4770r Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6928 -> Patchwork_14471 CI-20190529: 20190529 CI_DRM_6928: 74bb5b031ca11c7036f7be21f42a73a057fc8da8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5194: 531d3d02d5e7a2a84d61b92b28fa01b822afc399 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14471: 7885378114aefe9decb3c6ea2f10b575ed807d98 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 7885378114ae drm/i915: Prevent bonded requests from overtaking each other on preemption == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14471/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/12] drm/i915: Fix AVI infoframe quantization range for YCbCr output
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We're configuring the AVI infoframe quantization range bits as if
> we're always transmitting RGB pixels. Let's fix this so that we
> correctly indicate limited range YCC quantization range when
> transmitting YCbCr instead.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 9bf28de10401..b8100cf21dd0 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -724,11 +724,16 @@ intel_hdmi_compute_avi_infoframe(struct
> intel_encoder *encoder,
>
> drm_hdmi_avi_infoframe_colorspace(frame, conn_state);
>
> - drm_hdmi_avi_infoframe_quant_range(frame, connector,
> -adjusted_mode,
> -crtc_state-
> >limited_color_range ?
> -HDMI_QUANTIZATION_RANGE_LIMI
> TED :
> -HDMI_QUANTIZATION_RANGE_FULL
> );
> + if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_RGB) {
> + drm_hdmi_avi_infoframe_quant_range(frame, connector,
> +adjusted_mode,
> +crtc_state-
> >limited_color_range ?
> +HDMI_QUANTIZATION_RA
> NGE_LIMITED :
> +HDMI_QUANTIZATION_RA
> NGE_FULL);
> + } else {
> + frame->quantization_range =
> HDMI_QUANTIZATION_RANGE_DEFAULT;
> + frame->ycc_quantization_range =
> HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
> + }
>
> drm_hdmi_avi_infoframe_content_type(frame, conn_state);
>
The changes look good to me.
Reviewed-by: Gwan-gyeong Mun
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/2] drm/i915/uc: Update HuC firmware naming convention and load latest HuC
== Series Details == Series: series starting with [CI,1/2] drm/i915/uc: Update HuC firmware naming convention and load latest HuC URL : https://patchwork.freedesktop.org/series/66955/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6925_full -> Patchwork_14466_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14466_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14466_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_14466_full: ### IGT changes ### Possible regressions * igt@i915_suspend@debugfs-reader: - shard-iclb: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-iclb5/igt@i915_susp...@debugfs-reader.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-iclb4/igt@i915_susp...@debugfs-reader.html Known issues Here are the changes found in Patchwork_14466_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +14 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-kbl2/igt@gem_ctx_isolat...@rcs0-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-kbl2/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#110854]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-iclb4/igt@gem_exec_balan...@smoke.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-iclb7/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#111325]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-iclb3/igt@gem_exec_sched...@preempt-other-chain-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +16 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-iclb1/igt@gem_exec_sched...@preempt-queue-bsd1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-iclb3/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +10 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-apl2/igt@gem_workarou...@suspend-resume-context.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-apl1/igt@gem_workarou...@suspend-resume-context.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-skl: [PASS][13] -> [SKIP][14] ([fdo#109271]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-skl10/igt@i915_pm_rc6_reside...@rc6-accuracy.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-skl5/igt@i915_pm_rc6_reside...@rc6-accuracy.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#105363]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-skl1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-skl6/igt@kms_f...@flip-vs-expired-vblank-interruptible.html - shard-glk: [PASS][17] -> [FAIL][18] ([fdo#105363]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-glk5/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-glk1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([fdo#109507]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-skl6/igt@kms_f...@flip-vs-suspend-interruptible.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-skl4/igt@kms_f...@flip-vs-suspend-interruptible.html - shard-hsw: [PASS][21] -> [INCOMPLETE][22] ([fdo#103540]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6925/shard-hsw1/igt@kms_f...@flip-vs-suspend-interruptible.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14466/shard-hsw2/igt@kms_f...@flip-vs-suspend-interruptible.html *
Re: [Intel-gfx] [PATCH] drm/i915: Prevent bonded requests from overtaking each other on preemption
Quoting Tvrtko Ursulin (2019-09-20 13:24:47)
>
> On 20/09/2019 09:36, Chris Wilson wrote:
> > Force bonded requests to run on distinct engines so that they cannot be
> > shuffled onto the same engine where timeslicing will reverse the order.
> > A bonded request will often wait on a semaphore signaled by its master,
> > creating an implicit dependency -- if we ignore that implicit dependency
> > and allow the bonded request to run on the same engine and before its
> > master, we will cause a GPU hang.
> >
> > We can prevent this inversion by restricting which engines we allow
> > ourselves to jump to upon preemption, i.e. baking in the arrangement
> > established at first execution. (We should also consider capturing the
> > implicit dependency using i915_sched_add_dependency(), but first we need
> > to think about the constraints that requires on the execution/retirement
> > ordering.)
> >
> > Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
> > References: ee1136908e9b ("drm/i915/execlists: Virtual engine bonding")
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 19 +++
> > 1 file changed, 11 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index a99166a2d2eb..7920649e4d87 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -3755,18 +3755,21 @@ static void
> > virtual_bond_execute(struct i915_request *rq, struct dma_fence *signal)
> > {
> > struct virtual_engine *ve = to_virtual_engine(rq->engine);
> > + intel_engine_mask_t allowed, exec;
> > struct ve_bond *bond;
> >
> > bond = virtual_find_bond(ve, to_request(signal)->engine);
> > - if (bond) {
> > - intel_engine_mask_t old, new, cmp;
> > + if (!bond)
> > + return;
> >
> > - cmp = READ_ONCE(rq->execution_mask);
> > - do {
> > - old = cmp;
> > - new = cmp & bond->sibling_mask;
> > - } while ((cmp = cmpxchg(>execution_mask, old, new)) !=
> > old);
> > - }
> > + /* Restrict the bonded request to run on only the slaved engines */
> > + allowed = bond->sibling_mask & ~to_request(signal)->engine->mask;
>
> Hmm.. isn't it a miss on the uapi level that we allow master to be
> mentioned in the list of bonds? That's the only scenario where this line
> does something I think. So should we just forbid this setup on the uapi
> level?
That's just a lot of digging!
> > + exec = READ_ONCE(rq->execution_mask);
> > + while (!try_cmpxchg(>execution_mask, , exec & allowed))
> > + ;
> > +
> > + /* Prevent the master from being re-run on the slaved engines */
> > + to_request(signal)->execution_mask &= ~allowed;
>
> This sounds unfortunate for future scheduling. There shouldn't be a
> fundamental reason why next execution for the master couldn't be on an
> engine which can also be a slave. So if we have:
Note though that we do not reset the execution_mask at any point :)
That's actually harder to do than it sounds, as after the bonded
execution, they are no longer linked. :|
> master
>.veng=vcs0,vcs1
> slave
>.veng=vcs0,vcs1
>.bond(master=vcs0, mask=vcs1)
>.bond(master=vcs1, mask=vcs0)
>
> This should be allowed setup but with this change it would fix the
> master to only be one of the options.
It would fix it to the first one it selected and executed on. It can
still pick either vcs0 or vcs1 and the slave would then be on vcs1 or
vcs0 respectively.
> Is the real problem that after preemption for timeslicing and subsequent
> re-submit we miss some hooks to re-evaluate the bonded relationship?
That doesn't exist, yes. But it's more than that, as we don't have the
notion of global preemption -- we don't evaluate between engines whether
or not there are cross dependencies.
> I guess looking would be hard to do any peeking from one submission
> tasklet to another (different engines) to check if one of the pair is
> already executing again and so to pick the other end correctly?
Hard indeed. I would throw a flag onto the request that says if you
preempt me, stop the world (intel_engine_mask_t perhaps). Even that
requires some tricks we don't yet have. But we can't touch the other
engines within the tasklet unless we can come up with a lockless
strategy (hence the strategy of punting to a supreme thread with
oversight of all engines, gah.)
> I think in practical terms for media this work since they are not
> setting it up like my sketch shows. So it could be just fine in practice
> for current users.
I think your example works better than you think -- we just end up
concreted into our first choice and can't jump around hogs in the
system. (For example, to prove the above, we can launch two such
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Prevent bonded requests from overtaking each other on preemption
== Series Details ==
Series: drm/i915: Prevent bonded requests from overtaking each other on
preemption
URL : https://patchwork.freedesktop.org/series/66990/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7885378114ae drm/i915: Prevent bonded requests from overtaking each other on
preemption
-:22: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit ee1136908e9b
("drm/i915/execlists: Virtual engine bonding")'
#22:
References: ee1136908e9b ("drm/i915/execlists: Virtual engine bonding")
total: 1 errors, 0 warnings, 0 checks, 29 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for mdev based hardware virtio offloading support
== Series Details == Series: mdev based hardware virtio offloading support URL : https://patchwork.freedesktop.org/series/66989/ State : success == Summary == CI Bug Log - changes from CI_DRM_6928 -> Patchwork_14470 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14470/ Known issues Here are the changes found in Patchwork_14470 that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap_gtt@basic-short: - fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@gem_mmap_...@basic-short.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14470/fi-icl-u3/igt@gem_mmap_...@basic-short.html * igt@i915_selftest@live_gem_contexts: - fi-skl-guc: [PASS][3] -> [INCOMPLETE][4] ([fdo#111700]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-skl-guc/igt@i915_selftest@live_gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14470/fi-skl-guc/igt@i915_selftest@live_gem_contexts.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([fdo#111407]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14470/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html Possible fixes * igt@gem_ctx_switch@legacy-render: - fi-icl-u2: [INCOMPLETE][7] ([fdo#107713] / [fdo#111381]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14470/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html * igt@i915_module_load@reload: - fi-blb-e6850: [INCOMPLETE][9] ([fdo#107718]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-blb-e6850/igt@i915_module_l...@reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14470/fi-blb-e6850/igt@i915_module_l...@reload.html * igt@kms_addfb_basic@addfb25-x-tiled: - fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12] +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6928/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14470/fi-icl-u3/igt@kms_addfb_ba...@addfb25-x-tiled.html [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 [fdo#111700]: https://bugs.freedesktop.org/show_bug.cgi?id=111700 Participating hosts (54 -> 48) -- Additional (1): fi-hsw-4770r Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6928 -> Patchwork_14470 CI-20190529: 20190529 CI_DRM_6928: 74bb5b031ca11c7036f7be21f42a73a057fc8da8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5194: 531d3d02d5e7a2a84d61b92b28fa01b822afc399 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14470: 822c68b1ca1845b6e2a38ae71547e9d9b4a5fadb @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 822c68b1ca18 docs: Sample driver to demonstrate how to implement virtio-mdev framework 17f868b5d9a4 vringh: fix copy direction of vringh_iov_push_kern() 61e824bf250a virtio: introudce a mdev based transport 7bbada3ad14d mdev: introduce virtio device and its device ops 8efae9b60a78 mdev: introduce device specific ops 32afcef2acff mdev: class id support == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14470/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Mark contents as dirty on a write fault
Quoting Chris Wilson (2019-09-20 13:22:13)
> Quoting Chris Wilson (2019-09-20 13:18:21)
> > Since dropping the set-to-gtt-domain in commit a679f58d0510 ("drm/i915:
> > Flush pages on acquisition"), we no longer mark the contents as dirty on
> > a write fault. This has the issue of us then not marking the pages as
> > dirty on releasing the buffer, which means the contents are not written
> > out to the swap device (should we ever pick that buffer as a victim).
> > Notably, this is visible in the dumb buffer interface used for cursors.
> > Having updated the cursor contents via mmap, and swapped away, if the
> > shrinker should evict the old cursor, upon next reuse, the cursor would
> > be invisible.
>
> Hmm, I think the dumb interface may be missing a few steps around the
> place to ensure the contents are flushed.
No, it's fine. We do the flush in pinning pages, the only thing that was
dropped was then marking the content as dirty.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Add memory type decoding for bandwidth checking
On Thu, Sep 19, 2019 at 03:16:40PM -0700, James Ausmus wrote:
> The memory type values have changed in TGL, so we need to translate them
> differently than ICL.
>
> BSpec: 53998
>
> Cc: Ville Syrjälä
> Cc: Stanislav Lisovskiy
> Signed-off-by: James Ausmus
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 59 ++---
> 1 file changed, 43 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 688858ebe4d0..11224d9a6752 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -35,22 +35,49 @@ static int icl_pcode_read_mem_global_info(struct
> drm_i915_private *dev_priv,
> if (ret)
> return ret;
>
> - switch (val & 0xf) {
> - case 0:
> - qi->dram_type = INTEL_DRAM_DDR4;
> - break;
> - case 1:
> - qi->dram_type = INTEL_DRAM_DDR3;
> - break;
> - case 2:
> - qi->dram_type = INTEL_DRAM_LPDDR3;
> - break;
> - case 3:
> - qi->dram_type = INTEL_DRAM_LPDDR3;
This should be LPDDR4 actually. Doesn't really matter but would be nice
to fix as well.
> - break;
> - default:
> - MISSING_CASE(val & 0xf);
> - break;
> + if (IS_GEN(dev_priv, 12)) {
> + switch (val & 0xf) {
> + case 0:
> + qi->dram_type = INTEL_DRAM_DDR4;
> + break;
> + case 3:
> + qi->dram_type = INTEL_DRAM_LPDDR4;
> + break;
> + case 4:
> + qi->dram_type = INTEL_DRAM_DDR3;
> + break;
> + case 5:
> + qi->dram_type = INTEL_DRAM_LPDDR3;
> + break;
> + case 1:
> + case 2:
> + /* Unimplemented */
Seems pointless to list these.
The numbers match bspec. Unfortunatley I can't get tgl
configdb to cooperate so can't double check against the
MC register definition.
Reviewed-by: Ville Syrjälä
> + /* fall through */
> + default:
> + MISSING_CASE(val & 0xf);
> + break;
> + }
> + } else if (IS_GEN(dev_priv, 11)) {
> + switch (val & 0xf) {
> + case 0:
> + qi->dram_type = INTEL_DRAM_DDR4;
> + break;
> + case 1:
> + qi->dram_type = INTEL_DRAM_DDR3;
> + break;
> + case 2:
> + qi->dram_type = INTEL_DRAM_LPDDR3;
> + break;
> + case 3:
> + qi->dram_type = INTEL_DRAM_LPDDR3;
> + break;
> + default:
> + MISSING_CASE(val & 0xf);
> + break;
> + }
> + } else {
> + MISSING_CASE(INTEL_GEN(dev_priv));
> + qi->dram_type = INTEL_DRAM_LPDDR3; /* Conservative default */
> }
>
> qi->num_channels = (val & 0xf0) >> 4;
> --
> 2.22.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
