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

[H. Nikolaus Schaller]

> Am 14.01.2021 um 11:55 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> 
>> Am 14.01.2021 um 09:55 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> 
>> And if I run my script that patches some values from the 2.6.24 kernel I now
>> get a blinking cursor :)
>> 
>> So there is only a minor diff in the setup now.
>> 
>> I need a little time to manually do all devmem2 commands of my patch script
>> to see which one makes the panel work.
>> 
> 
> root at letux:~# devmem2 0x10010040 w 0x55555550
> /dev/mem opened.
> Memory mapped at address 0x77e36000.
> Value at address 0x10010040 (0x77e36040): 0x1015550
> Written 0x55555550; readback 0x55555550
> root at letux:~# devmem2 0x10010044 w 0x556a5555
> /dev/mem opened.
> Memory mapped at address 0x77e18000.
> Value at address 0x10010044 (0x77e18044): 0x55505555
> Written 0x556A5555; readback 0x556A5555
> root at letux:~#
> 
> makes it work... I can now
> 
> 	uname -a >/dev/tty1
> 
> and it appears on screen.
> 
> So we have a problem with the pinmux function selection.

Found it. Can now boot to blinking cursor without any user-space
help. Unless I try to start X11. Maybe X11 needs too much memory
or is influenced by the schedluer timer.

The problem was that there are new macros INGENIC_PIN_GROUP() and
INGENIC_PIN_GROUP_FUNCS() in pinctrl-ingenic to optimize memory
useage. So I had updated the earlier jz4730 pinmux group tables.

And I defined one of the pinmux arrays as int[] instead of u8[].
So 3 bytes were 0x00 until the next valid function state was there.
This made the pin functions for the LCDC not properly initialized
and so there was no HSYNC/VSYNC output to the panel.

Running my devmem2 script did overwrite and the display worked.

> This means the LCDC hacks are already working and the different
> lcd and pix clocks are not that critical.

BTW, I think I have found a patch for the DMA descriptor number
which should not harm the SoC with OSD and two LCDs but still do
the right thing for jz4730 and jz4740. So this is potentially
upstreamable.

So what remains to be fixed? Only the issue with the connector
type and bus format. I think the hack should not disturb other
Letux devices so we can merge it temporarily into the Letux tree.

So the Display should work now. I will consolidate the patches
so that my printk stuff is removed... So we will have a 5.11-rc4
on Monday with working LCD.

Then we can take another look at the I2C issues and the sluggish
scheduler timer and DMA. And finally on sound and Ethernet and why
X11 is not running.

BR,
Nikolaus

commit 7f4e6eda5bc9b634900ff33ae0fa3e7a7ce832ea
Author: H. Nikolaus Schaller <hns at goldelico.com>
Date:   Thu Jan 14 17:41:00 2021 +0100

    drm/ingenic: fix assignment of DMA channels
    for SoC without OSD like jz4730 and jz4740. On those, the first DMA
    channel is for the single LCD and the second for the palette. If we
    leave the first uninitialized, the LCDC will not become enabled.
    
    Fixes: 174d8e52a60f19 ("drm/ingenic: Alloc F0 and F1 DMA descriptors at once")
    Signed-off-by: H. Nikolaus Schaller <hns at goldelico.com>

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 17e7b860f0fa3b..1321ab68a9baaf 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -606,10 +606,10 @@ printk("%s\n", __func__);
                height = state->src_h >> 16;
                cpp = state->fb->format->cpp[0];
 
-               if (priv->soc_info->has_osd && plane->type == DRM_PLANE_TYPE_OVERLAY)
-                       hwdesc = &priv->dma_hwdescs->hwdesc_f0;
-               else
+               if (priv->soc_info->has_osd && plane->type != DRM_PLANE_TYPE_OVERLAY)
                        hwdesc = &priv->dma_hwdescs->hwdesc_f1;
+               else
+                       hwdesc = &priv->dma_hwdescs->hwdesc_f0;