All of lore.kernel.org
 help / color / mirror / Atom feed
From: Deepak S <deepak.s@linux.intel.com>
To: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 7/7] drm/i915: Throw out WIP CHV power well definitions
Date: Fri, 08 May 2015 20:28:32 +0530	[thread overview]
Message-ID: <554CCF18.9020906@linux.intel.com> (raw)
In-Reply-To: <1428679293-6208-8-git-send-email-ville.syrjala@linux.intel.com>



On Friday 10 April 2015 08:51 PM, ville.syrjala@linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Expecting CHV power wells to be just an extended versions of the VLV
> power wells, a bunch of commented out power wells were added in
> anticipation when Punit folks would implement it all. Turns out they
> never did, and instead CHV has fewer power wells than VLV. Rip out all
> the #if 0'ed junk that's not needed.
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>   drivers/gpu/drm/i915/i915_reg.h         |  4 --
>   drivers/gpu/drm/i915/intel_runtime_pm.c | 97 +--------------------------------
>   2 files changed, 3 insertions(+), 98 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 34c366a..f2e0d58 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -595,10 +595,6 @@ enum punit_power_well {
>   	PUNIT_POWER_WELL_DPIO_RX0		= 10,
>   	PUNIT_POWER_WELL_DPIO_RX1		= 11,
>   	PUNIT_POWER_WELL_DPIO_CMN_D		= 12,
> -	/* FIXME: guesswork below */
> -	PUNIT_POWER_WELL_DPIO_TX_D_LANES_01	= 13,
> -	PUNIT_POWER_WELL_DPIO_TX_D_LANES_23	= 14,
> -	PUNIT_POWER_WELL_DPIO_RX2		= 15,
>   
>   	PUNIT_POWER_WELL_NUM,
>   };
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index d9e00d3..f208806 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -977,18 +977,6 @@ void intel_display_power_put(struct drm_i915_private *dev_priv,
>   	BIT(POWER_DOMAIN_AUX_C) |		\
>   	BIT(POWER_DOMAIN_INIT))
>   
> -#define CHV_PIPE_A_POWER_DOMAINS (	\
> -	BIT(POWER_DOMAIN_PIPE_A) |	\
> -	BIT(POWER_DOMAIN_INIT))
> -
> -#define CHV_PIPE_B_POWER_DOMAINS (	\
> -	BIT(POWER_DOMAIN_PIPE_B) |	\
> -	BIT(POWER_DOMAIN_INIT))
> -
> -#define CHV_PIPE_C_POWER_DOMAINS (	\
> -	BIT(POWER_DOMAIN_PIPE_C) |	\
> -	BIT(POWER_DOMAIN_INIT))
> -
>   #define CHV_DPIO_CMN_BC_POWER_DOMAINS (		\
>   	BIT(POWER_DOMAIN_PORT_DDI_B_2_LANES) |	\
>   	BIT(POWER_DOMAIN_PORT_DDI_B_4_LANES) |	\
> @@ -1004,17 +992,6 @@ void intel_display_power_put(struct drm_i915_private *dev_priv,
>   	BIT(POWER_DOMAIN_AUX_D) |		\
>   	BIT(POWER_DOMAIN_INIT))
>   
> -#define CHV_DPIO_TX_D_LANES_01_POWER_DOMAINS (	\
> -	BIT(POWER_DOMAIN_PORT_DDI_D_2_LANES) |	\
> -	BIT(POWER_DOMAIN_PORT_DDI_D_4_LANES) |	\
> -	BIT(POWER_DOMAIN_AUX_D) |		\
> -	BIT(POWER_DOMAIN_INIT))
> -
> -#define CHV_DPIO_TX_D_LANES_23_POWER_DOMAINS (	\
> -	BIT(POWER_DOMAIN_PORT_DDI_D_4_LANES) |	\
> -	BIT(POWER_DOMAIN_AUX_D) |		\
> -	BIT(POWER_DOMAIN_INIT))
> -
>   static const struct i915_power_well_ops i9xx_always_on_power_well_ops = {
>   	.sync_hw = i9xx_always_on_power_well_noop,
>   	.enable = i9xx_always_on_power_well_noop,
> @@ -1172,40 +1149,16 @@ static struct i915_power_well chv_power_wells[] = {
>   		.domains = VLV_ALWAYS_ON_POWER_DOMAINS,
>   		.ops = &i9xx_always_on_power_well_ops,
>   	},
> -#if 0
> -	{
> -		.name = "display",
> -		.domains = VLV_DISPLAY_POWER_DOMAINS,
> -		.data = PUNIT_POWER_WELL_DISP2D,
> -		.ops = &vlv_display_power_well_ops,
> -	},
> -#endif
>   	{
>   		.name = "pipe-a",
>   		/*
> -		 * FIXME: pipe A power well seems to be the new disp2d well.
> -		 * At least all registers seem to be housed there. Figure
> -		 * out if this a a temporary situation in pre-production
> -		 * hardware or a permanent state of affairs.
> +		 * pipe A power well is the new disp2d well.
> +		 * pipe B and C wells don't actually exist.

Can we add a comment saying "enabling pipe A sub system will also enable pipe B & c"
Because it is confusing, We says pipe B and C wells don't actually exist,
then if we use PIPE B to drive. how is it working without powering up the well?

Other than this. patch looks fine
Reviewed-by:  Deepak S<deepak.s@linux.intel.com>

>   		 */
> -		.domains = CHV_PIPE_A_POWER_DOMAINS | VLV_DISPLAY_POWER_DOMAINS,
> +		.domains = VLV_DISPLAY_POWER_DOMAINS,
>   		.data = PIPE_A,
>   		.ops = &chv_pipe_power_well_ops,
>   	},
> -#if 0
> -	{
> -		.name = "pipe-b",
> -		.domains = CHV_PIPE_B_POWER_DOMAINS,
> -		.data = PIPE_B,
> -		.ops = &chv_pipe_power_well_ops,
> -	},
> -	{
> -		.name = "pipe-c",
> -		.domains = CHV_PIPE_C_POWER_DOMAINS,
> -		.data = PIPE_C,
> -		.ops = &chv_pipe_power_well_ops,
> -	},
> -#endif
>   	{
>   		.name = "dpio-common-bc",
>   		.domains = CHV_DPIO_CMN_BC_POWER_DOMAINS,
> @@ -1218,50 +1171,6 @@ static struct i915_power_well chv_power_wells[] = {
>   		.data = PUNIT_POWER_WELL_DPIO_CMN_D,
>   		.ops = &chv_dpio_cmn_power_well_ops,
>   	},
> -#if 0
> -	{
> -		.name = "dpio-tx-b-01",
> -		.domains = VLV_DPIO_TX_B_LANES_01_POWER_DOMAINS |
> -			   VLV_DPIO_TX_B_LANES_23_POWER_DOMAINS,
> -		.ops = &vlv_dpio_power_well_ops,
> -		.data = PUNIT_POWER_WELL_DPIO_TX_B_LANES_01,
> -	},
> -	{
> -		.name = "dpio-tx-b-23",
> -		.domains = VLV_DPIO_TX_B_LANES_01_POWER_DOMAINS |
> -			   VLV_DPIO_TX_B_LANES_23_POWER_DOMAINS,
> -		.ops = &vlv_dpio_power_well_ops,
> -		.data = PUNIT_POWER_WELL_DPIO_TX_B_LANES_23,
> -	},
> -	{
> -		.name = "dpio-tx-c-01",
> -		.domains = VLV_DPIO_TX_C_LANES_01_POWER_DOMAINS |
> -			   VLV_DPIO_TX_C_LANES_23_POWER_DOMAINS,
> -		.ops = &vlv_dpio_power_well_ops,
> -		.data = PUNIT_POWER_WELL_DPIO_TX_C_LANES_01,
> -	},
> -	{
> -		.name = "dpio-tx-c-23",
> -		.domains = VLV_DPIO_TX_C_LANES_01_POWER_DOMAINS |
> -			   VLV_DPIO_TX_C_LANES_23_POWER_DOMAINS,
> -		.ops = &vlv_dpio_power_well_ops,
> -		.data = PUNIT_POWER_WELL_DPIO_TX_C_LANES_23,
> -	},
> -	{
> -		.name = "dpio-tx-d-01",
> -		.domains = CHV_DPIO_TX_D_LANES_01_POWER_DOMAINS |
> -			   CHV_DPIO_TX_D_LANES_23_POWER_DOMAINS,
> -		.ops = &vlv_dpio_power_well_ops,
> -		.data = PUNIT_POWER_WELL_DPIO_TX_D_LANES_01,
> -	},
> -	{
> -		.name = "dpio-tx-d-23",
> -		.domains = CHV_DPIO_TX_D_LANES_01_POWER_DOMAINS |
> -			   CHV_DPIO_TX_D_LANES_23_POWER_DOMAINS,
> -		.ops = &vlv_dpio_power_well_ops,
> -		.data = PUNIT_POWER_WELL_DPIO_TX_D_LANES_23,
> -	},
> -#endif
>   };
>   
>   static struct i915_power_well *lookup_power_well(struct drm_i915_private *dev_priv,

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

      parent reply	other threads:[~2015-05-08 15:02 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-10 15:21 [PATCH 0/7] drm/i915: CHV DPIO power gating stuff ville.syrjala
2015-04-10 15:21 ` [PATCH 1/7] drm/i915: Implement chv display PHY lane stagger setup ville.syrjala
2015-05-08 12:26   ` Deepak S
2015-04-10 15:21 ` [PATCH 2/7] drm/i915: Work around DISPLAY_PHY_CONTROL register corruption on CHV ville.syrjala
2015-05-08 12:54   ` Deepak S
2015-05-08 13:19     ` Ville Syrjälä
2015-05-08 13:33       ` Deepak S
2015-05-08 13:57       ` Daniel Vetter
2015-04-10 15:21 ` [PATCH 3/7] Revert "drm/i915: Hack to tie both common lanes together on chv" ville.syrjala
2015-05-08 12:55   ` Deepak S
2015-04-10 15:21 ` [PATCH 4/7] drm/i915: Use the default 600ns LDO programming sequence delay ville.syrjala
2015-05-08 13:01   ` Deepak S
2015-05-08 13:22     ` Ville Syrjälä
2015-05-08 13:35       ` Deepak S
2015-04-10 15:21 ` [PATCH 5/7] drm/i915: Only wait for required lanes in vlv_wait_port_ready() ville.syrjala
2015-05-08 13:53   ` Deepak S
2015-05-08 14:27     ` Daniel Vetter
2015-04-10 15:21 ` [PATCH 6/7] drm/i915: Implement PHY lane power gating for CHV ville.syrjala
2015-05-08 14:49   ` Deepak S
2015-05-08 16:05     ` Ville Syrjälä
2015-05-09  5:35       ` Deepak S
2015-05-11 11:43         ` Ville Syrjälä
2015-05-13  3:19           ` Deepak S
2015-04-10 15:21 ` [PATCH 7/7] drm/i915: Throw out WIP CHV power well definitions ville.syrjala
2015-04-10 23:09   ` shuang.he
2015-05-08 14:58   ` Deepak S [this message]

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=554CCF18.9020906@linux.intel.com \
    --to=deepak.s@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.