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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Biju!

On Wed, Dec 07 2022 at 11:35, Biju Das wrote:
>> Subject: RE: [PATCH 0/6] Add RZ/V2M Compare-Match Timer (TIM) support
>> On Wed, Dec 07 2022 at 07:52, Biju Das wrote:
>> > 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?
>
> But our tick frequency for arm64 defconfig is CONFIG_HZ_250=y. So we
> get timer interrupt at every 4 msec.

CONFIG_HIGH_RES_TIMERS=y

> How do we get timer event interrupt, eg: for 1 microsec?

clock_nanosleep(...);

Though 1usec is wishful thinking with either variant of timer hardware.

>> 
>> We are debating a clocksource/clockevent driver and not a counter driver,
>> right?
>
> Yes, Rob pointed out we should not misuse the compatibles as I have both
> Timer and counter bindings for a given HW timer.
>
> Timer, It can be used as broadcast and highres timer for RT.

I buy the broadcast part if you really have a ARM architected timer
which stops in deep idle states. Highres for RT, no! The arm architected
timer works perfectly fine for that.

> 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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux