Re: fbtft: 5 years in staging

["Noralf Trønnes" <noralf@tronnes.org>]

Den 02.02.2020 16.41, skrev Noralf Trønnes:
> 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.

Some info for anyone wanting to convert fbtft drivers:

The following drivers are MIPI DBI compatible (like the ones already
converted) which means they have the same protocol and share certain
commands. They are very easy to port over for anyone with access to
such a display.

- fb_hx8340bn.c
- fb_hx8353d.c
- fb_ili9340.c
- fb_ili9481.c
- fb_s6d02a1.c
- fb_st7789v.c
- fb_tinylcd.c (probably has an ili9486 chip)
- fb_ili9163.c

(library: drivers/gpu/drm/drm_mipi_dbi.c)

There is also an out-of-tree ili9325 driver that supports the protocol
used by fb_ili9320 and fb_ili9325, but it doesn't support their panels
(at least the register values differ):
https://github.com/notro/tinydrm/blob/master/ili9325.c

> 
> 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
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel