by Linus Walleij

[permalink] [raw]

Subject: Re: [RFC PATCH v1 15/20] pwm: Add capability for PWM Driver managed state

On Tue, Aug 24, 2021 at 6:48 PM <[email protected]> wrote:

> From: Christopher Hall <[email protected]>
>
> Add additional flag that can be set by drivers to indicate that the
> driver will manage its own PWM state. When calling pwm_ops.apply the
> driver applies the requested state change to the pwm_device reconciling,
> if possible, any conflicting requests.
>
> Intel(R) Timed I/O devices support very limited PWM capabilities. The
> duty cycle must always be 50% of the period. When changing one parameter
> at a time through the sysfs interface, it isn't possible for the user or
> the PWM subsystem to maintain this relation.
>
> Signed-off-by: Christopher Hall <[email protected]>
> Signed-off-by: Tamal Saha <[email protected]>
> Signed-off-by: Lakshmi Sowjanya D <[email protected]>
> Reviewed-by: Mark Gross <[email protected]>

These PWM changes clearly need to be reviewed by the PWM
subsystem maintainers, and I think all of the output generation
portions of this really need to go into the PWM subsystem.

Yours,
Linus Walleij

2021-09-17 13:00:10

On Sun, Sep 19, 2021 at 11:21:22PM +0200, Clemens Gruber wrote:
> On Sun, Sep 19, 2021 at 09:38:58PM +0200, Linus Walleij wrote:
> > On Fri, Sep 17, 2021 at 9:27 AM Uwe Kleine-K?nig
> > <[email protected]> wrote:
> > > On Thu, Sep 16, 2021 at 11:42:04PM +0200, Linus Walleij wrote:
> > > > On Tue, Aug 24, 2021 at 6:48 PM <[email protected]> wrote:
> > > >
> > > > > From: Lakshmi Sowjanya D <[email protected]>
> > > > >
> > > > > Intel Timed I/O hardware supports output scheduled in hardware. Enable
> > > > > this functionality using GPIOlib
> > > > >
> > > > > Adds GPIOlib generate_output() hook into the driver. The driver is
> > > > > supplied with a timestamp in terms of realtime system clock (the same
> > > > > used for input timestamping). The driver must know how to translate this
> > > > > into a timebase meaningful for the hardware.
> > > > >
> > > > > Adds userspace write() interface. Output can be selected using the line
> > > > > event create ioctl. The write() interface takes a single timestamp
> > > > > event request parameter. An output edge rising or falling is generated
> > > > > for each event request.
> > > > >
> > > > > The user application supplies a trigger time in terms of the realtime
> > > > > clock the driver converts this into the corresponding ART clock value
> > > > > that is used to 'arm' the output.
> > > > >
> > > > > Work around device quirk that doesn't allow the output to be explicitly
> > > > > set. Instead, count the output edges and insert an additional edge as
> > > > > needed to reset the output to zero.
> > > > >
> > > > > Co-developed-by: Christopher Hall <[email protected]>
> > > > > Signed-off-by: Christopher Hall <[email protected]>
> > > > > Signed-off-by: Tamal Saha <[email protected]>
> > > > > Signed-off-by: Lakshmi Sowjanya D <[email protected]>
> > > > > Reviewed-by: Mark Gross <[email protected]>
> > > >
> > > > So this is some street organ machine that generates sequences
> > > > with determined timing between positive and negative edges
> > > > right?
> > > >
> > > > I can't see how this hardware is different from a PWM, or well
> > > > I do to some extent, you can control the period of several
> > > > subsequent waves, but that is really just an elaborate version
> > > > of PWM in my book.
> > >
> > > From looking in the patch I think this is more versatile than the PWM
> > > framework abstracts. I wonder if there is a usecase for the
> > > functionality that cannot be expressed using pwm_apply_state?!
> > >
> > > I remember we had approaches before that implemented repeating patterns
> > > (something like: active for 5ms, inactive for 10 ms, active for 30 ms,
> > > inactive for 10 ms, repeat) and limiting the number of periods
> > > (something like: .duty_cycle = 5ms, .period = 20ms, after 5 periods go
> > > into inactive state). These were considered to be too special to be
> > > abstracted in drivers/pwm.
> > >
> > > > It seems to me that this part of the functionality belongs in the
> > > > PWM subsystem which already has interfaces for similar
> > > > things, and you should probably extend PWM to handle
> > > > random waveforms rather than trying to shoehorn this
> > > > into the GPIO subsystem.
> > >
> > > I agree that GPIO is a worse candidate than PWM to abstract that. But
> > > I'm not convinced (yet?) that it's a good idea to extend PWM
> > > accordingly.
> >
> > Yeah it is a bit unfortunate.
> >
> > I think we need to fully understand the intended usecase before
> > we can deal with this: exactly what was this hardware constructed
> > to handle? Sound? Robotic stepper motors? It must be something
> > and apparently there are users.
> >
> > Maybe even a new subsystem is needed, like a
> > drivers/gpio-patterns or drivers/stepper-motor or whatever this
> > is supposed to drive.
>
> This would be interesting. Maybe even more abstract, not just supporting
> GPIO patterns but also PWM patterns.
>
> E.g. Set gpiochip1 line 2 to 1, wait 5ms, set it to 0
> Or set pwmchip1 pwm 2 to 100%, wait 250ms, set it back to 50% duty cycle

Note that adding support to drive PWMs in this "GPIO command sequence"
framework would not increase its expressiveness assuming this framework
has loop support. That's because the sequence "set pwmchip1 pwm 2 to
100% (with a period of X), wait 250ms, set it back to 50% duty cycle
with a period of Y" can be expressed using a GPIO as:

set GPIO to active
wait 250 ms + Y/2
while True:
toggle GPIO
wait Y/2

That's because this framework could provide a PWM from a GPIO.

(Also note that the original command sequence has some problems. That's
because (depending on the PWM in use and X) doing

pwm_apply_state(mypwm, &(struct pwm_state){ .period = X, .duty_cycle = X, .enabled = 1 });

and then 250ms later

pwm_apply_state(mypwm, &(struct pwm_state){ .period = Y, .duty_cycle = Y / 2, .enabled = 1 });

might give you an initially active phase that is considerably longer
than 250 ms + Y/2 because the PWM cannot implement .period = X exactly
and completes the period that is currently running at time 250 ms.

> This subsystem could then implement the patterns with hrtimers and be
> usable with every GPIO or PWM device supported in Linux, and for
> special hardware like the Intel Timed I/O, it could configure it to
> output the pattern itself.
>
> One usecase besides stepper motors and Robotics would be solenoid
> valves: You often have different sequences for opening, closing and
> maintenance. E.g. for liquid valves, especially if the liquid is
> viscuous, you have to first use 100% duty cycle PWM for e.g. 250ms to
> get it open and then dial back to 50% to keep it open without
> overheating it.
>
> Of course this can be done in userspace.. but it may also be useful to
> have some kind of pattern generator in the kernel. What do you think?

Without hearing the usecases of the original idea my feeling is:
Implement it in userspace, than the sequences can even contain network
interaction and access to SPI eeproms.

Best regards
Uwe

--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |

Attachments:

(No filename) (6.25 kB)
signature.asc (499.00 B)
Download all attachments

2021-09-22 09:55:09

by Bartosz Golaszewski

[permalink] [raw]

Subject: Re: [RFC PATCH v1 11/20] gpio: Add event count interface to gpiolib

On Tue, Aug 24, 2021 at 6:48 PM <[email protected]> wrote:
>
> From: Lakshmi Sowjanya D <[email protected]>
>
> Add a flag for event count and an extended structure to capture the event
> count when the flag is enabled.
>
> Intel(R) PMC Timed I/O device has an event count register counting
> the number of missed input edges. The register interface captures the
> event count and timestamp of the last event. For an event rate
> exceeding the rate that software can read events, the software can use
> the missed event count to calculate average event rates.
>
> The application requests one or both rising and falling edges when
> initializing the interface. The count of the selected edge type is
> optionally selected with an added event type flag. The event count is
> returned in an extended buffer using the read() interface.
>
> Co-developed-by: Christopher Hall <[email protected]>
> Signed-off-by: Christopher Hall <[email protected]>
> Signed-off-by: Tamal Saha <[email protected]>
> Signed-off-by: Lakshmi Sowjanya D <[email protected]>
> Reviewed-by: Mark Gross <[email protected]>
> ---
> drivers/gpio/gpiolib-cdev.c | 28 +++++++++++++++++++---------
> include/linux/gpio/driver.h | 1 +
> include/uapi/linux/gpio.h | 12 ++++++++++++
> 3 files changed, 32 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
> index 1df28a71f88b..3b5719d5e2dc 100644
> --- a/drivers/gpio/gpiolib-cdev.c
> +++ b/drivers/gpio/gpiolib-cdev.c
> @@ -518,7 +518,8 @@ struct linereq {
> GPIO_V2_LINE_DRIVE_FLAGS | \
> GPIO_V2_LINE_EDGE_FLAGS | \
> GPIO_V2_LINE_FLAG_EVENT_CLOCK_REALTIME | \
> - GPIO_V2_LINE_BIAS_FLAGS)
> + GPIO_V2_LINE_BIAS_FLAGS | \
> + GPIO_V2_LINE_FLAG_EVENT_COUNT)
>
> static void linereq_put_event(struct linereq *lr,
> struct gpio_v2_line_event *le)
> @@ -1252,10 +1253,14 @@ static ssize_t linereq_read(struct file *file,
> struct linereq *lr = file->private_data;
> struct gpioevent_poll_data poll_data;
> struct gpio_v2_line_event le;
> + size_t min_userbuf_size;
> ssize_t bytes_read = 0;
> int ret, offset;
>
> - if (count < sizeof(le))
> + min_userbuf_size = sizeof(le);
> + min_userbuf_size += lr->lines[0].eflags & GPIO_V2_LINE_FLAG_EVENT_COUNT ?
> + sizeof(struct gpio_v2_line_event_ext) : 0;
> + if (count < min_userbuf_size)
> return -EINVAL;
>
> /* Without an IRQ, we can only poll */
> @@ -1270,12 +1275,17 @@ static ssize_t linereq_read(struct file *file,
> lr->lines[offset].eflags, &poll_data);
> if (ret)
> return ret;
> - event = kzalloc(sizeof(*event), GFP_KERNEL);
> + event = kzalloc(min_userbuf_size, GFP_KERNEL);
> event->timestamp_ns = poll_data.timestamp;
> event->id = poll_data.id;
> - if (copy_to_user(buf, (void *)&event, sizeof(event)))
> - return -EFAULT;
> - return sizeof(event);
> + if (lr->lines[offset].eflags & GPIO_V2_LINE_FLAG_EVENT_COUNT)
> + event->ext[0].event_count = poll_data.event_count;
> +
> + ret = copy_to_user(buf, (void *)event, min_userbuf_size);
> + if (ret)
> + ret = -EFAULT;
> + kfree(event);
> + return ret ? ret : min_userbuf_size;
> }
>
> do {
> @@ -1396,7 +1406,7 @@ static int setup_input(struct linereq *lr, struct gpio_v2_line_config *lc,
> ret = edge_detector_setup(&lr->lines[line_no], lc, line_no,
> lflags & GPIO_V2_LINE_EDGE_FLAGS);
> if (ret < 0) {
> - if (ret != -ENXIO) {
> + if (ret == -ENXIO) {
> if (lr->gdev->chip->setup_poll &&
> lr->gdev->chip->setup_poll(lr->gdev->chip, offset,
> &lflags) == 0 &&
> @@ -1513,7 +1523,7 @@ static int linereq_create(struct gpio_device *gdev, void __user *ip)
> goto out_free_linereq;
> }
>
> - file_flags = O_RDONLY | O_CLOEXEC;
> + file_flags = O_CLOEXEC;
> file_flags |= output ? O_WRONLY : O_RDONLY;
> file_flags |= (!output && !lr->lines[i].irq) ? O_NONBLOCK : 0;
>
> @@ -1524,7 +1534,7 @@ static int linereq_create(struct gpio_device *gdev, void __user *ip)
> offset);
> }
>
> - fd = get_unused_fd_flags(O_RDONLY | O_CLOEXEC);
> + fd = get_unused_fd_flags(file_flags);
> if (fd < 0) {
> ret = fd;
> goto out_free_linereq;
> diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
> index 561e289434aa..09637fcbfd52 100644
> --- a/include/linux/gpio/driver.h
> +++ b/include/linux/gpio/driver.h
> @@ -493,6 +493,7 @@ struct gpio_chip {
> struct gpioevent_poll_data {
> __u64 timestamp;
> __u32 id;
> + __u32 event_count;
> };
>
> struct gpio_output_event_data {
> diff --git a/include/uapi/linux/gpio.h b/include/uapi/linux/gpio.h
> index c39efc459b9f..e7fff2a205ec 100644
> --- a/include/uapi/linux/gpio.h
> +++ b/include/uapi/linux/gpio.h
> @@ -80,6 +80,7 @@ enum gpio_v2_line_flag {
> 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),
> + GPIO_V2_LINE_FLAG_EVENT_COUNT = _BITULL(12),
> };
>
> /**
> @@ -270,6 +271,15 @@ enum gpio_v2_line_event_id {
> GPIO_V2_LINE_EVENT_UNKNOWN_EDGE = 3,
> };
>
> +/**
> + * struct gpio_v2_line_event_ext - Extended gpio line event
> + * @event_count: count of events
> + */
> +struct gpio_v2_line_event_ext {
> + __u32 event_count;
> + __u32 reserved[3];
> +};
> +
> /**
> * struct gpio_v2_line_event - The actual event being pushed to userspace
> * @timestamp_ns: best estimate of time of event occurrence, in nanoseconds.
> @@ -280,6 +290,7 @@ 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
> + * @gpio_v2_line_event_ext: Extended gpio line event
> *
> * By default the @timestamp_ns is read from %CLOCK_MONOTONIC and is
> * intended to allow the accurate measurement of the time between events.
> @@ -296,6 +307,7 @@ struct gpio_v2_line_event {
> __u32 line_seqno;
> /* Space reserved for future use. */
> __u32 padding[6];
> + struct gpio_v2_line_event_ext ext[];

This bit is an instant NAK as it breaks the ABI.

While I understand this is a bit of a different problem than the one
handled by the seqno fields, I think you should just think about
adding a field called something like "real_seqno" for those hardware
counted sequence numbers.

Bart

> };
>
> /**
> --
> 2.17.1
>

2021-09-22 10:05:26

by Bartosz Golaszewski

[permalink] [raw]

Subject: Re: [RFC PATCH v1 02/20] gpio: Add GPIO polling interface to GPIO lib

On Tue, Aug 24, 2021 at 6:48 PM <[email protected]> wrote:
>
> From: Lakshmi Sowjanya D <[email protected]>
>
> Some Intel Timed I/O devices do not implement IRQ functionality. Augment
> read() interface to allow polling.
>
> Add two GPIO device methods: setup_poll() and poll():
> - setup_poll() configures the GPIO interface e.g. capture rising edges
> - poll() checks for events on the interface
>
> To implement polling, the driver must implement the two functions above
> and should either leave to_irq() method NULL or return irq 0.
>
> setup_poll() should configure the hardware to 'listen' for input events.
>
> poll() driver implementation must return the realtime timestamp
> corresponding to the event and -EAGAIN if no data is available.
>
> Co-developed-by: Christopher Hall <[email protected]>
> Signed-off-by: Christopher Hall <[email protected]>
> Signed-off-by: Tamal Saha <[email protected]>
> Signed-off-by: Lakshmi Sowjanya D <[email protected]>
> Reviewed-by: Mark Gross <[email protected]>
> ---

Interesting. So the idea is to allow user-space to read line events as
if they were generated by interrupts handled in the kernel. While this
whole series has a long way to go and this patch looks wrong to me in
several places at first glance, I find the idea interesting. Cc'ing
Kent who's the author of most of this code - Kent: what do you think?

Bart

> drivers/gpio/gpiolib-cdev.c | 28 ++++++++++++++++++++++++++--
> include/linux/gpio/driver.h | 19 +++++++++++++++++++
> 2 files changed, 45 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
> index c7b5446d01fd..4741bf34750b 100644
> --- a/drivers/gpio/gpiolib-cdev.c
> +++ b/drivers/gpio/gpiolib-cdev.c
> @@ -1227,13 +1227,34 @@ static ssize_t linereq_read(struct file *file,
> loff_t *f_ps)

Why would you do this in linereq_read()? Userspace ends up in
linereq_poll() when it calls poll().

> {
> struct linereq *lr = file->private_data;
> + struct gpioevent_poll_data poll_data;
> struct gpio_v2_line_event le;
> ssize_t bytes_read = 0;
> - int ret;
> + int ret, offset;
>
> if (count < sizeof(le))
> return -EINVAL;
>
> + /* Without an IRQ, we can only poll */
> + offset = gpio_chip_hwgpio(lr->gdev->descs);
> + if (lr->lines[offset].irq == 0) {
> + struct gpio_v2_line_event *event;
> +
> + if (!(file->f_flags & O_NONBLOCK))
> + return -ENODEV;
> +
> + ret = lr->gdev->chip->do_poll(lr->gdev->chip, offset,
> + lr->lines[offset].eflags, &poll_data);

What if the driver doesn't implement do_poll()?

> + if (ret)
> + return ret;
> + event = kzalloc(sizeof(*event), GFP_KERNEL);
> + event->timestamp_ns = poll_data.timestamp;
> + event->id = poll_data.id;
> + if (copy_to_user(buf, (void *)&event, sizeof(event)))
> + return -EFAULT;
> + return sizeof(event);
> + }
> +
> do {
> spin_lock(&lr->wait.lock);
> if (kfifo_is_empty(&lr->events)) {
> @@ -1314,6 +1335,7 @@ static int linereq_create(struct gpio_device *gdev, void __user *ip)
> {
> struct gpio_v2_line_request ulr;
> struct gpio_v2_line_config *lc;
> + unsigned int file_flags;
> struct linereq *lr;
> struct file *file;
> u64 flags;
> @@ -1411,6 +1433,8 @@ static int linereq_create(struct gpio_device *gdev, void __user *ip)
> goto out_free_linereq;
> }
>
> + file_flags = O_RDONLY | O_CLOEXEC;
> +
> blocking_notifier_call_chain(&desc->gdev->notifier,
> GPIO_V2_LINE_CHANGED_REQUESTED, desc);
>
> @@ -1425,7 +1449,7 @@ static int linereq_create(struct gpio_device *gdev, void __user *ip)
> }
>
> file = anon_inode_getfile("gpio-line", &line_fileops, lr,
> - O_RDONLY | O_CLOEXEC);
> + file_flags);
> if (IS_ERR(file)) {
> ret = PTR_ERR(file);
> goto out_put_unused_fd;
> diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
> index 3a268781fcec..f5b971ad40bc 100644
> --- a/include/linux/gpio/driver.h
> +++ b/include/linux/gpio/driver.h
> @@ -17,6 +17,7 @@ struct device_node;
> struct seq_file;
> struct gpio_device;
> struct module;
> +struct gpioevent_poll_data;
> enum gpiod_flags;
> enum gpio_lookup_flags;
>
> @@ -304,6 +305,11 @@ struct gpio_irq_chip {
> * @add_pin_ranges: optional routine to initialize pin ranges, to be used when
> * requires special mapping of the pins that provides GPIO functionality.
> * It is called after adding GPIO chip and before adding IRQ chip.
> + * @setup_poll: optional routine for devices that don't support interrupts.
> + * Takes flags argument as in/out parameter, where caller requests
> + * event flags and driver returns accepted flags.
> + * @do_poll: optional routine for devices that don't support interrupts.
> + * Returns event specification in data parameter.
> * @base: identifies the first GPIO number handled by this chip;
> * or, if negative during registration, requests dynamic ID allocation.
> * DEPRECATION: providing anything non-negative and nailing the base
> @@ -396,6 +402,14 @@ struct gpio_chip {
>
> int (*add_pin_ranges)(struct gpio_chip *gc);
>
> + int (*setup_poll)(struct gpio_chip *chip,
> + unsigned int offset,
> + u32 *eflags);

Does anyone even call this?

> +
> + int (*do_poll)(struct gpio_chip *chip,
> + unsigned int offset, u32 eflags,
> + struct gpioevent_poll_data *data);
> +
> int base;
> u16 ngpio;
> const char *const *names;
> @@ -471,6 +485,11 @@ struct gpio_chip {
> #endif /* CONFIG_OF_GPIO */
> };
>
> +struct gpioevent_poll_data {
> + __u64 timestamp;
> + __u32 id;
> +};
> +
> extern const char *gpiochip_is_requested(struct gpio_chip *gc,
> unsigned int offset);
>
> --
> 2.17.1
>

This patch doesn't look good - or even tested - but as I said - the
idea itself sounds reasonable in general.

Bart

2021-10-07 02:16:02

by Kent Gibson

[permalink] [raw]

Subject: Re: [RFC PATCH v1 02/20] gpio: Add GPIO polling interface to GPIO lib

On Wed, Sep 22, 2021 at 12:03:53PM +0200, Bartosz Golaszewski wrote:
> On Tue, Aug 24, 2021 at 6:48 PM <[email protected]> wrote:
> >
> > From: Lakshmi Sowjanya D <[email protected]>
> >
> > Some Intel Timed I/O devices do not implement IRQ functionality. Augment
> > read() interface to allow polling.
> >
> > Add two GPIO device methods: setup_poll() and poll():
> > - setup_poll() configures the GPIO interface e.g. capture rising edges
> > - poll() checks for events on the interface
> >
> > To implement polling, the driver must implement the two functions above
> > and should either leave to_irq() method NULL or return irq 0.
> >
> > setup_poll() should configure the hardware to 'listen' for input events.
> >
> > poll() driver implementation must return the realtime timestamp
> > corresponding to the event and -EAGAIN if no data is available.
> >
> > Co-developed-by: Christopher Hall <[email protected]>
> > Signed-off-by: Christopher Hall <[email protected]>
> > Signed-off-by: Tamal Saha <[email protected]>
> > Signed-off-by: Lakshmi Sowjanya D <[email protected]>
> > Reviewed-by: Mark Gross <[email protected]>
> > ---
>
> Interesting. So the idea is to allow user-space to read line events as
> if they were generated by interrupts handled in the kernel. While this
> whole series has a long way to go and this patch looks wrong to me in
> several places at first glance, I find the idea interesting. Cc'ing
> Kent who's the author of most of this code - Kent: what do you think?
>

It is interesting that we're seeing more hardware that provides more
detailed edge info than we get from irq. The hte patch series can also
provide hardware timestamps, but the Timed I/O could even provide the
sequence numbers.
It might be worth abstracting the edge detection so edge events could be
more easily driven by subsystems other than irq, without festooning cdev
with special cases.

I'm not a fan of the polling here though, particularly from userspace.
If polling can't be avoided (why did they not provide an irq??) then I
would do the polling in kernel and place any resulting events in the
cdev kfifo for userspace to read as per the existing events.

Of course that is without knowing a whole lot about the hardware or use
cases. The Intel datasheet doesn't provide much in the way of data :|.

Cheers,
Kent.

2021-10-11 21:16:36

by Dipen Patel

[permalink] [raw]

Subject: Re: [RFC PATCH v1 00/20] Review Request: Add support for Intel PMC

Thanks Linus for referring. I will take a look.

@Sowjanya: I have recently sent out the RFC v2 of the HTE (https://patchwork.ozlabs.org/project/linux-tegra/list/?series=264896).

Please have a look and see if you can add TIO as one of the provider. That patch has necessary GPIOLIB and GPIO-CDEV changes

which can help userspace and in kernel driver retrieve GPIO realtime timestamps.

Best,

Dipen Patel

On 9/16/21 2:21 PM, Linus Walleij wrote:
> Hi Sowjanya,
>
> thanks for your patches!
>
> On Tue, Aug 24, 2021 at 6:48 PM <[email protected]> wrote:
>
>> From: Lakshmi Sowjanya D <[email protected]>
>>
>> Starting with Intel(R) Tiger Lake and Elkhart Lake platforms the PMC
>> hardware adds the Timed I/O hardware interface.
>>
>> The Timed I/O hardware implements some functionality similar to GPIO
>> with added timing logic that is driven by the Always Running Timer
>> (ART).
>>
>> The Timed I/O Hardware implement 3 basic functions:
>> * Input Timestamping
>> * Single Shot Timed Output
>> * Periodic Timed Output
>>
>> Please help to review the changes.
> This looks very similar to the usecase proposed for the HTE
> Hardware Timestamping Engine, proposed by Dipen Patel
> for the nVidia 194 and which is currently in RFC:
> https://lore.kernel.org/linux-gpio/[email protected]/
>
> Please review this new subsystem and see if you can just
> make a slot-in driver using Dipen's patches instead.
>
> Dipen: please have a look at Sowjanya's patches to see
> if this hardware is similar to yours.
>
> Sometimes several vendors come up with similar hardware
> around the same time, because of industry trends, so I would
> not be surprised if these two hardwares address the very
> same usecase.
>
> Yours,
> Linus Walleij