Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>,
	Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: Don't do display work on platforms without display
Date: Tue, 11 Oct 2022 09:30:25 +0100	[thread overview]
Message-ID: <593c378f-418c-0058-925a-4ed0a2653779@linux.intel.com> (raw)
In-Reply-To: <87o7ui24r6.wl-ashutosh.dixit@intel.com>


On 11/10/2022 08:34, Dixit, Ashutosh wrote:
> On Tue, 11 Oct 2022 00:22:34 -0700, Jani Nikula wrote:
>>
> 
> Hi Jani,
> 
>> On Mon, 10 Oct 2022, Ashutosh Dixit <ashutosh.dixit@intel.com> wrote:
>>> Do display work only on platforms with display. This avoids holding the
>>> runtime PM wakeref for an additional 100+ ms after GT has been parked.
>>>
>>> Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/7025
>>> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
>>> ---
>>>   drivers/gpu/drm/i915/gt/intel_gt_pm.c | 36 +++++++++++++++------------
>>>   1 file changed, 20 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
>>> index f553e2173bdad..26aa2e979a148 100644
>>> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
>>> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
>>> @@ -70,19 +70,21 @@ static int __gt_unpark(struct intel_wakeref *wf)
>>>
>>> 	GT_TRACE(gt, "\n");
>>>
>>> -	/*
>>> -	 * It seems that the DMC likes to transition between the DC states a lot
>>> -	 * when there are no connected displays (no active power domains) during
>>> -	 * command submission.
>>> -	 *
>>> -	 * This activity has negative impact on the performance of the chip with
>>> -	 * huge latencies observed in the interrupt handler and elsewhere.
>>> -	 *
>>> -	 * Work around it by grabbing a GT IRQ power domain whilst there is any
>>> -	 * GT activity, preventing any DC state transitions.
>>> -	 */
>>> -	gt->awake = intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
>>> -	GEM_BUG_ON(!gt->awake);
>>> +	if (HAS_DISPLAY(i915) && INTEL_DISPLAY_ENABLED(i915)) {
>>
>> Feels like something's wrong if you need both of those.
> 
> Don't think so:
> 
> 	/* Only valid when HAS_DISPLAY() is true */
> 	#define INTEL_DISPLAY_ENABLED(dev_priv) \
> 		(drm_WARN_ON(&(dev_priv)->drm, !HAS_DISPLAY(dev_priv)),         \
> 	         !(dev_priv)->params.disable_display &&                         \
> 	         !intel_opregion_headless_sku(dev_priv))
> 
> Maybe inside display code INTEL_DISPLAY_ENABLED is sufficient since code
> paths have previously invoked HAS_DISPLAY, but not in non-display code.

AFAIR this workaround is only needed when DMC is loaded so I wonder if 
we could detect that instead?

Although then I am not sure why we haven't done it like that from the 
start. Maybe there was a good reason and I just can't remember it.

Looking at the history, b68763741aa2 ("drm/i915: Restore GT performance 
in headless mode with DMC loaded") which added the workaround did not 
add the 100ms delay. That was added later in 81ff52b70577 ("drm/i915/gt: 
Ratelimit display power w/a"). That part sounds like it makes sense - if 
there is cost in these transitions usual approach is too add some 
hysteresis. (And AFAIR in this particular case it was actually a matter 
or re-adding the hysteresis which was lost once GEM idle work handler 
approach was removed.)

So I guess the main question is can we guard this with (ideally 
something better than) HAS_DMC. Perhaps back then GPUs wo/ display were 
simply not in our minds? Or obtaining the "DC off" power well was 
perhaps a no-op in it's own right when there is no display? If that was 
the case and isn't any more would that be feasible to re-add?

Regards,

Tvrtko

> 
> Thanks.
> --
> Ashutosh
> 
>>> +		/*
>>> +		 * It seems that the DMC likes to transition between the DC states a lot
>>> +		 * when there are no connected displays (no active power domains) during
>>> +		 * command submission.
>>> +		 *
>>> +		 * This activity has negative impact on the performance of the chip with
>>> +		 * huge latencies observed in the interrupt handler and elsewhere.
>>> +		 *
>>> +		 * Work around it by grabbing a GT IRQ power domain whilst there is any
>>> +		 * GT activity, preventing any DC state transitions.
>>> +		 */
>>> +		gt->awake = intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
>>> +		GEM_BUG_ON(!gt->awake);
>>> +	}
>>>
>>> 	intel_rc6_unpark(&gt->rc6);
>>> 	intel_rps_unpark(&gt->rps);
>>> @@ -115,9 +117,11 @@ static int __gt_park(struct intel_wakeref *wf)
>>> 	/* Everything switched off, flush any residual interrupt just in case */
>>> 	intel_synchronize_irq(i915);
>>>
>>> -	/* Defer dropping the display power well for 100ms, it's slow! */
>>> -	GEM_BUG_ON(!wakeref);
>>> -	intel_display_power_put_async(i915, POWER_DOMAIN_GT_IRQ, wakeref);
>>> +	if (HAS_DISPLAY(i915) && INTEL_DISPLAY_ENABLED(i915)) {
>>> +		/* Defer dropping the display power well for 100ms, it's slow! */
>>> +		GEM_BUG_ON(!wakeref);
>>> +		intel_display_power_put_async(i915, POWER_DOMAIN_GT_IRQ, wakeref);
>>> +	}
>>>
>>> 	return 0;
>>>   }
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2022-10-11  8:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-11  3:27 [Intel-gfx] [PATCH 0/2] Firm up gt park/unpark Ashutosh Dixit
2022-10-11  3:28 ` [Intel-gfx] [PATCH 1/2] drm/i915/gt: Don't do display work on platforms without display Ashutosh Dixit
2022-10-11  7:22   ` Jani Nikula
2022-10-11  7:34     ` Dixit, Ashutosh
2022-10-11  8:30       ` Tvrtko Ursulin [this message]
2022-10-11  8:34         ` Tvrtko Ursulin
2022-10-11  3:29 ` [Intel-gfx] [PATCH 2/2] drm/i915/gt: Warn if not in RC6 when GT is parked Ashutosh Dixit
2022-10-11  5:53   ` Dixit, Ashutosh
2022-10-11  8:35     ` Tvrtko Ursulin
2022-10-11  3:47 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Firm up gt park/unpark Patchwork
2022-10-11  4:37 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " 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=593c378f-418c-0058-925a-4ed0a2653779@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=ashutosh.dixit@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox