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

[H. Nikolaus Schaller]

Hi Paul,

> Am 28.12.2020 um 23:29 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> 
>> I still have the printk sched_clock timer issue. Which also may have
>> an influence since I don't know if it is used by
>> wait_for_completion_timeout() and triggers "early" timeout. Then I would
>> try to debug this in the i2c driver...
> 
> [...]
> 
>> To me the pattern looks like integer overflow during
>> multiplication / division or expansion from 32 bit
>> to 64 bit time value.
>> 
>> Question: how does sched_clock() work on the jz4730?
>> 
>> Obviously it does not use the simple jiffies based clock:
>> 
>> https://elixir.bootlin.com/linux/latest/source/kernel/sched/clock.c#L64
>> 
>> It likely does use
>> 
>> https://elixir.bootlin.com/linux/latest/source/kernel/time/sched_clock.c#L82
>> 
>> But I could not identify a call to sched_clock_register()
>> or how the setup works. And which registers sched_clock() reads.
>> 
>> So we probably should focus on that first before I
>> continue with the i2c driver.
> 
> So, among the other things I have been looking at is this. I went searching 
> for timer/counter details starting at time_init (arch/mips/kernel/time.c). 
> This led me to some likely definitions applicable to the JZ4730 such as 
> init_r4k_clocksource (arch/mips/kernel/csrc-r4k.c) which uses a variable 
> called mips_hpt_frequency that is defined in plat_time_init (arch/mips/
> generic/init.c).
> 
> It is in the plat_time_init function that an attempt is made to get a clock, 
> but we haven't defined one in the device tree for the JZ4730. So, with the 
> assumption that this might make a difference, I have made a patch that should 
> add a CPU node with a reference to the appropriate clock.
> 
> Paul<0001-Add-missing-CPU-node-to-make-timer-available.patch>

i have added the patch, which looks good to have in ay case, but it has no
effect.

I took the opportunity to print /proc/interrupts and test the "sleep" command:
it took real time 30 seconds for the "sleep 10"...

root at letux:~# cat /proc/interrupts && sleep 10 && cat /proc/interrupts 
           CPU0       
  2:      24680      MIPS   2  SoC intc cascade interrupt
  8:       8277       TCU   0  TCU0
  9:        413      INTC   1  10042000.i2c
 10:       1563      INTC   9  ttyS0
 14:       8656      INTC  14  10021000.mmc
 15:       6190      INTC  13  ohci_hcd:usb1
 16:          0     GPIOA   0  matrix-keypad
 17:          0     GPIOA   1  matrix-keypad
 18:          0     GPIOA   2  matrix-keypad
 19:          0     GPIOA   3  matrix-keypad
 20:          0     GPIOA   4  matrix-keypad
 21:          0      INTC  21  13020000.dma
 29:          0     GPIOA   5  matrix-keypad
 30:          0      INTC  30  ingenic-drm
 31:          0     GPIOA   6  matrix-keypad
 32:          0     GPIOA   7  matrix-keypad
 33:          0     GPIOC   0  10021000.mmc cd
 34:          0     GPIOA  16  Touchpad Left
 35:          0     GPIOA  13  Touchpad Right
ERR:          0
           CPU0       
  2:      26964      MIPS   2  SoC intc cascade interrupt
  8:       9278       TCU   0  TCU0
  9:        413      INTC   1  10042000.i2c
 10:       1676      INTC   9  ttyS0
 14:       8663      INTC  14  10021000.mmc
 15:       7355      INTC  13  ohci_hcd:usb1
 16:          0     GPIOA   0  matrix-keypad
 17:          0     GPIOA   1  matrix-keypad
 18:          0     GPIOA   2  matrix-keypad
 19:          0     GPIOA   3  matrix-keypad
 20:          0     GPIOA   4  matrix-keypad
 21:          0      INTC  21  13020000.dma
 29:          0     GPIOA   5  matrix-keypad
 30:          0      INTC  30  ingenic-drm
 31:          0     GPIOA   6  matrix-keypad
 32:          0     GPIOA   7  matrix-keypad
 33:          0     GPIOC   0  10021000.mmc cd
 34:          0     GPIOA  16  Touchpad Left
 35:          0     GPIOA  13  Touchpad Right
ERR:          0
root at letux:~# 

exactly 1001 TCU0 interrupts, some for ttyS0 as expected
and 1200 USB interrupts.

All that is not really fast.

So we should IMHO understand which version of sched_clock()
is used and which registers it is reading.

kernel/time/sched_clock.o exists so I assume that it uses
this version which calls some read_sched_clock function
pointer.

But what is the function behind the read pointer?

I think this needs some more printk - but printk is
not yet available before the really early stage setup
is done.

BR,
Nikolaus