Raspberry Pi and PiTFT display - problem with driver

Milan Obuch freebsd-arm at dino.sk
Sun Mar 8 19:44:50 UTC 2015


Hi,

I am trying to write a driver for PiTFT display, small 320x240 pixel
panel with touch screen. From software perspective, there are two
devices, touch screen controller with GPIO expander, STMPE610, and TFT
display controller/driver, ILI9341. Both are connected via SPI bus,
with one GPIO pin for the later.

This is where a problem is - I found a way how to use SPI bus to
program STMPE610, how to read and write to its register, at present,
read chip identification and set/reset GPIO used to control LED
backlight. I did it a bit hackish for now, using sysctl, but it is
simple to use and works. Definitive aproach should be to create a child
device, gpioc, possibly, but it is much more complicated and takes more
time to do.

ILI9341, on the other side, uses SPI with GPIO, so there is a question
how to do this - and, because this GPIO pin is used as 'command byte
flag', it is quite vital for proper function.

So, first, how can I describe this requirement in FDT? Currently, I
just put there simple fragment:

spi0 {
        ili0 {
                compatible = "st,ili";
                spi-chipselect = <0>;
        };

        tsc0 {
                compatible = "st,stmpe_tc";
                spi-chipselect = <1>;
        };
};

but this does not descibe fact ILI9341 uses one GPIO pin, in case of
PiTFT, GPIO 25. It is in some way similar to what gpioiic does, but
there is only one parent device, while I have two, spi bus and gpio
pin... I need some hint...

Second, I need some way to 'acquire' this pin in driver, so it is not
possible to change its status with gpioctl, and obtain correct values
for use in GPIOBUS_PIN_* calls to set pin's value.

Third, it is not yet clear to me how would be the best way to implement
this. According the docs, ILI9341 is programmed with series of short
data exchanges, with exactly one command byte send to device, being
flagged with active DC pin (connected to GPIO 25), followed with short
series of bytes being written to device or, in case of status read and
similar, being read from device, all with DC pin being inactive. DC is
short for 'data/command'.

Anybody out there with some hint? I will try to write something working
first, which will be surely not nice at the beginning, but it is much
easier to change something you know a bit about already...

Regards,
Milan


More information about the freebsd-arm mailing list