[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

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

[Piyush Patle]

On Fri, Jun 26, 2026 at 3:22 PM Liu Ying <victor.liu@nxp.com> wrote:
>
> 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.
>

Hi Liu,
Thanks for the detailed reply.

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

That answers the biggest question I had. Knowing that upstream i.MX95 should
follow the component helper makes the overall direction much clearer.

>
> > 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/
>
> [...]
Thanks for pointing that out. I went through the v5 series together with the
downstream i.MX95 driver. Although the modesetting paths are diverging, many of
the common display blocks still appear to share very similar register
programming, with most differences being SoC-specific data such as register
offsets and tables.

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

Thanks for confirming that.
Based on that comparison, my current plan is to prepare a refactoring series
that shares the common implementations for ConstFrame, ExtDst, LayerBlend,
FrameGen and the FetchUnit base through a helper library, while keeping the
i.MX95-specific blocks as separate component drivers.

One implementation detail I'd like to clarify: would you prefer the shared
code to remain in the existing dc-*.c files with additional i.MX95 match
data, or would you rather see it extracted into separate helper source files?
>
> > 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.
>

Understood. I'll treat the downstream monolithic driver as a reference
and follow these plan for the upstream implementation.
I'll start by preparing a refactoring series for the shared blocks. If the
approach looks reasonable, I'd be happy to post the series for review before
working on the i.MX95 driver itself.

Thanks again for the guidance.

Regards,
Piyush Patle

> --
> Regards,
> Liu Ying