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: <df8751ba-7215-4635-98b0-ca659ec786cd@nxp.com>
Date: Tue, 4 Nov 2025 15:18:09 +0800
From: Liu Ying <victor.liu@....com>
To: Marek Vasut <marek.vasut@...lbox.org>,
 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/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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ