All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Recalculate CDCLK if plane scaling ratio changes
Date: Wed, 12 Jan 2022 16:50:01 +0200	[thread overview]
Message-ID: <Yd7qmU/GCFLdGbjy@intel.com> (raw)
In-Reply-To: <20220112143917.GA3265@intel.com>

On Wed, Jan 12, 2022 at 04:39:17PM +0200, Lisovskiy, Stanislav wrote:
> On Wed, Jan 12, 2022 at 03:50:05PM +0200, Ville Syrjälä wrote:
> > On Tue, Jan 11, 2022 at 06:08:12PM +0200, Stanislav Lisovskiy wrote:
> > > Currently we only recalculate CDCLK if active plane mask changes
> > > or if we do a full modeset, however according to BSpec
> > > required Dbuf bandwidth calculations also depend on pipe/plane
> > > scaling ratio, which means that CDCLK must be recalculated
> > > everytime plane scaling ratio changes,
> > 
> > Already handled by the plane min_cdclk stuff.
> 
> Problem is that plane min_cdclk will only be called for those
> which are added to the state.
> In intel_atomic_check_planes we call intel_crtc_add_planes_to_state
> only if active_planes_affects_min_cdclk is true and active_planes
> mask got changed.
> However if we got one of planes scaling ratio changed, we need to
> recalculate CDCLK once again and make sure we have all the active
> planes in state for that. Don't we need all active planes 
> in state to calculate it properly?

If the plane's scaling ratio is changing then that plane is already
in the state. The min_cdclk/data_rate/etc. are all then cached in
the crtc state so that plane isn't needed again until its scaling
ratio (or whatever else) changes again.

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2022-01-12 14:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-11 16:08 [Intel-gfx] [PATCH] drm/i915: Recalculate CDCLK if plane scaling ratio changes Stanislav Lisovskiy
2022-01-11 16:45 ` Jani Nikula
2022-01-12  9:55   ` Lisovskiy, Stanislav
2022-01-11 18:39 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2022-01-11 18:55 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-01-12  0:26 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-01-12 13:50 ` [Intel-gfx] [PATCH] " Ville Syrjälä
2022-01-12 14:39   ` Lisovskiy, Stanislav
2022-01-12 14:50     ` Ville Syrjälä [this message]
2022-01-13  7:29       ` Lisovskiy, Stanislav
  -- strict thread matches above, loose matches on Subject: below --
2022-01-12 13:06 Stanislav Lisovskiy

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=Yd7qmU/GCFLdGbjy@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=stanislav.lisovskiy@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.