ISP CCDC freeze-up on STREAMON

ISP CCDC freeze-up on STREAMON

[Michael Jones]

Hi Laurent,

I'm observing a system freeze-up with the ISP when writing data to memory directly from the ccdc.

Here's the sequence I'm using:

0. apply the patch I'm sending separate in this thread.

1. configure the ISP pipeline for the CCDC to deliver V4L2_PIX_FMT_GREY directly from the sensor to memory.

2. yavta -c10 /dev/video2

The patch is pretty self-explanatory.  It introduces a loop (with ugly indenting to keep the patch simple) with 100 iterations leaving the device open between them. My system usually hangs up within the first 30 iterations.  I've never made it to 100 successfully.  I see the same behavior with user pointers and with mmap, but I don't see it when using data from the previewer.

Can you please try this out with your setup?  Even if you can't get 8-bit gray data from your sensor, hopefully you could observe it with any other format directly from the CCDC.

I'll postpone further discussion until you confirm that you can reproduce the behavior.  As the patch illustrates, it looks like it is hanging up in STREAMON.

-Michael

Michael Jones (1):
  prompt ISP CCDC freeze-up on STREAMON

 yavta.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

-- 
1.7.5.4


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

prompt ISP CCDC freeze-up on STREAMON

[Michael Jones]

---
 yavta.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/yavta.c b/yavta.c
index 2a166c6..95976b4 100644
--- a/yavta.c
+++ b/yavta.c
@@ -485,7 +485,9 @@ static int video_enable(struct device *dev, int enable)
 	int type = dev->type;
 	int ret;
 
+	printf("+%s\n", enable ? "STREAMON" : "STREAMOFF");
 	ret = ioctl(dev->fd, enable ? VIDIOC_STREAMON : VIDIOC_STREAMOFF, &type);
+	printf("-%s\n", enable ? "STREAMON" : "STREAMOFF");
 	if (ret < 0) {
 		printf("Unable to %s streaming: %d.\n", enable ? "start" : "stop",
 			errno);
@@ -1063,6 +1065,7 @@ int main(int argc, char *argv[])
 {
 	struct device dev;
 	int ret;
+	int i;
 
 	/* Options parsings */
 	int do_file = 0, do_capture = 0, do_pause = 0;
@@ -1259,6 +1262,9 @@ int main(int argc, char *argv[])
 		video_enum_inputs(&dev);
 	}
 
+	for (i=0; i<100; i++) {
+		printf("==== %d ====\n", i);
+
 	if (do_set_input) {
 		video_set_input(&dev, input);
 		ret = video_get_input(&dev);
@@ -1313,6 +1319,8 @@ int main(int argc, char *argv[])
 		return 1;
 	}
 
+	}
+
 	video_close(&dev);
 	return 0;
 }
-- 
1.7.5.4


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Re: ISP CCDC freeze-up on STREAMON

[Laurent Pinchart]

Hi Michael,

Sorry for the late reply.

On Thursday 30 June 2011 10:31:52 Michael Jones wrote:
> Hi Laurent,
> 
> I'm observing a system freeze-up with the ISP when writing data to memory
> directly from the ccdc.
> 
> Here's the sequence I'm using:
> 
> 0. apply the patch I'm sending separate in this thread.
> 
> 1. configure the ISP pipeline for the CCDC to deliver V4L2_PIX_FMT_GREY
> directly from the sensor to memory.
> 
> 2. yavta -c10 /dev/video2
> 
> The patch is pretty self-explanatory.  It introduces a loop (with ugly
> indenting to keep the patch simple) with 100 iterations leaving the device
> open between them. My system usually hangs up within the first 30
> iterations.  I've never made it to 100 successfully.  I see the same
> behavior with user pointers and with mmap, but I don't see it when using
> data from the previewer.
> 
> Can you please try this out with your setup?  Even if you can't get 8-bit
> gray data from your sensor, hopefully you could observe it with any other
> format directly from the CCDC.
> 
> I'll postpone further discussion until you confirm that you can reproduce
> the behavior.  As the patch illustrates, it looks like it is hanging up in
> STREAMON.

I've tested this with a serial CSI-2 sensor and a parallel sensor (MT9V032, in 
both 8-bit and 10-bit modes, albeit with SGRBG8 instead of GREY for the 8-bit 
mode), and I can't reproduce the issue.

I thought I've asked you already but can't find this in my mailbox, so I 
apologize if I have, but could you try increasing vertical blanking and see if 
it helps ?

-- 
Regards,

Laurent Pinchart

Re: ISP CCDC freeze-up on STREAMON

[Michael Jones]

Hi Laurent,

On 07/20/2011 10:47 AM, Laurent Pinchart wrote:
> 
> Hi Michael,
> 
> Sorry for the late reply.

Likewise :)

> 
> On Thursday 30 June 2011 10:31:52 Michael Jones wrote:
>> Hi Laurent,
>>
>> I'm observing a system freeze-up with the ISP when writing data to memory
>> directly from the ccdc.
>>
>> Here's the sequence I'm using:
>>
>> 0. apply the patch I'm sending separate in this thread.
>>
>> 1. configure the ISP pipeline for the CCDC to deliver V4L2_PIX_FMT_GREY
>> directly from the sensor to memory.
>>
>> 2. yavta -c10 /dev/video2
>>
>> The patch is pretty self-explanatory.  It introduces a loop (with ugly
>> indenting to keep the patch simple) with 100 iterations leaving the device
>> open between them. My system usually hangs up within the first 30
>> iterations.  I've never made it to 100 successfully.  I see the same
>> behavior with user pointers and with mmap, but I don't see it when using
>> data from the previewer.
>>
>> Can you please try this out with your setup?  Even if you can't get 8-bit
>> gray data from your sensor, hopefully you could observe it with any other
>> format directly from the CCDC.
>>
>> I'll postpone further discussion until you confirm that you can reproduce
>> the behavior.  As the patch illustrates, it looks like it is hanging up in
>> STREAMON.
> 
> I've tested this with a serial CSI-2 sensor and a parallel sensor (MT9V032, in 
> both 8-bit and 10-bit modes, albeit with SGRBG8 instead of GREY for the 8-bit 
> mode), and I can't reproduce the issue.
> 
> I thought I've asked you already but can't find this in my mailbox, so I 
> apologize if I have, but could you try increasing vertical blanking and see if 
> it helps ?
> 

I think that was the first time you suggested that. Indeed, if I stretch
out the time between frames, the problem goes away. I haven't tested it
precisely to see how long it needs to be to work correctly. But what
does this tell me? This isn't a very appealing fix as 1) I would have to
fish around for a minimum vertical blank time that works and 2) this
would slow down the frame rate for the normal case, when frames are just
being streamed uninterrupted.

-Michael

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier

Re: ISP CCDC freeze-up on STREAMON

[Sakari Ailus]

Hi Michael,

On Fri, Aug 05, 2011 at 11:33:20AM +0200, Michael Jones wrote:
> Hi Laurent,
> 
> On 07/20/2011 10:47 AM, Laurent Pinchart wrote:
...
> > I've tested this with a serial CSI-2 sensor and a parallel sensor (MT9V032, in 
> > both 8-bit and 10-bit modes, albeit with SGRBG8 instead of GREY for the 8-bit 
> > mode), and I can't reproduce the issue.
> > 
> > I thought I've asked you already but can't find this in my mailbox, so I 
> > apologize if I have, but could you try increasing vertical blanking and see if 
> > it helps ?
> > 
> 
> I think that was the first time you suggested that. Indeed, if I stretch
> out the time between frames, the problem goes away. I haven't tested it
> precisely to see how long it needs to be to work correctly. But what
> does this tell me? This isn't a very appealing fix as 1) I would have to

What works and what does not (in ISO units preferrably)?

Sometimes (at least) sensor minimum vertival blanking is enough.

-- 
Sakari Ailus
sakari.ailus@iki.fi

Re: ISP CCDC freeze-up on STREAMON

[Laurent Pinchart]

Hi Michael,

On Friday 05 August 2011 11:33:20 Michael Jones wrote:
> On 07/20/2011 10:47 AM, Laurent Pinchart wrote:
> > On Thursday 30 June 2011 10:31:52 Michael Jones wrote:
> >> Hi Laurent,
> >> 
> >> I'm observing a system freeze-up with the ISP when writing data to
> >> memory directly from the ccdc.
> >> 
> >> Here's the sequence I'm using:
> >> 
> >> 0. apply the patch I'm sending separate in this thread.
> >> 
> >> 1. configure the ISP pipeline for the CCDC to deliver V4L2_PIX_FMT_GREY
> >> directly from the sensor to memory.
> >> 
> >> 2. yavta -c10 /dev/video2
> >> 
> >> The patch is pretty self-explanatory.  It introduces a loop (with ugly
> >> indenting to keep the patch simple) with 100 iterations leaving the
> >> device open between them. My system usually hangs up within the first
> >> 30 iterations.  I've never made it to 100 successfully.  I see the same
> >> behavior with user pointers and with mmap, but I don't see it when
> >> using data from the previewer.
> >> 
> >> Can you please try this out with your setup?  Even if you can't get
> >> 8-bit gray data from your sensor, hopefully you could observe it with
> >> any other format directly from the CCDC.
> >> 
> >> I'll postpone further discussion until you confirm that you can
> >> reproduce the behavior.  As the patch illustrates, it looks like it is
> >> hanging up in STREAMON.
> > 
> > I've tested this with a serial CSI-2 sensor and a parallel sensor
> > (MT9V032, in both 8-bit and 10-bit modes, albeit with SGRBG8 instead of
> > GREY for the 8-bit mode), and I can't reproduce the issue.
> > 
> > I thought I've asked you already but can't find this in my mailbox, so I
> > apologize if I have, but could you try increasing vertical blanking and
> > see if it helps ?
> 
> I think that was the first time you suggested that. Indeed, if I stretch
> out the time between frames, the problem goes away. I haven't tested it
> precisely to see how long it needs to be to work correctly. But what
> does this tell me? This isn't a very appealing fix as 1) I would have to
> fish around for a minimum vertical blank time that works and 2) this
> would slow down the frame rate for the normal case, when frames are just
> being streamed uninterrupted.

Please complain to TI for their flaky hardware design. The OMAP3 ISP driver 
needs to perform operations in interrupt context between the end of a frame 
and the beginning of a new one. If the vertical blanking time is too short the 
ISP will fail. The minimum vertical blanking time depends on the system 
responsiveness to interrupts, so there's no easy way to give you a minimum 
value that will work in all cases.

-- 
Regards,

Laurent Pinchart