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

[Liu Ying <victor.liu@nxp.com>]

On Sun, Jul 05, 2026 at 03:33:51AM +0530, Piyush Patle wrote:
> 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.
> >
> > 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,

Hi Piyush,

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

Can you please share the code in a public place, like github?

> 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

Same here, just want to see how dc-drv-common.c and dc-lib-* would look like.

> i.MX95-specific blocks such as DomainBlend, Dither, FetchEco, FetchYUV,
> HScaler and VScaler remain separate component drivers.

i.MX8QXP display controller also has Dither, FetchEco, HScaler and Vscaler,
so they are not i.MX95-specific blocks.  To add minimal feautures at first,
we don't need to support them as of now.  i.MX95-specific FetchYUV is similar
to i.MX8QXP-specific FetchDecode, so maybe FetchYUV won't be a separate
component driver at the end of the day.  To start up small, I think the
must-have DomainBlend and Dither(for Data-Enable, HSync and VSync polarity
controls) and two FetchLayers can be enabled to support two display pipelines.

BTW, do you have the i.MX95 TRM?  If no, then it would be difficult for you
to add DT bindings for *all* blocks.  Note that the DT bindings are supposed
to be complete at the first place.

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

As I said before in separate mail thread, pixel link is not used in the LVDS
display pipeline, but instead it's only used in the MIPI DSI display pipeline.

> 
> EDID is read successfully, the initial modeset works for all tested modes
> (1920x1080@60, 1280x720@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.

Not sure what's the cause of the issue, but FrameGen needs to be disabled and
then re-enabled if you want to do a full modeset.  I'd say that's not a reset
path.  This critical issue needs to be fixed before posting formal patches.

> In
> addition, the DSI path is implemented on the DC side but remains unvalidated.

It's fine to support the LVDS display pipeline first as long as it doesn't
do harm to the MIPI DSI display pipeline support.  So, maybe drop the latter
first.

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

-- 
Regards,
Liu Ying