Re: omap3isp: known causes of "CCDC won't become idle!

[Jonathan Cameron <jic23@cam.ac.uk>]

On 07/05/11 16:02, Laurent Pinchart wrote:
> On Tuesday 05 July 2011 16:38:07 Sakari Ailus wrote:
>> On Tue, Jul 05, 2011 at 02:48:57PM +0100, Jonathan Cameron wrote:
>>> On 07/05/11 13:19, Sakari Ailus wrote:
>>>> On Tue, Jul 05, 2011 at 12:22:06PM +0100, Jonathan Cameron wrote:
>>>>> Hi Laurent,
>>>>>
>>>>> I'm just trying to get an mt9v034 sensor working on a beagle xm.
>>>>> Everything more or less works, except that after a random number
>>>>> of frames of capture, I tend to get won't become idle messages
>>>>> and the vd0 and vd1 interrupts tend to turn up at same time.
>>>>>
>>>>> I was just wondering if there are any known issues with the ccdc
>>>>> driver / silicon that might explain this?
>>>>>
>>>>> I also note that it appears to be impossible to disable
>>>>> HS_VS_IRQarch/arm/mach-s3c2410/Kconfig:# cpu frequency scaling
>>>>> support
>>>>>
>>>>> despite the datasheet claiming this can be done.  Is this a known
>>>>> issue?
>>>>
>>>> The same interrupt may be used to produce an interrupt per horizontal
>>>> sync but the driver doesn't use that. I remember of a case where the
>>>> two sync signals had enough crosstalk to cause vertical sync interrupt
>>>> per every horizontal sync. (It's been discussed on this list.) This
>>>> might not be the case here, though: you should be flooded with HS_VS
>>>> interrupts.
>>>
>>> As far as I can tell, the driver doesn't use either interrupt (except to
>>> pass it up as an event). Hence I was trying to mask it purely to cut
>>> down on the interrupt load.
>>
>> It does. This is the only way to detect the CCDC has finished processing a
>> frame.
> 
> We actually use the VD0 and VD1 interrupts for that, not the HS_VS interrupt.
> 
>>>> The VD* counters are counting and interrupts are produced (AFAIR) even
>>>> if the CCDC is disabled.
>>>
>>> Oh goody...
>>>
>>>> Once the CCDC starts receiving a frame, it becomes busy, and becomes
>>>> idle only when it has received the full frame. For this reason it's
>>>> important that the full frame is actually received by the CCDC,
>>>> otherwise this is due to happen when the CCDC is being stopped at the
>>>> end of the stream.
>>>
>>> Fair enough.  Is there any software reason why it might think it hasn't
>>> received the whole frame?  Obviously it could in theory be a hardware
>>> issue, but it's a bit odd that it can reliably do a certain number of
>>> frames before falling over.
>>
>> Others than those which Laurent already pointed out, one which crosses my
>> mind is the vsync polarity. The Documentation/video4linux/omap3isp.txt does
>> mention it. It _may_ have the effect that one line of input is missed by
>> the VD* counters. Thus the VD* counters might never reach the expected
>> value --- the last line of the frame.
> 
> I would first try to increase vertical blanking to see if it helps.
Have done. No luck as yet.  This sensor mt9v034 annoyingly starts live.
Right now this means I get two frames with very short vblank (10% ratio, at 60fps,
so sub 2 microseonds.)  Whilst the failure seems to be at a later time, I'd
obviously like to get rid of these.