Hi Thomas Gleixner and Geert, > Subject: Re: [PATCH 0/6] Add RZ/V2M Compare-Match Timer (TIM) support > > On Tue, Dec 06 2022 at 09:40, Geert Uytterhoeven wrote: > > On Tue, Dec 6, 2022 at 9:13 AM Biju Das <biju.das.jz@xxxxxxxxxxxxxx> > wrote: > >> > Do you have any use case to really switch. Doing so disables the > >> > vDSO access to the clocksource. > >> > >> Not really. Architecture timer should be sufficient for clocksource. > > > > When multiple clocksources are registered, the clocksource subsystems > > picks the best one anyway, right? > > As it does for the clock event devices. If there is an architected timer > then that should be always preferred. > > No idea why there is a need for the extra hardware and the drivers which > are both never utilized. I got feedback from BSP team for the actual usage of this timer. Basically, this HW timer is used for measuring the processing time of DRP-AI accurately compared to the CPU timer normally we use. The example use cases, Timer in FREERUN mode, Check the timer value after the restart(1usec)" Timer in FREERUN mode, Check the timer value after the restart(10000000usec)" What is the model to be used for this kind of HW usage? Counter or Timer? I can think of one possible HW usage by using Counter model. Not sure how timer model can be used for this kind of HW usage?? Eg: we can set ceiling values 1usec and 10000000usec using counter framework And that will trigger interrupt events corresponding to the ceiling values to user space and user space app can accurately measure the DRP-AI processing time. Also counter model exposes count values to user space from the counter HW. Cheers, Biju
