[Intel-gfx] [PATCH] drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017 (v2)
This fixes a problem found on the MacBookPro 2017 Retina panel.
The panel reports 10 bpc color depth in its EDID, and the
firmware chooses link settings at boot which support enough
bandwidth for 10 bpc (324000 kbit/sec = multiplier 0xc),
but the DP_MAX_LINK_RATE dpcd register only reports
2.7 Gbps (multiplier value 0xa) as possible, in direct
contradiction of what the firmware successfully set up.
This restricts the panel to 8 bpc, not providing the full
color depth of the panel.
This patch adds a quirk specific to the MBP 2017 15" Retina
panel to add the additiional 324000 kbps link rate during
edp setup.
Link to previous discussion of a different attempted fix
with Ville and Jani:
https://patchwork.kernel.org/patch/11325935/
v2: Follow Jani's proposal of defining quirk_rates[] instead
of just appending 324000. This for better clarity.
Signed-off-by: Mario Kleiner
Tested-by: Mario Kleiner
Cc: Ville Syrjälä
Cc: Jani Nikula
---
drivers/gpu/drm/drm_dp_helper.c | 2 ++
drivers/gpu/drm/i915/display/intel_dp.c | 11 +++
include/drm/drm_dp_helper.h | 7 +++
3 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 5a103e9b3c86..36a371c016cb 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1179,6 +1179,8 @@ static const struct dpcd_quirk dpcd_quirk_list[] = {
{ OUI(0x00, 0x00, 0x00), DEVICE_ID('C', 'H', '7', '5', '1', '1'),
false, BIT(DP_DPCD_QUIRK_NO_SINK_COUNT) },
/* Synaptics DP1.4 MST hubs can support DSC without virtual DPCD */
{ OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true,
BIT(DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) },
+ /* Apple MacBookPro 2017 15 inch eDP Retina panel reports too low
DP_MAX_LINK_RATE */
+ { OUI(0x00, 0x10, 0xfa), DEVICE_ID(101, 68, 21, 101, 98, 97), false,
BIT(DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS) },
};
#undef OUI
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4074d83b1a5f..c0d2c70b04fb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -169,6 +169,17 @@ static void intel_dp_set_sink_rates(struct intel_dp
*intel_dp)
};
int i, max_rate;
+ if (drm_dp_has_quirk(&intel_dp->desc,
+DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS)) {
+ /* Needed, e.g., for Apple MBP 2017, 15 inch eDP Retina panel */
+ static const int quirk_rates[] = { 162000, 27, 324000 };
+
+ memcpy(intel_dp->sink_rates, quirk_rates, sizeof(quirk_rates));
+ intel_dp->num_sink_rates = ARRAY_SIZE(quirk_rates);
+
+ return;
+ }
+
max_rate =
drm_dp_bw_code_to_link_rate(intel_dp->dpcd[DP_MAX_LINK_RATE]);
for (i = 0; i < ARRAY_SIZE(dp_rates); i++) {
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 262faf9e5e94..4b86a1f2a559 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1532,6 +1532,13 @@ enum drm_dp_quirk {
* The DSC caps can be read from the physical aux instead.
*/
DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD,
+ /**
+* @DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS:
+*
+* The device supports a link rate of 3.24 Gbps (multiplier 0xc) despite
+* the DP_MAX_LINK_RATE register reporting a lower max multiplier.
+*/
+ DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS,
};
/**
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017
On Wed, Mar 4, 2020 at 4:32 PM Jani Nikula wrote:
>
> On Sat, 29 Feb 2020, Mario Kleiner wrote:
> > This fixes a problem found on the MacBookPro 2017 Retina panel.
> >
> > The panel reports 10 bpc color depth in its EDID, and the
> > firmware chooses link settings at boot which support enough
> > bandwidth for 10 bpc (324000 kbit/sec = multiplier 0xc),
> > but the DP_MAX_LINK_RATE dpcd register only reports
> > 2.7 Gbps (multiplier value 0xa) as possible, in direct
> > contradiction of what the firmware successfully set up.
> >
> > This restricts the panel to 8 bpc, not providing the full
> > color depth of the panel.
> >
> > This patch adds a quirk specific to the MBP 2017 15" Retina
> > panel to add the additiional 324000 kbps link rate during
> > edp setup.
> >
> > Link to previous discussion of a different attempted fix
> > with Ville and Jani:
> >
> > https://patchwork.kernel.org/patch/11325935/
> >
> > Signed-off-by: Mario Kleiner
> > Cc: Ville Syrjälä
> > Cc: Jani Nikula
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 2 ++
> > drivers/gpu/drm/i915/display/intel_dp.c | 7 +++
> > include/drm/drm_dp_helper.h | 7 +++
> > 3 files changed, 16 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 5a103e9b3c86..36a371c016cb 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -1179,6 +1179,8 @@ static const struct dpcd_quirk dpcd_quirk_list[] = {
> > { OUI(0x00, 0x00, 0x00), DEVICE_ID('C', 'H', '7', '5', '1', '1'),
> > false, BIT(DP_DPCD_QUIRK_NO_SINK_COUNT) },
> > /* Synaptics DP1.4 MST hubs can support DSC without virtual DPCD */
> > { OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true,
> > BIT(DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) },
> > + /* Apple MacBookPro 2017 15 inch eDP Retina panel reports too low
> > DP_MAX_LINK_RATE */
> > + { OUI(0x00, 0x10, 0xfa), DEVICE_ID(101, 68, 21, 101, 98, 97), false,
> > BIT(DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS) },
> > };
> >
> > #undef OUI
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 4074d83b1a5f..1f6bd659ad41 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -178,6 +178,13 @@ static void intel_dp_set_sink_rates(struct intel_dp
> > *intel_dp)
> > }
> >
> > intel_dp->num_sink_rates = i;
> > +
> > + if (drm_dp_has_quirk(&intel_dp->desc,
> > + DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS)) {
> > + /* Needed for Apple MBP 2017, 15 inch eDP Retina panel */
> > + intel_dp->sink_rates[i] = 324000;
> > + intel_dp->num_sink_rates++;
> > + }
>
> If we can isolate the quirk to this one function, I'll be happy. \o/
>
Me too \o/ - Patch v2 is out, following your proposal, retested on the
machine, works. cat ... i915_display_info reports a pipe depth of 30
bpp, instead of 24 bpp.
I didn't add a stable tag, but wonder if a cc stable tag could be
added by you, if you think it is minimal enough, to get it also into
the kernels for the spring distro updates. In any case, case closed.
Thanks for the review,
-mario
> However, even if this might work on said machine, I'd prefer it if we
> didn't give the idea that you could just append a value in sink_rates
> (it must be sorted). How about putting something like this in the
> beginning of the function, to be a bit more explicit:
>
> if (quirk) {
> static const int quirk_rates[] = { 162000, 27, 324000 };
>
> memcpy(intel_dp->sink_rates, quirk_rates,
> sizeof(quirk_rates));
> intel_dp->num_sink_rates = ARRAY_SIZE(quirk_rates);
>
> return;
> }
>
> BR,
> Jani.
>
> > }
> >
> > /* Get length of rates array potentially limited by max_rate. */
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index 262faf9e5e94..4b86a1f2a559 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -1532,6 +1532,13 @@ enum drm_dp_quirk {
> >* The DSC caps can be read from the physical aux instead.
> >*/
> > DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD,
> > + /**
> > + * @DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS:
> > + *
> > + * The device supports a link rate of 3.24 Gbps (multiplier 0xc)
> > despite
> > + * the DP_MAX_LINK_RATE register reporting a lower max multiplier.
> > + */
> > + DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS,
> > };
> >
> > /**
>
> --
> Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 07/20] drm/i915: Unify the low level dbuf code
On Wed, 2020-03-04 at 20:30 +0200, Ville Syrjälä wrote: > On Wed, Mar 04, 2020 at 05:23:05PM +, Lisovskiy, Stanislav wrote: > > > > > - /* If 2nd DBuf slice required, enable it here */ > > >if (INTEL_GEN(dev_priv) >= 11 && slices_union != > > > hw_enabled_slices) > > > - icl_dbuf_slices_update(dev_priv, slices_union); > > > + gen9_dbuf_slices_update(dev_priv, slices_union); > > > } > > > static void icl_dbuf_slice_post_update(struct intel_atomic_state > > > *state) > > > @@ -15307,9 +15306,8 @@ static void > > > icl_dbuf_slice_post_update(struct intel_atomic_state *state) > > >u8 hw_enabled_slices = dev_priv->enabled_dbuf_slices_mask; > > >u8 required_slices = state->enabled_dbuf_slices_mask; > > > - /* If 2nd DBuf slice is no more required disable it */ > > > if (INTEL_GEN(dev_priv) >= 11 && required_slices != > > > hw_enabled_slices) > > > - icl_dbuf_slices_update(dev_priv, > > > required_slices); > > > + gen9_dbuf_slices_update(dev_priv, > > > required_slices); > > > > > > Doesn't make much sense. Just look - previously we were checking if > > INTEL_GEN is >= than 11(which _is_ ICL) > > > > and now we still _do_ check if INTEL_GEN is >= 11, but... call now > > function renamed to gen9 > > > > > > I guess you either need to change INTEL_GEN check to be >=9 to at > > least look somewhat consistent > > > > or leave it as is. Or at least rename icl_ prefix to gen11_ > > otherwise that looks inconsistent, i.e > > > > you are now checking that gen is >= 11 and then OK - now let's call > > gen 9! :) > > The standard practice is to name things based on the oldest platform > that introduced the thing. And that is fine - but then you need to change the check above from INTEL_GEN >= 11 to INTEL_GEN >= 9, right - if you gen9 is the oldest platform. - /* If 2nd DBuf slice required, enable it here */ > > >if (INTEL_GEN(dev_priv) >= 11 && slices_union != > > > hw_enabled_slices) > > > - icl_dbuf_slices_update(dev_priv, slices_union); > > > + gen9_dbuf_slices_update(dev_priv, slices_union); > > > } I mean previously we were checking INTEL_GEN to be at least 11 and called function prefixed with icl_ - which was consistent and logical. Now you changed this to gen9(oldest platform which introduced the thing), however then the check above makes no sense - it should be changed to INTEL_GEN >= 9 as well. Otherwise this "gen9_dbuf_slices_update" function will not be actually ever called for gen9. Or do you want function prefixed as gen9_ to be only called for gen 11, why we then prefix it.. Stan > > > > > > > Stan > > > > > > From: Ville Syrjala > > Sent: Tuesday, February 25, 2020 7:11:12 PM > > To: intel-gfx@lists.freedesktop.org > > Cc: Lisovskiy, Stanislav > > Subject: [PATCH v2 07/20] drm/i915: Unify the low level dbuf code > > > > From: Ville Syrjälä > > > > The low level dbuf slice code is rather inconsitent with its > > functiona naming and organization. Make it more consistent. > > > > Also share the enable/disable functions between all platforms > > since the same code works just fine for all of them. > > > > Cc: Stanislav Lisovskiy > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/i915/display/intel_display.c | 6 +-- > > .../drm/i915/display/intel_display_power.c| 44 --- > > > > .../drm/i915/display/intel_display_power.h| 6 +-- > > 3 files changed, 24 insertions(+), 32 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > > b/drivers/gpu/drm/i915/display/intel_display.c > > index 3031e64ee518..6952c398cc43 100644 > > --- a/drivers/gpu/drm/i915/display/intel_display.c > > +++ b/drivers/gpu/drm/i915/display/intel_display.c > > @@ -15296,9 +15296,8 @@ static void > > icl_dbuf_slice_pre_update(struct intel_atomic_state *state) > > u8 required_slices = state->enabled_dbuf_slices_mask; > > u8 slices_union = hw_enabled_slices | required_slices; > > > > - /* If 2nd DBuf slice required, enable it here */ > > if (INTEL_GEN(dev_priv) >= 11 && slices_union != > > hw_enabled_slices) > > - icl_dbuf_slices_update(dev_priv, slices_union); > > + gen9_dbuf_slices_update(dev_priv, slices_union); > > } > > > > static void icl_dbuf_slice_post_update(struct intel_atomic_state > > *state) > > @@ -15307,9 +15306,8 @@ static void > > icl_dbuf_slice_post_update(struct intel_atomic_state *state) > > u8 hw_enabled_slices = dev_priv->enabled_dbuf_slices_mask; > > u8 required_slices = state->enabled_dbuf_slices_mask; > > > > - /* If 2nd DBuf slice is no more required disable it */ > > if (INTEL_GEN(dev_priv) >= 11 && required_slices != > > hw_enabled_slices) > > - icl_dbuf_slices_update(dev_priv, required_slices); > > + gen9_dbuf_slices_update(d
[Intel-gfx] [PATCH] drm/i915: Improve the start alignment of bonded pairs
Always wait on the start of the signaler request to reduce the problem
of dequeueing the bonded pair too early -- we want both payloads to
start at the same time, with no latency, and yet still allow others to
make full use of the slack in the system.
Remindme: add testcases for starting the bonded pair too early due to an
infinite spin before the signaler, and via a semaphore.
Testcase: XXX
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 33 -
1 file changed, 28 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 4bfe68edfc81..c0a0089111a1 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1127,14 +1127,37 @@ __i915_request_await_execution(struct i915_request *to,
&from->fence))
return 0;
- /* Ensure both start together [after all semaphores in signal] */
- if (intel_engine_has_semaphores(to->engine))
- err = __emit_semaphore_wait(to, from, from->fence.seqno - 1);
- else
- err = i915_request_await_start(to, from);
+ /*
+* Wait until the start of this request.
+*
+* The execution cb fires when we submit the request to HW. But in
+* many cases this may be long before the request itself is ready to
+* run (consider that we submit 2 requests for the same context, where
+* the request of interest is behind an indefinite spinner). So we hook
+* up to both to reduce our queues tidy and execution lag minimised in
+* the worst case, though we hope that the await_start is elided.
+*/
+ err = i915_request_await_start(to, from);
if (err < 0)
return err;
+ /*
+* Ensure both start together [after all semaphores in signal]
+*
+* Now that we are queued to the HW at roughly the same time (thanks
+* to the execute cb) and are ready to run at roughly the same time
+* (thanks to the await start), our signaler may still be indefinitely
+* delayed by waiting on a semaphore from a remote engine. If our
+* signaler depends on a sempahore, so indirectly do we, and we do not
+* want to start our payload until our signaler also starts theirs.
+* So we wait.
+*/
+ if (intel_engine_has_semaphores(to->engine) && from->sched.semaphores) {
+ err = __emit_semaphore_wait(to, from, from->fence.seqno - 1);
+ if (err < 0)
+ return err;
+ }
+
/* Couple the dependency tree for PI on this exposed to->fence */
if (to->engine->schedule) {
err = i915_sched_node_add_dependency(&to->sched, &from->sched);
--
2.25.1
___
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: Apply i915_request_skip() on submission
== Series Details == Series: series starting with [CI,1/2] drm/i915: Apply i915_request_skip() on submission URL : https://patchwork.freedesktop.org/series/74264/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8063_full -> Patchwork_16816_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16816_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16816_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_16816_full: ### IGT changes ### Possible regressions * igt@i915_pm_dc@dc6-dpms: - shard-iclb: [PASS][1] -> [FAIL][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8063/shard-iclb4/igt@i915_pm...@dc6-dpms.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16816/shard-iclb3/igt@i915_pm...@dc6-dpms.html Warnings * igt@gem_exec_schedule@pi-userfault-bsd2: - shard-iclb: [SKIP][3] ([fdo#109276]) -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8063/shard-iclb6/igt@gem_exec_sched...@pi-userfault-bsd2.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16816/shard-iclb1/igt@gem_exec_sched...@pi-userfault-bsd2.html Known issues Here are the changes found in Patchwork_16816_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-vcs1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112080]) +10 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8063/shard-iclb1/igt@gem_b...@busy-vcs1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16816/shard-iclb8/igt@gem_b...@busy-vcs1.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#110854]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8063/shard-iclb1/igt@gem_exec_balan...@smoke.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16816/shard-iclb5/igt@gem_exec_balan...@smoke.html * igt@gem_exec_gttfill@basic: - shard-hsw: [PASS][9] -> [INCOMPLETE][10] ([i915#61]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8063/shard-hsw6/igt@gem_exec_gttf...@basic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16816/shard-hsw7/igt@gem_exec_gttf...@basic.html * igt@gem_exec_schedule@implicit-both-bsd2: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276] / [i915#677]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8063/shard-iclb2/igt@gem_exec_sched...@implicit-both-bsd2.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16816/shard-iclb6/igt@gem_exec_sched...@implicit-both-bsd2.html * igt@gem_exec_schedule@pi-common-bsd: - shard-iclb: [PASS][13] -> [SKIP][14] ([i915#677]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8063/shard-iclb3/igt@gem_exec_sched...@pi-common-bsd.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16816/shard-iclb1/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_exec_schedule@preempt-contexts-bsd2: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109276]) +18 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8063/shard-iclb4/igt@gem_exec_sched...@preempt-contexts-bsd2.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16816/shard-iclb3/igt@gem_exec_sched...@preempt-contexts-bsd2.html * igt@gem_exec_schedule@wide-bsd: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#112146]) +5 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8063/shard-iclb3/igt@gem_exec_sched...@wide-bsd.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16816/shard-iclb2/igt@gem_exec_sched...@wide-bsd.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-glk: [PASS][19] -> [FAIL][20] ([i915#644]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8063/shard-glk1/igt@gem_pp...@flink-and-close-vma-leak.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16816/shard-glk3/igt@gem_pp...@flink-and-close-vma-leak.html - shard-apl: [PASS][21] -> [FAIL][22] ([i915#644]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8063/shard-apl7/igt@gem_pp...@flink-and-close-vma-leak.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16816/shard-apl3/igt@gem_pp...@flink-and-close-vma-leak.html * igt@i915_suspend@fence-restore-untiled: - shard-kbl: [PASS][23] -> [INCOMPLETE][24] ([fdo#103665]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8063/shard-kbl7/igt@i915_susp...@
Re: [Intel-gfx] [PATCH] drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017 (v2)
On Thu, 05 Mar 2020, Mario Kleiner wrote:
> This fixes a problem found on the MacBookPro 2017 Retina panel.
>
> The panel reports 10 bpc color depth in its EDID, and the
> firmware chooses link settings at boot which support enough
> bandwidth for 10 bpc (324000 kbit/sec = multiplier 0xc),
> but the DP_MAX_LINK_RATE dpcd register only reports
> 2.7 Gbps (multiplier value 0xa) as possible, in direct
> contradiction of what the firmware successfully set up.
>
> This restricts the panel to 8 bpc, not providing the full
> color depth of the panel.
>
> This patch adds a quirk specific to the MBP 2017 15" Retina
> panel to add the additiional 324000 kbps link rate during
> edp setup.
>
> Link to previous discussion of a different attempted fix
> with Ville and Jani:
>
> https://patchwork.kernel.org/patch/11325935/
>
> v2: Follow Jani's proposal of defining quirk_rates[] instead
> of just appending 324000. This for better clarity.
>
> Signed-off-by: Mario Kleiner
> Tested-by: Mario Kleiner
> Cc: Ville Syrjälä
> Cc: Jani Nikula
As much as I dislike quirks, I think we did exhaust other options when
we debugged this, and this is now very nicely isolated. Thanks for the
patch.
Reviewed-by: Jani Nikula
I'll merge once the CI results are in, mostly to ensure this doesn't
impact other platforms, as we don't have the machine in the CI farm.
> ---
> drivers/gpu/drm/drm_dp_helper.c | 2 ++
> drivers/gpu/drm/i915/display/intel_dp.c | 11 +++
> include/drm/drm_dp_helper.h | 7 +++
> 3 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 5a103e9b3c86..36a371c016cb 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1179,6 +1179,8 @@ static const struct dpcd_quirk dpcd_quirk_list[] = {
> { OUI(0x00, 0x00, 0x00), DEVICE_ID('C', 'H', '7', '5', '1', '1'),
> false, BIT(DP_DPCD_QUIRK_NO_SINK_COUNT) },
> /* Synaptics DP1.4 MST hubs can support DSC without virtual DPCD */
> { OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true,
> BIT(DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) },
> + /* Apple MacBookPro 2017 15 inch eDP Retina panel reports too low
> DP_MAX_LINK_RATE */
> + { OUI(0x00, 0x10, 0xfa), DEVICE_ID(101, 68, 21, 101, 98, 97), false,
> BIT(DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS) },
> };
>
> #undef OUI
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 4074d83b1a5f..c0d2c70b04fb 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -169,6 +169,17 @@ static void intel_dp_set_sink_rates(struct intel_dp
> *intel_dp)
> };
> int i, max_rate;
>
> + if (drm_dp_has_quirk(&intel_dp->desc,
> + DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS)) {
> + /* Needed, e.g., for Apple MBP 2017, 15 inch eDP Retina panel */
> + static const int quirk_rates[] = { 162000, 27, 324000 };
> +
> + memcpy(intel_dp->sink_rates, quirk_rates, sizeof(quirk_rates));
> + intel_dp->num_sink_rates = ARRAY_SIZE(quirk_rates);
> +
> + return;
> + }
> +
> max_rate =
> drm_dp_bw_code_to_link_rate(intel_dp->dpcd[DP_MAX_LINK_RATE]);
>
> for (i = 0; i < ARRAY_SIZE(dp_rates); i++) {
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 262faf9e5e94..4b86a1f2a559 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1532,6 +1532,13 @@ enum drm_dp_quirk {
>* The DSC caps can be read from the physical aux instead.
>*/
> DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD,
> + /**
> + * @DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS:
> + *
> + * The device supports a link rate of 3.24 Gbps (multiplier 0xc) despite
> + * the DP_MAX_LINK_RATE register reporting a lower max multiplier.
> + */
> + DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS,
> };
>
> /**
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017 (v2)
On Thu, 05 Mar 2020, Jani Nikula wrote:
> On Thu, 05 Mar 2020, Mario Kleiner wrote:
>> This fixes a problem found on the MacBookPro 2017 Retina panel.
>>
>> The panel reports 10 bpc color depth in its EDID, and the
>> firmware chooses link settings at boot which support enough
>> bandwidth for 10 bpc (324000 kbit/sec = multiplier 0xc),
>> but the DP_MAX_LINK_RATE dpcd register only reports
>> 2.7 Gbps (multiplier value 0xa) as possible, in direct
>> contradiction of what the firmware successfully set up.
>>
>> This restricts the panel to 8 bpc, not providing the full
>> color depth of the panel.
>>
>> This patch adds a quirk specific to the MBP 2017 15" Retina
>> panel to add the additiional 324000 kbps link rate during
>> edp setup.
>>
>> Link to previous discussion of a different attempted fix
>> with Ville and Jani:
>>
>> https://patchwork.kernel.org/patch/11325935/
>>
>> v2: Follow Jani's proposal of defining quirk_rates[] instead
>> of just appending 324000. This for better clarity.
>>
>> Signed-off-by: Mario Kleiner
>> Tested-by: Mario Kleiner
>> Cc: Ville Syrjälä
>> Cc: Jani Nikula
>
> As much as I dislike quirks, I think we did exhaust other options when
> we debugged this, and this is now very nicely isolated. Thanks for the
> patch.
>
> Reviewed-by: Jani Nikula
>
> I'll merge once the CI results are in, mostly to ensure this doesn't
> impact other platforms, as we don't have the machine in the CI farm.
Note to self, add this when merging per Mario's suggestion:
Cc: sta...@vger.kernel.org
>
>> ---
>> drivers/gpu/drm/drm_dp_helper.c | 2 ++
>> drivers/gpu/drm/i915/display/intel_dp.c | 11 +++
>> include/drm/drm_dp_helper.h | 7 +++
>> 3 files changed, 20 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_helper.c
>> b/drivers/gpu/drm/drm_dp_helper.c
>> index 5a103e9b3c86..36a371c016cb 100644
>> --- a/drivers/gpu/drm/drm_dp_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>> @@ -1179,6 +1179,8 @@ static const struct dpcd_quirk dpcd_quirk_list[] = {
>> { OUI(0x00, 0x00, 0x00), DEVICE_ID('C', 'H', '7', '5', '1', '1'),
>> false, BIT(DP_DPCD_QUIRK_NO_SINK_COUNT) },
>> /* Synaptics DP1.4 MST hubs can support DSC without virtual DPCD */
>> { OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true,
>> BIT(DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) },
>> +/* Apple MacBookPro 2017 15 inch eDP Retina panel reports too low
>> DP_MAX_LINK_RATE */
>> +{ OUI(0x00, 0x10, 0xfa), DEVICE_ID(101, 68, 21, 101, 98, 97), false,
>> BIT(DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS) },
>> };
>>
>> #undef OUI
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
>> b/drivers/gpu/drm/i915/display/intel_dp.c
>> index 4074d83b1a5f..c0d2c70b04fb 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> @@ -169,6 +169,17 @@ static void intel_dp_set_sink_rates(struct intel_dp
>> *intel_dp)
>> };
>> int i, max_rate;
>>
>> +if (drm_dp_has_quirk(&intel_dp->desc,
>> + DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS)) {
>> +/* Needed, e.g., for Apple MBP 2017, 15 inch eDP Retina panel */
>> +static const int quirk_rates[] = { 162000, 27, 324000 };
>> +
>> +memcpy(intel_dp->sink_rates, quirk_rates, sizeof(quirk_rates));
>> +intel_dp->num_sink_rates = ARRAY_SIZE(quirk_rates);
>> +
>> +return;
>> +}
>> +
>> max_rate =
>> drm_dp_bw_code_to_link_rate(intel_dp->dpcd[DP_MAX_LINK_RATE]);
>>
>> for (i = 0; i < ARRAY_SIZE(dp_rates); i++) {
>> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
>> index 262faf9e5e94..4b86a1f2a559 100644
>> --- a/include/drm/drm_dp_helper.h
>> +++ b/include/drm/drm_dp_helper.h
>> @@ -1532,6 +1532,13 @@ enum drm_dp_quirk {
>> * The DSC caps can be read from the physical aux instead.
>> */
>> DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD,
>> +/**
>> + * @DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS:
>> + *
>> + * The device supports a link rate of 3.24 Gbps (multiplier 0xc) despite
>> + * the DP_MAX_LINK_RATE register reporting a lower max multiplier.
>> + */
>> +DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS,
>> };
>>
>> /**
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dmc: Use firmware v2.06 for TGL
On Wed, 04 Mar 2020, Daniele Ceraolo Spurio wrote: > On 3/3/20 1:29 AM, Jani Nikula wrote: >> Please ensure 2.06 is in linux-firmware upstream before v5.7 kernel >> release. > > I've just sent the PR to linux-firmware so it shouldn't be an issue to > get the binary upstream in time for 5.6, but isn't this patch going to > hit 5.7? That's what I wrote above didn't I? Surely I wouldn't be off by one! ;D BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 07/20] drm/i915: Unify the low level dbuf code
On Tue, 2020-02-25 at 19:11 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The low level dbuf slice code is rather inconsitent with its
> functiona naming and organization. Make it more consistent.
>
> Also share the enable/disable functions between all platforms
> since the same code works just fine for all of them.
>
> Cc: Stanislav Lisovskiy
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 6 +--
> .../drm/i915/display/intel_display_power.c| 44 -
> --
> .../drm/i915/display/intel_display_power.h| 6 +--
> 3 files changed, 24 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 3031e64ee518..6952c398cc43 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > On Wed, 2020-03-04 at 20:30 +0200, Ville Syrjälä wrote:
> > > On Wed, Mar 04, 2020 at 05:23:05PM +, Lisovskiy, Stanislav
> > wrote:
> > > >
> > > > > - /* If 2nd DBuf slice required, enable it here */
> > > > >if (INTEL_GEN(dev_priv) >= 11 && slices_union !=
> > > > > hw_enabled_slices)
> > > > > - icl_dbuf_slices_update(dev_priv,
> > slices_union);
> > > > > + gen9_dbuf_slices_update(dev_priv,
> > slices_union);
> > > > > }
> > > > > static void icl_dbuf_slice_post_update(struct
> > intel_atomic_state
> > > > > *state)
> > > > > @@ -15307,9 +15306,8 @@ static void
> > > > > icl_dbuf_slice_post_update(struct intel_atomic_state *state)
> > > > >u8 hw_enabled_slices = dev_priv-
> > >enabled_dbuf_slices_mask;
> > > > >u8 required_slices = state->enabled_dbuf_slices_mask;
> > > > > - /* If 2nd DBuf slice is no more required disable it
> > */
> > > > > if (INTEL_GEN(dev_priv) >= 11 && required_slices !=
> > > > > hw_enabled_slices)
> > > > > - icl_dbuf_slices_update(dev_priv,
> > > > > required_slices);
> > > > > + gen9_dbuf_slices_update(dev_priv,
> > > > > required_slices);
> > > >
> > > >
> > > > Doesn't make much sense. Just look - previously we were
> > checking if
> > > > INTEL_GEN is >= than 11(which _is_ ICL)
> > > >
> > > > and now we still _do_ check if INTEL_GEN is >= 11, but... call
> > now
> > > > function renamed to gen9
> > > >
> > > >
> > > > I guess you either need to change INTEL_GEN check to be >=9 to
> > at
> > > > least look somewhat consistent
> > > >
> > > > or leave it as is. Or at least rename icl_ prefix to gen11_
> > > > otherwise that looks inconsistent, i.e
> > > >
> > > > you are now checking that gen is >= 11 and then OK - now let's
> > call
> > > > gen 9! :)
> > >
> > > The standard practice is to name things based on the oldest
> > platform
> > > that introduced the thing.
> >
And that is fine - but then you need to change the check above from
INTEL_GEN >= 11 to INTEL_GEN >= 9, right - if you gen9 is the oldest
platform.
> > > - /* If 2nd DBuf slice required, enable it here */
> > >if (INTEL_GEN(dev_priv) >= 11 && slices_union !=
> > > hw_enabled_slices)
> > > - icl_dbuf_slices_update(dev_priv, slices_union);
> > > + gen9_dbuf_slices_update(dev_priv, slices_union);
> > > }
I mean previously we were checking INTEL_GEN to be at least 11 and
called function prefixed with icl_ - which was consistent and logical.
Now you changed this to gen9(oldest platform which introduced the
thing), however then the check above makes no sense - it should be
changed to INTEL_GEN >= 9 as well. Otherwise this
"gen9_dbuf_slices_update" function will not be actually ever called for
gen9.
Or do you want function prefixed as gen9_ to be only called for gen 11,
why we then prefix it..
Stan
>
> static void skl_commit_modeset_enables(struct intel_atomic_state
> *state)
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index e81e561e8ac0..ce3bbc4c7a27 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -4433,15 +4433,18 @@ static void
> intel_power_domains_sync_hw(struct drm_i915_private *dev_priv)
> mutex_unlock(&power_domains->lock);
> }
>
> -static void intel_dbuf_slice_set(struct drm_i915_private *dev_priv,
> - enum dbuf_slice slice, bool enable)
> +static void gen9_dbuf_slice_set(struct drm_i915_private *dev_priv,
> + enum dbuf_slice slice, bool enable)
> {
> i915_reg_t reg = DBUF_CTL_S(slice);
> bool state;
> u32 val;
>
> val = intel_de_read(dev_priv, reg);
> - val = enable ? (val | DBUF_POWER_REQUEST) : (val &
> ~DBUF_POWER_REQUEST);
> + if (enable)
> + val |= DBUF_POWER_REQUEST;
> + else
> + val &= ~DBUF_POWER_REQUEST;
> intel_de_write(dev_priv, reg, val);
>
Re: [Intel-gfx] [PATCH] drm/i915/display: Decrease log level
On Tue, 2020-03-03 at 03:08 +0530, Swati Sharma wrote:
> Converting error to debug print if sink fails to configure scrambling
> or
> TMDS bit clock ratio. In this case, we are timing out while disabling
> the scrambling and setting the SCDC ratio, as there is no response
> to the I2C SCDC write from the sink device. Error isn't due to
> something
> wrong done from driver side.
>
> Signed-off-by: Swati Sharma
> Suggested-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Reviewed-by: Stanislav Lisovskiy
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 284219da7df8..457ca88cd277 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3564,8 +3564,9 @@ static void intel_enable_ddi_hdmi(struct
> intel_encoder *encoder,
> if (!intel_hdmi_handle_sink_scrambling(encoder, connector,
> crtc_state-
> >hdmi_high_tmds_clock_ratio,
> crtc_state-
> >hdmi_scrambling))
> - DRM_ERROR("[CONNECTOR:%d:%s] Failed to configure sink
> scrambling/TMDS bit clock ratio\n",
> - connector->base.id, connector->name);
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Failed to configure
> sink "
> + "scrambling/TMDS bit clock ratio\n",
> +connector->base.id, connector->name);
>
> /* Display WA #1143: skl,kbl,cfl */
> if (IS_GEN9_BC(dev_priv)) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/dsb: Pre allocate and late cleanup of cmd buffer
On Wed, Feb 12, 2020 at 08:15:22PM +0530, Animesh Manna wrote:
> Pre-allocate command buffer in atomic_commit using intel_dsb_prepare
> function which also includes pinning and map in cpu domain.
>
> No change is dsb write/commit functions.
>
> Now dsb get/put function is refactored and currently used only for
> reference counting. Below dsb api added to do respective job
> mentioned below.
>
> intel_dsb_prepare - Allocate, pin and map the buffer.
> intel_dsb_cleanup - Unpin and release the gem object.
>
> RFC: Initial patch for design review.
> v2: included _init() part in _prepare(). [Daniel, Ville]
> v3: dsb_cleanup called after cleanup_planes. [Daniel]
>
> Cc: Ville Syrjälä
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Signed-off-by: Animesh Manna
I think this should fit a lot better wrt the dma_resv locking rework
that's ongoing.
Acked-by: Daniel Vetter
Cheers, Daniel
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 36 -
> drivers/gpu/drm/i915/display/intel_dsb.c | 132 ---
> drivers/gpu/drm/i915/display/intel_dsb.h | 2 +
> 3 files changed, 116 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 61ba1f2256a0..ae90687e3a6b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15076,6 +15076,19 @@ static int intel_atomic_check(struct drm_device *dev,
>
> static int intel_atomic_prepare_commit(struct intel_atomic_state *state)
> {
> + struct intel_crtc_state *crtc_state;
> + struct intel_crtc *crtc;
> + int i;
> +
> + for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
> + bool mode_changed = needs_modeset(crtc_state);
> +
> + if (mode_changed || crtc_state->update_pipe ||
> + crtc_state->uapi.color_mgmt_changed) {
> + intel_dsb_prepare(crtc);
> + }
> + }
> +
> return drm_atomic_helper_prepare_planes(state->base.dev,
> &state->base);
> }
> @@ -15643,15 +15656,26 @@ static void intel_atomic_commit_fence_wait(struct
> intel_atomic_state *intel_stat
> &wait_reset);
> }
>
> +static void intel_cleanup_dsbs(struct intel_atomic_state *state)
> +{
> + struct intel_crtc_state *crtc_state;
> + struct intel_crtc *crtc;
> + int i;
> +
> + for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i)
> + intel_dsb_cleanup(crtc);
> +}
> +
> static void intel_atomic_cleanup_work(struct work_struct *work)
> {
> - struct drm_atomic_state *state =
> - container_of(work, struct drm_atomic_state, commit_work);
> - struct drm_i915_private *i915 = to_i915(state->dev);
> + struct intel_atomic_state *state =
> + container_of(work, struct intel_atomic_state, base.commit_work);
> + struct drm_i915_private *i915 = to_i915(state->base.dev);
>
> - drm_atomic_helper_cleanup_planes(&i915->drm, state);
> - drm_atomic_helper_commit_cleanup_done(state);
> - drm_atomic_state_put(state);
> + drm_atomic_helper_cleanup_planes(&i915->drm, &state->base);
> + intel_cleanup_dsbs(state);
> + drm_atomic_helper_commit_cleanup_done(&state->base);
> + drm_atomic_state_put(&state->base);
>
> intel_atomic_helper_free_state(i915);
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> b/drivers/gpu/drm/i915/display/intel_dsb.c
> index 76ae01277fd6..c31132c41e0f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -34,6 +34,86 @@
> #define DSB_BYTE_EN_SHIFT20
> #define DSB_REG_VALUE_MASK 0xf
>
> +/**
> + * intel_dsb_prepare() - Allocate, pin and map the DSB command buffer.
> + * @crtc: intel_crtc structure to get pipe info.
> + *
> + * This function prepare the command buffer which is used to store dsb
> + * instructions with data.
> + */
> +
> +void intel_dsb_prepare(struct intel_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->base.dev;
> + struct drm_i915_private *i915 = to_i915(dev);
> + struct intel_dsb *dsb = &crtc->dsb;
> + struct drm_i915_gem_object *obj;
> + struct i915_vma *vma;
> + u32 *buf;
> + intel_wakeref_t wakeref;
> +
> + if (!HAS_DSB(i915) || dsb->cmd_buf)
> + return;
> +
> + wakeref = intel_runtime_pm_get(&i915->runtime_pm);
> +
> + obj = i915_gem_object_create_internal(i915, DSB_BUF_SIZE);
> + if (IS_ERR(obj)) {
> + DRM_ERROR("Gem object creation failed\n");
> + goto out;
> + }
> +
> + vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, 0);
> + if (IS_ERR(vma)) {
> + DRM_ERROR("Vma creation failed\n");
> + i915_gem_object_put(obj);
> + goto out;
> + }
> +
> + buf = i915_gem_object_pin_map(vma->obj, I915_MAP_WC);
> +
Re: [Intel-gfx] [PATCH v6 1/3] intel_acpi: Rename drm_dev local variable to dev
On Wed, 04 Mar 2020, Rajat Jain wrote:
> Change the struct drm_device * local variable from drm_dev to dev
> per the feedback received here:
> https://lkml.org/lkml/2020/1/24/1143
>
> Signed-off-by: Rajat Jain
Reviewed-by: Jani Nikula
> ---
> v6: Initial patch (v6 to match other patches in the set)
>
> drivers/gpu/drm/i915/display/intel_acpi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
> b/drivers/gpu/drm/i915/display/intel_acpi.c
> index e21fb14d5e07b..3e6831cca4ac1 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> @@ -224,13 +224,13 @@ static u32 acpi_display_type(struct intel_connector
> *connector)
>
> void intel_acpi_device_id_update(struct drm_i915_private *dev_priv)
> {
> - struct drm_device *drm_dev = &dev_priv->drm;
> + struct drm_device *dev = &dev_priv->drm;
> struct intel_connector *connector;
> struct drm_connector_list_iter conn_iter;
> u8 display_index[16] = {};
>
> /* Populate the ACPI IDs for all connectors for a given drm_device */
> - drm_connector_list_iter_begin(drm_dev, &conn_iter);
> + drm_connector_list_iter_begin(dev, &conn_iter);
> for_each_intel_connector_iter(connector, &conn_iter) {
> u32 device_id, type;
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 2/3] drm/i915: Lookup and attach ACPI device node for connectors
On Wed, 04 Mar 2020, Rajat Jain wrote:
> Lookup and attach ACPI nodes for intel connectors. The lookup is done
> in compliance with ACPI Spec 6.3
> https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
> (Ref: Pages 1119 - 1123).
>
> This can be useful for any connector specific platform properties. (This
> will be used for privacy screen in next patch).
>
> Signed-off-by: Rajat Jain
> ---
> v6: Addressed minor comments from Jani at
> https://lkml.org/lkml/2020/1/24/1143
> - local variable renamed.
> - used drm_dbg_kms()
> - used acpi_device_handle()
> - Used opaque type acpi_handle instead of void*
> v5: same as v4
> v4: Same as v3
> v3: fold the code into existing acpi_device_id_update() function
> v2: formed by splitting the original patch into ACPI lookup, and privacy
> screen property. Also move it into i915 now that I found existing code
> in i915 that can be re-used.
>
> drivers/gpu/drm/i915/display/intel_acpi.c | 24 +++
> .../drm/i915/display/intel_display_types.h| 5
> drivers/gpu/drm/i915/display/intel_dp.c | 3 +++
> 3 files changed, 32 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
> b/drivers/gpu/drm/i915/display/intel_acpi.c
> index 3e6831cca4ac1..870c1ad98df92 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> @@ -222,11 +222,22 @@ static u32 acpi_display_type(struct intel_connector
> *connector)
> return display_type;
> }
>
> +/*
> + * Ref: ACPI Spec 6.3
> + * https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
> + * Pages 1119 - 1123 describe, what I believe, a standard way of
> + * identifying / addressing "display panels" in the ACPI. It provides
> + * a way for the ACPI to define devices for the display panels attached
> + * to the system. It thus provides a way for the BIOS to export any panel
> + * specific properties to the system via ACPI (like device trees).
> + */
> void intel_acpi_device_id_update(struct drm_i915_private *dev_priv)
> {
> struct drm_device *dev = &dev_priv->drm;
> struct intel_connector *connector;
> struct drm_connector_list_iter conn_iter;
> + struct acpi_device *conn_dev;
> + u64 conn_addr;
> u8 display_index[16] = {};
>
> /* Populate the ACPI IDs for all connectors for a given drm_device */
> @@ -242,6 +253,19 @@ void intel_acpi_device_id_update(struct drm_i915_private
> *dev_priv)
> device_id |= display_index[type]++ << ACPI_DISPLAY_INDEX_SHIFT;
>
> connector->acpi_device_id = device_id;
> +
> + /* Build the _ADR to look for */
> + conn_addr = device_id | ACPI_DEVICE_ID_SCHEME |
> + ACPI_BIOS_CAN_DETECT;
> +
> + drm_dbg_kms(dev, "Checking connector ACPI node at _ADR=%llX\n",
> + conn_addr);
> +
> + /* Look up the connector device, under the PCI device */
> + conn_dev = acpi_find_child_device(
> + ACPI_COMPANION(&dev->pdev->dev),
> + conn_addr, false);
> + connector->acpi_handle = acpi_device_handle(conn_dev);
> }
> drm_connector_list_iter_end(&conn_iter);
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 5e00e611f077f..d70612cc1ba2a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -411,9 +411,14 @@ struct intel_connector {
>*/
> struct intel_encoder *encoder;
>
> +#ifdef CONFIG_ACPI
> /* ACPI device id for ACPI and driver cooperation */
> u32 acpi_device_id;
>
> + /* ACPI handle corresponding to this connector display, if found */
> + acpi_handle acpi_handle;
> +#endif
> +
> /* Reads out the current hw, returning true if the connector is enabled
>* and active (i.e. dpms ON state). */
> bool (*get_hw_state)(struct intel_connector *);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 0a417cd2af2bc..171821113d362 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -44,6 +44,7 @@
> #include "i915_debugfs.h"
> #include "i915_drv.h"
> #include "i915_trace.h"
> +#include "intel_acpi.h"
> #include "intel_atomic.h"
> #include "intel_audio.h"
> #include "intel_connector.h"
> @@ -6868,6 +6869,8 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
> struct drm_connector *connect
>
> connector->state->scaling_mode = DRM_MODE_SCALE_ASPECT;
>
> + /* Lookup the ACPI node corresponding to the connector */
> + intel_acpi_device_id_update(dev_priv);
I find this part problematic.
Normally, we call the function at probe
Re: [Intel-gfx] [PATCH v2 06/20] drm/i915: Polish some dbuf debugs
On Wed, 2020-03-04 at 20:26 +0200, Ville Syrjälä wrote:
> On Wed, Mar 04, 2020 at 04:29:47PM +, Lisovskiy, Stanislav wrote:
> > On Tue, 2020-02-25 at 19:11 +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Polish some of the dbuf code to give more meaningful debug
> > > messages and whatnot. Also we can switch over to the per-device
> > > debugs/warns at the same time.
> > >
> > > Cc: Stanislav Lisovskiy
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > .../drm/i915/display/intel_display_power.c| 40 +--
> > >
> > >
> > > 1 file changed, 19 insertions(+), 21 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > index 6e25a1317161..e81e561e8ac0 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > @@ -4433,11 +4433,12 @@ static void
> > > intel_power_domains_sync_hw(struct drm_i915_private *dev_priv)
> > > mutex_unlock(&power_domains->lock);
> > > }
> > >
> > > -static inline
> > > -bool intel_dbuf_slice_set(struct drm_i915_private *dev_priv,
> > > - i915_reg_t reg, bool enable)
> > > +static void intel_dbuf_slice_set(struct drm_i915_private
> > > *dev_priv,
> > > + enum dbuf_slice slice, bool enable)
> > > {
> > > - u32 val, status;
> > > + i915_reg_t reg = DBUF_CTL_S(slice);
> > > + bool state;
> > > + u32 val;
> > >
> > > val = intel_de_read(dev_priv, reg);
> > > val = enable ? (val | DBUF_POWER_REQUEST) : (val &
> > > ~DBUF_POWER_REQUEST);
> > > @@ -4445,13 +4446,10 @@ bool intel_dbuf_slice_set(struct
> > > drm_i915_private *dev_priv,
> > > intel_de_posting_read(dev_priv, reg);
> > > udelay(10);
> > >
> > > - status = intel_de_read(dev_priv, reg) & DBUF_POWER_STATE;
> > > - if ((enable && !status) || (!enable && status)) {
> > > - drm_err(&dev_priv->drm, "DBus power %s timeout!\n",
> > > - enable ? "enable" : "disable");
> > > - return false;
> > > - }
> > > - return true;
> > > + state = intel_de_read(dev_priv, reg) & DBUF_POWER_STATE;
> > > + drm_WARN(&dev_priv->drm, enable != state,
> > > + "DBuf slice %d power %s timeout!\n",
> > > + slice, enable ? "enable" : "disable");
> > > }
> > >
> > > static void gen9_dbuf_enable(struct drm_i915_private *dev_priv)
> > > @@ -4467,14 +4465,16 @@ static void gen9_dbuf_disable(struct
> > > drm_i915_private *dev_priv)
> > > void icl_dbuf_slices_update(struct drm_i915_private *dev_priv,
> > > u8 req_slices)
> > > {
> > > - int i;
> > > - int max_slices = INTEL_INFO(dev_priv)-
> > > > num_supported_dbuf_slices;
> > >
> > > + int num_slices = INTEL_INFO(dev_priv)-
> > > > num_supported_dbuf_slices;
> > >
> > > struct i915_power_domains *power_domains = &dev_priv-
> > > > power_domains;
> > >
> > > + enum dbuf_slice slice;
> > >
> > > - drm_WARN(&dev_priv->drm, hweight8(req_slices) > max_slices,
> > > - "Invalid number of dbuf slices requested\n");
> > > + drm_WARN(&dev_priv->drm, req_slices & ~(BIT(num_slices) - 1),
> > > + "Invalid set of dbuf slices (0x%x) requested (num dbuf
> > > slices %d)\n",
> > > + req_slices, num_slices);
> > >
> > > - DRM_DEBUG_KMS("Updating dbuf slices to 0x%x\n", req_slices);
> > > + drm_dbg_kms(&dev_priv->drm,
> > > + "Updating dbuf slices to 0x%x\n", req_slices);
> > >
> > > /*
> > >* Might be running this in parallel to
> > > gen9_dc_off_power_well_enable
> > > @@ -4485,11 +4485,9 @@ void icl_dbuf_slices_update(struct
> > > drm_i915_private *dev_priv,
> > >*/
> > > mutex_lock(&power_domains->lock);
> > >
> > > - for (i = 0; i < max_slices; i++) {
> > > - intel_dbuf_slice_set(dev_priv,
> > > - DBUF_CTL_S(i),
> > > - (req_slices & BIT(i)) != 0);
> > > - }
> > > + for (slice = DBUF_S1; slice < num_slices; slice++)
> > > + intel_dbuf_slice_set(dev_priv, slice,
> > > + req_slices & BIT(slice));
> >
> > Would be cool to completely get rid of any magic numbers or
> > definitions, 0 in a sense is more universal here than DBUF_S1.
> >
> > If we are counting slices as numbers it seems logical that we
> > iterate [0..num_slices) range. If you want to name the first slice
> > explicitly then it probably has to be something like iterator
> > logic, i.e for (slice = FIRST_SLICE; slice != LAST_SLICE; slice++).
> >
> > But trying to name it at the same time with comparing to total
> > _amount_
> > looks a bit confusing.
>
> This is the standard pattern used all over the driver.
Well, you can enumerate objects using their qualitative or quantative
characteristics, for instance if you take alphabet you would be
either enumerating letters like first is A and count until it becomes
Z, or
you take indexes and say start
Re: [Intel-gfx] [PATCH v6 3/3] drm/i915: Add support for integrated privacy screens
On Wed, 04 Mar 2020, Rajat Jain wrote:
> Certain laptops now come with panels that have integrated privacy
> screens on them. This patch adds support for such panels by adding
> a privacy-screen property to the intel_connector for the panel, that
> the userspace can then use to control and check the status.
>
> Identifying the presence of privacy screen, and controlling it, is done
> via ACPI _DSM methods.
>
> Currently, this is done only for the Intel display ports. But in future,
> this can be done for any other ports if the hardware becomes available
> (e.g. external monitors supporting integrated privacy screens?).
I think you should add the property at the drm core level in
drm_connector.c, not in i915, to ensure we have the same property across
drivers. Even if, for now, you leave the acpi implementation part in
i915.
More comments inline.
>
> Signed-off-by: Rajat Jain
> ---
> v6: Always initialize prop in intel_attach_privacy_screen_property()
> v5: fix a cosmetic checkpatch warning
> v4: Fix a typo in intel_privacy_screen.h
> v3: * Change license to GPL-2.0 OR MIT
> * Move privacy screen enum from UAPI to intel_display_types.h
> * Rename parameter name and some other minor changes.
> v2: Formed by splitting the original patch into multiple patches.
> - All code has been moved into i915 now.
> - Privacy screen is a i915 property
> - Have a local state variable to store the prvacy screen. Don't read
> it from hardware.
>
> drivers/gpu/drm/i915/Makefile | 3 +-
> drivers/gpu/drm/i915/display/intel_atomic.c | 13 +++-
> .../gpu/drm/i915/display/intel_connector.c| 35 +
> .../gpu/drm/i915/display/intel_connector.h| 1 +
> .../drm/i915/display/intel_display_types.h| 18 +
> drivers/gpu/drm/i915/display/intel_dp.c | 6 ++
> .../drm/i915/display/intel_privacy_screen.c | 72 +++
> .../drm/i915/display/intel_privacy_screen.h | 27 +++
> 8 files changed, 171 insertions(+), 4 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/display/intel_privacy_screen.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_privacy_screen.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 991a8c537d123..825951b4cd006 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -208,7 +208,8 @@ i915-y += \
> display/intel_vga.o
> i915-$(CONFIG_ACPI) += \
> display/intel_acpi.o \
> - display/intel_opregion.o
> + display/intel_opregion.o \
> + display/intel_privacy_screen.o
> i915-$(CONFIG_DRM_FBDEV_EMULATION) += \
> display/intel_fbdev.o
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index d043057d2fa03..4ed537c87 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -40,6 +40,7 @@
> #include "intel_global_state.h"
> #include "intel_hdcp.h"
> #include "intel_psr.h"
> +#include "intel_privacy_screen.h"
> #include "intel_sprite.h"
>
> /**
> @@ -60,11 +61,14 @@ int intel_digital_connector_atomic_get_property(struct
> drm_connector *connector,
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct intel_digital_connector_state *intel_conn_state =
> to_intel_digital_connector_state(state);
> + struct intel_connector *intel_connector = to_intel_connector(connector);
>
> if (property == dev_priv->force_audio_property)
> *val = intel_conn_state->force_audio;
> else if (property == dev_priv->broadcast_rgb_property)
> *val = intel_conn_state->broadcast_rgb;
> + else if (property == intel_connector->privacy_screen_property)
> + *val = intel_conn_state->privacy_screen_status;
> else {
> drm_dbg_atomic(&dev_priv->drm,
> "Unknown property [PROP:%d:%s]\n",
> @@ -93,15 +97,18 @@ int intel_digital_connector_atomic_set_property(struct
> drm_connector *connector,
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct intel_digital_connector_state *intel_conn_state =
> to_intel_digital_connector_state(state);
> + struct intel_connector *intel_connector = to_intel_connector(connector);
>
> if (property == dev_priv->force_audio_property) {
> intel_conn_state->force_audio = val;
> return 0;
> - }
> -
> - if (property == dev_priv->broadcast_rgb_property) {
> + } else if (property == dev_priv->broadcast_rgb_property) {
> intel_conn_state->broadcast_rgb = val;
> return 0;
> + } else if (property == intel_connector->privacy_screen_property) {
> + intel_privacy_screen_set_val(intel_connector, val);
I think this part should only change the connector state. The driver
would then do the magic at commit stage according to the property value.
>
Re: [Intel-gfx] [PATCH v6 1/3] intel_acpi: Rename drm_dev local variable to dev
On Wed, 04 Mar 2020, Rajat Jain wrote: > Change the struct drm_device * local variable from drm_dev to dev > per the feedback received here: > https://lkml.org/lkml/2020/1/24/1143 I don't know what's up with the two identical (or similar) threads here, but I replied in the thread starting at [1]. Please let's keep the discussion there. BR, Jani. [1] http://patchwork.freedesktop.org/patch/msgid/20200305012338.219746-2-raja...@google.com -- 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] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/2] drm/i915: Add mechanism to submit a context WA on ring submission
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Add mechanism to submit a
context WA on ring submission
URL : https://patchwork.freedesktop.org/series/74281/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
efd9736ffc9a drm/i915: Add mechanism to submit a context WA on ring submission
-:262: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#262:
new file mode 100644
-:373: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#373: FILE: drivers/gpu/drm/i915/gt/selftest_ring_submission.c:107:
+ pr_err("pass[%d] wa_bb emitted for the kernel
context\n",
+ pass);
-:384: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#384: FILE: drivers/gpu/drm/i915/gt/selftest_ring_submission.c:118:
+ pr_err("pass[%d] wa_bb *NOT* emitted after the
kernel context\n",
+ pass);
-:395: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#395: FILE: drivers/gpu/drm/i915/gt/selftest_ring_submission.c:129:
+ pr_err("pass[%d] wa_bb *NOT* emitted for the
user context switch\n",
+ pass);
total: 0 errors, 1 warnings, 3 checks, 499 lines checked
3b0f0cfecfdd drm/i915/gen7: Clear all EU/L3 residual contexts
-:46: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#46:
new file mode 100644
total: 0 errors, 1 warnings, 0 checks, 585 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-fixes
drm-misc-fixes-2020-03-05: Fixes for v5.6.rc5: - Fix memory leak - Fix resource id creation race in virtio. - Various mmap fixes. - Fix fence leak in ttm_buffer_object_transfer(). - Fixes for sun4i VI layer format support. - kirin: Revert "Fix for hikey620 display offset problem" The following changes since commit dde2bb2da01e96c17f0a44b4a3cf72a30e66e3ef: drm/panfrost: perfcnt: Reserve/use the AS attached to the perfcnt MMU context (2020-02-12 14:27:29 -0600) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2020-03-05 for you to fetch changes up to 1b79cfd99ff5127e6a143767b51694a527b3ea38: drm: kirin: Revert "Fix for hikey620 display offset problem" (2020-03-04 13:29:05 +) Fixes for v5.6.rc5: - Fix memory leak - Fix resource id creation race in virtio. - Various mmap fixes. - Fix fence leak in ttm_buffer_object_transfer(). - Fixes for sun4i VI layer format support. - kirin: Revert "Fix for hikey620 display offset problem" Ahzo (1): drm/ttm: fix leaking fences via ttm_buffer_object_transfer Cong Wang (1): dma-buf: free dmabuf->name in dma_buf_release() Gerd Hoffmann (3): drm/shmem: add support for per object caching flags. drm/virtio: fix mmap page attributes drm/shmem: drop pgprot_decrypted() Icenowy Zheng (1): drm/bridge: analogix-anx6345: fix set of link bandwidth Jernej Skrabec (3): drm/sun4i: de2/de3: Remove unsupported VI layer formats drm/sun4i: Add separate DE3 VI layer formats drm/sun4i: Fix DE2 VI layer format support John Bates (1): drm/virtio: fix resource id creation race John Stultz (1): drm: kirin: Revert "Fix for hikey620 display offset problem" Tomeu Vizoso (1): drm/panfrost: Don't try to map on error faults drivers/dma-buf/dma-buf.c | 1 + drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 3 +- drivers/gpu/drm/drm_gem_shmem_helper.c | 16 +++- drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h| 1 - drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c| 20 drivers/gpu/drm/panfrost/panfrost_mmu.c| 44 - drivers/gpu/drm/sun4i/sun8i_mixer.c| 104 ++--- drivers/gpu/drm/sun4i/sun8i_mixer.h| 11 +++ drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 66 +++-- drivers/gpu/drm/ttm/ttm_bo_util.c | 1 + drivers/gpu/drm/virtio/virtgpu_object.c| 5 +- include/drm/drm_gem_shmem_helper.h | 5 + 12 files changed, 202 insertions(+), 75 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [CI,1/2] drm/i915: Add mechanism to submit a context WA on ring submission
== Series Details == Series: series starting with [CI,1/2] drm/i915: Add mechanism to submit a context WA on ring submission URL : https://patchwork.freedesktop.org/series/74281/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_dpll_mgr.h:285: warning: Function parameter or member 'get_freq' not described in 'intel_shared_dpll_funcs' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave & Daniel - drm-intel-fixes-2020-03-05: drm/i915 fixes for v5.6-rc5: - Break up long lists of object reclaim with cond_resched() - PSR probe fix - TGL workarounds - Selftest return value fix - Drop timeline mutex while waiting for retirement - Wait for OA configuration completion before writes to OA buffer BR, Jani. The following changes since commit 98d54f81e36ba3bf92172791eba5ca5bd813989b: Linux 5.6-rc4 (2020-03-01 16:38:46 -0600) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2020-03-05 for you to fetch changes up to 169c0aa4bc17d37370f55188d9327b99d60fd9d7: drm/i915/gt: Drop the timeline->mutex as we wait for retirement (2020-03-04 13:49:26 +0200) drm/i915 fixes for v5.6-rc5: - Break up long lists of object reclaim with cond_resched() - PSR probe fix - TGL workarounds - Selftest return value fix - Drop timeline mutex while waiting for retirement - Wait for OA configuration completion before writes to OA buffer Chris Wilson (4): drm/i915/gem: Break up long lists of object reclaim drm/i915: Protect i915_request_await_start from early waits drm/i915/perf: Reintroduce wait on OA configuration completion drm/i915/gt: Drop the timeline->mutex as we wait for retirement Dan Carpenter (1): drm/i915/selftests: Fix return in assert_mmap_offset() José Roberto de Souza (1): drm/i915/psr: Force PSR probe only after full initialization Lucas De Marchi (1): drm/i915/tgl: Add Wa_1608008084 Matt Roper (2): drm/i915: Program MBUS with rmw during initialization drm/i915/tgl: Add Wa_22010178259:tgl drivers/gpu/drm/i915/display/intel_display_power.c | 29 +-- drivers/gpu/drm/i915/display/intel_psr.c | 25 -- drivers/gpu/drm/i915/display/intel_psr.h | 1 + drivers/gpu/drm/i915/gem/i915_gem_object.c | 1 + drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt_requests.c| 14 -- drivers/gpu/drm/i915/gt/intel_workarounds.c| 19 +++ drivers/gpu/drm/i915/i915_drv.c| 3 ++ drivers/gpu/drm/i915/i915_drv.h| 2 +- drivers/gpu/drm/i915/i915_perf.c | 58 +++--- drivers/gpu/drm/i915/i915_perf_types.h | 3 +- drivers/gpu/drm/i915/i915_reg.h| 1 + drivers/gpu/drm/i915/i915_request.c| 41 ++- 13 files changed, 142 insertions(+), 57 deletions(-) -- 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] drm/i915: Actually emit the await_start
Fix the inverted test to emit the wait on the end of the previous
request if we /haven't/ already.
Fixes: 6a79d848403d ("drm/i915: Lock signaler timeline while navigating")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: # v5.5+
---
drivers/gpu/drm/i915/i915_request.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 4bfe68edfc81..46dae33c1a20 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -882,7 +882,7 @@ i915_request_await_start(struct i915_request *rq, struct
i915_request *signal)
return 0;
err = 0;
- if (intel_timeline_sync_is_later(i915_request_timeline(rq), fence))
+ if (!intel_timeline_sync_is_later(i915_request_timeline(rq), fence))
err = i915_sw_fence_await_dma_fence(&rq->submit,
fence, 0,
I915_FENCE_GFP);
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gem: Limit struct_mutex to eb_reserve
On Wed, 04 Mar 2020, Chris Wilson wrote: > drivers/gpu/drm/i915/i915_drv.h | 6 --- Immediately looks like a good patch! BR, Jani. -- 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] ✗ Fi.CI.BAT: failure for series starting with [CI,1/2] drm/i915: Add mechanism to submit a context WA on ring submission
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Add mechanism to submit a
context WA on ring submission
URL : https://patchwork.freedesktop.org/series/74281/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8068 -> Patchwork_16825
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_16825 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_16825, 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_16825/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_16825:
### IGT changes ###
Possible regressions
* {igt@i915_selftest@live@ring_submission} (NEW):
- fi-hsw-4770:NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16825/fi-hsw-4770/igt@i915_selftest@live@ring_submission.html
- fi-ivb-3770:NOTRUN -> [INCOMPLETE][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16825/fi-ivb-3770/igt@i915_selftest@live@ring_submission.html
- fi-hsw-4770r: NOTRUN -> [INCOMPLETE][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16825/fi-hsw-4770r/igt@i915_selftest@live@ring_submission.html
- fi-hsw-peppy: NOTRUN -> [INCOMPLETE][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16825/fi-hsw-peppy/igt@i915_selftest@live@ring_submission.html
- fi-snb-2600:NOTRUN -> [DMESG-FAIL][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16825/fi-snb-2600/igt@i915_selftest@live@ring_submission.html
- fi-gdg-551: NOTRUN -> [DMESG-FAIL][6]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16825/fi-gdg-551/igt@i915_selftest@live@ring_submission.html
- fi-snb-2520m: NOTRUN -> [DMESG-FAIL][7]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16825/fi-snb-2520m/igt@i915_selftest@live@ring_submission.html
* igt@runner@aborted:
- fi-hsw-4770r: NOTRUN -> [FAIL][8]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16825/fi-hsw-4770r/igt@run...@aborted.html
- fi-hsw-peppy: NOTRUN -> [FAIL][9]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16825/fi-hsw-peppy/igt@run...@aborted.html
- fi-hsw-4770:NOTRUN -> [FAIL][10]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16825/fi-hsw-4770/igt@run...@aborted.html
- fi-ivb-3770:NOTRUN -> [FAIL][11]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16825/fi-ivb-3770/igt@run...@aborted.html
- fi-byt-j1900: NOTRUN -> [FAIL][12]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16825/fi-byt-j1900/igt@run...@aborted.html
New tests
-
New tests have been introduced between CI_DRM_8068 and Patchwork_16825:
### New IGT tests (1) ###
* igt@i915_selftest@live@ring_submission:
- Statuses : 3 dmesg-fail(s) 5 incomplete(s) 34 pass(s)
- Exec time: [0.0, 2.89] s
Known issues
Here are the changes found in Patchwork_16825 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@dp-crc-fast:
- fi-cml-u2: [PASS][13] -> [FAIL][14] ([i915#262])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16825/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][15] -> [FAIL][16] ([fdo#111407])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16825/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@prime_self_import@basic-llseek-size:
- fi-tgl-y: [PASS][17] -> [DMESG-WARN][18] ([CI#94] / [i915#402])
+1 similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-tgl-y/igt@prime_self_imp...@basic-llseek-size.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16825/fi-tgl-y/igt@prime_self_imp...@basic-llseek-size.html
Possible fixes
* igt@i915_getparams_basic@basic-eu-total:
- fi-tgl-y: [DMESG-WARN][19] ([CI#94] / [i915#402]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-tgl-y/igt@i915_getparams_ba...@basic-eu-total.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16825/fi-tgl-y/igt@i915_getparams_ba...@basic-eu-total.html
* igt@i915_selftest@live@gem_contexts:
- fi-cfl-8700k: [INCOMPLETE][21] ([i915#424]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/C
Re: [Intel-gfx] [PATCH] drm/i915: Actually emit the await_start
On 05/03/2020 10:42, Chris Wilson wrote:
Fix the inverted test to emit the wait on the end of the previous
request if we /haven't/ already.
Fixes: 6a79d848403d ("drm/i915: Lock signaler timeline while navigating")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: # v5.5+
---
drivers/gpu/drm/i915/i915_request.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 4bfe68edfc81..46dae33c1a20 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -882,7 +882,7 @@ i915_request_await_start(struct i915_request *rq, struct
i915_request *signal)
return 0;
err = 0;
- if (intel_timeline_sync_is_later(i915_request_timeline(rq), fence))
+ if (!intel_timeline_sync_is_later(i915_request_timeline(rq), fence))
err = i915_sw_fence_await_dma_fence(&rq->submit,
fence, 0,
I915_FENCE_GFP);
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Exercise bonded-payload synchronisation
Our goal with bonded submission is to submit the pair of user batches to
the HW at roughly the same time, and trying to avoid any bubbles. If we
submit the secondary batch too early, it will be running before the
first and stuck on the HW preventing others from utilising the GPU. At
worst, it may even appear unresponsive and trigger a GPU hang as it
waits for its master. If we submit the secondary too late, the reverse
situation may apply to the master as it has to wait to the secondaries.
This test tries to verify that using a submit-fence to create a bonded
pair does not prevent others from using the HW. By using a pair of
spinners, we can create a bonded hog that when set in motion will fully
utilize both engines [if the scheduling is incorrect]. We then use a
third party submitted after the bonded pair to cancel the spinner from
the GPU -- if it is unable to run, the spinner is never cancelled, and
the bonded pair will cause a GPU hang.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_exec_balancer.c | 91 ++
1 file changed, 91 insertions(+)
diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
index 69f0100ff..e1f9ce625 100644
--- a/tests/i915/gem_exec_balancer.c
+++ b/tests/i915/gem_exec_balancer.c
@@ -1240,6 +1240,94 @@ static void indices(int i915)
gem_quiescent_gpu(i915);
}
+static void __bonded_early(int i915, uint32_t ctx,
+ const struct i915_engine_class_instance *siblings,
+ unsigned int count)
+{
+ uint32_t handle = batch_create(i915);
+ struct drm_i915_gem_exec_object2 batch = {
+ .handle = handle,
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(&batch),
+ .buffer_count = 1,
+ .rsvd1 = ctx,
+ };
+ igt_spin_t *spin;
+
+ /* A: spin forever on engine 1 */
+ set_load_balancer(i915, ctx, siblings, count, NULL);
+ spin = igt_spin_new(i915,
+ .ctx = ctx,
+ .engine = 1,
+ .flags = IGT_SPIN_NO_PREEMPTION);
+
+ /* B: runs after A on engine 1 */
+ execbuf.flags = I915_EXEC_FENCE_OUT;
+ execbuf.flags |= 1;
+ gem_execbuf_wr(i915, &execbuf);
+
+ /* B': run in parallel with B on engine 2, i.e. not before A! */
+ set_load_balancer(i915, ctx, siblings, count, NULL);
+ execbuf.flags = I915_EXEC_FENCE_SUBMIT | I915_EXEC_FENCE_OUT;
+ execbuf.flags |= 2;
+ execbuf.rsvd2 >>= 32;
+ gem_execbuf_wr(i915, &execbuf);
+
+ /* C: prevent anything running on engine 2 after B' */
+ spin->execbuf.flags = 2;
+ gem_execbuf(i915, &spin->execbuf);
+
+ igt_debugfs_dump(i915, "i915_engine_info");
+
+ /* D: cancel the spinner from engine 2 (new timeline) */
+ set_load_balancer(i915, ctx, siblings, count, NULL);
+ batch.handle = create_semaphore_to_spinner(i915, spin);
+ execbuf.flags = 2;
+ gem_execbuf(i915, &execbuf);
+ gem_close(i915, batch.handle);
+
+ /* If C runs before D, we never cancel the spinner and so hang */
+ gem_sync(i915, handle);
+
+ /* Check the bonded pair completed successfully */
+ igt_assert_eq(sync_fence_status(execbuf.rsvd2 & 0x), 1);
+ igt_assert_eq(sync_fence_status(execbuf.rsvd2 >> 32), 1);
+
+ close(execbuf.rsvd2);
+ close(execbuf.rsvd2 >> 32);
+
+ gem_close(i915, handle);
+ igt_spin_free(i915, spin);
+}
+
+static void bonded_early(int i915)
+{
+ uint32_t ctx;
+
+ /*
+* Our goal is to start the bonded payloads at roughly the same time.
+* We do not want to start the secondary batch too early as it will
+* do nothing but hog the GPU until the first has a chance to execute.
+* So if we were to arbitrary delay the first by running it after a
+* spinner...
+*/
+
+ ctx = gem_context_create(i915);
+
+ for (int class = 0; class < 32; class++) {
+ struct i915_engine_class_instance *siblings;
+ unsigned int count;
+
+ siblings = list_engines(i915, 1u << class, &count);
+ if (count > 1)
+ __bonded_early(i915, ctx, siblings, count);
+ free(siblings);
+ }
+
+ gem_context_destroy(i915, ctx);
+}
+
static void busy(int i915)
{
uint32_t scratch = gem_create(i915, 4096);
@@ -1891,6 +1979,9 @@ igt_main
igt_subtest("bonded-semaphore")
bonded_semaphore(i915);
+ igt_subtest("bonded-early")
+ bonded_early(i915);
+
igt_fixture {
igt_stop_hang_detector();
}
--
2.25.1
___
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 gem_userptr_blits: mmap-offset-invalidate enhancements
Hi,
Here are my comments to CI results from testing the IGT changes on
Trybot with kernel change that prevents non-GTT mmap-offset mapping to
userptr reverted.
On Thu, 2020-03-05 at 06:15 +, Patchwork wrote:
> == Series Details ==
>
> Series: gem_userptr_blits: mmap-offset-invalidate enhancements
> URL : https://patchwork.freedesktop.org/series/74255/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_8063_full -> Trybot_5722_full
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Trybot_5722_full absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Trybot_5722_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
> Trybot_5722_full:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@gem_ctx_persistence@close-replace-race:
> - shard-tglb: [PASS][1] -> [INCOMPLETE][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8063/shard-tglb2/igt@gem_ctx_persiste...@close-replace-race.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_5722/shard-tglb5/igt@gem_ctx_persiste...@close-replace-race.html
This has nothing to do with the IGT changes.
>
> * {igt@gem_userptr_blits@mmap-offset-invalidate-active@gtt} (NEW):
> - shard-iclb: NOTRUN -> [SKIP][3]
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_5722/shard-iclb7/igt@gem_userptr_blits@mmap-offset-invalidate-act...@gtt.html
> - shard-tglb: NOTRUN -> [SKIP][4]
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_5722/shard-tglb7/igt@gem_userptr_blits@mmap-offset-invalidate-act...@gtt.html
>
> * {igt@gem_userptr_blits@mmap-offset-invalidate-active@wb} (NEW):
> - shard-snb: NOTRUN -> [DMESG-FAIL][5]
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_5722/shard-snb4/igt@gem_userptr_blits@mmap-offset-invalidate-act...@wb.html
> - shard-kbl: NOTRUN -> [DMESG-FAIL][6]
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_5722/shard-kbl6/igt@gem_userptr_blits@mmap-offset-invalidate-act...@wb.html
> - shard-glk: NOTRUN -> [DMESG-FAIL][7]
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_5722/shard-glk5/igt@gem_userptr_blits@mmap-offset-invalidate-act...@wb.html
> - shard-skl: NOTRUN -> [DMESG-FAIL][8]
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_5722/shard-skl9/igt@gem_userptr_blits@mmap-offset-invalidate-act...@wb.html
> - shard-apl: NOTRUN -> [DMESG-FAIL][9]
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_5722/shard-apl1/igt@gem_userptr_blits@mmap-offset-invalidate-act...@wb.html
> - shard-tglb: NOTRUN -> [DMESG-FAIL][10]
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_5722/shard-tglb7/igt@gem_userptr_blits@mmap-offset-invalidate-act...@wb.html
> - shard-iclb: NOTRUN -> [INCOMPLETE][11]
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_5722/shard-iclb7/igt@gem_userptr_blits@mmap-offset-invalidate-act...@wb.html
>
> * {igt@gem_userptr_blits@mmap-offset-invalidate-active@wc} (NEW):
> - shard-tglb: NOTRUN -> [INCOMPLETE][12]
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_5722/shard-tglb7/igt@gem_userptr_blits@mmap-offset-invalidate-act...@wc.html
> - shard-skl: NOTRUN -> [INCOMPLETE][13]
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_5722/shard-skl9/igt@gem_userptr_blits@mmap-offset-invalidate-act...@wc.html
Here we have driver issues reported by the active subtest variant when
run on a kernel with the lockdep loop preventive patch reverted.
>
> * igt@i915_pm_backlight@fade_with_dpms:
> - shard-iclb: [PASS][14] -> [SKIP][15]
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8063/shard-iclb8/igt@i915_pm_backlight@fade_with_dpms.html
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_5722/shard-iclb2/igt@i915_pm_backlight@fade_with_dpms.html
>
> * igt@i915_pm_dc@dc6-psr:
> - shard-skl: [PASS][16] -> [FAIL][17]
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8063/shard-skl10/igt@i915_pm...@dc6-psr.html
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_5722/shard-skl2/igt@i915_pm...@dc6-psr.html
The above two also have nothing to do with the IGT changes.
Thanks,
Janusz
>
> * igt@runner@aborted:
> - shard-tglb: NOTRUN -> ([FAIL][18], [FAIL][19], [FAIL][20])
> ([fdo#111870])
>[18]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_5722/shard-tglb7/igt@run...@aborted.html
>[19]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_5722/sha
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Enable timeslice on partial virtual engine dequeue
Chris Wilson writes:
> If we stop filling the ELSP due to an incompatible virtual engine
> request, check if we should enable the timeslice on behalf of the queue.
>
Leaves me pondering more of the why.
So that on these boundaries also, the last rq gets subdued to
a timeslice and not get a free run?
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 21 -
> 1 file changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 5da86a40434c..954bd4797482 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -1802,6 +1802,20 @@ static void set_timeslice(struct intel_engine_cs
> *engine)
> set_timer_ms(&engine->execlists.timer, active_timeslice(engine));
> }
>
> +static void start_timeslice(struct intel_engine_cs *engine,
> + struct i915_request *last)
> +{
> + struct intel_engine_execlists *execlists = &engine->execlists;
> +
> + /* As we are returning early, update the hint from the queue */
> + execlists->switch_priority_hint =
> + max(execlists->queue_priority_hint,
> + execlists->switch_priority_hint);
> +
> + if (!execlists->timer.expires && need_timeslice(engine, last))
> + set_timer_ms(&execlists->timer, timeslice(engine));
> +}
> +
> static void record_preemption(struct intel_engine_execlists *execlists)
> {
> (void)I915_SELFTEST_ONLY(execlists->preempt_hang.count++);
> @@ -1965,11 +1979,7 @@ static void execlists_dequeue(struct intel_engine_cs
> *engine)
>* Even if ELSP[1] is occupied and not worthy
>* of timeslices, our queue might be.
>*/
> - if (!execlists->timer.expires &&
> - need_timeslice(engine, last))
> - set_timer_ms(&execlists->timer,
> - timeslice(engine));
> -
> + start_timeslice(engine, last);
> return;
> }
> }
> @@ -2004,6 +2014,7 @@ static void execlists_dequeue(struct intel_engine_cs
> *engine)
>
> if (last && !can_merge_rq(last, rq)) {
> spin_unlock(&ve->base.active.lock);
> + start_timeslice(engine, last);
> return; /* leave this for another */
for another interrupt?
-Mika
> }
>
> --
> 2.25.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Improve the start alignment of bonded pairs
Chris Wilson writes:
> Always wait on the start of the signaler request to reduce the problem
> of dequeueing the bonded pair too early -- we want both payloads to
> start at the same time, with no latency, and yet still allow others to
> make full use of the slack in the system.
>
> Remindme: add testcases for starting the bonded pair too early due to an
> infinite spin before the signaler, and via a semaphore.
>
> Testcase: XXX
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_request.c | 33 -
> 1 file changed, 28 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_request.c
> b/drivers/gpu/drm/i915/i915_request.c
> index 4bfe68edfc81..c0a0089111a1 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -1127,14 +1127,37 @@ __i915_request_await_execution(struct i915_request
> *to,
> &from->fence))
> return 0;
>
> - /* Ensure both start together [after all semaphores in signal] */
> - if (intel_engine_has_semaphores(to->engine))
> - err = __emit_semaphore_wait(to, from, from->fence.seqno - 1);
> - else
> - err = i915_request_await_start(to, from);
> + /*
> + * Wait until the start of this request.
> + *
> + * The execution cb fires when we submit the request to HW. But in
> + * many cases this may be long before the request itself is ready to
> + * run (consider that we submit 2 requests for the same context, where
> + * the request of interest is behind an indefinite spinner). So we hook
> + * up to both to reduce our queues tidy and execution lag minimised in
> + * the worst case, though we hope that the await_start is elided.
> + */
> + err = i915_request_await_start(to, from);
> if (err < 0)
> return err;
>
> + /*
> + * Ensure both start together [after all semaphores in signal]
> + *
> + * Now that we are queued to the HW at roughly the same time (thanks
> + * to the execute cb) and are ready to run at roughly the same time
> + * (thanks to the await start), our signaler may still be indefinitely
> + * delayed by waiting on a semaphore from a remote engine. If our
> + * signaler depends on a sempahore, so indirectly do we, and we do not
s/sempahore/semaphore
-Mika
> + * want to start our payload until our signaler also starts theirs.
> + * So we wait.
> + */
> + if (intel_engine_has_semaphores(to->engine) && from->sched.semaphores) {
> + err = __emit_semaphore_wait(to, from, from->fence.seqno - 1);
> + if (err < 0)
> + return err;
> + }
> +
> /* Couple the dependency tree for PI on this exposed to->fence */
> if (to->engine->schedule) {
> err = i915_sched_node_add_dependency(&to->sched, &from->sched);
> --
> 2.25.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/2] drm/i915/gen7: Clear all EU/L3 residual contexts
From: Prathap Kumar Valsan
On gen7 and gen7.5 devices, there could be leftover data residuals in
EU/L3 from the retiring context. This patch introduces workaround to clear
that residual contexts, by submitting a batch buffer with dedicated HW
context to the GPU with ring allocation for each context switching.
This security mitigation changes does not triggers any performance
regression. Performance is on par with current drm-tips.
v2: Add igt generated header file for CB kernel assembled with Mesa tool
and addressed use of Kernel macro for ptr_align comment.
v3: Resolve Sparse warnings with newly generated, and imported CB
kernel.
v4: Include new igt generated CB kernel for gen7 and gen7.5. Also
add code formatting and compiler warnings changes (Chris Wilson)
Signed-off-by: Mika Kuoppala
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Akeem G Abodunrin
Cc: Chris Wilson
Cc: Balestrieri Francesco
Cc: Bloomfield Jon
Cc: Dutt Sudeep
Acked-by: Chris Wilson
Link:
https://patchwork.freedesktop.org/patch/msgid/20200304130353.2448417-2-ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/gen7_renderclear.c| 402 ++
drivers/gpu/drm/i915/gt/gen7_renderclear.h| 15 +
drivers/gpu/drm/i915/gt/hsw_clear_kernel.c| 61 +++
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 17 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 3 +-
drivers/gpu/drm/i915/gt/ivb_clear_kernel.c| 61 +++
7 files changed, 556 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.c
create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.h
create mode 100644 drivers/gpu/drm/i915/gt/hsw_clear_kernel.c
create mode 100644 drivers/gpu/drm/i915/gt/ivb_clear_kernel.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 991a8c537d12..9f887a86e555 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -80,6 +80,7 @@ gt-y += \
gt/debugfs_gt.o \
gt/debugfs_gt_pm.o \
gt/gen6_ppgtt.o \
+ gt/gen7_renderclear.o \
gt/gen8_ppgtt.o \
gt/intel_breadcrumbs.o \
gt/intel_context.o \
diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
new file mode 100644
index ..de595b66a746
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
@@ -0,0 +1,402 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include "gen7_renderclear.h"
+#include "i915_drv.h"
+#include "intel_gpu_commands.h"
+
+#define MAX_URB_ENTRIES 64
+#define STATE_SIZE (4 * 1024)
+#define GT3_INLINE_DATA_DELAYS 0x1E00
+#define batch_advance(Y, CS) GEM_BUG_ON((Y)->end != (CS))
+
+struct cb_kernel {
+ const void *data;
+ u32 size;
+};
+
+#define CB_KERNEL(name) { .data = (name), .size = sizeof(name) }
+
+#include "ivb_clear_kernel.c"
+static const struct cb_kernel cb_kernel_ivb = CB_KERNEL(ivb_clear_kernel);
+
+#include "hsw_clear_kernel.c"
+static const struct cb_kernel cb_kernel_hsw = CB_KERNEL(hsw_clear_kernel);
+
+struct batch_chunk {
+ struct i915_vma *vma;
+ u32 offset;
+ u32 *start;
+ u32 *end;
+ u32 max_items;
+};
+
+struct batch_vals {
+ u32 max_primitives;
+ u32 max_urb_entries;
+ u32 cmd_size;
+ u32 state_size;
+ u32 state_start;
+ u32 batch_size;
+ u32 surface_height;
+ u32 surface_width;
+ u32 scratch_size;
+ u32 max_size;
+};
+
+static void
+batch_get_defaults(struct drm_i915_private *i915, struct batch_vals *bv)
+{
+ if (IS_HASWELL(i915)) {
+ bv->max_primitives = 280;
+ bv->max_urb_entries = MAX_URB_ENTRIES;
+ bv->surface_height = 16 * 16;
+ bv->surface_width = 32 * 2 * 16;
+ } else {
+ bv->max_primitives = 128;
+ bv->max_urb_entries = MAX_URB_ENTRIES / 2;
+ bv->surface_height = 16 * 8;
+ bv->surface_width = 32 * 16;
+ }
+ bv->cmd_size = bv->max_primitives * 4096;
+ bv->state_size = STATE_SIZE;
+ bv->state_start = bv->cmd_size;
+ bv->batch_size = bv->cmd_size + bv->state_size;
+ bv->scratch_size = bv->surface_height * bv->surface_width;
+ bv->max_size = bv->batch_size + bv->scratch_size;
+}
+
+static void batch_init(struct batch_chunk *bc,
+ struct i915_vma *vma,
+ u32 *start, u32 offset, u32 max_bytes)
+{
+ bc->vma = vma;
+ bc->offset = offset;
+ bc->start = start + bc->offset / sizeof(*bc->start);
+ bc->end = bc->start;
+ bc->max_items = max_bytes / sizeof(*bc->start);
+}
+
+static u32 batch_offset(const struct batch_chunk *bc, u32 *cs)
+{
+ return (cs - bc->start) * sizeof(*bc->start) + bc->offset;
+}
+
+static u32 batch_addr(const struct batch_chunk *bc)
+{
+ return bc->vma->node.star
[Intel-gfx] [CI 1/2] drm/i915: Add mechanism to submit a context WA on ring submission
From: Mika Kuoppala
This patch adds framework to submit an arbitrary batchbuffer on each
context switch to clear residual state for render engine on Gen7/7.5
devices.
The idea of always emitting the context and vm setup around each request
is primary to make reset recovery easy, and not require rewriting the
ringbuffer. As each request would set up its own context, leaving it to
the HW to notice and elide no-op context switches, we could restart the
ring at any point, and reorder the requests freely.
However, to avoid emitting clear_residuals() between consecutive requests
in the ringbuffer of the same context, we do want to track the current
context in the ring. In doing so, we need to be careful to only record a
context switch when we are sure the next request will be emitted.
This security mitigation change does not trigger any performance
regression. Performance is on par with current mainline/drm-tip.
v2: Update vm_alias params to point to correct address space "vm" due to
changes made in the patch "f21613797bae98773"
v3-v4: none
Signed-off-by: Mika Kuoppala
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Akeem G Abodunrin
Cc: Chris Wilson
Cc: Balestrieri Francesco
Cc: Bloomfield Jon
Cc: Dutt Sudeep
Reviewed-by: Chris Wilson
Link:
https://patchwork.freedesktop.org/patch/msgid/20200304130353.2448417-1-ch...@chris-wilson.co.uk
---
.../gpu/drm/i915/gt/intel_ring_submission.c | 138 -
.../drm/i915/gt/selftest_ring_submission.c| 287 ++
.../drm/i915/selftests/i915_live_selftests.h | 1 +
3 files changed, 422 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/selftest_ring_submission.c
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index ee241b7eaa3b..f0ce70861e93 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -1356,7 +1356,9 @@ static int load_pd_dir(struct i915_request *rq,
return rq->engine->emit_flush(rq, EMIT_FLUSH);
}
-static inline int mi_set_context(struct i915_request *rq, u32 flags)
+static inline int mi_set_context(struct i915_request *rq,
+struct intel_context *ce,
+u32 flags)
{
struct drm_i915_private *i915 = rq->i915;
struct intel_engine_cs *engine = rq->engine;
@@ -1431,7 +1433,7 @@ static inline int mi_set_context(struct i915_request *rq,
u32 flags)
*cs++ = MI_NOOP;
*cs++ = MI_SET_CONTEXT;
- *cs++ = i915_ggtt_offset(rq->context->state) | flags;
+ *cs++ = i915_ggtt_offset(ce->state) | flags;
/*
* w/a: MI_SET_CONTEXT must always be followed by MI_NOOP
* WaMiSetContext_Hang:snb,ivb,vlv
@@ -1546,13 +1548,56 @@ static int switch_mm(struct i915_request *rq, struct
i915_address_space *vm)
return rq->engine->emit_flush(rq, EMIT_INVALIDATE);
}
+static int clear_residuals(struct i915_request *rq)
+{
+ struct intel_engine_cs *engine = rq->engine;
+ int ret;
+
+ ret = switch_mm(rq, vm_alias(engine->kernel_context->vm));
+ if (ret)
+ return ret;
+
+ if (engine->kernel_context->state) {
+ ret = mi_set_context(rq,
+engine->kernel_context,
+MI_MM_SPACE_GTT | MI_RESTORE_INHIBIT);
+ if (ret)
+ return ret;
+ }
+
+ ret = engine->emit_bb_start(rq,
+ engine->wa_ctx.vma->node.start, 0,
+ 0);
+ if (ret)
+ return ret;
+
+ ret = engine->emit_flush(rq, EMIT_FLUSH);
+ if (ret)
+ return ret;
+
+ /* Always invalidate before the next switch_mm() */
+ return engine->emit_flush(rq, EMIT_INVALIDATE);
+}
+
static int switch_context(struct i915_request *rq)
{
+ struct intel_engine_cs *engine = rq->engine;
struct intel_context *ce = rq->context;
+ void **residuals = NULL;
int ret;
GEM_BUG_ON(HAS_EXECLISTS(rq->i915));
+ if (engine->wa_ctx.vma && ce != engine->kernel_context) {
+ if (engine->wa_ctx.vma->private != ce) {
+ ret = clear_residuals(rq);
+ if (ret)
+ return ret;
+
+ residuals = &engine->wa_ctx.vma->private;
+ }
+ }
+
ret = switch_mm(rq, vm_alias(ce->vm));
if (ret)
return ret;
@@ -1560,7 +1605,7 @@ static int switch_context(struct i915_request *rq)
if (ce->state) {
u32 flags;
- GEM_BUG_ON(rq->engine->id != RCS0);
+ GEM_BUG_ON(engine->id != RCS0);
/* For resource streamer on HSW+ and power context elsewhere */
BUILD_BUG_ON(HSW_MI_RS_SAVE_STATE_EN != MI_SAVE_EXT_S
Re: [Intel-gfx] [igt-dev] [PATCH] i915/gem_exec_params: add test_invalid_batch_start
Matthew Auld writes:
> Sanity check that kernel rejects too large batch_start_offset.
>
> Signed-off-by: Matthew Auld
> Cc: Chris Wilson
> ---
> tests/i915/gem_exec_params.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/tests/i915/gem_exec_params.c b/tests/i915/gem_exec_params.c
> index cf7ea306..afc8d2c7 100644
> --- a/tests/i915/gem_exec_params.c
> +++ b/tests/i915/gem_exec_params.c
> @@ -268,6 +268,23 @@ static void mmapped(int i915)
> gem_close(i915, buf);
> }
>
> +static void test_invalid_batch_start(int fd)
> +{
> + struct drm_i915_gem_exec_object2 exec = {
> + .handle = batch_create(fd),
> + };
> + struct drm_i915_gem_execbuffer2 execbuf = {
> + .buffers_ptr = to_user_pointer(&exec),
> + .buffer_count = 1,
> + .batch_start_offset = 4096, /* space jump */
If we could get batch size from the handle would be
more documentative.
Reviewed-by: Mika Kuoppala
> + };
> +
> + igt_assert_eq(__gem_execbuf(fd, &execbuf), -EINVAL);
> +
> + gem_sync(fd, exec.handle);
> + gem_close(fd, exec.handle);
> +}
> +
> struct drm_i915_gem_execbuffer2 execbuf;
> struct drm_i915_gem_exec_object2 gem_exec[1];
> uint32_t batch[2] = {MI_BATCH_BUFFER_END};
> @@ -507,6 +524,9 @@ igt_main
> igt_subtest("batch-first")
> test_batch_first(fd);
>
> + igt_subtest("invalid-batch-start-offset")
> + test_invalid_batch_start(fd);
> +
> #define DIRT(name) \
> igt_subtest(#name "-dirt") { \
> execbuf.flags = 0; \
> --
> 2.20.1
>
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915: properly sanity check batch_start_offset
== Series Details == Series: drm/i915: properly sanity check batch_start_offset URL : https://patchwork.freedesktop.org/series/74287/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_dpll_mgr.h:285: warning: Function parameter or member 'get_freq' not described in 'intel_shared_dpll_funcs' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: properly sanity check batch_start_offset
Matthew Auld writes:
> Check the edge case where batch_start_offset sits exactly on the batch
> size.
>
> Testcase: igt/gem_exec_params/invalid-batch-start-offset
> Fixes: 0b5372727be3 ("drm/i915/cmdparser: Use cached vmappings")
> Signed-off-by: Matthew Auld
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 7bb27f382af7..5247de18a3d0 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -2714,7 +2714,8 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> goto err_vma;
> }
>
> - if (range_overflows_t(u64,
> + if (eb.batch_start_offset == eb.batch->vma->size ||
> + range_overflows_t(u64,
> eb.batch_start_offset, eb.batch_len,
Can we sanitize the batch_len apriori?
Not that this would not work,
Reviewed-by: Mika Kuoppala
> eb.batch->vma->size)) {
> drm_dbg(&i915->drm, "Attempting to use out-of-bounds batch\n");
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RESEND PATCH v2 0/7] drm: drm_fb_helper cleanup.
This series addresses below drm_fb_helper tasks from
Documentation/gpu/todo.rst.
- The max connector argument for drm_fb_helper_init() isn't used
anymore and can be removed.
- The helper doesn't keep an array of connectors anymore so these can
be removed: drm_fb_helper_single_add_all_connectors(),
drm_fb_helper_add_one_connector() and
drm_fb_helper_remove_one_connector().
Changes since v1:
- Accumulated all review tags into individual commits (Emil, Daniel)
- Squashed warning fixes into the patch that introduced the
warnings (into 5/7) (Laurent, Emil, Lyude)
- Remove entire drm_fb_helper tasks from todo list. Daniel's
"64914da24ea9 drm/fbdev-helper: don't force restores" fixes first
one (Daniel)
Pankaj Bharadiya (7):
drm: Remove unused arg from drm_fb_helper_init
drm/radeon: remove radeon_fb_{add,remove}_connector functions
drm/amdgpu: Remove drm_fb_helper_{add,remove}_one_connector calls
drm/i915/display: Remove drm_fb_helper_{add,remove}_one_connector calls
drm: Remove drm_fb_helper add, add all and remove connector calls
drm/fb-helper: Remove drm_fb_helper add, add_all and remove connector
functions
drm/todo: Update drm_fb_helper tasks
Documentation/gpu/todo.rst| 17
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 5 +---
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 13 -
drivers/gpu/drm/armada/armada_fbdev.c | 8 +-
drivers/gpu/drm/bridge/tc358764.c | 3 ---
drivers/gpu/drm/drm_fb_helper.c | 6 ++---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1 -
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 10 +--
drivers/gpu/drm/gma500/framebuffer.c | 6 +
drivers/gpu/drm/i915/display/intel_dp_mst.c | 12 -
drivers/gpu/drm/i915/display/intel_fbdev.c| 4 +--
drivers/gpu/drm/msm/msm_fbdev.c | 6 +
drivers/gpu/drm/nouveau/dispnv50/disp.c | 7 -
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 6 +
drivers/gpu/drm/omapdrm/omap_fbdev.c | 6 +
drivers/gpu/drm/radeon/radeon_dp_mst.c| 10 ---
drivers/gpu/drm/radeon/radeon_fb.c| 19 +
drivers/gpu/drm/radeon/radeon_mode.h | 3 ---
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 9 +--
drivers/gpu/drm/tegra/fb.c| 8 +-
include/drm/drm_fb_helper.h | 27 ++-
21 files changed, 15 insertions(+), 171 deletions(-)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RESEND PATCH v2 3/7] drm/amdgpu: Remove drm_fb_helper_{add, remove}_one_connector calls
drm_fb_helper_{add,remove}_one_connector() are dummy functions now
and serve no purpose. Hence remove their calls.
This is the preparatory step for removing the
drm_fb_helper_{add,remove}_one_connector() functions from
drm_fb_helper.h
Signed-off-by: Pankaj Bharadiya
Reviewed-by: Emil Velikov
Reviewed-by: Alex Deucher
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 0ef0eeb16778..0c4faba8ed28 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -440,9 +440,6 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
static void dm_dp_destroy_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
struct drm_connector *connector)
{
- struct amdgpu_dm_connector *master = container_of(mgr, struct
amdgpu_dm_connector, mst_mgr);
- struct drm_device *dev = master->base.dev;
- struct amdgpu_device *adev = dev->dev_private;
struct amdgpu_dm_connector *aconnector =
to_amdgpu_dm_connector(connector);
DRM_INFO("DM_MST: Disabling connector: %p [id: %d] [master: %p]\n",
@@ -457,21 +454,11 @@ static void dm_dp_destroy_mst_connector(struct
drm_dp_mst_topology_mgr *mgr,
}
drm_connector_unregister(connector);
- if (adev->mode_info.rfbdev)
-
drm_fb_helper_remove_one_connector(&adev->mode_info.rfbdev->helper, connector);
drm_connector_put(connector);
}
static void dm_dp_mst_register_connector(struct drm_connector *connector)
{
- struct drm_device *dev = connector->dev;
- struct amdgpu_device *adev = dev->dev_private;
-
- if (adev->mode_info.rfbdev)
-
drm_fb_helper_add_one_connector(&adev->mode_info.rfbdev->helper, connector);
- else
- DRM_ERROR("adev->mode_info.rfbdev is NULL\n");
-
drm_connector_register(connector);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RESEND PATCH v2 2/7] drm/radeon: remove radeon_fb_{add, remove}_connector functions
drm_fb_helper_{add,remove}_one_connector() are dummy functions now
and serve no purpose. Hence remove their calls.
This is the preparatory step for removing the
drm_fb_helper_{add,remove}_one_connector() functions from
drm_fb_helper.h
Signed-off-by: Pankaj Bharadiya
Reviewed-by: Emil Velikov
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_dp_mst.c | 10 --
drivers/gpu/drm/radeon/radeon_fb.c | 12
drivers/gpu/drm/radeon/radeon_mode.h | 3 ---
3 files changed, 25 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_dp_mst.c
b/drivers/gpu/drm/radeon/radeon_dp_mst.c
index 28eef9282874..5a9fb0ad175a 100644
--- a/drivers/gpu/drm/radeon/radeon_dp_mst.c
+++ b/drivers/gpu/drm/radeon/radeon_dp_mst.c
@@ -303,23 +303,13 @@ static struct drm_connector
*radeon_dp_add_mst_connector(struct drm_dp_mst_topol
static void radeon_dp_register_mst_connector(struct drm_connector *connector)
{
- struct drm_device *dev = connector->dev;
- struct radeon_device *rdev = dev->dev_private;
-
- radeon_fb_add_connector(rdev, connector);
-
drm_connector_register(connector);
}
static void radeon_dp_destroy_mst_connector(struct drm_dp_mst_topology_mgr
*mgr,
struct drm_connector *connector)
{
- struct radeon_connector *master = container_of(mgr, struct
radeon_connector, mst_mgr);
- struct drm_device *dev = master->base.dev;
- struct radeon_device *rdev = dev->dev_private;
-
drm_connector_unregister(connector);
- radeon_fb_remove_connector(rdev, connector);
drm_connector_cleanup(connector);
kfree(connector);
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c
b/drivers/gpu/drm/radeon/radeon_fb.c
index 85548cf2529a..1c02cd771d52 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -403,15 +403,3 @@ bool radeon_fbdev_robj_is_fb(struct radeon_device *rdev,
struct radeon_bo *robj)
return true;
return false;
}
-
-void radeon_fb_add_connector(struct radeon_device *rdev, struct drm_connector
*connector)
-{
- if (rdev->mode_info.rfbdev)
-
drm_fb_helper_add_one_connector(&rdev->mode_info.rfbdev->helper, connector);
-}
-
-void radeon_fb_remove_connector(struct radeon_device *rdev, struct
drm_connector *connector)
-{
- if (rdev->mode_info.rfbdev)
-
drm_fb_helper_remove_one_connector(&rdev->mode_info.rfbdev->helper, connector);
-}
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
b/drivers/gpu/drm/radeon/radeon_mode.h
index 629567da29f1..c7f223743d46 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -986,9 +986,6 @@ bool radeon_fbdev_robj_is_fb(struct radeon_device *rdev,
struct radeon_bo *robj)
void radeon_crtc_handle_vblank(struct radeon_device *rdev, int crtc_id);
-void radeon_fb_add_connector(struct radeon_device *rdev, struct drm_connector
*connector);
-void radeon_fb_remove_connector(struct radeon_device *rdev, struct
drm_connector *connector);
-
void radeon_crtc_handle_flip(struct radeon_device *rdev, int crtc_id);
int radeon_align_pitch(struct radeon_device *rdev, int width, int bpp, bool
tiled);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for i915/gem_exec_params: add test_invalid_batch_start
== Series Details == Series: i915/gem_exec_params: add test_invalid_batch_start URL : https://patchwork.freedesktop.org/series/74289/ State : failure == Summary == Applying: i915/gem_exec_params: add test_invalid_batch_start error: sha1 information is lacking or useless (tests/i915/gem_exec_params.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 i915/gem_exec_params: add test_invalid_batch_start When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RESEND PATCH v2 1/7] drm: Remove unused arg from drm_fb_helper_init
The max connector argument for drm_fb_helper_init() isn't used anymore
hence remove it.
All the drm_fb_helper_init() calls are modified with below sementic
patch.
@@
expression E1, E2, E3;
@@
- drm_fb_helper_init(E1,E2, E3)
+ drm_fb_helper_init(E1,E2)
Signed-off-by: Pankaj Bharadiya
Reviewed-by: Emil Velikov
Reviewed-by: Thomas Zimmermann
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 3 +--
drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
drivers/gpu/drm/drm_fb_helper.c | 6 ++
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +-
drivers/gpu/drm/gma500/framebuffer.c | 2 +-
drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +-
drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +-
drivers/gpu/drm/radeon/radeon_fb.c| 3 +--
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 2 +-
drivers/gpu/drm/tegra/fb.c| 2 +-
include/drm/drm_fb_helper.h | 6 ++
13 files changed, 15 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 2672dc64a310..579d614c7b70 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -336,8 +336,7 @@ int amdgpu_fbdev_init(struct amdgpu_device *adev)
drm_fb_helper_prepare(adev->ddev, &rfbdev->helper,
&amdgpu_fb_helper_funcs);
- ret = drm_fb_helper_init(adev->ddev, &rfbdev->helper,
-AMDGPUFB_CONN_LIMIT);
+ ret = drm_fb_helper_init(adev->ddev, &rfbdev->helper);
if (ret) {
kfree(rfbdev);
return ret;
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c
b/drivers/gpu/drm/armada/armada_fbdev.c
index ac8a78bfda03..6254353c00ae 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -129,7 +129,7 @@ int armada_fbdev_init(struct drm_device *dev)
drm_fb_helper_prepare(dev, fbh, &armada_fb_helper_funcs);
- ret = drm_fb_helper_init(dev, fbh, 1);
+ ret = drm_fb_helper_init(dev, fbh);
if (ret) {
DRM_ERROR("failed to initialize drm fb helper\n");
goto err_fb_helper;
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 490a99de6ec1..a9771de4d17e 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -450,7 +450,6 @@ EXPORT_SYMBOL(drm_fb_helper_prepare);
* drm_fb_helper_init - initialize a &struct drm_fb_helper
* @dev: drm device
* @fb_helper: driver-allocated fbdev helper structure to initialize
- * @max_conn_count: max connector count (not used)
*
* This allocates the structures for the fbdev helper with the given limits.
* Note that this won't yet touch the hardware (through the driver interfaces)
@@ -463,8 +462,7 @@ EXPORT_SYMBOL(drm_fb_helper_prepare);
* Zero if everything went ok, nonzero otherwise.
*/
int drm_fb_helper_init(struct drm_device *dev,
- struct drm_fb_helper *fb_helper,
- int max_conn_count)
+ struct drm_fb_helper *fb_helper)
{
int ret;
@@ -2125,7 +2123,7 @@ static int drm_fbdev_client_hotplug(struct drm_client_dev
*client)
drm_fb_helper_prepare(dev, fb_helper, &drm_fb_helper_generic_funcs);
- ret = drm_fb_helper_init(dev, fb_helper, 0);
+ ret = drm_fb_helper_init(dev, fb_helper);
if (ret)
goto err;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 647a1fd1d815..5afecb6a30ad 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -200,7 +200,7 @@ int exynos_drm_fbdev_init(struct drm_device *dev)
drm_fb_helper_prepare(dev, helper, &exynos_drm_fb_helper_funcs);
- ret = drm_fb_helper_init(dev, helper, MAX_CONNECTOR);
+ ret = drm_fb_helper_init(dev, helper);
if (ret < 0) {
DRM_DEV_ERROR(dev->dev,
"failed to initialize drm fb helper.\n");
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index 1459076d1980..fe892e1243db 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -513,7 +513,7 @@ int psb_fbdev_init(struct drm_device *dev)
drm_fb_helper_prepare(dev, fb_helper, &psb_fb_helper_funcs);
- ret = drm_fb_helper_init(dev, fb_helper, INTELFB_CONN_LIMIT);
+ ret = drm_fb_helper_init(dev, fb_helper);
if (ret)
goto free;
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index b6ee0d902003..8f65963266a3 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/dri
[Intel-gfx] [RESEND PATCH v2 4/7] drm/i915/display: Remove drm_fb_helper_{add, remove}_one_connector calls
drm_fb_helper_{add,remove}_one_connector() are dummy functions now
and serve no purpose. Hence remove their calls.
This is the preparatory step for removing the
drm_fb_helper_{add,remove}_one_connector() functions from
drm_fb_helper.h
Signed-off-by: Pankaj Bharadiya
Reviewed-by: Emil Velikov
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 39f5de9a8c7c..d53978ed3c12 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -721,27 +721,15 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
static void intel_dp_register_mst_connector(struct drm_connector *connector)
{
- struct drm_i915_private *dev_priv = to_i915(connector->dev);
-
- if (dev_priv->fbdev)
- drm_fb_helper_add_one_connector(&dev_priv->fbdev->helper,
- connector);
-
drm_connector_register(connector);
}
static void intel_dp_destroy_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
struct drm_connector *connector)
{
- struct drm_i915_private *dev_priv = to_i915(connector->dev);
-
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
connector->name);
drm_connector_unregister(connector);
- if (dev_priv->fbdev)
- drm_fb_helper_remove_one_connector(&dev_priv->fbdev->helper,
- connector);
-
drm_connector_put(connector);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RESEND PATCH v2 5/7] drm: Remove drm_fb_helper add, add all and remove connector calls
drm_fb_helper_{add,remove}_one_connector() and
drm_fb_helper_single_add_all_connectors() are dummy functions now
and serve no purpose. Hence remove their calls.
This is the preparatory step for removing the
drm_fb_helper_{add,remove}_one_connector() functions from
drm_fb_helper.h
This removal is done using below sementic patch and unused variable
compilation warnings are fixed manually.
@@
@@
- drm_fb_helper_single_add_all_connectors(...);
@@
expression e1;
statement S;
@@
- e1 = drm_fb_helper_single_add_all_connectors(...);
- S
@@
@@
- drm_fb_helper_add_one_connector(...);
@@
@@
- drm_fb_helper_remove_one_connector(...);
Changes since v1:
* Squashed warning fixes into the patch that introduced the
warnings (into 5/7) (Laurent, Emil, Lyude)
Signed-off-by: Pankaj Bharadiya
Reviewed-by: Laurent Pinchart
Reviewed-by: Emil Velikov
Reviewed-by: Alex Deucher
Reviewed-by: Lyude Paul
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 2 --
drivers/gpu/drm/armada/armada_fbdev.c | 6 --
drivers/gpu/drm/bridge/tc358764.c | 3 ---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1 -
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 8
drivers/gpu/drm/gma500/framebuffer.c | 4
drivers/gpu/drm/i915/display/intel_fbdev.c| 2 --
drivers/gpu/drm/msm/msm_fbdev.c | 4
drivers/gpu/drm/nouveau/dispnv50/disp.c | 7 ---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 4
drivers/gpu/drm/omapdrm/omap_fbdev.c | 4
drivers/gpu/drm/radeon/radeon_fb.c| 4
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 7 ---
drivers/gpu/drm/tegra/fb.c| 6 --
14 files changed, 62 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 579d614c7b70..9ae7b61f696a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -342,8 +342,6 @@ int amdgpu_fbdev_init(struct amdgpu_device *adev)
return ret;
}
- drm_fb_helper_single_add_all_connectors(&rfbdev->helper);
-
/* disable all the possible outputs/crtcs before entering KMS mode */
if (!amdgpu_device_has_dc_support(adev))
drm_helper_disable_unused_functions(adev->ddev);
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c
b/drivers/gpu/drm/armada/armada_fbdev.c
index 6254353c00ae..f2dc371bd8e5 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -135,12 +135,6 @@ int armada_fbdev_init(struct drm_device *dev)
goto err_fb_helper;
}
- ret = drm_fb_helper_single_add_all_connectors(fbh);
- if (ret) {
- DRM_ERROR("failed to add fb connectors\n");
- goto err_fb_setup;
- }
-
ret = drm_fb_helper_initial_config(fbh, 32);
if (ret) {
DRM_ERROR("failed to set initial config\n");
diff --git a/drivers/gpu/drm/bridge/tc358764.c
b/drivers/gpu/drm/bridge/tc358764.c
index 283e4a8dd923..5ac1430fab04 100644
--- a/drivers/gpu/drm/bridge/tc358764.c
+++ b/drivers/gpu/drm/bridge/tc358764.c
@@ -375,7 +375,6 @@ static int tc358764_attach(struct drm_bridge *bridge,
drm_connector_attach_encoder(&ctx->connector, bridge->encoder);
drm_panel_attach(ctx->panel, &ctx->connector);
ctx->connector.funcs->reset(&ctx->connector);
- drm_fb_helper_add_one_connector(drm->fb_helper, &ctx->connector);
drm_connector_register(&ctx->connector);
return 0;
@@ -384,10 +383,8 @@ static int tc358764_attach(struct drm_bridge *bridge,
static void tc358764_detach(struct drm_bridge *bridge)
{
struct tc358764 *ctx = bridge_to_tc358764(bridge);
- struct drm_device *drm = bridge->dev;
drm_connector_unregister(&ctx->connector);
- drm_fb_helper_remove_one_connector(drm->fb_helper, &ctx->connector);
drm_panel_detach(ctx->panel);
ctx->panel = NULL;
drm_connector_put(&ctx->connector);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 342d2a723a0e..e080aa92338c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1514,7 +1514,6 @@ static int exynos_dsi_create_connector(struct drm_encoder
*encoder)
return 0;
connector->funcs->reset(connector);
- drm_fb_helper_add_one_connector(drm->fb_helper, connector);
drm_connector_register(connector);
return 0;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 5afecb6a30ad..e6ceaf36fb04 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -207,14 +207,6 @@ int exynos_drm_fbdev_init(struct drm_device *dev)
goto err_init;
}
- ret = drm_fb_helper_single_add_all_connectors(helper)
[Intel-gfx] [RESEND PATCH v2 7/7] drm/todo: Update drm_fb_helper tasks
drm_fb_helper tasks are completed now hence remove them from todo list. Changes since v1: * remove entire drm_fb_helper tasks from todo list. Daniel's "64914da24ea9 drm/fbdev-helper: don't force restores" already fixes first one (Daniel) Signed-off-by: Pankaj Bharadiya Reviewed-by: Laurent Pinchart Reviewed-by: Emil Velikov --- Documentation/gpu/todo.rst | 17 - 1 file changed, 17 deletions(-) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index ccf5e8e34222..439656f55c5d 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -359,23 +359,6 @@ Contact: Sean Paul Level: Starter -drm_fb_helper tasks - -- drm_fb_helper_restore_fbdev_mode_unlocked() should call restore_fbdev_mode() - not the _force variant so it can bail out if there is a master. But first - these igt tests need to be fixed: kms_fbcon_fbt@psr and - kms_fbcon_fbt@psr-suspend. - -- The max connector argument for drm_fb_helper_init() isn't used anymore and - can be removed. - -- The helper doesn't keep an array of connectors anymore so these can be - removed: drm_fb_helper_single_add_all_connectors(), - drm_fb_helper_add_one_connector() and drm_fb_helper_remove_one_connector(). - -Level: Intermediate - connector register/unregister fixes --- -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RESEND PATCH v2 6/7] drm/fb-helper: Remove drm_fb_helper add, add_all and remove connector functions
drm_fb_helper_single_add_all_connectors(),
drm_fb_helper_add_one_connector()
and drm_fb_helper_remove_one_connector() don't keep an array of
connectors anymore and are just dummy. Now we have no callers to these
functions hence remove them.
Signed-off-by: Pankaj Bharadiya
Reviewed-by: Laurent Pinchart
Reviewed-by: Emil Velikov
Reviewed-by: Alex Deucher
---
include/drm/drm_fb_helper.h | 21 -
1 file changed, 21 deletions(-)
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 62e8dda6d1d1..208dbf87afa3 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -451,27 +451,6 @@ drm_fbdev_generic_setup(struct drm_device *dev, unsigned
int preferred_bpp)
#endif
-/* TODO: There's a todo entry to remove these three */
-static inline int
-drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper)
-{
- return 0;
-}
-
-static inline int
-drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
- struct drm_connector *connector)
-{
- return 0;
-}
-
-static inline int
-drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
- struct drm_connector *connector)
-{
- return 0;
-}
-
/**
* drm_fb_helper_remove_conflicting_framebuffers - remove firmware-configured
framebuffers
* @a: memory range, users of which are to be removed
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: properly sanity check batch_start_offset
== Series Details == Series: drm/i915: properly sanity check batch_start_offset URL : https://patchwork.freedesktop.org/series/74287/ State : success == Summary == CI Bug Log - changes from CI_DRM_8068 -> Patchwork_16826 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16826/index.html Known issues Here are the changes found in Patchwork_16826 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@module-reload: - fi-skl-6770hq: [PASS][1] -> [DMESG-WARN][2] ([i915#92]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-skl-6770hq/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16826/fi-skl-6770hq/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@gem_contexts: - fi-cml-s: [PASS][3] -> [DMESG-FAIL][4] ([i915#877]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-cml-s/igt@i915_selftest@live@gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16826/fi-cml-s/igt@i915_selftest@live@gem_contexts.html * igt@i915_selftest@live@gt_heartbeat: - fi-kbl-soraka: [PASS][5] -> [DMESG-FAIL][6] ([fdo#112406]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16826/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][7] -> [FAIL][8] ([fdo#111096] / [i915#323]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16826/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-skl-6770hq: [PASS][9] -> [SKIP][10] ([fdo#109271]) +5 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16826/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html * igt@kms_pipe_crc_basic@read-crc-pipe-b: - fi-skl-6770hq: [PASS][11] -> [DMESG-WARN][12] ([i915#106]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16826/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html * igt@prime_vgem@basic-read: - fi-tgl-y: [PASS][13] -> [DMESG-WARN][14] ([CI#94] / [i915#402]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-tgl-y/igt@prime_v...@basic-read.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16826/fi-tgl-y/igt@prime_v...@basic-read.html Possible fixes * igt@i915_getparams_basic@basic-eu-total: - fi-tgl-y: [DMESG-WARN][15] ([CI#94] / [i915#402]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-tgl-y/igt@i915_getparams_ba...@basic-eu-total.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16826/fi-tgl-y/igt@i915_getparams_ba...@basic-eu-total.html * igt@i915_selftest@live@gem_contexts: - fi-cfl-8700k: [INCOMPLETE][17] ([i915#424]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-cfl-8700k/igt@i915_selftest@live@gem_contexts.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16826/fi-cfl-8700k/igt@i915_selftest@live@gem_contexts.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096 [fdo#112406]: https://bugs.freedesktop.org/show_bug.cgi?id=112406 [i915#106]: https://gitlab.freedesktop.org/drm/intel/issues/106 [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424 [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 Participating hosts (52 -> 46) -- Additional (1): fi-gdg-551 Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8068 -> Patchwork_16826 CI-20190529: 20190529 CI_DRM_8068: f8e69af5cca45947ebce78f677b75b0ecc4ba744 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5492: 2be153507cdd652843f6ab44cc2a52a7f30206d9 @ git://anongit.freedeskto
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Exercise bonded-payload synchronisation
On 05/03/2020 11:15, Chris Wilson wrote:
Our goal with bonded submission is to submit the pair of user batches to
the HW at roughly the same time, and trying to avoid any bubbles. If we
submit the secondary batch too early, it will be running before the
first and stuck on the HW preventing others from utilising the GPU. At
worst, it may even appear unresponsive and trigger a GPU hang as it
waits for its master. If we submit the secondary too late, the reverse
situation may apply to the master as it has to wait to the secondaries.
This test tries to verify that using a submit-fence to create a bonded
pair does not prevent others from using the HW. By using a pair of
spinners, we can create a bonded hog that when set in motion will fully
utilize both engines [if the scheduling is incorrect]. We then use a
third party submitted after the bonded pair to cancel the spinner from
the GPU -- if it is unable to run, the spinner is never cancelled, and
the bonded pair will cause a GPU hang.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_exec_balancer.c | 91 ++
1 file changed, 91 insertions(+)
diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
index 69f0100ff..e1f9ce625 100644
--- a/tests/i915/gem_exec_balancer.c
+++ b/tests/i915/gem_exec_balancer.c
@@ -1240,6 +1240,94 @@ static void indices(int i915)
gem_quiescent_gpu(i915);
}
+static void __bonded_early(int i915, uint32_t ctx,
+ const struct i915_engine_class_instance *siblings,
+ unsigned int count)
+{
+ uint32_t handle = batch_create(i915);
+ struct drm_i915_gem_exec_object2 batch = {
+ .handle = handle,
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(&batch),
+ .buffer_count = 1,
+ .rsvd1 = ctx,
+ };
+ igt_spin_t *spin;
+
+ /* A: spin forever on engine 1 */
+ set_load_balancer(i915, ctx, siblings, count, NULL);
+ spin = igt_spin_new(i915,
+ .ctx = ctx,
+ .engine = 1,
+ .flags = IGT_SPIN_NO_PREEMPTION);
+
+ /* B: runs after A on engine 1 */
+ execbuf.flags = I915_EXEC_FENCE_OUT;
+ execbuf.flags |= 1;
+ gem_execbuf_wr(i915, &execbuf);
+
+ /* B': run in parallel with B on engine 2, i.e. not before A! */
+ set_load_balancer(i915, ctx, siblings, count, NULL);
+ execbuf.flags = I915_EXEC_FENCE_SUBMIT | I915_EXEC_FENCE_OUT;
+ execbuf.flags |= 2;
+ execbuf.rsvd2 >>= 32;
+ gem_execbuf_wr(i915, &execbuf);
+
+ /* C: prevent anything running on engine 2 after B' */
+ spin->execbuf.flags = 2;
+ gem_execbuf(i915, &spin->execbuf);
+
+ igt_debugfs_dump(i915, "i915_engine_info");
+
+ /* D: cancel the spinner from engine 2 (new timeline) */
+ set_load_balancer(i915, ctx, siblings, count, NULL);
+ batch.handle = create_semaphore_to_spinner(i915, spin);
+ execbuf.flags = 2;
+ gem_execbuf(i915, &execbuf);
+ gem_close(i915, batch.handle);
+
+ /* If C runs before D, we never cancel the spinner and so hang */
+ gem_sync(i915, handle);
+
+ /* Check the bonded pair completed successfully */
+ igt_assert_eq(sync_fence_status(execbuf.rsvd2 & 0x), 1);
+ igt_assert_eq(sync_fence_status(execbuf.rsvd2 >> 32), 1);
+
+ close(execbuf.rsvd2);
+ close(execbuf.rsvd2 >> 32);
+
+ gem_close(i915, handle);
+ igt_spin_free(i915, spin);
+}
+
+static void bonded_early(int i915)
+{
+ uint32_t ctx;
+
+ /*
+* Our goal is to start the bonded payloads at roughly the same time.
+* We do not want to start the secondary batch too early as it will
+* do nothing but hog the GPU until the first has a chance to execute.
+* So if we were to arbitrary delay the first by running it after a
+* spinner...
+*/
+
+ ctx = gem_context_create(i915);
+
+ for (int class = 0; class < 32; class++) {
+ struct i915_engine_class_instance *siblings;
+ unsigned int count;
+
+ siblings = list_engines(i915, 1u << class, &count);
+ if (count > 1)
+ __bonded_early(i915, ctx, siblings, count);
+ free(siblings);
+ }
+
+ gem_context_destroy(i915, ctx);
+}
+
static void busy(int i915)
{
uint32_t scratch = gem_create(i915, 4096);
@@ -1891,6 +1979,9 @@ igt_main
igt_subtest("bonded-semaphore")
bonded_semaphore(i915);
+ igt_subtest("bonded-early")
+ bonded_early(i915);
+
igt_fixture {
igt_stop_hang_detector();
}
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@l
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/gem: Limit struct_mutex to eb_reserve
== Series Details == Series: drm/i915/gem: Limit struct_mutex to eb_reserve URL : https://patchwork.freedesktop.org/series/74291/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_dpll_mgr.h:285: warning: Function parameter or member 'get_freq' not described in 'intel_shared_dpll_funcs' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/tgl: WaDisableGPGPUMidThreadPreemption
Quoting Tvrtko Ursulin (2020-03-04 15:31:44) > From: Tvrtko Ursulin > > Enable FtrPerCtxtPreemptionGranularityControl bit and select thread- > group as the default preemption level. > > v2: > * Remove register whitelisting (Rafael, Tony). > > Signed-off-by: Tvrtko Ursulin > Cc: Michał Winiarski > Cc: Joonas Lahtinen > Cc: piotr.zdunow...@intel.com > Cc: michal.mro...@intel.com > Cc: Tony Ye > Cc: Rafael Antognolli /me mutters So do we need to disable force-preemption on rcs if we can't do fine-grained preemption? Acked-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/tgl: WaDisableGPGPUMidThreadPreemption
On 3/5/2020 1:01 AM, Rafael Antognolli wrote: On Wed, Mar 04, 2020 at 04:24:13PM +, Tvrtko Ursulin wrote: On 04/03/2020 16:02, Rafael Antognolli wrote: On Wed, Mar 04, 2020 at 03:31:44PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Enable FtrPerCtxtPreemptionGranularityControl bit and select thread- group as the default preemption level. v2: * Remove register whitelisting (Rafael, Tony). Signed-off-by: Tvrtko Ursulin Cc: Michał Winiarski Cc: Joonas Lahtinen Cc: piotr.zdunow...@intel.com Cc: michal.mro...@intel.com Cc: Tony Ye Cc: Rafael Antognolli Thanks for CC'ing me. I also saw a reply from Jason yesterday, but I don't see it in the list now (though my mail client a mess lately). I saw nothing from Jason, but there was an email from you asking about interface descriptors and whitelisting which is why I copied you. But he asked whether it's possible for Media and OpenCL drivers to also disable mid-thread preemption through the INTERFACE_DESCRIPTOR_DATA, instead of from the kernel side, so we could try to experiment with it in the future. Also, do you have an idea of how broken it is? Or is it just not tested because no driver is currently implementing it? And do you know if the windows 3D drivers implement it at all? I see code in the driver that seems to me that it's only disabled in certain cases... To summarize, I think we should either: 1) Disable mid-thread preemption from the kernel and not whitelist the register (just like you do in this patch); or 2) Not do anything at all from the kernel, and let userspace disable it if needed. I think 2) is better, if it's not an issue to the other userspace drivers (OpenCL and Media). I know it is somewhat broken like in https://gitlab.freedesktop.org/drm/intel/issues/1293. And I know OpenCL and Media would prefer i915 to handle it, but that's always the case. :) OpenCL and Media folks are on the thread so can comment if they are okay with handling this themselves. Indeed a blanket ban in i915 means no one can try it out later without further kernel changes. Well, based on your comment from the previous patch: "General thinking is, since MTP is considered not validated / broken / dangerous, i915 should default it off. But yes, whitelisting or not on top is open." Maybe we should simply ban it and be done. So this patch is: Acked-by: Rafael Antognolli Acked-by: Tony Ye Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gem: Limit struct_mutex to eb_reserve
== Series Details == Series: drm/i915/gem: Limit struct_mutex to eb_reserve URL : https://patchwork.freedesktop.org/series/74291/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8068 -> Patchwork_16828 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16828 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16828, 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_16828/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_16828: ### IGT changes ### Possible regressions * igt@gem_exec_parallel@basic: - fi-skl-6700k2: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-skl-6700k2/igt@gem_exec_paral...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16828/fi-skl-6700k2/igt@gem_exec_paral...@basic.html * igt@gem_exec_parallel@contexts: - fi-skl-guc: [PASS][3] -> [TIMEOUT][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-skl-guc/igt@gem_exec_paral...@contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16828/fi-skl-guc/igt@gem_exec_paral...@contexts.html - fi-icl-dsi: [PASS][5] -> [TIMEOUT][6] +9 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-icl-dsi/igt@gem_exec_paral...@contexts.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16828/fi-icl-dsi/igt@gem_exec_paral...@contexts.html - fi-skl-6600u: [PASS][7] -> [TIMEOUT][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-skl-6600u/igt@gem_exec_paral...@contexts.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16828/fi-skl-6600u/igt@gem_exec_paral...@contexts.html - fi-skl-6770hq: [PASS][9] -> [INCOMPLETE][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-skl-6770hq/igt@gem_exec_paral...@contexts.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16828/fi-skl-6770hq/igt@gem_exec_paral...@contexts.html * igt@gem_exec_parallel@fds: - fi-cml-s: [PASS][11] -> [TIMEOUT][12] +8 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-cml-s/igt@gem_exec_paral...@fds.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16828/fi-cml-s/igt@gem_exec_paral...@fds.html - fi-cfl-guc: [PASS][13] -> [TIMEOUT][14] +9 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-cfl-guc/igt@gem_exec_paral...@fds.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16828/fi-cfl-guc/igt@gem_exec_paral...@fds.html - fi-skl-lmem:[PASS][15] -> [TIMEOUT][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-skl-lmem/igt@gem_exec_paral...@fds.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16828/fi-skl-lmem/igt@gem_exec_paral...@fds.html * igt@gem_exec_store@basic-all: - fi-cfl-8109u: [PASS][17] -> [TIMEOUT][18] +8 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-cfl-8109u/igt@gem_exec_st...@basic-all.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16828/fi-cfl-8109u/igt@gem_exec_st...@basic-all.html - fi-kbl-x1275: [PASS][19] -> [TIMEOUT][20] +8 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-kbl-x1275/igt@gem_exec_st...@basic-all.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16828/fi-kbl-x1275/igt@gem_exec_st...@basic-all.html - fi-icl-y: [PASS][21] -> [TIMEOUT][22] +8 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-icl-y/igt@gem_exec_st...@basic-all.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16828/fi-icl-y/igt@gem_exec_st...@basic-all.html * igt@gem_exec_suspend@basic: - fi-icl-u2: [PASS][23] -> [TIMEOUT][24] +9 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-icl-u2/igt@gem_exec_susp...@basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16828/fi-icl-u2/igt@gem_exec_susp...@basic.html * igt@gem_exec_suspend@basic-s0: - fi-cml-u2: [PASS][25] -> [TIMEOUT][26] +8 similar issues [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-cml-u2/igt@gem_exec_susp...@basic-s0.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16828/fi-cml-u2/igt@gem_exec_susp...@basic-s0.html - fi-kbl-r: [PASS][27] -> [TIMEOUT][28] +9 similar issues [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-kbl-r/igt@gem_exec_susp...@basic-s0.html [28]: https:
[Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [1/1] Revert "drm/i915/tgl: Add extra hdc flush workaround"
== Series Details == Series: series starting with [1/1] Revert "drm/i915/tgl: Add extra hdc flush workaround" URL : https://patchwork.freedesktop.org/series/74293/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_dpll_mgr.h:285: warning: Function parameter or member 'get_freq' not described in 'intel_shared_dpll_funcs' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Enable timeslice on partial virtual engine dequeue
Mika Kuoppala writes:
> Chris Wilson writes:
>
>> If we stop filling the ELSP due to an incompatible virtual engine
>> request, check if we should enable the timeslice on behalf of the queue.
>>
>
> Leaves me pondering more of the why.
>
> So that on these boundaries also, the last rq gets subdued to
> a timeslice and not get a free run?
I got some confirmations on irc. Yes this for that.
The commit message could be augmented on the why emphasis!
>
>> Signed-off-by: Chris Wilson
>> ---
>> drivers/gpu/drm/i915/gt/intel_lrc.c | 21 -
>> 1 file changed, 16 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
>> b/drivers/gpu/drm/i915/gt/intel_lrc.c
>> index 5da86a40434c..954bd4797482 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
>> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
>> @@ -1802,6 +1802,20 @@ static void set_timeslice(struct intel_engine_cs
>> *engine)
>> set_timer_ms(&engine->execlists.timer, active_timeslice(engine));
>> }
>>
>> +static void start_timeslice(struct intel_engine_cs *engine,
>> +struct i915_request *last)
>> +{
>> +struct intel_engine_execlists *execlists = &engine->execlists;
>> +
>> +/* As we are returning early, update the hint from the queue */
>> +execlists->switch_priority_hint =
>> +max(execlists->queue_priority_hint,
>> +execlists->switch_priority_hint);
Still not completely unclear how the all hints play together
but the comment holds true, we bail out early.
>> +
>> +if (!execlists->timer.expires && need_timeslice(engine, last))
>> +set_timer_ms(&execlists->timer, timeslice(engine));
>> +}
>> +
>> static void record_preemption(struct intel_engine_execlists *execlists)
>> {
>> (void)I915_SELFTEST_ONLY(execlists->preempt_hang.count++);
>> @@ -1965,11 +1979,7 @@ static void execlists_dequeue(struct intel_engine_cs
>> *engine)
>> * Even if ELSP[1] is occupied and not worthy
>> * of timeslices, our queue might be.
>> */
>> -if (!execlists->timer.expires &&
>> -need_timeslice(engine, last))
>> -set_timer_ms(&execlists->timer,
>> - timeslice(engine));
>> -
>> +start_timeslice(engine, last);
>> return;
>> }
>> }
>> @@ -2004,6 +2014,7 @@ static void execlists_dequeue(struct intel_engine_cs
>> *engine)
>>
>> if (last && !can_merge_rq(last, rq)) {
>> spin_unlock(&ve->base.active.lock);
>> +start_timeslice(engine, last);
>> return; /* leave this for another */
>
> for another interrupt?
For another veng. The comment might have already been augmented.
Reviewed-by: Mika Kuoppala
> -Mika
>
>> }
>>
>> --
>> 2.25.1
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/1] Revert "drm/i915/tgl: Add extra hdc flush workaround"
== Series Details ==
Series: series starting with [1/1] Revert "drm/i915/tgl: Add extra hdc flush
workaround"
URL : https://patchwork.freedesktop.org/series/74293/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8068 -> Patchwork_16829
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16829/index.html
Known issues
Here are the changes found in Patchwork_16829 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-tgl-y: [PASS][1] -> [FAIL][2] ([CI#94])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16829/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
* igt@gem_mmap_gtt@basic:
- fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([CI#94] / [i915#402])
+1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-tgl-y/igt@gem_mmap_...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16829/fi-tgl-y/igt@gem_mmap_...@basic.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [PASS][5] -> [DMESG-WARN][6] ([i915#44])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16829/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@i915_getparams_basic@basic-eu-total:
- fi-tgl-y: [DMESG-WARN][7] ([CI#94] / [i915#402]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-tgl-y/igt@i915_getparams_ba...@basic-eu-total.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16829/fi-tgl-y/igt@i915_getparams_ba...@basic-eu-total.html
* igt@i915_selftest@live@gem_contexts:
- fi-cfl-8700k: [INCOMPLETE][9] ([i915#424]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-cfl-8700k/igt@i915_selftest@live@gem_contexts.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16829/fi-cfl-8700k/igt@i915_selftest@live@gem_contexts.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
[i915#44]: https://gitlab.freedesktop.org/drm/intel/issues/44
[i915#998]: https://gitlab.freedesktop.org/drm/intel/issues/998
Participating hosts (52 -> 45)
--
Additional (1): fi-gdg-551
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-skl-lmem fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8068 -> Patchwork_16829
CI-20190529: 20190529
CI_DRM_8068: f8e69af5cca45947ebce78f677b75b0ecc4ba744 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5492: 2be153507cdd652843f6ab44cc2a52a7f30206d9 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16829: 5351dfbf1590d25e7d0a74142aad1c3513bfd01e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
5351dfbf1590 Revert "drm/i915/tgl: Add extra hdc flush workaround"
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16829/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/20] drm/i915: Unify the low level dbuf code
On Thu, Mar 05, 2020 at 08:28:30AM +, Lisovskiy, Stanislav wrote: > On Wed, 2020-03-04 at 20:30 +0200, Ville Syrjälä wrote: > > On Wed, Mar 04, 2020 at 05:23:05PM +, Lisovskiy, Stanislav wrote: > > > > > > > - /* If 2nd DBuf slice required, enable it here */ > > > >if (INTEL_GEN(dev_priv) >= 11 && slices_union != > > > > hw_enabled_slices) > > > > - icl_dbuf_slices_update(dev_priv, slices_union); > > > > + gen9_dbuf_slices_update(dev_priv, slices_union); > > > > } > > > > static void icl_dbuf_slice_post_update(struct intel_atomic_state > > > > *state) > > > > @@ -15307,9 +15306,8 @@ static void > > > > icl_dbuf_slice_post_update(struct intel_atomic_state *state) > > > >u8 hw_enabled_slices = dev_priv->enabled_dbuf_slices_mask; > > > >u8 required_slices = state->enabled_dbuf_slices_mask; > > > > - /* If 2nd DBuf slice is no more required disable it */ > > > > if (INTEL_GEN(dev_priv) >= 11 && required_slices != > > > > hw_enabled_slices) > > > > - icl_dbuf_slices_update(dev_priv, > > > > required_slices); > > > > + gen9_dbuf_slices_update(dev_priv, > > > > required_slices); > > > > > > > > > Doesn't make much sense. Just look - previously we were checking if > > > INTEL_GEN is >= than 11(which _is_ ICL) > > > > > > and now we still _do_ check if INTEL_GEN is >= 11, but... call now > > > function renamed to gen9 > > > > > > > > > I guess you either need to change INTEL_GEN check to be >=9 to at > > > least look somewhat consistent > > > > > > or leave it as is. Or at least rename icl_ prefix to gen11_ > > > otherwise that looks inconsistent, i.e > > > > > > you are now checking that gen is >= 11 and then OK - now let's call > > > gen 9! :) > > > > The standard practice is to name things based on the oldest platform > > that introduced the thing. > > And that is fine - but then you need to change the check above from > INTEL_GEN >= 11 to INTEL_GEN >= 9, right - if you gen9 is the oldest > platform. No, the function works just fine for all skl+ but no real requirement that it gets called on all of them. It's just part of the standard set of gen9_dbuf (which should really be skl_dbuf since this is about display stuff). Anyways, IIRC this check is going away in a later patch, so the discussion is a bit moot. > > - /* If 2nd DBuf slice required, enable it here */ > > > >if (INTEL_GEN(dev_priv) >= 11 && slices_union != > > > > hw_enabled_slices) > > > > - icl_dbuf_slices_update(dev_priv, slices_union); > > > > + gen9_dbuf_slices_update(dev_priv, slices_union); > > > > } > > I mean previously we were checking INTEL_GEN to be at least 11 and > called function prefixed with icl_ - which was consistent and logical. > > Now you changed this to gen9(oldest platform which introduced the > thing), however then the check above makes no sense - it should be > changed to INTEL_GEN >= 9 as well. Otherwise this > "gen9_dbuf_slices_update" function will not be actually ever called for > gen9. > > Or do you want function prefixed as gen9_ to be only called for gen 11, > why we then prefix it.. > > Stan > > > > > > > > > > > > Stan > > > > > > > > > From: Ville Syrjala > > > Sent: Tuesday, February 25, 2020 7:11:12 PM > > > To: intel-gfx@lists.freedesktop.org > > > Cc: Lisovskiy, Stanislav > > > Subject: [PATCH v2 07/20] drm/i915: Unify the low level dbuf code > > > > > > From: Ville Syrjälä > > > > > > The low level dbuf slice code is rather inconsitent with its > > > functiona naming and organization. Make it more consistent. > > > > > > Also share the enable/disable functions between all platforms > > > since the same code works just fine for all of them. > > > > > > Cc: Stanislav Lisovskiy > > > Signed-off-by: Ville Syrjälä > > > --- > > > drivers/gpu/drm/i915/display/intel_display.c | 6 +-- > > > .../drm/i915/display/intel_display_power.c| 44 --- > > > > > > .../drm/i915/display/intel_display_power.h| 6 +-- > > > 3 files changed, 24 insertions(+), 32 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > > > b/drivers/gpu/drm/i915/display/intel_display.c > > > index 3031e64ee518..6952c398cc43 100644 > > > --- a/drivers/gpu/drm/i915/display/intel_display.c > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c > > > @@ -15296,9 +15296,8 @@ static void > > > icl_dbuf_slice_pre_update(struct intel_atomic_state *state) > > > u8 required_slices = state->enabled_dbuf_slices_mask; > > > u8 slices_union = hw_enabled_slices | required_slices; > > > > > > - /* If 2nd DBuf slice required, enable it here */ > > > if (INTEL_GEN(dev_priv) >= 11 && slices_union != > > > hw_enabled_slices) > > > - icl_dbuf_slices_update(dev_priv, slices_union); > > > + gen9_dbuf_slices_update(dev_priv, slices_union); > >
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl: WaDisableGPGPUMidThreadPreemption
On 04/03/2020 19:11, Patchwork wrote: == Series Details == Series: drm/i915/tgl: WaDisableGPGPUMidThreadPreemption URL : https://patchwork.freedesktop.org/series/74274/ State : success == Summary == CI Bug Log - changes from CI_DRM_8066 -> Patchwork_16821 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16821/index.html Known issues Here are the changes found in Patchwork_16821 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [PASS][1] -> [FAIL][2] ([CI#94]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16821/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html * igt@i915_selftest@live@gem_contexts: - fi-cml-s: [PASS][3] -> [DMESG-FAIL][4] ([i915#877]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/fi-cml-s/igt@i915_selftest@live@gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16821/fi-cml-s/igt@i915_selftest@live@gem_contexts.html * igt@i915_selftest@live@hugepages: - fi-tgl-y: [PASS][5] -> [INCOMPLETE][6] ([CI#94]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/fi-tgl-y/igt@i915_selftest@l...@hugepages.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16821/fi-tgl-y/igt@i915_selftest@l...@hugepages.html * igt@prime_vgem@basic-fence-flip: - fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([CI#94] / [i915#402]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/fi-tgl-y/igt@prime_v...@basic-fence-flip.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16821/fi-tgl-y/igt@prime_v...@basic-fence-flip.html Possible fixes * igt@i915_selftest@live@workarounds: - fi-icl-guc: [DMESG-FAIL][9] ([i915#922]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/fi-icl-guc/igt@i915_selftest@l...@workarounds.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16821/fi-icl-guc/igt@i915_selftest@l...@workarounds.html * igt@prime_self_import@basic-llseek-bad: - fi-tgl-y: [DMESG-WARN][11] ([CI#94] / [i915#402]) -> [PASS][12] +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/fi-tgl-y/igt@prime_self_imp...@basic-llseek-bad.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16821/fi-tgl-y/igt@prime_self_imp...@basic-llseek-bad.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877 [i915#922]: https://gitlab.freedesktop.org/drm/intel/issues/922 Participating hosts (45 -> 42) -- Additional (7): fi-kbl-7560u fi-bwr-2160 fi-kbl-7500u fi-cfl-8109u fi-skl-lmem fi-blb-e6850 fi-kbl-r Missing(10): fi-kbl-soraka fi-icl-1065g7 fi-bdw-gvtdvm fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-bsw-kefka fi-bdw-samus fi-byt-clapper fi-skl-6600u Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8066 -> Patchwork_16821 CI-20190529: 20190529 CI_DRM_8066: 9e1454777a07902c85ce3febcc9648837a2224fd @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5491: d52794b426ae16630cc1e0354ae435ec98f6174b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16821: 770b14fbde2879037069c8ea3aa5d48a1d283fd4 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 770b14fbde28 drm/i915/tgl: WaDisableGPGPUMidThreadPreemption And pushed, thanks for the reviews! Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/hotplug: Use phy to get the hpd_pin instead of the port (rev6)
== Series Details == Series: drm/i915/hotplug: Use phy to get the hpd_pin instead of the port (rev6) URL : https://patchwork.freedesktop.org/series/72747/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_dpll_mgr.h:285: warning: Function parameter or member 'get_freq' not described in 'intel_shared_dpll_funcs' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 06/20] drm/i915: Polish some dbuf debugs
On Thu, Mar 05, 2020 at 09:53:34AM +, Lisovskiy, Stanislav wrote:
> On Wed, 2020-03-04 at 20:26 +0200, Ville Syrjälä wrote:
> > On Wed, Mar 04, 2020 at 04:29:47PM +, Lisovskiy, Stanislav wrote:
> > > On Tue, 2020-02-25 at 19:11 +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > Polish some of the dbuf code to give more meaningful debug
> > > > messages and whatnot. Also we can switch over to the per-device
> > > > debugs/warns at the same time.
> > > >
> > > > Cc: Stanislav Lisovskiy
> > > > Signed-off-by: Ville Syrjälä
> > > > ---
> > > > .../drm/i915/display/intel_display_power.c| 40 +--
> > > >
> > > >
> > > > 1 file changed, 19 insertions(+), 21 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > index 6e25a1317161..e81e561e8ac0 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > @@ -4433,11 +4433,12 @@ static void
> > > > intel_power_domains_sync_hw(struct drm_i915_private *dev_priv)
> > > > mutex_unlock(&power_domains->lock);
> > > > }
> > > >
> > > > -static inline
> > > > -bool intel_dbuf_slice_set(struct drm_i915_private *dev_priv,
> > > > - i915_reg_t reg, bool enable)
> > > > +static void intel_dbuf_slice_set(struct drm_i915_private
> > > > *dev_priv,
> > > > +enum dbuf_slice slice, bool enable)
> > > > {
> > > > - u32 val, status;
> > > > + i915_reg_t reg = DBUF_CTL_S(slice);
> > > > + bool state;
> > > > + u32 val;
> > > >
> > > > val = intel_de_read(dev_priv, reg);
> > > > val = enable ? (val | DBUF_POWER_REQUEST) : (val &
> > > > ~DBUF_POWER_REQUEST);
> > > > @@ -4445,13 +4446,10 @@ bool intel_dbuf_slice_set(struct
> > > > drm_i915_private *dev_priv,
> > > > intel_de_posting_read(dev_priv, reg);
> > > > udelay(10);
> > > >
> > > > - status = intel_de_read(dev_priv, reg) & DBUF_POWER_STATE;
> > > > - if ((enable && !status) || (!enable && status)) {
> > > > - drm_err(&dev_priv->drm, "DBus power %s timeout!\n",
> > > > - enable ? "enable" : "disable");
> > > > - return false;
> > > > - }
> > > > - return true;
> > > > + state = intel_de_read(dev_priv, reg) & DBUF_POWER_STATE;
> > > > + drm_WARN(&dev_priv->drm, enable != state,
> > > > +"DBuf slice %d power %s timeout!\n",
> > > > +slice, enable ? "enable" : "disable");
> > > > }
> > > >
> > > > static void gen9_dbuf_enable(struct drm_i915_private *dev_priv)
> > > > @@ -4467,14 +4465,16 @@ static void gen9_dbuf_disable(struct
> > > > drm_i915_private *dev_priv)
> > > > void icl_dbuf_slices_update(struct drm_i915_private *dev_priv,
> > > > u8 req_slices)
> > > > {
> > > > - int i;
> > > > - int max_slices = INTEL_INFO(dev_priv)-
> > > > > num_supported_dbuf_slices;
> > > >
> > > > + int num_slices = INTEL_INFO(dev_priv)-
> > > > > num_supported_dbuf_slices;
> > > >
> > > > struct i915_power_domains *power_domains = &dev_priv-
> > > > > power_domains;
> > > >
> > > > + enum dbuf_slice slice;
> > > >
> > > > - drm_WARN(&dev_priv->drm, hweight8(req_slices) > max_slices,
> > > > -"Invalid number of dbuf slices requested\n");
> > > > + drm_WARN(&dev_priv->drm, req_slices & ~(BIT(num_slices) - 1),
> > > > +"Invalid set of dbuf slices (0x%x) requested (num dbuf
> > > > slices %d)\n",
> > > > +req_slices, num_slices);
> > > >
> > > > - DRM_DEBUG_KMS("Updating dbuf slices to 0x%x\n", req_slices);
> > > > + drm_dbg_kms(&dev_priv->drm,
> > > > + "Updating dbuf slices to 0x%x\n", req_slices);
> > > >
> > > > /*
> > > > * Might be running this in parallel to
> > > > gen9_dc_off_power_well_enable
> > > > @@ -4485,11 +4485,9 @@ void icl_dbuf_slices_update(struct
> > > > drm_i915_private *dev_priv,
> > > > */
> > > > mutex_lock(&power_domains->lock);
> > > >
> > > > - for (i = 0; i < max_slices; i++) {
> > > > - intel_dbuf_slice_set(dev_priv,
> > > > -DBUF_CTL_S(i),
> > > > -(req_slices & BIT(i)) != 0);
> > > > - }
> > > > + for (slice = DBUF_S1; slice < num_slices; slice++)
> > > > + intel_dbuf_slice_set(dev_priv, slice,
> > > > +req_slices & BIT(slice));
> > >
> > > Would be cool to completely get rid of any magic numbers or
> > > definitions, 0 in a sense is more universal here than DBUF_S1.
> > >
> > > If we are counting slices as numbers it seems logical that we
> > > iterate [0..num_slices) range. If you w
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hotplug: Use phy to get the hpd_pin instead of the port (rev6)
== Series Details == Series: drm/i915/hotplug: Use phy to get the hpd_pin instead of the port (rev6) URL : https://patchwork.freedesktop.org/series/72747/ State : success == Summary == CI Bug Log - changes from CI_DRM_8068 -> Patchwork_16830 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16830/index.html Known issues Here are the changes found in Patchwork_16830 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [PASS][1] -> [FAIL][2] ([CI#94]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16830/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html * igt@i915_selftest@live@late_gt_pm: - fi-bsw-nick:[PASS][3] -> [INCOMPLETE][4] ([i915#1382]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16830/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html * igt@kms_chamelium@dp-edid-read: - fi-cml-u2: [PASS][5] -> [FAIL][6] ([i915#217] / [i915#976]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16830/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html * igt@prime_vgem@basic-gtt: - fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([CI#94] / [i915#402]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-tgl-y/igt@prime_v...@basic-gtt.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16830/fi-tgl-y/igt@prime_v...@basic-gtt.html Possible fixes * igt@i915_getparams_basic@basic-eu-total: - fi-tgl-y: [DMESG-WARN][9] ([CI#94] / [i915#402]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-tgl-y/igt@i915_getparams_ba...@basic-eu-total.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16830/fi-tgl-y/igt@i915_getparams_ba...@basic-eu-total.html * igt@i915_selftest@live@gem_contexts: - fi-cfl-8700k: [INCOMPLETE][11] ([i915#424]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8068/fi-cfl-8700k/igt@i915_selftest@live@gem_contexts.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16830/fi-cfl-8700k/igt@i915_selftest@live@gem_contexts.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [i915#1382]: https://gitlab.freedesktop.org/drm/intel/issues/1382 [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424 [i915#976]: https://gitlab.freedesktop.org/drm/intel/issues/976 Participating hosts (52 -> 45) -- Additional (1): fi-gdg-551 Missing(8): fi-ilk-m540 fi-hsw-4200u fi-bdw-gvtdvm fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8068 -> Patchwork_16830 CI-20190529: 20190529 CI_DRM_8068: f8e69af5cca45947ebce78f677b75b0ecc4ba744 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5492: 2be153507cdd652843f6ab44cc2a52a7f30206d9 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16830: 5bce3620610d00ef00a407fbf3f20eee734f84f7 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 5bce3620610d drm/i915/hotplug: Use phy to get the hpd_pin instead of the port (v5) == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16830/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Return early for await_start on same timeline
Requests within a timeline are ordered by that timeline, so awaiting for
the start of a request within the timeline is a no-op. This used to work
by falling out of the mutex_trylock() as the signaler and waiter had the
same timeline and not returning an error.
Fixes: 6a79d848403d ("drm/i915: Lock signaler timeline while navigating")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: # v5.5+
---
drivers/gpu/drm/i915/i915_request.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 46dae33c1a20..ca5361eb1f0b 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -837,8 +837,8 @@ i915_request_await_start(struct i915_request *rq, struct
i915_request *signal)
struct dma_fence *fence;
int err;
- GEM_BUG_ON(i915_request_timeline(rq) ==
- rcu_access_pointer(signal->timeline));
+ if (i915_request_timeline(rq) == rcu_access_pointer(signal->timeline))
+ return 0;
if (i915_request_started(signal))
return 0;
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: HDCP: fix Ri prime and R0 checks during auth
From: Oliver Barta
Including HDCP_STATUS_ENC bit in the checks is pointless.
It is simply not set at this point.
Signed-off-by: Oliver Barta
Fixes: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base implementation")
---
[v2] rebased on top of latest changes
drivers/gpu/drm/i915/display/intel_hdcp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index ee0f27ea2810..78dddbaa61d3 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -710,7 +710,7 @@ static int intel_hdcp_auth(struct intel_connector
*connector)
/* Wait for R0 ready */
if (wait_for(intel_de_read(dev_priv, HDCP_STATUS(dev_priv,
cpu_transcoder, port)) &
-(HDCP_STATUS_R0_READY | HDCP_STATUS_ENC), 1)) {
+HDCP_STATUS_R0_READY, 1)) {
drm_err(&dev_priv->drm, "Timed out waiting for R0 ready\n");
return -ETIMEDOUT;
}
@@ -743,7 +743,7 @@ static int intel_hdcp_auth(struct intel_connector
*connector)
/* Wait for Ri prime match */
if (!wait_for(intel_de_read(dev_priv, HDCP_STATUS(dev_priv,
cpu_transcoder, port)) &
- (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1))
+ HDCP_STATUS_RI_MATCH, 1))
break;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display: Decrease log level
On Thu, Mar 05, 2020 at 08:55:31AM +, Lisovskiy, Stanislav wrote:
> On Tue, 2020-03-03 at 03:08 +0530, Swati Sharma wrote:
> > Converting error to debug print if sink fails to configure scrambling
> > or
> > TMDS bit clock ratio. In this case, we are timing out while disabling
> > the scrambling and setting the SCDC ratio, as there is no response
> > to the I2C SCDC write from the sink device. Error isn't due to
> > something
> > wrong done from driver side.
> >
> > Signed-off-by: Swati Sharma
> > Suggested-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
>
> Reviewed-by: Stanislav Lisovskiy
Pushed to dinq. Thanks for the patch and review.
>
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 284219da7df8..457ca88cd277 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -3564,8 +3564,9 @@ static void intel_enable_ddi_hdmi(struct
> > intel_encoder *encoder,
> > if (!intel_hdmi_handle_sink_scrambling(encoder, connector,
> >crtc_state-
> > >hdmi_high_tmds_clock_ratio,
> >crtc_state-
> > >hdmi_scrambling))
> > - DRM_ERROR("[CONNECTOR:%d:%s] Failed to configure sink
> > scrambling/TMDS bit clock ratio\n",
> > - connector->base.id, connector->name);
> > + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Failed to configure
> > sink "
> > + "scrambling/TMDS bit clock ratio\n",
> > + connector->base.id, connector->name);
> >
> > /* Display WA #1143: skl,kbl,cfl */
> > if (IS_GEN9_BC(dev_priv)) {
> ___
> 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
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Don't check for wm changes until we've compute the wms fully
On Wed, Mar 04, 2020 at 11:25:42PM +, Souza, Jose wrote:
> On Wed, 2020-03-04 at 13:46 +0200, Ville Syrjälä wrote:
> > On Wed, Mar 04, 2020 at 12:21:01AM +, Souza, Jose wrote:
> > > On Fri, 2020-02-28 at 22:35 +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > Currently we're comparing the watermarks between the old and new
> > > > states
> > > > before we've fully computed the new watermarks. In particular
> > > > skl_build_pipe_wm() will not account for the amount of ddb space
> > > > we'll
> > > > have. That information is only available during skl_compute_ddb()
> > > > which will proceed to zero out any watermark level exceeding the
> > > > ddb allocation. If we're short on ddb space this will end up
> > > > adding the plane to the state due erronously determining that the
> > > > watermarks have changed. Fix the problem by deferring
> > > > skl_wm_add_affected_planes() until we have the final watermarks
> > > > computed.
> > > >
> > > > Noticed this when trying enable transition watermarks on glk.
> > > > We now computed the trans_wm as 28, but we only had 14 blocks
> > > > of ddb, and thus skl_compute_ddb() ended up disabling the cursor
> > > > trans_wm every time. Thus we ended up adding the cursor to every
> > > > commit that didn't actually affect the cursor at all.
> > > >
> > > > Signed-off-by: Ville Syrjälä
> > > > ---
> > > > drivers/gpu/drm/i915/intel_pm.c | 16
> > > > 1 file changed, 12 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > index 39299811b650..a3d76e69caae 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > @@ -5762,16 +5762,24 @@ skl_compute_wm(struct intel_atomic_state
> > > > *state)
> > > > ret = skl_build_pipe_wm(new_crtc_state);
> > > > if (ret)
> > > > return ret;
> > > > -
> > > > - ret = skl_wm_add_affected_planes(state, crtc);
> > > > - if (ret)
> > > > - return ret;
> > > > }
> > > >
> > > > ret = skl_compute_ddb(state);
> > > > if (ret)
> > > > return ret;
> > > >
> > > > + /*
> > > > +* skl_compute_ddb() will have adjusted the final watermarks
> > > > +* based on how much ddb is available. Now we can actually
> > > > +* check if the final watermarks changed.
> > > > +*/
> > > > + for_each_oldnew_intel_crtc_in_state(state, crtc,
> > > > old_crtc_state,
> > > > + new_crtc_state, i) {
> > > > + ret = skl_wm_add_affected_planes(state, crtc);
> > > > + if (ret)
> > > > + return ret;
> > > > + }
> > >
> > > skl_compute_ddb() is already calling skl_wm_add_affected_planes()
> > > after
> > > do the ddb allocation for each pipe, so we could remove this chunk,
> >
> > skl_compute_ddb() calls skl_*ddb*_add_affected_planes(), which is a
> > different thing..
>
> Thanks
No, thank you for the review. Series pushed to dinq.
>
> Reviewed-by: José Roberto de Souza
>
> >
> > > with that:
> > >
> > > Reviewed-by: José Roberto de Souza
> > >
> > > > +
> > > > skl_print_wm_changes(state);
> > > >
> > > > return 0;
--
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] drm/i915: HDCP: fix Ri prime check done during link check
On Tue, Mar 3, 2020 at 10:33 AM Ramalingam C wrote:
>
> On 2020-02-29 at 11:39:22 +0100, Oliver Barta wrote:
> > From: Oliver Barta
> >
> > The check was always succeeding even in case of a mismatch due to the
> > HDCP_STATUS_ENC bit being set. Make sure both bits are actually set.
> >
> > Signed-off-by: Oliver Barta
> Looks good to me. But we need to do same on intel_hdcp_auth(), where we
> check the R0 on authentication.
>
> -Ram
Thanks for review and your suggestion. I have created a separate patch as
the problem is a little bit different in intel_hdcp_auth(). See
https://patchwork.freedesktop.org/series/74271/
Oliver
> > Fixes: 2320175feb74 ("drm/i915: Implement HDCP for HDMI")
> > ---
> > Submitted before as part of patch series
> > https://patchwork.freedesktop.org/series/73961/
> > For some reason the versioning got messed up.
> > I marked the patch series as superseded and I'm
> > starting all over. Sorry for spamming you.
> >
> > drivers/gpu/drm/i915/display/intel_hdmi.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> > b/drivers/gpu/drm/i915/display/intel_hdmi.c
> > index 0ac9bdfbc094..ac4276157182 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> > @@ -1536,7 +1536,8 @@ bool intel_hdmi_hdcp_check_link(struct
> > intel_digital_port *intel_dig_port)
> > intel_de_write(i915, HDCP_RPRIME(i915, cpu_transcoder, port), ri.reg);
> >
> > /* Wait for Ri prime match */
> > - if (wait_for(intel_de_read(i915, HDCP_STATUS(i915, cpu_transcoder,
> > port)) &
> > + if (wait_for((intel_de_read(i915, HDCP_STATUS(i915, cpu_transcoder,
> > + port)) & (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC)) ==
> >(HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1)) {
> > DRM_ERROR("Ri' mismatch detected, link check failed (%x)\n",
> > intel_de_read(i915, HDCP_STATUS(i915,
> > cpu_transcoder, port)));
> > --
> > 2.20.1
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/execlists: Show the "switch priority hint" in dumps
Show the timeslicing priority hint in engine dumps to aide debugging.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 5da86a40434c..16a023ac4604 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -5317,11 +5317,15 @@ void intel_execlists_show_requests(struct
intel_engine_cs *engine,
show_request(m, last, "\t\tE ");
}
- last = NULL;
- count = 0;
+ if (execlists->switch_priority_hint != INT_MIN)
+ drm_printf(m, "\t\tSwitch priority hint: %d\n",
+ execlists->switch_priority_hint);
if (execlists->queue_priority_hint != INT_MIN)
drm_printf(m, "\t\tQueue priority hint: %d\n",
execlists->queue_priority_hint);
+
+ last = NULL;
+ count = 0;
for (rb = rb_first_cached(&execlists->queue); rb; rb = rb_next(rb)) {
struct i915_priolist *p = rb_entry(rb, typeof(*p), node);
int i;
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 07/20] drm/i915: Unify the low level dbuf code
On Thu, 2020-03-05 at 15:37 +0200, Ville Syrjälä wrote: > On Thu, Mar 05, 2020 at 08:28:30AM +, Lisovskiy, Stanislav wrote: > > On Wed, 2020-03-04 at 20:30 +0200, Ville Syrjälä wrote: > > > On Wed, Mar 04, 2020 at 05:23:05PM +, Lisovskiy, Stanislav > > > wrote: > > > > > > > > > - /* If 2nd DBuf slice required, enable it here */ > > > > >if (INTEL_GEN(dev_priv) >= 11 && slices_union != > > > > > hw_enabled_slices) > > > > > - icl_dbuf_slices_update(dev_priv, > > > > > slices_union); > > > > > + gen9_dbuf_slices_update(dev_priv, > > > > > slices_union); > > > > > } > > > > > static void icl_dbuf_slice_post_update(struct > > > > > intel_atomic_state > > > > > *state) > > > > > @@ -15307,9 +15306,8 @@ static void > > > > > icl_dbuf_slice_post_update(struct intel_atomic_state *state) > > > > >u8 hw_enabled_slices = dev_priv- > > > > > >enabled_dbuf_slices_mask; > > > > >u8 required_slices = state->enabled_dbuf_slices_mask; > > > > > - /* If 2nd DBuf slice is no more required disable it > > > > > */ > > > > > if (INTEL_GEN(dev_priv) >= 11 && required_slices != > > > > > hw_enabled_slices) > > > > > - icl_dbuf_slices_update(dev_priv, > > > > > required_slices); > > > > > + gen9_dbuf_slices_update(dev_priv, > > > > > required_slices); > > > > > > > > > > > > Doesn't make much sense. Just look - previously we were > > > > checking if > > > > INTEL_GEN is >= than 11(which _is_ ICL) > > > > > > > > and now we still _do_ check if INTEL_GEN is >= 11, but... call > > > > now > > > > function renamed to gen9 > > > > > > > > > > > > I guess you either need to change INTEL_GEN check to be >=9 to > > > > at > > > > least look somewhat consistent > > > > > > > > or leave it as is. Or at least rename icl_ prefix to gen11_ > > > > otherwise that looks inconsistent, i.e > > > > > > > > you are now checking that gen is >= 11 and then OK - now let's > > > > call > > > > gen 9! :) > > > > > > The standard practice is to name things based on the oldest > > > platform > > > that introduced the thing. > > > > And that is fine - but then you need to change the check above > > from > > INTEL_GEN >= 11 to INTEL_GEN >= 9, right - if you gen9 is the > > oldest > > platform. > > No, the function works just fine for all skl+ but no real requirement > that it gets called on all of them. It's just part of the standard > set > of gen9_dbuf (which should really be skl_dbuf since this is about > display stuff). > > Anyways, IIRC this check is going away in a later patch, so the > discussion is a bit moot. Ahh, I didn't simply get to that patch yet - no questions then :) Would just remove it here right away though, but whatever. Reviewed-by: Stanislav Lisovskiy > > > > > - /* If 2nd DBuf slice required, enable it here */ > > > > >if (INTEL_GEN(dev_priv) >= 11 && slices_union != > > > > > hw_enabled_slices) > > > > > - icl_dbuf_slices_update(dev_priv, > > > > > slices_union); > > > > > + gen9_dbuf_slices_update(dev_priv, > > > > > slices_union); > > > > > } > > > > I mean previously we were checking INTEL_GEN to be at least 11 and > > called function prefixed with icl_ - which was consistent and > > logical. > > > > Now you changed this to gen9(oldest platform which introduced the > > thing), however then the check above makes no sense - it should be > > changed to INTEL_GEN >= 9 as well. Otherwise this > > "gen9_dbuf_slices_update" function will not be actually ever called > > for > > gen9. > > > > Or do you want function prefixed as gen9_ to be only called for gen > > 11, > > why we then prefix it.. > > > > Stan > > > > > > > > > > > > > > > > > Stan > > > > > > > > > > > > From: Ville Syrjala > > > > Sent: Tuesday, February 25, 2020 7:11:12 PM > > > > To: intel-gfx@lists.freedesktop.org > > > > Cc: Lisovskiy, Stanislav > > > > Subject: [PATCH v2 07/20] drm/i915: Unify the low level dbuf > > > > code > > > > > > > > From: Ville Syrjälä > > > > > > > > The low level dbuf slice code is rather inconsitent with its > > > > functiona naming and organization. Make it more consistent. > > > > > > > > Also share the enable/disable functions between all platforms > > > > since the same code works just fine for all of them. > > > > > > > > Cc: Stanislav Lisovskiy > > > > Signed-off-by: Ville Syrjälä > > > > --- > > > > drivers/gpu/drm/i915/display/intel_display.c | 6 +-- > > > > .../drm/i915/display/intel_display_power.c| 44 --- > > > > > > > > > > > > .../drm/i915/display/intel_display_power.h| 6 +-- > > > > 3 files changed, 24 insertions(+), 32 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > > > > b/drivers/gpu/drm/i915/display/intel_display.c > > > > index 3031e64ee518..6952c398cc43 100644 > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c > > > > +++
[Intel-gfx] [PATCH] drm/i915/gem: Limit struct_mutex to eb_reserve
We only need to serialise the multiple pinning during the eb_reserve
phase. Ideally this would be using the vm->mutex as an outer lock, or
using a composite global mutex (ww_mutex), but at the moment we are
using struct_mutex for the group.
Fixes: 003d8b9143a6 ("drm/i915/gem: Only call eb_lookup_vma once during execbuf
ioctl")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 51 ---
drivers/gpu/drm/i915/i915_drv.h | 6 ---
2 files changed, 20 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 7bb27f382af7..faa5b5c99a9a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -610,7 +610,7 @@ static int eb_reserve(struct i915_execbuffer *eb)
struct list_head last;
struct eb_vma *ev;
unsigned int i, pass;
- int err;
+ int err = 0;
/*
* Attempt to pin all of the buffers into the GTT.
@@ -626,8 +626,10 @@ static int eb_reserve(struct i915_execbuffer *eb)
* room for the earlier objects *unless* we need to defragment.
*/
+ if (mutex_lock_interruptible(&eb->i915->drm.struct_mutex))
+ return -EINTR;
+
pass = 0;
- err = 0;
do {
list_for_each_entry(ev, &eb->unbound, bind_link) {
err = eb_reserve_vma(eb, ev, pin_flags);
@@ -635,7 +637,7 @@ static int eb_reserve(struct i915_execbuffer *eb)
break;
}
if (!(err == -ENOSPC || err == -EAGAIN))
- return err;
+ break;
/* Resort *all* the objects into priority order */
INIT_LIST_HEAD(&eb->unbound);
@@ -666,7 +668,9 @@ static int eb_reserve(struct i915_execbuffer *eb)
list_splice_tail(&last, &eb->unbound);
if (err == -EAGAIN) {
+ mutex_unlock(&eb->i915->drm.struct_mutex);
flush_workqueue(eb->i915->mm.userptr_wq);
+ mutex_lock(&eb->i915->drm.struct_mutex);
continue;
}
@@ -680,15 +684,20 @@ static int eb_reserve(struct i915_execbuffer *eb)
err = i915_gem_evict_vm(eb->context->vm);
mutex_unlock(&eb->context->vm->mutex);
if (err)
- return err;
+ goto unlock;
break;
default:
- return -ENOSPC;
+ err = -ENOSPC;
+ goto unlock;
}
pin_flags = PIN_USER;
} while (1);
+
+unlock:
+ mutex_unlock(&eb->i915->drm.struct_mutex);
+ return err;
}
static unsigned int eb_batch_index(const struct i915_execbuffer *eb)
@@ -1631,7 +1640,6 @@ static int eb_prefault_relocations(const struct
i915_execbuffer *eb)
static noinline int eb_relocate_slow(struct i915_execbuffer *eb)
{
- struct drm_device *dev = &eb->i915->drm;
bool have_copy = false;
struct eb_vma *ev;
int err = 0;
@@ -1642,8 +1650,6 @@ static noinline int eb_relocate_slow(struct
i915_execbuffer *eb)
goto out;
}
- mutex_unlock(&dev->struct_mutex);
-
/*
* We take 3 passes through the slowpatch.
*
@@ -1666,21 +1672,8 @@ static noinline int eb_relocate_slow(struct
i915_execbuffer *eb)
cond_resched();
err = 0;
}
- if (err) {
- mutex_lock(&dev->struct_mutex);
- goto out;
- }
-
- /* A frequent cause for EAGAIN are currently unavailable client pages */
- flush_workqueue(eb->i915->mm.userptr_wq);
-
- err = i915_mutex_lock_interruptible(dev);
- if (err) {
- mutex_lock(&dev->struct_mutex);
+ if (err)
goto out;
- }
-
- GEM_BUG_ON(!eb->batch);
list_for_each_entry(ev, &eb->relocs, reloc_link) {
if (!have_copy) {
@@ -1738,9 +1731,11 @@ static int eb_relocate(struct i915_execbuffer *eb)
if (err)
return err;
- err = eb_reserve(eb);
- if (err)
- return err;
+ if (!list_empty(&eb->unbound)) {
+ err = eb_reserve(eb);
+ if (err)
+ return err;
+ }
/* The objects are in their final locations, apply the relocations. */
if (eb->args->flags & __EXEC_HAS_RELOC) {
@@ -2690,10 +2685,6 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (unlikely(err))
goto err_context;
- err = i915_mutex_lock_interruptible(dev);
- if (err)
- goto err_engine;
-
err = eb_r
Re: [Intel-gfx] [PATCH] drm/i915: Return early for await_start on same timeline
On 05/03/2020 13:48, Chris Wilson wrote:
Requests within a timeline are ordered by that timeline, so awaiting for
the start of a request within the timeline is a no-op. This used to work
by falling out of the mutex_trylock() as the signaler and waiter had the
same timeline and not returning an error.
Fixes: 6a79d848403d ("drm/i915: Lock signaler timeline while navigating")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: # v5.5+
---
drivers/gpu/drm/i915/i915_request.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 46dae33c1a20..ca5361eb1f0b 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -837,8 +837,8 @@ i915_request_await_start(struct i915_request *rq, struct
i915_request *signal)
struct dma_fence *fence;
int err;
- GEM_BUG_ON(i915_request_timeline(rq) ==
- rcu_access_pointer(signal->timeline));
+ if (i915_request_timeline(rq) == rcu_access_pointer(signal->timeline))
+ return 0;
if (i915_request_started(signal))
return 0;
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 v2 06/20] drm/i915: Polish some dbuf debugs
On Thu, 2020-03-05 at 15:46 +0200, Ville Syrjälä wrote:
> On Thu, Mar 05, 2020 at 09:53:34AM +, Lisovskiy, Stanislav wrote:
> > On Wed, 2020-03-04 at 20:26 +0200, Ville Syrjälä wrote:
> > > On Wed, Mar 04, 2020 at 04:29:47PM +, Lisovskiy, Stanislav
> > > wrote:
> > > > On Tue, 2020-02-25 at 19:11 +0200, Ville Syrjala wrote:
> > > > > From: Ville Syrjälä
> > > > >
> > > > > Polish some of the dbuf code to give more meaningful debug
> > > > > messages and whatnot. Also we can switch over to the per-
> > > > > device
> > > > > debugs/warns at the same time.
> > > > >
> > > > > Cc: Stanislav Lisovskiy
> > > > > Signed-off-by: Ville Syrjälä
> > > > > ---
> > > > > .../drm/i915/display/intel_display_power.c| 40
> > > > > +--
> > > > >
> > > > >
> > > > > 1 file changed, 19 insertions(+), 21 deletions(-)
> > > > >
> > > > > diff --git
> > > > > a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > index 6e25a1317161..e81e561e8ac0 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > > @@ -4433,11 +4433,12 @@ static void
> > > > > intel_power_domains_sync_hw(struct drm_i915_private
> > > > > *dev_priv)
> > > > > mutex_unlock(&power_domains->lock);
> > > > > }
> > > > >
> > > > > -static inline
> > > > > -bool intel_dbuf_slice_set(struct drm_i915_private *dev_priv,
> > > > > - i915_reg_t reg, bool enable)
> > > > > +static void intel_dbuf_slice_set(struct drm_i915_private
> > > > > *dev_priv,
> > > > > + enum dbuf_slice slice, bool
> > > > > enable)
> > > > > {
> > > > > - u32 val, status;
> > > > > + i915_reg_t reg = DBUF_CTL_S(slice);
> > > > > + bool state;
> > > > > + u32 val;
> > > > >
> > > > > val = intel_de_read(dev_priv, reg);
> > > > > val = enable ? (val | DBUF_POWER_REQUEST) : (val &
> > > > > ~DBUF_POWER_REQUEST);
> > > > > @@ -4445,13 +4446,10 @@ bool intel_dbuf_slice_set(struct
> > > > > drm_i915_private *dev_priv,
> > > > > intel_de_posting_read(dev_priv, reg);
> > > > > udelay(10);
> > > > >
> > > > > - status = intel_de_read(dev_priv, reg) &
> > > > > DBUF_POWER_STATE;
> > > > > - if ((enable && !status) || (!enable && status)) {
> > > > > - drm_err(&dev_priv->drm, "DBus power %s
> > > > > timeout!\n",
> > > > > - enable ? "enable" : "disable");
> > > > > - return false;
> > > > > - }
> > > > > - return true;
> > > > > + state = intel_de_read(dev_priv, reg) &
> > > > > DBUF_POWER_STATE;
> > > > > + drm_WARN(&dev_priv->drm, enable != state,
> > > > > + "DBuf slice %d power %s timeout!\n",
> > > > > + slice, enable ? "enable" : "disable");
> > > > > }
> > > > >
> > > > > static void gen9_dbuf_enable(struct drm_i915_private
> > > > > *dev_priv)
> > > > > @@ -4467,14 +4465,16 @@ static void gen9_dbuf_disable(struct
> > > > > drm_i915_private *dev_priv)
> > > > > void icl_dbuf_slices_update(struct drm_i915_private
> > > > > *dev_priv,
> > > > > u8 req_slices)
> > > > > {
> > > > > - int i;
> > > > > - int max_slices = INTEL_INFO(dev_priv)-
> > > > > > num_supported_dbuf_slices;
> > > > >
> > > > > + int num_slices = INTEL_INFO(dev_priv)-
> > > > > > num_supported_dbuf_slices;
> > > > >
> > > > > struct i915_power_domains *power_domains = &dev_priv-
> > > > > > power_domains;
> > > > >
> > > > > + enum dbuf_slice slice;
> > > > >
> > > > > - drm_WARN(&dev_priv->drm, hweight8(req_slices) >
> > > > > max_slices,
> > > > > - "Invalid number of dbuf slices requested\n");
> > > > > + drm_WARN(&dev_priv->drm, req_slices & ~(BIT(num_slices)
> > > > > - 1),
> > > > > + "Invalid set of dbuf slices (0x%x) requested
> > > > > (num dbuf
> > > > > slices %d)\n",
> > > > > + req_slices, num_slices);
> > > > >
> > > > > - DRM_DEBUG_KMS("Updating dbuf slices to 0x%x\n",
> > > > > req_slices);
> > > > > + drm_dbg_kms(&dev_priv->drm,
> > > > > + "Updating dbuf slices to 0x%x\n",
> > > > > req_slices);
> > > > >
> > > > > /*
> > > > >* Might be running this in parallel to
> > > > > gen9_dc_off_power_well_enable
> > > > > @@ -4485,11 +4485,9 @@ void icl_dbuf_slices_update(struct
> > > > > drm_i915_private *dev_priv,
> > > > >*/
> > > > > mutex_lock(&power_domains->lock);
> > > > >
> > > > > - for (i = 0; i < max_slices; i++) {
> > > > > - intel_dbuf_slice_set(dev_priv,
> > > > > - DBUF_CTL_S(i),
> > > > > - (req_slices & BIT(i)) !=
> > > > > 0);
> > > > > - }
> > > > > + for (slice = DBUF_S1; slice < num_slices; slice++)
> > > > > + intel_dbuf_slice_set(dev_priv, sl
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Show the "switch priority hint" in dumps
Chris Wilson writes:
> Show the timeslicing priority hint in engine dumps to aide debugging.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 5da86a40434c..16a023ac4604 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -5317,11 +5317,15 @@ void intel_execlists_show_requests(struct
> intel_engine_cs *engine,
> show_request(m, last, "\t\tE ");
> }
>
> - last = NULL;
> - count = 0;
> + if (execlists->switch_priority_hint != INT_MIN)
> + drm_printf(m, "\t\tSwitch priority hint: %d\n",
> +execlists->switch_priority_hint);
> if (execlists->queue_priority_hint != INT_MIN)
> drm_printf(m, "\t\tQueue priority hint: %d\n",
> execlists->queue_priority_hint);
> +
> + last = NULL;
> + count = 0;
> for (rb = rb_first_cached(&execlists->queue); rb; rb = rb_next(rb)) {
> struct i915_priolist *p = rb_entry(rb, typeof(*p), node);
> int i;
> --
> 2.25.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix documentation for intel_dpll_get_freq()
== Series Details == Series: drm/i915: Fix documentation for intel_dpll_get_freq() URL : https://patchwork.freedesktop.org/series/74272/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8066_full -> Patchwork_16820_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16820_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16820_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_16820_full: ### IGT changes ### Possible regressions * igt@i915_pm_dc@dc5-dpms: - shard-iclb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb1/igt@i915_pm...@dc5-dpms.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16820/shard-iclb3/igt@i915_pm...@dc5-dpms.html Known issues Here are the changes found in Patchwork_16820_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-vcs1: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +7 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb2/igt@gem_b...@busy-vcs1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16820/shard-iclb7/igt@gem_b...@busy-vcs1.html * igt@gem_ctx_persistence@engines-mixed-process@vcs0: - shard-skl: [PASS][5] -> [FAIL][6] ([i915#679]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-skl10/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16820/shard-skl8/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html * igt@gem_ctx_persistence@engines-mixed-process@vecs0: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([i915#1197]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-skl10/igt@gem_ctx_persistence@engines-mixed-proc...@vecs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16820/shard-skl8/igt@gem_ctx_persistence@engines-mixed-proc...@vecs0.html * igt@gem_exec_schedule@implicit-read-write-bsd1: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276] / [i915#677]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb1/igt@gem_exec_sched...@implicit-read-write-bsd1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16820/shard-iclb3/igt@gem_exec_sched...@implicit-read-write-bsd1.html * igt@gem_exec_schedule@pi-distinct-iova-bsd: - shard-iclb: [PASS][11] -> [SKIP][12] ([i915#677]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb8/igt@gem_exec_sched...@pi-distinct-iova-bsd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16820/shard-iclb1/igt@gem_exec_sched...@pi-distinct-iova-bsd.html * igt@gem_exec_schedule@preempt-contexts-bsd2: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109276]) +11 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb1/igt@gem_exec_sched...@preempt-contexts-bsd2.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16820/shard-iclb3/igt@gem_exec_sched...@preempt-contexts-bsd2.html * igt@gem_exec_schedule@wide-bsd: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#112146]) +4 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb7/igt@gem_exec_sched...@wide-bsd.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16820/shard-iclb2/igt@gem_exec_sched...@wide-bsd.html * igt@kms_cursor_crc@pipe-b-cursor-alpha-transparent: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#54]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-skl10/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16820/shard-skl6/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-apl8/igt@kms_cursor_...@pipe-c-cursor-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16820/shard-apl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_flip_tiling@flip-to-x-tiled: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#167]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-skl6/igt@kms_flip_til...@flip-to-x-tiled.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16820/shard-skl5/igt@kms_fl
Re: [Intel-gfx] [PATCH] drm/i915/gem: Limit struct_mutex to eb_reserve
Chris Wilson writes:
> We only need to serialise the multiple pinning during the eb_reserve
> phase. Ideally this would be using the vm->mutex as an outer lock, or
> using a composite global mutex (ww_mutex), but at the moment we are
> using struct_mutex for the group.
>
> Fixes: 003d8b9143a6 ("drm/i915/gem: Only call eb_lookup_vma once during
> execbuf ioctl")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 51 ---
> drivers/gpu/drm/i915/i915_drv.h | 6 ---
> 2 files changed, 20 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 7bb27f382af7..faa5b5c99a9a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -610,7 +610,7 @@ static int eb_reserve(struct i915_execbuffer *eb)
> struct list_head last;
> struct eb_vma *ev;
> unsigned int i, pass;
> - int err;
> + int err = 0;
>
> /*
>* Attempt to pin all of the buffers into the GTT.
> @@ -626,8 +626,10 @@ static int eb_reserve(struct i915_execbuffer *eb)
>* room for the earlier objects *unless* we need to defragment.
>*/
>
> + if (mutex_lock_interruptible(&eb->i915->drm.struct_mutex))
> + return -EINTR;
> +
> pass = 0;
> - err = 0;
> do {
> list_for_each_entry(ev, &eb->unbound, bind_link) {
> err = eb_reserve_vma(eb, ev, pin_flags);
> @@ -635,7 +637,7 @@ static int eb_reserve(struct i915_execbuffer *eb)
> break;
> }
> if (!(err == -ENOSPC || err == -EAGAIN))
> - return err;
> + break;
>
> /* Resort *all* the objects into priority order */
> INIT_LIST_HEAD(&eb->unbound);
> @@ -666,7 +668,9 @@ static int eb_reserve(struct i915_execbuffer *eb)
> list_splice_tail(&last, &eb->unbound);
>
> if (err == -EAGAIN) {
> + mutex_unlock(&eb->i915->drm.struct_mutex);
> flush_workqueue(eb->i915->mm.userptr_wq);
> + mutex_lock(&eb->i915->drm.struct_mutex);
General curiousity of what mechanism prevents the possible jail of -EAGAIN
looping?
For the fix tho,
Reviewed-by: Mika Kuoppala
> continue;
> }
>
> @@ -680,15 +684,20 @@ static int eb_reserve(struct i915_execbuffer *eb)
> err = i915_gem_evict_vm(eb->context->vm);
> mutex_unlock(&eb->context->vm->mutex);
> if (err)
> - return err;
> + goto unlock;
> break;
>
> default:
> - return -ENOSPC;
> + err = -ENOSPC;
> + goto unlock;
> }
>
> pin_flags = PIN_USER;
> } while (1);
> +
> +unlock:
> + mutex_unlock(&eb->i915->drm.struct_mutex);
> + return err;
> }
>
> static unsigned int eb_batch_index(const struct i915_execbuffer *eb)
> @@ -1631,7 +1640,6 @@ static int eb_prefault_relocations(const struct
> i915_execbuffer *eb)
>
> static noinline int eb_relocate_slow(struct i915_execbuffer *eb)
> {
> - struct drm_device *dev = &eb->i915->drm;
> bool have_copy = false;
> struct eb_vma *ev;
> int err = 0;
> @@ -1642,8 +1650,6 @@ static noinline int eb_relocate_slow(struct
> i915_execbuffer *eb)
> goto out;
> }
>
> - mutex_unlock(&dev->struct_mutex);
> -
> /*
>* We take 3 passes through the slowpatch.
>*
> @@ -1666,21 +1672,8 @@ static noinline int eb_relocate_slow(struct
> i915_execbuffer *eb)
> cond_resched();
> err = 0;
> }
> - if (err) {
> - mutex_lock(&dev->struct_mutex);
> - goto out;
> - }
> -
> - /* A frequent cause for EAGAIN are currently unavailable client pages */
> - flush_workqueue(eb->i915->mm.userptr_wq);
> -
> - err = i915_mutex_lock_interruptible(dev);
> - if (err) {
> - mutex_lock(&dev->struct_mutex);
> + if (err)
> goto out;
> - }
> -
> - GEM_BUG_ON(!eb->batch);
>
> list_for_each_entry(ev, &eb->relocs, reloc_link) {
> if (!have_copy) {
> @@ -1738,9 +1731,11 @@ static int eb_relocate(struct i915_execbuffer *eb)
> if (err)
> return err;
>
> - err = eb_reserve(eb);
> - if (err)
> - return err;
> + if (!list_empty(&eb->unbound)) {
> + err = eb_reserve(eb);
> + if (err)
> + return err;
> + }
>
> /* The objects are in their final locations, apply the relocations. */
> if (eb->args->flags & __EXEC_HAS
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/edp: Ignore short pulse when panel powered off
== Series Details == Series: drm/i915/edp: Ignore short pulse when panel powered off URL : https://patchwork.freedesktop.org/series/74265/ State : success == Summary == CI Bug Log - changes from CI_DRM_8066_full -> Patchwork_16817_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16817_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-vcs1: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb2/igt@gem_b...@busy-vcs1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16817/shard-iclb6/igt@gem_b...@busy-vcs1.html * igt@gem_exec_async@concurrent-writes-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112146]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb3/igt@gem_exec_as...@concurrent-writes-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16817/shard-iclb1/igt@gem_exec_as...@concurrent-writes-bsd.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_8066/shard-iclb2/igt@gem_exec_balan...@smoke.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16817/shard-iclb3/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@implicit-read-write-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([i915#677]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb8/igt@gem_exec_sched...@implicit-read-write-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16817/shard-iclb4/igt@gem_exec_sched...@implicit-read-write-bsd.html * igt@gem_exec_schedule@implicit-write-read-bsd1: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276] / [i915#677]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb2/igt@gem_exec_sched...@implicit-write-read-bsd1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16817/shard-iclb6/igt@gem_exec_sched...@implicit-write-read-bsd1.html * igt@gem_exec_schedule@promotion-bsd1: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276]) +6 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb2/igt@gem_exec_sched...@promotion-bsd1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16817/shard-iclb3/igt@gem_exec_sched...@promotion-bsd1.html * igt@gem_workarounds@suspend-resume: - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-apl4/igt@gem_workarou...@suspend-resume.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16817/shard-apl4/igt@gem_workarou...@suspend-resume.html * igt@i915_pm_rpm@system-suspend-modeset: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([i915#151] / [i915#69]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-skl5/igt@i915_pm_...@system-suspend-modeset.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16817/shard-skl5/igt@i915_pm_...@system-suspend-modeset.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16817/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_crc@pipe-c-cursor-256x85-offscreen: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#54]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-skl6/igt@kms_cursor_...@pipe-c-cursor-256x85-offscreen.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16817/shard-skl5/igt@kms_cursor_...@pipe-c-cursor-256x85-offscreen.html * igt@kms_flip@dpms-off-confusion: - shard-kbl: [PASS][21] -> [INCOMPLETE][22] ([fdo#103665]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-kbl4/igt@kms_f...@dpms-off-confusion.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16817/shard-kbl1/igt@kms_f...@dpms-off-confusion.html - shard-apl: [PASS][23] -> [INCOMPLETE][24] ([fdo#103927]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-apl2/igt@kms_f...@dpms-off-confusion.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16817/shard-apl2/igt@kms_f...@dpms-off-confusion.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][25] -> [FAIL][26] ([i915#79]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-glk2/igt@kms_f...@flip-vs-expired-vblank-interr
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: WaDisableGPGPUMidThreadPreemption
== Series Details == Series: drm/i915/tgl: WaDisableGPGPUMidThreadPreemption URL : https://patchwork.freedesktop.org/series/74274/ State : success == Summary == CI Bug Log - changes from CI_DRM_8066_full -> Patchwork_16821_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16821_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-vcs1: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +10 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb2/igt@gem_b...@busy-vcs1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16821/shard-iclb5/igt@gem_b...@busy-vcs1.html * igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox: - shard-skl: [PASS][3] -> [FAIL][4] ([i915#679]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-skl7/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16821/shard-skl1/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.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_8066/shard-iclb2/igt@gem_exec_balan...@smoke.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16821/shard-iclb3/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@implicit-write-read-bsd1: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276] / [i915#677]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb2/igt@gem_exec_sched...@implicit-write-read-bsd1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16821/shard-iclb5/igt@gem_exec_sched...@implicit-write-read-bsd1.html * igt@gem_exec_schedule@pi-distinct-iova-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([i915#677]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb8/igt@gem_exec_sched...@pi-distinct-iova-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16821/shard-iclb4/igt@gem_exec_sched...@pi-distinct-iova-bsd.html * igt@gem_exec_schedule@promotion-bsd1: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276]) +17 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb2/igt@gem_exec_sched...@promotion-bsd1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16821/shard-iclb3/igt@gem_exec_sched...@promotion-bsd1.html * igt@gem_exec_schedule@wide-bsd: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#112146]) +7 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb7/igt@gem_exec_sched...@wide-bsd.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16821/shard-iclb1/igt@gem_exec_sched...@wide-bsd.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +6 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-apl3/igt@i915_susp...@sysfs-reader.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16821/shard-apl8/igt@i915_susp...@sysfs-reader.html * igt@kms_cursor_crc@pipe-c-cursor-256x85-offscreen: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#54]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-skl6/igt@kms_cursor_...@pipe-c-cursor-256x85-offscreen.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16821/shard-skl5/igt@kms_cursor_...@pipe-c-cursor-256x85-offscreen.html * igt@kms_flip@dpms-off-confusion: - shard-kbl: [PASS][19] -> [INCOMPLETE][20] ([fdo#103665]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-kbl4/igt@kms_f...@dpms-off-confusion.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16821/shard-kbl6/igt@kms_f...@dpms-off-confusion.html * igt@kms_flip@flip-vs-suspend: - shard-skl: [PASS][21] -> [INCOMPLETE][22] ([i915#221]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-skl10/igt@kms_f...@flip-vs-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16821/shard-skl10/igt@kms_f...@flip-vs-suspend.html * igt@kms_flip_tiling@flip-to-x-tiled: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#167]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-skl6/igt@kms_flip_til...@flip-to-x-tiled.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16821/shard-skl5/igt@kms_flip_til...@flip-to-x-tiled.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-skl: [PASS][25] -> [INCOMPLETE][26] ([i915#69]) +1 similar issue [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-sk
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Cancel banned contexts after GT reset
== Series Details == Series: drm/i915/gt: Cancel banned contexts after GT reset URL : https://patchwork.freedesktop.org/series/74276/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8066_full -> Patchwork_16822_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16822_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16822_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_16822_full: ### IGT changes ### Possible regressions * igt@i915_pm_dc@dc5-dpms: - shard-iclb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb1/igt@i915_pm...@dc5-dpms.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16822/shard-iclb3/igt@i915_pm...@dc5-dpms.html * igt@i915_selftest@live@gtt: - shard-skl: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-skl1/igt@i915_selftest@l...@gtt.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16822/shard-skl1/igt@i915_selftest@l...@gtt.html Known issues Here are the changes found in Patchwork_16822_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@bcs0-s3: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-apl6/igt@gem_ctx_isolat...@bcs0-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16822/shard-apl4/igt@gem_ctx_isolat...@bcs0-s3.html * igt@gem_exec_schedule@implicit-read-write-bsd1: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276] / [i915#677]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb1/igt@gem_exec_sched...@implicit-read-write-bsd1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16822/shard-iclb3/igt@gem_exec_sched...@implicit-read-write-bsd1.html * igt@gem_exec_schedule@pi-distinct-iova-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([i915#677]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb8/igt@gem_exec_sched...@pi-distinct-iova-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16822/shard-iclb2/igt@gem_exec_sched...@pi-distinct-iova-bsd.html * igt@gem_exec_schedule@preempt-contexts-bsd2: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276]) +14 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb1/igt@gem_exec_sched...@preempt-contexts-bsd2.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16822/shard-iclb3/igt@gem_exec_sched...@preempt-contexts-bsd2.html * igt@gem_exec_schedule@preemptive-hang-bsd: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#112146]) +7 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb6/igt@gem_exec_sched...@preemptive-hang-bsd.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16822/shard-iclb4/igt@gem_exec_sched...@preemptive-hang-bsd.html * igt@kms_addfb_basic@unused-modifier: - shard-skl: [PASS][15] -> [SKIP][16] ([fdo#109271]) +26 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-skl1/igt@kms_addfb_ba...@unused-modifier.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16822/shard-skl1/igt@kms_addfb_ba...@unused-modifier.html * igt@kms_cursor_crc@pipe-b-cursor-alpha-transparent: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#54]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-skl10/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16822/shard-skl2/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][19] -> [FAIL][20] ([i915#79]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-glk2/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16822/shard-glk1/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-skl: [PASS][21] -> [INCOMPLETE][22] ([i915#69]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-skl10/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16822/shard-skl6/
[Intel-gfx] [PATCH] drm/i915: Fix crtc nv12 etc. plane bitmasks for DPMS off
From: Ville Syrjälä
We only consider crtc_state->enable when initially calculating plane
visibility. Later on we try to override the plane's state to invisible
if the crtc is in DPMS off state (crtc_state->active==false).
Unfortunately the code doing that only updates the plane_state.visible
flag and the crtc_state.active_planes bimask, but forgets to update
some of the other plane bitmasks stored in the crtc_state. Namely
crtc_state.nv12_planes is left set up based on the original visibility
check which makes icl_check_nv12_planes() pick a slave plane for the
flagged plane in the bitmask. Later on we hit the watermark code
which sees a plane with a slave assigned and it then makes the
logical assumption that the master plane must itself be visible.
Since the master's plane_state.visible flag was already cleared
we get a WARN.
Fix the problem by clearing all the plane bitmasks for DPMS off.
This is more or less the wrong approach and instead we should
calculate all the plane related state purely based crtc_state->enable
(to guarantee that the subsequent DPMS on can't fail). However in
the past we definitely had some roadblocks to making that happen.
Not sure how many are left these days, but let's stick to the current
approach since it's a much simpler fix to the immediate problem
(the WARN).
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 21 +--
.../gpu/drm/i915/display/intel_atomic_plane.h | 2 ++
drivers/gpu/drm/i915/display/intel_display.c | 8 ++-
3 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 457b258683d3..25dfeb3197aa 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -264,6 +264,20 @@ void intel_plane_copy_uapi_to_hw_state(struct
intel_plane_state *plane_state,
plane_state->hw.color_range = from_plane_state->uapi.color_range;
}
+void intel_plane_set_invisible(struct intel_crtc_state *crtc_state,
+ struct intel_plane_state *plane_state)
+{
+ struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
+
+ crtc_state->active_planes &= ~BIT(plane->id);
+ crtc_state->nv12_planes &= ~BIT(plane->id);
+ crtc_state->c8_planes &= ~BIT(plane->id);
+ crtc_state->data_rate[plane->id] = 0;
+ crtc_state->min_cdclk[plane->id] = 0;
+
+ plane_state->uapi.visible = false;
+}
+
int intel_plane_atomic_check_with_state(const struct intel_crtc_state
*old_crtc_state,
struct intel_crtc_state *new_crtc_state,
const struct intel_plane_state
*old_plane_state,
@@ -273,12 +287,7 @@ int intel_plane_atomic_check_with_state(const struct
intel_crtc_state *old_crtc_
const struct drm_framebuffer *fb = new_plane_state->hw.fb;
int ret;
- new_crtc_state->active_planes &= ~BIT(plane->id);
- new_crtc_state->nv12_planes &= ~BIT(plane->id);
- new_crtc_state->c8_planes &= ~BIT(plane->id);
- new_crtc_state->data_rate[plane->id] = 0;
- new_crtc_state->min_cdclk[plane->id] = 0;
- new_plane_state->uapi.visible = false;
+ intel_plane_set_invisible(new_crtc_state, new_plane_state);
if (!new_plane_state->hw.crtc && !old_plane_state->hw.crtc)
return 0;
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
index a6bbf42bae1f..59dd1fbb02ea 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
@@ -52,5 +52,7 @@ int intel_plane_atomic_calc_changes(const struct
intel_crtc_state *old_crtc_stat
int intel_plane_calc_min_cdclk(struct intel_atomic_state *state,
struct intel_plane *plane,
bool *need_cdclk_calc);
+void intel_plane_set_invisible(struct intel_crtc_state *crtc_state,
+ struct intel_plane_state *plane_state);
#endif /* __INTEL_ATOMIC_PLANE_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 8f23c4d51c33..3ff9d9102cd2 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -12376,12 +12376,8 @@ int intel_plane_atomic_calc_changes(const struct
intel_crtc_state *old_crtc_stat
* per-plane wm computation to the .check_plane() hook, and
* only combine the results from all planes in the current place?
*/
- if (!is_crtc_enabled) {
- plane_state->uapi.visible = visible = false;
- crtc_state->active_planes &= ~BIT(plane->id);
- crtc_state->data_rate[plane->id] = 0;
- crtc_state->min_cdclk[plane->id] = 0;
- }
+
[Intel-gfx] [PATCH i-g-t] tests/gem_exec_gttfill: MMAP_OFFSET related refresh
The test already tried to use a working mapping by first trying legacy
WC, then GTT. Use gem_mmap__device_coherent() helper instead of
approaching its implementation locally.
Signed-off-by: Janusz Krzysztofik
---
tests/i915/gem_exec_gttfill.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/tests/i915/gem_exec_gttfill.c b/tests/i915/gem_exec_gttfill.c
index f810dafd1..27277df48 100644
--- a/tests/i915/gem_exec_gttfill.c
+++ b/tests/i915/gem_exec_gttfill.c
@@ -155,15 +155,10 @@ static void fillgtt(int fd, unsigned ring, int timeout)
igt_assert(batches);
for (unsigned i = 0; i < count; i++) {
batches[i].handle = gem_create(fd, BATCH_SIZE);
- batches[i].ptr =
- __gem_mmap__wc(fd, batches[i].handle,
- 0, BATCH_SIZE, PROT_WRITE);
- if (!batches[i].ptr) {
- batches[i].ptr =
- __gem_mmap__gtt(fd, batches[i].handle,
- BATCH_SIZE, PROT_WRITE);
- }
- igt_require(batches[i].ptr);
+ batches[i].ptr = gem_mmap__device_coherent(fd,
+ batches[i].handle, 0,
+ BATCH_SIZE,
+ PROT_WRITE);
}
/* Flush all memory before we start the timer */
--
2.21.1
___
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 Adding YUV444 packed format support for skl+ (rev4)
On Sat, 29 Feb 2020 09:11:20 + Patchwork wrote: > == Series Details == > > Series: Adding YUV444 packed format support for skl+ (rev4) > URL : https://patchwork.freedesktop.org/series/73020/ > State : failure I'm a bit confused by this. The build changes listed at the bottom indicate that this did use a modified IGT tree with the test patch (per the cover-letter test-with tag) but the errors below look exactly like what I'd expect if testing with a non-modified IGT tree. In fact the line number where the error occurs matches with an non-modified tree and not the modified tree. Did I do something wrong with the cover letter? Do I just re-run? Should I resubmit the series? Bob > > == Summary == > > CI Bug Log - changes from CI_DRM_8023_full -> Patchwork_16744_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_16744_full absolutely > need to be verified manually. > > If you think the reported changes have nothing to do with the > changes introduced in Patchwork_16744_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_16744_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_plane@pixel-format-pipe-a-planes: > - shard-iclb: [PASS][1] -> [FAIL][2] +13 similar issues >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-iclb1/igt@kms_pl...@pixel-format-pipe-a-planes.html > [2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16744/shard-iclb3/igt@kms_pl...@pixel-format-pipe-a-planes.html > > * igt@kms_plane@pixel-format-pipe-a-planes-source-clamping: > - shard-kbl: NOTRUN -> [FAIL][3] >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16744/shard-kbl6/igt@kms_pl...@pixel-format-pipe-a-planes-source-clamping.html > > * igt@kms_plane@pixel-format-pipe-b-planes: > - shard-skl: [PASS][4] -> [FAIL][5] +12 similar issues >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-skl3/igt@kms_pl...@pixel-format-pipe-b-planes.html > [5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16744/shard-skl1/igt@kms_pl...@pixel-format-pipe-b-planes.html > - shard-kbl: [PASS][6] -> [FAIL][7] +12 similar issues >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-kbl4/igt@kms_pl...@pixel-format-pipe-b-planes.html > [7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16744/shard-kbl6/igt@kms_pl...@pixel-format-pipe-b-planes.html > > * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: > - shard-tglb: [PASS][8] -> [FAIL][9] +19 similar issues >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-tglb8/igt@kms_pl...@pixel-format-pipe-b-planes-source-clamping.html > [9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16744/shard-tglb3/igt@kms_pl...@pixel-format-pipe-b-planes-source-clamping.html > > * igt@kms_plane_scaling@pipe-a-scaler-with-clipping-clamping: > - shard-glk: [PASS][10] -> [FAIL][11] +13 similar issues >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-glk9/igt@kms_plane_scal...@pipe-a-scaler-with-clipping-clamping.html > [11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16744/shard-glk5/igt@kms_plane_scal...@pipe-a-scaler-with-clipping-clamping.html > > * igt@kms_plane_scaling@pipe-b-scaler-with-pixel-format: > - shard-apl: [PASS][12] -> [FAIL][13] +13 similar issues >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-apl3/igt@kms_plane_scal...@pipe-b-scaler-with-pixel-format.html > [13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16744/shard-apl1/igt@kms_plane_scal...@pipe-b-scaler-with-pixel-format.html > > * igt@kms_plane_scaling@pipe-c-scaler-with-clipping-clamping: > - shard-iclb: NOTRUN -> [FAIL][14] >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16744/shard-iclb3/igt@kms_plane_scal...@pipe-c-scaler-with-clipping-clamping.html > > > Known issues > > > Here are the changes found in Patchwork_16744_full that come from > known issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_exec_schedule@pi-common-bsd: > - shard-iclb: [PASS][15] -> [SKIP][16] ([i915#677]) +2 > similar issues [15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8023/shard-iclb5/igt@gem_exec_sched...@pi-common-bsd.html > [16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16744/shard-iclb4/igt@gem_exec_sched...@pi-common-bsd.html > > * igt@gem_exec_schedule@preempt-other-chain-bsd: > - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#112146]) +6 > similar issues [17]: > https://intel-gfx-ci.01.org/tree/drm-tip
Re: [Intel-gfx] [PATCH 5/6] drm/i915/uc: Move uC debugfs to its own folder under GT
Hi Daniele,
> > On Thu, Feb 27, 2020 at 06:28:42PM -0800, Daniele Ceraolo Spurio wrote:
> > > uC is a component of the GT, so it makes sense for the uC debugfs files
> > > to be in the GT folder. A subfolder has been used to keep the same
> > > structure we have for the code.
> >
> > Can we please document the interface changes. I see there are
> > some differences between the original and the new interfaces.
> >
>
> What differences are you referring to? there aren't supposed to be any,
> aside from the path change.
Have I seen it wrong or there are new files in this patch?
In any case, maybe we need to have the new structure.
> > > +#define DEFINE_UC_DEBUGFS_ATTRIBUTE(__name)
> > > \
> > > + static int __name ## _open(struct inode *inode, struct file *file) \
> > > +{
> > > \
> > > + return single_open(file, __name ## _show, inode->i_private);\
> > > +}
> > > \
> > > +static const struct file_operations __name ## _fops = {
> > > \
> > > + .owner = THIS_MODULE, \
> > > + .open = __name ## _open,\
> > > + .read = seq_read, \
> > > + .llseek = seq_lseek,\
> > > + .release = single_release, \
> > > +}
> >
> > Why do we need DEFINE_UC_DEBUGFS_ATTRIBUTE()?
> >
> > DEFINE_GT_DEBUGFS_ATTRIBUTE() was meant to be common to all gt
> > debugfs. I there any reason we need a new one?
> >
>
> Just wanted to avoid including the other header just for this macro.
well that was supposed to be a library for all the gem/debugfs
files and avoid duplicated code, I don't see anything wrong with
including the file.
> > > +struct debugfs_uc_file {
> > > + const char *name;
> > > + const struct file_operations *fops;
> > > +};
> > > +
> > > +#define debugfs_uc_register_files(files__, root__, data__) \
> > > +do { \
> > > + int i__ = 0; \
> > > + for (i__ = 0; i__ < ARRAY_SIZE(files__); i__++) { \
> > > + debugfs_create_file(files__[i__].name, \
> > > + 0444, root__, data__, \
> > > + files__[i__].fops); \
> > > + } \
> > > +} while (0)
> >
> > You want to define your own debugfs_uc_register_files() instead
> > of using debugfs_gt_register_files() because you want "data__"
> > to be void, right?
> >
> > I think we can achieve that by adding a wrapper in debugfs_gt.c,
> > perhaps we can do something like:
> >
> > void __debugfs_gt_register_files(struct intel_gt *gt,
> > struct dentry *root,
> > const struct debugfs_gt_file *files,
> > void *data,
> > unsigned long count)
> > {
> >..
> > }
> >
> > and
> >
> > #define debugfs_gt_register_files(...) __debugfs_gt_register_files(...)
> > #define debugfs_uc_register_files(...) __debugfs_gt_register_files(...)
> >
> > so that we can keep everything in a library. What do you think.
> >
>
> LGTM. Mind if I rename to:
>
> intel_gt_debugfs_register(...)
> intel_uc_debugfs_register(...)
>
> to avoid the debugfs_* prefix, as pointed out by Jani?
I have a patch for it, can you please hold a little, unless, of
course, yours is already ready.
Obvously, the naming you propose makes sense.
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/tgl: Make wa_1606700617 permanent
This workaround is to disable FF DOP Clock gating. The fix
in B0 was backed out due to timing reasons and decided to
be made permanent.
Bspec: 52890
Signed-off-by: Swathi Dhanavanthri
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index cb7d85c42f13..a9d1975b5245 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1337,11 +1337,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
struct drm_i915_private *i915 = engine->i915;
if (IS_TGL_REVID(i915, TGL_REVID_A0, TGL_REVID_A0)) {
- /* Wa_1606700617:tgl */
- wa_masked_en(wal,
-GEN9_CS_DEBUG_MODE1,
-FF_DOP_CLOCK_GATE_DISABLE);
-
/*
* Wa_1607138336:tgl
* Wa_1607063988:tgl
@@ -1393,6 +1388,11 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
/* Wa_1409804808:tgl */
wa_masked_en(wal, GEN7_ROW_CHICKEN2,
GEN12_PUSH_CONST_DEREF_HOLD_DIS);
+
+ /* Wa_1606700617:tgl */
+ wa_masked_en(wal,
+GEN9_CS_DEBUG_MODE1,
+FF_DOP_CLOCK_GATE_DISABLE);
}
if (IS_GEN(i915, 11)) {
--
2.20.1
___
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 [v6,1/3] intel_acpi: Rename drm_dev local variable to dev
== Series Details ==
Series: series starting with [v6,1/3] intel_acpi: Rename drm_dev local variable
to dev
URL : https://patchwork.freedesktop.org/series/74298/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c20368a27477 intel_acpi: Rename drm_dev local variable to dev
f4a4471b5c37 drm/i915: Lookup and attach ACPI device node for connectors
-:56: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#56: FILE: drivers/gpu/drm/i915/display/intel_acpi.c:265:
+ conn_dev = acpi_find_child_device(
total: 0 errors, 0 warnings, 1 checks, 70 lines checked
f9f7e4554cff drm/i915: Add support for integrated privacy screens
-:205: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#205:
new file mode 100644
total: 0 errors, 1 warnings, 0 checks, 248 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [v6,1/3] intel_acpi: Rename drm_dev local variable to dev
== Series Details == Series: series starting with [v6,1/3] intel_acpi: Rename drm_dev local variable to dev URL : https://patchwork.freedesktop.org/series/74298/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_dpll_mgr.h:285: warning: Function parameter or member 'get_freq' not described in 'intel_shared_dpll_funcs' ___ 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 [v6,1/3] intel_acpi: Rename drm_dev local variable to dev
== Series Details ==
Series: series starting with [v6,1/3] intel_acpi: Rename drm_dev local variable
to dev
URL : https://patchwork.freedesktop.org/series/74298/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8070 -> Patchwork_16831
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_16831:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_heartbeat:
- {fi-tgl-dsi}: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html
Known issues
Here are the changes found in Patchwork_16831 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-tgl-y: [PASS][3] -> [FAIL][4] ([CI#94])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_module_load@reload:
- fi-skl-6770hq: [PASS][5] -> [DMESG-WARN][6] ([i915#92]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/fi-skl-6770hq/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/fi-skl-6770hq/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-rte:
- fi-hsw-4770:[PASS][7] -> [SKIP][8] ([fdo#109271]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/fi-hsw-4770/igt@i915_pm_...@basic-rte.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/fi-hsw-4770/igt@i915_pm_...@basic-rte.html
* igt@i915_selftest@live@gem_contexts:
- fi-skl-lmem:[PASS][9] -> [INCOMPLETE][10] ([i915#424])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [PASS][11] -> [FAIL][12] ([i915#217])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-skl-6770hq: [PASS][13] -> [SKIP][14] ([fdo#109271]) +5 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-skl-6770hq: [PASS][15] -> [DMESG-WARN][16] ([i915#106])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
* igt@prime_self_import@basic-with_one_bo_two_files:
- fi-tgl-y: [PASS][17] -> [DMESG-WARN][18] ([CI#94] / [i915#402])
+1 similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
Possible fixes
* igt@kms_addfb_basic@addfb25-modifier-no-flag:
- fi-tgl-y: [DMESG-WARN][19] ([CI#94] / [i915#402]) -> [PASS][20]
+1 similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/fi-tgl-y/igt@kms_addfb_ba...@addfb25-modifier-no-flag.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/fi-tgl-y/igt@kms_addfb_ba...@addfb25-modifier-no-flag.html
Warnings
* igt@runner@aborted:
- fi-kbl-8809g: [FAIL][21] ([i915#1209]) -> [FAIL][22] ([i915#192] /
[i915#193] / [i915#194])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/fi-kbl-8809g/igt@run...@aborted.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16831/fi-kbl-8809g/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WAR
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v6,1/3] intel_acpi: Rename drm_dev local variable to dev
== Series Details ==
Series: series starting with [v6,1/3] intel_acpi: Rename drm_dev local variable
to dev
URL : https://patchwork.freedesktop.org/series/74299/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e83f0d80506c intel_acpi: Rename drm_dev local variable to dev
0dfdbf299bc6 drm/i915: Lookup and attach ACPI device node for connectors
-:56: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#56: FILE: drivers/gpu/drm/i915/display/intel_acpi.c:265:
+ conn_dev = acpi_find_child_device(
total: 0 errors, 0 warnings, 1 checks, 70 lines checked
54d76ab89c1c drm/i915: Add support for integrated privacy screens
-:205: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#205:
new file mode 100644
total: 0 errors, 1 warnings, 0 checks, 248 lines checked
___
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 [1/1] Revert "drm/i915/tgl: Add extra hdc flush workaround"
== Series Details == Series: series starting with [1/1] Revert "drm/i915/tgl: Add extra hdc flush workaround" URL : https://patchwork.freedesktop.org/series/74277/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8066_full -> Patchwork_16823_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16823_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16823_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_16823_full: ### IGT changes ### Possible regressions * igt@gem_ctx_persistence@legacy-engines-mixed-process@bsd1: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-skl7/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16823/shard-skl6/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd1.html Known issues Here are the changes found in Patchwork_16823_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-vcs1: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +11 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb2/igt@gem_b...@busy-vcs1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16823/shard-iclb8/igt@gem_b...@busy-vcs1.html * igt@gem_ctx_persistence@legacy-engines-mixed-process@bsd: - shard-skl: [PASS][5] -> [FAIL][6] ([i915#679]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-skl7/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16823/shard-skl6/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#110854]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb2/igt@gem_exec_balan...@smoke.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16823/shard-iclb6/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@implicit-read-write-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([i915#677]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb8/igt@gem_exec_sched...@implicit-read-write-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16823/shard-iclb4/igt@gem_exec_sched...@implicit-read-write-bsd.html * igt@gem_exec_schedule@implicit-write-read-bsd1: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276] / [i915#677]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb2/igt@gem_exec_sched...@implicit-write-read-bsd1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16823/shard-iclb8/igt@gem_exec_sched...@implicit-write-read-bsd1.html * igt@gem_exec_schedule@promotion-bsd1: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109276]) +16 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb2/igt@gem_exec_sched...@promotion-bsd1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16823/shard-iclb6/igt@gem_exec_sched...@promotion-bsd1.html * igt@gem_exec_schedule@wide-bsd: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#112146]) +6 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-iclb7/igt@gem_exec_sched...@wide-bsd.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16823/shard-iclb2/igt@gem_exec_sched...@wide-bsd.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-kbl: [PASS][17] -> [FAIL][18] ([i915#644]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-kbl3/igt@gem_pp...@flink-and-close-vma-leak.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16823/shard-kbl2/igt@gem_pp...@flink-and-close-vma-leak.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-apl3/igt@i915_susp...@fence-restore-tiled2untiled.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16823/shard-apl6/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_cursor_crc@pipe-c-cursor-256x85-offscreen: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#54]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8066/shard-skl6/igt@kms_cursor_...@pipe-c-cursor-256x85-offscreen.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patc
[Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [v6,1/3] intel_acpi: Rename drm_dev local variable to dev
== Series Details == Series: series starting with [v6,1/3] intel_acpi: Rename drm_dev local variable to dev URL : https://patchwork.freedesktop.org/series/74299/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_dpll_mgr.h:285: warning: Function parameter or member 'get_freq' not described in 'intel_shared_dpll_funcs' ___ 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 [v6,1/3] intel_acpi: Rename drm_dev local variable to dev
== Series Details == Series: series starting with [v6,1/3] intel_acpi: Rename drm_dev local variable to dev URL : https://patchwork.freedesktop.org/series/74299/ State : success == Summary == CI Bug Log - changes from CI_DRM_8070 -> Patchwork_16832 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16832/index.html Known issues Here are the changes found in Patchwork_16832 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [PASS][1] -> [FAIL][2] ([CI#94]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16832/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html * igt@kms_addfb_basic@addfb25-bad-modifier: - fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([CI#94] / [i915#402]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/fi-tgl-y/igt@kms_addfb_ba...@addfb25-bad-modifier.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16832/fi-tgl-y/igt@kms_addfb_ba...@addfb25-bad-modifier.html Possible fixes * igt@kms_addfb_basic@addfb25-modifier-no-flag: - fi-tgl-y: [DMESG-WARN][5] ([CI#94] / [i915#402]) -> [PASS][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8070/fi-tgl-y/igt@kms_addfb_ba...@addfb25-modifier-no-flag.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16832/fi-tgl-y/igt@kms_addfb_ba...@addfb25-modifier-no-flag.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (49 -> 40) -- Additional (1): fi-kbl-soraka Missing(10): fi-ilk-m540 fi-hsw-4200u fi-skl-6770hq fi-bsw-cyan fi-snb-2520m fi-ctg-p8600 fi-blb-e6850 fi-kbl-r fi-bdw-samus fi-snb-2600 Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8070 -> Patchwork_16832 CI-20190529: 20190529 CI_DRM_8070: d4e6f8b48e361f0cae9132f50f1778707b2546a2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5495: 22df72de8affcec22d9f354bb6148d77f60cc580 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16832: 54d76ab89c1c5512cdcb4a1dcc37dcd5d0e62f99 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 54d76ab89c1c drm/i915: Add support for integrated privacy screens 0dfdbf299bc6 drm/i915: Lookup and attach ACPI device node for connectors e83f0d80506c intel_acpi: Rename drm_dev local variable to dev == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16832/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/execlists: Enable timeslice on partial virtual engine dequeue
== Series Details == Series: drm/i915/execlists: Enable timeslice on partial virtual engine dequeue URL : https://patchwork.freedesktop.org/series/74304/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_dpll_mgr.h:285: warning: Function parameter or member 'get_freq' not described in 'intel_shared_dpll_funcs' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017 (rev2)
== Series Details == Series: drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017 (rev2) URL : https://patchwork.freedesktop.org/series/74100/ State : failure == Summary == Applying: drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017 (v2) Using index info to reconstruct a base tree... M drivers/gpu/drm/drm_dp_helper.c M drivers/gpu/drm/i915/display/intel_dp.c M include/drm/drm_dp_helper.h Falling back to patching base and 3-way merge... Auto-merging include/drm/drm_dp_helper.h CONFLICT (content): Merge conflict in include/drm/drm_dp_helper.h Auto-merging drivers/gpu/drm/i915/display/intel_dp.c Auto-merging drivers/gpu/drm/drm_dp_helper.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017 (v2) When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 02/16] drm/i915: Clear the repeater bit on HDCP disable
From: Sean Paul
On HDCP disable, clear the repeater bit. This ensures if we connect a
non-repeater sink after a repeater, the bit is in the state we expect.
Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
Cc: Chris Wilson
Cc: Ramalingam C
Cc: Daniel Vetter
Cc: Sean Paul
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
Cc: # v4.17+
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-3-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-3-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-3-s...@poorly.run
#v4
Changes in v2:
-Added to the set
Changes in v3:
-None
I had previously agreed that clearing the rep_ctl bits on enable would
also be a good idea. However when I committed that idea to code, it
didn't look right. So let's rely on enables and disables being paired
and everything outside of that will be considered a bug
Changes in v4:
-s/I915_(READ|WRITE)/intel_de_(read|write)/
Changes in v5:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index defa8654e7ac5..553f5ff617a15 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -797,6 +797,7 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
struct intel_hdcp *hdcp = &connector->hdcp;
enum port port = intel_dig_port->base.port;
enum transcoder cpu_transcoder = hdcp->cpu_transcoder;
+ u32 repeater_ctl;
int ret;
drm_dbg_kms(&dev_priv->drm, "[%s:%d] HDCP is being disabled...\n",
@@ -812,6 +813,11 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
return -ETIMEDOUT;
}
+ repeater_ctl = intel_hdcp_get_repeater_ctl(dev_priv, cpu_transcoder,
+ port);
+ intel_de_write(dev_priv, HDCP_REP_CTL,
+ intel_de_read(dev_priv, HDCP_REP_CTL) & ~repeater_ctl);
+
ret = hdcp->shim->toggle_signalling(intel_dig_port, false);
if (ret) {
drm_err(&dev_priv->drm, "Failed to disable HDCP signalling\n");
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 01/16] drm/i915: Fix sha_text population code
From: Sean Paul
This patch fixes a few bugs:
1- We weren't taking into account sha_leftovers when adding multiple
ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with
the beginning of ksv[j]
2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was
being placed on the wrong half of sha_text, overlapping the leftover
ksv value
3- In the sha_leftovers == 2 case, we need to manually terminate the
byte stream with 0x80 since the hardware doesn't have enough room to
add it after writing M0
The upside is that all of the HDCP supported HDMI repeaters I could
find on Amazon just strip HDCP anyways, so it turns out to be _really_
hard to hit any of these cases without an MST hub, which is not (yet)
supported. Oh, and the sha_leftovers == 1 case works perfectly!
Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
Cc: Chris Wilson
Cc: Ramalingam C
Cc: Daniel Vetter
Cc: Sean Paul
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
Cc: # v4.17+
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-2-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-2-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-2-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-2-s...@poorly.run
#v4
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-Rebased on intel_de_write changes
Changes in v5:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 26 +--
include/drm/drm_hdcp.h| 3 +++
2 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index ee0f27ea2810d..defa8654e7ac5 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -338,8 +338,10 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
/* Fill up the empty slots in sha_text and write it out */
sha_empty = sizeof(sha_text) - sha_leftovers;
- for (j = 0; j < sha_empty; j++)
- sha_text |= ksv[j] << ((sizeof(sha_text) - j - 1) * 8);
+ for (j = 0; j < sha_empty; j++) {
+ u8 off = ((sizeof(sha_text) - j - 1 - sha_leftovers) *
8);
+ sha_text |= ksv[j] << off;
+ }
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
@@ -437,7 +439,7 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
/* Write 32 bits of text */
intel_de_write(dev_priv, HDCP_REP_CTL,
rep_ctl | HDCP_SHA1_TEXT_32);
- sha_text |= bstatus[0] << 24 | bstatus[1] << 16;
+ sha_text |= bstatus[0] << 8 | bstatus[1];
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
return ret;
@@ -452,17 +454,29 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
return ret;
sha_idx += sizeof(sha_text);
}
+
+ /*
+* Terminate the SHA-1 stream by hand. For the other leftover
+* cases this is appended by the hardware.
+*/
+ intel_de_write(dev_priv, HDCP_REP_CTL,
+ rep_ctl | HDCP_SHA1_TEXT_32);
+ sha_text = DRM_HDCP_SHA1_TERMINATOR << 24;
+ ret = intel_write_sha_text(dev_priv, sha_text);
+ if (ret < 0)
+ return ret;
+ sha_idx += sizeof(sha_text);
} else if (sha_leftovers == 3) {
- /* Write 32 bits of text */
+ /* Write 32 bits of text (filled from LSB) */
intel_de_write(dev_priv, HDCP_REP_CTL,
rep_ctl | HDCP_SHA1_TEXT_32);
- sha_text |= bstatus[0] << 24;
+ sha_text |= bstatus[0];
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
return ret;
sha_idx += sizeof(sha_text);
- /* Write 8 bits of text, 24 bits of M0 */
+ /* Write 8 bits of text (filled from LSB), 24 bits of M0 */
intel_de_write(dev_priv, HDCP_REP_CTL,
rep_ctl | HDCP_SHA1_TEXT_8);
ret = intel_write_sha_text(dev_priv, bstatus[1]);
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index c6bab4986a658..fe58dbb46962a 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -29,6 +29,9 @@
/* Slave address for the HDCP registers in the recei
[Intel-gfx] [PATCH v5 04/16] drm/i915: Intercept Aksv writes in the aux hooks
From: Sean Paul
Instead of hand rolling the transfer ourselves in the hdcp hook, inspect
aux messages and add the aksv flag in the aux transfer hook.
IIRC, this was the original implementation and folks wanted this hack to
be isolated to the hdcp code, which makes sense.
However in testing an LG monitor on my desk, I noticed it was passing
back a DEFER reply. This wasn't handled in our hand-rolled code and HDCP
auth was failing as a result. Instead of copy/pasting all of the retry
logic and delays from drm dp helpers, let's just use the helpers and hide
the aksv select as best as we can.
Reviewed-by: Ville Syrjälä
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-3-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-5-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-5-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-5-s...@poorly.run
#v4
Changes in v2:
-Remove 'generate' in intel_dp_aux_generate_xfer_flags, make arg const (Ville)
-Bundle Aksv if statement together (Ville)
-Rename 'txbuf' to 'aksv' (Ville)
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
---
drivers/gpu/drm/i915/display/intel_dp.c | 62 -
1 file changed, 29 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0a417cd2af2bc..1f80a1244abbb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1534,12 +1534,27 @@ intel_dp_aux_header(u8 txbuf[HEADER_SIZE],
txbuf[3] = msg->size - 1;
}
+static u32 intel_dp_aux_xfer_flags(const struct drm_dp_aux_msg *msg)
+{
+ /*
+* If we're trying to send the HDCP Aksv, we need to set a the Aksv
+* select bit to inform the hardware to send the Aksv after our header
+* since we can't access that data from software.
+*/
+ if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_NATIVE_WRITE &&
+ msg->address == DP_AUX_HDCP_AKSV)
+ return DP_AUX_CH_CTL_AUX_AKSV_SELECT;
+
+ return 0;
+}
+
static ssize_t
intel_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
{
struct intel_dp *intel_dp = container_of(aux, struct intel_dp, aux);
u8 txbuf[20], rxbuf[20];
size_t txsize, rxsize;
+ u32 flags = intel_dp_aux_xfer_flags(msg);
int ret;
intel_dp_aux_header(txbuf, msg);
@@ -1560,7 +1575,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
memcpy(txbuf + HEADER_SIZE, msg->buffer, msg->size);
ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
- rxbuf, rxsize, 0);
+ rxbuf, rxsize, flags);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
@@ -1583,7 +1598,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
return -E2BIG;
ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
- rxbuf, rxsize, 0);
+ rxbuf, rxsize, flags);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
/*
@@ -5959,17 +5974,9 @@ static
int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
u8 *an)
{
- struct intel_dp *intel_dp =
enc_to_intel_dp(to_intel_encoder(&intel_dig_port->base.base));
- static const struct drm_dp_aux_msg msg = {
- .request = DP_AUX_NATIVE_WRITE,
- .address = DP_AUX_HDCP_AKSV,
- .size = DRM_HDCP_KSV_LEN,
- };
- u8 txbuf[HEADER_SIZE + DRM_HDCP_KSV_LEN] = {}, rxbuf[2], reply = 0;
+ u8 aksv[DRM_HDCP_KSV_LEN] = {};
ssize_t dpcd_ret;
- int ret;
- /* Output An first, that's easy */
dpcd_ret = drm_dp_dpcd_write(&intel_dig_port->dp.aux, DP_AUX_HDCP_AN,
an, DRM_HDCP_AN_LEN);
if (dpcd_ret != DRM_HDCP_AN_LEN) {
@@ -5979,29 +5986,18 @@ int intel_dp_hdcp_write_an_aksv(struct
intel_digital_port *intel_dig_port,
}
/*
-* Since Aksv is Oh-So-Secret, we can't access it in software. So in
-* order to get it on the wire, we need to create the AUX header as if
-* we were writing the data, and then tickle the hardware to output the
-* data once the header is sent out.
+* Since Aksv is Oh-So-Secret, we can't access it in software. So we
+* send an empty buffer of the correct length through the DP helpers. On
+* the other side, in the transfer hook, we'll generate a flag based on
+* the destinat
[Intel-gfx] [PATCH v5 15/16] drm/i915: Print HDCP version info for all connectors
From: Sean Paul
De-duplicate the HDCP version code for each connector and print it for
all connectors.
Cc: Juston Li
Cc: Ramalingam C
Reviewed-by: Juston Li
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200227185714.171466-1-s...@poorly.run
#v4
Changes in v4:
- Added to the set
Changes in v5:
-Print "No connector support" for hdcp sink capability as well (Ram)
---
.../drm/i915/display/intel_display_debugfs.c | 21 ---
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 1e6eb7f2f72db..25f03da30ed49 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -597,6 +597,11 @@ static void intel_hdcp_info(struct seq_file *m,
{
bool hdcp_cap, hdcp2_cap;
+ if (!intel_connector->hdcp.shim) {
+ seq_puts(m, "No Connector Support");
+ goto out;
+ }
+
hdcp_cap = intel_hdcp_capable(intel_connector);
hdcp2_cap = intel_hdcp2_capable(intel_connector);
@@ -608,6 +613,7 @@ static void intel_hdcp_info(struct seq_file *m,
if (!hdcp_cap && !hdcp2_cap)
seq_puts(m, "None");
+out:
seq_puts(m, "\n");
}
@@ -624,10 +630,6 @@ static void intel_dp_info(struct seq_file *m,
drm_dp_downstream_debug(m, intel_dp->dpcd, intel_dp->downstream_ports,
&intel_dp->aux);
- if (intel_connector->hdcp.shim) {
- seq_puts(m, "\tHDCP version: ");
- intel_hdcp_info(m, intel_connector);
- }
}
static void intel_dp_mst_info(struct seq_file *m,
@@ -651,10 +653,6 @@ static void intel_hdmi_info(struct seq_file *m,
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(intel_encoder);
seq_printf(m, "\taudio support: %s\n", yesno(intel_hdmi->has_audio));
- if (intel_connector->hdcp.shim) {
- seq_puts(m, "\tHDCP version: ");
- intel_hdcp_info(m, intel_connector);
- }
}
static void intel_lvds_info(struct seq_file *m,
@@ -710,6 +708,9 @@ static void intel_connector_info(struct seq_file *m,
break;
}
+ seq_puts(m, "\tHDCP version: ");
+ intel_hdcp_info(m, intel_connector);
+
seq_printf(m, "\tmodes:\n");
list_for_each_entry(mode, &connector->modes, head)
intel_seq_print_mode(m, 2, mode);
@@ -1975,10 +1976,6 @@ static int i915_hdcp_sink_capability_show(struct
seq_file *m, void *data)
if (connector->status != connector_status_connected)
return -ENODEV;
- /* HDCP is supported by connector */
- if (!intel_connector->hdcp.shim)
- return -EINVAL;
-
seq_printf(m, "%s:%d HDCP version: ", connector->name,
connector->base.id);
intel_hdcp_info(m, intel_connector);
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 07/16] drm/i915: Protect workers against disappearing connectors
From: Sean Paul
This patch adds some protection against connectors being destroyed
before the HDCP workers are finished.
For check_work, we do a synchronous cancel after the connector is
unregistered which will ensure that it is finished before destruction.
In the case of prop_work, we can't do a synchronous wait since it needs
to take connection_mutex which could cause deadlock. Instead, we'll take
a reference on the connector when scheduling prop_work and give it up
once we're done.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-8-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-8-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-8-s...@poorly.run
#v4
Changes in v2:
-Added to the set
Changes in v3:
-Change the WARN_ON condition in intel_hdcp_cleanup to allow for
initializing connectors as well
Changes in v4:
-None
Changes in v5:
-Change WARN_ON to drm_WARN_ON
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 44 ---
1 file changed, 39 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index dfa792ee90ecd..9523ab6c65e0d 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -891,8 +891,10 @@ static void intel_hdcp_update_value(struct intel_connector
*connector,
return;
hdcp->value = value;
- if (update_property)
+ if (update_property) {
+ drm_connector_get(&connector->base);
schedule_work(&hdcp->prop_work);
+ }
}
/* Implements Part 3 of the HDCP authorization procedure */
@@ -984,6 +986,8 @@ static void intel_hdcp_prop_work(struct work_struct *work)
mutex_unlock(&hdcp->mutex);
drm_modeset_unlock(&dev_priv->drm.mode_config.connection_mutex);
+
+ drm_connector_put(&connector->base);
}
bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port)
@@ -1862,6 +1866,9 @@ static void intel_hdcp_check_work(struct work_struct
*work)
check_work);
struct intel_connector *connector = intel_hdcp_to_connector(hdcp);
+ if (drm_connector_is_unregistered(&connector->base))
+ return;
+
if (!intel_hdcp2_check_link(connector))
schedule_delayed_work(&hdcp->check_work,
DRM_HDCP2_CHECK_PERIOD_MS);
@@ -2178,12 +2185,39 @@ void intel_hdcp_component_fini(struct drm_i915_private
*dev_priv)
void intel_hdcp_cleanup(struct intel_connector *connector)
{
- if (!connector->hdcp.shim)
+ struct intel_hdcp *hdcp = &connector->hdcp;
+
+ if (!hdcp->shim)
return;
- mutex_lock(&connector->hdcp.mutex);
- kfree(connector->hdcp.port_data.streams);
- mutex_unlock(&connector->hdcp.mutex);
+ /*
+* If the connector is registered, it's possible userspace could kick
+* off another HDCP enable, which would re-spawn the workers.
+*/
+ drm_WARN_ON(connector->base.dev,
+ connector->base.registration_state == DRM_CONNECTOR_REGISTERED);
+
+ /*
+* Now that the connector is not registered, check_work won't be run,
+* but cancel any outstanding instances of it
+*/
+ cancel_delayed_work_sync(&hdcp->check_work);
+
+ /*
+* We don't cancel prop_work in the same way as check_work since it
+* requires connection_mutex which could be held while calling this
+* function. Instead, we rely on the connector references grabbed before
+* scheduling prop_work to ensure the connector is alive when prop_work
+* is run. So if we're in the destroy path (which is where this
+* function should be called), we're "guaranteed" that prop_work is not
+* active (tl;dr This Should Never Happen).
+*/
+ drm_WARN_ON(connector->base.dev, work_pending(&hdcp->prop_work));
+
+ mutex_lock(&hdcp->mutex);
+ kfree(hdcp->port_data.streams);
+ hdcp->shim = NULL;
+ mutex_unlock(&hdcp->mutex);
}
void intel_hdcp_atomic_check(struct drm_connector *connector,
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 11/16] drm/i915: Factor out HDCP shim functions from dp for use by dp_mst
From: Sean Paul
These functions are all the same for dp and dp_mst, so move them into a
dedicated file for both sst and mst to use.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-11-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-12-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-12-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-12-s...@poorly.run
#v4
Changes in v2:
-None
Changes in v3:
-Created intel_dp_hdcp.c for the shared functions to live (Ville)
Changes in v4:
-Rebased on new drm logging change
Changes in v5:
-None
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 585 +-
drivers/gpu/drm/i915/display/intel_dp.h | 3 +
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 607 +++
4 files changed, 615 insertions(+), 581 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 991a8c537d123..cb4a7f137c0d9 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -225,6 +225,7 @@ i915-y += \
display/intel_ddi.o \
display/intel_dp.o \
display/intel_dp_aux_backlight.o \
+ display/intel_dp_hdcp.o \
display/intel_dp_link_training.o \
display/intel_dp_mst.o \
display/intel_dsi.o \
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4a38012a1fb03..306e4ccac5bb4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5958,580 +5958,6 @@ void intel_dp_encoder_suspend(struct intel_encoder
*intel_encoder)
edp_panel_vdd_off_sync(intel_dp);
}
-static void intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp, int timeout)
-{
- long ret;
-
-#define C (hdcp->cp_irq_count_cached != atomic_read(&hdcp->cp_irq_count))
- ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
- msecs_to_jiffies(timeout));
-
- if (!ret)
- DRM_DEBUG_KMS("Timedout at waiting for CP_IRQ\n");
-}
-
-static
-int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
- u8 *an)
-{
- u8 aksv[DRM_HDCP_KSV_LEN] = {};
- ssize_t dpcd_ret;
-
- dpcd_ret = drm_dp_dpcd_write(&intel_dig_port->dp.aux, DP_AUX_HDCP_AN,
-an, DRM_HDCP_AN_LEN);
- if (dpcd_ret != DRM_HDCP_AN_LEN) {
- DRM_DEBUG_KMS("Failed to write An over DP/AUX (%zd)\n",
- dpcd_ret);
- return dpcd_ret >= 0 ? -EIO : dpcd_ret;
- }
-
- /*
-* Since Aksv is Oh-So-Secret, we can't access it in software. So we
-* send an empty buffer of the correct length through the DP helpers. On
-* the other side, in the transfer hook, we'll generate a flag based on
-* the destination address which will tickle the hardware to output the
-* Aksv on our behalf after the header is sent.
-*/
- dpcd_ret = drm_dp_dpcd_write(&intel_dig_port->dp.aux, DP_AUX_HDCP_AKSV,
-aksv, DRM_HDCP_KSV_LEN);
- if (dpcd_ret != DRM_HDCP_KSV_LEN) {
- DRM_DEBUG_KMS("Failed to write Aksv over DP/AUX (%zd)\n",
- dpcd_ret);
- return dpcd_ret >= 0 ? -EIO : dpcd_ret;
- }
- return 0;
-}
-
-static int intel_dp_hdcp_read_bksv(struct intel_digital_port *intel_dig_port,
- u8 *bksv)
-{
- ssize_t ret;
- ret = drm_dp_dpcd_read(&intel_dig_port->dp.aux, DP_AUX_HDCP_BKSV, bksv,
- DRM_HDCP_KSV_LEN);
- if (ret != DRM_HDCP_KSV_LEN) {
- DRM_DEBUG_KMS("Read Bksv from DP/AUX failed (%zd)\n", ret);
- return ret >= 0 ? -EIO : ret;
- }
- return 0;
-}
-
-static int intel_dp_hdcp_read_bstatus(struct intel_digital_port
*intel_dig_port,
- u8 *bstatus)
-{
- ssize_t ret;
- /*
-* For some reason the HDMI and DP HDCP specs call this register
-* definition by different names. In the HDMI spec, it's called BSTATUS,
-* but in DP it's called BINFO.
-*/
- ret = drm_dp_dpcd_read(&intel_dig_port->dp.aux, DP_AUX_HDCP_BINFO,
- bstatus, DRM_HDCP_BSTATUS_LEN);
- if (ret != DRM_HDCP_BSTATUS_LEN) {
- DRM_DEBUG_KMS("Read bstatus from DP/AUX failed (%zd)\n", ret);
- return ret >= 0 ? -EIO : ret;
- }
- return 0;
-}
-
-static
-int intel_dp_hdcp_read_bcaps(struct intel_digital_port *intel_dig_port,
-
[Intel-gfx] [PATCH v5 00/16] drm/i915: Add support for HDCP 1.4 over MST connectors
From: Sean Paul Hello friends, Another version of HDCP over MST rebased on -tip (pls stop refactoring stuff!). I've also added a couple of fixes to fix bugs found when I did some testing I on a non-CrOS laptop. PTAL, Sean Sean Paul (16): drm/i915: Fix sha_text population code drm/i915: Clear the repeater bit on HDCP disable drm/i915: WARN if HDCP signalling is enabled upon disable drm/i915: Intercept Aksv writes in the aux hooks drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signalling drm/i915: Factor out hdcp->value assignments drm/i915: Protect workers against disappearing connectors drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it drm/i915: Support DP MST in enc_to_dig_port() function drm/i915: Use ddi_update_pipe in intel_dp_mst drm/i915: Factor out HDCP shim functions from dp for use by dp_mst drm/i915: Plumb port through hdcp init drm/i915: Add connector to hdcp_shim->check_link() drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message drm/i915: Print HDCP version info for all connectors drm/i915: Add HDCP 1.4 support for MST connectors drivers/gpu/drm/drm_dp_mst_topology.c | 117 +++ drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_ddi.c | 27 +- drivers/gpu/drm/i915/display/intel_ddi.h | 2 + .../drm/i915/display/intel_display_debugfs.c | 21 +- .../drm/i915/display/intel_display_types.h| 30 +- drivers/gpu/drm/i915/display/intel_dp.c | 624 +-- drivers/gpu/drm/i915/display/intel_dp.h | 7 + drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 712 ++ drivers/gpu/drm/i915/display/intel_dp_mst.c | 15 + drivers/gpu/drm/i915/display/intel_hdcp.c | 217 -- drivers/gpu/drm/i915/display/intel_hdcp.h | 2 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 25 +- include/drm/drm_dp_helper.h | 3 + include/drm/drm_dp_mst_helper.h | 44 ++ include/drm/drm_hdcp.h| 3 + 16 files changed, 1155 insertions(+), 695 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c -- Sean Paul, Software Engineer, Google / Chromium OS ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 03/16] drm/i915: WARN if HDCP signalling is enabled upon disable
From: Sean Paul
HDCP signalling should not be left on, WARN if it is
Cc: Ville Syrjälä
Cc: Daniel Vetter
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-4-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-4-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-4-s...@poorly.run
#v4
Changes in v2:
-Added to the set in lieu of just clearing the bit
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-Change WARN_ON to drm_WARN_ON
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 73d0f4648c06a..4aff5717e9428 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1593,6 +1593,8 @@ void intel_ddi_disable_transcoder_func(const struct
intel_crtc_state *crtc_state
val = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
val &= ~TRANS_DDI_FUNC_ENABLE;
+ drm_WARN_ON(crtc->base.dev, val & TRANS_DDI_HDCP_SIGNALLING);
+
if (INTEL_GEN(dev_priv) >= 12) {
if (!intel_dp_mst_is_master_trans(crtc_state)) {
val &= ~(TGL_TRANS_DDI_PORT_MASK |
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 06/16] drm/i915: Factor out hdcp->value assignments
From: Sean Paul
This is a bit of housecleaning for a future patch. Instead of sprinkling
hdcp->value assignments and prop_work scheduling everywhere, introduce a
function to do it for us.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-7-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-7-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-7-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-7-s...@poorly.run
#v4
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-Rebased on top of drm_* logging changes
Changes in v5:
-Change WARN_ON to drm_WARN_ON
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 67 ---
1 file changed, 46 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index d61bfea3fd28f..dfa792ee90ecd 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -880,6 +880,21 @@ struct intel_connector *intel_hdcp_to_connector(struct
intel_hdcp *hdcp)
return container_of(hdcp, struct intel_connector, hdcp);
}
+static void intel_hdcp_update_value(struct intel_connector *connector,
+ u64 value, bool update_property)
+{
+ struct intel_hdcp *hdcp = &connector->hdcp;
+
+ drm_WARN_ON(connector->base.dev, !mutex_is_locked(&hdcp->mutex));
+
+ if (hdcp->value == value)
+ return;
+
+ hdcp->value = value;
+ if (update_property)
+ schedule_work(&hdcp->prop_work);
+}
+
/* Implements Part 3 of the HDCP authorization procedure */
static int intel_hdcp_check_link(struct intel_connector *connector)
{
@@ -907,15 +922,16 @@ static int intel_hdcp_check_link(struct intel_connector
*connector)
connector->base.name, connector->base.base.id,
intel_de_read(dev_priv, HDCP_STATUS(dev_priv,
cpu_transcoder, port)));
ret = -ENXIO;
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
if (hdcp->shim->check_link(intel_dig_port)) {
if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_ENABLED, true);
}
goto out;
}
@@ -927,16 +943,18 @@ static int intel_hdcp_check_link(struct intel_connector
*connector)
ret = _intel_hdcp_disable(connector);
if (ret) {
drm_err(&dev_priv->drm, "Failed to disable hdcp (%d)\n", ret);
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
ret = _intel_hdcp_enable(connector);
if (ret) {
drm_err(&dev_priv->drm, "Failed to enable hdcp (%d)\n", ret);
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
@@ -1771,16 +1789,18 @@ static int intel_hdcp2_check_link(struct
intel_connector *connector)
"HDCP2.2 link stopped the encryption, %x\n",
intel_de_read(dev_priv, HDCP2_STATUS(dev_priv,
cpu_transcoder, port)));
ret = -ENXIO;
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
ret = hdcp->shim->check_2_2_link(intel_dig_port);
if (ret == HDCP_LINK_PROTECTED) {
if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+
[Intel-gfx] [PATCH v5 13/16] drm/i915: Add connector to hdcp_shim->check_link()
From: Sean Paul
Currently we derive the connector from digital port in check_link(). For
MST, this isn't sufficient since the digital port passed into the
function can have multiple connectors downstream. This patch adds
connector to the check_link() arguments so we have it when we need it.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-13-s...@poorly.run
# v4
Changes in v4:
-Added to the set
Changes in v5:
-None
---
drivers/gpu/drm/i915/display/intel_display_types.h | 3 ++-
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 5 ++---
4 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 3cac51955f250..9cc43dcbb518f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -312,7 +312,8 @@ struct intel_hdcp_shim {
bool enable);
/* Ensures the link is still protected */
- bool (*check_link)(struct intel_digital_port *intel_dig_port);
+ bool (*check_link)(struct intel_digital_port *intel_dig_port,
+ struct intel_connector *connector);
/* Detects panel's hdcp capability. This is optional for HDMI. */
int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index abcb53975e0d5..549f02f622b45 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -538,7 +538,8 @@ int intel_dp_hdcp_toggle_signalling(struct
intel_digital_port *intel_dig_port,
}
static
-bool intel_dp_hdcp_check_link(struct intel_digital_port *intel_dig_port)
+bool intel_dp_hdcp_check_link(struct intel_digital_port *intel_dig_port,
+ struct intel_connector *connector)
{
ssize_t ret;
u8 bstatus;
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index fc3ce7586084c..e0418ad202d1f 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -956,7 +956,7 @@ static int intel_hdcp_check_link(struct intel_connector
*connector)
goto out;
}
- if (hdcp->shim->check_link(intel_dig_port)) {
+ if (hdcp->shim->check_link(intel_dig_port, connector)) {
if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
intel_hdcp_update_value(connector,
DRM_MODE_CONTENT_PROTECTION_ENABLED, true);
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 8b32c3c986bca..288525a9fdf7c 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1522,11 +1522,10 @@ int intel_hdmi_hdcp_toggle_signalling(struct
intel_digital_port *intel_dig_port,
}
static
-bool intel_hdmi_hdcp_check_link(struct intel_digital_port *intel_dig_port)
+bool intel_hdmi_hdcp_check_link(struct intel_digital_port *intel_dig_port,
+ struct intel_connector *connector)
{
struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
- struct intel_connector *connector =
- intel_dig_port->hdmi.attached_connector;
enum port port = intel_dig_port->base.port;
enum transcoder cpu_transcoder = connector->hdcp.cpu_transcoder;
int ret;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 05/16] drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signalling
From: Sean Paul
Instead of using intel_dig_port's encoder pipe to determine which
transcoder to toggle signalling on, use the cpu_transcoder field already
stored in intel_hdmi.
This is particularly important for MST.
Suggested-by: Ville Syrjälä
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-6-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-6-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-6-s...@poorly.run
#v4
Changes in v2:
-Added to the set
Changes in v3:
-s/hdcp/hdmi/ in commit msg (Ram)
Changes in v4:
-Rebased on intel_de_(read|write) change
Changes in v5:
-Update hdcp->cpu_transcoder in intel_hdcp_enable so it works with pipe != 0
---
drivers/gpu/drm/i915/display/intel_ddi.c | 13 +++--
drivers/gpu/drm/i915/display/intel_ddi.h | 2 ++
.../gpu/drm/i915/display/intel_display_types.h | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 1 +
drivers/gpu/drm/i915/display/intel_hdcp.c| 16 +---
drivers/gpu/drm/i915/display/intel_hdmi.c| 16 +++-
6 files changed, 27 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 4aff5717e9428..d27f74c8f55d0 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1614,12 +1614,12 @@ void intel_ddi_disable_transcoder_func(const struct
intel_crtc_state *crtc_state
}
int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
+enum transcoder cpu_transcoder,
bool enable)
{
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
intel_wakeref_t wakeref;
- enum pipe pipe = 0;
int ret = 0;
u32 tmp;
@@ -1628,19 +1628,12 @@ int intel_ddi_toggle_hdcp_signalling(struct
intel_encoder *intel_encoder,
if (drm_WARN_ON(dev, !wakeref))
return -ENXIO;
- if (drm_WARN_ON(dev,
- !intel_encoder->get_hw_state(intel_encoder, &pipe))) {
- ret = -EIO;
- goto out;
- }
-
- tmp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(pipe));
+ tmp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (enable)
tmp |= TRANS_DDI_HDCP_SIGNALLING;
else
tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
- intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(pipe), tmp);
-out:
+ intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), tmp);
intel_display_power_put(dev_priv, intel_encoder->power_domain, wakeref);
return ret;
}
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.h
b/drivers/gpu/drm/i915/display/intel_ddi.h
index 55fd72b901fe4..cd1342a557e4f 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.h
+++ b/drivers/gpu/drm/i915/display/intel_ddi.h
@@ -16,6 +16,7 @@ struct intel_crtc_state;
struct intel_dp;
struct intel_dpll_hw_state;
struct intel_encoder;
+enum transcoder;
void intel_ddi_fdi_post_disable(struct intel_encoder *intel_encoder,
const struct intel_crtc_state *old_crtc_state,
@@ -43,6 +44,7 @@ u8 intel_ddi_dp_voltage_max(struct intel_encoder *encoder);
u8 intel_ddi_dp_pre_emphasis_max(struct intel_encoder *encoder,
u8 voltage_swing);
int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
+enum transcoder cpu_transcoder,
bool enable);
void icl_sanitize_encoder_pll_mapping(struct intel_encoder *encoder);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5e00e611f077f..bd577f143469c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -308,6 +308,7 @@ struct intel_hdcp_shim {
/* Enables HDCP signalling on the port */
int (*toggle_signalling)(struct intel_digital_port *intel_dig_port,
+enum transcoder cpu_transcoder,
bool enable);
/* Ensures the link is still protected */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 1f80a1244abbb..b2e92ecd1e0ff 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6138,6 +6138,7 @@ int intel_dp_hdcp_read_v_prime_part(struct
intel_digital_port *intel_dig_port,
static
int intel_dp_hdcp_toggle_signalling(struct intel_digital_port *intel_dig_port,
+ enum transcoder cpu_transcoder,
[Intel-gfx] [PATCH v5 08/16] drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it
From: Sean Paul
This patch is required for HDCP over MST. If a port is being used for
multiple HDCP streams, we don't want to fully disable HDCP on a port if
one of them is disabled. Instead, we just disable the HDCP signalling on
that particular pipe and exit early. The last pipe to disable HDCP will
also bring down HDCP on the port.
In order to achieve this, we need to keep a refcount in intel_digital_port
and protect it using a new hdcp_mutex.
Cc: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-8-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-9-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-9-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-9-s...@poorly.run
#v4
Changes in v2:
-Move the toggle_signalling call into _intel_hdcp_disable so it's called from
check_work
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-Change WARN_ON to drm_WARN_ON
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 ++
.../drm/i915/display/intel_display_types.h| 5 ++
drivers/gpu/drm/i915/display/intel_dp.c | 2 +
drivers/gpu/drm/i915/display/intel_hdcp.c | 53 +++
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +
5 files changed, 56 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index d27f74c8f55d0..48910a2ce 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4452,6 +4452,9 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
drm_encoder_init(&dev_priv->drm, &encoder->base, &intel_ddi_funcs,
DRM_MODE_ENCODER_TMDS, "DDI %c", port_name(port));
+ mutex_init(&intel_dig_port->hdcp_mutex);
+ intel_dig_port->num_hdcp_streams = 0;
+
encoder->hotplug = intel_ddi_hotplug;
encoder->compute_output_type = intel_ddi_compute_output_type;
encoder->compute_config = intel_ddi_compute_config;
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index bd577f143469c..04161993e2038 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1388,6 +1388,11 @@ struct intel_digital_port {
enum phy_fia tc_phy_fia;
u8 tc_phy_fia_idx;
+ /* protects num_hdcp_streams reference count */
+ struct mutex hdcp_mutex;
+ /* the number of pipes using HDCP signalling out of this port */
+ unsigned int num_hdcp_streams;
+
void (*write_infoframe)(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
unsigned int type,
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index b2e92ecd1e0ff..4a38012a1fb03 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -7800,6 +7800,8 @@ bool intel_dp_init(struct drm_i915_private *dev_priv,
intel_encoder = &intel_dig_port->base;
encoder = &intel_encoder->base;
+ mutex_init(&intel_dig_port->hdcp_mutex);
+
if (drm_encoder_init(&dev_priv->drm, &intel_encoder->base,
&intel_dp_enc_funcs, DRM_MODE_ENCODER_TMDS,
"DP %c", port_name(port)))
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 9523ab6c65e0d..0ee29f88bab2d 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -803,6 +803,19 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
drm_dbg_kms(&dev_priv->drm, "[%s:%d] HDCP is being disabled...\n",
connector->base.name, connector->base.base.id);
+ /*
+* If there are other connectors on this port using HDCP, don't disable
+* it. Instead, toggle the HDCP signalling off on that particular
+* connector/pipe and exit.
+*/
+ if (intel_dig_port->num_hdcp_streams > 0) {
+ ret = hdcp->shim->toggle_signalling(intel_dig_port,
+ cpu_transcoder, false);
+ if (ret)
+ DRM_ERROR("Failed to disable HDCP signalling\n");
+ return ret;
+ }
+
hdcp->hdcp_encrypted = false;
intel_de_write(dev_priv, HDCP_CONF(dev_priv, cpu_transcoder, port), 0);
if (intel_de_wait_for_clear(dev_priv,
@@ -883,6 +896,8 @@ struct intel_connector *intel_hdcp_to_connector(struct
intel_hdcp *hdcp)
static void intel_hdcp_update_value(struct intel_connector *connector,
u64 value
[Intel-gfx] [PATCH v5 09/16] drm/i915: Support DP MST in enc_to_dig_port() function
From: Sean Paul
Although DP_MST fake encoders are not subclassed from digital ports,
they are associated with them. Support these encoders.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-9-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-10-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-10-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-10-s...@poorly.run
#v4
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
---
.../drm/i915/display/intel_display_types.h| 21 ---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 04161993e2038..3cac51955f250 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1502,6 +1502,18 @@ static inline bool intel_encoder_is_dig_port(struct
intel_encoder *encoder)
}
}
+static inline bool intel_encoder_is_mst(struct intel_encoder *encoder)
+{
+ return encoder->type == INTEL_OUTPUT_DP_MST;
+}
+
+static inline struct intel_dp_mst_encoder *
+enc_to_mst(struct intel_encoder *encoder)
+{
+ return container_of(&encoder->base, struct intel_dp_mst_encoder,
+ base.base);
+}
+
static inline struct intel_digital_port *
enc_to_dig_port(struct intel_encoder *encoder)
{
@@ -1510,6 +1522,8 @@ enc_to_dig_port(struct intel_encoder *encoder)
if (intel_encoder_is_dig_port(intel_encoder))
return container_of(&encoder->base, struct intel_digital_port,
base.base);
+ else if (intel_encoder_is_mst(intel_encoder))
+ return enc_to_mst(encoder)->primary;
else
return NULL;
}
@@ -1520,13 +1534,6 @@ intel_attached_dig_port(struct intel_connector
*connector)
return enc_to_dig_port(intel_attached_encoder(connector));
}
-static inline struct intel_dp_mst_encoder *
-enc_to_mst(struct intel_encoder *encoder)
-{
- return container_of(&encoder->base, struct intel_dp_mst_encoder,
- base.base);
-}
-
static inline struct intel_dp *enc_to_intel_dp(struct intel_encoder *encoder)
{
return &enc_to_dig_port(encoder)->dp;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 10/16] drm/i915: Use ddi_update_pipe in intel_dp_mst
From: Sean Paul
In order to act upon content_protection property changes, we'll need to
implement the .update_pipe() hook. We can re-use intel_ddi_update_pipe
for this
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-10-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-11-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-11-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-11-s...@poorly.run
#v4
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
---
drivers/gpu/drm/i915/display/intel_ddi.c| 9 +
drivers/gpu/drm/i915/display/intel_dp.h | 4
drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 +
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 48910a2ce..149937da20586 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3695,12 +3695,13 @@ static void intel_ddi_update_pipe_dp(struct
intel_encoder *encoder,
intel_panel_update_backlight(encoder, crtc_state, conn_state);
}
-static void intel_ddi_update_pipe(struct intel_encoder *encoder,
- const struct intel_crtc_state *crtc_state,
- const struct drm_connector_state *conn_state)
+void intel_ddi_update_pipe(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state)
{
- if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
+ if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) &&
+ !intel_encoder_is_mst(encoder))
intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
intel_hdcp_update_pipe(encoder, crtc_state, conn_state);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index 0c7be8ed1423a..ae4a1517632bf 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -123,4 +123,8 @@ static inline unsigned int intel_dp_unused_lane_mask(int
lane_count)
u32 intel_dp_mode_to_fec_clock(u32 mode_clock);
+void intel_ddi_update_pipe(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state);
+
#endif /* __INTEL_DP_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 39f5de9a8c7ce..af658c76125c1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -787,6 +787,7 @@ intel_dp_create_fake_mst_encoder(struct intel_digital_port
*intel_dig_port, enum
intel_encoder->compute_config = intel_dp_mst_compute_config;
intel_encoder->disable = intel_mst_disable_dp;
intel_encoder->post_disable = intel_mst_post_disable_dp;
+ intel_encoder->update_pipe = intel_ddi_update_pipe;
intel_encoder->pre_pll_enable = intel_mst_pre_pll_enable_dp;
intel_encoder->pre_enable = intel_mst_pre_enable_dp;
intel_encoder->enable = intel_mst_enable_dp;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
