Re: Lockup on second streamon with omap3-isp

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Julien,

On Friday 14 December 2012 15:18:29 Julien BERAUD wrote:
> 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.

Do you get CCDC stop timeouts ? They are reported in the kernel log as "CCDC 
stop timeout!".

> 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

Now this really doesn't make much sense to me. Both sequences should produce 
the exact same hardware accesses.

Could you add a printk in isp_reg_writel 
(drivers/media/platform/omap3isp/isp.h) and compare the register writes for 
both sequences ?

> > 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,

Laurent Pinchart