All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/5] drm/i915: unify first-stage engine struct setup
Date: Wed, 13 Jul 2016 14:16:49 +0100	[thread overview]
Message-ID: <57863F41.9000308@linux.intel.com> (raw)
In-Reply-To: <20160713122329.GI23520@phenom.ffwll.local>


On 13/07/16 13:23, Daniel Vetter wrote:
> On Fri, Jul 01, 2016 at 05:47:11PM +0100, Tvrtko Ursulin wrote:
>> From: Dave Gordon <david.s.gordon@intel.com>
>>
>> intel_lrc.c has a table of "logical rings" (meaning engines), while
>> intel_ringbuffer.c has separately open-coded initialisation for each
>> engine. We can deduplicate this somewhat by using the same first-stage
>> engine-setup function for both modes.
>>
>> So here we expose the function that transfers information from the
>> static table of (all) known engines to the dev_priv->engine array of
>> engines available on this device (adjusting the names along the way)
>> and then embed calls to it in both the LRC and the legacy-mode setup.
>>
>> Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
>> ---
>>   drivers/gpu/drm/i915/intel_lrc.c        | 40 +++++++++++++++++++++------------
>>   drivers/gpu/drm/i915/intel_ringbuffer.c | 40 +++++++++------------------------
>>   drivers/gpu/drm/i915/intel_ringbuffer.h |  5 +++++
>>   3 files changed, 41 insertions(+), 44 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
>> index 339d8041075f..ed017f1a07a2 100644
>> --- a/drivers/gpu/drm/i915/intel_lrc.c
>> +++ b/drivers/gpu/drm/i915/intel_lrc.c
>> @@ -1994,8 +1994,9 @@ logical_ring_default_vfuncs(struct intel_engine_cs *engine)
>>   }
>>
>>   static inline void
>> -logical_ring_default_irqs(struct intel_engine_cs *engine, unsigned shift)
>> +logical_ring_default_irqs(struct intel_engine_cs *engine)
>>   {
>> +	unsigned shift = engine->irq_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);
>> @@ -2096,14 +2097,14 @@ static int logical_render_ring_init(struct intel_engine_cs *engine)
>>   	return ret;
>>   }
>>
>> -static const struct logical_ring_info {
>> +static const struct engine_info {
>>   	const char *name;
>>   	unsigned exec_id;
>>   	unsigned guc_id;
>>   	u32 mmio_base;
>>   	unsigned irq_shift;
>>   	int (*init)(struct intel_engine_cs *engine);
>> -} logical_rings[] = {
>> +} intel_engines[] = {
>>   	[RCS] = {
>>   		.name = "render ring",
>>   		.exec_id = I915_EXEC_RENDER,
>> @@ -2146,20 +2147,31 @@ static const struct logical_ring_info {
>>   	},
>>   };
>>
>> -static struct intel_engine_cs *
>> -logical_ring_setup(struct drm_i915_private *dev_priv, enum intel_engine_id id)
>> +struct intel_engine_cs *
>> +intel_engine_setup(struct drm_i915_private *dev_priv,
>> +		   enum intel_engine_id id)
>
> Kerneldoc for this would be nice. Also, we now have a mess between
> intel_lrc.c and intel_ringbuffer.c. Extracting intel_engine.c with the

Yes that was already suggested by Chris and I am trybotting the 
additions today, again on his explicit request to progress this series.

> shared bits or something similar, plus cleanup up all the docs would be
> awesome as a follow up.

What do you mean "all the docs"? :D

>
> With the kerneldoc added:
>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Thanks, will add.

>>   {
>> -	const struct logical_ring_info *info = &logical_rings[id];
>> +	const struct engine_info *info = &intel_engines[id];
>>   	struct intel_engine_cs *engine = &dev_priv->engine[id];
>> -	enum forcewake_domains fw_domains;
>>
>>   	engine->id = id;
>> +	engine->i915 = dev_priv;
>>   	engine->name = info->name;
>>   	engine->exec_id = info->exec_id;
>> -	engine->guc_id = info->guc_id;
>> +	engine->hw_id = engine->guc_id = info->guc_id;
>
> Optional bikeshed: s/info->guc_id/info->hw_id/ makes sense imo in the new
> context. Or nuking engine->guc_id.

Someone said we cannot be sure they will be the same in the future. So 
maybe just rename to hw_id for now.

Regards,

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

  reply	other threads:[~2016-07-13 13:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-01 16:47 [PATCH 1/5] drm/i915: unify first-stage engine struct setup Tvrtko Ursulin
2016-07-01 16:47 ` [PATCH 2/5] drm/i915: Prepare for engine init unification Tvrtko Ursulin
2016-07-01 16:47 ` [PATCH 3/5] drm/i915: Unify engine init loop Tvrtko Ursulin
2016-07-01 16:47 ` [PATCH 4/5] drm/i915: Make more use of the shared engine irq setup Tvrtko Ursulin
2016-07-13 12:30   ` Daniel Vetter
2016-07-13 13:19     ` Tvrtko Ursulin
2016-07-01 16:47 ` [PATCH 5/5] drm/i915: Simplify intel_init_ring_buffer prototype Tvrtko Ursulin
2016-07-13 12:30   ` Daniel Vetter
2016-07-01 17:08 ` ✗ Ro.CI.BAT: warning for series starting with [1/5] drm/i915: unify first-stage engine struct setup Patchwork
2016-07-13 12:23 ` [PATCH 1/5] " Daniel Vetter
2016-07-13 13:16   ` Tvrtko Ursulin [this message]
2016-07-13 13:24     ` Tvrtko Ursulin
2016-07-14 14:29       ` Daniel Vetter
2016-07-14 11:33     ` Dave Gordon
  -- strict thread matches above, loose matches on Subject: below --
2016-07-06 10:52 Tvrtko Ursulin

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=57863F41.9000308@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=Intel-gfx@lists.freedesktop.org \
    --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 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.