[Intel-gfx] [PATCH 03/10] drm/i915: Add support for asynchronous display power disabling
Chris Wilson
chris at chris-wilson.co.uk
Fri May 3 12:16:04 UTC 2019
Quoting Imre Deak (2019-05-03 00:26:41)
> By disabling a power domain asynchronously we can restrict holding a
> reference on that power domain to the actual code sequence that
> requires the power to be on for the HW access it's doing, by also
> avoiding unneeded on-off-on togglings of the power domain (since the
> disabling happens with a delay).
That applies to no-delay. Are we not starting from a state where the
code acquires the powerwell for its immediate use, or it takes and holds
it for protracted durations even when the powerwell is not being used?
> One benefit is potential power saving if the delay is chosen properly.
Which is suggesting that some delay is better power saving than
no-delay? It's believable that powering on cost mores more energy than
normal. But do please fill in a few details on how the delay should be
chosen.
> In the case of the AUX power domain holding the reference on the domain
> for the minimal amount of time at defined spots is also a requirement:
Do you mean that there is a minimum duration for which the power well
must be asserted once acquired before being released?
> on ICL we need a stricter control of when either kind of AUX power
> domain (TBT-alt or DP-alt) can be enabled and the locking we need for
> that becomes problematic (due to dependencies on other locks) if we
> allow the reference to be held for arbitrarily long periods/places in
> the code.
>
> I chose the disabling delay to be 100msec for now to avoid the unneeded
> toggling (and so not to introduce dmesg spamming) in the DP MST sideband
> signaling code. We could optimize this delay later.
Or removing the spam. Are we at a point where the error detection is
good enough to pin-point the lack of a particular powerwell wakeref?
-Chris
More information about the Intel-gfx
mailing list