public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Imre Deak <imre.deak@intel.com>
To: Paulo Zanoni <przanoni@gmail.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 04/19] drm/i915: move power domain macros to intel_pm.c
Date: Mon, 24 Feb 2014 15:54:46 +0200	[thread overview]
Message-ID: <1393250086.13131.105.camel@intelbox> (raw)
In-Reply-To: <CA+gsUGQ_RkM9sizAmt74eaL+Bxk2etujpghi-RuSuTTG0kYxsw@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 5774 bytes --]

On Mon, 2014-02-24 at 10:38 -0300, Paulo Zanoni wrote:
> 2014-02-20 16:21 GMT-03:00 Jesse Barnes <jbarnes@virtuousgeek.org>:
> > On Tue, 18 Feb 2014 00:02:05 +0200
> > Imre Deak <imre.deak@intel.com> wrote:
> >
> >> These macros are used only locally, so move them to the .c file.
> >>
> >> Also since logically the init power domain should be part of all power
> >> wells add it to the always-on power wells too for consistency. Since
> >> always-on power wells have noop handlers, this doesn't change the
> >> functionality.
> 
> This patch should be split in two: one moves to .c, the other changes
> the init power domain.

Ok.

> But I'm a little confused. I always understood that the "power_on"
> domains were things that were always enabled on the hardware, so you
> couldn't really turn them "off", no matter how many domains you put.
> But the init power domain is different: when you get the init domain,
> a lot of stuff can get enabled, and when you put it, a lot of stuff
> can be disabled. By this logic, your patch would not make sense. So I
> guess we probably have two different definitions for what is a
> always_on power domain. I think we probably need to add some comments
> in the source code to clarify the definitions of things, to avoid
> further confusion :)

In general getting a power domain guarantees that you can access the
relevant registers, so if you get POWER_DOMAIN_INIT it should enable all
the HW resources necessary for this. For always-on power wells that
won't involve turning on a power well, but it may involve enabling other
resources. A good example is the HSW CRT port power domain, which is on
the always-on power well, so we don't need to enable any power well for
it, but we still need to disable runtime PM.

--Imre

> 
> >>
> >> Signed-off-by: Imre Deak <imre.deak@intel.com>
> >> ---
> >>  drivers/gpu/drm/i915/i915_drv.h | 10 ----------
> >>  drivers/gpu/drm/i915/intel_pm.c | 21 +++++++++++++++++++--
> >>  2 files changed, 19 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> >> index 796f971..de0c0e0 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -121,8 +121,6 @@ enum intel_display_power_domain {
> >>       POWER_DOMAIN_NUM,
> >>  };
> >>
> >> -#define POWER_DOMAIN_MASK (BIT(POWER_DOMAIN_NUM) - 1)
> >> -
> >>  #define POWER_DOMAIN_PIPE(pipe) ((pipe) + POWER_DOMAIN_PIPE_A)
> >>  #define POWER_DOMAIN_PIPE_PANEL_FITTER(pipe) \
> >>               ((pipe) + POWER_DOMAIN_PIPE_A_PANEL_FITTER)
> >> @@ -130,14 +128,6 @@ enum intel_display_power_domain {
> >>       ((tran) == TRANSCODER_EDP ? POWER_DOMAIN_TRANSCODER_EDP : \
> >>        (tran) + POWER_DOMAIN_TRANSCODER_A)
> >>
> >> -#define HSW_ALWAYS_ON_POWER_DOMAINS (                \
> >> -     BIT(POWER_DOMAIN_PIPE_A) |              \
> >> -     BIT(POWER_DOMAIN_TRANSCODER_EDP))
> >> -#define BDW_ALWAYS_ON_POWER_DOMAINS (                \
> >> -     BIT(POWER_DOMAIN_PIPE_A) |              \
> >> -     BIT(POWER_DOMAIN_TRANSCODER_EDP) |      \
> >> -     BIT(POWER_DOMAIN_PIPE_A_PANEL_FITTER))
> >> -
> >>  enum hpd_pin {
> >>       HPD_NONE = 0,
> >>       HPD_PORT_A = HPD_NONE, /* PORT_A is internal */
> >> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> >> index db48d55..9a608f1 100644
> >> --- a/drivers/gpu/drm/i915/intel_pm.c
> >> +++ b/drivers/gpu/drm/i915/intel_pm.c
> >> @@ -5384,6 +5384,23 @@ void i915_release_power_well(void)
> >>  }
> >>  EXPORT_SYMBOL_GPL(i915_release_power_well);
> >>
> >> +#define POWER_DOMAIN_MASK (BIT(POWER_DOMAIN_NUM) - 1)
> >> +
> >> +#define HSW_ALWAYS_ON_POWER_DOMAINS (                        \
> >> +     BIT(POWER_DOMAIN_PIPE_A) |                      \
> >> +     BIT(POWER_DOMAIN_TRANSCODER_EDP) |              \
> >> +     BIT(POWER_DOMAIN_INIT))
> >> +#define HSW_DISPLAY_POWER_DOMAINS (                          \
> >> +     (POWER_DOMAIN_MASK & ~HSW_ALWAYS_ON_POWER_DOMAINS) |    \
> >> +     BIT(POWER_DOMAIN_INIT))
> >> +
> >> +#define BDW_ALWAYS_ON_POWER_DOMAINS (                        \
> >> +     HSW_ALWAYS_ON_POWER_DOMAINS |                   \
> >> +     BIT(POWER_DOMAIN_PIPE_A_PANEL_FITTER))
> >> +#define BDW_DISPLAY_POWER_DOMAINS (                          \
> >> +     (POWER_DOMAIN_MASK & ~BDW_ALWAYS_ON_POWER_DOMAINS) |    \
> >> +     BIT(POWER_DOMAIN_INIT))
> >> +
> >>  static struct i915_power_well i9xx_always_on_power_well[] = {
> >>       {
> >>               .name = "always-on",
> >> @@ -5400,7 +5417,7 @@ static struct i915_power_well hsw_power_wells[] = {
> >>       },
> >>       {
> >>               .name = "display",
> >> -             .domains = POWER_DOMAIN_MASK & ~HSW_ALWAYS_ON_POWER_DOMAINS,
> >> +             .domains = HSW_DISPLAY_POWER_DOMAINS,
> >>               .is_enabled = hsw_power_well_enabled,
> >>               .set = hsw_set_power_well,
> >>       },
> >> @@ -5414,7 +5431,7 @@ static struct i915_power_well bdw_power_wells[] = {
> >>       },
> >>       {
> >>               .name = "display",
> >> -             .domains = POWER_DOMAIN_MASK & ~BDW_ALWAYS_ON_POWER_DOMAINS,
> >> +             .domains = BDW_DISPLAY_POWER_DOMAINS,
> >>               .is_enabled = hsw_power_well_enabled,
> >>               .set = hsw_set_power_well,
> >>       },
> >
> > Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> >
> > --
> > Jesse Barnes, Intel Open Source Technology Center
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> 
> 


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

  reply	other threads:[~2014-02-24 13:54 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-17 22:02 [PATCH 00/19] drm/i915: vlv power domains support Imre Deak
2014-02-17 22:02 ` [PATCH 01/19] drm/i915: use drm_i915_private everywhere in the power domain api Imre Deak
2014-02-20 19:16   ` Jesse Barnes
2014-02-17 22:02 ` [PATCH 02/19] drm/i915: fold in __intel_power_well_get/put functions Imre Deak
2014-02-20 19:17   ` Jesse Barnes
2014-02-20 19:44     ` Chris Wilson
2014-02-24 13:23   ` Paulo Zanoni
2014-02-24 14:07     ` Imre Deak
2014-02-17 22:02 ` [PATCH 03/19] drm/i915: move modeset_update_power_wells earlier Imre Deak
2014-02-20 19:18   ` Jesse Barnes
2014-02-17 22:02 ` [PATCH 04/19] drm/i915: move power domain macros to intel_pm.c Imre Deak
2014-02-20 19:21   ` Jesse Barnes
2014-02-24 13:38     ` Paulo Zanoni
2014-02-24 13:54       ` Imre Deak [this message]
2014-02-17 22:02 ` [PATCH 05/19] drm/i915: power domains: add power well ops Imre Deak
2014-02-20 19:26   ` Jesse Barnes
2014-02-24 11:42     ` Imre Deak
2014-02-17 22:02 ` [PATCH 06/19] drm/i915: remove power_well->always_on flag Imre Deak
2014-02-20 19:27   ` Jesse Barnes
2014-02-17 22:02 ` [PATCH 07/19] drm/i915: add port power domains Imre Deak
2014-02-20 19:31   ` Jesse Barnes
2014-02-24 11:52     ` Imre Deak
2014-03-05 10:11   ` Daniel Vetter
2014-02-17 22:02 ` [PATCH 08/19] drm/i915: get port power domain in connector detect Imre Deak
2014-02-19 12:35   ` Ville Syrjälä
2014-02-19 12:39     ` Imre Deak
2014-02-20 19:33       ` Jesse Barnes
2014-02-24 11:56         ` Imre Deak
2014-03-05 10:15           ` Daniel Vetter
2014-02-17 22:02 ` [PATCH 09/19] drm/i915: check port power domain when reading the encoder hw state Imre Deak
2014-02-20 19:36   ` Jesse Barnes
2014-02-24 12:53     ` Imre Deak
2014-03-05 10:21   ` Daniel Vetter
2014-02-17 22:02 ` [PATCH 10/19] drm/i915: check pipe power domain when reading its " Imre Deak
2014-02-20 19:37   ` Jesse Barnes
2014-03-05 10:24     ` Daniel Vetter
2014-02-17 22:02 ` [PATCH 11/19] drm/i915: vlv: keep first level vblank IRQs masked Imre Deak
2014-02-18 16:54   ` Ville Syrjälä
2014-02-17 22:02 ` [PATCH 12/19] drm/i915: sanitize PUNIT register macro definitions Imre Deak
2014-02-20 19:46   ` Jesse Barnes
2014-02-24 13:12     ` Imre Deak
2014-02-17 22:02 ` [PATCH 13/19] drm/i915: factor out reset_vblank_counter Imre Deak
2014-02-18 16:55   ` Ville Syrjälä
2014-02-17 22:02 ` [PATCH 14/19] drm/i915: switch order of power domain init wrt. irq install Imre Deak
2014-02-20 19:48   ` Jesse Barnes
2014-02-24 13:23     ` Imre Deak
2014-03-05 10:29       ` Daniel Vetter
2014-02-17 22:02 ` [PATCH 15/19] drm/i915: use power domain api to check vga power state Imre Deak
2014-02-20 19:51   ` Jesse Barnes
2014-03-05 10:31     ` Daniel Vetter
2014-02-17 22:02 ` [PATCH 16/19] drm/i915: sanity check power well sw state against hw state Imre Deak
2014-02-18 16:55   ` Ville Syrjälä
2014-02-18 17:37     ` Imre Deak
2014-02-18 17:59       ` Ville Syrjälä
2014-03-05 10:32         ` Daniel Vetter
2014-02-17 22:02 ` [PATCH 17/19] drm/i915: vlv: factor out valleyview_display_irq_install Imre Deak
2014-02-20 19:56   ` Jesse Barnes
2014-02-24 13:34     ` Imre Deak
2014-02-17 22:02 ` [PATCH 18/19] drm/i915: move hsw power domain comment to its right place Imre Deak
2014-02-20 19:53   ` Jesse Barnes
2014-03-05 10:34     ` Daniel Vetter
2014-02-17 22:02 ` [PATCH 19/19] drm/i915: power domains: add vlv power wells Imre Deak
2014-02-19 12:29   ` Ville Syrjälä
2014-02-20 19:58     ` Jesse Barnes
2014-02-26 18:02       ` Imre Deak
2014-02-26 19:52         ` Jesse Barnes
2014-02-27 10:03           ` Imre Deak
2014-03-05 10:38           ` Daniel Vetter

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=1393250086.13131.105.camel@intelbox \
    --to=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=przanoni@gmail.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