cc8a794229
feat: 调度、任务及pm解耦
...
pm中冻结线程的操作，融合至OsSchedSuspend和OsSchedResume，
使得调度模块提供对应完整的方法给任务模块，做到之间的相互解耦，
方便其它调度算法的融入。
Close #I4JTN6
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: Ifde7077166a2fe67e7246fa68f777844640d67db
2021-11-25 16:54:02 +08:00
9f185b5b52
fix: pm模块解冻线程时存在删除空链表且时间片频繁唤醒系统
...
1.如果冻结线程状态为delay，则此时pendlist为NULL，解冻时不需要delete
2.低功耗时关闭时间片，减少时间片频繁唤醒系统
3.risc-v 中64位相加存在溢出
Close #I4AKUS
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: Icb9e8f7df8488635f9660d3932b06fa6f57e6133
2021-09-18 11:42:08 +08:00
9b5739ab11
feat: 低功耗支持冻结线程等需求
...
1.支持低功耗时冻结线程
2.支持延时锁
3.低功耗与idle分离
4.支持对接电源管组件的低功耗接口
LOS_PmReadLock --- 常阻塞，低功耗线程阻塞于该接口，当系统无任何模块持锁时会唤醒低功耗线程, 触发低功耗流程
LOS_PmSuspend --- 进入低功耗流程
Close #I49FJF
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: I009255cfa1852b109dd8bfaf9c779e976660d621
2021-09-14 19:55:26 +08:00
4e11ded476
!267 fix: 删除延时节点后，存在时间无法有效刷新的场景
...
Merge pull request !267 from zhushengle/sched
2021-08-19 00:39:21 +00:00
0a87c04d58
fix: 删除延时节点后，存在时间无法有效刷新的场景
...
1.从延时队列上删除延时节点时，如果该延时节点的响应时间比当前系统tick的响应时间小时，
将tick的响应时间修改为OS_SCHED_MAX_RESPONSE_TIME，以保证tick响应时间能够被刷新。
2.任务切换时，若g_schedResponseID为旧任务的taskID时(tick的响应时间为旧任务的时间片
结束时间)，将tick的响应时间修改为OS_SCHED_MAX_RESPONSE_TIME。
Close #I45I9Y
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: Ia77b789a10112935b719e8f733ba33835894e060
2021-08-14 15:53:28 +08:00
509cf59bef
fix: 以g_sysSchedStartTime是否为0判断时间轴是否生效存在极限场景导致调度时间不生效
...
初始化调度时间不以g_sysSchedStartTime是否为0为界限，而以g_sysSchedStartTime是否为64位最大值，
为界限, 避免特殊以下场景：调度开启时系统时间为0，导致初始化的g_sysSchedStartTime还是0，导致
调度启动后获取的调度时间轴始终为0.
Close #I45HP5
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: Ie0ef4e7d149f09ac466c649c0f2d6538f5322439
2021-08-14 11:30:46 +08:00
2118c84616
fix: tick 动态化计算优化，减小中断执行时间对系统总体时间的影响，保证软件定时器的响应精度。
...
方案描述：
1.周期软件定时器超时添加一个startTime字段，用于记录当前软件定时器的开始计时的时间，
在定时器响应时，开始时间修改为上一次响应的结束时间(消除了中断执行时间对软件定时器
的影响)。
2. 在执行tick中断的过程当中，持有tick动态计算锁，保证在该过程中不会触发tick周期
的计算，在tick中断结束时统一计算设置。 --- 提升tick中断的执行效率
3. 在设置tick周期时，减掉tick中断执行的时间，减小周期动态化带来的时间误差
4.新增LOSCFG_BASE_CORE_TICK_PER_SECOND_MINI配置宏，用于配置tick中断的最小响应精度
Close #I3YGP1
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: Ia53e4accce497bce870557c2c3387ce51fa3fed3
2021-08-09 21:16:22 +08:00
d0efdfc20d
!169 feat: L0支持低功耗投票框架
...
Merge pull request !169 from zhushengle/PM
2021-06-22 11:55:22 +00:00
558ce14bec
feat: L0 支持低功耗框架
...
1.【需求描述】
L0 支持低功耗投票框架, 使内核与应用、驱动分离开，通过注册及投票机制控制系统的低功耗模式,
减低系统功耗,提升设备电池寿命。
2.【方案描述】
(1).提供注册机制，使驱动与内核分离
(2).提供投票机制，判断系统运行模式
(3).记录持锁设备，便于回溯
进入：系统运行进入idle任务时判断当前的功耗模式，如果上层应用未对当前功耗模式(deep和shutdown)
持锁，则系统准备进入当前模式,首先所有设备依次进入当前模式，如果有设备进入当前模式失败，则恢复
已进入当前模式的所有设备，并且功耗模式变为normal模式；设备依次进入当前功耗模式后cpu再进入当前
功耗模式。
恢复：功耗模式为deep时，需要恢复逻辑，时系统恢复运行。当有中断出发时，系统会退出低功耗模式，
恢复顺序为：首先cpu先恢复，然后设备依次恢复。
BREAKING CHANGE:
1.原调度中基于tick timer的低功耗扩展和当前的pm模块合并，删除原对外接口LOS_SchedSleepInit,
变为pm模块统一提供的LOS_PmRegistered接口.
2.原来在arch los_timer.h下提供的低功耗模式为枚举LOS_SysSleepEnum，其中OS_SYS_NORMAL_SLEEP
和OS_SYS_DEEP_SLEEP不符合对外定义，统一修改为LOS_SYS_NORMAL_SLEEP和LOS_SYS_DEEP_SLEEP,
并移至los_pm.h中.
3.VOID HalEnterSleep(LOS_SysSleepEnum sleep) 变更为UINT32 HalEnterSleep(VOID).
Close #I3UDNV
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: Id5382c42c8055ba7850895a3f575130a73e38a65
2021-06-22 13:15:06 +08:00
bcec32e389
fix: 延时队列为NULL时，返回的响应时间为64位最大值，导致无法更新tick timer的响应周期
...
问题描述：
当g_schedResponseTime = OS_SCHED_MAX_RESPONSE_TIME，且nextExpireTime =（UINT64-1时,
表示系统的延时队列已为NULL, 此时tick timer 中应该设置为最大值，但由于判断
g_schedResponseTime - nextExpireTime >= OS_CYCLE_PER_TICK,导致条件不成立，直接返回，
无法将其设置为最大值，导致tick 中断一直频繁响应。
解决方案：
将延时队列为NULL时的返回值以及idle线程的时间片修改为OS_SCHED_MAX_RESPONSE_TIME - OS_CYCLE_PER_TICK,
保证延时队列为NULL，能够正常设置tick响应的最大值。
Close #I3W1LF
Change-Id: I0d09119240ae5a50ddcb0c96fb23cd3d6e70b892
Signed-off-by: zhushengle <zhushengle@huawei.com>
2021-06-17 20:23:13 +08:00
f7d50d0fbf
fix: fix function name
...
correct function name OsSchedSetIdleTaskSchedParam
close https://gitee.com/openharmony/kernel_liteos_m/issues/I3PXEX
2021-05-08 10:12:52 +08:00
cd30e62998
IssueNo:#I3IK07
...
Description:liteos_m scheduling optimization and low power design.
Sig:kernel
Feature or Bugfix:Feature
Binary Source:No
Change-Id: I5b692a503ce6128626eec8f9a37742d7caa1fea9
2021-04-14 09:22:36 +08:00
f685eeb97d
IssueNo:#I3IK07
...
Description:liteos_m scheduling optimization and low power design.
Sig:kernel
Feature or Bugfix:Feature
Binary Source:No
Change-Id: If913b673c9b69039b51ca416be0a77ebccf2773b
2021-04-13 21:48:04 +08:00
zhushengle
openharmony_ci
rtos-lover
zhushengle