All of lore.kernel.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 02/19] drm/i915/execlists: Refactor common engine setup
Date: Thu, 5 May 2016 12:55:07 +0100	[thread overview]
Message-ID: <572B349B.9050709@linux.intel.com> (raw)
In-Reply-To: <572B2BD2.80905@linux.intel.com>


On 05/05/16 12:17, Tvrtko Ursulin wrote:
>
> On 05/05/16 11:33, Chris Wilson wrote:
>> On Thu, May 05, 2016 at 11:18:41AM +0100, Tvrtko Ursulin wrote:
>>>
>>> Hi,
>>>
>>> On 05/05/16 10:15, 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.
>>>> v3: Sanitize the engine's IMR to disable any potential interrupt before
>>>> we are ready (enabled in init_hw).
>>>
>>> Same as before - I don't like hardware access in this code path
>>> since we otherwise have it split into a later init_hw phase. And I
>>> don't like engine->dev being used for intel_engine_initialized.
>>
>> I think you raised a good point on the last round! It is an oversight
>> that we have not explicitly sanitized the per-engine registers as is our
>> mo. This gives us the symmetry with the init_hw phase where they are
>> enabled.
>>
>>> On retrospect, interrupt vs engine->irq_queue race is already there
>>> now, for the render ring at least. So maybe just drop the IMR bit
>>> which would make the patch pure refactoring and can have my R-b
>>> then.
>>
>> And this closes a race with a potential interrupt pending from takeover.
>
> Okay but whether or not I have raised a good point I think it wouldn't
> harm to split the pure refactoring from functional changes. You get at
> least one R-b like that. ;)

On the other hand, what I called pure refactoring is also adding the 
race window to other engines. So don't know.. engine->initialized? :) It 
doesn't look like anything in setup depends on it being true.

Regards,

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

  reply	other threads:[~2016-05-05 11:55 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-05  9:15 [PATCH 01/19] drm: Restore double clflush on the last partial cacheline Chris Wilson
2016-05-05  9:15 ` [PATCH 02/19] drm/i915/execlists: Refactor common engine setup Chris Wilson
2016-05-05 10:18   ` Tvrtko Ursulin
2016-05-05 10:33     ` Chris Wilson
2016-05-05 11:17       ` Tvrtko Ursulin
2016-05-05 11:55         ` Tvrtko Ursulin [this message]
2016-05-05  9:15 ` [PATCH 03/19] drm/i915: Store a i915 backpointer from engine, and use it Chris Wilson
2016-05-05 11:15   ` Tvrtko Ursulin
2016-05-05 11:26     ` Chris Wilson
2016-05-05 11:37     ` [PATCH v2] " Chris Wilson
2016-05-05 12:54       ` Tvrtko Ursulin
2016-05-05  9:15 ` [PATCH 04/19] drm/i915/shrinker: Flush active on objects before counting Chris Wilson
2016-05-05  9:15 ` [PATCH 05/19] drm/i915: Delay queuing hangcheck to wait-request Chris Wilson
2016-05-05  9:15 ` [PATCH 06/19] drm/i915: Remove the dedicated hangcheck workqueue Chris Wilson
2016-05-05  9:15 ` [PATCH 07/19] drm/i915: Make queueing the hangcheck work inline Chris Wilson
2016-05-05  9:15 ` [PATCH 08/19] drm/i915: Slaughter the thundering i915_wait_request herd Chris Wilson
2016-05-05  9:15 ` [PATCH 09/19] drm/i915: Remove the lazy_coherency parameter from request-completed? Chris Wilson
2016-05-05  9:15 ` [PATCH 10/19] drm/i915: Use HWS for seqno tracking everywhere Chris Wilson
2016-05-05  9:16 ` [PATCH 11/19] drm/i915: Add a delay between interrupt and inspecting the final seqno (ilk) Chris Wilson
2016-05-05  9:16 ` [PATCH 12/19] drm/i915: Check the CPU cached value of seqno after waking the waiter Chris Wilson
2016-05-05  9:16 ` [PATCH 13/19] drm/i915: Only apply one barrier after a breadcrumb interrupt is posted Chris Wilson
2016-05-05  9:16 ` [PATCH 14/19] drm/i915: Stop setting wraparound seqno on initialisation Chris Wilson
2016-05-05  9:16 ` [PATCH 15/19] drm/i915: Only query timestamp when measuring elapsed time Chris Wilson
2016-05-05  9:16 ` [PATCH 16/19] drm/i915: Convert trace-irq to the breadcrumb waiter Chris Wilson
2016-05-05  9:16 ` [PATCH 17/19] drm/i915: Move the get/put irq locking into the caller Chris Wilson
2016-05-05  9:16 ` [PATCH 18/19] drm/i915: Simplify enabling user-interrupts with L3-remapping Chris Wilson
2016-05-05  9:16 ` [PATCH 19/19] drm/i915: Remove debug noise on detecting fault-injection of missed interrupts 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=572B349B.9050709@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 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.