From: Jani Nikula <jani.nikula@linux.intel.com>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Daniel Vetter <daniel@ffwll.ch>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915: Postpone plane readout until after encoder readout, v3.
Date: Tue, 13 Oct 2015 15:40:27 +0300 [thread overview]
Message-ID: <87d1wj54ck.fsf@intel.com> (raw)
In-Reply-To: <55DEF8CE.3060600@linux.intel.com>
On Thu, 27 Aug 2015, Maarten Lankhorst <maarten.lankhorst@linux.intel.com> wrote:
> When reading out hw state for planes we disable inactive planes which in
> turn triggers an update of the watermarks. The update depends on the
> crtc_clock being set which is done when reading out encoders. Thus
> postpone the plane readout until after encoder readout.
>
> This prevents a warning in skl_compute_linetime_wm() where pixel_rate
> becomes 0 when crtc_clock is 0.
>
> Signed-off-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=91428
Maarten, I presume this patch is superseded by the commits referenced in
that bug. Is that correct?
BR,
Jani.
> ---
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index e3922d973db0..118b205e7bd5 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15033,30 +15033,6 @@ static bool primary_get_hw_state(struct intel_crtc *crtc)
> return !!(I915_READ(DSPCNTR(crtc->plane)) & DISPLAY_PLANE_ENABLE);
> }
>
> -static void readout_plane_state(struct intel_crtc *crtc,
> - struct intel_crtc_state *crtc_state)
> -{
> - struct intel_plane *p;
> - struct intel_plane_state *plane_state;
> - bool active = crtc_state->base.active;
> -
> - for_each_intel_plane(crtc->base.dev, p) {
> - if (crtc->pipe != p->pipe)
> - continue;
> -
> - plane_state = to_intel_plane_state(p->base.state);
> -
> - if (p->base.type == DRM_PLANE_TYPE_PRIMARY)
> - plane_state->visible = primary_get_hw_state(crtc);
> - else {
> - if (active)
> - p->disable_plane(&p->base, &crtc->base);
> -
> - plane_state->visible = false;
> - }
> - }
> -}
> -
> static void intel_modeset_readout_hw_state(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -15076,35 +15052,8 @@ static void intel_modeset_readout_hw_state(struct drm_device *dev)
>
> crtc->base.state->active = crtc->active;
> crtc->base.enabled = crtc->active;
> -
> - memset(&crtc->base.mode, 0, sizeof(crtc->base.mode));
> - if (crtc->base.state->active) {
> - intel_mode_from_pipe_config(&crtc->base.mode, crtc->config);
> - intel_mode_from_pipe_config(&crtc->base.state->adjusted_mode, crtc->config);
> - WARN_ON(drm_atomic_set_mode_for_crtc(crtc->base.state, &crtc->base.mode));
> -
> - /*
> - * The initial mode needs to be set in order to keep
> - * the atomic core happy. It wants a valid mode if the
> - * crtc's enabled, so we do the above call.
> - *
> - * At this point some state updated by the connectors
> - * in their ->detect() callback has not run yet, so
> - * no recalculation can be done yet.
> - *
> - * Even if we could do a recalculation and modeset
> - * right now it would cause a double modeset if
> - * fbdev or userspace chooses a different initial mode.
> - *
> - * If that happens, someone indicated they wanted a
> - * mode change, which means it's safe to do a full
> - * recalculation.
> - */
> - crtc->base.state->mode.private_flags = I915_MODE_FLAG_INHERITED;
> - }
> -
> - crtc->base.hwmode = crtc->config->base.adjusted_mode;
> - readout_plane_state(crtc, to_intel_crtc_state(crtc->base.state));
> + to_intel_plane_state(crtc->base.primary->state)->visible =
> + primary_get_hw_state(crtc);
>
> DRM_DEBUG_KMS("[CRTC:%d] hw state readout: %s\n",
> crtc->base.base.id,
> @@ -15186,6 +15135,33 @@ intel_modeset_setup_hw_state(struct drm_device *dev)
>
> for_each_pipe(dev_priv, pipe) {
> crtc = to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
> + crtc->base.hwmode = crtc->config->base.adjusted_mode;
> + memset(&crtc->base.mode, 0, sizeof(crtc->base.mode));
> + if (crtc->base.state->active) {
> + intel_mode_from_pipe_config(&crtc->base.mode, crtc->config);
> + intel_mode_from_pipe_config(&crtc->base.state->adjusted_mode, crtc->config);
> + WARN_ON(drm_atomic_set_mode_for_crtc(crtc->base.state, &crtc->base.mode));
> +
> + /*
> + * The initial mode needs to be set in order to keep
> + * the atomic core happy. It wants a valid mode if the
> + * crtc's enabled, so we do the above call.
> + *
> + * At this point some state updated by the connectors
> + * in their ->detect() callback has not run yet, so
> + * no recalculation can be done yet.
> + *
> + * Even if we could do a recalculation and modeset
> + * right now it would cause a double modeset if
> + * fbdev or userspace chooses a different initial mode.
> + *
> + * If that happens, someone indicated they wanted a
> + * mode change, which means it's safe to do a full
> + * recalculation.
> + */
> + crtc->base.state->mode.private_flags = I915_MODE_FLAG_INHERITED;
> + }
> +
> intel_sanitize_crtc(crtc);
> intel_dump_pipe_config(crtc, crtc->config,
> "[setup_hw_state]");
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-10-13 12:37 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-31 13:04 [PATCH] drm/i915: Postpone plane readout until after encoder readout Patrik Jakobsson
2015-08-03 6:31 ` Maarten Lankhorst
2015-08-03 14:36 ` Maarten Lankhorst
2015-08-04 15:37 ` Patrik Jakobsson
2015-08-05 10:45 ` drm/i915: Postpone plane readout until after encoder readout, v2 Maarten Lankhorst
2015-08-26 14:43 ` Daniel Vetter
2015-08-27 11:05 ` Maarten Lankhorst
2015-09-01 9:52 ` Daniel Vetter
2015-08-27 11:47 ` [PATCH] drm/i915: Postpone plane readout until after encoder readout, v3 Maarten Lankhorst
2015-08-27 12:05 ` Ville Syrjälä
2015-08-31 5:59 ` shuang.he
2015-10-13 12:40 ` Jani Nikula [this message]
2015-10-13 12:44 ` Maarten Lankhorst
2015-08-10 17:56 ` [PATCH] drm/i915: Postpone plane readout until after encoder readout shuang.he
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d1wj54ck.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=maarten.lankhorst@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.