[Letux-kernel] jz4730-i2c - clocksource

H. Nikolaus Schaller hns at goldelico.com
Sun Feb 28 21:53:08 CET 2021


One more result:


> Am 28.02.2021 um 19:16 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> [    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
> [    0.000000] NR_IRQS: 256
> [    0.000000] random: get_random_bytes called from start_kernel+0x720/0x960 with crng_init=0
> [    0.000000] clocksource: ingenic-timer: mask: 0xffff max_cycles: 0xffff, max_idle_ns: 7910990 ns
> 
> Now, the ingenic-timer is initialized
> 
> [    0.012152] sched_clock: 16 bits at 3686kHz, resolution 271ns, wraps every 8888753ns
> 
> Here it initialized some scheduler clock
> 
> These both come from drivers/clocksource/ingenic-timer.c
> 
> [    0.012163] Console: colour dummy device 80x25
> [    0.004522] printk: console [tty0] enabled
> 
> Oops - printk time runs backwards!
> 
> [    0.017993] Calibrating delay loop... 334.23 BogoMIPS (lpj=1671168)
> [    0.050788] pid_max: default: 32768 minimum: 301
> [    0.062225] LSM: Security Framework initializing
> [    0.063110] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
> [    0.076252] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
> [    0.077315] rcu: Hierarchical SRCU implementation.
> [    0.085358] devtmpfs: initialized
> [    0.109684] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
> 
> here the jiffies clocksource is initialized

This is from really using clocksource=jiffies

[    0.000000] random: get_random_bytes called from start_kernel+0x720/0x960 with crng_init=0
[    0.000000] clocksource: ingenic-timer: mask: 0xffff max_cycles: 0xffff, max_idle_ns: 7910990 ns
[    0.011686] sched_clock: 16 bits at 3686kHz, resolution 271ns, wraps every 8888753ns
[    0.011698] Console: colour dummy device 80x25
[    0.004085] printk: console [tty0] enabled

printk time is also running backwards!

[    0.017599] Calibrating delay loop... 334.23 BogoMIPS (lpj=1671168)
[    0.074705] pid_max: default: 32768 minimum: 301
[    0.079610] LSM: Security Framework initializing
[    0.080513] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.075880] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.076987] rcu: Hierarchical SRCU implementation.
[    0.085041] devtmpfs: initialized
[    0.109314] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns


This means the main problem is not the ingenic-timer. It may just makes
another (unknown) issue more critical which blocks boot.

So we are back at the question how the sched_clock works. It

a) uses ingenic_tcu_timer_read for a 16 bit timer
b) uses a high precision timer event to detect and handle overflows of the 16 bit timer

Which would mean that the high precision timer is still not scheduled correctly.

This is done in ingenic_tcu_cevt_set_next().

Hm... If we look at the jz4780 it uses the ingenic-ost.c driver. But has no
equivalent to ingenic_tcu_cevt_set_next().

But if we look into ingenic-sysost.c we find that ingenic_ost_cevt_set_next()
is also doing direct readl/writel:

https://elixir.bootlin.com/linux/latest/source/drivers/clocksource/ingenic-sysost.c#L242

This means we should get rid of the regmap in ingenic-timer.c!

Not only for reading but also for writing the timer.

But a test shows no improvement - although it should be done anyways.

This issue remains a mysterium.

The ingenic-timer issue is elsewhere. Maybe the timer speed is not what the kernel thinks?
Then it could read the timer register but make false decisions based on time differences.

BR,
Nikolaus



More information about the Letux-kernel mailing list