atomisp: add spinlock to solve race condition
BZ: 34525
issue: kernel panicking and system hang when doing MTBF
root cause:
In failed case, atomisp_isr() is running on CPU0,
atomisp_acc_load() is on another CPU1 (hyper-thread / dual-core).
Atomisp_acc_load() sets my_css.invalidate between
sh_css_preview_next_stage_needs_alloc(), and atomisp_start_binary().
It causes kernel panicing when CSS API sh_css_preview_start()
tries to free memory. Because the memory (de)allocation
might trigger a sleep operation and it's in the ISR of ISP.
solution:
added a spinlock to protect the CSS flag my_css.invalidate in
sh_css_load_acceleration(), meanwhile the memory allocation for
header->sp_arg in sh_css_load_acc() should be moved out of the
path spinlock protection. Moved it into the function
sh_css_acc_set_argument() which is the first place to use
the variable header->sp_arg.
For digital zoom/xnr, also add spinlock/mutex to protect
the CSS flag my_css.invalidate.
Change-Id: Icec8b3d2e1b513290fcbabcd19210710a962ecb8
Signed-off-by: Jianxu Zheng <jian.xu.zheng@intel.com>
Reviewed-on: http://android.intel.com:8080/53298
Reviewed-by: Augusteijn, Lex <lex.augusteijn@intel.com>
Reviewed-by: Govindapillai, Vinod <vinod.govindapillai@intel.com>
Reviewed-by: Kruger, Jozef <jozef.kruger@intel.com>
Reviewed-by: Tuominen, TeemuX <teemux.tuominen@intel.com>
Reviewed-by: Toivonen, Tuukka <tuukka.toivonen@intel.com>
Reviewed-by: Laakso, Antti <antti.laakso@intel.com>
Reviewed-by: Koski, Anttu <anttu.koski@intel.com>
Tested-by: Koski, Anttu <anttu.koski@intel.com>
Reviewed-by: buildbot <buildbot@intel.com>
Tested-by: buildbot <buildbot@intel.com>