LVDS screen on Cubieboard 2 (Allwinner A20) via DRM/KMS

[Andrey Lebedev]

Hello,

We at https://openvario.org/ are trying to upgrade our device from legacy linux-3.4 with proprietary mali drivers to modern linux with DRM/KMS-based graphics. The device we are building is based on Cubieboard 2 with Allwinner A20 (sun7i) SoC. It has a LCD screen connected via LVDS interface. 

We have a problem making this screen running under sun4i-drm display pipeline.

We are building an SD image using Yocto-based build system, that builds u-boot and linux kernel-5.2-rc2. Under current setup (which I will describe below), device is booted by u-boot, that successfully initializes the LCD and outputs a splash image on it (that's how I know LCD itself is connected correctly and works). When u-boot passes control to the kernel, that splash image slowly fades into all-white and the screen stays bright-white until device is turned off. I have full access to the machine via serial (ttyS0) interface.

U-boot is compiled with these config options (among others):

CONFIG_ARCH_SUNXI=y

CONFIG_MACH_SUN7I=y

CONFIG_VIDEO_LCD_MODE="x:640,y:480,depth:18,pclk_khz:25000,hs:1,vs:1,le:157,ri:2,up:42,lo:2,sync:3,vmode:0"

CONFIG_VIDEO_LCD_PANEL_LVDS=y

Kernel is configured to compile these drm-related modules (among others):

drm, panel_lvds, lima, sun4i_drm, gpu_sched, sun4i_drm_hdmi, sun4i_backend, sun4i_tcon, sun4i_frontend, drm_kms_helper. 

They all load automatically during boot and together with lima module produce /dev/dri/card0 and /dev/dri/card1 devices. I have created the device tree for the kernel with "panel-lvds" connected directly to tcon0, port 1, endpoint 0. I have also provided additional reset line, as per sun4i-drm.txt doc (see [1]). There is a pipeline for HDMI is set up in DT too, but I'm omitting it for brevity.

When kernel loads, I see sun4i-drm modules initialize without apparent errors (see [2]).

Since this set up didn't work out-of-the-box, I started to dig deeper and added more trace logging to parts of drivers/gpu/drm/sun4i/sun4i_tcon.c that deal with LVDS. It turned out that all LVDS initialization was basically skipped, because current  sun4i_tcon_quirks object (sun7i_a20_quirks in my case) did not have "supports_lvds" property (compare to sun8i_a83t_lcd_quirks). My naive attempt to simply add that property didn't result to LCD working (no notable changes in panel' behavior), however my tracing output indicate that sun4i_lvds_init() is called before "sun4i-drm display-engine: bound 1c0c000.lcd-controller" message. sun4i_tcon_lvds_set_status() function is called too (with enabled=true), just after "fbcon: Taking over console" message. Effectively what you see in [2] is a log after I introduced sun7i_a20_quirks.supports_lvds.

Do you see anything I missed trying to make LCD work? Is it expected to work at all with current kernel? If not, what is missing? Can I provide any additional info? 

I (and all Openvario users) would really appreciate any help making the LCD to run!

[1] Device tree excerpt:

    panel {

        compatible = "openvario,lvds57", "panel-lvds";

        width-mm = <261>;

        height-mm = <163>;

        data-mapping = "jeida-18";

        panel-timing {

            /* 640x480 @60Hz */

            clock-frequency = <25000000>;

            hactive = <640>;

            vactive = <480>;

            hsync-len = <1>;

            hfront-porch = <2>;

            hback-porch = <157>;

            vsync-len = <1>;

            vfront-porch = <2>;

            vback-porch = <42>;

        };

        port {

            lvds_panel_in: endpoint {

                remote-endpoint = <&display_out_rgb>;

            };

        };

    };

&tcon0 {

    resets = <&ccu RST_TCON0>, <&ccu RST_LVDS>;

    reset-names = "lcd", "lvds";

    ports {

        tcon0_out: port@1 {

            display_out_rgb: endpoint@0 {

                reg = <0>;

                remote-endpoint = <&lvds_panel_in>;

                allwinner,tcon-channel = <0>;

            };

        };

    };

};

[2] dmesg report excerpt

...

[    5.017228] lima 1c40000.gpu: bus rate = 300000000

[    5.022129] lima 1c40000.gpu: mod rate = 384000000

[    5.090519] lima 1c40000.gpu: gp - mali400 version major 1 minor 1

[    5.096905] lima 1c40000.gpu: pp0 - mali400 version major 1 minor 1

[    5.103562] lima 1c40000.gpu: pp1 - mali400 version major 1 minor 1

[    5.109985] lima 1c40000.gpu: l2 cache 64K, 4-way, 64byte cache line, 64bit external bus

[    5.122207] sun4i-drm display-engine: bound 1e00000.display-frontend (ops sun4i_frontend_driver_exit [sun4i_frontend])

[    5.133246] sun4i-drm display-engine: bound 1e20000.display-frontend (ops sun4i_frontend_driver_exit [sun4i_frontend])

[    5.144504] sun4i-drm display-engine: bound 1e60000.display-backend (ops sun4i_backend_ops [sun4i_backend])

[    5.154749] sun4i-drm display-engine: bound 1e40000.display-backend (ops sun4i_backend_ops [sun4i_backend])

[    5.206936] [drm] Initialized lima 1.0.0 20190217 for 1c40000.gpu on minor 0

[    5.211187] sun4i-drm display-engine: bound 1c0c000.lcd-controller (ops sun4i_tcon_platform_driver_exit [sun4i_tcon])

[    5.251228] sun4i-tcon 1c0d000.lcd-controller: Missing LVDS properties, Please upgrade your DT

[    5.259931] sun4i-tcon 1c0d000.lcd-controller: LVDS output disabled

[    5.282987] sun4i-drm display-engine: No panel or bridge found... RGB output disabled

[    5.290858] sun4i-drm display-engine: bound 1c0d000.lcd-controller (ops sun4i_tcon_platform_driver_exit [sun4i_tcon])

[    5.354508] axp20x-i2c 0-0034: AXP20X driver loaded

[    5.365705] sun4i-drm display-engine: bound 1c16000.hdmi (ops sun4i_hdmi_driver_exit [sun4i_drm_hdmi])

...

[   11.486816] fbcon: Taking over console

[   11.513746] Console: switching to colour frame buffer device 80x30

[Priit Laes]

On Thu, Feb 06, 2020 at 12:38:49PM -0800, Andrey Lebedev wrote:
> Hello,
>
> We at https://openvario.org/ are trying to upgrade our device from legacy
> linux-3.4 with proprietary mali drivers to modern linux with DRM/KMS-based
> graphics. The device we are building is based on Cubieboard 2 with
> Allwinner A20 (sun7i) SoC. It has a LCD screen connected via LVDS
> interface.
>
> We have a problem making this screen running under sun4i-drm display
> pipeline.

LVDS support for A20 is currently unimplemented.

I have a very old WIP branch that needs to be updated against current
kernel here: https://github.com/plaes/linux/commits/sun4i-lvds-wip

> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/f1edbfc8-6aca-4b6e-b0a0-e0f7e86723b7%40googlegroups.com.

[Andrey Lebedev]

> On Thu, Feb 06, 2020 at 12:38:49PM -0800, Andrey Lebedev wrote:

>> Hello,
>>
>> We at https://openvario.org/ are trying to upgrade our device from legacy
>> linux-3.4 with proprietary mali drivers to modern linux with DRM/KMS-based
>> graphics. The device we are building is based on Cubieboard 2 with
>> Allwinner A20 (sun7i) SoC. It has a LCD screen connected via LVDS
>> interface.
>>
>> We have a problem making this screen running under sun4i-drm display
>> pipeline.
>

> LVDS support for A20 is currently unimplemented.

I have finally made it work. The screen initializes when kernel boots
and I see linux console and can even run kmscube (suggesting that
everything works under DRM/KMS infrastructure). I had to implement a
specific LVDS initialization routine in tcon driver. I ported it from
u-boot.

I would like to submit my changes to the upstream kernel. I have a patch
against Linus' 5.5 release (attached). How would you suggest me to
proceed with this?


--
Andrey Lebedev aka -.- . -.. -.. . .-.
Software engineer
Homepage: http://lebedev.lt/

[Andrey Lebedev]

On Friday, February 7, 2020 at 9:31:49 AM UTC+2, plaes wrote:

LVDS support for A20 is currently unimplemented. 

I have a very old WIP branch that needs to be updated against current 
kernel here: https://github.com/plaes/linux/commits/sun4i-lvds-wip 

I'm willing to revive this branch (out of desperation), can you give me some guidance though?

First and foremost, did that actually work? What was missing?

Current kernel has /some/ LVDS support, which looks similar to your code, e.g. sun4i_lvds.c [1] or in sun4i_tcon.c [2]. Do you think it can be used / adapted to drive LVDS panel on A20? What that might involve?

Your device tree [3] actually defines pins for LVDS, something I missed in mine. Do you think the syntax you used is applicable to current kernel? Could it be the reason my set up didn't work?

[1] https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/sun4i/sun4i_lvds.c 

[2] https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/sun4i/sun4i_tcon.c#L117

[3] https://github.com/plaes/linux/commit/c2a3c76a52eb26e724a6ae001bc22f643a54b232#diff-8565831dddaab4dc7bfb1751a4fdad70R208-R229

[Andrey Lebedev]

On 2/7/20 8:05 PM, Andrey Lebedev wrote:
> On Friday, February 7, 2020 at 9:31:49 AM UTC+2, plaes wrote:
>
> LVDS support for A20 is currently unimplemented.
>
> I have a very old WIP branch that needs to be updated against current
> kernel here: https://github.com/plaes/linux/commits/sun4i-lvds-wip
> <https://github.com/plaes/linux/commits/sun4i-lvds-wip>
>
>
> I'm willing to revive this branch (out of desperation), can you give me
> some guidance though?

Emails didn't arrive in the right order, so please disregard this. See
my message with the patch for the proposed solution to the problem.