public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH v1 0/2] Migrate RAiO RA8875 from fbtft to DRM
@ 2026-05-04  2:13 Adam Azuddin
  2026-05-04  2:13 ` [RFC PATCH v1 1/2] dt-bindings: display: panel: Add RAiO RA8875 display controller Adam Azuddin
  2026-05-04  2:13 ` [RFC PATCH v1 2/2] drm/tiny: Add RAiO RA8875 display controller driver Adam Azuddin
  0 siblings, 2 replies; 4+ messages in thread
From: Adam Azuddin @ 2026-05-04  2:13 UTC (permalink / raw)
  To: dri-devel; +Cc: devicetree, Adam Azuddin

This RFC migrates the old fbtft fb_ra8875 (drivers/staging/fbtft/)
to a proper DRM/KMS driver. The RA8875 has a 2D Block Transfer Engine (BTE),
a touch controller, and PWM backlight control. This driver currently
implements only basic display pipe, with BTE and other subsystems as
planned follow-up work.

This driver does not use drm_mipi_dbi. The RA8875 SPI protocol is
structurally incompatible with both Type C options drm_mipi_dbi supports.
Type C1 encodes command/data as a 9th bit within a 9-bit SPI word. The
RA8875 uses a full prefix byte (0x80 = command write, 0x00 = data write,
0x40 = data read, 0xC0 = status read) sent as a separate 8-bit transaction.
These are not the same thing and cannot be mapped to each other.

Type C3 models two transfer types via a D/CX GPIO. The RA8875 has four
transfer cycle types and no D/CX pin. More critically, the GRAM write path
is stateful: an MRWC register-address transaction followed by a streaming
pixel pump under a single CS assertion. There is no way to express this
through the dbi->command() dispatch model without either abusing the
abstraction or reimplementing the transfer layer underneath it anyway.

Other than that, forcing DBI would actively obstruct the BTE
implementation, which requires direct control of the SPI bus at the
transaction level. A direct SPI implementation keeps this path clean.
Any feedback on these would be valuable.

Tested on Raspberry Pi 3B, 5" 800x480 display, kernel 7.0.0-rc3.

Currently placed in drm/tiny for review purposes. The intention is to move
to drivers/gpu/drm/ra8875/ in v2 to accommodate future BTE plane support
and the touch input subsystem on the same SPI device node.

Known limitation: at 25MHz SPI, full-screen throughput for 800x480 RGB565
is physically capped at ~4-5fps. The driver mitigates this with damage
tracking so only dirty regions are transferred. Full-screen animation and
video are not achievable over SPI at this resolution and are not intended
use cases for this hardware.

Some questions:

1. Register writes are currently capped at 1MHz. The datasheet allows
   higher but some boards have signal integrity issues. Should this be
   a DT property or is 1MHz a reasonable default?

2. PLL initialization hardcodes a 20MHz crystal assumption
   (PLLC1=0x0B, PLLC2=0x02). Should this be derived from a clock
   subsystem node or a DT property?

3. Currently using display-timings in the DT binding with
   of_get_videomode(OF_USE_NATIVE_MODE) in the driver. Should this
   use panel-timings instead, or is display-timings the correct
   choice for a controller-level binding like this?

4. Given planned BTE support as a DRM plane, is drm_simple_display_pipe
   the right foundation or should this be a full drm_driver from the
   start? Happy to restructure in v2 if consensus is to go full split now.

Future work: PWM backlight via DRM backlight interface, BTE as a DRM plane
or through drm_rect operations, touchscreen via input subsystem.


Adam Azuddin (2):
  dt-bindings: display: panel: Add RAiO RA8875 display controller
  drm/tiny: Add RAiO RA8875 display controller driver

 .../bindings/display/panel/raio,ra8875.yaml   |  76 ++
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 MAINTAINERS                                   |   6 +
 drivers/gpu/drm/tiny/Kconfig                  |  14 +
 drivers/gpu/drm/tiny/Makefile                 |   1 +
 drivers/gpu/drm/tiny/ra8875.c                 | 681 ++++++++++++++++++
 6 files changed, 780 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/panel/raio,ra8875.yaml
 create mode 100644 drivers/gpu/drm/tiny/ra8875.c

-- 
2.54.0


^ permalink raw reply	[flat|nested] 4+ messages in thread
* [RFC PATCH v1 0/2] Migrate RAiO RA8875 from fbtft to DRM
@ 2026-05-05 12:26 Adam Azuddin
  0 siblings, 0 replies; 4+ messages in thread
From: Adam Azuddin @ 2026-05-05 12:26 UTC (permalink / raw)
  To: dri-devel; +Cc: devicetree, Adam Azuddin

This is a resend — the original submission on Monday did not go through
as I was not yet subscribed to the list.

This RFC migrates the old fbtft fb_ra8875 (drivers/staging/fbtft/)
to a proper DRM/KMS driver. The RA8875 has a 2D Block Transfer Engine (BTE),
a touch controller, and PWM backlight control. This driver currently
implements only basic display pipe, with BTE and other subsystems as
planned follow-up work.

This driver does not use drm_mipi_dbi. The RA8875 SPI protocol is
structurally incompatible with both Type C options drm_mipi_dbi supports.
Type C1 encodes command/data as a 9th bit within a 9-bit SPI word. The
RA8875 uses a full prefix byte (0x80 = command write, 0x00 = data write,
0x40 = data read, 0xC0 = status read) sent as a separate 8-bit transaction.
These are not the same thing and cannot be mapped to each other.

Type C3 models two transfer types via a D/CX GPIO. The RA8875 has four
transfer cycle types and no D/CX pin. More critically, the GRAM write path
is stateful: an MRWC register-address transaction followed by a streaming
pixel pump under a single CS assertion. There is no way to express this
through the dbi->command() dispatch model without either abusing the
abstraction or reimplementing the transfer layer underneath it anyway.

Other than that, forcing DBI would actively obstruct the BTE
implementation, which requires direct control of the SPI bus at the
transaction level. A direct SPI implementation keeps this path clean.
Any feedback on these would be valuable.

Tested on Raspberry Pi 3B, 5" 800x480 display, kernel 7.0.0-rc3.

Currently placed in drm/tiny for review purposes. The intention is to move
to drivers/gpu/drm/ra8875/ in v2 to accommodate future BTE plane support
and the touch input subsystem on the same SPI device node.

Known limitation: at 25MHz SPI, full-screen throughput for 800x480 RGB565
is physically capped at ~4-5fps. The driver mitigates this with damage
tracking so only dirty regions are transferred. Full-screen animation and
video are not achievable over SPI at this resolution and are not intended
use cases for this hardware.

Some questions:

1. Register writes are currently capped at 1MHz. The datasheet allows
   higher but some boards have signal integrity issues. Should this be
   a DT property or is 1MHz a reasonable default?

2. PLL initialization hardcodes a 20MHz crystal assumption
   (PLLC1=0x0B, PLLC2=0x02). Should this be derived from a clock
   subsystem node or a DT property?

3. Currently using display-timings in the DT binding with
   of_get_videomode(OF_USE_NATIVE_MODE) in the driver. Should this
   use panel-timings instead, or is display-timings the correct
   choice for a controller-level binding like this?

4. Given planned BTE support as a DRM plane, is drm_simple_display_pipe
   the right foundation or should this be a full drm_driver from the
   start? Happy to restructure in v2 if consensus is to go full split now.

Future work: PWM backlight via DRM backlight interface, BTE as a DRM plane
or through drm_rect operations, touchscreen via input subsystem.


Adam Azuddin (2):
  dt-bindings: display: panel: Add RAiO RA8875 display controller
  drm/tiny: Add RAiO RA8875 display controller driver

 .../bindings/display/panel/raio,ra8875.yaml   |  76 ++
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 MAINTAINERS                                   |   6 +
 drivers/gpu/drm/tiny/Kconfig                  |  14 +
 drivers/gpu/drm/tiny/Makefile                 |   1 +
 drivers/gpu/drm/tiny/ra8875.c                 | 681 ++++++++++++++++++
 6 files changed, 780 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/panel/raio,ra8875.yaml
 create mode 100644 drivers/gpu/drm/tiny/ra8875.c

-- 
2.54.0


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-05-05 12:27 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-04  2:13 [RFC PATCH v1 0/2] Migrate RAiO RA8875 from fbtft to DRM Adam Azuddin
2026-05-04  2:13 ` [RFC PATCH v1 1/2] dt-bindings: display: panel: Add RAiO RA8875 display controller Adam Azuddin
2026-05-04  2:13 ` [RFC PATCH v1 2/2] drm/tiny: Add RAiO RA8875 display controller driver Adam Azuddin
  -- strict thread matches above, loose matches on Subject: below --
2026-05-05 12:26 [RFC PATCH v1 0/2] Migrate RAiO RA8875 from fbtft to DRM Adam Azuddin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox