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

[Thomas Gleixner <tglx@linutronix.de>]

Biju!

On Wed, Dec 07 2022 at 07:52, Biju Das wrote:
>> On Tue, Dec 06 2022 at 09:40, Geert Uytterhoeven wrote:
>> > 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.

How is a slow to access timer with a lower clock frequency more
accurate?

> 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.

Counter subsystem != clocksource/event subsystem.

We are debating a clocksource/clockevent driver and not a counter
driver, right?

Thanks,

        tglx