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:
signature.asc
Description: PGP signature
