public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	intel-gfx@lists.freedesktop.org,
	Dave Gordon <david.s.gordon@intel.com>
Subject: Re: [PATCH v2] drm/i915/execlists: Refactor common engine setup
Date: Fri, 29 Apr 2016 10:25:41 +0100	[thread overview]
Message-ID: <57232895.3020204@linux.intel.com> (raw)
In-Reply-To: <20160429091504.GE30680@nuc-i3427.alporthouse.com>


On 29/04/16 10:15, Chris Wilson wrote:
> On Fri, Apr 29, 2016 at 10:04:35AM +0100, Tvrtko Ursulin wrote:
>>
>> On 28/04/16 18:35, Chris Wilson wrote:
>>> Move all of the constant assignments up front and into a common
>>> function. This is primarily to ensure the backpointers are set as early
>>> as possible for later use during initialisation.
>>>
>>> v2: Use a constant struct so that all the similar values are set
>>> together.
>>>
>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>>> Cc: Dave Gordon <david.s.gordon@intel.com>
>>> ---
>>>   drivers/gpu/drm/i915/intel_lrc.c | 176 +++++++++++++++++++++------------------
>>>   1 file changed, 93 insertions(+), 83 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
>>> index 874c2515f9d4..2e0eaa9fa240 100644
>>> --- a/drivers/gpu/drm/i915/intel_lrc.c
>>> +++ b/drivers/gpu/drm/i915/intel_lrc.c
>>> @@ -1921,8 +1921,7 @@ void intel_logical_ring_cleanup(struct intel_engine_cs *engine)
>>>   }
>>>
>>>   static void
>>> -logical_ring_default_vfuncs(struct drm_device *dev,
>>> -			    struct intel_engine_cs *engine)
>>> +logical_ring_default_vfuncs(struct intel_engine_cs *engine)
>>>   {
>>>   	/* Default vfuncs which can be overriden by each engine. */
>>>   	engine->init_hw = gen8_init_common_ring;
>>> @@ -1933,7 +1932,7 @@ logical_ring_default_vfuncs(struct drm_device *dev,
>>>   	engine->emit_bb_start = gen8_emit_bb_start;
>>>   	engine->get_seqno = gen8_get_seqno;
>>>   	engine->set_seqno = gen8_set_seqno;
>>> -	if (IS_BXT_REVID(dev, 0, BXT_REVID_A1)) {
>>> +	if (IS_BXT_REVID(engine->dev, 0, BXT_REVID_A1)) {
>>>   		engine->irq_seqno_barrier = bxt_a_seqno_barrier;
>>>   		engine->set_seqno = bxt_a_set_seqno;
>>>   	}
>>> @@ -1944,6 +1943,7 @@ logical_ring_default_irqs(struct intel_engine_cs *engine, unsigned shift)
>>>   {
>>>   	engine->irq_enable_mask = GT_RENDER_USER_INTERRUPT << shift;
>>>   	engine->irq_keep_mask = GT_CONTEXT_SWITCH_INTERRUPT << shift;
>>> +	init_waitqueue_head(&engine->irq_queue);
>>>   }
>>>
>>>   static int
>>> @@ -1964,31 +1964,68 @@ lrc_setup_hws(struct intel_engine_cs *engine,
>>>   	return 0;
>>>   }
>>>
>>> -static int
>>> -logical_ring_init(struct drm_device *dev, struct intel_engine_cs *engine)
>>> +static const struct logical_ring_info {
>>> +	const char *name;
>>> +	unsigned exec_id;
>>> +	unsigned guc_id;
>>> +	u32 mmio_base;
>>> +	unsigned irq_shift;
>>> +} logical_rings[] = {
>>> +	[RCS] = {
>>> +		.name = "render ring",
>>> +		.exec_id = I915_EXEC_RENDER,
>>> +		.guc_id = GUC_RENDER_ENGINE,
>>> +		.mmio_base = RENDER_RING_BASE,
>>> +		.irq_shift = GEN8_RCS_IRQ_SHIFT,
>>> +	},
>>> +	[BCS] = {
>>> +		.name = "blitter ring",
>>> +		.exec_id = I915_EXEC_BLT,
>>> +		.guc_id = GUC_BLITTER_ENGINE,
>>> +		.mmio_base = BLT_RING_BASE,
>>> +		.irq_shift = GEN8_BCS_IRQ_SHIFT,
>>> +	},
>>> +	[VCS] = {
>>> +		.name = "bsd ring",
>>> +		.exec_id = I915_EXEC_BSD,
>>> +		.guc_id = GUC_VIDEO_ENGINE,
>>> +		.mmio_base = GEN6_BSD_RING_BASE,
>>> +		.irq_shift = GEN8_VCS1_IRQ_SHIFT,
>>> +	},
>>> +	[VCS2] = {
>>> +		.name = "bsd2 ring",
>>> +		.exec_id = I915_EXEC_BSD,
>>> +		.guc_id = GUC_VIDEO_ENGINE2,
>>> +		.mmio_base = GEN8_BSD2_RING_BASE,
>>> +		.irq_shift = GEN8_VCS2_IRQ_SHIFT,
>>> +	},
>>> +	[VECS] = {
>>> +		.name = "video enhancement ring",
>>> +		.exec_id = I915_EXEC_VEBOX,
>>> +		.guc_id = GUC_VIDEOENHANCE_ENGINE,
>>> +		.mmio_base = VEBOX_RING_BASE,
>>> +		.irq_shift = GEN8_VECS_IRQ_SHIFT,
>>> +	},
>>> +};
>>> +
>>> +static struct intel_engine_cs *
>>> +logical_ring_setup(struct drm_device *dev, enum intel_engine_id id)
>>>   {
>>
>> Would dev_priv be better? Just to gradually move towards the correct
>> state of things.
>
> I have a patch queued up to do engine->i915 (1 KiB in object code
> reduction) next.
>
>>> +	const struct logical_ring_info *info = &logical_rings[id];
>>>   	struct drm_i915_private *dev_priv = to_i915(dev);
>>> -	struct intel_context *dctx = dev_priv->kernel_context;
>>> +	struct intel_engine_cs *engine = &dev_priv->engine[id];
>>>   	enum forcewake_domains fw_domains;
>>> -	int ret;
>>> -
>>> -	/* Intentionally left blank. */
>>> -	engine->buffer = NULL;
>>>
>>>   	engine->dev = dev;
>>
>> Looking at usages of intel_engine_initialized... one potential
>> danger scenario would be interrupt noise during driver load end in
>> notify ring and explodes. Sounds very unlikely but theoretically it
>> is a regression compared to where engine->dev initialization was
>> before.
>>
>> We should really move away from engine->dev for this and just add an
>> explicit flag.
>
> Hmm. not that but I think we really should be sanitizing the irq here
> and enabling them last.
>
> Like:
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
> index 2e0eaa9fa240..2c94072ab085 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -2016,14 +2016,17 @@ logical_ring_setup(struct drm_device *dev, enum intel_engine_id id)
>          struct intel_engine_cs *engine = &dev_priv->engine[id];
>          enum forcewake_domains fw_domains;
>
> -       engine->dev = dev;
> -
>          engine->id = id;
>          engine->name = info->name;
>          engine->exec_id = info->exec_id;
>          engine->guc_id = info->guc_id;
>          engine->mmio_base = info->mmio_base;
>
> +       /* disable interrupts to this engine before we install ourselves*/
> +       I915_WRITE_IMR(engine, ~0);
> +
> +       engine->dev = dev;
> +
>          /* Intentionally left blank. */
>          engine->buffer = NULL;
>
> Make sense?

Not the most elegant because all the hw access we have so far is in 
engine->init_hw. Why can't we just make intel_engine_initialized return 
false until the very last thing in engine constructors?

Regards,

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

  reply	other threads:[~2016-04-29  9:25 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-28 13:47 [PATCH] drm/i915/execlists: Refactor common engine setup Chris Wilson
2016-04-28 14:17 ` ✗ Fi.CI.BAT: warning for " Patchwork
2016-04-28 15:10 ` [PATCH] " Tvrtko Ursulin
2016-04-28 15:26   ` Chris Wilson
2016-04-28 16:12 ` Dave Gordon
2016-04-28 17:04   ` Chris Wilson
2016-04-28 17:35 ` [PATCH v2] " Chris Wilson
2016-04-29  9:04   ` Tvrtko Ursulin
2016-04-29  9:15     ` Chris Wilson
2016-04-29  9:25       ` Tvrtko Ursulin [this message]
2016-04-29  9:39         ` Chris Wilson
2016-04-29  9:50           ` Tvrtko Ursulin
2016-04-29 10:00             ` Chris Wilson
2016-04-29 10:11               ` Tvrtko Ursulin
2016-04-29 10:22                 ` Chris Wilson
2016-05-02  8:51                   ` Daniel Vetter
2016-05-02 10:58                     ` Chris Wilson
2016-05-09  7:02                       ` Daniel Vetter
2016-05-09  7:45                         ` Chris Wilson
2016-05-09  7:58                           ` Daniel Vetter
2016-05-09 10:41                             ` Chris Wilson
2016-05-10  7:46                               ` Daniel Vetter
2016-05-10  7:50                                 ` Chris Wilson
2016-04-29  9:42         ` 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=57232895.3020204@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=david.s.gordon@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox