[RFC] staging: fbtft: Moving fb_ili9341 (and others) to DRM
Andy Shevchenko
andy.shevchenko at gmail.com
Sat Nov 7 03:40:28 PST 2026
On Fri, Nov 6, 2026 at 7:10 PM Daniel Matyas <matyasdaniel006 at gmail.com> wrote:
>
> On Thu, Nov 05, 2026 at 10:47:06PM +0100, Nam Cao wrote:
> > Daniel Matyas <matyasdaniel006 at gmail.com> writes:
> > > 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?
> >
> > IIRC the main reason fbtft needs to stay is because it supports parallel
> > interface which is missing in the DRM drivers.
> >
> > Nam
>
> Thank you for clarifying. However, the fb_ili9341 driver uses only the
> SPI interface.
Only two drivers use that macro, indeed:
drivers/staging/fbtft/fb_ili9341.c, line 136
drivers/staging/fbtft/fb_sh1106.c, line 173
> Is it alright then to move (or remove) those drivers that only use
> SPI interface and have DRM counterparts?
You can suggest removing it, but it might break some users (yes, I
understand that FBTFT is a staging driver), but doing such only for
two out of dozens drivers seems to me a bit inconsistent approach.
> Furthermore, would there be a need to enable parallel interface support
> in the DRM subsystem?
If you can do it, I will agree on retiring the FBTFT drivers that will
gain such a support. I can test 8347d (IIRC I have that panel at
hand).
--
With Best Regards,
Andy Shevchenko
More information about the linux-riscv
mailing list