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]

Thanks, so if that true for panel-dpi, I assume a DT entry for a simple panel must state  <panel>,"panel-simple" , like

compatible = "innolux,at070tn92","panel-simple"; (this panel I am using is listed in panel-simple.c), otherwise it won't load or find it ? The bindings don't mentions so, but sometimes things are missed in the docs/examples. in this post it shows as "simple-panel", so not sure which one to use ? https://community.st.com/t5/stm32-mpus-products/stm32mp1-ltdc-device-tree-for-rgb-display/td-p/315953

In CONFIG I found several PANEL_XXXX entries. Some of those are used on the DK board. Are these entries needed  ? Dodes it mean these panel have a custom driver besides being a simple-panel ? I am still struggling to fix these issues as the panel and backlight seems to to be found. (no backlight and no picture):

[ 0.318258] platform 5a001000.display-controller: Fixed dependency cycle(s) with /panel-rgb
[ 13.365350] platform panel-rgb: deferred probe pending
[ 13.369315] platform panel-backlight: deferred probe pending

[Erwan SZYMANSKI]

@debugging ,
I think the link you share is on a very old version of the Linux, and I am not sure it is used anymore.

Can you share me your device tree and boot log file ? Maybe it will be easier for me to help on your issue. I supposed you wanted to say "as the panel and backlight seems to not be found"

Concerning the configuration, either you have a dedicated panel driver and you should activate its own config in the Linux kernel, or you use panel simple and this is the configuration you have to enable.

Kind regards,
Erwan.

[debugging]

Send the DTS by mail. Working on the bootlog. Yes, I wonder  : if  panel-simple / simple-panel is not added to compatible,  will it be found by the simple panel driver or not ?  The deferred probe probably means the panel or sometthing it depend on cannot be found, but the bootlog does not tell. and don't know how to trace/debug this... 

[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"