Hi all, This is an RFC to settle the i.MX95 display architecture before any code is (re)posted. It is a question, not a submission.
It follows Marek's earlier [1] and Liu Ying's reply there proposing a separate i.MX95 driver plus a shared helper library rather than extending the existing i.MX8QXP DC driver (drivers/gpu/drm/imx/dc/). That question was never resolved, and it gates any serious submission. The implementation I evaluated is based on the existing NXP downstream dpu95 driver. My work has focused on bringing it up on current mainline, DT integration, FRDM enablement and validation rather than developing a new driver. I am not proposing to repost that driver as-is; I would rather settle the architecture first. The current dc/ implementation is a multi-device component driver with one platform_driver per block bound via the component framework. The downstream i.MX95 driver is a single monolithic platform_driver mapping all blocks from one register base. Unifying appears to require reconciling two bind models, rather than only adding match_data. DomainBlend is i.MX95-only and sits on the atomic CRTC path, with no i.MX8QXP analogue. The block decomposition also differs: i.MX95 has dither/hscaler/vscaler/fetcheco/fetchyuv/domainblend, while i.MX8QXP uses fetchwarp. There is also anticipated divergence which is not yet upstream (i.MX8QXP prefetch/PRG, LTS and tiling modifiers, and the downstream i.MX95 blit engine), although mainline dc/ is KMS-only today. A single parametrised driver may still be possible, but these differences led me to revisit the question before preparing a series. The ported stack is functional on an i.MX95 15x15 FRDM with an IT6263 LVDS-to-HDMI bridge on LVDS channel 1. The DPU probes successfully, EDID is read through the bridge, and modesetting works at 1280x720@60 and 1920x1080@60. Weston and sway both run correctly. Tested pipeline DPU -> pixel-interleaver -> pixel-link -> LDB -> LVDS PHY -> IT6263 -> HDMI, using JEIDA-24 mapping. DSI is not covered. One question for Liu Ying is whether the separate-driver plus shared helper-library approach is still the preferred direction, and where the helper boundary would be drawn (which blocks/ops are shared versus implemented per driver). If that approach is still preferred, I would be interested in working on the helper-library extraction. Before spending time on it, I would like to understand whether it matches the intended upstream direction or whether similar work is already planned. Likewise, it would be useful to understand whether extending dc/ is still considered preferable, and how the component and monolithic driver models would be reconciled given the differences described above. Thanks, Piyush Patle References [1] https://lore.kernel.org/dri-devel/[email protected]/
