Re: JZ4780 LCD controller initialisation (was Re: [PATCH] clocksource: Ingenic: Add high resolution timer support for SMP.)

[Paul Boddie <paul@boddie.org.uk>]

On Wednesday 27. May 2020 01.07.41 Paul Cercueil wrote:
> 
> Don't focus too much on interrupts right now. You don't get interrupts
> because the data is not flowing. Which in turns is caused either by the
> LCDC not being correctly configured, or the HDMI not sending
> hsync/vsync signals.
> 
> For now, what seems to be the problem is that the DMA descriptors
> aren't loaded properly. Whatever I do, the debug registers
> (LCDSAx/LCDIDx/etc) are still zero here.

I checked the LCDSA0 (source address) and LCDFID0 (frame identifier) 
registers, and they get populated with what I put in the descriptor, so I am 
inclined to think that some kind of initialisation does happen. However, as 
previously noted, the LCDIID (interrupt identifier) remains zero.

What I have subsequently done is to introduce the HDMI driver functionality 
from Linux into my test environment (L4Re) to investigate the configuration 
process. Eventually, I managed to get the HDMI signal enabled, meaning that I 
can switch my monitor to the DVI input and be told what kind of picture it 
thinks it is getting (1280x1024 @ 62Hz, and although I asked for 60Hz, the 
111MHz pixel clock will probably generate something closer to 62Hz).

Where this gets interesting/infuriating is that the signal persists but there 
is no actual picture (just a black screen, but illuminated), but accompanying 
this is a "FIFO 0 under run" condition (IFU0 in LCDSTATE). Looking at the 
manual, there is no other mention of this "FIFO 0", but I did wonder whether 
it had anything to do with the OSD functionality because it seems to be the 
case that the OSD is always enabled (OSDEN is set in LCDOSDC) and cannot be 
unset just by clearing the OSDEN bit.

I thought that the "new" 8-word descriptor arrangement might be important in 
this regard. Although the manual doesn't make this explicit, it seems to be 
the case that the extra 4 words are configuring the OSD foreground planes. So, 
I enabled the populated extra words in a similar way to what the 3.18 driver 
does. But even with various other JZ4780-specific registers set up (RGB 
control, priority threshold), what actually happens is that the monitor fails 
to acknowledge a signal and switches back to its default VGA input.

I have tried a few things, such as enabling the IPU clock in the CPM unit 
(which is probably unnecessary since it is enabled by default) and enabling 
the IPU clock in the LCD controller (IPU_CLKEN in LCDOSDCTRL), but neither 
changes the situation.

I also noted a recent patch on the dri-devel list adding OSD support...

"[PATCH 09/12] gpu/drm: Ingenic: Add support for OSD mode"

What is interesting about that patch is that it attempts to enable the OSD 
foreground planes by setting F0EN and F1EN on LCDOSDC. However, these are 
marked as read-only in the JZ4780 and cannot actually be set.

So, I am currently looking for some more ideas about how to get this working. 
It is entirely possible that I have taken one too many shortcuts with the HDMI 
initialisation: I have only implemented "DVI mode" and have sought only to 
implement what is necessary for that and for RGB data. It is also likely that 
I have missed something from the LCD initialisation, but whatever it is 
escapes me at present.

Any suggestions would be appreciated at this point!

Thanks in advance,

Paul

P.S. I can easily imagine that the obstacle to getting things working in a 
modern Linux kernel is just the data format/encoding. The 3.18 driver supports 
only RGB data, which is presumably converted by the HDMI peripheral to 
whatever the preferred output actually is.