Re: Video Capture Issue
Hi Aguirre Sergio, 1) Looks like it could be a data lane issue. OMAP detects lots of ERRSOTSYNCHS errors on the datalanes (CSI2_COMPLEXIO_IRQSTATUS) 2) Even if i configure it to use only one data lane on both sides. It detects errors on other data lanes. That explains the abnormally high number of these error interrupts and a frame completion interrupt once in a while. I guess, I need to check my configuration settings. Thanks, Sriram On Tue, Feb 28, 2012 at 9:12 PM, Aguirre, Sergio saagui...@ti.com wrote: Hi Sriram, On Tue, Feb 28, 2012 at 8:46 AM, Sriram V vshrir...@gmail.com wrote: Hi Aguirre Sergio, On Tue, Feb 28, 2012 at 9:08 AM, Aguirre, Sergio saagui...@ti.com wrote: Sriram, On Sun, Feb 26, 2012 at 8:54 AM, Sriram V vshrir...@gmail.com 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. Unfortunately, this condition is met. For some reason, ISS thinks it has got valid frame. Whereas the Image data is not populated into the buffers. The register CSI2_CTX_CTRL1_i[COUNT] keeps getting toggled between 0 and 1 indicating a frame arrival. I also notice that on some frames, The first 0x200 bytes contains data other than 0x55 and the rest are 0x55. Probably this could be related to resolution settings or hsync and vsync settings. Probably, my chip configuration is faulty. Hmm, sounds like it. Can you try adding this to the top of the file? #define DEBUG So that the dev_dbg() prints get executed? I'm curious to see if you detect any ComplexIO errors on omap4iss_csi2_isr()... 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? With RAW12 configuration, I dont see any interrupts at all. Ok, Then this means your CSI2 transmitter (sensor) is actually sending YUV422, and not RAW12. Nevermind that patch then... Regards, Sergio Regards, Sergio Please advice. On Thu, Feb 23, 2012 at 11:24 PM, Sriram V vshrir...@gmail.com 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 = 0x0A1E (UYVY Format) it bypass the ISP and dump directly into memory. On 2/23/12, Aguirre, Sergio saagui...@ti.com wrote: Hi Sriram, On Thu, Feb 23, 2012 at 11:25 AM, Sriram V vshrir...@gmail.com 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 = 0x0A1E) 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Sriram -- Regards, Sriram -- Regards, Sriram -- Regards, Sriram -- To unsubscribe
Re: Video Capture Issue
Sriram, On Sun, Feb 26, 2012 at 8:54 AM, Sriram V vshrir...@gmail.com 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 vshrir...@gmail.com 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 = 0x0A1E (UYVY Format) it bypass the ISP and dump directly into memory. On 2/23/12, Aguirre, Sergio saagui...@ti.com wrote: Hi Sriram, On Thu, Feb 23, 2012 at 11:25 AM, Sriram V vshrir...@gmail.com 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 = 0x0A1E) 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 majord...@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 {
Re: Video Capture Issue
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. 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?. I havent tried RAW12 which my device gives, Do i have to update only the Data Format Selection register of the ISS for RAW12? Please advice. On Thu, Feb 23, 2012 at 11:24 PM, Sriram V vshrir...@gmail.com 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 = 0x0A1E (UYVY Format) it bypass the ISP and dump directly into memory. On 2/23/12, Aguirre, Sergio saagui...@ti.com wrote: Hi Sriram, On Thu, Feb 23, 2012 at 11:25 AM, Sriram V vshrir...@gmail.com 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 = 0x0A1E) 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Sriram -- Regards, Sriram -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Video Capture Issue
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. 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 = 0x0A1E) I am trying to directly dump the data into memory without ISP processing. Please advice. -- Regards, Sriram -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Video Capture Issue
Hi Sriram, On Thu, Feb 23, 2012 at 11:25 AM, Sriram V vshrir...@gmail.com 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 = 0x0A1E) 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Video Capture Issue
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 = 0x0A1E (UYVY Format) it bypass the ISP and dump directly into memory. On 2/23/12, Aguirre, Sergio saagui...@ti.com wrote: Hi Sriram, On Thu, Feb 23, 2012 at 11:25 AM, Sriram V vshrir...@gmail.com 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 = 0x0A1E) 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Sriram -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html