From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
michal.grzelak@intel.com
Subject: Re: [PATCH v2 10/15] drm/i915: cache the results in vlv_clock_get_hpll_vco() and use it more
Date: Tue, 16 Sep 2025 22:51:11 +0300 [thread overview]
Message-ID: <aMm_r5PJtPNYFq8i@intel.com> (raw)
In-Reply-To: <14695618682d8d8fad1adc485de7a122c8e1494a.1757688216.git.jani.nikula@intel.com>
On Fri, Sep 12, 2025 at 05:48:49PM +0300, Jani Nikula wrote:
> Use vlv_clock_get_hpll_vco() helper more to avoid looking at
> i915->hpll_freq directly. Cache and return the cached results to avoid
> repeated lookups.
>
> v2: Rebase
>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 10 +++-----
> drivers/gpu/drm/i915/display/intel_display.c | 27 ++++++++------------
> 2 files changed, 14 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index ea1e6d964764..e77efa0f33ed 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -563,8 +563,7 @@ static void hsw_get_cdclk(struct intel_display *display,
>
> static int vlv_calc_cdclk(struct intel_display *display, int min_cdclk)
> {
> - struct drm_i915_private *dev_priv = to_i915(display->drm);
> - int freq_320 = (dev_priv->hpll_freq << 1) % 320000 != 0 ?
> + int freq_320 = (vlv_clock_get_hpll_vco(display->drm) << 1) % 320000 != 0 ?
> 333333 : 320000;
The somewhat dodgy thing here is that the device might not even be
awake when this is called. So this on-demand caching only works
correctly if the first call happens to be done at the right time
by accident.
I suppose we do end up calling most of these at some point during
the driver initialization when everything is powered on, but the
whole thing does feel rather fragile. I suppose we can hope that
the limited CI coverage was enough to catch most of that.
It would probably make sense to introduce an explicit initalization
function that can be called under controlled circumstances. But we
could do that as a followup, and in the meantime maybe toss in a
few remarks somewhere to remind us about this potential trap...
Series is
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> /*
> @@ -584,8 +583,6 @@ static int vlv_calc_cdclk(struct intel_display *display, int min_cdclk)
>
> static u8 vlv_calc_voltage_level(struct intel_display *display, int cdclk)
> {
> - struct drm_i915_private *dev_priv = to_i915(display->drm);
> -
> if (display->platform.valleyview) {
> if (cdclk >= 320000) /* jump to highest voltage for 400MHz too */
> return 2;
> @@ -599,7 +596,7 @@ static u8 vlv_calc_voltage_level(struct intel_display *display, int cdclk)
> * hardware has shown that we just need to write the desired
> * CCK divider into the Punit register.
> */
> - return DIV_ROUND_CLOSEST(dev_priv->hpll_freq << 1, cdclk) - 1;
> + return DIV_ROUND_CLOSEST(vlv_clock_get_hpll_vco(display->drm) << 1, cdclk) - 1;
> }
> }
>
> @@ -664,7 +661,6 @@ static void vlv_set_cdclk(struct intel_display *display,
> const struct intel_cdclk_config *cdclk_config,
> enum pipe pipe)
> {
> - struct drm_i915_private *dev_priv = to_i915(display->drm);
> int cdclk = cdclk_config->cdclk;
> u32 val, cmd = cdclk_config->voltage_level;
> intel_wakeref_t wakeref;
> @@ -709,7 +705,7 @@ static void vlv_set_cdclk(struct intel_display *display,
> if (cdclk == 400000) {
> u32 divider;
>
> - divider = DIV_ROUND_CLOSEST(dev_priv->hpll_freq << 1,
> + divider = DIV_ROUND_CLOSEST(vlv_clock_get_hpll_vco(display->drm) << 1,
> cdclk) - 1;
>
> /* adjust cdclk divider */
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index 022f32ffd697..7b5379262a37 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -144,17 +144,20 @@ static void bdw_set_pipe_misc(struct intel_dsb *dsb,
> /* returns HPLL frequency in kHz */
> int vlv_clock_get_hpll_vco(struct drm_device *drm)
> {
> + struct drm_i915_private *i915 = to_i915(drm);
> int hpll_freq, vco_freq[] = { 800, 1600, 2000, 2400 };
>
> - vlv_cck_get(drm);
> -
> - /* Obtain SKU information */
> - hpll_freq = vlv_cck_read(drm, CCK_FUSE_REG) &
> - CCK_FUSE_HPLL_FREQ_MASK;
> + if (!i915->hpll_freq) {
> + vlv_cck_get(drm);
> + /* Obtain SKU information */
> + hpll_freq = vlv_cck_read(drm, CCK_FUSE_REG) &
> + CCK_FUSE_HPLL_FREQ_MASK;
> + vlv_cck_put(drm);
>
> - vlv_cck_put(drm);
> + i915->hpll_freq = vco_freq[hpll_freq] * 1000;
> + }
>
> - return vco_freq[hpll_freq] * 1000;
> + return i915->hpll_freq;
> }
>
> static int vlv_get_cck_clock(struct drm_device *drm,
> @@ -179,15 +182,7 @@ static int vlv_get_cck_clock(struct drm_device *drm,
> static int vlv_get_cck_clock_hpll(struct drm_device *drm,
> const char *name, u32 reg)
> {
> - struct drm_i915_private *dev_priv = to_i915(drm);
> - int hpll;
> -
> - if (dev_priv->hpll_freq == 0)
> - dev_priv->hpll_freq = vlv_clock_get_hpll_vco(drm);
> -
> - hpll = vlv_get_cck_clock(drm, name, reg, dev_priv->hpll_freq);
> -
> - return hpll;
> + return vlv_get_cck_clock(drm, name, reg, vlv_clock_get_hpll_vco(drm));
> }
>
> int vlv_clock_get_hrawclk(struct drm_device *drm)
> --
> 2.47.3
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2025-09-16 19:51 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-12 14:48 [PATCH v2 00/15] drm/i915: vlv clock cleanups Jani Nikula
2025-09-12 14:48 ` [PATCH v2 01/15] drm/i915: do cck get/put inside vlv_get_hpll_vco() Jani Nikula
2025-09-18 10:54 ` Michał Grzelak
2025-09-12 14:48 ` [PATCH v2 02/15] drm/i915: do cck get/put inside vlv_get_cck_clock() Jani Nikula
2025-09-18 10:59 ` Michał Grzelak
2025-09-12 14:48 ` [PATCH v2 03/15] drm/i915: add vlv_clock_get_gpll() Jani Nikula
2025-09-12 14:48 ` [PATCH v2 04/15] drm/i915: add vlv_clock_get_czclk() Jani Nikula
2025-09-12 14:48 ` [PATCH v2 05/15] drm/i915: add vlv_clock_get_hrawclk() Jani Nikula
2025-09-12 14:48 ` [PATCH v2 06/15] drm/i915: make vlv_get_cck_clock_hpll() static Jani Nikula
2025-09-12 14:48 ` [PATCH v2 07/15] drm/i915: add vlv_clock_get_cdclk() Jani Nikula
2025-09-12 14:48 ` [PATCH v2 08/15] drm/i915: make vlv_get_cck_clock() static Jani Nikula
2025-09-12 14:48 ` [PATCH v2 09/15] drm/i915: rename vlv_get_hpll_vco() to vlv_clock_get_hpll_vco() Jani Nikula
2025-09-12 14:48 ` [PATCH v2 10/15] drm/i915: cache the results in vlv_clock_get_hpll_vco() and use it more Jani Nikula
2025-09-16 19:51 ` Ville Syrjälä [this message]
2025-09-17 13:57 ` Jani Nikula
2025-09-18 11:17 ` Michał Grzelak
2025-09-12 14:48 ` [PATCH v2 11/15] drm/i915: remove vlv_get_cck_clock_hpll() Jani Nikula
2025-09-18 11:24 ` Michał Grzelak
2025-09-12 14:48 ` [PATCH v2 12/15] drm/i915: remove intel_update_czclk() as unnecessary Jani Nikula
2025-09-18 11:26 ` Michał Grzelak
2025-09-12 14:48 ` [PATCH v2 13/15] drm/i915: log HPLL frequency similar to CZCLK Jani Nikula
2025-09-12 14:48 ` [PATCH v2 14/15] drm/i915: move hpll and czclk caching under display Jani Nikula
2025-09-18 11:28 ` Michał Grzelak
2025-09-12 14:48 ` [PATCH v2 15/15] drm/i915: split out vlv_clock.[ch] Jani Nikula
2025-09-18 11:32 ` Michał Grzelak
2025-09-12 14:56 ` ✗ CI.checkpatch: warning for drm/i915: vlv clock cleanups (rev3) Patchwork
2025-09-12 14:57 ` ✓ CI.KUnit: success " Patchwork
2025-09-12 15:12 ` ✗ CI.checksparse: warning " Patchwork
2025-09-12 15:35 ` ✓ Xe.CI.BAT: success " Patchwork
2025-09-12 17:25 ` ✗ Xe.CI.Full: failure " Patchwork
2025-09-18 12:01 ` [PATCH v2 00/15] drm/i915: vlv clock cleanups Michał Grzelak
2025-09-18 12:28 ` Jani Nikula
2025-09-19 22:00 ` Michał Grzelak
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=aMm_r5PJtPNYFq8i@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=michal.grzelak@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox