tm6000
Hi Who is maintainer of the tm6000 module?? With my best regards, Dmitry. -- 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: Problem with gspca and zc3xx
Hi All, On 01/11/2010 10:55 AM, Jean-Francois Moine wrote: On Mon, 11 Jan 2010 09:37:29 +0100 Hans de Goedehdego...@redhat.com wrote: This is the infamous zc3xx bottom of the image is missing in 320x240 problem, with several sensors the register settings we took from the windows driver will only give you 320x232 (iirc), we tried changing them to get 320x240, but then the camera would not stream. Most likely some timing issue between bridge and sensor. I once had a patch fixing this by actually reporting the broken modes as 320x232, but that never got applied as it breaks app which are hardcoded to ask for 320x240. libv4l has had the ability to extend the 320x232 image to 320x240 for a while now (by adding a few black lines at the top + bottom), fixing the hardcoded apps problem. So I think such a patch can and should be applied now. This will get rid of the jpeg decompression errors reported by libv4l and in case if yuv mode the ugly green bar with some random noise in it at the bottom. I'm afraid my patch is most likely lost, but I can create a new one if you want, I have access to quite a few zc3xx camera's, and more over what resolution they are actually streaming at can be deducted from the register settings in the driver. Hi Hans, As you may see in Jose Alberto's message, the problem occurs with 640x480 and, yes, the image bottom is lacking, but also the right side. Hmm, the right side missing would indicate some timing issue between sensor and bridge, but it seems this is an intermittent problem, as in Jose's last message only the last 8 lines are missing. As for this happening also at 640x480, I re-checked things and that is the same problem, here is a table of the resolutions per sensor, derived from the register settings in zc3xx.c, iow this are the resolutions we are telling the bridge to send us! adcm2700640x472 320x232 cs2102 640x480 320x240 cs2102k 640x480 320x240 gc0305 640x480 320x240 hdcs2020xb 640x480 320x240 hv7131bxx 640x480 320x240 hv7131cxx 640x480 320x240 icm105axx 640x480 320x240 MC501CB 640x472 320x232 OV7620 640x472 320x232 ov7630c 640x480 320x240 pas202b 640x480 320x232 mi0360soc 640x480 320x240 pb0330 640x480 320x240 PO2030 640x480 320x240 tas5130CK 640x480 320x240 tas5130cxx 640x480 320x240 tas5130c_vf0250 640x480 320x240 I did not lose your patch, but I did not apply it because most of the time, the webcams work in the best resolution (VGA) and the associated problem has not found yet a good resolution... It turns out I was wrong, and the problem happens for 3 of the 4 affected sensors at both VGA and QVGA. What we are currently doing is telling the bridge to send us these resolutions, and then telling userspace it is getting something different. This is just plain wrong, no but ..., it is just *wrong*. This makes for users getting an image out of the cam like Jose is getting with the last 8 lines garbled. And when they start their webcam application from a terminal the terminal fills with: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: ffec libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: ffd9 libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: libv4lconvert: Error decompressing JPEG: unknown huffman code: Which is because libv4l expects there to be more data then it actually is getting, as we are *lying* to it. I know ideally we would change the register settings to actually get 640x480 and 320x240, but that won't work when you do that the camera's with the affected sensors won't stream at all, that is I've tried fiddling with the register settings for a pas202b
[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
Hi Mauro, I added an important bug fix. Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb for the following 12 changesets: 01/12: gspca - ov534/ov534_9: Split the ov534 subdriver. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=b3b5fdea85f9 02/12: gspca - zc3xx: Cleanup code. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=88b763c4059e 03/12: gspca - zc3xx: Rename the USB sequences. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=2f95fe18d345 04/12: gspca - zc3xx: Fix hdcs2020 probe. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=5fa0a60e8b87 05/12: gspca - zc3xx: Let default sharpness for sensor pas202b. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=7135f9402c0d 06/12: gspca - zc3xx: Remove unuseful register write. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=6d982f8d5472 07/12: gspca - zc3xx: Switch off the LED on resume. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=be00fd76345f 08/12: gspca - zc3xx: Simplify code. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=e57ed5ad2d90 09/12: gspca - sunplus: Optimize and remove unused sequences. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=40901861f5d0 10/12: gspca - main: Change the check of the USB video interface. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=09a30227151c 11/12: gspca - pac7302: Fix a random USB error. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=ea88b3abee04 12/12: gspca - sonixj: Fix bad video mode for all webcams. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=a38bcee4174a b/linux/drivers/media/video/gspca/ov534_9.c | 1477 linux/Documentation/video4linux/gspca.txt |3 linux/drivers/media/video/gspca/Kconfig | 16 linux/drivers/media/video/gspca/Makefile|2 linux/drivers/media/video/gspca/gspca.c |9 linux/drivers/media/video/gspca/ov534.c | 1242 +-- linux/drivers/media/video/gspca/pac7302.c |2 linux/drivers/media/video/gspca/sonixj.c|6 linux/drivers/media/video/gspca/sunplus.c | 63 - linux/drivers/media/video/gspca/zc3xx.c | 352 +++--- 10 files changed, 1790 insertions(+), 1382 deletions(-) Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: [PATCH 1/1] media: video/cx18, fix potential null dereference
On 01/12/2010 12:48 AM, Andy Walls wrote: On Sun, 2010-01-10 at 09:56 +0100, Jiri Slaby wrote: Stanse found a potential null dereference in cx18_dvb_start_feed and cx18_dvb_stop_feed. There is a check for stream being NULL, but it is dereferenced earlier. Move the dereference after the check. Signed-off-by: Jiri Slaby jsl...@suse.cz Reviewed-by: Andy Walls awa...@radix.net Acked-by: Andy Walls awa...@radix.net You definitely know the code better, have you checked that it can happen at all? I mean may demux-priv be NULL? -- 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: tm6000
Dmitri Belimov wrote: Hi Who is maintainer of the tm6000 module?? With my best regards, Dmitry. I wrote it, although I'm currently lacking time to fix the bugs. Feel free to fix if you want. I have some boards here and I can help testing on them. Cheers, Mauro. -- 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: Problem with gspca and zc3xx
Hi, On 01/12/2010 09:36 AM, Jean-Francois Moine wrote: On Mon, 11 Jan 2010 15:49:55 +0100 Jose Alberto Reguerojaregu...@telefonica.net wrote: I take another image with 640x480 and the bad bottom lines are 8. The right side look right this time. The good sizes are: 320x240-320x232 640x480-640x472 Hi Jose Alberto and Hans, Hans, I modified a bit your patch to handle the 2 resolutions (also, the problem with pas202b does not exist anymore). May you sign or ack it? Thanks! It seems our mails crossed each other, you are right the pas202b 320x240 issue (the pas202b is a cam I have, and it only had the issue at 320x240, hence the incompleteness of my patch) is fixed in your tree, excellent! The patch is: Signed-off-by: Hans de Goede hdego...@redhat.com Regards, Hans -- 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: [PATCH - v4 1/4] V4L-vpfe_capture-remove-clock and platform code
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Monday, January 11, 2010 7:17 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; mche...@infradead.org; hverk...@xs4all.nl;
davinci-linux-open-sou...@linux.davincidsp.com
Subject: Re: [PATCH - v4 1/4] V4L-vpfe_capture-remove-clock and platform
code
m-kariche...@ti.com writes:
From: Muralidharan Karicheri m-kariche...@ti.com
This combines the two patches sent earlier to change the clock
configuration
and converting ccdc drivers to platform drivers. This has updated
comments
against v1 of these patches.
This part is also not relevant to the git history, and should be after the
'---'
In this patch, the clock configuration is moved to ccdc driver since
clocks
are configured for ccdc. Also adding proper error codes for ccdc register
function and removing the ccdc memory resource handling.
Also, this doesn't accuratly reflect the changes done in the patch.
Here the clock configuration isn't moved, it's removed. You should
mention it being removed here and added to platform-specific code in
subsequent patches.
Sorry to be so nit-picky about the comments, but having a well-written
and descriptive changelog is extremely importanty. For the benefit of
reading the git history later, and also for those of us less familiar
with the details of these drivers, we rely heavily on a good changelog.
[MK] I think you are being too picky on these comments :( Besides this was
gone through several reviews and I was wondering why you chose to ignore these
comments earlier. It was now being sent for merge, not for review.
This is really not helping the upstream merge :(
Anyways, I will make these changes and send again.
Kevin
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Rebased to latest linux-next tree
Applies to linux-next tree of v4l-dvb
drivers/media/video/davinci/vpfe_capture.c | 131 +++---
--
1 files changed, 13 insertions(+), 118 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index de22bc9..885cd54 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -107,9 +107,6 @@ struct ccdc_config {
int vpfe_probed;
/* name of ccdc device */
char name[32];
-/* for storing mem maps for CCDC */
-int ccdc_addr_size;
-void *__iomem ccdc_addr;
};
/* data structures */
@@ -229,7 +226,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
BUG_ON(!dev-hw_ops.set_image_window);
BUG_ON(!dev-hw_ops.get_image_window);
BUG_ON(!dev-hw_ops.get_line_length);
-BUG_ON(!dev-hw_ops.setfbaddr);
BUG_ON(!dev-hw_ops.getfid);
mutex_lock(ccdc_lock);
@@ -240,25 +236,23 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
* walk through it during vpfe probe
*/
printk(KERN_ERR vpfe capture not initialized\n);
-ret = -1;
+ret = -EFAULT;
goto unlock;
}
if (strcmp(dev-name, ccdc_cfg-name)) {
/* ignore this ccdc */
-ret = -1;
+ret = -EINVAL;
goto unlock;
}
if (ccdc_dev) {
printk(KERN_ERR ccdc already registered\n);
-ret = -1;
+ret = -EINVAL;
goto unlock;
}
ccdc_dev = dev;
-dev-hw_ops.set_ccdc_base(ccdc_cfg-ccdc_addr,
- ccdc_cfg-ccdc_addr_size);
unlock:
mutex_unlock(ccdc_lock);
return ret;
@@ -1786,61 +1780,6 @@ static struct vpfe_device *vpfe_initialize(void)
return vpfe_dev;
}
-static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
-{
-struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-
-clk_disable(vpfe_cfg-vpssclk);
-clk_put(vpfe_cfg-vpssclk);
-clk_disable(vpfe_cfg-slaveclk);
-clk_put(vpfe_cfg-slaveclk);
-v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master slave clocks disabled\n);
-}
-
-static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
-{
-struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-int ret = -ENOENT;
-
-vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
-if (NULL == vpfe_cfg-vpssclk) {
-v4l2_err(vpfe_dev-pdev-driver, No clock defined for
- vpss_master\n);
-return ret;
-}
-
-if (clk_enable(vpfe_cfg-vpssclk)) {
-v4l2_err(vpfe_dev-pdev-driver,
-vpfe vpss master clock not enabled\n);
-
Re: Problem with gspca and zc3xx
El Martes, 12 de Enero de 2010, Jean-Francois Moine escribió: On Mon, 11 Jan 2010 15:49:55 +0100 Jose Alberto Reguero jaregu...@telefonica.net wrote: I take another image with 640x480 and the bad bottom lines are 8. The right side look right this time. The good sizes are: 320x240-320x232 640x480-640x472 Hi Jose Alberto and Hans, Hans, I modified a bit your patch to handle the 2 resolutions (also, the problem with pas202b does not exist anymore). May you sign or ack it? Jose Alberto, the attached patch is to be applied to the last version of the gspca in my test repository at LinuxTv.org http://linuxtv.org/hg/~jfrancois/gspca May you try it? Regards. The patch works well. There is another problem. When autogain is on(default), the image is bad. It is possible to put autogain off by default? Thanks. Jose Alberto -- 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: [PATCH - v4 1/4] V4L-vpfe_capture-remove-clock and platform code
Karicheri, Muralidharan m-kariche...@ti.com writes: [...] Also, this doesn't accuratly reflect the changes done in the patch. Here the clock configuration isn't moved, it's removed. You should mention it being removed here and added to platform-specific code in subsequent patches. Sorry to be so nit-picky about the comments, but having a well-written and descriptive changelog is extremely importanty. For the benefit of reading the git history later, and also for those of us less familiar with the details of these drivers, we rely heavily on a good changelog. [MK] I think you are being too picky on these comments :( Part of my role is to be picky. ;) Besides this was gone through several reviews and I was wondering why you chose to ignore these comments earlier. It was now being sent for merge, not for review. I did not do a detailed review in the earlier versions because I was leaving this to be thoroughly reviewed by linux-media folks. However, with all the clock issues, I decided to give it a more thorough review, and I found the changelogs to not be helpful in understanding the patches. The linux-media maintainers are certainly free to merge the stuff with the current confusing changelog, but I would not recommend it. This is really not helping the upstream merge :( Well, it may be taking a bit longer, but it is helping the quality of the changes that are eventually merged upstream. Anyways, I will make these changes and send again. Thanks, Kevin -- 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
-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
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,
.u.csi.vpclk= 0x1,
.u.csi.data_start = 0x0,
.u.csi.data_size= 0x0,
.u.csi.format = V4L2_PIX_FMT_YUYV,
};
This is my initial configuration
#define OV7690_CSI2_CLOCK_POLARITY 0
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,
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: OK
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Jan 12 19:00:02 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13915:82bbb3bd0f0a gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-armv5: OK linux-2.6.33-rc2-armv5: OK linux-2.6.32-armv5-davinci: OK linux-2.6.33-rc2-armv5-davinci: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-armv5-ixp: OK linux-2.6.33-rc2-armv5-ixp: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-armv5-omap2: OK linux-2.6.33-rc2-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: OK linux-2.6.31-i686: WARNINGS linux-2.6.32-i686: WARNINGS linux-2.6.33-rc2-i686: ERRORS linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.33-rc2-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-mips: OK linux-2.6.33-rc2-mips: OK linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: OK linux-2.6.32-powerpc64: WARNINGS linux-2.6.33-rc2-powerpc64: ERRORS linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: OK linux-2.6.31-x86_64: WARNINGS linux-2.6.32-x86_64: WARNINGS linux-2.6.33-rc2-x86_64: ERRORS spec: OK sparse (linux-2.6.32): ERRORS sparse (linux-2.6.33-rc2): ERRORS linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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 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 the
dvb/bt8xx/dst.c
Hi Manu, I have submitted a patch for dst.c on 9 Jan 11:46 to linux-media but have not had any response from anybody since. Should I have sent the patch directly to you, as you are one the original authors of the code (assuming that there is only one Manu Abraham), or is there anything else I should do? Thanks, Klaas. -- 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
VL4-DVB compilation issue not covered by Daily Automated
Dear all, as suggested by http://www.linuxtv.org/wiki/index.php/Bug_Report I report several warnings and errors not yet covered in latest http://www.xs4all.nl/~hverkuil/logs/Monday.log I get when compiling. (The purpose of my experiments was trying to find out something about 0ccd:00a5 TerraTec Electronic GmbH) Regards Hagen $ uname -a Linux hagen-shuttle 2.6.31-15-generic #50-Ubuntu SMP Tue Nov 10 14:53:52 UTC 2009 x86_64 GNU/Linux $ sudo apt-get install mercurial linux-headers-$(uname -r) build-essential $ hg clone http://linuxtv.org/hg/v4l-dvb $ cd v4l-dvb/ $ make snip CC [M] /v4l-dvb/v4l/et61x251_core.o /v4l-dvb/v4l/et61x251_core.c: In function 'et61x251_ioctl_v4l2': /v4l-dvb/v4l/et61x251_core.c:2500: warning: the frame size of 1408 bytes is larger than 1024 bytes CC [M] /v4l-dvb/v4l/et61x251_tas5130d1b.o CC [M] /v4l-dvb/v4l/firedtv-avc.o CC [M] /v4l-dvb/v4l/firedtv-ci.o CC [M] /v4l-dvb/v4l/firedtv-dvb.o CC [M] /v4l-dvb/v4l/firedtv-fe.o CC [M] /v4l-dvb/v4l/firedtv-1394.o /v4l-dvb/v4l/firedtv-1394.c:21:17: error: dma.h: No such file or directory/v4l-dvb/v4l/firedtv-1394.c:22:21: error: csr1212.h: No such file or directory /v4l-dvb/v4l/firedtv-1394.c:23:23: error: highlevel.h: No such file or directory /v4l-dvb/v4l/firedtv-1394.c:24:19: error: hosts.h: No such file or directory /v4l-dvb/v4l/firedtv-1394.c:25:22: error: ieee1394.h: No such file or directory /v4l-dvb/v4l/firedtv-1394.c:26:17: error: iso.h: No such file or directory /v4l-dvb/v4l/firedtv-1394.c:27:21: error: nodemgr.h: No such file or directory/v4l-dvb/v4l/firedtv-1394.c:40: warning: 'struct hpsb_iso' declared inside parameter list /v4l-dvb/v4l/firedtv-1394.c:40: warning: its scope is only this definition or declaration, which is probably not what you want /v4l-dvb/v4l/firedtv-1394.c: In function 'rawiso_activity_cb': /v4l-dvb/v4l/firedtv-1394.c:56: error: dereferencing pointer to incomplete type /v4l-dvb/v4l/firedtv-1394.c:57: error: implicit declaration of function 'hpsb_iso_n_ready' /v4l-dvb/v4l/firedtv-1394.c:64: error: dereferencing pointer to incomplete type /v4l-dvb/v4l/firedtv-1394.c:65: error: implicit declaration of function 'dma_region_i' /v4l-dvb/v4l/firedtv-1394.c:65: error: dereferencing pointer to incomplete type /v4l-dvb/v4l/firedtv-1394.c:65: error: expected expression before 'unsigned' /v4l-dvb/v4l/firedtv-1394.c:66: warning: assignment makes pointer from integer without a cast /v4l-dvb/v4l/firedtv-1394.c:67: error: dereferencing pointer to incomplete type /v4l-dvb/v4l/firedtv-1394.c:71: error: dereferencing pointer to incomplete type /v4l-dvb/v4l/firedtv-1394.c:85: error: implicit declaration of function 'hpsb_iso_recv_release_packets' /v4l-dvb/v4l/firedtv-1394.c: In function 'node_of': /v4l-dvb/v4l/firedtv-1394.c:90: error: dereferencing pointer to incomplete type /v4l-dvb/v4l/firedtv-1394.c:90: warning: type defaults to 'int' in declaration of '__mptr' /v4l-dvb/v4l/firedtv-1394.c:90: warning: initialization from incompatible pointer type /v4l-dvb/v4l/firedtv-1394.c:90: error: invalid use of undefined type 'struct unit_directory' /v4l-dvb/v4l/firedtv-1394.c: In function 'node_lock': /v4l-dvb/v4l/firedtv-1394.c:97: error: implicit declaration of function 'hpsb_node_lock' /v4l-dvb/v4l/firedtv-1394.c:97: error: 'EXTCODE_COMPARE_SWAP' undeclared (first use in this function) /v4l-dvb/v4l/firedtv-1394.c:97: error: (Each undeclared identifier is reported only once /v4l-dvb/v4l/firedtv-1394.c:97: error: for each function it appears in.)
Re: VL4-DVB compilation issue not covered by Daily Automated
On Tue, Jan 12, 2010 at 4:26 PM, Hagen von Eitzen ha...@von-eitzen.de wrote: Dear all, as suggested by http://www.linuxtv.org/wiki/index.php/Bug_Report I report several warnings and errors not yet covered in latest http://www.xs4all.nl/~hverkuil/logs/Monday.log I get when compiling. (The purpose of my experiments was trying to find out something about 0ccd:00a5 TerraTec Electronic GmbH) Regards Hagen This is an Ubuntu-specific issue (they improperly packaged their kernel headers), which will not be covered by the daily build system (which exercises various kernels but not across different Linux distribution versions). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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
Re: dvb/bt8xx/dst.c
Hi Klaas, On Wed, Jan 13, 2010 at 1:35 AM, klaas de waal klaas.de.w...@gmail.com wrote: Hi Manu, I have submitted a patch for dst.c on 9 Jan 11:46 to linux-media but have not had any response from anybody since. Should I have sent the patch directly to you, as you are one the original authors of the code (assuming that there is only one Manu Abraham), or is there anything else I should do? Somehow, I missed that post. Saw it now though. I will test it and pull it into my tree. Thanks, Manu -- 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
Michael,
-Original Message-
From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org]
Sent: Tuesday, January 12, 2010 3:28 PM
To: Aguirre, Sergio
Cc: Nishanth Menon; linux-o...@vger.kernel.org; linux-
me...@vger.kernel.org
Subject: 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?
In the past, we used to rely on HS_VS for signaling when to do some actions,
like enable ISP preview sub-module, and also had VD0 and VD1 programmable
interrupts to do other actions.
Nowadays, the usage has changed. We don't really use HS_VS anymore. And we rely
mainly on VD0 (generated based on CCDC input) for doing many interframe
operations (like targeting for next buffer in the queue, and updating some
other settings.)
In conclusion, we disabled HS_VS, because we don't use it anymore.
how can I get the vrise?
.hsvs_syncdetect= ISPCTRL_SYNC_DETECT_VSFALL,
.hsvs_syncdetect= ISPCTRL_SYNC_DETECT_VSRISE,
I'm interested in seeing your board file in which you configure interface from
sensor to ISP. (See arch/arm/mach-omap2/board-zoom-camera.c for how I use it)
Regards,
Sergio
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
Re: WinTV Radio rev-c121 remote support
On Mon, 11 Jan 2010 20:24:51 +0100, Samuel Rakitnican
samuel.rakitni...@gmail.com wrote:
On Fri, 08 Jan 2010 13:59:14 +0100, Samuel Rakitnican
samuel.rakitni...@gmail.com wrote:
On Tue, 05 Jan 2010 21:11:59 +0100, Samuel Rakitničan
samuel.rakitni...@gmail.com wrote:
Hi,
I have an old bt878 based analog card. It's 'Hauppauge WinTV Radio'
model 44914,
rev C121.
I'm trying to workout support for this shipped remote control. I have
[...]
Card: http://linuxtv.org/wiki/index.php/File:Wintv-radio-C121.jpg
Remote: http://linuxtv.org/wiki/index.php/File:Wintv-radio-remote.jpg
Did some investigation, maybe this can help to clarify some things.
Still didn't get any response in dmesg from remote.
[...]
i2c_scan:
bttv0: i2c scan: found device @ 0x30 [IR (hauppauge)]
bttv0: i2c scan: found device @ 0xa0 [eeprom]
bttv0: i2c scan: found device @ 0xc2 [tuner (analog)]
[...]
modprobe ir-kbd-i2c debug=1
ir-kbd-i2c: probe 0x1a @ bt878 #0 [sw]: no
ir-kbd-i2c: probe 0x18 @ bt878 #0 [sw]: yes
[...]
OK, patch http://patchwork.kernel.org/patch/70126/ did the trick for
kernel oops and segfault. However there is still something wrong in the
filtering code for hauppauge remotes that prevents my remote codes for
passing through:
drivers/media/video/ir-kbd-i2c.c
99/*
100 * Hauppauge remotes (black/silver) always use
101 * specific device ids. If we do not filter the
102 * device ids then messages destined for devices
103 * such as TVs (id=0) will get through causing
104 * mis-fired events.
105 *
106 * We also filter out invalid key presses which
107 * produce annoying debug log entries.
108 */
109 ircode= (start 12) | (toggle 11) | (dev 6) | code;
110 if ((ircode 0x1fff)==0x1fff)
111 /* invalid key press */
112 return 0;
113
114 if (dev!=0x1e dev!=0x1f)
115 /* not a hauppauge remote */
116 return 0;
117
118 if (!range)
119 code += 64;
When I comment in this part: if (dev!=0x1e dev!=0x1f), my remote
works with a hauppage=1 parameter, althought a few buttons are not
mapped correctly.
dmesg example with an empty table (buttons CH+ and CH-):
: unknown key: key=0x20 down=1
: unknown key for scancode 0x0020
: unknown key: key=0x20 down=0
: unknown key for scancode 0x0021
: unknown key: key=0x21 down=1
: unknown key for scancode 0x0021
: unknown key: key=0x21 down=0
Can someone please take a look at this and perhaps fix the code. Thanks
in advance.
Regards,
Samuel
It seems that my device id is the one that code author wants to filter
(0x0) if I understood correctly. I can add it to if (dev!=0x1e
dev!=0x1f) statement, but I then (I guess) would broke the filter
functionality:
ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=0 code=32
If this is the case the only thing I can think of is to add a module
parameter that turns off
such filtering.
What do you think?
Regards,
Samuel
diff -r 82bbb3bd0f0a linux/drivers/media/video/ir-kbd-i2c.c
--- a/linux/drivers/media/video/ir-kbd-i2c.cMon Jan 11 11:47:33 2010 -0200
+++ b/linux/drivers/media/video/ir-kbd-i2c.cTue Jan 12 23:36:44 2010 +0100
@@ -61,6 +61,10 @@
module_param(hauppauge, int, 0644);/* Choose Hauppauge remote */
MODULE_PARM_DESC(hauppauge, Specify Hauppauge remote: 0=black, 1=grey
(defaults to 0));
+static int haup_filter = 1;
+module_param(haup_filter, int, 0644);
+MODULE_PARM_DESC(haup_filter, Turn off Hauppauge filter for other
remotes (defaults to 1));
+
#define DEVNAME ir-kbd-i2c
#define dprintk(level, fmt, arg...)if (debug = level) \
@@ -96,6 +100,8 @@
if (!start)
/* no key pressed */
return 0;
+
+ if (haup_filter != 0) {
/*
* Hauppauge remotes (black/silver) always use
* specific device ids. If we do not filter the
@@ -114,6 +120,7 @@
if (dev!=0x1e dev!=0x1f)
/* not a hauppauge remote */
return 0;
+ }
if (!range)
code += 64;
--
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: go7007 driver -- which program you use for capture
On Fri, 2010-01-08 at 14:07 -0500, TJ wrote:
Pete and anybody else out there with go7007 devices, what do you use for
capture?
I used a modified capture.c, based on
http://v4l2spec.bytesex.org/v4l2spec/capture.c
In the init_device(void) function, use:
fmt.type= V4L2_BUF_TYPE_VIDEO_CAPTURE;
switch (G_size) {
case 0:
fmt.fmt.pix.height = 640;
fmt.fmt.pix.width = 480;
break;
case 1:
fmt.fmt.pix.height = 320;
fmt.fmt.pix.width = 240;
break;
}
switch (type) {
case TYPE_MJPEG:
printf(MJPEG\n);
fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_MJPEG;
break;
case TYPE_MPEG1:
case TYPE_MPEG2:
case TYPE_MPEG4:
fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_MPEG;
break;
}
fmt.fmt.pix.field = V4L2_FIELD_ANY;
if (-1 == xioctl (fd, VIDIOC_S_FMT, fmt))
errno_exit (VIDIOC_S_FMT);
/* Note VIDIOC_S_FMT may change width and height. */
/* Buggy driver paranoia. */
min = fmt.fmt.pix.width * 2;
if (fmt.fmt.pix.bytesperline min)
fmt.fmt.pix.bytesperline = min;
min = fmt.fmt.pix.bytesperline * fmt.fmt.pix.height;
if (fmt.fmt.pix.sizeimage min)
fmt.fmt.pix.sizeimage = min;
/* optional MPEG parameters */
if( type != TYPE_MJPEG) {
struct v4l2_control ctrl;
ctrl.id = V4L2_CID_MPEG_VIDEO_ENCODING;
switch (type) {
case TYPE_MPEG1:
ctrl.value = V4L2_MPEG_VIDEO_ENCODING_MPEG_1;
break;
case TYPE_MPEG2:
ctrl.value = V4L2_MPEG_VIDEO_ENCODING_MPEG_2;
break;
case TYPE_MPEG4:
ctrl.value = V4L2_MPEG_VIDEO_ENCODING_MPEG_4_SP;
break;
}
if (0 != xioctl (fd, VIDIOC_S_CTRL, ctrl)) {
printf(could not set video encoding\n);
}
ctrl.id = V4L2_CID_MPEG_VIDEO_BITRATE;
ctrl.value = G_br;
if (0 != xioctl (fd, VIDIOC_S_CTRL, ctrl)) {
printf(could not change bitrate\n);
}
}
Without GO7007 ioctls, I was only able to get vlc to capture in MJPEG format.
Does VLC try to change video parameters after starting the stream? The
driver currently doesn't allow that. I think I've seen xawtv try to do
that too.
Pete
--
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
[PATCH 0/3] A few #define TRUE/FALSE removals
Joe Perches (3): drivers/net/tlan: Remove TRUE/FALSE defines, use bool drivers/isdn/mISDN/dsp_ecdis.h: Remove #define TRUE/FALSE, use bool drivers/media/dvb/frontends/si21xx.c: Remove #define TRUE/FALSE, use bool drivers/isdn/mISDN/dsp_ecdis.h | 20 +++-- drivers/media/dvb/frontends/si21xx.c | 38 ++--- drivers/net/tlan.c | 28 drivers/net/tlan.h |3 -- 4 files changed, 38 insertions(+), 51 deletions(-) -- 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
[PATCH 3/3] drivers/media/dvb/frontends/si21xx.c: Remove #define TRUE/FALSE, use bool
And a little code refactoring/neatening around the removals
Reduces object size a little bit:
new:
$ size drivers/media/dvb/frontends/si21xx.o
textdata bss dec hex filename
8984 561816 108562a68 drivers/media/dvb/frontends/si21xx.o
old:
$ size drivers/media/dvb/frontends/si21xx.o
textdata bss dec hex filename
9084 561792 109322ab4 drivers/media/dvb/frontends/si21xx.o
Signed-off-by: Joe Perches j...@perches.com
---
drivers/media/dvb/frontends/si21xx.c | 38 ++---
1 files changed, 16 insertions(+), 22 deletions(-)
diff --git a/drivers/media/dvb/frontends/si21xx.c
b/drivers/media/dvb/frontends/si21xx.c
index 9552a22..d21a327 100644
--- a/drivers/media/dvb/frontends/si21xx.c
+++ b/drivers/media/dvb/frontends/si21xx.c
@@ -97,8 +97,6 @@
#defineLNB_SUPPLY_CTRL_REG_4 0xce
#defineLNB_SUPPLY_STATUS_REG 0xcf
-#define FALSE 0
-#define TRUE 1
#define FAIL -1
#define PASS 0
@@ -718,7 +716,7 @@ static int si21xx_set_frontend(struct dvb_frontend *fe,
int fine_tune_freq;
unsigned char sample_rate = 0;
/* boolean */
- unsigned int inband_interferer_ind;
+ bool inband_interferer_ind;
/* INTERMEDIATE VALUES */
int icoarse_tune_freq; /* MHz */
@@ -728,15 +726,8 @@ static int si21xx_set_frontend(struct dvb_frontend *fe,
unsigned int x1;
unsigned int x2;
int i;
- unsigned int inband_interferer_div2[ALLOWABLE_FS_COUNT] = {
- FALSE, FALSE, FALSE, FALSE, FALSE,
- FALSE, FALSE, FALSE, FALSE, FALSE
- };
- unsigned int inband_interferer_div4[ALLOWABLE_FS_COUNT] = {
- FALSE, FALSE, FALSE, FALSE, FALSE,
- FALSE, FALSE, FALSE, FALSE, FALSE
- };
-
+ bool inband_interferer_div2[ALLOWABLE_FS_COUNT];
+ bool inband_interferer_div4[ALLOWABLE_FS_COUNT];
int status;
/* allowable sample rates for ADC in MHz */
@@ -762,7 +753,7 @@ static int si21xx_set_frontend(struct dvb_frontend *fe,
}
for (i = 0; i ALLOWABLE_FS_COUNT; ++i)
- inband_interferer_div2[i] = inband_interferer_div4[i] = FALSE;
+ inband_interferer_div2[i] = inband_interferer_div4[i] = false;
if_limit_high = -70;
if_limit_low = -10;
@@ -798,7 +789,7 @@ static int si21xx_set_frontend(struct dvb_frontend *fe,
if (((band_low x1) (x1 band_high)) ||
((band_low x2) (x2 band_high)))
- inband_interferer_div4[i] = TRUE;
+ inband_interferer_div4[i] = true;
}
@@ -811,25 +802,28 @@ static int si21xx_set_frontend(struct dvb_frontend *fe,
if (((band_low x1) (x1 band_high)) ||
((band_low x2) (x2 band_high)))
- inband_interferer_div2[i] = TRUE;
+ inband_interferer_div2[i] = true;
}
- inband_interferer_ind = TRUE;
- for (i = 0; i ALLOWABLE_FS_COUNT; ++i)
- inband_interferer_ind = inband_interferer_div2[i] |
- inband_interferer_div4[i];
+ inband_interferer_ind = true;
+ for (i = 0; i ALLOWABLE_FS_COUNT; ++i) {
+ if (inband_interferer_div2[i] || inband_interferer_div4[i]) {
+ inband_interferer_ind = false;
+ break;
+ }
+ }
if (inband_interferer_ind) {
for (i = 0; i ALLOWABLE_FS_COUNT; ++i) {
- if (inband_interferer_div2[i] == FALSE) {
+ if (!inband_interferer_div2[i]) {
sample_rate = (u8) afs[i];
break;
}
}
} else {
for (i = 0; i ALLOWABLE_FS_COUNT; ++i) {
- if ((inband_interferer_div2[i] |
- inband_interferer_div4[i]) == FALSE) {
+ if ((inband_interferer_div2[i] ||
+!inband_interferer_div4[i])) {
sample_rate = (u8) afs[i];
break;
}
--
1.6.6.rc0.57.gad7a
--
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
