xiaoxiang781216 commented on code in PR #18816:
URL: https://github.com/apache/nuttx/pull/18816#discussion_r3161953866
##########
sched/clock/clock_settime.c:
##########
@@ -82,7 +94,24 @@ static void nxclock_set_realtime(FAR const struct timespec
*tp)
# ifdef CONFIG_RTC
if (g_rtc_enabled)
{
+# ifdef CONFIG_SCHED_LPWORK
+ /* Setting the current time in RTC may be a blocking operation (driver
+ * needs to wait for oscillator stabilization after reset and so on).
+ * This may cause the unwanted effect of clock_settime blocking the
+ * code execution for a considerable amount of time.
+ *
+ * The solution is to plan a low priority work that takes care
+ * of setting the time in RTC and let clock_settime continue. We don't
+ * have to check if the work is available, just cancel it if there
+ * is a new time set request.
+ */
+
+ g_rtc_to_set = *tp;
+ work_queue(LPWORK, &g_rtc_work, rtc_worker,
Review Comment:
> True, but blocking for 30 ms is also not correct. The user can choose
higher priority for lp work if the system is really busy and preempt other not
so important tasks. Most RTCs store time in seconds, so the write would have to
be significantly delayed to show any time drift.
it's depends on hardware, nuttx even has the code to support the high res
RTC(CONFIG_RTC_HIRES).
>
> I don't really see other good solution here, except from removing RTC set
from `clock_settime` and having a separate API like Linux.
you can update RTC through /dev/rtcx.
BT, timespec has two fields, the second clock_settime may corrupt the
setting in the work thread.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
