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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
