notro / panel-mipi-dbi Goto Github PK

View Code? Open in Web Editor NEW

11.0 11.0 1.0 2 KB

Python 100.00%

panel-mipi-dbi's People

Contributors

Stargazers

Watchers

Forkers

rhgndf

panel-mipi-dbi's Issues

Can mipi-dbi-spi work with ili9488?

I tried to run 3.5 inch LCD with driver ili9488 in 4-line SPI mode on fbtft overlay, but this driver (ili9488) does not support RGB565 mode in 4 line SPI. If driver init with RGB666, then i`m take wrong pictrure on the screen...

Can you explain to the newbie how to run this display (9488) using mipi-dbi-spi?

PS: Raspberry 3b, 5.15.36-v7+

fbtft conversion

@notro Thanks for the great work on this. I'm trying to figure out how to convert an existing working sequence to panel-mipi-dbi and ran into some issues.

I dumped an fbtft log of the init:

fbtft_write_reg8_bus8: 11
fbtft_write_reg8_bus8: 3a 05
fbtft_write_reg8_bus8: b2 05 05 00 33 33
fbtft_write_reg8_bus8: b7 75
fbtft_write_reg8_bus8: c2 01 ff
fbtft_write_reg8_bus8: c3 13
fbtft_write_reg8_bus8: c4 20
fbtft_write_reg8_bus8: bb 22
fbtft_write_reg8_bus8: c5 20
fbtft_write_reg8_bus8: d0 a4 a1
fbtft_write_reg8_bus8: 29
fbtft_write_reg8_bus8: 21
fbtft_write_reg8_bus8: 36 c0
fbtft_update_display(start_line=0, end_line=134)
fbtft_write_reg8_bus8: 2a 00 00 00 ef
fbtft_write_reg8_bus8: 2b 00 00 00 86
fbtft_write_reg8_bus8: 2c
fbtft_write_vmem16_bus16(offset=0, len=64800)
fbtft_write_spi(len=64800): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...
fbtft_write_reg8_bus8: e0 d0 05 0a 09 08 05 2e 44 45 0f 17 16 2b 33
fbtft_write_reg8_bus8: e1 d0 05 0a 09 08 05 2e 43 45 0f 16 16 2b 33

I created an equivalent initialization file panel.bin in /lib/firmware:

command 0x11 # exit_sleep_mode
delay 120

command 0x3a 0x05 # pixel format

command 0xb2 0x05 0x05 0x00 0x33 0x33 
command 0xb7 0x75
command 0xc2 0x01 0xff
command 0xc3 0x13
command 0xc4 0x20
command 0xbb 0x22
command 0xc5 0x20
command 0xd0 0xa4 0xa1

command 0x29 # on
command 0x21 # invert
command 0x36 0xc0 # address mode
command 0x2a 0x00 0x00 0x00 0xef # column address
command 0x2b 0x00 0x00 0x00 0x86 # page address

command 0xe0 0xd0 0x05 0x0a 0x09 0x08 0x05 0x2e 0x44 0x45 0x0f 0x17 0x16 0x2b 0x33
command 0xe1 0xd0 0x05 0x0a 0x09 0x08 0x05 0x2e 0x43 0x45 0x0f 0x16 0x16 0x2b 0x33

It doesn't come with the screen clear but everything else is the same.

I create the device tree overlay:

			display@0 {
				compatible = "panel", "panel-mipi-dbi-spi";
				reg = <0>;
				spi-max-frequency = <40000000>;
				
				dc-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>; # copied from fbtft
				reset-gpios = <&gpio GPIOX_18 GPIO_ACTIVE_LOW>; # copied from fbtft
				write-only;
				
				backlight = <&display_backlight>;

				width-mm = <25>;
				height-mm = <15>;
				
				spi-cpol;
				spi-cpha;
				
				status = "okay";
				panel-timing {
					hactive = <135>;
					vactive = <240>;
					hback-porch = <0>;
					vback-porch = <0>;
					clock-frequency = <0>;
					hfront-porch = <0>;
					hsync-porch = <0>;
					hsync-len = <0>;
					vfront-porch = <0>;
					vsync-len = <0>;
				};
			};

For some reason, I have to manually modprobe panel-mipi-dbi. Is this expected?

I get the following dmesg after modprobe panel-mipi-dbi:

panel-mipi-dbi-spi spi0.0: Looking up power-supply from device tree
panel-mipi-dbi-spi spi0.0: Looking up power-supply property in node /soc/bus@c1100000/spi@8d80/display@0 failed
panel-mipi-dbi-spi spi0.0: supply power not found, using dummy regulator
[drm] Initialized panel-mipi-dbi 1.0.0 20220103 for spi0.0 on minor 2
panel-mipi-dbi-spi spi0.0: [drm] fb1: panel-mipi-dbid frame buffer device

The CS pins on SPI do not activate like with fbtft. I manually try to dump some data:

sudo dd if=/dev/zero of=/dev/fb1 bs=2
dd: error writing '/dev/fb1': No space left on device
32401+0 records in
32400+0 records out
64800 bytes (65 kB, 63 KiB) copied, 0.273157 s, 237 kB/s

However nothing is drawn on the screen and SPI CS never goes to ground. The reset line is stuck on low unlike just blinking with fbtft.

Any ideas? I'm on Linux 6.1.

Drop the need of command file for panels w/o vendor-specific commands

Sipeed MaixSense has a LCD panel that does not need any vendor-specific commands to initialize (because all configuration is programmed into OTP).

For this kind of panels, only MIPI DCS commands are needed.

Should we implement the generation of MIPI DCS control stream in panel-mipi-dbi and drop the need of command file?

See sipeed/linux@b0038b7 for an example.

Is it possible to specify firmware in config.txt

I defined content of firmware for ST7796S driver (included - could be usefull for someone):

# ST7796S 
# 480x320
command 0xB0 0x00
command 0x11
delay 255
command 0x3a 0x55 # pixel format RGB565
command 0x36 0x28 # address mode (madctl)
command 0xe0 0xf 0x1f 0x1c 0xc 0xf 0x8 0x48 0x98 0x37 0xa 0x13 0x4 0x11 0xd 0x0 
command 0xe1 0xf 0x32 0x2e 0xb 0xd 0x5 0x47 0x75 0x37 0x6 0x10 0x3 0x24 0x20 0x0 
command 0xe2 0xf 0x32 0x2e 0xb 0xd 0x5 0x47 0x75 0x37 0x6 0x10 0x3 0x24 0x20 0x0 
#found not needed: command 0x36 0x28 # address mode (madctl) again?
command 0x11 
command 0x29

I defined following fragment in config.txt

#
dtoverlay=mipi-dbi-spi,spi0-0,speed=32000000
dtparam=width=480,height=320,width-mm=85,height-mm=57
dtparam=write-only
dtparam=reset-gpio=25,dc-gpio=24

When I copy st7796.bin into /lib/firmware as panel.bin, all is fine. However I see in mipi-dbi-spi-overlay.dts that it's possible to override as well 'compatible'. I hoped that with this I can have my firmware named st96.bin
I'm not able to make it working. Once i write compatible=st7796 (using coma to dtoverlay or as dtparam) - LCD is not initialized, nothing in dmesg.
Is it possible to specify name of firmware in config.txt? (how?)

Any way to re-initialize display?

Sometimes my display gets disconnected or loses power for whatever reason. Currently my only option to re-initialize the display is to reboot. I tried unloading and reloading the kernel modules but it didn't do anything. Is there a way to manually trigger a re-initialization of the display?

mipi_dbi_typec3_command quirk for 16 bit parallel interfaces

mipi_dbi_typec3_command setups 8 bpw transfers over SPI

mipi_dbi_spi_transfer(spi, speed_hz, 8, cmd, 1);

Should a quirk or parameter for devices that are behind 16-bit parallel interfaces but communicate over SPI? Or maybe arbitrary bit interfaces?

Otherwise the data gets kind of clobbered. I know these hacked displays are not the primary target of panel-mipi-dbi but it would be good to support with one driver.

ST7796S

This init command sequence works on this ST7796S lcd: http://www.lcdwiki.com/4.0inch_SPI_Module_ST7796
It is taken from: https://github.com/Bodmer/TFT_eSPI/blob/master/TFT_Drivers/ST7796_Init.h

delay 120
command 0x01
delay 120
command 0x11
delay 120
command 0xF0 0xC3
command 0xF0 0x96
command 0x36 0x48
command 0x3A 0x55
command 0xB4 0x01
command 0xB6 0x80 0x02 0x3B
command 0xE8 0x40 0x8A 0x00 0x00 0x29 0x19 0xA5 0x33
command 0xC1 0x06
command 0xC2 0xA7
command 0xC5 0x18
delay 120
command 0xE0 0xF0 0x09 0x0b 0x06 0x04 0x15 0x2F 0x54 0x42 0x3C 0x17 0x14 0x18 0x1B
command 0xE1 0xE0 0x09 0x0B 0x06 0x04 0x03 0x2B 0x43 0x42 0x3B 0x16 0x14 0x17 0x1B
delay 120
command 0xF0 0x3C
command 0xF0 0x69
delay 120
command 0x29

This works nicely with xfce4 on a RPI4, but I have some questions related to this driver:

How do I set the rotation using the dts file? I have been modifying the command sequence above
Is any of the firmware files upstreamed?

Interfacing with standard DRM?

I attempted to use this to create a panel used for an Allwinner LCD controller but found it didn't make the calls to the drm subsystem to register the panel. The panel takes commands over SPI but data over an RGB signal.

Is this an intentional design choice or lacking feature?

The screen is still black after the driver is finished

Error code:

[    3.622226] sun6i-spi 1c69000.spi: chipselect 0 already in use
[    3.622264] spi_master spi0: spi_device register error /soc/spi@1c69000/panel@0
[    3.622325] spi_master spi0: Failed to create SPI device for /soc/spi@1c69000/panel@0

panel-mipi-dbi-spi.dts:

/dts-v1/;
/plugin/;
 
 / {
      compatible = "allwinner,sun8i-h2+";
 
         fragment@0 {
                 target = <&spi1>; // spi总线
                 __overlay__ {
                        /* needed to avoid dtc warning */
                         #address-cells = <1>;
                         #size-cells = <0>;
 
                         status = "okay";
 
                         panel: panel@0 {
                                 compatible = "panel-mipi-dbi-spi";
                                 reg = <0>;
                                 spi-max-frequency = <32000000>;
 
                                 width-mm = <20>;
                                 height-mm = <20>;

                                 reset-gpios = <&pio 0 199 0>; // reset引脚
                                 dc-gpios = <&pio 0 198 0>; // dc引脚
                                 write-only;
 
                                 timing: panel-timing {
                                         hactive = <160>; // 横向分辨率
                                         vactive = <128>; // 纵向分辨率
                                         hback-porch = <0>;
                                         vback-porch = <0>;

                                         clock-frequency = <0>;
                                         hfront-porch = <0>;
                                         hsync-len = <0>;
                                         vfront-porch = <0>;
                                         vsync-len = <0>;
                                 };
                         };
                 };
         };
 };

Why I can't create SPI device???

Bug in panel-timing verification?

Hey, I have a small Winstar 160x80 TFT LCD display that I wrote a custom driver for, but then I found this generic driver which seems to be a great option. I have however one issue. When adding my display, I use the following panel-timings for devicetree:

                timing: panel-timing {
                        hactive = <160>;
                        vactive = <80>;

                        vback-porch = <0x1a>;
                        vfront-porch = <0x69>;
                        vsync-len = <0>;

                        hback-porch = <0x01>;
                        hfront-porch = <0xa0>;
                        hsync-len = <0>;

                        clock-frequency = <0>;
                };

This is required since my display has both a back-poch and front-porch. But when inserting the above values and loading the driver, it bails out with:

panel-mipi-dbi-spi spi0.0: /n_ahb@e0000000/spi@e0011000/display@0: panel-timing out of bounds

So I read through the code, and found this check here which I do not fully understand:

        if (!mode->hdisplay || !mode->vdisplay || mode->flags ||                                  
            mode->hsync_end > mode->hdisplay || (hback_porch + mode->hdisplay) > 0xffff ||          
            mode->vsync_end > mode->vdisplay || (vback_porch + mode->vdisplay) > 0xffff) {          
                dev_err(dev, "%pOF: panel-timing out of bounds\n", dev->of_node);                 
                return -EINVAL;                                                                   
        }

Given the input above to devicetree, adding a few prints to the driver tells me during probe that the different values are:

<3>[  221.200790][ T4625] panel-mipi-dbi-spi spi0.0: PANEL: htotal              : 0x141
<3>[  221.201017][ T4625] panel-mipi-dbi-spi spi0.0: PANEL: vtotal              : 0xd3
<3>[  221.201222][ T4625] panel-mipi-dbi-spi spi0.0: PANEL: hdisplay            : 0xa0
<3>[  221.201428][ T4625] panel-mipi-dbi-spi spi0.0: PANEL: vdisplay            : 0x50
<3>[  221.201543][ T4625] panel-mipi-dbi-spi spi0.0: PANEL: flags               : 0x0
<3>[  221.201746][ T4625] panel-mipi-dbi-spi spi0.0: PANEL: hsync_end           : 0x140
<3>[  221.202088][ T4625] panel-mipi-dbi-spi spi0.0: PANEL: vsync_end           : 0xb9
<3>[  221.202214][ T4625] panel-mipi-dbi-spi spi0.0: PANEL: clock               : 0x0
<3>[  221.202426][ T4625] panel-mipi-dbi-spi spi0.0: PANEL: C: hback_porch (LO) : 0x1
<3>[  221.202631][ T4625] panel-mipi-dbi-spi spi0.0: PANEL: C: vback_porch (TO) : 0x1a

The part of the panel-timing check above that always fails are:
mode->hsync_end > mode->hdisplay (and corresponding vsync_end)
Reading https://www.kernel.org/doc/Documentation/devicetree/bindings/display/panel/panel-timing.yaml leads me to believe that:

hsync_end is hback_porch + hactive + hfront_porch => 0x140
hdisplay is the pixel width of the display => 0xa0
Uhm, but then hsync_end will always be bigger than hdisplay if you have back/front-porch, and the check will always fail,... ?

If I change the check (replace hdisplay with htotal and vdisplay with vtotal), then the driver loads perfectly fine and my display works exactly as it should, with correct back-porch etc.

Now, is this a bug, or am I completely misunderstanding something here? :o)

Best Regards
Stefan Nilsson

Can panel-mipi-dbi work with a RAiO RA8889 TFT LCD Controller chip based display?

Hi,

Would it be possible to get a RAio RA8889 based display working with the panel-mipi-dbi driver? It is about the display that is in an EdgeLogix-RPI-1000 industrial controller. A friend and I have been trying to get the display working for weeks. The EdgeLogix-RPI-1000 is built around a Raspberry Pi compute module 4. The display is connected to the CM4 via SPI. The CM4 runs Raspberry Pi OS (Debian 11) with a 6.1.61 kernel. In the meantime we have tried with panel-mipi-dbi, fbtft and anyspi without success. I've added a link to a recent kernel log and a link to an English datasheet for the RA8889 at the bottom.

If you need more information or something we can test, please let us know.

Any help is welcome. Thank you in advance.

dmesg log:
https://pastebin.com/kbk5YZVm
RA8889 datasheet
https://www.raio.com.tw/Data_raio/Datasheet/RA88%20Series/Completed/RA8889_DS_V13_Eng.pdf