Messages in this thread | | | Date | Mon, 8 Aug 2022 10:58:22 +0200 | Subject | Re: [PATCH v3 2/2] iio: time: capture-tiecap: capture driver support for ECAP | From | Julien Panis <> |
| |
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
| |