Regarding clock event driver testing

Regarding clock event driver testing

[Biju Das]

Hi Wolfram,

On RZ/V2M, we have 16 timer channels. First channel we planned to use it as clock source
And remaining 15 channels as clock event devices. I used clocksource-switch to verify
Clocksource functionality. But currently I do not know how to test the clock event?

HW wise, using devmem2, I have programmed clock event channels and verified it triggering IRQ's
At regular interval.

Looks like for CMT/TMU you have upstreamed clock event devices.

Can you please share your test setup details so that I can do the similar testing for
RZ/V2M TIM devices.

HW manual for IP is located at
https://www.renesas.com/in/en/document/mah/rzv2m-users-manual-hardware?language=en

Cheers,
Biju

Re: Regarding clock event driver testing

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

Hi Biju,

> On RZ/V2M, we have 16 timer channels. First channel we planned to use it as clock source
> And remaining 15 channels as clock event devices. I used clocksource-switch to verify
> Clocksource functionality. But currently I do not know how to test the clock event?

I would love to help, but sadly I can't. CMT/TMU haven't been changed in
ages. So, when I upstream them for new SoCs, I test basic/slightly
advanced functionality with 'clocksource-switch' and assume the rest has
been tested before. I didn't test clocksource events. Magnus seems to
have started something, but AFAIU it does the same as your devmem tests:

https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=&submitter=19&state=*&q=cmt&archive=&delegate=

Sorry I can't be of more help.

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

RE: Regarding clock event driver testing

[Biju Das]

Hi Wolfram,

Thanks for the response. I will check.

Meantime, I got a way to test clock event device.
Hacked the driver to make the channel as clock event device
rather than architectural timer.

+       ced->rating = 500;

Cheers,
Biju

>; Geert Uytterhoeven
> <geert+renesas@glider.be>
> Subject: Re: Regarding clock event driver testing
> 
> Hi Biju,
> 
> > On RZ/V2M, we have 16 timer channels. First channel we planned to use
> > it as clock source And remaining 15 channels as clock event devices. I
> > used clocksource-switch to verify Clocksource functionality. But
> currently I do not know how to test the clock event?
> 
> I would love to help, but sadly I can't. CMT/TMU haven't been changed in
> ages. So, when I upstream them for new SoCs, I test basic/slightly
> advanced functionality with 'clocksource-switch' and assume the rest has
> been tested before. I didn't test clocksource events. Magnus seems to
> have started something, but AFAIU it does the same as your devmem tests:
> 
> https://patchwork.kernel.org/project/linux-renesas-
> soc/list/?series=&submitter=19&state=*&q=cmt&archive=&delegate=
> 
> Sorry I can't be of more help.
> 
>    Wolfram

RE: Regarding clock event driver testing

[Biju Das]

Hi Wolfram,

Just an update, we could use counter subsystem as well for testing timers.

For eg: RZ/V2M TIM has a 32 bit counter with interrupts.

Basically, it needs, counter values and interrupt notification to user space
Both can be achieved using counter subsystem. In that case we don't need to
assign all the 16 channels to clock source and clock events in the timer subsystem

Just use 2 channels 1 for clock source and 1 for clock event and 
Other channels to counter subsystem, so that it can be used for various
Purposes.

I am going model TIM as timer and counter bindings.

I have modified [1] to test interrupt notification and counter value

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/tools/counter/counter_example.c?h=next-20221128

sample test app:

for i in {0..13};
do
	echo 1 > /sys/bus/counter/devices/counter$i/count0/enable
	echo 10000 > /sys/bus/counter/devices/counter$i/count0/ceiling
	echo "########## Counter channel $((8 +$i))####"
	for j in {0..2};
	do
		cat /sys/bus/counter/devices/counter$i/count0/count
		sleep 1
	done
	/counter_example $i   &
	PID=$!
	sleep 1
	kill -9 $PID > /dev/null 2>&1

	echo 0 > /sys/bus/counter/devices/counter$i/count0/enable
done

Cheers,
Biju

> -----Original Message-----
> From: Biju Das
> Sent: 25 November 2022 11:41
> To: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Cc: linux-renesas-soc@vger.kernel.org; Chris Paterson
> <Chris.Paterson2@renesas.com>; Geert Uytterhoeven
> <geert+renesas@glider.be>
> Subject: RE: Regarding clock event driver testing
> 
> Hi Wolfram,
> 
> Thanks for the response. I will check.
> 
> Meantime, I got a way to test clock event device.
> Hacked the driver to make the channel as clock event device rather than
> architectural timer.
> 
> +       ced->rating = 500;
> 
> Cheers,
> Biju
> 
> >; Geert Uytterhoeven
> > <geert+renesas@glider.be>
> > Subject: Re: Regarding clock event driver testing
> >
> > Hi Biju,
> >
> > > On RZ/V2M, we have 16 timer channels. First channel we planned to
> > > use it as clock source And remaining 15 channels as clock event
> > > devices. I used clocksource-switch to verify Clocksource
> > > functionality. But
> > currently I do not know how to test the clock event?
> >
> > I would love to help, but sadly I can't. CMT/TMU haven't been changed
> > in ages. So, when I upstream them for new SoCs, I test basic/slightly
> > advanced functionality with 'clocksource-switch' and assume the rest
> > has been tested before. I didn't test clocksource events. Magnus seems
> > to have started something, but AFAIU it does the same as your devmem
> tests:
> >
> > https://patchwork.kernel.org/project/linux-renesas-
> > soc/list/?series=&submitter=19&state=*&q=cmt&archive=&delegate=
> >
> > Sorry I can't be of more help.
> >
> >    Wolfram