public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Dave Gordon <david.s.gordon@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>, John.C.Harrison@Intel.com
Cc: Intel-GFX@Lists.FreeDesktop.Org
Subject: Re: [PATCH 03/10] drm/i915: Updating assorted register and status page definitions
Date: Wed, 10 Dec 2014 16:37:31 +0000	[thread overview]
Message-ID: <548876CB.8020302@intel.com> (raw)
In-Reply-To: <20141210104006.GO27182@phenom.ffwll.local>

On 10/12/14 10:40, Daniel Vetter wrote:
> On Tue, Dec 09, 2014 at 12:59:06PM +0000, John.C.Harrison@Intel.com wrote:
>> From: Dave Gordon <david.s.gordon@intel.com>
>>
>> Added various definitions that will be useful for the scheduler in general and
>> pre-emptive context switching in particular.
>>
>> Change-Id: Ica805b94160426def51f5d520f5ce51c60864a98
>> For: VIZ-1587
>> Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
>> ---
>>  drivers/gpu/drm/i915/i915_reg.h         |   30 ++++++++++++++++++++++-
>>  drivers/gpu/drm/i915/intel_ringbuffer.h |   40 +++++++++++++++++++++++++++++--
>>  2 files changed, 67 insertions(+), 3 deletions(-)

[snip]

>> +/*
>> + * Tracking; these are updated by the GPU at the beginning and/or end of every
>> + * batch. One pair for regular buffers, the other for preemptive ones.
>> + */
>> +#define I915_BATCH_DONE_SEQNO		0x30  /* Completed batch seqno        */
>> +#define I915_BATCH_ACTIVE_SEQNO		0x31  /* In progress batch seqno      */
>> +#define I915_PREEMPTIVE_DONE_SEQNO	0x32  /* Completed preemptive batch   */
>> +#define I915_PREEMPTIVE_ACTIVE_SEQNO	0x33  /* In progress preemptive batch */
> 
> This are software define and currently not yet used I think. Imo better to
> add them together with the scheduler code that uses them. Splitting out
> #define patches only makes sense if they can be reviewed separately (e.g.
> registers with Bspec). Just adding software stuff (structs, enums, offsets
> not enforced by hw) should be added with the actual code using it.

OK

>> +
>> +/*
>> + * Preemption; these are used by the GPU to save important registers
>> + */
>> +#define I915_SAVE_PREEMPTED_RING_PTR	0x34  /* HEAD before preemption     */
>> +#define I915_SAVE_PREEMPTED_BB_PTR	0x35  /* BB ptr before preemption   */
>> +#define I915_SAVE_PREEMPTED_SBB_PTR	0x36  /* SBB before preemption      */
>> +#define I915_SAVE_PREEMPTED_UHPTR	0x37  /* UHPTR after preemption     */
>> +#define I915_SAVE_PREEMPTED_HEAD	0x38  /* HEAD after preemption      */
>> +#define I915_SAVE_PREEMPTED_TAIL	0x39  /* TAIL after preemption      */
>> +#define I915_SAVE_PREEMPTED_STATUS	0x3A  /* RS preemption status       */
>> +#define I915_SAVE_PREEMPTED_NOPID	0x3B  /* Dummy                      */
> 
> I guess this is hardcoded in hw? In that case a HWS instead of I915 prefix
> sounds better to me to make it clear this is not something i915/gem code
> invented. Also comment should state whether this is execlist or gen8+ or
> something like that.
> -Daniel

No, these are s/w too, so they can be added later if that's preferred.

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

  reply	other threads:[~2014-12-10 16:39 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-09 12:59 [PATCH 00/10] Prep work patches for GPU scheduler John.C.Harrison
2014-12-09 12:59 ` [PATCH 01/10] drm/i915: Rename 'flags' to 'dispatch_flags' for better code reading John.C.Harrison
2014-12-09 12:59 ` [PATCH 02/10] drm/i915: Add missing trace point to LRC execbuff code path John.C.Harrison
2014-12-09 12:59 ` [PATCH 03/10] drm/i915: Updating assorted register and status page definitions John.C.Harrison
2014-12-10 10:40   ` Daniel Vetter
2014-12-10 16:37     ` Dave Gordon [this message]
2014-12-09 12:59 ` [PATCH 04/10] drm/i915: FIFO space query code refactor John.C.Harrison
2014-12-10 10:41   ` Daniel Vetter
2014-12-10 18:12     ` [PATCH v2] " Dave Gordon
2015-02-20  9:34       ` Mika Kuoppala
2015-02-23 15:46         ` Daniel Vetter
2014-12-09 12:59 ` [PATCH 05/10] drm/i915: Disable 'get seqno' workaround for VLV John.C.Harrison
2014-12-10 10:42   ` Daniel Vetter
2014-12-10 17:11     ` Dave Gordon
2014-12-15  9:02       ` Daniel Vetter
2014-12-09 12:59 ` [PATCH 06/10] drm/i915: Add extra add_request calls John.C.Harrison
2014-12-10 10:55   ` Daniel Vetter
2014-12-09 12:59 ` [PATCH 07/10] drm/i915: Early alloc request John.C.Harrison
2014-12-09 12:59 ` [PATCH 08/10] drm/i915: Prelude to splitting i915_gem_do_execbuffer in two John.C.Harrison
2014-12-10 10:58   ` Daniel Vetter
2014-12-10 16:33     ` Dave Gordon
2014-12-10 17:15       ` Daniel Vetter
2014-12-16 14:26         ` Dave Gordon
2014-12-17 20:09           ` Daniel Vetter
2014-12-18 14:06             ` Dave Gordon
2014-12-09 12:59 ` [PATCH 09/10] drm/i915: Split i915_dem_do_execbuffer() in half John.C.Harrison
2014-12-09 12:59 ` [PATCH 10/10] drm/i915: Cache ringbuf pointer in request structure John.C.Harrison
  -- strict thread matches above, loose matches on Subject: below --
2014-12-08 18:27 [PATCH 1/8] drm/i915: Rebalance runtime pm vs forcewake Mika Kuoppala
2014-12-08 18:27 ` [PATCH 2/8] drm/i915: Assert that runtime pm is active on user fw access Mika Kuoppala
2014-12-12 11:39   ` Deepak S
2014-12-11 11:53     ` Chris Wilson
2014-12-12 11:59       ` Deepak S
2014-12-08 18:27 ` [PATCH 3/8] drm/i915: Skip uncore lock on earlier gens Mika Kuoppala
2014-12-12 11:57   ` Deepak S
2014-12-08 18:27 ` [PATCH 4/8] drm/i915: Reduce duplicated forcewake logic Mika Kuoppala
2014-12-12 12:48   ` Deepak S
2014-12-16 15:26     ` Mika Kuoppala
2014-12-08 18:27 ` [PATCH 5/8] drm/i915: Consolidate forcewake code Mika Kuoppala
2014-12-12 13:13   ` Deepak S
2014-12-08 18:27 ` [PATCH 6/8] drm/i915: Make vlv and chv forcewake put generic Mika Kuoppala
2014-12-12 13:16   ` Deepak S
2014-12-08 18:27 ` [PATCH 7/8] drm/i915: Rename the forcewake get/put functions Mika Kuoppala
2014-12-12 13:19   ` Deepak S
2014-12-08 18:27 ` [PATCH 8/8] drm/i915: Follow the forcewake domains type on hw accessors Mika Kuoppala
2014-12-09 11:46   ` [PATCH 8/8] drm/i915: Enum forcewake domains and domain identifiers Mika Kuoppala
2014-12-09 13:32     ` Jani Nikula
2014-12-09 13:36       ` Daniel Vetter
2014-12-09 15:37       ` Mika Kuoppala
2014-12-12 13:21     ` Deepak S
2014-12-09 23:29   ` [PATCH 8/8] drm/i915: Follow the forcewake domains type on hw accessors shuang.he
2014-12-12 13:20   ` Deepak S
2014-12-12 10:00 ` [PATCH 1/8] drm/i915: Rebalance runtime pm vs forcewake Deepak S
2014-12-11 10:15   ` Chris Wilson
2014-12-12 11:24     ` Deepak S
2014-12-15  8:46     ` Daniel Vetter
2014-12-12 16:22 ` Paulo Zanoni
2014-12-12 16:45   ` 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=548876CB.8020302@intel.com \
    --to=david.s.gordon@intel.com \
    --cc=Intel-GFX@Lists.FreeDesktop.Org \
    --cc=John.C.Harrison@Intel.com \
    --cc=daniel@ffwll.ch \
    /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