From mboxrd@z Thu Jan 1 00:00:00 1970 From: alexandre.belloni@bootlin.com (Alexandre Belloni) Date: Wed, 28 Mar 2018 17:31:35 +0200 Subject: [PATCH v3 0/6] clocksource: rework Atmel TCB timer driver In-Reply-To: <75e5917b-a9ba-c67e-e964-3f002681f9bb@linaro.org> References: <20180223171558.7037-1-alexandre.belloni@bootlin.com> <9761072.pX2B0LJlSJ@ada> <989df8a3-462a-c645-87f1-9f956e1b22c9@linaro.org> <4073350.0MmxRoANOi@ada> <6d43177a-bbea-6a01-5fa5-1c7891e18412@linaro.org> <20180328141645.GF13942@piout.net> <75e5917b-a9ba-c67e-e964-3f002681f9bb@linaro.org> Message-ID: <20180328153135.GG13942@piout.net> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 28/03/2018 at 16:36:34 +0200, Daniel Lezcano wrote: > On 28/03/2018 16:16, Alexandre Belloni wrote: > > On 28/03/2018 at 15:03:11 +0200, Daniel Lezcano wrote: > >> On 28/03/2018 12:29, Alexander Dahl wrote: > >>> Hello Daniel, > >>> > >>> Am Dienstag, 27. M?rz 2018, 13:30:22 CEST schrieb Daniel Lezcano: > >>>> Can you can give a rough amount for the irq rate on the timer ? > >>> > >>> I used itop [1] now to get a rough estimate. First with kernel v4.14.29-rt25 > >>> (fully preempt RT): > >>> > >>> INT NAME RATE MAX > >>> 19 [ vel tc_clkevt] 397 Ints/s (max: 432) > >>> 26 [ vel eth0] 4 Ints/s (max: 38) > >>> > >>> Next test with kernel v4.15.13 gives (slightly slower, but non-RT): > >>> > >>> INT NAME RATE MAX > >>> 19 [ vel tc_clkevt] 248 Ints/s (max: 273) > >>> 26 [ vel eth0] 4 Ints/s (max: 11) > >>> > >>> With kernel v4.16-rc7 plus this patch series and tcb as clocksource: > >>> > >>> INT NAME RATE MAX > >>> 17 [vel timer at fffa] 2164 Ints/s (max: 2183) > >>> 26 [ vel eth0] 5 Ints/s (max: 10) > >>> > >>> Is this the information you wanted? If not, could you point me on how to get > >>> the requested irq rate? > >> > >> It is perfect. Thanks! > >> > >> It confirms what I was worried about: the clocksource wraps up too > >> quickly thus raising an interrupt every 400us. That is why I asked > >> Alexande about a prescalar register. > >> > > > > The code should behave exactly the same between the previous and the new > > driver. The interrupt is not coming from the clocksource but from the > > clockevent and it is already on the slowest clock, the 32kHz one. > > Do you have an explanation of why the rate is much higher ? > The core is giving deltas of 31 clocks instead of much more than that, I guess I messed up the initialization somewhere. -- Alexandre Belloni, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com