[Letux-kernel] Timers (was Re: [PATCH 00/20] A bunch of JZ4730 fixups for letux-kernel)
H. Nikolaus Schaller
hns at goldelico.com
Tue Jan 19 17:14:08 CET 2021
> Am 18.01.2021 um 01:03 schrieb Paul Boddie <paul at boddie.org.uk>:
> Nikolaus (and others),
> Just following up to something from a while ago...
> On Wednesday, 30 December 2020 18:02:40 CET Paul Boddie wrote:
>> On Wednesday, 30 December 2020 15:10:05 CET H. Nikolaus Schaller wrote:
>>> Which counter on the chip is used for that so that I could check its
>>> settings with devmem2?
>> Unless I am mistaken, the r4k_read_sched_clock function (arch/mips/kernel/
>> csrc-r4k.c) will be used, and this takes advantage of the Count coprocessor
>> register (CP0 register 9 select 0).
> In fact, I am not sure this is being included in the build. The arch/mips/
> Kconfig file does not set CSRC_R4K for any of the Ingenic-related options.
> I was just reviewing the timer-related code, and I can only suggest the
> improvements covered by the patch included here, with the casting to 16-bit
> values removed, and with an adjustment setting the counter upon reload
> appropriately remembering that the OST counts down, not up, unlike the TCU on
> the JZ4740.
Ah, sorry. I didn't understand that you essentially had the same finding as I had...
So you deserve appreciation of the first to have found the key issue (which is
setting both registers to "next").
Expanding to 32 bit turned out to be not necessary.
> Looking at my Fiasco timer initialisation code, the input clock frequency
> being EXCLK or 3686400Hz and a "scheduler granularity" of 1000 results in a
> reload value for the timer of 3686, so in that environment a 16-bit value is
> The other patch included with this message trims redundant definitions from
> the clock driver.
It was unfortunate that your patch didn't apply to my working branch. It would
likely have solved the issue a little faster... But we would have added an
unnecessary expansion to 32 bit.
BR and thanks,
More information about the Letux-kernel