Add framebuffer and LCD panel support to device tree

[hansemro]

Resources:

• https://github.com/hansemro/kernel_omap_otter-common/blob/p-android-omap-3.4/arch/arm/mach-omap2/board-4430kc1-tablet.c
• https://github.com/hansemro/kf_u-boot/blob/p-ti-u-boot-2014.01/board/ti/omap4_kc1/kc1_panel.c
• https://github.com/hansemro/kernel_omap_otter-common/blob/p-android-omap-3.4/arch/arm/plat-omap/android-display.c
• https://wiki.postmarketos.org/wiki/Mainlining_FAQ#Display_panel
• https://wiki.postmarketos.org/wiki/SDM845_Mainlining#Creating_a_framebuffer
• OMAP4430 Reference Manual: https://www.ti.com/lit/ug/swpu231ap/swpu231ap.pdf
• https://www.kernel.org/doc/html/latest/arm/omap/dss.html
• https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/clock/clock-bindings.txt#L172-L186

Device tree resources:

• Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
• Documentation/devicetree/bindings/display/panel/panel-simple.yaml
• Documentation/devicetree/bindings/display/panel/panel-common.yaml

Hardware details:

• Framebuffer address: 0x9fec4000 (reported by U-Boot)
• LCD Panel: Hydis HV070WS1-105
  • 1024x600
  • 32 bits/pixel (A8R8B8G8); 24 bits/pixel (R8B8G8)
  • GPTimer10 PWM backlight
  • GPIO 37: switch to LVDS mode (OMAP_RGB_SHTDOWN)
  • GPIO 47 : Enable 3.3V rail (OMAP_3V_ENABLE)
  • GPIO 45: LCD_PWR_ON

Notes:

• Display Subsystem (DSS): responsible for displaying frame to LCD2 channel by MIPI DPI 1.0

DSS configuration (from 3.4.48):

framebuffers -- overlays -- managers -- displays
FB0 --- GFX --\    LCD ---- (none)
        VID1   \   TV ----- (none)
        VID2    \- LCD2 --- LCD2
        VID3

Timings (pixclock in kHz,xres/hfp/hbp/hsw,yres/vfp/vbp/vsw): 51200,1024/160/150/10,600/12/20/3

dpll4_ck (?) = 1536000000 Hz
DSS_FCLK = (dpll4_ck / 9) = 170666666 Hz
DSS_CLK = DSS_FCLK = 170666666 Hz (?)
PLL2_CLK1 = 153600000 Hz
DISPC_FCLK = PLL2_CLK1 = 153600000 Hz
LCD2_CLK (DSI2 functional clock) = PLL2_CLK1 = 153600000 Hz
LCD2 (lck div) = DISPC_DIVISOR2[23:16] = 1
PCD2 (pck div) = DISPC_DIVISOR2[7:0] = 3
LC2_PCLK  = (LCD2_CLK  / LCD2) / PCD2 = 51200000 Hz

[hansemro]

Reference:

• Documentation/devicetree/bindings/display/simple-framebuffer.yaml

arch/arm/boot/dts/omap4-kc1.dts:

/ {
	...
	reserved-memory {
		#address-cells = <1>;
		#size-cells = <1>;
		ranges;

		framebuffer_region@9fec4000 {
			no-map;
			reg = <0x9fec4000 (600 * 1024 * 4)>;
		};
	};

	chosen {
		#address-cells = <1>;
		#size-cells = <1>;
		ranges;

		framebuffer0@9fec4000 {
			compatible = "simple-framebuffer";
			reg = <0x9fec4000 (600 * 1024 * 4)>;
			width = <600>;
			height = <1024>;
			stride = <(600 * 4)>;
			format = "r5g6b5";
			status = "okay";
		};
	};
	...
};

Kernel log:

[    0.842529] simple-framebuffer 9fec4000.framebuffer0: framebuffer at 0x9fec4000, 0x258000 bytes, mapped to 0x(ptrval)
[    0.842590] simple-framebuffer 9fec4000.framebuffer0: format=r5g6b5, mode=600x1024x16, linelength=2400
[    0.850769] Console: switching to colour frame buffer device 75x64
[    0.855682] simple-framebuffer 9fec4000.framebuffer0: fb0: simplefb registered!

Before the login prompt, the kernel seems to hang.

[hansemro]

Adding the following lines to enable dss (which is disabled by default) solved the hanging issue:

&dss {
	status = "okay";
};

However, there is still no backlight available.

[hansemro]

Never mind, the device still hangs before the login prompt can be reached.

[hansemro]

Setting framebuffer address to 0x9e600000 seems to create a framebuffer device without halting the system. However, I can't be certain about the address.

[hansemro]

amazon-otter:~# cat /sys/class/graphics/fb0/phys_addr 
9e800000
amazon-otter:~# cat /sys/class/graphics/fb0/size
8388608
amazon-otter:~# cat /sys/class/graphics/fb0/virtual_size 
1024,600
amazon-otter:~# cat /sys/class/graphics/fb0/bits_per_pixel 
32
amazon-otter:~# cat /sys/class/graphics/fb0/modes
U:1024x600p-59
amazon-otter:~# cat /sys/class/graphics/fb1/phys_addr 
9f000000
amazon-otter:~# cat /sys/class/graphics/fb1/size
4915200
amazon-otter:~# cat /sys/class/graphics/fb1/virtual_size
1024,600
amazon-otter:~# cat /sys/class/graphics/fb1/bits_per_pixel 
32
amazon-otter:~# cat /sys/class/graphics/fb1/modes
U:1024x600p-59
amazon-otter:~# uname -a
Linux amazon-otter 3.4.48+ #24 SMP PREEMPT Tue Mar 2 01:53:11 PST 2021 armv7l GNU/Linux

[hansemro]

For a brief moment, the screen was yellow when using the following device tree. However, the tablet quickly proceeds to halt. Either way, I think this cements that the framebuffer address was correctly identified by U-Boot.

/ {
	...
	reserved-memory {
		#address-cells = <1>;
		#size-cells = <1>;
		ranges;

		framebuffer_region@9fec4000 {
			no-map;
			reg = <0x9fec4000 (1024 * 600 * 4)>;
		};
	};

	chosen {
		#address-cells = <1>;
		#size-cells = <1>;
		ranges;

		stdout-path = "serial2";

		framebuffer0@9fec4000 {
			compatible = "simple-framebuffer";
			reg = <0x9fec4000 (1024 * 600 * 4)>;
			width = <1024>;
			height = <600>;
			stride = <(1024 * 4)>;
			format = "a8b8g8r8";
			status = "okay";
		};
	};
	...
};
...
&dss {
	status = "disabled";
	dispc@0  {
		status = "disabled";
	};
};

&dsi1 {
	status = "disabled";
};

&dsi2 {
	status = "disabled";
};

Interestingly, I had to use earlycon to show kernel messages through UART serial console.

[hansemro]

Leaving the framebuffer address at 0x9fec4000 and reserving from 9fec0000 onwards, the penguins show up for less than a second before the lcd backlight goes off and hangs.

[mj-sakellaropoulos]

I can confirm that with the same framebuffer entry, I get the same result.
There is variability in the following:

• Presence of penguins
• Image staying on screen indefinitely
• Reboot after black screen

Constant: Foreground color always yellow.

This is happening because u-boot has already configured the display subsystem, but somewhere in the kernel initialization some settings are being changed thus being incompatible (I think???).

Right now I'm trying to port the DPI pinmux configuration from uBoot and configure DSS to use DPI LCD2
https://github.com/hansemro/kf_u-boot/blob/p-ti-u-boot-2014.01/board/ti/omap4_kc1/kc1_mux_data.h
https://www.kernel.org/doc/Documentation/arm/OMAP/DSS
https://elixir.bootlin.com/linux/v5.10.31/source/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt
Note: panel-dpi and similar bindings were removed sometime after kernel 4.x

Edit: DPI pinout is same as pandaboard but instead of going to an encoder it goes straight to the panel (?)

dss_dpi_pins: pinmux_dss_dpi_pins {
pinctrl-single,pins = <
	OMAP4_IOPAD(0x162, PIN_OUTPUT | MUX_MODE5)	/* dispc2_data23 */
	OMAP4_IOPAD(0x164, PIN_OUTPUT | MUX_MODE5) 	/* dispc2_data22 */
	OMAP4_IOPAD(0x166, PIN_OUTPUT | MUX_MODE5)	/* dispc2_data21 */
	OMAP4_IOPAD(0x168, PIN_OUTPUT | MUX_MODE5)	/* dispc2_data20 */
	OMAP4_IOPAD(0x16a, PIN_OUTPUT | MUX_MODE5)	/* dispc2_data19 */
	OMAP4_IOPAD(0x16c, PIN_OUTPUT | MUX_MODE5)	/* dispc2_data18 */
	OMAP4_IOPAD(0x16e, PIN_OUTPUT | MUX_MODE5)	/* dispc2_data15 */
	OMAP4_IOPAD(0x170, PIN_OUTPUT | MUX_MODE5)	/* dispc2_data14 */
	OMAP4_IOPAD(0x172, PIN_OUTPUT | MUX_MODE5)	/* dispc2_data13 */
	OMAP4_IOPAD(0x174, PIN_OUTPUT | MUX_MODE5)	/* dispc2_data12 */
	OMAP4_IOPAD(0x176, PIN_OUTPUT | MUX_MODE5)	/* dispc2_data11 */

	OMAP4_IOPAD(0x1b4, PIN_OUTPUT | MUX_MODE5)	/* dispc2_data10 */
	OMAP4_IOPAD(0x1b6, PIN_OUTPUT | MUX_MODE5)	/* dispc2_data9 */
	OMAP4_IOPAD(0x1b8, PIN_OUTPUT | MUX_MODE5)	/* dispc2_data16 */
	OMAP4_IOPAD(0x1ba, PIN_OUTPUT | MUX_MODE5)	/* dispc2_data17 */
	OMAP4_IOPAD(0x1bc, PIN_OUTPUT | MUX_MODE5)	/* dispc2_hsync */
	OMAP4_IOPAD(0x1be, PIN_OUTPUT | MUX_MODE5)	/* dispc2_pclk */
	OMAP4_IOPAD(0x1c0, PIN_OUTPUT | MUX_MODE5)	/* dispc2_vsync */
	OMAP4_IOPAD(0x1c2, PIN_OUTPUT | MUX_MODE5)	/* dispc2_de */
	OMAP4_IOPAD(0x1c4, PIN_OUTPUT | MUX_MODE5)	/* dispc2_data8 */
	OMAP4_IOPAD(0x1c6, PIN_OUTPUT | MUX_MODE5)	/* dispc2_data7 */
	OMAP4_IOPAD(0x1c8, PIN_OUTPUT | MUX_MODE5)	/* dispc2_data6 */
	OMAP4_IOPAD(0x1ca, PIN_OUTPUT | MUX_MODE5)	/* dispc2_data5 */
	OMAP4_IOPAD(0x1cc, PIN_OUTPUT | MUX_MODE5)	/* dispc2_data4 */
	OMAP4_IOPAD(0x1ce, PIN_OUTPUT | MUX_MODE5)	/* dispc2_data3 */

	OMAP4_IOPAD(0x1d0, PIN_OUTPUT | MUX_MODE5)	/* dispc2_data2 */
	OMAP4_IOPAD(0x1d2, PIN_OUTPUT | MUX_MODE5)	/* dispc2_data1 */
	OMAP4_IOPAD(0x1d4, PIN_OUTPUT | MUX_MODE5)	/* dispc2_data0 */
>;
};

[mj-sakellaropoulos]

For simple-framebuffer, I think something similar to drebrez/linux@c2fa556 needs to be done. DSS initializing will overwrite the config from u-boot, breaking the framebuffer (?)
However, the relevant portions have been refactored/renamed/moved somewhere else in mainline - still tracking it down

Edit: There are multiple reports of the yellow/orange screen with OMAP processors. Default DSS color ?
I have compiled linux without DSS, omapdrm or omapfb and still get the yellow screen.

[hansemro]

FWIW, I've noticed that when the kernel starts handling pin configuration (pinctrl), the screen goes off.