STM32MP15 ECO 5.0 RGB panels panel-simple or panel-dpi bindings ?

[debugging]

For Rockchip RGB panel  this link to refers to device tree binding of panel-dpi, (MIPI-DPI),  https://wiki.st.com/stm32mpu/wiki/Display_panels_hardware_components

Several RGB panels are also listed in panel-simple.yaml.   Which devicetree bindings one to follow for RGB panels ?

 

[Erwan SZYMANSKI]

Hello @debugging ,
There is no "special technique" to know it directly, but I can explain few points : 

The panel-simple driver is a one used by many panels that have a quite generic behavior. At start, they will mainly start regulators, clock, anything common to every panel. And for a lot of panel, it is enough to make them work (be careful, the panel-timing will differ, but as each panel has its own timing, that is why we declare the timings in the device tree).

Now as you say, some panels have specific driver, and it can be done for different reasons : 

1. The driver has a special initialization sequence, and need to send some vendor specific DCS command at the start of panel. It can either need a specific firmware load or anything. This is the most common reason.
2. The driver is here mainly to inform about the panel specific timing, then the user does not have to recalculate with the panel spec the blanking and so on... But if this is the only reason, the compatible is most probably in panel-simple.c

Now, my advice on how to proceed :

• I want to use a panel, does it have a driver upstreamed in Linux ? If yes, I use it. If no continue ...
• My panel has a compatible provided in panel-simple.c driver ? If yes, I use it and I need to get the right timings. If no, continue ...
• I so cannot find it upstreamed, If I have not many information on the panel, I will first try to use panel-simple and see if I can make it work. 
• If I get some trouble, I need to get the panel vendor specific information, and see if the panel has special needs (init sequence and so on as we said). If it has, I face a panel that needs a specific driver, but that does not exist, so I need to create it myself and add it to my Linux build.

I hope it will help you to better understand and go forward.
Kind regards,
Erwan.

[debugging]

Many thanks for the detail. In ECO 1.0 I added my custom panel in panel-simple.c with its specific resolution etc.. and it worked file, just a simple RGB with reset,disp, hsync, vsync w/o any I2C setup need. I have other RGB panels that do need I2C sequences to initialize, so thank you for the hint. P.S is  Do panel-dpi bindings apply to those and/or how do you get uboot or kernel execute those I2C commands ?

I am having an issue with a panel already defined in panel-simple.c that worked with ECO 1.0 too. This panel only does use I2C but only for touch.  I wanted to understand when to use panel-dpi or when to use panel-simple bindings.   For example "reset-gpios" that is defined for the MIPI-DPI (panel-dpi bindings), is not defined in bindings  for panel-simple .For this simple panel , w/o a specific driver the reset pins seems to get pulled in reset (likely for PM reason) as  I did define this reset GPIO in the dts.

[Erwan SZYMANSKI]

Hello @debugging ,
Sorry I missed the panel-dpi part, my bad.

You have RGB  parallel panel that follows MIPI-DPI standard. This is the case for the default panel we have on STM32MP135F-DK board for example. 

If this is the case, you need to precise that this is a MIPI-DPI panel in the dedicated node of your device tree, in addition to you panel compatible.

This is what we can see in kernel documentation, panel-dpi.yaml file :

properties:
 compatible:
 description:
 Shall contain a panel specific compatible and "panel-dpi"
 in that order.

In the case of your panel, OK the I2C touchscreen is managed aside, directly by I2C and a dedicated driver. Same for STM13MP157F-DK2 board and STM32MP135F-DK board as example.

Now concerning your point on "reset-gpios". We precise it if the driver needs and can handle it. For specific panel driver such as panel-orisetech-otm8009a.c you can see that it handles a specific sequence using reset-gpios (if I remember well, this is to avoid some screen glitches at reboot or transition between U-Boot and the kernel). For generic simple driver, I do not think they use it, but need to check inside drivers.

Kind Regards,
Erwan.

 

[debugging]

For reference, the panel is working, at least touch, a (gtk) program to read touch detects clickd and movement, just no picture ad backlight..

 

Only.... it's weird it detect only 8x8 matrix.

[debugging]

Bootlog sent.

[debugging]

One weird thing is gpioinfo. the GPIO are input, not set as output.

more details here https://community.st.com/t5/stm32-mpus-products/stm32mp1-eco-5-0-ltdc-device-tree-rgb-lcd-not-working-anymore/td-p/706511

P.S the different in binding between dpi and simple, are that dpi has a timing section and supports reset, there aren't much other differences. This panel worked on ECO 0 as simple panel and is defined a panel-simple.c so I guess it must be panel-simple in the DTS.

 

piochip9 - 16 lines:
	line 0:	"PJ0" 	input consumer="kernel"
	line 1:	"PJ1" 	input consumer="kernel"
	line 2:	"PJ2" 	input consumer="kernel"
	line 3:	"PJ3" 	input consumer="kernel"
	line 4:	"PJ4" 	input consumer="kernel"
	line 5:	"PJ5" 	input consumer="kernel"
	line 6:	"PJ6" 	input consumer="kernel"
	line 7:	"PJ7" 	input consumer="kernel"
	line 8:	"PJ8" 	input consumer="kernel"
	line 9:	"PJ9" 	input consumer="kernel"
	line 10:	"PJ10" 	input consumer="kernel"
	line 11:	"PJ11" 	input consumer="kernel"
	line 12:	"PJ12" 	input consumer="kernel"
	line 13:	"PJ13" 	input consumer="kernel"
	line 14:	"PJ14" 	input consumer="kernel"
	line 15:	"PJ15" 	input consumer="kernel"

 

 

 

[debugging]

The backlight driver seems to be set with the values form the DTS.just the BL is not on,  Could turn on the BL with gpioset -t0 -c 7 7=1 before, but now  it does not have any effect

 

root@stm32mp1:/sys/class/backlight/panel-backlight# ls -l
total 0
-r--r--r-- 1 root root 4096 Aug 9 13:50 actual_brightness
-rw-r--r-- 1 root root 4096 Aug 9 13:54 bl_power
-rw-r--r-- 1 root root 4096 Aug 9 13:50 brightness
lrwxrwxrwx 1 root root 0 Aug 9 13:50 device -> ../../../panel-backlight
-r--r--r-- 1 root root 4096 Aug 9 13:50 max_brightness
drwxr-xr-x 2 root root 0 Aug 9 13:51 power
-r--r--r-- 1 root root 4096 Aug 9 13:51 scale
lrwxrwxrwx 1 root root 0 Aug 9 13:50 subsystem -> ../../../../../class/backlight
-r--r--r-- 1 root root 4096 Aug 9 13:50 type
-rw-r--r-- 1 root root 4096 Aug 9 13:49 uevent
root@stm32mp1:/sys/class/backlight/panel-backlight# cat actual_brightness
7
root@stm32mp1:/sys/class/backlight/panel-backlight# cat max_brightness
7
root@stm32mp1:/sys/class/backlight/panel-backlight# cat brightness
7

 

[debugging]

Panel is working now. a few changes

1. in ECO 1, in panel reset-gpios = <&gpioh 7 GPIO_ACTIVE_LOW>; seems to work, but in ECO 5.0 it does not. Removed the GPIO rest property. Setting cmpatible r to "panel-dpi does not work.
2. PWM cells in timers should not change. In ECO 1.0 uses 2 arguments, in ECO 5.0 it uses 3 arguments, so need to add 0 for polarity. or use calls=2 with 1 arguments in backlight node.

3. Removed reset GPIO property from backlight control. (this cause kernel to use this GPIO but never activate  it)

4. Removed backlight property form panel and use gpio command to get it out of reset (this result in LCD to work)

5. The panel is actually innolux,zj070na-01p  this seems to be panel uses by RPI. The driver used  is ft5x06,.

6. Need to provide resolution to the touch driver otherwise it thinks it is 8x8.

Open issues:

a. STM demo program does not work correctly for touch.

b. The (custom) gtk test program "click" event is not fired for location larger than 600 (panel is 1024)

c. Can't create splash screen because the panel is kept in reset during boot. (how to fix this? custom gpio driver?)

d. The Wayland touch calibration program fails in points beyond x pixel 600   (but gtk touch detect location works fine but click event beyond x position around 600 is not detected as well)

[debugging]

All issues resolved, cause:

- brightness reversed  polarity

- bias levels for PWM pin.

- settings for touch

All seems the be panel specific. A lot is guess work

Not resolved:

Reset pin which actually is not a reset of the display controller but disables the regulators on the panel. it seems the pwm-backlight driver does not use the enable-gpios' pin. Could be a bug in the driver. something STMicro may need to look into.