From: "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, jani.saarinen@intel.com
Subject: Re: [PATCH 2/4] drm/i915: Use old mbus_join value when increasing CDCLK
Date: Mon, 25 Mar 2024 20:49:26 +0200 [thread overview]
Message-ID: <ZgHHNnzIFDNTcvVC@intel.com> (raw)
In-Reply-To: <ZgHA8RHihlozBoAn@intel.com>
On Mon, Mar 25, 2024 at 08:22:41PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 25, 2024 at 08:16:55PM +0200, Lisovskiy, Stanislav wrote:
> > On Mon, Mar 25, 2024 at 07:01:48PM +0200, Ville Syrjälä wrote:
> > > On Mon, Mar 25, 2024 at 06:55:21PM +0200, Lisovskiy, Stanislav wrote:
> > > > On Mon, Mar 25, 2024 at 04:30:14PM +0200, Ville Syrjälä wrote:
> > > > > On Mon, Mar 25, 2024 at 01:23:27PM +0200, Stanislav Lisovskiy wrote:
> > > > > > In order to make sure we are not breaking the proper sequence
> > > > > > lets to updates step by step and don't change MBUS join value
> > > > > > during MDCLK/CDCLK programming stage.
> > > > > > MBUS join programming would be taken care by pre/post ddb hooks.
> > > > > >
> > > > > > v2: - Reworded comment about using old mbus_join value in
> > > > > > intel_set_cdclk(Ville Syrjälä)
> > > > > >
> > > > > > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/display/intel_cdclk.c | 12 +++++++++++-
> > > > > > 1 file changed, 11 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > > > index 31aaa9780dfcf..c7813d433c424 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > > > @@ -2611,9 +2611,19 @@ intel_set_cdclk_pre_plane_update(struct intel_atomic_state *state)
> > > > > >
> > > > > > if (pipe == INVALID_PIPE ||
> > > > > > old_cdclk_state->actual.cdclk <= new_cdclk_state->actual.cdclk) {
> > > > > > + struct intel_cdclk_config cdclk_config;
> > > > > > +
> > > > > > drm_WARN_ON(&i915->drm, !new_cdclk_state->base.changed);
> > > > > >
> > > > > > - intel_set_cdclk(i915, &new_cdclk_state->actual, pipe);
> > > > > > + /*
> > > > > > + * By this hack we want to prevent mbus_join to be changed
> > > > > > + * beforehand
> > > > >
> > > > > That sentence is still confusing.
> > > >
> > > > Write it yourself then. I'm not going to rephrase it anymore.
> > >
> > > You didn't rephrase it at all AFAIK.
> > >
> > > Something like
> > > "MBUS joining will be changed later by
> > > intel_dbuf_mbus_{pre,post}_ddb_update(), thus
> > > keep using the old joined_mbus state during cdclk
> > > programming to match the actual hardware state."
> >
> > Basically my comment says exactly same stuff but with other
> > words, i.e preventing changing mbus join value beforehand,
> > until intel_dbuf_mbus_post_ddb_update takes care of that.
>
> To me your comment literally says
> "we massage cdclk_config in order to prevent mbus
> joining changes from happening here"
> Which is a lie; mbus joining will not change here
> no matter what we do to the cdclk_config.
>
> What we do is make sure the cdclk_config actually
> matches the real hardware state of mbus joining.
Couple of revisions ago we discussed that here we use
old_cdclk state in order to prevent mbus join state to be
changed here so that we kind of do it in steps.
That is what I exactly meant.
To be honest I had some kind of impression from your words
that eventually it might get changed here as well, otherwise
it seems to be quite too much hassle for just keeping
hw/sw in sync.
Arguing about comments is of course really required here.
>
> >
> > >
> > > >
> > > > >
> > > > > > - we will take care of this later in
> > > > > > + * intel_dbuf_mbus_post_ddb_update
> > > > > > + */
> > > > > > + cdclk_config = new_cdclk_state->actual;
> > > > > > + cdclk_config.joined_mbus = old_cdclk_state->actual.joined_mbus;
> > > > > > +
> > > > > > + intel_set_cdclk(i915, &cdclk_config, pipe);
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > --
> > > > > > 2.37.3
> > > > >
> > > > > --
> > > > > Ville Syrjälä
> > > > > Intel
> > >
> > > --
> > > Ville Syrjälä
> > > Intel
>
> --
> Ville Syrjälä
> Intel
next prev parent reply other threads:[~2024-03-25 18:49 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-25 11:23 [PATCH 0/4] Enable fastset for mbus_join state change Stanislav Lisovskiy
2024-03-25 11:23 ` [PATCH 1/4] drm/i915: Update mbus in intel_dbuf_mbus_update and do it properly Stanislav Lisovskiy
2024-03-25 14:45 ` Ville Syrjälä
2024-03-25 17:01 ` Lisovskiy, Stanislav
2024-03-25 17:11 ` Ville Syrjälä
2024-03-25 18:29 ` Lisovskiy, Stanislav
2024-03-25 18:43 ` Ville Syrjälä
2024-03-25 19:03 ` Lisovskiy, Stanislav
2024-03-26 12:12 ` Ville Syrjälä
2024-03-26 18:58 ` Ville Syrjälä
2024-03-25 11:23 ` [PATCH 2/4] drm/i915: Use old mbus_join value when increasing CDCLK Stanislav Lisovskiy
2024-03-25 14:30 ` Ville Syrjälä
2024-03-25 16:55 ` Lisovskiy, Stanislav
2024-03-25 17:01 ` Ville Syrjälä
2024-03-25 18:16 ` Lisovskiy, Stanislav
2024-03-25 18:22 ` Ville Syrjälä
2024-03-25 18:49 ` Lisovskiy, Stanislav [this message]
2024-03-25 11:23 ` [PATCH 3/4] drm/i915: Loop over all active pipes in intel_mbus_dbox_update Stanislav Lisovskiy
2024-03-25 11:23 ` [PATCH 4/4] drm/i915: Implement vblank synchronized MBUS join changes Stanislav Lisovskiy
2024-03-25 15:06 ` ✗ Fi.CI.CHECKPATCH: warning for Enable fastset for mbus_join state change (rev4) Patchwork
2024-03-25 15:19 ` ✗ Fi.CI.BAT: failure " 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=ZgHHNnzIFDNTcvVC@intel.com \
--to=stanislav.lisovskiy@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.saarinen@intel.com \
--cc=ville.syrjala@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.