Date:   Mon, 8 Aug 2022 10:58:22 +0200
From:   Julien Panis <jpanis@...libre.com>
To:     William Breathitt Gray <william.gray@...aro.org>
Cc:     Jonathan Cameron <jic23@...nel.org>, 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
Subject: Re: [PATCH v3 2/2] iio: time: capture-tiecap: capture driver support
 for ECAP



On 08/08/2022 02:30, William Breathitt Gray wrote:
> Hi Julien,
>
> I've taken a cursory look over the TI ECAP reference guide and your
> descriptions in this thread. I think a device driver for this would fit
> better in the Counter subsystem than IIO.
>
> First I want to correct a minor misunderstanding: the "timestamp"
> member of struct counter_event is simply a way to identify Counter
> events on the system as a way of grouping multiple Counter watches. In
> other words, the "timestamp" member here represents when a Counter event
> was detected by the system, not when an event was logged on the counter
> device hardware. Instead, hardware timestamps such as the CAPx registers
> would be provided by the "value" member of struct counter_event.
>
> Now, I have a few ideas for how we could expose the timestamps using a
> Counter device driver, but first I want to make sure I understand
> correctly what's happening in this device. If I understand correctly, we
> have the following device components:
>
> * CTR: 32-bit counter timer
> * Mod4: 2-bit counter
> * CAP1-CAP4: four 32-bit registers, each indepedently store a timestamp
> * ECAP: input signal providing event trigger edges
>
> Four edge polarities are configured corresponding to each CAPx register,
> yet the input signal is still the same single ECAP pin. The event that
> is fired is instead determined by the Mod4 counter: when Mod4 is 0 and
> the edge of ECAP matches the polarity configured for CAP1 then an event
> is triggered which saves the current CTR value to CAP1 and increments
> Mod4 to 1, etc.
>
> Is my understanding of how this device behaves correct?

Hi William. Thank you for your help.
Yes, your understanding of how this device behaves is correct.

>
> If so, then one possible way to represent this device in the Counter
> sysfs tree is something like this:
>
> * CTR: /sys/bus/counter/devices/counterX/count0/count
> * Mod4: /sys/bus/counter/devices/counterX/count1/count
> * CAP1: /sys/bus/counter/devices/counterX/count1/cap1
> * CAP2: /sys/bus/counter/devices/counterX/count1/cap2
> * CAP3: /sys/bus/counter/devices/counterX/count1/cap3
> * CAP4: /sys/bus/counter/devices/counterX/count1/cap4
> * ECAP: /sys/bus/counter/devices/counterX/signal0/signal
> * polarity1: /sys/bus/counter/devices/counterX/signal0/cap1_polarity
> * polarity2: /sys/bus/counter/devices/counterX/signal0/cap2_polarity
> * polarity3: /sys/bus/counter/devices/counterX/signal0/cap3_polarity
> * polarity4: /sys/bus/counter/devices/counterX/signal0/cap4_polarity
>
> This is just a tentative arrangement (you could also include "enable"
> attributes as well), but it should give you an idea of how it could be
> organized.
>
> In your driver, you could then use counter_push_event() whenever you get
> an event triggered. In userspace, your application will add Counter
> watches for the CAPx registers they want. When an event triggers,
> userspace can then received all four CAP register values at the same
> time via the respective /dev/counterX character device node.
>
> Would this design work for your needs?

Yes, that would work for my needs.
The "how" is not fully clear to me yet, since I never used counter 
subsystem. But the
best way to understand better how it works is probably to start working 
with it. :-)
So, next patch version will be based on counter subsystem.

>
> William Breathitt Gray

Powered by blists - more mailing lists