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
prev 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox