Re: [PATCH 0/6] Add RZ/V2M Compare-Match Timer (TIM) support

[William Breathitt Gray <william.gray@linaro.org>]

[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]

On Wed, Dec 07, 2022 at 05:49:09PM +0100, Thomas Gleixner wrote:
> On Wed, Dec 07 2022 at 11:35, Biju Das wrote:
> > Counter, It can be used as measuring the processing time of DRP-AI.
> 
> Sigh. You can do that with the architected timer too, especially when
> you are going to do the measurement in user space.
> 
> clock_gettime(), which uses the VDSO with the architected timer is fast
> to access and accurate.
> 
> Thanks,
> 
>         tglx

Hi Biju,

It's true that you could implement a Counter driver to achieve what you
want here, but I don't think that's the most apt interface for this
device. Your device is used to measure the processing time of DRP-AI, so
modeling this as a clocksource seems like the right approach to take.

Of course, if there is something missing from clocksource/clockevent
that you need, then it should be added to the subsystem. So let's try to
narrow down exactly what functionality you need.

You gave a Counter use-case example earlier where you can configure the
ceiling value of the timer (e.g. to 1usec or 10000000usec) and push
Counter events on the interrupts that trigger off that that
configuration; the Counter subsystem can logs the current system time
everytime a Counter event is pushed.

Could the same thing be achieved using clockevents framework instead?
With this approach you would register an event to fire in the future
(e.g. 1usec or 10000000usec) and then call clock_gettime() to get the
current system when you're notified of the event. Would this approach
work for your use-case, or is something else missing here?

William Breathitt Gray

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]