| Message ID | CAAwP0s3NFvvUYd-0kwKLKXfYB4Zx1nXb0nd9+JM61JWtrVFfRg@mail.gmail.com (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers |
Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from <linux-media-owner@vger.kernel.org>) id 1RD2MO-0003sM-BP; Mon, 10 Oct 2011 01:01:09 +0200 X-tubIT-Incoming-IP: 209.132.180.67 Received: from vger.kernel.org ([209.132.180.67]) by mail.tu-berlin.de (exim-4.75/mailfrontend-1) with esmtp id 1RD2MN-0006O0-Ke; Mon, 10 Oct 2011 01:00:43 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751394Ab1JIXAl (ORCPT <rfc822;patchwork@linuxtv.org> + 3 others); Sun, 9 Oct 2011 19:00:41 -0400 Received: from mail-gy0-f174.google.com ([209.85.160.174]:61095 "EHLO mail-gy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750851Ab1JIXAk convert rfc822-to-8bit (ORCPT <rfc822; linux-media@vger.kernel.org>); Sun, 9 Oct 2011 19:00:40 -0400 Received: by gyg10 with SMTP id 10so4861383gyg.19 for <linux-media@vger.kernel.org>; Sun, 09 Oct 2011 16:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=lf7m4nR4H36HbM1/T9IekzEl1gixvJfnYHmZSpGV00w=; b=txkV1kqgC1VZUbV40xiPfuMqzG7OsY2KAVfiPzXlV7gdSmj2pdFtNt8AprWO+XnxaL x6g23XuZvyJvnErvtW7341oCNs0LahrbDhEf7EBrBbTILyb2PyBYlIeCYj0Ak0QYeUco Twb7/fniwp0b8I2If1L6K9k+qNbVMQt/3O/v0= Received: by 10.236.76.136 with SMTP id b8mr21213948yhe.9.1318201240060; Sun, 09 Oct 2011 16:00:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.111.7 with HTTP; Sun, 9 Oct 2011 16:00:20 -0700 (PDT) In-Reply-To: <CA+2YH7vat9iSAuZ4ztDvvo4Od+b4tCOsK6Y+grTE05YUZZEYPQ@mail.gmail.com> References: <CA+2YH7t+cHNoV_oNF6cOyTjr+OFbWAAoKCujFwfNHjvijoD8pw@mail.gmail.com> <CA+2YH7tv-VVnsoKe+C3es==hmKZw771YvVNL=_wwN=hz7JSKSQ@mail.gmail.com> <CAAwP0s0qUvCn+L+tx4NppZknNJ=6aMD5e8E+bLerTnBLLyGL8A@mail.gmail.com> <201110081751.38953.laurent.pinchart@ideasonboard.com> <CAAwP0s3K8D7-LyVUmbj1tMjU6UPESJPxWJu43P2THz4fDSF41A@mail.gmail.com> <CA+2YH7vat9iSAuZ4ztDvvo4Od+b4tCOsK6Y+grTE05YUZZEYPQ@mail.gmail.com> From: Javier Martinez Canillas <martinez.javier@gmail.com> Date: Mon, 10 Oct 2011 01:00:20 +0200 Message-ID: <CAAwP0s3NFvvUYd-0kwKLKXfYB4Zx1nXb0nd9+JM61JWtrVFfRg@mail.gmail.com> Subject: Re: omap3-isp status To: Enrico <ebutera@users.berlios.de> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Deepthy Ravi <deepthy.ravi@ti.com>, Gary Thomas <gary@mlbassoc.com>, Adam Pledger <a.pledger@thermoteknix.com>, linux-media@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.10.9.225414 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' FORGED_FROM_GMAIL 0.1, MULTIPLE_RCPTS 0.1, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, FROM_NAME_PHRASE 0, WEBMAIL_SOURCE 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_MEDIA_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_BODY_WEBMAIL 0, __FRAUD_WEBMAIL 0, __FRAUD_WEBMAIL_FROM 0, __FROM_GMAIL 0, __HAS_MSGID 0, __HAS_X_MAILING_LIST 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __PHISH_SPEAR_HTTP_RECEIVED 0, __PHISH_SPEAR_STRUCTURE_1 0, __PHISH_SPEAR_STRUCTURE_2 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __URI_NO_WWW 0, __URI_NS ' X-LSpam-Score: 1.1 (+) X-LSpam-Report: No, score=1.1 required=5.0 tests=BAYES_00=-1.9, FREEMAIL_FROM=0.001, KB_DATE_CONTAINS_TAB=2.751, RCVD_IN_DNSWL_MED=-2.3, TAB_IN_FROM=2.494, T_DKIM_INVALID=0.01 autolearn=no |
Commit Message
Javier Martinez Canillas
Oct. 9, 2011, 11 p.m. UTC
On Mon, Oct 10, 2011 at 12:35 AM, Enrico <ebutera@users.berlios.de> wrote: > On Sat, Oct 8, 2011 at 6:11 PM, Javier Martinez Canillas > <martinez.javier@gmail.com> wrote: >> Yes, I'll cook a patch today on top on your omap3isp-yuv and send for >> review. I won't be able to test neither since I don't have proper >> hardware at home. But at least you will get an idea of the approach we >> are using to solve this and can point possible flaws. > > I made some tests and unfortunately there are some problems. > > Note: i made these tests picking some patches from omap3isp-yuv branch > and applying to igep 3.1.0rc9 kernel (more or less like mainline + > some bsp patches) so maybe i made some mistakes (the tvp5150 driver is > patched too), but due to the nature of the problems i don't think this > is the case. > > Javier patches v1: i can grab frames with yavta but i get only garbage. > > Javier patches v2: i cannot grab frames with yavta (it hangs). I see > only 2 interrupts on the isp, then stops. > > I compared Javier-v2 registers setup with Deepthy's patches and there > are some differences. Moreover i remember that in Deepthy patches vd1 > interrupt was not used (and in fact i had the same yavta-hanging > problem before, and Deepthy patches solved it). > > I think Javier-v1 patches didn't hang the isp because they changed > vd0/vd1 logic too, so maybe there were only some wrong isp registers > but the logic was correct. > > Now i wonder if it could be easier/better to port Deepthy patches > first and then add Javier fixes... > > Enrico > Hi Enrico, Yes, you are right in interlaced mode the VD1 interrupt handler doesn't have to be executed. In v1 there is a conditional execution and that is why the ISP doesn't hang up. Could you please try changing this on ispccdc.c with v2 patches? ccdc_lsc_isr(ccdc, events); With this change the ISP shouldn't hang but I don't know if you will get the right data. Best regards,
Comments
On Mon, Oct 10, 2011 at 1:00 AM, Javier Martinez Canillas <martinez.javier@gmail.com> wrote: > On Mon, Oct 10, 2011 at 12:35 AM, Enrico <ebutera@users.berlios.de> wrote: >> I made some tests and unfortunately there are some problems. >> >> Note: i made these tests picking some patches from omap3isp-yuv branch >> and applying to igep 3.1.0rc9 kernel (more or less like mainline + >> some bsp patches) so maybe i made some mistakes (the tvp5150 driver is >> patched too), but due to the nature of the problems i don't think this >> is the case. >> >> Javier patches v1: i can grab frames with yavta but i get only garbage. >> >> Javier patches v2: i cannot grab frames with yavta (it hangs). I see >> only 2 interrupts on the isp, then stops. >> >> I compared Javier-v2 registers setup with Deepthy's patches and there >> are some differences. Moreover i remember that in Deepthy patches vd1 >> interrupt was not used (and in fact i had the same yavta-hanging >> problem before, and Deepthy patches solved it). >> >> I think Javier-v1 patches didn't hang the isp because they changed >> vd0/vd1 logic too, so maybe there were only some wrong isp registers >> but the logic was correct. >> >> Now i wonder if it could be easier/better to port Deepthy patches >> first and then add Javier fixes... >> >> Enrico >> > > Hi Enrico, > > Yes, you are right in interlaced mode the VD1 interrupt handler > doesn't have to be executed. In v1 there is a conditional execution > and that is why the ISP doesn't hang up. > > Could you please try changing this on ispccdc.c with v2 patches? > > diff --git a/drivers/media/video/omap3isp/ispccdc.c > b/drivers/media/video/omap3isp/ispccdc.c > index 9b40968..bfd3f46 100644 > --- a/drivers/media/video/omap3isp/ispccdc.c > +++ b/drivers/media/video/omap3isp/ispccdc.c > @@ -1658,7 +1658,8 @@ int omap3isp_ccdc_isr(struct isp_ccdc_device > *ccdc, u32 events) > if (ccdc->state == ISP_PIPELINE_STREAM_STOPPED) > return 0; > > - if (events & IRQ0STATUS_CCDC_VD1_IRQ) > + if ((events & IRQ0STATUS_CCDC_VD1_IRQ) && > + !ccdc_input_is_fldmode(ccdc)) > ccdc_vd1_isr(ccdc); > > ccdc_lsc_isr(ccdc, events); > > With this change the ISP shouldn't hang but I don't know if you will > get the right data. I tried that but i only get this: root@igep0020:~# yavta -c4 -f UYVY -s 720x625 -n 4 /dev/video2 Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: UYVY (59565955) 720x625 buffer size 900000 Video format: UYVY (59565955) 720x625 buffer size 900000 4 buffers requested. length: 900000 offset: 0 Buffer 0 mapped at address 0x4027a000. length: 900000 offset: 901120 Buffer 1 mapped at address 0x403de000. length: 900000 offset: 1802240 Buffer 2 mapped at address 0x4059b000. length: 900000 offset: 2703360 Buffer 3 mapped at address 0x40748000. [ 952.675170] omap3isp omap3isp: CCDC won't become idle! [ 952.695159] omap3isp omap3isp: CCDC won't become idle! [ 952.715179] omap3isp omap3isp: CCDC won't become idle! [ 952.735137] omap3isp omap3isp: CCDC won't become idle! and it continues forever saying that. I'm going to try to apply Deepthy patches on omap3isp-yuv and hope it will work. Enrico -- 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
On Mon, Oct 10, 2011 at 10:54 AM, Enrico <ebutera@users.berlios.de> wrote: > On Mon, Oct 10, 2011 at 1:00 AM, Javier Martinez Canillas > <martinez.javier@gmail.com> wrote: >> On Mon, Oct 10, 2011 at 12:35 AM, Enrico <ebutera@users.berlios.de> wrote: >>> I made some tests and unfortunately there are some problems. >>> >>> Note: i made these tests picking some patches from omap3isp-yuv branch >>> and applying to igep 3.1.0rc9 kernel (more or less like mainline + >>> some bsp patches) so maybe i made some mistakes (the tvp5150 driver is >>> patched too), but due to the nature of the problems i don't think this >>> is the case. >>> >>> Javier patches v1: i can grab frames with yavta but i get only garbage. >>> >>> Javier patches v2: i cannot grab frames with yavta (it hangs). I see >>> only 2 interrupts on the isp, then stops. >>> >>> I compared Javier-v2 registers setup with Deepthy's patches and there >>> are some differences. Moreover i remember that in Deepthy patches vd1 >>> interrupt was not used (and in fact i had the same yavta-hanging >>> problem before, and Deepthy patches solved it). >>> >>> I think Javier-v1 patches didn't hang the isp because they changed >>> vd0/vd1 logic too, so maybe there were only some wrong isp registers >>> but the logic was correct. >>> >>> Now i wonder if it could be easier/better to port Deepthy patches >>> first and then add Javier fixes... >>> >>> Enrico >>> >> >> Hi Enrico, >> >> Yes, you are right in interlaced mode the VD1 interrupt handler >> doesn't have to be executed. In v1 there is a conditional execution >> and that is why the ISP doesn't hang up. >> >> Could you please try changing this on ispccdc.c with v2 patches? >> >> diff --git a/drivers/media/video/omap3isp/ispccdc.c >> b/drivers/media/video/omap3isp/ispccdc.c >> index 9b40968..bfd3f46 100644 >> --- a/drivers/media/video/omap3isp/ispccdc.c >> +++ b/drivers/media/video/omap3isp/ispccdc.c >> @@ -1658,7 +1658,8 @@ int omap3isp_ccdc_isr(struct isp_ccdc_device >> *ccdc, u32 events) >> if (ccdc->state == ISP_PIPELINE_STREAM_STOPPED) >> return 0; >> >> - if (events & IRQ0STATUS_CCDC_VD1_IRQ) >> + if ((events & IRQ0STATUS_CCDC_VD1_IRQ) && >> + !ccdc_input_is_fldmode(ccdc)) >> ccdc_vd1_isr(ccdc); >> >> ccdc_lsc_isr(ccdc, events); >> >> With this change the ISP shouldn't hang but I don't know if you will >> get the right data. > > I tried that but i only get this: > > root@igep0020:~# yavta -c4 -f UYVY -s 720x625 -n 4 /dev/video2 > Device /dev/video2 opened. > Device `OMAP3 ISP CCDC output' on `media' is a video capture device. > Video format set: UYVY (59565955) 720x625 buffer size 900000 > Video format: UYVY (59565955) 720x625 buffer size 900000 > 4 buffers requested. > length: 900000 offset: 0 > Buffer 0 mapped at address 0x4027a000. > length: 900000 offset: 901120 > Buffer 1 mapped at address 0x403de000. > length: 900000 offset: 1802240 > Buffer 2 mapped at address 0x4059b000. > length: 900000 offset: 2703360 > Buffer 3 mapped at address 0x40748000. > [ 952.675170] omap3isp omap3isp: CCDC won't become idle! > [ 952.695159] omap3isp omap3isp: CCDC won't become idle! > [ 952.715179] omap3isp omap3isp: CCDC won't become idle! > [ 952.735137] omap3isp omap3isp: CCDC won't become idle! > > and it continues forever saying that. > > I'm going to try to apply Deepthy patches on omap3isp-yuv and hope it will work. > > Enrico > Hi Enrico, Is your tree (igep 3.1.0rc9 kernel + omap3isp-yuv patches) accessible so I can clone and give a try? I can then make a patch-set on top on that, one that I can actually test on real hardware and be sure that is working well. If I can git clone your tree then it will be faster, otherwise I will try omap3isp-yuv with igep board support added, but it would take me more time to do so. I will find some free time late this afternoon to try that. Best regards,
On Mon, Oct 10, 2011 at 11:02 AM, Javier Martinez Canillas <martinez.javier@gmail.com> wrote: > Is your tree (igep 3.1.0rc9 kernel + omap3isp-yuv patches) accessible > so I can clone and give a try? > > I can then make a patch-set on top on that, one that I can actually > test on real hardware and be sure that is working well. > > If I can git clone your tree then it will be faster, otherwise I will > try omap3isp-yuv with igep board support added, but it would take me > more time to do so. I will find some free time late this afternoon to > try that. I have updated my igep openembedded layer at [1] (testing branch) with: current igep master kernel (3.1.0rc9) + omap3isp-yuv patches + your patches v2 + tvp5150 patches + some tvp5150 and board files fixes. All the patches (specified in the .bb file) are git am-able patches so you can just clone the igep master repository and apply all the patches (0001-0025). This is the cover letter for the patches i applied, if someone can review the omap3isp related patches to be sure i didn't forget anything it would be very helpful: Arnaud Lacombe (1): drivers/media: do not use EXTRA_CFLAGS Enrico Butera (3): tvp5150: compile fixes and added missing entity_cleanup exp-igep0022: add tvp5151 support igep00x0: fix camera platform data Guennadi Liakhovetski (1): omap3isp: ccdc: remove redundant operation Ivaylo Petrov (1): omap3isp: csi2: Add V4L2_MBUS_FMT_YUYV8_2X8 support Javier Martinez Canillas (6): omap3isp: ccdc: Add interlaced field mode to platform data omap3isp: ccdc: Add interlaced count field to isp_ccdc_device omap3isp: ccdc: Add support to ITU-R BT.656 video data format tvp5150: Add constants for PAL and NTSC video standards tvp5150: Add video format registers configuration values tvp5150: Migrate to media-controller framework and add video format detection Laurent Pinchart (12): omap3isp: Don't accept pipelines with no video source as valid omap3isp: Move platform data definitions from isp.h to media/omap3isp.h omap3isp: Don't fail streamon when the sensor doesn't implement s_stream omap3isp: video: Avoid crashes when pipeline set stream operation fails omap3isp: Move media_entity_cleanup() from unregister() to cleanup() omap3isp: Move *_init_entities() functions to the init/cleanup section omap3isp: Add missing mutex_destroy() calls omap3isp: Fix memory leaks in initialization error paths omap3isp: video: Split format info bpp field into width and bpp omap3isp: ccdc: Remove support for interlaced data and master HS/VS mode omap3isp: ccdc: Remove ispccdc_syncif structure omap3isp: ccdc: Add YUV input formats support Michael Jones (1): omap3isp: queue: fail QBUF if user buffer is too small arch/arm/mach-omap2/board-igep00x0.c | 67 +++++ arch/arm/mach-omap2/exp-igep0022.c | 3 + drivers/media/video/omap3isp/Makefile | 4 +- drivers/media/video/omap3isp/isp.c | 13 +- drivers/media/video/omap3isp/isp.h | 87 +------ drivers/media/video/omap3isp/ispccdc.c | 376 ++++++++++++++++---------- drivers/media/video/omap3isp/ispccdc.h | 38 +--- drivers/media/video/omap3isp/ispccp2.c | 129 +++++----- drivers/media/video/omap3isp/ispcsi2.c | 118 +++++--- drivers/media/video/omap3isp/isph3a_aewb.c | 2 +- drivers/media/video/omap3isp/isph3a_af.c | 2 +- drivers/media/video/omap3isp/isphist.c | 2 +- drivers/media/video/omap3isp/isppreview.c | 108 ++++---- drivers/media/video/omap3isp/ispqueue.c | 4 + drivers/media/video/omap3isp/ispresizer.c | 104 ++++---- drivers/media/video/omap3isp/ispstat.c | 52 ++-- drivers/media/video/omap3isp/ispstat.h | 2 +- drivers/media/video/omap3isp/ispvideo.c | 77 ++++-- drivers/media/video/omap3isp/ispvideo.h | 5 +- drivers/media/video/tvp5150.c | 408 +++++++++++++++++++++++++++- drivers/media/video/tvp5150_reg.h | 17 +- include/media/omap3isp.h | 138 ++++++++++ include/media/tvp5150.h | 6 + 23 files changed, 1215 insertions(+), 547 deletions(-) create mode 100644 include/media/omap3isp.h Enrico -- 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
On Mon, Oct 10, 2011 at 12:06 PM, Enrico <ebutera@users.berlios.de> wrote:
> I have updated my igep openembedded layer at [1] (testing branch) with:
Ops, forgot [1] !
[1]: https://github.com/ebutera/meta-igep
Enrico
--
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
On Mon, Oct 10, 2011 at 12:07 PM, Enrico <ebutera@users.berlios.de> wrote: > On Mon, Oct 10, 2011 at 12:06 PM, Enrico <ebutera@users.berlios.de> wrote: >> I have updated my igep openembedded layer at [1] (testing branch) with: > > Ops, forgot [1] ! > > [1]: https://github.com/ebutera/meta-igep > > Enrico > Perfect, thank you Enrico. I will try this latter today and let you know. I'm sure I can get this working (with the ghosting effect of course) so you can at least obtain 25 fps and once I have this working I will resend the patch-set as v3 so Laurent can review it and hopefully help us to fix the artifact on the video. Best regards,
On Mon, Oct 10, 2011 at 12:33 PM, Javier Martinez Canillas <martinez.javier@gmail.com> wrote: > On Mon, Oct 10, 2011 at 12:07 PM, Enrico <ebutera@users.berlios.de> wrote: >> On Mon, Oct 10, 2011 at 12:06 PM, Enrico <ebutera@users.berlios.de> wrote: >>> I have updated my igep openembedded layer at [1] (testing branch) with: >> >> Ops, forgot [1] ! >> >> [1]: https://github.com/ebutera/meta-igep >> >> Enrico >> > > Perfect, thank you Enrico. I will try this latter today and let you > know. I'm sure I can get this working (with the ghosting effect of > course) so you can at least obtain 25 fps and once I have this working > I will resend the patch-set as v3 so Laurent can review it and > hopefully help us to fix the artifact on the video. For your tests i suggest to add "nohlt" to the kernel cmdline, see [1] for the reason. Enrico [1]: http://www.spinics.net/lists/linux-media/msg37795.html -- 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
diff --git a/drivers/media/video/omap3isp/ispccdc.c b/drivers/media/video/omap3isp/ispccdc.c index 9b40968..bfd3f46 100644 --- a/drivers/media/video/omap3isp/ispccdc.c +++ b/drivers/media/video/omap3isp/ispccdc.c @@ -1658,7 +1658,8 @@ int omap3isp_ccdc_isr(struct isp_ccdc_device *ccdc, u32 events) if (ccdc->state == ISP_PIPELINE_STREAM_STOPPED) return 0; - if (events & IRQ0STATUS_CCDC_VD1_IRQ) + if ((events & IRQ0STATUS_CCDC_VD1_IRQ) && + !ccdc_input_is_fldmode(ccdc)) ccdc_vd1_isr(ccdc);