From: Sunil Kamath <sunil.kamath@intel.com>
To: imre.deak@intel.com
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH v3 01/13] drm/i915/gen9: csr_init after runtime pm enable
Date: Wed, 04 Nov 2015 14:57:23 +0530 [thread overview]
Message-ID: <5639CF7B.6080605@intel.com> (raw)
In-Reply-To: <1446126908.28303.18.camel@intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 4061 bytes --]
On Thursday 29 October 2015 07:25 PM, Imre Deak wrote:
> On to, 2015-10-29 at 15:48 +0530, Sunil Kamath wrote:
>> On Thursday 29 October 2015 03:28 AM, Imre Deak wrote:
>>> From: Animesh Manna <animesh.manna@intel.com>
>>>
>>> Skl is fully dependent on dmc for going to low power state (dc5/dc6).
>>> This requires a trigger from rpm. To ensure the dmc firmware
>>> is available for runtime pm support rpm-reference-count is used
>>> by not releasing the rpm reference if firmware loading is
>>> not completed.
>>>
>>> So moved the intel_csr_ucode_init call after runtime pm enable.
>>>
>>> Cc: Daniel Vetter <daniel.vetter@intel.com>
>>> Cc: Damien Lespiau <damien.lespiau@intel.com>
>>> Cc: Imre Deak <imre.deak@intel.com>
>>> Cc: Sunil Kamath <sunil.kamath@intel.com>
>>> Signed-off-by: Animesh Manna <animesh.manna@intel.com>
>>> [imre: moved the call right after power domain init to avoid race with
>>> the console modesetting]
>>> ---
>>> drivers/gpu/drm/i915/i915_dma.c | 5 ++---
>>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
>>> index 2336af9..5d68942 100644
>>> --- a/drivers/gpu/drm/i915/i915_dma.c
>>> +++ b/drivers/gpu/drm/i915/i915_dma.c
>>> @@ -398,6 +398,8 @@ static int i915_load_modeset_init(struct drm_device *dev)
>>>
>>> intel_power_domains_init_hw(dev_priv);
>>>
>>> + intel_csr_ucode_init(dev);
>>> +
>> Its really unclear why this call to be done here.
>> We need to call just after intel_runtime_pm_enable.
>> With this change it will do much in advance.
> In general the earlier we start the firmware loading work the better,
> since we can start saving power the earliest this way.
>
>> Can you please add some more details about "how adding change after
>> iniet_runtime_pm_enable() will create race condition for console
>> modesetting?"
> We want to avoid to call into either the power well code or the runtime
> s/r handlers. This is why we take a ref on the INIT power domain in
> intel_csr_ucode_init() which should prevent both. Now if we do this only
> after the point where a power well reference can drop to zero, there is
> a chance that we call into the power well code before we took the above
> INIT power domain ref.
>
> If you look at i915_load_modeset_init(), it schedules
> intel_fbdev_initial_config(), which may end up doing a modeset for the
> console, leading up to intel_modeset_setup_hw_state() and
> intel_display_set_init_power(false). Depending on the the active outputs
> this may drop the last reference on some domains and call into the power
> well code.
>
> Due to similar reasons we could drop the last runtime PM reference and
> call the runtime s/r handlers before the firmware is loaded if we took
> the INIT power domain ref only after calling intel_runtime_pm_enable().
>
> --Imre
>
>> - Sunil
>>
Concern that we had was:
In intel_csr_ucode_init() we are calling
intel_display_power_get(dev_priv, POWER_DOMAIN_INIT); which intern call
intel_runtime_pm_get. That means rpm will not be enabled before this
code flow.
Now it’s clear that that's not a problem. As we do RPM gets even
earlier. It will only drop an RPM reference, that in effect will make it
possible to enter RPM. There are places taking an RPM ref already
earlier like in intel_power_domains_init_hw() and RPM references are
taken even before our driver's probe runtime is called by the pci core.
So that's completely normal.
Reviewed-by: A.Sunil Kamath <sunil.kamath@intel.com>
<mailto:sunil.kamath@intel.com>
>>> ret = intel_irq_install(dev_priv);
>>> if (ret)
>>> goto cleanup_gem_stolen;
>>> @@ -942,9 +944,6 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags)
>>>
>>> intel_uncore_init(dev);
>>>
>>> - /* Load CSR Firmware for SKL */
>>> - intel_csr_ucode_init(dev);
>>> -
>>> ret = i915_gem_gtt_init(dev);
>>> if (ret)
>>> goto out_freecsr;
>
[-- Attachment #1.2: Type: text/html, Size: 5618 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-11-04 9:27 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-28 21:58 [PATCH v3 00/13] drm/i915: Redesign dmc firmware loading Imre Deak
2015-10-28 21:58 ` [PATCH v3 01/13] drm/i915/gen9: csr_init after runtime pm enable Imre Deak
2015-10-29 10:18 ` Sunil Kamath
2015-10-29 13:55 ` Imre Deak
2015-11-04 9:27 ` Sunil Kamath [this message]
2015-10-28 21:58 ` [PATCH v3 02/13] drm/i915: use correct power domain for csr loading Imre Deak
2015-10-28 21:58 ` [PATCH v3 03/13] drm/i915/gen9: move assert_csr_loaded into intel_rpm.c Imre Deak
2015-11-12 12:22 ` Imre Deak
2015-11-12 14:48 ` Jani Nikula
2015-11-12 15:09 ` Imre Deak
2015-10-28 21:58 ` [PATCH v3 04/13] drm/i915/gen9: Remove csr.state, csr_lock and related code Imre Deak
2015-10-29 9:02 ` Animesh Manna
2015-11-12 15:10 ` [PATCH v4 " Imre Deak
2015-10-28 21:58 ` [PATCH v3 05/13] drm/i915/gen9: Align line continuations in intel_csr.c Imre Deak
2015-10-28 21:59 ` [PATCH v3 06/13] drm/i915/gen9: Simplify csr loading failure printing Imre Deak
2015-10-28 21:59 ` [PATCH v3 07/13] drm/i915/gen9: Don't try to load garbage dmc firmware on resume Imre Deak
2015-10-28 21:59 ` [PATCH v3 08/13] drm/i915/gen9: Use dev_priv in csr functions Imre Deak
2015-10-28 21:59 ` [PATCH v3 09/13] drm/i915/gen9: extract parse_csr_fw Imre Deak
2015-11-12 15:11 ` [PATCH v4 " Imre Deak
2015-10-28 21:59 ` [PATCH v3 10/13] drm/i915: Use request_firmware and our own async work Imre Deak
2015-10-28 21:59 ` [PATCH v3 11/13] drm/i915/gen9: Use flush_work to synchronize with dmc loader Imre Deak
2015-10-28 21:59 ` [PATCH v3 12/13] drm/i915/gen9: flush DMC fw loading work during system suspend Imre Deak
2015-10-29 9:05 ` Animesh Manna
2015-10-28 21:59 ` [PATCH v3 13/13] drm/i915/skl: Removed assert for csr-fw-loading check during disabling dc6 Imre Deak
2015-10-29 8:08 ` [PATCH v3 00/13] drm/i915: Redesign dmc firmware loading Jani Nikula
2015-10-29 13:32 ` Imre Deak
2015-11-04 17:16 ` Daniel Stone
2015-11-12 15:37 ` Jani Nikula
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=5639CF7B.6080605@intel.com \
--to=sunil.kamath@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=imre.deak@intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox