Hi,
Since I'm the original author of fbtft I thought I'd highlight a couple of issues that's probably not well known.
Right after fbtft was added, fbdev was closed for new drivers[1] and the fbdev maintainer wanted to remove fbtft as a consequence of that decision, but Greg KH said he'd keep fbtft drivers in staging "until a matching DRM driver is present in the tree"[2].
There are 2 issues wrt the goal of making a matching DRM driver (strictly speaking). One is impossible to do (policy), the other is unlikely to happen:
1. Device Tree 'init' property
All fbtft drivers have controller setup code that matches one particular display panel. From the start of fbtft it was possible to override this using platform data. Later when Device Tree support was added, an 'init=' property to do the same was added.
Example: init = <0x10000e5 0x78F0 0x1000001 0x0100 0x2000032 0x1000007 0x0133>;
This translates to: register_write(0x00e5, 0x78F0); register_write(0x0001, 0x0100); mdelay(32); register_write(0x0007, 0x0133);
AFAIU setting register values from DT is a no-go, so this functionality can't be replicated in a DRM driver. Many displays are made to work using this mechanism, in particular ili9341 based ones.
2. Parallel bus interface
All fbtft drivers support both a SPI and a parallel bus interface through the fbtft helper module. Many (not all) controllers support more than one interface. The parallel bus support was added to fbtft in its early days when not many SPI displays were available (nowadays there's lots to choose from). fbtft uses bitbanging to drive the parallel interface so it's really slow, even more slow than SPI and SPI with DMA beats it thoroughly. I know there are people that use the paralell bus support, but I don't see much point in it unless we get a parallel bus subsystem that can use the dedicated hw on certain SoC's (Beaglebone, Pi). And those SOC's most likely have a parallel video/RGB bus as well, which IMO is a much better option for a panel.
The following drivers have DRM counterparts that have the same panel setup code:
- fb_hx8357d.c: drivers/gpu/drm/tiny/hx8357d.c - fb_ili9341.c: drivers/gpu/drm/tiny/mi0283qt.c - fb_st7735r.c: drivers/gpu/drm/tiny/st7735r.c - fb_ili9486.c: Patches are posted on dri-devel[3]
But they don't support all panels based on that controller and they don't have parallel bus support.
There is actually also another obstacle for conversion and that is, some of the displays (for which there is builtin driver support) might be impossible to source except as second hand. And it's not always obvious which panel is supported by a certain driver. At least the displays supported by these drivers are listed as discontinued on the fbtft wiki[4]: - fb_hx8340bn.c - fb_hx8347d.c - fb_ili9320
This one never made it from a prototype to an actual product, because it was too slow: - fb_watterott.c
I have no plans to convert fbtft drivers myself, but I figured a 5 year anniversary was a good excuse for a status update.
Noralf.
[1] https://lkml.org/lkml/2015/9/24/253 [2] https://lkml.org/lkml/2016/11/23/146 [3] https://patchwork.freedesktop.org/series/72645/ [4] https://github.com/notro/fbtft/wiki/LCD-Modules#discontinued-products