Message ID | 501C23D7.3020307@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 1SxNNf-0000uw-0k for patchwork@linuxtv.org; Fri, 03 Aug 2012 21:17:51 +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-2) with esmtp for <patchwork@linuxtv.org> id 1SxNNe-0005oj-HZ; Fri, 03 Aug 2012 21:17:50 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752876Ab2HCTRs (ORCPT <rfc822;patchwork@linuxtv.org>); Fri, 3 Aug 2012 15:17:48 -0400 Received: from mail-bk0-f46.google.com ([209.85.214.46]:58502 "EHLO mail-bk0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752328Ab2HCTRr (ORCPT <rfc822; linux-media@vger.kernel.org>); Fri, 3 Aug 2012 15:17:47 -0400 Received: by bkwj10 with SMTP id j10so395600bkw.19 for <multiple recipients>; Fri, 03 Aug 2012 12:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qdUjWeomBGjahlFCvPO3w++d7j7ZQnXulRFzzzyPBxk=; b=Qp4J6KGEFCtYkp/4DZg/dJ3DSNZ++Rw4GfdZZ8nruLGUuJsLOzxJh1o/mKattCOaIs g6jJR/QHg2a7SMdkcz+OkUBYLgZ0q8KPlGZKHqdSlEEhBGJWBGNPtE++20DjTTzsiaxo v68ZhmCdnEcPBruiQxh7mL5STtvtbRD1HLUTRCYWlfsfVlSwotzbeElX7oTpDTugTYvw FNwuTZcG0WWl+isSNnhPVt9hW5Vf2RpEihhC6jYlVeAHsdl6oj0iFhSNHu9MjhKzms4N k0Q8iIWbuiE/DDSn9UTIT/dmEaALeFXypoXDszDQBh2DHHbLwd4dA1Ky6szHQ0z3kIxa fL5A== Received: by 10.204.152.19 with SMTP id e19mr1101916bkw.8.1344021465494; Fri, 03 Aug 2012 12:17:45 -0700 (PDT) Received: from [192.168.1.110] (031011252076.warszawa.vectranet.pl. [31.11.252.76]) by mx.google.com with ESMTPS id hg13sm5187499bkc.7.2012.08.03.12.17.44 (version=SSLv3 cipher=OTHER); Fri, 03 Aug 2012 12:17:44 -0700 (PDT) Message-ID: <501C23D7.3020307@gmail.com> Date: Fri, 03 Aug 2012 21:17:43 +0200 From: Sylwester Nawrocki <sylvester.nawrocki@gmail.com> User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mike Dyer <mike.dyer@md-soft.co.uk> CC: LMML <linux-media@vger.kernel.org>, "linux-samsung-soc@vger.kernel.org" <linux-samsung-soc@vger.kernel.org> Subject: Re: s5p-fimc capturing interlaced BT656 References: <1343911731.4113.5.camel@edge> In-Reply-To: <1343911731.4113.5.camel@edge> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: 2012.8.3.190915 X-PMX-Spam: Gauge=IIIIIIIII, Probability=9%, Report=' FORGED_FROM_GMAIL 0.1, MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1600_1699 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, CT_TEXT_PLAIN_UTF8_CAPS 0, URI_ENDS_IN_HTML 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_WEBMAIL 0, __FRAUD_WEBMAIL_FROM 0, __FROM_GMAIL 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILING_LIST 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MULTIPLE_RCPTS_CC_X2 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0' |
Commit Message
Sylwester Nawrocki
Aug. 3, 2012, 7:17 p.m. UTC
Hi Mike, On 08/02/2012 02:48 PM, Mike Dyer wrote: > Hi All, > > I'm using the S5PV210 camera IF and capturing BT656 video from a TVP5150 > video decoder. > > I notice that the capture driver ignores the field interlace flags > reported by the 'sensor' and always uses 'V4L2_FIELD_NONE'. It also > seems each field ends up in it's own frame, using only half the height. s5p-fimc driver doesn't support the interlaced video capture, as we had no such use case yet. Patches adding it are welcome. > What would need to be done to store both fields in a single frame, for > example in a V4L2_FIELD_INTERLACE_TB/BT format? Firstly, it would good to figure out FIMC register settings that would allow storing both fields in a single frame. I _suspect_ it's as simple as setting CAM_INTERLACE bit in CIGCTRL register. Have you perhaps tried it already ? For a quick test a patch as below might be sufficient. -- Thanks, Sylwester -- 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
Comments
Hi Sylwester, On Fri, 2012-08-03 at 21:17 +0200, Sylwester Nawrocki wrote: > Hi Mike, > > On 08/02/2012 02:48 PM, Mike Dyer wrote: > > Hi All, > > > > I'm using the S5PV210 camera IF and capturing BT656 video from a TVP5150 > > video decoder. > > > > I notice that the capture driver ignores the field interlace flags > > reported by the 'sensor' and always uses 'V4L2_FIELD_NONE'. It also > > seems each field ends up in it's own frame, using only half the height. > > s5p-fimc driver doesn't support the interlaced video capture, as we had > no such use case yet. Patches adding it are welcome. > > > What would need to be done to store both fields in a single frame, for > > example in a V4L2_FIELD_INTERLACE_TB/BT format? > > Firstly, it would good to figure out FIMC register settings that would > allow storing both fields in a single frame. I _suspect_ it's as simple > as setting CAM_INTERLACE bit in CIGCTRL register. Have you perhaps tried > it already ? > > For a quick test a patch as below might be sufficient. > > > diff --git a/drivers/media/video/s5p-fimc/fimc-reg.c b/drivers/media/video/s5p-fimc/fimc-reg.c > index 1fc4ce8..19afa1a 100644 > --- a/drivers/media/video/s5p-fimc/fimc-reg.c > +++ b/drivers/media/video/s5p-fimc/fimc-reg.c > @@ -576,6 +576,8 @@ int fimc_hw_set_camera_polarity(struct fimc_dev *fimc, > if (cam->flags & V4L2_MBUS_FIELD_EVEN_LOW) > cfg |= FIMC_REG_CIGCTRL_INVPOLFIELD; > > + cfg |= FIMC_REG_CIGCTRL_INTERLACE; > + > writel(cfg, fimc->regs + FIMC_REG_CIGCTRL); > > return 0; > > > -- > > Thanks, > Sylwester I have indeed tried setting that, but with no effect. However, checking through the datasheet for the FIMC I discovered a DMA output (CIOCTRL) register bit called 'Weave_Out'. The description is: "Even and Odd fields can be weaved together and combined to form a complete progressive frame by hardware. This field is useful for interlace DMA output mode (Interlace_out or CAM_INTERLACE). Even field address (1st frame start address) is used weave address. Odd fields address (2nd frame start address) is ignored." This does produce full sized frames, but I still seem to only be getting one field per frame, with a blank line inserted between each real line. Setting both interlace and weave doesn't seem to help. So, something still missing... I wonder if the irq handler is getting called for each field, maybe we need to wait for two interrupts before dequeing the frame? Cheers, Mike -- 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 08/03/2012 10:01 PM, Mike Dyer wrote: > I have indeed tried setting that, but with no effect. However, checking > through the datasheet for the FIMC I discovered a DMA output (CIOCTRL) > register bit called 'Weave_Out'. The description is: > > "Even and Odd fields can be weaved together and combined to form a > complete progressive frame by hardware. This field is useful for > interlace DMA output mode (Interlace_out or CAM_INTERLACE). Even field > address (1st frame start address) is used weave address. Odd fields > address (2nd frame start address) is ignored." > > This does produce full sized frames, but I still seem to only be getting > one field per frame, with a blank line inserted between each real line. > Setting both interlace and weave doesn't seem to help. So, something > still missing... > > I wonder if the irq handler is getting called for each field, maybe we > need to wait for two interrupts before dequeing the frame? Hmm, might be worth to try. But I'm wondering if the output DMA handling doesn't need to be reworked for that. According to the datasheet (Figure 2-20 Frame Buffer Control), even fields are written to DMA buffer with even index (e.g. 0) and odd fields are written to DMA buffer with odd index (e.g. 1). So possibly, if we set same address at two DMA buffer start address registers (e.g. FIMC_REG_CIOYSA(0), FIMC_REG_CIOYSA(1)) then even and odd frame will be written to proper memory location ? This might not be very difficult to implement. -- Regards, Sylwester -- 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/s5p-fimc/fimc-reg.c b/drivers/media/video/s5p-fimc/fimc-reg.c index 1fc4ce8..19afa1a 100644 --- a/drivers/media/video/s5p-fimc/fimc-reg.c +++ b/drivers/media/video/s5p-fimc/fimc-reg.c @@ -576,6 +576,8 @@ int fimc_hw_set_camera_polarity(struct fimc_dev *fimc, if (cam->flags & V4L2_MBUS_FIELD_EVEN_LOW) cfg |= FIMC_REG_CIGCTRL_INVPOLFIELD; + cfg |= FIMC_REG_CIGCTRL_INTERLACE; + writel(cfg, fimc->regs + FIMC_REG_CIGCTRL); return 0;