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

[Paul Boddie]

On Saturday, 26 December 2020 15:24:10 CET H. Nikolaus Schaller wrote:
> Good news:
> 
> I think I have managed to get the new i2c driver working.
> There are no more timeouts and I can read the hardware clock.
> And "poweroff" finally turns off the machine (incl. power LED)
> so that means our minipc-mcu driver is working well.
> 
> BTW: it appears as if the jz4740 doesn't have an i2c driver...
> I thought quite late about looking for it and it even turned out
> to have exactly the same register model and flowcharts.

Now that I can see both manuals, I can also see that the peripherals are very 
similar or the same.

> So we could have simply used the jz4740-i2c driver - but fortunately
> we did not do double-work because an jz4740-i2c driver doesn't seem
> to exist at least in device tree based kernels.

I think it has been said that various people found the JZ4740 I2C peripheral 
to be unreliable, so there has never been a Linux driver for that, to my 
knowledge.

> There is also an jz4780-i2c driver but that has a more elaborated
> controller with much more control registers.

Yes, this is the one we struggled with for the EDID retrieval until we 
switched to getting the HDMI peripheral to do that job.

> And one more finding: with /dev/fb0 present my rootfs now starts
> X11 and that seems to be running. It just takes a high CPU load
> and seems to block uart interrupts and the console has some
> hickups. Looking into /proc/interrupts didn't help much. i2c is silent,
> mmc interrupts are not counting up, but usb interrupts. Maybe my
> user-space is triggering something with spinlocks on the usb side.
> 
> Firstly, I will consolidate all the new patches... And then I can
> look if I can fix the LCD and keyboard.

I can't remember too many details of the driver, but it would certainly 
benefit from some review given that it was done speculatively over three years 
ago. From a commit message to the gta04-kernel repository, I see that I used 
the JZ4780 driver as the structural basis of this driver, which might explain 
a few things. Mistakes would have been made as I tried to adapt the code, 
which would explain things like the inverted test for read operations.

Thanks for debugging my code, though! If you could send the I2C driver as is, 
I might be able to see whether it can be refined further.

Paul