On Fri, May 03, 2019 at 01:16:04PM +0100, Chris Wilson wrote: > 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? The latter: we hold it for the entire duration of the detect and hotplug cycles, whereas we would only need it for the actual AUX transfers. By the end of the patchset we only hold it for the required duration, that is the AUX transfer, but to do that we would also want - imo - to avoid the power well on/off ping-pong due to back-to-back AUX transfers. > > 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. It's just my assumption that an on-off-on sequence costs more then just leaving the power well(s) on if the duration is short between the two on events, I haven't measured this. In the extreme case we could reduce the delay to 0, but still keep the disabling asynchronous, which would mean not blocking on the disabling. I measured the disabling time (with wait_for_us) to be ~1ms in average on VLV with the worst case being 4ms. > > 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? I meant that we would need to keep the sequence where we hold the reference short and a well defined place, like what we would have by just holding the reference for the actual AUX transfer (achieved by the end of the patchset). Anything else would make the locking we need for ICL TypeC ports around this sequence rather problematic, adding for instance unnecessary lockdep dependencies, which I would really like to avoid. > > 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? We don't have a per-powerwell list of registers that we could check against if that's what you mean. So we only detect if no wakeref is held (by this or another thread) or an actual unclaimed access if the power well is really off. > -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
