Re: [PATCH v4 07/14] drm/imx: dc: Add DPR channel support

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

On 11/02/2025, Marek Vasut wrote:
> On 10/20/25 4:47 AM, Liu Ying wrote:
> 
> Hello Liu,

Hello Marek,

> 
> sorry for my late reply.
> 
>>>> +++ b/drivers/gpu/drm/imx/dc/Kconfig
>>>> @@ -1,6 +1,7 @@
>>>>    config DRM_IMX8_DC
>>>>        tristate "Freescale i.MX8 Display Controller Graphics"
>>>>        depends on DRM && COMMON_CLK && OF && (ARCH_MXC || COMPILE_TEST)
>>>> +    depends on IMX_SCU
>>> Can the SCU dependency be made optional,
>>
>> I don't think this can be done.  If you grep 'depends on IMX_SCU' in
>> kernel, you may find a handful of existing dependancies.
> 
> Sure, I do not dispute this part.
> 
> But the SCU dependency can be contained in a component of this driver,
> which is not used by MX95, and used only by MX8Q . Then there will be
> no problem.

Which component?  You mean PRG and DPRC?

If we add something like CONFIG_DRM_IMX8_DC_PRG and make CONFIG_DRM_IMX8_DC_PRG
depend on SCU, then should we make CONFIG_DRM_IMX8_DC depend on
CONFIG_DRM_IMX8_DC_PRG?  That's yet another dependency.

> 
>>> or per-module,
>>
>> Well, DRM_IMX8_DC(for the imx8_dc_drm module) depends on IMX_SCU just as
>> this patch does.
> 
> I assume it shouldn't have to, because the SCU dependency is only relevant
> for the prefetch engine ?

The SCU dependency is only relevant for the prefetch engine, agreed.
But, how to avoid the dependency?

> 
>>> or somehow abstracted out (via regmap?),
>>
>> Like I replied to your i.MX95 DC patch series's cover letter, SCU accesses
>> registers via Cortex-M core instead of Cortex-A core IIUC.  I really don't
>> know how to abstract IMX_SCU out, especially via regmap.
> 
> The simplest way would be to use regmap_config .reg_read and .reg_write ,
> if there is no better way.

Can you shed more light on this?  Any examples?

> 
>>> so iMX95 support can be added into the driver easily too ?
>>
>> Like I replied to your i.MX95 DC patch series, I think i.MX95 DC support
>> can be in drivers/gpu/drm/imx/dc, but it should be in a separate module
>> (something like imx95_dc_drm) plus an additional common module(like
>> imx_dc_drm_common).
> This design part is something I do not fully understand. Sure, it can be
> two modules, but in the end, the result would have to be capable of being
> compiled into single kernel binary if both modules would be =y in Kconfig
> anyway.

This is something like imx8qm_ldb, imx8qxp_ldb and imx_ldb_helper modules -
DRM_IMX8QM_LDB and DRM_IMX8QXP_LDB select DRM_IMX_LDB_HELPER.

Note you may make CONFIG_DRM_IMX8QM_LDB=y and CONFIG_DRM_IMX8QXP_LDB=m with
CONFIG_DRM_IMX_LDB_HELPER=y.

-- 
Regards,
Liu Ying