Hi William Breathitt Gray, Thanks for the feedback. > Subject: Re: [PATCH 0/6] Add RZ/V2M Compare-Match Timer (TIM) support > > 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? If I am correct, from this thread discussion, we can make use of architecture timer with hrtimer, which will give call back events to user space after time expires. In the callback, we could call clock_gettime(), which uses the VDSO which is fast and accurate. So there is no need to use any extra HW timer. scheduling tick is 4millisec. so if we want callback at 1 microsec, then we need to use clock_nanosleep. Getting 1 microsec callback to user space is challenging as the scheduling tick is only 4 millisec. Cheers, Biju > 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?
