On Sun, Dec 08, 2024 at 06:38:50PM +0200, Markuss Broks wrote:

On 12/6/24 9:50 PM, Daniel Lezcano wrote:

quoted

On 12/6/24 14:28, Krzysztof Kozlowski wrote:

quoted

On Fri, Dec 06, 2024 at 12:39:56AM +0100, Daniel Lezcano wrote:

quoted

quoted

+# SPDX-License-Identifier: GPL-2.0-only
+
+config EXYNOS_ACPM_PROTOCOL
+    tristate "Exynos Alive Clock and Power Manager (ACPM)
Message Protocol"

Given the importance of this driver where a lot of PM services
rely on, does
it really make sense to allow it as a module ?

Some PM services may be needed very early in the boot process

If it works as module e.g. on Android, it is beneficial. I think the
platform was booting fine without it, at least to some shell, so I can
imagine this can be loaded a bit later.

Usually the firmware sets the frequency to the maximum in order to boot
the kernel as fast as possible. That may lead to thermal issues at boot
time where the thermal framework won't be able to kick in as some
components will depends on ACPM while the system stays at its highest
performance state.

I disagree with the first assumption: usually firmware selects high, but
safe frequency. Otherwise you would not be able to wait in bootloader
prompt.

Also, as far as I understand, ACPM is used here as an interface to the PMIC,
so every driver which would need power management from the main SoC PMIC
would get deferred until the ACPM module has been loaded. This would make it

It was an issue 10 years ago, not anymore. Drivers handle deferred
probe.

impossible to e.g. initialize the UFS or the MMC card before initramfs.

Which is not a problem, because you are supposed to have initramfs. This
is preferred way. Being this a module does not force you to use it as a
module, e.g. if in your setup you do not have initramfs (although it is
unlikely for arm64 platforms...).

Best regards,
Krzysztof