From: "Kamble, Sagar A" <sagar.a.kamble@intel.com>
To: Michal Wajdeczko <michal.wajdeczko@intel.com>,
intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 6/6] drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts
Date: Thu, 14 Sep 2017 21:50:24 +0530 [thread overview]
Message-ID: <f20f4772-95e4-c5d8-855d-127bf472ebdd@intel.com> (raw)
In-Reply-To: <op.y6kck6g6xaggs7@mwajdecz-mobl1.ger.corp.intel.com>
On 9/14/2017 9:41 PM, Michal Wajdeczko wrote:
> On Thu, 14 Sep 2017 18:04:27 +0200, Kamble, Sagar A
> <sagar.a.kamble@intel.com> wrote:
>
>>
>>
>> On 9/14/2017 6:07 PM, Michal Wajdeczko wrote:
>>> On Thu, 14 Sep 2017 11:55:08 +0200, Sagar Arun Kamble
>>> <sagar.a.kamble@intel.com> wrote:
>>>
>>>> From: "Kamble, Sagar A" <sagar.a.kamble@intel.com>
>>>>
>>>> Disabling GuC interrupts involves access to GuC IRQ control registers
>>>> hence ensure device is RPM awake.
>>>>
>>>> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>>> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
>>>> ---
>>>> drivers/gpu/drm/i915/intel_guc_log.c | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/intel_guc_log.c
>>>> b/drivers/gpu/drm/i915/intel_guc_log.c
>>>> index ba36162..d7557b5 100644
>>>> --- a/drivers/gpu/drm/i915/intel_guc_log.c
>>>> +++ b/drivers/gpu/drm/i915/intel_guc_log.c
>>>> @@ -657,8 +657,10 @@ void i915_guc_log_unregister(struct
>>>> drm_i915_private *dev_priv)
>>>> return;
>>>> mutex_lock(&dev_priv->drm.struct_mutex);
>>>> + intel_runtime_pm_get(dev_priv);
>>>> /* GuC logging is currently the only user of Guc2Host
>>>> interrupts */
>>>> gen9_disable_guc_interrupts(dev_priv);
>>>> + intel_runtime_pm_put(dev_priv);
>>>> guc_log_runtime_destroy(&dev_priv->guc);
>>>
>>> Maybe we should just destroy runtime here, and allow irq to be disabled
>>> by intel_uc_fini_hw() which will be called right after. This will also
>>> fix the upcoming case when log will not be the only user of Guc irqs.
>>>
>>> See https://patchwork.freedesktop.org/patch/170390/
>>>
>>> Michal
>> Destroying runtime here may create issues as enabled GuC interrupts
>> may be causing the use of the guc_log_runtime.
>
> Yes, but this should be easy to fix.
>
>> Should we move the i915_driver_unregister post i915_gem_unload?
>
> But then we will have to handle the case when gem was unloaded but
> driver will still be in registered state.
>
> Note that as guc log will not be the only user of the guc irqs,
> code that disables irq will be removed from this function anyway.
>
> Michal
I see now that guc_log_runtime_destroy already happen along
intel_uc_fini_hw->i915_guc_submission_fini->intel_guc_log_destroy path too.
So we can remove guc_log_unregister completely with irq_disable
happening as part of intel_guc_unload and guc_log_runtime_destroy too
handled.
>
>>>
>>>> mutex_unlock(&dev_priv->drm.struct_mutex);
>>>> }
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2017-09-14 16:20 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-14 9:55 [PATCH 0/6] GuC code restructuring and fixes Sagar Arun Kamble
2017-09-14 9:55 ` [PATCH 1/6] drm/i915: Separate GuC/HuC specific functionality from intel_uc Sagar Arun Kamble
2017-09-14 15:54 ` Michal Wajdeczko
2017-09-14 9:55 ` [PATCH 2/6] drm/i915/guc: Make guc_enable/disable_communication functions public Sagar Arun Kamble
2017-09-14 15:31 ` Michal Wajdeczko
2017-09-14 15:56 ` Kamble, Sagar A
2017-09-14 16:02 ` Michal Wajdeczko
2017-09-14 9:55 ` [PATCH 3/6] drm/i915/guc: Fix GuC interaction in reset/suspend scenarios Sagar Arun Kamble
2017-09-14 9:55 ` [PATCH 4/6] drm/i915/guc: Fix GuC HW/SW state cleanup in unload path Sagar Arun Kamble
2017-09-14 9:55 ` [PATCH 5/6] drm/i915/guc: Enable default/critical logging in GuC by default from GuC v9 Sagar Arun Kamble
2017-09-14 13:13 ` Michal Wajdeczko
2017-09-14 16:00 ` Kamble, Sagar A
2017-09-14 9:55 ` [PATCH 6/6] drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts Sagar Arun Kamble
2017-09-14 12:37 ` Michal Wajdeczko
2017-09-14 16:04 ` Kamble, Sagar A
2017-09-14 16:11 ` Michal Wajdeczko
2017-09-14 16:20 ` Kamble, Sagar A [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-09-13 6:30 [PATCH 1/6] drm/i915: Separate GuC/HuC specific functionality from intel_uc Sagar Arun Kamble
2017-09-13 6:30 ` [PATCH 6/6] drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts Sagar Arun Kamble
2017-09-11 6:02 [PATCH 1/6] drm/i915: Separate GuC/HuC specific functionality from intel_uc Sagar Arun Kamble
2017-09-11 6:02 ` [PATCH 6/6] drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts Sagar Arun Kamble
2017-09-11 17:34 ` Michal Wajdeczko
2017-09-12 4:33 ` Kamble, Sagar A
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=f20f4772-95e4-c5d8-855d-127bf472ebdd@intel.com \
--to=sagar.a.kamble@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=michal.wajdeczko@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.