[RFC] drm/imx: upstream direction for i.MX95 display support

[RFC] drm/imx: upstream direction for i.MX95 display support

[Piyush Patle]

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/20251011170213.128907-1-marek.vasut@mailbox.org/

Re: [RFC] drm/imx: upstream direction for i.MX95 display support

[Liu Ying]

On Wed, Jun 24, 2026 at 03:33:18PM +0530, Piyush Patle wrote:

[...]

> 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.

I think that upstream i.MX95 display controller driver would also be based
on the component helper.  That's something for sure.

[...]

> 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.

Just want to point out that I sent out v5 patch set[2] to add i.MX8QXP
prefetch engine(DPRC + PRG) support for KMS.  That changes the driver's
mode setting code a lot.

[2] https://lore.kernel.org/all/20251027-imx8-dc-prefetch-v5-0-4ecb6c6d4941@nxp.com/

[...]

> 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).

Yes, separate DRM drivers + a helper library approach is still the direction
I want.  I think that the drivers and library would sit in the same
directory drivers/gpu/drm/imx/dc/.

The purpose to add a library is to share code to reduce overall code lines.
I'd assume that shared blocks or common part of slightly different blocks
should be covered by the library.

[...]

> how the component and monolithic driver models
> would be reconciled given the differences described above.

Like I said above, I don't think upstream driver would be monolithic.

-- 
Regards,
Liu Ying