On Mon, Jul 06, 2026 at 03:15:24PM +0530, Piyush Patle wrote:

On Mon, Jul 6, 2026 at 8:07 AM Liu Ying [off-list ref] wrote:

quoted

On Sun, Jul 05, 2026 at 03:33:51AM +0530, Piyush Patle wrote:

quoted

On Fri, Jun 26, 2026 at 3:22 PM Liu Ying [off-list ref] wrote:

quoted

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

[...]

quoted

The current dc/ implementation is a multi-device component driver

with one

quoted

quoted

quoted

quoted

platform_driver per block bound via the component framework. The

downstream

quoted

quoted

quoted

quoted

i.MX95 driver is a single monolithic platform_driver mapping all

blocks from

quoted

quoted

quoted

quoted

one register base. Unifying appears to require reconciling two bind

models,

quoted

quoted

quoted

quoted

rather than only adding match_data.

I think that upstream i.MX95 display controller driver would also be

based

quoted

quoted

quoted

on the component helper.  That's something for sure.

[...]

quoted

There is also anticipated divergence which is not yet upstream

(i.MX8QXP

quoted

quoted

quoted

quoted

prefetch/PRG, LTS and tiling modifiers, and the downstream i.MX95

blit

quoted

quoted

quoted

quoted

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

quoted

quoted

quoted

mode setting code a lot.

[2]

https://lore.kernel.org/all/20251027-imx8-dc-prefetch-v5-0-4ecb6c6d4941@nxp.com/ (local)

quoted

quoted

quoted

[...]

quoted

One question for Liu Ying is whether the separate-driver plus shared
helper-library approach is still the preferred direction, and where

the

quoted

quoted

quoted

quoted

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

quoted

quoted

quoted

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.

quoted

quoted

quoted

I'd assume that shared blocks or common part of slightly different

blocks

quoted

quoted

quoted

should be covered by the library.

[...]

quoted

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,

quoted

A quick follow-up with some progress.
I went ahead with the refactoring we discussed and now have it working

on the

quoted

quoted

i.MX95 15x15 FRDM, following the component-based model.
The common implementations for ConstFrame, ExtDst, LayerBlend, FrameGen

and

quoted

quoted

the FetchUnit base have been moved into shared dc-lib-* helpers, with

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

Sure. I've pushed the current work-in-progress branch here:
https://github.com/PiyushPatle26/linux-mecha-im95-wip/tree/imx95-dc-preview

I gave this branch a quick look.  The major problem is that you are using
the same 'struct drm_driver dc_drm_driver' for i.MX95 and i.MX8QXP display
controllers instead of using separate DRM drivers.  From userspace's POV,
they should see different driver names(drm_driver.name).  From drivers'
POVs, they should implement different mode setting callbacks.

It looks like it's not worth extracting common code into those dc-lib-* files.
Each dc-[block].c is a library itself, though I could be wrong - after all,
I haven't find a time slice to add i.MX95 blocks to them and see how they
will be.

The idea is to share some code between the two DRM drivers *naturally*.

The files you asked about are:
drivers/gpu/drm/imx/dc/dc-drv-common.c
drivers/gpu/drm/imx/dc/dc-lib-*.c
One thing I'd like to point out is that the pixel interleaver, display pixel
link, LDB and LVDS PHY drivers are ports of the existing NXP downstream
drivers. The new work in this branch is mainly the DC refactoring into the
component model and the shared helper library.

quoted

quoted

SoC-specific register layouts and tables supplied as data. The per-SoC

glue is

quoted

quoted

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.

quoted

The files you mentioned are available under:
drivers/gpu/drm/imx/dc/dc-drv-common.c
drivers/gpu/drm/imx/dc/dc-lib-*.c
The helper library currently contains the common implementations for
ConstFrame, ExtDst, LayerBlend, FrameGen and the FetchUnit base.

quoted

quoted

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,

quoted

so they are not i.MX95-specific blocks.  To add minimal feautures at

first,

quoted

we don't need to support them as of now.  i.MX95-specific FetchYUV is

similar

quoted

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.

quoted

Okay, I've reduced the implementation accordingly. The current branch
only keeps DomainBlend, Dither and two FetchLayers. FetchEco, FetchYUV,
HScaler and VScaler have been dropped for now.

quoted

BTW, do you have the i.MX95 TRM?  If no, then it would be difficult for

you

quoted

to add DT bindings for *all* blocks.  Note that the DT bindings are

supposed

quoted

to be complete at the first place.

Yes, I do.

quoted

quoted

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

HDMI

quoted

As I said before in separate mail thread, pixel link is not used in the

LVDS

quoted

display pipeline, but instead it's only used in the MIPI DSI display

pipeline.

quoted

Thanks for pointing that out. After checking the TRM, I updated the DT graph
so the LVDS pipeline is now:

DC -> Pixel-interleaver -> LDB -> LVDS PHY -> IT6263 -> HDMI

Yes, this pipeline is correct.

Removing display_pixel_link from the LVDS path also required moving the
bridge
format translation into the pixel interleaver driver.

quoted

quoted

EDID is read successfully, the initial modeset works for all tested

modes

quoted

quoted

(1920x1080@60, 1280x720@60, 720x480 and 640x480), and Weston and sway

both run.

quoted

quoted

There are still two known limitations. The initial modeset works, but
subsequent mode changes currently wedge the ExtDst content shadow load,

which

quoted

quoted

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

quoted

then re-enabled if you want to do a full modeset.  I'd say that's not a

reset

quoted

path.  This critical issue needs to be fixed before posting formal

patches.

quoted

Understood. I'll continue investigating the modeset issue before posting the
formal patch series.

quoted

quoted

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

unvalidated.

quoted

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

quoted

first.

I've done that in the current branch. It now focuses only on the validated
LVDS pipeline.

quoted

quoted

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

prefetch

quoted

quoted

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

Thanks again for taking the time to review this.

Regards,
Piyush Patle

-- 
Regards,
Liu Ying