motion_sense: Fix ap_event_interval calculation.

[CONFIG_AP].ec_rate, populated with sysfs entry |hwfifo_timeout|, is used
to calculate |ap_event_interval| the delay before sending a new event to
the AP.
When load_fifo() still existed (CL:938146), it was critical that a
sample was available before gathering the data. When ODR and
|hwfifo_timeout| are closed, |ap_event_interval| is increased by 5%.
Now, since samples are collected after an interrupt triggers due to at
least one element in the sensor FIFO or are scheduled based on the
sensor data rate (forced mode), we are guaranteed to have an event.
We should actually decreate |ap_event_interval| by 5% to be sure an
event is triggered.
When both an interrupt based sensor and a force sensor are at running at
the same ODR, they will probably not be in phase, but there will be
opportunity to send event to the host. One sensor will have a fix delay,
guaranteed to be less than its ODR.

BUG=b:195264765,b:129159505,b:73557414
BRANCH=many.
TEST=Without the change, on gaybrush, we can see that events are sent 2
by 2, event when the AP asks for them immediately.

Using 'iioservice_simpleclient --device_id=3 --channels="timestamp"
--frequency=49 --samples=40' (50Hz ODR):

                  : Before               : After
 Latency tolerance: 0.070408 s           : 0.070408 s
 Max latency      : 0.024089 s           : 0.004047 s
 Min latency      : 0.003339 s           : 0.003167 s
 Median latency   : 0.02319 s            : 0.003565 s
 Mean latency     : 0.013644 s           : 0.003567 s

Change-Id: I9035dd535ff2895be5011335c5f44bd069c9421e
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3172269
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Diana Z <dzigterman@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3200839
Reviewed-by: Ting Shen <phoenixshen@chromium.org>

1 files changed, 12 insertions, 12 deletions

diff --git a/common/motion_sense.c b/common/motion_sense.c
index c0d556b5cb..4f25397080 100644
--- a/common/motion_sense.c
+++ b/common/motion_sense.c
@@ -211,28 +211,28 @@ static int motion_sense_set_ec_rate_from_ap(
 
 	if (new_rate_us == 0)
 		return 0;
-	if (motion_sensor_in_forced_mode(sensor))
+
+	if (odr_mhz == 0)
 		/*
-		 * AP EC sampling rate does not matter: we will collect at the
-		 * requested sensor frequency.
+		 * No event (interrupt or forced mode) are generated,
+		 * any ec rate works.
 		 */
 		goto end_set_ec_rate_from_ap;
-	if (odr_mhz == 0)
-		goto end_set_ec_rate_from_ap;
 
 	/*
 	 * If the EC collection rate is close to the sensor data rate,
-	 * given variation from the EC scheduler, it is possible that a sensor
-	 * will not present any measurement for a given time slice, and then 2
-	 * measurement for the next. That will create a large interval between
-	 * 2 measurements.
-	 * To prevent that, increase the EC period by 5% to be sure to get at
-	 * least one measurement at every collection time.
+	 * given variation from the EC scheduler, we want to be sure the EC is
+	 * ready to send an event to the AP when either the interrupt arrives,
+	 * or the EC is actively probing the sensor.
+	 * Decrease the EC period by 5% to be sure to get at least one
+	 * measurement at every collection time.
 	 * We will apply that correction only if the ec rate is within 10% of
 	 * the data rate.
+	 * It is possible for sensors at the same ODR to not be in phase.
+	 * One will have a delay guarantee to be less than its ODR.
 	 */
 	if (SECOND * 1100 / odr_mhz > new_rate_us)
-		new_rate_us = new_rate_us / 100 * 105;
+		new_rate_us = new_rate_us / 95 * 100;
 
 end_set_ec_rate_from_ap:
 	return MAX(new_rate_us, motion_min_interval);