mbox series

[0/4] Further multi-gt handling

Message ID 20220914220427.3091448-1-matthew.d.roper@intel.com (mailing list archive)
Headers show
Series Further multi-gt handling | expand

Message

Matt Roper Sept. 14, 2022, 10:04 p.m. UTC
Now that MTL is going to start providing two GTs, there are a few more
places in the driver that need to iterate over each GT instead of
operating directly on gt0.  Also some more deliberate cleanup is needed,
in cases where we fail GT/engine initialization after the first GT has
been fully setup.

Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>

Chris Wilson (1):
  drm/i915/gt: Cleanup partial engine discovery failures

Tvrtko Ursulin (3):
  drm/i915: Make GEM resume all engines
  drm/i915: Make GEM suspend all GTs
  drm/i915: Handle all GTs on driver (un)load paths

 drivers/gpu/drm/i915/gem/i915_gem_pm.c    | 33 ++++++++++++++--
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 16 ++++++--
 drivers/gpu/drm/i915/i915_driver.c        |  3 +-
 drivers/gpu/drm/i915/i915_gem.c           | 46 +++++++++++++++++------
 4 files changed, 78 insertions(+), 20 deletions(-)

Comments

Jani Nikula Sept. 15, 2022, 12:25 p.m. UTC | #1
On Wed, 14 Sep 2022, Matt Roper <matthew.d.roper@intel.com> wrote:
> Now that MTL is going to start providing two GTs, there are a few more
> places in the driver that need to iterate over each GT instead of
> operating directly on gt0.  Also some more deliberate cleanup is needed,
> in cases where we fail GT/engine initialization after the first GT has
> been fully setup.

Hijacking the thread a bit, not to be considered a blocker for this
series:

Is there a plan to kzalloc i915->gt[0] too in intel_gt_probe_all() so we
wouldn't need to have intel_gt gt0 in struct drm_i915_private? And the
to_gt() inline would return i915->gt[0] instead of &i915->gt0? (And
maybe i915_drv.h wouldn't need the definition of intel_gt anymore! :o)

BR,
Jani.


>
> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>
> Chris Wilson (1):
>   drm/i915/gt: Cleanup partial engine discovery failures
>
> Tvrtko Ursulin (3):
>   drm/i915: Make GEM resume all engines
>   drm/i915: Make GEM suspend all GTs
>   drm/i915: Handle all GTs on driver (un)load paths
>
>  drivers/gpu/drm/i915/gem/i915_gem_pm.c    | 33 ++++++++++++++--
>  drivers/gpu/drm/i915/gt/intel_engine_cs.c | 16 ++++++--
>  drivers/gpu/drm/i915/i915_driver.c        |  3 +-
>  drivers/gpu/drm/i915/i915_gem.c           | 46 +++++++++++++++++------
>  4 files changed, 78 insertions(+), 20 deletions(-)
Andi Shyti Sept. 15, 2022, 9:41 p.m. UTC | #2
Hi Jani,

On Thu, Sep 15, 2022 at 03:25:15PM +0300, Jani Nikula wrote:
> On Wed, 14 Sep 2022, Matt Roper <matthew.d.roper@intel.com> wrote:
> > Now that MTL is going to start providing two GTs, there are a few more
> > places in the driver that need to iterate over each GT instead of
> > operating directly on gt0.  Also some more deliberate cleanup is needed,
> > in cases where we fail GT/engine initialization after the first GT has
> > been fully setup.
> 
> Hijacking the thread a bit, not to be considered a blocker for this
> series:
> 
> Is there a plan to kzalloc i915->gt[0] too in intel_gt_probe_all() so we
> wouldn't need to have intel_gt gt0 in struct drm_i915_private? And the
> to_gt() inline would return i915->gt[0] instead of &i915->gt0? (And
> maybe i915_drv.h wouldn't need the definition of intel_gt anymore! :o)

I had a patch that was doing that and sent it long time ago and
it was rejected.

I can't find it but I will check better to see what was the
reason for it to be rejected.

Andi
Matt Roper Sept. 15, 2022, 11:29 p.m. UTC | #3
On Thu, Sep 15, 2022 at 03:25:15PM +0300, Jani Nikula wrote:
> On Wed, 14 Sep 2022, Matt Roper <matthew.d.roper@intel.com> wrote:
> > Now that MTL is going to start providing two GTs, there are a few more
> > places in the driver that need to iterate over each GT instead of
> > operating directly on gt0.  Also some more deliberate cleanup is needed,
> > in cases where we fail GT/engine initialization after the first GT has
> > been fully setup.
> 
> Hijacking the thread a bit, not to be considered a blocker for this
> series:
> 
> Is there a plan to kzalloc i915->gt[0] too in intel_gt_probe_all() so we
> wouldn't need to have intel_gt gt0 in struct drm_i915_private? And the
> to_gt() inline would return i915->gt[0] instead of &i915->gt0? (And
> maybe i915_drv.h wouldn't need the definition of intel_gt anymore! :o)

Yeah, in the more medium-term I would like to dynamically allocate gt0
(and probably the primary uncore structure too) so that they don't need
to be embedded into dev_priv.  I'll probably wait until most of the
other MTL stuff has landed and we have some CI machines setup to make
sure it doesn't accidentally break anything before doing that though.


Matt

> 
> BR,
> Jani.
> 
> 
> >
> > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> >
> > Chris Wilson (1):
> >   drm/i915/gt: Cleanup partial engine discovery failures
> >
> > Tvrtko Ursulin (3):
> >   drm/i915: Make GEM resume all engines
> >   drm/i915: Make GEM suspend all GTs
> >   drm/i915: Handle all GTs on driver (un)load paths
> >
> >  drivers/gpu/drm/i915/gem/i915_gem_pm.c    | 33 ++++++++++++++--
> >  drivers/gpu/drm/i915/gt/intel_engine_cs.c | 16 ++++++--
> >  drivers/gpu/drm/i915/i915_driver.c        |  3 +-
> >  drivers/gpu/drm/i915/i915_gem.c           | 46 +++++++++++++++++------
> >  4 files changed, 78 insertions(+), 20 deletions(-)
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center