public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Enric Balletbo i Serra <enric.balletbo@collabora.com>
To: Gwendal Grignou <gwendal@chromium.org>,
	groeck@chromium.org, bleung@chromium.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] platform: cros_ec: sensorhub: Simplify legacy timestamp spreading
Date: Mon, 17 Aug 2020 13:32:14 +0200	[thread overview]
Message-ID: <8fdaba0f-be3d-84e7-c0df-8a70612402fe@collabora.com> (raw)
In-Reply-To: <20200728091355.2506827-1-gwendal@chromium.org>

Hi Gwendal,

On 28/7/20 11:13, Gwendal Grignou wrote:
> On some machine (nami), interrupt latency cause samples to appear
> to be from the future and are pegged to the current time.
> We would see samples with this pattern:
> 
> [t, t + ~5ms, t + ~10ms, t + ~10ms + 100us, t + ~10ms + 200us],
>                              (current now)      (current now)
> (t is the last timestamp time)
> 
> Last 2 samples would be barely spread, causing applications to
> complain.
> We now spread the entire sequence. This is not great: in the example
> the sensor was supposed to send samples every 5ms, it now appears to
> send one every 2.5ms, but it is slightly closer to reality:
> 
> sampling time in the example above
> At sensor level
> 
> 1             2             3             4            5
> +-----5ms-----+-----5ms-----+-----5ms-----+----5ms-----+---> t
> 
> Before, at host level
>                        1             2             3 4 5
> --interrupt delay------+-----5ms-----+-----5ms-----+-+-+---> t
> 
> Afer, at host level
>                        1       2       3       4       5
> --interrupt delay------+-2.5ms-+-2.5ms-+-2.5ms-+-2.5ms-+---> t
> 
> Signed-off-by: Gwendal Grignou <gwendal@chromium.org>


Sorry for late notice. The patch has been applied for 5.9.

> ---
>  .../platform/chrome/cros_ec_sensorhub_ring.c  | 94 +++++++------------
>  1 file changed, 33 insertions(+), 61 deletions(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_sensorhub_ring.c b/drivers/platform/chrome/cros_ec_sensorhub_ring.c
> index 1b9637655e63e..0b0bf93073c30 100644
> --- a/drivers/platform/chrome/cros_ec_sensorhub_ring.c
> +++ b/drivers/platform/chrome/cros_ec_sensorhub_ring.c
> @@ -719,29 +719,22 @@ done_with_this_batch:
>   * cros_ec_sensor_ring_spread_add_legacy: Calculate proper timestamps then
>   * add to ringbuffer (legacy).
>   *
> - * Note: This assumes we're running old firmware, where every sample's timestamp
> - * is after the sample. Run if tight_timestamps == false.
> - *
> - * If there is a sample with a proper timestamp
> + * Note: This assumes we're running old firmware, where timestamp
> + * is inserted after its sample(s)e. There can be several samples between
> + * timestamps, so several samples can have the same timestamp.
>   *
>   *                        timestamp | count
>   *                        -----------------
> - * older_unprocess_out --> TS1      | 1
> - *                         TS1      | 2
> - *                out -->  TS1      | 3
> - *           next_out -->  TS2      |
> - *
> - * We spread time for the samples [older_unprocess_out .. out]
> - * between TS1 and TS2: [TS1+1/4, TS1+2/4, TS1+3/4, TS2].
> + *          1st sample --> TS1      | 1
> + *                         TS2      | 2
> + *                         TS2      | 3
> + *                         TS3      | 4
> + *           last_out -->
>   *
> - * If we reach the end of the samples, we compare with the
> - * current timestamp:
>   *
> - * older_unprocess_out --> TS1      | 1
> - *                         TS1      | 2
> - *                 out --> TS1      | 3
> + * We spread time for the samples using perod p = (current - TS1)/4.
> + * between TS1 and TS2: [TS1+p/4, TS1+2p/4, TS1+3p/4, current_timestamp].
>   *
> - * We know have [TS1+1/3, TS1+2/3, current timestamp]
>   */
>  static void
>  cros_ec_sensor_ring_spread_add_legacy(struct cros_ec_sensorhub *sensorhub,
> @@ -754,58 +747,37 @@ cros_ec_sensor_ring_spread_add_legacy(struct cros_ec_sensorhub *sensorhub,
>  	int i;
>  
>  	for_each_set_bit(i, &sensor_mask, sensorhub->sensor_num) {
> -		s64 older_timestamp;
>  		s64 timestamp;
> -		struct cros_ec_sensors_ring_sample *older_unprocess_out =
> -			sensorhub->ring;
> -		struct cros_ec_sensors_ring_sample *next_out;
> -		int count = 1;
> -
> -		for (out = sensorhub->ring; out < last_out; out = next_out) {
> -			s64 time_period;
> +		int count = 0;
> +		s64 time_period;
>  
> -			next_out = out + 1;
> +		for (out = sensorhub->ring; out < last_out; out++) {
>  			if (out->sensor_id != i)
>  				continue;
>  
>  			/* Timestamp to start with */
> -			older_timestamp = out->timestamp;
> -
> -			/* Find next sample. */
> -			while (next_out < last_out && next_out->sensor_id != i)
> -				next_out++;
> +			timestamp = out->timestamp;
> +			out++;
> +			count = 1;
> +			break;
> +		}
> +		for (; out < last_out; out++) {
> +			/* Find last sample. */
> +			if (out->sensor_id != i)
> +				continue;
> +			count++;
> +		}
> +		if (count == 0)
> +			continue;
>  
> -			if (next_out >= last_out) {
> -				timestamp = current_timestamp;
> -			} else {
> -				timestamp = next_out->timestamp;
> -				if (timestamp == older_timestamp) {
> -					count++;
> -					continue;
> -				}
> -			}
> +		/* Spread uniformly between the first and last samples. */
> +		time_period = div_s64(current_timestamp - timestamp, count);
>  
> -			/*
> -			 * The next sample has a new timestamp, spread the
> -			 * unprocessed samples.
> -			 */
> -			if (next_out < last_out)
> -				count++;
> -			time_period = div_s64(timestamp - older_timestamp,
> -					      count);
> -
> -			for (; older_unprocess_out <= out;
> -					older_unprocess_out++) {
> -				if (older_unprocess_out->sensor_id != i)
> -					continue;
> -				older_timestamp += time_period;
> -				older_unprocess_out->timestamp =
> -					older_timestamp;
> -			}
> -			count = 1;
> -			/* The next_out sample has a valid timestamp, skip. */
> -			next_out++;
> -			older_unprocess_out = next_out;
> +		for (out = sensorhub->ring; out < last_out; out++) {
> +			if (out->sensor_id != i)
> +				continue;
> +			timestamp += time_period;
> +			out->timestamp = timestamp;
>  		}
>  	}
>  
> 

      reply	other threads:[~2020-08-17 11:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-28  9:13 [PATCH] platform: cros_ec: sensorhub: Simplify legacy timestamp spreading Gwendal Grignou
2020-08-17 11:32 ` Enric Balletbo i Serra [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8fdaba0f-be3d-84e7-c0df-8a70612402fe@collabora.com \
    --to=enric.balletbo@collabora.com \
    --cc=bleung@chromium.org \
    --cc=groeck@chromium.org \
    --cc=gwendal@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox