4a79a917f3
The change handles tasklet scheduling delays in buf done handling. If there is a scenario where in we have a request N in active list, and N+1 is applied on the output frame for N. It's possible that after applying N+1, the buf done tasklet for N is not scheduled in time, and if it so happens that the tasklet is scheduled out beyond the next frame, HW would have consumed N+1, and we end up reading the last consumed addr for N+1 in the buf done bh for N. The read last consumed address from N+1, will never match with N ultimately stalling N. We could read the last consumed addr registers in top half, but that would lead to increased register reads in ISR, delaying top half processing therefore the change handle such delays within the ISP state machine. The underlying understanding here is if HW has generated buf done for client X on request N+1, it's bound to have processed the buffer for client X on request N. CRs-Fixed: 3223063 Change-Id: I1e96f5b51b6fc388f3c189f882f8ae543a6ccb06 Signed-off-by: Karthik Anantha Ram <quic_kartanan@quicinc.com>