All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: imre.deak@intel.com
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [RFC 1/3] drm/i915/power: move dc state members to struct i915_power_domains
Date: Mon, 06 Feb 2023 18:21:11 +0200	[thread overview]
Message-ID: <87cz6mzrwo.fsf@intel.com> (raw)
In-Reply-To: <Y91n9NfNyV9F0dWw@ideak-desk.fi.intel.com>

On Fri, 03 Feb 2023, Imre Deak <imre.deak@intel.com> wrote:
> On Thu, Feb 02, 2023 at 10:47:46PM +0200, Jani Nikula wrote:
>> There's only one reference to the struct intel_dmc members dc_state,
>> target_dc_state, and allowed_dc_mask within intel_dmc.c, begging the
>> question why they are under struct intel_dmc to begin with.
>> 
>> Moreover, the only references to i915->display.dmc outside of
>> intel_dmc.c are to these members.
>> 
>> They don't belong. Move them from struct intel_dmc to struct
>> i915_power_domains, which seems like a more suitable place.
>> 
>> Cc: Imre Deak <imre.deak@intel.com>
>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>> ---
>> [...]
>>
>> @@ -481,7 +482,7 @@ void intel_dmc_load_program(struct drm_i915_private *dev_priv)
>>  		}
>>  	}
>>  
>> -	dev_priv->display.dmc.dc_state = 0;
>> +	power_domains->dc_state = 0;
>
> This could be dropped as well, as it's already inited by the time the
> function is called.

The whole dc_state thing originates to 832dba889e27 ("drm/i915/gen9:
Check for DC state mismatch"), and it's all about detecting
mismatches. I'm not sure how that works and if it's still useful.

> I agree with making struct intel_dmc internal to intel_dmc.c. Since DC
> state is a functionality provided by the firmware (except of DC9), an
> alternative would be to move/add get/set/assert etc. DC state functions
> to intel_dmc.c instead and call these from intel_display_power*.c.

That was actually the first patch I wrote but didn't send. There were a
few reasons I switched to this one:

First, it adds a dependency between power well and dmc initialization.

Second, it's a bunch of boilerplate, six get/set functions altogether,
and all of them checking for dmc init in patch 3.

Third, it still seems funny to have these members stored in intel_dmc,
accessed via intel_dmc.c, but intel_dmc.c not actually using them for
anything internally. It's only the power well code that uses
them. Should more of the DC state handling be moved to intel_dmc.c then?


BR,
Jani.


>
>>  
>>  	gen9_set_dc_state_debugmask(dev_priv);
>>  
>> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.h b/drivers/gpu/drm/i915/display/intel_dmc.h
>> index 88eae74dbcf2..da8ba246013e 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dmc.h
>> +++ b/drivers/gpu/drm/i915/display/intel_dmc.h
>> @@ -40,9 +40,6 @@ struct intel_dmc {
>>  		bool present;
>>  	} dmc_info[DMC_FW_MAX];
>>  
>> -	u32 dc_state;
>> -	u32 target_dc_state;
>> -	u32 allowed_dc_mask;
>>  	intel_wakeref_t wakeref;
>>  };
>>  
>> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c
>> index 2954759e9d12..cf13580af34a 100644
>> --- a/drivers/gpu/drm/i915/display/intel_psr.c
>> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
>> @@ -702,6 +702,7 @@ tgl_dc3co_exitline_compute_config(struct intel_dp *intel_dp,
>>  {
>>  	const u32 crtc_vdisplay = crtc_state->uapi.adjusted_mode.crtc_vdisplay;
>>  	struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>> +	struct i915_power_domains *power_domains = &dev_priv->display.power.domains;
>>  	u32 exit_scanlines;
>>  
>>  	/*
>> @@ -718,7 +719,7 @@ tgl_dc3co_exitline_compute_config(struct intel_dp *intel_dp,
>>  	if (crtc_state->enable_psr2_sel_fetch)
>>  		return;
>>  
>> -	if (!(dev_priv->display.dmc.allowed_dc_mask & DC_STATE_EN_DC3CO))
>> +	if (!(power_domains->allowed_dc_mask & DC_STATE_EN_DC3CO))
>>  		return;
>>  
>>  	if (!dc3co_is_pipe_port_compatible(intel_dp, crtc_state))
>> -- 
>> 2.34.1
>> 

-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2023-02-06 16:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-02 20:47 [Intel-gfx] [RFC 0/3] drm/i915/dmc: allocate dmc struct dynamically Jani Nikula
2023-02-02 20:47 ` [Intel-gfx] [RFC 1/3] drm/i915/power: move dc state members to struct i915_power_domains Jani Nikula
2023-02-03 20:00   ` Imre Deak
2023-02-06 16:21     ` Jani Nikula [this message]
2023-02-06 16:58       ` Imre Deak
2023-02-07 10:05         ` Jani Nikula
2023-02-16 12:47           ` Imre Deak
2023-02-02 20:47 ` [Intel-gfx] [RFC 2/3] drm/i915/dmc: drop "ucode" from function names Jani Nikula
2023-02-02 20:47 ` [Intel-gfx] [RFC 3/3] drm/i915/dmc: allocate dmc structure dynamically Jani Nikula
2023-02-02 21:38 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/dmc: allocate dmc struct dynamically Patchwork
2023-02-02 21:53 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " 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=87cz6mzrwo.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=imre.deak@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.