drivers/media/platform/st/stm32/dma2d · keep-annotate

STMicroelectronics STM32 Chrom-ART (DMA2D) 2D graphics accelerator

Chrom-ART Accelerator, also called DMA2D, is a small 2D graphics block built into ST's STM32F4/F7 and related microcontrollers. It offloads pixel-format conversion, blending, and rectangle fills from the Cortex-M CPU, mainly to drive small embedded LCD panels in industrial HMIs, appliances, and IoT gadgets.

keep-annotate conf=0.84 last_sold=2025 deploy=low replacement=none subsystem=media category=media-other

84%

recommendation

Worth keeping but documenting as niche: the hardware block lives on STM32F429-class microcontrollers that ST still sells new in 2025, and only one in-tree device tree (stm32f429.dtsi) actually wires it up, so real Linux deployments are narrow. The code is not abandoned — it received a genuine clock-enable bug fix in 2024 and tracked V4L2 API changes into 2025 — and there is no upstream discussion of removing it.

repository signals

4 files

1,106 source lines

16 commits, 5y

+1,141 / −35 lines added / removed, 5y

11 authors, 5y

monthly commits · 2021-04-21 → 2026-04-21 · 16 total · active in 9/61 months

sources

cateee.net
Upstream Kconfig symbol CONFIG_VIDEO_STM32_DMA2D is still present through current kernel heads, indicating the driver remains supported in mainline.
st.com
STM32F429 devices that include the Chrom-ART/DMA2D block are still sold by ST as active volume-production parts.
st.com
An STM32F429 Discovery board with LCD-oriented use cases is still sold, showing continuing availability of DMA2D-capable hardware.
st.com
The STM32F429/439 family page still markets Chrom-ART Accelerator-equipped parts, supporting 2025 new-hardware availability.
lkml.indiana.edu
The driver was added upstream as a dedicated STM32 DMA2D media mem2mem driver, confirming the hardware/use-case covered by this directory.

codex reasoning notes (technical)

Real driver directory: contains a platform_driver and OF match for "st,stm32-dma2d". Local shell inspection (`rg`, `git log`) shows only one in-tree DT binding use under `arch/arm/boot/dts/st/stm32f429.dtsi`, so Linux deployments look niche/embedded rather than broad. Local `git -c safe.directory=... log` also shows non-removal maintenance through 2024-2025, including a real clk_enable() fix in 2024 plus 2025 V4L2 API churn updates; I found no removal/deprecation discussion. URLs were obtained via web search (`web.search_query`); local shell commands supplied the upstream activity signal. Result: keep the driver, but annotate it as low-deployment/niche rather than a removal candidate.