All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@gmail.com>
To: Mahesh Kumar <mahesh1.kumar@intel.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
	Paulo Zanoni <paulo.r.zanoni@intel.com>,
	maarten.lankhorst@intel.com
Subject: Re: [PATCH 1/3] drm/i915/skl+: Don't trust cached ddb values
Date: Fri, 26 May 2017 14:23:56 -0700	[thread overview]
Message-ID: <CABVU7+t3UWKtKMD70wbJ55qe1W5KbzoRo6A6fh=A=eB5kouOjA@mail.gmail.com> (raw)
In-Reply-To: <20170526151546.25025-2-mahesh1.kumar@intel.com>

On Fri, May 26, 2017 at 8:15 AM, Mahesh Kumar <mahesh1.kumar@intel.com> wrote:
> Don't trust cached DDB values. Recalculate the ddb value if cached value
> is zero.
>
> If i915 is build as a module, there may be a race condition when
> cursor_disable call comes even before intel_fbdev_initial_config.
> Which may lead to cached value being 0. And further commit will fail
> until a modeset.
>
> Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 15 ++++++++++-----
>  1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 936eef1634c7..b67be1355e39 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3721,6 +3721,7 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device *dev,
>         struct drm_i915_private *dev_priv = to_i915(dev);
>         struct drm_crtc *for_crtc = cstate->base.crtc;
>         unsigned int pipe_size, ddb_size;
> +       unsigned int active_crtcs;
>         int nth_active_pipe;
>
>         if (WARN_ON(!state) || !cstate->base.active) {
> @@ -3731,10 +3732,11 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device *dev,
>         }
>
>         if (intel_state->active_pipe_changes)
> -               *num_active = hweight32(intel_state->active_crtcs);
> +               active_crtcs = intel_state->active_crtcs;
>         else
> -               *num_active = hweight32(dev_priv->active_crtcs);
> +               active_crtcs = dev_priv->active_crtcs;
>
> +       *num_active = hweight32(active_crtcs);
>         ddb_size = INTEL_INFO(dev_priv)->ddb_size;
>         WARN_ON(ddb_size == 0);
>
> @@ -3754,12 +3756,15 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device *dev,
>                  * copy from old state to be sure
>                  */
>                 *alloc = to_intel_crtc_state(for_crtc->state)->wm.skl.ddb;
> -               return;
> +               if (!skl_ddb_entry_size(alloc))
> +                       DRM_DEBUG_KMS("Cached pipe DDB is 0 recalculate\n");
> +               else
> +                       return;

I see 2 different patches inside this patch here. One is this chunk
here that does what commit message tells.

>         }
>
> -       nth_active_pipe = hweight32(intel_state->active_crtcs &
> +       nth_active_pipe = hweight32(active_crtcs &
>                                     (drm_crtc_mask(for_crtc) - 1));
> -       pipe_size = ddb_size / hweight32(intel_state->active_crtcs);
> +       pipe_size = ddb_size / hweight32(active_crtcs);

While this is fixing another bug where we were still using
intel_state->active_crtcs here even when we use dev_priv->active_crtcs
for num_active.

Am I missing or misunderstanding something?

>         alloc->start = nth_active_pipe * ddb_size / *num_active;
>         alloc->end = alloc->start + pipe_size;
>  }
> --
> 2.11.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-05-26 21:23 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-26 15:15 [PATCH 0/3] Remaining patches for WM cleanup series Mahesh Kumar
2017-05-26 15:15 ` [PATCH 1/3] drm/i915/skl+: Don't trust cached ddb values Mahesh Kumar
2017-05-26 21:23   ` Rodrigo Vivi [this message]
2017-05-29  5:56     ` Mahesh Kumar
2017-05-30 10:00   ` Maarten Lankhorst
2017-05-30 12:56     ` Mahesh Kumar
2017-05-30 14:35       ` Lankhorst, Maarten
2017-05-31  7:56   ` [PATCH] drm/i915: Always recompute watermarks when distrust_bios_wm is set Maarten Lankhorst
2017-05-31  7:56     ` Maarten Lankhorst
2017-05-31 10:42     ` Mahesh Kumar
2017-05-31 10:59       ` Maarten Lankhorst
2017-05-31 15:42     ` [PATCH] drm/i915: Always recompute watermarks when distrust_bios_wm is set, v2 Maarten Lankhorst
2017-05-31 17:43       ` Mahesh Kumar
2017-05-31 17:43         ` Mahesh Kumar
2017-05-31 22:08       ` Matt Roper
2017-05-26 15:15 ` [PATCH 2/3] drm/i915/skl: New ddb allocation algorithm Mahesh Kumar
2017-05-31 22:16   ` Matt Roper
2017-06-01  5:59     ` Mahesh Kumar
2017-05-26 15:15 ` [PATCH 3/3] drm/i915/skl+: consider max supported plane pixel rate while scaling Mahesh Kumar
2017-06-01  8:24   ` Maarten Lankhorst
2017-05-26 15:43 ` ✗ Fi.CI.BAT: warning for Remaining patches for WM cleanup series (rev3) Patchwork

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='CABVU7+t3UWKtKMD70wbJ55qe1W5KbzoRo6A6fh=A=eB5kouOjA@mail.gmail.com' \
    --to=rodrigo.vivi@gmail.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=maarten.lankhorst@intel.com \
    --cc=mahesh1.kumar@intel.com \
    --cc=paulo.r.zanoni@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.