St7789v tft display bring up on colibri imx7d

Hi everybody!

I’m trying to bring up a small fbtft st7789v (I attached the data sheet to the ticket) on our custom mother board (based on your colibri emmc-eval-v3) with your SOM colibri-imx7d-emmc.

To do this I just added to your colibri_imx7_defconfig (I’m using the downstream kernel: toradex_5.4-2.3.x-imx) these three defines:

CONFIG_STAGING=y
CONFIG_FB_TFT=y
CONFIG_FB_TFT_ST7789V=y

in order to have the correct (staging) driver inside the linux kernel.

Then I use this overlay (on your default dtb: imx7d-colibri-emmc-eval-v3.dtb) to explain to the driver where I have the connections:

// Enable the spi fbtft interface on the Colibri iMX7
#include <dt-bindings/gpio/gpio.h>

/dts-v1/;
/plugin/;

/ {
	compatible = "toradex,colibri-imx7d",
		     "toradex,colibri-imx7d-emmc",
		     "toradex,colibri-imx7s";
};

// Enabling the SPI controller also enables spidev on cs0, so we have disable it
&spidev0 {
	status = "disabled";
};

// Enabling the SPI controller also enables CAN controller on cs0, 
// so we have disable it
&mcp2515 {
	status = "disabled";
};

&ecspi3 {
	// Enable the SPI controller
	status = "okay";
	
	/* needed to avoid dtc warning */
	#address-cells = <1>;
	#size-cells = <0>;
		
	display: display@0{

		compatible = "sitronix,st7789v";
		reg = <0>; // Chip Select 0

		spi-max-frequency = <32000000>; // 32MHz
		
		reset-gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
		dc-gpios = <&gpio7 2 GPIO_ACTIVE_HIGH>;
		
		width = <320>;
		height = <240>;
		buswidth = <8>; // Most controllers use this value

		rotate = <1>;		
	};
};

I followed this thread to write my overlay:

Linux boot correctly, but I don’t have the fb interface in /dev and I can’t see any dmesg about “tft” or “fb”…

Do you have any suggestion? Have you ever tried to connect this type of tft display on your SOM?

Any idea or suggestion is really appreciated!

Thanks!

ST7789V2_SPEC_V1.0.pdf (3.1 MB)

Hi @vbardelli !

I have never used this kind of SPI display.

But from the device tree bindings documentation, seems like the device tree setup for this display is different from what you did: sitronix,st7701.txt « panel « display « bindings « devicetree « Documentation - linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules

Seems like it is expected to use the graph concept in your device tree.


EDIT: I shared the wrong documentation. These is the right one:

Best regards,

hi @vbardelli,

I’m the college of @cgsasse (the thread you referring to). In the last days we made some further steps towards using a ST7789V2 SPI display @ toradex SOM. Which means, the display is working but splash screen is still an mayor issue! So let me share with you what we have (I hope this will help you:

Our section for using the ST7789V2 at ecspi1: (you will have to change the spi and the gpios)

&ecspi1 {
	status = "okay";

	display: display@0 {
		compatible = "sitronix,st7789v";

		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_disp_gpio>;

		reg = <0>;									// ECSPI1 has only one slave select
		spi-max-frequency = <24000000>;				// 48MHz
		buswidth = <8>;

		reset-gpios = <&gpio3 11 GPIO_ACTIVE_HIGH>;	// SODIMM pin 80
		dc-gpios = <&gpio2 4 GPIO_ACTIVE_HIGH>;		// SODIMM pin 73
		led-gpios = <&gpio4 16 GPIO_ACTIVE_HIGH>;	// SODIMM pin 28

		width = <240>;
		height = <320>;
		rotate = <270>;								// Rotate to landscape

		debug = <0x4000000>;						// Print init commands to the kernel log

		status = "okay";
	};

	spidev0: spidev@0 {
		compatible = "toradex,evalspi";
		reg = <0>;
		spi-max-frequency = <23000000>;
		status = "disabled";
	};
};

please note:

  • we disabled the the spidev0: spidev@0, copied from mcp251x example within (imx6dll-colibri-eval-v3.dts)
  • we use a custom pinctrl “pinctrl_disp_gpio”- group which describes the GPIOs used for reset, dc and led (all of them are outputs)

we defined the group by extending the iomuxc as followed (placed to the same file as changes above):

&iomuxc {

	pinctrl_disp_gpio: disp_gpio_muxgrp {
		fsl,pins = <
			MX6UL_PAD_LCD_DATA06__GPIO3_IO11		0x000a0	/* DIS_RST   @ SODIMM 80 */
			MX6UL_PAD_ENET1_TX_DATA1__GPIO2_IO04	0x000a0	/* DIS_D/CX  @ SODIMM 73 */
			MX6UL_PAD_NAND_DQS__GPIO4_IO16			0x000a0	/* DIS_BL_EN @ SODIMM 28 */
		>;
	};
};

You will have to replace the MX6UL_PAD_XXX__BANK_PIN with the pins you have connected.
Attention must be taken if the IOs you are using are defined and used elsewhere. In that case you have to disable the peripheral, or remove / replace the pins from conflicting group.

I hope this will help.

cheers

Thank for your response @shsasse!

Unfortunately your suggestion doesn’t work for me, on imx7d-emmc, with kernel 5.4.193 (downstream). :frowning:

This is my dtb overlay now:

// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
/*
 * Copyright 2020-2021 Toradex
 */

// Enable the parallel RGB interface with settings for VGA Displays on the Colibri iMX7
#include <dt-bindings/clock/imx7d-clock.h>
#include <dt-bindings/gpio/gpio.h>

/dts-v1/;
/plugin/;

/ {
	compatible = "toradex,colibri-imx7d",
		     "toradex,colibri-imx7d-emmc",
		     "toradex,colibri-imx7s";
};

&ecspi3 {
	// Enable the SPI controller
	status = "okay";
	
	// needed to avoid dtc warning
	#address-cells = <1>;
	#size-cells = <0>;

	mcp2515: can@0 {
		status = "disabled";
	};

	spidev0: spidev@0 {
		status = "disabled";
	};
	
	display: display@0{
		
		compatible = "sitronix,st7789v";
	
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_disp_gpio>;		
		
		reg = <0>; // Chip Select 0

		spi-max-frequency = <32000000>; // 32MHz
		
		reset-gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
		dc-gpios = <&gpio7 2 GPIO_ACTIVE_HIGH>;
		//led-gpios = <&gpio1 18 0>;
		
		width = <320>;
		height = <240>;
		buswidth = <8>; // Most controllers use this value

		rotate = <1>;
		
		debug = <0x4000000>;						// Print init commands to the kernel log

		status = "okay";				
	};
};

Then, as per your suggestion, I had this part at the end of &iomuxc node, in file imx7-colibri.dtsi:

pinctrl_disp_gpio: disp_gpio_muxgrp {
		fsl,pins = <
			MX7D_PAD_ECSPI2_SS0__GPIO4_IO23		0x14	/* DIS_RST   @ SODIMM 65 */
			MX7D_PAD_ENET1_RGMII_RD2__GPIO7_IO2	0x14	/* DIS_D/CX  @ SODIMM 63 */
		>;
	};

Then I recompiled the kernel, the overlay, and I put zImage, imx7d-colibri-emmc-eval-v3.dtb and my overlay on the board, and add my overlay to overlay.txt.

But nothing happens on my display and I don’t have /dev/fb0 interface.

I also tried to compile the driver as module, and config it with this fbtft_device.conf in /etc/modprobe.d:

# On fbtft_device set the proper bus, rotate, speed and gpio for chip select, reset and data control
speed=10000000 debug=3
# New display 320x240 (fb_st7789v):
options fbtft_device name=admatec_c-berry28 rotate=270 busnum=2 gpios=reset:119,dc:194,led:129 speed=10000000 debug=3
options fb_st7789v invert=1

But it doesn’t work also this way… :frowning:

Which is your kernel version? Have you ever tried to use the driver as module?

Also for us the main scope is to have a splash screen, do you have any success about this?

Have you tried to introduce the driver in u-boot?

Any idea or suggestion is really appreciated!

Thanks a lot!

Hi @vbardelli and @shsasse !

In my previous message, I mistakenly shared the wrong documentation. Sorry for that. I just edited the message:

From the documentation, we see that are required:

  • compatible
  • reg
  • reset-gpios
  • power-supply

From the device tree shared, you do not have the power-supply property in the SPI panel node.

Could you please try adding it?

Also, in the device tree example, graph logic is used. you should also try using that.

Did you check if there is any other SPI device with reg=<0>?

Please share the dmesg output when trying to boot with this SPI panel enabled.

Best regards,

Hi @henrique.tx (and @shsasse ) and thanks for your response!

Now I’m finally able to have the st7789v (320x240) working as kernel module. At the moment I’m using kernel 4.9 (but I need then to port the same on kernel 5.4). At the moment using driver as a module (in make menuconfig):

device drivers >
staging drivers >
support for small tft lcd display modules (M) >
fb driver for the st7789v lcd controller (M) >
module to for adding fbtft devices (M)

(in any case I attach my configuration [.config] file)

then I have this configuration file in /etc/modprobe.d (fbtft_device.conf):

# On fbtft_device set the proper bus, rotate, speed and gpio for chip select, reset and data control
# New display 320x240 (fb_st7789v):
options fbtft_device name=admatec_c-berry28 rotate=270 busnum=2 gpios=reset:119,dc:194,led:129 speed=40000000 debug=3
options fb_st7789v invert=1

In this way the display works (I only have to add ‘gpio set 54’ in u-boot in order to power up, for the moment). In this way i have /dev/fb0 interface and I’m able to present some garbage with: cat /dev/urandom > /dev/fb0.

Then I tried to convert modules to drivers directly compiled into the kernel (in the make menuconfig, the same as above, from M to Y). Then I add this part (for the moment in imx7d-colibri-emmc-eval-v3.dts, before every overlay):

&lcdif {
	status = "disabled";
};

&iomuxc {	
	pinctrl_disp_gpio: disp_gpio_muxgrp {
		fsl,pins = <
			MX7D_PAD_ECSPI2_SS0__GPIO4_IO23      0x14  // DIS_RST   @ SODIMM 65
			MX7D_PAD_ENET1_RGMII_RD2__GPIO7_IO2  0x14  // DIS_D/CX  @ SODIMM 63
		>;
	};
};

&ecspi3 {
	// Enable the SPI controller
	status = "okay";
	
	// needed to avoid dtc warning
	#address-cells = <1>;
	#size-cells = <0>;

	mcp2515: can@0 {
		status = "disabled";
	};

	// To keep the CAN controller enabled by default,
	// disable conflicting spidev. This spidev device
	// enables with the devicetree overlay.
	//
	spidev0: spidev@0 {
		status = "disabled";
	};
	
	display: display@0{

		compatible = "sitronix,st7789v";
	
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_disp_gpio>;		
		
		reg = <0>;  // Chip Select 0

		spi-max-frequency = <32000000>;  // 32MHz
		
		reset-gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
		dc-gpios = <&gpio7 2 GPIO_ACTIVE_HIGH>;
		
		width = <320>;
		height = <240>;
		buswidth = <8>;  // Most controllers use this value

		// This is a hack to prevent fb_s6d02a1.c:set_var() from issuing
		// command 0x36 after the init sequence has been applied and thus
		// changing the config.
		rotate = <1>;
		
		debug = <0x4000000>;  // Print init commands to the kernel log

		status = "okay";				
	};
};

(in any case I also added all my imx7d-colibri-emmc-eval-v3.dts).

All the others dts and dtsi files involved should be the same as for toradex eval board.

Unfortunately in this way I have no /dev/fb0 interface and I have these message in dmesg:

[    1.518438] fb_st7789v spi2.0: Error applying setting, reverse things back
[    1.525675] fb_st7789v: probe of spi2.0 failed with error -22

Any suggestion is really appreciated!

@shsasse in the emaning time are you able to have the splash screen? The first and preliminary solution for me should be to have display working as module and to have the splash screen…

Thanks a lot!

config_as_m (118.8 KB)

imx7d-colibri-emmc-eval-v3.dts (4.1 KB)

Hi @henrique.tx,

what do you intend with “you do not have the power-supply property in the SPI panel node”? In any case, at the moment I switch on the display with “gpio set 54”, from u-boot…

Also, in the device tree example, graph logic is used. you should also try using that.

I tried also with this, in my device tree:

&iomuxc {	
	pinctrl_disp_gpio: disp_gpio_muxgrp {
		fsl,pins = <
			MX7D_PAD_ECSPI2_SS0__GPIO4_IO23      0x14  // DIS_RST   @ SODIMM 65
			MX7D_PAD_ENET1_RGMII_RD2__GPIO7_IO2  0x14  // DIS_D/CX  @ SODIMM 63
		>;
	};
};

&ecspi3 {
	// Enable the SPI controller
	status = "okay";
	
	// needed to avoid dtc warning
	#address-cells = <1>;
	#size-cells = <0>;

	mcp2515: can@0 {
		compatible = "microchip,mcp2515";
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_can_int>;
		reg = <0>;
		clocks = <&clk16m>;
		interrupt-parent = <&gpio5>;
		interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
		spi-max-frequency = <10000000>;
		status = "disabled";
	};

	spidev0: spidev@0 {
		compatible = "toradex,evalspi";
		reg = <0>;
		spi-max-frequency = <23000000>;
		status = "disabled";
	};

	display: panel@0 {
		compatible = "sitronix,st7789v";
		
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_disp_gpio>;		
		
		reg = <0>;
		
		reset-gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
		dc-gpios = <&gpio7 2 GPIO_ACTIVE_HIGH>;
		backlight = <&pwm1>;
		spi-max-frequency = <100000>;
		spi-cpol;
		spi-cpha;

//		port {
//			panel_input: endpoint {
//				remote-endpoint = <&tcon0_out_panel>;
//			};
//		};
	
		width = <320>;
		height = <240>;
		buswidth = <8>;  // Most controllers use this value

		// This is a hack to prevent fb_s6d02a1.c:set_var() from issuing
		// command 0x36 after the init sequence has been applied and thus
		// changing the config.
		rotate = <1>;
		
		debug = <0x4000000>;  // Print init commands to the kernel log

		status = "okay";	
	};
};

but the result is the same: no fb0 interface in /dev…

Did you check if there is any other SPI device with reg=<0>?

Yes, I disabled all spi device on ecspi3 (spidev and can), as you can see on my imx7d-colibri-emmc-eval-v3.dts

Please share the dmesg output when trying to boot with this SPI panel enabled.

this is what happens in dmesg about spi, the problem it seems related to spi probe by the fb7789v driver, but I don’t understand why, because this is work when I use the driver like module:

CSFreedomX:~# dmesg | grep spi
[    1.003941] spi_imx 30840000.ecspi: can't get the TX DMA channel, error -19!
[    1.003952] spi_imx 30840000.ecspi: dma setup error -19, use pio
[    1.010313] spi_imx 30840000.ecspi: registered master spi2
[    1.010491] spi spi2.0: spi_imx_setup: mode 3, 8 bpw, 100000 hz
[    1.010508] spi spi2.0: setup mode 3, 8 bits/w, 100000 Hz max --> 0
[    1.010766] spi_imx 30840000.ecspi: registered child spi2.0
[    1.010774] spi_imx 30840000.ecspi: probed
[    1.504974] spi_imx 30840000.ecspi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 100000, post: 6, pre: 9
[    1.629283] spi_imx 30840000.ecspi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 100000, post: 6, pre: 9
[    1.629500] spi_imx 30840000.ecspi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 100000, post: 6, pre: 9
[    1.629710] spi_imx 30840000.ecspi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 100000, post: 6, pre: 9
[    1.629909] spi_imx 30840000.ecspi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 100000, post: 6, pre: 9
[    1.630622] spi_imx 30840000.ecspi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 100000, post: 6, pre: 9
[    1.630823] spi_imx 30840000.ecspi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 100000, post: 6, pre: 9
[    1.631024] spi_imx 30840000.ecspi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 100000, post: 6, pre: 9
[    1.631224] spi_imx 30840000.ecspi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 100000, post: 6, pre: 9
[    1.631554] spi_imx 30840000.ecspi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 100000, post: 6, pre: 9
[    1.631754] spi_imx 30840000.ecspi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 100000, post: 6, pre: 9
[    1.631955] spi_imx 30840000.ecspi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 100000, post: 6, pre: 9
[    1.632155] spi_imx 30840000.ecspi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 100000, post: 6, pre: 9
[    1.632356] spi_imx 30840000.ecspi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 100000, post: 6, pre: 9
[    1.632557] spi_imx 30840000.ecspi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 100000, post: 6, pre: 9
[    1.632758] spi_imx 30840000.ecspi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 100000, post: 6, pre: 9
[    1.632958] spi_imx 30840000.ecspi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 100000, post: 6, pre: 9
[    1.633160] spi_imx 30840000.ecspi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 100000, post: 6, pre: 9
[    1.633360] spi_imx 30840000.ecspi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 100000, post: 6, pre: 9
[    1.633689] spi_imx 30840000.ecspi: mx51_ecspi_clkdiv: fin: 60000000, fspi: 100000, post: 6, pre: 9
[    1.643345] fb_st7789v: probe of spi2.0 failed with error -22
SCSFreedomX:~#

In any case I attached the whole dmesg output:
boot.txt (20.1 KB)

This is what happen in dmesg when I use the driver as module:
boot_as_mdule.txt (43.8 KB)

I also tried to delay (with “mdelay(3000)”) the init_display function in fb_st7789v.c, but the result is the same…

I’m really astonished about the behaviour of this kind of display… :((((

Any suggestion, test or idea is really appreciated!

Thank you very much!

Valerio

Hi @vbardelli,

I recommend you take a look at the links shared before with the Linux Documentation of this SPI display. As I have never used it, this is the best I can recommend you.

You might find this useful as well:

https://forums.raspberrypi.com/viewtopic.php?t=294784

The documentation from Linux Kernel v5.10 seems a bit better and I don’t expect the driver implementation ti diverge from the v5.4 which you are using:

Best regards,

Hi @henrique.tx , thanks for your response.

Now I understood something more about the problem, and I want to clean the discussion.

At the moment I’m using kernel 4.9. In the menuconfig of this kernel the driver for st7789v is under “staging” and not under “Device drivers > Graphic support > DRM > Panels” like in kernel 5. This is why I’m trying to use “display” mode in the device tree, instead the “panel”.

This is also because @shsasse (and another person, in another ticket How to show splash screen instead show booting output) said that they are able to use the display in this way.

Furthermore the kernel 4.9 is the only kernel where I’m able to bring up the display AS MODULE.

So, for the moment, I prefer to bring up the display on this version of kernel (4.9), the version that I have, at the moment, in use on my board, before to jump to BSP 5.

Is this possible?

Which version of kernel are you using @shsasse ?

Thanks a lot!

Valerio

Hi @vbardelli !

I don’t know how to continue using this older kernel would help you. Linux Kernel 5 and 6 indeed are keeping fb_st7789v.c as stagging. But they have the panel-sitronix-st7789v.c, that is not a stagging driver and is better documented.

And a little bit more about stagging drivers: The Linux Staging tree, what it is and is not. [LWN.net]

Best regards,

Dear @henrique.tx , I’m totally agree with you, I prefer to use the panel driver, instead of staging driver.

But I have to do it step by step. Because the only driver that works for me is “staging” driver in kernel 4.9 (AS MODULE) I started from it. As I wrote here:

now I’m able to have the driver integrated into kernel 4.9 (NOT as a module) and I have the splash screen. This is the first step.

Then I passed to kernel 5.4, and I tried to do the same (with “staging” driver, and the same device tree like in kernel 4.9). The strange thing is that the /dev/fb0 interface is correctly setup, but it doesn’t work (also with a simple “cat /dev/urandom > /dev/fb0”). This is quite surprising for me.

So I cut off “staging” driver and I tried with “panel” driver under drm. For this I enable “Direct Rendering Manager” in “Graphic support” under “Device Drivers”, and then “Sitronix ST7789V panel” under “Display Panels”.

Then I use this devicetree for this:

&iomuxc {	
	pinctrl_disp_gpio: disp_gpio_muxgrp {
		fsl,pins = <
			MX7D_PAD_ECSPI2_SS0__GPIO4_IO23      0x14  // DIS_RST   @ SODIMM 65
			MX7D_PAD_ENET1_RGMII_RD2__GPIO7_IO2  0x14  // DIS_D/CX  @ SODIMM 63
		>;
	};
};

&ecspi3 {
	// Enable the SPI controller
	status = "okay";
	
	// needed to avoid dtc warning
	#address-cells = <1>;
	#size-cells = <0>;

	mcp2515: can@0 {
		compatible = "microchip,mcp2515";
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_can_int>;
		reg = <0>;
		clocks = <&clk16m>;
		interrupt-parent = <&gpio5>;
		interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
		spi-max-frequency = <10000000>;
		status = "disabled";
	};

	spidev0: spidev@0 {
		compatible = "toradex,evalspi";
		reg = <0>;
		spi-max-frequency = <23000000>;
		status = "disabled";
	};
	
    panel@0 {
		compatible = "sitronix,st7789v";

		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_disp_gpio>;		
		
		reg = <0>;
		reset-gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
		backlight = <&pwm1>;
		power-supply = <&reg_module_5v>;
		spi-max-frequency = <100000>;
		spi-cpol;
		spi-cpha;
/*		
		port {
			panel_input: endpoint {
				remote-endpoint = <&tcon0_out_panel>;
			};
		};
*/		
	};

Where I commented “port” because I don’t know how to define it. Is it mandatory?

In this way I have no error in dmesg, but I don’t have any /dev/fb interface.

Is there anybody that are able to use this display via “drm” and “panel” driver (or a similar fb display)? Because I don’t see anybody that are using this interface and it’s very poor documented.

I there anyone that can address me to define the devicetree in the correct way? Also about the port?

Thanks a lot!

Valerio

Hi @vbardelli !

That is great! Congratulations :slight_smile: It is nice to see effort being paid off!

Again, I ask you to refer to the driver’s documentation, that was shared before.

I have never done it, but I think you need to connect the SPI display’s port to the lcdif’s node port. But you will need to create this port in the lcdif node, as it doesn’t exist.

You can try to do something like this:

&lcdif {
  port {
    spi_display: endpoint {
      remote-endpoint = <&panel_input>;
    };
  };
};

/* this the spi display panel you created*/
panel@0 {
  compatible = "sitronix,st7789v";
  
  /*...
  your configurations
  ...*/

  port {
    panel_input: endpoint {
      remote-endpoint = <&spi_display>;
    };
  };
};

Please be aware that I haven’t tested it (I do not possess this device).

Best regards,

Hi @henrique.tx and thanks a lot for your response!

Now I have a little improvement, and now I have “/dev/fb0” interface. To have this I follow your suggestion and:

  • comment out &lcdif node, in imx7-colibri.dtsi file;

  • add this in my .dts file (imx7d-colibri-emmc-eval-v3.dts, for the moment):

&lcdif {
  status = "okay";
  
  #address-cells = <1>;
  #size-cells = <0>;  

  port@0 {
    reg = <0>;
    spi_display: endpoint {
      remote-endpoint = <&panel_input>;
    };
  };
};

(keep attention to port@0, and to reg = <0>, without them I have no “/dev/fb0” interface)

  • add this in my .dts file, to &ecspi3 node, (imx7d-colibri-emmc-eval-v3.dts, for the moment):
    panel: panel@0 {
		compatible = "sitronix,st7789v";
		
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_disp_gpio>;		
		
		reg = <0>;
		
		reset-gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
		dc-gpios = <&gpio7 2 GPIO_ACTIVE_HIGH>;
		backlight = <&backlight>;
		power-supply = <&reg_module_5v>;
		spi-max-frequency = <20000000>;
		spi-cpol;
		spi-cpha;
		
		width = <240>;
		height = <320>;
		rotate = <270>;                  // Rotate to landscape            
		
		debug = <0x4000000>;             // Print init commands to the kernel log

		status = "okay";		
		
		  port {
			panel_input: endpoint {
			  remote-endpoint = <&spi_display>;
			};
		  };		
	};

Unfortunately I can’t see any penguins or boot on the display, and when I tried with “cat /dev/urandom > /dev/fb0” I see nothing on the display. The display is on.

Indeed I have the same, with kernel 5.4, if I use fb_st7789v “staging” driver: I see the “/dev/fb0” interface, but it doesn’t work…

I need to change some configurations between kernel 4.9 to kernel 5.4? Because my configuration works with kernel 4.9…

For sure I read the documentation that you suggest many times, but I can’t see any useful information about this…

Any suggestion or idea? I know that you don’t have this damned display, but I’m ready to do any test that you suggest…

Is there any person in the community that are using st7789v display (or something similar, for example ilitek) with kernel 5.4 and panel-sitronix-st7789v driver that can address me?

Many thanks!

Valerio

Hi @vbardelli !

Did you check the link I shared before: 1.54LCD ST7789v fbtft display at kernel 5.4 - Raspberry Pi Forums?

Maybe it can give you some hints. But to follow that, you should check if the driver is actually the same.

Best regards,

Hi @henrique.tx

yes, I also read 1.54LCD ST7789v fbtft display at kernel 5.4 - Raspberry Pi Forums, but it’s not useful, and, in any case they are using fb_st7789v.c staging driver, and not the panel driver:

Should I choice drivers/gpu/drm/panel/panel-sitronix-st7789v.c instead of drivers/staging/fbtft/fb_st7789v.ko ?

I’ll try with staging driver again, with kernel 5.4…

Valerio

Hi @henrique.tx and all community.

My assertion about fb0 interface creation (using “panel” driver under drm) after define port, inside lcdif node, is totally wrong, my fault, sorry.

Instead, if I comment lcdif node inside imx7-colibri.dtsi, and add port in lcif node in my device driver (like described in my 12 post), I don’t have any fb0 created.

So, I can’t create any fb0 interface with panel (under drm) and port.

What I see is, instead, that all boards, in linux dts directory, that are using a “panel” display, are using lvds and not lcdif. I also saw, in make menuconfig, that in Display Interface Bridges, SN65DSI83 mipi dsi to lvds bridge is selected. Could be this my problem?

Is there anyone that are using any kind of “panel” display on any king of Toradex SOM with kernel 5.4 and drm, and can kindly address me to configure devicetree accordingly?


In the mean time I made some progress using “staging” driver, in kernel 5.4…

If I change (what it works with kernel 4.9!):

		reset-gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
		dc-gpios = <&gpio7 2 GPIO_ACTIVE_HIGH>;

with:

        reset-gpios = <&gpio4 23 1>;
		dc-gpios = <&gpio7 2 0>;

Then, with “staging” driver, in kernel 5.4, the fb0 interface (that I already have), starts to work!

I’m really astonish about this: the gpio_active is different from a kernel version (4.9) to another (5.4)?!?

In any case, with kernel 5.4, I’m able to see some boot messages, but I don’ see any penguins and nor my splash… is it possible that the fb0 interface is created too late for the splash like described here?

Any idea or suggestion on how to solve also this problem?

Thanks a lot!

Valerio

Hi @vbardelli !

Toradex has a wide network of partners that could help you to integrate your device. If you want we can do the introduction.

Best regards,

Hi @henrique.tx , and thanks for your response.

It could be a solution… we can evaluate it… sitronix is one of your partners?

If not, which of your partners do you suggest to solve our problem?

Thank you.

Valerio

Hi @vbardelli !

Sorry for the delay.

I am afraid not.

You can check the available partners in the link from my previous message.

I will check internally and figure out how we can proceed. Most probably we will send you an email to talk about this.

Researching a bit more, I found this (RISCV) device that uses the same compatible string. This one doesn’t even use the port… Maybe you want to give a shot at this way of using it.

https://git.toradex.com/cgit/linux-toradex.git/tree/arch/riscv/boot/dts/canaan/sipeed_maixduino.dts?h=toradex_5.15-2.1.x-imx#n151

Also, this is an overlay that targets the same compatible (from the thread Waveshare 2.0 inch LCD ST7789V SPI drivers for kernel 5.4 - Raspberry Pi Forums). Again no use of the port:

When using the panel driver, have you ever checked the /sys/class/drm folder?

Best regards,

Hi @henrique.tx , and thanks for your response.

Your solution seems to me the same that I tried at the early stage, when I commented out the “port” part at all, see here:

In any case I can do a test, just to be sure.

Thanks, Valerio