[Letux-kernel] Timers (was Re: [PATCH 00/20] A bunch of JZ4730 fixups for letux-kernel)

[H. Nikolaus Schaller]

Hi Paul,

> 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.
> 
> 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 
> sufficient.
> 
> The other patch included with this message trims redundant definitions from 
> the clock driver.

I'll try both but I am quite sure that the OST is running properly and having
16 bits only is not a limitation or a reason for the observed problems. Extending
to 32 bit may only hide them better so that it occurs more rarely.

I already found that there are calculations to set up a hr-timer to regularily
and early enough read the OST and handle its 16 bit overflow.

The problem seems to be that this hrtimer isn't scheduled as fast as requested.
So it is a problem of the hrtimer and not the jz4730 specific OST.

The main reason I can imagine is that somewhere there is a spinlock or
interrupts are disabled for a too long time.

Anyways it will be interesting what your patches really change. Maybe we
get another hint towards a debugging strategy.

BR and thanks,
Nikolaus

> 
> Paul<0001-Removed-redundant-CPM-register-definitions.patch><0002-Observe-32-bit-timer-values-countdown-semantics.patch>