ENGR00232530 Refine VPU suspend/resume according to open_count
1. Refine VPU suspend/resume according to open_count to completely
fix bug: ENGR00230203 [Android_MX6DL_SD] Gallery: System hang
after resume from suspend during video playback. 20%
open_count == 0 case can be simplified because VPU is released
(all instances are freed), so
- clock is already off
- context is no longer needed
- power is already off on MX6
VPU reset is removed from resume because power is ensured to be off
before entering resume on MX6 by calling regulator API.
2. Fix bug: VPU always busy after suspend/resume
Error log (VPU refused to suspend due to VPU busy):
pm_op(): platform_pm_suspend+0x0/0x54 returns -11
PM: Device mxc_vpu failed to suspend: error -11
PM: Some devices failed to suspend
Root cause:
- Suspend happened during vpu_Init(), somewhere after VPU lib started
to download FW (when PC == 0), but before run FW. (BIT_BUSY_FLAG=1,
BIT_CODE_RUN=1).
- In such case, VPU resume downloaded FW and run VPU to idle because
suspend was triggered after VPU was opened (active).
- vpu_Init run VPU again with BIT_BUSY_FLAG=1. So VPU was trapped in
idle loop but BIT_BUSY_FLAG was never cleared. VPU lib regarded VPU
as always busy.
Solution (in VPU resume):
- run VPU FW only if VPU was opened and PC before suspend is not 0
- restore host register is required
- download FW is required, because program memory is lost after power
off.
Signed-off-by: Hongzhang Yang <Hongzhang.Yang@freescale.com>