[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdYJkPgaz-BvQ1X0PHRCCbn0hrMDabouDwHkn+pr9d-dSQ@mail.gmail.com>
Date: Thu, 16 Sep 2021 23:42:04 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: "D, Lakshmi Sowjanya" <lakshmi.sowjanya.d@...el.com>,
"thierry.reding@...il.com" <thierry.reding@...il.com>,
Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>, Lee Jones <lee.jones@...aro.org>,
"open list:PWM SUBSYSTEM" <linux-pwm@...r.kernel.org>
Cc: "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
Bartosz Golaszewski <bgolaszewski@...libre.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Mark Gross <mgross@...ux.intel.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
"Saha, Tamal" <tamal.saha@...el.com>, bala.senthil@...el.com,
Dipen Patel <dipenp@...dia.com>
Subject: Re: [RFC PATCH v1 07/20] gpio: Add output event generation method to
GPIOLIB and PMC Driver
Hi Lakshmi,
On Tue, Aug 24, 2021 at 6:48 PM <lakshmi.sowjanya.d@...el.com> wrote:
> From: Lakshmi Sowjanya D <lakshmi.sowjanya.d@...el.com>
>
> 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 <christopher.s.hall@...el.com>
> Signed-off-by: Christopher Hall <christopher.s.hall@...el.com>
> Signed-off-by: Tamal Saha <tamal.saha@...el.com>
> Signed-off-by: Lakshmi Sowjanya D <lakshmi.sowjanya.d@...el.com>
> Reviewed-by: Mark Gross <mgross@...ux.intel.com>
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.
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.
Yours,
Linus Walleij
Powered by blists - more mailing lists