Re: [PATCH v3 3/3] counter: Add STM based counter

[Daniel Lezcano]

Hi William,

On 12/28/25 07:52, William Breathitt Gray wrote:
> On Wed, Dec 17, 2025 at 08:49:57AM +0100, Daniel Lezcano wrote:
> > The NXP S32G2 automotive platform integrates four Cortex-A53 cores and
> > three Cortex-M7 cores, along with a large number of timers and
> > counters. These hardware blocks can be used as clocksources or
> > clockevents, or as timestamp counters shared across the various
> > subsystems running alongside the Linux kernel, such as firmware
> > components. Their actual usage depends on the overall platform
> > software design.
> >
> > In a Linux-based system, the kernel controls the counter, which is a
> > read-only shared resource for the other subsystems. One of its primary
> > purposes is to act as a common timestamp source for messages or
> > traces, allowing correlation of events occurring in different
> > operating system contexts.
> >
> > These changes introduce a basic counter driver that can start, stop,
> > and reset the counter. It also handles overflow accounting and
> > configures the prescaler value.
> >
> > Signed-off-by: Daniel Lezcano <daniel.lezcano@xxxxxxxxxx>
>
> Hi Daniel,
>
> It sounds like you're trying to implement a clock for timestamping.

Well no, it is a counter which is used for timestamping. It is an 
automotive design.

> Although the Generic Counter interface is flexible enough to shoehorn a
> a clock into its representation, I don't believe it's the right
> abstraction for this particular device.
>
> Perhaps reimplementing this
> driver under the Linux common clock framework would be a better approach
> to achieve what you want.

The common clock framework ? Sorry I may have misunderstood the CCF but 
how a counter exported and controlled by the userspace can be managed by 
the CCF. Can you elaborate ?

> Regardless, if you do pursue a Counter driver you'll need to follow the
> Generic Counter paradigm[^1] and define at least three core components:
> a Signal, a Synapse, and a Count. Resetting the Count is typically
> implemented by defining a struct counter_ops counter_write()
> callback[^2], while overflows are typically implemented by pushing
> COUNTER_EVENT_OVERFLOW Counter events[^3] that can be watched by
> userspace.

Yes, I think the Generic counter makes sense here for the goal to be 
achieved. Thanks for the pointers, I'll see how the counter fits with 
the paradigm.

  -- Daniel


> William Breathitt Gray
>
> [^1] https://docs.kernel.org/driver-api/generic-counter.html#paradigm
> [^2] https://docs.kernel.org/driver-api/generic-counter.html#c.counter_ops
> [^3] https://docs.kernel.org/driver-api/generic-counter.html#counter-events


--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog