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

[Paul Boddie]

On Sunday, 27 December 2020 20:07:04 CET H. Nikolaus Schaller wrote:
> 
> Am 26.12.2020 um 22:16 schrieb Paul Boddie <paul at boddie.org.uk>:
> > 
> > I suppose that there is some uncertainty about what will cause interrupt
> > conditions. I would have to look at the manual again, but I don't think it
> > is very thorough about that.
> 
> Well, it only mentions to enable interrupts in the flow chart. But has no
> explanation and the flow-charts do not use interrupts at all. Besides
> enabling them...

Yes, it isn't the most helpful documentation ever. There's almost more benefit 
to be had from reading the vendor code. :-)

[...]

> So may either have a problem with u64 emulation or our scheduler clock
> doesn't work correctly. The latter would also explain why boot and X11 has
> these hickups.

It will need more investigation, certainly.

> >> I am not at all sure but it may have started with the latest TCU/CGU
> >> update?
> > 
> > No, it was in your earlier logs, too. I had to sort one of them to make
> > sense of it.
> 
> Yes, you are right. It is already jittering in the regs-5.10.txt. I just
> didn't notice. Anyways the time scale seems to have changed by a factor
> between 10 and 16. In regs-5.10.txt it was
> 
> [    0.178323] jz4740-mmc 10021000.mmc: Ingenic SD/MMC card driver
> registered [    0.169440] jz4740-mmc 10021000.mmc: Using PIO, 4-bit mode
> [    0.175484] reg: cpm
> [    0.177888] reg: 10000000: 0d522220
> [    0.181572] reg: 10000004: 000000f8
> [    0.185254] reg: 10000008: 00000001
> [    0.171697] reg: 1000000c: 00000000
> 
> Now it is
> 
> [    2.588107] jz4740-mmc 10021000.mmc: Ingenic SD/MMC card driver
> registered [    2.804999] jz4740-mmc 10021000.mmc: Using PIO, 4-bit mode
> [    1.840017] reg: cpm
> [    1.912256] reg: 10000000: 0d522220
> [    2.024097] reg: 10000004: 000000f8
> [    2.168697] reg: 10000008: 00000001
> [    2.281562] reg: 1000000c: 00000000
> 
> which is closer to real time.

I wonder if /proc/interrupts or whatever it is has any useful details. Every 
time the timers wrap around, there should be an interrupt, and this would 
presumably increment some counter that might be recorded in /proc/interrupts 
if nowhere else.

The factor of 16 improvement is intriguing. Initially, I thought that the 
timers were being set up using the wrong value (2, corresponding to EXCLK on 
the JZ4740 but corresponding to PCLK/16 on the JZ4730), this coming from the 
device tree.

But then I considered that I had misunderstood the relationships between the 
device tree and driver, which are rather elaborate/incoherent (as usual), and 
that since a value of 5 (EXCLK on the JZ4730) was being written into the input 
clock field, it seemed that the lookup for EXCLK was happening correctly.

But if PCLK/16 were being set up, and if PCLK were set to be EXCLK, this might 
be an explanation for the clock speed issue.

[...]

> So I am now trying to use the flow-chart in non-irq mode to print and
> analyse how the status and control register flags really are doing, i.e.
> when they are reset. What I don't know is how to check if they would
> generate an interrupt request or release it.

I haven't got into looking at this yet. I was actually getting back to 
building my other software for the Ben NanoNote, just to make sure I still 
can, and then I was going to build that software for the Minibook and to see 
if I could also debug this and other issues. Building Linux would also be 
something to try as well, obviously.

I had also considered looking at I2C support on the Ben NanoNote given that we 
know it has the same I2C peripheral as the Minibook. Unfortunately, the 
NanoNote uses the two I2C pins as GPIOs for scanning the keypad and so cannot 
be tested in this way.

This may also be a reason why no-one ever bothered to write a driver, or that 
the driver development effort skipped I2C. There were other devices with the 
JZ4740, like the Dingoo A320, and maybe they used these pins for I2C, but I 
have no real familiarity with such devices or of the development efforts that 
took place to support them.

Paul