[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <f2ec8a55-42ad-498a-b793-072444dcb92e@prolan.hu>
Date: Tue, 21 Jan 2025 16:19:27 +0100
From: Csókás Bence <csokas.bence@...lan.hu>
To: <linux-iio@...r.kernel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
<timestamp@...ts.linux.dev>
CC: William Breathitt Gray <wbg@...nel.org>, Jonathan Cameron
<jic23@...nel.org>, Lars-Peter Clausen <lars@...afoo.de>, Daniel Lezcano
<daniel.lezcano@...aro.org>, Thomas Gleixner <tglx@...utronix.de>, "Dipen
Patel" <dipenp@...dia.com>
Subject: [Q] Frequency & duty cycle measurement?
Hi all,
we want to measure the frequency and duty cycle of a signal (relating to
power consumption) using a hardware timer in our SoC (Microchip
SAMA5D2). The hardware is capable of taking a snapshot of the timer
value into another dedicated register pair (RA, RB) on the
rising/falling edges, and a small `devmem`-based userspace utility was
created as a working PoC. Now we want to move to a "proper" kernelspace
solution.
However, none of the existing drivers seem to be able to do this; the
closest was `drivers/counter/microchip-tcb-capture.c`, but that only
seems to count one type of edge (rising/falling), and cannot give us the
time between them, which would be needed for duty cycle calculation. The
only other driver I could find was
`drivers/clocksource/timer-atmel-tcb.c`, which again seems incapable of
such measurements. Therefore, a new module will probably be needed; the
question then becomes: which API to implement.
As `microchip-tcb-capture.c` uses the Generic Counter Interface, that
was obviously a first stop. However, from what I could see, you can only
represent (1) the number of times an edge has been encountered, and (2)
rotary encodings (quadrature and direction-step decoders); and not the
time between edges.
IIO_ALTVOLTAGE and IIO_CHAN_INFO_FREQUENCY/_PHASE also seemed promising
(although the lack of IIO_CHAN_INFO_DUTY_CYCLE already posed a problem),
until I saw that all current drivers are frequency *generators*, and not
measurers, the latter seems to be completely unimplemented.
The only other contender I could find was the Hardware Timestamping
Engine (HTE), but again, it's not clear whether (1) the API is even
capable of relaying duty cycle information to userspace and (2) if it
is, how would one go about implementing it.
It is also entirely possible I missed a driver or API that could handle
this better, if so, please don't keep it to yourselves.
So, how could one go about implementing such a driver?
Bence
Powered by blists - more mailing lists