Re: [PATCH 00/39] Add i.MX95 DPU/DSI/LVDS support

[Marek Vasut <marek.vasut@mailbox.org>]

On 10/20/25 4:15 AM, Ying Liu wrote:

Hello Liu,

>>>> I wanted to put this whole thing on the list first, before I start splitting it
>> up.
>>>>
>>>> For starters, I think I can send these separately:
>>>
>>> Before discussing how to split, a bigger question is that is it fine to
>>> support both i.MX8qxp DC and i.MX95 DC in the same imx8_dc_drm
>> module?
>>> Separate modules look more reasonable to me, considering the fact that
>>> there are quite a lot difference between the two DCs.
>>
>> (maybe I do not quite understand your suggestion with "separate module",
>> I assume this means entirely duplicate driver, is that correct? I
>> operate with that assumption in the text below.)
> 
> I'd expect separate modules: the existing imx8_dc_drm(which can be
> modprobe'd) and something like imx95_dc_drm.  I wouldn't call them
> *entirely* duplicated drivers since I mentioned common part of the DCs
> could be wrapped as helpers in an additional module(something like
> imx_dc_drm_common).

How would this look if everything is built into the kernel ?

>> This series indicates that the functional units in the DC are basically
>> identical, with the majority of changes being register base addresses of
>> the whole DC and an odd bit or register offset here and there. Most of
>> the code can be reused, as can be seen in the first half of the series.
> 
> The major differences between the i.MX95 and i.MX8qxp DCs are
> different components in Display Engines(especially the additional
> Domain Blend Unit in i.MX95 DC)

This seems to be one component in the whole pipeline, with links going 
into it. Those links are already in place. Maybe I am not seeing the 
specialty of this particular DB component ?

> plus i.MX8qxp DC's capability
> to connect with the prefetch engines(DPRC & PRG).

Isn't the prefetch engine only a bit of register configuration, that can 
be abstracted out ?

> Both would
> have significant impact on how we implement the drivers.  We'll
> certainly end up having different implementations for callbacks to
> enable/disable CRTCs or update/disable planes.

It doesn't seem they have to be entirely different so far, do they ?

> The sort of minor difference is in Pixel Engine(including Blit Engine)
> where FethUnit types and numbers are different plus different numbers
> of Scaler Engine.  I'd expect logics to allocate FetchUnits for planes can be
> implemented in the imx_dc_drm_common module

This part is fine, but ultimately, it would have to be possible to build 
both the MX8Q and MX95 drivers into the kernel too. And then there would 
have to be some logic to deal with that, likely based on driver data, as 
it is done here.

>> The addition of iMX95 into the iMX8QXP DC also does not seem to be
>> making the driver in any way more complicated.
> 
> Disagree. The addition would introduce quite a few i.MX95 or i.MX8qxp
> DC specific code branches due to the differences mentioned above.

This does not need to be the case, see the first half of this series ?

> I'd say i.MX95 DC support could be in drivers/gpu/drm/imx/dc, but it
> needs to be in a separate module like again imx95_dc_drm.
> 
> This makes feel that the debate here becomes kind of similar to what
> we did for single mxsfb module vs  mxsfb + imx_lcdif separate modules...

The mxsfb (the old iMX23 LCDIF) and lcdifv3 (the new iMX8MP/iMXRT LCDIF) 
are entirely different hardware IPs, the former is from SigmaTel , the 
later is from somewhere else, right ?

>> What would be the benefit of having duplicate driver for IP that is
>> basically identical, for i.MX95 ?
> 
> Cleaner driver implementation and easier to maintain.  I don’t want
> to test both i.MX95 and i.MX8qxp platforms when only either
> i.MX95 DC specific or i.MX8qxp DC specific code is changed.
> 
> But again, they won't be entirely duplicated drivers.  Common
> part could be shared between the drivers with software techniques,
> like the imx_dc_drm_common module mentioned above.
Please have a look at the first part of this patchset, there do not seem 
to be that many new or complex branches.