Bringing LVDS on A64 (VDP7) to work

[Kamps, John-Eric]

Hi all

I have an Allwinner A64 based device and I wanted to bring the LVDS Display to live.
http://linux-sunxi.org/Honeywell_VDP7

Attached is the patch for Jagan Tekis kernel from
https://github.com/amarula/linux-amarula.git
Version: 3fcf0ebf8263377172da3ad0628c67e411a58831

I added the LVDS pins to the sun50i-a64.dtsi:
lcd_lvds_pins: lcd-lvds-pins {
pins = "PD12", "PD13", "PD14", "PD15", "PD16",
"PD17", "PD18", "PD19", "PD20", "PD21";
function = "lvds0";
};

And I used the information from sun8i-a83t-tbs-a711.dts with changed values to write my own connection:
+ panel {
+ compatible = "tbs,a711-panel", "panel-lvds";
+ backlight = <&backlight>;
+ power-supply = <&reg_dc1sw>;
+
+ width-mm = <154>;
+ height-mm = <86>;
+ data-mapping = "vesa-24";
+
+/* reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>;*/ /* RST (PD24) */
+
+ panel-timing {
+ /* 1024x600 @60Hz */
+ clock-frequency = <51450000>;
+ hactive = <1024>;
+ vactive = <600>;
+ hsync-len = <8>;
+ hfront-porch = <156>;
+ hback-porch = <156>;
+ vfront-porch = <16>;
+ vback-porch = <16>;
+ vsync-len = <6>;
+// de-active = <0>;
+// hsync-active = <1>;
+// vsync-active = <1>;
+ };
+
+ port {
+ panel_input: endpoint {
+ remote-endpoint = <&tcon0_out_lcd>;
+ };
+ };
+ };
And for TCON connection
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_lvds_pins>;
+};
+
+&tcon0_out {
+ tcon0_out_lcd: endpoint@0{
+ reg = <0>;
+ remote-endpoint = <&panel_input>;
+ };

I will get a framebuffer device. The backlight is working and I can change the brightness. The panal-lvds is used and the clock looks that they will be generated in the attached bootlog.
I also added some additional debug outputs to be aware, that the functions are called. Looks also fine for me.

I checked the sunxi-lvds source file and compared the lvds register settings with the voltage levels on the pins. They are identical and looking fine for me. I checked with an Osciloscope the signals but they are statical. No changes on them. I also checked the reset line, voltages and so on, they are correct that with signal input all should work.

My current thinking is, that there are something wrong with the dts tcon connection. I checked also to use reg 1 (MIPI) and not reg 0, but then I will get no framebuffer and some dct warnings that the MIPI Display is only connected in one direction.

I'm going deeper and deeper in the dts writing and find a lot. But lvds and allwinner devices is not really documented anywhere.
Did someone has an idea what could be wrong?

My next check will be the new 5.1 kernel release.

Best regards
John-Eric

[Kamps, John-Eric]

Hi all.

With the 5.1.0 Kernel it is also not running

Can someone have a look on the dts-file? I hope it is correct from the information I could find in the bindings documentation and the other dts-files.

Has someone a hind what I can check next?

Best regards
John-Eric

[Jagan Teki]

Pipeline seems fine to me quick look, and lvds connector gets detected
in the log. I'm suspecting about pixel clock with respective lvds
divider values

Possible checks.

01. Try the bsp first, since we don't have any kind of reference documents.
02: Identify the working pixel clock rates along with dividers
03: Better get the regmap of tcon0 and other sequence for cross verification.

Jagan.

[Kamps, John-Eric]

Hi Jagan

>Possible checks.

>01. Try the bsp first, since we don't have any kind of reference documents.

OK I will compare them

>02: Identify the working pixel clock rates along with dividers

I will check the kernel log from the original device.

>03: Better get the regmap of tcon0 and other sequence for cross verification.

How can I get these values? Is there a bash command, or debugging, log output, syslog interface file?

Thanks
John-Eric

[Priit Laes]

Using busybox `devmem` applet or devmem2 utility.

If you're using Armbian/Debian just `apt install busybox`.

And sample usage of the devmem applet I used to debug hdmi issues on A20:

[snip]
#! /bin/bash
function dump {
base=$1
size=$2
for((i=0;i<$size;i=i+4)) ; do
addr=$(($base + $i))
data=$(busybox devmem $addr)
echo $(printf '%#x: %s' $addr $data)
done
}
function f {
dump $(( $1 )) $(( $2 ))
}
# XXX: These are A20 addresses and block sizes
# tcon0
f 0x01c0c000 0x1000
# ccu
f 0x01c20000 0x400
[/snip]

[Kamps, John-Eric]

Hi.

Thanks for the sample code.
I read the register (Attached file with comments) and compared them with the Allwinner User Manual V1.1

Summary Clock:
Video0 = 24MHz*99/8=297MHz
MIPI based on Video0 = 297MHz*3*2/5=356,4MHz

Then the pixel clock is 356,4MHz/7=50,914MHz
Requested is 51,45MHz
--> Sounds OK for me and is the same in the debug output:
sun4i_dclk_round_rate: ideal = 360150000, rounded = 356400000, div = 7
sun4i_dclk_round_rate: div = 7 rate = 50914285


Summary tcon0:
TCON0 Control: En, normal, sync+DE, 1E=TCON start delay ,src=DE0
TCON0 Clock: dclk, dclk1, dclk2, dclkm2 --> on; DCLK-DIV=7 --> >6 --> OK
x=1023+1, y=599+1
HT=1343+1, HBP=163+1
VT=1276, VBP=21+1
HSPW=0+1 , VSPW=0+1
HV Panal Interface: 24Bit, RGB
LVDS-Panel: Enable, normal, NS-Mode, 24Bit, debug off, lvds mode0, LVDS_CLK_SEL --> TCON_CLK, polarity normal
polarity: normal output, use DCLK0, IO2/3 = not invert, IO1/0 = invert, data normal polarity
--> It sounds strange for me, that channel 0 and 1 are inverted and the others not.
io trigger reg: RGB endian normal, IO0-3 enabled, data enabled
LVDS ANA0 is like expected and the same what the kernel will set up. Measured voltage levels are the same like configured.

One thing is strange. In LVDS-Panel Interface Register (0x084) is bit 20 TCON0_LVDS_Clk_Sel=1. And this means TCON0_CLK and not MIPI_CLK source. From my understanding the MIPI clock, which is based on the video0 clock, has the correct frequency and should be normally used, or?

I will search for them in the driver and check it.

-----Ursprüngliche Nachricht-----
Von: Priit Laes [mailto:pl...@plaes.org]
Gesendet: Dienstag, 21. Mai 2019 10:39
An: Kamps, John-Eric
Cc: ja...@amarulasolutions.com; linux...@googlegroups.com
Betreff: [External] Re: [linux-sunxi] Re: Bringing LVDS on A64 (VDP7) to work

[Kamps, John-Eric]

Hi.

I checked a lot the last days and compared the register data with the datasheets. I compared also to the A83T datasheet which has these tablet LVDS display and the tcon should also work like A64. I compared the bsp source code with the mainline one. Here a summary.

I compared pinctrl to the original Bootloader one:
* Data identically. All needed pins as lvds0

I compared ccu to the original Bootloader one:
* PLL-Video0: only change is that the Lock Bit is not set in Bootloader
* PLL-Mipi: only change is that the Lock Bit is not set in Bootloader
* BUS-Gating: TCON0 -> On, DE -> On, MIPIDSI -> off
I added MIPIDSI to the ccu dts-section to enable them. Which works but with no effect. Manually enabling with Busybox has no effect.
Does The Bus-Gate Register will enable only the Bus clock to the module or also the other clocks like PLL-Video0 and PLL-MIPI?

I compared tcon0 register:
* Resolution is correct, backporch, frontporch are differ in 1-2 pixel. This should be ok for my understanding.
* Interrupts are enabled like in source code (TCON0_Vb_Int_En and TCON0_Tri_Finish_Int_En)
* FRM is off but the seed and table registers are filled with data. Should be not a problem
* TCON-Control register: TCON-Start delay differs a bit
* Data Clock Register: Clock is Enabled. Only 8-Hex and not F-Hex is used. A change in the kernel to F-Hex has no effect. A manual write with Busybox has no effect. Both shall work for my understanding.
* LVDS-Panel-Interface-Register: Bootloader is using TCON0 clock and not MIPI PLL. The pin polarity is reverse. A change with busybox in this register has no effect. For me the mainline is correct to the datasheet.
* Safe Period Register: Is used in Bootloader, not in Mainline driver
* LVDS Ana0 Register: identically

I see nothing that looks wrong. But I have no signal change on the pins which I don't understand. With X11VNC I can send the framebuffer to my desktop system which is working. Changes with fb-test tool are transmitted. So the framebuffer with memory is ok.

I could understand that garbage is on the display because of wrong settings. But I have statical pins. Clocks are OK and identically in the register. The tcon is configured and LVDS is for my understanding only enabled with the LVDS-Panel-Interface and the Ana0 register.
It looks that there is no clock, but they are enabled.
Or the interrupt for the data is not generated and because of this is no transmission?

I have also checked the LVDS code from the BSP which does nearly the same for LVDS.

I would test if I can get the parallel TCON Interface to live to see that the tcon0 will send something. If this is working then LVDS is only a change in the output mode.

Any other ideas about why I have only statical signals? Could be the tcon to mixer interface wrong that they will get no data?

John-Eric

[Maxime Ripard]

Do you have a setup that works with the BSP? Usually in cases like
this I would dump the registers of the whole display engine and the
TCON, and compare them to see what's going on.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Kamps, John-Eric]

>Do you have a setup that works with the BSP? Usually in cases like this I would dump the >registers of the whole display engine and the TCON, and compare them to see what's going on.

Not yet tested, because the new uboot can't load the original BSP Kernel. And I was thinking that it will be not so difficult. :-(

The original System is an Android one.
Can I change the uboot kernel bootargs and use the original Android kernel with changed Linux rootfs and boot them? Is that possible?
If yes I would give this a try to check that I will get a running BSP System to dump the register.

I dumped the tcon and ccu section from the original uboot which has a boot splash screen on the display.
Should I also dump and compare the de (display section) as well?
Any other register that I should dump and compare?

John-Eric

[Jernej Škrabec]

Dne ponedeljek, 03. junij 2019 ob 21:09:48 CEST je Kamps, John-Eric
napisal(a):

> >Do you have a setup that works with the BSP? Usually in cases like this I
> >would dump the >registers of the whole display engine and the TCON, and
> >compare them to see what's going on.
> Not yet tested, because the new uboot can't load the original BSP Kernel.
> And I was thinking that it will be not so difficult. :-(
>
> The original System is an Android one.

Usually Android on AW devices has busybox application with devmem support.
Just use "busybox devmem <memory location>". It shows only one location at a
time, but with little scripting this can be overcome.

Best regards,
Jernej

[Maxime Ripard]

If your Android build has access to /dev/mem, I have a small test
program to do this:
http://code.bulix.org/p19scz-757910

You can compile it statically and put it into your rootfs, and then
run it. You'll want to use the -2 and -e options.