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

[H. Nikolaus Schaller]

Hi Paul,

> Am 29.12.2020 um 23:46 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> 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.

Yes,looks reasonable.

> 
> [...]
> 
>> 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.

and still gives 270ns resolution.

> If that is 
> too infrequent, it would be completely possible for the software to make it 
> more frequent.

IMHO it is more a practical choice than a strict requirement in either direction.

Only, the hrtimer which is calculated from that 56 Hz should run at least at
that speed to catch and count the wrap-arounds.

I have found another symptom of this issue besides sleep 10 needing 20 seconds.
The LEDs can be set to use the heartbeat trigger. And that blinks at half speed
compared to all other systems I have.

> 
>> 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.

Which counter on the chip is used for that so that I could check its
settings with devmem2?

> 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!

Sorry that I didn't review earlier :) That is the benefit of team-work.
It gives higher quality (even if the first proposal, i.e. yours, is
already very good). And combining review and real world testing is also
beneficial.

What else is new: I have played with PWM. The chip is not enabled but
has been programmed for a duty cycle 0. If I devmem2 a duty cycle and
set the enable pin the backlight goes on and is controllable. This
means that we have a proper setup of the pinctrl now.

Unfortunately the LCD is not showing anything, despite an /dev/fb0 existing.
So our LCD controller isn't doing what it should. Could also be a clock
issue. But backlight only going off and not on is a sign of more subtle
issues (like those from CI20 HDMI...).

Anyways I have now consolidated all recent patches, merged everything
and started to build 5.11-rc1 and 5.10.4 etc. So the trees and new patches
will arrive in the next hours.

There is also an update for [1].

BR,
Nikolaus

[1]: https://projects.goldelico.com/p/gta04-kernel/issues/951/#ic3302