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

[H. Nikolaus Schaller]

Hi Paul,

> Am 12.01.2021 um 15:54 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> 
>> Am 12.01.2021 um 15:17 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> 
>> I could pinpoint this to drm_mode_legacy_fb_format()
>> 
>> https://elixir.bootlin.com/linux/v5.11-rc3/source/drivers/gpu/drm/drm_fourcc.c#L46
>> 
>> There is no case for bpp=32 and depth=16.
>> 
>> I just want to try to add a case 16: fmt = DRM_FORMAT_RGB565; and let's see...
>> 
> 
> Yes, that makes it work - except the vblank timeouts which we know have a different reason.
> 
> BTW: CGU_REG_CFCR2 and CFCR.PFR still differ from 2.6.24-Kernel.
> 
> 2.6.24:
> 0x10000000 0d523220 CGU_REG_CFCR
> 0x10000060 0000000b CGU_REG_CFCR2
> 
> 5.11-rc3:
> 0x10000000 0d522220 CGU_REG_CFCR
> 0x10000060 0000000c CGU_REG_CFCR2
> 
> I.e. LFR=3 vs. LFR=2 - so we may have the LCD clock running at 50% higher speed (maybe exceeding the 150 MHz limit?)
> And PXFR=11 vs. PXFR=12 - this is a small deviation of less than 10%.

Here is what I get printed inside ingenic_drm_bind(() after the devm_get_clk()

[    0.317768] ingenic_drm_bind: lcd_clk rate=111820800	- 112 MHz is ok
[    0.323005] ingenic_drm_bind: pix_clk rate=335462400 - 335 MHz sounds far too fast?

There is code to clk_set_rate with a comment that the pix_clk is running at 3x lcd_clk. Which it already is.
So a second printk does not show a change:

[    0.340504] ingenic_drm_bind: lcd_clk rate=111820800
[    0.328357] ingenic_drm_bind: pix_clk rate=335462400

...

[    0.358530] ingenic_drm_bind: lcd_clk rate=111820800
[    0.363762] ingenic_drm_bind: pix_clk rate=335462400

Ah, I found a second clk_set_rate which makes very reasonable 25.8 MHz:

[    0.367946] ingenic_drm_crtc_atomic_flush: pix_clk rate=25804800

In total it appears as if we do not have to care about the pix_clk rate in DT, just the lcd_clk.

> But before looking at this I now want to find out why the DMA descriptors are not properly set up...

Hm. Maybe we overwrite them because the code for the jz4780 extended descriptors is applied unconditionally in the Letux tree?

> And why there are no vblank interrupts. Maybe this are just two symptoms of the same reason.

Unfortunately I haven't found a reason yet. The write-only LCDCTRL.ENA bit seems to be stuck at 1:

root at letux:~# devmem2 0x13050030
/dev/mem opened.
Memory mapped at address 0x77ece000.
Value at address 0x13050030 (0x77ece030): 0x2400200C
root at letux:~# 

Hm. A reason could indeed be that the lcd_clk is running too fast and the LCDC engine gets stuck.

Or the LCDC enable process is different from what we think. There is an indication for that theory.
There is no vertical scanning until I write some random value to the descriptor base address...
Then, scanning starts and I can reset ENA or set DIS to get it stopped. Or restarted. The QD and LDD
bits follow. But no interrupts occur.

BTW: it seems to be a bug in the manual of jt4730 AND jz4740 that the ENA bit is write only. I can
read back its state after I got video running. Being able to write/read 0/1 is different from the
"Reserved" bits in that register.

There isn't missing much, but we are not yet done... Just one puzzle piece doesn't want to fall in
its place...

BR,
Nikolaus