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

[H. Nikolaus Schaller]

> Am 27.12.2020 um 22:32 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> 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. :-)

Well, here not even vendor code hepls. The vendor code doesn't answer how to
make the driver interrupt driven and we had to hack it already for the 2.6
kernel without knowing if it was correct then.

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

I had looked into them (currently can't test because I have injected code
into the i2c driver) but there was nothing unusual. Just that USB had some
interrupts running and counting but I think it may be the WiFi module.

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

Yes, that would be a good idea!

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

Ok, so the NanoNote is not really a help here.

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

I had also looked a little for it but also not found anything useful.

So we have to spend a little more time in reverse engineering the behaviour
of the SR flags and their relation to interrupts.

Hm. Is it possible to read the interrupt request register without triggering
an interrupt? Then I can easily try to deduce from examples which bits are
or-ed together to form the I2C-IRQ... Should be ICSR at 0x10001000, right?
And there BIT(1). Even if interrupts are disabled by the kernel. I just have
to enable IEN in the I2CCR. 

BR,
Nikolaus