Hi Julien, Going through my old BT.656-related e-mails, I think this is my most late reply so far. Let's hope I won't break the record in the future. Now that BT.656 support for the OMAP3 ISP is finally going to mainline, I was wondering if you still had access to the platform mentioned below, and if you could test whether the problem still occurs. The OMAP3 ISP code is available at git://linuxtv.org/pinchartl/media.git omap3isp/next tvp5151 test patches can be found in the omap3isp/bt656 branch of the same repository. On Wednesday 07 November 2012 11:37:36 Julien BERAUD wrote: > Hello, > > I have been working on a platform based on an omap3630 with a tvp5151 in > bt656 mode and I have iommu translation faults when starting and > stopping capture in a loop a certain number of times. > I think I have identified the problem and though my working branch is > not exactly the same as yours, I think that you have the same issue. > > When stopping ccdc capture(ccdc_set_stream), function ccdc_disable is > called which clears the bit ISPCCDC_PCR_EN (__ccdc_disable) and waits > for the current frame to finish. > In progressive mode, the next vd0_isr will call ccdc_isr_buffer which > will wait for the ccdc pcr busy flag to go off and then call function > __ccdc_handle_stopping which will set the flags that will allow the > stopping process to go on. > > The problem seems to be that in interlaced mode, if the next vd0_isr is > received for the first half of the frame(odd field), the ccdc_isr_buffer > routine is not called, __ccdc_handle_stopping is called and sets the > flags that will allow the stopping process to go on without waiting for > the frame to finish like it should be the case, or like it is the case > if the next vd0_isr is received for the second part of the frame(even > field). > > Calling ccdc_isr_buffer in case ccdc->stopping & CCDC_STOP_REQUEST != 0 > makes that the flags are set only after the busy signal goes off and it > fixes the issue I have. > > By the way, I haven't seen anything in the omap3630 trm that tells me > that in case we are in progressive mode, the busy flag goes off after > the current field(half frame) is finished instead of the whole frame but > I noticed this is the case. > > If there is something I missed, or if the behaviour of the ccdc isn't > supposed to be like that, could you explain what I got wrong? -- 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
