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(>->rc6);
>>> intel_rps_unpark(>->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
next prev parent 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 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.