Support for ILI9341, ILI9225, ST7735R, ST7586

[dlech]

I am replying to raspberrypi/linux#1270 (comment) here.

I maintain Linux drivers for a number of LEGO MINDSTORMS compatible products that use the displays listed above. I've been using the fbtft drivers for these, but since is sounds like those won't be around forever, I'd like to get them implemented here.

I'm willing to do the coding and testing for these chips, just point me in the right direction.

[notro]

There's nothing to do yet. I'll let you know when the drm maintainers have accepted the tinydrm core modules.

[dlech]

Status update:

• ST7586 is in 4.14 kernel
• ILI9225 is submitted
• Getting ready to start on ST7735R

@ladyada, I'm getting ready to work on a driver for the Adafruit 1.8" TFT breakout board (ST7735R). Who at Adafruit would like to be CCed when I submit the patch?

[ladyada]

oh wow that would be awesome. yes please cc me and let me know how you want me to test. i also have a nice 240x240 ST7789 panel id like to add (its 99% same as '7735)

[dlech]

What is the 1% that is different?

[ladyada]

just the init code
https://github.com/adafruit/Adafruit-ST7735-Library/blob/ST77xx/Adafruit_ST7789.cpp

[dlech]

Hi @ladyada,

I've sent the patches to the mailing lists and CCed you. I guess you just need to test that it works for whatever you like to do with these displays. You could also test all of the rotations to make sure I got it right.

I've pushed the code to https://github.com/dlech/ev3dev-kernel/tree/st7735r in case it is easier for you to check it out that way, but I think the patches should work with any 4.14 kernel.

[dlech]

I also found this: torvalds/linux@7142afb

Not sure if the "V" at the end makes a difference or if it is the same controller you mentioned.

[ladyada]

ooh interesting ok its all done over mailing lists - what if i have changes? i should send a PR to...your repo?

are you using a raspi to test?

[dlech]

Yeah, this is going in the mainline kernel. 😉

If you have suggested changes, you can just mention them inline in a reply-all to the email so that everyone on the mailing lists will be able to see it too. (Make sure your email client is configured for plain text, otherwise the mailing lists will reject your reply email). You can see an example of this in one of my previous drivers (scroll down to the Comments section).

I'm actually using a LEGO MINDSTORMS EV3 to test: http://www.ev3dev.org/news/2015/07/24/Color-LCD-on-the-EV3/

It should be easy enough to test with RPi or BeagleBone. I know that BeagleBone will boot using omap2plus_defconfig, not sure which defconfig to use for RPi though. You will need to modify the device tree (or create an overlay) based on the example in the first patch.

[ladyada]

kk for my future reference https://github.com/dlech/ev3dev-kernel/tree/st7735r/drivers/gpu/drm/tinydrm

wrt to the ST7735, it doesnt look like the devtree options currently has options to set display size/offset. that would be very useful because the sizes of the displays varies. so i would want to add that :)

that link to the ST7789V is in video mode only, not SPI...many of these chips have a wide interfacing range.

is this a good time to add any/all display drivers i have access to? e.g. HX, other ST's & ILI's, eInk... ? looks like the framework is very easy to use and adapt for new chipsets

[dlech]

it doesnt look like the devtree options currently has options to set display size/offset. that would be very useful because the sizes of the displays varies. so i would want to add that :)

That would be a good thing to mention on the mailing list and see what the experts say. (I have more to say on the subject, but I'll save that for the mailing list).

that link to the ST7789V is in video mode only, not SPI...many of these chips have a wide interfacing range.

Right. The commit message says something to the effect of "tinydrm support can be added later". I'm not sure exactly how to do that without breaking things at this point, but maybe @notro can enlighten us. I think it would just be a matter of adding an optional dc-gpios device tree property and then modifying the driver to use tinydrm if it is present or work as-is if it is absent.

is this a good time to add any/all display drivers i have access to?

I don't see why not 😃

I have a couple displays with ILI9341 controllers, so that is next on my list (one is Adafruit 2.8" resistive touch screen for RPi).

[notro]

it doesnt look like the devtree options currently has options to set display size/offset. that would be very useful because the sizes of the displays varies. so i would want to add that :)

AFAICT it's difficult to model complex controllers using Device Tree properties without having tons of properties. At least I haven't found a way to decribe a panel/controller combination with it's power/timing/etc settings in a generic way.
And I was specifically told that setting registers from Device Tree was not allowed so we can't have generic drivers like fbtft in effect has.
So I think we need to add a compatible string for each display we support. One driver can support many displays.
Simple controllers can get away with DT properties: https://www.kernel.org/doc/Documentation/devicetree/bindings/display/ssd1307fb.txt
Is st7735 so simple that it can be described in a similar way?

one is Adafruit 2.8" resistive touch screen for RPi

This one is supported by mi0283qt: https://github.com/notro/tinydrm/blob/master/rpi-overlays/pitft28-resistive-overlay.dts

ST7789V

I brought up the issue when that driver was reviewed but without a conclusion. I don't think it's a good idea to have a tinydrm driver in drm/panel. The drm/panel drivers are for MIPI DSI/DPI panels that have a dedicated pixel bus/interface with special DT properties connecting display controller and panel controller (Documentation/devicetree/bindings/display/panel/sitronix%2Cst7789v.txt). tinydrm is targeted at controllers that can take pixel data over the "control" bus.
Probably best to make a new driver and call it st7789, without the V.

I'm all ears if there are other ways to do this, I'm no expert on the panel side of things, how they differ and if in reality only one type of panel exists for a controller making it possible to use just a few DT properties to describe it.

[ladyada]

its not so much that you need specific registers, as we can 're-word' them to properties that make more sense like "color_order" "width" "height" "left_offset" and "right_offset". its a bit of a struggle to predict future panels. basically the driver chip is always the same but the way it is wired to the panel itself varies for every device :)

[ladyada]

@dlech wrt to the mailing list, i just subscribe and then respond to the post in text?

overall, i rather prefer a ton of device-tree switches. they're free, and better than having one device per TFT model (yuk)

[dlech]

@dlech wrt to the mailing list, i just subscribe and then respond to the post in text?

I think all of these mailing lists are open, so you shouldn't have to subscribe to any of them. You might want to subscribe to the DRM mailing list though, just to get familiar with it since it sounds like you may be submitting some of your own patches soon(ish).

And like I said previously, make sure your email client is configured for text-only (no HTML) and reply-all.

[dlech]

Hi @ladyada, I never saw any comments from you via email. I just wanted to make sure that you saw the patches (sent v3 just now) and you didn't have anything to say (as opposed to me using a bad email address or something like that).

[ladyada]

yeah im sorry >.< its been the busiest time of the year. my free time starts in about 2 days when all the holiday shopping is over ;) i did see all the emails, i have them in a sub-inbox

[pdp7]

@dlech @notro do you know how I can test st7735r with libdrm modtest?

I does not seem to be an option in the latest version at https://dri.freedesktop.org/libdrm/ or in https://github.com/freedreno/libdrm (per the wiki)

Background info:
I am trying to use the tinydrm st7735r driver with the Adafruit 1.8" TFT on a BeagleBone Black:

root@beaglebone:~/# dmesg |grep spi
[   20.546768] [drm] Initialized st7735r 1.0.0 20171128 for spi1.0 on minor 0
[   21.627551] st7735r spi1.0: fb0:  frame buffer device

root@beaglebone:~# cat /sys/kernel/debug/dri/0/name
st7735r dev=spi1.0 unique=spi1.0

root@beaglebone:~# ls -ltar /dev/fb0 
crw-rw---- 1 root video 29, 0 Feb 21 08:49 /dev/fb0

More info in this gist

[notro]

tinydrm uses dumb buffers (no special GPU buffers) so it doesn't have special handling.

# Show info
modetest -M st7735r
# Show test image
modetest -M st7735r -s <connector_id>:128x160

https://github.com/notro/tinydrm/wiki/Development#modetest

[pdp7]

@notro thanks! modetest does appear to run ok. No output on the LCD so I will recheck my device tree settings.

debian@beaglebone:~/libdrm/tests/modetest$ ./modetest -M st7735r |head
Encoders:
id	crtc	type	possible crtcs	possible clones	
31	30	none	0x00000001	0x00000000

Connectors:
id	encoder	status		name		size (mm)	modes	encoders
28	31	connected	Virtual-1      	35x28		1	31
  modes:
	name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
  160x128 0 160 160 160 160 128 128 128 128 1 flags: ; type: preferred, driver

debian@beaglebone:~/libdrm/tests/modetest$ sudo ./modetest -M st7735r -s 28:160x128 
setting mode 160x128-0Hz@XR24 on connectors 28, crtc 30

debian@beaglebone:~/libdrm/tests/modetest$ find |grep modetest^C
debian@beaglebone:~/libdrm/tests/modetest$ sudo ./modetest -M st7735r -s 28:160x128 -v
setting mode 160x128-0Hz@XR24 on connectors 28, crtc 30
freq: 37.50Hz
freq: 37.43Hz

For anyone interested, here is a discussion thread about using this Adafruit 1.8" TFT LCD with tinydrm on BeagleBone.

[pdp7]

I now have the Adafruit 1.8" LCD with the tinydrm st7735r driver. @dlech pointed out that I had the DC and RESET pins swapped in the device tree overlay file I'm using. It's great to see the modetest colorbars!

[dlech]

Just submitted the final display I am currently interested in, so calling this closed.