The test is doing multiple iterations (50). Each iteration tries to
squeeze target number of cursor updates in half a second worth of flips.
If we don't hit the target in any given iteration we bail out early.

Because of that we don't have the data on the number of iterations that
have failed and/or succeeded any given run, which makes hunting down
this elusive issue hard.

Let's change that so we always go through all the iterations and fail at
the end printing out the number of iterations we haven't met the target.

Each failed iteration also logs how many cursor updates it has managed
to do.

Since our target is generated run-time and is also load sensitive, let's
bump the log level of message containing our target to "info" so we can
compare those values across both passes and failures.

Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>