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:
- There would be 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. (this is probably what "oneshot" now tries to be, but it is mixed with
systicks and whatnot...)
- Alarm interface should be a client for a single arch_timer, supporting a
queue of alarms. 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
