public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 4/6] drm/i915: Dynamically allocate s0ix struct for VLV
Date: Fri, 16 Aug 2019 08:33:54 -0700	[thread overview]
Message-ID: <afb02de2-a004-db0d-b948-c66594946341@intel.com> (raw)
In-Reply-To: <875zmxfo6r.fsf@intel.com>



On 8/16/19 2:35 AM, Jani Nikula wrote:
> On Thu, 15 Aug 2019, Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> wrote:
>> This is only required for a single platform so no need to reserve the
>> memory on all of them.
>>
>> This removes the last direct dependency of i915_drv.h on i915_reg.h
>> (apart from the i915_reg_t definition).
>>
>> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>> Cc: Imre Deak <imre.deak@intel.com>
> 
> Heh, I've already sent a version of this [1], but I don't mind you
> finishing the job. Especially because I think it's better to handle the
> alloc/free explicitly instead of the way I do it.

D'oh! I completely missed that

> 
> I do have some nitpicks on this one though, inline.
> 
> 
> [1] http://patchwork.freedesktop.org/patch/msgid/20190807144939.32123-1-jani.nikula@intel.com
> 
> 

<snip>


>> @@ -2137,7 +2228,7 @@ static int i915_pm_restore(struct device *kdev)
>>    */
>>   static void vlv_save_gunit_s0ix_state(struct drm_i915_private *dev_priv)
>>   {
>> -	struct vlv_s0ix_state *s = &dev_priv->vlv_s0ix_state;
>> +	struct vlv_s0ix_state *s = dev_priv->s0ix_state;
> 
> I think I'd now call this function unconditionally, and return early if
> (!s). This puts the decision to do this or not in one place only, in
> vlv_alloc_s0ix_state(), instead of duplicating the conditions.

ack

> 
> 
>>   	int i;
>>   
>>   	/* GAM 0x4000-0x4770 */
>> @@ -2147,7 +2238,7 @@ static void vlv_save_gunit_s0ix_state(struct drm_i915_private *dev_priv)
>>   	s->gfx_pend_tlb0	= I915_READ(GEN7_GFX_PEND_TLB0);
>>   	s->gfx_pend_tlb1	= I915_READ(GEN7_GFX_PEND_TLB1);
>>   
>> -	for (i = 0; i < ARRAY_SIZE(s->lra_limits); i++)
>> +	for (i = 0; i < GEN7_LRA_LIMITS_REG_NUM; i++)
>>   		s->lra_limits[i] = I915_READ(GEN7_LRA_LIMITS(i));
>>   
>>   	s->media_max_req_count	= I915_READ(GEN7_MEDIA_MAX_REQ_COUNT);
>> @@ -2191,7 +2282,7 @@ static void vlv_save_gunit_s0ix_state(struct drm_i915_private *dev_priv)
>>   	s->pm_imr		= I915_READ(GEN6_PMIMR);
>>   	s->pm_ier		= I915_READ(GEN6_PMIER);
>>   
>> -	for (i = 0; i < ARRAY_SIZE(s->gt_scratch); i++)
>> +	for (i = 0; i < GEN7_GT_SCRATCH_REG_NUM; i++)
>>   		s->gt_scratch[i] = I915_READ(GEN7_GT_SCRATCH(i));
> 
> The above two hunks are in the wrong patch.
> 

Yup, leftovers from a previous version.

>>   
>>   	/* GT SA CZ domain, 0x100000-0x138124 */
>> @@ -2218,7 +2309,7 @@ static void vlv_save_gunit_s0ix_state(struct drm_i915_private *dev_priv)
>>   
>>   static void vlv_restore_gunit_s0ix_state(struct drm_i915_private *dev_priv)
>>   {
>> -	struct vlv_s0ix_state *s = &dev_priv->vlv_s0ix_state;
>> +	struct vlv_s0ix_state *s = dev_priv->s0ix_state;
> 
> Early return on !s here as well, and call the function unconditionally.
> 

ok

>>   	u32 val;
>>   	int i;
>>   
>> @@ -2229,7 +2320,7 @@ static void vlv_restore_gunit_s0ix_state(struct drm_i915_private *dev_priv)
>>   	I915_WRITE(GEN7_GFX_PEND_TLB0,	s->gfx_pend_tlb0);
>>   	I915_WRITE(GEN7_GFX_PEND_TLB1,	s->gfx_pend_tlb1);
>>   
>> -	for (i = 0; i < ARRAY_SIZE(s->lra_limits); i++)
>> +	for (i = 0; i < GEN7_LRA_LIMITS_REG_NUM; i++)
>>   		I915_WRITE(GEN7_LRA_LIMITS(i), s->lra_limits[i]);
>>   
>>   	I915_WRITE(GEN7_MEDIA_MAX_REQ_COUNT, s->media_max_req_count);
>> @@ -2273,7 +2364,7 @@ static void vlv_restore_gunit_s0ix_state(struct drm_i915_private *dev_priv)
>>   	I915_WRITE(GEN6_PMIMR,		s->pm_imr);
>>   	I915_WRITE(GEN6_PMIER,		s->pm_ier);
>>   
>> -	for (i = 0; i < ARRAY_SIZE(s->gt_scratch); i++)
>> +	for (i = 0; i < GEN7_GT_SCRATCH_REG_NUM; i++)
>>   		I915_WRITE(GEN7_GT_SCRATCH(i), s->gt_scratch[i]);
> 
> The above two hunks are in the wrong patch.
> 
>>   
>>   	/* GT SA CZ domain, 0x100000-0x138124 */
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
>> index c6722d54ccd5..9b41f2209b69 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -527,68 +527,6 @@ struct i915_suspend_saved_registers {
>>   	u16 saveGCDGMBUS;
>>   };
>>   
>> -struct vlv_s0ix_state {
>> -	/* GAM */
>> -	u32 wr_watermark;
>> -	u32 gfx_prio_ctrl;
>> -	u32 arb_mode;
>> -	u32 gfx_pend_tlb0;
>> -	u32 gfx_pend_tlb1;
>> -	u32 lra_limits[GEN7_LRA_LIMITS_REG_NUM];
>> -	u32 media_max_req_count;
>> -	u32 gfx_max_req_count;
>> -	u32 render_hwsp;
>> -	u32 ecochk;
>> -	u32 bsd_hwsp;
>> -	u32 blt_hwsp;
>> -	u32 tlb_rd_addr;
>> -
>> -	/* MBC */
>> -	u32 g3dctl;
>> -	u32 gsckgctl;
>> -	u32 mbctl;
>> -
>> -	/* GCP */
>> -	u32 ucgctl1;
>> -	u32 ucgctl3;
>> -	u32 rcgctl1;
>> -	u32 rcgctl2;
>> -	u32 rstctl;
>> -	u32 misccpctl;
>> -
>> -	/* GPM */
>> -	u32 gfxpause;
>> -	u32 rpdeuhwtc;
>> -	u32 rpdeuc;
>> -	u32 ecobus;
>> -	u32 pwrdwnupctl;
>> -	u32 rp_down_timeout;
>> -	u32 rp_deucsw;
>> -	u32 rcubmabdtmr;
>> -	u32 rcedata;
>> -	u32 spare2gh;
>> -
>> -	/* Display 1 CZ domain */
>> -	u32 gt_imr;
>> -	u32 gt_ier;
>> -	u32 pm_imr;
>> -	u32 pm_ier;
>> -	u32 gt_scratch[GEN7_GT_SCRATCH_REG_NUM];
>> -
>> -	/* GT SA CZ domain */
>> -	u32 tilectl;
>> -	u32 gt_fifoctl;
>> -	u32 gtlc_wake_ctrl;
>> -	u32 gtlc_survive;
>> -	u32 pmwgicz;
>> -
>> -	/* Display 2 CZ domain */
>> -	u32 gu_ctl0;
>> -	u32 gu_ctl1;
>> -	u32 pcbr;
>> -	u32 clock_gate_dis2;
>> -};
>> -
>>   struct intel_rps_ei {
>>   	ktime_t ktime;
>>   	u32 render_c0;
>> @@ -1622,7 +1560,7 @@ struct drm_i915_private {
>>   	u32 suspend_count;
>>   	bool power_domains_suspended;
>>   	struct i915_suspend_saved_registers regfile;
>> -	struct vlv_s0ix_state vlv_s0ix_state;
>> +	void *s0ix_state;
> 
> I'd keep the vlv_ prefix in the member name.

ok (including the fwd decl mentioned in the other reply)

Daniele

> 
> BR,
> Jani.
> 
> 
>>   
>>   	enum {
>>   		I915_SAGV_UNKNOWN = 0,
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2019-08-16 15:33 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-16  1:23 [PATCH 0/6] Some more display uncore prep work Daniele Ceraolo Spurio
2019-08-16  1:23 ` [PATCH 1/6] drm/i915: Move i915_power_well_id out of i915_reg.h Daniele Ceraolo Spurio
2019-08-16  4:52   ` Lucas De Marchi
2019-08-16 15:27     ` Daniele Ceraolo Spurio
2019-08-16 15:28       ` Daniele Ceraolo Spurio
2019-08-16  1:23 ` [PATCH 2/6] drm/i915: Move engine IDs " Daniele Ceraolo Spurio
2019-08-16  4:56   ` Lucas De Marchi
2019-08-16  1:23 ` [PATCH 3/6] drm/i915: Move gmbus definitions " Daniele Ceraolo Spurio
2019-08-16  5:03   ` Lucas De Marchi
2019-08-16  1:23 ` [PATCH 4/6] drm/i915: Dynamically allocate s0ix struct for VLV Daniele Ceraolo Spurio
2019-08-16  5:09   ` Lucas De Marchi
2019-08-16 15:30     ` Daniele Ceraolo Spurio
2019-08-16  9:35   ` Jani Nikula
2019-08-16  9:40     ` Chris Wilson
2019-08-16 10:32       ` Jani Nikula
2019-08-16 15:33     ` Daniele Ceraolo Spurio [this message]
2019-08-16  1:23 ` [PATCH 5/6] drm/i915: Introduce i915_reg_types.h Daniele Ceraolo Spurio
2019-08-16  9:40   ` Michal Wajdeczko
2019-08-16 15:35     ` Daniele Ceraolo Spurio
2019-08-16  1:23 ` [PATCH 6/6] drm/i915: Wrappers for display register waits Daniele Ceraolo Spurio
2019-08-16  7:17   ` Chris Wilson
2019-08-16  1:46 ` ✗ Fi.CI.CHECKPATCH: warning for Some more display uncore prep work Patchwork
2019-08-16  2:19 ` ✓ Fi.CI.BAT: success " Patchwork
2019-08-16 17:30 ` ✓ Fi.CI.IGT: " Patchwork
2019-08-16 21:22 ` [PATCH 0/6] " Chris Wilson

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=afb02de2-a004-db0d-b948-c66594946341@intel.com \
    --to=daniele.ceraolospurio@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.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