drm/tiny: Add RAiO RA8875 display controller driver support
Subsystems (4)
v2 cover drm/tiny: Add RAiO RA8875 display controller driver support
This series adds a new drm/tiny driver and matching dt-binding for the RAiO RA8875 SPI display controller. An fbtft driver for this chip currently exists at drivers/staging/fbtft/fb_ra8875.c, but fbtft is a legacy fbdev-based staging driver, and nothing in mainline DRM currently supports this controller.
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.
My ER-TFTM050-3 board has RST tied NC, and VDD is a fixed supply
set via an on-board solder jumper rather than software-controllable, so I couldn't test reset-gpios/vdd-supply myself, but added them
as optional/required properties per review feedback for boards that do need them.
Tested on a Raspberry Pi 3B connected over SPI to an East Rising ER-TFTM050-3, a 5" 800x480 panel driven by the RA8875 in Linux 7.3.0-rc4.
Link to v1: https://lore.kernel.org/all/[email protected]/
---
Changes in v2:
Documentation/devicetree/bindings/display/panel/raio,ra8875.yaml (review by Krzysztof Kozlowski):
- Add hardware description to the binding
- Drop the display-timings property, and instead require it in the required block
- Add a required vdd-supply and an optional reset gpio property
- Rename the example node to a more generic "panel: display@0"
drivers/gpu/drm/tiny/Makefile and Kconfig:
- Remove TINYDRM prefix from the config name (Thomas Zimmermann [1])
drivers/gpu/drm/tiny/ra8875.c:
- Reformat device_id table to match current convention (Krzysztof Kozlowski)
- Drop unneeded linux/mod_devicetable.h include (Uwe Kleine-König)
- Use drm_dev_unplug() instead of drm_dev_unregister() in remove callback
- Move stack-allocated cmd/data buffers into ra8875_device struct
- Add mode_valid() callback to validate height/width against panel maximum
- Add optional reset gpio
- Use dev_err_probe() in probe function
- Remove connector detect callback
- Remove unnecessary |= on register write return value in hw_init
- Migrate from simple display pipe to manually-handled plane/crtc/encoder, following the simple-KMS-helper removal effort [2]
- Use defined constants instead of magic values where possible
- Use drm_atomic_helper_damage_merged() and drm_fb_swab() in plane update
[1] https://lore.kernel.org/all/[email protected]/
[2] https://lore.kernel.org/all/20260705-drm-simple-kms-removal-v1-0-b4e1ca053623@oss.qualcomm.com/
---
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 | 78 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 6 + drivers/gpu/drm/tiny/Kconfig | 13 + drivers/gpu/drm/tiny/Makefile | 1 + drivers/gpu/drm/tiny/ra8875.c | 808 ++++++++++++++++++ 6 files changed, 908 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/raio,ra8875.yaml create mode 100644 drivers/gpu/drm/tiny/ra8875.c
Signature · 1 line
2.55.0
PATCH v2 1/2 dt-bindings: display: panel: Add RAiO RA8875 display controller
The RA8875 is an SPI-connected TFT display controller by RAiO Technology Inc. It supports display resolutions of up to 800x480.
--- .../bindings/display/panel/raio,ra8875.yaml | 78 +++++++++++++++++++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + 2 files changed, 80 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/raio,ra8875.yaml
Documentation/devicetree/bindings/display/panel/raio,ra8875.yaml new file +78 -0
@@ -0,0 +1,78 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/raio,ra8875.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: RAiO RA8875 Display Controller + +maintainers: + - Adam Azuddin <[email protected]> + +description: + The RA8875 is a TFT LCD controller for panels up to 800x480 pixels. + It can be connected to the controller via 8080/6800 parallel interface, + SPI or I2C. This binding describes the SPI-connected device. + +allOf: + - $ref: panel-common.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +properties: + compatible: + const: raio,ra8875 + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 25000000 + + vdd-supply: + description: + 3.3 V supply for the IO pins, the oscillator IO pins, the ADC pins + and the internal LDO. The 1.8 V core rail is generated internally. + + reset-gpios: + description: + GPIO connected to the active-low RST# pin. Optional, since the board + may instead use an RC reset circuit. + maxItems: 1 + +required: + - compatible + - reg + - display-timings + - vdd-supply + +unevaluatedProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + panel: display@0 { + compatible = "raio,ra8875"; + reg = <0>; + spi-max-frequency = <16000000>; + vdd-supply = <&vcc_3v3>; + reset-gpios = <&gpio 25 GPIO_ACTIVE_LOW>; + + display-timings { + native-mode = <&timing0>; + timing0: timing0 { + clock-frequency = <25000000>; + hactive = <800>; + vactive = <480>; + hfront-porch = <40>; + hsync-len = <40>; + hback-porch = <40>; + vfront-porch = <10>; + vsync-len = <10>; + vback-porch = <20>; + }; + }; + }; + };
Documentation/devicetree/bindings/vendor-prefixes.yaml +2 -0
@@ -1395,6 +1395,8 @@ patternProperties: description: Radxa "^raidsonic,.*": description: RaidSonic Technology GmbH + "^raio,.*": + description: RAiO Technology Inc. "^ralink,.*": description: Mediatek/Ralink Technology Corp. "^ramtron,.*":
Signature · 1 line
2.55.0
[email protected]
AI reviewRe: [PATCH v2 1/2] dt-bindings: display: panel: Add RAiO RA8875 display controller
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] dt-bindings: missing <dt-bindings/gpio/gpio.h> in example causes dtc build failure --
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] dt-bindings: missing <dt-bindings/gpio/gpio.h> in example causes dtc build failure --
commit 7e01f56671098a8bf49e596e68df147ced833fec
Author: Adam Azuddin <[email protected]>
dt-bindings: display: panel: Add RAiO RA8875 display controller
This commit introduces a new device tree binding for the RAiO RA8875 TFT display controller. It documents properties for its SPI interface, including required supplies and GPIO resets.
Quoted 5 lines
Documentation/devicetree/bindings/display/panel/raio,ra8875.yaml new file +0
-0
[ ... ]
Documentation/devicetree/bindings/display/panel/raio,ra8875.yaml line 61
Quoted 12 lines
Documentation/devicetree/bindings/display/panel/raio,ra8875.yaml new file +12
-0+examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + panel: display@0 { + compatible = "raio,ra8875"; + reg = <0>; + spi-max-frequency = <16000000>; + vdd-supply = <&vcc_3v3>; + reset-gpios = <&gpio 25 GPIO_ACTIVE_LOW>;
[Severity: Low]
Does this example fail to compile during the make dt_binding_check target?
The GPIO_ACTIVE_LOW macro is used here without the required header inclusion. This causes dtc compilation to fail with a syntax error because the macro remains unexpanded.
Could we include <dt-bindings/gpio/gpio.h> at the beginning of the example block?
Quoted 2 lines
Documentation/devicetree/bindings/display/panel/raio,ra8875.yaml new file +2
-0+ + display-timings {
[ ... ]
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
Rob Herring (Arm)
maintainerRe: [PATCH v2 1/2] dt-bindings: display: panel: Add RAiO RA8875 display controller
In reply to Adam AzuddinQuoted 11 lines · Adam Azuddin
The RA8875 is an SPI-connected TFT display controller by RAiO Technology Inc. It supports display resolutions of up to 800x480.
Assisted-by LLMSigned-off-by Adam Azuddin <[email protected]>--- .../bindings/display/panel/raio,ra8875.yaml | 78 +++++++++++++++++++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + 2 files changed, 80 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/raio,ra8875.yaml
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
Lexical error: Documentation/devicetree/bindings/display/panel/raio,ra8875.example.dts:27.41-56 Unexpected 'GPIO_ACTIVE_LOW' FATAL ERROR: Syntax error parsing input tree
make[2]: *** [scripts/Makefile.dtbs:140: Documentation/devicetree/bindings/display/panel/raio,ra8875.example.dtb] Error 1 make[2]: *** Waiting for unfinished jobs....
make[1]: *** [/builds/robherring/linux-dt-review/Makefile:1714: dt_binding_check] Error 2
make: *** [Makefile:248: __sub-make] Error 2
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/[email protected]
The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
PATCH v2 2/2 drm/tiny: Add RAiO RA8875 display controller driver
In reply to Adam AzuddinAdd a DRM tiny driver for the RAiO RA8875 SPI-connected TFT display controller. The driver supports display resolutions up to 800x480 and uses the GEM shmem helper for buffer management.
--- MAINTAINERS | 6 + drivers/gpu/drm/tiny/Kconfig | 13 + drivers/gpu/drm/tiny/Makefile | 1 + drivers/gpu/drm/tiny/ra8875.c | 808 ++++++++++++++++++++++++++++++++++ 4 files changed, 828 insertions(+) create mode 100644 drivers/gpu/drm/tiny/ra8875.c
MAINTAINERS +6 -0
@@ -8449,6 +8449,12 @@ S: Maintained F: Documentation/devicetree/bindings/display/panel/raydium,rm67191.yaml F: drivers/gpu/drm/panel/panel-raydium-rm67191.c +DRM DRIVER FOR RAIO RA8875 PANELS +M: Adam Azuddin <[email protected]> +S: Maintained +F: Documentation/devicetree/bindings/display/panel/raio,ra8875.yaml +F: drivers/gpu/drm/tiny/ra8875.c + DRM DRIVER FOR SAMSUNG DB7430 PANELS M: Linus Walleij <[email protected]> S: Maintained
drivers/gpu/drm/tiny/Kconfig +13 -0
@@ -195,6 +195,19 @@ config TINYDRM_REPAPER If M is selected the module will be called repaper. +config DRM_RA8875 + tristate "DRM support for RA8875 display panels" + depends on DRM && SPI + select DRM_CLIENT_SELECTION + select DRM_KMS_HELPER + select DRM_GEM_SHMEM_HELPER + select VIDEOMODE_HELPERS + help + DRM driver for the following RAiO RA8875 based LCD panels: + * East Rising 5.00" TFT LCD (ER-TFTM070-5V4) + + If M is selected the module will be called ra8875. + config TINYDRM_SHARP_MEMORY tristate "DRM support for Sharp Memory LCD panels" depends on DRM && SPI
drivers/gpu/drm/tiny/Makefile +1 -0
@@ -14,4 +14,5 @@ obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o obj-$(CONFIG_TINYDRM_ILI9486) += ili9486.o obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o +obj-$(CONFIG_DRM_RA8875) += ra8875.o obj-$(CONFIG_TINYDRM_SHARP_MEMORY) += sharp-memory.o
drivers/gpu/drm/tiny/ra8875.c new file +808 -0
808 lines not on this page · raw message
Signature · 1 line
2.55.0
[email protected]
AI reviewRe: [PATCH v2 2/2] drm/tiny: Add RAiO RA8875 display controller driver
Thank you for your contribution! Sashiko AI review found 7 potential issue(s) to consider: - [High] drm/tiny: atomic context violation by calling sleeping functions - [High] spi: DMA-unsafe stack…
Thank you for your contribution! Sashiko AI review found 7 potential issue(s) to consider:
- [High] drm/tiny: atomic context violation by calling sleeping functions
- [High] spi: DMA-unsafe stack buffers passed to spi_sync
- [High] drm: missing reset callback in drm_crtc_funcs leads to null deref
- [High] drm: missing cleanup_fb causes GEM object pin leaks
- [Medium] spi: massive contiguous allocation and unbounded spi transfers
- [Medium] drm: missing atomic_disable hook causes intentional warnings
- [Medium] spi: missing cs_change=1 breaks RA8875 spi protocol
--
commit 594ac08dfc437ba3494bf3b5226a6268a7e028be
Author: Adam Azuddin <[email protected]>
drm/tiny: Add RAiO RA8875 display controller driver
Add a DRM tiny driver for the RAiO RA8875 SPI-connected TFT display controller. The driver supports display resolutions up to 800x480 and uses the GEM shmem helper for buffer management.
Quoted 4 lines
drivers/gpu/drm/tiny/ra8875.c new file +0
-0
[ ... ]
Quoted 18 lines
drivers/gpu/drm/tiny/ra8875.c new file +18
-0+static int ra8875_read_reg (struct ra8875_device *ra8875,u8 reg,u8 *val) +{ + ra8875->cmd_buf[0 ] =RA8875_CMDWRITE ; + ra8875->cmd_buf[1 ] = reg; +int ret; + +u8 tx[2 ] = {0x40 ,0x00 }; +u8 rx[2 ] = {0x00 ,0x00 }; + +struct spi_transfer t_cmd = { + .tx_buf = ra8875->cmd_buf, + .len =2 , + .speed_hz =RA8875_REG_SPI_SPEED , + .cs_change =1 + }; +struct spi_transfer t_read = { + .tx_buf = tx, + .rx_buf = rx,
drivers/gpu/drm/tiny/ra8875.c line 211
Quoted 10 lines
drivers/gpu/drm/tiny/ra8875.c new file +10
-0+ .len = 2, + .speed_hz = RA8875_REG_SPI_SPEED, + }; +struct spi_message m; + +spi_message_init (&m); +spi_message_add_tail (&t_cmd, &m); +spi_message_add_tail (&t_read, &m); + + ret =spi_sync (ra8875->spi, &m);
[Severity: High]
Does this code pass stack memory into a DMA-mapped SPI transfer?
The Linux SPI subsystem uses the DMA API to map transfer buffers if the SPI controller supports it. Stack memory allocated for tx and rx might not be physically contiguous, leading to memory corruption or cache coherency failures.
Quoted 2 lines
drivers/gpu/drm/tiny/ra8875.c new file +2
-0+if (ret) +return ret;
[ ... ]
Quoted 4 lines
drivers/gpu/drm/tiny/ra8875.c new file +4
-0+static int ra8875_hw_init (struct ra8875_device *ra8875, +struct drm_display_mode *mode) +{ +u8 hdwr, hndr, hstr, hpwr, vpwr;
drivers/gpu/drm/tiny/ra8875.c line 232
Quoted 10 lines
drivers/gpu/drm/tiny/ra8875.c new file +10
-0+u16 vdhr, vndr, vstr; +u8 readback; +int ret; + +if (ra8875->rst_gpio) { +gpiod_set_value_cansleep (ra8875->rst_gpio,1 ); +usleep_range (1000 ,1200 ); +gpiod_set_value_cansleep (ra8875->rst_gpio,0 ); +msleep (RA8875_RESET_WAIT_MS ); + }
[Severity: High]
Does this execute sleeping functions in an atomic context?
The global review guidelines dictate that CRTC and plane atomic update callbacks execute in an atomic context during non-blocking commits, where hardware sequence paths must not sleep.
Since ra8875_hw_init() is called by ra8875_crtc_atomic_enable(), executing msleep(), usleep_range(), and gpiod_set_value_cansleep() here can lead to system instability, lockups, and kernel warnings for scheduling while atomic.
Quoted 3 lines
drivers/gpu/drm/tiny/ra8875.c new file +3
-0+ +/* Soft Reset Sequence */ + ret =ra8875_write_reg (ra8875,RA8875_PWRR ,RA8875_PWRR_SOFTRST );
[ ... ]
Quoted 3 lines
drivers/gpu/drm/tiny/ra8875.c new file +3
-0+static int ra8875_clear_screen (struct ra8875_device *ra8875, +struct drm_display_mode *mode) +{
[ ... ]
drivers/gpu/drm/tiny/ra8875.c line 427
Quoted 9 lines
drivers/gpu/drm/tiny/ra8875.c new file +9
-0+for (y =0 ; y < height;) { + rows =min (rows_per_chunk, height - y); + +u8 cmd[2 ] = {RA8875_CMDWRITE ,RA8875_MRWC }; +struct spi_transfer t_cmd = { + .tx_buf = cmd, + .len =2 , + .speed_hz =RA8875_REG_SPI_SPEED , + };
[Severity: Medium]
Will the missing cs_change = 1 break the RA8875 SPI protocol here?
Unlike ra8875_write_reg() which sets cs_change = 1 for command transfers to de-assert the chip select before sending the data payload, this transfer omits it. Without toggling the CS pin between the command and data phases, the hardware might misinterpret the incoming data.
[Severity: High]
Does this code use stack memory for an SPI transfer buffer?
Passing the local stack array cmd into spi_sync() is unsafe because the SPI subsystem may use DMA to map the buffer, which is explicitly prohibited for stack variables.
Quoted 6 lines
drivers/gpu/drm/tiny/ra8875.c new file +6
-0+struct spi_transfer t_data = { + .tx_buf = txbuf, + .len =1 + rows * width *2 , + .speed_hz =RA8875_MAX_SPI_SPEED , + }; +struct spi_message m;
[ ... ]
Quoted 3 lines
drivers/gpu/drm/tiny/ra8875.c new file +3
-0+static void ra8875_fb_dirty (struct ra8875_device *ra8875,struct iosys_map *src, +struct drm_framebuffer *fb,struct drm_rect *rect) +{
[ ... ]
drivers/gpu/drm/tiny/ra8875.c line 531
Quoted 4 lines
drivers/gpu/drm/tiny/ra8875.c new file +4
-0+memset (&t_data,0 ,sizeof (t_data)); + t_data.tx_buf = ra8875->txbuf; + t_data.len =1 + height * width *2 ; + t_data.speed_hz = ra8875->spi->max_speed_hz;
[Severity: Medium]
Will this result in unbounded SPI transfers that exceed the host controller's limits?
The driver attempts to send up to the entire 768 KB buffer (for an 800x480 resolution) in a single spi_transfer depending on the damage rect size. Many SPI controllers impose maximum transfer limits, such as 65535 bytes, and will reject oversized transfers.
drivers/gpu/drm/tiny/ra8875.c line 535
Quoted 4 lines
drivers/gpu/drm/tiny/ra8875.c new file +4
-0+ +spi_message_init (&m); +spi_message_add_tail (&t_data, &m); +if (spi_sync (ra8875->spi, &m))
[Severity: High]
Does this call a sleeping function from the plane's atomic update callback?
spi_sync() sleeps while waiting for hardware I/O to complete. Because ra8875_fb_dirty() is invoked from ra8875_plane_atomic_update(), this executes sleeping routines in an atomic context, leading to kernel warnings and system lockups.
Quoted 3 lines
drivers/gpu/drm/tiny/ra8875.c new file +3
-0+ goto err; + +drm_format_conv_state_release (&fmtcnv_state);
[ ... ]
drivers/gpu/drm/tiny/ra8875.c line 557
Quoted 13 lines
drivers/gpu/drm/tiny/ra8875.c new file +13
-0+static void ra8875_plane_atomic_update (struct drm_plane *plane,struct drm_atomic_commit *state) +{ + struct ra8875_device *ra8875 = container_of(plane->dev, struct ra8875_device, drm); +struct drm_plane_state *old_plane_state =drm_atomic_get_old_plane_state (state, plane); +struct drm_plane_state *plane_state =drm_atomic_get_new_plane_state (state, plane); +struct drm_shadow_plane_state *shadow_plane_state =to_drm_shadow_plane_state (plane_state); +struct drm_framebuffer *fb = plane_state->fb; +struct drm_rect rect; +struct iosys_map *map = &shadow_plane_state->data[0 ]; +int idx; + +if (drm_WARN_ON_ONCE (&ra8875->drm, !fb)) +return ;
[Severity: Medium]
Is this code triggering intentional warnings during plane disables?
Because the driver does not provide an atomic_disable callback in ra8875_plane_helper_funcs, the DRM atomic helpers fall back to calling atomic_update with a NULL fb. This warning will immediately fire on valid plane disable requests, generating a stack trace that could crash the system if panic_on_warn is enabled.
Quoted 2 lines
drivers/gpu/drm/tiny/ra8875.c new file +2
-0+ +if (!drm_dev_enter (&ra8875->drm, &idx))
[ ... ]
drivers/gpu/drm/tiny/ra8875.c line 612
Quoted 2 lines
drivers/gpu/drm/tiny/ra8875.c new file +2
-0+static const struct drm_crtc_funcs ra8875_crtc_funcs = { + .atomic_create_state = drm_atomic_helper_crtc_create_state,
[Severity: High]
Does this structure omit the required .reset callback and mistakenly assign to .atomic_create_state instead of .atomic_duplicate_state (or similar)?
There is no .atomic_create_state member in drm_crtc_funcs, causing a build failure. Furthermore, omitting the required .reset callback (typically drm_atomic_helper_crtc_reset) leaves crtc->state as NULL, leading to a kernel panic upon the first atomic check or commit.
Quoted 17 lines
drivers/gpu/drm/tiny/ra8875.c new file +17
-0+ .destroy = drm_crtc_cleanup, + .set_config = drm_atomic_helper_set_config, + .page_flip = drm_atomic_helper_page_flip, + .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state, + .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state, +}; + +static const struct drm_crtc_helper_funcs ra8875_crtc_helper_funcs = { + .mode_valid = ra8875_mode_valid, + .atomic_enable = ra8875_crtc_atomic_enable, + .atomic_disable = ra8875_crtc_atomic_disable, +}; + +static const struct drm_plane_funcs ra8875_plane_funcs = { + .update_plane = drm_atomic_helper_update_plane, + .disable_plane = drm_atomic_helper_disable_plane, + .destroy = drm_plane_cleanup,
drivers/gpu/drm/tiny/ra8875.c line 639
Quoted 10 lines
drivers/gpu/drm/tiny/ra8875.c new file +10
-0+ DRM_GEM_SHADOW_PLANE_FUNCS, +}; + +static const struct drm_plane_helper_funcs ra8875_plane_helper_funcs = { + .prepare_fb = drm_gem_plane_helper_prepare_fb, + .begin_fb_access = drm_gem_begin_shadow_fb_access, + .end_fb_access = drm_gem_end_shadow_fb_access, + .atomic_check = ra8875_plane_atomic_check, + .atomic_update = ra8875_plane_atomic_update, +};
[Severity: High]
Does this code leak GEM object pins by missing a cleanup_fb hook?
The driver specifies .prepare_fb = drm_gem_plane_helper_prepare_fb, which pins the framebuffer during a page flip or mode set. Without providing a matching .cleanup_fb hook (such as drm_gem_plane_helper_cleanup_fb), the framebuffer is never unpinned. The GEM object reference count will perpetually increase, and the memory cannot be freed.
Quoted 2 lines
drivers/gpu/drm/tiny/ra8875.c new file +2
-0+ +static const struct drm_driver ra8875_driver = {
[ ... ]
Quoted 2 lines
drivers/gpu/drm/tiny/ra8875.c new file +2
-0+static int ra8875_probe (struct spi_device *spi) +{
[ ... ]
drivers/gpu/drm/tiny/ra8875.c line 705
Quoted 6 lines
drivers/gpu/drm/tiny/ra8875.c new file +6
-0+ ret =spi_setup (spi); +if (ret) +return dev_err_probe (dev, ret,"Failed to setup SPI:\n" ); + + buf_size =1 +RA8875_MAX_HEIGHT *RA8875_MAX_WIDTH *2 ; + ra8875->txbuf =devm_kzalloc (&spi->dev, buf_size,GFP_KERNEL );
[Severity: Medium]
Will this fail to allocate memory on fragmented systems?
The driver allocates ~768 KB of memory for a maximum 800x480 resolution using devm_kzalloc. Because this requires an order-8 contiguous physical allocation, it is highly likely to fail on systems with memory fragmentation.
Quoted 2 lines
drivers/gpu/drm/tiny/ra8875.c new file +2
-0+if (!ra8875->txbuf) +return -ENOMEM ;
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2