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>
4a79a917f3