gpiolib: cdev: allow edge event timestamps to be configured as REALTIME

PATCH Applied Kent Gibson 5 participants 15 messages Oct 15, 2020 – Dec 5, 2020

Subsystems (2)

GPIO GPIO uapi

lore

Share & tools

lore

Kent Gibson

author reviewer

2020-10-15 01:40 UTC #0 lore raw

v2 cover gpiolib: cdev: allow edge event timestamps to be configured as REALTIME

This patch set adds the option to select CLOCK_REALTIME as the source clock for line events.

The first patch is the core of the change, while the remaining two update the GPIO tools to make use of the new option.

Changes for v2:
- change line_event_timestamp() return to u64 to avoid clipping to 32bits on 32bit platforms.
- fix the line spacing after line_event_timestamp()

Kent Gibson (3):
gpiolib: cdev: allow edge event timestamps to be configured as
REALTIME
tools: gpio: add support for reporting realtime event clock to lsgpio
tools: gpio: add option to report wall-clock time to gpio-event-mon

 drivers/gpio/gpiolib-cdev.c | 21 ++++++++++++++++++---
 drivers/gpio/gpiolib.h      |  1 +
 include/uapi/linux/gpio.h   | 12 +++++++++---
 tools/gpio/gpio-event-mon.c |  6 +++++-
 tools/gpio/lsgpio.c         |  4 ++++
 5 files changed, 37 insertions(+), 7 deletions(-)

Signature · 1 line

2.28.0

Kent Gibson

author reviewer

2020-10-15 01:39 UTC #1 lore raw

PATCH v2 1/3 gpiolib: cdev: allow edge event timestamps to be configured as REALTIME

Using CLOCK_REALTIME as the source for event timestamps is crucial for some specific applications, particularly those requiring timetamps relative to a PTP clock, so provide an option to switch the event timestamp source from the default CLOCK_MONOTONIC to CLOCK_REALTIME.

Note that CLOCK_REALTIME was the default source clock for GPIO until Linux 5.7 when it was changed to CLOCK_MONOTONIC due to issues with the shifting of the realtime clock.
Providing this option maintains the CLOCK_MONOTONIC as the default, while also providing a path forward for those dependent on the pre-5.7 behaviour.

Signed-off-by Kent Gibson <[email protected]>

---
 drivers/gpio/gpiolib-cdev.c | 21 ++++++++++++++++++---
 drivers/gpio/gpiolib.h      |  1 +
 include/uapi/linux/gpio.h   | 12 +++++++++---
 3 files changed, 28 insertions(+), 6 deletions(-)

drivers/gpio/gpiolib-cdev.c +18 -3

index 678de9264617..ea787eb3810d 100644
@@ -515,6 +515,7 @@ struct linereq {
 	 GPIO_V2_LINE_DIRECTION_FLAGS | \
 	 GPIO_V2_LINE_DRIVE_FLAGS | \
 	 GPIO_V2_LINE_EDGE_FLAGS | \
+	 GPIO_V2_LINE_FLAG_EVENT_CLOCK_REALTIME | \
 	 GPIO_V2_LINE_BIAS_FLAGS)
 
 static void linereq_put_event(struct linereq *lr,

@@ -535,6 +536,14 @@ static void linereq_put_event(struct linereq *lr,
 		pr_debug_ratelimited("event FIFO is full - event dropped\n");
 }
 
+static u64 line_event_timestamp(struct line *line)
+{
+	if (test_bit(FLAG_EVENT_CLOCK_REALTIME, &line->desc->flags))
+		return ktime_get_real_ns();
+
+	return ktime_get_ns();
+}
+
 static irqreturn_t edge_irq_thread(int irq, void *p)
 {
 	struct line *line = p;

@@ -553,7 +562,7 @@ static irqreturn_t edge_irq_thread(int irq, void *p)
 		 * which case we didn't get the timestamp from
 		 * edge_irq_handler().
 		 */
-		le.timestamp_ns = ktime_get_ns();
+		le.timestamp_ns = line_event_timestamp(line);
 		if (lr->num_lines != 1)
 			line->req_seqno = atomic_inc_return(&lr->seqno);
 	}

@@ -598,7 +607,7 @@ static irqreturn_t edge_irq_handler(int irq, void *p)
 	 * Just store the timestamp in hardirq context so we get it as
 	 * close in time as possible to the actual event.
 	 */
-	line->timestamp_ns = ktime_get_ns();
+	line->timestamp_ns = line_event_timestamp(line);
 
 	if (lr->num_lines != 1)
 		line->req_seqno = atomic_inc_return(&lr->seqno);

@@ -673,7 +682,7 @@ static void debounce_work_func(struct work_struct *work)
 	memset(&le, 0, sizeof(le));
 
 	lr = line->req;
-	le.timestamp_ns = ktime_get_ns();
+	le.timestamp_ns = line_event_timestamp(line);
 	le.offset = gpio_chip_hwgpio(line->desc);
 	line->line_seqno++;
 	le.line_seqno = line->line_seqno;

@@ -977,6 +986,9 @@ static void gpio_v2_line_config_flags_to_desc_flags(u64 flags,
 		   flags & GPIO_V2_LINE_FLAG_BIAS_PULL_DOWN);
 	assign_bit(FLAG_BIAS_DISABLE, flagsp,
 		   flags & GPIO_V2_LINE_FLAG_BIAS_DISABLED);
+
+	assign_bit(FLAG_EVENT_CLOCK_REALTIME, flagsp,
+		   flags & GPIO_V2_LINE_FLAG_EVENT_CLOCK_REALTIME);
 }
 
 static long linereq_get_values(struct linereq *lr, void __user *ip)

@@ -1940,6 +1952,9 @@ static void gpio_desc_to_lineinfo(struct gpio_desc *desc,
 	if (test_bit(FLAG_EDGE_FALLING, &desc->flags))
 		info->flags |= GPIO_V2_LINE_FLAG_EDGE_FALLING;
 
+	if (test_bit(FLAG_EVENT_CLOCK_REALTIME, &desc->flags))
+		info->flags |= GPIO_V2_LINE_FLAG_EVENT_CLOCK_REALTIME;
+
 	debounce_period_us = READ_ONCE(desc->debounce_period_us);
 	if (debounce_period_us) {
 		info->attrs[num_attrs].id = GPIO_V2_LINE_ATTR_ID_DEBOUNCE;

drivers/gpio/gpiolib.h +1 -0

index b674b5bb980e..2f228ffe8320 100644
@@ -116,6 +116,7 @@ struct gpio_desc {
 #define FLAG_BIAS_DISABLE    15	/* GPIO has pull disabled */
 #define FLAG_EDGE_RISING     16	/* GPIO CDEV detects rising edge events */
 #define FLAG_EDGE_FALLING    17	/* GPIO CDEV detects falling edge events */
+#define FLAG_EVENT_CLOCK_REALTIME	18 /* GPIO CDEV reports REALTIME timestamps in events */
 
 	/* Connection label */
 	const char		*label;

include/uapi/linux/gpio.h +9 -3

index 2072c260f5d0..e4eb0b8c5cf9 100644
@@ -65,6 +65,7 @@ struct gpiochip_info {
  * @GPIO_V2_LINE_FLAG_BIAS_PULL_UP: line has pull-up bias enabled
  * @GPIO_V2_LINE_FLAG_BIAS_PULL_DOWN: line has pull-down bias enabled
  * @GPIO_V2_LINE_FLAG_BIAS_DISABLED: line has bias disabled
+ * @GPIO_V2_LINE_FLAG_EVENT_CLOCK_REALTIME: line events contain REALTIME timestamps
  */
 enum gpio_v2_line_flag {
 	GPIO_V2_LINE_FLAG_USED			= _BITULL(0),

@@ -78,6 +79,7 @@ enum gpio_v2_line_flag {
 	GPIO_V2_LINE_FLAG_BIAS_PULL_UP		= _BITULL(8),
 	GPIO_V2_LINE_FLAG_BIAS_PULL_DOWN	= _BITULL(9),
 	GPIO_V2_LINE_FLAG_BIAS_DISABLED		= _BITULL(10),
+	GPIO_V2_LINE_FLAG_EVENT_CLOCK_REALTIME	= _BITULL(11),
 };
 
 /**

@@ -270,9 +272,6 @@ enum gpio_v2_line_event_id {
 /**
  * struct gpio_v2_line_event - The actual event being pushed to userspace
  * @timestamp_ns: best estimate of time of event occurrence, in nanoseconds.
- * The @timestamp_ns is read from %CLOCK_MONOTONIC and is intended to allow
- * the accurate measurement of the time between events. It does not provide
- * the wall-clock time.
  * @id: event identifier with value from &enum gpio_v2_line_event_id
  * @offset: the offset of the line that triggered the event
  * @seqno: the sequence number for this event in the sequence of events for

@@ -280,6 +279,13 @@ enum gpio_v2_line_event_id {
  * @line_seqno: the sequence number for this event in the sequence of
  * events on this particular line
  * @padding: reserved for future use
+ *
+ * By default the @timestamp_ns is read from %CLOCK_MONOTONIC and is
+ * intended to allow the accurate measurement of the time between events.
+ * It does not provide the wall-clock time.
+ *
+ * If the %GPIO_V2_LINE_FLAG_EVENT_CLOCK_REALTIME flag is set then the
+ * @timestamp_ns is read from %CLOCK_REALTIME.
  */
 struct gpio_v2_line_event {
 	__aligned_u64 timestamp_ns;

Signature · 1 line

2.28.0

Andy Shevchenko

2020-10-16 14:12 UTC #2 lore raw

Quoted 12 lines · Kent Gibson

Using CLOCK_REALTIME as the source for event timestamps is crucial for some specific applications, particularly those requiring timetamps relative to a PTP clock, so provide an option to switch the event timestamp source from the default CLOCK_MONOTONIC to CLOCK_REALTIME.
Note that CLOCK_REALTIME was the default source clock for GPIO until Linux 5.7 when it was changed to CLOCK_MONOTONIC due to issues with the shifting of the realtime clock.
Providing this option maintains the CLOCK_MONOTONIC as the default, while also providing a path forward for those dependent on the pre-5.7 behaviour.

...

Quoted 4 lines

         GPIO_V2_LINE_DIRECTION_FLAGS | \
         GPIO_V2_LINE_DRIVE_FLAGS | \
         GPIO_V2_LINE_EDGE_FLAGS | \

+ GPIO_V2_LINE_FLAG_EVENT_CLOCK_REALTIME | \

Wondering if we would have something like

          GPIO_V2_LINE_CLOCK_FLAGS | \

here for the sake of consistency.

Quoted 1 line

GPIO_V2_LINE_BIAS_FLAGS)

...

drivers/gpio/gpiolib-cdev.c static void linereq_put_event(struct linereq *lr, · line 541

Quoted 4 lines

drivers/gpio/gpiolib-cdev.c +3 -0

+static u64 line_event_timestamp(struct line *line)
+{
 
+       if (test_bit(FLAG_EVENT_CLOCK_REALTIME, &line->desc->flags))

I dunno if we can actually drop the word EVENT from these definitions. I don't think we would have in the near future something similar for the non-event data.

drivers/gpio/gpiolib-cdev.c static void linereq_put_event(struct linereq *lr, · line 545

Quoted 4 lines

drivers/gpio/gpiolib-cdev.c +4 -0

+               return ktime_get_real_ns();
+
+       return ktime_get_ns();
+}

In general it looks good, thanks!

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Kent Gibson

author reviewer

2020-10-16 23:28 UTC #3 lore raw

Quoted 21 lines · Andy Shevchenko

Quoted 12 lines · Kent Gibson
Using CLOCK_REALTIME as the source for event timestamps is crucial for some specific applications, particularly those requiring timetamps relative to a PTP clock, so provide an option to switch the event timestamp source from the default CLOCK_MONOTONIC to CLOCK_REALTIME.
Note that CLOCK_REALTIME was the default source clock for GPIO until Linux 5.7 when it was changed to CLOCK_MONOTONIC due to issues with the shifting of the realtime clock.
Providing this option maintains the CLOCK_MONOTONIC as the default, while also providing a path forward for those dependent on the pre-5.7 behaviour.
...
Quoted 4 lines
         GPIO_V2_LINE_DIRECTION_FLAGS | \
         GPIO_V2_LINE_DRIVE_FLAGS | \
         GPIO_V2_LINE_EDGE_FLAGS | \
+ GPIO_V2_LINE_FLAG_EVENT_CLOCK_REALTIME | \

Quoted 6 lines

Wondering if we would have something like
          GPIO_V2_LINE_CLOCK_FLAGS | \
here for the sake of consistency.

I considered it, but thought the chance of there ever being another CLOCK flag to be near zero - the remaining clocks relate to CPU or thread time which don't have any relevance for external events like GPIO. If there ever is one we can split it out then.

And it is consistent with the GPIO_V2_LINE_FLAG_ACTIVE_LOW flag that you pruned out in your response. i.e. lone flags don't get grouped.

Quoted 4 lines

Quoted 1 line
GPIO_V2_LINE_BIAS_FLAGS)
...

Quoted 9 lines

drivers/gpio/gpiolib-cdev.c static void linereq_put_event(struct linereq *lr, · line 541
Quoted 4 lines
drivers/gpio/gpiolib-cdev.c +3 -0
+static u64 line_event_timestamp(struct line *line)
+{
 
+       if (test_bit(FLAG_EVENT_CLOCK_REALTIME, &line->desc->flags))
I dunno if we can actually drop the word EVENT from these definitions. I don't think we would have in the near future something similar for the non-event data.

I considered this too, as another clock flag seems unlikely. But if we ever add a non-event clock flag then this one would become confusing, and the overhead of the long name seemed minor compared to the clarity it brings with it.

Cheers,
Kent.

Kent Gibson

author reviewer

2020-10-15 01:40 UTC #4 lore raw

PATCH v2 2/3 tools: gpio: add support for reporting realtime event clock to lsgpio

In reply to Kent Gibson

Add support for reporting if a line is configured to report realtime timestamps in events.

Signed-off-by Kent Gibson <[email protected]>

---
 tools/gpio/lsgpio.c | 4 ++++
 1 file changed, 4 insertions(+)

tools/gpio/lsgpio.c +4 -0

index 5a05a454d0c9..c61d061247e1 100644
@@ -65,6 +65,10 @@ struct gpio_flag flagnames[] = {
 		.name = "bias-disabled",
 		.mask = GPIO_V2_LINE_FLAG_BIAS_DISABLED,
 	},
+	{
+		.name = "clock-realtime",
+		.mask = GPIO_V2_LINE_FLAG_EVENT_CLOCK_REALTIME,
+	},
 };
 
 static void print_attributes(struct gpio_v2_line_info *info)

Signature · 1 line

2.28.0

Kent Gibson

author reviewer

2020-10-15 01:39 UTC #5 lore raw

PATCH v2 3/3 tools: gpio: add option to report wall-clock time to gpio-event-mon

In reply to Kent Gibson

Add support for selecting the realtime clock for events.

Signed-off-by Kent Gibson <[email protected]>

---
 tools/gpio/gpio-event-mon.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

tools/gpio/gpio-event-mon.c +5 -1

index 90c3155f05b1..cacd66ad7926 100644
@@ -148,6 +148,7 @@ void print_usage(void)
 		"  -s         Set line as open source\n"
 		"  -r         Listen for rising edges\n"
 		"  -f         Listen for falling edges\n"
+		"  -w         Report the wall-clock time for events\n"
 		"  -b <n>     Debounce the line with period n microseconds\n"
 		" [-c <n>]    Do <n> loops (optional, infinite loop if not stated)\n"
 		"  -?         This helptext\n"

@@ -173,7 +174,7 @@ int main(int argc, char **argv)
 
 	memset(&config, 0, sizeof(config));
 	config.flags = GPIO_V2_LINE_FLAG_INPUT;
-	while ((c = getopt(argc, argv, "c:n:o:b:dsrf?")) != -1) {
+	while ((c = getopt(argc, argv, "c:n:o:b:dsrfw?")) != -1) {
 		switch (c) {
 		case 'c':
 			loops = strtoul(optarg, NULL, 10);

@@ -204,6 +205,9 @@ int main(int argc, char **argv)
 		case 'f':
 			config.flags |= GPIO_V2_LINE_FLAG_EDGE_FALLING;
 			break;
+		case 'w':
+			config.flags |= GPIO_V2_LINE_FLAG_EVENT_CLOCK_REALTIME;
+			break;
 		case '?':
 			print_usage();
 			return -1;

Signature · 1 line

2.28.0

Linus Walleij

2020-10-28 22:31 UTC #6 lore raw

In reply to Kent Gibson

Quoted 10 lines · Kent Gibson

This patch set adds the option to select CLOCK_REALTIME as the source clock for line events.
The first patch is the core of the change, while the remaining two update the GPIO tools to make use of the new option.
Changes for v2:
- change line_event_timestamp() return to u64 to avoid clipping to 32bits on 32bit platforms.
- fix the line spacing after line_event_timestamp()

Where are we standing with this patch set? Good to go so I should just try to merge it?

Yours,
Linus Walleij

Kent Gibson

author reviewer

2020-10-28 23:23 UTC #7 lore raw

Quoted 8 lines · Linus Walleij

Quoted 6 lines · Kent Gibson
This patch set adds the option to select CLOCK_REALTIME as the source clock for line events.
The first patch is the core of the change, while the remaining two update the GPIO tools to make use of the new option.

Quoted 8 lines

Quoted 4 lines
Changes for v2:
- change line_event_timestamp() return to u64 to avoid clipping to 32bits on 32bit platforms.
- fix the line spacing after line_event_timestamp()
Where are we standing with this patch set? Good to go so I should just try to merge it?

I'm fine with it, especially now that I've tested it on 32bit platforms as well as 64bit.

Bart was ok with v1, and I doubt the changes for v2 would negatively impact that, though I did overlook adding his review tag.

Cheers,
Kent.

Quoted 2 lines

Yours,
Linus Walleij

Bartosz Golaszewski

2020-10-30 14:49 UTC #8 lore raw

Quoted 19 lines · Kent Gibson

Quoted 8 lines · Linus Walleij
Quoted 6 lines · Kent Gibson
This patch set adds the option to select CLOCK_REALTIME as the source clock for line events.
The first patch is the core of the change, while the remaining two update the GPIO tools to make use of the new option.
Quoted 8 lines
Quoted 4 lines
Changes for v2:
- change line_event_timestamp() return to u64 to avoid clipping to 32bits on 32bit platforms.
- fix the line spacing after line_event_timestamp()
Where are we standing with this patch set? Good to go so I should just try to merge it?

Quoted 11 lines

I'm fine with it, especially now that I've tested it on 32bit platforms as well as 64bit.
Bart was ok with v1, and I doubt the changes for v2 would negatively impact that, though I did overlook adding his review tag.
Cheers,
Kent.
Quoted 2 lines
Yours,
Linus Walleij

I'll take it through my tree then.

Bartosz

Bartosz Golaszewski

2020-10-30 14:52 UTC #9 lore raw

Quoted 30 lines · Bartosz Golaszewski

Quoted 28 lines · Kent Gibson
Quoted 8 lines · Linus Walleij
Quoted 6 lines · Kent Gibson
This patch set adds the option to select CLOCK_REALTIME as the source clock for line events.
The first patch is the core of the change, while the remaining two update the GPIO tools to make use of the new option.
Quoted 8 lines
Quoted 4 lines
Changes for v2:
- change line_event_timestamp() return to u64 to avoid clipping to 32bits on 32bit platforms.
- fix the line spacing after line_event_timestamp()
Where are we standing with this patch set? Good to go so I should just try to merge it?
I'm fine with it, especially now that I've tested it on 32bit platforms as well as 64bit.
Bart was ok with v1, and I doubt the changes for v2 would negatively impact that, though I did overlook adding his review tag.
Cheers,
Kent.

Quoted 6 lines

Quoted 2 lines
Quoted 2 lines
Yours,
Linus Walleij
I'll take it through my tree then.
Bartosz

The series no longer applies on top of v5.10-rc1. Could you rebase and resend?

Bartosz

Kent Gibson

author reviewer

2020-10-31 00:01 UTC #10 lore raw

Quoted 32 lines · Bartosz Golaszewski

Quoted 30 lines · Bartosz Golaszewski
Quoted 28 lines · Kent Gibson
Quoted 8 lines · Linus Walleij
Quoted 6 lines · Kent Gibson
This patch set adds the option to select CLOCK_REALTIME as the source clock for line events.
The first patch is the core of the change, while the remaining two update the GPIO tools to make use of the new option.
Quoted 8 lines
Quoted 4 lines
Changes for v2:
- change line_event_timestamp() return to u64 to avoid clipping to 32bits on 32bit platforms.
- fix the line spacing after line_event_timestamp()
Where are we standing with this patch set? Good to go so I should just try to merge it?
I'm fine with it, especially now that I've tested it on 32bit platforms as well as 64bit.
Bart was ok with v1, and I doubt the changes for v2 would negatively impact that, though I did overlook adding his review tag.
Cheers,
Kent.

Quoted 9 lines

Quoted 6 lines
Quoted 2 lines
Quoted 2 lines
Yours,
Linus Walleij
I'll take it through my tree then.
Bartosz
The series no longer applies on top of v5.10-rc1. Could you rebase and resend?

Nuts, it relies on my doc tidy-up series that Linus has pulled into fixes, and so will likely go into v5.10-rc2??

Specifically it is based over/conflicts with:
2cc522d3931b gpio: uapi: kernel-doc formatting improvements

If I rebase it onto devel then you will get a conflict when those merge. Is that what you want?

Cheers,
Kent.

Bartosz Golaszewski

2020-11-02 08:57 UTC #11 lore raw

Quoted 47 lines · Kent Gibson

Quoted 32 lines · Bartosz Golaszewski
Quoted 30 lines · Bartosz Golaszewski
Quoted 28 lines · Kent Gibson
Quoted 8 lines · Linus Walleij
Quoted 6 lines · Kent Gibson
This patch set adds the option to select CLOCK_REALTIME as the source clock for line events.
The first patch is the core of the change, while the remaining two update the GPIO tools to make use of the new option.
Quoted 8 lines
Quoted 4 lines
Changes for v2:
- change line_event_timestamp() return to u64 to avoid clipping to 32bits on 32bit platforms.
- fix the line spacing after line_event_timestamp()
Where are we standing with this patch set? Good to go so I should just try to merge it?
I'm fine with it, especially now that I've tested it on 32bit platforms as well as 64bit.
Bart was ok with v1, and I doubt the changes for v2 would negatively impact that, though I did overlook adding his review tag.
Cheers,
Kent.
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
Quoted 2 lines
Yours,
Linus Walleij
I'll take it through my tree then.
Bartosz
The series no longer applies on top of v5.10-rc1. Could you rebase and resend?
Nuts, it relies on my doc tidy-up series that Linus has pulled into fixes, and so will likely go into v5.10-rc2??

Quoted 8 lines

Specifically it is based over/conflicts with:
2cc522d3931b gpio: uapi: kernel-doc formatting improvements
If I rebase it onto devel then you will get a conflict when those merge. Is that what you want?
Cheers,
Kent.

I'll let Linus take these through his tree then.

Bartosz

Linus Walleij

2020-11-06 13:49 UTC #12 lore raw

In reply to Kent Gibson

Quoted 6 lines · Kent Gibson

Quoted 1 line · Bartosz Golaszewski
The series no longer applies on top of v5.10-rc1. Could you rebase and resend?
Nuts, it relies on my doc tidy-up series that Linus has pulled into fixes, and so will likely go into v5.10-rc2??

If I have time to get the GPIO fixes into -rc2. Otherwise -rc3 and then I need to merge the resulting -rc into the devel branch before applying.

I will get to it sooner or later, I think Bartosz might have some more GPIO fixes that I need to pull first before sending any fixes upstream.

Yours,
Linus Walleij

Bartosz Golaszewski

2020-12-01 18:21 UTC #13 lore raw

Quoted 13 lines · Linus Walleij

Quoted 6 lines · Kent Gibson
Quoted 1 line · Bartosz Golaszewski
The series no longer applies on top of v5.10-rc1. Could you rebase and resend?
Nuts, it relies on my doc tidy-up series that Linus has pulled into fixes, and so will likely go into v5.10-rc2??
If I have time to get the GPIO fixes into -rc2. Otherwise -rc3 and then I need to merge the resulting -rc into the devel branch before applying.

Quoted 6 lines

I will get to it sooner or later, I think Bartosz might have some more GPIO fixes that I need to pull first before sending any fixes upstream.
Yours,
Linus Walleij

Hi Linus,

Just a gentle ping on this, so it doesn't get forgotten before the next merge window.

Bartosz

Linus Walleij

Applied

2020-12-05 22:24 UTC #14 lore raw

In reply to Kent Gibson

Quoted 10 lines · Kent Gibson

This patch set adds the option to select CLOCK_REALTIME as the source clock for line events.
The first patch is the core of the change, while the remaining two update the GPIO tools to make use of the new option.
Changes for v2:
- change line_event_timestamp() return to u64 to avoid clipping to 32bits on 32bit platforms.
- fix the line spacing after line_event_timestamp()

I applied the v2 patch set for v5.11 now, it seems to work fine!

Yours,
Linus Walleij