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
next prev 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