Re: Lockup on second streamon with omap3-isp

[Julien BERAUD <julien.beraud@parrot.com>]

Hi Jean-Philippe,

I have had exactly the same problem and the following workaround has 
caused no regression on our board yet.
I can't explain exactly why it works and I think that it is internal to 
the isp.

In function ccdc_set_stream, don't disable the ccdc_subclk when stopping 
capture:

                 ret = ccdc_disable(ccdc);
                 if (ccdc->output & CCDC_OUTPUT_MEMORY)
                         omap3isp_sbl_disable(isp, 
OMAP3_ISP_SBL_CCDC_WRITE);
-               omap3isp_subclk_disable(isp, OMAP3_ISP_SUBCLK_CCDC);
+               //omap3isp_subclk_disable(isp, OMAP3_ISP_SUBCLK_CCDC);

I know that it is still a workaround but I hope that maybe it will help 
someone to understand the real cause of this issue.

Best Regards,
Julien BERAUD

Le 13/12/2012 15:14, jean-philippe francois a écrit :
> Hi,
>
> I have news on the "IRQ storm on second streamon" problem.
> Reminder :
> Given a perfectly fine HSYNC / VSYNC / PIXELCLOK configuration, the
> omap3-isp (at least until 3.4) will go into an interrupt storm when
> streamon is called for the second time, unless you are able to stop
> the sensor when not streaming. I have reproduced this on three
> different board, with three different sensor.
>
> On board 1, the problem disappeared by itself (in fact not by itself,
> see below) and the board is not in my possession anymore.
> On board 2, I implemented a working s_stream operation in the subdev
> driver, so the problem was solved because the sensor would effectively
> stop streaming when told to, keeping the ISP + CCDC happy
> On board 3, I can't stop the streaming, or I did not figure out how to
> make it stop  yet.
>
> I tried to disable the HS_VS_IRQ, but it did not help, so I came back
> looking at the code of board 1, which was running fine with a 3.4
> kernel. And I discovered the problem doesn't happen if I break the
> pipeline between two consecutive streamon.
>
> In other word if I do the following :
>
> media-ctl -l '16:0->5:0[1], 5:1->6:0[1]'
> media-ctl -f '16:0 [SBGGR8 2560x800 (0, 0)/2560x800]'
> yavta ....
> yavta ...       <--------- board locks up, soft lockup is fired
>
> But if I do this instead :
>
> media-ctl -l '16:0->5:0[0], 5:1->6:0[0]'
> media-ctl -l '16:0->5:0[1], 5:1->6:0[1]'
> media-ctl -f '16:0 [SBGGR8 2560x800 (0, 0)/2560x800]'
> yavta ....
> media-ctl -l '16:0->5:0[0], 5:1->6:0[0]'
> media-ctl -l '16:0->5:0[1], 5:1->6:0[1]'
> media-ctl -f '16:0 [SBGGR8 2560x800 (0, 0)/2560x800]'
> yavta ...       <--------- image are acquired, board doesn't lock up anymore
>
> It would be interesting to go from this workaround to the elimination of
> the root cause. What can I do / test next to stop this bug from hapenning ?
>
> Regards,
> Jean-Philippe François
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html