Issue Observations:

On random frequent sleep-wakeup cycles, DSS ISR for VP_SYNC_LOST fires every 3-5µs and the system in unrecoverable after this flood occurs. This issue was also observed occasionally on long running instances. In some of these instances, it was seen that the `headNode` in the Dss_evtMgrMasterIsr() was NULL, thereby skipping the interrupt clearing mechanism within the ISR.

It was also noted that in the following DispApp_configDctrl() IOCTL initialization:

    retVal = Fvid2_control(
        appObj->dctrlHandle,
        IOCTL_DSS_DCTRL_SET_VP_PARAMS,
        vpParams,
        NULL);
    if(retVal != FVID2_SOK)
    {
        DebugP_log("Dctrl Set VP Params IOCTL Failed!!!\r\n");
    }    if (appObj->oldiParams != NULL)
    {
        retVal = Fvid2_control(
            appObj->dctrlHandle,
            IOCTL_DSS_DCTRL_SET_OLDI_PARAMS,
            oldiParams,
            NULL);
        if(retVal != FVID2_SOK)
        {
            DebugP_log("DCTRL Set OLDI Params IOCTL Failed!!!\r\n");
        }
    } 

if any preemption occurs before or after both of the VP and OLDI IOCTLs, there was no issue, but soon as there is a preemption after VP IOCTL but before OLDI IOCTL, there is an IRQ flood.

Root Cause Analysis:

When the VP is enabled with IOCTL, but then a preemption causes a delayed OLDI sw reset via IOCTL, the OLDI is still in reset asserted mode while VP tries to stream frames causing VP sync lost.
In cases when ISR is able to clear the interrupt, hardware will again set the interrupt status thereby re-entering the ISR even before the OLDI IOCTL can be called.

Resolution:

Swapping the IOCTL call order, i.e. Calling OLDI IOCTL first and then calling the VP IOCTL ensures that the OLDI is ready before the VP is enabled. So even if a preemption occurs in the middle, the VP is still disables, and VP_SYNC_LOST IRQ will not trigger. This solves the issue for the customer.