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

[H. Nikolaus Schaller]

Hi Paul,

> Am 26.12.2020 um 16:05 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> 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.

Yes, I have seen such a note. But it may be that not the hardware is unreliable
but the drivers always were...

I had needed some guesses what to correctly do in interrupt mode (this is missing
in the documentation) but my driver seems to work well now in all "standard" cases
(send bytes, read bytes and detect NACK/non-present device - at least on write).

What I can't test are 10-bit address and write+read commands (e.g. write 5 bytes
and then switch to read - this is something the xfer can do by defining protocol
modifying flags). And I am not sure if NACK detection on read or abort by client
is handled correctly. This might need a hardware setup with connecting some
programmable i2c client (i.e. a microcontroller) to the debug connector and
injecting specific protocol responses. Nothing what I want to do is is worth
the effort.

But we need neither for the mipsbook.

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

Yes, it is attached. IMHO quite streamlined now. I think we can simplify
jz4730_i2c_xfer a little more by replacing all goto out; by a return and
removing the ret variable.

I still have to test if I can now remove the irq disable/enable hacks, but
I did no longer get messages about spurious interrupts. So it likely works
now.

BR,
Nikolaus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: i2c-jz4730.c
Type: application/octet-stream
Size: 10357 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20201226/936486da/attachment-0001.obj>
-------------- next part --------------