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. (this is probably
what "oneshot" now tries to be...)
- Alarm interface should be a client for a single arch_timers, 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.
##########
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. (this is probably
what "oneshot" now tries to be...)
- 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
