[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