Message ID | 4CD413E4.20401@matrix-vision.de (mailing list archive) |
---|---|
State | Superseded, archived |
Headers |
Return-path: <mchehab@gaivota> Envelope-to: mchehab@gaivota Delivery-date: Fri, 05 Nov 2010 11:10:20 -0400 Received: from mchehab by gaivota with local (Exim 4.72) (envelope-from <mchehab@gaivota>) id 1PENvo-0001Uy-Oe for mchehab@gaivota; Fri, 05 Nov 2010 11:10:20 -0400 Received: from casper.infradead.org [85.118.1.10] by gaivota with IMAP (fetchmail-6.3.17) for <mchehab@localhost> (single-drop); Fri, 05 Nov 2010 11:10:20 -0400 (EDT) Received: from vger.kernel.org ([209.132.180.67]) by casper.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1PENEj-0000t3-51; Fri, 05 Nov 2010 14:25:49 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752613Ab0KEOZr (ORCPT <rfc822; kmpark@infradead.org> + 1 other); Fri, 5 Nov 2010 10:25:47 -0400 Received: from mail1.matrix-vision.com ([78.47.19.71]:46003 "EHLO mail1.matrix-vision.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752546Ab0KEOZq (ORCPT <rfc822; linux-media@vger.kernel.org>); Fri, 5 Nov 2010 10:25:46 -0400 Received: from mail1.matrix-vision.com (localhost [127.0.0.1]) by mail1.matrix-vision.com (Postfix) with ESMTP id 66C6D7245E; Fri, 5 Nov 2010 15:25:42 +0100 (CET) Received: from erinome (g2.matrix-vision.com [80.152.136.245]) by mail1.matrix-vision.com (Postfix) with ESMTPA id 2991D7230D; Fri, 5 Nov 2010 15:25:42 +0100 (CET) Received: from erinome (localhost [127.0.0.1]) by erinome (Postfix) with ESMTP id 2E6F76F8A; Fri, 5 Nov 2010 15:25:41 +0100 (CET) Received: by erinome (Postfix, from userid 108) id 1FB646F9C; Fri, 5 Nov 2010 15:25:41 +0100 (CET) Received: from [192.168.65.46] (host65-46.intern.matrix-vision.de [192.168.65.46]) by erinome (Postfix) with ESMTPA id 090AE6F8A; Fri, 5 Nov 2010 15:25:41 +0100 (CET) Message-ID: <4CD413E4.20401@matrix-vision.de> Date: Fri, 05 Nov 2010 15:25:40 +0100 From: Michael Jones <michael.jones@matrix-vision.de> User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Bastian Hecht <hechtb@googlemail.com> CC: Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>, Linux Media Mailing List <linux-media@vger.kernel.org> Subject: Re: OMAP3530 ISP irqs disabled References: <AANLkTint8J4NdXQ4v1wmKAKWa7oeSHsdOn8JzjDqCqeY@mail.gmail.com> <4CD161B3.9000709@maxwell.research.nokia.com> <AANLkTikTAo71Kr+Nh8Q8DOMFwWB=gLQSXozgGo8ecYwm@mail.gmail.com> <201011040434.53836.laurent.pinchart@ideasonboard.com> <AANLkTik56opb35vrTnsP=U0F+24uvAWxjtnoGnW18Yta@mail.gmail.com> <AANLkTi=drc6qQeYx_RHOAuQHZ=h6wy6m9fhHsatAjoQU@mail.gmail.com> In-Reply-To: <AANLkTi=drc6qQeYx_RHOAuQHZ=h6wy6m9fhHsatAjoQU@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MV-Disclaimer: true (erinome) X-AV-Checked: ClamAV using ClamSMTP (erinome) X-AV-Checked: ClamAV using ClamSMTP (mail1) Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org Sender: Mauro Carvalho Chehab <mchehab@gaivota> |
Commit Message
Michael Jones
Nov. 5, 2010, 2:25 p.m. UTC
Hi Bastian (Laurent, and Sakari), > > I want to clarify this: > > I try to read images with yafta. > I read in 4 images with 5MP size (no skipping). All 4 images contain only zeros. > I repeat the process some times and keep checking the data. After - > let's say the 6th time - the images contain exactly the data I expect. > WHEN they are read they are good. I just don't want to read 20 black > images before 1 image is transferred right. > > -Bastian > I'm on to your problem, having reproduced it myself. I suspect that you're actually only getting one frame: your very first buffer. You don't touch it, and neither does the CCDC after you requeue it, and after you've cycled through all your other buffers, you get back the non-zero frame. If you clear the "good" frame in your application once, you won't get any more non-zero frames afterwards. Or if you request more buffers, you'll have fewer non-zero frames. That's the behavior I observe. The CCDC is getting disabled by the VD1 interrupt: ispccdc_vd1_isr()->__ispccdc_handle_stopping()->__ispccdc_enable(ccdc, 0) To test this theory I tried disabling the VD1 interrupt, but it didn't solve the problem. In fact, I was still getting VD1 interrupts even though I had disabled them. Has anybody else observed that VD1 cannot be disabled? I also found it strange that the CCDC seemed to continue to generate interrupts when it's disabled. Here's my suggestion for a fix, hopefully Laurent or Sakari can comment on it:
Comments
2010/11/5 Michael Jones <michael.jones@matrix-vision.de>: > Hi Bastian (Laurent, and Sakari), >> >> I want to clarify this: >> >> I try to read images with yafta. >> I read in 4 images with 5MP size (no skipping). All 4 images contain only zeros. >> I repeat the process some times and keep checking the data. After - >> let's say the 6th time - the images contain exactly the data I expect. >> WHEN they are read they are good. I just don't want to read 20 black >> images before 1 image is transferred right. >> >> -Bastian >> > > I'm on to your problem, having reproduced it myself. I suspect that you're actually only getting one frame: your very first buffer. You don't touch it, and neither does the CCDC after you requeue it, and after you've cycled through all your other buffers, you get back the non-zero frame. If you clear the "good" frame in your application once, you won't get any more non-zero frames afterwards. Or if you request more buffers, you'll have fewer non-zero frames. That's the behavior I observe. I can confirm the very first buffer theorem. I indeed get 1 valid frame after each reboot. First I didn'notice it because I used Laurent's yafta .... --skip 3 ... command line. I read 4 frames and only saved the last. Btw, heaven sent you... I keep working on this problem 1 week now and am pretty desperate. I started reading about the linux memory management system to understand all the buffer dma streaming. (well that is probably not the worst thing to sacrifice time...) Tell me if I can do something for you to help. cheers, Bastian > The CCDC is getting disabled by the VD1 interrupt: > ispccdc_vd1_isr()->__ispccdc_handle_stopping()->__ispccdc_enable(ccdc, 0) > > To test this theory I tried disabling the VD1 interrupt, but it didn't solve the problem. In fact, I was still getting VD1 interrupts even though I had disabled them. Has anybody else observed that VD1 cannot be disabled? > > I also found it strange that the CCDC seemed to continue to generate interrupts when it's disabled. > > Here's my suggestion for a fix, hopefully Laurent or Sakari can comment on it: > > --- a/drivers/media/video/isp/ispccdc.c > +++ b/drivers/media/video/isp/ispccdc.c > @@ -1477,7 +1477,7 @@ static void ispccdc_vd1_isr(struct isp_ccdc_device *ccdc) > spin_lock_irqsave(&ccdc->lsc.req_lock, flags); > > /* We are about to stop CCDC and/without LSC */ > - if ((ccdc->output & CCDC_OUTPUT_MEMORY) || > + if ((ccdc->output & CCDC_OUTPUT_MEMORY) && > (ccdc->state == ISP_PIPELINE_STREAM_SINGLESHOT)) > ccdc->stopping = CCDC_STOP_REQUEST; > > > -- > Michael Jones > > MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler > Registergericht: Amtsgericht Stuttgart, HRB 271090 > Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- a/drivers/media/video/isp/ispccdc.c +++ b/drivers/media/video/isp/ispccdc.c @@ -1477,7 +1477,7 @@ static void ispccdc_vd1_isr(struct isp_ccdc_device *ccdc) spin_lock_irqsave(&ccdc->lsc.req_lock, flags); /* We are about to stop CCDC and/without LSC */ - if ((ccdc->output & CCDC_OUTPUT_MEMORY) || + if ((ccdc->output & CCDC_OUTPUT_MEMORY) && (ccdc->state == ISP_PIPELINE_STREAM_SINGLESHOT)) ccdc->stopping = CCDC_STOP_REQUEST;