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
Subject: Re: [RFC 01/14] drm/i915: Make i915_check_and_clear_faults take uncore
Date: Tue, 11 Jun 2019 13:05:58 +0100	[thread overview]
Message-ID: <421cccc8-bf07-870b-7289-da0e67f2b4e9@linux.intel.com> (raw)
In-Reply-To: <156024312932.2497.10958718717558667647@skylake-alporthouse-com>


On 11/06/2019 09:52, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-06-11 09:35:07)
>>
>> On 10/06/2019 17:26, Chris Wilson wrote:
>>> Quoting Tvrtko Ursulin (2019-06-10 16:54:06)
>>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>
>>>> Continuing the conversion and elimination of implicit dev_priv.
>>>>
>>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>> Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>>> ---
>>>>    drivers/gpu/drm/i915/gt/intel_engine_cs.c |  2 +-
>>>>    drivers/gpu/drm/i915/gt/intel_reset.c     | 28 ++++++++++++-----------
>>>>    drivers/gpu/drm/i915/gt/intel_reset.h     |  2 +-
>>>>    drivers/gpu/drm/i915/i915_drv.c           |  2 +-
>>>>    drivers/gpu/drm/i915/i915_gem_gtt.c       |  4 ++--
>>>>    5 files changed, 20 insertions(+), 18 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>>>> index c0d986db5a75..a046e8dccc96 100644
>>>> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>>>> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>>>> @@ -453,7 +453,7 @@ int intel_engines_init_mmio(struct drm_i915_private *i915)
>>>>    
>>>>           RUNTIME_INFO(i915)->num_engines = hweight32(mask);
>>>>    
>>>> -       i915_check_and_clear_faults(i915);
>>>> +       i915_check_and_clear_faults(&i915->uncore);
>>>
>>> This name is still setting off red flags for me, but I have to confess
>>> that staring at it, passing uncore does make sense.
>>
>> Rename to intel_uncore_check_and_clear_faults?
>>
>> Or move later in the series as intel_gt_check_and_clear_faults?
> 
> I think I prefer the latter option, intel_gt_check_and_clear_faults.

Yep agreed.

Any comments on the intel_gt.c the series added?

And the end result in i915_gem_init(_hw)?

>>> I just wish we have per-engines faults everywhere and this could be
>>> reduced to passing engine.
>>>
>>> Hmm, this I guess we will just have to revisit in the near future as we
>>> may get the opportunity to put these regs under more scrutiny.
>>>
>>>>    
>>>>           intel_setup_engine_capabilities(i915);
>>>>    
>>>> diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c
>>>> index 60d24110af80..13471916559b 100644
>>>> --- a/drivers/gpu/drm/i915/gt/intel_reset.c
>>>> +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
>>>> @@ -1166,10 +1166,10 @@ static void gen8_clear_engine_error_register(struct intel_engine_cs *engine)
>>>>           GEN6_RING_FAULT_REG_POSTING_READ(engine);
>>>>    }
>>>>    
>>>> -static void clear_error_registers(struct drm_i915_private *i915,
>>>> +static void clear_error_registers(struct intel_uncore *uncore,
>>>>                                     intel_engine_mask_t engine_mask)
>>>>    {
>>>> -       struct intel_uncore *uncore = &i915->uncore;
>>>> +       struct drm_i915_private *i915 = uncore_to_i915(uncore);
>>>
>>> Grr, I should have objected to uncore_to_i915() loudly from the
>>> beginning
>>>
>>> What's done is done,
>>
>> Is it too late already? Shouldn't be. My thinking was the implementation
>> can easily be changed if/when backpointer is added (instead of
>> container_of). But if you would prefer we start without a helper, but
>> with a direct access to backpointer straight away that is fine by me.
> 
> I'm optimistic that we can land a split display/gt intel_uncore early
> and so the churn is in the not too distant future.

Okay but that doesn't explicitly answer whether you prefer I just drop 
all the XXX_to_YYY wrappers in favour of using direct pointer dereferences.

You are also in favour of replacing engine->i915 with engine->gt 
straight away?

Regards,

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

  reply	other threads:[~2019-06-11 12:06 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-10 15:54 [RFC v2 00/14] Implicit dev_priv removal Tvrtko Ursulin
2019-06-10 15:54 ` [RFC 01/14] drm/i915: Make i915_check_and_clear_faults take uncore Tvrtko Ursulin
2019-06-10 16:26   ` Chris Wilson
2019-06-11  8:35     ` Tvrtko Ursulin
2019-06-11  8:52       ` Chris Wilson
2019-06-11 12:05         ` Tvrtko Ursulin [this message]
2019-06-11 12:12           ` Chris Wilson
2019-06-10 15:54 ` [RFC 02/14] drm/i915: Convert intel_vgt_(de)balloon to uncore Tvrtko Ursulin
2019-06-10 15:54 ` [RFC 03/14] drm/i915: Introduce struct intel_gt as replacement for anonymous i915->gt Tvrtko Ursulin
2019-06-10 15:54 ` [RFC 04/14] drm/i915: Add a couple intel_gt helpers Tvrtko Ursulin
2019-06-10 16:19   ` Chris Wilson
2019-06-10 15:54 ` [RFC 05/14] drm/i915: Convert i915_gem_init_swizzling to intel_gt Tvrtko Ursulin
2019-06-10 15:54 ` [RFC 06/14] drm/i915: Convert init_unused_rings " Tvrtko Ursulin
2019-06-10 15:54 ` [RFC 07/14] drm/i915: Convert gt workarounds " Tvrtko Ursulin
2019-06-10 15:54 ` [RFC 08/14] drm/i915: Store backpointer to intel_gt in the engine Tvrtko Ursulin
2019-06-10 16:16   ` Chris Wilson
2019-06-10 18:17     ` Daniele Ceraolo Spurio
2019-06-11  8:41       ` Tvrtko Ursulin
2019-06-11  9:36         ` Chris Wilson
2019-06-11 16:42           ` Daniele Ceraolo Spurio
2019-06-10 15:54 ` [RFC 09/14] drm/i915: Convert intel_mocs_init_l3cc_table to intel_gt Tvrtko Ursulin
2019-06-10 15:54 ` [RFC 10/14] drm/i915: Convert i915_ppgtt_init_hw " Tvrtko Ursulin
2019-06-10 15:54 ` [RFC 11/14] drm/i915: Consolidate some open coded mmio rmw Tvrtko Ursulin
2019-06-10 15:54 ` [RFC 12/14] drm/i915: Convert i915_gem_init_hw to intel_gt Tvrtko Ursulin
2019-06-10 15:54 ` [RFC 13/14] drm/i915/guc: Move intel_guc_reserved_gtt_size to intel_wopcm_guc_size Tvrtko Ursulin
2019-06-10 18:29   ` Michal Wajdeczko
2019-06-10 15:54 ` [RFC 14/14] drm/i915: Make GuC GGTT reservation work on ggtt Tvrtko Ursulin
2019-06-10 18:43   ` Michal Wajdeczko
2019-06-10 17:42 ` ✗ Fi.CI.CHECKPATCH: warning for Implicit dev_priv removal (rev2) Patchwork
2019-06-10 17:48 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-06-10 18:05 ` ✓ Fi.CI.BAT: success " Patchwork
2019-06-11 23:03 ` ✓ Fi.CI.IGT: " Patchwork

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=421cccc8-bf07-870b-7289-da0e67f2b4e9@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=chris@chris-wilson.co.uk \
    /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.