Message-ID: <20220806180153.1eb22591@jic23-huawei>
Date:   Sat, 6 Aug 2022 18:01:53 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Julien Panis <jpanis@...libre.com>
Cc:     robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        lars@...afoo.de, linux-iio@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        mranostay@...com, William Breathitt Gray <william.gray@...aro.org>
Subject: Re: [PATCH v3 2/2] iio: time: capture-tiecap: capture driver
 support for ECAP

On Tue, 2 Aug 2022 15:28:09 +0200
Julien Panis <jpanis@...libre.com> wrote:

> On 01/08/2022 16:08, Julien Panis wrote:
> >
> >
> > On 31/07/2022 17:41, Jonathan Cameron wrote:  
> >> On Thu, 28 Jul 2022 19:51:24 +0200
> >> Julien Panis <jpanis@...libre.com> wrote:
> >>  
> >>> ECAP hardware on AM62x SoC supports capture feature. It can be used
> >>> to timestamp events (falling/rising edges) detected on signal input 
> >>> pin.
> >>>
> >>> This commit adds capture driver support for ECAP hardware on AM62x SoC.
> >>>
> >>> In the ECAP hardware, capture pin can also be configured to be in
> >>> PWM mode. Current implementation only supports capture operating mode.
> >>> Hardware also supports timebase sync between multiple instances, but
> >>> this driver supports simple independent capture functionality.
> >>>
> >>> Signed-off-by: Julien Panis <jpanis@...libre.com>  
> >> Hi Julien,
> >>
> >> So this isn't the first ecap driver we've had proposed, but the previous
> >> one was a few years ago and never reached v2.
> >> https://lore.kernel.org/all/20200818153614.6438-1-dts86@cornell.edu/
> >>
> >> Honestly I can't remember much about it, but maybe the discussion around
> >> that will be worth a reread.  
> >
> > Hi Jonathan, thank you for your review.
> >
> > I read the discussion about previous attempt, before submitting this 
> > patch. There were
> > interesting comments indeed.
> >
> > But in this previous attempt, only one-shot pulses were handled 
> > (moreover, global IRQ flag
> > was not cleared, so I'm not sure that IRQ could be raised more than 
> > once).
> >
> > However, ECAP can be used to make time measurements for any type of 
> > "square waveform".
> > That's why I tried to make this event mode configurable. Besides, 
> > using a continuous mode allows
> > handling much more signal types (not only single pulses).
> >  
> >>
> >> The use of ABI here is unusual. So I'd definitely like to see some 
> >> documentation
> >> probably as a file in the main kernel documentation to explain what 
> >> the interface
> >> is an how that relates to what is being captured.  
> >
> > OK, I will add some userspace documentation.
> >  
> >>
> >> First thing to note here is the channel type of IIO_INDEX is now not 
> >> actually
> >> used any more because we moved all the relevant drivers over to the 
> >> counter
> >> subsystem (and we failed to mark it deprecated).  
> >
> > I evaluated this counter subsystem before starting development. 
> > Counting events is not "a priori"
> > the goal when using ECAP.
> >
> > Nevertheless, maybe "counter_push_event" function could do the job. If 
> > I use counter API :
> > # Option 1 : CAP1/2/3/4 registers could be seen as 4 channels of the 
> > same counter...
> > but there are not channels, there are just sequential timestamps 
> > actually. So I'm afraid this leads
> > to misunderstanding for the user.
> > Moreover, the user will have to read several entries (counts 1/2/3/4) 
> > to gather timestamps from
> > the same input signal, which is not very convenient.
> > # Option 2 : Either CAP 1/2/3/4 events could be gathered in a single 
> > channel...but then it will not
> > be possible to configure their polarity (rising/falling edge) 
> > individually (unless I did
> > not understand well counter framework documentation).
> >
> > So, even with counter framework, it will lead to some diverted use of 
> > the framwork, since ECAP
> > is a very specific hardware that do not fit 100% counter philosophy.
> >
> > I admit that ECAP do not fit 100% IIO philosophy either.
> >
> > Maybe misc API would be more relevant actually. Any opinion about it 
> > will be welcome. :-)  
> 
> [Answering my own mail]
> 
> I got a closer look at counter framework. It is not suitable at all for 
> ECAP. Initially, I thought that
> "counter_push_event" function could be used, but the only timestamp 
> handled by this function
> is a software timestamp. I strongly doubt that counter framework 
> maintainer would accept
> some modification here to support hardware timestamp : a patch rejection 
> would be
> legitimate, since a counter is dedicated to "event counting". Whereas 
> ECAP is dedicated to
> "event timestamping".
+CC William.  

one thing to note is that a hardware timestamp is just a freerunning
counter.  As such, you can capture it alongside other data in a similar
fashion to any mutliple counter acquisition (which is the same as we
will be doing with this in IIO anyway).

> 
> Beside, ECAP has 4 timestamp registers but they are used to capture 
> timestamps for a
> single input pin (only 1 channel). In ECAP context, 'index X" is used to 
> identify CAP X
> (used to capture event X detected on a single pin, with X = 0/1/2/3/0...).
> In counter framework, "index X" is used to identify channel X (among 
> several pins).
> So, the word "index" has not the same meaning in counter framework than 
> in ECAP device.
> Somehow, this ECAP index (0/1/2/3 for CAP1/2/3/4 registers) must be 
> logged with timestamp
> because it is an important part of signal info for the user (raw 
> consecutive timestamps
> are not enough).
> 
> So, here is my proposal for my next version :
> (1) Replace IIO_INDEX by IIO_COUNT channel (already used in 
> "stm32-timer-trigger.c" driver)

IIO_COUNT might work, but don't use that driver as a basis. It's a leftover
that was complex to clean up that no one has had the time to do yet.

We want to be careful that any meaning we assign to ABI via this driver
doesn't cause legacy problems.

> # In ECAP documentation, the word "index" is not used. The word used to 
> speak about this
> 0->1->2->3->0 sequenced counter is "Mod4 counter".
> (2) Configure event mode with 4 sysfs entries (to remove the mix of 
> buffers and events interfaces)
> # User will see 4 files (1 file for each CAP timestamp) named 
> "falling_edge_active_0/1/2/3".
> Writing 1 will select falling edge/ Writing 0 will select rising edge.

Naming should reflect the channel to which it applies. So add a prefix to
that. Maybe in_countX_falling_edge_active etc (I'm not sure how this
would fit together as a whole ABI however).

A few questions / comments that might help me get my head around this.

There isn't a direct association between a wire and a channel in IIO.
We have various derived channels.  It's more about measuring 'one thing'.

So we could treat these various signals as aspects of a given thing.
Perhaps simply as events (though the interface for those assumes a common
timestamp basis with the host OS).  In that case we'd have 4 events
and every time one fired we'd push an even across to userspace.

Or we treat them as 4 aspects in a 'scan'.  That means we only get
data once all enabled 'edges' are seen, as we push them all together
as 4 channels.  Those channels contain the 4 timestamps from one
sequence of 0,1,2,3.  Either could be abstract counts, or could be
4 timestamps.

I'm not really sure which approach would work out better.

Rule of thumb. IIO events are for asynchronous things like threshold crossing
detections.  Arguably your detections here are in that category, but because
they happen, 0,1,2,3,0,1,2,3 etc they also look like channel scans - where
we normally pretend they are simultaneous measurements of different signals.
They are rarely actually simultaneous as normally there is a mux involved
somewhere and they channels are sampled sequentially and when a scan is finished
the hardware may well immediately start on the next one.



> 
> Would it be an acceptable alternative for you, Jonathan ? Would either 
> (1) and/or (2) be a "no-go" ?

It may take us a few more iterations to come to a conclusion and even if
the counter subsystem is looking unlikely I'd still like William's input
on this even if it ends up in IIO.  He spent quite some time hammering
odd devices into IIO before there was a counter subsystem.

Thanks,

Jonathan

> 
> >  
> >>
> >> Anyhow, I've reviewed below, but need docs to discuss this in depth.  
> >> In particular
> >> the mix of buffers and events interfaces is unlikely to be an 
> >> acceptable path
> >> forwards.  
> >
> > OK, I will consider alternatives.
> >  
> >>
> >> Jonathan  
> 

Powered by blists - more mailing lists