[Letux-kernel] [PATCH 00/20] A bunch of JZ4730 fixups for letux-kernel

[Paul Boddie]

On Tuesday, 29 December 2020 23:07:39 CET H. Nikolaus Schaller wrote:
> 
> Now, the interesting part. Here are the new clk_rates:
> 
> root at letux:~# (cd /sys/kernel/debug/clk/; for i in *; do echo $i: $(cat
> "$i/clk_rate"); done) 2>/dev/null ak4643_mcko: 12000000
> cclk: 335462400
> cclkdiv: 335462400

So, these are the CPU-related clock nodes, with cclk hopefully being the input 
to the high resolution timer.

[...]

> pclk: 111820800
> pclkdiv: 111820800
> pll: 335462400

Here, pll is related to cclk, and it looks as if there is no division of pll 
to produce cclk, which contradicts observations I made earlier from old 
register dumps, but I suppose that the clocks might have been set up 
differently now. Certainly, we do want a CPU frequency of around 335 MHz.

[...]

> tcu: 3686400
> timer0: 3686400
> timer1: 3686400
> timer2: 3686400

This shows that the TCU input clock is EXCLK, which is what we ask for in the 
Mipsbook device tree by using assigned-clock.

[...]

> Everything is the same - except for timer0, 1, 2.
> As expected they are really running faster now.

Yes.

> So there are still several tiny bugs to locate in the clockworks.
> At the moment I just know the questions but no answers.
> 
> a) why is real time sleep twice as long the given time?
>    (which timer does the sleep syscall use? A hrtimer?)
> b) why is the timer clock now that fast? Should it be that fast or slower?

Having the TCU frequency as EXCLK seems to set up a wrap-around frequency of 
around 56 Hz, which is probably quite reasonable for scheduling. If that is 
too infrequent, it would be completely possible for the software to make it 
more frequent.

> Which precision do we expect? Seems to be 300µs now which is quite good.
> Higher precision needs more sched_clock-update-load by the hrtimer
> c) the hrtimer isn't triggering fast enough
>    btw: kr_wrap should be smaller as 65535/3686400/1e-9 i.e. ~17e6
>    and it is only ~8e6 i.e. would be quick enough with every 8ms!
>    But it seems to come too slow.
>    So my guess again that hrtimer is somehow broken.
> 
> Do we have any idea which timer is used for hrtimer?

From the plat_time_init function (arch/mips/generic/init.c), I believe it 
should be the clock associated with the cpu device tree node, which is cclk 
(above), with the counter being updated at half that frequency.

So, the high resolution timer should be updated at around 335462400/2 or 
167731200 Hz, unless I am completely misunderstanding what is happening. But 
this depends on the device tree node being understood and the appropriate 
clock being obtained.

> PS: seems as if I have fixed touchpad buttons and keyboard matrix.
> Problem was that ingenic_gpio_irq_(un)mask was not jz4730-aware
> and did write to GPIO_MSK which happens to be the IER and not
> the mask register. So the interrupts were shortly enabled
> and immediately disabled instead of masked. And not properly
> unmasked/enabled again because gpiolib assumed they were still
> enabled.

Sorry to have missed that!

Paul