| Message ID | 20221205145955.391526-1-biju.das.jz@bp.renesas.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add RZ/V2M Compare-Match Timer (TIM) support | expand |
On Mon, Dec 05, 2022 at 02:59:49PM +0000, Biju Das wrote: > This patch series aims to add support for Compare-Match Timer (TIM) > module found on RZ/V2M SoC. > > it is composed of 32 channels and channels 0-7 and 24-32 are > reserved for ISP usage. > > Channel 22 is modelled as clock source and Channel 23 is modelled as clock > event driver and the rest of the channels are modelled as counter driver > as it provides Why did you pick those 2 counters for those functions? Unless the h/w blocks are different, this is an abuse of compatible strings. What's the h/w difference that makes you care which counter the OS picks? That's what the DT should describe. If any timer will do, just let the OS pick. > > 1) counter for counting > 2) configurable counter value for generating timer interrupt > 3) userspace event for each interrupt. > > logs:- > Counter driver: > Counter driver is tested by reading counts and interrupts tested by > counter-example in tools/counter/counter_example.c > > Count snapshot value: > 3114 > Output from counter_example when it triggers interrupts: > Timestamp 0: 24142152969 Count 0: 5 > Error Message 0: Success > > Clock source: > Clock source driver is tested by clock-source-switch app. > [ 1275.703567] clocksource: Switched to clocksource arch_sys_counter > [ 1275.710189] clocksource: Switched to clocksource a4000b00.timer Do you have any use case to really switch. Doing so disables the vDSO access to the clocksource. Rob
Hi Rob, Thanks for the feedback. > Subject: Re: [PATCH 0/6] Add RZ/V2M Compare-Match Timer (TIM) support > > On Mon, Dec 05, 2022 at 02:59:49PM +0000, Biju Das wrote: > > This patch series aims to add support for Compare-Match Timer (TIM) > > module found on RZ/V2M SoC. > > > > it is composed of 32 channels and channels 0-7 and 24-32 are reserved > > for ISP usage. > > > > Channel 22 is modelled as clock source and Channel 23 is modelled as > > clock event driver and the rest of the channels are modelled as > > counter driver as it provides > > Why did you pick those 2 counters for those functions? Currently it uses architecture timer for broadcast timer, so I thought Since TIM has 24 channels, use 1 channel for broadcast timer and 1 Channel for clock source. But having said that SoC has an aarch64 architecture clock source strictly speaking we don't need this. > > Unless the h/w blocks are different, this is an abuse of compatible > strings. What's the h/w difference that makes you care which counter the > OS picks? That's what the DT should describe. If any timer will do, just > let the OS pick. There is no HW difference. Same HW block can be used for mutually exclusive functionality. One is for Linux Clock source/event functionality((scheduler tick/broadcast tick etc) and the other purpose is to expose count and event ticks from this module to user space, so that wide range of applications can make use of it. If it is an abuse of compatible strings for mutually exclusive functionality , then I would like to drop clock source and use all the channels as Either clock events(for broadcast ticks and real time usage??) or as counters. If this is not OK, then I need to pick one. I will go with counters. Please share your thoughts. > > > > > 1) counter for counting > > 2) configurable counter value for generating timer interrupt > > 3) userspace event for each interrupt. > > > > logs:- > > Counter driver: > > Counter driver is tested by reading counts and interrupts tested by > > counter-example in tools/counter/counter_example.c > > > > Count snapshot value: > > 3114 > > Output from counter_example when it triggers interrupts: > > Timestamp 0: 24142152969 Count 0: 5 > > Error Message 0: Success > > > > Clock source: > > Clock source driver is tested by clock-source-switch app. > > [ 1275.703567] clocksource: Switched to clocksource arch_sys_counter > > [ 1275.710189] clocksource: Switched to clocksource a4000b00.timer > > 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. Cheers, Biju
Hi Biju, On Tue, Dec 6, 2022 at 9:13 AM Biju Das <biju.das.jz@bp.renesas.com> wrote: > > Subject: Re: [PATCH 0/6] Add RZ/V2M Compare-Match Timer (TIM) support > > On Mon, Dec 05, 2022 at 02:59:49PM +0000, Biju Das wrote: > > > This patch series aims to add support for Compare-Match Timer (TIM) > > > module found on RZ/V2M SoC. > > > > > > it is composed of 32 channels and channels 0-7 and 24-32 are reserved > > > for ISP usage. > > > > > > Channel 22 is modelled as clock source and Channel 23 is modelled as > > > clock event driver and the rest of the channels are modelled as > > > counter driver as it provides > > > > Why did you pick those 2 counters for those functions? > > Currently it uses architecture timer for broadcast timer, so I thought > Since TIM has 24 channels, use 1 channel for broadcast timer and 1 > Channel for clock source. But having said that SoC has an aarch64 architecture > clock source strictly speaking we don't need this. > > > Unless the h/w blocks are different, this is an abuse of compatible > > strings. What's the h/w difference that makes you care which counter the > > OS picks? That's what the DT should describe. If any timer will do, just > > let the OS pick. > > There is no HW difference. Same HW block can be used for mutually exclusive > functionality. > > One is for Linux Clock source/event functionality((scheduler tick/broadcast tick etc) and > > the other purpose is to expose count and event ticks from this module to user space, > so that wide range of applications can make use of it. > > If it is an abuse of compatible strings for mutually exclusive functionality > , then I would like to drop clock source and use all the channels as > Either clock events(for broadcast ticks and real time usage??) or as counters. > > If this is not OK, then I need to pick one. I will go with counters. > > Please share your thoughts. Can't you handle this like sh_cmt.c does: /* * Use the first channel as a clock event device and the second channel * as a clock source. If only one channel is available use it for both. */ > > > 1) counter for counting > > > 2) configurable counter value for generating timer interrupt > > > 3) userspace event for each interrupt. > > > > > > logs:- > > > Counter driver: > > > Counter driver is tested by reading counts and interrupts tested by > > > counter-example in tools/counter/counter_example.c > > > > > > Count snapshot value: > > > 3114 > > > Output from counter_example when it triggers interrupts: > > > Timestamp 0: 24142152969 Count 0: 5 > > > Error Message 0: Success > > > > > > Clock source: > > > Clock source driver is tested by clock-source-switch app. > > > [ 1275.703567] clocksource: Switched to clocksource arch_sys_counter > > > [ 1275.710189] clocksource: Switched to clocksource a4000b00.timer > > > > 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? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
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@bp.renesas.com> 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. Thanks, tglx
Hi Geert, Thanks for the feedback. > Subject: Re: [PATCH 0/6] Add RZ/V2M Compare-Match Timer (TIM) support > > Hi Biju, > > On Tue, Dec 6, 2022 at 9:13 AM Biju Das <biju.das.jz@bp.renesas.com> > wrote: > > > Subject: Re: [PATCH 0/6] Add RZ/V2M Compare-Match Timer (TIM) > > > support On Mon, Dec 05, 2022 at 02:59:49PM +0000, Biju Das wrote: > > > > This patch series aims to add support for Compare-Match Timer > > > > (TIM) module found on RZ/V2M SoC. > > > > > > > > it is composed of 32 channels and channels 0-7 and 24-32 are > > > > reserved for ISP usage. > > > > > > > > Channel 22 is modelled as clock source and Channel 23 is modelled > > > > as clock event driver and the rest of the channels are modelled as > > > > counter driver as it provides > > > > > > Why did you pick those 2 counters for those functions? > > > > Currently it uses architecture timer for broadcast timer, so I thought > > Since TIM has 24 channels, use 1 channel for broadcast timer and 1 > > Channel for clock source. But having said that SoC has an aarch64 > > architecture clock source strictly speaking we don't need this. > > > > > Unless the h/w blocks are different, this is an abuse of compatible > > > strings. What's the h/w difference that makes you care which counter > > > the OS picks? That's what the DT should describe. If any timer will > > > do, just let the OS pick. > > > > There is no HW difference. Same HW block can be used for mutually > > exclusive functionality. > > > > One is for Linux Clock source/event functionality((scheduler > > tick/broadcast tick etc) and > > > > the other purpose is to expose count and event ticks from this module > > to user space, so that wide range of applications can make use of it. > > > > If it is an abuse of compatible strings for mutually exclusive > > functionality , then I would like to drop clock source and use all the > > channels as Either clock events(for broadcast ticks and real time > usage??) or as counters. > > > > If this is not OK, then I need to pick one. I will go with counters. > > > > Please share your thoughts. > > Can't you handle this like sh_cmt.c does: > > /* > * Use the first channel as a clock event device and the second > channel > * as a clock source. If only one channel is available use it for > both. > */ Currently it is handled like above except for the case " If only one channel is available use it for Both", see patch#3 [1] probe function. The only difference is here we have separate address space, clocks, and interrupts for each channel. [1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20221205145955.391526-4-biju.das.jz@bp.renesas.com/ Our customer BSP, uses this hw module for exposing timer interrupt event to user space by using custom driver. The same functionality can be achieved through counter driver. That is the reason, I have added counter driver to expose this functionality as well. > > > > > 1) counter for counting > > > > 2) configurable counter value for generating timer interrupt > > > > 3) userspace event for each interrupt. > > > > > > > > logs:- > > > > Counter driver: > > > > Counter driver is tested by reading counts and interrupts tested > > > > by counter-example in tools/counter/counter_example.c > > > > > > > > Count snapshot value: > > > > 3114 > > > > Output from counter_example when it triggers interrupts: > > > > Timestamp 0: 24142152969 Count 0: 5 > > > > Error Message 0: Success > > > > > > > > Clock source: > > > > Clock source driver is tested by clock-source-switch app. > > > > [ 1275.703567] clocksource: Switched to clocksource > > > > arch_sys_counter [ 1275.710189] clocksource: Switched to > > > > clocksource a4000b00.timer > > > > > > 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? Yes, it picks based on the rating. Cheers, Biju
> 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@bp.renesas.com> > 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. Maybe, if you use secure OS, this timer hardware can be used there. If you use PM deep states, Maybe, it could be used as broadcast event for waking up the system?? Cheers, Biju
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@bp.renesas.com> > 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
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
Hi Thomas Gleixner, Thanks for the feedback. > Subject: RE: [PATCH 0/6] Add RZ/V2M Compare-Match Timer (TIM) support > > 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? But our tick frequency for arm64 defconfig is CONFIG_HZ_250=y. So we get timer interrupt at every 4 msec. How do we get timer event interrupt, eg: for 1 microsec? > > > 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? 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. Counter, It can be used as measuring the processing time of DRP-AI. What is the best way to use this hardware to take care of all this use cases? So far all the Renesas timers used timer model. But for RZ/V2M the HW usage is different. The customer BSP mainly uses this timer for measuring the processing time of DRP-AI, so the expectation is we should at least have support for this use case. Cheers, Biju
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
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
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?
On Sat, Dec 10 2022 at 07:52, Biju Das wrote: > 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. The tick is only relevant if high resolution timers are disabled because then hrtimers are expired in the tick. If high resolution timers are enabled then the hrtimer expiry happens at the exact expiry time. What's challenging about the 1 microsecond accuracy is that the system immanent latencies are already in that range. So while the timer fires exactly, the actual execution of the woken up task in user space is not exact as that is subject to the worst case sum of latencies in the system. Thanks, tglx
This patch series aims to add support for Compare-Match Timer (TIM) module found on RZ/V2M SoC. it is composed of 32 channels and channels 0-7 and 24-32 are reserved for ISP usage. Channel 22 is modelled as clock source and Channel 23 is modelled as clock event driver and the rest of the channels are modelled as counter driver as it provides 1) counter for counting 2) configurable counter value for generating timer interrupt 3) userspace event for each interrupt. logs:- Counter driver: Counter driver is tested by reading counts and interrupts tested by counter-example in tools/counter/counter_example.c Count snapshot value: 3114 Output from counter_example when it triggers interrupts: Timestamp 0: 24142152969 Count 0: 5 Error Message 0: Success Clock source: Clock source driver is tested by clock-source-switch app. [ 1275.703567] clocksource: Switched to clocksource arch_sys_counter [ 1275.710189] clocksource: Switched to clocksource a4000b00.timer [OK] # Totals: pass[ 1275.718112] clocksource: Switched to clocksource arch_sys_counter :0 fail:0 xfail:0 xpass:0 skip:0 error:0 # Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0 Clock event: clock event driver is tested by changing the rating as 500. Biju Das (6): clk: renesas: r9a09g011: Add TIM clock and reset entries dt-bindings: timer: Add RZ/V2M TIM binding clocksource/drivers/rzv2m-tim: Add Renesas RZ/V2M compare match timer(TIM) driver dt-bindings: counter: Add RZ/V2M TIM counter binding counter: Add Renesas RZ/V2M TIM counter driver arm64: dts: renesas: r9a09g011: Add tim nodes .../counter/renesas,rzv2m-tim-cnt.yaml | 83 +++++ .../bindings/timer/renesas,rzv2m-tim.yaml | 83 +++++ arch/arm64/boot/dts/renesas/r9a09g011.dtsi | 192 ++++++++++ drivers/clk/renesas/r9a09g011-cpg.c | 22 ++ drivers/clocksource/Kconfig | 7 + drivers/clocksource/Makefile | 1 + drivers/clocksource/rzv2m-tim.c | 330 ++++++++++++++++++ drivers/counter/Kconfig | 10 + drivers/counter/Makefile | 1 + drivers/counter/rzv2m-tim-cnt.c | 312 +++++++++++++++++ 10 files changed, 1041 insertions(+) create mode 100644 Documentation/devicetree/bindings/counter/renesas,rzv2m-tim-cnt.yaml create mode 100644 Documentation/devicetree/bindings/timer/renesas,rzv2m-tim.yaml create mode 100644 drivers/clocksource/rzv2m-tim.c create mode 100644 drivers/counter/rzv2m-tim-cnt.c