On Wed, Jun 10, 2026 at 06:31:02PM +0200, Marek Vasut wrote:

On 6/9/26 10:26 AM, Liu Ying wrote:

Hello Liu,

Hello Marek,

quoted

quoted

quoted

quoted

I brought this series up on the i.MX95 15x15 FRDM (IT6263 LVDS-to-HDMI on
LVDS ch1). It mostly works, but I ran into a few issues around DI routing,
LVDS format handling, and DC enable sequencing which needed rework before
HDMI would come up reliably on the board.

I don't see a v2 of the series and things seem to have been quiet since
November. Are you planning to post an updated version?

My plan was to enable prefetch engine support[1] for i.MX8QXP display
controller and add device tree for a whole i.MX8QXP LVDS display pipeline,
before adding i.MX95 display controller support.

Unfortunately, it seems that Marek is not a big fan of [1]

I am fine with [1] as long as it can be isolated and does not affect every
SoC that might reuse this driver, which I think it can be done.

How can it be isolated?

if (compatible("mx8q"))
  something->prefetch_op = somefunction;

I certainly cannot add this to [1], because currently the driver only supports
i.MX8QXP display controller.

And then wherever is prefetch used, do

if (something->prefetch_op)
  something->prefetch_op()

These 'if' checks can be avoided, if i.MX95 display controller is supported
by a separate driver.  The checks are just telling us that the i.MX8QXP and
i.MX95 display controllers are different from H/W point of view - i.MX8QXP
SoC has prefetch engines, while i.MX95 SoC has not.  Of course, there are a
lot more H/W differences, hence it's worth separate drivers.  Without
prefetch engines to do tile to linear resolving for framebuffers, i.MX95
display controller's DRM planes cannot advertise tile specific modifiers.
The separate driver's IOCTL designs for blit-engine could also be different,
because of the prefetch engine and no Linear Tile Store(LTS) [2] attached to
i.MX95 display controller Store unit's output.  Userspace could easily check
the DRM driver names to get the IOCTLS that a particular driver supports.

[2] https://elixir.bootlin.com/linux/v7.0/source/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-store.yaml#L73-L76

Or something along those lines ?

quoted

quoted

quoted

and I'm busy
with downstream development so the plan doesn't move forward well.  I still
think [1] makes sense(maybe I need to rebase it on latest drm-misc-next),
so I'd like to see review comments on [1] and hopefully people think that
the overall idea of [1] is ok.

My only concern is, to keep it isolated to MX8Q, so this driver can be
reused by MX95.

quoted

quoted

I've accumulated a fair amount of rework while getting this running on the
FRDM. If you're not planning a v2, I can clean things up and send one based
on the current series.

I still think that i.MX95 display controller driver should be in a separate
driver, rather than sharing the same driver with i.MX8QXP display controller
like this patch series does, because the two display controllers are quite
different as I mentioned in comments on this patch series and in discussion
in [1].  Also, the common part between the two display controllers should
be extracted to a common helper library as I mentioned there too.

Are they really? It seems this series adds support for the MX95 DC without
that many changes, so are the DCs really that different ? It seems the MX95
DC is simply a reuse/evolution of the MX8Q DC blocks, so duplicating the
code seems like the wrong direction, it will only lead to disparate sets of
bugs in two drivers, which isn't desired.

I pointed out a lot of H/W differences between the two display controllers
during the discussions for this patch series and my i.MX8QXP prefetch engine
patch series[1].  Please take a look at [1], which clearly shows that the
prefetch engine would considerably impact CRTC/plane atomic callback
implementations.

Is the prefetch engine actually grown into the CRTC/DE or not ? I suspect it
is separate and instead part of the built-in DMA, right ?

It is separate and not grown into CRTC/DE.
It sits between DRAM and pixel engine's or blit engine's fetchunit.

quoted

Display controller internal blocks would also impact
the implementations, e.g., DomainBlend block in i.MX95 display controller
doesn't present in i.MX8QXP display controller.  It makes sense to use
separate drivers for the two display controllers instead of adding 'if/else'
checks to a single driver's atomic callbacks or introducing two pairs of
atomic callbacks to that single driver.  I mentioned before, the code to
simply add a DRM driver(struct drm_driver) is fairly limited.

Can't we simply have two sets of ops (one for mx8q and one for mx95) for
those ops which are too complicated to implement as a single op with if/else
statements ?

Technically, we can, but using separate drivers is a better design:
- no 'if/else' checks to advertise those tile specific modifiers or not.
- better IOCTL designs for blit-engine with different DRM driver names.
- again, the code to add a DRM driver(struct drm_driver) is fairly limited.

quoted

I also mentioned before that separate drivers make them easier to maintain:
we don't have to test both i.MX8QXP and i.MX95 if only one display controller
specific code is changed.

The downside is lack of code reuse, which leads to disparate sets of bugs in
these two drivers and code duplication. And it seems to me, that large parts
of the MX8Q and MX95 DC are effectively identical.

A common helper library achieves code reuse, so that's not a downside.

I'd say a lot of display controller internal units are identical, but H/W
differences would significantly impact driver implementations:
- i.MX95-only display controller DomainBlend unit supports 4 different modes,
  which impacts plane/CRTC drivers.
- i.MX8QXP-only prefetch engine impacts plane/CRTC drivers and blit-engine
  driver/IOCTLs.
- i.MX8QXP-only LTS impacts blit-engine driver/IOCTLs.

quoted

quoted

(I might not fully understand what you have in mind with the helper library
though?)

I said this could be something like imx-ldb-helper.c and plus perhaps some
callbacks like fg->dc_fg_cfg_videomode().

Do you perceive that the DC driver cannot be parametrized easily enough that
it has to be turned into a library like that ? When I look at this patchset,
esp. the first half which updates the various blocks, it does not seem to me
that way.

Yes, I do perceive that.  Your patchset touches mostly the identical display
controller units(DomainBlend is an exception and could impact plane/CRTC
drivers a lot) and enables kind of minimal features.  That's probaly why you
feel that way.  If think more about the different part, probably it will make
you feel the other way around.

-- 
Regards,
Liu Ying