From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/cnp+: update to the new RAWCLK_FREQ recommendations
Date: Fri, 12 Oct 2018 15:42:31 +0300 [thread overview]
Message-ID: <20181012124231.GP9144@intel.com> (raw)
In-Reply-To: <20181012004045.13535-1-paulo.r.zanoni@intel.com>
On Thu, Oct 11, 2018 at 05:40:45PM -0700, Paulo Zanoni wrote:
> These are the new recommended values provided by our spec (18 -> 19
> and 23 -> 24). It seems this should help fixing GMBUS issues. Since
> we're doing pretty much the same thing for both CNP and ICP now, unify
> the functions using the ICP version since it's more straightforward by
> just matching the values listed in BSpec instead of recalculating
> them.
IMO calculating would be better. Would be trivial to see that the values
are at least consistent. With four magic numbers you have no choice but
to dig up the spec, which is painful. I don't like needless pain that
much.
>
> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 -
> drivers/gpu/drm/i915/intel_cdclk.c | 37 ++++++-------------------------------
> 2 files changed, 6 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 20785417953d..ffd564a8d339 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7832,7 +7832,6 @@ enum {
> #define CNP_RAWCLK_DIV(div) ((div) << 16)
> #define CNP_RAWCLK_FRAC_MASK (0xf << 26)
> #define CNP_RAWCLK_FRAC(frac) ((frac) << 26)
> -#define ICP_RAWCLK_DEN(den) ((den) << 26)
> #define ICP_RAWCLK_NUM(num) ((num) << 11)
>
> #define PCH_DPLL_TMR_CFG _MMIO(0xc6208)
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c b/drivers/gpu/drm/i915/intel_cdclk.c
> index 29075c763428..17d3f13d89db 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -2660,48 +2660,25 @@ void intel_update_cdclk(struct drm_i915_private *dev_priv)
> }
>
> static int cnp_rawclk(struct drm_i915_private *dev_priv)
> -{
> - u32 rawclk;
> - int divider, fraction;
> -
> - if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) {
> - /* 24 MHz */
> - divider = 24000;
> - fraction = 0;
> - } else {
> - /* 19.2 MHz */
> - divider = 19000;
> - fraction = 200;
> - }
> -
> - rawclk = CNP_RAWCLK_DIV((divider / 1000) - 1);
> - if (fraction)
> - rawclk |= CNP_RAWCLK_FRAC(DIV_ROUND_CLOSEST(1000,
> - fraction) - 1);
> -
> - I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
> - return divider + fraction;
> -}
> -
> -static int icp_rawclk(struct drm_i915_private *dev_priv)
> {
> u32 rawclk;
> int divider, numerator, denominator, frequency;
>
> if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) {
> frequency = 24000;
> - divider = 23;
> + divider = 24;
> numerator = 0;
> denominator = 0;
> } else {
> frequency = 19200;
> - divider = 18;
> + divider = 19;
> numerator = 1;
> denominator = 4;
These numbers are extremely confusing. The hardware wants the numerator
as is but then it wants denominator-1. Which is a but odd. I think I'd
move the -1 for the denominator into the macro (or the invocation of the
macro, like cnp had). Alternatively we could at least write this as 5-1
here, so that the reader has at least some chance to figure out what
this means.
> }
>
> - rawclk = CNP_RAWCLK_DIV(divider) | ICP_RAWCLK_NUM(numerator) |
> - ICP_RAWCLK_DEN(denominator);
> + rawclk = CNP_RAWCLK_DIV(divider) | CNP_RAWCLK_FRAC(denominator);
> + if (HAS_PCH_ICP(dev_priv))
> + rawclk |= ICP_RAWCLK_NUM(numerator);
>
> I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
> return frequency;
> @@ -2754,9 +2731,7 @@ static int g4x_hrawclk(struct drm_i915_private *dev_priv)
> */
> void intel_update_rawclk(struct drm_i915_private *dev_priv)
> {
> - if (HAS_PCH_ICP(dev_priv))
> - dev_priv->rawclk_freq = icp_rawclk(dev_priv);
> - else if (HAS_PCH_CNP(dev_priv))
> + if (HAS_PCH_CNP(dev_priv) || HAS_PCH_ICP(dev_priv))
> dev_priv->rawclk_freq = cnp_rawclk(dev_priv);
> else if (HAS_PCH_SPLIT(dev_priv))
> dev_priv->rawclk_freq = pch_rawclk(dev_priv);
> --
> 2.14.4
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-10-12 12:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-12 0:40 [PATCH] drm/i915/cnp+: update to the new RAWCLK_FREQ recommendations Paulo Zanoni
2018-10-12 1:11 ` ✗ Fi.CI.BAT: failure for " Patchwork
2018-10-12 12:42 ` Ville Syrjälä [this message]
2018-10-16 23:00 ` [PATCH] " Paulo Zanoni
2018-10-16 23:09 ` Rodrigo Vivi
2018-10-18 12:52 ` Ville Syrjälä
2018-10-18 23:46 ` Rodrigo Vivi
2018-11-10 0:23 ` [PATCH 1/3] " Paulo Zanoni
2018-11-10 0:23 ` [PATCH 2/3] drm/i915: rename CNP_RAWCLK_FRAC to CNP_RAWCLK_DEN Paulo Zanoni
2018-11-10 0:23 ` [PATCH 3/3] drm/i915: add ICP support to cnp_rawclk() and kill icp_rawclk() Paulo Zanoni
2018-11-12 14:54 ` Ville Syrjälä
2018-11-12 18:17 ` Paulo Zanoni
2018-11-12 18:37 ` [PATCH 3/3 v2] " Paulo Zanoni
2018-11-12 20:52 ` ✗ Fi.CI.BAT: failure for drm/i915/cnp+: update to the new RAWCLK_FREQ recommendations 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=20181012124231.GP9144@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=paulo.r.zanoni@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;
as well as URLs for NNTP newsgroup(s).