From patchwork Tue Feb 28 03:38:31 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "Aguirre Rodriguez, Sergio Alberto" X-Patchwork-Id: 10082 Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from ) id 1S2Dty-0001sU-Dw for patchwork@linuxtv.org; Tue, 28 Feb 2012 04:38:58 +0100 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-3) with esmtp for id 1S2Dtx-0002Ur-DK; Tue, 28 Feb 2012 04:38:58 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755564Ab2B1Diy (ORCPT ); Mon, 27 Feb 2012 22:38:54 -0500 Received: from na3sys009aog103.obsmtp.com ([74.125.149.71]:47728 "EHLO na3sys009aog103.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754231Ab2B1Dix (ORCPT ); Mon, 27 Feb 2012 22:38:53 -0500 Received: from mail-qy0-f173.google.com ([209.85.216.173]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKT0xMTE96+k/4Munfw8vp2DN8ZjGUYLXC@postini.com; Mon, 27 Feb 2012 19:38:53 PST Received: by qcsc20 with SMTP id c20so2168941qcs.4 for ; Mon, 27 Feb 2012 19:38:51 -0800 (PST) Received-SPF: pass (google.com: domain of saaguirre@ti.com designates 10.224.102.8 as permitted sender) client-ip=10.224.102.8; Authentication-Results: mr.google.com; spf=pass (google.com: domain of saaguirre@ti.com designates 10.224.102.8 as permitted sender) smtp.mail=saaguirre@ti.com Received: from mr.google.com ([10.224.102.8]) by 10.224.102.8 with SMTP id e8mr12801964qao.50.1330400331411 (num_hops = 1); Mon, 27 Feb 2012 19:38:51 -0800 (PST) Received: by 10.224.102.8 with SMTP id e8mr10745715qao.50.1330400331292; Mon, 27 Feb 2012 19:38:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.235.203 with HTTP; Mon, 27 Feb 2012 19:38:31 -0800 (PST) In-Reply-To: References: From: "Aguirre, Sergio" Date: Mon, 27 Feb 2012 21:38:31 -0600 Message-ID: Subject: Re: Video Capture Issue To: Sriram V Cc: linux-media@vger.kernel.org X-Gm-Message-State: ALoCoQkzfuNWUzYAlL0mJDVTd/9fQUlQ2oIDZ1lqKbf9XmtC/rIeVNFP0bc7hIurm74H5yRE/06n Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.2.21.234815 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, MIME_TEXT_ONLY_MP_MIXED 0.05, MSGID_ADDED_BY_MTA 0.05, BODY_SIZE_6000_6999 0, BODY_SIZE_7000_LESS 0, CTYPE_MULTIPART_NO_QUOTE 0, DATE_TZ_NA 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, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_MIXED 0, __FRAUD_BODY_WEBMAIL 0, __FRAUD_WEBMAIL 0, __HAS_MSGID 0, __HAS_X_MAILING_LIST 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_HTTP_RECEIVED 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __URI_NO_WWW 0, __URI_NS ' Sriram, On Sun, Feb 26, 2012 at 8:54 AM, Sriram V wrote: > Hi, >  When I take the dump of the buffer which is pointed by "DATA MEM > PING ADDRESS". It always shows 0x55. >  Even if i write 0x00 to the address. I do notice that it quickly > changes to 0x55. >  Under what conditions could this happen? What am i missing here. If you're using "yavta" for capture, notice that it clears out the buffers before queuing them in: static int video_queue_buffer(struct device *dev, int index, enum buffer_fill_mode fill) { struct v4l2_buffer buf; int ret; ... ... if (dev->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) { ... } else { if (fill & BUFFER_FILL_FRAME) memset(dev->buffers[buf.index].mem, 0x55, dev->buffers[index].size); if (fill & BUFFER_FILL_PADDING) memset(dev->buffers[buf.index].mem + dev->buffers[index].size, 0x55, dev->buffers[index].padding); } ... } So, just make sure this condition is not met. > >  I do notice that the OMAP4 ISS is tested to work with OV5640 (YUV422 > Frames) and OV5650 (Raw Data) >  When you say 422 Frames only. Do you mean 422-8Bit Mode?. Yes. When saving YUV422 to memory, you can only use this mode AFAIK. > >  I havent tried RAW12 which my device gives, Do i have to update only > the Data Format Selection register >  of the ISS  for RAW12? Ok, now it makes sense. So, if your CSI2 source is giving, you need to make sure: CSI2_CTX_CTRL2_0.FORMAT[9:0] is: - 0xAC: RAW12 + EXP16 or - 0x2C: RAW12 The difference is that the EXP16 variant, will save to memory in expansion to 2 bytes, instead of 12 bits, so it'll be byte aligned. Can you try attached patch? Regards, Sergio > >  Please advice. > > > On Thu, Feb 23, 2012 at 11:24 PM, Sriram V wrote: >> Hi, >>  1) An Hexdump of the captured file shows 0x55 at all locations. >>      Is there any buffer location i need to check. >>  2) I have tried with  "devel" branch. >>  3) Changing the polarities doesnt help either. >>  4) The sensor is giving out YUV422 8Bit Mode, >>      Will 0x52001074 = 0x0A00001E (UYVY Format)  it bypass the ISP >>       and dump directly into memory. >> >> On 2/23/12, Aguirre, Sergio wrote: >>> Hi Sriram, >>> >>> On Thu, Feb 23, 2012 at 11:25 AM, Sriram V wrote: >>>> Hi, >>>>  1) I am trying to get a HDMI to CSI Bridge chip working with OMAP4 ISS. >>>>      The issue is the captured frames are completely green in color. >>> >>> Sounds like the buffer is all zeroes, can you confirm? >>> >>>>  2) The Chip is configured to output VGA Color bar sequence with >>>> YUV422-8Bit and >>>>       uses datalane 0 only. >>>>  3) The Format on OMAP4 ISS  is UYVY (Register 0x52001074 = 0x0A00001E) >>>>  I am trying to directly dump the data into memory without ISP processing. >>>> >>>> >>>>  Please advice. >>> >>> Just to be clear on your environment, which branch/commitID are you based >>> on? >>> >>> Regards, >>> Sergio >>> >>>> >>>> -- >>>> Regards, >>>> Sriram >>>> -- >>>> 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 >>> >> >> >> -- >> Regards, >> Sriram > > > > -- > Regards, > Sriram diff --git a/drivers/media/video/omap4iss/iss_csi2.c b/drivers/media/video/omap4iss/iss_csi2.c index 04985a0..0e8a069 100644 --- a/drivers/media/video/omap4iss/iss_csi2.c +++ b/drivers/media/video/omap4iss/iss_csi2.c @@ -106,6 +106,10 @@ static const unsigned int csi2_input_fmts[] = { V4L2_MBUS_FMT_SGBRG8_1X8, V4L2_MBUS_FMT_SGRBG8_1X8, V4L2_MBUS_FMT_SRGGB8_1X8, + V4L2_MBUS_FMT_SBGGR12_1X12, + V4L2_MBUS_FMT_SGBRG12_1X12, + V4L2_MBUS_FMT_SGRBG12_1X12, + V4L2_MBUS_FMT_SRGGB12_1X12, V4L2_MBUS_FMT_UYVY8_1X16, V4L2_MBUS_FMT_YUYV8_1X16, }; @@ -171,6 +175,23 @@ static const u16 __csi2_fmt_map[][2][2] = { 0, }, }, + /* RAW12 formats */ + { + /* Output to memory */ + { + /* No DPCM decompression */ + CSI2_PIX_FMT_RAW12_EXP16, + /* DPCM decompression */ + 0, + }, + /* Output to both */ + { + /* No DPCM decompression */ + CSI2_PIX_FMT_RAW12_VP, + /* DPCM decompression */ + 0, + }, + }, /* YUV422 formats */ { /* Output to memory */ @@ -220,9 +241,15 @@ static u16 csi2_ctx_map_format(struct iss_csi2_device *csi2) case V4L2_MBUS_FMT_SRGGB8_1X8: fmtidx = 2; break; + case V4L2_MBUS_FMT_SBGGR12_1X12: + case V4L2_MBUS_FMT_SGBRG12_1X12: + case V4L2_MBUS_FMT_SGRBG12_1X12: + case V4L2_MBUS_FMT_SRGGB12_1X12: + fmtidx = 3; + break; case V4L2_MBUS_FMT_UYVY8_1X16: case V4L2_MBUS_FMT_YUYV8_1X16: - fmtidx = 3; + fmtidx = 4; break; default: WARN(1, KERN_ERR "CSI2: pixel format %08x unsupported!\n", diff --git a/drivers/media/video/omap4iss/iss_csi2.h b/drivers/media/video/omap4iss/iss_csi2.h index aa81971..beed331 100644 --- a/drivers/media/video/omap4iss/iss_csi2.h +++ b/drivers/media/video/omap4iss/iss_csi2.h @@ -32,6 +32,8 @@ enum iss_csi2_pix_formats { CSI2_PIX_FMT_RAW8_DPCM10_EXP16 = 0x2aa, CSI2_PIX_FMT_RAW8_DPCM10_VP = 0x32a, CSI2_PIX_FMT_RAW8_VP = 0x12a, + CSI2_PIX_FMT_RAW12_EXP16 = 0xac, + CSI2_PIX_FMT_RAW12_VP = 0x12c, CSI2_USERDEF_8BIT_DATA1_DPCM10_VP = 0x340, CSI2_USERDEF_8BIT_DATA1_DPCM10 = 0x2c0, CSI2_USERDEF_8BIT_DATA1 = 0x40,