We were running this loop 100 times with 5 ms delays. Change it to run 500 times with 1 ms delays, which gives us the same overall timeout but lets us bail out a bit sooner -- in practice, at most, 4 ms sooner but every bit counts. Note, however, that the tighter timing does reduce opportunities for threading. There is a non-obvious set of tradeoffs on timeouts. BUG=None TEST=build and boot with this test and note we still have graphics BRANCH=None Change-Id: I4af671c2a791aa92e446e66ac2fe5710d1e6aa4c Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://chromium-review.googlesource.com/167387 Reviewed-by: David Hendricks <dhendrix@chromium.org> Commit-Queue: ron minnich <rminnich@chromium.org> Tested-by: ron minnich <rminnich@chromium.org> |
||
|---|---|---|
| .. | ||
| arch | ||
| console | ||
| cpu | ||
| device | ||
| drivers | ||
| ec | ||
| include | ||
| lib | ||
| mainboard | ||
| northbridge | ||
| southbridge | ||
| superio | ||
| vendorcode | ||
| Kconfig | ||