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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
