Re: [Intel-gfx] [PATCH 1/3] drm/atomic: Use explicit old crtc state in drm_atomic_add_affected_planes()
On Thu, Nov 01, 2018 at 08:46:44PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Replace 'crtc->state' with the explicit old crtc state.
>
> Actually it shouldn't matter whether we use the old or the new
> crtc state here since any plane that has been removed from the
> crtc since the crtc state was duplicated will have been added
> to the atomic state already. That is, you can't call
> drm_atomic_set_crtc_for_plane() without having the new
> plane state already in hand.
>
> Signed-off-by: Ville Syrjälä
I think this will break amdgpu_notify_freesync because that doesn't grab
the crtc state first. Which worked with the old stuff, because adding a
connector or plane will also add it's crtc. But with the new logic we'll
just oops I think.
Otoh, it's dead code, so what exactly are amd people doing again :-)
Adding Harry so he's aware, but patch here looks good.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 3dbfbddae7e6..064c48075917 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -927,6 +927,8 @@ int
> drm_atomic_add_affected_planes(struct drm_atomic_state *state,
> struct drm_crtc *crtc)
> {
> + const struct drm_crtc_state *old_crtc_state =
> + drm_atomic_get_old_crtc_state(state, crtc);
> struct drm_plane *plane;
>
> WARN_ON(!drm_atomic_get_new_crtc_state(state, crtc));
> @@ -934,7 +936,7 @@ drm_atomic_add_affected_planes(struct drm_atomic_state
> *state,
> DRM_DEBUG_ATOMIC("Adding all current planes for [CRTC:%d:%s] to %p\n",
>crtc->base.id, crtc->name, state);
>
> - drm_for_each_plane_mask(plane, state->dev, crtc->state->plane_mask) {
> + drm_for_each_plane_mask(plane, state->dev, old_crtc_state->plane_mask) {
> struct drm_plane_state *plane_state =
> drm_atomic_get_plane_state(state, plane);
>
> --
> 2.18.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/atomic: Use explicit old/new state in drm_atomic_crtc_check()
On Thu, Nov 01, 2018 at 08:46:45PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Convert drm_atomic_crtc_check() over to using explicit old vs. new
> crtc states. Avoids the confusion of "what does crtc->state mean
> again?".
Yeah much better.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic.c | 26 +++---
> 1 file changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 064c48075917..dde696181efe 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -315,9 +315,11 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
> }
> EXPORT_SYMBOL(drm_atomic_get_crtc_state);
>
> -static int drm_atomic_crtc_check(struct drm_crtc *crtc,
> - struct drm_crtc_state *state)
> +static int drm_atomic_crtc_check(const struct drm_crtc_state *old_crtc_state,
> + const struct drm_crtc_state *new_crtc_state)
> {
> + struct drm_crtc *crtc = new_crtc_state->crtc;
> +
> /* NOTE: we explicitly don't enforce constraints such as primary
>* layer covering entire screen, since that is something we want
>* to allow (on hw that supports it). For hw that does not, it
> @@ -326,7 +328,7 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
>* TODO: Add generic modeset state checks once we support those.
>*/
>
> - if (state->active && !state->enable) {
> + if (new_crtc_state->active && !new_crtc_state->enable) {
> DRM_DEBUG_ATOMIC("[CRTC:%d:%s] active without enabled\n",
>crtc->base.id, crtc->name);
> return -EINVAL;
> @@ -336,14 +338,14 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
>* as this is a kernel-internal detail that userspace should never
>* be able to trigger. */
> if (drm_core_check_feature(crtc->dev, DRIVER_ATOMIC) &&
> - WARN_ON(state->enable && !state->mode_blob)) {
> + WARN_ON(new_crtc_state->enable && !new_crtc_state->mode_blob)) {
> DRM_DEBUG_ATOMIC("[CRTC:%d:%s] enabled without mode blob\n",
>crtc->base.id, crtc->name);
> return -EINVAL;
> }
>
> if (drm_core_check_feature(crtc->dev, DRIVER_ATOMIC) &&
> - WARN_ON(!state->enable && state->mode_blob)) {
> + WARN_ON(!new_crtc_state->enable && new_crtc_state->mode_blob)) {
> DRM_DEBUG_ATOMIC("[CRTC:%d:%s] disabled with mode blob\n",
>crtc->base.id, crtc->name);
> return -EINVAL;
> @@ -359,7 +361,8 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
>* and legacy page_flip IOCTL which also reject service on a disabled
>* pipe.
>*/
> - if (state->event && !state->active && !crtc->state->active) {
> + if (new_crtc_state->event &&
> + !new_crtc_state->active && !old_crtc_state->active) {
> DRM_DEBUG_ATOMIC("[CRTC:%d:%s] requesting event but off\n",
>crtc->base.id, crtc->name);
> return -EINVAL;
> @@ -965,7 +968,8 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
> struct drm_plane *plane;
> struct drm_plane_state *plane_state;
> struct drm_crtc *crtc;
> - struct drm_crtc_state *crtc_state;
> + struct drm_crtc_state *old_crtc_state;
> + struct drm_crtc_state *new_crtc_state;
> struct drm_connector *conn;
> struct drm_connector_state *conn_state;
> int i, ret = 0;
> @@ -981,8 +985,8 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
> }
> }
>
> - for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> - ret = drm_atomic_crtc_check(crtc, crtc_state);
> + for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
> new_crtc_state, i) {
> + ret = drm_atomic_crtc_check(old_crtc_state, new_crtc_state);
> if (ret) {
> DRM_DEBUG_ATOMIC("[CRTC:%d:%s] atomic core check
> failed\n",
>crtc->base.id, crtc->name);
> @@ -1010,8 +1014,8 @@ int drm_atomic_check_only(struct drm_atomic_state
> *state)
> }
>
> if (!state->allow_modeset) {
> - for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> - if (drm_atomic_crtc_needs_modeset(crtc_state)) {
> + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (drm_atomic_crtc_needs_modeset(new_crtc_state)) {
> DRM_DEBUG_ATOMIC("[CRTC:%d:%s] requires full
> modeset\n",
>crtc->base.id, crtc->name);
> return -EINVAL;
> --
> 2.18.1
>
> ___
> dri-devel mailing l
Re: [Intel-gfx] [PATCH v10 00/15] drm/i915/icl: dsi enabling
> -Original Message- > From: Kulkarni, Vandita > Sent: Monday, November 5, 2018 11:17 AM > To: Nikula, Jani ; Chauhan, Madhav > ; intel-gfx@lists.freedesktop.org > Cc: Ville Syrjälä > Subject: RE: [Intel-gfx] [PATCH v10 00/15] drm/i915/icl: dsi enabling > > > > > -Original Message- > > From: Nikula, Jani > > Sent: Sunday, November 4, 2018 12:46 AM > > To: Chauhan, Madhav ; intel- > > g...@lists.freedesktop.org; Kulkarni, Vandita > > > > Cc: Ville Syrjälä > > Subject: Re: [Intel-gfx] [PATCH v10 00/15] drm/i915/icl: dsi enabling > > > > On Sat, 03 Nov 2018, Madhav Chauhan > wrote: > > > On 11/2/2018 7:15 PM, Jani Nikula wrote: > > >> On Fri, 02 Nov 2018, Jani Nikula wrote: > > >>> Next version of [1]. Sorry for the spam, needed to get the > > >>> authorship straight. Fixed power domains and compute config hook > > initialization. > > >> It looks like DDI intel_ddi_get_hw_state() returns true for ICL DSI > Yes, it does, checked on Jani's latest branch. > > >> as well. I'm not sure how this wasn't a problem before, but if I'm > > >> not mistaken it is now. > > >> > > >> At least that's my only explanation to intel_ddi_get_config() > > >> hitting WARN_ON(transcoder_is_dsi(cpu_transcoder)). > > > > > > I didn't observe that while testing. Where can we access the complete > log?? > Sent. There were some patches from Clock enabling and one hack wrt to VBT parsing. Vandita will be trying with those. Regards, Madhav > -Vandita > > > > Vandita reported that. > > > > BR, > > Jani. > > > > > > > > Regards, > > > Madhav > > > > > >> > > >> 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 3/3] drm/atomic: Use explicit old/new state in drm_atomic_plane_check()
On Thu, Nov 01, 2018 at 08:46:46PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Convert drm_atomic_plane_check() over to using explicit old vs. new
> plane states. Avoids the confusion of "what does plane->state mean
> again?".
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_atomic.c | 90 ++--
> 1 file changed, 46 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index dde696181efe..46f8d798efaf 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -492,108 +492,109 @@ drm_atomic_get_plane_state(struct drm_atomic_state
> *state,
> EXPORT_SYMBOL(drm_atomic_get_plane_state);
>
> static bool
> -plane_switching_crtc(struct drm_atomic_state *state,
> - struct drm_plane *plane,
> - struct drm_plane_state *plane_state)
> +plane_switching_crtc(const struct drm_plane_state *old_plane_state,
> + const struct drm_plane_state *new_plane_state)
> {
> - if (!plane->state->crtc || !plane_state->crtc)
> - return false;
> -
> - if (plane->state->crtc == plane_state->crtc)
> - return false;
> -
> /* This could be refined, but currently there's no helper or driver code
>* to implement direct switching of active planes nor userspace to take
>* advantage of more direct plane switching without the intermediate
>* full OFF state.
>*/
> - return true;
> + return old_plane_state->crtc && new_plane_state->crtc &&
> + old_plane_state->crtc != new_plane_state->crtc;
I think the old layout was clearer, instead of an obscure monster
condition.
With the old layout here this is:
Reviewed-by: Daniel Vetter
> }
>
> /**
> * drm_atomic_plane_check - check plane state
> - * @plane: plane to check
> - * @state: plane state to check
> + * @old_plane_state: old plane state to check
> + * @new_plane_state: new plane state to check
> *
> * Provides core sanity checks for plane state.
> *
> * RETURNS:
> * Zero on success, error code on failure
> */
> -static int drm_atomic_plane_check(struct drm_plane *plane,
> - struct drm_plane_state *state)
> +static int drm_atomic_plane_check(const struct drm_plane_state
> *old_plane_state,
> + const struct drm_plane_state *new_plane_state)
> {
> + struct drm_plane *plane = new_plane_state->plane;
> + struct drm_crtc *crtc = new_plane_state->crtc;
> + const struct drm_framebuffer *fb = new_plane_state->fb;
> unsigned int fb_width, fb_height;
> int ret;
>
> /* either *both* CRTC and FB must be set, or neither */
> - if (state->crtc && !state->fb) {
> + if (crtc && !fb) {
> DRM_DEBUG_ATOMIC("[PLANE:%d:%s] CRTC set but no FB\n",
>plane->base.id, plane->name);
> return -EINVAL;
> - } else if (state->fb && !state->crtc) {
> + } else if (fb && !crtc) {
> DRM_DEBUG_ATOMIC("[PLANE:%d:%s] FB set but no CRTC\n",
>plane->base.id, plane->name);
> return -EINVAL;
> }
>
> /* if disabled, we don't care about the rest of the state: */
> - if (!state->crtc)
> + if (!crtc)
> return 0;
>
> /* Check whether this plane is usable on this CRTC */
> - if (!(plane->possible_crtcs & drm_crtc_mask(state->crtc))) {
> + if (!(plane->possible_crtcs & drm_crtc_mask(crtc))) {
> DRM_DEBUG_ATOMIC("Invalid [CRTC:%d:%s] for [PLANE:%d:%s]\n",
> - state->crtc->base.id, state->crtc->name,
> + crtc->base.id, crtc->name,
>plane->base.id, plane->name);
> return -EINVAL;
> }
>
> /* Check whether this plane supports the fb pixel format. */
> - ret = drm_plane_check_pixel_format(plane, state->fb->format->format,
> -state->fb->modifier);
> + ret = drm_plane_check_pixel_format(plane, fb->format->format,
> +fb->modifier);
> if (ret) {
> struct drm_format_name_buf format_name;
> DRM_DEBUG_ATOMIC("[PLANE:%d:%s] invalid pixel format %s,
> modifier 0x%llx\n",
>plane->base.id, plane->name,
> - drm_get_format_name(state->fb->format->format,
> + drm_get_format_name(fb->format->format,
>&format_name),
> - state->fb->modifier);
> + fb->modifier);
> return ret;
> }
>
> /* Give drivers some help against integer overflows */
> - if (state->crtc_w > INT_MAX ||
> - state->crtc_x > INT_MAX - (int32_t) state->crtc
[Intel-gfx] [PATCH] drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5
Exercising the gpu reloc path strenuously revealed an issue where the
updated relocations (from MI_STORE_DWORD_IMM) were not being observed
upon execution. After some experiments with adding pipecontrols (a lot
of pipecontrols (32) as gen4/5 do not have a bit to wait on earlier pipe
controls or even the current on), it was discovered that we merely
needed to delay the EMIT_INVALIDATE by several flushes. It is important
to note that it is the EMIT_INVALIDATE as opposed to the EMIT_FLUSH that
needs the delay as opposed to what one might first expect -- that the
delay is required for the TLB invalidation to take effect (one presumes
to purge any CS buffers) as opposed to a delay after flushing to ensure
the writes have landed before triggering invalidation.
Testcase: igt/gem_tiled_fence_blits
Signed-off-by: Chris Wilson
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 38 +++--
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index b8a7a014d46d..87eebc13c0d8 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -91,6 +91,7 @@ static int
gen4_render_ring_flush(struct i915_request *rq, u32 mode)
{
u32 cmd, *cs;
+ int i;
/*
* read/write caches:
@@ -127,12 +128,45 @@ gen4_render_ring_flush(struct i915_request *rq, u32 mode)
cmd |= MI_INVALIDATE_ISP;
}
- cs = intel_ring_begin(rq, 2);
+ i = 2;
+ if (mode & EMIT_INVALIDATE)
+ i += 20;
+
+ cs = intel_ring_begin(rq, i);
if (IS_ERR(cs))
return PTR_ERR(cs);
*cs++ = cmd;
- *cs++ = MI_NOOP;
+
+ /*
+* A random delay to let the CS invalidate take effect? Without this
+* delay, the GPU relocation path fails as the CS does not see
+* the updated contents. Just as important, if we apply the flushes
+* to the EMIT_FLUSH branch (i.e. immediately after the relocation
+* write and before the invalidate on the next batch), the relocations
+* still fail. This implies that is a delay following invalidation
+* that is required to reset the caches as opposed to a delay to
+* ensure the memory is written.
+*/
+ if (mode & EMIT_INVALIDATE) {
+ *cs++ = GFX_OP_PIPE_CONTROL(4) | PIPE_CONTROL_QW_WRITE;
+ *cs++ = i915_ggtt_offset(rq->engine->scratch) |
+ PIPE_CONTROL_GLOBAL_GTT;
+ *cs++ = 0;
+ *cs++ = 0;
+
+ for (i = 0; i < 12; i++)
+ *cs++ = MI_FLUSH;
+
+ *cs++ = GFX_OP_PIPE_CONTROL(4) | PIPE_CONTROL_QW_WRITE;
+ *cs++ = i915_ggtt_offset(rq->engine->scratch) |
+ PIPE_CONTROL_GLOBAL_GTT;
+ *cs++ = 0;
+ *cs++ = 0;
+ }
+
+ *cs++ = cmd;
+
intel_ring_advance(rq, cs);
return 0;
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v2 1/2] drm: Add colorspace property
On 11/02/2018 03:29 PM, Jonas Karlman wrote:
On 2018-11-02 15:13, Shankar, Uma wrote:
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Friday, November 2, 2018 5:00 PM
To: Maarten Lankhorst
Cc: Shankar, Uma ; dri-de...@lists.freedesktop.org;
intel-gfx@lists.freedesktop.org; Syrjala, Ville ;
Lankhorst, Maarten ; Hans Verkuil
Subject: Re: [Intel-gfx] [v2 1/2] drm: Add colorspace property
On Fri, Nov 02, 2018 at 10:19:10AM +0100, Maarten Lankhorst wrote:
Op 31-10-18 om 13:05 schreef Uma Shankar:
This patch adds a colorspace property enabling userspace to switch
to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.
v2: Addressed Maarten and Ville's review comments. Enhanced the
colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
drivers/gpu/drm/drm_connector.c | 44
+++
include/drm/drm_connector.h | 7 +++
include/drm/drm_mode_config.h | 6 ++
include/uapi/drm/drm_mode.h | 24 +
5 files changed, 85 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index d5b7f31..9e1d46b 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -721,6 +721,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
state->picture_aspect_ratio = val;
} else if (property == config->content_type_property) {
state->content_type = val;
+ } else if (property == config->colorspace_property) {
+ state->colorspace = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
} else if (property == connector->content_protection_property) {
@@ -795,6 +797,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+ } else if (property == config->colorspace_property) {
+ *val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c
b/drivers/gpu/drm/drm_connector.c index aa18b1d..5ad52a0 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -826,6 +826,38 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info, };
DRM_ENUM_NAME_FN(drm_get_content_protection_name,
drm_cp_enum_list)
+static const struct drm_prop_enum_list colorspace[] = {
+ /* Standard Definition Colorimetry based on CEA 861 */
+ { COLORIMETRY_ITU_601, "601" },
+ { COLORIMETRY_ITU_709, "709" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { COLORIMETRY_XV_YCC_601, "601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { COLORIMETRY_XV_YCC_709, "709" },
2 definitions that share the same name?
All in all, I think the enum strings need to be more descriptive and self-
consistent.
+1
Sure, will modify this.
+ /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+ { COLORIMETRY_S_YCC_601, "s601" },
+ /* Colorimetry based on IEC 61966-2-5 [33] */
+ { COLORIMETRY_ADOBE_YCC_601, "adobe601" },
Hans (cc:d) recetly noted that these things aren't called Adobe
anymore in the CTA-861 spec. There is some new name for them, which I now
forget.
EC2 EC1 EC0 Extended Colorimetry
0 1 1 AdobeYCC601
This is the bit format mentioned in CEA861.F while defining the AVI infoframe,
so looks
like they are still keeping it that way. Not sure if its updated as part of any
latest spec
update.
New names is opRGB and opYCC601 according to the notice on the first page of
CTA-861-G [1]
Updated CTA-861-E/F/G can be found at
https://standards.cta.tech/kwspub/published_docs/
[1]
https://standards.cta.tech/kwspub/published_docs/CTA-861-G_FINAL_revised_2017.pdf
Correct. The names were updated since Adobe complained to the CTA about
trademark issues. And in all fairness, it makes sense to refer to the
official international standard name instead of a company standard, even
though they are effectively identical.
Basically, just avoid the name 'Adobe' :-)
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 00/15] drm/i915/icl: dsi enabling
> -Original Message- > From: Chauhan, Madhav > Sent: Monday, November 5, 2018 3:03 PM > To: Kulkarni, Vandita ; Nikula, Jani > ; intel-gfx@lists.freedesktop.org > Cc: Ville Syrjälä > Subject: RE: [Intel-gfx] [PATCH v10 00/15] drm/i915/icl: dsi enabling > > > -Original Message- > > From: Kulkarni, Vandita > > Sent: Monday, November 5, 2018 11:17 AM > > To: Nikula, Jani ; Chauhan, Madhav > > ; intel-gfx@lists.freedesktop.org > > Cc: Ville Syrjälä > > Subject: RE: [Intel-gfx] [PATCH v10 00/15] drm/i915/icl: dsi enabling > > > > > > > > > -Original Message- > > > From: Nikula, Jani > > > Sent: Sunday, November 4, 2018 12:46 AM > > > To: Chauhan, Madhav ; intel- > > > g...@lists.freedesktop.org; Kulkarni, Vandita > > > > > > Cc: Ville Syrjälä > > > Subject: Re: [Intel-gfx] [PATCH v10 00/15] drm/i915/icl: dsi > > > enabling > > > > > > On Sat, 03 Nov 2018, Madhav Chauhan > > wrote: > > > > On 11/2/2018 7:15 PM, Jani Nikula wrote: > > > >> On Fri, 02 Nov 2018, Jani Nikula wrote: > > > >>> Next version of [1]. Sorry for the spam, needed to get the > > > >>> authorship straight. Fixed power domains and compute config hook > > > initialization. > > > >> It looks like DDI intel_ddi_get_hw_state() returns true for ICL > > > >> DSI > > Yes, it does, checked on Jani's latest branch. > > > >> as well. I'm not sure how this wasn't a problem before, but if > > > >> I'm not mistaken it is now. > > > >> > > > >> At least that's my only explanation to intel_ddi_get_config() > > > >> hitting WARN_ON(transcoder_is_dsi(cpu_transcoder)). > > > > > > > > I didn't observe that while testing. Where can we access the > > > > complete > > log?? > > Sent. > > There were some patches from Clock enabling and one hack wrt to VBT parsing. > Vandita will be trying with those. Thanks Madhav, but looks like just that is not enough. Will keep you posted. Regards, Vandita > > Regards, > Madhav > > > -Vandita > > > > > > Vandita reported that. > > > > > > BR, > > > Jani. > > > > > > > > > > > Regards, > > > > Madhav > > > > > > > >> > > > >> 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] [PATCH] drm/lease: look at ->universal_planes only once
It's lockless, and userspace might chance it underneath us. That's not
really a problem, all userspace gets is a slightly dysfunctional
lease with the current code. But this might change, and gcc might
decide to reload a few too many times, and then boom. So better safe
than sorry.
v2: Remove the now unused lessor_priv argument from validate_lease()
(Keith).
v3: Actually add everything ... silly me.
Cc: Keith Packard
Cc: Dave Airlie
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_lease.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 3b0342a45ae9..3650d3c46718 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -353,9 +353,9 @@ void drm_lease_revoke(struct drm_master *top)
}
static int validate_lease(struct drm_device *dev,
- struct drm_file *lessor_priv,
int object_count,
- struct drm_mode_object **objects)
+ struct drm_mode_object **objects,
+ bool universal_planes)
{
int o;
int has_crtc = -1;
@@ -372,14 +372,14 @@ static int validate_lease(struct drm_device *dev,
if (objects[o]->type == DRM_MODE_OBJECT_CONNECTOR &&
has_connector == -1)
has_connector = o;
- if (lessor_priv->universal_planes) {
+ if (universal_planes) {
if (objects[o]->type == DRM_MODE_OBJECT_PLANE &&
has_plane == -1)
has_plane = o;
}
}
if (has_crtc == -1 || has_connector == -1)
return -EINVAL;
- if (lessor_priv->universal_planes && has_plane == -1)
+ if (universal_planes && has_plane == -1)
return -EINVAL;
return 0;
}
@@ -393,6 +393,8 @@ static int fill_object_idr(struct drm_device *dev,
struct drm_mode_object **objects;
u32 o;
int ret;
+ bool universal_planes = READ_ONCE(lessor_priv->universal_planes);
+
objects = kcalloc(object_count, sizeof(struct drm_mode_object *),
GFP_KERNEL);
if (!objects)
@@ -421,7 +423,7 @@ static int fill_object_idr(struct drm_device *dev,
}
}
- ret = validate_lease(dev, lessor_priv, object_count, objects);
+ ret = validate_lease(dev, object_count, objects, universal_planes);
if (ret) {
DRM_DEBUG_LEASE("lease validation failed\n");
goto out_free_objects;
@@ -448,7 +450,7 @@ static int fill_object_idr(struct drm_device *dev,
object_id, ret);
goto out_free_objects;
}
- if (obj->type == DRM_MODE_OBJECT_CRTC &&
!lessor_priv->universal_planes) {
+ if (obj->type == DRM_MODE_OBJECT_CRTC && !universal_planes) {
struct drm_crtc *crtc = obj_to_crtc(obj);
ret = idr_alloc(leases, &drm_lease_idr_object,
crtc->primary->base.id, crtc->primary->base.id + 1, GFP_KERNEL);
if (ret < 0) {
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 00/15] drm/i915/icl: dsi enabling
> -Original Message- > From: Kulkarni, Vandita > Sent: Monday, November 5, 2018 3:26 PM > To: Chauhan, Madhav ; Nikula, Jani > ; intel-gfx@lists.freedesktop.org > Cc: Ville Syrjälä > Subject: RE: [Intel-gfx] [PATCH v10 00/15] drm/i915/icl: dsi enabling > > > > > -Original Message- > > From: Chauhan, Madhav > > Sent: Monday, November 5, 2018 3:03 PM > > To: Kulkarni, Vandita ; Nikula, Jani > > ; intel-gfx@lists.freedesktop.org > > Cc: Ville Syrjälä > > Subject: RE: [Intel-gfx] [PATCH v10 00/15] drm/i915/icl: dsi enabling > > > > > -Original Message- > > > From: Kulkarni, Vandita > > > Sent: Monday, November 5, 2018 11:17 AM > > > To: Nikula, Jani ; Chauhan, Madhav > > > ; intel-gfx@lists.freedesktop.org > > > Cc: Ville Syrjälä > > > Subject: RE: [Intel-gfx] [PATCH v10 00/15] drm/i915/icl: dsi > > > enabling > > > > > > > > > > > > > -Original Message- > > > > From: Nikula, Jani > > > > Sent: Sunday, November 4, 2018 12:46 AM > > > > To: Chauhan, Madhav ; intel- > > > > g...@lists.freedesktop.org; Kulkarni, Vandita > > > > > > > > Cc: Ville Syrjälä > > > > Subject: Re: [Intel-gfx] [PATCH v10 00/15] drm/i915/icl: dsi > > > > enabling > > > > > > > > On Sat, 03 Nov 2018, Madhav Chauhan > > > wrote: > > > > > On 11/2/2018 7:15 PM, Jani Nikula wrote: > > > > >> On Fri, 02 Nov 2018, Jani Nikula wrote: > > > > >>> Next version of [1]. Sorry for the spam, needed to get the > > > > >>> authorship straight. Fixed power domains and compute config > > > > >>> hook > > > > initialization. > > > > >> It looks like DDI intel_ddi_get_hw_state() returns true for ICL > > > > >> DSI > > > Yes, it does, checked on Jani's latest branch. > > > > >> as well. I'm not sure how this wasn't a problem before, but if > > > > >> I'm not mistaken it is now. > > > > >> > > > > >> At least that's my only explanation to intel_ddi_get_config() > > > > >> hitting (transcoder_is_dsi(cpu_transcoder)). > > > > > > > > > > I didn't observe that while testing. Where can we access the > > > > > complete > > > log?? > > > Sent. > > > > There were some patches from Clock enabling and one hack wrt to VBT > parsing. > > Vandita will be trying with those. > Thanks Madhav, but looks like just that is not enough. Will keep you posted. Ok. So you included VBT Patch + PLL Enabling + Clock gate/ungated patches. Whats the issue now?? Still WARN_ON?? Regards, Madhav > > Regards, > Vandita > > > > Regards, > > Madhav > > > > > -Vandita > > > > > > > > Vandita reported that. > > > > > > > > BR, > > > > Jani. > > > > > > > > > > > > > > Regards, > > > > > Madhav > > > > > > > > > >> > > > > >> 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: success for drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5
== Series Details == Series: drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5 URL : https://patchwork.freedesktop.org/series/52013/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5085 -> Patchwork_10722 = == Summary - WARNING == Minor unknown changes coming with Patchwork_10722 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10722, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/52013/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_10722: === IGT changes === Warnings igt@drv_selftest@live_guc: fi-icl-u: PASS -> SKIP +2 == Known issues == Here are the changes found in Patchwork_10722 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-blb-e6850: PASS -> INCOMPLETE (fdo#107718) Possible fixes igt@gem_cpu_reloc@basic: fi-skl-6700hq: INCOMPLETE (fdo#108011) -> PASS igt@gem_exec_suspend@basic-s3: fi-glk-dsi: FAIL (fdo#103375) -> PASS igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: DMESG-WARN (fdo#102614) -> PASS fi-icl-u: FAIL (fdo#103167) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-byt-clapper: FAIL (fdo#103191, fdo#107362) -> PASS Warnings igt@drv_selftest@live_contexts: fi-icl-u: DMESG-FAIL (fdo#108569) -> INCOMPLETE (fdo#108315, fdo#108535) fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#108011 https://bugs.freedesktop.org/show_bug.cgi?id=108011 fdo#108315 https://bugs.freedesktop.org/show_bug.cgi?id=108315 fdo#108535 https://bugs.freedesktop.org/show_bug.cgi?id=108535 fdo#108569 https://bugs.freedesktop.org/show_bug.cgi?id=108569 == Participating hosts (45 -> 44) == Additional (4): fi-kbl-7560u fi-gdg-551 fi-bwr-2160 fi-pnv-d510 Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 == Build changes == * Linux: CI_DRM_5085 -> Patchwork_10722 CI_DRM_5085: 6ae61ee5db4af12c0b21bf39e0400ccf024187c4 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4706: 5421c73a7db3cfaa85ab24325fe6e898cbb27fb3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10722: 2c7f605ac0d85a04c93ff6866fcbe7d07dead990 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 2c7f605ac0d8 drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10722/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/lease: debug output for lease creation (rev3)
== Series Details ==
Series: series starting with [1/3] drm/lease: debug output for lease creation
(rev3)
URL : https://patchwork.freedesktop.org/series/51944/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
97b0f495d8f2 drm/lease: debug output for lease creation
b91deb02ca70 drm/file: Uncompact the feature flags
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 39868bd7668b ("drm: Compact
booleans within struct drm_file")'
#8:
commit 39868bd7668bd47308b1dfd97c212757caee764f
-:36: CHECK:BOOL_MEMBER: Avoid using bool structure members because of possible
alignment issues - see: https://lkml.org/lkml/2017/11/21/384
#36: FILE: include/drm/drm_file.h:167:
+ bool authenticated;
-:44: CHECK:BOOL_MEMBER: Avoid using bool structure members because of possible
alignment issues - see: https://lkml.org/lkml/2017/11/21/384
#44: FILE: include/drm/drm_file.h:174:
+ bool stereo_allowed;
-:53: CHECK:BOOL_MEMBER: Avoid using bool structure members because of possible
alignment issues - see: https://lkml.org/lkml/2017/11/21/384
#53: FILE: include/drm/drm_file.h:182:
+ bool universal_planes;
-:57: CHECK:BOOL_MEMBER: Avoid using bool structure members because of possible
alignment issues - see: https://lkml.org/lkml/2017/11/21/384
#57: FILE: include/drm/drm_file.h:185:
+ bool atomic;
-:66: CHECK:BOOL_MEMBER: Avoid using bool structure members because of possible
alignment issues - see: https://lkml.org/lkml/2017/11/21/384
#66: FILE: include/drm/drm_file.h:193:
+ bool aspect_ratio_allowed;
-:74: CHECK:BOOL_MEMBER: Avoid using bool structure members because of possible
alignment issues - see: https://lkml.org/lkml/2017/11/21/384
#74: FILE: include/drm/drm_file.h:200:
+ bool writeback_connectors;
-:83: CHECK:BOOL_MEMBER: Avoid using bool structure members because of possible
alignment issues - see: https://lkml.org/lkml/2017/11/21/384
#83: FILE: include/drm/drm_file.h:211:
+ bool is_master;
-:86: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 1 errors, 1 warnings, 7 checks, 52 lines checked
5ac837eb99e9 drm/lease: look at ->universal_planes only once
-:80: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 51 lines checked
___
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: Release DDI power well references in MST ports
On Fri, Nov 02, 2018 at 01:39:22PM -0700, José Roberto de Souza wrote:
> MST ports did not had the post_pll_disable() hook causing the
> references get in pre_pll_enable() never being released causing
> DDI and AUX CH being enabled all the times.
>
> Cc: Imre Deak
> Cc: Manasi Navare
> Signed-off-by: José Roberto de Souza
Could you resend this and the first patch separately?
Thanks,
Imre
> ---
> drivers/gpu/drm/i915/intel_dp_mst.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 8b71d64ebd9d..8e3d0b04580b 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -215,6 +215,20 @@ static void intel_mst_pre_pll_enable_dp(struct
> intel_encoder *encoder,
> pipe_config, NULL);
> }
>
> +static void intel_mst_post_pll_disable_dp(struct intel_encoder *encoder,
> + const struct intel_crtc_state
> *pipe_config,
> + const struct drm_connector_state
> *conn_state)
> +{
> + struct intel_dp_mst_encoder *intel_mst = enc_to_mst(&encoder->base);
> + struct intel_digital_port *intel_dig_port = intel_mst->primary;
> + struct intel_dp *intel_dp = &intel_dig_port->dp;
> +
> + if (intel_dp->active_mst_links == 0 &&
> + intel_dig_port->base.post_pll_disable)
> + intel_dig_port->base.post_pll_disable(&intel_dig_port->base,
> + pipe_config, NULL);
> +}
> +
> static void intel_mst_pre_enable_dp(struct intel_encoder *encoder,
> const struct intel_crtc_state *pipe_config,
> const struct drm_connector_state
> *conn_state)
> @@ -549,6 +563,7 @@ intel_dp_create_fake_mst_encoder(struct
> intel_digital_port *intel_dig_port, enum
> intel_encoder->disable = intel_mst_disable_dp;
> intel_encoder->post_disable = intel_mst_post_disable_dp;
> intel_encoder->pre_pll_enable = intel_mst_pre_pll_enable_dp;
> + intel_encoder->post_pll_disable = intel_mst_post_pll_disable_dp;
> intel_encoder->pre_enable = intel_mst_pre_enable_dp;
> intel_encoder->enable = intel_mst_enable_dp;
> intel_encoder->get_hw_state = intel_dp_mst_enc_get_hw_state;
> --
> 2.19.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 series starting with [1/3] drm/lease: debug output for lease creation (rev3)
== Series Details == Series: series starting with [1/3] drm/lease: debug output for lease creation (rev3) URL : https://patchwork.freedesktop.org/series/51944/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5085 -> Patchwork_10723 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/51944/revisions/3/mbox/ == Known issues == Here are the changes found in Patchwork_10723 that come from known issues: === IGT changes === Issues hit igt@pm_rpm@basic-pci-d3-state: fi-skl-6600u: PASS -> FAIL (fdo#107707) Possible fixes igt@gem_cpu_reloc@basic: fi-skl-6700hq: INCOMPLETE (fdo#108011) -> PASS igt@gem_exec_suspend@basic-s3: fi-glk-dsi: FAIL (fdo#103375) -> PASS igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: DMESG-WARN (fdo#102614) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-byt-clapper: FAIL (fdo#103191, fdo#107362) -> PASS fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107707 https://bugs.freedesktop.org/show_bug.cgi?id=107707 fdo#108011 https://bugs.freedesktop.org/show_bug.cgi?id=108011 == Participating hosts (45 -> 43) == Additional (4): fi-kbl-7560u fi-gdg-551 fi-bwr-2160 fi-pnv-d510 Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-u == Build changes == * Linux: CI_DRM_5085 -> Patchwork_10723 CI_DRM_5085: 6ae61ee5db4af12c0b21bf39e0400ccf024187c4 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4706: 5421c73a7db3cfaa85ab24325fe6e898cbb27fb3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10723: 5ac837eb99e96e5aa0eb3e6701b40b8fb5463a52 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 5ac837eb99e9 drm/lease: look at ->universal_planes only once b91deb02ca70 drm/file: Uncompact the feature flags 97b0f495d8f2 drm/lease: debug output for lease creation == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10723/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/icl: Only grab TC ports when using it
On Sat, Nov 03, 2018 at 01:41:12AM +0200, Souza, Jose wrote:
> On Sat, 2018-11-03 at 01:06 +0200, Imre Deak wrote:
> > On Fri, Nov 02, 2018 at 01:39:23PM -0700, José Roberto de Souza
> > wrote:
> > > When suspending or unloading the driver, it needs to release the
> > > TC ports so HW can change it state without wait for driver
> > > handshake.
> > > Spec also state that if the port is not used by driver it should
> > > release TC access, so here only grabbing control of the TC ports
> > > and
> > > marking as unsafe when aux power is needed as have aux power well
> > > is
> > > a requirement to have DDI enabled in TC ports, the pre_pll_enable
> > > and
> > > post_pll_disable hooks takes care of getting and releasing it.
> > >
> > > BSpec: 21750
> > >
> > > Cc: Imre Deak
> > > Cc: Ville Syrjälä
> > > Signed-off-by: José Roberto de Souza
> >
> > Agreed that we should force a manual disconnect before entering
> > low-power states and driver unloading, but I don't think this should
> > be
> > done from the power well code. We could perform multiple AUX
> > transfers
> > after a connect event around each of which we would enable/disable
> > the
> > AUX power well. We would then likely continue doing a modeset. During
> > this whole sequence I don't think we should do forced
> > connects/disconnects due to the AUX power well getting
> > enabled/disabled.
> >
> > I think normally we should change the connection status (that is the
> > safe/unsafe mode you're setting here) in response to HPD events, also
> > considering that we may have to delay changing the state as discussed
> > earlier with Ville (due to an ongoing AUX transfer or active mode in
> > the
>
> What do you think about use power_well->count to delay when type-
> c/legacy is disconnected? Then when the last reference is taken
> icl_tc_phy_aux_power_well_disable() check if the TC live status is
> disconnected and mark as unsafe.
^mark as safe if I read the spec correctly, whatever
that means.
I think this should be done from the suspend/unload handlers. At those
places we should put the controller into safe state regardless of the
live status.
> > opposite TypeC mode). Then only during system/runtime suspend and
> > unload
> > should we do a forced disconnect, which would be safe since at those
> > points we don't have any pending AUX transfers or active outputs.
> >
> > --Imre
> >
> > > ---
> > > drivers/gpu/drm/i915/intel_dp.c | 28 -
> > > drivers/gpu/drm/i915/intel_runtime_pm.c | 55
> > > -
> > > 2 files changed, 54 insertions(+), 29 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 52a54ef746af..d978127e7208 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -5013,16 +5013,6 @@ static bool icl_tc_phy_connect(struct
> > > drm_i915_private *dev_priv,
> > > return false;
> > > }
> > >
> > > - /*
> > > - * This function may be called many times in a row without an
> > > HPD event
> > > - * in between, so try to avoid the write when we can.
> > > - */
> > > - val = I915_READ(PORT_TX_DFLEXDPCSSS);
> > > - if (!(val & DP_PHY_MODE_STATUS_NOT_SAFE(tc_port))) {
> > > - val |= DP_PHY_MODE_STATUS_NOT_SAFE(tc_port);
> > > - I915_WRITE(PORT_TX_DFLEXDPCSSS, val);
> > > - }
> > > -
> > > /*
> > >* Now we have to re-check the live state, in case the port
> > > recently
> > >* became disconnected. Not necessary for legacy mode.
> > > @@ -5044,24 +5034,6 @@ static bool icl_tc_phy_connect(struct
> > > drm_i915_private *dev_priv,
> > > static void icl_tc_phy_disconnect(struct drm_i915_private
> > > *dev_priv,
> > > struct intel_digital_port *dig_port)
> > > {
> > > - enum tc_port tc_port = intel_port_to_tc(dev_priv, dig_port-
> > > >base.port);
> > > -
> > > - if (dig_port->tc_type == TC_PORT_UNKNOWN)
> > > - return;
> > > -
> > > - /*
> > > - * TBT disconnection flow is read the live status, what was
> > > done in
> > > - * caller.
> > > - */
> > > - if (dig_port->tc_type == TC_PORT_TYPEC ||
> > > - dig_port->tc_type == TC_PORT_LEGACY) {
> > > - u32 val;
> > > -
> > > - val = I915_READ(PORT_TX_DFLEXDPCSSS);
> > > - val &= ~DP_PHY_MODE_STATUS_NOT_SAFE(tc_port);
> > > - I915_WRITE(PORT_TX_DFLEXDPCSSS, val);
> > > - }
> > > -
> > > dig_port->tc_type = TC_PORT_UNKNOWN;
> > > }
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > index 6c453366cd24..dab5f90646c4 100644
> > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > @@ -465,6 +465,48 @@ icl_combo_phy_aux_power_well_disable(struct
> > > drm_i915_private *dev_priv,
> > > hsw_wait_for_power_well_disable(dev_priv, power_well);
> > > }
> > >
> > > +stat
Re: [Intel-gfx] [PATCH 5/5] drm/i915/icl: Fix port B combo PHY context loss after DC transitions
On Fri, Nov 02, 2018 at 12:22:15PM -0700, Rodrigo Vivi wrote: > On Fri, Nov 02, 2018 at 08:07:06PM +0200, Imre Deak wrote: > > On ICL DMC/PCODE retains the HW context only for port A across DC > > transitions, for the other port B combo PHY, it doesn't. So we need to > > do this manually after exiting from DC6. Do the reinit even after > > exiting from DC5, it won't hurt since we only reinit the PHY in case > > it's needed (in case it was disabled to begin with). > > > > As can be guessed from the bugzilla report leaving the PHY uninited will > > lead to a later timeout during the port B specific AUX and DDI_IO power > > well enabling. > > > > Bspec: 21257 > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108070 > > Cc: Paulo Zanoni > > Cc: Ville Syrjälä > > Cc: José Roberto de Souza > > Cc: Rodrigo Vivi > > Signed-off-by: Imre Deak > > --- > > drivers/gpu/drm/i915/intel_runtime_pm.c | 8 > > 1 file changed, 8 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c > > b/drivers/gpu/drm/i915/intel_runtime_pm.c > > index f8da471e81aa..763912c0245c 100644 > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c > > @@ -843,6 +843,14 @@ static void gen9_dc_off_power_well_enable(struct > > drm_i915_private *dev_priv, > > > > if (IS_GEN9_LP(dev_priv)) > > bxt_verify_ddi_phy_power_wells(dev_priv); > > + > > + if (IS_ICELAKE(dev_priv)) > > maybe INTEL_GEN(dev_priv) >= 11? Ok, will change it. > > > with or without: > > Reviewed-by: Rodrigo Vivi > > > > > + /* > > +* DMC retains HW context only for port A, the other combo > > +* PHY's HW context for port B is lost after DC transitions, > > +* so we need to restore it manually. > > +*/ > > + icl_combo_phys_init(dev_priv); > > } > > > > static void gen9_dc_off_power_well_disable(struct drm_i915_private > > *dev_priv, > > -- > > 2.13.2 > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5
== Series Details == Series: drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5 URL : https://patchwork.freedesktop.org/series/52013/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5085_full -> Patchwork_10722_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_10722_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10722_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_10722_full: === IGT changes === Warnings igt@pm_rc6_residency@rc6-accuracy: shard-snb: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_10722_full that come from known issues: === IGT changes === Issues hit igt@gem_exec_reuse@baggage: shard-apl: PASS -> INCOMPLETE (fdo#103927) igt@gem_exec_schedule@pi-ringfull-bsd: shard-skl: NOTRUN -> FAIL (fdo#103158) +1 igt@gem_softpin@noreloc-s3: shard-skl: NOTRUN -> INCOMPLETE (fdo#104108, fdo#107773) igt@kms_busy@extended-modeset-hang-newfb-render-a: shard-skl: NOTRUN -> DMESG-WARN (fdo#107956) +4 igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: shard-kbl: PASS -> DMESG-WARN (fdo#107956) igt@kms_busy@extended-pageflip-hang-newfb-render-a: shard-apl: PASS -> DMESG-WARN (fdo#107956) igt@kms_cursor_crc@cursor-128x42-onscreen: shard-skl: NOTRUN -> FAIL (fdo#103232) igt@kms_cursor_crc@cursor-256x256-dpms: shard-glk: PASS -> FAIL (fdo#103232) +2 igt@kms_fbcon_fbt@psr: shard-skl: NOTRUN -> FAIL (fdo#107882) igt@kms_flip_tiling@flip-y-tiled: shard-skl: NOTRUN -> FAIL (fdo#108303) igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen: shard-apl: PASS -> FAIL (fdo#103167) igt@kms_frontbuffer_tracking@fbc-stridechange: shard-skl: NOTRUN -> FAIL (fdo#105683) igt@kms_plane@plane-position-covered-pipe-b-planes: shard-glk: PASS -> FAIL (fdo#103166) +1 igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max: shard-skl: NOTRUN -> FAIL (fdo#108145) +4 igt@kms_plane_alpha_blend@pipe-b-alpha-basic: shard-skl: NOTRUN -> FAIL (fdo#107815, fdo#108145) +1 igt@kms_properties@connector-properties-atomic: shard-skl: NOTRUN -> FAIL (fdo#108642) igt@kms_setmode@basic: shard-skl: NOTRUN -> FAIL (fdo#99912) igt@kms_sysfs_edid_timing: shard-skl: NOTRUN -> FAIL (fdo#100047) Possible fixes igt@gem_exec_reloc@basic-wc-cpu-noreloc: shard-snb: INCOMPLETE (fdo#105411) -> PASS igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c: shard-hsw: DMESG-WARN (fdo#107956) -> PASS igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a: shard-snb: DMESG-WARN (fdo#107956) -> PASS igt@kms_cursor_crc@cursor-128x42-onscreen: shard-glk: FAIL (fdo#103232) -> PASS +1 igt@kms_cursor_crc@cursor-64x64-offscreen: shard-skl: FAIL (fdo#103232) -> PASS +1 igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-ytiled: shard-skl: FAIL (fdo#103184) -> PASS igt@kms_draw_crc@draw-method-xrgb-pwrite-untiled: shard-skl: FAIL (fdo#108472) -> PASS igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-mmap-cpu: shard-skl: FAIL (fdo#105682) -> PASS igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-cpu: shard-apl: FAIL (fdo#103167) -> PASS igt@kms_frontbuffer_tracking@fbc-1p-rte: shard-glk: FAIL (fdo#105682, fdo#103167) -> PASS igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-onoff: shard-glk: FAIL (fdo#103167) -> PASS +1 igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-wc: shard-skl: FAIL (fdo#105682, fdo#103167) -> PASS igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: shard-skl: FAIL (fdo#107815, fdo#108145) -> PASS igt@kms_plane_multiple@atomic-pipe-a-tiling-x: shard-apl: FAIL (fdo#103166) -> PASS +2 igt@kms_plane_multiple@atomic-pipe-a-tiling-yf: shard-glk: FAIL (fdo#103166) -> PASS igt@perf@oa-exponents: shard-glk: FAIL (fdo#105483) -> PASS igt@pm_rpm@system-suspend: shard-skl: INCOMPLETE (fdo#107807, fdo#104108, fdo#107773) -> PASS fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158 fdo#103166 https://bu
[Intel-gfx] [PATCH v4] mm, drm/i915: mark pinned shmemfs pages as unevictable
The i915 driver uses shmemfs to allocate backing storage for gem
objects. These shmemfs pages can be pinned (increased ref count) by
shmem_read_mapping_page_gfp(). When a lot of pages are pinned, vmscan
wastes a lot of time scanning these pinned pages. In some extreme case,
all pages in the inactive anon lru are pinned, and only the inactive
anon lru is scanned due to inactive_ratio, the system cannot swap and
invokes the oom-killer. Mark these pinned pages as unevictable to speed
up vmscan.
Export pagevec API check_move_unevictable_pages().
This patch was inspired by Chris Wilson's change [1].
[1]: https://patchwork.kernel.org/patch/9768741/
Cc: Chris Wilson
Cc: Michal Hocko
Cc: Joonas Lahtinen
Cc: Peter Zijlstra
Cc: Andrew Morton
Cc: Dave Hansen
Signed-off-by: Kuo-Hsin Yang
---
Changes for v4:
Export pagevec API check_move_unevictable_pages().
Changes for v3:
Use check_move_lru_page instead of shmem_unlock_mapping to move pages
to appropriate lru lists.
Changes for v2:
Squashed the two patches.
Documentation/vm/unevictable-lru.rst | 4 +++-
drivers/gpu/drm/i915/i915_gem.c | 25 +++--
include/linux/swap.h | 4 +++-
mm/shmem.c | 2 +-
mm/vmscan.c | 18 +-
5 files changed, 39 insertions(+), 14 deletions(-)
diff --git a/Documentation/vm/unevictable-lru.rst
b/Documentation/vm/unevictable-lru.rst
index fdd84cb8d511..a812fb55136d 100644
--- a/Documentation/vm/unevictable-lru.rst
+++ b/Documentation/vm/unevictable-lru.rst
@@ -143,7 +143,7 @@ using a number of wrapper functions:
Query the address space, and return true if it is completely
unevictable.
-These are currently used in two places in the kernel:
+These are currently used in three places in the kernel:
(1) By ramfs to mark the address spaces of its inodes when they are created,
and this mark remains for the life of the inode.
@@ -154,6 +154,8 @@ These are currently used in two places in the kernel:
swapped out; the application must touch the pages manually if it wants to
ensure they're in memory.
+ (3) By the i915 driver to mark pinned address space until it's unpinned.
+
Detecting Unevictable Pages
---
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0c8aa57ce83b..7972eeb2e921 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2381,12 +2381,22 @@ void __i915_gem_object_invalidate(struct
drm_i915_gem_object *obj)
invalidate_mapping_pages(mapping, 0, (loff_t)-1);
}
+/* Move pages to appropriate lru and release the pagevec */
+static inline void check_release_pagevec(struct pagevec *pvec)
+{
+ if (pagevec_count(pvec)) {
+ check_move_unevictable_pages(pvec);
+ __pagevec_release(pvec);
+ }
+}
+
static void
i915_gem_object_put_pages_gtt(struct drm_i915_gem_object *obj,
struct sg_table *pages)
{
struct sgt_iter sgt_iter;
struct page *page;
+ struct pagevec pvec;
__i915_gem_object_release_shmem(obj, pages, true);
@@ -2395,6 +2405,9 @@ i915_gem_object_put_pages_gtt(struct drm_i915_gem_object
*obj,
if (i915_gem_object_needs_bit17_swizzle(obj))
i915_gem_object_save_bit_17_swizzle(obj, pages);
+ mapping_clear_unevictable(file_inode(obj->base.filp)->i_mapping);
+
+ pagevec_init(&pvec);
for_each_sgt_page(page, sgt_iter, pages) {
if (obj->mm.dirty)
set_page_dirty(page);
@@ -2402,8 +2415,10 @@ i915_gem_object_put_pages_gtt(struct drm_i915_gem_object
*obj,
if (obj->mm.madv == I915_MADV_WILLNEED)
mark_page_accessed(page);
- put_page(page);
+ if (!pagevec_add(&pvec, page))
+ check_release_pagevec(&pvec);
}
+ check_release_pagevec(&pvec);
obj->mm.dirty = false;
sg_free_table(pages);
@@ -2526,6 +2541,7 @@ static int i915_gem_object_get_pages_gtt(struct
drm_i915_gem_object *obj)
unsigned int sg_page_sizes;
gfp_t noreclaim;
int ret;
+ struct pagevec pvec;
/*
* Assert that the object is not currently in any GPU domain. As it
@@ -2559,6 +2575,7 @@ static int i915_gem_object_get_pages_gtt(struct
drm_i915_gem_object *obj)
* Fail silently without starting the shrinker
*/
mapping = obj->base.filp->f_mapping;
+ mapping_set_unevictable(mapping);
noreclaim = mapping_gfp_constraint(mapping, ~__GFP_RECLAIM);
noreclaim |= __GFP_NORETRY | __GFP_NOWARN;
@@ -2673,8 +2690,12 @@ static int i915_gem_object_get_pages_gtt(struct
drm_i915_gem_object *obj)
err_sg:
sg_mark_end(sg);
err_pages:
+ mapping_clear_unevictable(mapping);
+ pagevec_init(&pvec);
for_each_sgt_page(page,
Re: [Intel-gfx] [PATCH v3] mm, drm/i915: mark pinned shmemfs pages as unevictable
On Fri, Nov 2, 2018 at 10:05 PM Dave Hansen wrote: > On 11/2/18 6:22 AM, Vovo Yang wrote: > > Chris helped to answer this question: > > Though it includes a few non-shmemfs objects, see > > debugfs/dri/0/i915_gem_objects and the "bound objects". > > > > Example i915_gem_object output: > > 591 objects, 95449088 bytes > > 55 unbound objects, 1880064 bytes > > 533 bound objects, 93040640 bytes > > Do those non-shmemfs objects show up on the unevictable list? How far > can the amount of memory on the unevictable list and the amount > displayed in this "bound objects" value diverge? Those non-shmemfs objects would not show up on the unevictable list. On typical use case, The size of gtt bounded objects (in unevictable list) is very close to the bound size in i915_gem_objects. E.g. on my laptop: i915_gem_object shows 110075904 bytes bounded objects, and there are 109760512 bytes gtt bounded objects, the difference is about 0.3%. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for mm, drm/i915: Mark pinned shmemfs pages as unevictable (rev3)
== Series Details == Series: mm, drm/i915: Mark pinned shmemfs pages as unevictable (rev3) URL : https://patchwork.freedesktop.org/series/25337/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6cf86e3e77fd mm, drm/i915: mark pinned shmemfs pages as unevictable -:148: CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files #148: FILE: include/linux/swap.h:374: +extern void check_move_unevictable_pages(struct pagevec *pvec); total: 0 errors, 0 warnings, 1 checks, 151 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/25] RFT drm/i915/execlists: Flush memory before signaling ELSQ
Chris Wilson writes:
> We observe that the ordering of writes for a CS event is not as strong
> from the GPU as we would like, and that on occasions we see the
> ringbuffer tail updated before the event is written into the ringbuffer,
> leading us to reuse the stale data.
>
> Through around a big hammer to try and batter ELSQ into submission with
> the presumption that perhaps the UC mmio write is not flushing our
> writes into the context images.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=108315
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 22b57b8926fc..ba61849fbb9b 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -454,8 +454,10 @@ static void execlists_submit_ports(struct
> intel_engine_cs *engine)
> }
>
> /* we need to manually load the submit queue */
> - if (execlists->ctrl_reg)
> + if (execlists->ctrl_reg) {
> + wmb(); /* XXX Big hammer or paper? XXX */
Well, even tho it would be papering, we need it, assuming
it helps.
Next step is to go with mmio based csb, that is papering also :O
Reviewed-by: Mika Kuoppala
-Mika
> writel(EL_CTRL_LOAD, execlists->ctrl_reg);
> + }
>
> execlists_clear_active(execlists, EXECLISTS_ACTIVE_HWACK);
> }
> --
> 2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 00/15] drm/i915/icl: dsi enabling
> -Original Message- > From: Chauhan, Madhav > Sent: Monday, November 5, 2018 3:46 PM > To: Kulkarni, Vandita ; Nikula, Jani > ; intel-gfx@lists.freedesktop.org > Cc: Ville Syrjälä > Subject: RE: [Intel-gfx] [PATCH v10 00/15] drm/i915/icl: dsi enabling > > > -Original Message- > > From: Kulkarni, Vandita > > Sent: Monday, November 5, 2018 3:26 PM > > To: Chauhan, Madhav ; Nikula, Jani > > ; intel-gfx@lists.freedesktop.org > > Cc: Ville Syrjälä > > Subject: RE: [Intel-gfx] [PATCH v10 00/15] drm/i915/icl: dsi enabling > > > > > > > > > -Original Message- > > > From: Chauhan, Madhav > > > Sent: Monday, November 5, 2018 3:03 PM > > > To: Kulkarni, Vandita ; Nikula, Jani > > > ; intel-gfx@lists.freedesktop.org > > > Cc: Ville Syrjälä > > > Subject: RE: [Intel-gfx] [PATCH v10 00/15] drm/i915/icl: dsi > > > enabling > > > > > > > -Original Message- > > > > From: Kulkarni, Vandita > > > > Sent: Monday, November 5, 2018 11:17 AM > > > > To: Nikula, Jani ; Chauhan, Madhav > > > > ; intel-gfx@lists.freedesktop.org > > > > Cc: Ville Syrjälä > > > > Subject: RE: [Intel-gfx] [PATCH v10 00/15] drm/i915/icl: dsi > > > > enabling > > > > > > > > > > > > > > > > > -Original Message- > > > > > From: Nikula, Jani > > > > > Sent: Sunday, November 4, 2018 12:46 AM > > > > > To: Chauhan, Madhav ; intel- > > > > > g...@lists.freedesktop.org; Kulkarni, Vandita > > > > > > > > > > Cc: Ville Syrjälä > > > > > Subject: Re: [Intel-gfx] [PATCH v10 00/15] drm/i915/icl: dsi > > > > > enabling > > > > > > > > > > On Sat, 03 Nov 2018, Madhav Chauhan > > > > wrote: > > > > > > On 11/2/2018 7:15 PM, Jani Nikula wrote: > > > > > >> On Fri, 02 Nov 2018, Jani Nikula wrote: > > > > > >>> Next version of [1]. Sorry for the spam, needed to get the > > > > > >>> authorship straight. Fixed power domains and compute config > > > > > >>> hook > > > > > initialization. > > > > > >> It looks like DDI intel_ddi_get_hw_state() returns true for > > > > > >> ICL DSI > > > > Yes, it does, checked on Jani's latest branch. > > > > > >> as well. I'm not sure how this wasn't a problem before, but > > > > > >> if I'm not mistaken it is now. > > > > > >> > > > > > >> At least that's my only explanation to intel_ddi_get_config() > > > > > >> hitting (transcoder_is_dsi(cpu_transcoder)). > > > > > > > > > > > > I didn't observe that while testing. Where can we access the > > > > > > complete > > > > log?? > > > > Sent. > > > > > > There were some patches from Clock enabling and one hack wrt to VBT > > parsing. > > > Vandita will be trying with those. > > Thanks Madhav, but looks like just that is not enough. Will keep you posted. > Ok. So you included VBT Patch + PLL Enabling + Clock gate/ungated patches. Yes. > Whats the issue now?? Still WARN_ON?? Looks like the VBT hack fixes the WARN_ON and the ddi calls. Thanks for the help. Unfortunately, it doesn't boot, even with the above recipe. There is a hard hang. Regards, Vandita > > Regards, > Madhav > > > > > Regards, > > Vandita > > > > > > Regards, > > > Madhav > > > > > > > -Vandita > > > > > > > > > > Vandita reported that. > > > > > > > > > > BR, > > > > > Jani. > > > > > > > > > > > > > > > > > Regards, > > > > > > Madhav > > > > > > > > > > > >> > > > > > >> 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: success for mm, drm/i915: Mark pinned shmemfs pages as unevictable (rev3)
== Series Details == Series: mm, drm/i915: Mark pinned shmemfs pages as unevictable (rev3) URL : https://patchwork.freedesktop.org/series/25337/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5085 -> Patchwork_10724 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/25337/revisions/3/mbox/ == Known issues == Here are the changes found in Patchwork_10724 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s3: fi-kbl-soraka: NOTRUN -> INCOMPLETE (fdo#107556, fdo#107859, fdo#107774) igt@kms_chamelium@dp-edid-read: fi-kbl-7500u: PASS -> WARN (fdo#102672) igt@kms_frontbuffer_tracking@basic: fi-byt-clapper: PASS -> FAIL (fdo#103167) Possible fixes igt@gem_cpu_reloc@basic: fi-skl-6700hq: INCOMPLETE (fdo#108011) -> PASS igt@gem_exec_suspend@basic-s3: fi-glk-dsi: FAIL (fdo#103375) -> PASS igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: DMESG-WARN (fdo#102614) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-byt-clapper: FAIL (fdo#107362, fdo#103191) -> PASS fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107556 https://bugs.freedesktop.org/show_bug.cgi?id=107556 fdo#107774 https://bugs.freedesktop.org/show_bug.cgi?id=107774 fdo#107859 https://bugs.freedesktop.org/show_bug.cgi?id=107859 fdo#108011 https://bugs.freedesktop.org/show_bug.cgi?id=108011 == Participating hosts (45 -> 45) == Additional (6): fi-kbl-soraka fi-bwr-2160 fi-ilk-650 fi-snb-2520m fi-gdg-551 fi-kbl-7560u Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-u == Build changes == * Linux: CI_DRM_5085 -> Patchwork_10724 CI_DRM_5085: 6ae61ee5db4af12c0b21bf39e0400ccf024187c4 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4706: 5421c73a7db3cfaa85ab24325fe6e898cbb27fb3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10724: 6cf86e3e77fd663f2ac3423a3606de6bbb790871 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 6cf86e3e77fd mm, drm/i915: mark pinned shmemfs pages as unevictable == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10724/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/lease: debug output for lease creation (rev3)
== Series Details == Series: series starting with [1/3] drm/lease: debug output for lease creation (rev3) URL : https://patchwork.freedesktop.org/series/51944/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_5085_full -> Patchwork_10723_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_10723_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10723_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_10723_full: === IGT changes === Possible regressions igt@drm_import_export@import-close-race-flink: shard-skl: NOTRUN -> TIMEOUT Warnings igt@pm_rc6_residency@rc6-accuracy: shard-snb: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_10723_full that come from known issues: === IGT changes === Issues hit igt@gem_cpu_reloc@full: shard-skl: NOTRUN -> INCOMPLETE (fdo#108073) igt@gem_exec_schedule@pi-ringfull-bsd: shard-skl: NOTRUN -> FAIL (fdo#103158) +2 igt@kms_busy@extended-modeset-hang-newfb-render-a: shard-skl: NOTRUN -> DMESG-WARN (fdo#107956) +4 igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: shard-kbl: PASS -> DMESG-WARN (fdo#107956) igt@kms_busy@extended-pageflip-hang-newfb-render-a: shard-apl: PASS -> DMESG-WARN (fdo#107956) igt@kms_ccs@pipe-b-bad-pixel-format: shard-apl: PASS -> DMESG-WARN (fdo#105602, fdo#103558) +3 igt@kms_chv_cursor_fail@pipe-c-256x256-top-edge: shard-skl: PASS -> FAIL (fdo#104671) igt@kms_cursor_crc@cursor-128x128-random: shard-apl: PASS -> FAIL (fdo#103232) +1 igt@kms_cursor_crc@cursor-128x42-onscreen: shard-skl: NOTRUN -> FAIL (fdo#103232) +1 igt@kms_cursor_crc@cursor-64x64-dpms: shard-glk: PASS -> FAIL (fdo#103232) igt@kms_cursor_crc@cursor-64x64-suspend: shard-apl: PASS -> FAIL (fdo#103191, fdo#103232) igt@kms_cursor_legacy@cursorb-vs-flipb-toggle: shard-glk: PASS -> DMESG-WARN (fdo#105763, fdo#106538) igt@kms_fbcon_fbt@psr: shard-skl: NOTRUN -> FAIL (fdo#107882) igt@kms_flip_tiling@flip-y-tiled: shard-skl: NOTRUN -> FAIL (fdo#108303) igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-render: shard-apl: PASS -> FAIL (fdo#103167) +3 igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff: shard-glk: PASS -> FAIL (fdo#103167) igt@kms_frontbuffer_tracking@fbc-stridechange: shard-skl: NOTRUN -> FAIL (fdo#105683) igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: shard-skl: NOTRUN -> FAIL (fdo#103166) igt@kms_plane@plane-position-covered-pipe-a-planes: shard-glk: PASS -> FAIL (fdo#103166) +2 igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb: shard-skl: NOTRUN -> FAIL (fdo#108145) +7 igt@kms_plane_alpha_blend@pipe-b-alpha-basic: shard-skl: NOTRUN -> FAIL (fdo#108145, fdo#107815) +1 igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: shard-skl: NOTRUN -> FAIL (fdo#107815) igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: shard-skl: PASS -> FAIL (fdo#107815) igt@kms_plane_multiple@atomic-pipe-c-tiling-yf: shard-apl: PASS -> FAIL (fdo#103166) +2 igt@kms_properties@connector-properties-atomic: shard-skl: NOTRUN -> FAIL (fdo#108642) igt@kms_rotation_crc@primary-rotation-90: shard-skl: NOTRUN -> FAIL (fdo#103925, fdo#107815) igt@kms_setmode@basic: shard-skl: NOTRUN -> FAIL (fdo#99912) shard-kbl: PASS -> FAIL (fdo#99912) igt@kms_sysfs_edid_timing: shard-skl: NOTRUN -> FAIL (fdo#100047) igt@perf@buffer-fill: shard-kbl: PASS -> INCOMPLETE (fdo#103665) Possible fixes igt@drv_suspend@debugfs-reader: shard-kbl: INCOMPLETE (fdo#103665) -> PASS igt@kms_cursor_crc@cursor-128x42-onscreen: shard-glk: FAIL (fdo#103232) -> PASS +1 shard-apl: FAIL (fdo#103232) -> PASS +2 igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-cpu: shard-apl: FAIL (fdo#103167) -> PASS igt@kms_frontbuffer_tracking@fbc-1p-rte: shard-glk: FAIL (fdo#103167, fdo#105682) -> PASS igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-onoff: shard-glk: FAIL (fdo#103167) -> PASS +3 igt@kms_plane_multiple@atomic-pipe-a-
Re: [Intel-gfx] [PATCH v4] mm, drm/i915: mark pinned shmemfs pages as unevictable
On Mon 05-11-18 19:13:48, Kuo-Hsin Yang wrote:
> The i915 driver uses shmemfs to allocate backing storage for gem
> objects. These shmemfs pages can be pinned (increased ref count) by
> shmem_read_mapping_page_gfp(). When a lot of pages are pinned, vmscan
> wastes a lot of time scanning these pinned pages. In some extreme case,
> all pages in the inactive anon lru are pinned, and only the inactive
> anon lru is scanned due to inactive_ratio, the system cannot swap and
> invokes the oom-killer. Mark these pinned pages as unevictable to speed
> up vmscan.
>
> Export pagevec API check_move_unevictable_pages().
Thanks for reworking the patch. This looks much more to my taste. At
least the mm part. I haven't really looked at the the drm part.
Just a nit below
> This patch was inspired by Chris Wilson's change [1].
>
> [1]: https://patchwork.kernel.org/patch/9768741/
I would recommend using msg-id based url.
> Cc: Chris Wilson
> Cc: Michal Hocko
> Cc: Joonas Lahtinen
> Cc: Peter Zijlstra
> Cc: Andrew Morton
> Cc: Dave Hansen
> Signed-off-by: Kuo-Hsin Yang
other than that
Acked-by: Michal Hocko
[...]
> @@ -4184,15 +4185,13 @@ int page_evictable(struct page *page)
>
> #ifdef CONFIG_SHMEM
> /**
> - * check_move_unevictable_pages - check pages for evictability and move to
> appropriate zone lru list
> - * @pages: array of pages to check
> - * @nr_pages:number of pages to check
> + * check_move_unevictable_pages - move evictable pages to appropriate
> evictable
> + * lru lists
I am not sure this is an improvement. I would just keep the original
wording. It is not great either but the explicit note about check for
evictability sounds like a better fit to me.
> + * @pvec: pagevec with pages to check
> *
> - * Checks pages for evictability and moves them to the appropriate lru list.
> - *
> - * This function is only used for SysV IPC SHM_UNLOCK.
> + * This function is only used to move shmem pages.
I do not really see anything that would be shmem specific here. We can
use this function for any LRU pages unless I am missing something
obscure. I would just drop the last sentence.
A note that this function should be only used for LRU pages would be
nice.
> */
> -void check_move_unevictable_pages(struct page **pages, int nr_pages)
> +void check_move_unevictable_pages(struct pagevec *pvec)
> {
> struct lruvec *lruvec;
> struct pglist_data *pgdat = NULL;
> @@ -4200,8 +4199,8 @@ void check_move_unevictable_pages(struct page **pages,
> int nr_pages)
> int pgrescued = 0;
> int i;
>
> - for (i = 0; i < nr_pages; i++) {
> - struct page *page = pages[i];
> + for (i = 0; i < pvec->nr; i++) {
> + struct page *page = pvec->pages[i];
> struct pglist_data *pagepgdat = page_pgdat(page);
>
> pgscanned++;
> @@ -4233,4 +4232,5 @@ void check_move_unevictable_pages(struct page **pages,
> int nr_pages)
> spin_unlock_irq(&pgdat->lru_lock);
> }
> }
> +EXPORT_SYMBOL(check_move_unevictable_pages);
> #endif /* CONFIG_SHMEM */
> --
> 2.19.1.930.g4563a0d9d0-goog
>
--
Michal Hocko
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] mm, drm/i915: mark pinned shmemfs pages as unevictable
On Mon 05-11-18 14:02:09, Michal Hocko wrote: > On Mon 05-11-18 19:13:48, Kuo-Hsin Yang wrote: > > The i915 driver uses shmemfs to allocate backing storage for gem > > objects. These shmemfs pages can be pinned (increased ref count) by > > shmem_read_mapping_page_gfp(). When a lot of pages are pinned, vmscan > > wastes a lot of time scanning these pinned pages. In some extreme case, > > all pages in the inactive anon lru are pinned, and only the inactive > > anon lru is scanned due to inactive_ratio, the system cannot swap and > > invokes the oom-killer. Mark these pinned pages as unevictable to speed > > up vmscan. > > > > Export pagevec API check_move_unevictable_pages(). > > Thanks for reworking the patch. This looks much more to my taste. At > least the mm part. I haven't really looked at the the drm part. One side note. Longterm we probably want a better pinning API. It would hide this LRU manipulation implementation detail + enforce some limiting and provide a good way that the pin is longterm. People are working on this already but it is a PITA and long time to get there. -- Michal Hocko SUSE Labs ___ 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 drm/i915/icl: Fix suspend/resume for TypeC HDMI
On Sat, Nov 03, 2018 at 12:45:01AM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/icl: Fix suspend/resume for TypeC HDMI > URL : https://patchwork.freedesktop.org/series/51976/ > State : failure The failures are unrelated since all those platforms are without a TypeC port and the changes have an effect only on TypeC ports. More below. > > == Summary == > > = CI Bug Log - changes from CI_DRM_5081_full -> Patchwork_10716_full = > > == Summary - FAILURE == > > Serious unknown changes coming with Patchwork_10716_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_10716_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_10716_full: > > === IGT changes === > > Possible regressions > > igt@kms_cursor_crc@cursor-64x21-offscreen: > shard-skl: PASS -> INCOMPLETE Haven't found anything in the logs, I added a comment about this failure to https://bugs.freedesktop.org/show_bug.cgi?id=104108 > Warnings > > igt@kms_cursor_legacy@flip-vs-cursor-crc-legacy: > shard-snb: SKIP -> PASS +3 Not sure what this is about, it's a 'SKIP->PASS' and I haven't found any errors/warnings in the log. > > igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-plflip-blt: > shard-snb: PASS -> SKIP +1 VGA output can't be detected after a system suspend/resume cycle. I opened a new bug for this: https://bugs.freedesktop.org/show_bug.cgi?id=108663 > > igt@perf_pmu@rc6: > shard-kbl: PASS -> SKIP GPU doesn't enter RC6, opened a new bug for it: https://bugs.freedesktop.org/show_bug.cgi?id=108664 > > > == Known issues == > > Here are the changes found in Patchwork_10716_full that come from known > issues: > > === IGT changes === > > Issues hit > > igt@gem_userptr_blits@readonly-unsync: > shard-skl: NOTRUN -> INCOMPLETE (fdo#108074) > > igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: > shard-skl: NOTRUN -> DMESG-WARN (fdo#107956) > > igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c: > shard-glk: PASS -> DMESG-WARN (fdo#107956) > > igt@kms_chv_cursor_fail@pipe-b-128x128-bottom-edge: > shard-skl: PASS -> FAIL (fdo#104671) > > igt@kms_chv_cursor_fail@pipe-b-64x64-bottom-edge: > shard-kbl: PASS -> DMESG-WARN (fdo#105345) > > igt@kms_color@pipe-c-legacy-gamma: > shard-apl: PASS -> FAIL (fdo#104782) > > igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic: > shard-glk: PASS -> FAIL (fdo#106509, fdo#105454) > > igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt: > shard-skl: NOTRUN -> FAIL (fdo#103167) +1 > > igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff: > shard-apl: PASS -> FAIL (fdo#103167) > > igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence: > shard-skl: PASS -> FAIL (fdo#107362, fdo#103191) > > igt@kms_plane@plane-position-covered-pipe-c-planes: > shard-apl: PASS -> FAIL (fdo#103166) +1 > > igt@kms_setmode@basic: > shard-kbl: PASS -> FAIL (fdo#99912) > > igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend: > shard-skl: PASS -> INCOMPLETE (fdo#107773, fdo#104108) > > > Possible fixes > > igt@kms_busy@extended-modeset-hang-newfb-render-b: > shard-skl: DMESG-WARN (fdo#107956) -> PASS > > igt@kms_cursor_crc@cursor-128x128-suspend: > shard-skl: INCOMPLETE (fdo#104108) -> PASS > > igt@kms_cursor_crc@cursor-128x42-random: > shard-skl: FAIL (fdo#103232) -> PASS > > igt@kms_cursor_crc@cursor-256x256-sliding: > shard-glk: FAIL (fdo#103232) -> PASS +1 > > igt@kms_cursor_crc@cursor-256x85-random: > shard-apl: FAIL (fdo#103232) -> PASS +1 > > igt@kms_flip@flip-vs-expired-vblank: > shard-skl: FAIL (fdo#105363) -> PASS > > igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt: > shard-glk: FAIL (fdo#103167) -> PASS > > igt@kms_plane@plane-position-covered-pipe-b-planes: > shard-glk: FAIL (fdo#103166) -> PASS +2 > > igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: > shard-skl: FAIL (fdo#107815) -> PASS > > igt@kms_setmode@basic: > shard-apl: FAIL (fdo#99912) -> PASS > > igt@pm_rpm@legacy-planes-dpms: > shard-skl: INCOMPLETE (fdo#105959, fdo#107807) -> PASS > > > fdo#103166 https://bugs.freedesktop.org/show_
[Intel-gfx] [PATCH v4 1/2] drm/i915/skl: Rework MOCS tables to keep common part in a define
The MOCS tables are going to be very similar across platforms.
To reduce the amount of copied code, this patch rips the common part and
puts it into a definition valid for all gen9 platforms.
Signed-off-by: Tomasz Lis
Suggested-by: Lucas De Marchi
Reviewed-by: Lucas De Marchi
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_mocs.c | 61 ++-
1 file changed, 22 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_mocs.c
b/drivers/gpu/drm/i915/intel_mocs.c
index 77e9871..76aed59 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -96,26 +96,29 @@ struct drm_i915_mocs_table {
* may only be updated incrementally by adding entries at the
* end.
*/
-static const struct drm_i915_mocs_entry skylake_mocs_table[] = {
- [I915_MOCS_UNCACHED] = {
- /* 0x0009 */
- .control_value = LE_CACHEABILITY(LE_UC) |
- LE_TGT_CACHE(LE_TC_LLC_ELLC) |
- LE_LRUM(0) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
- LE_PFM(0) | LE_SCF(0),
- /* 0x0010 */
- .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
- },
- [I915_MOCS_PTE] = {
- /* 0x0038 */
- .control_value = LE_CACHEABILITY(LE_PAGETABLE) |
- LE_TGT_CACHE(LE_TC_LLC_ELLC) |
- LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
- LE_PFM(0) | LE_SCF(0),
- /* 0x0030 */
- .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+#define GEN9_MOCS_TABLE \
+ [I915_MOCS_UNCACHED] = { \
+ /* 0x0009 */ \
+ .control_value = LE_CACHEABILITY(LE_UC) | \
+ LE_TGT_CACHE(LE_TC_LLC_ELLC) | \
+ LE_LRUM(0) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) | \
+ LE_PFM(0) | LE_SCF(0), \
+ /* 0x0010 */ \
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC), \
+ }, \
+ [I915_MOCS_PTE] = { \
+ /* 0x0038 */ \
+ .control_value = LE_CACHEABILITY(LE_PAGETABLE) | \
+ LE_TGT_CACHE(LE_TC_LLC_ELLC) | \
+ LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) | \
+ LE_PFM(0) | LE_SCF(0), \
+ /* 0x0030 */ \
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB), \
},
+
+static const struct drm_i915_mocs_entry skylake_mocs_table[] = {
+ GEN9_MOCS_TABLE
[I915_MOCS_CACHED] = {
/* 0x003b */
.control_value = LE_CACHEABILITY(LE_WB) |
@@ -129,33 +132,13 @@ static const struct drm_i915_mocs_entry
skylake_mocs_table[] = {
/* NOTE: the LE_TGT_CACHE is not used on Broxton */
static const struct drm_i915_mocs_entry broxton_mocs_table[] = {
- [I915_MOCS_UNCACHED] = {
- /* 0x0009 */
- .control_value = LE_CACHEABILITY(LE_UC) |
- LE_TGT_CACHE(LE_TC_LLC_ELLC) |
- LE_LRUM(0) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
- LE_PFM(0) | LE_SCF(0),
-
- /* 0x0010 */
- .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
- },
- [I915_MOCS_PTE] = {
- /* 0x0038 */
- .control_value = LE_CACHEABILITY(LE_PAGETABLE) |
- LE_TGT_CACHE(LE_TC_LLC_ELLC) |
- LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
- LE_PFM(0) | LE_SCF(0),
-
- /* 0x0030 */
- .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
- },
+ GEN9_MOCS_TABLE
[I915_MOCS_CACHED] = {
/* 0x0039 */
.control_value = LE_CACHEABILITY(LE_UC) |
LE_TGT_CACHE(LE_TC_LLC_ELLC) |
LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
LE_PFM(0) | LE_SCF(0),
-
/* 0x0030 */
.l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
},
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/2] drm/i915/icl: Define MOCS table for Icelake
The table has been unified across OSes to minimize virtualization overhead.
The MOCS table is now published as part of bspec, and versioned. Entries
are supposed to never be modified, but new ones can be added. Adding
entries increases table version. The patch includes version 1 entries.
Meaning of each entry is now explained in bspec, and user mode clients
are expected to know what each entry means. The 3 entries used for previous
platforms are still compatible with their legacy definitions, but that is
not guaranteed to be true for future platforms.
v2: Fixed SCC values, improved commit comment (Daniele)
v3: Improved MOCS table comment (Daniele)
v4: Moved new entries below gen9 ones. Put common entries into
definition to be used in multiple arrays. (Lucas)
BSpec: 34007
BSpec: 560
Signed-off-by: Tomasz Lis
Reviewed-by: Daniele Ceraolo Spurio (v3)
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Daniele Ceraolo Spurio
Cc: Zhenyu Wang
Cc: Zhi A Wang
Cc: Anuj Phogat
Cc: Adam Cetnerowski
Cc: Piotr Rozenfeld
Cc: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_mocs.c | 249 +++---
1 file changed, 235 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_mocs.c
b/drivers/gpu/drm/i915/intel_mocs.c
index 76aed59..2a1e5f0 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -44,6 +44,8 @@ struct drm_i915_mocs_table {
#define LE_SCC(value) ((value) << 8)
#define LE_PFM(value) ((value) << 11)
#define LE_SCF(value) ((value) << 14)
+#define LE_CoS(value) ((value) << 15)
+#define LE_SSE(value) ((value) << 17)
/* Defines for the tables (LNCFMOCS0 - LNCFMOCS31) - two entries per word */
#define L3_ESC(value) ((value) << 0)
@@ -80,21 +82,21 @@ struct drm_i915_mocs_table {
* LNCFCMOCS0 - LNCFCMOCS32 registers.
*
* These tables are intended to be kept reasonably consistent across
- * platforms. However some of the fields are not applicable to all of
- * them.
+ * HW platforms, and for ICL+, be identical across OSes. To achieve
+ * that, for Icelake and above, list of entries is published as part
+ * of bspec.
*
* Entries not part of the following tables are undefined as far as
- * userspace is concerned and shouldn't be relied upon. For the time
- * being they will be implicitly initialized to the strictest caching
- * configuration (uncached) to guarantee forwards compatibility with
- * userspace programs written against more recent kernels providing
- * additional MOCS entries.
+ * userspace is concerned and shouldn't be relied upon.
*
- * NOTE: These tables MUST start with being uncached and the length
- * MUST be less than 63 as the last two registers are reserved
- * by the hardware. These tables are part of the kernel ABI and
- * may only be updated incrementally by adding entries at the
- * end.
+ * The last two entries are reserved by the hardware. For ICL+ they
+ * should be initialized according to bspec and never used, for older
+ * platforms they should never be written to.
+ *
+ * NOTE: These tables are part of bspec and defined as part of hardware
+ * interface for ICL+. For older platforms, they are part of kernel
+ * ABI. It is expected that existing entries will remain constant
+ * and the tables will only be updated by adding new entries.
*/
#define GEN9_MOCS_TABLE \
@@ -144,6 +146,222 @@ static const struct drm_i915_mocs_entry
broxton_mocs_table[] = {
},
};
+#define GEN11_MOCS_TABLE \
+ [0] = { \
+ /* Base - Uncached (Deprecated) */ \
+ .control_value = LE_CACHEABILITY(LE_UC) | \
+ LE_TGT_CACHE(LE_TC_LLC) | \
+ LE_LRUM(0) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) | \
+ LE_PFM(0) | LE_SCF(0) | LE_CoS(0) | LE_SSE(0), \
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC), \
+ }, \
+ [1] = { \
+ /* Base - L3 + LeCC:PAT (Deprecated) */ \
+ .control_value = LE_CACHEABILITY(LE_PAGETABLE) | \
+ LE_TGT_CACHE(LE_TC_LLC) | \
+ LE_LRUM(0) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) | \
+ LE_PFM(0) | LE_SCF(0) | LE_CoS(0) | LE_SSE(0), \
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB), \
+ }, \
+ [2] = { \
+ /* Base - L3 + LLC */ \
+ .control_value = LE_CACHEABILITY(LE_WB) | \
+ LE_TGT_CACHE(LE_TC_LLC) | \
+ LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) | \
+ LE_PFM(0) | LE_SCF(0) | LE_CoS(0) | LE_SSE(0), \
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB), \
+ }, \
+ [3] = { \
+ /* Base - Uncached */ \
+ .control_value = LE_CACHEABILITY(LE_UC) | \
+ LE_TGT_CACHE(LE
[Intel-gfx] ✗ Fi.CI.IGT: failure for mm, drm/i915: Mark pinned shmemfs pages as unevictable (rev3)
== Series Details == Series: mm, drm/i915: Mark pinned shmemfs pages as unevictable (rev3) URL : https://patchwork.freedesktop.org/series/25337/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_5085_full -> Patchwork_10724_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_10724_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10724_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_10724_full: === IGT changes === Possible regressions igt@drm_import_export@import-close-race-flink: shard-skl: NOTRUN -> TIMEOUT Warnings igt@pm_rc6_residency@rc6-accuracy: shard-snb: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_10724_full that come from known issues: === IGT changes === Issues hit igt@drv_suspend@sysfs-reader: shard-skl: NOTRUN -> INCOMPLETE (fdo#107773, fdo#104108) +1 igt@gem_exec_schedule@pi-ringfull-bsd: shard-skl: NOTRUN -> FAIL (fdo#103158) +2 igt@gem_fence_thrash@bo-copy: shard-apl: PASS -> INCOMPLETE (fdo#103927) igt@kms_busy@extended-modeset-hang-newfb-render-a: shard-skl: NOTRUN -> DMESG-WARN (fdo#107956) +5 igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: shard-kbl: PASS -> DMESG-WARN (fdo#107956) igt@kms_busy@extended-pageflip-hang-newfb-render-a: shard-apl: PASS -> DMESG-WARN (fdo#107956) igt@kms_ccs@pipe-b-crc-sprite-planes-basic: shard-glk: PASS -> FAIL (fdo#108145) igt@kms_cursor_crc@cursor-128x42-onscreen: shard-skl: NOTRUN -> FAIL (fdo#103232) igt@kms_cursor_crc@cursor-256x256-dpms: shard-glk: PASS -> FAIL (fdo#103232) +1 igt@kms_cursor_crc@cursor-64x64-sliding: shard-apl: PASS -> FAIL (fdo#103232) igt@kms_cursor_crc@cursor-64x64-suspend: shard-apl: PASS -> FAIL (fdo#103191, fdo#103232) igt@kms_cursor_legacy@cursorb-vs-flipb-toggle: shard-glk: PASS -> DMESG-WARN (fdo#105763, fdo#106538) igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-untiled: shard-skl: PASS -> FAIL (fdo#103184) igt@kms_fbcon_fbt@psr: shard-skl: NOTRUN -> FAIL (fdo#107882) igt@kms_flip_tiling@flip-y-tiled: shard-skl: NOTRUN -> FAIL (fdo#108303) igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen: shard-apl: PASS -> FAIL (fdo#103167) +2 igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-move: shard-glk: PASS -> FAIL (fdo#103167) +1 igt@kms_frontbuffer_tracking@fbc-stridechange: shard-skl: NOTRUN -> FAIL (fdo#105683) igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-mmap-wc: shard-skl: PASS -> FAIL (fdo#105682, fdo#103167) igt@kms_frontbuffer_tracking@psr-rgb101010-draw-pwrite: shard-skl: PASS -> FAIL (fdo#103167) +2 igt@kms_pipe_crc_basic@read-crc-pipe-a: shard-skl: PASS -> FAIL (fdo#107362) igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb: shard-skl: NOTRUN -> FAIL (fdo#108145) +8 igt@kms_plane_alpha_blend@pipe-b-alpha-basic: shard-skl: NOTRUN -> FAIL (fdo#108145, fdo#107815) +1 igt@kms_plane_multiple@atomic-pipe-a-tiling-y: shard-glk: PASS -> FAIL (fdo#103166) +1 shard-apl: PASS -> FAIL (fdo#103166) igt@kms_properties@connector-properties-atomic: shard-skl: NOTRUN -> FAIL (fdo#108642) igt@kms_setmode@basic: shard-skl: NOTRUN -> FAIL (fdo#99912) igt@kms_sysfs_edid_timing: shard-skl: NOTRUN -> FAIL (fdo#100047) Possible fixes igt@debugfs_test@read_all_entries_display_off: shard-skl: INCOMPLETE (fdo#104108) -> PASS igt@kms_cursor_crc@cursor-128x42-onscreen: shard-glk: FAIL (fdo#103232) -> PASS +1 shard-apl: FAIL (fdo#103232) -> PASS +2 igt@kms_cursor_crc@cursor-64x64-offscreen: shard-skl: FAIL (fdo#103232) -> PASS +1 igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-ytiled: shard-skl: FAIL (fdo#103184) -> PASS igt@kms_draw_crc@draw-method-xrgb-pwrite-untiled: shard-skl: FAIL (fdo#108472) -> PASS igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-mmap-cpu: shard-skl: FAIL (fdo#105682) -> PASS igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-cpu: shard-apl: FAIL (fdo#103167) -> PASS igt@kms_fron
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/icl: Fix suspend/resume for TypeC HDMI
On Mon, Nov 05, 2018 at 03:42:07PM +0200, Imre Deak wrote: > On Sat, Nov 03, 2018 at 12:45:01AM +, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915/icl: Fix suspend/resume for TypeC HDMI > > URL : https://patchwork.freedesktop.org/series/51976/ > > State : failure > > The failures are unrelated since all those platforms are without a TypeC > port and the changes have an effect only on TypeC ports. More below. Thanks for the review and testing, pushed both patches to -dinq. > > > > > == Summary == > > > > = CI Bug Log - changes from CI_DRM_5081_full -> Patchwork_10716_full = > > > > == Summary - FAILURE == > > > > Serious unknown changes coming with Patchwork_10716_full absolutely need > > to be > > verified manually. > > > > If you think the reported changes have nothing to do with the changes > > introduced in Patchwork_10716_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_10716_full: > > > > === IGT changes === > > > > Possible regressions > > > > igt@kms_cursor_crc@cursor-64x21-offscreen: > > shard-skl: PASS -> INCOMPLETE > > Haven't found anything in the logs, I added a comment about this failure to > https://bugs.freedesktop.org/show_bug.cgi?id=104108 > > > Warnings > > > > igt@kms_cursor_legacy@flip-vs-cursor-crc-legacy: > > shard-snb: SKIP -> PASS +3 > > Not sure what this is about, it's a 'SKIP->PASS' and I haven't found any > errors/warnings in the log. > > > > > igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-plflip-blt: > > shard-snb: PASS -> SKIP +1 > > VGA output can't be detected after a system suspend/resume cycle. I > opened a new bug for this: > https://bugs.freedesktop.org/show_bug.cgi?id=108663 > > > > > igt@perf_pmu@rc6: > > shard-kbl: PASS -> SKIP > > GPU doesn't enter RC6, opened a new bug for it: > https://bugs.freedesktop.org/show_bug.cgi?id=108664 > > > > > > > == Known issues == > > > > Here are the changes found in Patchwork_10716_full that come from known > > issues: > > > > === IGT changes === > > > > Issues hit > > > > igt@gem_userptr_blits@readonly-unsync: > > shard-skl: NOTRUN -> INCOMPLETE (fdo#108074) > > > > igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: > > shard-skl: NOTRUN -> DMESG-WARN (fdo#107956) > > > > igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c: > > shard-glk: PASS -> DMESG-WARN (fdo#107956) > > > > igt@kms_chv_cursor_fail@pipe-b-128x128-bottom-edge: > > shard-skl: PASS -> FAIL (fdo#104671) > > > > igt@kms_chv_cursor_fail@pipe-b-64x64-bottom-edge: > > shard-kbl: PASS -> DMESG-WARN (fdo#105345) > > > > igt@kms_color@pipe-c-legacy-gamma: > > shard-apl: PASS -> FAIL (fdo#104782) > > > > igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic: > > shard-glk: PASS -> FAIL (fdo#106509, fdo#105454) > > > > igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt: > > shard-skl: NOTRUN -> FAIL (fdo#103167) +1 > > > > igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff: > > shard-apl: PASS -> FAIL (fdo#103167) > > > > igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence: > > shard-skl: PASS -> FAIL (fdo#107362, fdo#103191) > > > > igt@kms_plane@plane-position-covered-pipe-c-planes: > > shard-apl: PASS -> FAIL (fdo#103166) +1 > > > > igt@kms_setmode@basic: > > shard-kbl: PASS -> FAIL (fdo#99912) > > > > igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend: > > shard-skl: PASS -> INCOMPLETE (fdo#107773, fdo#104108) > > > > > > Possible fixes > > > > igt@kms_busy@extended-modeset-hang-newfb-render-b: > > shard-skl: DMESG-WARN (fdo#107956) -> PASS > > > > igt@kms_cursor_crc@cursor-128x128-suspend: > > shard-skl: INCOMPLETE (fdo#104108) -> PASS > > > > igt@kms_cursor_crc@cursor-128x42-random: > > shard-skl: FAIL (fdo#103232) -> PASS > > > > igt@kms_cursor_crc@cursor-256x256-sliding: > > shard-glk: FAIL (fdo#103232) -> PASS +1 > > > > igt@kms_cursor_crc@cursor-256x85-random: > > shard-apl: FAIL (fdo#103232) -> PASS +1 > > > > igt@kms_flip@flip-vs-expired-vblank: > > shard-skl: FAIL (fdo#105363) -> PASS > > > > igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt: > > shard-glk: FAIL (fdo#103167) -> PASS > > > > igt@kms_plane@plane-position-covered-pipe-b-planes: > > s
Re: [Intel-gfx] [PATCH 1/3] drm/atomic: Use explicit old crtc state in drm_atomic_add_affected_planes()
On Mon, Nov 05, 2018 at 10:26:01AM +0100, Daniel Vetter wrote:
> On Thu, Nov 01, 2018 at 08:46:44PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Replace 'crtc->state' with the explicit old crtc state.
> >
> > Actually it shouldn't matter whether we use the old or the new
> > crtc state here since any plane that has been removed from the
> > crtc since the crtc state was duplicated will have been added
> > to the atomic state already. That is, you can't call
> > drm_atomic_set_crtc_for_plane() without having the new
> > plane state already in hand.
> >
> > Signed-off-by: Ville Syrjälä
>
> I think this will break amdgpu_notify_freesync because that doesn't grab
> the crtc state first. Which worked with the old stuff, because adding a
> connector or plane will also add it's crtc. But with the new logic we'll
> just oops I think.
drm_atomic_add_affected_connectors() will add the crtc to the
state. So looks like it shouldn't oops.
>
> Otoh, it's dead code, so what exactly are amd people doing again :-)
Heh. Thanks for the review.
>
> Adding Harry so he's aware, but patch here looks good.
>
> Reviewed-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_atomic.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 3dbfbddae7e6..064c48075917 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -927,6 +927,8 @@ int
> > drm_atomic_add_affected_planes(struct drm_atomic_state *state,
> >struct drm_crtc *crtc)
> > {
> > + const struct drm_crtc_state *old_crtc_state =
> > + drm_atomic_get_old_crtc_state(state, crtc);
> > struct drm_plane *plane;
> >
> > WARN_ON(!drm_atomic_get_new_crtc_state(state, crtc));
> > @@ -934,7 +936,7 @@ drm_atomic_add_affected_planes(struct drm_atomic_state
> > *state,
> > DRM_DEBUG_ATOMIC("Adding all current planes for [CRTC:%d:%s] to %p\n",
> > crtc->base.id, crtc->name, state);
> >
> > - drm_for_each_plane_mask(plane, state->dev, crtc->state->plane_mask) {
> > + drm_for_each_plane_mask(plane, state->dev, old_crtc_state->plane_mask) {
> > struct drm_plane_state *plane_state =
> > drm_atomic_get_plane_state(state, plane);
> >
> > --
> > 2.18.1
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Ville Syrjälä
Intel
___
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 drm/i915/icl: Fix suspend/resume for TypeC HDMI
On 05/11/2018 15:42, Imre Deak wrote: > On Sat, Nov 03, 2018 at 12:45:01AM +, Patchwork wrote: >> == Series Details == >> >> Series: drm/i915/icl: Fix suspend/resume for TypeC HDMI >> URL : https://patchwork.freedesktop.org/series/51976/ >> State : failure > > The failures are unrelated since all those platforms are without a TypeC > port and the changes have an effect only on TypeC ports. More below. > >> >> == Summary == >> >> = CI Bug Log - changes from CI_DRM_5081_full -> Patchwork_10716_full = >> >> == Summary - FAILURE == >> >> Serious unknown changes coming with Patchwork_10716_full absolutely need >> to be >> verified manually. >> >> If you think the reported changes have nothing to do with the changes >> introduced in Patchwork_10716_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_10716_full: >> >> === IGT changes === >> >> Possible regressions >> >> igt@kms_cursor_crc@cursor-64x21-offscreen: >> shard-skl: PASS -> INCOMPLETE > > Haven't found anything in the logs, I added a comment about this failure to > https://bugs.freedesktop.org/show_bug.cgi?id=104108 Thanks, I changed the filing in the cibuglog. Re-reported and it is a success now :) > >> Warnings >> >> igt@kms_cursor_legacy@flip-vs-cursor-crc-legacy: >> shard-snb: SKIP -> PASS +3 > > Not sure what this is about, it's a 'SKIP->PASS' and I haven't found any > errors/warnings in the log. Ignore these, we are not filing bugs for these yet. > >> >> igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-plflip-blt: >> shard-snb: PASS -> SKIP +1 > > VGA output can't be detected after a system suspend/resume cycle. I > opened a new bug for this: > https://bugs.freedesktop.org/show_bug.cgi?id=108663 > >> >> igt@perf_pmu@rc6: >> shard-kbl: PASS -> SKIP > > GPU doesn't enter RC6, opened a new bug for it: > https://bugs.freedesktop.org/show_bug.cgi?id=108664 > >> >> >> == Known issues == >> >> Here are the changes found in Patchwork_10716_full that come from known >> issues: >> >> === IGT changes === >> >> Issues hit >> >> igt@gem_userptr_blits@readonly-unsync: >> shard-skl: NOTRUN -> INCOMPLETE (fdo#108074) >> >> igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: >> shard-skl: NOTRUN -> DMESG-WARN (fdo#107956) >> >> igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c: >> shard-glk: PASS -> DMESG-WARN (fdo#107956) >> >> igt@kms_chv_cursor_fail@pipe-b-128x128-bottom-edge: >> shard-skl: PASS -> FAIL (fdo#104671) >> >> igt@kms_chv_cursor_fail@pipe-b-64x64-bottom-edge: >> shard-kbl: PASS -> DMESG-WARN (fdo#105345) >> >> igt@kms_color@pipe-c-legacy-gamma: >> shard-apl: PASS -> FAIL (fdo#104782) >> >> igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic: >> shard-glk: PASS -> FAIL (fdo#106509, fdo#105454) >> >> igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt: >> shard-skl: NOTRUN -> FAIL (fdo#103167) +1 >> >> igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff: >> shard-apl: PASS -> FAIL (fdo#103167) >> >> igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence: >> shard-skl: PASS -> FAIL (fdo#107362, fdo#103191) >> >> igt@kms_plane@plane-position-covered-pipe-c-planes: >> shard-apl: PASS -> FAIL (fdo#103166) +1 >> >> igt@kms_setmode@basic: >> shard-kbl: PASS -> FAIL (fdo#99912) >> >> igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend: >> shard-skl: PASS -> INCOMPLETE (fdo#107773, fdo#104108) >> >> >> Possible fixes >> >> igt@kms_busy@extended-modeset-hang-newfb-render-b: >> shard-skl: DMESG-WARN (fdo#107956) -> PASS >> >> igt@kms_cursor_crc@cursor-128x128-suspend: >> shard-skl: INCOMPLETE (fdo#104108) -> PASS >> >> igt@kms_cursor_crc@cursor-128x42-random: >> shard-skl: FAIL (fdo#103232) -> PASS >> >> igt@kms_cursor_crc@cursor-256x256-sliding: >> shard-glk: FAIL (fdo#103232) -> PASS +1 >> >> igt@kms_cursor_crc@cursor-256x85-random: >> shard-apl: FAIL (fdo#103232) -> PASS +1 >> >> igt@kms_flip@flip-vs-expired-vblank: >> shard-skl: FAIL (fdo#105363) -> PASS >> >> igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt: >> shard-glk: FAIL (fdo#103167) -> PASS >> >> igt@kms_plane@plane-position-covered-pipe-b-planes: >> shard-glk: FAIL (fdo#103166) -> PASS +2 >> >> igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: >>
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: Fix suspend/resume for TypeC HDMI
== Series Details == Series: drm/i915/icl: Fix suspend/resume for TypeC HDMI URL : https://patchwork.freedesktop.org/series/51976/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5081_full -> Patchwork_10716_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_10716_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10716_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_10716_full: === IGT changes === Warnings igt@kms_cursor_legacy@flip-vs-cursor-crc-legacy: shard-snb: SKIP -> PASS +3 igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-plflip-blt: shard-snb: PASS -> SKIP +1 igt@perf_pmu@rc6: shard-kbl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_10716_full that come from known issues: === IGT changes === Issues hit igt@gem_userptr_blits@readonly-unsync: shard-skl: NOTRUN -> INCOMPLETE (fdo#108074) igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: shard-skl: NOTRUN -> DMESG-WARN (fdo#107956) igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c: shard-glk: PASS -> DMESG-WARN (fdo#107956) igt@kms_chv_cursor_fail@pipe-b-128x128-bottom-edge: shard-skl: PASS -> FAIL (fdo#104671) igt@kms_chv_cursor_fail@pipe-b-64x64-bottom-edge: shard-kbl: PASS -> DMESG-WARN (fdo#105345) igt@kms_color@pipe-c-legacy-gamma: shard-apl: PASS -> FAIL (fdo#104782) igt@kms_cursor_crc@cursor-64x21-offscreen: shard-skl: PASS -> INCOMPLETE (fdo#104108) igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic: shard-glk: PASS -> FAIL (fdo#106509, fdo#105454) igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt: shard-skl: NOTRUN -> FAIL (fdo#103167) +1 igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff: shard-apl: PASS -> FAIL (fdo#103167) igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence: shard-skl: PASS -> FAIL (fdo#107362, fdo#103191) igt@kms_plane@plane-position-covered-pipe-c-planes: shard-apl: PASS -> FAIL (fdo#103166) +1 igt@kms_setmode@basic: shard-kbl: PASS -> FAIL (fdo#99912) igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend: shard-skl: PASS -> INCOMPLETE (fdo#104108, fdo#107773) Possible fixes igt@kms_busy@extended-modeset-hang-newfb-render-b: shard-skl: DMESG-WARN (fdo#107956) -> PASS igt@kms_cursor_crc@cursor-128x128-suspend: shard-skl: INCOMPLETE (fdo#104108) -> PASS igt@kms_cursor_crc@cursor-128x42-random: shard-skl: FAIL (fdo#103232) -> PASS igt@kms_cursor_crc@cursor-256x256-sliding: shard-glk: FAIL (fdo#103232) -> PASS +1 igt@kms_cursor_crc@cursor-256x85-random: shard-apl: FAIL (fdo#103232) -> PASS +1 igt@kms_flip@flip-vs-expired-vblank: shard-skl: FAIL (fdo#105363) -> PASS igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt: shard-glk: FAIL (fdo#103167) -> PASS igt@kms_plane@plane-position-covered-pipe-b-planes: shard-glk: FAIL (fdo#103166) -> PASS +2 igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: shard-skl: FAIL (fdo#107815) -> PASS igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS igt@pm_rpm@legacy-planes-dpms: shard-skl: INCOMPLETE (fdo#107807, fdo#105959) -> PASS fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103232 https://bugs.freedesktop.org/show_bug.cgi?id=103232 fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108 fdo#104671 https://bugs.freedesktop.org/show_bug.cgi?id=104671 fdo#104782 https://bugs.freedesktop.org/show_bug.cgi?id=104782 fdo#105345 https://bugs.freedesktop.org/show_bug.cgi?id=105345 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#105959 https://bugs.freedesktop.org/show_bug.cgi?id=105959 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773 fdo#107807 https://bugs.freedesktop.org/show_bug.cgi?id=107807 fdo#107815 https://bugs.freedesktop.org/show_bug.cgi?id=10
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/2] drm/i915/skl: Rework MOCS tables to keep common part in a define
== Series Details == Series: series starting with [v4,1/2] drm/i915/skl: Rework MOCS tables to keep common part in a define URL : https://patchwork.freedesktop.org/series/52027/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5085 -> Patchwork_10725 = == Summary - WARNING == Minor unknown changes coming with Patchwork_10725 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10725, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/52027/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_10725: === IGT changes === Warnings igt@drv_selftest@live_guc: fi-skl-iommu: PASS -> SKIP +1 == Known issues == Here are the changes found in Patchwork_10725 that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_hangcheck: fi-skl-iommu: PASS -> INCOMPLETE (fdo#108602) igt@gem_exec_suspend@basic-s3: fi-kbl-soraka: NOTRUN -> INCOMPLETE (fdo#107556, fdo#107774, fdo#107859) igt@kms_chamelium@dp-edid-read: fi-kbl-7500u: PASS -> WARN (fdo#102672) igt@kms_frontbuffer_tracking@basic: fi-byt-clapper: PASS -> FAIL (fdo#103167) igt@kms_pipe_crc_basic@hang-read-crc-pipe-a: fi-skl-guc: PASS -> FAIL (fdo#103191, fdo#107362) igt@kms_pipe_crc_basic@read-crc-pipe-a: fi-byt-clapper: PASS -> FAIL (fdo#107362) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-blb-e6850: PASS -> INCOMPLETE (fdo#107718) Possible fixes igt@gem_cpu_reloc@basic: fi-skl-6700hq: INCOMPLETE (fdo#108011) -> PASS igt@gem_exec_suspend@basic-s3: fi-glk-dsi: FAIL (fdo#103375) -> PASS igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: DMESG-WARN (fdo#102614) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-byt-clapper: FAIL (fdo#103191, fdo#107362) -> PASS fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107556 https://bugs.freedesktop.org/show_bug.cgi?id=107556 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#107774 https://bugs.freedesktop.org/show_bug.cgi?id=107774 fdo#107859 https://bugs.freedesktop.org/show_bug.cgi?id=107859 fdo#108011 https://bugs.freedesktop.org/show_bug.cgi?id=108011 fdo#108602 https://bugs.freedesktop.org/show_bug.cgi?id=108602 == Participating hosts (45 -> 45) == Additional (7): fi-kbl-soraka fi-bwr-2160 fi-ilk-650 fi-snb-2520m fi-gdg-551 fi-pnv-d510 fi-kbl-7560u Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-kbl-8809g fi-icl-u == Build changes == * Linux: CI_DRM_5085 -> Patchwork_10725 CI_DRM_5085: 6ae61ee5db4af12c0b21bf39e0400ccf024187c4 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4706: 5421c73a7db3cfaa85ab24325fe6e898cbb27fb3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10725: 11eb04f01462fe2fb31600ef3d3fd1df261fd182 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 11eb04f01462 drm/i915/icl: Define MOCS table for Icelake 0e81c0cb8af6 drm/i915/skl: Rework MOCS tables to keep common part in a define == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10725/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/atomic: Use explicit old crtc state in drm_atomic_add_affected_planes()
On 2018-11-05 9:04 a.m., Ville Syrjälä wrote:
> On Mon, Nov 05, 2018 at 10:26:01AM +0100, Daniel Vetter wrote:
>> On Thu, Nov 01, 2018 at 08:46:44PM +0200, Ville Syrjala wrote:
>>> From: Ville Syrjälä
>>>
>>> Replace 'crtc->state' with the explicit old crtc state.
>>>
>>> Actually it shouldn't matter whether we use the old or the new
>>> crtc state here since any plane that has been removed from the
>>> crtc since the crtc state was duplicated will have been added
>>> to the atomic state already. That is, you can't call
>>> drm_atomic_set_crtc_for_plane() without having the new
>>> plane state already in hand.
>>>
>>> Signed-off-by: Ville Syrjälä
>>
>> I think this will break amdgpu_notify_freesync because that doesn't grab
>> the crtc state first. Which worked with the old stuff, because adding a
>> connector or plane will also add it's crtc. But with the new logic we'll
>> just oops I think.
>
> drm_atomic_add_affected_connectors() will add the crtc to the
> state. So looks like it shouldn't oops.
>
Thanks. I thought I was too tired on a Monday morning to spot the oops.
This code should be on the way out with the variable refresh patches from Nick.
It's currently only used by our DKMS driver.
Looks good to me.
Acked-by: Harry Wentland
Harry
>>
>> Otoh, it's dead code, so what exactly are amd people doing again :-)
>
> Heh. Thanks for the review.
>
>>
>> Adding Harry so he's aware, but patch here looks good.
>>
>> Reviewed-by: Daniel Vetter
>>> ---
>>> drivers/gpu/drm/drm_atomic.c | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>>> index 3dbfbddae7e6..064c48075917 100644
>>> --- a/drivers/gpu/drm/drm_atomic.c
>>> +++ b/drivers/gpu/drm/drm_atomic.c
>>> @@ -927,6 +927,8 @@ int
>>> drm_atomic_add_affected_planes(struct drm_atomic_state *state,
>>>struct drm_crtc *crtc)
>>> {
>>> + const struct drm_crtc_state *old_crtc_state =
>>> + drm_atomic_get_old_crtc_state(state, crtc);
>>> struct drm_plane *plane;
>>>
>>> WARN_ON(!drm_atomic_get_new_crtc_state(state, crtc));
>>> @@ -934,7 +936,7 @@ drm_atomic_add_affected_planes(struct drm_atomic_state
>>> *state,
>>> DRM_DEBUG_ATOMIC("Adding all current planes for [CRTC:%d:%s] to %p\n",
>>> crtc->base.id, crtc->name, state);
>>>
>>> - drm_for_each_plane_mask(plane, state->dev, crtc->state->plane_mask) {
>>> + drm_for_each_plane_mask(plane, state->dev, old_crtc_state->plane_mask) {
>>> struct drm_plane_state *plane_state =
>>> drm_atomic_get_plane_state(state, plane);
>>>
>>> --
>>> 2.18.1
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-de...@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] mm, drm/i915: mark pinned shmemfs pages as unevictable
On Mon, Nov 5, 2018 at 9:02 PM Michal Hocko wrote:
>
> On Mon 05-11-18 19:13:48, Kuo-Hsin Yang wrote:
> > The i915 driver uses shmemfs to allocate backing storage for gem
> > objects. These shmemfs pages can be pinned (increased ref count) by
> > shmem_read_mapping_page_gfp(). When a lot of pages are pinned, vmscan
> > wastes a lot of time scanning these pinned pages. In some extreme case,
> > all pages in the inactive anon lru are pinned, and only the inactive
> > anon lru is scanned due to inactive_ratio, the system cannot swap and
> > invokes the oom-killer. Mark these pinned pages as unevictable to speed
> > up vmscan.
> >
> > Export pagevec API check_move_unevictable_pages().
>
> Thanks for reworking the patch. This looks much more to my taste. At
> least the mm part. I haven't really looked at the the drm part.
>
> Just a nit below
>
> > This patch was inspired by Chris Wilson's change [1].
> >
> > [1]: https://patchwork.kernel.org/patch/9768741/
>
> I would recommend using msg-id based url.
I didn't find a msg-id based url for the [1] patch. This patch is sent
to intel-gfx@lists.freedesktop.org and linux...@kvack.org, but not to
linux-ker...@vger.kernel.org .
>
> > Cc: Chris Wilson
> > Cc: Michal Hocko
> > Cc: Joonas Lahtinen
> > Cc: Peter Zijlstra
> > Cc: Andrew Morton
> > Cc: Dave Hansen
> > Signed-off-by: Kuo-Hsin Yang
>
> other than that
> Acked-by: Michal Hocko
>
> [...]
>
> > @@ -4184,15 +4185,13 @@ int page_evictable(struct page *page)
> >
> > #ifdef CONFIG_SHMEM
> > /**
> > - * check_move_unevictable_pages - check pages for evictability and move to
> > appropriate zone lru list
> > - * @pages: array of pages to check
> > - * @nr_pages:number of pages to check
> > + * check_move_unevictable_pages - move evictable pages to appropriate
> > evictable
> > + * lru lists
>
> I am not sure this is an improvement. I would just keep the original
> wording. It is not great either but the explicit note about check for
> evictability sounds like a better fit to me.
OK, will keep the original wording.
>
> > + * @pvec: pagevec with pages to check
> > *
> > - * Checks pages for evictability and moves them to the appropriate lru
> > list.
> > - *
> > - * This function is only used for SysV IPC SHM_UNLOCK.
> > + * This function is only used to move shmem pages.
>
> I do not really see anything that would be shmem specific here. We can
> use this function for any LRU pages unless I am missing something
> obscure. I would just drop the last sentence.
OK, this function should not be specific to shmem pages.
Is it OK to remove the #ifdef SHMEM surrounding check_move_unevictable_pages?
>
> A note that this function should be only used for LRU pages would be
> nice.
>
> > */
> > -void check_move_unevictable_pages(struct page **pages, int nr_pages)
> > +void check_move_unevictable_pages(struct pagevec *pvec)
> > {
> > struct lruvec *lruvec;
> > struct pglist_data *pgdat = NULL;
> > @@ -4200,8 +4199,8 @@ void check_move_unevictable_pages(struct page
> > **pages, int nr_pages)
> > int pgrescued = 0;
> > int i;
> >
> > - for (i = 0; i < nr_pages; i++) {
> > - struct page *page = pages[i];
> > + for (i = 0; i < pvec->nr; i++) {
> > + struct page *page = pvec->pages[i];
> > struct pglist_data *pagepgdat = page_pgdat(page);
> >
> > pgscanned++;
> > @@ -4233,4 +4232,5 @@ void check_move_unevictable_pages(struct page
> > **pages, int nr_pages)
> > spin_unlock_irq(&pgdat->lru_lock);
> > }
> > }
> > +EXPORT_SYMBOL(check_move_unevictable_pages);
> > #endif /* CONFIG_SHMEM */
> > --
> > 2.19.1.930.g4563a0d9d0-goog
> >
>
> --
> Michal Hocko
> SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/atomic: Use explicit old/new state in drm_atomic_plane_check()
On Mon, Nov 05, 2018 at 10:33:47AM +0100, Daniel Vetter wrote:
> On Thu, Nov 01, 2018 at 08:46:46PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Convert drm_atomic_plane_check() over to using explicit old vs. new
> > plane states. Avoids the confusion of "what does plane->state mean
> > again?".
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_atomic.c | 90 ++--
> > 1 file changed, 46 insertions(+), 44 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index dde696181efe..46f8d798efaf 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -492,108 +492,109 @@ drm_atomic_get_plane_state(struct drm_atomic_state
> > *state,
> > EXPORT_SYMBOL(drm_atomic_get_plane_state);
> >
> > static bool
> > -plane_switching_crtc(struct drm_atomic_state *state,
> > -struct drm_plane *plane,
> > -struct drm_plane_state *plane_state)
> > +plane_switching_crtc(const struct drm_plane_state *old_plane_state,
> > +const struct drm_plane_state *new_plane_state)
> > {
> > - if (!plane->state->crtc || !plane_state->crtc)
> > - return false;
> > -
> > - if (plane->state->crtc == plane_state->crtc)
> > - return false;
> > -
> > /* This could be refined, but currently there's no helper or driver code
> > * to implement direct switching of active planes nor userspace to take
> > * advantage of more direct plane switching without the intermediate
> > * full OFF state.
> > */
> > - return true;
> > + return old_plane_state->crtc && new_plane_state->crtc &&
> > + old_plane_state->crtc != new_plane_state->crtc;
>
> I think the old layout was clearer, instead of an obscure monster
> condition.
I guess it's a matter of taste. I think my new style is much more
succinct and reads more natural:
"if old exists and new exists and old is not new we're swithing crtcs"
vs.
"if old doesn't exist or new doesn't exist we're not switching
crtcs, otherwise if old is new we're not switching crtcs, otherwise
we're switching crtcs".
But meh. So I'll change it back.
>
> With the old layout here this is:
>
> Reviewed-by: Daniel Vetter
> > }
> >
> > /**
> > * drm_atomic_plane_check - check plane state
> > - * @plane: plane to check
> > - * @state: plane state to check
> > + * @old_plane_state: old plane state to check
> > + * @new_plane_state: new plane state to check
> > *
> > * Provides core sanity checks for plane state.
> > *
> > * RETURNS:
> > * Zero on success, error code on failure
> > */
> > -static int drm_atomic_plane_check(struct drm_plane *plane,
> > - struct drm_plane_state *state)
> > +static int drm_atomic_plane_check(const struct drm_plane_state
> > *old_plane_state,
> > + const struct drm_plane_state *new_plane_state)
> > {
> > + struct drm_plane *plane = new_plane_state->plane;
> > + struct drm_crtc *crtc = new_plane_state->crtc;
> > + const struct drm_framebuffer *fb = new_plane_state->fb;
> > unsigned int fb_width, fb_height;
> > int ret;
> >
> > /* either *both* CRTC and FB must be set, or neither */
> > - if (state->crtc && !state->fb) {
> > + if (crtc && !fb) {
> > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] CRTC set but no FB\n",
> > plane->base.id, plane->name);
> > return -EINVAL;
> > - } else if (state->fb && !state->crtc) {
> > + } else if (fb && !crtc) {
> > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] FB set but no CRTC\n",
> > plane->base.id, plane->name);
> > return -EINVAL;
> > }
> >
> > /* if disabled, we don't care about the rest of the state: */
> > - if (!state->crtc)
> > + if (!crtc)
> > return 0;
> >
> > /* Check whether this plane is usable on this CRTC */
> > - if (!(plane->possible_crtcs & drm_crtc_mask(state->crtc))) {
> > + if (!(plane->possible_crtcs & drm_crtc_mask(crtc))) {
> > DRM_DEBUG_ATOMIC("Invalid [CRTC:%d:%s] for [PLANE:%d:%s]\n",
> > -state->crtc->base.id, state->crtc->name,
> > +crtc->base.id, crtc->name,
> > plane->base.id, plane->name);
> > return -EINVAL;
> > }
> >
> > /* Check whether this plane supports the fb pixel format. */
> > - ret = drm_plane_check_pixel_format(plane, state->fb->format->format,
> > - state->fb->modifier);
> > + ret = drm_plane_check_pixel_format(plane, fb->format->format,
> > + fb->modifier);
> > if (ret) {
> > struct drm_format_name_buf format_name;
> > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] invalid pixel format %s,
> > modifier 0x%llx\n",
> > plane->base.
Re: [Intel-gfx] [PATCH 1/3] drm/atomic: Use explicit old crtc state in drm_atomic_add_affected_planes()
On Mon, Nov 05, 2018 at 02:30:50PM +, Wentland, Harry wrote:
>
>
> On 2018-11-05 9:04 a.m., Ville Syrjälä wrote:
> > On Mon, Nov 05, 2018 at 10:26:01AM +0100, Daniel Vetter wrote:
> >> On Thu, Nov 01, 2018 at 08:46:44PM +0200, Ville Syrjala wrote:
> >>> From: Ville Syrjälä
> >>>
> >>> Replace 'crtc->state' with the explicit old crtc state.
> >>>
> >>> Actually it shouldn't matter whether we use the old or the new
> >>> crtc state here since any plane that has been removed from the
> >>> crtc since the crtc state was duplicated will have been added
> >>> to the atomic state already. That is, you can't call
> >>> drm_atomic_set_crtc_for_plane() without having the new
> >>> plane state already in hand.
> >>>
> >>> Signed-off-by: Ville Syrjälä
> >>
> >> I think this will break amdgpu_notify_freesync because that doesn't grab
> >> the crtc state first. Which worked with the old stuff, because adding a
> >> connector or plane will also add it's crtc. But with the new logic we'll
> >> just oops I think.
> >
> > drm_atomic_add_affected_connectors() will add the crtc to the
> > state. So looks like it shouldn't oops.
> >
>
> Thanks. I thought I was too tired on a Monday morning to spot the oops.
>
> This code should be on the way out with the variable refresh patches from
> Nick. It's currently only used by our DKMS driver.
>
> Looks good to me.
>
> Acked-by: Harry Wentland
>
> Harry
>
> >>
> >> Otoh, it's dead code, so what exactly are amd people doing again :-)
> >
> > Heh. Thanks for the review.
> >
> >>
> >> Adding Harry so he's aware, but patch here looks good.
> >>
> >> Reviewed-by: Daniel Vetter
> >>> ---
> >>> drivers/gpu/drm/drm_atomic.c | 4 +++-
> >>> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >>> index 3dbfbddae7e6..064c48075917 100644
> >>> --- a/drivers/gpu/drm/drm_atomic.c
> >>> +++ b/drivers/gpu/drm/drm_atomic.c
> >>> @@ -927,6 +927,8 @@ int
> >>> drm_atomic_add_affected_planes(struct drm_atomic_state *state,
> >>> struct drm_crtc *crtc)
> >>> {
> >>> + const struct drm_crtc_state *old_crtc_state =
> >>> + drm_atomic_get_old_crtc_state(state, crtc);
> >>> struct drm_plane *plane;
> >>>
> >>> WARN_ON(!drm_atomic_get_new_crtc_state(state, crtc));
Oh, and if the crtc hadn't been added to the state this WARN would
have already triggered before my change.
> >>> @@ -934,7 +936,7 @@ drm_atomic_add_affected_planes(struct
> >>> drm_atomic_state *state,
> >>> DRM_DEBUG_ATOMIC("Adding all current planes for [CRTC:%d:%s] to %p\n",
> >>>crtc->base.id, crtc->name, state);
> >>>
> >>> - drm_for_each_plane_mask(plane, state->dev, crtc->state->plane_mask) {
> >>> + drm_for_each_plane_mask(plane, state->dev, old_crtc_state->plane_mask) {
> >>> struct drm_plane_state *plane_state =
> >>> drm_atomic_get_plane_state(state, plane);
> >>>
> >>> --
> >>> 2.18.1
> >>>
> >>> ___
> >>> dri-devel mailing list
> >>> dri-de...@lists.freedesktop.org
> >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >>
> >> --
> >> Daniel Vetter
> >> Software Engineer, Intel Corporation
> >> http://blog.ffwll.ch
> >
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/vgem: Fix typo in driver feature flags
Fix typo in struct field initializer.
Fixes: 3a6eb795641c ("drm/vgem: create a render node for vgem")
Cc: Emil Velikov
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/vgem/vgem_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index f1d1d9e2c82e..5930facd6d2d 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -432,7 +432,7 @@ static void vgem_release(struct drm_device *dev)
static struct drm_driver vgem_driver = {
.driver_features= DRIVER_GEM | DRIVER_PRIME |
- DRIVER_RENDER;
+ DRIVER_RENDER,
.release= vgem_release,
.open = vgem_open,
.postclose = vgem_postclose,
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/vgem: Fix typo in driver feature flags
== Series Details == Series: drm/vgem: Fix typo in driver feature flags URL : https://patchwork.freedesktop.org/series/52029/ State : failure == Summary == Applying: drm/vgem: Fix typo in driver feature flags Using index info to reconstruct a base tree... M drivers/gpu/drm/vgem/vgem_drv.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/vgem/vgem_drv.c CONFLICT (content): Merge conflict in drivers/gpu/drm/vgem/vgem_drv.c error: Failed to merge in the changes. Patch failed at 0001 drm/vgem: Fix typo in driver feature flags Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gen9_lp: Fix DMC DC counter debugfs output
On Thu, Nov 01, 2018 at 05:33:41AM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/gen9_lp: Fix DMC DC counter debugfs output > URL : https://patchwork.freedesktop.org/series/51837/ > State : success Thanks for the review, pushed to -dinq with the warn for missing case added. > > == Summary == > > = CI Bug Log - changes from CI_DRM_5062_full -> Patchwork_10678_full = > > == Summary - WARNING == > > Minor unknown changes coming with Patchwork_10678_full need to be verified > manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_10678_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_10678_full: > > === IGT changes === > > Warnings > > igt@pm_rc6_residency@rc6-accuracy: > shard-kbl: PASS -> SKIP > > > == Known issues == > > Here are the changes found in Patchwork_10678_full that come from known > issues: > > === IGT changes === > > Issues hit > > igt@drv_suspend@shrink: > shard-snb: PASS -> INCOMPLETE (fdo#105411, fdo#106886) > > igt@gem_exec_schedule@pi-ringfull-bsd: > shard-skl: NOTRUN -> FAIL (fdo#103158) > > igt@gem_exec_schedule@preempt-hang-bsd: > shard-apl: PASS -> INCOMPLETE (fdo#103927) > > igt@kms_atomic_transition@1x-modeset-transitions-fencing: > shard-skl: NOTRUN -> FAIL (fdo#108470, fdo#107815) > > igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: > shard-skl: NOTRUN -> DMESG-WARN (fdo#107956) > > igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a: > shard-snb: NOTRUN -> DMESG-WARN (fdo#107956) +1 > > igt@kms_ccs@pipe-a-crc-sprite-planes-basic: > shard-glk: PASS -> FAIL (fdo#108145) > > igt@kms_color@pipe-b-ctm-max: > shard-apl: PASS -> FAIL (fdo#108147) > > igt@kms_cursor_crc@cursor-128x128-onscreen: > shard-apl: PASS -> FAIL (fdo#103232) +1 > > igt@kms_cursor_crc@cursor-256x256-suspend: > shard-skl: NOTRUN -> FAIL (fdo#103232, fdo#103191) > > igt@kms_cursor_crc@cursor-64x64-sliding: > shard-glk: PASS -> FAIL (fdo#103232) +1 > > igt@kms_cursor_crc@cursor-64x64-suspend: > shard-glk: PASS -> INCOMPLETE (k.org#198133, fdo#103359) > > igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: > shard-glk: PASS -> FAIL (fdo#104873) > > igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: > shard-glk: NOTRUN -> FAIL (fdo#106509, fdo#105454) > > igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: > shard-glk: PASS -> FAIL (fdo#105363) > > igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt: > shard-apl: PASS -> FAIL (fdo#103167) +1 > > igt@kms_plane@pixel-format-pipe-b-planes: > shard-skl: NOTRUN -> DMESG-FAIL (fdo#106885, fdo#103166) > > igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb: > shard-apl: NOTRUN -> FAIL (fdo#108145) > > igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb: > shard-skl: NOTRUN -> FAIL (fdo#108145) +1 > > igt@kms_plane_alpha_blend@pipe-c-alpha-basic: > shard-glk: NOTRUN -> FAIL (fdo#108145) > > igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: > shard-skl: NOTRUN -> FAIL (fdo#107815) > > > Possible fixes > > igt@gem_ppgtt@blt-vs-render-ctx0: > shard-kbl: INCOMPLETE (fdo#106023, fdo#106887, fdo#103665) -> > PASS > > igt@kms_color@pipe-b-legacy-gamma: > shard-skl: FAIL (fdo#104782) -> PASS > > igt@kms_cursor_crc@cursor-256x85-random: > shard-glk: FAIL (fdo#103232) -> PASS > > igt@kms_cursor_crc@cursor-64x21-random: > shard-apl: FAIL (fdo#103232) -> PASS > > igt@kms_cursor_crc@cursor-64x64-suspend: > shard-snb: DMESG-WARN (fdo#102365) -> PASS > > igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu: > shard-apl: FAIL (fdo#103167) -> PASS > > igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-pwrite: > shard-glk: FAIL (fdo#103167) -> PASS > > igt@kms_plane_multiple@atomic-pipe-a-tiling-yf: > shard-apl: FAIL (fdo#103166) -> PASS +1 > > igt@kms_plane_multiple@atomic-pipe-c-tiling-x: > shard-glk: FAIL (fdo#103166) -> PASS > > igt@kms_setmode@basic: > shard-apl: FAIL (fdo#99912) -> PASS > shard-kbl: FAIL (fdo#99912) -> PASS > > igt@pm_rpm@modeset-lpsp-stress-no-wait: > shard-skl: INCOMPLETE (fdo#10780
Re: [Intel-gfx] [PATCH] drm/vgem: Fix typo in driver feature flags
On Mon, 5 Nov 2018 at 14:54, Imre Deak wrote:
>
> Fix typo in struct field initializer.
>
> Fixes: 3a6eb795641c ("drm/vgem: create a render node for vgem")
> Cc: Emil Velikov
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Imre Deak
Reviewed-by: Emil Velikov
-Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v4,1/2] drm/i915/skl: Rework MOCS tables to keep common part in a define
== Series Details == Series: series starting with [v4,1/2] drm/i915/skl: Rework MOCS tables to keep common part in a define URL : https://patchwork.freedesktop.org/series/52027/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5085_full -> Patchwork_10725_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_10725_full that come from known issues: === IGT changes === Issues hit igt@drv_suspend@shrink: shard-snb: PASS -> INCOMPLETE (fdo#105411, fdo#106886) shard-skl: PASS -> INCOMPLETE (fdo#106886) igt@gem_exec_schedule@pi-ringfull-render: shard-skl: NOTRUN -> FAIL (fdo#103158) igt@kms_busy@extended-modeset-hang-newfb-render-a: shard-skl: NOTRUN -> DMESG-WARN (fdo#107956) +3 igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: shard-kbl: PASS -> DMESG-WARN (fdo#107956) igt@kms_busy@extended-pageflip-hang-newfb-render-a: shard-apl: PASS -> DMESG-WARN (fdo#107956) igt@kms_chv_cursor_fail@pipe-c-256x256-top-edge: shard-skl: PASS -> FAIL (fdo#104671) igt@kms_cursor_crc@cursor-256x256-dpms: shard-glk: PASS -> FAIL (fdo#103232) +3 igt@kms_cursor_crc@cursor-256x256-random: shard-apl: PASS -> FAIL (fdo#103232) igt@kms_cursor_crc@cursor-64x64-suspend: shard-apl: PASS -> FAIL (fdo#103191, fdo#103232) igt@kms_cursor_legacy@cursorb-vs-flipb-toggle: shard-glk: PASS -> DMESG-WARN (fdo#105763, fdo#106538) igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-wc: shard-glk: PASS -> FAIL (fdo#103167) +1 igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu: shard-apl: PASS -> FAIL (fdo#103167) igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max: shard-skl: NOTRUN -> FAIL (fdo#108145) +4 igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: shard-skl: PASS -> FAIL (fdo#107815) igt@kms_plane_multiple@atomic-pipe-a-tiling-y: shard-glk: PASS -> FAIL (fdo#103166) +4 igt@kms_plane_multiple@atomic-pipe-c-tiling-yf: shard-apl: PASS -> FAIL (fdo#103166) +3 igt@kms_properties@connector-properties-atomic: shard-skl: NOTRUN -> FAIL (fdo#108642) igt@kms_setmode@basic: shard-skl: NOTRUN -> FAIL (fdo#99912) shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_cursor_crc@cursor-128x42-onscreen: shard-glk: FAIL (fdo#103232) -> PASS +1 igt@kms_cursor_crc@cursor-64x21-onscreen: shard-apl: FAIL (fdo#103232) -> PASS igt@kms_cursor_crc@cursor-64x64-offscreen: shard-skl: FAIL (fdo#103232) -> PASS +1 igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-ytiled: shard-skl: FAIL (fdo#103184) -> PASS igt@kms_draw_crc@draw-method-xrgb-pwrite-untiled: shard-skl: FAIL (fdo#108472) -> PASS igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-mmap-cpu: shard-skl: FAIL (fdo#105682) -> PASS igt@kms_frontbuffer_tracking@fbc-1p-rte: shard-glk: FAIL (fdo#105682, fdo#103167) -> PASS igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-onoff: shard-glk: FAIL (fdo#103167) -> PASS +5 igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-wc: shard-skl: FAIL (fdo#105682, fdo#103167) -> PASS igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: shard-skl: FAIL (fdo#108145, fdo#107815) -> PASS igt@kms_plane_multiple@atomic-pipe-a-tiling-x: shard-apl: FAIL (fdo#103166) -> PASS +3 shard-glk: FAIL (fdo#103166) -> PASS igt@perf@oa-exponents: shard-glk: FAIL (fdo#105483) -> PASS igt@prime_vgem@basic-fence-flip: shard-apl: FAIL (fdo#104008) -> PASS fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158 fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103184 https://bugs.freedesktop.org/show_bug.cgi?id=103184 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103232 https://bugs.freedesktop.org/show_bug.cgi?id=103232 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#104671 https://bugs.freedesktop.org/show_bug.cgi?id=104671 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105483 https://bugs.freedesktop.org/show_bug.cgi?id=105483 fdo#105682 https://bugs.freedesktop.org/show_bug.cgi?id=105682 fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763 fdo#106538 https://bugs.freedesktop.org/show_bug.cgi?id=106538 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#107815
Re: [Intel-gfx] [PATCH 2/3] drm/i915/icl: Enable 2nd DBuf slice only when needed
On Thu, Apr 26, 2018 at 07:55:16PM +0530, Mahesh Kumar wrote:
> ICL has two slices of DBuf, each slice of size 1024 blocks.
> We should not always enable slice-2. It should be enabled only if
> display total required BW is > 12GBps OR more than 1 pipes are enabled.
>
> Changes since V1:
> - typecast total_data_rate to u64 before multiplication to solve any
>possible overflow (Rodrigo)
> - fix where skl_wm_get_hw_state was memsetting ddb, resulting
>enabled_slices to become zero
> - Fix the logic of calculating ddb_size
> Changes since V2:
> - If no-crtc is part of commit required_slices will have value "0",
>don't try to disable DBuf slice.
> Changes since V3:
> - Create a generic helper to enable/disable slice
> - don't return early if total_data_rate is 0, it may be cursor only
>commit, or atomic modeset without any plane.
> Changes since V4:
> - Solve checkpatch warnings
> - use kernel types u8/u64 instead of uint8_t/uint64_t
> Changes since V5:
> - Rebase
>
> Signed-off-by: Mahesh Kumar
> Reviewed-by: Rodrigo Vivi
Hi, could you take a look at
https://bugs.freedesktop.org/show_bug.cgi?id=108654
?
Looks like we're calculating
dev_priv->wm.skl_hw.ddb.enabled_slices or
intel_state->wm_results.ddb.enabled_slices
incorrectly when outputs are disabled, leading to an invalid HW access
by a set_plane IOCTL while runtime suspended.
> ---
> drivers/gpu/drm/i915/intel_display.c| 10 +
> drivers/gpu/drm/i915/intel_drv.h| 6 +++
> drivers/gpu/drm/i915/intel_pm.c | 57 +++--
> drivers/gpu/drm/i915/intel_runtime_pm.c | 65
> ++---
> 4 files changed, 113 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index e5ad95d0af1b..a61909dc90ba 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12256,6 +12256,8 @@ static void skl_update_crtcs(struct drm_atomic_state
> *state)
> bool progress;
> enum pipe pipe;
> int i;
> + u8 hw_enabled_slices = dev_priv->wm.skl_hw.ddb.enabled_slices;
> + u8 required_slices = intel_state->wm_results.ddb.enabled_slices;
>
> const struct skl_ddb_entry *entries[I915_MAX_PIPES] = {};
>
> @@ -12264,6 +12266,10 @@ static void skl_update_crtcs(struct drm_atomic_state
> *state)
> if (new_crtc_state->active)
> entries[i] =
> &to_intel_crtc_state(old_crtc_state)->wm.skl.ddb;
>
> + /* If 2nd DBuf slice required, enable it here */
> + if (INTEL_GEN(dev_priv) >= 11 && required_slices > hw_enabled_slices)
> + icl_dbuf_slices_update(dev_priv, required_slices);
> +
> /*
>* Whenever the number of active pipes changes, we need to make sure we
>* update the pipes in the right order so that their ddb allocations
> @@ -12314,6 +12320,10 @@ static void skl_update_crtcs(struct drm_atomic_state
> *state)
> progress = true;
> }
> } while (progress);
> +
> + /* 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);
> }
>
> static void intel_atomic_helper_free_state(struct drm_i915_private *dev_priv)
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 9bba0354ccd3..11a1932cde6e 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -144,6 +144,10 @@
> #define KHz(x) (1000 * (x))
> #define MHz(x) KHz(1000 * (x))
>
> +#define KBps(x) (1000 * (x))
> +#define MBps(x) KBps(1000 * (x))
> +#define GBps(x) ((u64)1000 * MBps((x)))
> +
> /*
> * Display related stuff
> */
> @@ -1931,6 +1935,8 @@ bool intel_display_power_get_if_enabled(struct
> drm_i915_private *dev_priv,
> enum intel_display_power_domain domain);
> void intel_display_power_put(struct drm_i915_private *dev_priv,
>enum intel_display_power_domain domain);
> +void icl_dbuf_slices_update(struct drm_i915_private *dev_priv,
> + u8 req_slices);
>
> static inline void
> assert_rpm_device_not_suspended(struct drm_i915_private *dev_priv)
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index a29e6d512771..3e72e9eb736e 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3771,9 +3771,42 @@ bool intel_can_enable_sagv(struct drm_atomic_state
> *state)
> return true;
> }
>
> +static unsigned int intel_get_ddb_size(struct drm_i915_private *dev_priv,
> +const struct intel_crtc_state *cstate,
> +const unsigned int total_data_rate,
> +const int num_active,
> +
Re: [Intel-gfx] [PATCH v4] mm, drm/i915: mark pinned shmemfs pages as unevictable
On Mon 05-11-18 22:33:13, Kuo-Hsin Yang wrote: > On Mon, Nov 5, 2018 at 9:02 PM Michal Hocko wrote: > > > > On Mon 05-11-18 19:13:48, Kuo-Hsin Yang wrote: [...] > > > + * @pvec: pagevec with pages to check > > > * > > > - * Checks pages for evictability and moves them to the appropriate lru > > > list. > > > - * > > > - * This function is only used for SysV IPC SHM_UNLOCK. > > > + * This function is only used to move shmem pages. > > > > I do not really see anything that would be shmem specific here. We can > > use this function for any LRU pages unless I am missing something > > obscure. I would just drop the last sentence. > > OK, this function should not be specific to shmem pages. > > Is it OK to remove the #ifdef SHMEM surrounding check_move_unevictable_pages? Yes, I think so. -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/25] drm/i915/userptr: Avoid struct_mutex recursion for mmu_invalidate_range_start
On 02/11/2018 16:12, Chris Wilson wrote:
Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers") we have been able to report failure from
mmu_invalidate_range_start which allows us to use a trylock on the
struct_mutex to avoid potential recursion and report -EBUSY instead.
Furthermore, this allows us to pull the work into the main callback and
avoid the sleight-of-hand in using a workqueue to avoid lockdep.
However, not all paths to mmu_invalidate_range_start are prepared to
handle failure, so instead of reporting the recursion, deal with it.
Judging by the code below non-blockable paths can handle failure but
blockable can not? Right, now that I read the invalidate_range_start api
docs that seems to be the case. So that sounds like blockable brings us
marginal benefits, if any, on the design level. Which is why I suppose
this patch looks quite big. Lets see..
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108375
References: 93065ac753e4 ("mm, oom: distinguish blockable moe for mmu
notifiers")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/i915_gem.c | 18 +-
drivers/gpu/drm/i915/i915_gem_object.h | 7 +
drivers/gpu/drm/i915/i915_gem_userptr.c | 217 +++-
4 files changed, 120 insertions(+), 126 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2a88a7eb871b..1056b12c3bc8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3073,8 +3073,8 @@ enum i915_mm_subclass { /* lockdep subclass for
obj->mm.lock */
I915_MM_SHRINKER
};
-void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
-enum i915_mm_subclass subclass);
+int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
+ enum i915_mm_subclass subclass);
void __i915_gem_object_invalidate(struct drm_i915_gem_object *obj);
enum i915_map_type {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 93d09282710d..9a8af9454a53 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2429,8 +2429,8 @@ __i915_gem_object_unset_pages(struct drm_i915_gem_object
*obj)
struct sg_table *pages;
pages = fetch_and_zero(&obj->mm.pages);
- if (!pages)
- return NULL;
+ if (IS_ERR_OR_NULL(pages))
+ return pages; >
spin_lock(&i915->mm.obj_lock);
list_del(&obj->mm.link);
@@ -2454,17 +2454,16 @@ __i915_gem_object_unset_pages(struct
drm_i915_gem_object *obj)
return pages;
}
-void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
-enum i915_mm_subclass subclass)
+int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
+ enum i915_mm_subclass subclass)
{
struct sg_table *pages;
+ int ret = -EBUSY;
if (i915_gem_object_has_pinned_pages(obj))
- return;
+ return -EBUSY;
GEM_BUG_ON(obj->bind_count);
- if (!i915_gem_object_has_pages(obj))
- return;
Unrelated to this patch?
/* May be called by shrinker from within get_pages() (on another bo) */
mutex_lock_nested(&obj->mm.lock, subclass);
@@ -2477,11 +2476,16 @@ void __i915_gem_object_put_pages(struct
drm_i915_gem_object *obj,
* lists early.
*/
pages = __i915_gem_object_unset_pages(obj);
+ if (!pages && !i915_gem_object_needs_async_cancel(obj))
+ pages = ERR_PTR(-EINVAL);
(Hmm yeah, this path did not used to handle the existing possible NULL
pages here.)
Please put a blurb in the commit message on the high to medium level
design of the change.
if (!IS_ERR(pages))
obj->ops->put_pages(obj, pages);
+ ret = 0;
unlock:
mutex_unlock(&obj->mm.lock);
+
+ return ret;
}
bool i915_sg_trim(struct sg_table *orig_st)
diff --git a/drivers/gpu/drm/i915/i915_gem_object.h
b/drivers/gpu/drm/i915/i915_gem_object.h
index a6dd7c46de0d..49ce797173b5 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -56,6 +56,7 @@ struct drm_i915_gem_object_ops {
#define I915_GEM_OBJECT_HAS_STRUCT_PAGE BIT(0)
#define I915_GEM_OBJECT_IS_SHRINKABLE BIT(1)
#define I915_GEM_OBJECT_IS_PROXY BIT(2)
+#define I915_GEM_OBJECT_ASYNC_CANCEL BIT(3)
/* Interface between the GEM object and its backing storage.
* get_pages() is called once prior to the use of the associated set
@@ -386,6 +387,12 @@ i915_gem_object_is_proxy(const struct drm_i915_gem_object
*obj)
return obj->ops->flags & I915_GEM_OBJECT_IS_PROXY;
}
+static inline bool
+i915_gem_object_needs_async_cancel(const struct drm_i915_gem_object *obj)
+{
+ return obj->ops->flags & I915_
[Intel-gfx] [PATCH] drm/i915: Break long iterations for get/put shmemfs pages
As we may have to iterate a few thousand elements to acquire and release
the shmemfs backing storage for a GPU object, we need to break up the
long loop with cond_resched() to retain a modicum of low latency for
other processes.
Testcase: igt/benchmarks/gem_syslatency
Signed-off-by: Chris Wilson
Cc: Kuo-Hsin Yang
Cc: Matthew Auld
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b1caff07ed65..a120112d0621 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2404,6 +2404,7 @@ i915_gem_object_put_pages_gtt(struct drm_i915_gem_object
*obj,
mark_page_accessed(page);
put_page(page);
+ cond_resched();
}
obj->mm.dirty = false;
@@ -2574,6 +2575,7 @@ static int i915_gem_object_get_pages_gtt(struct
drm_i915_gem_object *obj)
gfp_t gfp = noreclaim;
do {
+ cond_resched();
page = shmem_read_mapping_page_gfp(mapping, i, gfp);
if (likely(!IS_ERR(page)))
break;
@@ -2584,7 +2586,6 @@ static int i915_gem_object_get_pages_gtt(struct
drm_i915_gem_object *obj)
}
i915_gem_shrink(dev_priv, 2 * page_count, NULL, *s++);
- cond_resched();
/*
* We've tried hard to allocate the memory by reaping
--
2.19.1
___
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: Break long iterations for get/put shmemfs pages
== Series Details == Series: drm/i915: Break long iterations for get/put shmemfs pages URL : https://patchwork.freedesktop.org/series/52036/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_5088 -> Patchwork_10727 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_10727 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10727, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/52036/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_10727: === IGT changes === Possible regressions igt@drv_module_reload@basic-no-display: fi-byt-clapper: PASS -> WARN == Known issues == Here are the changes found in Patchwork_10727 that come from known issues: === IGT changes === Issues hit igt@amdgpu/amd_basic@cs-compute: fi-kbl-8809g: NOTRUN -> FAIL (fdo#108094) igt@amdgpu/amd_prime@amd-to-i915: fi-kbl-8809g: NOTRUN -> FAIL (fdo#107341) igt@gem_exec_fence@basic-await-default: fi-byt-j1900: PASS -> INCOMPLETE (fdo#102657) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-byt-clapper: PASS -> FAIL (fdo#103191, fdo#107362) +1 fi-icl-u: NOTRUN -> INCOMPLETE (fdo#107713) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-blb-e6850: PASS -> INCOMPLETE (fdo#107718) Possible fixes igt@drv_module_reload@basic-reload-inject: fi-byt-clapper: WARN -> PASS igt@kms_pipe_crc_basic@hang-read-crc-pipe-b: fi-byt-clapper: FAIL (fdo#103191, fdo#107362) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-cfl-8109u: FAIL (fdo#103375) -> PASS +1 igt@pm_rpm@module-reload: fi-byt-clapper: FAIL -> PASS fdo#102657 https://bugs.freedesktop.org/show_bug.cgi?id=102657 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#107341 https://bugs.freedesktop.org/show_bug.cgi?id=107341 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107713 https://bugs.freedesktop.org/show_bug.cgi?id=107713 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#108094 https://bugs.freedesktop.org/show_bug.cgi?id=108094 == Participating hosts (49 -> 45) == Additional (3): fi-icl-u fi-kbl-8809g fi-pnv-d510 Missing(7): fi-ilk-m540 fi-hsw-4200u fi-skl-guc fi-byt-squawks fi-bsw-cyan fi-apl-guc fi-ctg-p8600 == Build changes == * Linux: CI_DRM_5088 -> Patchwork_10727 CI_DRM_5088: 1a4a6dafa1fdcab0fbf0a5ef7f4c56be9c49b87e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4709: 15dff9353621d0746b80fae534c20621e03a9f01 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10727: 152412f441d8feb5ed9ae66a23821c5f94ff5cda @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 152412f441d8 drm/i915: Break long iterations for get/put shmemfs pages == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10727/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v5 1/8] drm: Add Enhanced Gamma LUT precision structure
On Sun, Sep 16, 2018 at 01:45:24PM +0530, Uma Shankar wrote:
> Existing LUT precision structure is having only 16 bit
> precision. This is not enough for upcoming enhanced hardwares
> and advance usecases like HDR processing. Hence added a new
> structure with 32 bit precision values. Also added the code,
> for extracting the same from values passed from userspace.
>
> v4: Rebase
>
> v5: Relocated the helper function to drm_color_mgmt.c. Declared
> the same in a header file (Alexandru Gheorghe)
>
> Signed-off-by: Uma Shankar
> Reviewed-by: Alexandru Gheorghe
> ---
> drivers/gpu/drm/drm_color_mgmt.c | 19 +++
> include/drm/drm_color_mgmt.h | 1 +
> include/uapi/drm/drm_mode.h | 15 +++
> 3 files changed, 35 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> b/drivers/gpu/drm/drm_color_mgmt.c
> index b97e2de..1bdcc1a 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -128,6 +128,25 @@ uint32_t drm_color_lut_extract(uint32_t user_input,
> uint32_t bit_precision)
> }
> EXPORT_SYMBOL(drm_color_lut_extract);
>
> +/*
> + * Added to accommodate enhanced LUT precision.
> + * Max LUT precision is 32 bits.
> + */
> +uint32_t drm_color_lut_extract_ext(uint32_t user_input, uint32_t
> bit_precision)
> +{
> + uint32_t val = user_input;
> + uint32_t max = 0x >> (32 - bit_precision);
> +
> + /* Round only if we're not using full precision. */
> + if (bit_precision < 32) {
> + val += 1UL << (32 - bit_precision - 1);
Does val need to be a 64-bit type to prevent this from overflowing?
Matt
> + val >>= 32 - bit_precision;
> + }
> +
> + return clamp_val(val, 0, max);
> +}
> +EXPORT_SYMBOL(drm_color_lut_extract_ext);
> +
> /**
> * drm_crtc_enable_color_mgmt - enable color management properties
> * @crtc: DRM CRTC
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index 44f04233..78b5a37 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -29,6 +29,7 @@
> struct drm_plane;
>
> uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision);
> +uint32_t drm_color_lut_extract_ext(uint32_t user_input, uint32_t
> bit_precision);
>
> void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
> uint degamma_lut_size,
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 8d67243..874407b 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -629,6 +629,21 @@ struct drm_color_lut {
> __u16 reserved;
> };
>
> +/*
> + * Creating 32 bit palette entries for better data
> + * precision. This will be required for HDR and
> + * similar color processing usecases.
> + */
> +struct drm_color_lut_ext {
> + /*
> + * Data is U0.32 fixed point format.
> + */
> + __u32 red;
> + __u32 green;
> + __u32 blue;
> + __u32 reserved;
> +};
> +
> #define DRM_MODE_PAGE_FLIP_EVENT 0x01
> #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
> #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] mm, drm/i915: mark pinned shmemfs pages as unevictable
On 11/5/18 3:13 AM, Kuo-Hsin Yang wrote: > -These are currently used in two places in the kernel: > +These are currently used in three places in the kernel: > > (1) By ramfs to mark the address spaces of its inodes when they are created, > and this mark remains for the life of the inode. > @@ -154,6 +154,8 @@ These are currently used in two places in the kernel: > swapped out; the application must touch the pages manually if it wants > to > ensure they're in memory. > > + (3) By the i915 driver to mark pinned address space until it's unpinned. At a minimum, I think we owe some documentation here of how to tell approximately how much memory i915 is consuming with this mechanism. The debugfs stuff sounds like a halfway reasonable way to approximate it, although it's imperfect. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Don't oops during modeset shutdown after lpe audio deinit
From: Ville Syrjälä We deinit the lpe audio device before we call drm_atomic_helper_shutdown(), which means the platform device may already be gone when it comes time to shut down the crtc. As we don't know when the last reference to the platform device gets dropped by the audio driver we can't assume that the device and its data are still around when turning off the crtc. Mark the platform device as gone as soon as we do the audio deinit. Cc: sta...@vger.kernel.org Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_lpe_audio.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c b/drivers/gpu/drm/i915/intel_lpe_audio.c index cdf19553ffac..5d5336fbe7b0 100644 --- a/drivers/gpu/drm/i915/intel_lpe_audio.c +++ b/drivers/gpu/drm/i915/intel_lpe_audio.c @@ -297,8 +297,10 @@ void intel_lpe_audio_teardown(struct drm_i915_private *dev_priv) lpe_audio_platdev_destroy(dev_priv); irq_free_desc(dev_priv->lpe_audio.irq); -} + dev_priv->lpe_audio.irq = -1; + dev_priv->lpe_audio.platdev = NULL; +} /** * intel_lpe_audio_notify() - notify lpe audio event -- 2.18.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 drm/i915: Fix ilk+ watermarks when disabling pipes
On Fri, Oct 26, 2018 at 08:05:04PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Fix ilk+ watermarks when disabling pipes > URL : https://patchwork.freedesktop.org/series/51518/ > State : failure > > == Summary == > > = CI Bug Log - changes from CI_DRM_5042_full -> Patchwork_10603_full = > > == Summary - FAILURE == > > Serious unknown changes coming with Patchwork_10603_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_10603_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_10603_full: > > === IGT changes === > > Possible regressions > > igt@kms_flip_tiling@flip-changes-tiling: > shard-skl: NOTRUN -> FAIL The patch doesn't change the behaviour for SKL+ so this is unrelated. The test seems pingpong between NOTRUN and PASS a lot. There is a bug about a fail as well but that only lists VLV so far: https://bugs.freedesktop.org/show_bug.cgi?id=107831 Anyways, pushed with Maarten's irc r-b. > > > Warnings > > igt@pm_rc6_residency@rc6-accuracy: > shard-snb: SKIP -> PASS > > > == Known issues == > > Here are the changes found in Patchwork_10603_full that come from known > issues: > > === IGT changes === > > Issues hit > > igt@drv_suspend@shrink: > shard-hsw: PASS -> INCOMPLETE (fdo#106886, fdo#103540) > > igt@gem_cpu_reloc@full: > shard-skl: NOTRUN -> INCOMPLETE (fdo#108073) > > igt@gem_exec_schedule@pi-ringfull-vebox: > shard-skl: NOTRUN -> FAIL (fdo#103158) > > igt@gem_userptr_blits@readonly-unsync: > shard-skl: NOTRUN -> INCOMPLETE (fdo#108074) > > igt@gem_workarounds@suspend-resume-context: > shard-skl: NOTRUN -> INCOMPLETE (fdo#107773, fdo#104108) > > igt@kms_available_modes_crc@available_mode_test_crc: > shard-snb: PASS -> FAIL (fdo#106641) > > igt@kms_busy@extended-modeset-hang-newfb-render-a: > shard-skl: NOTRUN -> DMESG-WARN (fdo#107956) +2 > > igt@kms_busy@extended-pageflip-hang-newfb-render-b: > shard-glk: PASS -> DMESG-WARN (fdo#107956) > > igt@kms_chv_cursor_fail@pipe-c-256x256-right-edge: > shard-skl: NOTRUN -> FAIL (fdo#104671) > > igt@kms_color@pipe-c-legacy-gamma: > shard-skl: NOTRUN -> FAIL (fdo#104782) > > igt@kms_cursor_crc@cursor-128x128-random: > shard-apl: PASS -> INCOMPLETE (fdo#103927) > > igt@kms_cursor_crc@cursor-256x256-suspend: > shard-apl: PASS -> FAIL (fdo#103375) > > igt@kms_cursor_crc@cursor-64x21-sliding: > shard-apl: PASS -> FAIL (fdo#103232) > > igt@kms_flip_tiling@flip-to-x-tiled: > shard-skl: NOTRUN -> FAIL (fdo#108134) > > igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff: > shard-apl: PASS -> FAIL (fdo#103167) > > igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu: > shard-glk: PASS -> FAIL (fdo#103167) +3 > > igt@kms_frontbuffer_tracking@fbc-stridechange: > shard-skl: NOTRUN -> FAIL (fdo#105683) > > igt@kms_panel_fitting@legacy: > shard-skl: NOTRUN -> FAIL (fdo#105456) > > igt@kms_pipe_crc_basic@hang-read-crc-pipe-c: > shard-apl: PASS -> DMESG-WARN (fdo#108549) +19 > > igt@kms_plane@pixel-format-pipe-b-planes: > shard-skl: NOTRUN -> DMESG-FAIL (fdo#103166, fdo#106885) +1 > > igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb: > shard-skl: NOTRUN -> FAIL (fdo#108145) +3 > > igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb: > shard-glk: PASS -> FAIL (fdo#108145) +1 > shard-kbl: NOTRUN -> FAIL (fdo#108145) > > igt@kms_plane_alpha_blend@pipe-c-alpha-basic: > shard-skl: NOTRUN -> FAIL (fdo#107815, fdo#108145) > > igt@kms_plane_multiple@atomic-pipe-b-tiling-x: > shard-glk: PASS -> FAIL (fdo#103166) +2 > > igt@kms_rotation_crc@primary-rotation-180: > shard-snb: NOTRUN -> FAIL (fdo#103925) > > igt@kms_setmode@basic: > shard-kbl: PASS -> FAIL (fdo#99912) > > igt@kms_universal_plane@universal-plane-pipe-b-functional: > shard-apl: PASS -> FAIL (fdo#103166) > > igt@kms_vblank@pipe-b-ts-continuation-modeset-hang: > shard-apl: PASS -> DMESG-FAIL (fdo#108549) +2 > > igt@pm_backlight@fade_with_suspend: > shard-skl: NOTRUN -> FAIL (fdo#107847) > > > Possible fixes > > igt@gem_render_copy_redux@interruptible: >
Re: [Intel-gfx] [PATCH] drm/i915: Don't oops during modeset shutdown after lpe audio deinit
Quoting Ville Syrjala (2018-11-05 19:46:04) > From: Ville Syrjälä > > We deinit the lpe audio device before we call > drm_atomic_helper_shutdown(), which means the platform device > may already be gone when it comes time to shut down the crtc. Doesn't this mean that we fail to notify the audio codec of it being turned off? I'm wondering if we shouldn't do the display/gt idling first (like a i915_driver_unload_prepare). > As we don't know when the last reference to the platform > device gets dropped by the audio driver we can't assume that > the device and its data are still around when turning off the > crtc. Mark the platform device as gone as soon as we do the > audio deinit. > > Cc: sta...@vger.kernel.org > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_lpe_audio.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c > b/drivers/gpu/drm/i915/intel_lpe_audio.c > index cdf19553ffac..5d5336fbe7b0 100644 > --- a/drivers/gpu/drm/i915/intel_lpe_audio.c > +++ b/drivers/gpu/drm/i915/intel_lpe_audio.c > @@ -297,8 +297,10 @@ void intel_lpe_audio_teardown(struct drm_i915_private > *dev_priv) > lpe_audio_platdev_destroy(dev_priv); > > irq_free_desc(dev_priv->lpe_audio.irq); > -} > > + dev_priv->lpe_audio.irq = -1; > + dev_priv->lpe_audio.platdev = NULL; > +} This thanks to HAS_LPE_AUDIO() (confusing macro of the day) will prevent a use-after-free during crtc shutdown. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/3] drm/i915/mst: Drop pre_pll_enable null check
MST is only supported in DDI ports that have this hook, so the null check can be dropped. Suggested-by: Imre Deak Cc: Imre Deak Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/intel_dp_mst.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index d57dc7900eb1..34ac1a7c2202 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -209,8 +209,7 @@ static void intel_mst_pre_pll_enable_dp(struct intel_encoder *encoder, struct intel_digital_port *intel_dig_port = intel_mst->primary; struct intel_dp *intel_dp = &intel_dig_port->dp; - if (intel_dp->active_mst_links == 0 && - intel_dig_port->base.pre_pll_enable) + if (intel_dp->active_mst_links == 0) intel_dig_port->base.pre_pll_enable(&intel_dig_port->base, pipe_config, NULL); } -- 2.19.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/3] drm/i915: Release DDI power well references in MST ports
MST ports did not had the post_pll_disable() hook causing the
references get in pre_pll_enable() never being released causing
DDI and AUX CH being enabled all the times.
v2: renamed intel_mst_post_pll_disable_dp() parameters
Reviewed-by: Ville Syrjälä
Reviewed-by: Imre Deak
Cc: Imre Deak
Cc: Manasi Navare
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_dp_mst.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 8b71d64ebd9d..d57dc7900eb1 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -215,6 +215,20 @@ static void intel_mst_pre_pll_enable_dp(struct
intel_encoder *encoder,
pipe_config, NULL);
}
+static void intel_mst_post_pll_disable_dp(struct intel_encoder *encoder,
+ const struct intel_crtc_state
*old_crtc_state,
+ const struct drm_connector_state
*old_conn_state)
+{
+ struct intel_dp_mst_encoder *intel_mst = enc_to_mst(&encoder->base);
+ struct intel_digital_port *intel_dig_port = intel_mst->primary;
+ struct intel_dp *intel_dp = &intel_dig_port->dp;
+
+ if (intel_dp->active_mst_links == 0)
+ intel_dig_port->base.post_pll_disable(&intel_dig_port->base,
+ old_crtc_state,
+ old_conn_state);
+}
+
static void intel_mst_pre_enable_dp(struct intel_encoder *encoder,
const struct intel_crtc_state *pipe_config,
const struct drm_connector_state
*conn_state)
@@ -549,6 +563,7 @@ intel_dp_create_fake_mst_encoder(struct intel_digital_port
*intel_dig_port, enum
intel_encoder->disable = intel_mst_disable_dp;
intel_encoder->post_disable = intel_mst_post_disable_dp;
intel_encoder->pre_pll_enable = intel_mst_pre_pll_enable_dp;
+ intel_encoder->post_pll_disable = intel_mst_post_pll_disable_dp;
intel_encoder->pre_enable = intel_mst_pre_enable_dp;
intel_encoder->enable = intel_mst_enable_dp;
intel_encoder->get_hw_state = intel_dp_mst_enc_get_hw_state;
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/3] drm/i915: Reuse the aux_domain cached
intel_dp_detect() caches the aux_domain in the beginning of the
function as it is used twice, so lets also use it as the aux_domain
don't change in runtime by jumping to the end of function when
retrain the link fails.
v2: jumping to the end of the function instead of just reuse
aux_domain
Cc: Imre Deak
Reviewed-by: Imre Deak
Reviewed-by: Ville Syrjälä
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_dp.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5258c9d654f4..c7814d53f70f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5165,13 +5165,9 @@ intel_dp_detect(struct drm_connector *connector,
* with an IRQ_HPD, so force a link status check.
*/
if (!intel_dp_is_edp(intel_dp)) {
- int ret;
-
- ret = intel_dp_retrain_link(encoder, ctx);
- if (ret) {
- intel_display_power_put(dev_priv,
-
intel_aux_power_domain(dig_port));
- return ret;
+ if (intel_dp_retrain_link(encoder, ctx)) {
+ status = connector_status_disconnected;
+ goto out;
}
}
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] X freezes for a second or every now and then when lid closed
On Sun, Nov 04, 2018 at 09:51:44PM -0800, Joel Fernandes wrote: > i915 DRM maintainers, could you take a look at the below issue? It causes an > annoying Xorg hang every 30 seconds when my laptop lid is closed with > external monitors connected. This is a thinkpad laptop. I am not sure how to > get the panel info but if you can let me know how to do that, I can dig it > out. Logs excerpts are below and full logs are attached to earlier threads. Hi Joel, Could you please file a bug at https://bugs.freedesktop.org following: https://01.org/linuxgraphics/documentation/how-report-bugs Unfortunately the dmesg provided is not enough since it has lost the initial information. So please increase log length or capture right on the begining with only drm.debug=0xe Thanks, Rodrigo. > > On Thu, Nov 01, 2018 at 05:02:54PM -0700, Joel Fernandes wrote: > > On Mon, Oct 29, 2018 at 01:11:30PM +, Chris Wilson wrote: > > > Quoting Joel Fernandes (2018-10-27 09:14:07) > > > > On Sat, Oct 27, 2018 at 12:38:56AM -0700, Joel Fernandes wrote: > > > > > Hi! > > > > > My Linux laptop running kernel v4.17 freezes intermittently when the > > > > > laptop > > > > > lid is closed but external monitors are connected to 2 HDMI ports. I > > > > > provided > > > > > details on the issue, any idea what could be causing it? > > > > > > > > > > I ruled out many different subsystems by trial and error, finally I > > > > > enabled > > > > > ftrace events on power subsystem and see that the freeze is precisely > > > > > at the > > > > > same time as drm_mode_getconnector is called on these events and its > > > > > the Xorg > > > > > process. I think since Xorg is busy on this drm_mode_getconnector > > > > > ioctl, its > > > > > not able to perform its duties. > > > > > > > > > > I get a stacktrace like so: > > > > > Xorg-1285 [001] 801.156606: pm_qos_update_request: > > > > >pm_qos_class=CPU_DMA_LATENCY value=-1 > > > > > Xorg-1285 [001] 801.156607: pm_qos_update_target: > > > > >action=UPDATE_REQ prev_value=0 curr_value=20 > > > > > Xorg-1285 [001] 801.156609: > > > > > => pm_qos_update_target > > > > > => intel_dp_aux_xfer > > > > > => intel_dp_aux_transfer > > > > > => drm_dp_dpcd_access > > > > > => drm_dp_dpcd_read > > > > > => intel_dp_read_dpcd > > > > > => intel_dp_detect > > > > > => drm_helper_probe_single_connector_modes > > > > > => drm_mode_getconnector > > > > > => drm_ioctl_kernel > > > > > => drm_ioctl > > > > > => do_vfs_ioctl > > > > > => ksys_ioctl > > > > > => __x64_sys_ioctl > > > > > => do_syscall_64 > > > > > => entry_SYSCALL_64_after_hwframe > > > > > > > > > > The X version I'm running is X.Org X Server 1.19.6 > > > > > > > > > > I also see these in /var/log/Xorg.0.log every 30 seconds and it seems > > > > > correlated to the time of freezing: > > > > > [ 1141.925] (--) modeset(0): HDMI max TMDS frequency 17KHz > > > > > [ 1142.223] (II) modeset(0): EDID vendor "HWP", prod id 13093 > > > > > [ 1142.223] (II) modeset(0): Using hsync ranges from config file > > > > > [ 1142.223] (II) modeset(0): Using vrefresh ranges from config file > > > > > [ 1142.223] (II) modeset(0): Printing DDC gathered Modelines: > > > > > [ 1142.223] (II) modeset(0): Modeline "1920x1080"x0.0 148.50 1920 > > > > > 2008 > > > > > 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.5 kHz eP) > > > > > [ 1142.223] (II) modeset(0): Modeline "1920x1080"x0.0 148.50 1920 > > > > > 2448 > > > > > 2492 2640 1080 1084 1089 1125 +hsync +vsync (56.2 kHz e) > > > > > > > > > > Let me know if you spot anything weird, and if you have any > > > > > suggestions? > > > > > > > > Just for documenting it, the issue seems very similar to what is > > > > reported in > > > > this comment: > > > > https://forums.linuxmint.com/viewtopic.php?t=253475#p1457587 > > > > > > > > I am indeed using Cinammon as well. With the lid closed, the same > > > > 'modeset' > > > > log messages appear and freeze the system every 30 seconds. > > > > > > 30s == hotplug polling kthread; the implication would be that it is > > > generating a hotplug uevent everytime. drm.debug=0xe should record what > > > it going on, so capture a dmesg with the lid closed. > > > > > > Platform and panel HW would be useful to know, dmesg from boot is > > > usually sufficient > > > > Thanks a lot Chris. So here is what I get with drm.debug=0xe. Below is a > > small part of it close to the "stuck" state. I do see some errors. Any > > insights are appreciated! > > I attached the full dmesg dump here at this link: > > https://gist.github.com/joelagnel/72806b2e1a4a0c97e11915315158cbde > > > > [ 297.414429] [drm:drm_helper_probe_single_connector_modes > > [drm_kms_helper]] [CONNECTOR:71:eDP-1] > > [ 297.414497] [drm:intel_dp_detect [i915]] [CONNECTOR:71:eDP-1] > > [ 297.414560] [drm:intel_dp_print_rates [i915]] source rates: 162000, > > 216000, 27, 3240
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/mst: Drop pre_pll_enable null check
On Mon, Nov 05, 2018 at 12:25:52PM -0800, José Roberto de Souza wrote: > MST is only supported in DDI ports that have this hook, so the null > check can be dropped. > > Suggested-by: Imre Deak > Cc: Imre Deak > Signed-off-by: José Roberto de Souza I feel that the extra check doesn't hurt since it is an "optional" hook, but I don't believe it would be possible to have any mst without this pre-enalble hook anyway so we can remove... Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_dp_mst.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c > b/drivers/gpu/drm/i915/intel_dp_mst.c > index d57dc7900eb1..34ac1a7c2202 100644 > --- a/drivers/gpu/drm/i915/intel_dp_mst.c > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c > @@ -209,8 +209,7 @@ static void intel_mst_pre_pll_enable_dp(struct > intel_encoder *encoder, > struct intel_digital_port *intel_dig_port = intel_mst->primary; > struct intel_dp *intel_dp = &intel_dig_port->dp; > > - if (intel_dp->active_mst_links == 0 && > - intel_dig_port->base.pre_pll_enable) > + if (intel_dp->active_mst_links == 0) > intel_dig_port->base.pre_pll_enable(&intel_dig_port->base, > pipe_config, NULL); > } > -- > 2.19.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 v3 4/5] drm/i915: Clarify flow for disabling IRQs on storms
On Fri, Nov 02, 2018 at 08:19:07PM -0400, Lyude Paul wrote: > This is rather confusing to look at as-is: > dev_priv->display.hpd_irq_setup(dev_priv); in intel_hpd_irq_handler() > handles disabling the actual HPD IRQ, while > intel_hpd_irq_storm_disable() handles moving the HPD pin state over from > MARK_DISABLED to DISABLED along with enabling polling for it. what about also changing the name of the function? > > Cc: Ville Syrjälä > Signed-off-by: Lyude Paul > --- > drivers/gpu/drm/i915/intel_hotplug.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_hotplug.c > b/drivers/gpu/drm/i915/intel_hotplug.c > index c11d73de16f2..e5e3eeb7e482 100644 > --- a/drivers/gpu/drm/i915/intel_hotplug.c > +++ b/drivers/gpu/drm/i915/intel_hotplug.c > @@ -351,7 +351,7 @@ static void i915_hotplug_work_func(struct work_struct > *work) > hpd_event_bits = dev_priv->hotplug.event_bits; > dev_priv->hotplug.event_bits = 0; > > - /* Disable hotplug on connectors that hit an irq storm. */ > + /* Enable polling for connectors which had HPD IRQ storms */ > intel_hpd_irq_storm_disable(dev_priv); This now gets confusing to my brain... comment says "enable" function name is "disable". > > spin_unlock_irq(&dev_priv->irq_lock); > @@ -458,6 +458,10 @@ void intel_hpd_irq_handler(struct drm_i915_private > *dev_priv, > } > } > > + /* > + * Disable any IRQs that storms were detected on. Polling enablement > + * happens later in our hotplug work. > + */ > if (storm_detected && dev_priv->display_irqs_enabled) > dev_priv->display.hpd_irq_setup(dev_priv); > spin_unlock(&dev_priv->irq_lock); > -- > 2.19.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] [PATCH v4 5/5] drm/i915: Add short HPD IRQ storm detection for non-MST systems
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having updated. The amount of time it took to boot went
from around 30 seconds, to over 6 minutes consistently.
After some investigation, I discovered that i915 was reporting massive
amounts of short HPD IRQ spam on this system from the DisplayPort port,
despite there not being anything actually connected. The symptoms would
start with one "long" HPD IRQ being detected at boot:
[1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0044, dig 0x0044, pins 0x00a0
[1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
[1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN
5 - cnt: 0
[1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
[1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN
7 - cnt: 0
[1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
[1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
…
followed by constant short IRQs afterwards:
[1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status
updated from unknown to disconnected
[1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7)
received hotplug event.
[1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
[1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0020, dig 0x0020, pins 0x0080
[1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0020, dig 0x0020, pins 0x0080
[1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status
0x71450085
[1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0020, dig 0x0020, pins 0x0080
[1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0020, dig 0x0020, pins 0x0080
[1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0020, dig 0x0020, pins 0x0080
The customer's system in question has a GM45 GPU, which is apparently
well known for hotplugging storms.
So, workaround this impressively broken hardware by changing the default
HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and
short IRQs count for 1. This makes it so that 5 long IRQs will trigger
an HPD storm, and on systems with short HPD storm detection 50 short
IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of
constant pulsing, which seems like a good middleground between being too
sensitive and not being sensitive enough (which would cause visible
stutters in userspace every time a storm occurs).
And just to be extra safe: we don't enable this by default on systems
with MST support. There's too high of a chance of MST support triggering
storm detection, and systems that are new enough to support MST are a
lot less likely to have issues with IRQ storms anyway.
As a note: this patch was tested using a ThinkPad T450s and a Chamelium
to simulate the short IRQ storms.
Changes since v1:
- Don't use two separate thresholds, just make long IRQs count for 10
each and short IRQs count for 1. This simplifies the code a bit
- Ville Syrjälä
Changes since v2:
- Document @long_hpd in intel_hpd_irq_storm_detect, no functional
changes
Signed-off-by: Lyude Paul
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_debugfs.c | 74
drivers/gpu/drm/i915/i915_drv.h | 5 +-
drivers/gpu/drm/i915/i915_irq.c | 7 +++
drivers/gpu/drm/i915/intel_hotplug.c | 49 ++
4 files changed, 114 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index f60485906f7e..670db5073d70 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4658,6 +4658,79 @@ static const struct file_operations
i915_hpd_storm_ctl_fops = {
.write = i915_hpd_storm_ctl_write
};
+static int i915_hpd_short_storm_ctl_show(struct seq_file *m, void *data)
+{
+ struct drm_i915_private *dev_priv = m->private;
+
+ seq_printf(m, "Enabled: %s\n",
+ yesno(dev_priv->hotplug.hpd_short_storm_enabled));
+
+ return 0;
+}
+
+static int
+i915_hpd_short_storm_ctl_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, i915_hpd_short_s
[Intel-gfx] [PATCH v4 2/5] drm/i915: Fix NULL deref when re-enabling HPD IRQs on systems with MST
Turns out that if you trigger an HPD storm on a system that has an MST
topology connected to it, you'll end up causing the kernel to eventually
hit a NULL deref:
[ 332.339041] BUG: unable to handle kernel NULL pointer dereference at
00ec
[ 332.340906] PGD 0 P4D 0
[ 332.342750] Oops: [#1] SMP PTI
[ 332.344579] CPU: 2 PID: 25 Comm: kworker/2:0 Kdump: loaded Tainted: G
O 4.18.0-rc3short-hpd-storm+ #2
[ 332.346453] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET71WW (1.35
) 09/14/2018
[ 332.348361] Workqueue: events intel_hpd_irq_storm_reenable_work [i915]
[ 332.350301] RIP: 0010:intel_hpd_irq_storm_reenable_work.cold.3+0x2f/0x86
[i915]
[ 332.352213] Code: 00 00 ba e8 00 00 00 48 c7 c6 c0 aa 5f a0 48 c7 c7 d0 73
62 a0 4c 89 c1 4c 89 04 24 e8 7f f5 af e0 4c 8b 04 24 44 89 f8 29 e8 <41> 39 80
ec 00 00 00 0f 85 43 13 fc ff 41 0f b6 86 b8 04 00 00 41
[ 332.354286] RSP: 0018:c9147e48 EFLAGS: 00010006
[ 332.356344] RAX: 0005 RBX: 8802c226c9d4 RCX: 0006
[ 332.358404] RDX: RSI: 0082 RDI: 88032dc95570
[ 332.360466] RBP: 0005 R08: R09: 88031b3dc840
[ 332.362528] R10: R11: 00031a069602 R12: 8802c226ca20
[ 332.364575] R13: 8802c2268000 R14: 880310661000 R15: 000a
[ 332.366615] FS: () GS:88032dc8()
knlGS:
[ 332.368658] CS: 0010 DS: ES: CR0: 80050033
[ 332.370690] CR2: 00ec CR3: 0200a003 CR4: 003606e0
[ 332.372724] DR0: DR1: DR2:
[ 332.374773] DR3: DR6: fffe0ff0 DR7: 0400
[ 332.376798] Call Trace:
[ 332.378809] process_one_work+0x1a1/0x350
[ 332.380806] worker_thread+0x30/0x380
[ 332.382777] ? wq_update_unbound_numa+0x10/0x10
[ 332.384772] kthread+0x112/0x130
[ 332.386740] ? kthread_create_worker_on_cpu+0x70/0x70
[ 332.388706] ret_from_fork+0x35/0x40
[ 332.390651] Modules linked in: i915(O) vfat fat joydev btusb btrtl btbcm
btintel bluetooth ecdh_generic iTCO_wdt wmi_bmof i2c_algo_bit drm_kms_helper
intel_rapl syscopyarea sysfillrect x86_pkg_temp_thermal sysimgblt coretemp
fb_sys_fops crc32_pclmul drm psmouse pcspkr mei_me mei i2c_i801 lpc_ich
mfd_core i2c_core tpm_tis tpm_tis_core thinkpad_acpi wmi tpm rfkill video
crc32c_intel serio_raw ehci_pci xhci_pci ehci_hcd xhci_hcd [last unloaded: i915]
[ 332.394963] CR2: 00ec
This appears to be due to the fact that with an MST topology, not all
intel_connector structs will have ->encoder set. So, fix this by
skipping connectors without encoders in
intel_hpd_irq_storm_reenable_work().
For those wondering, this bug was found on accident while simulating HPD
storms using a Chamelium connected to a ThinkPad T450s (Broadwell).
Changes since v1:
- Check intel_connector->mst_port instead of intel_connector->encoder
Signed-off-by: Lyude Paul
Reviewed-by: Ville Syrjälä
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_hotplug.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
b/drivers/gpu/drm/i915/intel_hotplug.c
index 648a13c6043c..8326900a311e 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -228,7 +228,9 @@ static void intel_hpd_irq_storm_reenable_work(struct
work_struct *work)
drm_for_each_connector_iter(connector, &conn_iter) {
struct intel_connector *intel_connector =
to_intel_connector(connector);
- if (intel_connector->encoder->hpd_pin == pin) {
+ /* Don't check MST ports, they don't have pins */
+ if (!intel_connector->mst_port &&
+ intel_connector->encoder->hpd_pin == pin) {
if (connector->polled !=
intel_connector->polled)
DRM_DEBUG_DRIVER("Reenabling HPD on
connector %s\n",
connector->name);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 3/5] drm/i915: Fix threshold check in intel_hpd_irq_storm_detect()
Currently in intel_hpd_irq_storm_detect() when we detect that the last
recorded hotplug wasn't within the period defined by
HPD_STORM_DETECT_DELAY, we make the mistake of resetting the HPD count
to 0 without incrementing it. This results in us only enabling storm
detection when we go +2 above the threshold, e.g. an HPD threshold of 5
would not trigger a storm until we reach a total of 7 hotplugs.
So: rework the code a bit so we reset the HPD count when
HPD_STORM_DETECT_DELAY has passed, then increment the count afterwards.
Also, clean things up a bit to make it easier to undertand.
Cc: Ville Syrjälä
Signed-off-by: Lyude Paul
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_hotplug.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
b/drivers/gpu/drm/i915/intel_hotplug.c
index 8326900a311e..c11d73de16f2 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -135,24 +135,27 @@ enum hpd_pin intel_hpd_pin_default(struct
drm_i915_private *dev_priv,
static bool intel_hpd_irq_storm_detect(struct drm_i915_private *dev_priv,
enum hpd_pin pin)
{
- unsigned long start = dev_priv->hotplug.stats[pin].last_jiffies;
+ struct i915_hotplug *hpd = &dev_priv->hotplug;
+ unsigned long start = hpd->stats[pin].last_jiffies;
unsigned long end = start + msecs_to_jiffies(HPD_STORM_DETECT_PERIOD);
- const int threshold = dev_priv->hotplug.hpd_storm_threshold;
+ const int threshold = hpd->hpd_storm_threshold;
bool storm = false;
+ if (!threshold)
+ return false;
+
if (!time_in_range(jiffies, start, end)) {
- dev_priv->hotplug.stats[pin].last_jiffies = jiffies;
- dev_priv->hotplug.stats[pin].count = 0;
- DRM_DEBUG_KMS("Received HPD interrupt on PIN %d - cnt: 0\n",
pin);
- } else if (dev_priv->hotplug.stats[pin].count > threshold &&
- threshold) {
- dev_priv->hotplug.stats[pin].state = HPD_MARK_DISABLED;
+ hpd->stats[pin].last_jiffies = jiffies;
+ hpd->stats[pin].count = 0;
+ }
+
+ if (++hpd->stats[pin].count > threshold) {
+ hpd->stats[pin].state = HPD_MARK_DISABLED;
DRM_DEBUG_KMS("HPD interrupt storm detected on PIN %d\n", pin);
storm = true;
} else {
- dev_priv->hotplug.stats[pin].count++;
DRM_DEBUG_KMS("Received HPD interrupt on PIN %d - cnt: %d\n",
pin,
- dev_priv->hotplug.stats[pin].count);
+ hpd->stats[pin].count);
}
return storm;
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 4/5] drm/i915: Clarify flow for disabling IRQs on storms
This is rather confusing to look at as-is:
dev_priv->display.hpd_irq_setup(dev_priv); in intel_hpd_irq_handler()
handles disabling the actual HPD IRQ, while
intel_hpd_irq_storm_disable() handles moving the HPD pin state over from
MARK_DISABLED to DISABLED along with enabling polling for it.
Changes since v3:
- Rename i915_hpd_irq_storm_disable() to
i915_hpd_irq_storm_switch_to_polling() - Rodrigo Vivi
Cc: Ville Syrjälä
Signed-off-by: Lyude Paul
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_hotplug.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
b/drivers/gpu/drm/i915/intel_hotplug.c
index c11d73de16f2..d642c0795452 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -161,7 +161,8 @@ static bool intel_hpd_irq_storm_detect(struct
drm_i915_private *dev_priv,
return storm;
}
-static void intel_hpd_irq_storm_disable(struct drm_i915_private *dev_priv)
+static void
+intel_hpd_irq_storm_switch_to_polling(struct drm_i915_private *dev_priv)
{
struct drm_device *dev = &dev_priv->drm;
struct intel_connector *intel_connector;
@@ -351,8 +352,8 @@ static void i915_hotplug_work_func(struct work_struct *work)
hpd_event_bits = dev_priv->hotplug.event_bits;
dev_priv->hotplug.event_bits = 0;
- /* Disable hotplug on connectors that hit an irq storm. */
- intel_hpd_irq_storm_disable(dev_priv);
+ /* Enable polling for connectors which had HPD IRQ storms */
+ intel_hpd_irq_storm_switch_to_polling(dev_priv);
spin_unlock_irq(&dev_priv->irq_lock);
@@ -458,6 +459,10 @@ void intel_hpd_irq_handler(struct drm_i915_private
*dev_priv,
}
}
+ /*
+* Disable any IRQs that storms were detected on. Polling enablement
+* happens later in our hotplug work.
+*/
if (storm_detected && dev_priv->display_irqs_enabled)
dev_priv->display.hpd_irq_setup(dev_priv);
spin_unlock(&dev_priv->irq_lock);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/5] drm/i915: Fix possible race in intel_dp_add_mst_connector()
This hasn't caused any issues yet that I'm aware of, but as Ville
Syrjälä pointed out - we need to make sure that
intel_connector->mst_port is set before initializing MST connectors,
since in theory we could potentially check intel_connector->mst_port in
i915_hpd_poll_init_work() after registering the connector but before
having written it's value.
Signed-off-by: Lyude Paul
Reviewed-by: Ville Syrjälä
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dp_mst.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 8b71d64ebd9d..8cb4093f8bcc 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -441,6 +441,10 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
if (!intel_connector)
return NULL;
+ intel_connector->get_hw_state = intel_dp_mst_get_hw_state;
+ intel_connector->mst_port = intel_dp;
+ intel_connector->port = port;
+
connector = &intel_connector->base;
ret = drm_connector_init(dev, connector, &intel_dp_mst_connector_funcs,
DRM_MODE_CONNECTOR_DisplayPort);
@@ -451,10 +455,6 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
drm_connector_helper_add(connector,
&intel_dp_mst_connector_helper_funcs);
- intel_connector->get_hw_state = intel_dp_mst_get_hw_state;
- intel_connector->mst_port = intel_dp;
- intel_connector->port = port;
-
for_each_pipe(dev_priv, pipe) {
struct drm_encoder *enc =
&intel_dp->mst_encoders[pipe]->base.base;
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 0/5] drm/i915: HPD IRQ storm detection fixes
This series contains a fix for a problem which is very difficult to reproduce under normal circumstances without specialized testing hardware, along with a fix that seems to be required for some especially rebellious GM45 laptops. Lyude Paul (5): drm/i915: Fix possible race in intel_dp_add_mst_connector() drm/i915: Fix NULL deref when re-enabling HPD IRQs on systems with MST drm/i915: Fix threshold check in intel_hpd_irq_storm_detect() drm/i915: Clarify flow for disabling IRQs on storms drm/i915: Add short HPD IRQ storm detection for non-MST systems drivers/gpu/drm/i915/i915_debugfs.c | 74 + drivers/gpu/drm/i915/i915_drv.h | 5 +- drivers/gpu/drm/i915/i915_irq.c | 7 +++ drivers/gpu/drm/i915/intel_dp_mst.c | 8 +-- drivers/gpu/drm/i915/intel_hotplug.c | 83 +--- 5 files changed, 140 insertions(+), 37 deletions(-) -- 2.19.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: HPD IRQ storm detection fixes (rev4)
== Series Details == Series: drm/i915: HPD IRQ storm detection fixes (rev4) URL : https://patchwork.freedesktop.org/series/51556/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Fix possible race in intel_dp_add_mst_connector() Okay! Commit: drm/i915: Fix NULL deref when re-enabling HPD IRQs on systems with MST Okay! Commit: drm/i915: Fix threshold check in intel_hpd_irq_storm_detect() Okay! Commit: drm/i915: Clarify flow for disabling IRQs on storms Okay! Commit: drm/i915: Add short HPD IRQ storm detection for non-MST systems -drivers/gpu/drm/i915/selftests/../i915_drv.h:3705:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3708:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6 3/4] i915/dp/fec: Configure the Forward Error Correction bits.
If FEC is supported, the corresponding
DP_TP_CTL register bits have to be configured.
The driver has to program the FEC_ENABLE in DP_TP_CTL[30] register
and wait till FEC_STATUS in DP_TP_CTL[28] is 1.
Also add the warn message to make sure that the control
register is already active while enabling FEC.
v2:
- Change commit message. Configure fec state after
link training (Manasi, Gaurav)
- Remove redundent checks (Manasi)
- Remove the registers that get added automagically (Anusha)
v3: s/intel_dp_set_fec_state()/intel_dp_enable_fec_state() (Gaurav)
v4: rebased.
v5:
- Move the code to the proper spot, according to spec.(Ville)
- Use fec state as a check too.
v6: Pass intel_encoder, instead of intel_dp. (Ville)
Cc: dri-de...@lists.freedesktop.org
Cc: Gaurav K Singh
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Manasi Navare
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_ddi.c | 24
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1a84e8f98e66..209b64d2f27a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9148,6 +9148,7 @@ enum skl_power_gate {
#define _DP_TP_CTL_B 0x64140
#define DP_TP_CTL(port) _MMIO_PORT(port, _DP_TP_CTL_A, _DP_TP_CTL_B)
#define DP_TP_CTL_ENABLE (1 << 31)
+#define DP_TP_CTL_FEC_ENABLE (1 << 30)
#define DP_TP_CTL_MODE_SST(0 << 27)
#define DP_TP_CTL_MODE_MST(1 << 27)
#define DP_TP_CTL_FORCE_ACT (1 << 25)
@@ -9166,6 +9167,7 @@ enum skl_power_gate {
#define _DP_TP_STATUS_A0x64044
#define _DP_TP_STATUS_B0x64144
#define DP_TP_STATUS(port) _MMIO_PORT(port, _DP_TP_STATUS_A, _DP_TP_STATUS_B)
+#define DP_TP_STATUS_FEC_ENABLE_LIVE (1 << 28)
#define DP_TP_STATUS_IDLE_DONE(1 << 25)
#define DP_TP_STATUS_ACT_SENT (1 << 24)
#define DP_TP_STATUS_MODE_STATUS_MST (1 << 23)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 53a9b31e66a2..fad7385dbd76 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3065,6 +3065,28 @@ static void intel_dp_sink_set_fec_ready(struct intel_dp
*intel_dp,
DRM_DEBUG_KMS("Failed to get FEC enabled in sink\n");
}
+static void intel_ddi_enable_fec(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ enum port port = encoder->port;
+ u32 val;
+
+ /* FEC support exists for DP 1.4 only */
+ if (!crtc_state->fec_enable)
+ return;
+
+ val = I915_READ(DP_TP_CTL(port));
+ val |= DP_TP_CTL_FEC_ENABLE;
+ I915_WRITE(DP_TP_CTL(port), val);
+
+ if (intel_wait_for_register(dev_priv, DP_TP_STATUS(port),
+ DP_TP_STATUS_FEC_ENABLE_LIVE,
+ DP_TP_STATUS_FEC_ENABLE_LIVE,
+ 1))
+ DRM_ERROR("Timed out waiting for FEC Enable Status\n");
+}
+
static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state
*conn_state)
@@ -3110,6 +3132,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
*encoder,
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
+ intel_ddi_enable_fec(encoder, crtc_state);
+
icl_enable_phy_clock_gating(dig_port);
if (!is_mst)
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6 0/4] Forward Error Correction
With Display Compression, the bit error in the pixel stream can turn into a significant corruption on the screen. The DP1.4 adds FEC - Forward Error Correction scheme which uses Reed-Solomon parity/correction check generated by the source and used by the sink to detect and correct small numbers of bit errors in the compressed stream. v2: Avoid doing aux channel read everytime we check for FEC support. Instead cache the value of the DPCD registers, similar to the DSC implementaion (Jani) v3: Add fec as a state to crtc. Move around the code. (Ville) v4: s/can_fec/fec_enable; s/intel_dp_can_fec/intel_dp_supports_fec; Add intel_dp_source supports_fec() (Ville) v5: Reduce unwanted checks. Pass intel_encoder to fec func instead of intel_dp. Move code around to suitable place. v6: Remove warning. rebase. Rebased on top of: https://patchwork.freedesktop.org/series/51986/ Anusha Srivatsa (4): i915/dp/fec: Add fec_enable to the crtc state. drm/i915/fec: Set FEC_READY in FEC_CONFIGURATION i915/dp/fec: Configure the Forward Error Correction bits. drm/i915/fec: Disable FEC state. drivers/gpu/drm/i915/i915_reg.h | 2 + drivers/gpu/drm/i915/intel_ddi.c | 68 ++-- drivers/gpu/drm/i915/intel_dp.c | 28 +++-- drivers/gpu/drm/i915/intel_drv.h | 3 ++ 4 files changed, 94 insertions(+), 7 deletions(-) -- 2.19.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6 1/4] i915/dp/fec: Add fec_enable to the crtc state.
For DP 1.4 and above, Display Stream compression can be
enabled only if Forward Error Correctin can be performed.
Add a crtc state for FEC. Currently, the state
is determined by platform, DP and DSC being
enabled. Moving forward we can use the state
to have error correction on other scenarios too
if needed.
v2:
- Control compression_enable with the fec_enable
parameter in crtc state and with intel_dp_supports_fec()
(Ville)
- intel_dp_can_fec()/intel_dp_supports_fec()(manasi)
v3: Check for FEC support along with setting crtc state.
v4: add checks to intel_dp_source_supports_dsc.(manasi)
- Move intel_dp_supports_fec() closer to
intel_dp_supports_dsc() (Anusha)
Suggested-by: Ville Syrjala
Cc: dri-de...@lists.freedesktop.org
Cc: Ville Syrjala
Cc: Jani Nikula
Cc: Manasi Navare
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel_dp.c | 28 +---
drivers/gpu/drm/i915/intel_drv.h | 3 +++
2 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 73c00c5acf14..60e323662eea 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -545,7 +545,7 @@ intel_dp_mode_valid(struct drm_connector *connector,
dsc_slice_count =
drm_dp_dsc_sink_max_slice_count(intel_dp->dsc_dpcd,
true);
- } else {
+ } else if (drm_dp_sink_supports_fec(intel_dp->fec_capable)) {
dsc_max_output_bpp =
intel_dp_dsc_get_output_bpp(max_link_clock,
max_lanes,
@@ -1710,13 +1710,27 @@ struct link_config_limits {
int min_bpp, max_bpp;
};
+static bool intel_dp_source_supports_fec(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
+ enum port port = dig_port->base.port;
+
+ return INTEL_GEN(dev_priv) >= 11 && port != PORT_A;
+}
+
+static bool intel_dp_supports_fec(struct intel_dp *intel_dp)
+{
+ return intel_dp_source_supports_fec(intel_dp) &&
+ drm_dp_sink_supports_fec(intel_dp->fec_capable);
+}
+
static bool intel_dp_source_supports_dsc(struct intel_dp *intel_dp,
const struct intel_crtc_state
*pipe_config)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
- /* FIXME: FEC needed for external DP until then reject DSC on DP */
- if (!intel_dp_is_edp(intel_dp))
+ if (!intel_dp_supports_fec(intel_dp) && !intel_dp_is_edp(intel_dp))
return false;
return INTEL_GEN(dev_priv) >= 10 &&
@@ -1886,9 +1900,17 @@ static bool intel_dp_dsc_compute_config(struct intel_dp
*intel_dp,
u16 dsc_max_output_bpp = 0;
u8 dsc_dp_slice_count = 0;
+ pipe_config->fec_enable = !intel_dp_is_edp(intel_dp);
+
if (!intel_dp_supports_dsc(intel_dp, pipe_config))
return false;
+ /* DSC not supported if external DP sink does not support FEC */
+ if (pipe_config->fec_enable && !intel_dp_supports_fec(intel_dp)) {
+ DRM_DEBUG_KMS("Sink does not support Forward Error Correction,
disabling Display Compression\n");
+ return false;
+ }
+
/* DSC not supported for DSC sink BPC < 8 */
if (limits->max_bpp < 3 * DP_DSC_MIN_SUPPORTED_BPC) {
DRM_DEBUG_KMS("No DSC support for less than 8bpc\n");
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index dd22cdeaa673..997bea5fdf16 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -945,6 +945,9 @@ struct intel_crtc_state {
u8 slice_count;
} dsc_params;
struct drm_dsc_config dp_dsc_cfg;
+
+ /* Forward Error correction State */
+ bool fec_enable;
};
struct intel_crtc {
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6 2/4] drm/i915/fec: Set FEC_READY in FEC_CONFIGURATION
If the panel supports FEC, the driver has to
set the FEC_READY bit in the dpcd register:
FEC_CONFIGURATION.
This has to happen before link training.
v2: s/intel_dp_set_fec_ready/intel_dp_sink_set_fec_ready
- change commit message. (Gaurav)
v3: rebased. (r-b Manasi)
v4: Use fec crtc state, before setting FEC_READY
bit. (Anusha)
v5: Move to intel_ddi.c
- Make the function static (Anusha)
Cc: dri-de...@lists.freedesktop.org
Cc: Gaurav K Singh
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Manasi Navare
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel_ddi.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 46c1b9e12fbd..53a9b31e66a2 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3051,6 +3051,20 @@ static void icl_program_mg_dp_mode(struct
intel_digital_port *intel_dig_port)
I915_WRITE(MG_DP_MODE(port, 1), ln1);
}
+static void intel_dp_sink_set_fec_ready(struct intel_dp *intel_dp,
+ const struct intel_crtc_state
*crtc_state,
+ int state)
+{
+ int ret;
+
+ if (!crtc_state->fec_enable)
+ return;
+
+ ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_FEC_CONFIGURATION, state);
+ if (ret < 0)
+ DRM_DEBUG_KMS("Failed to get FEC enabled in sink\n");
+}
+
static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state
*conn_state)
@@ -3091,6 +3105,7 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
*encoder,
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_sink_set_decompression_state(intel_dp, crtc_state,
true);
+ intel_dp_sink_set_fec_ready(intel_dp, crtc_state, DP_FEC_READY);
intel_dp_start_link_train(intel_dp);
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6 4/4] drm/i915/fec: Disable FEC state.
Set the suitable bits in DP_TP_CTL to stop
bit correction when DSC is disabled.
v2:
- rebased.
- Add additional check for compression state. (Gaurav)
v3: rebased.
v4:
- Move the code to the proper spot according to spec (Ville)
- Use proper checks (manasi)
v5: Remove unnecessary checks (Ville)
v6: Resolve warnings. Add crtc_state as an argument to
intel_disable_ddi_buf(). (Manasi)
Cc: dri-de...@lists.freedesktop.org
Cc: Gaurav K Singh
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Manasi Navare
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel_ddi.c | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index fad7385dbd76..21af8fe1cf35 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3087,6 +3087,22 @@ static void intel_ddi_enable_fec(struct intel_encoder
*encoder,
DRM_ERROR("Timed out waiting for FEC Enable Status\n");
}
+static void intel_ddi_disable_fec_state(struct intel_encoder *encoder,
+ const struct intel_crtc_state
*crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ enum port port = encoder->port;
+ u32 val;
+
+ if (!crtc_state->fec_enable)
+ return;
+
+ val = I915_READ(DP_TP_CTL(port));
+ val &= ~DP_TP_CTL_FEC_ENABLE;
+ I915_WRITE(DP_TP_CTL(port), val);
+ POSTING_READ(DP_TP_CTL(port));
+}
+
static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state
*conn_state)
@@ -3230,10 +3246,12 @@ static void intel_ddi_pre_enable(struct intel_encoder
*encoder,
}
}
-static void intel_disable_ddi_buf(struct intel_encoder *encoder)
+static void intel_disable_ddi_buf(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum port port = encoder->port;
+
bool wait = false;
u32 val;
@@ -3249,6 +3267,9 @@ static void intel_disable_ddi_buf(struct intel_encoder
*encoder)
val |= DP_TP_CTL_LINK_TRAIN_PAT1;
I915_WRITE(DP_TP_CTL(port), val);
+ /* Disable FEC in DP Sink */
+ intel_ddi_disable_fec_state(encoder, crtc_state);
+
if (wait)
intel_wait_ddi_buf_idle(dev_priv, port);
}
@@ -3272,7 +3293,7 @@ static void intel_ddi_post_disable_dp(struct
intel_encoder *encoder,
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
}
- intel_disable_ddi_buf(encoder);
+ intel_disable_ddi_buf(encoder, old_crtc_state);
intel_edp_panel_vdd_on(intel_dp);
intel_edp_panel_off(intel_dp);
@@ -3295,7 +3316,7 @@ static void intel_ddi_post_disable_hdmi(struct
intel_encoder *encoder,
intel_ddi_disable_pipe_clock(old_crtc_state);
- intel_disable_ddi_buf(encoder);
+ intel_disable_ddi_buf(encoder, old_crtc_state);
intel_display_power_put(dev_priv, dig_port->ddi_io_power_domain);
@@ -3346,7 +3367,7 @@ void intel_ddi_fdi_post_disable(struct intel_encoder
*encoder,
val &= ~FDI_RX_ENABLE;
I915_WRITE(FDI_RX_CTL(PIPE_A), val);
- intel_disable_ddi_buf(encoder);
+ intel_disable_ddi_buf(encoder, old_crtc_state);
intel_ddi_clk_disable(encoder);
val = I915_READ(FDI_RX_MISC(PIPE_A));
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Forward Error Correction (rev6)
== Series Details == Series: Forward Error Correction (rev6) URL : https://patchwork.freedesktop.org/series/47848/ State : failure == Summary == Applying: i915/dp/fec: Add fec_enable to the crtc state. error: sha1 information is lacking or useless (drivers/gpu/drm/i915/intel_dp.c). error: could not build fake ancestor Patch failed at 0001 i915/dp/fec: Add fec_enable to the crtc state. Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 09/10] drm/i915: Keep PSR disabled after a driver reload after a PSR error
On Wed, 2018-10-31 at 16:45 -0700, Dhinakaran Pandiyan wrote:
> On Thu, 2018-10-25 at 18:17 -0700, José Roberto de Souza wrote:
> > If a PSR error happened and the driver is reloaded, the EDP_PSR_IIR
> > will still keep the error set even after the reset done in the
> > irq_preinstall and irq_uninstall hooks.
>
> Does this happen or are you suspecting it might? Is this because IIR
> clearing did not work or is it because of a new unhandled interrupt?
It happens, it is cleared I can read it back right after clear it and
the value is correct but it is still set. I did some tests like clear
IIR with the interruption unmasked but it also don't work.
>
> -DK
>
>
>
> > And enabling in this situation cause the screen to freeze in the
> > first time that PSR HW tries to activate so lets keep PSR disabled
> > to avoid any rendering problems.
> >
> > Cc: Dhinakaran Pandiyan
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/intel_psr.c | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 68201cc24d25..718270da1061 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -529,6 +529,19 @@ void intel_psr_compute_config(struct intel_dp
> > *intel_dp,
> > return;
> > }
> >
> > + /*
> > +* If a PSR error happened and the driver is reloaded, the
> > EDP_PSR_IIR
> > +* will still keep the error set even after the reset done in
> > the
> > +* irq_preinstall and irq_uninstall hooks.
> > +* And enabling in this situation cause the screen to freeze in
> > the
> > +* first time that PSR HW tries to activate so lets keep PSR
> > disabled
> > +* to avoid any rendering problems.
> > +*/
> > + if (I915_READ(EDP_PSR_IIR) & EDP_PSR_ERROR(TRANSCODER_EDP)) {
> > + DRM_DEBUG_KMS("PSR interruption error set\n");
> > + return;
> > + }
> > +
> > if (IS_HASWELL(dev_priv) &&
> > I915_READ(HSW_STEREO_3D_CTL(crtc_state->cpu_transcoder)) &
> > S3D_ENABLE) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] mm, drm/i915: mark pinned shmemfs pages as unevictable
On Tue, Nov 6, 2018 at 12:41 AM Michal Hocko wrote: > On Mon 05-11-18 22:33:13, Kuo-Hsin Yang wrote: > > OK, this function should not be specific to shmem pages. > > > > Is it OK to remove the #ifdef SHMEM surrounding > > check_move_unevictable_pages? > > Yes, I think so. Thanks for you review. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] mm, drm/i915: mark pinned shmemfs pages as unevictable
On Tue, Nov 6, 2018 at 2:52 AM Dave Hansen wrote: > > On 11/5/18 3:13 AM, Kuo-Hsin Yang wrote: > > -These are currently used in two places in the kernel: > > +These are currently used in three places in the kernel: > > > > (1) By ramfs to mark the address spaces of its inodes when they are > > created, > > and this mark remains for the life of the inode. > > @@ -154,6 +154,8 @@ These are currently used in two places in the kernel: > > swapped out; the application must touch the pages manually if it > > wants to > > ensure they're in memory. > > > > + (3) By the i915 driver to mark pinned address space until it's unpinned. > > At a minimum, I think we owe some documentation here of how to tell > approximately how much memory i915 is consuming with this mechanism. > The debugfs stuff sounds like a halfway reasonable way to approximate > it, although it's imperfect. OK, I will add more comments here. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the drm-msm tree with the drm-misc tree
Hi all,
Today's linux-next merge of the drm-msm tree got a conflict in:
drivers/gpu/drm/msm/hdmi/hdmi.c
between commit:
f384d7d514d1 ("drm: Convert to using %pOFn instead of device_node.name")
from the drm-misc tree and commit:
bdc309778907 ("drm: msm: Use DRM_DEV_* instead of dev_*")
from the drm-msm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/msm/hdmi/hdmi.c
index 23670907a29d,74ffc2412f68..
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@@ -579,7 -585,7 +585,7 @@@ static int msm_hdmi_bind(struct device
hdmi_cfg = (struct hdmi_platform_config *)
of_device_get_match_data(dev);
if (!hdmi_cfg) {
- dev_err(dev, "unknown hdmi_cfg: %pOFn\n", of_node);
- DRM_DEV_ERROR(dev, "unknown hdmi_cfg: %s\n", of_node->name);
++ DRM_DEV_ERROR(dev, "unknown hdmi_cfg: %pOFn\n", of_node);
return -ENXIO;
}
pgpECYgixMAMB.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v6 1/4] i915/dp/fec: Add fec_enable to the crtc state.
On Mon, Nov 05, 2018 at 03:31:47PM -0800, Anusha Srivatsa wrote:
> For DP 1.4 and above, Display Stream compression can be
> enabled only if Forward Error Correctin can be performed.
>
> Add a crtc state for FEC. Currently, the state
> is determined by platform, DP and DSC being
> enabled. Moving forward we can use the state
> to have error correction on other scenarios too
> if needed.
>
> v2:
> - Control compression_enable with the fec_enable
> parameter in crtc state and with intel_dp_supports_fec()
> (Ville)
>
> - intel_dp_can_fec()/intel_dp_supports_fec()(manasi)
>
> v3: Check for FEC support along with setting crtc state.
>
> v4: add checks to intel_dp_source_supports_dsc.(manasi)
> - Move intel_dp_supports_fec() closer to
> intel_dp_supports_dsc() (Anusha)
>
> Suggested-by: Ville Syrjala
> Cc: dri-de...@lists.freedesktop.org
> Cc: Ville Syrjala
> Cc: Jani Nikula
> Cc: Manasi Navare
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/intel_dp.c | 28 +---
> drivers/gpu/drm/i915/intel_drv.h | 3 +++
> 2 files changed, 28 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 73c00c5acf14..60e323662eea 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -545,7 +545,7 @@ intel_dp_mode_valid(struct drm_connector *connector,
> dsc_slice_count =
>
> drm_dp_dsc_sink_max_slice_count(intel_dp->dsc_dpcd,
> true);
> - } else {
> + } else if (drm_dp_sink_supports_fec(intel_dp->fec_capable)) {
> dsc_max_output_bpp =
> intel_dp_dsc_get_output_bpp(max_link_clock,
> max_lanes,
> @@ -1710,13 +1710,27 @@ struct link_config_limits {
> int min_bpp, max_bpp;
> };
>
> +static bool intel_dp_source_supports_fec(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> + enum port port = dig_port->base.port;
> +
> + return INTEL_GEN(dev_priv) >= 11 && port != PORT_A;
> +}
> +
> +static bool intel_dp_supports_fec(struct intel_dp *intel_dp)
> +{
> + return intel_dp_source_supports_fec(intel_dp) &&
> + drm_dp_sink_supports_fec(intel_dp->fec_capable);
> +}
> +
> static bool intel_dp_source_supports_dsc(struct intel_dp *intel_dp,
>const struct intel_crtc_state
> *pipe_config)
> {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>
> - /* FIXME: FEC needed for external DP until then reject DSC on DP */
> - if (!intel_dp_is_edp(intel_dp))
> + if (!intel_dp_supports_fec(intel_dp) && !intel_dp_is_edp(intel_dp))
> return false;
>
> return INTEL_GEN(dev_priv) >= 10 &&
> @@ -1886,9 +1900,17 @@ static bool intel_dp_dsc_compute_config(struct
> intel_dp *intel_dp,
> u16 dsc_max_output_bpp = 0;
> u8 dsc_dp_slice_count = 0;
>
> + pipe_config->fec_enable = !intel_dp_is_edp(intel_dp);
fec_enable state be set based on !intel_dp_is_edp() && intel_dp_supports_fec()
Because we enable fec in atomic ocmmit just based on this
crtc_state->fec_enable so
it should definitely be set based on intel_dp_supports_fec()
> +
> if (!intel_dp_supports_dsc(intel_dp, pipe_config))
> return false;
>
> + /* DSC not supported if external DP sink does not support FEC */
> + if (pipe_config->fec_enable && !intel_dp_supports_fec(intel_dp)) {
Then here just check for if (pipe_config->fec_enable)
Manasi
> + DRM_DEBUG_KMS("Sink does not support Forward Error Correction,
> disabling Display Compression\n");
> + return false;
> + }
> +
> /* DSC not supported for DSC sink BPC < 8 */
> if (limits->max_bpp < 3 * DP_DSC_MIN_SUPPORTED_BPC) {
> DRM_DEBUG_KMS("No DSC support for less than 8bpc\n");
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index dd22cdeaa673..997bea5fdf16 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -945,6 +945,9 @@ struct intel_crtc_state {
> u8 slice_count;
> } dsc_params;
> struct drm_dsc_config dp_dsc_cfg;
> +
> + /* Forward Error correction State */
> + bool fec_enable;
> };
>
> struct intel_crtc {
> --
> 2.19.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v6 2/4] drm/i915/fec: Set FEC_READY in FEC_CONFIGURATION
On Mon, Nov 05, 2018 at 03:31:48PM -0800, Anusha Srivatsa wrote:
> If the panel supports FEC, the driver has to
> set the FEC_READY bit in the dpcd register:
> FEC_CONFIGURATION.
>
> This has to happen before link training.
>
> v2: s/intel_dp_set_fec_ready/intel_dp_sink_set_fec_ready
>- change commit message. (Gaurav)
>
> v3: rebased. (r-b Manasi)
>
> v4: Use fec crtc state, before setting FEC_READY
> bit. (Anusha)
>
> v5: Move to intel_ddi.c
> - Make the function static (Anusha)
>
> Cc: dri-de...@lists.freedesktop.org
> Cc: Gaurav K Singh
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Manasi Navare
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 46c1b9e12fbd..53a9b31e66a2 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3051,6 +3051,20 @@ static void icl_program_mg_dp_mode(struct
> intel_digital_port *intel_dig_port)
> I915_WRITE(MG_DP_MODE(port, 1), ln1);
> }
>
> +static void intel_dp_sink_set_fec_ready(struct intel_dp *intel_dp,
> + const struct intel_crtc_state
> *crtc_state,
> + int state)
u8 state should be good enough since you are writing only a byte here
> +{
> + int ret;
> +
> + if (!crtc_state->fec_enable)
> + return;
> +
> + ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_FEC_CONFIGURATION, state);
> + if (ret < 0)
This should ret <=0 since even if it writes 0 bytes its an error. Infact you
dont need ret
you can just say"
if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_FEC_CONFIGURATION, state) <= 0)
After the above changes,
Reviewed-by: Manasi Navare
Manasi
> + DRM_DEBUG_KMS("Failed to get FEC enabled in sink\n");
> +}
> +
> static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
> const struct intel_crtc_state *crtc_state,
> const struct drm_connector_state
> *conn_state)
> @@ -3091,6 +3105,7 @@ static void intel_ddi_pre_enable_dp(struct
> intel_encoder *encoder,
> intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> intel_dp_sink_set_decompression_state(intel_dp, crtc_state,
> true);
> + intel_dp_sink_set_fec_ready(intel_dp, crtc_state, DP_FEC_READY);
> intel_dp_start_link_train(intel_dp);
> if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> intel_dp_stop_link_train(intel_dp);
> --
> 2.19.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 04/19] drm/dsc: Add helpers for DSC picture parameter set infoframes
>-Original Message-
>From: Navare, Manasi D
>Sent: Friday, November 2, 2018 2:31 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
>Cc: Navare, Manasi D ; Jani Nikula
>; Ville Syrjala ;
>Srivatsa, Anusha ; Harry Wentland
>
>Subject: [PATCH v8 04/19] drm/dsc: Add helpers for DSC picture parameter set
>infoframes
>
>According to Display Stream compression spec 1.2, the picture parameter set
>metadata is sent from source to sink device using the DP Secondary data packet.
>An infoframe is formed for the PPS SDP header and PPS SDP payload bytes.
>This patch adds helpers to fill the PPS SDP header and PPS SDP payload
>according
>to the DSC 1.2 specification.
>
>v7:
>* Use BUILD_BUG_ON() to protect changing struct size (Ville)
>* Remove typecaseting (Ville)
>* Include byteorder.h in drm_dsc.c (Ville)
>v6:
>* Use proper sequence points for breaking down the assignments (Chris Wilson)
>* Use SPDX identifier
>v5:
>Do not use bitfields for DRM structs (Jani N)
>v4:
>* Use DSC constants for params that dont change across configurations
>v3:
>* Add reference to added kernel-docs in
>Documentation/gpu/drm-kms-helpers.rst (Daniel Vetter)
>
>v2:
>* Add EXPORT_SYMBOL for the drm functions (Manasi)
>
>Cc: dri-de...@lists.freedesktop.org
>Cc: Jani Nikula
>Cc: Ville Syrjala
>Cc: Anusha Srivatsa
>Cc: Harry Wentland
>Signed-off-by: Manasi Navare
>Acked-by: Harry Wentland
>---
> Documentation/gpu/drm-kms-helpers.rst | 12 ++
> drivers/gpu/drm/Makefile | 2 +-
> drivers/gpu/drm/drm_dsc.c | 228 ++
> include/drm/drm_dsc.h | 21 +++
> 4 files changed, 262 insertions(+), 1 deletion(-) create mode 100644
>drivers/gpu/drm/drm_dsc.c
>
>diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-
>kms-helpers.rst
>index 4b4dc236ef6f..b422eb8edf16 100644
>--- a/Documentation/gpu/drm-kms-helpers.rst
>+++ b/Documentation/gpu/drm-kms-helpers.rst
>@@ -232,6 +232,18 @@ MIPI DSI Helper Functions Reference .. kernel-doc::
>drivers/gpu/drm/drm_mipi_dsi.c
>:export:
>
>+Display Stream Compression Helper Functions Reference
>+=
>+
>+.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
>+ :doc: dsc helpers
>+
>+.. kernel-doc:: include/drm/drm_dsc.h
>+ :internal:
>+
>+.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
>+ :export:
>+
> Output Probing Helper Functions Reference
>=
>
>diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index
>576ba985e138..3a3e6fb6d476 100644
>--- a/drivers/gpu/drm/Makefile
>+++ b/drivers/gpu/drm/Makefile
>@@ -32,7 +32,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
> drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>
>-drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
>+drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o
>+drm_probe_helper.o \
> drm_plane_helper.o drm_dp_mst_topology.o
>drm_atomic_helper.o \
> drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
> drm_simple_kms_helper.o drm_modeset_helper.o \ diff --git
>a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c new file mode
>100644 index ..3a4942c1ae3b
>--- /dev/null
>+++ b/drivers/gpu/drm/drm_dsc.c
>@@ -0,0 +1,228 @@
>+// SPDX-License-Identifier: MIT
Nit-
In some places the License is within /* */ like comment
Is the right way to Add License Identifier?
>+/*
>+ * Copyright © 2018 Intel Corp
>+ *
>+ * Author:
>+ * Manasi Navare */
>+
>+#include
>+#include
>+#include
>+#include
>+#include
>+#include
>+#include
>+
>+/**
>+ * DOC: dsc helpers
>+ *
>+ * These functions contain some common logic and helpers to deal with
>+VESA
>+ * Display Stream Compression standard required for DSC on Display
>+Port/eDP or
>+ * MIPI display interfaces.
>+ */
>+
>+/**
>+ * drm_dsc_dp_pps_header_init() - Initializes the PPS Header
>+ * for DisplayPort as per the DP 1.4 spec.
>+ * @pps_sdp: Secondary data packet for DSC Picture Parameter Set */
>+void drm_dsc_dp_pps_header_init(struct drm_dsc_pps_infoframe *pps_sdp)
>+{
>+ memset(&pps_sdp->pps_header, 0, sizeof(pps_sdp->pps_header));
>+
>+ pps_sdp->pps_header.HB1 = DP_SDP_PPS;
>+ pps_sdp->pps_header.HB2 =
>DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1;
>+}
>+EXPORT_SYMBOL(drm_dsc_dp_pps_header_init);
>+
>+/**
>+ * drm_dsc_pps_infoframe_pack() - Populates the DSC PPS infoframe
>+ * using the DSC configuration parameters in the order expected
>+ * by the DSC Display Sink device. For the DSC, the sink device
>+ * expects the PPS payload in the big endian format for the fields
>+ * that span more than 1 byte.
>+ *
>+ * @pps_sdp:
>+ * Secondary data packet for DSC Picture Parameter Set
>+ * @dsc_cfg:
>+ * DSC Configuration data filled by driver */ void
>+drm_dsc_pps_infoframe_pack(struct drm_dsc_pps_infoframe *pps_sdp,
>+
Re: [Intel-gfx] [PATCH v4 2/2] drm/i915/icl: Define MOCS table for Icelake
On 05/11/2018 05:50, Tomasz Lis wrote:
The table has been unified across OSes to minimize virtualization overhead.
The MOCS table is now published as part of bspec, and versioned. Entries
are supposed to never be modified, but new ones can be added. Adding
entries increases table version. The patch includes version 1 entries.
Meaning of each entry is now explained in bspec, and user mode clients
are expected to know what each entry means. The 3 entries used for previous
platforms are still compatible with their legacy definitions, but that is
not guaranteed to be true for future platforms.
v2: Fixed SCC values, improved commit comment (Daniele)
v3: Improved MOCS table comment (Daniele)
v4: Moved new entries below gen9 ones. Put common entries into
definition to be used in multiple arrays. (Lucas)
BSpec: 34007
BSpec: 560
Signed-off-by: Tomasz Lis
Reviewed-by: Daniele Ceraolo Spurio (v3)
The table is the same as v3 and I'm ok with the new approach, so my r-b
stands.
Thanks,
Daniele
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Daniele Ceraolo Spurio
Cc: Zhenyu Wang
Cc: Zhi A Wang
Cc: Anuj Phogat
Cc: Adam Cetnerowski
Cc: Piotr Rozenfeld
Cc: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_mocs.c | 249 +++---
1 file changed, 235 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_mocs.c
b/drivers/gpu/drm/i915/intel_mocs.c
index 76aed59..2a1e5f0 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -44,6 +44,8 @@ struct drm_i915_mocs_table {
#define LE_SCC(value) ((value) << 8)
#define LE_PFM(value) ((value) << 11)
#define LE_SCF(value) ((value) << 14)
+#define LE_CoS(value) ((value) << 15)
+#define LE_SSE(value) ((value) << 17)
/* Defines for the tables (LNCFMOCS0 - LNCFMOCS31) - two entries per word */
#define L3_ESC(value) ((value) << 0)
@@ -80,21 +82,21 @@ struct drm_i915_mocs_table {
* LNCFCMOCS0 - LNCFCMOCS32 registers.
*
* These tables are intended to be kept reasonably consistent across
- * platforms. However some of the fields are not applicable to all of
- * them.
+ * HW platforms, and for ICL+, be identical across OSes. To achieve
+ * that, for Icelake and above, list of entries is published as part
+ * of bspec.
*
* Entries not part of the following tables are undefined as far as
- * userspace is concerned and shouldn't be relied upon. For the time
- * being they will be implicitly initialized to the strictest caching
- * configuration (uncached) to guarantee forwards compatibility with
- * userspace programs written against more recent kernels providing
- * additional MOCS entries.
+ * userspace is concerned and shouldn't be relied upon.
*
- * NOTE: These tables MUST start with being uncached and the length
- * MUST be less than 63 as the last two registers are reserved
- * by the hardware. These tables are part of the kernel ABI and
- * may only be updated incrementally by adding entries at the
- * end.
+ * The last two entries are reserved by the hardware. For ICL+ they
+ * should be initialized according to bspec and never used, for older
+ * platforms they should never be written to.
+ *
+ * NOTE: These tables are part of bspec and defined as part of hardware
+ * interface for ICL+. For older platforms, they are part of kernel
+ * ABI. It is expected that existing entries will remain constant
+ * and the tables will only be updated by adding new entries.
*/
#define GEN9_MOCS_TABLE \
@@ -144,6 +146,222 @@ static const struct drm_i915_mocs_entry
broxton_mocs_table[] = {
},
};
+#define GEN11_MOCS_TABLE \
+ [0] = { \
+ /* Base - Uncached (Deprecated) */ \
+ .control_value = LE_CACHEABILITY(LE_UC) | \
+ LE_TGT_CACHE(LE_TC_LLC) | \
+ LE_LRUM(0) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) | \
+ LE_PFM(0) | LE_SCF(0) | LE_CoS(0) | LE_SSE(0), \
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC), \
+ }, \
+ [1] = { \
+ /* Base - L3 + LeCC:PAT (Deprecated) */ \
+ .control_value = LE_CACHEABILITY(LE_PAGETABLE) | \
+ LE_TGT_CACHE(LE_TC_LLC) | \
+ LE_LRUM(0) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) | \
+ LE_PFM(0) | LE_SCF(0) | LE_CoS(0) | LE_SSE(0), \
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB), \
+ }, \
+ [2] = { \
+ /* Base - L3 + LLC */ \
+ .control_value = LE_CACHEABILITY(LE_WB) | \
+ LE_TGT_CACHE(LE_TC_LLC) | \
+ LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) | \
+ LE_PFM(0) | LE_SCF(0) | LE_CoS(0) | LE_SSE(0), \
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB)
[Intel-gfx] [PATCH] drm/framebuffer: Expose only modifiers that support at least a format
Allows drivers to pass a larger modifier array, thereby avoiding
declarations of static modifier arrays that are only slight different
for each plane.
Cc: dri-de...@lists.freedesktop.org
Cc: Ville Syrjälä
Suggested-by: Ville Syrjälä
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/drm_plane.c | 35 +++
1 file changed, 27 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 1fa98bd12003..1546ffbf8e36 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -179,8 +179,8 @@ int drm_universal_plane_init(struct drm_device *dev, struct
drm_plane *plane,
const char *name, ...)
{
struct drm_mode_config *config = &dev->mode_config;
- unsigned int format_modifier_count = 0;
- int ret;
+ unsigned int format_modifier_count, in_modifier_count = 0;
+ int ret, i;
/* plane index is used with 32bit bitmasks */
if (WARN_ON(config->num_total_plane >= 32))
@@ -216,22 +216,43 @@ int drm_universal_plane_init(struct drm_device *dev,
struct drm_plane *plane,
if (format_modifiers) {
const uint64_t *temp_modifiers = format_modifiers;
+
while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
- format_modifier_count++;
+ in_modifier_count++;
}
- plane->modifier_count = format_modifier_count;
- plane->modifiers = kmalloc_array(format_modifier_count,
+ plane->modifiers = kmalloc_array(in_modifier_count,
sizeof(format_modifiers[0]),
GFP_KERNEL);
- if (format_modifier_count && !plane->modifiers) {
+ if (in_modifier_count && !plane->modifiers) {
DRM_DEBUG_KMS("out of memory when allocating plane\n");
kfree(plane->format_types);
drm_mode_object_unregister(dev, &plane->base);
return -ENOMEM;
}
+ for (i = 0, format_modifier_count = 0; i < in_modifier_count; i++) {
+ int j;
+
+ for (j = 0; funcs->format_mod_supported && j < format_count;
j++)
+ if (funcs->format_mod_supported(plane, formats[j],
+ format_modifiers[i]))
+ break;
+
+ if (j < format_count)
+ plane->modifiers[format_modifier_count++] =
+ format_modifiers[i];
+ }
+
+ if (format_modifier_count < in_modifier_count) {
+ size_t size;
+
+ size = format_modifier_count * sizeof(format_modifiers[0]);
+ plane->modifiers = krealloc(plane->modifiers, size, GFP_KERNEL);
+ }
+ plane->modifier_count = format_modifier_count;
+
if (name) {
va_list ap;
@@ -251,8 +272,6 @@ int drm_universal_plane_init(struct drm_device *dev, struct
drm_plane *plane,
memcpy(plane->format_types, formats, format_count * sizeof(uint32_t));
plane->format_count = format_count;
- memcpy(plane->modifiers, format_modifiers,
- format_modifier_count * sizeof(format_modifiers[0]));
plane->possible_crtcs = possible_crtcs;
plane->type = type;
--
2.14.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 drm/framebuffer: Expose only modifiers that support at least a format
== Series Details == Series: drm/framebuffer: Expose only modifiers that support at least a format URL : https://patchwork.freedesktop.org/series/52064/ State : warning == Summary == $ dim checkpatch origin/drm-tip dcf2012746d9 drm/framebuffer: Expose only modifiers that support at least a format -:75: WARNING:KREALLOC_ARG_REUSE: Reusing the krealloc arg is almost always a bug #75: FILE: drivers/gpu/drm/drm_plane.c:252: + plane->modifiers = krealloc(plane->modifiers, size, GFP_KERNEL); total: 0 errors, 1 warnings, 0 checks, 65 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/4] drm/i915: Get active pending request for given context
From: Praveen Diwakar
This patch gives us the active pending request count which is yet
to be submitted to the GPU
Signed-off-by: Praveen Diwakar
Signed-off-by: Yogesh Marathe
Signed-off-by: Aravindan Muthukumar
Signed-off-by: Kedar J Karanje
Signed-off-by: Ankit Navik
Suggested-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.c| 1 +
drivers/gpu/drm/i915/i915_drv.h| 5 +
drivers/gpu/drm/i915/i915_gem_context.c| 1 +
drivers/gpu/drm/i915/i915_gem_context.h| 6 ++
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 +
drivers/gpu/drm/i915/intel_lrc.c | 6 ++
6 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f8cfd16..d37c46e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -903,6 +903,7 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
mutex_init(&dev_priv->av_mutex);
mutex_init(&dev_priv->wm.wm_mutex);
mutex_init(&dev_priv->pps_mutex);
+ mutex_init(&dev_priv->pred_mutex);
i915_memcpy_init_early(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4aca534..137ec33 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1609,6 +1609,11 @@ struct drm_i915_private {
* controller on different i2c buses. */
struct mutex gmbus_mutex;
+ /** pred_mutex protects against councurrent usage of pending
+* request counter for multiple contexts
+*/
+ struct mutex pred_mutex;
+
/**
* Base address of the gmbus and gpio block.
*/
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index b10770c..0bcbe32 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -387,6 +387,7 @@ i915_gem_create_context(struct drm_i915_private *dev_priv,
}
trace_i915_context_create(ctx);
+ atomic_set(&ctx->req_cnt, 0);
return ctx;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index b116e49..04e3ff7 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -194,6 +194,12 @@ struct i915_gem_context {
* context close.
*/
struct list_head handles_list;
+
+ /** req_cnt: tracks the pending commands, based on which we decide to
+* go for low/medium/high load configuration of the GPU, this is
+* controlled via a mutex
+*/
+ atomic_t req_cnt;
};
static inline bool i915_gem_context_is_closed(const struct i915_gem_context
*ctx)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 3f0c612..8afa2a5 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2178,6 +2178,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
struct drm_syncobj **fences)
{
struct i915_execbuffer eb;
+ struct drm_i915_private *dev_priv = to_i915(dev);
struct dma_fence *in_fence = NULL;
struct sync_file *out_fence = NULL;
int out_fence_fd = -1;
@@ -2390,6 +2391,10 @@ i915_gem_do_execbuffer(struct drm_device *dev,
*/
eb.request->batch = eb.batch;
+ mutex_lock(&dev_priv->pred_mutex);
+ atomic_inc(&eb.ctx->req_cnt);
+ mutex_unlock(&dev_priv->pred_mutex);
+
trace_i915_request_queue(eb.request, eb.batch_flags);
err = eb_submit(&eb);
err_request:
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 1744792..bcbb66b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -728,6 +728,12 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
trace_i915_request_in(rq, port_index(port, execlists));
last = rq;
submit = true;
+
+ mutex_lock(&rq->i915->pred_mutex);
+ if (atomic_read(&rq->gem_context->req_cnt) > 0)
+ atomic_dec(&rq->gem_context->req_cnt);
+
+ mutex_unlock(&rq->i915->pred_mutex);
}
rb_erase_cached(&p->node, &execlists->queue);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/4] drm/i915: set optimum eu/slice/sub-slice configuration based on load type
From: Praveen Diwakar
This patch will select optimum eu/slice/sub-slice configuration based on
type of load (low, medium, high) as input.
Based on our readings and experiments we have predefined set of optimum
configuration for each platform(CHT, KBL).
i915_gem_context_set_load_type will select optimum configuration from
pre-defined optimum configuration table(opt_config).
It also introduce flag update_render_config which can set by any governor.
Signed-off-by: Praveen Diwakar
Signed-off-by: Yogesh Marathe
Signed-off-by: Aravindan Muthukumar
Signed-off-by: Kedar J Karanje
Signed-off-by: Ankit Navik
Suggested-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem_context.c | 21 +++
drivers/gpu/drm/i915/i915_gem_context.h | 30 ++
drivers/gpu/drm/i915/intel_device_info.c | 44 ++--
drivers/gpu/drm/i915/intel_lrc.c | 4 ++-
5 files changed, 98 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 137ec33..f1b16d0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1686,6 +1686,8 @@ struct drm_i915_private {
struct drm_i915_fence_reg fence_regs[I915_MAX_NUM_FENCES]; /* assume
965 */
int num_fence_regs; /* 8 on pre-965, 16 otherwise */
+ struct optimum_config opt_config[LOAD_TYPE_MAX];
+
unsigned int fsb_freq, mem_freq, is_ddr3;
unsigned int skl_preferred_vco_freq;
unsigned int max_cdclk_freq;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index d040858..28ff868 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -388,14 +388,35 @@ i915_gem_create_context(struct drm_i915_private *dev_priv,
trace_i915_context_create(ctx);
atomic_set(&ctx->req_cnt, 0);
+ ctx->update_render_config = 0;
ctx->slice_cnt = hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask);
ctx->subslice_cnt = hweight8(
INTEL_INFO(dev_priv)->sseu.subslice_mask[0]);
ctx->eu_cnt = INTEL_INFO(dev_priv)->sseu.eu_per_subslice;
+ ctx->load_type = 0;
+ ctx->pending_load_type = 0;
return ctx;
}
+
+void i915_gem_context_set_load_type(struct i915_gem_context *ctx,
+ enum gem_load_type type)
+{
+ struct drm_i915_private *dev_priv = ctx->i915;
+
+ /* Call opt_config to get correct configuration for eu,slice,subslice */
+ ctx->slice_cnt = dev_priv->opt_config[type].slice;
+ ctx->subslice_cnt = dev_priv->opt_config[type].subslice;
+ ctx->eu_cnt = dev_priv->opt_config[type].eu;
+
+ /* Enabling this to update the rpcs */
+ if (ctx->pending_load_type != type)
+ ctx->update_render_config = 1;
+
+ ctx->pending_load_type = type;
+}
+
/**
* i915_gem_context_create_gvt - create a GVT GEM context
* @dev: drm device *
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index 2b3bf09..9345aa3 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -53,6 +53,19 @@ struct intel_context_ops {
void (*destroy)(struct intel_context *ce);
};
+enum gem_load_type {
+ LOAD_TYPE_LOW,
+ LOAD_TYPE_MEDIUM,
+ LOAD_TYPE_HIGH,
+ LOAD_TYPE_MAX
+};
+
+struct optimum_config {
+ u8 slice;
+ u8 subslice;
+ u8 eu;
+};
+
/**
* struct i915_gem_context - client state
*
@@ -209,6 +222,21 @@ struct i915_gem_context {
/** eu_cnt: used to set the # of eu to be enabled. */
u8 eu_cnt;
+
+ /** update_render_config: to track the updates to the render
+* configuration (S/SS/EU Configuration on the GPU)
+*/
+ bool update_render_config;
+
+ /** load_type: The designated load_type (high/medium/low) for a given
+* number of pending commands in the command queue.
+*/
+ enum gem_load_type load_type;
+
+ /** pending_load_type: The earlier load type that the GPU was configured
+* for (high/medium/low).
+*/
+ enum gem_load_type pending_load_type;
};
static inline bool i915_gem_context_is_closed(const struct i915_gem_context
*ctx)
@@ -337,6 +365,8 @@ int i915_gem_context_setparam_ioctl(struct drm_device *dev,
void *data,
struct drm_file *file_priv);
int i915_gem_context_reset_stats_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
+void i915_gem_context_set_load_type(struct i915_gem_context *ctx,
+ enum gem_load_type type);
struct i915_gem_context *
i915_gem_context_create_kernel(struct drm_i915_private *i915, int prio);
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
ind
[Intel-gfx] [PATCH v2 4/4] drm/i915: Predictive governor to control eu/slice/subslice
From: Praveen Diwakar
High resoluton timer is used for predictive governor to control
eu/slice/subslice based on workloads.
Debugfs is provided to enable/disable/update timer configuration
Signed-off-by: Praveen Diwakar
Signed-off-by: Yogesh Marathe
Signed-off-by: Aravindan Muthukumar
Signed-off-by: Kedar J Karanje
Signed-off-by: Ankit Navik
Suggested-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 88 -
drivers/gpu/drm/i915/i915_drv.h | 3 ++
2 files changed, 90 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index f9ce35d..0f368f6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4740,6 +4740,90 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_drrs_status", i915_drrs_status, 0},
{"i915_rps_boost_info", i915_rps_boost_info, 0},
};
+
+#define PENDING_REQ_0 0 /* No active request pending */
+
+/*
+ * Anything above threshold is considered as HIGH load, less is considered
+ * as LOW load and equal is considered as MEDIAUM load.
+ *
+ * The threshold value of three active requests pending.
+ */
+#define PENDING_REQ_3 3
+
+static int predictive_load_enable;
+
+static enum hrtimer_restart predictive_load_cb(struct hrtimer *hrtimer)
+{
+ struct drm_i915_private *dev_priv =
+ container_of(hrtimer, typeof(*dev_priv), pred_timer);
+ struct i915_gem_context *ctx;
+ atomic_t req_pending;
+
+ list_for_each_entry(ctx, &dev_priv->contexts.list, link) {
+
+ if (!ctx->name)
+ continue;
+
+ mutex_lock(&dev_priv->pred_mutex);
+ atomic_set(&req_pending, atomic_read(&ctx->req_cnt));
+ mutex_unlock(&dev_priv->pred_mutex);
+
+ if (atomic_read(&req_pending) == PENDING_REQ_0)
+ continue;
+
+ if (atomic_read(&req_pending) > PENDING_REQ_3)
+ ctx->load_type = LOAD_TYPE_HIGH;
+ else if (atomic_read(&req_pending) == PENDING_REQ_3)
+ ctx->load_type = LOAD_TYPE_MEDIUM;
+ else
+ ctx->load_type = LOAD_TYPE_LOW;
+
+ i915_gem_context_set_load_type(ctx, ctx->load_type);
+ }
+
+ hrtimer_forward_now(hrtimer,
+ ms_to_ktime(predictive_load_enable));
+
+ return HRTIMER_RESTART;
+}
+
+static int
+i915_predictive_load_get(void *data, u64 *val)
+{
+ *val = predictive_load_enable;
+ return 0;
+}
+
+static int
+i915_predictive_load_set(void *data, u64 val)
+{
+ struct drm_i915_private *dev_priv = data;
+
+ predictive_load_enable = val;
+
+ if (predictive_load_enable) {
+ if (!dev_priv->predictive_load_timer_init) {
+ hrtimer_init(&dev_priv->pred_timer, CLOCK_MONOTONIC,
+ HRTIMER_MODE_REL);
+ dev_priv->pred_timer.function = predictive_load_cb;
+ dev_priv->predictive_load_timer_init = 1;
+ }
+
+ hrtimer_start(&dev_priv->pred_timer,
+ ms_to_ktime(predictive_load_enable),
+ HRTIMER_MODE_REL_PINNED);
+ } else {
+ hrtimer_cancel(&dev_priv->pred_timer);
+ }
+
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_predictive_load_ctl,
+ i915_predictive_load_get, i915_predictive_load_set,
+ "%llu\n");
+
#define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)
static const struct i915_debugfs_files {
@@ -4769,7 +4853,9 @@ static const struct i915_debugfs_files {
{"i915_hpd_storm_ctl", &i915_hpd_storm_ctl_fops},
{"i915_ipc_status", &i915_ipc_status_fops},
{"i915_drrs_ctl", &i915_drrs_ctl_fops},
- {"i915_edp_psr_debug", &i915_edp_psr_debug_fops}
+ {"i915_edp_psr_debug", &i915_edp_psr_debug_fops},
+ /* FIXME: When feature will become real, move to sysfs */
+ {"i915_predictive_load_ctl", &i915_predictive_load_ctl}
};
int i915_debugfs_register(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f1b16d0..72ddd63 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1686,7 +1686,10 @@ struct drm_i915_private {
struct drm_i915_fence_reg fence_regs[I915_MAX_NUM_FENCES]; /* assume
965 */
int num_fence_regs; /* 8 on pre-965, 16 otherwise */
+ /* optimal slice/subslice/EU configration state */
struct optimum_config opt_config[LOAD_TYPE_MAX];
+ struct hrtimer pred_timer;
+ int predictive_load_timer_init;
unsigned int fsb_freq, mem_freq, is_ddr3;
unsigned int skl_preferred_vco_freq;
--
2.7.4
__
[Intel-gfx] [PATCH v2 2/4] drm/i915: Update render power clock state configuration for given context
From: Praveen Diwakar
This patch will update power clock state register at runtime base on the
flag which can set by any governor which computes load and want to update
rpcs register.
subsequent patches will have a timer based governor which computes pending
load/request.
Signed-off-by: Praveen Diwakar
Signed-off-by: Yogesh Marathe
Signed-off-by: Aravindan Muthukumar
Signed-off-by: Kedar J Karanje
Signed-off-by: Ankit Navik
Suggested-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_context.c | 4
drivers/gpu/drm/i915/i915_gem_context.h | 9 +
drivers/gpu/drm/i915/intel_lrc.c| 12 +++-
3 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 0bcbe32..d040858 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -388,6 +388,10 @@ i915_gem_create_context(struct drm_i915_private *dev_priv,
trace_i915_context_create(ctx);
atomic_set(&ctx->req_cnt, 0);
+ ctx->slice_cnt = hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask);
+ ctx->subslice_cnt = hweight8(
+ INTEL_INFO(dev_priv)->sseu.subslice_mask[0]);
+ ctx->eu_cnt = INTEL_INFO(dev_priv)->sseu.eu_per_subslice;
return ctx;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index 04e3ff7..2b3bf09 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -200,6 +200,15 @@ struct i915_gem_context {
* controlled via a mutex
*/
atomic_t req_cnt;
+
+ /** slice_cnt: used to set the # of slices to be enabled. */
+ u8 slice_cnt;
+
+ /** subslice_cnt: used to set the # of subslices to be enabled. */
+ u8 subslice_cnt;
+
+ /** eu_cnt: used to set the # of eu to be enabled. */
+ u8 eu_cnt;
};
static inline bool i915_gem_context_is_closed(const struct i915_gem_context
*ctx)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index bcbb66b..a8ab71a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -171,6 +171,7 @@ static void execlists_init_reg_state(u32 *reg_state,
struct i915_gem_context *ctx,
struct intel_engine_cs *engine,
struct intel_ring *ring);
+static u32 make_rpcs(struct drm_i915_private *dev_priv);
static inline struct i915_priolist *to_priolist(struct rb_node *rb)
{
@@ -417,12 +418,21 @@ execlists_update_context_pdps(struct i915_hw_ppgtt
*ppgtt, u32 *reg_state)
static u64 execlists_update_context(struct i915_request *rq)
{
+ u32 rpcs_config = 0;
struct intel_context *ce = rq->hw_context;
+ u32 *reg_state = ce->lrc_reg_state;
+ struct i915_gem_context *ctx = rq->gem_context;
struct i915_hw_ppgtt *ppgtt =
rq->gem_context->ppgtt ?: rq->i915->mm.aliasing_ppgtt;
- u32 *reg_state = ce->lrc_reg_state;
reg_state[CTX_RING_TAIL+1] = intel_ring_set_tail(rq->ring, rq->tail);
+ /* FIXME: To avoid stale rpcs config, move it to context_pin */
+ if (ctx->pid && ctx->name && (rq->engine->id == RCS)) {
+ rpcs_config = make_rpcs(ctx->i915);
+ reg_state[CTX_LRI_HEADER_2] = MI_LOAD_REGISTER_IMM(1);
+ CTX_REG(reg_state, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE,
+ rpcs_config);
+ }
/* True 32b PPGTT with dynamic page allocation: update PDP
* registers and point the unallocated PDPs to scratch page.
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/4] Dynamic EU configuration of Slice/Subslice/EU.
drm/i915: Context aware user agnostic EU/Slice/Sub-slice control within kernel Current GPU configuration code for i915 does not allow us to change EU/Slice/Sub-slice configuration dynamically. Its done only once while context is created. While particular graphics application is running, if we examine the command requests from user space, we observe that command density is not consistent. It means there is scope to change the graphics configuration dynamically even while context is running actively. This patch series proposes the solution to find the active pending load for all active context at given time and based on that, dynamically perform graphics configuration for each context. We use a hr (high resolution) timer with i915 driver in kernel to get a callback every few milliseconds (this timer value can be configured through debugfs, default is '0' indicating timer is in disabled state i.e. original system without any intervention).In the timer callback, we examine pending commands for a context in the queue, essentially, we intercept them before they are executed by GPU and we update context with required number of EUs. Two questions, how did we arrive at right timer value? and what's the right number of EUs? For the prior one, empirical data to achieve best performance in least power was considered. For the later one, we roughly categorized number of EUs logically based on platform. Now we compare number of pending commands with a particular threshold and then set number of EUs accordingly with update context. That threshold is also based on experiments & findings. If GPU is able to catch up with CPU, typically there are no pending commands, the EU config would remain unchanged there. In case there are more pending commands we reprogram context with higher number of EUs. Please note, here we are changing EUs even while context is running by examining pending commands every 'x' milliseconds. With this solution in place, on KBL-GT3 + Android we saw following pnp benefits, power numbers mentioned here are system power. App /KPI | % Power | | Benefit | | (mW) | -| 3D Mark (Ice storm)| 2.30% | TRex On screen | 2.49% | TRex Off screen| 1.32% | ManhattanOn screen | 3.11% | Manhattan Off screen | 0.89% | AnTuTu 6.1.4 | 3.42% | Note - For KBL (GEN9) we cannot control at sub-slice level, it was always a constraint. We always controlled number of EUs rather than sub-slices/slices. Praveen Diwakar (4): drm/i915: Get active pending request for given context drm/i915: Update render power clock state configuration for given context drm/i915: set optimum eu/slice/sub-slice configuration based on load type drm/i915: Predictive governor to control eu/slice/subslice drivers/gpu/drm/i915/i915_debugfs.c| 88 +- drivers/gpu/drm/i915/i915_drv.c| 1 + drivers/gpu/drm/i915/i915_drv.h| 10 drivers/gpu/drm/i915/i915_gem_context.c| 26 + drivers/gpu/drm/i915/i915_gem_context.h| 45 +++ drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 ++ drivers/gpu/drm/i915/intel_device_info.c | 44 ++- drivers/gpu/drm/i915/intel_lrc.c | 20 ++- 8 files changed, 235 insertions(+), 4 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Get active pending request for given context
Hi Tvrtko,
> -Original Message-
> From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
> Sent: Friday, September 21, 2018 6:10 PM
> To: J Karanje, Kedar ; intel-
> g...@lists.freedesktop.org
> Cc: Diwakar, Praveen ; Marathe, Yogesh
> ; Navik, Ankit P ;
> Muthukumar, Aravindan
> Subject: Re: [Intel-gfx] [PATCH 1/4] drm/i915: Get active pending request for
> given context
>
>
> On 21/09/2018 10:13, kedar.j.kara...@intel.com wrote:
> > From: Praveen Diwakar
> >
> > This patch gives us the active pending request count which is yet to
> > be submitted to the GPU
> >
> > Change-Id: I10c2828ad0f1a0b7af147835737134e07a2d5b6d
> > Signed-off-by: Praveen Diwakar
> > Signed-off-by: Yogesh Marathe
> > Signed-off-by: Aravindan Muthukumar
> > Signed-off-by: Kedar J Karanje
> > Signed-off-by: Ankit Navik
> > ---
> > drivers/gpu/drm/i915/i915_drv.c| 1 +
> > drivers/gpu/drm/i915/i915_drv.h| 5 +
> > drivers/gpu/drm/i915/i915_gem_context.c| 1 +
> > drivers/gpu/drm/i915/i915_gem_context.h| 6 ++
> > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 +
> > drivers/gpu/drm/i915/intel_lrc.c | 6 ++
> > 6 files changed, 24 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c index f8cfd16..d37c46e 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -903,6 +903,7 @@ static int i915_driver_init_early(struct
> drm_i915_private *dev_priv,
> > mutex_init(&dev_priv->av_mutex);
> > mutex_init(&dev_priv->wm.wm_mutex);
> > mutex_init(&dev_priv->pps_mutex);
> > + mutex_init(&dev_priv->pred_mutex);
> >
> > i915_memcpy_init_early(dev_priv);
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index 4aca534..137ec33 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1609,6 +1609,11 @@ struct drm_i915_private {
> > * controller on different i2c buses. */
> > struct mutex gmbus_mutex;
> >
> > + /** pred_mutex protects against councurrent usage of pending
> > +* request counter for multiple contexts
> > +*/
> > + struct mutex pred_mutex;
> > +
> > /**
> > * Base address of the gmbus and gpio block.
> > */
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> > b/drivers/gpu/drm/i915/i915_gem_context.c
> > index b10770c..30932d9 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > @@ -387,6 +387,7 @@ i915_gem_create_context(struct drm_i915_private
> *dev_priv,
> > }
> >
> > trace_i915_context_create(ctx);
> > + ctx->req_cnt = 0;
> >
> > return ctx;
> > }
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
> > b/drivers/gpu/drm/i915/i915_gem_context.h
> > index b116e49..243ea22 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.h
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.h
> > @@ -194,6 +194,12 @@ struct i915_gem_context {
> > * context close.
> > */
> > struct list_head handles_list;
> > +
> > + /** req_cnt: tracks the pending commands, based on which we decide
> to
> > +* go for low/medium/high load configuration of the GPU, this is
> > +* controlled via a mutex
> > +*/
> > + u64 req_cnt;
>
> 64-bit is too wide and mutex causes you problems later in the series.
> I'd suggest atomic_t.
Changes done in v2.
>
> > };
> >
> > static inline bool i915_gem_context_is_closed(const struct
> > i915_gem_context *ctx) diff --git
> > a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 3f0c612..f799ff9 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -2178,6 +2178,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> >struct drm_syncobj **fences)
> > {
> > struct i915_execbuffer eb;
> > + struct drm_i915_private *dev_priv = to_i915(dev);
> > struct dma_fence *in_fence = NULL;
> > struct sync_file *out_fence = NULL;
> > int out_fence_fd = -1;
> > @@ -2390,6 +2391,10 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> > */
> > eb.request->batch = eb.batch;
> >
> > + mutex_lock(&dev_priv->pred_mutex);
> > + eb.ctx->req_cnt++;
> > + mutex_unlock(&dev_priv->pred_mutex);
> > +
> > trace_i915_request_queue(eb.request, eb.batch_flags);
> > err = eb_submit(&eb);
> > err_request:
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 1744792..039fbdb 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -728,6 +728,12 @@ static void execlists_dequeue(struct intel_engine_cs
> *engine)
> > trace_i915_request_in(rq, port_index(port, execlists));
> > last = rq;
> > submit = true;
> > +
> > +
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Update render power clock state configuration for given context
Hi Tvrtko,
> -Original Message-
> From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
> Sent: Friday, September 21, 2018 6:22 PM
> To: J Karanje, Kedar ; intel-
> g...@lists.freedesktop.org
> Cc: Diwakar, Praveen ; Marathe, Yogesh
> ; Navik, Ankit P ;
> Muthukumar, Aravindan
> Subject: Re: [Intel-gfx] [PATCH 2/4] drm/i915: Update render power clock state
> configuration for given context
>
>
> On 21/09/2018 10:13, kedar.j.kara...@intel.com wrote:
> > From: Praveen Diwakar
> >
> > This patch will update power clock state register at runtime base on
> > the flag update_render_config which can set by any governor which
> > computes load and want to update rpcs register.
> > subsequent patches will have a timer based governor which computes
> > pending load/request.
> >
> > Change-Id: I4e7d2f484b957d5bd496e1decc59a69e3bc6d186
> > Signed-off-by: Praveen Diwakar
> > Signed-off-by: Yogesh Marathe
> > Signed-off-by: Aravindan Muthukumar
> > Signed-off-by: Kedar J Karanje
> > Signed-off-by: Ankit Navik
> > ---
> > drivers/gpu/drm/i915/i915_gem_context.c | 5
> > drivers/gpu/drm/i915/i915_gem_context.h | 14 +++
> > drivers/gpu/drm/i915/intel_lrc.c| 41
> +
> > 3 files changed, 60 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> > b/drivers/gpu/drm/i915/i915_gem_context.c
> > index 30932d9..2838c1d 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > @@ -388,6 +388,11 @@ i915_gem_create_context(struct drm_i915_private
> > *dev_priv,
> >
> > trace_i915_context_create(ctx);
> > ctx->req_cnt = 0;
> > + ctx->update_render_config = 0;
> > + ctx->slice_cnt = hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask);
> > + ctx->subslice_cnt = hweight8(
> > + INTEL_INFO(dev_priv)->sseu.subslice_mask[0]);
> > + ctx->eu_cnt = INTEL_INFO(dev_priv)->sseu.eu_per_subslice;
> >
> > return ctx;
> > }
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
> > b/drivers/gpu/drm/i915/i915_gem_context.h
> > index 243ea22..52e341c 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.h
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.h
> > @@ -200,6 +200,20 @@ struct i915_gem_context {
> > * controlled via a mutex
> > */
> > u64 req_cnt;
> > +
> > + /** slice_cnt: used to set the # of slices to be enabled. */
> > + u8 slice_cnt;
> > +
> > + /** subslice_cnt: used to set the # of subslices to be enabled. */
> > + u8 subslice_cnt;
> > +
> > + /** eu_cnt: used to set the # of eu to be enabled. */
> > + u8 eu_cnt;
> > +
> > + /** update_render_config: to track the updates to the render
> > +* configuration (S/SS/EU Configuration on the GPU)
> > +*/
> > + bool update_render_config;
> > };
> >
> > static inline bool i915_gem_context_is_closed(const struct
> > i915_gem_context *ctx) diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 039fbdb..d2d0e7d 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -364,6 +364,36 @@ execlists_unwind_incomplete_requests(struct
> intel_engine_execlists *execlists)
> > spin_unlock_irqrestore(&engine->timeline.lock, flags);
> > }
> >
> > +static u32
> > +get_context_rpcs_config(struct i915_gem_context *ctx) {
> > + struct drm_i915_private *dev_priv = ctx->i915;
> > + u32 rpcs = 0;
> > +
> > + if (INTEL_GEN(dev_priv) < 8)
> > + return 0;
> > +
> > + if (INTEL_INFO(dev_priv)->sseu.has_slice_pg) {
> > + rpcs |= GEN8_RPCS_S_CNT_ENABLE;
> > + rpcs |= ctx->slice_cnt << GEN8_RPCS_S_CNT_SHIFT;
> > + rpcs |= GEN8_RPCS_ENABLE;
> > + }
> > +
> > + if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
> > + rpcs |= GEN8_RPCS_SS_CNT_ENABLE;
> > + rpcs |= ctx->subslice_cnt << GEN8_RPCS_SS_CNT_SHIFT;
> > + rpcs |= GEN8_RPCS_ENABLE;
> > + }
> > +
> > + if (INTEL_INFO(dev_priv)->sseu.has_eu_pg) {
> > + rpcs |= ctx->eu_cnt << GEN8_RPCS_EU_MIN_SHIFT;
> > + rpcs |= ctx->eu_cnt << GEN8_RPCS_EU_MAX_SHIFT;
> > + rpcs |= GEN8_RPCS_ENABLE;
> > + }
> > +
> > + return rpcs;
> > +}
>
> This function is very similar to make_rpcs so I'd suggest to extract some
> commonality and share the code.
Incorporated Changes in v2.
>
> In any case you are likely to get overtaken by
> https://patchwork.freedesktop.org/series/48194/ after which you will be able
> to use struct intel_sseu to package the data you need in one ctx member, etc.
>
> > +
> > static inline void
> > execlists_context_status_change(struct i915_request *rq, unsigned long
> status)
> > {
> > @@ -418,11 +448,22 @@ execlists_update_context_pdps(struct
> i915_hw_ppgtt *ppgtt, u32 *reg_state)
> > static u64 execlists_update_context(struct i915_request *rq)
> > {
> > struct intel_context *ce = rq->hw_context;
> > + s
[Intel-gfx] ✗ Fi.CI.BAT: failure for Dynamic EU configuration of Slice/Subslice/EU. (rev2)
== Series Details == Series: Dynamic EU configuration of Slice/Subslice/EU. (rev2) URL : https://patchwork.freedesktop.org/series/50006/ State : failure == Summary == Applying: drm/i915: Get active pending request for given context Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_drv.c M drivers/gpu/drm/i915/i915_drv.h M drivers/gpu/drm/i915/i915_gem_context.c M drivers/gpu/drm/i915/i915_gem_context.h M drivers/gpu/drm/i915/i915_gem_execbuffer.c M drivers/gpu/drm/i915/intel_lrc.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_lrc.c Auto-merging drivers/gpu/drm/i915/i915_gem_execbuffer.c Auto-merging drivers/gpu/drm/i915/i915_gem_context.h Auto-merging drivers/gpu/drm/i915/i915_gem_context.c Auto-merging drivers/gpu/drm/i915/i915_drv.h Auto-merging drivers/gpu/drm/i915/i915_drv.c Applying: drm/i915: Update render power clock state configuration for given context Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_gem_context.c M drivers/gpu/drm/i915/i915_gem_context.h M drivers/gpu/drm/i915/intel_lrc.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_lrc.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_lrc.c Auto-merging drivers/gpu/drm/i915/i915_gem_context.h Auto-merging drivers/gpu/drm/i915/i915_gem_context.c error: Failed to merge in the changes. Patch failed at 0002 drm/i915: Update render power clock state configuration for given context Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: set optimum eu/slice/sub-slice configuration based on load type
Hi Tvrtko,
Your review changes are incorporated in v2.
Regards, Ankit
> -Original Message-
> From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
> Sent: Friday, September 21, 2018 6:36 PM
> To: J Karanje, Kedar ; intel-
> g...@lists.freedesktop.org
> Cc: Diwakar, Praveen ; Marathe, Yogesh
> ; Navik, Ankit P ;
> Muthukumar, Aravindan
> Subject: Re: [Intel-gfx] [PATCH 3/4] drm/i915: set optimum eu/slice/sub-slice
> configuration based on load type
>
>
> On 21/09/2018 10:13, kedar.j.kara...@intel.com wrote:
> > From: Praveen Diwakar
> >
> > This patch will select optimum eu/slice/sub-slice configuration based
> > on type of load (low, medium, high) as input.
> > Based on our readings and experiments we have predefined set of
> > optimum configuration for each platform(CHT, KBL).
> > i915_set_optimum_config will select optimum configuration from
> > pre-defined optimum configuration table(opt_config).
> >
> > Change-Id: I3a6a2a6b01b3d3c97995f5403aef3c6fa989
> > Signed-off-by: Praveen Diwakar
> > Signed-off-by: Yogesh Marathe
> > Signed-off-by: Aravindan Muthukumar
> > Signed-off-by: Kedar J Karanje
> > Signed-off-by: Ankit Navik
> > ---
> > drivers/gpu/drm/i915/i915_gem_context.c | 46
> +
> > drivers/gpu/drm/i915/i915_gem_context.h | 32 +++
> > 2 files changed, 78 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> > b/drivers/gpu/drm/i915/i915_gem_context.c
> > index 2838c1d..1b76410 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > @@ -94,6 +94,32 @@
> >
> > #define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
> >
> > +static struct optimum_config
> opt_config[TIER_VERSION_MAX][LOAD_TYPE_MAX] = {
> > + {
> > + /* Cherry trail low */
> > + { 1, 1, 4},
> > + /* Cherry trail medium */
> > + { 1, 1, 6},
> > + /* Cherry trail high */
> > + { 1, 2, 6}
> > + },
> > + {
> > + /* kbl gt2 low */
> > + { 2, 3, 4},
> > + /* kbl gt2 medium */
> > + { 2, 3, 6},
> > + /* kbl gt2 high */
> > + { 2, 3, 8}
> > + },
> > + {
> > + /* kbl gt3 low */
> > + { 2, 3, 4},
> > + /* kbl gt3 medium */
> > + { 2, 3, 6},
> > + /* kbl gt3 high */
> > + { 2, 3, 8}
> > + }
> > +};
> > static void lut_close(struct i915_gem_context *ctx)
> > {
> > struct i915_lut_handle *lut, *ln;
> > @@ -393,10 +419,30 @@ i915_gem_create_context(struct drm_i915_private
> *dev_priv,
> > ctx->subslice_cnt = hweight8(
> > INTEL_INFO(dev_priv)->sseu.subslice_mask[0]);
> > ctx->eu_cnt = INTEL_INFO(dev_priv)->sseu.eu_per_subslice;
> > + ctx->load_type = 0;
> > + ctx->prev_load_type = 0;
> >
> > return ctx;
> > }
> >
> > +
> > +void i915_set_optimum_config(int type, struct i915_gem_context *ctx,
>
> Type for type should be enum.
>
> Name the function as i915_gem_context_set_load_type(ctx, type).
>
> > + enum gem_tier_versions version)
> > +{
> > + struct intel_context *ce = &ctx->__engine[RCS];
> > + u32 *reg_state = ce->lrc_reg_state;
> > + u32 rpcs_config = 0;
>
> Unused locals?
>
> > + /* Call opt_config to get correct configuration for eu,slice,subslice */
> > + ctx->slice_cnt = (u8)opt_config[version][type].slice;
> > + ctx->subslice_cnt = (u8)opt_config[version][type].subslice;
> > + ctx->eu_cnt = (u8)opt_config[version][type].eu;
>
> You could store the correct table for the device in dev_priv and use the
> static
> table to assign/populate on device init time.
>
> > +
> > + /* Enabling this to update the rpcs */
> > + if (ctx->prev_load_type != type)
> > + ctx->update_render_config = 1;
>
> ctx->update_render_config was unused in last patch. So patch ordering is
> a bit suboptimal but I don't know.
>
> > +
> > + ctx->prev_load_type = type;
> > +}
> > /**
> >* i915_gem_context_create_gvt - create a GVT GEM context
> >* @dev: drm device *
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
> b/drivers/gpu/drm/i915/i915_gem_context.h
> > index 52e341c..50183e6 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.h
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.h
> > @@ -53,6 +53,26 @@ struct intel_context_ops {
> > void (*destroy)(struct intel_context *ce);
> > };
> >
> > +enum gem_load_type {
> > + LOAD_TYPE_LOW,
> > + LOAD_TYPE_MEDIUM,
> > + LOAD_TYPE_HIGH,
> > + LOAD_TYPE_MAX
> > +};
> > +
> > +enum gem_tier_versions {
> > + CHERRYVIEW = 0,
> > + KABYLAKE_GT2,
> > + KABYLAKE_GT3,
> > + TIER_VERSION_MAX
> > +};
> > +
> > +struct optimum_config {
> > + int slice;
> > + int subslice;
> > + int eu;
>
> u8 would do global table definitely.
>
> > +};
> > +
> > /**
> >* struct i915_gem_context - client state
> >*
> > @@ -210,6 +230,16 @@ struct i9
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Predictive governor to control eu/slice/subslice based on workload
Hi Tvrtko,
> -Original Message-
> From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
> Sent: Tuesday, September 25, 2018 1:56 PM
> To: Navik, Ankit P ; intel-gfx@lists.freedesktop.org
> Cc: J Karanje, Kedar ; Diwakar, Praveen
> ; Marathe, Yogesh
> ; Muthukumar, Aravindan
>
> Subject: Re: [Intel-gfx] [PATCH 4/4] drm/i915: Predictive governor to control
> eu/slice/subslice based on workload
>
>
> On 25/09/2018 07:12, Navik, Ankit P wrote:
> > Hi Tvrtko,
> >
> > Thank you for your valuable comments. We have gone through it.
> > I'll be submitting revised patch-sets after incorporating all your review
> comments.
>
> You're welcome!
>
> Btw one more thing - you can suspend your timer when GPU goes idle and
> restart it when active. See for instance i915_pmu_gt_parked/unparked where to
> put the hooks.
We are working on this and we will send as new patch on top of series.
>
> Regards,
>
> Tvrtko
>
> >> On 21/09/2018 10:13, kedar.j.kara...@intel.com wrote:
> >>> From: Praveen Diwakar
> >>>
> >>> High resoluton timer is used for this purpose.
> >>>
> >>> Debugfs is provided to enable/disable/update timer configuration
> >>>
> >>> Change-Id: I35d692c5afe962fcad4573185bc6f744487711d0
> >>> Signed-off-by: Praveen Diwakar
> >>> Signed-off-by: Yogesh Marathe
> >>> Signed-off-by: Aravindan Muthukumar
> >>> Signed-off-by: Kedar J Karanje
> >>> Signed-off-by: Ankit Navik >>> ---
> >>>drivers/gpu/drm/i915/i915_debugfs.c | 94
> >> -
> >>>drivers/gpu/drm/i915/i915_drv.h | 1 +
> >>>2 files changed, 94 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> >>> b/drivers/gpu/drm/i915/i915_debugfs.c
> >>> index f9ce35d..81ba509 100644
> >>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> >>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> >>> @@ -4740,6 +4740,97 @@ static const struct drm_info_list
> >> i915_debugfs_list[] = {
> >>> {"i915_drrs_status", i915_drrs_status, 0},
> >>> {"i915_rps_boost_info", i915_rps_boost_info, 0},
> >>>};
> >>> +
> >>> +#define POLL_PERIOD_MS (1000 * 1000)
> >>> +#define PENDING_REQ_00 /* No active request pending*/
> >>> +#define PENDING_REQ_33 /* Threshold value of 3 active request
> >> pending*/
> >>> + /* Anything above this is considered as HIGH load
> >>> +* context
> >>> +*/
> >>> + /* And less is considered as LOW load*/
> >>> + /* And equal is considered as mediaum load */
> >>
> >> Wonky comments and some typos up to here.
Changes done in v2.
> >>
> >>> +
> >>> +static int predictive_load_enable;
> >>> +static int predictive_load_timer_init;
> >>> +
> >>> +static enum hrtimer_restart predictive_load_cb(struct hrtimer
> >>> +*hrtimer) {
> >>> + struct drm_i915_private *dev_priv =
> >>> + container_of(hrtimer, typeof(*dev_priv),
> >>> + pred_timer);
> >>> + enum intel_engine_id id;
> >>> + struct intel_engine_cs *engine;
> >>
> >> Some unused's.
Changes done in v2.
> >>
> >>> + struct i915_gem_context *ctx;
> >>> + u64 req_pending;
> >>
> >> unsigned long, and also please try to order declaration so the right
> >> edge of text is moving in one direction only.
Changes done in v2.
> >>
> >>> +
> >>> + list_for_each_entry(ctx, &dev_priv->contexts.list, link) {
> >>> +
> >>> + if (!ctx->name)
> >>> + continue;
> >>
> >> What is this?
Just an error check for invalid context.
> >>
> >>> +
> >>> + mutex_lock(&dev_priv->pred_mutex);
> >>
> >> Here the mutex bites you since you cannot sleep in the timer callback.
> >> atomic_t would solve it. Or would a native unsigned int/long since
> >> lock to read a native word on x86 is not needed.
Changes done in v2.
> >>
> >>> + req_pending = ctx->req_cnt;
> >>> + mutex_unlock(&dev_priv->pred_mutex);
> >>> +
> >>> + if (req_pending == PENDING_REQ_0)
> >>> + continue;
> >>> +
> >>> + if (req_pending > PENDING_REQ_3)
> >>> + ctx->load_type = LOAD_TYPE_HIGH;
> >>> + else if (req_pending == PENDING_REQ_3)
> >>> + ctx->load_type = LOAD_TYPE_MEDIUM;
> >>> + else if (req_pending < PENDING_REQ_3)
> >>
> >> Must be smaller if not greater or equal, but maybe the compiler does
> >> that for you.
Changes done in v2.
> >>
> >>> + ctx->load_type = LOAD_TYPE_LOW;
> >>> +
> >>> + i915_set_optimum_config(ctx->load_type, ctx,
> >> KABYLAKE_GT3);
> >>
> >> Only KBL? Idea to put the table in dev_priv FTW! :)
Changes done in v2.
> >>
> >> ctx->load_type used only as a temporary uncovered here? :)
> >>
> >>> + }
> >>> +
> >>> + hrtimer_forward_now(hrtimer,
> >>> +
> >>ns_to_ktime(predictive_load_enable*POLL_PERIOD_MS));
> >>
> >> Or HRTIMER_NORESTART if disabled? Hard to call it, details..
We get timer value and we don’t start the timer if the value is
