From: Ander Conselvan De Oliveira <conselvan2@gmail.com>
To: Jani Nikula <jani.nikula@linux.intel.com>,
ville.syrjala@linux.intel.com, intel-gfx@lists.freedesktop.org
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH 04/14] drm/i915: Clean up the .get_cdclk() assignment if ladder
Date: Tue, 20 Dec 2016 11:46:43 +0200 [thread overview]
Message-ID: <1482227203.5778.11.camel@gmail.com> (raw)
In-Reply-To: <874m1zes9z.fsf@intel.com>
On Mon, 2016-12-19 at 19:35 +0200, Jani Nikula wrote:
> On Mon, 19 Dec 2016, ville.syrjala@linux.intel.com wrote:
> >
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Let's clean up the mess we have in the if ladder that assigns the
> > .get_cdclk() hooks. The grouping of the platforms by the function
> > results in a thing that's not really legible, so let's do it the
> > other way around and order the if ladder by platform and duplicate
> > whatever assignments we need.
> >
> > To further avoid confusion with the function names let's rename
> > them to just fixed_<freq>_get_cdclk(). The other option would
> > be to duplicate the functions entirely but it seems quite
> > pointless to do that since each one just returns a fixed value.
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 41 +++++++++++++++++++++----------
> > -----
> > 1 file changed, 24 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index bbfef348783b..29f91e799272 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -7379,22 +7379,22 @@ static int valleyview_get_cdclk(struct
> > drm_i915_private *dev_priv)
> > CCK_DISPLAY_CLOCK_CONTROL);
> > }
> >
> > -static int ilk_get_cdclk(struct drm_i915_private *dev_priv)
> > +static int fixed_450mhz_get_cdclk(struct drm_i915_private *dev_priv)
> > {
> > return 450000;
> > }
> >
> > -static int i945_get_cdclk(struct drm_i915_private *dev_priv)
> > +static int fixed_400mhz_get_cdclk(struct drm_i915_private *dev_priv)
> > {
> > return 400000;
> > }
> >
> > -static int i915_get_cdclk(struct drm_i915_private *dev_priv)
> > +static int fixed_333mhz_get_cdclk(struct drm_i915_private *dev_priv)
> > {
> > return 333333;
> > }
> >
> > -static int i9xx_misc_get_cdclk(struct drm_i915_private *dev_priv)
> > +static int fixed_200mhz_get_cdclk(struct drm_i915_private *dev_priv)
> > {
> > return 200000;
> > }
> > @@ -7444,7 +7444,7 @@ static int i915gm_get_cdclk(struct drm_i915_private
> > *dev_priv)
> > }
> > }
> >
> > -static int i865_get_cdclk(struct drm_i915_private *dev_priv)
> > +static int fixed_266mhz_get_cdclk(struct drm_i915_private *dev_priv)
> > {
> > return 266667;
> > }
> > @@ -7487,7 +7487,7 @@ static int i85x_get_cdclk(struct drm_i915_private
> > *dev_priv)
> > return 0;
> > }
> >
> > -static int i830_get_cdclk(struct drm_i915_private *dev_priv)
> > +static int fixed_133mhz_get_cdclk(struct drm_i915_private *dev_priv)
> > {
> > return 133333;
> > }
> > @@ -16098,32 +16098,39 @@ void intel_init_display_hooks(struct
> > drm_i915_private *dev_priv)
> > dev_priv->display.get_cdclk = haswell_get_cdclk;
> > else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > dev_priv->display.get_cdclk = valleyview_get_cdclk;
> > + else if (IS_GEN6(dev_priv) || IS_IVYBRIDGE(dev_priv))
> > + dev_priv->display.get_cdclk = fixed_400mhz_get_cdclk;
> > else if (IS_GEN5(dev_priv))
> > - dev_priv->display.get_cdclk = ilk_get_cdclk;
> > - else if (IS_I945G(dev_priv) || IS_I965G(dev_priv) ||
> > - IS_GEN6(dev_priv) || IS_IVYBRIDGE(dev_priv))
> > - dev_priv->display.get_cdclk = i945_get_cdclk;
> > + dev_priv->display.get_cdclk = fixed_450mhz_get_cdclk;
> > else if (IS_GM45(dev_priv))
> > dev_priv->display.get_cdclk = gm45_get_cdclk;
> > + else if (IS_G4X(dev_priv))
> > + dev_priv->display.get_cdclk = g33_get_cdclk;
> > else if (IS_I965GM(dev_priv))
> > dev_priv->display.get_cdclk = i965gm_get_cdclk;
> > + else if (IS_I965G(dev_priv))
> > + dev_priv->display.get_cdclk = fixed_400mhz_get_cdclk;
> > else if (IS_PINEVIEW(dev_priv))
> > dev_priv->display.get_cdclk = pnv_get_cdclk;
> > - else if (IS_G33(dev_priv) || IS_G4X(dev_priv))
> > + else if (IS_G33(dev_priv))
> > dev_priv->display.get_cdclk = g33_get_cdclk;
> > - else if (IS_I915G(dev_priv))
> > - dev_priv->display.get_cdclk = i915_get_cdclk;
> > - else if (IS_I945GM(dev_priv) || IS_I845G(dev_priv))
> > - dev_priv->display.get_cdclk = i9xx_misc_get_cdclk;
> > + else if (IS_I945GM(dev_priv))
> > + dev_priv->display.get_cdclk = fixed_200mhz_get_cdclk;
> > + else if (IS_I945G(dev_priv))
> > + dev_priv->display.get_cdclk = fixed_400mhz_get_cdclk;
> > else if (IS_I915GM(dev_priv))
> > dev_priv->display.get_cdclk = i915gm_get_cdclk;
> > + else if (IS_I915G(dev_priv))
> > + dev_priv->display.get_cdclk = fixed_333mhz_get_cdclk;
> > else if (IS_I865G(dev_priv))
> > - dev_priv->display.get_cdclk = i865_get_cdclk;
> > + dev_priv->display.get_cdclk = fixed_266mhz_get_cdclk;
> > else if (IS_I85X(dev_priv))
> > dev_priv->display.get_cdclk = i85x_get_cdclk;
> > + else if (IS_I845G(dev_priv))
> > + dev_priv->display.get_cdclk = fixed_200mhz_get_cdclk;
> > else { /* 830 */
> > WARN(!IS_I830(dev_priv), "Unknown platform. Assuming 133
> > MHz CDCLK\n");
> > - dev_priv->display.get_cdclk = i830_get_cdclk;
> > + dev_priv->display.get_cdclk = fixed_133mhz_get_cdclk;
> > }
> I wonder if "switch (dev_priv->info.platform)" is a viable alternative
> to some of the worst if ladders we have, like this one.
How about something like this?
struct cdclk_iface {
int (*get)(...);
void (*set)(...);
int (*calc)(...);
int fixed;
};
static int fixed_cdclk_get(struct drm_i915_private *dev_priv)
{
return INTEL_INFO(dev_priv)->cdclk.fixed;
}
#define FIXED_CDCLK(value) \
{ .get = fixed_cdclk_get, .fixed = value }
struct cdclk_iface skl_cdclk = {
.get = skl_get_cdclk,
.set = skl_set_cdclk,
.calc = skl_get_cdclk,
};
...
And then in device info we just do either
.cdclk = FIXED_CDCLK(value),
or
.cdclk = skl_cdclk,
Ander
>
> BR,
> Jani.
>
>
> >
> >
> > if (IS_GEN5(dev_priv)) {
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-12-20 9:46 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-19 12:34 [PATCH 00/14] drm/i915: Introduce intel_cdclk_state ville.syrjala
2016-12-19 12:34 ` [PATCH 01/14] drm/i915: Store the pipe pixel rate in the crtc state ville.syrjala
2016-12-19 12:34 ` [PATCH 02/14] drm/i915: Nuke intel_mode_max_pixclk() ville.syrjala
2016-12-19 12:34 ` [PATCH 03/14] drm/i915: s/get_display_clock_speed/get_cdclk/ ville.syrjala
2016-12-19 12:34 ` [PATCH 04/14] drm/i915: Clean up the .get_cdclk() assignment if ladder ville.syrjala
2016-12-19 17:35 ` Jani Nikula
2016-12-20 9:46 ` Ander Conselvan De Oliveira [this message]
2016-12-20 10:08 ` Jani Nikula
2016-12-20 10:20 ` Ander Conselvan De Oliveira
2016-12-19 12:34 ` [PATCH 05/14] drm/i915: Move most cdclk/rawclk related code to intel_cdclk.c ville.syrjala
2016-12-19 12:34 ` [PATCH 06/14] drm/i915: Pass computed vco to bxt_set_cdclk() ville.syrjala
2016-12-19 12:34 ` [PATCH 07/14] drm/i915: Start moving the cdclk stuff into a distinct state structure ville.syrjala
2016-12-19 12:34 ` [PATCH 08/14] drm/i915: Track full cdclk state for the logical and actual cdclk frequencies ville.syrjala
2016-12-19 12:34 ` [PATCH 09/14] drm/i915: Pass dev_priv to remainder of the cdclk functions ville.syrjala
2016-12-19 12:34 ` [PATCH 10/14] drm/i915: Pass the cdclk state to the set_cdclk() functions ville.syrjala
2016-12-19 12:34 ` [PATCH 11/14] drm/i915: Move PFI credit reprogramming into vlv/chv_set_cdclk() ville.syrjala
2016-12-19 12:34 ` [PATCH 12/14] drm/i915: Nuke the VLV/CHV PFI programming power domain workaround ville.syrjala
2016-12-19 12:35 ` [PATCH 13/14] drm/i915: Replace the .modeset_commit_cdclk() hook with a more direct .set_cdclk() hook ville.syrjala
2016-12-19 12:35 ` [PATCH 14/14] drm/i915: Move ilk_pipe_pixel_rate() to intel_display.c ville.syrjala
2016-12-19 14:23 ` ✗ Fi.CI.BAT: failure for drm/i915: Introduce intel_cdclk_state Patchwork
-- strict thread matches above, loose matches on Subject: below --
2016-12-19 17:28 [PATCH v2 00/14] drm/i915: Introduce intel_cdclk_state (v2) ville.syrjala
2016-12-19 17:28 ` [PATCH 04/14] drm/i915: Clean up the .get_cdclk() assignment if ladder ville.syrjala
2016-12-20 13:42 ` Ander Conselvan De Oliveira
2017-01-20 18:21 [PATCH v3 00/14] drm/i915: Introduce intel_cdclk_state (v3) ville.syrjala
2017-01-20 18:21 ` [PATCH 04/14] drm/i915: Clean up the .get_cdclk() assignment if ladder ville.syrjala
2017-01-24 12:29 ` David Weinehall
2017-01-25 13:53 ` Ville Syrjälä
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=1482227203.5778.11.camel@gmail.com \
--to=conselvan2@gmail.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=rodrigo.vivi@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 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).