From: Imre Deak <imre.deak@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Don't check power domains state in intel_power_domains_init_hw()
Date: Tue, 28 Aug 2018 14:52:20 +0300 [thread overview]
Message-ID: <20180828115220.GC6015@ideak-desk.fi.intel.com> (raw)
In-Reply-To: <153545673098.28857.6301348610876433372@skylake-alporthouse-com>
On Tue, Aug 28, 2018 at 12:45:31PM +0100, Chris Wilson wrote:
> Quoting Imre Deak (2018-08-28 12:40:43)
> > During power domains initialization we acquire power well references for
> > power wells in the INIT power domain. The rest of power wells - which
> > BIOS could have left enabled - we can only acquire references as needed
> > during display HW readout. Thus during initialization these latter power
> > wells can have a refcount of 0 while still being enabled. To avoid the
> > false-positive state mismatch error this causes remove the check from
> > intel_power_domains_init_hw() and rely on the state check in
> > intel_power_domains_enable() which follows the HW readout.
>
> Missing from above is a quick explanation of how those extraneous
> powerwells are sanitizied. If we don't do the HW readout
> (i915.disable_display?) do we not then leave the powerwell active and so
> complain in a later verify_state()?
These power wells (AUX and DDI on ICL) can only be enabled/disabled at
a specific spot in the modeset sequence, otherwise the power well
enable / disable operation will time out. That's the reason they're not
part of the INIT domain. For these we will acquire the references during
HW readout when noticing that the corresponding display HW block is active
and drop them when disabling these HW blocks (normally or as part of
display state sanitizatoionin). That way we'll ensure the proper spot
mentioned above for power well enabling/disabling.
--Imre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-08-28 11:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-28 11:40 [PATCH] drm/i915: Don't check power domains state in intel_power_domains_init_hw() Imre Deak
2018-08-28 11:45 ` Chris Wilson
2018-08-28 11:52 ` Imre Deak [this message]
2018-08-28 11:56 ` Imre Deak
2018-08-28 12:03 ` Chris Wilson
2018-08-28 12:14 ` ✓ Fi.CI.BAT: success for " Patchwork
2018-08-28 12:22 ` [PATCH v2] " Imre Deak
2018-08-28 12:27 ` Chris Wilson
2018-08-28 13:00 ` ✓ Fi.CI.BAT: success for drm/i915: Don't check power domains state in intel_power_domains_init_hw() (rev2) Patchwork
2018-08-28 13:49 ` ✓ Fi.CI.IGT: " Patchwork
2018-08-29 10:28 ` Imre Deak
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=20180828115220.GC6015@ideak-desk.fi.intel.com \
--to=imre.deak@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox