yinjiaming
194ac5898d
fix: 当前仓代码编译告警的问题
...
【背景】
当前仓代码存在编译告警需要处理
【修改方案】
在测试用例中屏蔽了-Werror选项
在对应的代码处添加了相应函数的声明头文件
【影响】
对现有的产品编译不会有影响。
re #I4N50W
Signed-off-by: yinjiaming <yinjiaming@huawei.com>
Change-Id: I7dc1e38105aa3d60f9f991f34f88875cccb48463
2022-01-19 02:27:14 +00:00
zhushengle
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
zhushengle
91903a3716
fix: 修正部分编码风格问题
...
Close #I4K8M7
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: If34d5c632cbb06f639434d8c35fb226a0253f4a7
Signed-off-by: zhushengle <zhushengle@huawei.com>
2021-11-29 14:22:39 +08:00
zhushengle
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
zhushengle
3907238b0f
fix:Fixed kernel error with header protector and header comment description.
...
Close #I3O4SF
Change-Id: I544cde728fb8131d199a21be440ae02da2fe21fb
2021-04-26 21:13:55 +08:00
zhushengle
bad8c3d53b
IssueNo:#I3IK07
...
Description:LOS_SysCycleGet replace HalCpuCycleGet
Sig:kernel
Feature or Bugfix:Feature
Binary Source:No
Change-Id: Ife3a4d351818f718f58d3624b5ee6dd127113378
2021-04-17 16:07:51 +08:00
zhushengle
57f6e1f181
IssueNo:I3IK07
...
Description:liteos_m scheduling optimization and low power design.
Sig:kernel
Feature or Bugfix:Feature
Binary Source:No
Change-Id: I6ccbe267ec20f93f97032c5b006c3214eb099daa
2021-04-16 18:54:47 +08:00
zhushengle
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
mamingshuai
778c8b9930
update openharmony 1.0.1
2021-03-11 20:30:40 +08:00
Caoruihong
1405111aa9
Description: refactor
...
Reviewed-by: likailong
2020-12-16 17:30:08 +08:00
likailong
72c4acf01e
Description: liteos-m refactoring
...
Reviewed-by: wangmihu, zhushengle
2020-12-02 19:40:34 +08:00
wenjun
dc16ffa8cb
add OpenHarmony 1.0 baseline
2020-09-08 16:46:24 +08:00