search

notro / fbtft

Linux Framebuffer drivers for small TFT LCD display modules. Development has moved to https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/tree/drivers/staging/fbtft?h=staging-testing
1.86k stars 494 forks source link

Is it possible to use two or more SPI displays (not simultaneously)? #42

Closed vlad-ivanov-name closed 10 years ago

vlad-ivanov-name commented 11 years ago

For example, i need to drive 4 small SPI displays. According to SPI specification, i can use slave select (SS) to select display i need to drive. But, does display controller need some initialization or just changing SS will be enough?

notro commented 11 years ago

The SPI controller supports 3 chip selects, but only 2 of them is brought out on the header: CE0 and CE1. This makes it possible to drive 2 displays at the same time. What do you mean by not simultaneously? All displays are connected and initialized, but not updated at the same time? If so, that is tricky. I have read posts where people are using some kind of multiplexing on the chip selects to get more of them, and using a gpio to control it. But they do everything from userspace, and have full control of when transfers happen. You could in theory load the drivers for two displays, switch the multiplexer output, and then load 2 more drivers. For this to work you need to make sure that nothing writes to the devices/drivers that is not connected to their displays. For instance there is a blanking timeout of 30 minutes. When that kicks in, all 4 devices will update their displays at the same time, and you have problems. I wish we had more chip selects, and have thought of adding that support to spi_bcm2708, which is the SPI master driver. But I have more than enough work on the fbtft project, so I have never gotten around to it.

vlad-ivanov-name commented 11 years ago

Thank you for explanation. Looks like connecting 3+ displays to RPi is a kind of difficult work; there are some SPI perepherical controllers like MAX3421E, but kernel driver should be completely rewritten in this case. Another solution, as i have understand, is switching multiplexer output every minute to refresh image on displays that do not need to be updated. This is a dirty hack, however.

timothybrown commented 11 years ago

I've seen a kernel module that adds "fake" CS pins to the /dev tree for the SPI bus. The idea was to allow interaction with more SPI devices through userland. In that case you would just hook the device up to a spare GPIO and manipulate that directly from your software as a CS, while still having access to the SPI bus through /dev, if that makes any sense?

Anyway, I saw talk of modifying that module so those "fake" CE3, CE4, etc. entries would correspond to real GPIO pins and actually function as chip selects. Could that be a viable solution?

notro commented 11 years ago

It's hard to comment on that module when I haven't seen the code. The best solution would be to patch spi_bcm2708. This patch, among other things, controls CE0 and CE1 through software instead of letting hardware do it. It could be used as a starting point: https://github.com/msperl/linux/pull/1/files

asmecher commented 10 years ago

@resetnow, you might want to look at the binocular driver I wrote for the SSD1331 at https://github.com/asmecher/fbtft/commit/0283653dae7ac21f2961420253d3d77ed7fe8ad9. It moves the CS line control into the driver rather than delegating it to the SPI interface itself, which allows me to combine two SSD1331s into a single FB device. Since it interacts with the CS lines as simple GPIO pins, the same approach could be applied to support many devices using other GPIO pins. More information at http://cassettepunk.com/blog/2013/11/12/view-master-video-player-hacking/.

notro commented 10 years ago

Closing issue since there has been no activity for more than 2 months. Reopen if needed.