NXP support lptmr tickless function #95143

yongxu-wang15 · 2025-08-29T08:46:24Z

added lptmr tickless function
verified in imx95 m7 core which enabled PM and tickless

yongxu-wang15 · 2025-09-24T02:00:56Z

Updated to fixed dts conflict with newly commit modification.

Hi, this PR is aim to support nxp lptmr tickless function, and supported it in imx95 m7, can you help review it when you time free?

Thanks

decsny · 2025-09-29T16:40:51Z

@mmahadevan108 please help review this

mmahadevan108 · 2025-09-30T18:09:53Z

ping @henrikbrixandersen @DerekSnell
There is a mention in the Reference Manual that "If LPTMR is enabled, you must alter CMR only if TCF = 1." Is this accounted for in your PR.

henrikbrixandersen · 2025-09-30T18:37:43Z

ping @henrikbrixandersen @DerekSnell There is a mention in the Reference Manual that "If LPTMR is enabled, you must alter CMR only if TCF = 1." Is this accounted for in your PR.

Yeah, this is the reason I did not implement tickless mode in this driver when I originally submitted it (see 21806b5).

yongxu-wang15 · 2025-10-16T08:37:43Z

Hi @mmahadevan108 , I have added disable/start code logic in LPTMR_SetTimerPeriod to avoid the hardware limitations, tested passed on imx95 m7 power_mgmt_soc test case, the time sleep and tick record is right in my side, please help reivew it when you time free, thanks

henrikbrixandersen

Stopping/starting the timer when setting a new timeout will affect the ticks (as the time all the instructions between stopping and starting will not be counted). I don't think this is an acceptable solution.

yongxu-wang15 · 2025-10-17T08:58:52Z

Hi @henrikbrixandersen I fully understand your concerns. After reconfirming with the design team, we need to ensure that there is sufficient time when updating the CMP. We can choose to reset(but this will cause the time to go back instead of monotonically increasing. Even through software, it is difficult to guarantee that there are no corner cases). In the latest commit, I added a protection mechanism. When the distance is very close, It will postpone a windo to prevent it from being triggered. Of course, this should depend on different SoCs, please help review it again when you time free, thanks a lot

sonarqubecloud · 2025-10-17T09:09:13Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

henrikbrixandersen · 2025-10-24T13:25:10Z

Hi @henrikbrixandersen I fully understand your concerns. After reconfirming with the design team, we need to ensure that there is sufficient time when updating the CMP. We can choose to reset(but this will cause the time to go back instead of monotonically increasing. Even through software, it is difficult to guarantee that there are no corner cases). In the latest commit, I added a protection mechanism. When the distance is very close, It will postpone a windo to prevent it from being triggered. Of course, this should depend on different SoCs, please help review it again when you time free, thanks a lot

I'd like to hear @andyross and @teburd (System timer maintainer/collaborator) view on this. I am unsure if this is a good solution.

yongxu-wang15 · 2025-11-17T09:20:27Z

Hi @henrikbrixandersen, Has there been any progress on this issue? thanks

henrikbrixandersen · 2025-11-18T10:44:09Z

Hi @henrikbrixandersen, Has there been any progress on this issue? thanks

@teburd, @andyross Ping?

teburd · 2025-11-18T17:30:57Z

The design of kernel timers is time never stops (free running counter) that you may set a compare to catch sometime in the future.

Stopping/Starting the underlying timer will surely introduce timing drift and jitter, something that tends to surprise and upset people when they see it. My opinion is that if your hardware needs to stop and start to set the compare, this hardware isn't a good source for kernel timers without at least some build warnings informing people building with it that yes, this is what they really want.

I'm not going to stop a vendor from supplying a driver that introduces drift/jitter. But I do feel like I can say we should warn about it.

Unless you can perhaps show in the PR the external tool test from https://github.com/zephyrproject-rtos/zephyr/tree/main/tests/kernel/timer/timer_behavior with correct timer behavior with this driver with the start/stop behavior? Maybe its ok, I don't know!

Holt-Sun · 2025-11-19T03:27:45Z

soc/nxp/imx/imx9/imx95/Kconfig.defconfig.mimx95.m7

+	default y
+
+config SYS_CLOCK_TICKS_PER_SEC
+	default 1000


Consider to set default to 1024.
For default 1000, since SYS_CLOCK_HW_CYCLES_PER_SEC = 32768, then CYCLES_PER_TICK = 32768 / 1000 = 32 (fractional part is dropped), so one OS “tick” is 32 hardware cycles, than tick_rate = tick_rate = 32768 / 32 = 1024 ticks/s, but the configuration says "1000 ticks/s", there is 2.4% drift.

For a 32768 Hz clock, Zephyr typically uses tick rates that divide 32768 exactly (1024, 512, 256, 128, …), in this way, there is no rafe shift.

sure, update into 1024 now, thanks

add lptmr1 node into imx95 m7 dts which locate on Always On domain and can continue work when whole soc enter system sleep mode Signed-off-by: Yongxu Wang <yongxu.wang@nxp.com>

remove lptmr2 and enable lptmr1 interface as default Signed-off-by: Yongxu Wang <yongxu.wang@nxp.com>

Enable lptmr interface to support counter_basic_api test case Signed-off-by: Yongxu Wang <yongxu.wang@nxp.com>

Use lptmr interface as system clock if enabled PM as system tick can't continue work in system suspend mode Signed-off-by: Yongxu Wang <yongxu.wang@nxp.com>

When tickless is enabled, it is necessary to ensure that lptmr can be set for a period of time instead of generating an interrupt at one tick Set lptmr to the free running mode to ensure that the current cycles value of lptmr can be directly obtained in ISR Signed-off-by: Yongxu Wang <yongxu.wang@nxp.com>

Add safety window mechanism to prevent race conditions when updating LPTMR compare register (CMR). Problem: - Setting CMR too close to current hardware counter can cause missed interrupts and system hangs Solution: - Implement lptmr_set_safe_immediate() with configurable safety window Signed-off-by: Yongxu Wang <yongxu.wang@nxp.com>

Tested imx95 m7 lptmr as system tick in timer_behavior test case Signed-off-by: Yongxu Wang <yongxu.wang@nxp.com>

yongxu-wang15 · 2025-11-19T09:21:28Z

The design of kernel timers is time never stops (free running counter) that you may set a compare to catch sometime in the future.

Stopping/Starting the underlying timer will surely introduce timing drift and jitter, something that tends to surprise and upset people when they see it. My opinion is that if your hardware needs to stop and start to set the compare, this hardware isn't a good source for kernel timers without at least some build warnings informing people building with it that yes, this is what they really want.

I'm not going to stop a vendor from supplying a driver that introduces drift/jitter. But I do feel like I can say we should warn about it.

Unless you can perhaps show in the PR the external tool test from https://github.com/zephyrproject-rtos/zephyr/tree/main/tests/kernel/timer/timer_behavior with correct timer behavior with this driver with the start/stop behavior? Maybe its ok, I don't know!

thanks your comments, have droped stop/start flow now, just added one customer safe window now, its 10 as default, and it can be set into different value to adapter socs. And added LOG_WRN in driver init, if you want to enlarge the safe window value, it will may introduce some timing drift and jitter.
And used lptmr 10 safe window to test as system tick, it seem passed in zephyr/tests/kernel/timer/timer_behavior, there is log:------ TESTSUITE SUMMARY START ------

SUITE PASS - 100.00% [timer_jitter_drift]: pass = 2, fail = 0, skip = 0, total = 2 duration = 39.339 seconds

PASS - [timer_jitter_drift.test_jitter_drift_timer_period] duration = 19.669 seconds
PASS - [timer_jitter_drift.test_jitter_drift_timer_startdelay] duration = 19.670 seconds

SUITE PASS - 100.00% [timer_tick_train]: pass = 1, fail = 0, skip = 0, total = 1 duration = 10.362 seconds

PASS - [timer_tick_train.test_one_tick_timer_train] duration = 10.362 seconds

------ TESTSUITE SUMMARY END ------

===================================================================
PROJECT EXECUTION SUCCESSFUL

thanks a lot for your time

sonarqubecloud · 2025-11-19T09:41:35Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

zejiang0jason · 2025-11-26T07:07:19Z

drivers/timer/Kconfig.mcux_lptmr

+	  If enabled, the driver will use SoC-specific default values.
+
+config MCUX_LPTMR_TIMER_SAFETY_WINDOW_CYCLES
+	int "MCUX LPTMR timer safety window cycles"


How can user choose a proper value, is there a guidance?

zejiang0jason · 2025-11-26T07:08:31Z

drivers/timer/mcux_lptmr_timer.c

+
+#define MAX_TICKS ((COUNTER_MAX / CYCLES_PER_TICK) - 1)
+#define MAX_CYCLES (MAX_TICKS * CYCLES_PER_TICK)
+#define MIN_DELAY  1000


how is this value decided?

zejiang0jason · 2025-11-26T07:13:58Z

drivers/timer/mcux_lptmr_timer.c

 #define CYCLES_PER_TICK ((uint32_t)((uint64_t)sys_clock_hw_cycles_per_sec() \
 			/ (uint64_t)CONFIG_SYS_CLOCK_TICKS_PER_SEC))

+#define COUNTER_MAX 0xffffffff


there is LPTMR which uses 16-bit counter. such as kw45.

zejiang0jason · 2025-11-26T07:26:28Z

drivers/timer/mcux_lptmr_timer.c

+		next += CYCLES_PER_TICK;
+	}
+
+	next += announced_cycles;


could this next overflow? which means in function lptmr_set_safe_immediate, target_cycles < hw_counter

zejiang0jason · 2025-11-26T07:27:51Z

soc/nxp/imx/imx9/imx95/Kconfig.defconfig.mimx95.m7

+	default y
+
+config SYS_CLOCK_TICKS_PER_SEC
+	default 1024


can be

default 1024 if MCUX_LPTMR_TIMER default 1000 if CORTEX_M_SYSTICK

also, I guess this should be outside of if PM ... endif

zejiang0jason · 2025-11-26T07:29:54Z

tests/kernel/timer/timer_behavior/boards/imx95_evk_mimx9596_m7.conf

@@ -0,0 +1,3 @@
+CONFIG_MCUX_LPTMR_TIMER=y
+CONFIG_TICKLESS_KERNEL=y
+CONFIG_SYS_CLOCK_TICKS_PER_SEC=1024


this can be removed if done in soc/nxp/imx/imx9/imx95/Kconfig.defconfig.mimx95.m7

zephyrbot added area: Timer Timer area: Counter platform: NXP MPU platform: NXP Drivers NXP Semiconductors, drivers labels Aug 29, 2025

zephyrbot requested review from JiafeiPan, Zhiqiang-Hou, andyross, dbaluta, decsny, dleach02, iuliana-prodan, manuargue, mmahadevan108, nordic-krch, teburd and yangbolu1991 August 29, 2025 08:47

zephyrbot assigned nordic-krch Aug 29, 2025

yongxu-wang15 force-pushed the NXP-support-lptmr-tickless-function branch from 2cf7357 to 0b787a8 Compare September 24, 2025 01:58

yongxu-wang15 force-pushed the NXP-support-lptmr-tickless-function branch 2 times, most recently from a4522f5 to 5b1791a Compare September 29, 2025 01:52

zephyrbot added platform: NXP NXP area: Tests Issues related to a particular existing or missing test area: Boards/SoCs labels Sep 29, 2025

zephyrbot requested a review from nashif September 29, 2025 01:54

yongxu-wang15 force-pushed the NXP-support-lptmr-tickless-function branch from 5b1791a to 099ead3 Compare September 29, 2025 05:15

yongxu-wang15 force-pushed the NXP-support-lptmr-tickless-function branch from 099ead3 to 6719da2 Compare October 16, 2025 08:32

henrikbrixandersen requested changes Oct 16, 2025

View reviewed changes

yongxu-wang15 force-pushed the NXP-support-lptmr-tickless-function branch 2 times, most recently from 2446f3e to ac6e777 Compare October 17, 2025 08:56

yongxu-wang15 force-pushed the NXP-support-lptmr-tickless-function branch from ac6e777 to 43ce283 Compare October 17, 2025 09:04

yongxu-wang15 mentioned this pull request Oct 28, 2025

tests: tests/subsys/pm/power_mgmt_soc: imx95_evk/mimx9596/m7: failed: Unknown Error #98296

Open

decsny mentioned this pull request Oct 30, 2025

soc: mcxw7x: PM not working properly. Issues with timing and flashing #98484

Open

Holt-Sun reviewed Nov 19, 2025

View reviewed changes

yongxu-wang15 force-pushed the NXP-support-lptmr-tickless-function branch from 43ce283 to 2f0b7c7 Compare November 19, 2025 08:52

zephyrbot added the area: Kernel label Nov 19, 2025

zephyrbot requested a review from peter-mitsis November 19, 2025 08:53

yongxu-wang15 added 7 commits November 19, 2025 17:12

dts: arm: nxp: imx95_m7: add lptmr1 node

c9d10fd

add lptmr1 node into imx95 m7 dts which locate on Always On domain and can continue work when whole soc enter system sleep mode Signed-off-by: Yongxu Wang <yongxu.wang@nxp.com>

board: nxp: imx95_evk_mimx9596_m7: set lptmr1 interface

a8bdb4c

remove lptmr2 and enable lptmr1 interface as default Signed-off-by: Yongxu Wang <yongxu.wang@nxp.com>

test: counter_basic_api: add imx95 evk m7 support

de94c7a

Enable lptmr interface to support counter_basic_api test case Signed-off-by: Yongxu Wang <yongxu.wang@nxp.com>

soc: nxp: imx95: use lptmr if enabled PM

d54bea5

Use lptmr interface as system clock if enabled PM as system tick can't continue work in system suspend mode Signed-off-by: Yongxu Wang <yongxu.wang@nxp.com>

tests: timer: timer_behavior: enabled imx95 lptmr as system tick test

12f0265

Tested imx95 m7 lptmr as system tick in timer_behavior test case Signed-off-by: Yongxu Wang <yongxu.wang@nxp.com>

yongxu-wang15 force-pushed the NXP-support-lptmr-tickless-function branch from 2f0b7c7 to 12f0265 Compare November 19, 2025 09:14

yongxu-wang15 requested a review from henrikbrixandersen November 19, 2025 09:22

zejiang0jason mentioned this pull request Nov 26, 2025

drivers: counter: lptmr: Fix get_pending_int wrong implementation #99784

Merged

zejiang0jason requested changes Nov 26, 2025

View reviewed changes

NXP support lptmr tickless function #95143

Are you sure you want to change the base?

NXP support lptmr tickless function #95143

Conversation

yongxu-wang15 commented Aug 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yongxu-wang15 commented Sep 24, 2025

Uh oh!

decsny commented Sep 29, 2025

Uh oh!

mmahadevan108 commented Sep 30, 2025

Uh oh!

henrikbrixandersen commented Sep 30, 2025

Uh oh!

yongxu-wang15 commented Oct 16, 2025

Uh oh!

henrikbrixandersen left a comment

Choose a reason for hiding this comment

Uh oh!

yongxu-wang15 commented Oct 17, 2025

Uh oh!

sonarqubecloud bot commented Oct 17, 2025

Quality Gate passed

Uh oh!

henrikbrixandersen commented Oct 24, 2025

Uh oh!

yongxu-wang15 commented Nov 17, 2025

Uh oh!

henrikbrixandersen commented Nov 18, 2025

Uh oh!

teburd commented Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yongxu-wang15 commented Nov 19, 2025

Uh oh!

sonarqubecloud bot commented Nov 19, 2025

Quality Gate passed

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

yongxu-wang15 commented Aug 29, 2025 •

edited

Loading

teburd commented Nov 18, 2025 •

edited

Loading