194ac5898d
fix: 当前仓代码编译告警的问题
...
【背景】
当前仓代码存在编译告警需要处理
【修改方案】
在测试用例中屏蔽了-Werror选项
在对应的代码处添加了相应函数的声明头文件
【影响】
对现有的产品编译不会有影响。
re #I4N50W
Signed-off-by: yinjiaming <yinjiaming@huawei.com>
Change-Id: I7dc1e38105aa3d60f9f991f34f88875cccb48463
2022-01-19 02:27:14 +00:00
f635450d7c
feat: 内核提供tick timer框架，支持多架构多平台通用化
...
背景：
当前Arch下tick timer的实现依赖于弱函数机制，三方适配时出错及限制较大，且tick
timer作为内核必须模块，未模块化，当前散落在tick和调度等模块中，且当前存在arch依赖
内核，内核也依赖arch的情况，为了解决上述问题，将tick timer模块化，通过提供tick
timer框架实现内核依赖Arch而Arch不依赖内核，并且可以减少对外暴漏的接口，使得三方
适配时更加明确需要实现的接口。
方案描述：
1.tick timer结构
在kernel_liteos_m/arch/include/los_timer.h，中定义结构：
typedef struct {
UINT32 freq;
INT32 irqNum;
UINT32 (*init)(HWI_PROC_FUNC tickHandler);
UINT64 (*getCycle)(UINT32 *period);
VOID (*reload)(UINT64 time);
VOID (*lock)(VOID);
VOID (*unlock)(VOID);
HWI_PROC_FUNC tickHandler;
} ArchTickTimer;
并声明对外获取tick timer的接口：
ArchTickTimer *ArchSysTickTimerGet(VOID)
define LOS_SysTickTimerGet ArchSysTickTimerGet
2.在每个架构下提供默认的tick timer操作：
STATIC ArchTickTimer g_archTickTimer = {
.freq = xxx, 必填
.irqNum = xxx, 必填
.init = xxx, 必填
.getCycle = xxx, 必填
.reload = xxx, 必填
.lock = xxx, 必填
.unlock = xxx, 必填
.tickHandler = NULL, 可选
}
并实现：ArchTickTimer *ArchSysTickTimerGet(VOID) 接口
3.内核los_tick.c中提供对外(其它模块)和公共的tick timer初始化操作函数，
如果用户不想启用系统默认的tick timer,则需要在 "内核初始化之前" 调用接口：
LOS_TickTimerRegister(const ArchTickTimer *timer, const HWI_PROC_FUNC tickHandler)
将用户自己的tick timer或中断处理函数 注册进去。
用户也可以注册自己的中断处理函数(用户不提供，默认使用系统提供的)。
BREAKING CHANGE:
原来版本中每个架构下提供的tick timer相关操作函数为弱函数：
WEAK UINT32 HalTickStart(OS_TICK_HANDLER handler);
WEAK VOID HalSysTickReload(UINT64 nextResponseTime);
WEAK UINT64 HalGetTickCycle(UINT32 *period);
WEAK VOID HalTickLock(VOID);
WEAK VOID HalTickUnlock(VOID);
用户如果需要启用自己的tick timer需要自己实现相关接口(强属性)，在 "内核初始化之前" 通过调用：
LOS_TickTimerRegister 接口替换系统默认提供的tick timer相关接口。
无论用户提供的tick timer 还是系统默认提供的，均在内核初始化时启动。
Close #I4N7XV:arch 重构
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: I83ad0bdf303904f0e73f808b57b60183619fddcd
2021-12-31 10:50:33 +08:00
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
yinjiaming
zhushengle
openharmony_ci
rtos-lover
zhushengle