All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Shyti <andi.shyti@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Intel GFX <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH v2 1/2] drm/i915: Extract GT render power state management
Date: Wed, 23 Oct 2019 15:49:04 +0300	[thread overview]
Message-ID: <20191023124904.GB4125@intel.intel> (raw)
In-Reply-To: <157183418163.15766.12473099234353818990@skylake-alporthouse-com>

> > > >          * maximum clocks following a vblank miss (see do_rps_boost()).
> > > >          */
> > > >         if (!intel_state->rps_interactive) {
> > > > -               intel_rps_mark_interactive(dev_priv, true);
> > > > +               intel_rps_mark_interactive(&dev_priv->gt.rps, true);
> > > 
> > > I wonder if we can do &plane->vma->vm->gt->rps
> > 
> > agree, looks ugly, I could fix it by extracting rps. Shall I do
> > it now in a v3 or after the patch gets merged? As you can gues
> > I'd prefer doing after the patch is merged :)
> 
> Mostly thinking aloud. I plan on soak testing this first; something did
> not look quite right around pm_enable/pm_disable vs gt_resume/gt_suspend
> (i.e. did not match my current expectations of where to push the gt init
> next).

yes, it's confusing and to me they look inverted in meaining :).
Do we want to have a unique resume/suspend rather than both?

For this refactoring it was just easier to keep it this way.

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

WARNING: multiple messages have this Message-ID (diff)
From: Andi Shyti <andi.shyti@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Intel GFX <intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Extract GT render power state management
Date: Wed, 23 Oct 2019 15:49:04 +0300	[thread overview]
Message-ID: <20191023124904.GB4125@intel.intel> (raw)
Message-ID: <20191023124904.xwV45yY6PsPzMdMxHjyGSVugBmoy1HJYeO4SB3ebESw@z> (raw)
In-Reply-To: <157183418163.15766.12473099234353818990@skylake-alporthouse-com>

> > > >          * maximum clocks following a vblank miss (see do_rps_boost()).
> > > >          */
> > > >         if (!intel_state->rps_interactive) {
> > > > -               intel_rps_mark_interactive(dev_priv, true);
> > > > +               intel_rps_mark_interactive(&dev_priv->gt.rps, true);
> > > 
> > > I wonder if we can do &plane->vma->vm->gt->rps
> > 
> > agree, looks ugly, I could fix it by extracting rps. Shall I do
> > it now in a v3 or after the patch gets merged? As you can gues
> > I'd prefer doing after the patch is merged :)
> 
> Mostly thinking aloud. I plan on soak testing this first; something did
> not look quite right around pm_enable/pm_disable vs gt_resume/gt_suspend
> (i.e. did not match my current expectations of where to push the gt init
> next).

yes, it's confusing and to me they look inverted in meaining :).
Do we want to have a unique resume/suspend rather than both?

For this refactoring it was just easier to keep it this way.

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

  reply	other threads:[~2019-10-23 12:49 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-23  9:38 [PATCH 0/2] Extract rps and guc Andi Shyti
2019-10-23  9:38 ` [Intel-gfx] " Andi Shyti
2019-10-23  9:38 ` [PATCH 1/2] drm/i915: Extract GT render power state management Andi Shyti
2019-10-23  9:38   ` [Intel-gfx] " Andi Shyti
2019-10-23  9:38 ` [PATCH 2/2] drm/i915: Extract the GuC interrupt handlers Andi Shyti
2019-10-23  9:38   ` [Intel-gfx] " Andi Shyti
2019-10-23  9:50 ` [PATCH v2 1/2] drm/i915: Extract GT render power state management Andi Shyti
2019-10-23  9:50   ` [Intel-gfx] " Andi Shyti
2019-10-23  9:52   ` Andi Shyti
2019-10-23  9:52     ` [Intel-gfx] " Andi Shyti
2019-10-23 12:11   ` Chris Wilson
2019-10-23 12:11     ` [Intel-gfx] " Chris Wilson
2019-10-23 12:32     ` Andi Shyti
2019-10-23 12:32       ` [Intel-gfx] " Andi Shyti
2019-10-23 12:36       ` Chris Wilson
2019-10-23 12:36         ` [Intel-gfx] " Chris Wilson
2019-10-23 12:49         ` Andi Shyti [this message]
2019-10-23 12:49           ` Andi Shyti
2019-10-23 17:48 ` ✗ Fi.CI.CHECKPATCH: warning for Extract rps and guc Patchwork
2019-10-23 17:48   ` [Intel-gfx] " Patchwork
2019-10-23 18:17 ` ✓ Fi.CI.BAT: success " Patchwork
2019-10-23 18:17   ` [Intel-gfx] " Patchwork
2019-10-24 10:24 ` ✗ Fi.CI.IGT: failure " Patchwork
2019-10-24 10:24   ` [Intel-gfx] " 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=20191023124904.GB4125@intel.intel \
    --to=andi.shyti@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --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.