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 ?
