jlaitine commented on code in PR #16485:
URL: https://github.com/apache/nuttx/pull/16485#discussion_r2128016198
##########
arch/risc-v/Kconfig:
##########
@@ -214,6 +214,8 @@ config ARCH_CHIP_MPFS
select ARCH_HAVE_PWM_MULTICHAN
select ARCH_HAVE_S_MODE
select ARCH_RV_CPUID_MAP
+ select ARCH_HAVE_PERF_EVENTS
+ select ARCH_PERF_EVENTS
Review Comment:
I'll try to refine the solution like this:
https://github.com/apache/nuttx/pull/16487
I believe this fixes your concern (if it passes the CI ...)
Btw. I am not quite happy how the high resolution hardware timer and
arch_alarm and oneshot are tied together, and also perf functions being there
as well. Architecturally, IMHO, it would be cleaner if:
- An architecture specific timer interface, supporting reading a HW timer;
something like clock_t "arch_timer_get(int timer_id)", "arch_timer_freq(int
timer_id)" and functions to set register interrupt cb for absolute and relative
timeout time (one registration per timer). This is something that every
architecture supports anyhow, currently for a single timer.
- Alarm interface should support a queue of alarms, where any kernel driver
could just register an alarm (with relative and/or absolute time). There could
be also a connection to power management/wakeup support for calendar alarms
from here.
- up_perf_* functions would be just defined to arch_timer_get,
arch_timer_freq...
- Watchdogs would just register an alarm to alarm interface
- Systick would just register an alarm to alarm interface
This would allow registering precise alarm callbacks also for ticked
systems, and harmonize the functionality between systicked/tickless
architectures.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
