public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Paulo Zanoni <paulo.r.zanoni@intel.com>
To: James Ausmus <james.ausmus@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 02/17] drm/i915/icl: add ICL support to cnl_set_procmon_ref_values
Date: Fri, 26 Jan 2018 18:24:32 -0200	[thread overview]
Message-ID: <1516998272.16643.94.camel@intel.com> (raw)
In-Reply-To: <20180124003256.GB11858@jausmus-gentoo-dev6.jf.intel.com>

Em Ter, 2018-01-23 às 16:32 -0800, James Ausmus escreveu:
> On Tue, Jan 23, 2018 at 05:05:21PM -0200, Paulo Zanoni wrote:
> > On ICL we have two sets of registers: one for port A and another
> > for
> > port B. The set of port A registers is the same as the CNL
> > registers.
> > 
> > Since the procmon table on ICL is the same we want to reuse the CNL
> > function. To do that we add a port argument and make CNL always
> > call
> > the function passing port A. This way, we'll be able to easily
> > reuse
> > the function on ICL when we add icl_display_core_init().
> > 
> > v2: Don't use _PICK() when you can use a ternary operator.
> > 
> > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h         | 26
> > ++++++++++++++++++++++++++
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 21 ++++++++++++++-------
> >  2 files changed, 40 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index d72e206b2b9f..ebf6261d30fd 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -2102,6 +2102,32 @@ enum i915_power_well_id {
> >  #define CNL_PORT_COMP_DW9		_MMIO(0x162124)
> >  #define CNL_PORT_COMP_DW10		_MMIO(0x162128)
> >  
> > +#define _ICL_PORT_COMP_DW0_A		0x162100
> > +#define _ICL_PORT_COMP_DW0_B		0x6C100
> > +#define ICL_PORT_COMP_DW0(port)		_MMIO((port ==
> > PORT_A) ?	\
> > +					      _ICL_PORT_COMP_DW0_A
> > :	\
> > +					      _ICL_PORT_COMP_DW0_B
> > )
> > +#define _ICL_PORT_COMP_DW1_A		0x162104
> > +#define _ICL_PORT_COMP_DW1_B		0x6C104
> > +#define ICL_PORT_COMP_DW1(port)		_MMIO((port ==
> > PORT_A) ?	\
> > +					      _ICL_PORT_COMP_DW1_A
> > :	\
> > +					      _ICL_PORT_COMP_DW1_B
> > )
> > +#define _ICL_PORT_COMP_DW3_A		0x16210C
> > +#define _ICL_PORT_COMP_DW3_B		0x6C10C
> > +#define ICL_PORT_COMP_DW3(port)		_MMIO((port ==
> > PORT_A) ?	\
> > +					      _ICL_PORT_COMP_DW3_A
> > : 	\
> > +					      _ICL_PORT_COMP_DW3_B
> > )
> > +#define _ICL_PORT_COMP_DW9_A		0x162124
> > +#define _ICL_PORT_COMP_DW9_B		0x6C124
> > +#define ICL_PORT_COMP_DW9(port)		_MMIO((port ==
> > PORT_A) ?	\
> > +					      _ICL_PORT_COMP_DW9_A
> > :	\
> > +					      _ICL_PORT_COMP_DW9_B
> > )
> > +#define _ICL_PORT_COMP_DW10_A		0x162128
> > +#define _ICL_PORT_COMP_DW10_B		0x6C128
> > +#define ICL_PORT_COMP_DW10(port)	_MMIO((port == PORT_A) ?	
> > \
> > +					      _ICL_PORT_COMP_DW10_
> > A :	\
> > +					      _ICL_PORT_COMP_DW10_
> > B)
> > +
> >  /* BXT PHY Ref registers */
> >  #define _PORT_REF_DW3_A			0x16218C
> >  #define _PORT_REF_DW3_BC		0x6C18C
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 5b1aa4b9c72c..73dd525d241a 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -2758,12 +2758,19 @@ static const struct cnl_procmon {
> >  		{ .dw1 = 0x00440000, .dw9 = 0x9A00AB25, .dw10 =
> > 0x8AE38FF1, },
> >  };
> >  
> > -static void cnl_set_procmon_ref_values(struct drm_i915_private
> > *dev_priv)
> > +/*
> > + * CNL has just one set of registers, while ICL has two sets: one
> > for port A and
> > + * the other for port B. The CNL registers are equivalent to the
> > ICL port A
> > + * registers, that's why we call the ICL macros even though the
> > function has CNL
> > + * on its name.
> > + */

My reply below refers to this comment here ^.




> > +static void cnl_set_procmon_ref_values(struct drm_i915_private
> > *dev_priv,
> > +				       enum port port)
> >  {
> >  	const struct cnl_procmon *procmon;
> >  	u32 val;
> >  
> > -	val = I915_READ(CNL_PORT_COMP_DW3);
> > +	val = I915_READ(ICL_PORT_COMP_DW3(port));
> >  	switch (val & (PROCESS_INFO_MASK | VOLTAGE_INFO_MASK)) {
> >  	default:
> >  		MISSING_CASE(val);
> > @@ -2784,13 +2791,13 @@ static void
> > cnl_set_procmon_ref_values(struct drm_i915_private *dev_priv)
> >  		break;
> >  	}
> >  
> > -	val = I915_READ(CNL_PORT_COMP_DW1);
> > +	val = I915_READ(ICL_PORT_COMP_DW1(port));
> >  	val &= ~((0xff << 16) | 0xff);
> >  	val |= procmon->dw1;
> > -	I915_WRITE(CNL_PORT_COMP_DW1, val);
> > +	I915_WRITE(ICL_PORT_COMP_DW1(port), val);
> >  
> > -	I915_WRITE(CNL_PORT_COMP_DW9, procmon->dw9);
> > -	I915_WRITE(CNL_PORT_COMP_DW10, procmon->dw10);
> > +	I915_WRITE(ICL_PORT_COMP_DW9(port), procmon->dw9);
> > +	I915_WRITE(ICL_PORT_COMP_DW10(port), procmon->dw10);
> >  }
> >  
> >  static void cnl_display_core_init(struct drm_i915_private
> > *dev_priv, bool resume)
> > @@ -2811,7 +2818,7 @@ static void cnl_display_core_init(struct
> > drm_i915_private *dev_priv, bool resume
> >  	val &= ~CNL_COMP_PWR_DOWN;
> >  	I915_WRITE(CHICKEN_MISC_2, val);
> >  
> > -	cnl_set_procmon_ref_values(dev_priv);
> > +	cnl_set_procmon_ref_values(dev_priv, PORT_A);
> 
> Maybe worth a one-line comment here about why we're passing PORT_A so
> drive-by readings don't get confused on why we're only setting
> PORT_A?
> 
> Maybe something like
> 
> /* Dummy PORT_A to get the correct CNL register from the ICL macro */

I put such comment at the beginning of the function. See above. Is that
enough or you think we also need this extra comment?

> 
> Either way:
> 
> Reviewed-by: James Ausmus <james.ausmus@intel.com>

Thanks!

> 
> >  
> >  	val = I915_READ(CNL_PORT_COMP_DW0);
> >  	val |= COMP_INIT;
> > -- 
> > 2.14.3
> > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-01-26 20:24 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-23 19:05 [PATCH 00/17] ICL display initialization and some plane bits Paulo Zanoni
2018-01-23 19:05 ` [PATCH 01/17] drm/i915/icl: add the main CDCLK functions Paulo Zanoni
2018-01-26 23:14   ` James Ausmus
2018-02-01 20:09     ` Paulo Zanoni
2018-01-29 10:51   ` Imre Deak
2018-02-01 20:08     ` Paulo Zanoni
2018-02-01 20:40       ` Imre Deak
2018-02-02 19:57   ` Paulo Zanoni
2018-02-02 22:12     ` James Ausmus
2018-01-23 19:05 ` [PATCH 02/17] drm/i915/icl: add ICL support to cnl_set_procmon_ref_values Paulo Zanoni
2018-01-24  0:32   ` James Ausmus
2018-01-26 20:24     ` Paulo Zanoni [this message]
2018-01-26 20:47       ` James Ausmus
2018-01-26 20:33   ` Ville Syrjälä
2018-02-02 16:23   ` Paulo Zanoni
2018-02-02 18:17     ` James Ausmus
2018-01-23 19:05 ` [PATCH 03/17] drm/i915/icl: implement the display init/uninit sequences Paulo Zanoni
2018-01-26 23:25   ` James Ausmus
2018-01-23 19:05 ` [PATCH 04/17] drm/i915/icl: Enable both DBuf slices during init Paulo Zanoni
2018-01-24  0:49   ` James Ausmus
2018-01-26 20:50     ` Paulo Zanoni
2018-01-29 17:47       ` Paulo Zanoni
2018-01-23 19:05 ` [PATCH 05/17] drm/i915/icl: Don't allocate fixed bypass path blocks for ICL Paulo Zanoni
2018-01-24  0:58   ` James Ausmus
2018-01-23 19:05 ` [PATCH 06/17] drm/i915/icl: Do not fix dbuf block size to 512 Paulo Zanoni
2018-01-24  1:14   ` James Ausmus
2018-01-29 23:07   ` Paulo Zanoni
2018-01-29 23:32     ` James Ausmus
2018-01-23 19:05 ` [PATCH 07/17] drm/i915/icl: Fail flip if ddb allocated are less than min display buffer needed Paulo Zanoni
2018-01-26 23:50   ` James Ausmus
2018-01-29 18:16     ` Paulo Zanoni
2018-01-29 23:08   ` [PATCH 07/13] " Paulo Zanoni
2018-01-23 19:05 ` [PATCH 08/17] drm/i915/icl: NV12 y-plane ddb is not in same plane Paulo Zanoni
2018-01-25 22:31   ` James Ausmus
2018-01-23 19:05 ` [PATCH 09/17] drm/i915/icl: Introduce MBus related registers Paulo Zanoni
2018-01-25 22:38   ` James Ausmus
2018-01-23 19:05 ` [PATCH 10/17] drm/i915/icl: initialize MBus during display init Paulo Zanoni
2018-01-25 22:39   ` James Ausmus
2018-01-23 19:05 ` [PATCH 11/17] drm/i915/icl: program mbus during pipe enable Paulo Zanoni
2018-01-25 22:42   ` James Ausmus
2018-01-23 19:05 ` [PATCH 12/17] drm/i915/icl: track dbuf slice-2 status Paulo Zanoni
2018-01-25 23:08   ` James Ausmus
2018-01-23 19:05 ` [PATCH 13/17] drm/i915/icl: Enable 2nd DBuf slice only when needed Paulo Zanoni
2018-01-25 22:56   ` James Ausmus
2018-03-14 16:19   ` [PATCH 2/2] " Mahesh Kumar
2018-01-23 19:05 ` [PATCH 14/17] drm/i915/icl: update ddb entry start/end mask during hw ddb readout Paulo Zanoni
2018-01-25 23:00   ` James Ausmus
2018-01-23 19:05 ` [PATCH 15/17] drm/i915/gen11: fix the SAGV block time for gen11 Paulo Zanoni
2018-01-25 23:09   ` James Ausmus
2018-01-23 19:05 ` [PATCH 16/17] drm/i915/icl: enable SAGV for ICL platform Paulo Zanoni
2018-01-25 23:09   ` James Ausmus
2018-01-29 22:07   ` Paulo Zanoni
2018-01-23 19:05 ` [PATCH 17/17] drm/i915/icl: Handle expanded PLANE_CTL_FORMAT field Paulo Zanoni
2018-01-23 19:32 ` ✗ Fi.CI.BAT: failure for ICL display initialization and some plane bits Patchwork
2018-01-23 20:32 ` Patchwork
2018-01-29 23:27 ` ✗ Fi.CI.BAT: failure for ICL display initialization and some plane bits (rev2) Patchwork
2018-02-02 17:10 ` ✗ Fi.CI.BAT: failure for ICL display initialization and some plane bits (rev4) Patchwork
2018-02-02 17:28 ` Patchwork
2018-02-02 20:22 ` ✗ Fi.CI.BAT: failure for ICL display initialization and some plane bits (rev5) 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=1516998272.16643.94.camel@intel.com \
    --to=paulo.r.zanoni@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=james.ausmus@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