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

[H. Nikolaus Schaller]

> Am 13.01.2021 um 16:50 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> On Wednesday, 13 January 2021 14:46:35 CET H. Nikolaus Schaller wrote:
>> 
>> Am 12.01.2021 um 22:32 schrieb Paul Boddie <paul at boddie.org.uk>:
>>> 
>>> I have attached the driver with my own modifications for comparison with
>>> previous versions. I cannot promise that it will work, but you should be
>>> able to see what I have been trying to do.
>> 
>> Yes, the idea is good!
>> 
>> What I have done is to take the latest letux-5.11-rc3 and replace the i2c
>> driver with yours (it seems to be based on an older version of what I had
>> tried last, but should not matter since interfaces are the same).
>> 
>> Unfortunately the only effect I can see is the kernel being stuck after
>> a timeout:
> 
> I actually forgot to include some code that tests the bus conditions after an 
> address is sent. So, a slightly updated version of the code is included.
> 
> What I left out was a test for the mysterious STX flag which needs to be clear 
> before an attempt is made to read data, at least in my experience, and one of 
> the ACKF and DRF flags must also be set.
> 
> [...]
> 
>> What I assume from earlier experiments is that not processing an IRQ doesn't
>> work in this case. This makes the interrupt handler being called
>> immediately again.
> 
> The IRQ should still be handled since all returning from jz4730_i2c_irq 
> appears to involve IRQ_HANDLED, but that might not stop the IRQ from occurring 
> again immediately, I suppose.
> 
>> AFAIR, the kernel should throttle IRQs that are not processed too often
>> but the broken sched-timer may stop this function.
>> 
>> So unfortunately that does not work.
>> 
>> I think I'll try to make the LCDC work first and then I can focus again on
>> the I2C driver. Debugging both in parallel doesn't work well...
> 
> Agreed. The I2C functionality isn't particularly important compared to the 
> LCD.

Seems as if I have some breaktrough!!!

I managed to play with demmem2 to suddenly make the boot log visible on the LCD.

It seems as if I have to provide the second DMA descriptor (also) as the first.
Maybe the first descriptor is broken.

I also had provided in that experiment my other devmem2 commands which change
the pixel clock but next I can try what happens if I change it back.

The dev/tty isn't working because the DRM system isn't aware that I now
have enabled the LCDC...

This raises the question how the code wants to handle the f0 and f1 descriptors.
Especially it appears if the f1 descriptor is good but the LCD is connected
to the DMA channel for the f0 descriptor.

A hint is that the new const struct jz_soc_info has fields for different
format tables for f0 and f1. Strangely the jz4740 defines only f1 and I
have simply copied it. Maybe that is the bug...

BR,
Nikolaus