Re: About the VIDIOC_DQBUF
Hi,
Sorry I still don't get what the full frame means, but I might
consider that is the maximum resolution-ed image data coming from
external camera module. And whatever it is, you might have no problem
getting data through memcpy with buf.byteused size.
Cheers,
Nate
On Tue, Jun 9, 2009 at 11:22 AM, xieyili@gmail.com wrote:
hi ~~ Dongsoo, Nathaniel ~
I am sorry for disturbing you, and not descripe the question clear ~
Thanks very much for your help ~~
I know that I must stop preview with streamoff and re-configure with
s_fmt ~~ I have asked to you before ~!~
The full frame means a complete frame ~Because I just need to get the
frame data and post it to multimedia framework, so I want to consult to
you that if I can get a complete frame with memcpy ~~
I want to know that can I get a complete frame from buf.start to the
end , and the memory-lenth is buf.byteused ~
buf.byteused
|-|
buf.startend
在 2009-06-08一的 20:40 +0900，Dongsoo, Nathaniel Kim写道：
Hi,
Sorry I'm not an expert, you can expect expertise from maintainers not from
me.
But before answering your question about capturing, I'm not sure about
what the full frame means. I just assume that you meant to say the
biggest resolution of image frame, right?
So, when you are to capture a full resolution data while preview is
working, you need to stop preview with streamoff, re-configure
resolution with s_fmt to external camera module and start capturing
issuing streamon with re-configured resolution. I think you are
well-aware with this, aren't you? And in my opinion, memcpy may be
cool for that. What else are you expecting to use? and for what?
Anyway, I wish you luck.
Cheers,
Nate
On Mon, Jun 8, 2009 at 5:02 PM, xieyili@gmail.com wrote:
Hi Dongsoo, Nathaniel ~
You must be expert on V4l2 ~ Thanks very much for your help and advice
~!~
I used the MXC camera interface driver from Fressscale ,I readed the
driver interface just now ,and have fouded that the driver not modified
the buf.lenth but buf.byteused . You are very right , I will use the
buf.byteused instead of buf.length ~
There is also a problem I want to consult to you ~ Can i get a full
frame with the below method if the driver have no problem ?
memcpy((mCameraProwave-getPreviewHeap())-base(),
v4l2Buffer[buf.index].start, buf.byteused) ;
Because I just need to implement a hal for getting the frame data and
post it to top layer , so I used the memcpy simply . Am I right ~ ? Or
what about your advice ?
Thanks a lot ~~
在 2009-06-08一的 15:56 +0900，Dongsoo, Nathaniel Kim写道：
Hello Xie,
I'm not sure which camera interface driver you are using, but it seems
to be camera interface driver's problem. Let me guess, are you using
pxa camera interface driver from Marvell?(proprietary but not in up
stream kernel)
It just looks like that camera interface driver is not returning
proper data in dqbuf.
And one more thing. I prefer to use byteused rather than length in
buf. because as far as I know the size of preview data from camera is
in byte unit which we need to copy to memory. But it should be
possible to use length, I guess..
Cheers,
Nate
On Mon, Jun 8, 2009 at 11:05 AM, xieyili@gmail.com wrote:
Dear all ~~
I have met a issue when I used the mmap method for previewing . I just
used the standard code as spec to get the image data :
status_t CameraHardwareProwave::V4l2Camera::v4l2CaptureMainloop()
{
LOG_FUNCTION_NAME
int rt ;
unsigned int i ;
fd_set fds ;
struct timeval tv ;
struct v4l2_buffer buf ;
for(;;){
FD_ZERO(fds) ;
FD_SET(v4l2Fd, fds) ;
//now the time is long ,just for debug
tv.tv_sec = 2 ;
tv.tv_usec = 0 ;
rt = select(v4l2Fd + 1, fds, NULL, NULL, tv) ;
LOGD(The value of select return : %d\n, rt) ;
/** for debug
if(V4L2_NOERROR != v4l2ReadFrame()){
LOGE(READ ERROR) ;
}
***/
if(-1 == rt){
LOGE(there is something wrong in select
function(select)) ;
//no defined error manage
return V4L2_IOCTL_ERROR ;
}
if(0 == rt){
LOGE(wait for data timeout in select) ;
return V4L2_TIMEOUT ;
}
memset(buf, 0, sizeof(buf)) ;
buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE ;
buf.memory = V4L2_MEMORY_MMAP ;
if(-1 == ioctl(v4l2Fd, VIDIOC_DQBUF, buf)){
LOGE(there is something wrong in dequeue
Re: Haupauge Nova-T 500 2.6.28 regression dib0700
Hi, cc-ed linux-media On Mon, Jun 01, 2009 at 12:48:33PM +0200, Hubert Hafner wrote: I've read your message on mail-archive.com on the linux-media section. The same problem seems to be valid for the Haupauge Nova-TD (a dual receiver). After a few minutes the ehci_hcd core is halted. Have you got any ideas how to solve this? I've read setting URB to 1 (?) should solve this issue - but where to set this parameter and did it work out? There's a patch on the linux-media list. Search for a thread with dib0700 Nova-TD-Stick problem as subject. disable_rc_polling does not solve the problem. At least at my Ubuntu Server 8.10 with kernel 2.6.27-7. Seems to be different problem than. At least kernel 2.6.27.x works here without problems. Janne -- 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: [PATCHv6 5 of 7] FMTx: si4713: Add files to add radio interface for si4713
On Monday 08 June 2009 10:18:05 Eduardo Valentin wrote:
From: Eduardo Valentin eduardo.valen...@nokia.com
# HG changeset patch
# User Eduardo Valentin eduardo.valen...@nokia.com
# Date 126611 -10800
# Node ID 92ec243dd1882c136a588898dd5b7a1913ca0f4b
# Parent 2456c8fc506ecf928d2e95da36d611d094c0ec55
This patch adds files which creates the radio interface
for si4713 FM transmitter devices.
Priority: normal
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
diff -r 2456c8fc506e -r 92ec243dd188 linux/drivers/media/radio/radio-si4713.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/radio/radio-si4713.cMon Jun 08 10:36:51
2009 +0300
@@ -0,0 +1,332 @@
+/*
+ * drivers/media/radio/radio-si4713.c
+ *
+ * Platform Driver for Silicon Labs Si4713 FM Radio Transmitter:
+ *
+ * Copyright (c) 2008 Instituto Nokia de Tecnologia - INdT
+ * Contact: Eduardo Valentin eduardo.valen...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/version.h
+#include linux/platform_device.h
+#include linux/i2c.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-common.h
+#include media/v4l2-ioctl.h
+
+#include radio-si4713.h
+#include si4713.h
+
+/* module parameters */
+static int radio_nr = -1;/* radio device minor (-1 == auto assign) */
+
+/* radio_si4713_fops - file operations interface */
+static const struct v4l2_file_operations radio_si4713_fops = {
+ .owner = THIS_MODULE,
+ .ioctl = video_ioctl2,
+};
+
+/* Video4Linux Interface */
+static int radio_si4713_vidioc_g_audio(struct file *file, void *priv,
+ struct v4l2_audio *audio)
+{
+ if (audio-index 1)
+ return -EINVAL;
+
+ strncpy(audio-name, Radio, 32);
+ audio-capability = V4L2_AUDCAP_STEREO;
+
+ return 0;
+}
+
+static int radio_si4713_vidioc_s_audio(struct file *file, void *priv,
+ struct v4l2_audio *audio)
+{
+ if (audio-index != 0)
+ return -EINVAL;
+
+ return 0;
+}
This is a transmitter (aka modulator) device, so it should implement g_audout,
s_audout and enumaudout rather than s_audio and g_audio.
+
+static int radio_si4713_vidioc_g_input(struct file *file, void *priv,
+ unsigned int *i)
+{
+ *i = 0;
+
+ return 0;
+}
+
+static int radio_si4713_vidioc_s_input(struct file *file, void *priv,
+ unsigned int i)
+{
+ if (i != 0)
+ return -EINVAL;
+
+ return 0;
+}
These are not needed: it is an audio only device, so no video. Since g/s_input
deals with video inputs these are not relevant. And even if it was, then it
would have to be g/s_output :-)
+
+/* radio_si4713_vidioc_querycap - query device capabilities */
+static int radio_si4713_vidioc_querycap(struct file *file, void *priv,
+ struct v4l2_capability *capability)
+{
+ struct radio_si4713_device *rsdev;
+
+ rsdev = video_get_drvdata(video_devdata(file));
+
+ strlcpy(capability-driver, radio-si4713, sizeof(capability-driver));
+ strlcpy(capability-card, Silicon Labs Si4713 FM Radio Transmitter,
+ sizeof(capability-card));
+ capability-capabilities = V4L2_CAP_TUNER;
+
+ return 0;
+}
+
+/* radio_si4713_vidioc_queryctrl - enumerate control items */
+static int radio_si4713_vidioc_queryctrl(struct file *file, void *priv,
+ struct v4l2_queryctrl *qc)
+{
+
+ /* Must be sorted from low to high control ID! */
+ static const u32 user_ctrls[] = {
+ V4L2_CID_USER_CLASS,
+ V4L2_CID_AUDIO_VOLUME,
+ V4L2_CID_AUDIO_BALANCE,
+ V4L2_CID_AUDIO_BASS,
+ V4L2_CID_AUDIO_TREBLE,
+ V4L2_CID_AUDIO_LOUDNESS,
+ V4L2_CID_AUDIO_MUTE,
+ 0
+ };
+
+ /* Must be sorted from low to high control ID! */
+ static const u32 fmtx_ctrls[] = {
+ V4L2_CID_FMTX_CLASS,
+
[patch review] gspca - stv06xx: remove needless if check and goto
Hello, Jean-Francois and Erik André What do you think about such small change? Looks like the code doesn't need if-check and goto here in stv06xx_stopN function. The code after label out does this. -- Patch removes needless if check and goto. Signed-off-by: Alexey Klimov klimov.li...@gmail.com -- diff -r ed3781a79c73 linux/drivers/media/video/gspca/stv06xx/stv06xx.c --- a/linux/drivers/media/video/gspca/stv06xx/stv06xx.c Sat Jun 06 16:31:34 2009 +0400 +++ b/linux/drivers/media/video/gspca/stv06xx/stv06xx.c Tue Jun 09 14:49:04 2009 +0400 @@ -293,8 +293,6 @@ goto out; err = sd-sensor-stop(sd); - if (err 0) - goto out; out: if (err 0) -- Best regards, Klimov Alexey -- 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: [PATCHv6 5 of 7] FMTx: si4713: Add files to add radio interface for si4713
Hi Hans,
On Tue, Jun 09, 2009 at 12:41:38PM +0200, ext Hans Verkuil wrote:
On Monday 08 June 2009 10:18:05 Eduardo Valentin wrote:
From: Eduardo Valentin eduardo.valen...@nokia.com
# HG changeset patch
# User Eduardo Valentin eduardo.valen...@nokia.com
# Date 126611 -10800
# Node ID 92ec243dd1882c136a588898dd5b7a1913ca0f4b
# Parent 2456c8fc506ecf928d2e95da36d611d094c0ec55
This patch adds files which creates the radio interface
for si4713 FM transmitter devices.
Priority: normal
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
diff -r 2456c8fc506e -r 92ec243dd188
linux/drivers/media/radio/radio-si4713.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/radio/radio-si4713.cMon Jun 08 10:36:51
2009 +0300
@@ -0,0 +1,332 @@
+/*
+ * drivers/media/radio/radio-si4713.c
+ *
+ * Platform Driver for Silicon Labs Si4713 FM Radio Transmitter:
+ *
+ * Copyright (c) 2008 Instituto Nokia de Tecnologia - INdT
+ * Contact: Eduardo Valentin eduardo.valen...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/version.h
+#include linux/platform_device.h
+#include linux/i2c.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-common.h
+#include media/v4l2-ioctl.h
+
+#include radio-si4713.h
+#include si4713.h
+
+/* module parameters */
+static int radio_nr = -1;/* radio device minor (-1 == auto assign) */
+
+/* radio_si4713_fops - file operations interface */
+static const struct v4l2_file_operations radio_si4713_fops = {
+ .owner = THIS_MODULE,
+ .ioctl = video_ioctl2,
+};
+
+/* Video4Linux Interface */
+static int radio_si4713_vidioc_g_audio(struct file *file, void *priv,
+ struct v4l2_audio *audio)
+{
+ if (audio-index 1)
+ return -EINVAL;
+
+ strncpy(audio-name, Radio, 32);
+ audio-capability = V4L2_AUDCAP_STEREO;
+
+ return 0;
+}
+
+static int radio_si4713_vidioc_s_audio(struct file *file, void *priv,
+ struct v4l2_audio *audio)
+{
+ if (audio-index != 0)
+ return -EINVAL;
+
+ return 0;
+}
This is a transmitter (aka modulator) device, so it should implement g_audout,
s_audout and enumaudout rather than s_audio and g_audio.
+
+static int radio_si4713_vidioc_g_input(struct file *file, void *priv,
+ unsigned int *i)
+{
+ *i = 0;
+
+ return 0;
+}
+
+static int radio_si4713_vidioc_s_input(struct file *file, void *priv,
+ unsigned int i)
+{
+ if (i != 0)
+ return -EINVAL;
+
+ return 0;
+}
These are not needed: it is an audio only device, so no video. Since g/s_input
deals with video inputs these are not relevant. And even if it was, then it
would have to be g/s_output :-)
+
+/* radio_si4713_vidioc_querycap - query device capabilities */
+static int radio_si4713_vidioc_querycap(struct file *file, void *priv,
+ struct v4l2_capability *capability)
+{
+ struct radio_si4713_device *rsdev;
+
+ rsdev = video_get_drvdata(video_devdata(file));
+
+ strlcpy(capability-driver, radio-si4713,
sizeof(capability-driver));
+ strlcpy(capability-card, Silicon Labs Si4713 FM Radio Transmitter,
+ sizeof(capability-card));
+ capability-capabilities = V4L2_CAP_TUNER;
+
+ return 0;
+}
+
+/* radio_si4713_vidioc_queryctrl - enumerate control items */
+static int radio_si4713_vidioc_queryctrl(struct file *file, void *priv,
+ struct v4l2_queryctrl *qc)
+{
+
+ /* Must be sorted from low to high control ID! */
+ static const u32 user_ctrls[] = {
+ V4L2_CID_USER_CLASS,
+ V4L2_CID_AUDIO_VOLUME,
+ V4L2_CID_AUDIO_BALANCE,
+ V4L2_CID_AUDIO_BASS,
+ V4L2_CID_AUDIO_TREBLE,
+
Re: [patch review] gspca - stv06xx: remove needless if check and goto
2009/6/9 Alexey Klimov klimov.li...@gmail.com: Hello, Jean-Francois and Erik André What do you think about such small change? Looks like the code doesn't need if-check and goto here in stv06xx_stopN function. The code after label out does this. -- Patch removes needless if check and goto. Signed-off-by: Alexey Klimov klimov.li...@gmail.com Looks sane. Thank you for reporting. Best regards, Erik Reviewed-by: Erik Andrén erik.and...@gmail.com -- diff -r ed3781a79c73 linux/drivers/media/video/gspca/stv06xx/stv06xx.c --- a/linux/drivers/media/video/gspca/stv06xx/stv06xx.c Sat Jun 06 16:31:34 2009 +0400 +++ b/linux/drivers/media/video/gspca/stv06xx/stv06xx.c Tue Jun 09 14:49:04 2009 +0400 @@ -293,8 +293,6 @@ goto out; err = sd-sensor-stop(sd); - if (err 0) - goto out; out: if (err 0) -- Best regards, Klimov Alexey -- 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/2] SE401 clean up
Tidy up the SE401 driver --- Alan Cox (2): se401: Fix unsafe use of sprintf with identical source/destination se401: Fix coding style drivers/media/video/se401.c | 882 ++- drivers/media/video/se401.h |7 2 files changed, 456 insertions(+), 433 deletions(-) -- I'd prefer the trees to be separate for testing purposes: it doens't make much sense to have SMP support as a normal kernel feature when most people won't have SMP anyway -- Linus Torvalds -- 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 1/2] se401: Fix unsafe use of sprintf with identical source/destination
From: Alan Cox a...@linux.intel.com
Closes-bug: http://bugzilla.kernel.org/show_bug.cgi?id=13435
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/media/video/se401.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/se401.c b/drivers/media/video/se401.c
index 5990ab3..08129a8 100644
--- a/drivers/media/video/se401.c
+++ b/drivers/media/video/se401.c
@@ -1244,17 +1244,18 @@ static int se401_init(struct usb_se401 *se401, int
button)
int i=0, rc;
unsigned char cp[0x40];
char temp[200];
+ int slen;
/* led on */
se401_sndctrl(1, se401, SE401_REQ_LED_CONTROL, 1, NULL, 0);
/* get camera descriptor */
rc=se401_sndctrl(0, se401, SE401_REQ_GET_CAMERA_DESCRIPTOR, 0, cp,
sizeof(cp));
- if (cp[1]!=0x41) {
+ if (cp[1] != 0x41) {
err(Wrong descriptor type);
return 1;
}
- sprintf (temp, ExtraFeatures: %d, cp[3]);
+ slen = snprintf(temp, 200, ExtraFeatures: %d, cp[3]);
se401-sizes=cp[4]+cp[5]*256;
se401-width=kmalloc(se401-sizes*sizeof(int), GFP_KERNEL);
@@ -1269,9 +1270,10 @@ static int se401_init(struct usb_se401 *se401, int
button)
se401-width[i]=cp[6+i*4+0]+cp[6+i*4+1]*256;
se401-height[i]=cp[6+i*4+2]+cp[6+i*4+3]*256;
}
- sprintf (temp, %s Sizes:, temp);
+ slen += snprintf (temp + slen, 200 - slen, Sizes:);
for (i=0; ise401-sizes; i++) {
- sprintf(temp, %s %dx%d, temp, se401-width[i],
se401-height[i]);
+ slen += snprintf(temp + slen, 200 - slen,
+%dx%d, se401-width[i], se401-height[i]);
}
dev_info(se401-dev-dev, %s\n, temp);
se401-maxframesize=se401-width[se401-sizes-1]*se401-height[se401-sizes-1]*3;
--
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: [PATCHv6 5 of 7] FMTx: si4713: Add files to add radio interface for si4713
On Tuesday 09 June 2009 13:11:11 Eduardo Valentin wrote:
Hi Hans,
On Tue, Jun 09, 2009 at 12:41:38PM +0200, ext Hans Verkuil wrote:
snip
+static struct v4l2_ioctl_ops radio_si4713_ioctl_ops = {
+ .vidioc_g_input = radio_si4713_vidioc_g_input,
+ .vidioc_s_input = radio_si4713_vidioc_s_input,
+ .vidioc_g_audio = radio_si4713_vidioc_g_audio,
+ .vidioc_s_audio = radio_si4713_vidioc_s_audio,
+ .vidioc_querycap= radio_si4713_vidioc_querycap,
+ .vidioc_queryctrl = radio_si4713_vidioc_queryctrl,
+ .vidioc_g_ext_ctrls = radio_si4713_vidioc_g_ext_ctrls,
+ .vidioc_s_ext_ctrls = radio_si4713_vidioc_s_ext_ctrls,
+ .vidioc_g_ctrl = radio_si4713_vidioc_g_ctrl,
+ .vidioc_s_ctrl = radio_si4713_vidioc_s_ctrl,
+ .vidioc_g_tuner = radio_si4713_vidioc_g_tuner,
+ .vidioc_s_tuner = radio_si4713_vidioc_s_tuner,
It's a modulator device, so it should implement g/s_modulator rather than
g/s_tuner.
Now, here I am running into a problem: looking at section 1.6.2 in the v4l2
spec I see that in QUERYCAP you are supposed to return CAP_TUNER and rely on
ENUMOUTPUT to determine which output has a modulator. I think it is nuts
that
there is no CAP_MODULATOR. I propose adding this. There are currently NO
modulator drivers in v4l-dvb, nor have I ever heard from out-of-tree
modulator drivers (not that I particularly care about that), so it should be
safe to add it.
The next problem is that ENUMOUTPUT does not apply to a radio modulator.
This problem is actually also present on radio tuners. Currently all radio
tuner drivers implement g/s_input and g/s_audio but no enuminput or
enumaudio.
I think g/s_input is bogus since these devices have no video inputs.
However, neither g/s_audio nor enumaudio can currently tell the application
whether the audio input is connected to a tuner. Only enuminput can do that
currently. This would be an argument for using g/s_input if it wasn't for
the fact that none of the radio drivers actually implements enuminput.
I propose adding a V4L2_AUDCAP_TUNER capability telling this application
that the audio input is connected to a tuner, and adding a
V4L2_AUDOUTCAP_MODULATOR capability for struct v4l2_audioout to do the same
for a modulator.
Comments?
Ok. Here comes the real needed changes to support the radio modulator.
You may not remember, but in previous versions of this series I commented
that this driver was fully based on fm receiver existing drivers.
I think that's why I went in the mistake of implementing g_audio, s_audio
instead of g_audout, s_audout. Also, the same mistake of implementing
the s,g_input done in fm receiver drivers was repeated here.
Also, I think another thing has biased me to add this wrong callbacks. I use
fmtools to test the driver, for setting fm freq for instance.
I admit, there are wrong callbacks.
So, I'd ask which application to use to test the driver ?
You have the honor of adding the first modulator driver to the kernel, so
there are no apps yet. That said, I suggest adding support for g/s_modulator
to the v4l2-ctl tool (in v4l2-apps/util). It's the swiss army knife utility
of v4l2 and can call most ioctls from the command line.
About the suggested changes (adding V4L2_AUDCAP_TUNER and
V4L2_AUDOUTCAP_MODULATOR),
I think it is a reasonable way to do it. However, it'd be nice to hear more
opinions.
But, if I understood correctly, this would be the method to determine
if the driver is a fm transmitter (aka modulator) ?
The CAP_MODULATOR capability is used to determine if the driver supports a
modulator, and the new capabilities for v4l2_audio and v4l2_audioout can be
used to determine which audio input/output is hooked up to a tuner or
modulator. In theory there may be multiple inputs and outputs where some
are connected to a tuner/modulator and others are straight inputs/outputs.
It is common for video capture cards (tuner input vs. Composite/Line-In
inputs), but there is a case to be made that this is very unlikely for
radio tuners/modulators. So perhaps I'm paranoid :-)
Actually, looking at it a bit closer it is not enough to just set the
capability, you also need to set the index of the associated tuner or
modulatory, which would mean using one of the reserved fields.
Hmm, this is getting complicated. Perhaps we should just add a CAP_MODULATOR
capability and leave it at that for now. I think the MODULATOR capability
is really needed, otherwise there is no easy way to check whether it is a
tuner or modulator device.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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 2/2] se401: Fix coding style
From: Alan Cox a...@linux.intel.com
Having fixed the sprintfs I decided a quick clean wouldn't do any harm so
it was actually easy to read in future.
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/media/video/se401.c | 876 ++-
drivers/media/video/se401.h |7
2 files changed, 452 insertions(+), 431 deletions(-)
diff --git a/drivers/media/video/se401.c b/drivers/media/video/se401.c
index 08129a8..c8f0529 100644
--- a/drivers/media/video/se401.c
+++ b/drivers/media/video/se401.c
@@ -38,7 +38,7 @@ static const char version[] = 0.24;
static int flickerless;
static int video_nr = -1;
-static struct usb_device_id device_table [] = {
+static struct usb_device_id device_table[] = {
{ USB_DEVICE(0x03e8, 0x0004) },/* Endpoints/Aox SE401 */
{ USB_DEVICE(0x0471, 0x030b) },/* Philips PCVC665K */
{ USB_DEVICE(0x047d, 0x5001) },/* Kensington 67014 */
@@ -53,7 +53,8 @@ MODULE_AUTHOR(Jeroen Vreeken pe1...@amsat.org);
MODULE_DESCRIPTION(SE401 USB Camera Driver);
MODULE_LICENSE(GPL);
module_param(flickerless, int, 0);
-MODULE_PARM_DESC(flickerless, Net frequency to adjust exposure time to
(0/50/60));
+MODULE_PARM_DESC(flickerless,
+ Net frequency to adjust exposure time to (0/50/60));
module_param(video_nr, int, 0);
static struct usb_driver se401_driver;
@@ -78,8 +79,8 @@ static void *rvmalloc(unsigned long size)
adr = (unsigned long) mem;
while (size 0) {
SetPageReserved(vmalloc_to_page((void *)adr));
- adr += PAGE_SIZE;
- size -= PAGE_SIZE;
+ adr += PAGE_SIZE;
+ size -= PAGE_SIZE;
}
return mem;
@@ -95,8 +96,8 @@ static void rvfree(void *mem, unsigned long size)
adr = (unsigned long) mem;
while ((long) size 0) {
ClearPageReserved(vmalloc_to_page((void *)adr));
- adr += PAGE_SIZE;
- size -= PAGE_SIZE;
+ adr += PAGE_SIZE;
+ size -= PAGE_SIZE;
}
vfree(mem);
}
@@ -112,7 +113,7 @@ static void rvfree(void *mem, unsigned long size)
static int se401_sndctrl(int set, struct usb_se401 *se401, unsigned short req,
unsigned short value, unsigned char *cp, int size)
{
- return usb_control_msg (
+ return usb_control_msg(
se401-dev,
set ? usb_sndctrlpipe(se401-dev, 0) :
usb_rcvctrlpipe(se401-dev, 0),
req,
@@ -132,7 +133,7 @@ static int se401_set_feature(struct usb_se401 *se401,
unsigned short selector,
and the param in index, but in the logs of the windows driver they do
this the other way around...
*/
- return usb_control_msg (
+ return usb_control_msg(
se401-dev,
usb_sndctrlpipe(se401-dev, 0),
SE401_REQ_SET_EXT_FEATURE,
@@ -152,7 +153,7 @@ static unsigned short se401_get_feature(struct usb_se401
*se401,
wrong here to
*/
unsigned char cp[2];
- usb_control_msg (
+ usb_control_msg(
se401-dev,
usb_rcvctrlpipe(se401-dev, 0),
SE401_REQ_GET_EXT_FEATURE,
@@ -175,46 +176,51 @@ static unsigned short se401_get_feature(struct usb_se401
*se401,
static int se401_send_pict(struct usb_se401 *se401)
{
- se401_set_feature(se401, HV7131_REG_TITL, se401-expose_l);/*
integration time low */
- se401_set_feature(se401, HV7131_REG_TITM, se401-expose_m);/*
integration time mid */
- se401_set_feature(se401, HV7131_REG_TITU, se401-expose_h);/*
integration time mid */
- se401_set_feature(se401, HV7131_REG_ARLV, se401-resetlevel);/* reset
level value */
- se401_set_feature(se401, HV7131_REG_ARCG, se401-rgain);/* red color
gain */
- se401_set_feature(se401, HV7131_REG_AGCG, se401-ggain);/* green color
gain */
- se401_set_feature(se401, HV7131_REG_ABCG, se401-bgain);/* blue color
gain */
+ /* integration time low */
+ se401_set_feature(se401, HV7131_REG_TITL, se401-expose_l);
+ /* integration time mid */
+ se401_set_feature(se401, HV7131_REG_TITM, se401-expose_m);
+ /* integration time mid */
+ se401_set_feature(se401, HV7131_REG_TITU, se401-expose_h);
+ /* reset level value */
+ se401_set_feature(se401, HV7131_REG_ARLV, se401-resetlevel);
+ /* red color gain */
+ se401_set_feature(se401, HV7131_REG_ARCG, se401-rgain);
+ /* green color gain */
+ se401_set_feature(se401, HV7131_REG_AGCG, se401-ggain);
+ /* blue color gain */
+ se401_set_feature(se401, HV7131_REG_ABCG, se401-bgain);
return 0;
}
static void se401_set_exposure(struct usb_se401 *se401, int brightness)
{
- int integration=brightness5;
-
- if (flickerless==50) {
- integration=integration-integration%106667;
- }
- if
Re: RFC: proposal for new i2c.h macro to initialize i2c address lists on the fly
On Monday 08 June 2009 14:39:32 Jean Delvare wrote:
Hi Hans,
On Sat, 6 Jun 2009 15:00:48 +0200, Hans Verkuil wrote:
For video4linux we sometimes need to probe for a single i2c address.
Normally you would do it like this:
static const unsigned short addrs[] = {
addr, I2C_CLIENT_END
};
client = i2c_new_probed_device(adapter, info, addrs);
This is a bit awkward and I came up with this macro:
#define V4L2_I2C_ADDRS(addr, addrs...) \
((const unsigned short []){ addr, ## addrs, I2C_CLIENT_END })
This can construct a list of one or more i2c addresses on the fly. But
this is something that really belongs in i2c.h, renamed to I2C_ADDRS.
With this macro we can just do:
client = i2c_new_probed_device(adapter, info, I2C_ADDRS(addr));
Comments?
I'm not a big fan of macros which hide how things work, but if this
makes your life easier, why not. Just send a patch and I'll queue it up
for 2.6.31.
Hi Jean,
Here it is:
--- linux-git/include/linux/i2c.h.orig 2009-06-09 14:53:32.0 +0200
+++ linux-git/include/linux/i2c.h 2009-06-09 15:03:24.0 +0200
@@ -412,6 +412,10 @@
/* The numbers to use to set I2C bus address */
#define ANY_I2C_BUS0x
+/* Construct an I2C_CLIENT_END-terminated array of i2c addresses */
+#define I2C_ADDRS(addr, addrs...) \
+ ((const unsigned short []){ addr, ## addrs, I2C_CLIENT_END })
+
/* - functions exported by i2c.o */
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Note that this can also be used to initialize an array:
static const unsigned short addrs[] = I2C_ADDRS(0x2a, 0x2c);
Whether you want to is another matter, but it works. This functionality is
also available in the oldest supported gcc (3.2).
Thanks,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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 00/10 v2] soc-camera conversions
On Mon, Jun 08, 2009 at 09:19:50PM +0200, Guennadi Liakhovetski wrote: On Tue, 19 May 2009, Paul Mundt wrote: On Fri, May 15, 2009 at 07:18:45PM +0200, Guennadi Liakhovetski wrote: this is the next round of soc-camera conversions. Run-tested on i.MX31, PXA270, SH7722, compile-tested only for i.MX1. It should have been a straight-forward port of the previous version to a more current tree, but then I started converting soc_camera_platform, and things became a bit more complex... As a bonus, now soc-camera can handle not only i2c subdevices, and we can even drop the CONFIG_I2C dependency again. I'll also upload a comlpete stack somewhere a bit later, for example for those, wishing to test it on i.MX31, otherwise the series will not apply cleanly. I'd like to push the first 8 of them asap, 9 and 10 will still have to be reworked Paul, I put you on cc on all patches, because, unfortunately, several of them affect arch/sh. But I'll mention it explicitly in each such patch. Looks ok to me, there shouldn't be any problems with taking these all through the v4l tree. Feel free to add my Acked-by if you like. I guess we will find out in -next if there are any conflicts or not :-) Yes, can do this, thanks, but first these 3 patches (including Magnus' ack) have to be applied to sh: http://www.mail-archive.com/linux-media@vger.kernel.org/msg05223.html which in turn depend on http://www.mail-archive.com/linux-media@vger.kernel.org/msg04724.html and the latter one is already in the next tree. Would you like me to also merge and pull the above three patches via v4l or would you be applying them yourself? I can take care of them once the dependent patch is merged. -- 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: funny colors from XC5000 on big endian systems
On Mon, Jun 8, 2009 at 7:09 PM, W. Michael Petullo m...@flyn.org wrote: I have a VCR connected to my 950Q using the coaxial interface. Kernel is 2.6.29.4. I am using streamer from Fedora's xawtv-3.95-11.fc11.ppc: v4lctl setchannel 3 streamer -r 30 -s 640x480 -f jpeg -i Television -n NTSC-M -c /dev/video0 -o ~/Desktop/foo.avi -t 00:60:00 I am using gstreamer-plugins-good-0.10.14-2.fc11.ppc: gst-launch v4l2src ! ffmpegcolorspace ! ximagesink Mike Hello Mike, Just a quick follow up, I was up until 1am debugging this issue. It appears that a couple of the ioctl calls are failing when negotiating the capabilities of the analog support. As a result, the gstreamer v4l code is falling back to a default colorspace. The command I sent you should be good enough for it to work for you, but I obviously need to debug this further so that the autonegotiation works properly. 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: [PATCH 2/2] se401: Fix coding style
Alan Cox wrote:
From: Alan Cox a...@linux.intel.com
Having fixed the sprintfs I decided a quick clean wouldn't do any harm so
it was actually easy to read in future.
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/media/video/se401.c | 876
++-
drivers/media/video/se401.h |7
2 files changed, 452 insertions(+), 431 deletions(-)
diff --git a/drivers/media/video/se401.c b/drivers/media/video/se401.c
index 08129a8..c8f0529 100644
--- a/drivers/media/video/se401.c
+++ b/drivers/media/video/se401.c
[...]
@@ -78,8 +79,8 @@ static void *rvmalloc(unsigned long size)
adr = (unsigned long) mem;
while (size 0) {
SetPageReserved(vmalloc_to_page((void *)adr));
- adr += PAGE_SIZE;
- size -= PAGE_SIZE;
+ adr += PAGE_SIZE;
+ size -= PAGE_SIZE;
Why 2 spaces are better here?
}
return mem;
--
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: cx18, s5h1409: chronic bit errors, only under Linux
Steven, One thing that is interesting is that he is getting BER/UNC errors even on ATSC, when he has a 30.2 dB signal. While I agree that the cable company could be sending a weak signal, 30 dB should be plenty for ATSC. Also, it's possible that the playback application/codec in question poorly handles recovery from MPEG errors such as discontinuity, which results in the experience appearing to be worse under Linux. I'm going to see if I can find some cycles to do some testing here with s5h1409/s5h1411 and see if I can reproduce what David is seeing. Thanks. I ruled out 30db on ATSC because that sounds incredibly high, I assumed cable because that would be consistent with the numbers. You could well be right. -- Steven Toth - 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: cx18, s5h1409: chronic bit errors, only under Linux
David Ward wrote: On 06/08/2009 04:36 PM, Devin Heitmueller wrote: On Mon, Jun 8, 2009 at 4:20 PM, Steven Tothst...@kernellabs.com wrote: We're getting into the realm of 'do you need to amplify and/or debug your cable network', and out of the realm of driver development. Comcast is coming tomorrow to check out the signal quality. They said that they expect to deliver SNR in the range of 33dB - 45dB to the premises. I will let you know how that affects Linux captures. 33 should be fine for any Linux TV device. Make sure the engineer checks for 33db across a range of the higher (80 thru 100) rf channels (where rf falloff of common). Let us know how you get on. Regards, -- Steven Toth - 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: cx18, s5h1409: chronic bit errors, only under Linux
On Tue, Jun 9, 2009 at 10:21 AM, Steven Toth st...@kernellabs.com wrote: I ruled out 30db on ATSC because that sounds incredibly high, I assumed cable because that would be consistent with the numbers. You could well be right. -- Steven Toth - Kernel Labs http://www.kernellabs.com I agree it's high, but certainly possible. I've got a 30 dB signal, but my situation is a bit unusual. I spent all of last night working on another issue, but I am hoping to get back to it this week. 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: RFC: proposal for new i2c.h macro to initialize i2c address lists on the fly
On Tue, 9 Jun 2009 15:04:36 +0200, Hans Verkuil wrote:
Here it is:
--- linux-git/include/linux/i2c.h.orig2009-06-09 14:53:32.0
+0200
+++ linux-git/include/linux/i2c.h 2009-06-09 15:03:24.0 +0200
@@ -412,6 +412,10 @@
/* The numbers to use to set I2C bus address */
#define ANY_I2C_BUS 0x
+/* Construct an I2C_CLIENT_END-terminated array of i2c addresses */
+#define I2C_ADDRS(addr, addrs...) \
+ ((const unsigned short []){ addr, ## addrs, I2C_CLIENT_END })
+
/* - functions exported by i2c.o */
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Note that this can also be used to initialize an array:
static const unsigned short addrs[] = I2C_ADDRS(0x2a, 0x2c);
Whether you want to is another matter, but it works. This functionality is
also available in the oldest supported gcc (3.2).
Applied, thanks.
--
Jean Delvare
--
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: [PULL] http://linuxtv.org/hg/~pinchartl/uvcvideo/
Em Mon, 8 Jun 2009 16:15:57 +0200
Laurent Pinchart laurent.pinch...@skynet.be escreveu:
Hi Mauro,
On Monday 08 June 2009 03:52:12 Mauro Carvalho Chehab wrote:
Em Thu, 4 Jun 2009 14:39:52 +0200
Laurent Pinchart laurent.pinch...@skynet.be escreveu:
Mauro,
Please pull from http://linuxtv.org/hg/~pinchartl/uvcvideo/
for the following 3 changesets:
uvcvideo: Add generic control blacklist.
uvcvideo: Don't accept to change the format when buffers are allocated.
uvcvideo: Implement VIDIOC_[GS]_JPEGCOMP
I have a few comments about the code of the last patch:
I'll have to drop the tree, clone v4l-dvb and re-apply patches. git ? :-)
(don't take this too seriously, I would love to switch to git, but it doesn't
bother me *that* much for now as I don't have to rework patches too often).
With hg, there aren't any alternatives, AFAIK, since hg push -f won't delete
an object that were removed locally with hg strip (or changed via hg mq).
+ jpeg-quality = video-streaming-ctrl.wCompQuality / 100;
Wouldn't be better to round it to the closest value instead of just
truncating?
Ok. I don't think it will really make a difference given how webcams handle
JPEG compression quality, but better being correct anyway.
Ok.
+ memcpy(probe, video-streaming-ctrl, sizeof probe);
Please use sizeof(probe) instead.
Oops sorry. I'm used to the 'sizeof variable' syntax. Seems checkpatch
doesn't
catch this. I'll fix that.
Checkpatch doesn't catch all problems (and, sometimes, a new version forgets
to report some errors that previous versions used to report).
ERROR: do not use assignment in if condition
#64: FILE: linux/drivers/media/video/uvc/uvc_v4l2.c:376:
+ if ((ret = uvc_probe_video(video, probe)) 0)
ERROR: do not use assignment in if condition
#80: FILE: linux/drivers/media/video/uvc/uvc_v4l2.c:872:
+ if ((ret = uvc_acquire_privileges(handle)) 0)
total: 2 errors, 0 warnings, 81 lines checked
Please, one statement per line.
Is there any way I can convince you to accept the
if ((ret = function(...) 0)
I prefer if you fix it, although I won't nack your pull just due to that.
syntax on the basis that it's used throughout the rest of the driver ? :-)
$ find . -type f -name \*.c -exec grep -l 'if (([a-zA-Z]\+ \?= \?[a-zA-
Z_]\+([a-zA-Z0-9 ,*]*)) \?[=]\+ \?[a-zA-Z0-9]\+)' {} \; | wc
307 3079204
I might have missed a few cases. Not that many occurrences.
Try to count the proper coding style over the kernel source code. I bet
they you'll find much more cases of:
ret = function();
if (ret 0)/* and other similar tests, like ret == NULL, ret,
!ret, etc */
foo;
Since uvc is part of the kernel, in fact, it is uvcvideo that is adding more
exceptions to the Kernel style.
Also, I have a few comments, from API POV.
It doesn't seem that those ioctls are properly implemented. There are some
things there that sounded obfuscated for me, and it you aren't
implementing. Probably because it is not clear enough.
The UVC standard doesn't specify a way to add/remove specific JPEG segments.
As MJPEG has not COM, DRI and DHT segments, I've hardcoded flags to DQT.
Also, we used to have a similar set of ioctls for MPEG, that were removed,
in favor of the usage of extended controls, with a cleaner interface.
That's said, instead of adding more support for this obfuscated API, maybe
we could deprecate those in favor of some controls that could make more
sense, and let vidio_ioctl2 provide backward compat for it by calling the
proper controls, just to preserve binary compatibility with legacy
applications.
I have mixed feelings about this. On one hand I agree that VIDIOC_S_JPEGCOMP
is under-specified and should be either properly document, or deprecate it in
favor of a control. On the other hand, the uvcvideo driver assumes that
controls can all be read and written while streaming is in progress. I
suppose
other drivers (probably non-MPEG ones) were written with the same assumption
in mind. Using a control to set JPEG compression would mean that a proper
infrastructure would need to be put in place in those drivers to handle
controls that influence video streaming. I'd appreciate your opinion on that.
I'm in favor of deprecate VIDIOC_S_JPEGCOMP.
The issue you've described of changing the format while streaming exists, being
it a control, or an ioctl. So, it deserves a separate discussion.
-
The MPEG drivers block trials of changing the MPEG format that can't be done
while
streaming. On the other hand, user preference controls, like bright, contrast,
(auto)gain, exposure, etc can be done anytime. As most drivers just exposes
such controls, they don't need a logic to block a control while streaming.
The case of JPEG/MJPEG is similar to MPEG: there are some changes that may not
be possible while streaming. So, such changes
Re: [PATCH 2/2] se401: Fix coding style
- adr += PAGE_SIZE; - size -= PAGE_SIZE; + adr += PAGE_SIZE; + size -= PAGE_SIZE; Why 2 spaces are better here? Regexps need tweaking a tiny bit I guess. I'll post a follow up patch at some point when I'm back dealing with ultra-low priority tweaks (although it does now pass codingstyle like that anyway). -- 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: [PULL] http://linuxtv.org/hg/~pinchartl/uvcvideo/
Hi Mauro,
On Tuesday 09 June 2009 17:01:14 Mauro Carvalho Chehab wrote:
Em Mon, 8 Jun 2009 16:15:57 +0200
Laurent Pinchart laurent.pinch...@skynet.be escreveu:
On Monday 08 June 2009 03:52:12 Mauro Carvalho Chehab wrote:
ERROR: do not use assignment in if condition
#64: FILE: linux/drivers/media/video/uvc/uvc_v4l2.c:376:
+ if ((ret = uvc_probe_video(video, probe)) 0)
ERROR: do not use assignment in if condition
#80: FILE: linux/drivers/media/video/uvc/uvc_v4l2.c:872:
+ if ((ret = uvc_acquire_privileges(handle)) 0)
total: 2 errors, 0 warnings, 81 lines checked
Please, one statement per line.
Is there any way I can convince you to accept the
if ((ret = function(...) 0)
I prefer if you fix it, although I won't nack your pull just due to that.
I'll fix the syntax.
syntax on the basis that it's used throughout the rest of the driver ?
:-)
$ find . -type f -name \*.c -exec grep -l 'if (([a-zA-Z]\+ \?= \?[a-zA-
Z_]\+([a-zA-Z0-9 ,*]*)) \?[=]\+ \?[a-zA-Z0-9]\+)' {} \; | wc
307 3079204
I might have missed a few cases. Not that many occurrences.
Try to count the proper coding style over the kernel source code. I bet
they you'll find much more cases of:
ret = function();
if (ret 0) /* and other similar tests, like ret == NULL, ret,
!ret, etc
*/ foo;
Since uvc is part of the kernel, in fact, it is uvcvideo that is adding
more exceptions to the Kernel style.
Damn, I hoped you wouldn't notice that ;-)
I find the
if ((ret = function()) 0)
more compact (which can't be debated) and as easy to read as the alternative,
if not easier (now this can be debated). As this point of view seems to be
minority I'll try to adjust my coding style accordingly. Of course I'll blame
you personally for any bug that it would introduce ;-)
Also, I have a few comments, from API POV.
It doesn't seem that those ioctls are properly implemented. There are
some things there that sounded obfuscated for me, and it you aren't
implementing. Probably because it is not clear enough.
The UVC standard doesn't specify a way to add/remove specific JPEG
segments. As MJPEG has not COM, DRI and DHT segments, I've hardcoded
flags to DQT.
Also, we used to have a similar set of ioctls for MPEG, that were
removed, in favor of the usage of extended controls, with a cleaner
interface.
That's said, instead of adding more support for this obfuscated API,
maybe we could deprecate those in favor of some controls that could
make more sense, and let vidio_ioctl2 provide backward compat for it by
calling the proper controls, just to preserve binary compatibility with
legacy applications.
I have mixed feelings about this. On one hand I agree that
VIDIOC_S_JPEGCOMP is under-specified and should be either properly
document, or deprecate it in favor of a control. On the other hand, the
uvcvideo driver assumes that controls can all be read and written while
streaming is in progress. I suppose other drivers (probably non-MPEG
ones) were written with the same assumption in mind. Using a control to
set JPEG compression would mean that a proper infrastructure would need
to be put in place in those drivers to handle controls that influence
video streaming. I'd appreciate your opinion on that.
I'm in favor of deprecate VIDIOC_S_JPEGCOMP.
The issue you've described of changing the format while streaming exists,
being it a control, or an ioctl. So, it deserves a separate discussion.
-
The MPEG drivers block trials of changing the MPEG format that can't be
done while streaming. On the other hand, user preference controls, like
bright, contrast, (auto)gain, exposure, etc can be done anytime. As most
drivers just exposes such controls, they don't need a logic to block a
control while streaming.
The case of JPEG/MJPEG is similar to MPEG: there are some changes that may
not be possible while streaming. So, such changes should, in thesis, be
blocked.
On the other hand, from users perspective, it seems interesting for they to
start an application and, for example, change the JPEG quality while
streaming, to see what better fits his needs.
Since JPEG is just a set of independent jpeg images, in thesis, it is
possible to change the encoding while streaming, without breaking for
userspace, assuming that the allocated buffers are large enough to support
such changes.
So, IMO, we should try to allow such changes where possible, even by doing
something like this, at the loop that fills the video buffer:
if (streaming frame_is_complete quality_changed) {
stop_streaming();
change_quality();
start_streaming();
}
This can only be done if the allocated buffers are big enough. As the device
reports the required buffer size the driver would have to query the device
before deciding if it allows to change the quality during streaming. Given the
Re: [PATCHv6 5 of 7] FMTx: si4713: Add files to add radio interface for si4713
On Tuesday 09 June 2009 14:02:01 Hans Verkuil wrote:
On Tuesday 09 June 2009 13:11:11 Eduardo Valentin wrote:
Hi Hans,
On Tue, Jun 09, 2009 at 12:41:38PM +0200, ext Hans Verkuil wrote:
snip
+static struct v4l2_ioctl_ops radio_si4713_ioctl_ops = {
+ .vidioc_g_input = radio_si4713_vidioc_g_input,
+ .vidioc_s_input = radio_si4713_vidioc_s_input,
+ .vidioc_g_audio = radio_si4713_vidioc_g_audio,
+ .vidioc_s_audio = radio_si4713_vidioc_s_audio,
+ .vidioc_querycap= radio_si4713_vidioc_querycap,
+ .vidioc_queryctrl = radio_si4713_vidioc_queryctrl,
+ .vidioc_g_ext_ctrls = radio_si4713_vidioc_g_ext_ctrls,
+ .vidioc_s_ext_ctrls = radio_si4713_vidioc_s_ext_ctrls,
+ .vidioc_g_ctrl = radio_si4713_vidioc_g_ctrl,
+ .vidioc_s_ctrl = radio_si4713_vidioc_s_ctrl,
+ .vidioc_g_tuner = radio_si4713_vidioc_g_tuner,
+ .vidioc_s_tuner = radio_si4713_vidioc_s_tuner,
It's a modulator device, so it should implement g/s_modulator rather
than g/s_tuner.
Now, here I am running into a problem: looking at section 1.6.2 in
the v4l2 spec I see that in QUERYCAP you are supposed to return
CAP_TUNER and rely on ENUMOUTPUT to determine which output has a
modulator. I think it is nuts that there is no CAP_MODULATOR. I
propose adding this. There are currently NO modulator drivers in
v4l-dvb, nor have I ever heard from out-of-tree modulator drivers
(not that I particularly care about that), so it should be safe to
add it.
The next problem is that ENUMOUTPUT does not apply to a radio
modulator. This problem is actually also present on radio tuners.
Currently all radio tuner drivers implement g/s_input and g/s_audio
but no enuminput or enumaudio.
I think g/s_input is bogus since these devices have no video inputs.
However, neither g/s_audio nor enumaudio can currently tell the
application whether the audio input is connected to a tuner. Only
enuminput can do that currently. This would be an argument for using
g/s_input if it wasn't for the fact that none of the radio drivers
actually implements enuminput.
I propose adding a V4L2_AUDCAP_TUNER capability telling this
application that the audio input is connected to a tuner, and adding
a
V4L2_AUDOUTCAP_MODULATOR capability for struct v4l2_audioout to do
the same for a modulator.
Comments?
Ok. Here comes the real needed changes to support the radio modulator.
You may not remember, but in previous versions of this series I
commented that this driver was fully based on fm receiver existing
drivers.
I think that's why I went in the mistake of implementing g_audio,
s_audio instead of g_audout, s_audout. Also, the same mistake of
implementing the s,g_input done in fm receiver drivers was repeated
here.
Also, I think another thing has biased me to add this wrong callbacks.
I use fmtools to test the driver, for setting fm freq for instance.
I admit, there are wrong callbacks.
So, I'd ask which application to use to test the driver ?
You have the honor of adding the first modulator driver to the kernel, so
there are no apps yet. That said, I suggest adding support for
g/s_modulator to the v4l2-ctl tool (in v4l2-apps/util). It's the swiss
army knife utility of v4l2 and can call most ioctls from the command
line.
About the suggested changes (adding V4L2_AUDCAP_TUNER and
V4L2_AUDOUTCAP_MODULATOR), I think it is a reasonable way to do it.
However, it'd be nice to hear more opinions. But, if I understood
correctly, this would be the method to determine if the driver is a fm
transmitter (aka modulator) ?
The CAP_MODULATOR capability is used to determine if the driver supports
a modulator, and the new capabilities for v4l2_audio and v4l2_audioout
can be used to determine which audio input/output is hooked up to a tuner
or modulator. In theory there may be multiple inputs and outputs where
some are connected to a tuner/modulator and others are straight
inputs/outputs.
It is common for video capture cards (tuner input vs. Composite/Line-In
inputs), but there is a case to be made that this is very unlikely for
radio tuners/modulators. So perhaps I'm paranoid :-)
Actually, looking at it a bit closer it is not enough to just set the
capability, you also need to set the index of the associated tuner or
modulatory, which would mean using one of the reserved fields.
Hmm, this is getting complicated. Perhaps we should just add a
CAP_MODULATOR capability and leave it at that for now. I think the
MODULATOR capability is really needed, otherwise there is no easy way to
check whether it is a tuner or modulator device.
Regards,
Hans
I've made a separate tree that adds support for a string control type and
for a modulator capability. It also adds modulator
Re: [PULL] http://linuxtv.org/hg/~pinchartl/uvcvideo/
Em Tue, 9 Jun 2009 17:29:58 +0200
Laurent Pinchart laurent.pinch...@skynet.be escreveu:
Since uvc is part of the kernel, in fact, it is uvcvideo that is adding
more exceptions to the Kernel style.
Damn, I hoped you wouldn't notice that ;-)
:)
I find the
if ((ret = function()) 0)
more compact (which can't be debated) and as easy to read as the alternative,
if not easier (now this can be debated). As this point of view seems to be
minority I'll try to adjust my coding style accordingly. Of course I'll blame
you personally for any bug that it would introduce ;-)
It is more compact, and I used to write codes like above in the past. Yet, we
should stick on Kernel style at the kernelspace stuff.
About the readability, a code like:
ret = function;
if (ret 0)
is just a little more readable than on a single line. However, if codes like
the above are accepted, it should be accepted things like:
if ((ret = functionX() * functionY() + 3) 5 + 2 * functionZ())
that would be more complex to read than when broken into two separate
statements:
ret = functionX() * functionY() + 3;
if (ret 5 + 2 * functionZ())
Anyway, since Coding Style is global to the kernel as a hole, it is out of
topic to discuss about the rationale behind each rule, or proposing
improvements here. The proper forum for it is LKML.
Also, I have a few comments, from API POV.
It doesn't seem that those ioctls are properly implemented. There are
some things there that sounded obfuscated for me, and it you aren't
implementing. Probably because it is not clear enough.
The UVC standard doesn't specify a way to add/remove specific JPEG
segments. As MJPEG has not COM, DRI and DHT segments, I've hardcoded
flags to DQT.
Also, we used to have a similar set of ioctls for MPEG, that were
removed, in favor of the usage of extended controls, with a cleaner
interface.
That's said, instead of adding more support for this obfuscated API,
maybe we could deprecate those in favor of some controls that could
make more sense, and let vidio_ioctl2 provide backward compat for it by
calling the proper controls, just to preserve binary compatibility with
legacy applications.
I have mixed feelings about this. On one hand I agree that
VIDIOC_S_JPEGCOMP is under-specified and should be either properly
document, or deprecate it in favor of a control. On the other hand, the
uvcvideo driver assumes that controls can all be read and written while
streaming is in progress. I suppose other drivers (probably non-MPEG
ones) were written with the same assumption in mind. Using a control to
set JPEG compression would mean that a proper infrastructure would need
to be put in place in those drivers to handle controls that influence
video streaming. I'd appreciate your opinion on that.
I'm in favor of deprecate VIDIOC_S_JPEGCOMP.
The issue you've described of changing the format while streaming exists,
being it a control, or an ioctl. So, it deserves a separate discussion.
-
The MPEG drivers block trials of changing the MPEG format that can't be
done while streaming. On the other hand, user preference controls, like
bright, contrast, (auto)gain, exposure, etc can be done anytime. As most
drivers just exposes such controls, they don't need a logic to block a
control while streaming.
The case of JPEG/MJPEG is similar to MPEG: there are some changes that may
not be possible while streaming. So, such changes should, in thesis, be
blocked.
On the other hand, from users perspective, it seems interesting for they to
start an application and, for example, change the JPEG quality while
streaming, to see what better fits his needs.
Since JPEG is just a set of independent jpeg images, in thesis, it is
possible to change the encoding while streaming, without breaking for
userspace, assuming that the allocated buffers are large enough to support
such changes.
So, IMO, we should try to allow such changes where possible, even by doing
something like this, at the loop that fills the video buffer:
if (streaming frame_is_complete quality_changed) {
stop_streaming();
change_quality();
start_streaming();
}
This can only be done if the allocated buffers are big enough. As the device
reports the required buffer size the driver would have to query the device
before deciding if it allows to change the quality during streaming. Given
the
usefulness of changing MJPEG compression quality during streaming, and given
how most webcams seem to ignore the quality anyway, I don't think it would be
worth it at the moment.
Ok.
Should I submit a patch that implement VIDIOC_S_JPEGCOMP support in the UVC
driver and implement a JPEG compression quality control later, or would you
prefer the driver not to implement VIDIOC_S_JPEGCOMP at all ? As there are
existing applications using that
Re: [PULL] http://linuxtv.org/hg/~pinchartl/uvcvideo/
On Tuesday 09 June 2009 17:56:01 Mauro Carvalho Chehab wrote:
Em Tue, 9 Jun 2009 17:29:58 +0200
Laurent Pinchart laurent.pinch...@skynet.be escreveu:
Since uvc is part of the kernel, in fact, it is uvcvideo that is
adding more exceptions to the Kernel style.
Damn, I hoped you wouldn't notice that ;-)
:)
:
I find the
if ((ret = function()) 0)
more compact (which can't be debated) and as easy to read as the
alternative, if not easier (now this can be debated). As this point of
view seems to be minority I'll try to adjust my coding style
accordingly. Of course I'll blame you personally for any bug that it
would introduce ;-)
It is more compact, and I used to write codes like above in the past.
Yet, we should stick on Kernel style at the kernelspace stuff.
About the readability, a code like:
ret = function;
if (ret 0)
is just a little more readable than on a single line. However, if codes
like the above are accepted, it should be accepted things like:
if ((ret = functionX() * functionY() + 3) 5 + 2 * functionZ())
that would be more complex to read than when broken into two separate
statements:
ret = functionX() * functionY() + 3;
if (ret 5 + 2 * functionZ())
Anyway, since Coding Style is global to the kernel as a hole, it is out
of topic to discuss about the rationale behind each rule, or proposing
improvements here. The proper forum for it is LKML.
Also, I have a few comments, from API POV.
It doesn't seem that those ioctls are properly implemented. There
are some things there that sounded obfuscated for me, and it you
aren't implementing. Probably because it is not clear enough.
The UVC standard doesn't specify a way to add/remove specific JPEG
segments. As MJPEG has not COM, DRI and DHT segments, I've
hardcoded flags to DQT.
Also, we used to have a similar set of ioctls for MPEG, that were
removed, in favor of the usage of extended controls, with a
cleaner interface.
That's said, instead of adding more support for this obfuscated
API, maybe we could deprecate those in favor of some controls
that could make more sense, and let vidio_ioctl2 provide backward
compat for it by calling the proper controls, just to preserve
binary compatibility with legacy applications.
I have mixed feelings about this. On one hand I agree that
VIDIOC_S_JPEGCOMP is under-specified and should be either properly
document, or deprecate it in favor of a control. On the other hand,
the uvcvideo driver assumes that controls can all be read and
written while streaming is in progress. I suppose other drivers
(probably non-MPEG ones) were written with the same assumption in
mind. Using a control to set JPEG compression would mean that a
proper infrastructure would need to be put in place in those
drivers to handle controls that influence video streaming. I'd
appreciate your opinion on that.
I'm in favor of deprecate VIDIOC_S_JPEGCOMP.
The issue you've described of changing the format while streaming
exists, being it a control, or an ioctl. So, it deserves a separate
discussion.
-
The MPEG drivers block trials of changing the MPEG format that can't
be done while streaming. On the other hand, user preference controls,
like bright, contrast, (auto)gain, exposure, etc can be done anytime.
As most drivers just exposes such controls, they don't need a logic
to block a control while streaming.
The case of JPEG/MJPEG is similar to MPEG: there are some changes
that may not be possible while streaming. So, such changes should, in
thesis, be blocked.
On the other hand, from users perspective, it seems interesting for
they to start an application and, for example, change the JPEG
quality while streaming, to see what better fits his needs.
Since JPEG is just a set of independent jpeg images, in thesis, it is
possible to change the encoding while streaming, without breaking for
userspace, assuming that the allocated buffers are large enough to
support such changes.
So, IMO, we should try to allow such changes where possible, even by
doing something like this, at the loop that fills the video buffer:
if (streaming frame_is_complete quality_changed) {
stop_streaming();
change_quality();
start_streaming();
}
This can only be done if the allocated buffers are big enough. As the
device reports the required buffer size the driver would have to query
the device before deciding if it allows to change the quality during
streaming. Given the usefulness of changing MJPEG compression quality
during streaming, and given how most webcams seem to ignore the quality
anyway, I don't think it would be worth it at the moment.
Ok.
Should I submit a patch that implement VIDIOC_S_JPEGCOMP support in the
UVC driver and implement a JPEG compression
Re: [RFC] passing bus/interface parameters from bridge driver to sub device
On Tuesday 02 June 2009 19:08:01 Karicheri, Muralidharan wrote:
Hi,
1) I want to use v4l2_i2c_new_probed_subdev_addr() to load and probe the
the v4l2 sub-device from my vpfe capture driver. Currently the api's
available doesn't allow setting platform data in the client before the
sub-device's probe is called. I see that there is discussion about adding
i2c_board_info as an argument to the api. I would need this to allow
loading of sub-device from vpfe capture. I have seen patches sent by
Eduardo Valentin Guennadi Liakhovetski addressing the issue. Do you
have any suggestions for use in my vpfe capture driver?
As you have probably seen by now I've made changes to the v4l2 core that
make it easy to use an i2c_board_info struct when creating a subdev. So as
far as I can tell that solves this issue completely.
The code is in my v4l-dvb-subdev tree.
2) I need a common structure (preferably in i2c-subdev.h for defining and
using bus (interface) parameters in the bridge (vpfe capture) and sub
device (tvp514x or mt9t031) drivers. This will allow bridge driver to
read these values from platform data and set the same in the vpfe capture
driver and sub device drivers. Since bus parameters such as interface
type (BT.656, BT.1120, Raw Bayer image data etc), polarity of various
signals etc are used across bridge and sub-devices, it make sense to add
it to i2c-subdev.h. Here is what I have come up with. If this support is
not already planned, I would like to sent a patch for the same.
It makes sense to define a struct in v4l2-subdev.h and a core ops to set it
(s_bus).
However, I would pack it differently:
struct v4l2_subdev_bus {
enum v4l2_subdev_bus_type type;
u8 width;
unsigned pol_vsync:1;
unsigned pol_hsync:1;
unsigned pol_field:1;
unsigned pol_pclock:1;
};
It's more concise this way.
Regards,
Hans
+/*
+ * Some Sub-devices are connected to the bridge device through a bus
+ * that carries the clock, vsync, hsync and data. Some interfaces
+ * such as BT.656 carries the sync embedded in the data where as others
+ * have seperate line carrying the sync signals. This structure is
+ * used by bridge driver to set the desired bus parameters in the sub
+ * device to work with it.
+ */
+enum v4l2_subdev_bus_type {
+ /* BT.656 interface. Embedded syncs */
+ V4L2_SUBDEV_BUS_BT_656,
+ /* BT.1120 interface. Embedded syncs */
+ V4L2_SUBDEV_BUS_BT_1120,
+ /* 8 bit YCbCr muxed bus, separate sync and field id signals */
+ V4L2_SUBDEV_BUS_YCBCR_8,
+ /* 16 bit YCbCr bus, separate sync and field id signals */
+ V4L2_SUBDEV_BUS_YCBCR_16,
+ /* Raw Bayer data bus, 8 - 16 bit wide, sync signals */
+ V4L2_SUBDEV_BUS_RAW_BAYER
+};
+
+/* Raw bayer data bus width */
+enum v4l2_subdev_raw_bayer_data_width {
+ V4L2_SUBDEV_RAW_BAYER_DATA_8BIT,
+ V4L2_SUBDEV_RAW_BAYER_DATA_9BIT,
+ V4L2_SUBDEV_RAW_BAYER_DATA_10BIT,
+ V4L2_SUBDEV_RAW_BAYER_DATA_11BIT,
+ V4L2_SUBDEV_RAW_BAYER_DATA_12BIT,
+ V4L2_SUBDEV_RAW_BAYER_DATA_13BIT,
+ V4L2_SUBDEV_RAW_BAYER_DATA_14BIT,
+ V4L2_SUBDEV_RAW_BAYER_DATA_15BIT,
+ V4L2_SUBDEV_RAW_BAYER_DATA_16BIT
+};
+
+struct v4l2_subdev_bus_params {
+ /* bus type */
+ enum v4l2_subdev_bus_type type;
+ /* data size for raw bayer data bus */
+ enum v4l2_subdev_raw_bayer_data_width width;
+ /* polarity of vsync. 0 - active low, 1 - active high */
+ u8 vsync_pol;
+ /* polarity of hsync. 0 - active low, 1 - active low */
+ u8 hsync_pol;
+ /* polarity of field id, 0 - low to high, 1 - high to low */
+ u8 fid_pol;
+ /* polarity of data. 0 - active low, 1 - active high */
+ u8 data_pol;
+ /* pclk polarity. 0 - sample at falling edge, 1 - sample at rising edge
*/ + u8 pclk_pol;
+};
+
Murali Karicheri
email: m-kariche...@ti.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
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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] passing bus/interface parameters from bridge driver to sub device
Hans,
Thanks for looking into this...
1) I want to use v4l2_i2c_new_probed_subdev_addr() to load and probe the
the v4l2 sub-device from my vpfe capture driver. Currently the api's
available doesn't allow setting platform data in the client before the
sub-device's probe is called. I see that there is discussion about adding
i2c_board_info as an argument to the api. I would need this to allow
loading of sub-device from vpfe capture. I have seen patches sent by
Eduardo Valentin Guennadi Liakhovetski addressing the issue. Do you
have any suggestions for use in my vpfe capture driver?
As you have probably seen by now I've made changes to the v4l2 core that
make it easy to use an i2c_board_info struct when creating a subdev. So as
far as I can tell that solves this issue completely.
The code is in my v4l-dvb-subdev tree.
[MK] Yes. I have been following this and will resolve this.
2) I need a common structure (preferably in i2c-subdev.h for defining and
using bus (interface) parameters in the bridge (vpfe capture) and sub
device (tvp514x or mt9t031) drivers. This will allow bridge driver to
read these values from platform data and set the same in the vpfe capture
driver and sub device drivers. Since bus parameters such as interface
type (BT.656, BT.1120, Raw Bayer image data etc), polarity of various
signals etc are used across bridge and sub-devices, it make sense to add
it to i2c-subdev.h. Here is what I have come up with. If this support is
not already planned, I would like to sent a patch for the same.
It makes sense to define a struct in v4l2-subdev.h and a core ops to set it
(s_bus).
However, I would pack it differently:
struct v4l2_subdev_bus {
enum v4l2_subdev_bus_type type;
u8 width;
unsigned pol_vsync:1;
unsigned pol_hsync:1;
unsigned pol_field:1;
unsigned pol_pclock:1;
};
[MK] Looks good to me. So is it up to the bridge and sub device to determine
how they interpret the values of pol_xxx fields? Since same sub-device might
work across multiple sub device, it is worth documenting them as given in my
RFC. I would like to add one more field for data polarity :-
unsigned pol_data:1;
Will you take care of this yourself or expecting me to send a patch for the
same?
Regards,
Murali
It's more concise this way.
Regards,
Hans
+/*
+ * Some Sub-devices are connected to the bridge device through a bus
+ * that carries the clock, vsync, hsync and data. Some interfaces
+ * such as BT.656 carries the sync embedded in the data where as others
+ * have seperate line carrying the sync signals. This structure is
+ * used by bridge driver to set the desired bus parameters in the sub
+ * device to work with it.
+ */
+enum v4l2_subdev_bus_type {
+/* BT.656 interface. Embedded syncs */
+V4L2_SUBDEV_BUS_BT_656,
+/* BT.1120 interface. Embedded syncs */
+V4L2_SUBDEV_BUS_BT_1120,
+/* 8 bit YCbCr muxed bus, separate sync and field id signals */
+V4L2_SUBDEV_BUS_YCBCR_8,
+/* 16 bit YCbCr bus, separate sync and field id signals */
+V4L2_SUBDEV_BUS_YCBCR_16,
+/* Raw Bayer data bus, 8 - 16 bit wide, sync signals */
+V4L2_SUBDEV_BUS_RAW_BAYER
+};
+
+/* Raw bayer data bus width */
+enum v4l2_subdev_raw_bayer_data_width {
+V4L2_SUBDEV_RAW_BAYER_DATA_8BIT,
+V4L2_SUBDEV_RAW_BAYER_DATA_9BIT,
+V4L2_SUBDEV_RAW_BAYER_DATA_10BIT,
+V4L2_SUBDEV_RAW_BAYER_DATA_11BIT,
+V4L2_SUBDEV_RAW_BAYER_DATA_12BIT,
+V4L2_SUBDEV_RAW_BAYER_DATA_13BIT,
+V4L2_SUBDEV_RAW_BAYER_DATA_14BIT,
+V4L2_SUBDEV_RAW_BAYER_DATA_15BIT,
+V4L2_SUBDEV_RAW_BAYER_DATA_16BIT
+};
+
+struct v4l2_subdev_bus_params {
+/* bus type */
+enum v4l2_subdev_bus_type type;
+/* data size for raw bayer data bus */
+enum v4l2_subdev_raw_bayer_data_width width;
+/* polarity of vsync. 0 - active low, 1 - active high */
+u8 vsync_pol;
+/* polarity of hsync. 0 - active low, 1 - active low */
+u8 hsync_pol;
+/* polarity of field id, 0 - low to high, 1 - high to low */
+u8 fid_pol;
+/* polarity of data. 0 - active low, 1 - active high */
+u8 data_pol;
+/* pclk polarity. 0 - sample at falling edge, 1 - sample at rising
edge
*/ + u8 pclk_pol;
+};
+
Murali Karicheri
email: m-kariche...@ti.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
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
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 Jun 9 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11930:ed3781a79c73 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29.1-armv5: OK linux-2.6.30-rc7-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-rc7-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-rc7-armv5-omap2: WARNINGS linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-rc7-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-rc7-m32r: OK linux-2.6.22.19-mips: ERRORS linux-2.6.26-mips: ERRORS linux-2.6.27-mips: ERRORS linux-2.6.28-mips: ERRORS linux-2.6.29.1-mips: ERRORS linux-2.6.30-rc7-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-rc7-powerpc64: WARNINGS 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: OK linux-2.6.30-rc7-x86_64: WARNINGS sparse (linux-2.6.29.1): OK sparse (linux-2.6.30-rc7): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS 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: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS 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 V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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
Green screen and barf with HP Webcam (15b8:6002)
I've been trying to get an HP webcam (usbid 15b8:6002) running on my GFs machine. She's running Ubuntu Hardy with 2.6.24-24-generic kernel. I downloaded the mercurial repo for v4l-dvb. It compiled without complaint and the modules load without complaint. I've got it running on Ubuntu Jaunty with 2.6.28-11-generic and it seems to work fine. I've been using Skype as my test platform. I noticed on Jaunty that Skype is now wrapped with the v4l1compat.so library, so I tried doing that, but the results were the same. Is there anything I can try short of upgrading my distro or kernel? James -- 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: [PULL] http://linuxtv.org/hg/~pinchartl/uvcvideo/
Em Tue, 9 Jun 2009 18:08:38 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Should I submit a patch that implement VIDIOC_S_JPEGCOMP support in the UVC driver and implement a JPEG compression quality control later, or would you prefer the driver not to implement VIDIOC_S_JPEGCOMP at all ? As there are existing applications using that ioctl a few users are pushing for VIDIOC_S_JPEGCOMP support. I prefer the later. Adding a new ioctl support just to deprecate it on the next kernel doesn't seem nice. Let's add directly the newer controls and add a patch marking this as deprecated. I'm not sure whether we can deprecate JPEGCOMP. It is used in too many places. Perhaps we should create a set of JPEG controls that match what is in v4l2_jpegcompression and convert all the drivers that use JPEGCOMP to these new controls. Then the v4l core can map S/G_JPEGCOMP ioctls to a set of control read/writes. I'm working on string control support, so that will allow us to handle the APP_data and COM_data fields. This seems to be the correct approach. Implement it as controls, and let video_ioctl2 to handle the calls to the legacy ioctls, while marking it as deprecate. 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
[PATCH 0/10 - v2] ARM: DaVinci: Video: DM355/DM6446 VPFE Capture driver
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com VPFE Capture driver for DaVinci Media SOCs :- DM355 and DM6446 This is the version v2 of the patch series. This is the reworked version of the driver based on comments received against the last version of the patch. +++ These patches add support for VPFE (Video Processing Front End) based video capture on DM355 and DM6446 EVMs. For more details on the hardware configuration and capabilities, please refer the vpfe_capture.c header. This patch set consists of following:- Patch 1: VPFE Capture bridge driver Patch 2: CCDC hw device header file Patch 3: DM355 CCDC hw module Patch 4: DM644x CCDC hw module Patch 5: common types used across CCDC modules Patch 6: Makefile and config files for the driver Patch 7: DM355 platform and board setup Patch 8: DM644x platform and board setup Patch 9: Remove outdated driver files from davinci git tree Patch 10: common vpss hw module for video drivers NOTE: Dependent on the TVP514x decoder driver patch for migrating the driver to sub device model from Vaibhav Hiremath Following tests are performed. 1) Capture and display video (PAL NTSC) from tvp5146 decoder. Displayed using fbdev device driver available on davinci git tree 2) Tested with driver built statically and dynamically Muralidhara Karicheri Reviewed By Hans Verkuil. Reviewed By Laurent Pinchart. Signed-off-by: Muralidharan Karicheri m-kariche...@ti.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
[PATCH 4/10 - v2] dm644x ccdc module for vpfe capture driver
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
DM644x CCDC hw module
This is the hw module for DM644x CCDC. This registers with the
vpfe capture driver and provides a set of hw_ops to configure
CCDC for a specific decoder device connected to the VPFE
Following are some of the major comments addressed :-
1) removed vpss configration from this module to a standalone
vpss module that can be used by other video drivers as well
2) replaced magic numbers with #defines
3) cleaned up and refractored ccdc_config_raw()
4) embedded config part of the variables inside
ccdc_params_raw to help in memcpy.
5) avoided generic names for ccdc types in include file by
prefixing with ccdc_
Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
drivers/media/video/davinci/dm644x_ccdc.c | 876
drivers/media/video/davinci/dm644x_ccdc_regs.h | 145
include/media/davinci/dm644x_ccdc.h| 184 +
3 files changed, 1205 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/dm644x_ccdc.c
create mode 100644 drivers/media/video/davinci/dm644x_ccdc_regs.h
create mode 100644 include/media/davinci/dm644x_ccdc.h
diff --git a/drivers/media/video/davinci/dm644x_ccdc.c
b/drivers/media/video/davinci/dm644x_ccdc.c
new file mode 100644
index 000..4f81f69
--- /dev/null
+++ b/drivers/media/video/davinci/dm644x_ccdc.c
@@ -0,0 +1,876 @@
+/*
+ * Copyright (C) 2006-2009 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * CCDC hardware module for DM6446
+ * --
+ *
+ * This module is for configuring CCD controller of DM6446 VPFE to capture
+ * Raw yuv or Bayer RGB data from a decoder. CCDC has several modules
+ * such as Defect Pixel Correction, Color Space Conversion etc to
+ * pre-process the Raw Bayer RGB data, before writing it to SDRAM. This
+ * module also allows application to configure individual
+ * module parameters through VPFE_CMD_S_CCDC_RAW_PARAMS IOCTL.
+ * To do so, application includes dm644x_ccdc.h and vpfe_capture.h header
+ * files. The setparams() API is called by vpfe_capture driver
+ * to configure module parameters. This file is named DM644x so that other
+ * variants such DM6443 may be supported using the same module.
+ *
+ * TODO: Test Raw bayer parameter settings and bayer capture
+ * Split module parameter structure to module specific ioctl structs
+ * investigate if enum used for user space type definition
+ * to be replaced by #defines or integer
+ */
+#include linux/platform_device.h
+#include linux/uaccess.h
+#include linux/videodev2.h
+#include media/davinci/dm644x_ccdc.h
+#include media/davinci/vpss.h
+#include dm644x_ccdc_regs.h
+#include ccdc_hw_device.h
+
+static struct device *dev;
+
+/* Object for CCDC raw mode */
+static struct ccdc_params_raw ccdc_hw_params_raw = {
+ .pix_fmt = CCDC_PIXFMT_RAW,
+ .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+ .win = CCDC_WIN_VGA,
+ .fid_pol = VPFE_PINPOL_POSITIVE,
+ .vd_pol = VPFE_PINPOL_POSITIVE,
+ .hd_pol = VPFE_PINPOL_POSITIVE,
+ .config_params = {
+ .data_sz = CCDC_DATA_10BITS,
+ },
+};
+
+/* Object for CCDC ycbcr mode */
+static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
+ .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
+ .frm_fmt = CCDC_FRMFMT_INTERLACED,
+ .win = CCDC_WIN_PAL,
+ .fid_pol = VPFE_PINPOL_POSITIVE,
+ .vd_pol = VPFE_PINPOL_POSITIVE,
+ .hd_pol = VPFE_PINPOL_POSITIVE,
+ .bt656_enable = 1,
+ .pix_order = CCDC_PIXORDER_CBYCRY,
+ .buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED
+};
+
+#define CCDC_MAX_RAW_YUV_FORMATS 2
+
+/* Raw Bayer formats */
+static u32 ccdc_raw_bayer_pix_formats[] =
+ {V4L2_PIX_FMT_SBGGR8, V4L2_PIX_FMT_SBGGR16};
+
+/* Raw YUV formats */
+static u32 ccdc_raw_yuv_pix_formats[] =
+ {V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_YUYV};
+
+static void *__iomem ccdc_base_addr;
+static int ccdc_addr_size;
+static enum vpfe_hw_if_type ccdc_if_type;
+
+/* register access routines */
+static inline u32 regr(u32 offset)
+{
+ return
[PATCH 3/10 - v2] dm355 ccdc module for vpfe capture driver
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
DM355 CCDC hw module
Adds ccdc hw module for DM355 CCDC. This registers with the bridge
driver a set of hw_ops for configuring the CCDC for a specific
decoder device connected to vpfe.
Following are some of the major comments addressed :-
1) removed vpss configration from this module to a standalone
vpss module that can be used by other video drivers as well
2) replaced magic numbers with #defines
3) cleaned up and refractored ccdc_config_raw()
4) embedded config part of the variables inside
ccdc_params_raw to help in memcpy.
5) avoided generic names for ccdc types in include file by
prefixing with ccdc_
Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
drivers/media/video/davinci/dm355_ccdc.c | 1161 +
drivers/media/video/davinci/dm355_ccdc_regs.h | 310 +++
include/media/davinci/dm355_ccdc.h| 336 +++
3 files changed, 1807 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/dm355_ccdc.c
create mode 100644 drivers/media/video/davinci/dm355_ccdc_regs.h
create mode 100644 include/media/davinci/dm355_ccdc.h
diff --git a/drivers/media/video/davinci/dm355_ccdc.c
b/drivers/media/video/davinci/dm355_ccdc.c
new file mode 100644
index 000..1e7152e
--- /dev/null
+++ b/drivers/media/video/davinci/dm355_ccdc.c
@@ -0,0 +1,1161 @@
+/*
+ * Copyright (C) 2005-2009 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * CCDC hardware module for DM355
+ * --
+ *
+ * This module is for configuring DM355 CCD controller of VPFE to capture
+ * Raw yuv or Bayer RGB data from a decoder. CCDC has several modules
+ * such as Defect Pixel Correction, Color Space Conversion etc to
+ * pre-process the Bayer RGB data, before writing it to SDRAM. This
+ * module also allows application to configure individual
+ * module parameters through VPFE_CMD_S_CCDC_RAW_PARAMS IOCTL.
+ * To do so, application include dm355_ccdc.h and vpfe_capture.h header
+ * files. The setparams() API is called by vpfe_capture driver
+ * to configure module parameters
+ *
+ * TODO: 1) Raw bayer parameter settings and bayer capture
+ * 2) Split module parameter structure to module specific ioctl structs
+ * 3) add support for lense shading correction
+ * 4) investigate if enum used for user space type definition
+ * to be replaced by #defines or integer
+ */
+#include linux/platform_device.h
+#include linux/uaccess.h
+#include linux/videodev2.h
+#include media/davinci/dm355_ccdc.h
+#include media/davinci/vpss.h
+#include dm355_ccdc_regs.h
+#include ccdc_hw_device.h
+
+static struct device *dev;
+
+/* Object for CCDC raw mode */
+static struct ccdc_params_raw ccdc_hw_params_raw = {
+ .pix_fmt = CCDC_PIXFMT_RAW,
+ .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+ .win = CCDC_WIN_VGA,
+ .fid_pol = VPFE_PINPOL_POSITIVE,
+ .vd_pol = VPFE_PINPOL_POSITIVE,
+ .hd_pol = VPFE_PINPOL_POSITIVE,
+ .gain = {
+ .r_ye = 256,
+ .gb_g = 256,
+ .gr_cy = 256,
+ .b_mg = 256
+ },
+ .config_params = {
+ .datasft = 2,
+ .data_sz = CCDC_DATA_10BITS,
+ .mfilt1 = CCDC_NO_MEDIAN_FILTER1,
+ .mfilt2 = CCDC_NO_MEDIAN_FILTER2,
+ .alaw = {
+ .gama_wd = 2,
+ },
+ .blk_clamp = {
+ .sample_pixel = 1,
+ .dc_sub = 25
+ },
+ .col_pat_field0 = {
+ .olop = CCDC_GREEN_BLUE,
+ .olep = CCDC_BLUE,
+ .elop = CCDC_RED,
+ .elep = CCDC_GREEN_RED
+ },
+ .col_pat_field1 = {
+ .olop = CCDC_GREEN_BLUE,
+ .olep = CCDC_BLUE,
+ .elop = CCDC_RED,
+ .elep = CCDC_GREEN_RED
+ },
+ },
+};
+
+
+/* Object for CCDC ycbcr mode */
+static struct
[PATCH 5/10 - v2] ccdc hw device header file for vpfe capture
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
CCDC hw device header file
Adds ccdc hw device header for vpfe capture driver
Incorporated review comments against previous patch
Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
drivers/media/video/davinci/ccdc_hw_device.h | 110 ++
1 files changed, 110 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/ccdc_hw_device.h
diff --git a/drivers/media/video/davinci/ccdc_hw_device.h
b/drivers/media/video/davinci/ccdc_hw_device.h
new file mode 100644
index 000..86b9b35
--- /dev/null
+++ b/drivers/media/video/davinci/ccdc_hw_device.h
@@ -0,0 +1,110 @@
+/*
+ * Copyright (C) 2008-2009 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * ccdc device API
+ */
+#ifndef _CCDC_HW_DEVICE_H
+#define _CCDC_HW_DEVICE_H
+
+#ifdef __KERNEL__
+#include linux/videodev2.h
+#include linux/device.h
+#include media/davinci/vpfe_types.h
+#include media/davinci/ccdc_types.h
+
+/*
+ * ccdc hw operations
+ */
+struct ccdc_hw_ops {
+ /* Pointer to initialize function to initialize ccdc device */
+ int (*open) (struct device *dev);
+ /* Pointer to deinitialize function */
+ int (*close) (struct device *dev);
+ /* set ccdc base address */
+ void (*set_ccdc_base)(void *base, int size);
+ /* Pointer to function to enable or disable ccdc */
+ void (*enable) (int en);
+ /* reset sbl. only for 6446 */
+ void (*reset) (void);
+ /* enable output to sdram */
+ void (*enable_out_to_sdram) (int en);
+ /* Pointer to function to set hw parameters */
+ int (*set_hw_if_params) (struct vpfe_hw_if_param *param);
+ /* get interface parameters */
+ int (*get_hw_if_params) (struct vpfe_hw_if_param *param);
+ /*
+* Pointer to function to set parameters. Used
+* for implementing VPFE_S_CCDC_PARAMS
+*/
+ int (*set_params) (void *params);
+ /*
+* Pointer to function to get parameter. Used
+* for implementing VPFE_G_CCDC_PARAMS
+*/
+ int (*get_params) (void *params);
+ /* Pointer to function to configure ccdc */
+ int (*configure) (void);
+
+ /* Pointer to function to set buffer type */
+ int (*set_buftype) (enum ccdc_buftype buf_type);
+ /* Pointer to function to get buffer type */
+ enum ccdc_buftype (*get_buftype) (void);
+ /* Pointer to function to set frame format */
+ int (*set_frame_format) (enum ccdc_frmfmt frm_fmt);
+ /* Pointer to function to get frame format */
+ enum ccdc_frmfmt (*get_frame_format) (void);
+ /* enumerate hw pix formats */
+ int (*enum_pix)(u32 *hw_pix, int i);
+ /* Pointer to function to set buffer type */
+ u32 (*get_pixel_format) (void);
+ /* Pointer to function to get pixel format. */
+ int (*set_pixel_format) (u32 pixfmt);
+ /* Pointer to function to set image window */
+ int (*set_image_window) (struct v4l2_rect *win);
+ /* Pointer to function to set image window */
+ void (*get_image_window) (struct v4l2_rect *win);
+ /* Pointer to function to get line length */
+ unsigned int (*get_line_length) (void);
+
+ /* Query CCDC control IDs */
+ int (*queryctrl)(struct v4l2_queryctrl *qctrl);
+ /* Set CCDC control */
+ int (*set_control)(struct v4l2_control *ctrl);
+ /* Get CCDC control */
+ int (*get_control)(struct v4l2_control *ctrl);
+
+ /* Pointer to function to set frame buffer address */
+ void (*setfbaddr) (unsigned long addr);
+ /* Pointer to function to get field id */
+ int (*getfid) (void);
+};
+
+struct ccdc_hw_device {
+ /* ccdc device name */
+ char name[32];
+ /* module owner */
+ struct module *owner;
+ /* hw ops */
+ struct ccdc_hw_ops hw_ops;
+};
+
+/* Used by CCDC module to register unregister with vpfe capture driver */
+int vpfe_register_ccdc_device(struct ccdc_hw_device *dev);
+void vpfe_unregister_ccdc_device(struct ccdc_hw_device *dev);
+
+#endif
+#endif
--
1.6.0.4
--
To unsubscribe from this list:
[PATCH 5/10 - v2] ccdc types used across ccdc modules for vpfe capture driver
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
common types used across CCDC modules
No change from last version
Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
include/media/davinci/ccdc_types.h | 43
1 files changed, 43 insertions(+), 0 deletions(-)
create mode 100644 include/media/davinci/ccdc_types.h
diff --git a/include/media/davinci/ccdc_types.h
b/include/media/davinci/ccdc_types.h
new file mode 100644
index 000..5773874
--- /dev/null
+++ b/include/media/davinci/ccdc_types.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2008-2009 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ **/
+#ifndef _CCDC_TYPES_H
+#define _CCDC_TYPES_H
+enum ccdc_pixfmt {
+ CCDC_PIXFMT_RAW,
+ CCDC_PIXFMT_YCBCR_16BIT,
+ CCDC_PIXFMT_YCBCR_8BIT
+};
+
+enum ccdc_frmfmt {
+ CCDC_FRMFMT_PROGRESSIVE,
+ CCDC_FRMFMT_INTERLACED
+};
+
+/* PIXEL ORDER IN MEMORY from LSB to MSB */
+/* only applicable for 8-bit input mode */
+enum ccdc_pixorder {
+ CCDC_PIXORDER_YCBYCR,
+ CCDC_PIXORDER_CBYCRY,
+};
+
+enum ccdc_buftype {
+ CCDC_BUFTYPE_FLD_INTERLEAVED,
+ CCDC_BUFTYPE_FLD_SEPARATED
+};
+#endif
--
1.6.0.4
--
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 6/10 - v2] Makefile and config files for vpfe capture driver
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com Makefile and config files for the driver This adds Makefile and Kconfig changes to build vpfe capture driver. Added configuration variable for vpss driver based on last review Reviewed By Hans Verkuil. Reviewed By Laurent Pinchart. Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com --- Applies to v4l-dvb repository drivers/media/video/Kconfig | 49 ++ drivers/media/video/Makefile |1 + drivers/media/video/davinci/Makefile |9 ++ 3 files changed, 59 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/davinci/Makefile diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 9d48da2..ee6806c 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -479,6 +479,55 @@ config VIDEO_VIVI Say Y here if you want to test video apps or debug V4L devices. In doubt, say N. +config VIDEO_VPSS_SYSTEM + tristate VPSS System module driver + depends on ARCH_DAVINCI + help + Support for vpss system module for video driver + default y + +config VIDEO_VPFE_CAPTURE + tristate VPFE Video Capture Driver + depends on VIDEO_V4L2 ARCH_DAVINCI + select VIDEOBUF_DMA_CONTIG + help + Support for DM VPFE based frame grabber. This is the + common V4L2 module for following DMXXX SoCs from Texas + Instruments:- DM6446 DM355. + + To compile this driver as a module, choose M here: the + module will be called vpfe-capture. + +config VIDEO_DM6446_CCDC + tristate DM6446 CCDC HW module + depends on ARCH_DAVINCI_DM644x VIDEO_VPFE_CAPTURE + select VIDEO_VPSS_SYSTEM + default y + help + Enables DaVinci CCD hw module. DaVinci CCDC hw interfaces + with decoder modules such as TVP5146 over BT656 or + sensor module such as MT9T001 over a raw interface. This + module configures the interface and CCDC/ISIF to do + video frame capture from slave decoders. + + To compile this driver as a module, choose M here: the + module will be called vpfe. + +config VIDEO_DM355_CCDC + tristate DM355 CCDC HW module + depends on ARCH_DAVINCI_DM355 VIDEO_VPFE_CAPTURE + select VIDEO_VPSS_SYSTEM + default y + help + Enables DM355 CCD hw module. DM355 CCDC hw interfaces + with decoder modules such as TVP5146 over BT656 or + sensor module such as MT9T001 over a raw interface. This + module configures the interface and CCDC/ISIF to do + video frame capture from a slave decoders + + To compile this driver as a module, choose M here: the + module will be called vpfe. + source drivers/media/video/bt8xx/Kconfig config VIDEO_PMS diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 3f1a035..bc8ac8e 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -147,6 +147,7 @@ obj-$(CONFIG_SOC_CAMERA_MT9V022)+= mt9v022.o obj-$(CONFIG_SOC_CAMERA_OV772X)+= ov772x.o obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o obj-$(CONFIG_SOC_CAMERA_TW9910)+= tw9910.o +obj-$(CONFIG_ARCH_DAVINCI)+= davinci/ obj-$(CONFIG_VIDEO_AU0828) += au0828/ diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile new file mode 100644 index 000..b84a405 --- /dev/null +++ b/drivers/media/video/davinci/Makefile @@ -0,0 +1,9 @@ +# +# Makefile for the davinci video device drivers. +# + +# Capture: DM6446 and DM355 +obj-$(CONFIG_VIDEO_VPSS_SYSTEM) += vpss.o +obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o +obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o +obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o -- 1.6.0.4 -- 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 7/10 - v2] DM355 platform changes for vpfe capture driver
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
DM355 platform and board setup
This has platform and board setup changes to support vpfe capture
driver for DM355 EVMs.
Added registration of vpss platform driver based on last review
Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to Davinci GIT Tree
arch/arm/mach-davinci/board-dm355-evm.c| 72 +++-
arch/arm/mach-davinci/dm355.c | 83
arch/arm/mach-davinci/include/mach/dm355.h |2 +
arch/arm/mach-davinci/include/mach/mux.h |9 +++
4 files changed, 163 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index 5ac2f56..cf87e21 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -20,6 +20,8 @@
#include linux/io.h
#include linux/gpio.h
#include linux/clk.h
+#include linux/videodev2.h
+#include media/tvp514x.h
#include linux/spi/spi.h
#include linux/spi/eeprom.h
@@ -134,12 +136,23 @@ static void dm355evm_mmcsd_gpios(unsigned gpio)
dm355evm_mmc_gpios = gpio;
}
+#define TVP5146_I2C_ADDR 0x5D
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity = 1,
+ .vs_polarity = 1
+};
+
static struct i2c_board_info dm355evm_i2c_info[] = {
- { I2C_BOARD_INFO(dm355evm_msp, 0x25),
+ { I2C_BOARD_INFO(dm355evm_msp, 0x25),
.platform_data = dm355evm_mmcsd_gpios,
- /* plus irq */ },
+ },
+ {
+ I2C_BOARD_INFO(tvp5146, TVP5146_I2C_ADDR),
+ .platform_data = tvp5146_pdata,
+ },
+ /* { plus irq }, */
/* { I2C_BOARD_INFO(tlv320aic3x, 0x1b), }, */
- /* { I2C_BOARD_INFO(tvp5146, 0x5d), }, */
};
static void __init evm_init_i2c(void)
@@ -178,6 +191,57 @@ static struct platform_device dm355evm_dm9000 = {
.num_resources = ARRAY_SIZE(dm355evm_dm9000_rsrc),
};
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = COMPOSITE,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = SVIDEO,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct v4l2_routing tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI2B,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+ {
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+ {
+ .name = tvp5146,
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ }
+};
+
+static struct vpfe_config vpfe_cfg = {
+ .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+ .sub_devs = vpfe_sub_devs,
+ .card_name = DM355 EVM,
+ .ccdc = DM355 CCDC,
+};
+
static struct platform_device *davinci_evm_devices[] __initdata = {
dm355evm_dm9000,
davinci_nand_device,
@@ -189,6 +253,8 @@ static struct davinci_uart_config uart_config __initdata = {
static void __init dm355_evm_map_io(void)
{
+ /* setup input configuration for VPFE input devices */
+ dm355_set_vpfe_config(vpfe_cfg);
dm355_init();
}
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 9baeed3..3263af8 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -481,6 +481,14 @@ INT_CFG(DM355, INT_EDMA_TC1_ERR, 4,1,1,
false)
EVT_CFG(DM355, EVT8_ASP1_TX,0,1,0, false)
EVT_CFG(DM355, EVT9_ASP1_RX,1,1,0, false)
EVT_CFG(DM355, EVT26_MMC0_RX, 2,1,0, false)
+
+MUX_CFG(DM355, VIN_PCLK, 0, 14,1,1, false)
+MUX_CFG(DM355, VIN_CAM_WEN,0, 13,1,1, false)
+MUX_CFG(DM355, VIN_CAM_VD, 0, 12,1,1, false)
+MUX_CFG(DM355, VIN_CAM_HD, 0, 11,1,1, false)
+MUX_CFG(DM355, VIN_YIN_EN, 0, 10,1,1, false)
+MUX_CFG(DM355, VIN_CINL_EN,0, 0, 0xff, 0x55,false)
+MUX_CFG(DM355, VIN_CINH_EN,0, 8, 3,3, false)
#endif
};
@@ -623,6 +631,67 @@ static struct platform_device dm355_edma_device = {
.resource =
[PATCH 8/10 - v2] DM6446 platform changes for vpfe capture driver
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
DM644x platform and board setup
This adds plarform and board setup changes required to support
vpfe capture driver on DM644x
Added registration of vpss platform driver based on last comment
Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to Davinci GIT Tree
arch/arm/mach-davinci/board-dm644x-evm.c| 68 ++-
arch/arm/mach-davinci/dm644x.c | 56 ++
arch/arm/mach-davinci/include/mach/dm644x.h |2 +
3 files changed, 124 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index d9d4045..13b73a7 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -28,7 +28,8 @@
#include linux/io.h
#include linux/phy.h
#include linux/clk.h
-
+#include linux/videodev2.h
+#include media/tvp514x.h
#include asm/setup.h
#include asm/mach-types.h
@@ -195,6 +196,57 @@ static struct platform_device davinci_fb_device = {
.num_resources = 0,
};
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = COMPOSITE,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = SVIDEO,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct v4l2_routing tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI2B,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+ {
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+ {
+ .name = tvp5146,
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ },
+};
+
+static struct vpfe_config vpfe_cfg = {
+ .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+ .sub_devs = vpfe_sub_devs,
+ .card_name = DM6446 EVM,
+ .ccdc = DM6446 CCDC,
+};
+
static struct platform_device rtc_dev = {
.name = rtc_davinci_evm,
.id = -1,
@@ -447,6 +499,13 @@ static struct at24_platform_data eeprom_info = {
.context= (void *)0x7f00,
};
+#define TVP5146_I2C_ADDR (0x5D)
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity = 1,
+ .vs_polarity = 1
+};
+
/*
* MSP430 supports RTC, card detection, input from IR remote, and
* a bit more. It triggers interrupts on GPIO(7) from pressing
@@ -558,9 +617,12 @@ static struct i2c_board_info __initdata i2c_info[] = {
I2C_BOARD_INFO(24c256, 0x50),
.platform_data = eeprom_info,
},
+ {
+ I2C_BOARD_INFO(tvp5146, TVP5146_I2C_ADDR),
+ .platform_data = tvp5146_pdata,
+ },
/* ALSO:
* - tvl320aic33 audio codec (0x1b)
-* - tvp5146 video decoder (0x5d)
*/
};
@@ -591,6 +653,8 @@ static struct davinci_uart_config uart_config __initdata = {
static void __init
davinci_evm_map_io(void)
{
+ /* setup input configuration for VPFE input devices */
+ dm644x_set_vpfe_config(vpfe_cfg);
dm644x_init();
}
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 1b3aec8..444c4df 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -549,6 +549,59 @@ static struct platform_device dm644x_edma_device = {
.resource = edma_resources,
};
+static struct resource dm644x_vpss_resources[] = {
+ {
+ /* VPSS Base address */
+ .name = vpss,
+ .start = 0x01c73400,
+ .end= 0x01c73400 + 0xff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device dm644x_vpss_device = {
+ .name = vpss,
+ .id = -1,
+ .dev.platform_data = dm644x_vpss,
+ .num_resources = ARRAY_SIZE(dm644x_vpss_resources),
+ .resource = dm644x_vpss_resources,
+};
+
+static struct resource vpfe_resources[] = {
+ {
+ .start = IRQ_VDINT0,
+ .end= IRQ_VDINT0,
+
[PATCH 9/10 - v2] remove outdated video driver files of dm6446
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
Remove outdated driver files from davinci git tree
No change from last patch
Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to Davinci GIT Tree
drivers/media/video/ccdc_davinci.c | 124
drivers/media/video/davinci_vpfe.c | 1136
include/media/ccdc_davinci.h | 144 -
include/media/davinci_vpfe.h | 121
4 files changed, 0 insertions(+), 1525 deletions(-)
delete mode 100644 drivers/media/video/ccdc_davinci.c
delete mode 100644 drivers/media/video/davinci_vpfe.c
delete mode 100644 include/media/ccdc_davinci.h
delete mode 100644 include/media/davinci_vpfe.h
diff --git a/drivers/media/video/ccdc_davinci.c
b/drivers/media/video/ccdc_davinci.c
deleted file mode 100644
index d3cd333..000
--- a/drivers/media/video/ccdc_davinci.c
+++ /dev/null
@@ -1,124 +0,0 @@
-/*
- *
- *
- * Copyright (C) 2006 Texas Instruments Inc
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-/* ccdc_davinci.c */
-
-#include media/ccdc_davinci.h
-#define debug_print(x...) //printk(x)
-void ccdc_reset()
-{
- int i;
- /* disable CCDC */
- ccdc_enable(0);
- /* set all registers to default value */
- for (i = 0; i = 0x94; i += 4) {
- regw(0, i);
- }
- regw(0, PCR);
- regw(0, SYN_MODE);
- regw(0, HD_VD_WID);
- regw(0, PIX_LINES);
- regw(0, HORZ_INFO);
- regw(0, VERT_START);
- regw(0, VERT_LINES);
- regw(0x00ff, CULLING);
- regw(0, HSIZE_OFF);
- regw(0, SDOFST);
- regw(0, SDR_ADDR);
- regw(0, VDINT);
- regw(0, REC656IF);
- regw(0, CCDCFG);
- regw(0, FMTCFG);
- regw(0, VP_OUT);
-}
-
-void ccdc_setwin(ccdc_params_ycbcr * params)
-{
- int horz_start, horz_nr_pixels;
- int vert_start, vert_nr_lines;
-
- /* configure horizonal and vertical starts and sizes */
- horz_start = params-win.left 1;
- horz_nr_pixels = (params-win.width 1) - 1;
- regw((horz_start 16) | horz_nr_pixels, HORZ_INFO);
-
- vert_start = params-win.top;
-
- if (params-frm_fmt == CCDC_FRMFMT_INTERLACED) {
- vert_nr_lines = (params-win.height 1) - 1;
- vert_start = 1;
- } else {
- vert_nr_lines = params-win.height - 1;
- }
- regw((vert_start 16) | vert_start, VERT_START);
- regw(vert_nr_lines, VERT_LINES);
-}
-
-void ccdc_config_ycbcr(ccdc_params_ycbcr * params)
-{
- u32 syn_mode;
-
- /* first reset the CCDC */
- /* all registers have default values after reset */
- /* This is important since we assume default values to be set in */
- /* a lot of registers that we didn't touch */
- ccdc_reset();
-
- /* configure pixel format */
- syn_mode = (params-pix_fmt 0x3) 12;
-
- /* configure video frame format */
- syn_mode |= (params-frm_fmt 0x1) 7;
-
- /* setup BT.656 sync mode */
- if (params-bt656_enable) {
- regw(3, REC656IF);
-
- /* configure the FID, VD, HD pin polarity */
- /* fld,hd pol positive, vd negative, 8-bit pack mode */
- syn_mode |= 0x0F04;
- } else {/* y/c external sync mode */
- syn_mode |= ((params-fid_pol 0x1) 4);
- syn_mode |= ((params-hd_pol 0x1) 3);
- syn_mode |= ((params-vd_pol 0x1) 2);
- }
-
- /* configure video window */
- ccdc_setwin(params);
-
- /* configure the order of y cb cr in SD-RAM */
- regw((params-pix_order 11) | 0x8000, CCDCFG);
-
- /* configure the horizontal line offset */
- /* this is done by rounding up width to a multiple of 16 pixels */
- /* and multiply by two to account for y:cb:cr 4:2:2 data */
- regw(((params-win.width * 2) + 31) 0xffe0, HSIZE_OFF);
-
- /* configure the memory line offset */
- if (params-buf_type == CCDC_BUFTYPE_FLD_INTERLEAVED) {
- /* two fields are interleaved in memory */
- regw(0x0249, SDOFST);
-
[PATCH 10/10 - v2] common vpss module for video drivers
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.
This is a new module added for vpss library functions that are
used configuring vpss system module. All video drivers will
include vpss.h header and call functions defined in this module
to configure vpss system module.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
drivers/media/video/davinci/vpss.c | 291
include/media/davinci/vpss.h | 69 +
2 files changed, 360 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpss.c
create mode 100644 include/media/davinci/vpss.h
diff --git a/drivers/media/video/davinci/vpss.c
b/drivers/media/video/davinci/vpss.c
new file mode 100644
index 000..9480256
--- /dev/null
+++ b/drivers/media/video/davinci/vpss.c
@@ -0,0 +1,291 @@
+/*
+ * Copyright (C) 2009 Texas Instruments.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ * common vpss driver for all video drivers.
+ */
+#include linux/kernel.h
+#include linux/sched.h
+#include linux/init.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/spinlock.h
+#include linux/compiler.h
+#include linux/io.h
+#include mach/cpu.h
+#include mach/hardware.h
+#include media/davinci/vpss.h
+
+/* DM644x defines */
+#define DM644X_SBL_PCR_VPSS(4)
+
+/* vpss BL register offsets */
+#define DM355_VPSSBL_CCDCMUX 0x1c
+/* vpss CLK register offsets */
+#define DM355_VPSSCLK_CLKCTRL 0x04
+/* masks and shifts */
+#define VPSS_HSSISEL_SHIFT 4
+
+/*
+ * vpss operations. Depends on platform. Not all functions are available
+ * on all platforms. The api, first check if a functio is available before
+ * invoking it. In the probe, the function ptrs are intialized based on
+ * vpss name. vpss name can be dm355_vpss, dm644x_vpss etc.
+ */
+struct vpss_hw_ops {
+ /* enable clock */
+ int (*enable_clock)(enum vpss_clock_sel clock_sel, int en);
+ /* select input to ccdc */
+ void (*select_ccdc_source)(enum vpss_ccdc_source_sel src_sel);
+ /* clear wbl overlflow bit */
+ int (*clear_wbl_overflow)(enum vpss_wbl_sel wbl_sel);
+};
+
+/* vpss configuration */
+struct vpss_oper_config {
+ __iomem void *vpss_bl_regs_base;
+ __iomem void *vpss_regs_base;
+ struct resource *r1;
+ resource_size_t len1;
+ struct resource *r2;
+ resource_size_t len2;
+ char vpss_name[32];
+ spinlock_t vpss_lock;
+ struct vpss_hw_ops hw_ops;
+};
+
+static struct vpss_oper_config oper_cfg;
+
+/* register access routines */
+static inline u32 bl_regr(u32 offset)
+{
+ return __raw_readl(oper_cfg.vpss_bl_regs_base + offset);
+}
+
+static inline void bl_regw(u32 val, u32 offset)
+{
+ __raw_writel(val, oper_cfg.vpss_bl_regs_base + offset);
+}
+
+static inline u32 vpss_regr(u32 offset)
+{
+ return __raw_readl(oper_cfg.vpss_regs_base + offset);
+}
+
+static inline void vpss_regw(u32 val, u32 offset)
+{
+ __raw_writel(val, oper_cfg.vpss_regs_base + offset);
+}
+
+static void dm355_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
+{
+ bl_regw(src_sel VPSS_HSSISEL_SHIFT, DM355_VPSSBL_CCDCMUX);
+}
+
+int vpss_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
+{
+ if (!oper_cfg.hw_ops.select_ccdc_source)
+ return -1;
+
+ dm355_select_ccdc_source(src_sel);
+ return 0;
+}
+EXPORT_SYMBOL(vpss_select_ccdc_source);
+
+static int dm644x_clear_wbl_overflow(enum vpss_wbl_sel wbl_sel)
+{
+ u32 mask = 1, val;
+
+ if (wbl_sel VPSS_PCR_AEW_WBL_0 ||
+ wbl_sel VPSS_PCR_CCDC_WBL_O)
+ return -1;
+
+ /* writing a 0 clear the overflow */
+ mask = ~(mask wbl_sel);
+ val = bl_regr(DM644X_SBL_PCR_VPSS) mask;
+ bl_regw(val, DM644X_SBL_PCR_VPSS);
+ return 0;
+}
+
+int vpss_clear_wbl_overflow(enum vpss_wbl_sel wbl_sel)
+{
+ if (!oper_cfg.hw_ops.clear_wbl_overflow)
+ return -1;
+
+ return oper_cfg.hw_ops.clear_wbl_overflow(wbl_sel);
+}
+EXPORT_SYMBOL(vpss_clear_wbl_overflow);
+
+/*
+ * dm355_enable_clock - Enable VPSS Clock
+ * @clock_sel: CLock to be
Re: cx18, s5h1409: chronic bit errors, only under Linux
On 06/09/2009 10:24 AM, Steven Toth wrote: David has called out Comcast to review his installation. After replacing all the connectors and some cables from the pole all the way to the outlet, their meter ultimately showed 39-40dB at the outlet. My card is showing the same SNR values as before. Go figure. -- 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 5/10 - v2] ccdc hw device header file for vpfe capture
Please ignore this, it has wrong series number. I will re-send it soon
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Tuesday, June 09, 2009 2:50 PM
To: linux-media@vger.kernel.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Muralidharan Karicheri;
Karicheri, Muralidharan
Subject: [PATCH 5/10 - v2] ccdc hw device header file for vpfe capture
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
CCDC hw device header file
Adds ccdc hw device header for vpfe capture driver
Incorporated review comments against previous patch
Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
drivers/media/video/davinci/ccdc_hw_device.h | 110
++
1 files changed, 110 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/ccdc_hw_device.h
diff --git a/drivers/media/video/davinci/ccdc_hw_device.h
b/drivers/media/video/davinci/ccdc_hw_device.h
new file mode 100644
index 000..86b9b35
--- /dev/null
+++ b/drivers/media/video/davinci/ccdc_hw_device.h
@@ -0,0 +1,110 @@
+/*
+ * Copyright (C) 2008-2009 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
USA
+ *
+ * ccdc device API
+ */
+#ifndef _CCDC_HW_DEVICE_H
+#define _CCDC_HW_DEVICE_H
+
+#ifdef __KERNEL__
+#include linux/videodev2.h
+#include linux/device.h
+#include media/davinci/vpfe_types.h
+#include media/davinci/ccdc_types.h
+
+/*
+ * ccdc hw operations
+ */
+struct ccdc_hw_ops {
+ /* Pointer to initialize function to initialize ccdc device */
+ int (*open) (struct device *dev);
+ /* Pointer to deinitialize function */
+ int (*close) (struct device *dev);
+ /* set ccdc base address */
+ void (*set_ccdc_base)(void *base, int size);
+ /* Pointer to function to enable or disable ccdc */
+ void (*enable) (int en);
+ /* reset sbl. only for 6446 */
+ void (*reset) (void);
+ /* enable output to sdram */
+ void (*enable_out_to_sdram) (int en);
+ /* Pointer to function to set hw parameters */
+ int (*set_hw_if_params) (struct vpfe_hw_if_param *param);
+ /* get interface parameters */
+ int (*get_hw_if_params) (struct vpfe_hw_if_param *param);
+ /*
+ * Pointer to function to set parameters. Used
+ * for implementing VPFE_S_CCDC_PARAMS
+ */
+ int (*set_params) (void *params);
+ /*
+ * Pointer to function to get parameter. Used
+ * for implementing VPFE_G_CCDC_PARAMS
+ */
+ int (*get_params) (void *params);
+ /* Pointer to function to configure ccdc */
+ int (*configure) (void);
+
+ /* Pointer to function to set buffer type */
+ int (*set_buftype) (enum ccdc_buftype buf_type);
+ /* Pointer to function to get buffer type */
+ enum ccdc_buftype (*get_buftype) (void);
+ /* Pointer to function to set frame format */
+ int (*set_frame_format) (enum ccdc_frmfmt frm_fmt);
+ /* Pointer to function to get frame format */
+ enum ccdc_frmfmt (*get_frame_format) (void);
+ /* enumerate hw pix formats */
+ int (*enum_pix)(u32 *hw_pix, int i);
+ /* Pointer to function to set buffer type */
+ u32 (*get_pixel_format) (void);
+ /* Pointer to function to get pixel format. */
+ int (*set_pixel_format) (u32 pixfmt);
+ /* Pointer to function to set image window */
+ int (*set_image_window) (struct v4l2_rect *win);
+ /* Pointer to function to set image window */
+ void (*get_image_window) (struct v4l2_rect *win);
+ /* Pointer to function to get line length */
+ unsigned int (*get_line_length) (void);
+
+ /* Query CCDC control IDs */
+ int (*queryctrl)(struct v4l2_queryctrl *qctrl);
+ /* Set CCDC control */
+ int (*set_control)(struct v4l2_control *ctrl);
+ /* Get CCDC control */
+ int (*get_control)(struct v4l2_control *ctrl);
+
+ /* Pointer to function to set frame buffer address */
+ void (*setfbaddr) (unsigned long addr);
+ /* Pointer to function to get field id */
+ int (*getfid) (void);
+};
+
+struct ccdc_hw_device {
+ /* ccdc device name */
+ char name[32];
+ /* module owner */
+ struct module
[PATCH 2/10 - v2] ccdc hw device header file for vpfe capture
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
CCDC hw device header file
Adds ccdc hw device header for vpfe capture driver
Incorporated review comments against previous patch
Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
drivers/media/video/davinci/ccdc_hw_device.h | 110 ++
1 files changed, 110 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/ccdc_hw_device.h
diff --git a/drivers/media/video/davinci/ccdc_hw_device.h
b/drivers/media/video/davinci/ccdc_hw_device.h
new file mode 100644
index 000..86b9b35
--- /dev/null
+++ b/drivers/media/video/davinci/ccdc_hw_device.h
@@ -0,0 +1,110 @@
+/*
+ * Copyright (C) 2008-2009 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * ccdc device API
+ */
+#ifndef _CCDC_HW_DEVICE_H
+#define _CCDC_HW_DEVICE_H
+
+#ifdef __KERNEL__
+#include linux/videodev2.h
+#include linux/device.h
+#include media/davinci/vpfe_types.h
+#include media/davinci/ccdc_types.h
+
+/*
+ * ccdc hw operations
+ */
+struct ccdc_hw_ops {
+ /* Pointer to initialize function to initialize ccdc device */
+ int (*open) (struct device *dev);
+ /* Pointer to deinitialize function */
+ int (*close) (struct device *dev);
+ /* set ccdc base address */
+ void (*set_ccdc_base)(void *base, int size);
+ /* Pointer to function to enable or disable ccdc */
+ void (*enable) (int en);
+ /* reset sbl. only for 6446 */
+ void (*reset) (void);
+ /* enable output to sdram */
+ void (*enable_out_to_sdram) (int en);
+ /* Pointer to function to set hw parameters */
+ int (*set_hw_if_params) (struct vpfe_hw_if_param *param);
+ /* get interface parameters */
+ int (*get_hw_if_params) (struct vpfe_hw_if_param *param);
+ /*
+* Pointer to function to set parameters. Used
+* for implementing VPFE_S_CCDC_PARAMS
+*/
+ int (*set_params) (void *params);
+ /*
+* Pointer to function to get parameter. Used
+* for implementing VPFE_G_CCDC_PARAMS
+*/
+ int (*get_params) (void *params);
+ /* Pointer to function to configure ccdc */
+ int (*configure) (void);
+
+ /* Pointer to function to set buffer type */
+ int (*set_buftype) (enum ccdc_buftype buf_type);
+ /* Pointer to function to get buffer type */
+ enum ccdc_buftype (*get_buftype) (void);
+ /* Pointer to function to set frame format */
+ int (*set_frame_format) (enum ccdc_frmfmt frm_fmt);
+ /* Pointer to function to get frame format */
+ enum ccdc_frmfmt (*get_frame_format) (void);
+ /* enumerate hw pix formats */
+ int (*enum_pix)(u32 *hw_pix, int i);
+ /* Pointer to function to set buffer type */
+ u32 (*get_pixel_format) (void);
+ /* Pointer to function to get pixel format. */
+ int (*set_pixel_format) (u32 pixfmt);
+ /* Pointer to function to set image window */
+ int (*set_image_window) (struct v4l2_rect *win);
+ /* Pointer to function to set image window */
+ void (*get_image_window) (struct v4l2_rect *win);
+ /* Pointer to function to get line length */
+ unsigned int (*get_line_length) (void);
+
+ /* Query CCDC control IDs */
+ int (*queryctrl)(struct v4l2_queryctrl *qctrl);
+ /* Set CCDC control */
+ int (*set_control)(struct v4l2_control *ctrl);
+ /* Get CCDC control */
+ int (*get_control)(struct v4l2_control *ctrl);
+
+ /* Pointer to function to set frame buffer address */
+ void (*setfbaddr) (unsigned long addr);
+ /* Pointer to function to get field id */
+ int (*getfid) (void);
+};
+
+struct ccdc_hw_device {
+ /* ccdc device name */
+ char name[32];
+ /* module owner */
+ struct module *owner;
+ /* hw ops */
+ struct ccdc_hw_ops hw_ops;
+};
+
+/* Used by CCDC module to register unregister with vpfe capture driver */
+int vpfe_register_ccdc_device(struct ccdc_hw_device *dev);
+void vpfe_unregister_ccdc_device(struct ccdc_hw_device *dev);
+
+#endif
+#endif
--
1.6.0.4
--
To unsubscribe from this list:
Re: cx18, s5h1409: chronic bit errors, only under Linux
On Tue, Jun 9, 2009 at 2:52 PM, David Ward david.w...@gatech.edu wrote: On 06/09/2009 10:24 AM, Steven Toth wrote: David has called out Comcast to review his installation. After replacing all the connectors and some cables from the pole all the way to the outlet, their meter ultimately showed 39-40dB at the outlet. My card is showing the same SNR values as before. Go figure. I want to say that the SNR counter for the s5h1409 caps out at 30dB, but I would have to double check the source code. 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: cx18, s5h1409: chronic bit errors, only under Linux
Devin Heitmueller wrote: On Tue, Jun 9, 2009 at 2:52 PM, David Ward david.w...@gatech.edu wrote: On 06/09/2009 10:24 AM, Steven Toth wrote: David has called out Comcast to review his installation. After replacing all the connectors and some cables from the pole all the way to the outlet, their meter ultimately showed 39-40dB at the outlet. My card is showing the same SNR values as before. Go figure. I want to say that the SNR counter for the s5h1409 caps out at 30dB, but I would have to double check the source code. Devin 40db. -- Steven Toth - 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: cx18, s5h1409: chronic bit errors, only under Linux
On Tue, Jun 9, 2009 at 3:04 PM, Steven Toth st...@kernellabs.com wrote: 40db. -- Steven Toth - Kernel Labs http://www.kernellabs.com Just checked the source. It's 40dB for QAM256, but 30dB for ATSC and QAM64. Are we sure he's doing QAM256 and not QAM64? 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev
Em Tue, 9 Jun 2009 18:15:41 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev for the following: - v4l-dvb: replace the v4l2_i2c_new_*subdev* functions with v4l2_i2c_new_subdev() No, please! Let's keep the previously agreed strategy of not changing KABI on 2.6.31, in order to help fixing bug fixes that may eventually be present on 2.6.30 due to the large amount of changes due to V4L2 dev/subdev and I2C. We did a really large set of changes on 2.6.30, due to all those dev/subdev stuff. By deprecating functions that will be added on 2.6.30 on the next version (2.6.31), without even waiting for 2.6.30 regression list is not ok. Please come again with this only at the end of 2.6.31 kernel cycle. - v4l-dvb: add the s_config call to the core ops - v4l2-device: fix incorrect kernel check - v4l-dvb: add v4l2_i2c_new_subdev_board call If those are independent of the previous one, and are just adding new code, I'm ok on merging they. Yet, on a quick look at the the diff, it seems that they are changing the behavior of the existing functions [1]. Please double check and be sure that the diff will reflect just the new code addition. [1] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev/rev/ccc05f10e075 - v4l2: rename V4L2_I2C_ADDRS to I2C_ADDRS This one is OK, but I prefer to do this cleanup also later, to avoid needing to do backports if regressions are found close to this code 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: cx18, s5h1409: chronic bit errors, only under Linux
Devin Heitmueller wrote: On Tue, Jun 9, 2009 at 3:04 PM, Steven Toth st...@kernellabs.com wrote: 40db. -- Steven Toth - Kernel Labs http://www.kernellabs.com Just checked the source. It's 40dB for QAM256, but 30dB for ATSC and QAM64. Are we sure he's doing QAM256 and not QAM64? Devin 30db for the top end of ATSC sounds about right. David, when you ran the windows signal monitor - did it claim QAM64 or 256 when it was reporting 30db? -- Steven Toth - 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: [PULL] http://linuxtv.org/hg/~pinchartl/uvcvideo/
On Tue, 9 Jun 2009, Mauro Carvalho Chehab wrote: Em Tue, 9 Jun 2009 18:08:38 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Should I submit a patch that implement VIDIOC_S_JPEGCOMP support in the UVC driver and implement a JPEG compression quality control later, or would you prefer the driver not to implement VIDIOC_S_JPEGCOMP at all ? As there are existing applications using that ioctl a few users are pushing for VIDIOC_S_JPEGCOMP support. I prefer the later. Adding a new ioctl support just to deprecate it on the next kernel doesn't seem nice. Let's add directly the newer controls and add a patch marking this as deprecated. I'm not sure whether we can deprecate JPEGCOMP. It is used in too many places. Perhaps we should create a set of JPEG controls that match what is in v4l2_jpegcompression and convert all the drivers that use JPEGCOMP to these new controls. Then the v4l core can map S/G_JPEGCOMP ioctls to a set of control read/writes. I'm working on string control support, so that will allow us to handle the APP_data and COM_data fields. This seems to be the correct approach. Implement it as controls, and let video_ioctl2 to handle the calls to the legacy ioctls, while marking it as deprecate. One problem is that COM and APP segment actually have a string of bytes associated with them. Right now we only have boolean and interger controls. There is no way to set a control to the 32-bytes you want put into a APP segment. Now, if we added NUL terminated string and fixed length byte arrays as control types this could be done. I know that's something I've mentioned before. It would also be a step to allowing drivers to export metadata about captured images (exposured info, focus tracking, etc.) via a control-like interface. -- 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
DVB-S (-S2?), CI, CAM, Irdeto (Dragon/T-Rex?)
Hi all, I've been trying to put together a recomendation for the right combination of DVB-S (or S2?), CI, and CAM that can handle Irdeto encryption but after days of searching and finding lots of little pieces of information, I have not been able to find any examples of people running the right combinations of hardware running on Linux. There's plenty examples of it running on other platforms (MCE etc.) but finding the right combination of Tuner Card + CI, and CI + CAM that is all supported on Linux is proving to be a problem. Is any body running a Linux setup based on this? I'd really appreciate any feedback from your valuable experience as I'm really not able to find any examples of people saying I have this working. Many thanks in advance. Regards -- Brad. -- 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
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 for the following: - v4l2: add new s_config subdev ops and v4l2_i2c_new_subdev_cfg/board calls - v4l2-device: fix incorrect kernel check - v4l-compat: add I2C_ADDRS macro. - v4l2: update framework documentation. - v4l2-subdev: remove unnecessary check This time I've only added new functions and left the existing ones in place. I did add a bit of code to the existing v4l2_i2c_new_(probed_)subdev functions to call the new s_config op if it is available. Existing subdev drivers never set this new op, so this code will not effect current behavior. But for new drivers that do set s_config it is important that it is called no matter what flavor of these functions is used. At the end of the 2.6.31 cycle we can replace the current v4l2_i2c_new_(probed_)subdev calls with the new one I had in my earlier patches. Thanks, Hans diffstat: linux/Documentation/video4linux/v4l2-framework.txt | 24 +++ linux/drivers/media/video/v4l2-common.c| 166 + linux/drivers/media/video/v4l2-device.c|2 linux/include/media/v4l2-common.h | 18 ++ linux/include/media/v4l2-subdev.h |9 - v4l/compat.h |6 6 files changed, 222 insertions(+), 3 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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] adding support for setting bus parameters in sub device
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
This patch adds support for setting bus parameters such as bus type
(BT.656, BT.1120 etc), width (example 10 bit raw image data bus)
and polarities (vsync, hsync, field etc) in sub device. This allows
bridge driver to configure the sub device for a specific set of bus
parameters through s_bus() function call.
Reviewed By Hans Verkuil.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
include/media/v4l2-subdev.h | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1785608..c1cfb3b 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -37,6 +37,41 @@ struct v4l2_decode_vbi_line {
u32 type; /* VBI service type (V4L2_SLICED_*). 0 if no
service found */
};
+/*
+ * Some sub-devices are connected to the bridge device through a bus that
+ * carries * the clock, vsync, hsync and data. Some interfaces such as BT.656
+ * carries the sync embedded in the data where as others have separate line
+ * carrying the sync signals. The structure below is used by bridge driver to
+ * set the desired bus parameters in the sub device to work with it.
+ */
+enum v4l2_subdev_bus_type {
+ /* BT.656 interface. Embedded sync */
+ V4L2_SUBDEV_BUS_BT_656,
+ /* BT.1120 interface. Embedded sync */
+ V4L2_SUBDEV_BUS_BT_1120,
+ /* 8 bit muxed YCbCr bus, separate sync and field signals */
+ V4L2_SUBDEV_BUS_YCBCR_8,
+ /* 16 bit YCbCr bus, separate sync and field signals */
+ V4L2_SUBDEV_BUS_YCBCR_16,
+ /* Raw Bayer image data bus , 8 - 16 bit wide, sync signals */
+ V4L2_SUBDEV_BUS_RAW_BAYER
+};
+
+struct v4l2_subdev_bus {
+ enum v4l2_subdev_bus_type type;
+ u8 width;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_vsync:1;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_hsync:1;
+ /* 0 - low to high , 1 - high to low */
+ unsigned pol_field:1;
+ /* 0 - sample at falling edge , 1 - sample at rising edge */
+ unsigned pol_pclock:1;
+ /* 0 - active low , 1 - active high */
+ unsigned pol_data:1;
+};
+
/* Sub-devices are devices that are connected somehow to the main bridge
device. These devices are usually audio/video muxers/encoders/decoders or
sensors and webcam controllers.
@@ -109,6 +144,7 @@ struct v4l2_subdev_core_ops {
int (*querymenu)(struct v4l2_subdev *sd, struct v4l2_querymenu *qm);
int (*s_std)(struct v4l2_subdev *sd, v4l2_std_id norm);
long (*ioctl)(struct v4l2_subdev *sd, unsigned int cmd, void *arg);
+ int (*s_bus)(struct v4l2_subdev *sd, struct v4l2_subdev_bus *bus);
#ifdef CONFIG_VIDEO_ADV_DEBUG
int (*g_register)(struct v4l2_subdev *sd, struct v4l2_dbg_register
*reg);
int (*s_register)(struct v4l2_subdev *sd, struct v4l2_dbg_register
*reg);
--
1.6.0.4
--
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 RFC] adding support for setting bus parameters in sub device
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
re-sending with RFC in the header
This patch adds support for setting bus parameters such as bus type
(BT.656, BT.1120 etc), width (example 10 bit raw image data bus)
and polarities (vsync, hsync, field etc) in sub device. This allows
bridge driver to configure the sub device for a specific set of bus
parameters through s_bus() function call.
Reviewed By Hans Verkuil.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
include/media/v4l2-subdev.h | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1785608..c1cfb3b 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -37,6 +37,41 @@ struct v4l2_decode_vbi_line {
u32 type; /* VBI service type (V4L2_SLICED_*). 0 if no
service found */
};
+/*
+ * Some sub-devices are connected to the bridge device through a bus that
+ * carries * the clock, vsync, hsync and data. Some interfaces such as BT.656
+ * carries the sync embedded in the data where as others have separate line
+ * carrying the sync signals. The structure below is used by bridge driver to
+ * set the desired bus parameters in the sub device to work with it.
+ */
+enum v4l2_subdev_bus_type {
+ /* BT.656 interface. Embedded sync */
+ V4L2_SUBDEV_BUS_BT_656,
+ /* BT.1120 interface. Embedded sync */
+ V4L2_SUBDEV_BUS_BT_1120,
+ /* 8 bit muxed YCbCr bus, separate sync and field signals */
+ V4L2_SUBDEV_BUS_YCBCR_8,
+ /* 16 bit YCbCr bus, separate sync and field signals */
+ V4L2_SUBDEV_BUS_YCBCR_16,
+ /* Raw Bayer image data bus , 8 - 16 bit wide, sync signals */
+ V4L2_SUBDEV_BUS_RAW_BAYER
+};
+
+struct v4l2_subdev_bus {
+ enum v4l2_subdev_bus_type type;
+ u8 width;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_vsync:1;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_hsync:1;
+ /* 0 - low to high , 1 - high to low */
+ unsigned pol_field:1;
+ /* 0 - sample at falling edge , 1 - sample at rising edge */
+ unsigned pol_pclock:1;
+ /* 0 - active low , 1 - active high */
+ unsigned pol_data:1;
+};
+
/* Sub-devices are devices that are connected somehow to the main bridge
device. These devices are usually audio/video muxers/encoders/decoders or
sensors and webcam controllers.
@@ -109,6 +144,7 @@ struct v4l2_subdev_core_ops {
int (*querymenu)(struct v4l2_subdev *sd, struct v4l2_querymenu *qm);
int (*s_std)(struct v4l2_subdev *sd, v4l2_std_id norm);
long (*ioctl)(struct v4l2_subdev *sd, unsigned int cmd, void *arg);
+ int (*s_bus)(struct v4l2_subdev *sd, struct v4l2_subdev_bus *bus);
#ifdef CONFIG_VIDEO_ADV_DEBUG
int (*g_register)(struct v4l2_subdev *sd, struct v4l2_dbg_register
*reg);
int (*s_register)(struct v4l2_subdev *sd, struct v4l2_dbg_register
*reg);
--
1.6.0.4
--
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 RFC] adding support for setting bus parameters in sub device
On Tuesday 09 June 2009 22:55:53 m-kariche...@ti.com wrote:
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
re-sending with RFC in the header
This patch adds support for setting bus parameters such as bus type
(BT.656, BT.1120 etc), width (example 10 bit raw image data bus)
and polarities (vsync, hsync, field etc) in sub device. This allows
bridge driver to configure the sub device for a specific set of bus
parameters through s_bus() function call.
Reviewed By Hans Verkuil.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
include/media/v4l2-subdev.h | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1785608..c1cfb3b 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -37,6 +37,41 @@ struct v4l2_decode_vbi_line {
u32 type; /* VBI service type (V4L2_SLICED_*). 0 if no
service found
*/ };
+/*
+ * Some sub-devices are connected to the bridge device through a bus
that + * carries * the clock, vsync, hsync and data. Some interfaces such
as BT.656 + * carries the sync embedded in the data where as others have
separate line + * carrying the sync signals. The structure below is used
by bridge driver to + * set the desired bus parameters in the sub device
to work with it. + */
+enum v4l2_subdev_bus_type {
+ /* BT.656 interface. Embedded sync */
+ V4L2_SUBDEV_BUS_BT_656,
+ /* BT.1120 interface. Embedded sync */
+ V4L2_SUBDEV_BUS_BT_1120,
+ /* 8 bit muxed YCbCr bus, separate sync and field signals */
+ V4L2_SUBDEV_BUS_YCBCR_8,
+ /* 16 bit YCbCr bus, separate sync and field signals */
+ V4L2_SUBDEV_BUS_YCBCR_16,
Hmm, what do you mean with 8 bit muxed YCbCr bus? It's not clear to me
what the format of these YCBCR bus types is exactly.
+ /* Raw Bayer image data bus , 8 - 16 bit wide, sync signals */
+ V4L2_SUBDEV_BUS_RAW_BAYER
+};
+
+struct v4l2_subdev_bus {
+ enum v4l2_subdev_bus_type type;
+ u8 width;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_vsync:1;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_hsync:1;
+ /* 0 - low to high , 1 - high to low */
+ unsigned pol_field:1;
+ /* 0 - sample at falling edge , 1 - sample at rising edge */
+ unsigned pol_pclock:1;
+ /* 0 - active low , 1 - active high */
+ unsigned pol_data:1;
+};
+
/* Sub-devices are devices that are connected somehow to the main bridge
device. These devices are usually audio/video
muxers/encoders/decoders or sensors and webcam controllers.
@@ -109,6 +144,7 @@ struct v4l2_subdev_core_ops {
int (*querymenu)(struct v4l2_subdev *sd, struct v4l2_querymenu *qm);
int (*s_std)(struct v4l2_subdev *sd, v4l2_std_id norm);
long (*ioctl)(struct v4l2_subdev *sd, unsigned int cmd, void *arg);
+ int (*s_bus)(struct v4l2_subdev *sd, struct v4l2_subdev_bus *bus);
Make this 'const struct v4l2_subdev_bus *bus'.
#ifdef CONFIG_VIDEO_ADV_DEBUG
int (*g_register)(struct v4l2_subdev *sd, struct v4l2_dbg_register
*reg); int (*s_register)(struct v4l2_subdev *sd, struct v4l2_dbg_register
*reg);
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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 RFC] adding support for setting bus parameters in sub device
On Tuesday 09 June 2009 23:03:01 Hans Verkuil wrote:
On Tuesday 09 June 2009 22:55:53 m-kariche...@ti.com wrote:
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
re-sending with RFC in the header
This patch adds support for setting bus parameters such as bus type
(BT.656, BT.1120 etc), width (example 10 bit raw image data bus)
and polarities (vsync, hsync, field etc) in sub device. This allows
bridge driver to configure the sub device for a specific set of bus
parameters through s_bus() function call.
Reviewed By Hans Verkuil.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
include/media/v4l2-subdev.h | 36
1 files changed, 36 insertions(+),
0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1785608..c1cfb3b 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -37,6 +37,41 @@ struct v4l2_decode_vbi_line {
u32 type; /* VBI service type (V4L2_SLICED_*). 0 if no
service found
*/ };
+/*
+ * Some sub-devices are connected to the bridge device through a bus
that + * carries * the clock, vsync, hsync and data. Some interfaces
such as BT.656 + * carries the sync embedded in the data where as
others have separate line + * carrying the sync signals. The structure
below is used by bridge driver to + * set the desired bus parameters in
the sub device to work with it. + */
+enum v4l2_subdev_bus_type {
+ /* BT.656 interface. Embedded sync */
+ V4L2_SUBDEV_BUS_BT_656,
+ /* BT.1120 interface. Embedded sync */
+ V4L2_SUBDEV_BUS_BT_1120,
+ /* 8 bit muxed YCbCr bus, separate sync and field signals */
+ V4L2_SUBDEV_BUS_YCBCR_8,
+ /* 16 bit YCbCr bus, separate sync and field signals */
+ V4L2_SUBDEV_BUS_YCBCR_16,
Hmm, what do you mean with 8 bit muxed YCbCr bus? It's not clear to me
what the format of these YCBCR bus types is exactly.
+ /* Raw Bayer image data bus , 8 - 16 bit wide, sync signals */
+ V4L2_SUBDEV_BUS_RAW_BAYER
+};
+
+struct v4l2_subdev_bus {
+ enum v4l2_subdev_bus_type type;
+ u8 width;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_vsync:1;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_hsync:1;
+ /* 0 - low to high , 1 - high to low */
+ unsigned pol_field:1;
+ /* 0 - sample at falling edge , 1 - sample at rising edge */
+ unsigned pol_pclock:1;
+ /* 0 - active low , 1 - active high */
+ unsigned pol_data:1;
+};
+
/* Sub-devices are devices that are connected somehow to the main
bridge device. These devices are usually audio/video
muxers/encoders/decoders or sensors and webcam controllers.
@@ -109,6 +144,7 @@ struct v4l2_subdev_core_ops {
int (*querymenu)(struct v4l2_subdev *sd, struct v4l2_querymenu *qm);
int (*s_std)(struct v4l2_subdev *sd, v4l2_std_id norm);
long (*ioctl)(struct v4l2_subdev *sd, unsigned int cmd, void *arg);
+ int (*s_bus)(struct v4l2_subdev *sd, struct v4l2_subdev_bus *bus);
Make this 'const struct v4l2_subdev_bus *bus'.
And move it to the video ops. This op is only relevant for video, after all.
Yes, I know I said to add it to core initially; so sue me :-)
Regards,
Hans
#ifdef CONFIG_VIDEO_ADV_DEBUG
int (*g_register)(struct v4l2_subdev *sd, struct v4l2_dbg_register
*reg); int (*s_register)(struct v4l2_subdev *sd, struct
v4l2_dbg_register *reg);
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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 RFC] adding support for setting bus parameters in sub device
email: m-kariche...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Tuesday, June 09, 2009 5:03 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; davinci-linux-open-
sou...@linux.davincidsp.com; Muralidharan Karicheri
Subject: Re: [PATCH RFC] adding support for setting bus parameters in sub
device
On Tuesday 09 June 2009 22:55:53 m-kariche...@ti.com wrote:
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
re-sending with RFC in the header
This patch adds support for setting bus parameters such as bus type
(BT.656, BT.1120 etc), width (example 10 bit raw image data bus)
and polarities (vsync, hsync, field etc) in sub device. This allows
bridge driver to configure the sub device for a specific set of bus
parameters through s_bus() function call.
Reviewed By Hans Verkuil.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
include/media/v4l2-subdev.h | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1785608..c1cfb3b 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -37,6 +37,41 @@ struct v4l2_decode_vbi_line {
u32 type; /* VBI service type (V4L2_SLICED_*). 0 if no
service found
*/ };
+/*
+ * Some sub-devices are connected to the bridge device through a bus
that + * carries * the clock, vsync, hsync and data. Some interfaces such
as BT.656 + * carries the sync embedded in the data where as others have
separate line + * carrying the sync signals. The structure below is used
by bridge driver to + * set the desired bus parameters in the sub device
to work with it. + */
+enum v4l2_subdev_bus_type {
+/* BT.656 interface. Embedded sync */
+V4L2_SUBDEV_BUS_BT_656,
+/* BT.1120 interface. Embedded sync */
+V4L2_SUBDEV_BUS_BT_1120,
+/* 8 bit muxed YCbCr bus, separate sync and field signals */
+V4L2_SUBDEV_BUS_YCBCR_8,
+/* 16 bit YCbCr bus, separate sync and field signals */
+V4L2_SUBDEV_BUS_YCBCR_16,
Hmm, what do you mean with 8 bit muxed YCbCr bus? It's not clear to me
what the format of these YCBCR bus types is exactly.
[MK] For YCbCr16, there is separate bus to carry Y and CbCr data, where as on
YCbCr8, both gets multiplexed over same 8 bit bus (Y, Cb, Y, Cr, Y, Cb The
difference between V4L2_SUBDEV_BUS_BT_656 and V4L2_SUBDEV_BUS_YCBCR_8 is that
sync is embedded with data in the former, where as there is dedicated sync
lines for the latter.
+/* Raw Bayer image data bus , 8 - 16 bit wide, sync signals */
+V4L2_SUBDEV_BUS_RAW_BAYER
+};
+
+struct v4l2_subdev_bus {
+enum v4l2_subdev_bus_type type;
+u8 width;
+/* 0 - active low, 1 - active high */
+unsigned pol_vsync:1;
+/* 0 - active low, 1 - active high */
+unsigned pol_hsync:1;
+/* 0 - low to high , 1 - high to low */
+unsigned pol_field:1;
+/* 0 - sample at falling edge , 1 - sample at rising edge */
+unsigned pol_pclock:1;
+/* 0 - active low , 1 - active high */
+unsigned pol_data:1;
+};
+
/* Sub-devices are devices that are connected somehow to the main bridge
device. These devices are usually audio/video
muxers/encoders/decoders or sensors and webcam controllers.
@@ -109,6 +144,7 @@ struct v4l2_subdev_core_ops {
int (*querymenu)(struct v4l2_subdev *sd, struct v4l2_querymenu *qm);
int (*s_std)(struct v4l2_subdev *sd, v4l2_std_id norm);
long (*ioctl)(struct v4l2_subdev *sd, unsigned int cmd, void *arg);
+int (*s_bus)(struct v4l2_subdev *sd, struct v4l2_subdev_bus *bus);
Make this 'const struct v4l2_subdev_bus *bus'.
Ok.
#ifdef CONFIG_VIDEO_ADV_DEBUG
int (*g_register)(struct v4l2_subdev *sd, struct v4l2_dbg_register
*reg); int (*s_register)(struct v4l2_subdev *sd, struct v4l2_dbg_register
*reg);
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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: AVerTV Volar Black HD: i2c oops in warm state on mips
Solved with [PATCH] af9015: fix stack corruption bug. Best regards, Jan -- 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
[PULL] http://linuxtv.org/hg/~awalls/v4l-dvb
Mauro, Please pull from http://linuxtv.org/hg/~awalls/v4l-dvb for the following 2 changesets: 01/02: cx18: Split LeadTek PVR2100 and DVR3100 H into 2 separate card entries http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=ab23b24b09ce 02/02: cx18: Add DVB-T support for the Leadtek WinFast DVR3100 H http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=ad7dd34a2b2d cx18-cards.c | 79 ++ cx18-driver.c |3 +- cx18-driver.h |5 ++- cx18-dvb.c| 53 +- 4 files changed, 120 insertions(+), 20 deletions(-) Special thanks goes to Terry Wu of Leadtek who provided the missing information necessary to get DVB-T working for the Leadtek DVR 3100 H! Terry also performed the testing: 6 MHz and 8 MHz DVB-T work now; 7 MHz DVB-T can also work with a change to tuner-xc2028.c which I will post in a follow up. Rusty, This is the first of 3 cards supported by the cx18 driver with a tuner shared by both analog and digital TV. (The Toshiba Qosmio interal and the Yuan MPC718 will be 2 other cards). The cx18 driver currently has no interlock - so maybe this would be a good example case for what you were looking to pursue. I imagine the cx18 driver could implement all the interlocking itself, but I suppose you were looking at some sort of infrastructure to make the job easier for bridge drivers. Regards, Andy -- 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] af9015: fix stack corruption bug
On 06/10/2009 01:31 AM, Jan Nikitenko wrote: This patch fixes stack corruption bug present in af9015_eeprom_dump(): the buffer buf is one byte smaller than required - there is 4 chars for address prefix, 16*3 chars for dump of 16 eeprom bytes per line and 1 byte for zero ending the string required, i.e. 53 bytes, but only 52 are provided. The one byte missing in stack based buffer buf causes following oops on MIPS little endian platform, because i2c_adap pointer in af9015_af9013_frontend_attach() is corrupted by inlined function af9015_eeprom_dump(): Signed-off-by: Jan Nikitenkojan.nikite...@gmail.com Acked-by: Antti Palosaari cr...@iki.fi regards Antti -- http://palosaari.fi/ -- 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] tuner-xc2028: Fix 7 MHz DVB-T when used with zl10353 demod
All,
The following is a patch that gets 7 MHz DVB-T working for the Leadtek
DVR3100 H.
Any comments?
Regards,
Andy
Signed-off-by: Andy Walls awa...@radix.net
Tested-by: Terry Wu terrywu2...@gmail.com
diff -r fad35ab59848 linux/drivers/media/common/tuners/tuner-xc2028.c
--- a/linux/drivers/media/common/tuners/tuner-xc2028.c Fri Jun 05 08:42:27
2009 -0400
+++ b/linux/drivers/media/common/tuners/tuner-xc2028.c Tue Jun 09 20:10:06
2009 -0400
@@ -1099,8 +1099,13 @@
}
/* All S-code tables need a 200kHz shift */
- if (priv-ctrl.demod)
+ if (priv-ctrl.demod) {
demod = priv-ctrl.demod + 200;
+ /* Terry Wu terrywu2...@gmail.com */
+ if (priv-ctrl.demod == XC3028_FE_ZARLINK456
+ bw == BANDWIDTH_7_MHZ)
+ demod += 500;
+ }
return generic_set_freq(fe, p-frequency,
T_DIGITAL_TV, type, 0, demod);
--
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: About the VIDIOC_DQBUF
hi ~~
I have found the problem ~~ The 3'rd partner didn't give us the right
v4l2 driver. Thanks for your help ~~
Best wishes
在 2009-06-09二的 16:41 +0900，Dongsoo, Nathaniel Kim写道：
Hi,
Sorry I still don't get what the full frame means, but I might
consider that is the maximum resolution-ed image data coming from
external camera module. And whatever it is, you might have no problem
getting data through memcpy with buf.byteused size.
Cheers,
Nate
On Tue, Jun 9, 2009 at 11:22 AM, xieyili@gmail.com wrote:
hi ~~ Dongsoo, Nathaniel ~
I am sorry for disturbing you, and not descripe the question clear ~
Thanks very much for your help ~~
I know that I must stop preview with streamoff and re-configure with
s_fmt ~~ I have asked to you before ~!~
The full frame means a complete frame ~Because I just need to get the
frame data and post it to multimedia framework, so I want to consult to
you that if I can get a complete frame with memcpy ~~
I want to know that can I get a complete frame from buf.start to the
end , and the memory-lenth is buf.byteused ~
buf.byteused
|-|
buf.startend
在 2009-06-08一的 20:40 +0900，Dongsoo, Nathaniel Kim写道：
Hi,
Sorry I'm not an expert, you can expect expertise from maintainers not
from me.
But before answering your question about capturing, I'm not sure about
what the full frame means. I just assume that you meant to say the
biggest resolution of image frame, right?
So, when you are to capture a full resolution data while preview is
working, you need to stop preview with streamoff, re-configure
resolution with s_fmt to external camera module and start capturing
issuing streamon with re-configured resolution. I think you are
well-aware with this, aren't you? And in my opinion, memcpy may be
cool for that. What else are you expecting to use? and for what?
Anyway, I wish you luck.
Cheers,
Nate
On Mon, Jun 8, 2009 at 5:02 PM, xieyili@gmail.com wrote:
Hi Dongsoo, Nathaniel ~
You must be expert on V4l2 ~ Thanks very much for your help and advice
~!~
I used the MXC camera interface driver from Fressscale ,I readed the
driver interface just now ,and have fouded that the driver not modified
the buf.lenth but buf.byteused . You are very right , I will use the
buf.byteused instead of buf.length ~
There is also a problem I want to consult to you ~ Can i get a full
frame with the below method if the driver have no problem ?
memcpy((mCameraProwave-getPreviewHeap())-base(),
v4l2Buffer[buf.index].start, buf.byteused) ;
Because I just need to implement a hal for getting the frame data and
post it to top layer , so I used the memcpy simply . Am I right ~ ? Or
what about your advice ?
Thanks a lot ~~
在 2009-06-08一的 15:56 +0900，Dongsoo, Nathaniel Kim写道：
Hello Xie,
I'm not sure which camera interface driver you are using, but it seems
to be camera interface driver's problem. Let me guess, are you using
pxa camera interface driver from Marvell?(proprietary but not in up
stream kernel)
It just looks like that camera interface driver is not returning
proper data in dqbuf.
And one more thing. I prefer to use byteused rather than length in
buf. because as far as I know the size of preview data from camera is
in byte unit which we need to copy to memory. But it should be
possible to use length, I guess..
Cheers,
Nate
On Mon, Jun 8, 2009 at 11:05 AM, xieyili@gmail.com wrote:
Dear all ~~
I have met a issue when I used the mmap method for previewing . I just
used the standard code as spec to get the image data :
status_t CameraHardwareProwave::V4l2Camera::v4l2CaptureMainloop()
{
LOG_FUNCTION_NAME
int rt ;
unsigned int i ;
fd_set fds ;
struct timeval tv ;
struct v4l2_buffer buf ;
for(;;){
FD_ZERO(fds) ;
FD_SET(v4l2Fd, fds) ;
//now the time is long ,just for debug
tv.tv_sec = 2 ;
tv.tv_usec = 0 ;
rt = select(v4l2Fd + 1, fds, NULL, NULL, tv) ;
LOGD(The value of select return : %d\n, rt) ;
/** for debug
if(V4L2_NOERROR != v4l2ReadFrame()){
LOGE(READ ERROR) ;
}
***/
if(-1 == rt){
LOGE(there is something wrong in select
function(select)) ;
//no defined error manage
return V4L2_IOCTL_ERROR ;
}
if(0 == rt){
LOGE(wait for data timeout in select) ;
return V4L2_TIMEOUT
