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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <de695268-1241-4658-871c-30dbf068ad92@mailbox.org>
Date: Sun, 9 Nov 2025 20:11:02 +0100
From: Marek Vasut <marek.vasut@...lbox.org>
To: Liu Ying <victor.liu@....com>, Philipp Zabel <p.zabel@...gutronix.de>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
 Sascha Hauer <s.hauer@...gutronix.de>,
 Pengutronix Kernel Team <kernel@...gutronix.de>,
 Fabio Estevam <festevam@...il.com>, Dmitry Baryshkov <lumag@...nel.org>
Cc: dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
 imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org, Frank Li <Frank.Li@....com>
Subject: Re: [PATCH v4 07/14] drm/imx: dc: Add DPR channel support

On 11/4/25 8:18 AM, Liu Ying wrote:

Hello Liu,

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

I would say, if possible, put the SCU-dependent parts behind 
CONFIG_DRM_IMX8_DC_PRG symbol, and make that symbol configurable via 
Kconfig . Users of iMX95-only can turn it off, generic kernel config 
should keep it on.

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

How about containing the SCU parts in a single file and put it behind a 
Kconfig symbol ? The common code can call the SCU parts and they would 
either use SCU (on MX8QXP) or do nothing (on MX95) . It should even be 
possible to discern this at runtime.

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

I'll just reply to this part, because that is probably the most relevant 
to this whole conversation.

git grep '\.reg_write' drivers -> drivers/hwmon/aspeed-pwm-tacho.c as a 
simple example.

Then such a reg_write implementation can do:

if (SCU)
   use SCU accessor
else
   use writel() or so

>>>> 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.
Do we have to make it this complicated right from the start ? Maybe we 
can start simple, with one module, and then split it up if it turns out 
to be unsuitable ?