FBTFT drivers now in staging

[notro]

The FBTFT framebuffer drivers for small LCD displays, is now accepted in the staging tree:
https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/tree/drivers/staging/fbtft?h=staging-testing
They will probably enter in the 3.20 merge window.

Can these drivers be included in rpi-3.18.y?

The following config additions are also needed:

CONFIG_FB_TFT=m
CONFIG_FB_TFT_AGM1264K_FL=m
CONFIG_FB_TFT_BD663474=m
CONFIG_FB_TFT_HX8340BN=m
CONFIG_FB_TFT_HX8347D=m
CONFIG_FB_TFT_HX8353D=m
CONFIG_FB_TFT_ILI9320=m
CONFIG_FB_TFT_ILI9325=m
CONFIG_FB_TFT_ILI9340=m
CONFIG_FB_TFT_ILI9341=m
CONFIG_FB_TFT_ILI9481=m
CONFIG_FB_TFT_ILI9486=m
CONFIG_FB_TFT_PCD8544=m
CONFIG_FB_TFT_RA8875=m
CONFIG_FB_TFT_S6D02A1=m
CONFIG_FB_TFT_S6D1121=m
CONFIG_FB_TFT_SSD1289=m
CONFIG_FB_TFT_SSD1306=m
CONFIG_FB_TFT_SSD1331=m
CONFIG_FB_TFT_SSD1351=m
CONFIG_FB_TFT_ST7735R=m
CONFIG_FB_TFT_TINYLCD=m
CONFIG_FB_TFT_TLS8204=m
CONFIG_FB_TFT_UC1701=m
CONFIG_FB_TFT_UPD161704=m
CONFIG_FB_TFT_WATTEROTT=m
CONFIG_FB_FLEX=m
CONFIG_FB_TFT_FBTFT_DEVICE=m

This configuration change will trigger rpi-update issue #106

$ sudo modprobe fbtft_device name=rpi-display
ERROR: could not insert 'fbtft_device': Exec format error

$ dmesg
[ 1499.653760] backlight: exports duplicate symbol backlight_device_register (owned by kernel)

$ sudo rm /lib/modules/3.18.3+/kernel/drivers/video/backlight/backlight.ko
$ sudo depmod

$ sudo modprobe fbtft_device name=rpi-display
$

The reason this module changes from loadable to builtin, is that FB_TFT selects FB_BACKLIGHT which is a bool and thus BACKLIGHT_CLASS_DEVICE switches to builtin.

In my rpi-update kernels, I use this pre-install script as a fix:

find "${FW_REPOLOCAL}/modules" -mindepth 1 -maxdepth 1 -type d | while read DIR; do
    BASEDIR=$(basename "${DIR}")
    echo "     rm -rf ${FW_MODPATH}/${BASEDIR}/kernel"
    rm -rf "${FW_MODPATH}/${BASEDIR}/kernel"
done

This takes care not to remove out-of-tree modules in the extra directory.

[notro]

The Adafruit PiTFT - 2.8" Touchscreen is very popular.
This configuration change is needed to enable the necessary touch and gpio drivers:

CONFIG_TOUCHSCREEN_STMPE=y
CONFIG_GPIO_STMPE=y
CONFIG_MFD_STMPE=y
CONFIG_STMPE_I2C=y
CONFIG_STMPE_SPI=y

The touchscreen driver can be a module, but it doesn't autoload when the device is present.
The other modules can only be builtin.

[notro]

Also in linux-next: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/staging/fbtft

[pdp7]

@notro linux-next and gregkh staging is promising as the st7735 is of interest to me on several ARM boards. I asked Matt Porter if he was going to try to get his st7735fb driver merged into mainline (http://elinux.org/images/1/19/Passing_Time_With_SPI_Framebuffer_Driver.pdf) and he told he didn't believe any new framebuffer drivers would be merged as fbdev is being deprecated by Laurent Pinchart and others.

[notro]

he told he didn't believe any new framebuffer drivers would be merged as fbdev is being deprecated by Laurent Pinchart and others

I asked about that almost 2 weeks ago, and haven't gotten an answer yet: Is fbdev deprecated?
(I mention fbdbi in that post, but I have abandoned it now, and will integrate the work in staging/fbtft instead)
Since there's no answer on the mailing list, I guess the issue isn't all clear. At least the fbdev maintainers isn't taking the opportunity to make a statement

This is what Arnd Bergmann said in December:

We try to not have any new framebuffer drivers. Please consider making
this a DRM/KMS driver instead.

phoronix article a year ago: FBDEV Is Still Not Deprecated In The Linux Kernel

I'm working on some structural changes to fbtft that will provide better layering which will make it easy to move the drivers to DRM or any other graphics subsystem if that's needed.

[pdp7]

@notro thanks for the thorough update

[pelwell]

@notro:

The touchscreen driver can be a module, but it doesn't autoload when the device is present.
The other modules can only be builtin.

Can it be made to load using device tree?

[notro]

Yes, this is the overlay I use: https://github.com/notro/fbtft/blob/master/dts/overlays/rpi/pitft-overlay.dts

[notro]

It's in Linus' tree now: https://github.com/torvalds/linux/tree/master/drivers/staging/fbtft

[popcornmix]

@notro do you want to create a PR adding the staging fbtt drivers, the defconfig changes and the dtoverlay. I think as long as the new drivers are not loaded without being enabled through the overlay, then we're okay with this.

[notro]

@popcornmix how do you change the defconfig? Do you manually edit the files?

[popcornmix]

Edit your .config. Build run "make ARCH=arm savedefconfig" and copy defconfig into arch/arm/configs.

[notro]

Thanks.
How do we deal with rpi-update issue 106 that I mention in the first post of this issue?