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

Hi Liu,

A quick follow-up with some progress.
I went ahead with the refactoring we discussed and now have it working on the
i.MX95 15x15 FRDM, following the component-based model.
The common implementations for ConstFrame, ExtDst, LayerBlend, FrameGen and
the FetchUnit base have been moved into shared dc-lib-* helpers, with
SoC-specific register layouts and tables supplied as data. The per-SoC glue is
split into dc-drv-common.c, dc-drv-imx8qxp.c and dc-drv-imx95.c, while
i.MX95-specific blocks such as DomainBlend, Dither, FetchEco, FetchYUV,
HScaler and VScaler remain separate component drivers.

The implementation is functional on the FRDM over the pipeline
DPU -> pixel-interleaver -> pixel-link -> LDB -> LVDS PHY -> IT6263 -> HDMI

EDID is read successfully, the initial modeset works for all tested modes
(1920x1080 at 60, 1280x720 at 60, 720x480 and 640x480), and Weston and sway both run.

There are still two known limitations. The initial modeset works, but
subsequent mode changes currently wedge the ExtDst content shadow load, which
appears related to the lack of a reset path for the i.MX95 FrameGen. In
addition, the DSI path is implemented on the DC side but remains unvalidated.

The implementation is currently based on v7.2-rc1 together with your prefetch
v5 series.

The work is now ready to be posted as patch series: Adding LVDS/DSI
i.MX95 support.


Regards,
Piyush Patle