From: Michael Jones <michael.jones@matrix-vision.de>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: linux-media@vger.kernel.org
Subject: Re: ISP CCDC freeze-up on STREAMON
Date: Fri, 05 Aug 2011 11:33:20 +0200 [thread overview]
Message-ID: <4E3BB8E0.3000406@matrix-vision.de> (raw)
In-Reply-To: <201107201047.11972.laurent.pinchart@ideasonboard.com>
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
next prev parent reply other threads:[~2011-08-05 9:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-30 8:31 ISP CCDC freeze-up on STREAMON Michael Jones
2011-06-30 8:31 ` prompt " Michael Jones
2011-07-20 8:47 ` Laurent Pinchart
2011-08-05 9:33 ` Michael Jones [this message]
2011-08-06 23:38 ` Sakari Ailus
2011-08-08 9:55 ` Laurent Pinchart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E3BB8E0.3000406@matrix-vision.de \
--to=michael.jones@matrix-vision.de \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox