NXP i.MX 8 QuadXPlus / QuadMax JPEG encoder and decoder
Hardware JPEG encode/decode block built into NXP's i.MX 8 QXP and QM application processors, used in industrial, automotive, and embedded products that need to capture or display JPEG images without burning CPU cycles. It is exposed to userspace as a standard V4L2 video device.
recommendation
It should stay because the underlying i.MX 8 and i.MX 8X SoCs are still listed as Active by NXP under its long-term longevity program, modules built on them (such as Variscite's VAR-SOM-MX8) are still being shipped in 2025, and the driver is receiving regular upstream maintenance into 2025-2026. There is also no generic replacement for this SoC-specific JPEG engine, so removing it would simply leave that hardware unusable on Linux.
repository signals
sources
- nxp.com
NXP lists the i.MX 8X family as Active, including i.MX 8QuadXPlus, indicating the SoC family remains commercially current.
- nxp.com
NXP lists the wider i.MX 8 family as Active and under its longevity program, supporting ongoing industrial/embedded availability.
- variscite.com
Current commercial SoM listings based on NXP i.MX 8QuadMax/8QuadPlus show the platform is still deployed in new embedded products.
- git.kernel.org
Kernel history for this directory shows continued upstream work into 2025-2026 rather than abandonment or removal preparation.
- git.kernel.org
The in-tree Kconfig identifies this as the V4L2 driver for the i.MX8 QXP/QM integrated JPEG encoder/decoder.
codex reasoning notes (technical)
Real driver directory: local `exec_command` inspection found `module_platform_driver(mxc_jpeg_driver)` and Kconfig text naming the i.MX8 QXP/QM JPEG encoder/decoder. Local `exec_command` git log showed substantive 2025-2026 maintenance (Ming Qian, Laurent Pinchart, Marek Vasut, treewide followups) and no visible removal-oriented activity in the recent history sampled. Web search obtained NXP product pages showing i.MX8/i.MX8X still Active, plus a current Variscite SoM page showing ongoing embedded deployments. Kernel.org URLs are canonical-recall citations used to anchor the upstream driver/history pages. Given active maintenance, current sale of relevant SoC family/module products, and no natural cross-driver replacement for this SoC-specific JPEG block, the correct disposition is keep.