fbtft: 5 years in staging

Noralf Trønnes noralf at tronnes.org
Sun Feb 2 15:41:54 UTC 2020


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


More information about the dri-devel mailing list