public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
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

  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