Hi,
Is it possible to add gpio-support to python to use the luma-lcd library for driving display via spi?
I found this fork,but it does nit yet support bpi-r3 and i have no idea how to include the lib into my python project
https://luma-lcd.readthedocs.io/en/latest/
Regards Frank
There is no support for using this display with tinydrm in Linux or why you want to drive it from userspace?
I have 2 of them from older rpi projects. As i got oled workin very easy and this a better resolution than the oled i would give it a try. I only want to print system info,so there is no need for full xserver. Driving them from userspace like the oled gives possibility to draw all information
Here is a way using spidev which maybe does not require gpio pin conversion,but uses again the adafruit libs
Btw.the display seems to be supported in staging with fb_tft,but how to draw to fb without xserver?
This looks related: https://pythonhosted.org/fbpy/
Based on http://www.lcdwiki.com/3.5inch_RPi_Display It uses an ILI9486 controller
There is an in-kernel driver for this display which exposes a framebuffer device – hence you can then open /dev/fb0 from userspace and draw around in it. No need for any hardware-specific knowledge in user-space, nor need for any vendor-specific libraries, …
config TINYDRM_ILI9486
tristate "DRM support for ILI9486 display panels"
depends on DRM && SPI
select DRM_KMS_HELPER
select DRM_GEM_DMA_HELPER
select DRM_MIPI_DBI
select BACKLIGHT_CLASS_DEVICE
help
DRM driver for the following Ilitek ILI9486 panels:
* PISCREEN 3.5" 320x480 TFT (Ozzmaker 3.5")
* RPILCD 3.5" 320x480 TFT (Waveshare 3.5")
If M is selected the module will be called ili9486.
i see here an example of dts entry
https://www.kernel.org/doc/Documentation/devicetree/bindings/display/ilitek%2Cili9486.yaml
is it possible to do it as overlay? i guess it does not compile overlay as the phandles are not resolved without the main dts
Yes, using DT-overlay would be the natural choice here. You don’t need to use phandle for that, just use DT overlay /plugin/ syntax and use target-path pointing to the SPI bus.
i used the target-path, but for reset/dc-gpio (have not looked what the latter exactly is) i need phandles to the gpio-controller
/dts-v1/;
/plugin/;
#include <dt-bindings/gpio/gpio.h>
/ {
compatible = "bananapi,bpi-r3", "mediatek,mt7986a";
fragment@0 {
target-path = "/soc/spi@1100b000";
__overlay__ {
#address-cells = <1>;
#size-cells = <0>;
display@0{
compatible = "waveshare,rpi-lcd-35", "ilitek,ili9486";
reg = <0>;
spi-max-frequency = <32000000>;
dc-gpios = <&pio 44 GPIO_ACTIVE_HIGH>; //pin 18
reset-gpios = <&pio 62 GPIO_ACTIVE_HIGH>; //22
//rotation = <180>;
//backlight = <&backlight>;
};
};
};
};
edit: updated overlay to have right gpio for r3 and added gpio.h include
That should not be a problem, the overlay should compile as-is and just add a record for the phandle which is then matched during runtime when U-Boot applies the overlay.
yes, you’re right, missed the gpio.h include 
mhm, board hangs after loading the module
spi@1100b000 {
pinctrl-names = "default";
#address-cells = <0x01>;
pinctrl-0 = <0x0b>;
clock-names = "parent-clk\0sel-clk\0spi-clk\0hclk";
interrupts = <0x00 0x8d 0x04>;
clocks = <0x04 0x04 0x04 0x1d 0x03 0x24 0x03 0x26>;
#size-cells = <0x00>;
compatible = "mediatek,mt7986-spi-ipm\0mediatek,spi-ipm";
status = "okay";
reg = <0x00 0x1100b000 0x00 0x100>;
phandle = <0x46>;
display@0 {
spi-max-frequency = <0x1e84800>;
reset-gpios = <0x02 0x3e 0x00>;
compatible = "waveshare,rpi-lcd-35\0ilitek,ili9486";
dc-gpios = <0x02 0x2c 0x00>;
reg = <0x00>;
};
};
root@bpi-r3:~# find /lib/modules/$(uname -r) -iname '*ili9486*'
/lib/modules/6.2.0-rc1-bpi-r3-rpidisplay/kernel/drivers/staging/fbtft/fb_ili9486.ko
/lib/modules/6.2.0-rc1-bpi-r3-rpidisplay/kernel/drivers/gpu/drm/tiny/ili9486.ko
root@bpi-r3:~# modprobe ili9486
[ 149.869776] SPI driver ili9486 has no spi_device_id for waveshare,rpi-lcd-35
[ 149.876861] SPI driver ili9486 has no spi_device_id for ozzmaker,piscreen
[ 149.884278] [drm] Initialized ili9486 1.0.0 20200118 for spi1.0 on minor 0
seems i cannot abort it with ctrl+c or similar 
any idea how to debug this? have only connected 1x 5v, 1x 3v3 and 1xGND + spi-pins including CS0 (no CS1), reset and the dc-pin (defined like above)…wonder if i need to set the CS in dts? and i’m not sure polarity is right…only found the wiki i linked above
Hi,
did you made a connection via ethernet? I’m trying to use an oled spi display by myself. So far I connected only a logic analyzer on the GPIO header. I noticed that as soon as I send some data via spidev, all LEDs on the ethernet ports are flashing for a second, hence I assume that some kind of reset is applied to the switch IC.
Can you confirm that observation?
The data is send correctly via SPI.
I also tried to use the SPI pins as simple GPIO and toggle them manually. But I was not able to reproduce that behavior.
Regards Alex
I did the tests with debug-uart and did not noticed a reset when using spi.
How does your dts look like?
I modified the mt7986a-bananapi-bpi-r3.dts from OpenWRT with
&pio {
...
spic_pins: spic-pins {
mux {
function = "spi";
groups = "spi1_0";
};
};
...
};
and
&spi1 {
#address-cells = <1>;
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&spic_pins>;
cs-gpios = <0>, <0>;
status = "okay";
spidev0: spidev@0 {
compatible = "rohm,dh2228fv";
spi-max-frequency = <1000000>;
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
};
};
The compatible string is because otherwise the kernel would complain about the directly listed spidev in DT
Mhm,had spidev recognized in my kernel,but did not know how to access my display over this because i did not get the luma-lcd module installed (missing gpio library for r3). I tried using display driver from kernel,but did not get it working yet
Could you just try the spidev? I would like to know if the reset of the switch occurs as well.
If i know how can i access the display through spidev…
Could you just send some data via spidev without display? Even in that case the switch seems to be reset.
I think I’m also seeing this, once I start communicating on the SPI port ( spi1.0 ) ( or the kernel initializes the device on there as set in my DTS ) Teh Ethernet LEDs flash and i stop getting Ethernet comms
I’ve been testing SPI communication ( with multiple CS pins on the SPIC port ):
root@openwrt:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=117 time=12.039 ms
64 bytes from 8.8.8.8: seq=1 ttl=117 time=13.262 ms
64 bytes from 8.8.8.8: seq=2 ttl=117 time=16.911 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 12.039/14.070/16.911 ms
root@openwrt:~# echo "test" > /dev/spidev1.0
root@openwrt:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
it does the same when I use “spidev1.1” ie. my other GPIO chipselect, so its probably not the CS pins ( something todo with the switch JTAG connections or are the SPIC pins shared with the MT7531 causing it to reset? )