ISP中断类型
SOF: 一帧图像数据开始传输
EOF: 一帧图像数据传输完成
REG_UPDATE: ISP寄存器更新完成(每个reg group都有独立的这个中断)
EPOCH: ISP某一行结尾(默认20)就会产生此中断
BUFFER DONE: 一帧图像数据ISP完全写到DDR了
管理Isp request的几个List
struct cam_isp_context {
struct list_head active_req_list;//reg_upd中断将isp request保存到这里并等待buffer done中断
struct list_head pending_req_list;//umd submit的isp request保存到这里等待sof(epoch)时crm apply其到HW
struct list_head wait_req_list;//apply之后保存isp request到这个链表并且等待reg_upd中断
struct list_head free_req_list;//保存所有可用的isp request对象
}
Isp request在kernel里的生命周期图
Bubble Recovery
Isp bubble state request生命周期解析图
Isp bubble 恢复机制
cam_req_mgr_process_error(void *priv, void *data)
{
switch (err_info->error) {
case CRM_KMD_ERR_BUBBLE:
idx = __cam_req_mgr_find_slot_for_req(in_q, err_info->req_id);//在in_q中找到bubble request对应下标
__cam_req_mgr_tbl_set_all_skip_cnt(&link->req.l_tbl);//让bubble这次遍历skip掉pd 1的request
in_q->rd_idx = idx;//重置rd_idx为bubble request对应的下标
slot_diff = in_q->last_applied_idx - idx;//计算出最新applied request到 发生bubble request的下标偏差
//把出现bubble request开始到last appiled之间的request都标为CRM_SLOT_STATUS_REQ_ADDED，
//这些request都需要在SOF/EOF来时重新配置到realtime HW
for (i = 0; i < slot_diff; i++) {
__cam_req_mgr_inc_idx(&idx, 1, link->req.l_tbl->num_slots);
if (in_q->slot[idx].status == CRM_SLOT_STATUS_REQ_APPLIED)
in_q->slot[idx].status = CRM_SLOT_STATUS_REQ_ADDED;
}
__cam_req_mgr_apply_on_bubble(link, err_info);//立刻重新配置pd 2的设备的request到hw
}
}
正常流程：sof - applywithcf - Applied状态 - reg upd中断 - epoch状态 - bufdone中断
ISP bubble ：Applied之后应该是reg upd 的中断，这时来了epoch中断，说明这张图无效，此时进入buffle状态，isp通知crm error
如果req5发生bubble，rd_idx会被移动到req5的位置，前面配置到ISP的5的buffer done不会返回到umd。等reapply到5的request，完成buffer done并且状态从bubble恢复之后才返回UMD。
req5在下一个SOF重新配置给ISP HW，如果这是bubbled req5 buf done还没到，就等下个sof再检查bubbled req5 buf done是否到达，到达就reapply req5到isp hw
