[Letux-kernel] [PATCH 00/20] A bunch of JZ4730 fixups for letux-kernel
H. Nikolaus Schaller
hns at goldelico.com
Tue Dec 29 23:07:39 CET 2020
Hi Paul,
> Am 29.12.2020 um 19:25 schrieb Paul Boddie <paul at boddie.org.uk>:
>
> On Tuesday, 29 December 2020 17:23:31 CET H. Nikolaus Schaller wrote:
>> Well, bad behaviour to answer only to one's own mails...
>
> Well, I do it quite a lot. :-)
>
>>> Hm. How and with which parameters is the ingenic-timer setup
>>> calling sched_clock_register()?
>>
>> Finally found it:
>>
>> https://elixir.bootlin.com/linux/latest/source/drivers/clocksource/ingenic-timer.c#L346
>>
>> rate = clk_get_rate(tcu->cs_clk);
>> sched_clock_register(ingenic_tcu_timer_read, 16, rate);
>>
>> So bits = 16 and rate = tcu->cs_clk.
>>
>> Do we define the cs clock wrongly in DTS? With wrong clock rate?
>> Can I read that through sysfs?
>
> As far as I know, the following properties of the tcu node are applicable:
>
> clocks = <&cgu JZ4730_CLK_RTC>,
> <&cgu JZ4730_CLK_EXT>,
> <&cgu JZ4730_CLK_PCLK>,
> <&cgu JZ4730_CLK_TCU>;
> clock-names = "rtc", "ext", "pclk", "tcu";
>
> This is where I was uncertain about the previous TCU driver code (drivers/clk/
> ingenic/tcu.c), since there are four clocks listed here, all but the last one
> being used to configure the timer, but that code employed seven parent clocks
> (breaking out the divided PCLK into four distinct clocks) for timer
> configuration. However, these clocks are not acquired to configure the timer
> (or not primarily), which is what I was worried about.
>
> Reviewing the code again, I see something that I probably missed when
> modifying it: the ingenic_tcu_timer_parents which map the register-appropriate
> values for the input clocks employs the JZ4740 values, not ones suitable for
> the JZ4730 as was done before. This is definitely going to cause the wrong
> clock to be selected, I think.
>
> So, I recommend reverting the "Simplified JZ4730 TCU driver modifications."
> patch sent earlier. I don't think there was anything particularly wrong with
> what it was doing.
>
> Sorry for the inconvenience!
No problem. Especially as it is not the full solution...
sched_clock still makes jumps back and forth. It just runs slower and the jumps
are smaller.
So some divisor has changed but the overall problem of the hrtimer running too
slow is not solved.
New log:
[ 0.165129] adapter_test: sched_clock=165084545 jiffies=4294937483 OTCNT1=47050
[ 0.172751] adapter_test: sched_clock=172710142 jiffies=4294937483 OTCNT1=18939
[ 0.162822] adapter_test: sched_clock=162766294 jiffies=4294937484 OTCNT1=55596
[ 0.170465] adapter_test: sched_clock=170423358 jiffies=4294937484 OTCNT1=27369
[ 0.178087] adapter_test: sched_clock=178045970 jiffies=4294937484 OTCNT1=64805
[ 0.168160] adapter_test: sched_clock=168103750 jiffies=4294937485 OTCNT1=35921
[ 0.175802] adapter_test: sched_clock=175760814 jiffies=4294937485 OTCNT1=7693
[ 0.183338] adapter_test: sched_clock=183296893 jiffies=4294937485 OTCNT1=45448
[ 0.173411] adapter_test: sched_clock=173355214 jiffies=4294937486 OTCNT1=16561
[ 0.181053] adapter_test: sched_clock=181012007 jiffies=4294937486 OTCNT1=53871
[ 0.188676] adapter_test: sched_clock=188634348 jiffies=4294937486 OTCNT1=25772
[ 0.178749] adapter_test: sched_clock=178692941 jiffies=4294937487 OTCNT1=62421
[ 0.186392] adapter_test: sched_clock=186350548 jiffies=4294937487 OTCNT1=34191
[ 0.194014] adapter_test: sched_clock=193972618 jiffies=4294937487 OTCNT1=6094
[ 0.184017] adapter_test: sched_clock=183959596 jiffies=4294937488 OTCNT1=43006
[ 0.191660] adapter_test: sched_clock=191618559 jiffies=4294937488 OTCNT1=14772
[ 0.199282] adapter_test: sched_clock=199241172 jiffies=4294937488 OTCNT1=52207
[ 0.189354] adapter_test: sched_clock=189298680 jiffies=4294937489 OTCNT1=23324
[ 0.196997] adapter_test: sched_clock=196955473 jiffies=4294937489 OTCNT1=60634
[ 0.204620] adapter_test: sched_clock=204578357 jiffies=4294937489 OTCNT1=32532
[ 0.194732] adapter_test: read_sched_clock=ingenic_tcu_timer_read+0x0/0xb8
[ 0.201851] adapter_test: epoch_ns=194510811
[ 0.206317] adapter_test: epoch_cyc=61406
[ 0.210523] adapter_test: sched_clock_mask=65535
[ 0.197799] adapter_test: mult=568888889
[ 0.201935] adapter_test: shift=21
[ 0.205531] adapter_test: wrap_kt=8888753
[ 0.209780] adapter_test: actual_read_sched_clock=ingenic_tcu_timer_read+0x0/0xb8
Obviously the OTCNT1 is now running much faster. And overflows every second or
third printk().
The sleep system call is now a little faster but seems to run at half speed.
I.e. sleep 10 waits 20 seconds.
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
clk-usb: 47923200
clk_dump:
clk_orphan_dump:
clk_orphan_summary:
clk_summary:
dma: 111820800
ext: 3686400
ext_div128: 4294967295
hclk: 111820800
hclkdiv: 111820800
i2c: 111820800
i2s: 335462400
lcd: 111820800
lcd_pclk: 335462400
lcddiv: 111820800
mclk: 111820800
mclkdiv: 111820800
mmc: 24000000
msc16m: 16000000
msc24m: 24000000
pcf8563-clkout: 32768
pclk: 111820800
pclkdiv: 111820800
pll: 335462400
pll half: 4294967295
rtc: 32768
spi: 335462400
tcu: 3686400
timer0: 3686400
timer1: 3686400
timer2: 3686400
uart0: 3686400
uart1: 3686400
uart2: 3686400
uart3: 3686400
uhc: 47923200
uhcdiv: 47923200
usb48m: 48000000
wdt: 4294967295
root at letux:~#
Everything is the same - except for timer0, 1, 2.
As expected they are really running faster now.
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? 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?
BR,
Nikolaus
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.
More information about the Letux-kernel
mailing list