STM32MP1 ECO 5.0 LTDC device tree, RGB LCD not working anymore

[debugging]

Objective is to get the RGB888 LCD working with ECO 5.0 This panel worked fine with ECO 1.0

[1] Follow this, topic: https://community.st.com/t5/stm32-mpus-products/stm32mp1-ltdc-device-tree-for-rgb-display/td-p/315953.  In ECO 5.0 these DT entries seems not valid anymore. DTC warnings occurs as listed below, even though the build goes through.

[2] RGB LCDs have reset and Enable pins for LCD control,  The link above had an  DT entry for it.

 

enable-gpios = <&gpioh 15 GPIO_ACTIVE_HIGH>; // DISP
reset-gpios = <&gpioh 7 GPIO_ACTIVE_HIGH>; // RESET

 

But PH7 the reset  pin is not released at boot. using gpioset -c 7 7=1, the reset is released (backlight goes on), it seems the panel DT node is ignored or panel entries have been changed. Since CubeMX does not generate  DT panel examples and the wiki's might be outdated, it feels like a  state of limbo.

P.S: when using gpioget -c 7 7, the tool seems to reconfigure the I/O as input and the output goes low. (LCD reset)

[3] Perhaps not related, ( I guessed it may been needed to switch on the GPU) DT examples for dk2 mention:

&gpu
{
contiguous-area = <&gpu_reserved>;
};

but this give an error in ECO 5.0,

 

For item [1] the u-boot DTC output:

 

arch/arm/dts/stm32mp157a-board-mx-lcd.dtb: Warning (reg_format): /panel/port@0:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
arch/arm/dts/stm32mp157a-board-mx-lcd.dtb: Warning (avoid_default_addr_size): /panel/port@0: Relying on default #address-cells value
arch/arm/dts/stm32mp157a-board-mx-lcd.dtb: Warning (avoid_default_addr_size): /panel/port@0: Relying on default #size-cells value

 

 

[debugging]

 

Addtions:  dmseg reports

[ 0.317852] platform 5a001000.display-controller: Fixed dependency cycle(s) with /panel
[ 12.710279] platform panel-backlight: deferred probe pending
[ 12.721404] platform panel: deferred probe pending
[ 15.135513] pwm-backlight panel-backlight: supply power not found, using dummy regulator
[ 16.011862] pwm-backlight panel-backlight: supply power not found, using dummy regulator
[ 16.045170] pwm-backlight panel-backlight: invalid default brightness level: 32, using 7
[ 16.091774] panel-simple panel: supply power not found, using dummy regulator
[ 16.195329] panel-simple panel: Specify missing connector_type
[ 16.203700] stm32mp157-pinctrl soc:pinctrl@50002000: pin PI12 already requested by panel; cannot claim for 5a001000.display-controller

[ 16.265550] stm32mp157-pinctrl soc:pinctrl@50002000: pin-140 (5a001000.display-controller) status -22
[ 16.273481] stm32mp157-pinctrl soc:pinctrl@50002000: could not request pin 140 (PI12) from group PI12 on device soc:pinctrl@50002000

[3][ 16.045170] pwm-backlight panel-backlight: invalid default brightness level: 32, using 7

Default-brightness was set to <3> both in kernel and uboot, 

[CLOSED] The value is an index in the array Fixed by setting a valid index.

 

 

	 panel_backlight: panel-backlight {
		compatible = "pwm-backlight";
		pwms = <&pwm2 0 5000000>;
		brightness-levels = <0 4 8 16 32 64 128 255>;
		// dmseg: pwm-backlight panel-backlight: invalid default brightness level: 32, using 7
		default-brightness-level = <3>;
		status = "okay";
	};

 

 

[4]   stm32mp157-pinctrl soc:pinctrl@50002000: pin PI12 already requested by panel; cannot claim for 5a001000.display-controller

This Conflict was resolved by removing pinctrl form te &ltdc node and keep it in the root panel node. Though no change, the panel is still not working.

 

Both uboot and kernels declare the following and there isn't overlap. Definitions were copied from CubeMX generated device trees. Why this report? just as a try, removed pinctrl for the panel from u-boot. but error in dmseg is still there. removing PI12, results in the same error for PI13  etc.. etc.. so ot seems the whole list of pin for the LCD is duplicated, but this is not catched or reported  at dtb compilation time. This is very odd.

 

 

 

 

 

ltdc_sleep_pins_mx: ltdc_sleep_mx-0 {
pins1 {
pinmux = <STM32_PINMUX('I', 12, AF14)>, /* LTDC_HSYNC */
<STM32_PINMUX('I', 13, AF14)>, /* LTDC_VSYNC */
<STM32_PINMUX('I', 15, AF14)>, /* LTDC_R0 */
<STM32_PINMUX('J', 0, AF14)>, /* LTDC_R1 */
<STM32_PINMUX('J', 1, AF14)>, /* LTDC_R2 */
<STM32_PINMUX('J', 2, AF14)>, /* LTDC_R3 */
<STM32_PINMUX('J', 3, AF14)>, /* LTDC_R4 */
<STM32_PINMUX('J', 4, AF14)>, /* LTDC_R5 */
<STM32_PINMUX('J', 5, AF14)>, /* LTDC_R6 */
<STM32_PINMUX('J', 6, AF14)>, /* LTDC_R7 */
<STM32_PINMUX('J', 7, AF14)>, /* LTDC_G0 */
<STM32_PINMUX('J', 8, AF14)>, /* LTDC_G1 */
<STM32_PINMUX('J', 9, AF14)>, /* LTDC_G2 */
<STM32_PINMUX('J', 10, AF14)>, /* LTDC_G3 */
<STM32_PINMUX('J', 11, AF14)>, /* LTDC_G4 */
<STM32_PINMUX('J', 12, AF14)>, /* LTDC_B0 */
<STM32_PINMUX('J', 13, AF14)>, /* LTDC_B1 */
<STM32_PINMUX('J', 14, AF14)>, /* LTDC_B2 */
<STM32_PINMUX('J', 15, AF14)>, /* LTDC_B3 */
<STM32_PINMUX('K', 0, AF14)>, /* LTDC_G5 */
<STM32_PINMUX('K', 1, AF14)>, /* LTDC_G6 */
<STM32_PINMUX('K', 2, AF14)>, /* LTDC_G7 */
<STM32_PINMUX('K', 3, AF14)>, /* LTDC_B4 */
<STM32_PINMUX('K', 4, AF14)>, /* LTDC_B5 */
<STM32_PINMUX('K', 5, AF14)>, /* LTDC_B6 */
<STM32_PINMUX('K', 6, AF14)>, /* LTDC_B7 */
<STM32_PINMUX('K', 7, AF14)>; /* LTDC_DE */
bias-disable;
drive-push-pull;
slew-rate = <0>;
};
pins2 {
pinmux = <STM32_PINMUX('I', 14, AF14)>; /* LTDC_CLK */
bias-disable;
drive-push-pull;
slew-rate = <1>;
};

pins {
pinmux = <STM32_PINMUX('I', 12, ANALOG)>, /* LTDC_HSYNC */
<STM32_PINMUX('I', 13, ANALOG)>, /* LTDC_VSYNC */
<STM32_PINMUX('I', 14, ANALOG)>, /* LTDC_CLK */
<STM32_PINMUX('I', 15, ANALOG)>, /* LTDC_R0 */
<STM32_PINMUX('J', 0, ANALOG)>, /* LTDC_R1 */
<STM32_PINMUX('J', 1, ANALOG)>, /* LTDC_R2 */
<STM32_PINMUX('J', 2, ANALOG)>, /* LTDC_R3 */
<STM32_PINMUX('J', 3, ANALOG)>, /* LTDC_R4 */
<STM32_PINMUX('J', 4, ANALOG)>, /* LTDC_R5 */
<STM32_PINMUX('J', 5, ANALOG)>, /* LTDC_R6 */
<STM32_PINMUX('J', 6, ANALOG)>, /* LTDC_R7 */
<STM32_PINMUX('J', 7, ANALOG)>, /* LTDC_G0 */
<STM32_PINMUX('J', 8, ANALOG)>, /* LTDC_G1 */
<STM32_PINMUX('J', 9, ANALOG)>, /* LTDC_G2 */
<STM32_PINMUX('J', 10, ANALOG)>, /* LTDC_G3 */
<STM32_PINMUX('J', 11, ANALOG)>, /* LTDC_G4 */
<STM32_PINMUX('J', 12, ANALOG)>, /* LTDC_B0 */
<STM32_PINMUX('J', 13, ANALOG)>, /* LTDC_B1 */
<STM32_PINMUX('J', 14, ANALOG)>, /* LTDC_B2 */
<STM32_PINMUX('J', 15, ANALOG)>, /* LTDC_B3 */
<STM32_PINMUX('K', 0, ANALOG)>, /* LTDC_G5 */
<STM32_PINMUX('K', 1, ANALOG)>, /* LTDC_G6 */
<STM32_PINMUX('K', 2, ANALOG)>, /* LTDC_G7 */
<STM32_PINMUX('K', 3, ANALOG)>, /* LTDC_B4 */
<STM32_PINMUX('K', 4, ANALOG)>, /* LTDC_B5 */
<STM32_PINMUX('K', 5, ANALOG)>, /* LTDC_B6 */
<STM32_PINMUX('K', 6, ANALOG)>, /* LTDC_B7 */
<STM32_PINMUX('K', 7, ANALOG)>; /* LTDC_DE */
};
};

 

 

 

Searching the source tree, PI12 is declared only here, Assume that the dts should have overrules the defaults  from pinctrl files ?

 

 

 

kernel

arch/arm/boot/dts/stm32mp157a-board-mx-lcd.dts:			pinmux = <STM32_PINMUX('I', 12, AF14)>, /* LTDC_HSYNC */
arch/arm/boot/dts/stm32mp15-pinctrl.dtsi:				 <STM32_PINMUX('I', 12, AF14)>, /* LCD_HSYNC */
arch/arm/boot/dts/stm32f4-pinctrl.dtsi:					pinmux = <STM32_PINMUX('I', 12, AF14)>, /* LCD_HSYNC */
scripts/dtc/include-prefixes/arm/stm32mp157a-board-mx-lcd.dts:			pinmux = <STM32_PINMUX('I', 12, AF14)>, /* LTDC_HSYNC */
scripts/dtc/include-prefixes/arm/stm32mp15-pinctrl.dtsi:				 <STM32_PINMUX('I', 12, AF14)>, /* LCD_HSYNC */
scripts/dtc/include-prefixes/arm/stm32f4-pinctrl.dtsi:					pinmux = <STM32_PINMUX('I', 12, AF14)>, /* LCD_HSYNC */

u-boot

arch/arm/dts/stm32mp157a-board-mx-lcd.dts:			pinmux = <STM32_PINMUX('I', 12, AF14)>, /* LTDC_HSYNC */
arch/arm/dts/stm32mp15-pinctrl.dtsi:				 <STM32_PINMUX('I', 12, AF14)>, /* LCD_HSYNC */
arch/arm/dts/.stm32mp157a-board-mx-lcd.dtb.pre.tmp:			pinmux = <STM32_PINMUX('I', 12, AF14)>, /* LTDC_HSYNC */
arch/arm/dts/stm32f4-pinctrl.dtsi:					pinmux = <STM32_PINMUX('I', 12, AF14)>, /* LCD_HSYNC */

 

 

 

 

[5] [ 16.195329] panel-simple panel: Specify missing connector_type

Even though panel-simple.c was the standard file added .connector_type = DRM_MODE_CONNECTOR_DPI. but then this error appeared: [ 16.954227] panel-simple panel: Expected bpc in {6,8} but got: 0,   [CLOSED] Fixed by adding bpc in the panel file (original kernel sources seems not have this entry)

[6] Regulator issues

The WIKI did not mentioned about such requirement.  but this panel is fed from direct power, Not sure if this issue has impact on enabling the panel ?
[CLOSED] Resolved by adding power-supply to the backlight node

 

[debugging]

I removed the pinctrl items in ltdc and the conflict is gone, but not sure this will cause the panel not be loaded.

&ltdc {
	//pinctrl-names = "default", "sleep";
	//pinctrl-0 = <&ltdc_pins_mx>;
	//pinctrl-1 = <&ltdc_sleep_pins_mx>;
	status = "okay";
	

dmesg still reports:

[ 0.317695] platform 5a001000.display-controller: Fixed dependency cycle(s) with /panel
[ 12.711472] platform panel-backlight: deferred probe pending
[ 12.722430] platform panel: deferred probe pending

[debugging]

Regarding

enable-gpios = <&gpioh 15 GPIO_ACTIVE_HIGH>; // DISP
reset-gpios = <&gpioh 7 GPIO_ACTIVE_HIGH>; // RESET

reset-gpio is not defined in the  device-tree manual, so I changed to set DE high and reset high.

enable-gpios = <&gpioh 15 GPIO_ACTIVE_HIGH>, <&gpioh 7 GPIO_ACTIVE_HIGH>;

Now the remaining messages are

[ 13.348141] platform panel-backlight: deferred probe pending
[ 13.404388] platform panel: deferred probe pending

and this boot error appears

[FAILED] Failed to start Starts Psplash Boot screen

 

[debugging]

I have seen now the following  in the ltdc and the the panel root device node. The ltdc device tree binding,nor the panel-simple device tree binding list these. Where they are supposed to be ?  Nor is reset-gpio defined for the panel node, *but it is for panel-dpi",  though found in several examples for RGB panels.

pinctrl-names = "default", "sleep";
	pinctrl-0 = <&ltdc_pins_mx>;
	pinctrl-1 = <&ltdc_sleep_pins_mx>;

when I add

 

reset-gpios = <&gpioh 7 GPIO_ACTIVE_HIGH>; // RESET
OR
reset-gpios = <&gpioh 7 GPIO_ACTIVE_LOW; // RESET

 

I can set the reset pin with gopio set. But it is turned a few seconds later and cannot be turned on again with gpioset..  When removing these lines, gpioset does not work, so it seem the driver does recognize this setting, though it does not program it pin as the backlight it not coming on via this GPIO.

[debugging]

I do not see any error in the build process for uboot, OP-TEE , TF-A and the kernel. dmesg reports

 

[ 0.317692] platform 5a001000.display-controller: Fixed dependency cycle(s) with /panel
[ 13.347461] platform panel-backlight: deferred probe pending
[ 13.435865] platform panel: deferred probe pending

 

Something cause the driver not to be probed. but what, All DTS according the WIKI and DT bindings.. Stuck here...

[debugging]

Can;t figure out why the loading of the drivers are deferred. no messages in dmesg

[ 13.349348] platform panel-backlight: deferred probe pending
[ 13.360388] platform panel-rgb: deferred probe pending

Weston load the I2C touch driver it seems. No clues... The backlight does not turn on either.

[05:32:38.987] Using config file '/etc/xdg/weston/weston.ini'
[05:32:38.990] Output repaint window is 100 ms maximum.
[05:32:38.994] Loading module '/usr/lib/libweston-11/drm-backend.so'
[05:32:39.042] initializing drm backend
[05:32:39.042] Trying logind launcher...
[05:32:39.058] logind: session control granted
[05:32:39.078] using /dev/dri/card0
[05:32:39.078] DRM: supports atomic modesetting
[05:32:39.078] DRM: supports GBM modifiers
[05:32:39.078] DRM: supports picture aspect ratio
[05:32:39.182] event0 - generic ft5x06 (82): is tagged by udev as: Touchscreen
[05:32:39.188] event0 - generic ft5x06 (82): device is a touch device
[05:32:39.191] Touchscreen - generic ft5x06 (82) - /sys/devices/platform/soc/5c007000.etzpc/40013000.i2c/i2c-0/0-0038/input/input0/event0
[05:32:39.191] libinput: configuring device "generic ft5x06 (82)".
[05:32:39.191] input device event0 has no enabled output associated (none named), skipping calibration for now.
[05:32:39.192] DRM: head 'DPI-1' updated, connector 32 is connected, EDID make 'unknown', model 'unknown', serial 'unknown'
 Supported EOTF modes: SDR
[05:32:39.193] DRM: head 'DPI-1' found, connector 32 is connected, EDID make 'unknown', model 'unknown', serial 'unknown'
 Supported EOTF modes: SDR
[05:32:39.194] Registered plugin API 'weston_drm_output_api_v1' of size 16
[05:32:39.194] Color manager: no-op
[05:32:39.195] Output 'DPI-1' attempts EOTF mode: SDR
[05:32:39.195] Output 'DPI-1' using color profile: built-in default sRGB SDR profile
[05:32:39.202] DRM: output DPI-1 uses shadow framebuffer.
[05:32:39.202] Initialized backlight for head 'DPI-1', device /sys/class/backlight/panel-backlight
[05:32:39.203] Output DPI-1 (crtc 38) video modes:
 800x480@57.9, preferred, current, 33.3 MHz
[05:32:39.204] associating input device event0 with output DPI-1 (none by udev)
[05:32:39.206] Output 'DPI-1' enabled with head(s) DPI-1
[05:32:39.206] Compositor capabilities:
 arbitrary surface rotation: yes
 screen capture uses y-flip: no
 cursor planes: yes
 arbitrary resolutions: no
 view mask clipping: yes
 explicit sync: no
 color operations: no
 presentation clock: CLOCK_MONOTONIC, id 1
 presentation clock resolution: 0.000000001 s
[05:32:39.210] Loading module '/usr/lib/weston/desktop-shell.so'
[05:32:39.215] Loading module '/usr/lib/weston/systemd-notify.so'
[05:32:39.217] info: add 1 socket(s) provided by systemd
[05:32:39.218] launching '/usr/libexec/weston-keyboard'
[05:32:39.225] launching '/usr/libexec/weston-desktop-shell'
[05:32:39.237] Warning: computed repaint delay is insane: -51363 msec

 

[debugging]

Confirmed the panel's touch I2c driver works,  but ofcourse that's independent from the ltdc/panel issue

[debugging]

Fixed,

Issue is the backlight driver does not activate the enable-gpio pins delcared in the node

[ 0.317695] platform 5a001000.display-controller: Fixed dependency cycle(s) with /panel
[ 12.711472] platform panel-backlight: deferred probe pending
[ 12.722430] platform panel: deferred probe pending

These messages are still in the dmseg, even the panel works fine under linux kernel. Perhaps this is an early warning that resolved itself after other drivers were loaded.