[PATCH] drm/i915/cdclk: Rename intel_cdclk_needs_modeset to intel_cdclk_params_changed

[Ville Syrjälä]

On Wed, Feb 14, 2024 at 04:56:50PM -0300, Gustavo Sousa wrote:
> Hi, Ville.
> 
> Sorry for taking long to get back to this.
> 
> Quoting Ville Syrjälä (2024-02-05 12:34:57-03:00)
> >On Sat, Feb 03, 2024 at 10:25:18AM -0300, Gustavo Sousa wrote:
> >> Quoting Ville Syrjälä (2024-02-02 16:58:37-03:00)
> >> >On Fri, Feb 02, 2024 at 10:12:08AM -0300, Gustavo Sousa wrote:
> >> >> Looks like the name and description of intel_cdclk_needs_modeset()
> >> >> became inacurate as of commit 59f9e9cab3a1 ("drm/i915: Skip modeset for
> >> >> cdclk changes if possible"), when it became possible to update the cdclk
> >> >> without requiring disabling the pipes when only changing the cd2x
> >> >> divider was enough.
> >> >> 
> >> >> Later on we also added the same type of support with squash and crawling
> >> >> with commit 25e0e5ae5610 ("drm/i915/display: Do both crawl and squash
> >> >> when changing cdclk"), commit d4a23930490d ("drm/i915: Allow cdclk
> >> >> squasher to be reconfigured live") and commit d62686ba3b54
> >> >> ("drm/i915/adl_p: CDCLK crawl support for ADL").
> >> >> 
> >> >> As such, update that function's name and documentation to something more
> >> >> appropriate, since the real checks for requiring modeset are done
> >> >> elsewhere.
> >> >> 
> >> >> Signed-off-by: Gustavo Sousa <gustavo.sousa at intel.com>
> >> >> ---
> >> >> 
> >> >> One thing worth noting here is that, with this change, we are left with an
> >> >> awkward situation where two function names related to checking changes in cdclk:
> >> >> 
> >> >>   intel_cdclk_params_changed() and intel_cdclk_changed()
> >> >> 
> >> >> ,
> >> >> 
> >> >> and I find it weird that we have intel_cdclk_changed(), which checks for the
> >> >> voltage level as well. Shouldn't the voltage level be a function of cdclk and
> >> >> ddi clock? Why do we need that?
> >> >> 
> >> >>  drivers/gpu/drm/i915/display/intel_cdclk.c        | 15 +++++++--------
> >> >>  drivers/gpu/drm/i915/display/intel_cdclk.h        |  4 ++--
> >> >>  .../drm/i915/display/intel_display_power_well.c   |  4 ++--
> >> >>  3 files changed, 11 insertions(+), 12 deletions(-)
> >> >> 
> >> >> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c
> >> >> index 26200ee3e23f..caadd880865f 100644
> >> >> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> >> >> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> >> >> @@ -2233,17 +2233,16 @@ static bool intel_cdclk_can_squash(struct drm_i915_private *dev_priv,
> >> >>  }
> >> >>  
> >> >>  /**
> >> >> - * intel_cdclk_needs_modeset - Determine if changong between the CDCLK
> >> >> - *                             configurations requires a modeset on all pipes
> >> >> + * intel_cdclk_params_changed - Check whether CDCLK parameters changed
> >> >>   * @a: first CDCLK configuration
> >> >>   * @b: second CDCLK configuration
> >> >>   *
> >> >>   * Returns:
> >> >> - * True if changing between the two CDCLK configurations
> >> >> - * requires all pipes to be off, false if not.
> >> >> + * True if parameters changed in a way that requires programming the CDCLK
> >> >> + * and False otherwise.
> >> >>   */
> >> >> -bool intel_cdclk_needs_modeset(const struct intel_cdclk_config *a,
> >> >> -                               const struct intel_cdclk_config *b)
> >> >> +bool intel_cdclk_params_changed(const struct intel_cdclk_config *a,
> >> >> +                                const struct intel_cdclk_config *b)
> >> >
> >> >The new name isn't very descriptive either.
> >> 
> >> Yeah... I would much rather use intel_cdclk_changed(), but that one is
> >> already taken.
> >> 
> >> >
> >> >Outside the cd2x/crawl/squash cases we stil have to consider
> >> >two cases:
> >> >1. cdclk frequency/pll changes (voltage level can change or not)
> >> >2. cdclk frequency/pll doesn't change, but voltage level needs to change
> >> >
> >> >And that difference is what intel_cdclk_needs_modeset() is trying
> >> >convey. And intel_cdclk_changed() tells us whether anything at all
> >> >is changing.
> >> 
> >> I might be missing something, but, by going through the specs, it looked
> >> to me that voltage level was dependent on cdclk (as well as on ddi
> >> clock) and not the other way around. That's why I find it odd that we
> >> need an intel_cdclk_changed() that, besides looking for changes in
> >> cdclk, also checks for the voltage level.
> >> 
> >> In intel_set_cdclk(), we check intel_cdclk_changed() before continuing.
> >> If, for example, there is a change in ddi clock that requires a change
> >> in voltage level but no changes in cdclk, intel_cdclk_changed() would
> >> return true, right? Wouldn't that make us unnecessarily go through
> >> intel_set_cdclk()?
> >
> >intel_set_cdclk() is the thing that does the voltage change.
> 
> Yep and perhaps I provided an incomplete response above. Sorry.
> 
> I was wondering if handling voltage level should really be
> intel_set_cdclk()'s responsibility.
> 
> I might be missing the big picture here, but, at least for the recent
> platforms, I get the understanding that voltage level handling should be
> a separate step in the hardware commit process.
> 
> Would it be possible to have a commit containing (i) update(s) to ddi
> clk and (ii) no update to cdclk such that (i) require an update to
> voltage level, right?

That is possible yes. But I don't think there's much
point in complicating things by splitting the voltage
level stuff into a completely separate thing.

What I think we could do is split .set_cdclk() into more
fine grained steps so that:
- it's easier to reuse individual pieces across platforms without
  ugly if ladders
- perhaps make it a bit easier to skip unnecessary steps
  although the actual cdclk progrmaming in the nop case really
  just ends up being a CDLCK_CTL/etc. register write
  so not a big deal in practice.

-- 
Ville Syrjälä
Intel