On Fri, Apr 07, 2017 at 04:01:44PM +0000, Michal Wajdeczko wrote: > In some cases we may want to spend more time in atomic wait than > hardcoded 2us. Let's add additional fast timeout parameter to allow > flexible configuration of atomic timeout before switching into heavy wait. > Add also possibility to return registry value to avoid extra read. > > v2: use explicit fast timeout (Tvrtko/Chris) > allow returning register value (Chris) > > Signed-off-by: Michal Wajdeczko <michal.wajdeczko@xxxxxxxxx> > Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> For fun this causes: add/remove: 2/1 grow/shrink: 6/2 up/down: 626/-348 (278) function old new delta __intel_wait_for_register_fw - 429 +429 gen6_hw_domain_reset - 57 +57 sandybridge_pcode_write 494 528 +34 sandybridge_pcode_read 524 554 +30 gen8_reset_engines 287 313 +26 gen6_bsd_submit_request 156 178 +22 init_ring_common 1368 1382 +14 gmbus_wait_idle 204 218 +14 gen6_reset_engines 183 160 -23 intel_guc_reset 140 109 -31 intel_wait_for_register_fw 294 - -294 Hmm. Thinking about it more, using _wait_for() at all here is pointless. You just want to do something like, if (fast_timeout_us > 10) fast_timeout_us = 10; So - ret = _wait_for(done, fast_timeout_us, 10); - else - ret = _wait_for_atomic(done, fast_timeout_us, 0); + if (fast_timeout_us > 50000) + fast_timeout_us = 50000; + ret = _wait_for_atomic(done, fast_timeout_us, 0); gives add/remove: 2/1 grow/shrink: 6/2 up/down: 515/-348 (167) function old new delta __intel_wait_for_register_fw - 318 +318 gen6_hw_domain_reset - 57 +57 sandybridge_pcode_write 494 528 +34 sandybridge_pcode_read 524 554 +30 gen8_reset_engines 287 313 +26 gen6_bsd_submit_request 156 178 +22 init_ring_common 1368 1382 +14 gmbus_wait_idle 204 218 +14 gen6_reset_engines 183 160 -23 intel_guc_reset 140 109 -31 intel_wait_for_register_fw 294 - -294 which is more reasonable, and fits in with the current warnings. Happy? -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
