Hi Jean-Philippe, On Monday 17 December 2012 16:41:29 jean-philippe francois wrote: > 2012/12/17 Laurent Pinchart: > > 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!". Does Julien's patch fix your issue ? > >> 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 ? > > And you are right, it was pure coincidence, the issue is still there. Thought so :-) > Sorry for the inaccurate report. No worries. > >> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
