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

["H. Nikolaus Schaller" <hns@goldelico.com>]

Hi Paul,

> Am 26.05.2020 um 01:03 schrieb Paul Boddie <paul@boddie.org.uk>:
> 
> On Friday 22. May 2020 21.16.10 Paul Boddie wrote:
>> On Friday 22. May 2020 14.26.15 Paul Cercueil wrote:
>>> Hi Paul,
>>> 
>>> I think the ingenic-drm driver is fine, even though the old 3.8 kernel
>>> worked differently, the IP is backwards-compatible so it should work no
>>> problem. I think the problem is somewhere in the Synopsis HDMI code or
>>> the glue code. Because the LCDC does seem to send data, which is not
>>> encoded properly by the HDMI chip.
>> 
>> There was one interesting insight related to vertical blank interrupts,
>> where it would appear that the end-of-frame condition does not occur, with
>> this failure then obstructing driver initialisation. I aim to look into
>> that further.
> 
> Some further experiments indicate that interrupt generation is indeed a 
> problem...
> 
> [L4Re experimentation]
> 
>> So far, I have managed to reproduce EDID retrieval using the HDMI
>> peripheral's own I2C support, and I plan to reproduce the HDMI peripheral
>> initialisation itself. However, it is perhaps more interesting to get the
>> LCD controller working first and potentially delivering end-of-frame
>> interrupts: this might help me understand whether this problem is a serious
>> obstacle or not.
> 
> First of all, I managed to get the HDMI connector hotplug detection working. 
> This was a relatively simple matter of setting the appropriate flags, binding 
> to an interrupt and then waiting for one to arrive. Consequently, booting 
> without the connector inserted means that my program is halted until the 
> interrupt arrives upon insertion; then, the EDID is read, which seems to work 
> reliably.

Well, with Linux my hack to set dev->mode_config.poll_enabled = true;
in drm_probe_helper.c seems to make it works in all cases without halting.

And what I observed is that interrupts are generated and arriving. They are
just not properly delivered because dev->mode_config.poll_enabled = false
has some wrong side-effect.

So I think there must be a simpler solution (for Linux).

> 
> However, I then found that the LCD controller could not be activated.

In my tests the code to setup the LCDC was never called so I could never
debug anything there.

I still have to digest the mail "DRM interaction problems on Ingenic CI20 / jz4780 with dw-hdmi and ingenic-drm"
from Paul.

> The 
> solution to this involves the TVE clock on the JZ4780 which appears to be 
> necessary in addition to the LCD clock. Ingenic documentation being what it 
> is, I suspect that the LCD clock in the block diagram is really the pixel 
> clock(s), with the TVE clock not even appearing in the diagram. The 3.18 
> kernel's device tree for the JZ4780 plus the CGU code provide the necessary 
> hints, without any explanation, of course.
> 
> With the LCD controller now willing to retain values stored in its registers, 
> I have been attempting to set up descriptors and do the usual general 
> configuration exercise that works on the JZ4720 and JZ4730. However, I have 
> never enabled interrupts on those devices, so I don't know what I need to do 
> other than to set the appropriate control and command (descriptor) flags. 
> Doing so doesn't manage to generate any interrupts, though.
> 
> The 3.18 kernel driver sets up the "new" 8-word descriptor and other new 
> things. Initially, I ignored these things, but then I thought that they might 
> actually be mandatory. Still, introducing practically the same details as seen 
> in the 3.18 driver seems to have no effect. So, I imagine I am missing 
> something pretty obvious: it took me a while to realise that I wasn't even 
> enabling the LCD controller, after all.
> 
> One thing I would point out is that the operation of the JZ4780 is not exactly 
> the same as earlier products. For example, various configuration register bits 
> related to pixel depths are now read-only.

And what I observed is that there are additional registers compared to a
JZ4740 LCDC. My assumption would be that leaving them 0x00 would be ok.

> Presumably, the idea is to set the 
> pixel depth in the "new" descriptor fields instead, enabling some kind of 
> mixing of different kinds of pixel data. I also wonder how well supported some 
> of the older functions are in the newer hardware.
> 
> Anyway, I'm rather stuck with this at the moment. I don't know whether I 
> should be reproducing the HDMI initialisation in my test environment under the 
> assumption that the LCD controller isn't sending data without some kind of 
> output path, or whether I should fake up some other output path (maybe a 
> serial LCD) by setting GPIO alternate pin functions. But it turns out not to 
> be entirely trivial to just have the LCD controller do its own thing and 
> generate these interrupts all by itself.
> 
> But again, I may well be overlooking an obvious mistake of my own.
> 
> Paul

BR,
Nikolaus