Add module support for Arm64 Exynos MCT driver

This series adds support to build the Arm64 Exynos MCT driver as a module. This is only possible on Arm64 SoCs since they can use the Arm architected timer as the clocksource. Once the Exynos MCT module is loaded and the device probes, the MCT is used as the wakeup source for the arch_timer to ensure the device can wakeup from the "c2" idle state.

These patches are originally from the downstream Pixel 6 (gs101) kernel found at [1] and have been adapted for upstream. Not only has the Exynos MCT driver been shipping as a module in the field with Android, but I've also tested this series with the upstream kernel on my Pixel 6 Pro.

To verify the module on Pixel 6 Pro is used and the arch_timer is used as the main clocksource, I ran these tests:

# lsmod | grep exynos_mct
exynos_mct             24576  9 [permanent]

$ cat /proc/interrupts | grep -E "mct|arch_timer"
 23:        222        171        211        139        184        124        825        378    GICv3  30 Level     arch_timer
117:          1          0          0          0          0          0          0          0    GICv3 785 Level     mct_comp_irq
118:        228          0          0          0          0          0          0          0    GICv3 789 Level     mct_tick0
119:          0        351          0          0          0          0          0          0    GICv3 790 Level     mct_tick1
120:          0          0       1490          0          0          0          0          0    GICv3 791 Level     mct_tick2
121:          0          0          0        325          0          0          0          0    GICv3 792 Level     mct_tick3
122:          0          0          0          0         97          0          0          0    GICv3 793 Level     mct_tick4
123:          0          0          0          0          0        150          0          0    GICv3 794 Level     mct_tick5
124:          0          0          0          0          0          0        188          0    GICv3 795 Level     mct_tick6
125:          0          0          0          0          0          0          0        157    GICv3 796 Level     mct_tick7

# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
arch_sys_counter

I also compile tested for ARCH=ARM DEFCONFIG=multi_v7_defconfig with the following debug configs to ensure the section mismatches are fixed:
CONFIG_DEBUG_SECTION_MISMATCH=y
# CONFIG_SECTION_MISMATCH_WARN_ONLY is not set

Any additional testing is much appreciated!

Thanks,
Will

Note1, instructions to build and flash a Pixel 6 device with the upstream kernel can be found at [2].

Note2, this series is based off of krzk/for-next commit 870f6ca955ea ("Merge branch 'next/clk' into for-next").

[1] https://android.googlesource.com/kernel/gs/+log/refs/heads/android-gs-raviole-5.10-android12-d1
[2] https://gitlab.com/LinaroLtd/googlelt/pixelscripts/-/blob/clo/main/README.md?ref_type=heads

---

Changes in v6:
- Updated module support to only register the MCT driver as a platform driver for ARM64 to ensure ARM 32-bit SoCs continue to probe the MCT driver very early.
- Squashed the percpu fix suggested by Marek Szyprowski in
https://lore.kernel.org/all/[email protected]/
together with patch 3/6.

Changes in v5:
- Fixed section mismatch issues.
- Addressed Arnd's concerns regarding potential issues with unloading and/or unbinding the driver.
- Fixed SoB concerns to clarify the development chain from AOSP to Linux.
- Pulled in https://lore.kernel.org/all/[email protected]/
to limit percpu interrupts only for ARM64.

Changes in v4:
- Missed the "v3" string in the previous series for the actual patches
- Re-generated patches with --base a15edf91668beefdb5171c53fa698c9b43dd1e0d for kernel test robot.

Changes in v3:
- Rebased on top of Daniel's timer modularization prep series [3] and krzk/for-next commit a15edf91668b ("Merge branch 'next/dt64' into for-next")
- Added owner references to Exynos MCT clocksource and clockevent objects.
- Dropped #ifdef MODULE conditional section in favor of just using module_platform_driver() which will properly handle setting up the of_device_id table based on if the driver is built-in or a module.
- Update commit message for patch 2 based on John's feedback.
- Dropped DT change from v2 as it was picked up by Krzysztof for CPU Idle.

Changes in v2:
- Re-worked patch v1 5 based on Rob Herring's review to use the compatible data for retrieving the mct_init function pointer.
- Updated the Kconfig logic to disallow building the Exynos MCT driver as a module for ARM32 configurations based on Krzysztof Kozlowski's findings.
- Added comments and clarified commit messages in patches 1 and 2 based on reviews from John Stultz and Youngmin Nam.
- Fixed an issue found during testing that resulted in the device getting stuck on boot. This is included in v2 as patch 5.
- Collected *-by tags
- Rebased to the latest linux-next/master.
---

Donghoon Yu (2):
clocksource/drivers/exynos_mct: Don't register as a sched_clock on

    arm64

clocksource/drivers/exynos_mct: Add module support for ARM64

Hosung Kim (1):
clocksource/drivers/exynos_mct: Set percpu local timer interrupts for

    ARM64

Will McVicker (3):
ARM: make register_current_timer_delay() accessible after init clocksource/drivers/exynos_mct: Fix uninitialized irq name warning
arm64: exynos: Drop select CLKSRC_EXYNOS_MCT

 arch/arm/lib/delay.c             |  2 +-
 arch/arm64/Kconfig.platforms     |  1 -
 drivers/clocksource/Kconfig      |  3 +-
 drivers/clocksource/exynos_mct.c | 87 +++++++++++++++++++++++++++-----
 4 files changed, 78 insertions(+), 15 deletions(-)

base-commit: 870f6ca955ea3f23b4d7824c815c81180a6d7c48

2.52.0.rc2.455.g230fcf2819-goog

The function register_current_timer_delay() is called from the exynos_mct clocksource driver at probe time. In the event that the exynos_mct driver is probed deferred or the platform manually unbinds and rebinds the driver we need this function available. So drop the __init tag.

---
 arch/arm/lib/delay.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index b7fe84f68bf1..acfb87143f21 100644
@@ -62,7 +62,7 @@ static void __timer_udelay(unsigned long usecs)
 	__timer_const_udelay(usecs * UDELAY_MULT);
 }
 
-void __init register_current_timer_delay(const struct delay_timer *timer)
+void register_current_timer_delay(const struct delay_timer *timer)
 {
 	u32 new_mult, new_shift;
 	u64 res;

2.52.0.rc2.455.g230fcf2819-goog

Is this change supposed to fix an existing bug or is it a guess it could happen ? If the latter, I prefer to not pick this patch until is proven it fixes an observed issue.

<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

First question. Why.

Second, have you analysed the code to check that you _can_ call this after init time?

Let's look at the code:

        if (!delay_calibrated && (!delay_res || (res < delay_res))) {
        } else {
                pr_info("Ignoring duplicate/late registration of read_current_ti
mer delay\n");
        }

So, if delay_calibrated is set, then this will fail. When is that set? It's set by calibrate_delay_is_known() and calibration_delay_done(). When are these called? Basically after calibrate_delay() has finished. When is calibrate_delay() called? It's called by start_kernel(), while the init sections are still present.

So, calling this _after_ the init sections has been freed will result in the above pr_info() printed and this function doing *nothing*. So it's utterly pointless to call if the init sections have been freed.

Please find a different solution.

RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Hi Daniel and Russell,

Sorry for not explaining this very well. Let me fill in the gaps.

Sorry for wasting your time digging into this! You're right we shouldn't (and don't) call register_current_timer_delay() after the init sections are freed. This change was made purely to address the section mismatch compile-time errors. The Exynos MCT driver cannot be compiled as a module for ARM 32-bit devices; however, since ARM64 and ARM devices both call the function exynos4_clocksource_init() and ARM64 configurations can set the MCT driver as a module, we hit a section mismatch error due to calling an __init tagged function -- register_current_timer_delay() -- from a non-init tagged function -- exynos4_clocksource_init(). If you inspect the code, you will see that register_current_timer_delay() is compiled out of the driver for ARM64. To avoid hacking up the MCT driver with more #if defined(CONFIG_ARM) to handle this section mismatch, I decided it was cleaner to drop the __init tag.

I'd be happy to re-factor the MCT driver to split up the ARM and ARM64 parts of exynos4_clocksource_init() to avoid the section mismatch altogher in order to keep the __init tag for register_current_timer_delay(). Given the comments here, I think that makes sense.

I hope that explains it. Let me know if I overlooked anything.

Thanks,
Will

From: Donghoon Yu <[email protected]>

The MCT register is unfortunately very slow to access, but importantly does not halt in the c2 idle state. So for ARM64, we can improve performance by not registering the MCT for sched_clock, allowing the system to use the faster ARM architected timer for sched_clock instead.

The MCT is still registered as a clocksource, and a clockevent in order to be a wakeup source for the arch_timer to exit the "c2" idle state.

Since ARM32 SoCs don't have an architected timer, the MCT must continue to be used for sched_clock. Detailed discussion on this topic can be found at [1].

[1] https://lore.kernel.org/linux-samsung-soc/[email protected]/

[Original commit from https://android.googlesource.com/kernel/gs/+/630817f7080e92c5e0216095ff52f6eb8dd00727

---
 drivers/clocksource/exynos_mct.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

index da09f467a6bb..96361d5dc57d 100644
@@ -219,12 +219,18 @@ static struct clocksource mct_frc = {
 	.resume		= exynos4_frc_resume,
 };
 
+/*
+ * Since ARM devices do not have an architected timer, they need to continue
+ * using the MCT as the main clocksource for timekeeping, sched_clock, and the
+ * delay timer. For AARCH64 SoCs, the architected timer is the preferred
+ * clocksource due to it's superior performance.
+ */
+#if defined(CONFIG_ARM)
 static u64 notrace exynos4_read_sched_clock(void)
 {
 	return exynos4_read_count_32();
 }
 
-#if defined(CONFIG_ARM)
 static struct delay_timer exynos4_delay_timer;
 
 static cycles_t exynos4_read_current_timer(void)

@@ -250,12 +256,13 @@ static int __init exynos4_clocksource_init(bool frc_shared)
 	exynos4_delay_timer.read_current_timer = &exynos4_read_current_timer;
 	exynos4_delay_timer.freq = clk_rate;
 	register_current_timer_delay(&exynos4_delay_timer);
+
+	sched_clock_register(exynos4_read_sched_clock, 32, clk_rate);
 #endif
 
 	if (clocksource_register_hz(&mct_frc, clk_rate))
 		panic("%s: can't register clocksource\n", mct_frc.name);
 
-	sched_clock_register(exynos4_read_sched_clock, 32, clk_rate);
 
 	return 0;
 }

2.52.0.rc2.455.g230fcf2819-goog

From: Hosung Kim <[email protected]>

To allow the CPU to handle it's own clock events, we need to set the IRQF_PERCPU flag. This prevents the local timer interrupts from migrating to other CPUs. This is only supported on ARM64.

---
 drivers/clocksource/exynos_mct.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

index 96361d5dc57d..1429b9d03a58 100644
@@ -596,7 +596,9 @@ static int __init exynos4_timer_interrupts(struct device_node *np,
 			irq_set_status_flags(mct_irq, IRQ_NOAUTOEN);
 			if (request_irq(mct_irq,
 					exynos4_mct_tick_isr,
-					IRQF_TIMER | IRQF_NOBALANCING,
+					IRQF_TIMER | IRQF_NOBALANCING |
+					(IS_ENABLED(CONFIG_ARM64) ?
+					 IRQF_PERCPU : 0),
 					pcpu_mevt->name, pcpu_mevt)) {
 				pr_err("exynos-mct: cannot register IRQ (cpu%d)\n",
 									cpu);

2.52.0.rc2.455.g230fcf2819-goog

The Exynos MCT driver doesn't set the clocksource name until the CPU hotplug state is setup which happens after the IRQs are requested. This results in an empty IRQ name which leads to the below warning at proc_create() time. When this happens, the userdata partition fails to mount and the device gets stuck in an endless loop printing the error:

root '/dev/disk/by-partlabel/userdata' doesn't exist or does not contain a /dev.

To fix this, we just need to initialize the name before requesting the IRQs.

Warning from Pixel 6 kernel log:

[  T430] name len 0
[  T430] WARNING: CPU: 6 PID: 430 at fs/proc/generic.c:407 __proc_create+0x258/0x2b4
[  T430] Modules linked in: dwc3_exynos(E+)
[  T430]  ufs_exynos(E+) phy_exynos_ufs(E)
[  T430]  phy_exynos5_usbdrd(E) exynos_usi(E+) exynos_mct(E+) s3c2410_wdt(E)
[  T430]  arm_dsu_pmu(E) simplefb(E)
[  T430] CPU: 6 UID: 0 PID: 430 Comm: (udev-worker) Tainted:
         ... 6.14.0-next-20250331-4k-00008-g59adf909e40e #1 ...
[  T430] Tainted: [W]=WARN, [E]=UNSIGNED_MODULE
[  T430] Hardware name: Raven (DT)
[...]
[  T430] Call trace:
[  T430]  __proc_create+0x258/0x2b4 (P)
[  T430]  proc_mkdir+0x40/0xa0
[  T430]  register_handler_proc+0x118/0x140
[  T430]  __setup_irq+0x460/0x6d0
[  T430]  request_threaded_irq+0xcc/0x1b0
[  T430]  mct_init_dt+0x244/0x604 [exynos_mct ...]
[  T430]  mct_init_spi+0x18/0x34 [exynos_mct ...]
[  T430]  exynos4_mct_probe+0x30/0x4c [exynos_mct ...]
[  T430]  platform_probe+0x6c/0xe4
[  T430]  really_probe+0xf4/0x38c
[...]
[  T430]  driver_register+0x6c/0x140
[  T430]  __platform_driver_register+0x28/0x38
[  T430]  exynos4_mct_driver_init+0x24/0xfe8 [exynos_mct ...]
[  T430]  do_one_initcall+0x84/0x3c0
[  T430]  do_init_module+0x58/0x208
[  T430]  load_module+0x1de0/0x2500
[  T430]  init_module_from_file+0x8c/0xdc

---
 drivers/clocksource/exynos_mct.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

index 1429b9d03a58..fece6bbc190e 100644
@@ -465,8 +465,6 @@ static int exynos4_mct_starting_cpu(unsigned int cpu)
 		per_cpu_ptr(&percpu_mct_tick, cpu);
 	struct clock_event_device *evt = &mevt->evt;
 
-	snprintf(mevt->name, sizeof(mevt->name), "mct_tick%d", cpu);
-
 	evt->name = mevt->name;
 	evt->cpumask = cpumask_of(cpu);
 	evt->set_next_event = exynos4_tick_set_next_event;

@@ -567,6 +565,14 @@ static int __init exynos4_timer_interrupts(struct device_node *np,
 	for (i = MCT_L0_IRQ; i < nr_irqs; i++)
 		mct_irqs[i] = irq_of_parse_and_map(np, i);
 
+	for_each_possible_cpu(cpu) {
+		struct mct_clock_event_device *mevt =
+		    per_cpu_ptr(&percpu_mct_tick, cpu);
+
+		snprintf(mevt->name, sizeof(mevt->name), "mct_tick%d",
+			 cpu);
+	}
+
 	if (mct_int_type == MCT_INT_PPI) {
 
 		err = request_percpu_irq(mct_irqs[MCT_L0_IRQ],

2.52.0.rc2.455.g230fcf2819-goog

From: Donghoon Yu <[email protected]>

On Arm64 platforms the Exynos MCT driver can be built as a module. On boot (and even after boot) the arch_timer is used as the clocksource and tick timer. Once the MCT driver is loaded, it can be used as the wakeup source for the arch_timer.

---
 drivers/clocksource/Kconfig      |  3 +-
 drivers/clocksource/exynos_mct.c | 62 ++++++++++++++++++++++++++++----
 2 files changed, 57 insertions(+), 8 deletions(-)

index ffcd23668763..9450cfaf982f 100644
@@ -451,7 +451,8 @@ config ATMEL_TCB_CLKSRC
 	  Support for Timer Counter Blocks on Atmel SoCs.
 
 config CLKSRC_EXYNOS_MCT
-	bool "Exynos multi core timer driver" if COMPILE_TEST
+	tristate "Exynos multi core timer driver" if ARM64
+	default y if ARCH_EXYNOS || COMPILE_TEST
 	depends on ARM || ARM64
 	depends on ARCH_ARTPEC || ARCH_EXYNOS || COMPILE_TEST
 	help

2.52.0.rc2.455.g230fcf2819-goog

Since the Exynos MCT driver can be built as a module for some Arm64 SoCs like gs101, drop force-selecting it as a built-in driver by ARCH_EXYNOS and instead depend on default y if ARCH_EXYNOS to select it automatically. This allows platforms like Android to build the driver as a module if desired.

---
 arch/arm64/Kconfig.platforms | 1 -
 1 file changed, 1 deletion(-)

index 13173795c43d..fc6026c368ca 100644
@@ -128,7 +128,6 @@ config ARCH_CIX
 config ARCH_EXYNOS
 	bool "Samsung Exynos SoC family"
 	select COMMON_CLK_SAMSUNG
-	select CLKSRC_EXYNOS_MCT
 	select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
 	select EXYNOS_PMU
 	select PINCTRL

2.52.0.rc2.455.g230fcf2819-goog

Works fine on 32bit Exynos systems in my test farm!

Best regards

Marek Szyprowski, PhD
Samsung R&D Institute Poland

There are parts of this that are just totally incompatible with it being a module. For example, you can't register a replacement udelay loop after the system has booted.

This is the second time I've faced a patch series wanting to remove __init anntations to call it from a module, where the author has clearly not analysed the code to see whether that is a valid thing to do. This is unfair on reviewers - it is the submitters responsibility to check that what they are doing is valid.

Moreover, in _this_ case, you will have received a kernel diagnostic message stating that the call to register_current_timer_delay() was ignored, so I also question whether you bothered to run-time test this change.

RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Hi Russell,

Sorry for wasting your time on this due to my lack of explanation. PTAL at my response in the other patch set.

To address your testing concerns, this series has been thoroughly tested on Pixel 6 (ARM64) since 2021 starting with the 5.10 kernel version and is continually being tested on the latest kernel version today.

Thanks,
Will