Re: Intel Timed-IO driver in IIO/Counter subsystem

[Kent Gibson <kent.gibson@iinet.net.au>]

On Thu, Jun 23, 2022 at 02:21:30PM +0200, Linus Walleij wrote:
> On Sat, Jun 18, 2022 at 4:01 AM Hall, Christopher S
> <christopher.s.hall@intel.com> wrote:
> > Friday, June 17, 2022 4:40 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > > For 2. I am uncertain. Periodic events sound like PWM to me.
> >
> > I do not think TGPIO periodic output is useful for PWM. There are two output
> > modes: edge output and pulse output. In edge mode output, where the an edge
> > is produced periodically based on the programmed period the duty cycle is
> > always 50%. In pulse mode output where a pulse is produced each output
> > period, the width of the pulse is two ART ticks which on current Intel
> > client platforms is about 50 ns. The pulse width is not adjustable.
> >
> > We want to be able to output a clock from 1 Hz (1 PPS) up to 1 KHz that is
> > synchronized with the system clock.
> >
> > It is possible to represent the periodic output function as a PWM device,
> > but the PWM subsystem output - without modification - is not aligned to
> > any clock which breaks the timing application.
> 
> Is it "just" a clock then? As in drivers/clk?
> 
> It's of course annoying that the functionality of a certain hardware falls
> between the subsystems so we end up using pieces of a subsystem in
> another one, but there are several precedents, like network switch chips
> and USB UART chips with GPIO inside them, or graphic chips with
> clock dividers inside.
> 
> > > If a "single event" is something
> > > like pulling a GPIO line high/low at a specific (wall clock) time in the
> > > future, it should probably be in the GPIO subsystem, like a triggered
> > > GPIO event or so, that sounds a bit hard but certainly doable with some
> > > thinking and tinkering.
> >
> > Earlier, we proposed a linereq_write() method in addition to the already
> > existing linereq_read().
> >
> > https://lkml.org/lkml/2021/8/24/807
> 
> This might be a good approach for this part of the hardware, as long
> as we can make sure we get the userspace API abstract enough
> that other hardware can make use of it and userspace does not
> need to know what provides the timed output, just that there is
> some hardware that does.
> 
> The ABI in the patch looks a bit dangerous, what happens if
> you set an event like that and something decides to shake the
> line by setting the output while the scheduled event is pending?
> 
> The direction seems sound however, but Bartosz and Kent need
> to look at it in detail, their effort on the userspace ABI has been
> tremendous.
> 

Extending the GPIO uAPI seems like a reasonable approach for timed
sets, but as Linus mentioned, you need to consider the semantics of
your operation for the general case.  What if the set time has already
passed?  What happens with subsequent sets when one is already pending?
Can they be cancelled?

My first thought was that you could extend the SET_VALUES ioctl but,
while we have reserved space for future use in most of the ioctls it
turns out we overlooked sets and gets, so you would be looking at a new
ioctl.  And you need to keep in mind how the SET_VALUES ioctl would
interact with it (Linus' point).

I don't see the linereq_write() approach flying - an ioctl is more
appropriate.

Cheers,
Kent.