[RFC] staging: fbtft: Moving fb_ili9341 (and others) to DRM
Daniel Matyas
matyasdaniel006 at gmail.com
Thu Nov 5 12:11:53 PST 2026
Hi,
I'm looking at the fbtft TODO (convert drivers to DRM) and want to check
whether fb_ili9341 can be dropped. Findings against v7.4-rc1:
1. fb_ili9341's init sequence is the MI0283QT-9A one. Comparing register
writes with drivers/gpu/drm/tiny/mi0283qt.c, the values are identical,
including the default gamma tables. Differences I found:
- mi0283qt writes EN3GAM (0xF2) = 0x08; the fbtft write is commented out.
- mi0283qt always sets MADCTL BGR; fbtft makes it configurable (bgr=).
- fbtft rotate=270 also sets ML; mi0283qt does not.
- Rotation maps as DRM rotation = fbtft rotate - 90 (mod 360).
- fbtft also offers runtime gamma adjustment.
2. fb_ili9341 registers the compatible "ilitek,ili9341", which is also the
fallback in the dt-schema binding, so it can match nodes that the DRM
drivers claim via their specific compatibles.
3. In-tree users: no defconfig enables FB_TFT. canaan_kd233 (62363a8e2f56, Feb 2021)
has a status = "disabled" panel node compatible with "canaan,kd233-tft",
"ilitek,ili9341". It predates the first DRM driver accepting ilitek,ili9341
(5a04227326b0, Jul 2021), and none of the DRM drivers match canaan,kd233-tft.
fbtft requests "dc" and "reset" GPIOs, which fits that node. I haven't tried
binding it. I suppose that, if the board is used, then it is built against the
fbtft driver.
4. fb_ili9341 has had only style/mechanical changes in recent years.
Questions:
a) Is removing fb_ili9341 acceptable, pointing users of other ILI9341
modules to panel-mipi-dbi? The KD233 node would then have no driver.
b) Or should KD233 panel support go into a DRM driver first? I don't have
its init sequence or physical size, or the board...
c) Is removal of all of fbtft already planned?
d) Several other fbtft drivers have drm counterparts. Should I inspect those
to see if removal is needed?
I have not tested on hardware.
Thanks,
Daniel M
More information about the linux-riscv
mailing list