Re: [PATCH 01/13] drm/i915/cdclk: Fix CDCLK programming order when pipes are active

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Fri, Mar 29, 2024 at 12:29:09PM -0300, Gustavo Sousa wrote:
> Quoting Ville Syrjala (2024-03-27 14:45:32-03:00)
> >From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> >Currently we always reprogram CDCLK from the
> >intel_set_cdclk_pre_plane_update() when using squahs/crawl.
> >The code only works correctly for the cd2x update or full
> >modeset cases, and it was simply never updated to deal with
> >squash/crawl.
> >
> >If the CDCLK frequency is increasing we must reprogram it
> >before we do anything else that might depend on the new
> >higher frequency, and conversely we must not decrease
> >the frequency until everything that might still depend
> >on the old higher frequency has been dealt with.
> >
> >Since cdclk_state->pipe is only relevant when doing a cd2x
> >update we can't use it to determine the correct sequence
> >during squash/crawl. To that end introduce cdclk_state->disable_pipes
> >which simply indicates that we must perform the update
> >while the pipes are disable (ie. during
> >intel_set_cdclk_pre_plane_update()). Otherwise we use the
> >same old vs. new CDCLK frequency comparsiong as for cd2x
> >updates.
> >
> >The only remaining problem case is when the voltage_level
> >needs to increase due to a DDI port, but the CDCLK frequency
> >is decreasing (and not all pipes are being disabled). The
> >current approach will not bump the voltage level up until
> >after the port has already been enabled, which is too late.
> >But we'll take care of that case separately.
> 
> Yep. Maybe that's another reason to have that logic detached from the
> cdclk sequence in the future?

Perhaps.

The cdclk sequence is typically specified as
1. request max voltage
2. change cdclk
3. request final voltage
 
We don't actually know whether step 1 has any other side effects
beyond changing the voltage. Eg. it might also do some other magic
to prepare the hardware/firmware for the cdclk change, and so we
might not be able to decouple it from the cdclk sequence 100%.
One solution could be to bump the voltage to the max in the pre
plane voltage hook whenever cdclk is also changing.

We would definitely end up spreading the voltage requests further
out from the actual cdclk programming (they'd have to be the
outermost pre/post plane hooks), which may or may not have some
other side effects as well.

-- 
Ville Syrjälä
Intel