On Sun, Dec 08, 2024 at 06:38:50PM +0200, Markuss Broks wrote: > > On 12/6/24 9:50 PM, Daniel Lezcano wrote: > > On 12/6/24 14:28, Krzysztof Kozlowski wrote: > > > On Fri, Dec 06, 2024 at 12:39:56AM +0100, Daniel Lezcano wrote: > > > > > +# 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
