PXA320 camera support
Hi all, I have seen that the pxa27xx-camera is inside the devices for the PXA320 but I don't know if this support work for this cpu. Looking at the code for example the overrun condition check is wrong for the PXA320 because the bits of the overrun is different - camera_status = __raw_readl(pcdev-base + CISR); + camera_status = __raw_readl(pcdev-base + CIFSR); In the two implementation. Anyone has tried to use it on the pxa320? Michael Trimarchi -- 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: omap34xxcam question?
Hi, Sakari Ailus wrote: Hi Michael, Michael Trimarchi wrote: Aguirre, Sergio wrote: ... So, if I got you right, you're saying that, there should be priorities for sensor baseformats, depending on the preference specified somewhere in the boardfile? Yes, that is the idea. Try to provide a better patch later, I'm working hard on the sensor part :) Apologies for my late answer. No problem on that The frame sizes in our sensor drivers are in width descending order. The selection has been working somehow so far but it's definitely not perfect. Ok for the frame size but you need to test all the possible sensor output too and continue in case of error. We're converting the ISP driver to use the Media controller so this code will be dropped in near future probably. In that case the user space has to select the sensor mode it wants to use as well. Good. Maybe I can test the framework on the FLOW1.5 mobile device using the TCM8240MD What is your git for the camera framework? Michael -- 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: omap34xxcam question?
Michael Trimarchi wrote: Aguirre, Sergio wrote: -Original Message- From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org] Sent: Thursday, January 14, 2010 11:39 AM To: Aguirre, Sergio Cc: linux-media@vger.kernel.org Subject: Re: omap34xxcam question? Aguirre, Sergio wrote: -Original Message- From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org] Sent: Thursday, January 14, 2010 11:25 AM To: Aguirre, Sergio Cc: linux-media@vger.kernel.org Subject: Re: omap34xxcam question? Hi, Aguirre, Sergio wrote: -Original Message- From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org] Sent: Thursday, January 14, 2010 6:01 AM To: linux-media@vger.kernel.org Cc: Aguirre, Sergio Subject: omap34xxcam question? Hi Is ok that it try only the first format and size? why does it not continue and find a matching? Actually, that was the intention, but I guess it was badly implemented. Thanks for the catch, and the contribution! Regards, Sergio @@ -470,7 +471,7 @@ static int try_pix_parm(struct omap34xxcam_videodev *vdev, pix_tmp_out = *wanted_pix_out; rval = isp_try_fmt_cap(isp, pix_tmp_in, pix_tmp_out); if (rval) - return rval; + continue; Is the patch good? or you are going to provide a better fix Yes. Sorry if I wasn't clear enough. Looks good to me, and I don't have a better fix on top of my head for the moment... I'm assuming you tested it in your environment, right? Ok, my enviroment is not pretty stable but for sure this is required. There is one problem: Suppose that the camera support this format: YUV and RAW10 The video4linux enumeration is done in this order. We know that if you want to use resizer and previewer we can't use the YUV (go straight to memory) but it is selected because is the first. So maybe the best thing is to find the one that is suggest in the csi configuration first. Hope that is clear. Hmm.. I see. So, if I got you right, you're saying that, there should be priorities for sensor baseformats, depending on the preference specified somewhere in the boardfile? Yes, that is the idea. Try to provide a better patch later, I'm working hard on the sensor part :) diff --git a/drivers/media/video/omap34xxcam.c b/drivers/media/video/omap34xxcam index 53b587e..75bd858 100644 --- a/drivers/media/video/omap34xxcam.c +++ b/drivers/media/video/omap34xxcam.c @@ -448,6 +448,10 @@ static int try_pix_parm(struct omap34xxcam_videodev *vdev, break; dev_dbg(vdev-vfd-dev, trying fmt %8.8x (%d)\n, fmtd.pixelformat, fmtd_index); + + if (fmtd.pixelformat != best_pix_in-pixelformat) + continue; + /* * Get supported resolutions. */ @@ -470,7 +474,7 @@ static int try_pix_parm(struct omap34xxcam_videodev *vdev, pix_tmp_out = *wanted_pix_out; rval = isp_try_fmt_cap(isp, pix_tmp_in, pix_tmp_out); if (rval) - return rval; + continue; dev_dbg(vdev-vfd-dev, this w %d\th %d\tfmt %8.8x\t Somenthing like that. michael Michael Regards, Sergio Michael If yes, then I'll take the patch in my queue for submission to Sakari's tree. Thanks for your time. Regards, Sergio Michael Michael -- 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 -- 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 -- 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: camera with high framerate
rath wrote:
Okay, are there some other cameras avaiable with 160x120 pixels or
output in rgb? I only have an ARM Cortex-A8 with 500MHz to process the
image data and converting between different pixelformats take a long
time. So it would be fine if a resolution of 160x120 pixels is supported
or the output is in rgb.
ov538-ov7690 solution
static const struct v4l2_pix_format vga_mode[] = {
{ 176, 144, V4L2_PIX_FMT_YUYV, V4L2_FIELD_NONE,
.bytesperline = 176 * 2,
.sizeimage = 176 * 144 * 2,
.colorspace = V4L2_COLORSPACE_SRGB,
.priv = size176_144 },
I think that it has the 160x120 resolution too, but I don't write the code for
that.
The sensor arrive at 60 fps in QVGA mode
Michael
- Original Message - From: Jean-Francois Moine moin...@free.fr
To: rath maili...@hardware-datenbank.de
Cc: linux-media@vger.kernel.org
Sent: Saturday, January 16, 2010 7:14 PM
Subject: Re: camera with high framerate
On Sat, 16 Jan 2010 18:33:54 +0100
rath maili...@hardware-datenbank.de wrote:
I'm searching a v4l supported webcam with a framerate higher than
30fps. I found the Playstation Eye and it seems to have a framerate
of up to 120fps @320x240 pixels.
Does this camera support a resolution of 160x120 pixels? How are the
images transfered over usb (jpeg, rgb, yuv)?
Hi Joern,
The resolutions are only 640x480 and 320x240. The images are transfered
in YUYV (16 bits YUV 4:2:2).
Regards.
--
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: omap34xxcam question?
Aguirre, Sergio wrote: -Original Message- From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org] Sent: Thursday, January 14, 2010 11:39 AM To: Aguirre, Sergio Cc: linux-media@vger.kernel.org Subject: Re: omap34xxcam question? Aguirre, Sergio wrote: -Original Message- From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org] Sent: Thursday, January 14, 2010 11:25 AM To: Aguirre, Sergio Cc: linux-media@vger.kernel.org Subject: Re: omap34xxcam question? Hi, Aguirre, Sergio wrote: -Original Message- From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org] Sent: Thursday, January 14, 2010 6:01 AM To: linux-media@vger.kernel.org Cc: Aguirre, Sergio Subject: omap34xxcam question? Hi Is ok that it try only the first format and size? why does it not continue and find a matching? Actually, that was the intention, but I guess it was badly implemented. Thanks for the catch, and the contribution! Regards, Sergio @@ -470,7 +471,7 @@ static int try_pix_parm(struct omap34xxcam_videodev *vdev, pix_tmp_out = *wanted_pix_out; rval = isp_try_fmt_cap(isp, pix_tmp_in, pix_tmp_out); if (rval) - return rval; + continue; Is the patch good? or you are going to provide a better fix Yes. Sorry if I wasn't clear enough. Looks good to me, and I don't have a better fix on top of my head for the moment... I'm assuming you tested it in your environment, right? Ok, my enviroment is not pretty stable but for sure this is required. There is one problem: Suppose that the camera support this format: YUV and RAW10 The video4linux enumeration is done in this order. We know that if you want to use resizer and previewer we can't use the YUV (go straight to memory) but it is selected because is the first. So maybe the best thing is to find the one that is suggest in the csi configuration first. Hope that is clear. Hmm.. I see. So, if I got you right, you're saying that, there should be priorities for sensor baseformats, depending on the preference specified somewhere in the boardfile? Yes, that is the idea. Try to provide a better patch later, I'm working hard on the sensor part :) Michael Regards, Sergio Michael If yes, then I'll take the patch in my queue for submission to Sakari's tree. Thanks for your time. Regards, Sergio Michael Michael -- 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 -- 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
omap34xxcam question?
Hi Is ok that it try only the first format and size? why does it not continue and find a matching? @@ -470,7 +471,7 @@ static int try_pix_parm(struct omap34xxcam_videodev *vdev, pix_tmp_out = *wanted_pix_out; rval = isp_try_fmt_cap(isp, pix_tmp_in, pix_tmp_out); if (rval) - return rval; + continue; Michael -- 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: omap34xxcam question?
Hi, Aguirre, Sergio wrote: -Original Message- From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org] Sent: Thursday, January 14, 2010 6:01 AM To: linux-media@vger.kernel.org Cc: Aguirre, Sergio Subject: omap34xxcam question? Hi Is ok that it try only the first format and size? why does it not continue and find a matching? Actually, that was the intention, but I guess it was badly implemented. Thanks for the catch, and the contribution! Regards, Sergio @@ -470,7 +471,7 @@ static int try_pix_parm(struct omap34xxcam_videodev *vdev, pix_tmp_out = *wanted_pix_out; rval = isp_try_fmt_cap(isp, pix_tmp_in, pix_tmp_out); if (rval) - return rval; + continue; Is the patch good? or you are going to provide a better fix Michael Michael -- 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: omap34xxcam question?
Aguirre, Sergio wrote: -Original Message- From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org] Sent: Thursday, January 14, 2010 11:25 AM To: Aguirre, Sergio Cc: linux-media@vger.kernel.org Subject: Re: omap34xxcam question? Hi, Aguirre, Sergio wrote: -Original Message- From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org] Sent: Thursday, January 14, 2010 6:01 AM To: linux-media@vger.kernel.org Cc: Aguirre, Sergio Subject: omap34xxcam question? Hi Is ok that it try only the first format and size? why does it not continue and find a matching? Actually, that was the intention, but I guess it was badly implemented. Thanks for the catch, and the contribution! Regards, Sergio @@ -470,7 +471,7 @@ static int try_pix_parm(struct omap34xxcam_videodev *vdev, pix_tmp_out = *wanted_pix_out; rval = isp_try_fmt_cap(isp, pix_tmp_in, pix_tmp_out); if (rval) - return rval; + continue; Is the patch good? or you are going to provide a better fix Yes. Sorry if I wasn't clear enough. Looks good to me, and I don't have a better fix on top of my head for the moment... I'm assuming you tested it in your environment, right? Ok, my enviroment is not pretty stable but for sure this is required. There is one problem: Suppose that the camera support this format: YUV and RAW10 The video4linux enumeration is done in this order. We know that if you want to use resizer and previewer we can't use the YUV (go straight to memory) but it is selected because is the first. So maybe the best thing is to find the one that is suggest in the csi configuration first. Hope that is clear. Michael If yes, then I'll take the patch in my queue for submission to Sakari's tree. Thanks for your time. Regards, Sergio Michael Michael -- 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 -- 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
[RFC PATCH] fix try_pix_parm loop
This patch fix try_pix_parm loop that try to find a suitable format for the isp engine Signed-off-by: Michael Trimarchi mich...@panicking.kicks-ass.org Cc: akari Ailus sakari.ai...@maxwell.research.nokia.com Cc: Sergio Aguirre saagui...@ti.com --- diff --git a/drivers/media/video/omap34xxcam.c b/drivers/media/video/omap34xxcam.c index 53b587e..bf7db71 100644 --- a/drivers/media/video/omap34xxcam.c +++ b/drivers/media/video/omap34xxcam.c @@ -470,7 +470,7 @@ static int try_pix_parm(struct omap34xxcam_videodev *vdev, pix_tmp_out = *wanted_pix_out; rval = isp_try_fmt_cap(isp, pix_tmp_in, pix_tmp_out); if (rval) -return rval; +continue; dev_dbg(vdev-vfd-dev, this w %d\th %d\tfmt %8.8x\t - w %d\th %d\t fmt %8.8x
Re: ISP OMAP3 camera support ov7690
Hi, I have done a step ahead maybe: The camera has this output format: YUYV --- the first use the CCDC_OTHERS_MEM, so seems that it needs the WEN signal to syncronize (I don't have this one) RGB565 --- is not supported RAW8 --- is supported by the ISP but seems that is not implemented as a isp formats So I can't use the first one but I can use the last one because the pipeline support RAW format, the data path is the same of RAW10 expet for the autofocus module. If all is correct what are the steps? - add the isp_format - add in the if confidition this data format and use the same path of RAW10 ... Regards Michael -- 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: ISP OMAP3 camera support ov7690
Hi all,
Aguirre, Sergio wrote:
-Original Message-
From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org]
Sent: Tuesday, January 12, 2010 7:15 AM
To: Aguirre, Sergio
Cc: Nishanth Menon; linux-o...@vger.kernel.org; linux-
me...@vger.kernel.org
Subject: Re: ISP OMAP3 camera support ov7690
Hi all,
Now I have a good camera pcb and I can test again the driver. My board is
an overo gumstix board.
Excellent!
Please let me know if you're having issues with it.
Thanks for your interest!
Regards,
Sergio
maybe I have done some mistake during writing the email, but I have asked few
things inside the email.
The camera part is ok because I have written a driver using the ov538 bridge
but I have some problem
in configuring the isp omap3 device. It opens correctly the camera, and set
xclk frequency. Then
seems that vsync and hsync are not routed to the engine because I don't receive any interrupt.
Aguirre Rodriguez, Sergio Alberto wrote:
Hi Michael,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of michael
Sent: Sunday, October 04, 2009 7:29 PM
To: Nishanth Menon
Cc: linux-o...@vger.kernel.org; linux-media@vger.kernel.org
Subject: Re: ISP OMAP3 camera support ov7690
Hi,
cc: linux-media
Nishanth Menon wrote:
michael said the following on 10/03/2009 06:13 PM:
I'm writing a driver to support the ov7690 camera and I have some
question about the meaning of:
- datalane configuration
CSI2 Data lanes - each CSI2 lane is a differential pair.
And, at least 1
clock and data lane is used in devices.
Sorry can you explain a little bit more. I have the camera
connected to the
cam_hs and cam_vs and the data is 8Bit. I use the the isp init
structure. The sccb bus works great and I can send
configuration to it,
but I don't receive any interrupt from the ics, seems that it
doen't see
the transaction:
The ISPCCDC: ###CCDC SYN_MODE=0x31704 seems ok.
static struct isp_interface_config ov7690_if_config = {
.ccdc_par_ser = ISP_CSIA,
.dataline_shift = 0x0,
.hsvs_syncdetect= ISPCTRL_SYNC_DETECT_VSFALL,
Can you try with ISPCTRL_SYNC_DETECT_VSRISE ?
.strobe = 0x0,
.prestrobe = 0x0,
.shutter= 0x0,
.wenlog = ISPCCDC_CFG_WENLOG_AND,
.wait_hs_vs = 0x4,
.raw_fmt_in = ISPCCDC_INPUT_FMT_GR_BG,
.u.csi.crc = 0x0,
.u.csi.mode = 0x0,
.u.csi.edge = 0x0,
.u.csi.signalling = 0x0,
.u.csi.strobe_clock_inv = 0x0,
.u.csi.vs_edge = 0x0,
.u.csi.channel = 0x0,
.u.csi.vpclk= 0x1,
.u.csi.data_start = 0x0,
.u.csi.data_size= 0x0,
.u.csi.format = V4L2_PIX_FMT_YUYV,
};
and I don't know the meaning of
lanecfg.clk.pol = OV7690_CSI2_CLOCK_POLARITY;
lanecfg.clk.pos = OV7690_CSI2_CLOCK_LANE;
lanecfg.data[0].pol = OV7690_CSI2_DATA0_POLARITY;
lanecfg.data[0].pos = OV7690_CSI2_DATA0_LANE;
lanecfg.data[1].pol = OV7690_CSI2_DATA1_POLARITY;
lanecfg.data[1].pos = OV7690_CSI2_DATA1_LANE;
lanecfg.data[2].pol = 0;
lanecfg.data[2].pos = 0;
lanecfg.data[3].pol = 0;
lanecfg.data[3].pos = 0;
This is the physical connection details:
- The .pol field stands for the differntial pair polarity.
(i.e. the order in which the negative and positive connections
are pugged in to the CSI2 ComplexIO module)
What exact the meaning of the pol, sorry? I have a signal that is
connected
to a pin. If the pos is avalaible can I use it?
It's not important how to route the signal but don't route on the same
lane.
Is it right?
This is the timing of the camera so I can check signal, but I don't
receive interrupt
of isp engine
The camera is direct connected to the
camera omap camera signal and using the oscilloscope I can see the hs/vs
signal
The hs is low and go up, like the vs signal. I have only one camera
with that use D0 to D7 data bit.
http://www.gumstix.net/Hardware/view/I/O-connectors-cabling/Gumstix-Overo-
27-pin-connector-J5-to-manage-camera-controls/112.html
static struct isp_interface_config ov7690_if_config = {
.ccdc_par_ser = ISP_CSIA,
.dataline_shift = 0x0,
.hsvs_syncdetect= ISPCTRL_SYNC_DETECT_VSRISE,
.strobe = 0x0,
.prestrobe = 0x0,
.shutter= 0x0,
.wenlog = ISPCCDC_CFG_WENLOG_AND,
.wait_hs_vs = 0x4,
.raw_fmt_in = ISPCCDC_INPUT_FMT_GR_BG,
.u.csi.crc = 0x0,
.u.csi.mode = 0x0,
.u.csi.edge = 0x0,
.u.csi.signalling = 0x0,
.u.csi.strobe_clock_inv = 0x0,
.u.csi.vs_edge = 0x0,
.u.csi.channel = 0x0
[RFC PATCH] Fix and invalid array indexing in isp_csi2_complexio_lanes_config
Fix and invalid array indexing when refcfg-data[i].pos is equal to 0.
The code access an invalid location.
Signed-off-by: Michael Trimarchi mich...@panicking.kicks-ass.org
cc: akari Ailus sakari.ai...@maxwell.research.nokia.com
cc: Sergio Aguirre saagui...@ti.com
---
diff --git a/drivers/media/video/isp/ispcsi2.c b/drivers/media/video/isp/ispcsi2.c
index fb0f44f..cc8fa39 100644
--- a/drivers/media/video/isp/ispcsi2.c
+++ b/drivers/media/video/isp/ispcsi2.c
@@ -85,8 +85,10 @@ int isp_csi2_complexio_lanes_config(struct isp_csi2_device *isp_csi2,
parameters for data lane #%d\n, i);
goto err_einval;
}
- if (pos_occupied[reqcfg-data[i].pos - 1]
- reqcfg-data[i].pos 0) {
+ if (!reqcfg-data[i].pos)
+ continue;
+
+ if (pos_occupied[reqcfg-data[i].pos - 1]) {
printk(KERN_ERR Lane #%d already occupied\n,
reqcfg-data[i].pos);
goto err_einval;
Re: ISP OMAP3 camera support ov7690
Hi,
Michael Trimarchi wrote:
Hi all,
Aguirre, Sergio wrote:
-Original Message-
From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org]
Sent: Tuesday, January 12, 2010 7:15 AM
To: Aguirre, Sergio
Cc: Nishanth Menon; linux-o...@vger.kernel.org; linux-
me...@vger.kernel.org
Subject: Re: ISP OMAP3 camera support ov7690
Hi all,
Now I have a good camera pcb and I can test again the driver. My
board is
an overo gumstix board.
Excellent!
Please let me know if you're having issues with it.
Thanks for your interest!
Regards,
Sergio
maybe I have done some mistake during writing the email, but I have
asked few things inside the email.
The camera part is ok because I have written a driver using the ov538
bridge but I have some problem
in configuring the isp omap3 device. It opens correctly the camera, and
set xclk frequency. Then
seems that vsync and hsync are not routed to the engine because I don't
receive any interrupt.
--- a/drivers/media/video/isp/isp.c
+++ b/drivers/media/video/isp/isp.c
@@ -299,6 +299,7 @@ static void isp_enable_interrupts(struct device *dev)
| IRQ0ENABLE_CSIA_IRQ
| IRQ0ENABLE_CSIB_IRQ | IRQ0ENABLE_HIST_DONE_IRQ
| IRQ0ENABLE_H3A_AWB_DONE_IRQ | IRQ0ENABLE_H3A_AF_DONE_IRQ
+ | IRQ0ENABLE_HS_VS_IRQ
| isp-interrupts;
if (CCDC_PREV_CAPTURE(isp))
@@ -328,6 +329,7 @@ static void isp_disable_interrupts(struct device *dev)
| IRQ0ENABLE_CSIA_IRQ
| IRQ0ENABLE_CSIB_IRQ | IRQ0ENABLE_HIST_DONE_IRQ
| IRQ0ENABLE_H3A_AWB_DONE_IRQ | IRQ0ENABLE_H3A_AF_DONE_IRQ
+ | IRQ0ENABLE_HS_VS_IRQ
| isp-interrupts);
Adding this in the irq mask give me interrupt from the camera, but I don't
undestarstand
why they are disabled. Are they disabled in the latest git code?
how can I get the vrise?
.hsvs_syncdetect= ISPCTRL_SYNC_DETECT_VSFALL,
Michael
Aguirre Rodriguez, Sergio Alberto wrote:
Hi Michael,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of michael
Sent: Sunday, October 04, 2009 7:29 PM
To: Nishanth Menon
Cc: linux-o...@vger.kernel.org; linux-media@vger.kernel.org
Subject: Re: ISP OMAP3 camera support ov7690
Hi,
cc: linux-media
Nishanth Menon wrote:
michael said the following on 10/03/2009 06:13 PM:
I'm writing a driver to support the ov7690 camera and I have some
question about the meaning of:
- datalane configuration
CSI2 Data lanes - each CSI2 lane is a differential pair.
And, at least 1
clock and data lane is used in devices.
Sorry can you explain a little bit more. I have the camera
connected to the
cam_hs and cam_vs and the data is 8Bit. I use the the isp init
structure. The sccb bus works great and I can send
configuration to it,
but I don't receive any interrupt from the ics, seems that it
doen't see
the transaction:
The ISPCCDC: ###CCDC SYN_MODE=0x31704 seems ok.
static struct isp_interface_config ov7690_if_config = {
.ccdc_par_ser = ISP_CSIA,
.dataline_shift = 0x0,
.hsvs_syncdetect= ISPCTRL_SYNC_DETECT_VSFALL,
Can you try with ISPCTRL_SYNC_DETECT_VSRISE ?
.strobe = 0x0,
.prestrobe = 0x0,
.shutter= 0x0,
.wenlog = ISPCCDC_CFG_WENLOG_AND,
.wait_hs_vs = 0x4,
.raw_fmt_in = ISPCCDC_INPUT_FMT_GR_BG,
.u.csi.crc = 0x0,
.u.csi.mode = 0x0,
.u.csi.edge = 0x0,
.u.csi.signalling = 0x0,
.u.csi.strobe_clock_inv = 0x0,
.u.csi.vs_edge = 0x0,
.u.csi.channel = 0x0,
.u.csi.vpclk= 0x1,
.u.csi.data_start = 0x0,
.u.csi.data_size= 0x0,
.u.csi.format = V4L2_PIX_FMT_YUYV,
};
and I don't know the meaning of
lanecfg.clk.pol = OV7690_CSI2_CLOCK_POLARITY;
lanecfg.clk.pos = OV7690_CSI2_CLOCK_LANE;
lanecfg.data[0].pol = OV7690_CSI2_DATA0_POLARITY;
lanecfg.data[0].pos = OV7690_CSI2_DATA0_LANE;
lanecfg.data[1].pol = OV7690_CSI2_DATA1_POLARITY;
lanecfg.data[1].pos = OV7690_CSI2_DATA1_LANE;
lanecfg.data[2].pol = 0;
lanecfg.data[2].pos = 0;
lanecfg.data[3].pol = 0;
lanecfg.data[3].pos = 0;
This is the physical connection details:
- The .pol field stands for the differntial pair polarity.
(i.e. the order in which the negative and positive connections
are pugged in to the CSI2 ComplexIO module)
What exact the meaning of the pol, sorry? I have a signal that is
connected
to a pin. If the pos is avalaible can I use it?
It's not important how to route the signal but don't route on the same
lane.
Is it right?
This is the timing of the camera so I can check signal, but I don't
receive interrupt
of isp engine
The camera is direct connected to the
camera omap camera signal and using
Re: USB MAssage Storage drivers
Hi, Gopala Gottumukkala wrote: (gcc version 3.4.3 (MontaVista 3.4.3-25.0.104.0600975 2006-07-06)) #4 PREEMPT Tue Dec 15 18:10:24 EST 2009 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 CPU: VIVT data cache, VIVT instruction cache Machine: DaVinci DM644x EVM Memory policy: ECC disabled, Data cache writeback DaVinci dm6446 variant 0x0 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 50800 I have compile the kernel 2.6.32 and boot up the target. But when I plug in the mass storage like external HDD or Pendrive it is not recognizing. Do you compile the usb support? Do you have in your config? Michael Any help appreciated. - GG -Original Message- From: Philby John [mailto:pj...@in.mvista.com] Sent: Wednesday, December 16, 2009 2:22 AM To: Gopala Gottumukkala Cc: davinci-linux-open-sou...@linux.davincidsp.com; linux-media@vger.kernel.org Subject: Re: USB MAssage Storage drivers On Tue, 2009-12-15 at 18:46 -0500, Gopala Gottumukkala wrote: My target is not recognizing the USB massage storage. I am working the 2.6.32 Davinci kernel Any suggestion and ideas. ahah, this information isn't enough. Your Vendor/Product ID for this device is compared in a lookup a table. If no match is found, your device probably won't be detected as mass storage. You could check in the unusual_devs.h to see if your device is included there, if your device is relatively new you could submit a Vendor/Product ID to the USB dev list for inclusion. Regards, Philby -- 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: flicker/jumpy at the bottom of the video
Purushottam R S wrote: Hi , I am using latest gspca driver from dvb for camera driver. But I see bottom of the video has flickering/jumping effect. I have Zippys web camera, which is from Z-Star. I have loaded the following drivers. 1. gspca_zc3xx 44832 0 - Live 0xbf01f000 2. gspca_main 23840 1 gspca_zc3xx, Live 0xbf014000 3. videodev 36672 1 gspca_main, Live 0xbf006000 4. v4l1_compat 14788 1 videodev, Live 0xbf00 But otherwise there is no issue with video. I tested using gst-launch pipeline. Can you try using vlc application. I have the same effect using v4l1 compat api Michael regards Purush The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/ -- 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: [RFC, PATCH] gspca: implement vidioc_enum_frameintervals
Hans de Goede wrote: Hi, On 11/17/2009 11:41 AM, Antonio Ospite wrote: Hi, gspca does not implement vidioc_enum_frameintervals yet, so even if a camera can support multiple frame rates (or frame intervals) there is still no way to enumerate them from userspace. The following is just a quick and dirty implementation to show the problem and to have something to base the discussion on. In the patch there is also a working example of use with the ov534 subdriver. Someone with a better knowledge of gspca and v4l internals can suggest better solutions. Does the ov534 driver actually support selecting a framerate from the list this patch adds, and does it then honor the selection ? The ov534 is a bridge for different sensor like ov538 so it support different frame rate, depends on the sensor too. Michael -- 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: [RFC, PATCH] gspca: implement vidioc_enum_frameintervals
Hi,
Antonio Ospite wrote:
Hi,
gspca does not implement vidioc_enum_frameintervals yet, so even if a
camera can support multiple frame rates (or frame intervals) there is
still no way to enumerate them from userspace.
The following is just a quick and dirty implementation to show the
problem and to have something to base the discussion on. In the patch
there is also a working example of use with the ov534 subdriver.
Someone with a better knowledge of gspca and v4l internals can suggest
better solutions.
The tests has been done using 'luvcview -L', the output before the
patch:
$ luvcview -d /dev/video1 -L
luvcview 0.2.6
SDL information:
Video driver: x11
A window manager is available
Device information:
Device path: /dev/video1
{ pixelformat = 'YUYV', description = 'YUYV' }
{ discrete: width = 320, height = 240 }
Time interval between frame:
1/40, 1/30, { discrete: width = 640, height = 480 }
Time interval between frame:
And the output after it:
$ luvcview -d /dev/video1 -L
luvcview 0.2.6
SDL information:
Video driver: x11
A window manager is available
Device information:
Device path: /dev/video1
{ pixelformat = 'YUYV', description = 'YUYV' }
{ discrete: width = 320, height = 240 }
Time interval between frame: 1/125, 1/100, 1/75, 1/60, 1/50, 1/40,
1/30,
{ discrete: width = 640, height = 480 }
Time interval between frame: 1/60, 1/50, 1/40, 1/30, 1/15,
Thanks,
Antonio
diff -r 182b5f8fa160 linux/drivers/media/video/gspca/gspca.c
--- a/linux/drivers/media/video/gspca/gspca.c Sun Nov 15 10:05:30 2009 +0100
+++ b/linux/drivers/media/video/gspca/gspca.c Tue Nov 17 11:39:21 2009 +0100
@@ -995,6 +995,37 @@
return -EINVAL;
}
+static int vidioc_enum_frameintervals(struct file *filp, void *priv,
+ struct v4l2_frmivalenum *fival)
+{
+ struct gspca_dev *gspca_dev = priv;
+ int mode = wxh_to_mode(gspca_dev, fival-width, fival-height);
+ int i;
+ __u32 index = 0;
+
+ if (gspca_dev-cam.mode_framerates == NULL ||
+ gspca_dev-cam.mode_framerates[mode].nrates == 0)
+ return -EINVAL;
+
+ /* FIXME: Needed? */
+ if (fival-pixel_format !=
+ gspca_dev-cam.cam_mode[mode].pixelformat)
+ return -EINVAL;
+
+ for (i = 0; i gspca_dev-cam.mode_framerates[mode].nrates; i++) {
+ if (fival-index == index) {
+ fival-type = V4L2_FRMSIZE_TYPE_DISCRETE;
+ fival-discrete.numerator = 1;
+ fival-discrete.denominator =
+ gspca_dev-cam.mode_framerates[mode].rates[i];
+ return 0;
+ }
+ index++;
+ }
+
+ return -EINVAL;
+}
+
static void gspca_release(struct video_device *vfd)
{
struct gspca_dev *gspca_dev = container_of(vfd, struct gspca_dev, vdev);
@@ -1987,6 +2018,7 @@
.vidioc_g_parm = vidioc_g_parm,
.vidioc_s_parm = vidioc_s_parm,
.vidioc_enum_framesizes = vidioc_enum_framesizes,
+ .vidioc_enum_frameintervals = vidioc_enum_frameintervals,
#ifdef CONFIG_VIDEO_ADV_DEBUG
.vidioc_g_register = vidioc_g_register,
.vidioc_s_register = vidioc_s_register,
diff -r 182b5f8fa160 linux/drivers/media/video/gspca/gspca.h
--- a/linux/drivers/media/video/gspca/gspca.h Sun Nov 15 10:05:30 2009 +0100
+++ b/linux/drivers/media/video/gspca/gspca.h Tue Nov 17 11:39:21 2009 +0100
@@ -45,11 +45,17 @@
/* image transfers */
#define MAX_NURBS 4/* max number of URBs */
+struct framerates {
+ int *rates;
+ int nrates;
+};
+
/* device information - set at probe time */
struct cam {
int bulk_size; /* buffer size when image transfer by bulk */
const struct v4l2_pix_format *cam_mode; /* size nmodes */
char nmodes;
+ const struct framerates *mode_framerates; /* size nmode, like cam_mode
*/
__u8 bulk_nurbs;/* number of URBs in bulk mode
* - cannot be MAX_NURBS
* - when 0 and bulk_size != 0 means
I think that the best thing is to slip in two patches. One is related to the
gspa main
and the other is a change on a driver.
diff -r 182b5f8fa160 linux/drivers/media/video/gspca/ov534.c
--- a/linux/drivers/media/video/gspca/ov534.c Sun Nov 15 10:05:30 2009 +0100
+++ b/linux/drivers/media/video/gspca/ov534.c Tue Nov 17 11:39:21 2009 +0100
@@ -287,6 +287,20 @@
.priv = 0},
};
+static int qvga_rates[] = {125, 100, 75, 60, 50, 40, 30};
+static int vga_rates[] = {60, 50, 40, 30, 15};
+
+static const struct framerates ov772x_framerates[] = {
+ { /* 320x240 */
+ .rates = qvga_rates,
+ .nrates = ARRAY_SIZE(qvga_rates),
Re: ov538-ov7690
Mauro Carvalho Chehab wrote: Em Tue, 10 Nov 2009 09:09:10 -0800 Randy Dunlap rdun...@xenotime.net escreveu: (**) This is also one of several codes that different kinds of host controller use to indicate a transfer has failed because of device disconnect. In the interval before the hub driver starts disconnect processing, devices may receive such fault reports for every request. Ok, this is not a big issue because I can use vlc to test the camera. But anybody knows why camorama, camstream, cheese crash during test. is it driver depend? or not? Could be driver. Easily could be a device problem too. I think that it can be a vl2 vl1 problem. Because now I can manage in skype too using the v4l1-compat library. Maybe my 2.6.32-rc5 is too new :( I don't even know what vl2 vl1 means. ;) He is probably referring to V4L1 x V4L2 API calls. Very unlikely. What libv4l Yes does is to convert userspace calls via V4L1 to a V4L2 call to kernel. So, you're basically using the same API to communicate to userspace. Ugly but very usefull in such application like skype, and people want it :( It should be noticed that, if you're not using libv4l for the other applications, then you may be using a different format at the driver, since libv4l has the capability of doing format conversions. So, it could be possible that the device firmware for some formats are broken. Another possibility is that maybe libv4l is just discarding such errors. Or, as Randy mentioned, it can be just a cable or a connector with bad contact. Change the connector fix the packet problem. So at least the version ov538-ov7690 seems ok. Thanks -- 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: ov538-ov7690
Hi, Michael Trimarchi wrote: Hi all I'm working on the ov538 bridge with the ov7690 camera connected. Somentimes I receive [ 1268.146705] gspca: ISOC data error: [110] len=1020, status=-71 [ 1270.946739] gspca: ISOC data error: [114] len=1020, status=-71 [ 1271.426689] gspca: ISOC data error: [82] len=1020, status=-71 [ 1273.314640] gspca: ISOC data error: [1] len=1020, status=-71 [ 1274.114661] gspca: ISOC data error: [17] len=1020, status=-71 [ 1274.658718] gspca: ISOC data error: [125] len=1020, status=-71 [ 1274.834666] gspca: ISOC data error: [21] len=1020, status=-71 [ 1275.84] gspca: ISOC data error: [94] len=1020, status=-71 [ 1275.826645] gspca: ISOC data error: [40] len=1020, status=-71 [ 1276.226721] gspca: ISOC data error: [100] len=1020, status=-71 This error from the usb, how are they related to the camera? Ok, this is not a big issue because I can use vlc to test the camera. But anybody knows why camorama, camstream, cheese crash during test. is it driver depend? or not? Michael Michael -- 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: ov538-ov7690
Hi, Randy Dunlap wrote: On Tue, 10 Nov 2009 11:18:13 +0100 Michael Trimarchi wrote: Hi, Michael Trimarchi wrote: Hi all I'm working on the ov538 bridge with the ov7690 camera connected. Somentimes I receive [ 1268.146705] gspca: ISOC data error: [110] len=1020, status=-71 [ 1270.946739] gspca: ISOC data error: [114] len=1020, status=-71 [ 1271.426689] gspca: ISOC data error: [82] len=1020, status=-71 [ 1273.314640] gspca: ISOC data error: [1] len=1020, status=-71 [ 1274.114661] gspca: ISOC data error: [17] len=1020, status=-71 [ 1274.658718] gspca: ISOC data error: [125] len=1020, status=-71 [ 1274.834666] gspca: ISOC data error: [21] len=1020, status=-71 [ 1275.84] gspca: ISOC data error: [94] len=1020, status=-71 [ 1275.826645] gspca: ISOC data error: [40] len=1020, status=-71 [ 1276.226721] gspca: ISOC data error: [100] len=1020, status=-71 This error from the usb, how are they related to the camera? -71 = -EPROTO (from include/asm-generic/errno.h). -EPROTO in USB drivers means (from Documentation/usb/error-codes.txt): -EPROTO (*, **) a) bitstuff error b) no response packet received within the prescribed bus turn-around time c) unknown USB error footnotes: (*) Error codes like -EPROTO, -EILSEQ and -EOVERFLOW normally indicate hardware problems such as bad devices (including firmware) or cables. OK, but it's a failure of the ehci transaction on my laptop and seems that is not so frequent. I think that can be a cable problem. (**) This is also one of several codes that different kinds of host controller use to indicate a transfer has failed because of device disconnect. In the interval before the hub driver starts disconnect processing, devices may receive such fault reports for every request. Ok, this is not a big issue because I can use vlc to test the camera. But anybody knows why camorama, camstream, cheese crash during test. is it driver depend? or not? Could be driver. Easily could be a device problem too. I think that it can be a vl2 vl1 problem. Because now I can manage in skype too using the v4l1-compat library. Maybe my 2.6.32-rc5 is too new :( Michael --- ~Randy -- 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
ov538-ov7690
Hi all I'm working on the ov538 bridge with the ov7690 camera connected. Somentimes I receive [ 1268.146705] gspca: ISOC data error: [110] len=1020, status=-71 [ 1270.946739] gspca: ISOC data error: [114] len=1020, status=-71 [ 1271.426689] gspca: ISOC data error: [82] len=1020, status=-71 [ 1273.314640] gspca: ISOC data error: [1] len=1020, status=-71 [ 1274.114661] gspca: ISOC data error: [17] len=1020, status=-71 [ 1274.658718] gspca: ISOC data error: [125] len=1020, status=-71 [ 1274.834666] gspca: ISOC data error: [21] len=1020, status=-71 [ 1275.84] gspca: ISOC data error: [94] len=1020, status=-71 [ 1275.826645] gspca: ISOC data error: [40] len=1020, status=-71 [ 1276.226721] gspca: ISOC data error: [100] len=1020, status=-71 This error from the usb, how are they related to the camera? Michael -- 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
