Re: Problem on RJ54N1CB0C
Hi Uwe On Mon, 16 Nov 2009, Uwe Taeubert wrote: Hi Guennadi You will find the driver sources for our Sharp module in lz0p39ha.c and the initialization data in lz0p39ha_init.c. In lz0p35du_set_fmt_cap() you can see the resolution depending change of the divider. In our system we get correct pictures in all resolution mensioned there. But FYI, if no flashlight is desired, we do not switch to still mode - only still mode generates flash controll signals. We are working with the Technical Manual Ver. 2.2C, also under NDA. May I ask you if you have an English or a Japanese version?:-) I've got a 2.3C Japanese... Concerning the exposure control, I know the use of the registers 0x04d8 and 0x04d9 is more a hack but a solution. And the result is unsatisfying - it was a try. At the moment I'm checking the influence of RAMPCLK- TGCLK-ratio. I was able to get higher exposer by changing RAMPCLK but I wasn't able to calculate a well doing relation between all clocks and to have a fast frame rate. The driver content is in a preliminary state. I'm working on lz0p35du_set_fmt_cap function. We do not diffenrentialte between preview and still mode. It makes it easier to handle buffers in VFL at the moment. Thanks for the code. I looked briefly at it and one essential difference that occurred to me is, that you're setting the RESIZE registers at the beginning of the format-change function (lz0p35du_set_fmt_cap()), and I am doing this following code examples, that I had in the end, followed by a killer delay of 230ms... You might try to do that in the end, but it might only become worse, because, as I said, my version of the driver has problems with bigger images. My driver also doesn't set autofocus ATM, as there had been errors in examples that I had and I didn't have time to experiment with those values. I'm also relying on the automatic exposure area selection (0x58c bit 7) instead of setting it automatically. You also don't seem to dynamically adjust INC_USE_SEL registers, instead you just initialise them to 0xff. And in my experience that register does make a difference, so, you might try to play with it a bit. Have a look at my driver, although, I don't think values I configure there are perfect either. In fact, it might indeed become a problem for you, that you're updating the RESIZE registers too early and not pausing after that. Unfortunately, I do not have time now to look at the driver in detail ATM, let me know your results when you fix your problem. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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] gspca: add sanity check for mandatory operations
On Tue, 17 Nov 2009 07:47:40 +0100 Németh Márton nm...@freemail.hu wrote: From: Márton Németh nm...@fremail.hu Add check for the mandatory config, init, start and pkt_scan gspca subdriver operations. Signed-off-by: Márton Németh nm...@fremail.hu --- diff -r 182b5f8fa160 linux/drivers/media/video/gspca/gspca.c --- a/linux/drivers/media/video/gspca/gspca.c Sun Nov 15 10:05:30 2009 +0100 +++ b/linux/drivers/media/video/gspca/gspca.c Tue Nov 17 07:42:34 2009 +0100 @@ -2035,6 +2035,12 @@ return -ENODEV; } + /* check for mandatory operations */ + BUG_ON(!sd_desc-config); + BUG_ON(!sd_desc-init); + BUG_ON(!sd_desc-start); + BUG_ON(!sd_desc-pkt_scan); + /* create the device */ if (dev_size sizeof *gspca_dev) dev_size = sizeof *gspca_dev; Hi Németh, I don't think this is useful: the people who write the subdrivers know the mandatory parameters. If not, the system will simply oops at the first test... -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dvb-core: Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed into the remaining bytes of a MPEG2-TS frame
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation code has a bug that incorrectly treats ULE SNDU packed into the remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer field on the subsequent MPEG2-TS frame. This patch was generated against v2.6.32-rc7, however it wasn't tested using that kernel. Similar patch was applied and tested using 2.6.27 which is similar to the latest dvb_net.c, except for network device statistical data structure. I suspect that this bug was introduced in kernel version 2.6.15, but had not verified it. Care has been taken not to introduce more bug by fixing this bug, but please scrutinize the code for I always produces buggy code. Signed-off-by: Ang Way Chuang wc...@nav6.org -- 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] dvb-core: Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed into the remaining bytes of a MPEG2-TS frame
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation
code has a bug that incorrectly treats ULE SNDU packed into the remaining
2 or 3 bytes of a MPEG2-TS frame as having invalid pointer field on the
subsequent MPEG2-TS frame.
This patch was generated against v2.6.32-rc7, however it wasn't tested
using that kernel. Similar patch was applied and tested using 2.6.27 which
is similar to the latest dvb_net.c, except for network device statistical data
structure. I suspect that this bug was introduced in kernel version 2.6.15,
but had not verified it.
Care has been taken not to introduce more bug by fixing this bug, but
please scrutinize the code for I always produces buggy code.
Signed-off-by: Ang Way Chuang wc...@nav6.org
---
diff --git a/drivers/media/dvb/dvb-core/dvb_net.c
b/drivers/media/dvb/dvb-core/dvb_net.c
index 0241a7c..a521395 100644
--- a/drivers/media/dvb/dvb-core/dvb_net.c
+++ b/drivers/media/dvb/dvb-core/dvb_net.c
@@ -533,6 +533,7 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
from_where += 2;
}
+ priv-ule_sndu_remain = priv-ule_sndu_len + 2;
/*
* State of current TS:
* ts_remain (remaining bytes in the current TS cell)
@@ -542,6 +543,7 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
*/
switch (ts_remain) {
case 1:
+ priv-ule_sndu_remain--;
priv-ule_sndu_type = from_where[0]
8;
priv-ule_sndu_type_1 = 1; /* first
byte of ule_type is set. */
ts_remain -= 1; from_where += 1;
@@ -555,6 +557,7 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
default: /* complete ULE header is present in
current TS. */
/* Extract ULE type field. */
if (priv-ule_sndu_type_1) {
+ priv-ule_sndu_type_1 = 0;
priv-ule_sndu_type |=
from_where[0];
from_where += 1; /* points to
payload start. */
ts_remain -= 1;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC, PATCH] gspca: implement vidioc_enum_frameintervals
Hi,
gspca does not implement vidioc_enum_frameintervals yet, so even if a
camera can support multiple frame rates (or frame intervals) there is
still no way to enumerate them from userspace.
The following is just a quick and dirty implementation to show the
problem and to have something to base the discussion on. In the patch
there is also a working example of use with the ov534 subdriver.
Someone with a better knowledge of gspca and v4l internals can suggest
better solutions.
The tests has been done using 'luvcview -L', the output before the
patch:
$ luvcview -d /dev/video1 -L
luvcview 0.2.6
SDL information:
Video driver: x11
A window manager is available
Device information:
Device path: /dev/video1
{ pixelformat = 'YUYV', description = 'YUYV' }
{ discrete: width = 320, height = 240 }
Time interval between frame:
1/40, 1/30, { discrete: width = 640, height = 480 }
Time interval between frame:
And the output after it:
$ luvcview -d /dev/video1 -L
luvcview 0.2.6
SDL information:
Video driver: x11
A window manager is available
Device information:
Device path: /dev/video1
{ pixelformat = 'YUYV', description = 'YUYV' }
{ discrete: width = 320, height = 240 }
Time interval between frame: 1/125, 1/100, 1/75, 1/60, 1/50, 1/40,
1/30,
{ discrete: width = 640, height = 480 }
Time interval between frame: 1/60, 1/50, 1/40, 1/30, 1/15,
Thanks,
Antonio
diff -r 182b5f8fa160 linux/drivers/media/video/gspca/gspca.c
--- a/linux/drivers/media/video/gspca/gspca.c Sun Nov 15 10:05:30 2009 +0100
+++ b/linux/drivers/media/video/gspca/gspca.c Tue Nov 17 11:39:21 2009 +0100
@@ -995,6 +995,37 @@
return -EINVAL;
}
+static int vidioc_enum_frameintervals(struct file *filp, void *priv,
+ struct v4l2_frmivalenum *fival)
+{
+ struct gspca_dev *gspca_dev = priv;
+ int mode = wxh_to_mode(gspca_dev, fival-width, fival-height);
+ int i;
+ __u32 index = 0;
+
+ if (gspca_dev-cam.mode_framerates == NULL ||
+ gspca_dev-cam.mode_framerates[mode].nrates == 0)
+ return -EINVAL;
+
+ /* FIXME: Needed? */
+ if (fival-pixel_format !=
+ gspca_dev-cam.cam_mode[mode].pixelformat)
+ return -EINVAL;
+
+ for (i = 0; i gspca_dev-cam.mode_framerates[mode].nrates; i++) {
+ if (fival-index == index) {
+ fival-type = V4L2_FRMSIZE_TYPE_DISCRETE;
+ fival-discrete.numerator = 1;
+ fival-discrete.denominator =
+ gspca_dev-cam.mode_framerates[mode].rates[i];
+ return 0;
+ }
+ index++;
+ }
+
+ return -EINVAL;
+}
+
static void gspca_release(struct video_device *vfd)
{
struct gspca_dev *gspca_dev = container_of(vfd, struct gspca_dev, vdev);
@@ -1987,6 +2018,7 @@
.vidioc_g_parm = vidioc_g_parm,
.vidioc_s_parm = vidioc_s_parm,
.vidioc_enum_framesizes = vidioc_enum_framesizes,
+ .vidioc_enum_frameintervals = vidioc_enum_frameintervals,
#ifdef CONFIG_VIDEO_ADV_DEBUG
.vidioc_g_register = vidioc_g_register,
.vidioc_s_register = vidioc_s_register,
diff -r 182b5f8fa160 linux/drivers/media/video/gspca/gspca.h
--- a/linux/drivers/media/video/gspca/gspca.h Sun Nov 15 10:05:30 2009 +0100
+++ b/linux/drivers/media/video/gspca/gspca.h Tue Nov 17 11:39:21 2009 +0100
@@ -45,11 +45,17 @@
/* image transfers */
#define MAX_NURBS 4/* max number of URBs */
+struct framerates {
+ int *rates;
+ int nrates;
+};
+
/* device information - set at probe time */
struct cam {
int bulk_size; /* buffer size when image transfer by bulk */
const struct v4l2_pix_format *cam_mode; /* size nmodes */
char nmodes;
+ const struct framerates *mode_framerates; /* size nmode, like cam_mode
*/
__u8 bulk_nurbs;/* number of URBs in bulk mode
* - cannot be MAX_NURBS
* - when 0 and bulk_size != 0 means
diff -r 182b5f8fa160 linux/drivers/media/video/gspca/ov534.c
--- a/linux/drivers/media/video/gspca/ov534.c Sun Nov 15 10:05:30 2009 +0100
+++ b/linux/drivers/media/video/gspca/ov534.c Tue Nov 17 11:39:21 2009 +0100
@@ -287,6 +287,20 @@
.priv = 0},
};
+static int qvga_rates[] = {125, 100, 75, 60, 50, 40, 30};
+static int vga_rates[] = {60, 50, 40, 30, 15};
+
+static const struct framerates ov772x_framerates[] = {
+ { /* 320x240 */
+ .rates = qvga_rates,
+ .nrates = ARRAY_SIZE(qvga_rates),
+ },
+ { /* 640x480 */
+ .rates = vga_rates,
+ .nrates = ARRAY_SIZE(vga_rates),
+ },
+};
+
static const
Re: [RFC, PATCH] gspca: implement vidioc_enum_frameintervals
Hi,
Antonio Ospite wrote:
Hi,
gspca does not implement vidioc_enum_frameintervals yet, so even if a
camera can support multiple frame rates (or frame intervals) there is
still no way to enumerate them from userspace.
The following is just a quick and dirty implementation to show the
problem and to have something to base the discussion on. In the patch
there is also a working example of use with the ov534 subdriver.
Someone with a better knowledge of gspca and v4l internals can suggest
better solutions.
The tests has been done using 'luvcview -L', the output before the
patch:
$ luvcview -d /dev/video1 -L
luvcview 0.2.6
SDL information:
Video driver: x11
A window manager is available
Device information:
Device path: /dev/video1
{ pixelformat = 'YUYV', description = 'YUYV' }
{ discrete: width = 320, height = 240 }
Time interval between frame:
1/40, 1/30, { discrete: width = 640, height = 480 }
Time interval between frame:
And the output after it:
$ luvcview -d /dev/video1 -L
luvcview 0.2.6
SDL information:
Video driver: x11
A window manager is available
Device information:
Device path: /dev/video1
{ pixelformat = 'YUYV', description = 'YUYV' }
{ discrete: width = 320, height = 240 }
Time interval between frame: 1/125, 1/100, 1/75, 1/60, 1/50, 1/40,
1/30,
{ discrete: width = 640, height = 480 }
Time interval between frame: 1/60, 1/50, 1/40, 1/30, 1/15,
Thanks,
Antonio
diff -r 182b5f8fa160 linux/drivers/media/video/gspca/gspca.c
--- a/linux/drivers/media/video/gspca/gspca.c Sun Nov 15 10:05:30 2009 +0100
+++ b/linux/drivers/media/video/gspca/gspca.c Tue Nov 17 11:39:21 2009 +0100
@@ -995,6 +995,37 @@
return -EINVAL;
}
+static int vidioc_enum_frameintervals(struct file *filp, void *priv,
+ struct v4l2_frmivalenum *fival)
+{
+ struct gspca_dev *gspca_dev = priv;
+ int mode = wxh_to_mode(gspca_dev, fival-width, fival-height);
+ int i;
+ __u32 index = 0;
+
+ if (gspca_dev-cam.mode_framerates == NULL ||
+ gspca_dev-cam.mode_framerates[mode].nrates == 0)
+ return -EINVAL;
+
+ /* FIXME: Needed? */
+ if (fival-pixel_format !=
+ gspca_dev-cam.cam_mode[mode].pixelformat)
+ return -EINVAL;
+
+ for (i = 0; i gspca_dev-cam.mode_framerates[mode].nrates; i++) {
+ if (fival-index == index) {
+ fival-type = V4L2_FRMSIZE_TYPE_DISCRETE;
+ fival-discrete.numerator = 1;
+ fival-discrete.denominator =
+ gspca_dev-cam.mode_framerates[mode].rates[i];
+ return 0;
+ }
+ index++;
+ }
+
+ return -EINVAL;
+}
+
static void gspca_release(struct video_device *vfd)
{
struct gspca_dev *gspca_dev = container_of(vfd, struct gspca_dev, vdev);
@@ -1987,6 +2018,7 @@
.vidioc_g_parm = vidioc_g_parm,
.vidioc_s_parm = vidioc_s_parm,
.vidioc_enum_framesizes = vidioc_enum_framesizes,
+ .vidioc_enum_frameintervals = vidioc_enum_frameintervals,
#ifdef CONFIG_VIDEO_ADV_DEBUG
.vidioc_g_register = vidioc_g_register,
.vidioc_s_register = vidioc_s_register,
diff -r 182b5f8fa160 linux/drivers/media/video/gspca/gspca.h
--- a/linux/drivers/media/video/gspca/gspca.h Sun Nov 15 10:05:30 2009 +0100
+++ b/linux/drivers/media/video/gspca/gspca.h Tue Nov 17 11:39:21 2009 +0100
@@ -45,11 +45,17 @@
/* image transfers */
#define MAX_NURBS 4/* max number of URBs */
+struct framerates {
+ int *rates;
+ int nrates;
+};
+
/* device information - set at probe time */
struct cam {
int bulk_size; /* buffer size when image transfer by bulk */
const struct v4l2_pix_format *cam_mode; /* size nmodes */
char nmodes;
+ const struct framerates *mode_framerates; /* size nmode, like cam_mode
*/
__u8 bulk_nurbs;/* number of URBs in bulk mode
* - cannot be MAX_NURBS
* - when 0 and bulk_size != 0 means
I think that the best thing is to slip in two patches. One is related to the
gspa main
and the other is a change on a driver.
diff -r 182b5f8fa160 linux/drivers/media/video/gspca/ov534.c
--- a/linux/drivers/media/video/gspca/ov534.c Sun Nov 15 10:05:30 2009 +0100
+++ b/linux/drivers/media/video/gspca/ov534.c Tue Nov 17 11:39:21 2009 +0100
@@ -287,6 +287,20 @@
.priv = 0},
};
+static int qvga_rates[] = {125, 100, 75, 60, 50, 40, 30};
+static int vga_rates[] = {60, 50, 40, 30, 15};
+
+static const struct framerates ov772x_framerates[] = {
+ { /* 320x240 */
+ .rates = qvga_rates,
+ .nrates = ARRAY_SIZE(qvga_rates),
Re: xawtv and v4lctl with usbvision kernel driver
Devin Heitmueller wrote: On Mon, Nov 16, 2009 at 10:01 AM, Sietse Achterop s.achte...@rug.nl wrote: Context: debian/lenny with usb frame grabber: Zoran Co. Personal Media Division (Nogatech) Hauppauge WinTV Pro (PAL/SECAM) This uses the usbvision driver. The problem is that while xawtv works OK with color, v4lctl ONLY shows the frames in black-and-white. I don't know about that board in particular, but on some boards the composite and s-video are actually wired together (sharing the luma line), so if you have the device configured in composite mode but have the s-video plugged in, then you will get a black/white image (since it expects to see both luma/chroma on the one pin that provides luma). Hi Devin, Thanks for your reponse, but xawtv happely shows color, so I don't think thats the issue, Thanks again, Sietse -- 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 17/21] workqueue: simple reimplementation of SINGLE_THREAD workqueue
On Tue, 2009-11-17 at 14:23 +0900, Tejun Heo wrote: Hello, 11/17/2009 09:47 AM, Andy Walls wrote: An important property of the single threaded workqueue, upon which the cx18 driver relies, is that work objects will be processed strictly in the order in which they were queued. The cx18 driver has a pool of work orders and multiple active work orders can be queued up on the workqueue especially if multiple streams are active. If these work orders were to be processed out of order, video artifacts would result in video display applications. That's an interesting use of single thread workqueue. Most of single thread workqueues seem to be made single thread just to save number of threads. Some seem to depend on single thread of execution but I never knew there are ones which depend on the exact execution order. Do you think that usage is wide-spread? I doubt it. Most that I have seen use the singlethreaded workqueue object with a queue depth of essentially 1 for syncronization - as you have noted. Implementing strict ordering shouldn't be too difficult but I can't help but feeling that such assumption is abuse of implementation detail. Hmmm, does not the queue in workqueue mean FIFO? If not for strict ordering, why else would a driver absolutely need a singlethreaded workqueue object? It seems to me the strict ording is the driving requirement for a singlethreaded workqueue at all. Your patch series indicates to me that the performance and synchronization use cases are not driving requirements for a singlethreaded workqueue. Thanks for your consideration. Regards, Andy Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Fwd: [PATCH 2.6.31.5 1/1] v4l2: add new define for last camera class control id]
Hi Bertrand,
Please, always send patches c/c to:
linux-me...@vger.kernel.org.
This way, people can better review it.
For more details, please read:
http://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches
There are some additional details on how patch submission works at:
http://linuxtv.org/hg/v4l-dvb/file/tip/README.patches
I'm forwarding it to the ML. I'll comment about it there.
Cheers,
Mauro.
Mensagem original
Assunto: [PATCH 2.6.31.5 1/1] v4l2: add new define for last camera class
control id
Data: Wed, 11 Nov 2009 22:00:24 +0100
De: Bertrand b...@cykian.net
Para: Mauro Carvalho Chehab mche...@infradead.org
The videodev2.h file contains, among other things, defines that point
to the control properties of video devices.
For the standard video controls, there is a V4L2_CID_BASE define for
the base, and a pointer to the last control ID plus 1 named
V4L2_CID_LASTP1.
This allows automatic, version independent enumeration of the controls.
There are other controls which are specific to the camera class
devices. While there is a V4L2_CID_CAMERA_CLASS_BASE define, there was
none for the last one.
As a result it was not possible to do an enumeration of the controls
of that class. This patch corrects this by adding a
V4L2_CID_CAMERA_CLASS_LASTP1 define.
Signed-off-by: Bertrand Achard b...@cykian.net
--- linux-2.6.31.5/include/linux/videodev2.h2009-10-23 00:57:56.0
+0200
+++ linux-2.6.31.5-n/include/linux/videodev2.h 2009-11-11
21:48:48.0 +0100
@@ -1147,6 +1147,8 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_PRIVACY (V4L2_CID_CAMERA_CLASS_BASE+16)
+#define V4L2_CID_CAMERA_CLASS_LASTP1 (V4L2_CID_CAMERA_CLASS_BASE+17)
+
/*
* T U N I N G
*/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] [PATCH] omap_vout: default colorspace for RGB565 set to SRGB
This patch is dependent on the patch [PATCH 4/4] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2 From 41b85f02f441771ace6c42ee08475ab7be04eb90 Mon Sep 17 00:00:00 2001 From: Kishore Y kishor...@ti.com Date: Wed, 11 Nov 2009 19:47:14 +0530 Subject: [PATCH] omap_vout: default colorspace for RGB565 set to SRGB Default video format is set to RGB565 and the colorspace is set to JPEG. Best colorspace for RGB565 is SRGB and hence changed to it. Signed-off-by: Kishore Y kishor...@ti.com --- drivers/media/video/omap/omap_vout.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c index 6118665..7092ef2 100644 --- a/drivers/media/video/omap/omap_vout.c +++ b/drivers/media/video/omap/omap_vout.c @@ -2078,7 +2078,7 @@ static int __init omap_vout_setup_video_data(struct omap_vout_device *vout) pix-bytesperline = pix-width * 2; pix-sizeimage = pix-bytesperline * pix-height; pix-priv = 0; - pix-colorspace = V4L2_COLORSPACE_JPEG; + pix-colorspace = V4L2_COLORSPACE_SRGB; vout-bpp = RGB565_BPP; vout-fbuf.fmt.width = display-panel.timings.x_res; -- 1.5.4.3 Regards, Kishore Y Ph:- +918039813085 -- 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: KWorld UB435-Q Support
On Nov 17, 2009, at 1:03 AM, Robert Cicconetti wrote: On Tue, Nov 17, 2009 at 12:55 AM, Michael Krufky mkru...@linuxtv.org wrote: [ 812.465930] tda18271: performing RF tracking filter calibration [ 818.572446] tda18271: RF tracking filter calibration complete [ 818.953946] tda18271: performing RF tracking filter calibration [ 825.093211] tda18271: RF tracking filter calibration complete If you see this happen more than once consecutively, and there is only 1 silicon tuner present, then it means something very bad is happening, and there is a chance of burning out a part. I still wouldnt not recommend any mainline merge until you can prevent this behavior -- I suspect that a GPIO reset is being toggled where it shouldnt be, which should be harmless ... but until we fix it, we cant be sure what damage might get done... The RF tracking filter calibration is a procedure that should only happen once while the tuner is powered on -- it should *only* be repeated if the tuner indicated that calibration is necessary, and that would only happen after a hardware reset. This still looks fishy to me... Agreed. I did manage to dig into this some more last night, something is definitely still awry. Here's a dmesg dump with some extra debug spew added in key spots: ... em28xx driver loaded tda18271 4-0060: creating new instance TDA18271HD/C2 detected @ 4-0060 tda18271: R_EP1 is 0xce cal is not initialized (cal_initialized=false)... tda18271: performing RF tracking filter calibration tda18271: RF tracking filter calibration complete (0xde) DVB: registering new adapter (em28xx #0) DVB: registering adapter 0 frontend 0 (LG Electronics LGDT3304 VSB/QAM Frontend)... em28xx #0: Successfully loaded em28xx-dvb Em28xx: Initialized (Em28xx dvb Extension) extension 1st tuning attempt tda18271: R_EP1 is 0x00 cal is not initialized (cal_initialized=true)... tda18271: performing RF tracking filter calibration tda18271: RF tracking filter calibration complete (0x00) tda18271: R_EP1 is 0x00 cal is not initialized (cal_initialized=true)... tda18271: performing RF tracking filter calibration tda18271: RF tracking filter calibration complete (0x00) 2nd tuning attempt tda18271: R_EP1 is 0x00 cal is not initialized (cal_initialized=true)... tda18271: performing RF tracking filter calibration tda18271: RF tracking filter calibration complete (0x00) tda18271: R_EP1 is 0x00 cal is not initialized (cal_initialized=true)... tda18271: performing RF tracking filter calibration tda18271: RF tracking filter calibration complete (0x00) I'll try tweaking the GPIO reset mask and whatnot, definitely does seem like something's getting reset that shouldn't, because you can clearly see that cal *was* initialized, then R_EP1 got zeroed out. It happened at every tuning operation, and made mythfrontend unhappy (unable to tune after the first channel). I disabled the check for RF_CAL_OK which triggered the recalibration, and mythfrontend worked. Yeah, tuning is much quicker here if I skip that check as well, but its definitely not the proper fix. The stick has been plugged in for a few months, so presumably would've caught on fire by now if it was going to. It would be nice if the tuning delay went away, though.. it still takes ~6 seconds to switch frequencies. Wait, it still takes that long with the check gone? I didn't poke for very long with the check disabled, mostly focusing on trying to figure out why things are going haywire. I have not yet compiled and tested the lastest patches from Jarod. Really shouldn't be any difference from what you've got, they're just rebased to the latest v4l-dvb tree. -- Jarod Wilson ja...@wilsonet.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
[RFC] [PATCH] omap_vout: Change allocated buffer to only needed size
This patch is dependent on the patch
[PATCH 4/4] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2
From eb4302232f15e0af075604a9cf24fcaa9688e8a5 Mon Sep 17 00:00:00 2001
From: Kishore Y kishor...@ti.com
Date: Tue, 10 Nov 2009 21:44:10 +0530
Subject: [PATCH] omap_vout: Change allocated buffer to only needed size
This patch change allocation size of IO buffers to allocate
only needed size depending on pix.width, pix.height and bytes
per pixel. The buffer size is rounded to allocate always a PAGE_SIZE multiple
Signed-off-by: Kishore Y kishor...@ti.com
---
drivers/media/video/omap/omap_vout.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index a13f65e..8064c2d 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -855,6 +855,8 @@ static int omap_vout_buffer_setup(struct videobuf_queue *q,
unsigned int *count,
/* Now allocated the V4L2 buffers */
*size = vout-buffer_size;
+ *size = vout-pix.width * vout-pix.height * vout-bpp;
+ *size = PAGE_ALIGN(*size);
startindex = (vout-vid == OMAP_VIDEO1) ?
video1_numbuffers : video2_numbuffers;
for (i = startindex; i *count; i++) {
--
1.5.4.3
Regards,
Kishore Y
Ph:- +918039813085
--
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: [Fwd: [PATCH 2.6.31.5 1/1] v4l2: add new define for last camera class control id]
Hi Bertrand,
Please, always send patches c/c to:
linux-me...@vger.kernel.org.
This way, people can better review it.
For more details, please read:
http://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches
There are some additional details on how patch submission works at:
http://linuxtv.org/hg/v4l-dvb/file/tip/README.patches
I'm forwarding it to the ML. I'll comment about it there.
Cheers,
Mauro.
Mensagem original
Assunto: [PATCH 2.6.31.5 1/1] v4l2: add new define for last camera class
control id
Data: Wed, 11 Nov 2009 22:00:24 +0100
De: Bertrand b...@cykian.net
Para: Mauro Carvalho Chehab mche...@infradead.org
The videodev2.h file contains, among other things, defines that point
to the control properties of video devices.
For the standard video controls, there is a V4L2_CID_BASE define for
the base, and a pointer to the last control ID plus 1 named
V4L2_CID_LASTP1.
This allows automatic, version independent enumeration of the controls.
There are other controls which are specific to the camera class
devices. While there is a V4L2_CID_CAMERA_CLASS_BASE define, there was
none for the last one.
As a result it was not possible to do an enumeration of the controls
of that class. This patch corrects this by adding a
V4L2_CID_CAMERA_CLASS_LASTP1 define.
Hi Bertrand,
Enumerating controls that are not part of the user controls or the private
controls must use the V4L2_CTRL_FLAG_NEXT_CTRL flag when enumerating:
http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec-single/v4l2.html#id2762121
If a driver does not support that, then that driver should be fixed.
Note that this can also be used for user and private controls, but most
drivers do not do that. I'm working on a better driver framework that will
handle this in the core inside of depending on the driver support.
The old style of using LASTP defines is really bad and inflexible and
should be avoided for extended controls.
Regards,
Hans
Signed-off-by: Bertrand Achard b...@cykian.net
--- linux-2.6.31.5/include/linux/videodev2.h 2009-10-23 00:57:56.0
+0200
+++ linux-2.6.31.5-n/include/linux/videodev2.h2009-11-11
21:48:48.0 +0100
@@ -1147,6 +1147,8 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_PRIVACY (V4L2_CID_CAMERA_CLASS_BASE+16)
+#define V4L2_CID_CAMERA_CLASS_LASTP1 (V4L2_CID_CAMERA_CLASS_BASE+17)
+
/*
* T U N I N G
*/
--
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
New DibCom based ISDB-T device
Hi Patrick,
A friend of mine got a Geniatech S870 ISDB-T card. According to him, this
device is based
on stk8090 chipset and wants to use it in Brazil.
The board has the following USB ID:
Bus 002 Device 002: ID 10b8:1fa0 DiBcom
I was wandering if the existing dib8000 driver will work with such device.
If so, would the following patch be enough?
Cheers,
Mauro.
---
Add support for Dibcom STK8090
Signed-off-by: Mauro Carvalho Chehab mche...@infradead.org
diff --git a/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
b/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
--- a/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
+++ b/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
@@ -1950,6 +1950,7 @@ struct usb_device_id dib0700_usb_id_tabl
{ USB_DEVICE(USB_VID_DIBCOM,USB_PID_DIBCOM_STK807XP) },
{ USB_DEVICE(USB_VID_PIXELVIEW, USB_PID_PIXELVIEW_SBTVD) },
{ USB_DEVICE(USB_VID_EVOLUTEPC, USB_PID_TVWAY_PLUS) },
+ { USB_DEVICE(USB_VID_DIBCOM,USB_PID_DIBCOM_STK8090) },
{ 0 } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, dib0700_usb_id_table);
@@ -2496,7 +2497,7 @@ struct dvb_usb_device_properties dib0700
},
},
- .num_device_descs = 3,
+ .num_device_descs = 4,
.devices = {
{ DiBcom STK807xP reference design,
{ dib0700_usb_id_table[62], NULL },
@@ -2510,6 +2511,10 @@ struct dvb_usb_device_properties dib0700
{ dib0700_usb_id_table[64], NULL },
{ NULL },
},
+ { DiBcom STK8090 reference design,
+ { dib0700_usb_id_table[65], NULL },
+ { NULL },
+ },
},
.rc_interval = DEFAULT_RC_INTERVAL,
diff --git a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
@@ -100,6 +100,7 @@
#define USB_PID_DIBCOM_STK7070PD 0x1ebe
#define USB_PID_DIBCOM_STK807XP0x1f90
#define USB_PID_DIBCOM_STK807XPVR 0x1f98
+#define USB_PID_DIBCOM_STK8090 0x1fa0
#define USB_PID_DIBCOM_ANCHOR_2135_COLD0x2131
#define USB_PID_DIBCOM_STK7770P0x1e80
#define USB_PID_DPOSH_M9206_COLD 0x9206
--
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: KWorld UB435-Q Support
On Tue, Nov 17, 2009 at 9:15 AM, Jarod Wilson ja...@wilsonet.com wrote: On Nov 17, 2009, at 1:03 AM, Robert Cicconetti wrote: On Tue, Nov 17, 2009 at 12:55 AM, Michael Krufky mkru...@linuxtv.org wrote: [ 812.465930] tda18271: performing RF tracking filter calibration [ 818.572446] tda18271: RF tracking filter calibration complete [ 818.953946] tda18271: performing RF tracking filter calibration [ 825.093211] tda18271: RF tracking filter calibration complete If you see this happen more than once consecutively, and there is only 1 silicon tuner present, then it means something very bad is happening, and there is a chance of burning out a part. I still wouldnt not recommend any mainline merge until you can prevent this behavior -- I suspect that a GPIO reset is being toggled where it shouldnt be, which should be harmless ... but until we fix it, we cant be sure what damage might get done... The RF tracking filter calibration is a procedure that should only happen once while the tuner is powered on -- it should *only* be repeated if the tuner indicated that calibration is necessary, and that would only happen after a hardware reset. This still looks fishy to me... Agreed. I did manage to dig into this some more last night, something is definitely still awry. Here's a dmesg dump with some extra debug spew added in key spots: ... em28xx driver loaded tda18271 4-0060: creating new instance TDA18271HD/C2 detected @ 4-0060 tda18271: R_EP1 is 0xce cal is not initialized (cal_initialized=false)... tda18271: performing RF tracking filter calibration tda18271: RF tracking filter calibration complete (0xde) DVB: registering new adapter (em28xx #0) DVB: registering adapter 0 frontend 0 (LG Electronics LGDT3304 VSB/QAM Frontend)... em28xx #0: Successfully loaded em28xx-dvb Em28xx: Initialized (Em28xx dvb Extension) extension 1st tuning attempt tda18271: R_EP1 is 0x00 cal is not initialized (cal_initialized=true)... tda18271: performing RF tracking filter calibration tda18271: RF tracking filter calibration complete (0x00) tda18271: R_EP1 is 0x00 cal is not initialized (cal_initialized=true)... tda18271: performing RF tracking filter calibration tda18271: RF tracking filter calibration complete (0x00) 2nd tuning attempt tda18271: R_EP1 is 0x00 cal is not initialized (cal_initialized=true)... tda18271: performing RF tracking filter calibration tda18271: RF tracking filter calibration complete (0x00) tda18271: R_EP1 is 0x00 cal is not initialized (cal_initialized=true)... tda18271: performing RF tracking filter calibration tda18271: RF tracking filter calibration complete (0x00) I'll try tweaking the GPIO reset mask and whatnot, definitely does seem like something's getting reset that shouldn't, because you can clearly see that cal *was* initialized, then R_EP1 got zeroed out. It happened at every tuning operation, and made mythfrontend unhappy (unable to tune after the first channel). I disabled the check for RF_CAL_OK which triggered the recalibration, and mythfrontend worked. Yeah, tuning is much quicker here if I skip that check as well, but its definitely not the proper fix. The stick has been plugged in for a few months, so presumably would've caught on fire by now if it was going to. It would be nice if the tuning delay went away, though.. it still takes ~6 seconds to switch frequencies. Wait, it still takes that long with the check gone? I didn't poke for very long with the check disabled, mostly focusing on trying to figure out why things are going haywire. I have not yet compiled and tested the lastest patches from Jarod. Really shouldn't be any difference from what you've got, they're just rebased to the latest v4l-dvb tree. Hey Jarod, I haven't seen your exact GPIO config but I noticed something recently: the em28xx driver runs the dvb_gpio sequence whenever starting streaming, not just whenever opening the DVB frontend. This means that if your dvb_gpio definition strobes the tda18271 reset (as opposed to just taking it out of reset), then the chip will get reset whenever the streaming is started (a real problem if multiple tuning attempts are performed without closing the frontend first). Mauro seems to think this is intended behavior, although I cannot see how this could possibly be correct, especially since the .init() callback is not called in that case. I setup a tree to remove the call, but never got far enough into the testing to confirm whether it broke any improperly configured boards depending on the incorrect behavior. As a test, you might want to check your dvb_gpio config and see if you are pulling anything low and then high, and just remove the line that sets the pin low and see if the recalibration still occurs. 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
Re: KWorld UB435-Q Support
On Tue, Nov 17, 2009 at 9:15 AM, Jarod Wilson ja...@wilsonet.com wrote: It happened at every tuning operation, and made mythfrontend unhappy (unable to tune after the first channel). I disabled the check for RF_CAL_OK which triggered the recalibration, and mythfrontend worked. Yeah, tuning is much quicker here if I skip that check as well, but its definitely not the proper fix. The stick has been plugged in for a few months, so presumably would've caught on fire by now if it was going to. It would be nice if the tuning delay went away, though.. it still takes ~6 seconds to switch frequencies. Wait, it still takes that long with the check gone? I didn't poke for very long with the check disabled, mostly focusing on trying to figure out why things are going haywire. Okay.. couple of unscientific tests later show I was wrong above: First tuning, ~5-6 seconds to lock. Later tunings, ~3 seconds to lock. This is with my hack to remove the recalibrations. -Bob -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] [PATCH] V4L2: Allow rotation between stream off-on
This patch is dependent on the patch
[PATCH 4/4] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2
From cda5b97d02784318d89a029a2fde97903610d2b2 Mon Sep 17 00:00:00 2001
From: Kishore Y kishor...@ti.com
Date: Wed, 11 Nov 2009 19:22:46 +0530
Subject: [PATCH] V4L2: Allow rotation between stream off-on
This patch configures vrfb buffers when streamon ioctl is called
in order to allow changing video rotation among streamoff/streamon
sequences without calling reqbuf ioctl
Signed-off-by: Kishore Y kishor...@ti.com
---
drivers/media/video/omap/omap_vout.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index c39c8a7..6118665 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -1800,6 +1800,7 @@ static int vidioc_streamon(struct file *file, void *fh,
struct omap_vout_device *vout = fh;
struct videobuf_queue *q = vout-vbq;
u32 addr = 0;
+ unsigned int count;
int r = 0;
int t;
struct omapvideo_info *ovid = vout-vid_info;
@@ -1837,6 +1838,9 @@ static int vidioc_streamon(struct file *file, void *fh,
vout-first_int = 1;
+ count = vout-buffer_allocated;
+ omap_vout_vrfb_buffer_setup(vout, count, 0);
+
if (omap_vout_calculate_offset(vout)) {
mutex_unlock(vout-lock);
return -EINVAL;
--
1.5.4.3
Regards,
Kishore Y
Ph:- +918039813085
--
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
Support for AVerTVHD Duet - A188
Good Morning! I could not find the AVerTVHD Duet A188 in the wiki, and searching the mailing list did not produce much either. Is the card now supported in Linux? Thanks! -- Mit freundlichen Grüßen / Best Regards Andreas Schlehahn -- 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 17/21] workqueue: simple reimplementation of SINGLE_THREAD workqueue
On Tue, 17 Nov 2009, Tejun Heo wrote: Do you think that usage is wide-spread? Implementing strict ordering shouldn't be too difficult but I can't help but feeling that such assumption is abuse of implementation detail. I think it would be good if it were more than an implementation detail, and was something documented and known. The less random and timing-dependent our interfaces are, the better off we are. Guaranteeing that a single-threaded workqueue is done in order seems to me to be a GoodThing(tm), regardless of whether much code depends on it. Of course, if there is some fundamental reason why it wouldn't be the case, that's another thing. But if you think uit should be easy, and since there _are_ users, then it shouldn't be seen as an implementation detail. It's a feature. Linus -- 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
Help in adding documentation
Hi Mauro, Is there some instructions on adding new sections in the v4l2 documentation. I had been struggling yesterday to add my documentation for video timing API. It is easy to make minor documentation changes. But since I am adding new ioctls, Looks like I need to create vidioc-xxx.xml under DoCBook/v4l/ directory since media-specs/Makefile is generating videodev2.h.xml automatically (I learned it in the hard way). I have added the IOCTL name in media-specs/Makefile and also added the structure name. But somehow, the videodev2.h.xml file doesn't show my structure types documented in vidioc-xxx.xml. Any idea what could be wrong? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 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
RE: Help in adding documentation
After compilation I get the following error Error: no ID for contstraint linkend: v4l2-dv-enum-presets. v4l2-dv-enum-presets is the new structure type added. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Karicheri, Muralidharan Sent: Tuesday, November 17, 2009 10:58 AM To: 'Mauro Carvalho Chehab' Cc: 'Hans Verkuil'; linux-media@vger.kernel.org Subject: Help in adding documentation Hi Mauro, Is there some instructions on adding new sections in the v4l2 documentation. I had been struggling yesterday to add my documentation for video timing API. It is easy to make minor documentation changes. But since I am adding new ioctls, Looks like I need to create vidioc-xxx.xml under DoCBook/v4l/ directory since media-specs/Makefile is generating videodev2.h.xml automatically (I learned it in the hard way). I have added the IOCTL name in media-specs/Makefile and also added the structure name. But somehow, the videodev2.h.xml file doesn't show my structure types documented in vidioc- xxx.xml. Any idea what could be wrong? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 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
Re: [PATCH 17/21] workqueue: simple reimplementation of SINGLE_THREAD workqueue
Hello, Linus. 11/18/2009 12:05 AM, Linus Torvalds wrote: Do you think that usage is wide-spread? Implementing strict ordering shouldn't be too difficult but I can't help but feeling that such assumption is abuse of implementation detail. I think it would be good if it were more than an implementation detail, and was something documented and known. The less random and timing-dependent our interfaces are, the better off we are. Guaranteeing that a single-threaded workqueue is done in order seems to me to be a GoodThing(tm), regardless of whether much code depends on it. Of course, if there is some fundamental reason why it wouldn't be the case, that's another thing. But if you think uit should be easy, and since there _are_ users, then it shouldn't be seen as an implementation detail. It's a feature. I might have been too early with the 'easy' part but I definitely can give it a shot. What do you think about the scheduler notifier implementation? It seems we'll end up with three callbacks. It can either be three hlist_heads in the struct_task linking each ops or single hilst_head links ops tables (like the current preempt notifiers). Which one should I go with? Thanks. -- tejun -- 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] dvb-apps: fixes in scan utility
Hello,
I did correct work with circular polarisation (R=V)
Added call for setup_switch function for Monopoint LNBf, because somebody may
use it with diseqc switch and we also should set correct polarisation.
Signed-off-by: Anton Myachin a...@lantan.ru
--- a/util/scan/scan.c 2009-11-16 19:29:41.0 +0500
+++ b/util/scan/scan.c 2009-11-16 20:37:44.0 +0500
@@ -1484,7 +1484,7 @@ static int __tune_to_transponder (int fr
setup_switch (frontend_fd,
switch_pos,
- t-polarisation ==
POLARISATION_VERTICAL ? 0 : 1,
+ t-polarisation ==
POLARISATION_VERTICAL || t-polarisation == POLARISATION_CIRCULAR_RIGHT ? 0 : 1,
hiband);
usleep(5);
if (hiband)
@@ -1497,7 +1497,12 @@ static int __tune_to_transponder (int fr
lnb_type.low_val:
lnb_type.high_val));
}
} else {
- /* Monopoint LNBf without switch */
+ /* Monopoint LNBf */
+ setup_switch (frontend_fd,
+ switch_pos,
+ t-polarisation == POLARISATION_VERTICAL
|| t-polarisation == POLARISATION_CIRCULAR_RIGHT ? 0 : 1,
+ 0);
+ usleep(5);
p.frequency = abs(p.frequency - lnb_type.low_val);
}
if (verbosity = 2)
@@ -1930,7 +1935,7 @@ static void pids_dump_service_parameter_
static char sat_polarisation (struct transponder *t)
{
- return t-polarisation == POLARISATION_VERTICAL ? 'v' : 'h';
+ return t-polarisation == POLARISATION_VERTICAL || t-polarisation ==
POLARISATION_CIRCULAR_RIGHT ? 'v' : 'h';
}
static int sat_number (struct transponder *t)
--
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 17/21] workqueue: simple reimplementation of SINGLE_THREAD workqueue
Hello, 11/17/2009 09:05 PM, Andy Walls wrote: Implementing strict ordering shouldn't be too difficult but I can't help but feeling that such assumption is abuse of implementation detail. Hmmm, does not the queue in workqueue mean FIFO? I don't think it necessarily means strict execution ordering. If not for strict ordering, why else would a driver absolutely need a singlethreaded workqueue object? It seems to me the strict ording is the driving requirement for a singlethreaded workqueue at all. Your patch series indicates to me that the performance and synchronization use cases are not driving requirements for a singlethreaded workqueue. I still think the biggest reason why single threaded workqueue is used is just to reduce the number of threads hanging around. I tried to audit single thread users some time ago. My impression was that many of single thread work users did synchronization itself anyway while smaller portion depended on single threadedness. I didn't notice the strict ordering requirement but then again I wasn't looking for them. It seems there are at least two cases depending on FIFO behavior, so let's see if we can retain the behavior for single threaded workqueues (maybe it should be renamed to ORDERED?). Thanks. -- tejun -- 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: Help in adding documentation
Em Tue, 17 Nov 2009 10:00:07 -0600 Karicheri, Muralidharan m-kariche...@ti.com escreveu: Hi Mauro, Is there some instructions on adding new sections in the v4l2 documentation. No, sorry. The documentation build is undocumented.. I had been struggling yesterday to add my documentation for video timing API. It is easy to make minor documentation changes. But since I am adding new ioctls, Looks like I need to create vidioc-xxx.xml under DoCBook/v4l/ directory since media-specs/Makefile is generating videodev2.h.xml automatically (I learned it in the hard way). Yes, this is the better way: create a separate xml file for it, to keep the same concept used there. I have added the IOCTL name in media-specs/Makefile and also added the structure name. We may try to add the ioctls automatically at the Makefile. I started doing things like that at the DVB side of the Makefile. It is not that hard, since all we need to do is to check for _IO defines at videodev2.h. But somehow, the videodev2.h.xml file doesn't show my structure types documented in vidioc- xxx.xml. Any idea what could be wrong? Probably, the name is wrong. Maybe lower-case/upper-case? Some DocBook tool versions are case sensitive, while others aren't. After compilation I get the following error Error: no ID for contstraint linkend: v4l2-dv-enum-presets. v4l2-dv-enum-presets is the new structure type added. This probably means that videodev2.h has it defined, while you didn't have the link id created at the xml file you've created. You probably need a tag like: table pgwide=1 frame=none id=v4l2-dv-enum-presets !-- your enum table -- /table 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: Help in adding documentation
Mauro, Thanks for your reply. I made progress after my email. My new file is being processed by Makefile now. I have some issues with some tags. This probably means that videodev2.h has it defined, while you didn't have Do you mean videodev2.h.xml? I see there videodev2.h under linux/include. Do I need to copy my latest videodev2.h to that directory? the link id created at the xml file you've created. You probably need a tag like: table pgwide=1 frame=none id=v4l2-dv-enum-presets !-- your enum table -- /table 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 -- 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: Help in adding documentation
Karicheri, Muralidharan escreveu: Mauro, Thanks for your reply. I made progress after my email. My new file is being processed by Makefile now. I have some issues with some tags. This probably means that videodev2.h has it defined, while you didn't have Do you mean videodev2.h.xml? I see there videodev2.h under linux/include. Do I need to copy my latest videodev2.h to that directory? videodev2.h.xml is generated automatically by Makefile, from videodev2.h. Basically, Makefile scripts will parse it, search for certain structs/enums/ioctls and generate videodev2.h.xml. What happens is that you likely declared the presets enum on videodev2.h, and the enum got detected, producing a linkend tag. However, as you didn't define the reference ID for that tag on your xml file, you got an error. the link id created at the xml file you've created. You probably need a tag like: table pgwide=1 frame=none id=v4l2-dv-enum-presets !-- your enum table -- /table 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 -- 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 17/21] workqueue: simple reimplementation of SINGLE_THREAD workqueue
On Wed, 18 Nov 2009, Tejun Heo wrote: I might have been too early with the 'easy' part but I definitely can give it a shot. What do you think about the scheduler notifier implementation? It seems we'll end up with three callbacks. It can either be three hlist_heads in the struct_task linking each ops or single hilst_head links ops tables (like the current preempt notifiers). Which one should I go with? I have to say that I don't know. Will this eventually be something common? Is the cache footprint problem of 3 pointers that are usually empty worse than the cache problem of following a chain where you don't use half the entries? Who knows? And when it actually _is_ used, is it going to be horrible to have a possibly upredictable indirect branch (and on some architectures, _all_ indirect branches are unpredictable) in a really hot path? In general, notifiers are always horrible. If there's only one or two common cases, it's probably going to be better to hardcode those with flags to be tested instead of following function pointers. So I just don't know. Linus -- 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: Details about DVB frontend API
Manu Abraham escreveu:
On Fri, Oct 23, 2009 at 12:10 AM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
Em Thu, 22 Oct 2009 21:13:30 +0200
Jean Delvare kh...@linux-fr.org escreveu:
Hi folks,
I am looking for details regarding the DVB frontend API. I've read
linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER,
FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS
commands return, however it does not give any information about how the
returned values should be interpreted (or, seen from the other end, how
the frontend kernel drivers should encode these values.) If there
documentation available that would explain this?
For example, the signal strength. All I know so far is that this is a
16-bit value. But then what? Do greater values represent stronger
signal or weaker signal? Are 0x and 0x special values? Is the
returned value meaningful even when FE_HAS_SIGNAL is 0? When
FE_HAS_LOCK is 0? Is the scale linear, or do some values have
well-defined meanings, or is it arbitrary and each driver can have its
own scale? What are the typical use cases by user-space application for
this value?
That's the kind of details I'd like to know, not only for the signal
strength, but also for the SNR, BER and UB. Without this information,
it seems a little difficult to have consistent frontend drivers.
We all want to know about that ;)
Seriously, the lack of a description of the meaning of the ranges for those
read values were already widely discussed at LMML and at the legacy dvb ML.
We should return this discussion again and decide what would be the better
way to describe those values.
My suggestion is that someone summarize the proposals we had and give some
time
for people vote. After that, we just commit the most voted one, and commit
the
patches for it. A pending question that should also be discussed is what we
will
do with those dvb devices where we simply don't know what scale it uses.
There
are several of them.
Sometime back, (some time in April) i proposed a patch which addressed
the issue to scale even those devices which have a weird scale or
none. Though based on an older tree of mine, here is the patch again.
If it looks good enough, i can port the patch to accomodate other
devices as well.
Regards,
Manu
Manu,
Sorry for not answering earlier. Due to my travels, I had a very big backlog
here
to handle.
I prefer a solution like you've proposed of creating a new set of API calls for
it, instead of re-defining the current calls.
Yet, I have a few comments:
diff -r b5505a985f24 linux/include/linux/dvb/frontend.h
--- a/linux/include/linux/dvb/frontend.hSat Feb 21 01:12:09 2009 +0400
+++ b/linux/include/linux/dvb/frontend.hTue Apr 07 18:19:22 2009 +0400
@@ -645,4 +645,118 @@
};
#define DVBFE_GET_EVENT_IOR('o', 86, struct
dvbfe_event)
+/* Frontend General Statistics
+ * General parameters
+ * FE_*_UNKNOWN:
+ * Parameter is unknown to the frontend and doesn't really
+ * make any sense for an application.
+ *
+ * FE_*_RELATIVE:
+ * Parameter is relative on the basis of a ceil - floor basis
+ * Format is based on empirical test to determine
+ * the floor and ceiling values. This format is exactly the
+ * same format as the existing statistics implementation.
+ */
+enum fecap_quality_params {
+ FE_QUALITY_UNKNOWN = 0,
+ FE_QUALITY_SNR = (1 0),
+ FE_QUALITY_CNR = (1 1),
+ FE_QUALITY_EsNo = (1 2),
+ FE_QUALITY_EbNo = (1 3),
+ FE_QUALITY_RELATIVE = (1 31),
+};
+
+enum fecap_scale_params {
+ FE_SCALE_UNKNOWN= 0,
+ FE_SCALE_dB = (1 0),
+ FE_SCALE_RELATIVE = (1 31),
+};
+
+enum fecap_error_params {
+ FE_ERROR_UNKNOWN= 0,
+ FE_ERROR_BER= (1 0),
+ FE_ERROR_PER= (1 1),
+ FE_ERROR_RELATIVE = (1 31),
+};
+
+enum fecap_unc_params {
+ FE_UNC_UNKNOWN = 0,
+ FE_UNC_RELATIVE = (1 31),
+};
+
+/* General parameters
+ * width:
+ * Specifies the width of the field
+ *
+ * exponent:
+ * Specifies the multiplier for the respective field
+ * MSB:1bit indicates the signdness of the parameter
+ */
+struct fecap_quality {
+ enum fecap_quality_params params;
+ enum fecap_scale_params scale;
+
+ __u32 width;
+ __s32 exponent;
+};
+
+struct fecap_strength {
+ enum fecap_scale_params params;
+ __u32 width;
+ __s32 exponent;
+};
+
+struct fecap_error {
+ enum fecap_error_params params;
+ __u32 width;
+
[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 Nov 17 19:00:03 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 1:e341e9e85af2 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: WARNINGS linux-2.6.23.12-armv5: WARNINGS linux-2.6.24.7-armv5: WARNINGS linux-2.6.25.11-armv5: WARNINGS linux-2.6.26-armv5: WARNINGS linux-2.6.27-armv5: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29.1-armv5: WARNINGS linux-2.6.30-armv5: WARNINGS linux-2.6.31-armv5: WARNINGS linux-2.6.32-rc6-armv5: ERRORS linux-2.6.32-rc6-armv5-davinci: ERRORS 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-armv5-ixp: WARNINGS linux-2.6.31-armv5-ixp: WARNINGS linux-2.6.32-rc6-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.31-armv5-omap2: ERRORS linux-2.6.32-rc6-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS 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-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.32-rc6-i686: WARNINGS linux-2.6.23.12-m32r: WARNINGS linux-2.6.24.7-m32r: WARNINGS linux-2.6.25.11-m32r: WARNINGS linux-2.6.26-m32r: WARNINGS linux-2.6.27-m32r: WARNINGS linux-2.6.28-m32r: WARNINGS linux-2.6.29.1-m32r: WARNINGS linux-2.6.30-m32r: WARNINGS linux-2.6.31-m32r: WARNINGS linux-2.6.32-rc6-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: WARNINGS linux-2.6.32-rc6-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-powerpc64: WARNINGS linux-2.6.31-powerpc64: WARNINGS linux-2.6.32-rc6-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS linux-2.6.32-rc6-x86_64: ERRORS sparse (linux-2.6.31): OK sparse (linux-2.6.32-rc6): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS 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 failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification failed to build, but the last compiled spec 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
Re: Details about DVB frontend API
On Tue, Nov 17, 2009 at 2:46 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: I don't like the idea of creating structs grouping those parameters. While for certain devices this may mean a more direct approach, for others, this may not make sense, due to the way their API's were implemented (for example, devices with firmware may need several calls to get all those info). There is some value in providing grouping the results in a single request - in many cases the data is based off of the same internal registers, and Manu's proposed approach allows for a more atomic response. The fact that we currently do the status, SNR, strength, and UNC/BER in separate calls is one reason that people sometimes see inconsistent results in the output of tools like zap. As an example, they can see lines in the zap output where the lock is lost but SNR appears fine. In the case where the driver servicing the query needs to do three calls, it could be slightly more expensive, but only if we believe that it is commonplace to ask for a subset of the stats. 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: new sensor for a t613 camera
Hello, people. I did it! I looked at the log and modified the driver to support my webcam. It's working!! I'm sending an image attached. :] I'll clean up my code now, and submit a patch later. Help is appreciated, because I don't have much experience contributing to large projects... This webcam is a very cheap one, quite easy to find these days. I hope the support will be appreciated by many users. See you, ++nicolau On Fri, Nov 13, 2009 at 03:35:26PM -0500, leandro Costantino wrote: Hi Nicolau, Are you able to give me some usb traces? there's a little how to http://deaglecito.blogspot.com/2008/10/new-sensor-merge-faq-tascorp-17a10128.html here. I don't have too much time now, but i can take a look and made some changes to test and guide you. Best Regards Costantino Leandro On Fri, Nov 13, 2009 at 3:27 PM, Nicolau Werneck nwern...@gmail.com wrote: On Fri, Nov 13, 2009 at 09:04:23PM +0100, Erik Andrén wrote: 2009/11/13 Nicolau Werneck nwern...@gmail.com: Hello. I bought me a new webcam. lsusb said me it was a 17a1:0128 device, for which the gspca_t613 module is available. But it did not recognize the sensor number, 0x0802. I fiddled with the driver source code, and just made it recognize it as a 0x0803 sensor, called others in the code, and I did get images from the camera. But the colors are extremely wrong, like the contrast was set to a very high number. It's probably some soft of color encoding gone wrong... How can I start hacking this driver to try to make my camera work under Linux? If possible you could open the camera to investigate if there is anything printed on the sensor chip. This might give you a clue to what sensor it is. Thanks for redirecting me. I opened it (So much for the warranty seal...), but there is just huge black blob of goo over the chip, as usual these days. ++nicolau -- Nicolau Werneck nwern...@gmail.com 1AAB 4050 1999 BDFF 4862 http://www.lti.pcs.usp.br/~nwerneck 4A33 D2B5 648B 4789 0327 Linux user #460716 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkr9wUIACgkQ0rVki0eJAycSegCfRQyYN54CNH2thIo/PHBnVaL9 avAAoMe6ihIbvX23kM1ir2sJK32q6jxm =HI4V -END PGP SIGNATURE- -- 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 -- Nicolau Werneck nwern...@gmail.com 1AAB 4050 1999 BDFF 4862 http://www.lti.pcs.usp.br/~nwerneck 4A33 D2B5 648B 4789 0327 Linux user #460716 signature.asc Description: Digital signature
Re: saa7134 module load problem
On Mon, Nov 16, 2009 at 1:10 PM, Gordon Smith spider.karma+linux-me...@gmail.com wrote: Hello - I'm unable to find a working environment for saa7134 based RTD Technologies VFG7350 (two channel, no tuner) using vanilla kernel. Please disregard, apparently this is a problem with busybox modprobe. -- 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
em28xx not detected: Please send an email with this log to linux-media@vger.kernel.org
Hi, I've got a MSI VOX USB2.0 Video grabber (analog TV in, USB framegrabber out) which is partially detected with Linux 2.6.31-11-generic (Ubuntu version). The logs suggest that I E-mail the output of the logs to here, so that's what I do. The dmesg log says: [ 6672.753915] em28xx: New device @ 480 Mbps (eb1a:2820, interface 0, class 0) [ 6672.754323] em28xx #0: chip ID is em2820 (or em2710) [ 6672.844662] em28xx #0: board has no eeprom [ 6672.856403] em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) [ 6672.871904] em28xx #0: found i2c device @ 0x42 [???] [ 6672.878901] em28xx #0: found i2c device @ 0x66 [???] [ 6672.879273] em28xx #0: found i2c device @ 0x68 [???] [ 6672.885150] em28xx #0: found i2c device @ 0x86 [tda9887] [ 6672.896149] em28xx #0: found i2c device @ 0xc0 [tuner (analog)] [ 6672.896523] em28xx #0: found i2c device @ 0xc2 [tuner (analog)] [ 6672.907900] em28xx #0: Your board has no unique USB ID and thus need a hint to be detected. [ 6672.907906] em28xx #0: You may try to use card=n insmod option to workaround that. [ 6672.907908] em28xx #0: Please send an email with this log to: [ 6672.907911] em28xx #0: V4L Mailing List linux-media@vger.kernel.org [ 6672.907914] em28xx #0: Board eeprom hash is 0x [ 6672.907916] em28xx #0: Board i2c devicelist hash is 0x742400f0 When adding the 'card=5' option, the log changes to: [10013.346671] em28xx: New device @ 480 Mbps (eb1a:2820, interface 0, class 0) [10013.347112] em28xx #0: chip ID is em2820 (or em2710) [10013.449303] em28xx #0: board has no eeprom [10013.449985] em28xx #0: Identified as MSI VOX USB 2.0 (card=5) [10013.848477] saa7115 1-0021: saa7114 found (1f7114d0e00) @ 0x42 (em28xx #0) [10016.177760] tuner 1-0043: chip found @ 0x86 (em28xx #0) [10016.177869] tda9887 1-0043: creating new instance [10016.177873] tda9887 1-0043: tda988[5/6/7] found [10016.192029] All bytes are equal. It is not a TEA5767 [10016.192163] tuner 1-0060: chip found @ 0xc0 (em28xx #0) [10016.193010] tuner-simple 1-0060: creating new instance [10016.193015] tuner-simple 1-0060: type set to 37 (LG PAL (newer TAPC series)) [10016.240382] em28xx #0: Config register raw data: 0x00 [10016.372077] em28xx #0: v4l2 driver version 0.1.2 [10016.836166] em28xx #0: V4L2 device registered as /dev/video0 and /dev/vbi0 [10016.848106] usbcore: registered new interface driver em28xx [10016.848114] em28xx driver loaded Now xawtv and mplayer do not seem to work: xawtv hangs when changing input. mplayer tv:// gives v4l2: current audio mode is : MONO v4l2: ioctl set format failed: Invalid argument v4l2: ioctl set format failed: Invalid argument v4l2: ioctl set format failed: Invalid argument v4l2: ioctl queue buffer failed: Cannot allocate memory v4l2: 0 frames successfully processed, 0 frames dropped. Any ideas? Rutger. -- 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: Details about DVB frontend API
On Tue, 17 Nov 2009 14:55:51 -0500, Devin Heitmueller wrote: On Tue, Nov 17, 2009 at 2:46 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: I don't like the idea of creating structs grouping those parameters. While for certain devices this may mean a more direct approach, for others, this may not make sense, due to the way their API's were implemented (for example, devices with firmware may need several calls to get all those info). There is some value in providing grouping the results in a single request - in many cases the data is based off of the same internal registers, and Manu's proposed approach allows for a more atomic response. The fact that we currently do the status, SNR, strength, and UNC/BER in separate calls is one reason that people sometimes see inconsistent results in the output of tools like zap. As an example, they can see lines in the zap output where the lock is lost but SNR appears fine. In the case where the driver servicing the query needs to do three calls, it could be slightly more expensive, but only if we believe that it is commonplace to ask for a subset of the stats. For what it's worth, we have solved this problem in hwmon driver the following way: we cache related values (read from the same register or set of registers) for ~1 second. When user-space requests the information, if the cache is fresh it is used, otherwise the cache is first refreshed. That way we ensure that data returned to nearby user-space calls are taken from the same original register value. One advantage is that we thus did not have to map the API to the hardware register constraints and thus have the guarantee that all hardware designs fit. I don't know if a similar logic would help for DVB. -- 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
[PATCH 0/3] pxa_camera: remove init() callback
Hi, this series removes the init() callback from pxa_camera_platform_data, and fixes its users to do initialization statically at machine init time. Guennadi requested this change because there seems to be no use cases for dynamic initialization. I also believe that the current semantics for this init() callback is ambiguous anyways, it is invoked in pxa_camera_activate(), hence at device node open, but its users use it like a generic initialization to be done at module init time (configure MFP, request GPIOs for *sensor* control). So removing it is definitely good. As a side note, If we were really exposing some dynamic and generic initialization, this could be done in soc-camera itself, not in pxa_camera anyways. Thanks, Antonio Antonio Ospite (3): em-x270: don't use pxa_camera init() callback pcm990-baseboard: don't use pxa_camera init() callback pxa_camera: remove init() callback arch/arm/mach-pxa/em-x270.c |9 + arch/arm/mach-pxa/include/mach/camera.h |2 -- arch/arm/mach-pxa/pcm990-baseboard.c|8 +--- drivers/media/video/pxa_camera.c| 10 -- 4 files changed, 6 insertions(+), 23 deletions(-) -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- 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/3] em-x270: don't use pxa_camera init() callback
pxa_camera init() is going to be removed.
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
---
arch/arm/mach-pxa/em-x270.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa/em-x270.c
index aec7f42..f71f34c 100644
--- a/arch/arm/mach-pxa/em-x270.c
+++ b/arch/arm/mach-pxa/em-x270.c
@@ -967,7 +967,7 @@ static inline void em_x270_init_gpio_keys(void) {}
#if defined(CONFIG_VIDEO_PXA27x) || defined(CONFIG_VIDEO_PXA27x_MODULE)
static struct regulator *em_x270_camera_ldo;
-static int em_x270_sensor_init(struct device *dev)
+static int em_x270_sensor_init(void)
{
int ret;
@@ -996,7 +996,6 @@ static int em_x270_sensor_init(struct device *dev)
}
struct pxacamera_platform_data em_x270_camera_platform_data = {
- .init = em_x270_sensor_init,
.flags = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 |
PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN,
.mclk_10khz = 2600,
@@ -1049,8 +1048,10 @@ static struct platform_device em_x270_camera = {
static void __init em_x270_init_camera(void)
{
- pxa_set_camera_info(em_x270_camera_platform_data);
- platform_device_register(em_x270_camera);
+ if (em_x270_sensor_init() == 0) {
+ pxa_set_camera_info(em_x270_camera_platform_data);
+ platform_device_register(em_x270_camera);
+ }
}
#else
static inline void em_x270_init_camera(void) {}
--
1.6.5.2
--
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/3] pcm990-baseboard: don't use pxa_camera init() callback
pxa_camera init() is going to be removed.
Configure PXA CIF pins directly in machine init function.
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
---
arch/arm/mach-pxa/pcm990-baseboard.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
b/arch/arm/mach-pxa/pcm990-baseboard.c
index bbda570..d5255ae 100644
--- a/arch/arm/mach-pxa/pcm990-baseboard.c
+++ b/arch/arm/mach-pxa/pcm990-baseboard.c
@@ -359,19 +359,12 @@ static unsigned long pcm990_camera_pin_config[] = {
GPIO44_CIF_LV,
};
-static int pcm990_pxacamera_init(struct device *dev)
-{
- pxa2xx_mfp_config(ARRAY_AND_SIZE(pcm990_camera_pin_config));
- return 0;
-}
-
/*
* CICR4: PCLK_EN: Pixel clock is supplied by the sensor
* MCLK_EN:Master clock is generated by PXA
* PCP:Data sampled on the falling edge of pixel clock
*/
struct pxacamera_platform_data pcm990_pxacamera_platform_data = {
- .init = pcm990_pxacamera_init,
.flags = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 |
PXA_CAMERA_DATAWIDTH_10 |
PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN/* | PXA_CAMERA_PCP*/,
.mclk_10khz = 1000,
@@ -532,6 +525,7 @@ void __init pcm990_baseboard_init(void)
pxa_set_ac97_info(NULL);
#if defined(CONFIG_VIDEO_PXA27x) || defined(CONFIG_VIDEO_PXA27x_MODULE)
+ pxa2xx_mfp_config(ARRAY_AND_SIZE(pcm990_camera_pin_config));
pxa_set_camera_info(pcm990_pxacamera_platform_data);
i2c_register_board_info(0, ARRAY_AND_SIZE(pcm990_i2c_devices));
--
1.6.5.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] pxa_camera: remove init() callback
pxa_camera init() callback is sometimes abused to setup MFP for PXA CIF, or
even to request GPIOs to be used by the camera *sensor*. These initializations
can be performed statically in machine init functions.
The current semantics for this init() callback is ambiguous anyways, it is
invoked in pxa_camera_activate(), hence at device node open, but its users use
it like a generic initialization to be done at module init time (configure
MFP, request GPIOs for *sensor* control).
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
---
arch/arm/mach-pxa/include/mach/camera.h |2 --
drivers/media/video/pxa_camera.c| 10 --
2 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-pxa/include/mach/camera.h
b/arch/arm/mach-pxa/include/mach/camera.h
index 31abe6d..6709b1c 100644
--- a/arch/arm/mach-pxa/include/mach/camera.h
+++ b/arch/arm/mach-pxa/include/mach/camera.h
@@ -35,8 +35,6 @@
#define PXA_CAMERA_VSP 0x400
struct pxacamera_platform_data {
- int (*init)(struct device *);
-
unsigned long flags;
unsigned long mclk_10khz;
};
diff --git a/drivers/media/video/pxa_camera.c b/drivers/media/video/pxa_camera.c
index 51b683c..49f2bf9 100644
--- a/drivers/media/video/pxa_camera.c
+++ b/drivers/media/video/pxa_camera.c
@@ -882,18 +882,8 @@ static void recalculate_fifo_timeout(struct pxa_camera_dev
*pcdev,
static void pxa_camera_activate(struct pxa_camera_dev *pcdev)
{
- struct pxacamera_platform_data *pdata = pcdev-pdata;
- struct device *dev = pcdev-soc_host.v4l2_dev.dev;
u32 cicr4 = 0;
- dev_dbg(dev, Registered platform device at %p data %p\n,
- pcdev, pdata);
-
- if (pdata pdata-init) {
- dev_dbg(dev, %s: Init gpios\n, __func__);
- pdata-init(dev);
- }
-
/* disable all interrupts */
__raw_writel(0x3ff, pcdev-base + CICR0);
--
1.6.5.2
--
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 5/5] dvb: make struct videobuf_queue_ops constant
From: Jonathan Corbet cor...@lwn.net
The videobuf_queue_ops function vector is not declared constant, but
there's no need for the videobuf layer to ever change it. Make it const
so that videobuf users can make their operations const without warnings.
Signed-off-by: Jonathan Corbet cor...@lwn.net
Cc: Mauro Carvalho Chehab mche...@infradead.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/media/video/videobuf-core.c |2 +-
drivers/media/video/videobuf-dma-contig.c |2 +-
drivers/media/video/videobuf-dma-sg.c |2 +-
drivers/media/video/videobuf-vmalloc.c|2 +-
include/media/videobuf-core.h |4 ++--
include/media/videobuf-dma-contig.h |2 +-
include/media/videobuf-dma-sg.h |2 +-
include/media/videobuf-vmalloc.h |2 +-
8 files changed, 9 insertions(+), 9 deletions(-)
diff -puN
drivers/media/video/videobuf-core.c~dvb-make-struct-videobuf_queue_ops-constant
drivers/media/video/videobuf-core.c
---
a/drivers/media/video/videobuf-core.c~dvb-make-struct-videobuf_queue_ops-constant
+++ a/drivers/media/video/videobuf-core.c
@@ -110,7 +110,7 @@ EXPORT_SYMBOL_GPL(videobuf_queue_to_vmal
void videobuf_queue_core_init(struct videobuf_queue *q,
-struct videobuf_queue_ops *ops,
+const struct videobuf_queue_ops *ops,
struct device *dev,
spinlock_t *irqlock,
enum v4l2_buf_type type,
diff -puN
drivers/media/video/videobuf-dma-contig.c~dvb-make-struct-videobuf_queue_ops-constant
drivers/media/video/videobuf-dma-contig.c
---
a/drivers/media/video/videobuf-dma-contig.c~dvb-make-struct-videobuf_queue_ops-constant
+++ a/drivers/media/video/videobuf-dma-contig.c
@@ -428,7 +428,7 @@ static struct videobuf_qtype_ops qops =
};
void videobuf_queue_dma_contig_init(struct videobuf_queue *q,
- struct videobuf_queue_ops *ops,
+ const struct videobuf_queue_ops *ops,
struct device *dev,
spinlock_t *irqlock,
enum v4l2_buf_type type,
diff -puN
drivers/media/video/videobuf-dma-sg.c~dvb-make-struct-videobuf_queue_ops-constant
drivers/media/video/videobuf-dma-sg.c
---
a/drivers/media/video/videobuf-dma-sg.c~dvb-make-struct-videobuf_queue_ops-constant
+++ a/drivers/media/video/videobuf-dma-sg.c
@@ -702,7 +702,7 @@ void *videobuf_sg_alloc(size_t size)
}
void videobuf_queue_sg_init(struct videobuf_queue* q,
-struct videobuf_queue_ops *ops,
+const struct videobuf_queue_ops *ops,
struct device *dev,
spinlock_t *irqlock,
enum v4l2_buf_type type,
diff -puN
drivers/media/video/videobuf-vmalloc.c~dvb-make-struct-videobuf_queue_ops-constant
drivers/media/video/videobuf-vmalloc.c
---
a/drivers/media/video/videobuf-vmalloc.c~dvb-make-struct-videobuf_queue_ops-constant
+++ a/drivers/media/video/videobuf-vmalloc.c
@@ -391,7 +391,7 @@ static struct videobuf_qtype_ops qops =
};
void videobuf_queue_vmalloc_init(struct videobuf_queue* q,
-struct videobuf_queue_ops *ops,
+const struct videobuf_queue_ops *ops,
void *dev,
spinlock_t *irqlock,
enum v4l2_buf_type type,
diff -puN
include/media/videobuf-core.h~dvb-make-struct-videobuf_queue_ops-constant
include/media/videobuf-core.h
--- a/include/media/videobuf-core.h~dvb-make-struct-videobuf_queue_ops-constant
+++ a/include/media/videobuf-core.h
@@ -166,7 +166,7 @@ struct videobuf_queue {
enum v4l2_fieldfield;
enum v4l2_fieldlast; /* for field=V4L2_FIELD_ALTERNATE */
struct videobuf_buffer *bufs[VIDEO_MAX_FRAME];
- struct videobuf_queue_ops *ops;
+ const struct videobuf_queue_ops *ops;
struct videobuf_qtype_ops *int_ops;
unsigned int streaming:1;
@@ -195,7 +195,7 @@ void *videobuf_queue_to_vmalloc (struct
struct videobuf_buffer *buf);
void videobuf_queue_core_init(struct videobuf_queue *q,
-struct videobuf_queue_ops *ops,
+const struct videobuf_queue_ops *ops,
struct device *dev,
spinlock_t *irqlock,
enum v4l2_buf_type type,
diff -puN
include/media/videobuf-dma-contig.h~dvb-make-struct-videobuf_queue_ops-constant
include/media/videobuf-dma-contig.h
---
a/include/media/videobuf-dma-contig.h~dvb-make-struct-videobuf_queue_ops-constant
+++ a/include/media/videobuf-dma-contig.h
@@ -17,7 +17,7 @@
#include media/videobuf-core.h
void videobuf_queue_dma_contig_init(struct videobuf_queue *q,
[patch 3/5] drivers/media/video: Move dereference after NULL test
From: Julia Lawall ju...@diku.dk
In quickcam_messenger.c, if the NULL test on uvd is needed, then the
dereference should be after the NULL test.
In vpif_display.c, std_info is initialized to the address of a structure
field. This seems unlikely to be NULL. If it could somehow be NULL, then
the assignment should be moved after the NULL test. Alternatively, perhaps
the NULL test is intended to test std_info-stdid rather than std_info?
In saa7134-alsa.c, the function is only called from one place, where the
chip argument has already been dereferenced. On the other hand, if it
should be kept, then card should be initialized after it.
A simplified version of the semantic match that detects this problem is as
follows (http://coccinelle.lip6.fr/):
// smpl
@match exists@
expression x, E;
identifier fld;
@@
* x-fld
... when != \(x = E\|x\)
* x == NULL
// /smpl
Signed-off-by: Julia Lawall ju...@diku.dk
Cc: Mauro Carvalho Chehab mche...@infradead.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/media/video/davinci/vpif_display.c|2 --
drivers/media/video/saa7134/saa7134-alsa.c|2 --
drivers/media/video/usbvideo/quickcam_messenger.c |3 ++-
3 files changed, 2 insertions(+), 5 deletions(-)
diff -puN
drivers/media/video/davinci/vpif_display.c~drivers-media-video-move-dereference-after-null-test
drivers/media/video/davinci/vpif_display.c
---
a/drivers/media/video/davinci/vpif_display.c~drivers-media-video-move-dereference-after-null-test
+++ a/drivers/media/video/davinci/vpif_display.c
@@ -383,8 +383,6 @@ static int vpif_get_std_info(struct chan
int index;
std_info-stdid = vid_ch-stdid;
- if (!std_info)
- return -1;
for (index = 0; index ARRAY_SIZE(ch_params); index++) {
config = ch_params[index];
diff -puN
drivers/media/video/saa7134/saa7134-alsa.c~drivers-media-video-move-dereference-after-null-test
drivers/media/video/saa7134/saa7134-alsa.c
---
a/drivers/media/video/saa7134/saa7134-alsa.c~drivers-media-video-move-dereference-after-null-test
+++ a/drivers/media/video/saa7134/saa7134-alsa.c
@@ -1011,8 +1011,6 @@ static int snd_card_saa7134_new_mixer(sn
unsigned int idx;
int err, addr;
- if (snd_BUG_ON(!chip))
- return -EINVAL;
strcpy(card-mixername, SAA7134 Mixer);
for (idx = 0; idx ARRAY_SIZE(snd_saa7134_volume_controls); idx++) {
diff -puN
drivers/media/video/usbvideo/quickcam_messenger.c~drivers-media-video-move-dereference-after-null-test
drivers/media/video/usbvideo/quickcam_messenger.c
---
a/drivers/media/video/usbvideo/quickcam_messenger.c~drivers-media-video-move-dereference-after-null-test
+++ a/drivers/media/video/usbvideo/quickcam_messenger.c
@@ -692,12 +692,13 @@ static int qcm_start_data(struct uvd *uv
static void qcm_stop_data(struct uvd *uvd)
{
- struct qcm *cam = (struct qcm *) uvd-user_data;
+ struct qcm *cam;
int i, j;
int ret;
if ((uvd == NULL) || (!uvd-streaming) || (uvd-dev == NULL))
return;
+ cam = (struct qcm *) uvd-user_data;
ret = qcm_camera_off(uvd);
if (ret)
_
--
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/5] sms-cards: make id unsigned in sms_get_board()
From: Roel Kluin roel.kl...@gmail.com
Make id signed so we can't get an invalid pointer when we pass a negative
id.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Michael Krufky mkru...@kernellabs.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/media/dvb/siano/sms-cards.c |2 +-
drivers/media/dvb/siano/sms-cards.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff -puN
drivers/media/dvb/siano/sms-cards.c~sms-cards-make-id-unsigned-in-sms_get_board
drivers/media/dvb/siano/sms-cards.c
---
a/drivers/media/dvb/siano/sms-cards.c~sms-cards-make-id-unsigned-in-sms_get_board
+++ a/drivers/media/dvb/siano/sms-cards.c
@@ -97,7 +97,7 @@ static struct sms_board sms_boards[] = {
},
};
-struct sms_board *sms_get_board(int id)
+struct sms_board *sms_get_board(unsigned id)
{
BUG_ON(id = ARRAY_SIZE(sms_boards));
diff -puN
drivers/media/dvb/siano/sms-cards.h~sms-cards-make-id-unsigned-in-sms_get_board
drivers/media/dvb/siano/sms-cards.h
---
a/drivers/media/dvb/siano/sms-cards.h~sms-cards-make-id-unsigned-in-sms_get_board
+++ a/drivers/media/dvb/siano/sms-cards.h
@@ -81,7 +81,7 @@ struct sms_board {
int led_power, led_hi, led_lo, lna_ctrl, rf_switch;
};
-struct sms_board *sms_get_board(int id);
+struct sms_board *sms_get_board(unsigned id);
extern struct smscore_device_t *coredev;
_
--
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/5] konicawc.c: possible buffer overflow while use strncat
From: Alexander Strakh str...@ispras.ru
In driver ./drivers/media/video/usbvideo/konicawc.c in line 227:
227 usb_make_path(dev, cam-input_physname,
sizeof(cam-input_physname));
After this line we use strncat:
228 strncat(cam-input_physname, /input0,
sizeof(cam-input_physname));
where sizeof(cam-input_physname) returns length of cam-input_phisname
without length for null-symbol. But this parameter must be - maximum
numbers of bytes to copy, i.e.:
sizeof(cam-input_physname)-strlen(cam-input_physname)-1.
In this case, after call to usb_make_path the similar drivers use strlcat.
Like in drivers/hid/usbhid/hid-core.c:
1152 usb_make_path(dev, hid-phys, sizeof(hid-phys));
1153 strlcat(hid-phys, /input, sizeof(hid-phys));
Found by Linux Driver Verification Project.
Use strlcat instead of strncat.
Signed-off-by: Alexander Strakh str...@ispras.ru
Cc: Mauro Carvalho Chehab mche...@infradead.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/media/video/usbvideo/konicawc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN
drivers/media/video/usbvideo/konicawc.c~konicawcc-possible-buffer-overflow-while-use-strncat
drivers/media/video/usbvideo/konicawc.c
---
a/drivers/media/video/usbvideo/konicawc.c~konicawcc-possible-buffer-overflow-while-use-strncat
+++ a/drivers/media/video/usbvideo/konicawc.c
@@ -225,7 +225,7 @@ static void konicawc_register_input(stru
int error;
usb_make_path(dev, cam-input_physname, sizeof(cam-input_physname));
- strncat(cam-input_physname, /input0, sizeof(cam-input_physname));
+ strlcat(cam-input_physname, /input0, sizeof(cam-input_physname));
cam-input = input_dev = input_allocate_device();
if (!input_dev) {
_
--
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/5] quickcam_messenger.c: possible buffer overflow while use strncat
From: Alexander Strakh str...@ispras.ru
In driver ./drivers/media/video/usbvideo/quickcam_messenger.c in line 91:
91 usb_make_path(dev, cam-input_physname,
sizeof(cam-input_physname));
After this line we use strncat:
92 strncat(cam-input_physname, /input0,
sizeof(cam-input_physname));
where sizeof(cam-input_physname) returns length of cam-input_phisname
without length for null-symbol. But this parameter must be - maximum
numbers of bytes to copy, i.e.:
sizeof(cam-input_physname)-strlen(cam-input_physname)-1.
In this case, after call to usb_make_path the similar drivers use strlcat.
Like in: drivers/hid/usbhid/hid-core.c:
1152 usb_make_path(dev, hid-phys, sizeof(hid-phys));
1153 strlcat(hid-phys, /input, sizeof(hid-phys));
Found by Linux Driver Verification Project.
Use strlcat instead of strncat.
Signed-off-by: Alexander Strakh str...@ispras.ru
Cc: Mauro Carvalho Chehab mche...@infradead.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/media/video/usbvideo/quickcam_messenger.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN
drivers/media/video/usbvideo/quickcam_messenger.c~quickcam_messengerc-possible-buffer-overflow-while-use-strncat
drivers/media/video/usbvideo/quickcam_messenger.c
---
a/drivers/media/video/usbvideo/quickcam_messenger.c~quickcam_messengerc-possible-buffer-overflow-while-use-strncat
+++ a/drivers/media/video/usbvideo/quickcam_messenger.c
@@ -89,7 +89,7 @@ static void qcm_register_input(struct qc
int error;
usb_make_path(dev, cam-input_physname, sizeof(cam-input_physname));
- strncat(cam-input_physname, /input0, sizeof(cam-input_physname));
+ strlcat(cam-input_physname, /input0, sizeof(cam-input_physname));
cam-input = input_dev = input_allocate_device();
if (!input_dev) {
_
--
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: Help in adding documentation
Mauro, Thanks to your help, I could finish my documentation today. But I have another issue with the v4l2-apps. When I do make apps, it doesn't seem to build. I get the following error logs... Is this broken? Thanks. Murali make -C /local/mkaricheri/davinci_git/video_timing/new_v4l2-dvb/v4l-dvb-aba823ecaea6/v4l apps make[1]: Entering directory `/local/mkaricheri/davinci_git/video_timing/new_v4l2-dvb/v4l-dvb-aba823ecaea6/v4l' make -C ../v4l2-apps make[2]: Entering directory `/local/mkaricheri/davinci_git/video_timing/new_v4l2-dvb/v4l-dvb-aba823ecaea6/v4l2-apps' if [ ! -d include ]; then \ cp -r ../linux/include include ; \ ../v4l/scripts/headers_convert.pl `find include -type f` ; \ fi make -C libv4l all make[3]: Entering directory `/local/mkaricheri/davinci_git/video_timing/new_v4l2-dvb/v4l-dvb-aba823ecaea6/v4l2-apps/libv4l' make -C libv4lconvert V4L2_LIB_VERSION=0.6.2-test all make[4]: Entering directory `/local/mkaricheri/davinci_git/video_timing/new_v4l2-dvb/v4l-dvb-aba823ecaea6/v4l2-apps/libv4l/libv4lconvert' cc -Wp,-MMD,libv4lconvert.d,-MQ,libv4lconvert.o,-MP -c -I../include -I../../../include -fvisibility=hidden -fPIC -DLIBDIR=\/usr/local/lib\ -DLIBSUBDIR=\libv4l\ -g -O1 -Wall -Wno-unused -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -o libv4lconvert.o libv4lconvert.c In file included from libv4lconvert.c:25: ../include/libv4lconvert.h:100: warning: struct v4l2_frmsizeenum declared inside parameter list ../include/libv4lconvert.h:100: warning: its scope is only this definition or declaration, which is probably not what you want ../include/libv4lconvert.h:105: warning: struct v4l2_frmivalenum declared inside parameter list In file included from libv4lconvert.c:26: libv4lconvert-priv.h:129: error: field `framesizes' has incomplete type libv4lconvert.c: In function `v4lconvert_get_framesizes': libv4lconvert.c:1121: error: variable `frmsize' has initializer but incomplete type libv4lconvert.c:1121: error: unknown field `pixel_format' specified in initializer libv4lconvert.c:1121: warning: excess elements in struct initializer libv4lconvert.c:1121: warning: (near initialization for `frmsize') libv4lconvert.c:1121: error: storage size of 'frmsize' isn't known libv4lconvert.c:1125: error: `VIDIOC_ENUM_FRAMESIZES' undeclared (first use in this function) libv4lconvert.c:1125: error: (Each undeclared identifier is reported only once libv4lconvert.c:1125: error: for each function it appears in.) libv4lconvert.c:1135: error: `V4L2_FRMSIZE_TYPE_DISCRETE' undeclared (first use in this function) libv4lconvert.c:1140: error: `V4L2_FRMSIZE_TYPE_CONTINUOUS' undeclared (first use in this function) libv4lconvert.c:1141: error: `V4L2_FRMSIZE_TYPE_STEPWISE' undeclared (first use in this function) libv4lconvert.c: In function `v4lconvert_enum_framesizes': libv4lconvert.c:1180: error: dereferencing pointer to incomplete type libv4lconvert.c:1185: error: `VIDIOC_ENUM_FRAMESIZES' undeclared (first use in this function) libv4lconvert.c:1188: error: dereferencing pointer to incomplete type libv4lconvert.c:1193: error: dereferencing pointer to incomplete type libv4lconvert.c:1193: error: dereferencing pointer to incomplete type libv4lconvert.c:1194: error: dereferencing pointer to incomplete type libv4lconvert.c:1195: error: `V4L2_FRMSIZE_TYPE_DISCRETE' undeclared (first use in this function) libv4lconvert.c:1196: error: dereferencing pointer to incomplete type libv4lconvert.c:1196: error: dereferencing pointer to incomplete type libv4lconvert.c:1198: error: dereferencing pointer to incomplete type libv4lconvert.c:1199: error: dereferencing pointer to incomplete type libv4lconvert.c:1201: error: `V4L2_FRMSIZE_TYPE_CONTINUOUS' undeclared (first use in this function) libv4lconvert.c:1202: error: `V4L2_FRMSIZE_TYPE_STEPWISE' undeclared (first use in this function) libv4lconvert.c:1203: error: dereferencing pointer to incomplete type libv4lconvert.c:1203: error: dereferencing pointer to incomplete type libv4lconvert.c: At top level: libv4lconvert.c:1211: warning: struct v4l2_frmivalenum declared inside parameter list libv4lconvert.c:1212: error: conflicting types for 'v4lconvert_enum_frameintervals' ../include/libv4lconvert.h:105: error: previous declaration of 'v4lconvert_enum_frameintervals' was here libv4lconvert.c:1212: error: conflicting types for 'v4lconvert_enum_frameintervals' ../include/libv4lconvert.h:105: error: previous declaration of 'v4lconvert_enum_frameintervals' was here libv4lconvert.c: In function `v4lconvert_enum_frameintervals': libv4lconvert.c:1216: error: dereferencing pointer to incomplete type libv4lconvert.c:1221: error: `VIDIOC_ENUM_FRAMEINTERVALS' undeclared (first use in this function) libv4lconvert.c:1230: error: dereferencing pointer to incomplete type libv4lconvert.c:1231: error: dereferencing pointer to incomplete type libv4lconvert.c:1232: error: dereferencing pointer to incomplete type libv4lconvert.c:1240: error: dereferencing pointer to
v4l: Add video_device_node_name function
Many drivers access the device number (video_device::v4l2_devnode::num)
in order to print the video device node name. Add and use a helper
function to retrieve the video_device node name.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Index: v4l-dvb-mc-uvc/linux/drivers/media/video/v4l2-dev.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/media/video/v4l2-dev.c
+++ v4l-dvb-mc-uvc/linux/drivers/media/video/v4l2-dev.c
@@ -619,8 +619,8 @@ static int __video_register_device(struc
vdev-dev.release = v4l2_device_release;
if (nr != -1 nr != vdev-num warn_if_nr_in_use)
- printk(KERN_WARNING %s: requested %s%d, got %s%d\n,
- __func__, name_base, nr, name_base, vdev-num);
+ printk(KERN_WARNING %s: requested %s%d, got %s\n, __func__,
+ name_base, nr, video_device_node_name(vdev));
/* Part 5: Activate this minor. The char device can now be used. */
mutex_lock(videodev_lock);
Index: v4l-dvb-mc-uvc/linux/include/media/v4l2-dev.h
===
--- v4l-dvb-mc-uvc.orig/linux/include/media/v4l2-dev.h
+++ v4l-dvb-mc-uvc/linux/include/media/v4l2-dev.h
@@ -153,6 +153,15 @@ static inline void *video_drvdata(struct
return video_get_drvdata(video_devdata(file));
}
+static inline const char *video_device_node_name(struct video_device *vdev)
+{
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 19)
+ return vdev-dev.class_id;
+#else
+ return dev_name(vdev-dev);
+#endif
+}
+
static inline int video_is_unregistered(struct video_device *vdev)
{
return test_bit(V4L2_FL_UNREGISTERED, vdev-flags);
--
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] V4L core cleanups
Hi everybody, this patch sets attemp to clean up the V4L core to remove the video_device::minor and video_device::num references in most drivers. There are two reasons for this. The first one is that drivers really shouldn't care about those fields, especially the minor number. This doesn't mean a driver can't request a specific device number, that remains a perfectly valid use case, but most use cases of those fields after device registration shouldn't be needed. The second reason is that most drivers use those fields in bogus ways, making it obvious they shouldn't have cared about them in the first place :-) We've had a video_drvdata function for a long time, but many drivers still have their own private minor - data mapping lists for historical reasons. That code is error prone and completely unneeded. So this patch sets tries to clean up the V4L core by porting drivers to the most recent APIs (which are actually quite old) and introducing a new helper function. The first two patches add and use the video_device_node_name function. The function returns a const pointer to the video device name. On systems using udev, the name is passed as a hint to udev and will likely become the /dev device node name, unless overwritten by udev rules (I've heard that some distributions put the V4L device nodes in /dev/v4l). Some drivers erroneously created the name from the video_device::minor field instead of video_device::num, which is fixed by the second patch. This is an example video_device_node_name usage typical from what can be found in the second patch. - printk(KERN_INFO bttv%d: registered device radio%d\n, - btv-c.nr, btv-radio_dev-num); + printk(KERN_INFO bttv%d: registered device %s\n, + btv-c.nr, video_device_node_name(btv-radio_dev)); The third patch removes left video_device::num usage from the drivers. The field was used to create information strings that shouldn't include the device node name (such as video_device::name) or that should be created using a stable identifier (such as i2c_adapter::name). The fourth, fifth and sixth patches replace video_is_unregistered with video_is_registered and use the new function in device drivers. As explained in the fourth patch commit message, the rationale behind that is to have video_is_registered return false when called on an initialized but not yet registered video_device instance. The function can be used instead of checking video_device::minor manually, making it less error-prone as drivers don't need to make sure they video_device::minor to -1 correctly for all error paths. A typical use case is - if (-1 != dev-radio_dev-minor) + if (video_is_registered(dev-radio_dev)) video_unregister_device(dev-radio_dev); else video_device_release(dev-radio_dev); The seventh patch replace local minor to data lists by video_drvdata(). The function has been there for a long time but wasn't used by many drivers, probably because they were written before it was available, or, for some of them, because they were written based on drivers that were not using it. This patch removes lots of identical unneeded code blocks, making the result less bug-prone. The eight patch removes now unneeded video_device::minor assignments to -1, as the previous patches made them unneeded. The last patch removes a few more video_device::minor users. As explained in the patch description, the field was used either to - test for error conditions that can't happen anymore with the current v4l-dvb core, - store the value in a driver private field that isn't used anymore, - check the video device type where video_device::vfl_type should be used, or - create the name of a kernel thread that should get a stable name. There are still two video_device::num users and those can easily be removed. Hans Verkuil is working on a patch, as one of the drivers is the ivtv driver and the other one is based on the same code. There are also still a few video_device::minor users. One of them is the pvrusb2 driver that creates sysfs attributes storing the minor numbers of the device nodes created by the driver. I'm not sure what to do about that one. All the others are V4L1 drivers that need the minor number for the VIDIOCGUNIT ioctl. Hopefully that will die when the drivers will be ported to V4L2 :-) I've split the patches into core and device patches to make them easier to apply on my work trees. I'll merge the core and device code together when submitting a pull request to avoid bisection errors. I'll send a pull request after receiving (and incorporating) your comments, or in a few days if there's no comments. Regards, Laurent Pinchart -- 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
v4l: Remove video_device::num usage from device drivers
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Index: v4l-dvb-mc-uvc/linux/drivers/media/video/vivi.c === --- v4l-dvb-mc-uvc.orig/linux/drivers/media/video/vivi.c +++ v4l-dvb-mc-uvc/linux/drivers/media/video/vivi.c @@ -1376,9 +1376,6 @@ static int __init vivi_create_instance(i /* Now that everything is fine, let's add it to device list */ list_add_tail(dev-vivi_devlist, vivi_devlist); - snprintf(vfd-name, sizeof(vfd-name), %s (%i), - vivi_template.name, vfd-num); - if (video_nr = 0) video_nr++; Index: v4l-dvb-mc-uvc/linux/drivers/media/video/w9968cf.c === --- v4l-dvb-mc-uvc.orig/linux/drivers/media/video/w9968cf.c +++ v4l-dvb-mc-uvc/linux/drivers/media/video/w9968cf.c @@ -2891,8 +2891,7 @@ static long w9968cf_v4l_ioctl(struct fil .minwidth = cam-minwidth, .minheight = cam-minheight, }; - sprintf(cap.name, W996[87]CF USB Camera #%d, - cam-v4ldev-num); + sprintf(cap.name, W996[87]CF USB Camera); cap.maxwidth = (cam-upscaling w9968cf_vpp) ? max((u16)W9968CF_MAX_WIDTH, cam-maxwidth) : cam-maxwidth; Index: v4l-dvb-mc-uvc/linux/drivers/media/video/usbvision/usbvision-i2c.c === --- v4l-dvb-mc-uvc.orig/linux/drivers/media/video/usbvision/usbvision-i2c.c +++ v4l-dvb-mc-uvc/linux/drivers/media/video/usbvision/usbvision-i2c.c @@ -219,8 +219,8 @@ int usbvision_i2c_register(struct usb_us memcpy(usbvision-i2c_adap, i2c_adap_template, sizeof(struct i2c_adapter)); - sprintf(usbvision-i2c_adap.name + strlen(usbvision-i2c_adap.name), -#%d, usbvision-vdev-num); + sprintf(usbvision-i2c_adap.name, %s-%d-%s, i2c_adap_template.name, + usbvision-dev-bus-busnum, usbvision-dev-devpath); PDEBUG(DBG_I2C,Adaptername: %s, usbvision-i2c_adap.name); usbvision-i2c_adap.dev.parent = usbvision-dev-dev; -- 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
v4l: Replace video_is_unregistered with video_is_registered
Replace the video_is_unregistered function by a video_is_registered
function. The V4L2_FL_UNREGISTERED flag is replaced by a
V4L2_FL_REGISTERED flag.
This change makes the video_is_registered function return coherent
results when called on an initialize but not yet registered video_device
instance. The function can now be used instead of checking
video_device::minor.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Index: v4l-dvb-mc-uvc/linux/drivers/media/video/v4l2-dev.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/media/video/v4l2-dev.c
+++ v4l-dvb-mc-uvc/linux/drivers/media/video/v4l2-dev.c
@@ -227,7 +227,7 @@ static ssize_t v4l2_read(struct file *fi
if (!vdev-fops-read)
return -EINVAL;
- if (video_is_unregistered(vdev))
+ if (!video_is_registered(vdev))
return -EIO;
return vdev-fops-read(filp, buf, sz, off);
}
@@ -239,7 +239,7 @@ static ssize_t v4l2_write(struct file *f
if (!vdev-fops-write)
return -EINVAL;
- if (video_is_unregistered(vdev))
+ if (!video_is_registered(vdev))
return -EIO;
return vdev-fops-write(filp, buf, sz, off);
}
@@ -248,7 +248,7 @@ static unsigned int v4l2_poll(struct fil
{
struct video_device *vdev = video_devdata(filp);
- if (!vdev-fops-poll || video_is_unregistered(vdev))
+ if (!vdev-fops-poll || !video_is_registered(vdev))
return DEFAULT_POLLMASK;
return vdev-fops-poll(filp, poll);
}
@@ -288,7 +288,7 @@ static unsigned long v4l2_get_unmapped_a
if (!vdev-fops-get_unmapped_area)
return -ENOSYS;
- if (video_is_unregistered(vdev))
+ if (!video_is_registered(vdev))
return -ENODEV;
return vdev-fops-get_unmapped_area(filp, addr, len, pgoff, flags);
}
@@ -298,8 +298,7 @@ static int v4l2_mmap(struct file *filp,
{
struct video_device *vdev = video_devdata(filp);
- if (!vdev-fops-mmap ||
- video_is_unregistered(vdev))
+ if (!vdev-fops-mmap || !video_is_registered(vdev))
return -ENODEV;
return vdev-fops-mmap(filp, vm);
}
@@ -315,7 +314,7 @@ static int v4l2_open(struct inode *inode
vdev = video_devdata(filp);
/* return ENODEV if the video device has been removed
already or if it is not registered anymore. */
- if (vdev == NULL || video_is_unregistered(vdev)) {
+ if (vdev == NULL || !video_is_registered(vdev)) {
mutex_unlock(videodev_lock);
return -ENODEV;
}
@@ -623,6 +622,7 @@ static int __video_register_device(struc
name_base, nr, video_device_node_name(vdev));
/* Part 5: Activate this minor. The char device can now be used. */
+ set_bit(V4L2_FL_REGISTERED, vdev-flags);
mutex_lock(videodev_lock);
video_device[vdev-minor] = vdev;
mutex_unlock(videodev_lock);
@@ -661,11 +661,11 @@ EXPORT_SYMBOL(video_register_device_no_w
void video_unregister_device(struct video_device *vdev)
{
/* Check if vdev was ever registered at all */
- if (!vdev || vdev-minor 0)
+ if (!vdev || !video_is_registered(vdev))
return;
mutex_lock(videodev_lock);
- set_bit(V4L2_FL_UNREGISTERED, vdev-flags);
+ clear_bit(V4L2_FL_REGISTERED, vdev-flags);
mutex_unlock(videodev_lock);
#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 19)
class_device_unregister(vdev-dev);
Index: v4l-dvb-mc-uvc/linux/include/media/v4l2-dev.h
===
--- v4l-dvb-mc-uvc.orig/linux/include/media/v4l2-dev.h
+++ v4l-dvb-mc-uvc/linux/include/media/v4l2-dev.h
@@ -28,10 +28,10 @@ struct v4l2_ioctl_callbacks;
struct video_device;
struct v4l2_device;
-/* Flag to mark the video_device struct as unregistered.
- Drivers can set this flag if they want to block all future
- device access. It is set by video_unregister_device. */
-#define V4L2_FL_UNREGISTERED (0)
+/* Flag to mark the video_device struct as registered.
+ Drivers can clear this flag if they want to block all future
+ device access. It is cleared by video_unregister_device. */
+#define V4L2_FL_REGISTERED (0)
struct v4l2_file_operations {
struct module *owner;
@@ -100,9 +100,7 @@ struct video_device
/* Register video devices. Note that if video_register_device fails,
the release() callback of the video_device structure is *not* called, so
the caller is responsible for freeing any data. Usually that means that
- you call video_device_release() on failure.
-
- Also note that vdev-minor is set to -1 if the registration failed. */
+ you call video_device_release() on failure. */
int __must_check video_register_device(struct video_device *vdev, int type,
int nr);
/* Same as video_register_device, but no warning is
v4l: Use the new video_device_node_name function
Fix all device drivers to use the new video_device_node_name function.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Index: v4l-dvb-mc-uvc/linux/drivers/media/common/saa7146_fops.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/media/common/saa7146_fops.c
+++ v4l-dvb-mc-uvc/linux/drivers/media/common/saa7146_fops.c
@@ -544,15 +544,13 @@ int saa7146_register_device(struct video
return err;
}
- if( VFL_TYPE_GRABBER == type ) {
+ if (VFL_TYPE_GRABBER == type)
vv-video_minor = vfd-minor;
- INFO((%s: registered device video%d [v4l2]\n,
- dev-name, vfd-num));
- } else {
+ else
vv-vbi_minor = vfd-minor;
- INFO((%s: registered device vbi%d [v4l2]\n,
- dev-name, vfd-num));
- }
+
+ INFO((%s: registered device %s [v4l2]\n,
+ dev-name, video_device_node_name(vfd)));
*vid = vfd;
return 0;
Index: v4l-dvb-mc-uvc/linux/drivers/media/video/bt8xx/bttv-driver.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/media/video/bt8xx/bttv-driver.c
+++ v4l-dvb-mc-uvc/linux/drivers/media/video/bt8xx/bttv-driver.c
@@ -4276,8 +4276,8 @@ static int __devinit bttv_register_video
if (video_register_device(btv-video_dev, VFL_TYPE_GRABBER,
video_nr[btv-c.nr]) 0)
goto err;
- printk(KERN_INFO bttv%d: registered device video%d\n,
- btv-c.nr, btv-video_dev-num);
+ printk(KERN_INFO bttv%d: registered device %s\n,
+ btv-c.nr, video_device_node_name(btv-video_dev));
#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 19)
if (class_device_create_file(btv-video_dev-dev,
class_device_attr_card)0) {
@@ -4298,8 +4298,8 @@ static int __devinit bttv_register_video
if (video_register_device(btv-vbi_dev, VFL_TYPE_VBI,
vbi_nr[btv-c.nr]) 0)
goto err;
- printk(KERN_INFO bttv%d: registered device vbi%d\n,
- btv-c.nr, btv-vbi_dev-num);
+ printk(KERN_INFO bttv%d: registered device %s\n,
+ btv-c.nr, video_device_node_name(btv-vbi_dev));
if (!btv-has_radio)
return 0;
@@ -4310,8 +4310,8 @@ static int __devinit bttv_register_video
if (video_register_device(btv-radio_dev, VFL_TYPE_RADIO,
radio_nr[btv-c.nr]) 0)
goto err;
- printk(KERN_INFO bttv%d: registered device radio%d\n,
- btv-c.nr, btv-radio_dev-num);
+ printk(KERN_INFO bttv%d: registered device %s\n,
+ btv-c.nr, video_device_node_name(btv-radio_dev));
/* all done */
return 0;
Index: v4l-dvb-mc-uvc/linux/drivers/media/video/cpia.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/media/video/cpia.c
+++ v4l-dvb-mc-uvc/linux/drivers/media/video/cpia.c
@@ -1343,15 +1343,13 @@ out:
static void create_proc_cpia_cam(struct cam_data *cam)
{
- char name[5 + 1 + 10 + 1];
struct proc_dir_entry *ent;
if (!cpia_proc_root || !cam)
return;
- snprintf(name, sizeof(name), video%d, cam-vdev.num);
-
- ent = create_proc_entry(name, S_IFREG|S_IRUGO|S_IWUSR, cpia_proc_root);
+ ent = create_proc_entry(video_device_node_name(cam-vdev),
+ S_IFREG|S_IRUGO|S_IWUSR, cpia_proc_root);
if (!ent)
return;
@@ -1369,13 +1367,10 @@ static void create_proc_cpia_cam(struct
static void destroy_proc_cpia_cam(struct cam_data *cam)
{
- char name[5 + 1 + 10 + 1];
-
if (!cam || !cam-proc_entry)
return;
- snprintf(name, sizeof(name), video%d, cam-vdev.num);
- remove_proc_entry(name, cpia_proc_root);
+ remove_proc_entry(video_device_node_name(cam-vdev), cpia_proc_root);
cam-proc_entry = NULL;
}
Index: v4l-dvb-mc-uvc/linux/drivers/media/video/cpia2/cpia2_v4l.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/media/video/cpia2/cpia2_v4l.c
+++ v4l-dvb-mc-uvc/linux/drivers/media/video/cpia2/cpia2_v4l.c
@@ -1967,9 +1967,9 @@ void cpia2_unregister_camera(struct came
if (!cam-open_count) {
video_unregister_device(cam-vdev);
} else {
- LOG(/dev/video%d removed while open,
- deferring video_unregister_device\n,
- cam-vdev-num);
+ LOG(/dev/%s removed while open, deferring
+ video_unregister_device\n,
+ video_device_node_name(cam-vdev));
}
}
Index: v4l-dvb-mc-uvc/linux/drivers/media/video/cx18/cx18-streams.c
v4l: Use the video_drvdata function in drivers
Fix all device drivers to use the video_drvdata function instead of
maintaining a local list of minor to private data mappings. Call
video_set_drvdata to register the driver private pointer when not
already done.
Where applicable, the local list of mappings is completely removed when
it becomes unused.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Index: v4l-dvb-mc-uvc/linux/drivers/staging/cx25821/cx25821-audups11.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/staging/cx25821/cx25821-audups11.c
+++ v4l-dvb-mc-uvc/linux/drivers/staging/cx25821/cx25821-audups11.c
@@ -95,35 +95,18 @@ static struct videobuf_queue_ops cx25821
static int video_open(struct file *file)
{
int minor = video_devdata(file)-minor;
- struct cx25821_dev *h, *dev = NULL;
+ struct cx25821_dev *dev = video_drvdata(file);
struct cx25821_fh *fh;
- struct list_head *list;
- enum v4l2_buf_type type = 0;
-
- lock_kernel();
- list_for_each(list, cx25821_devlist) {
- h = list_entry(list, struct cx25821_dev, devlist);
-
- if (h-video_dev[SRAM_CH11]
-h-video_dev[SRAM_CH11]-minor == minor) {
- dev = h;
- type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
- }
- }
-
- if (NULL == dev) {
- unlock_kernel();
- return -ENODEV;
- }
+ enum v4l2_buf_type type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
printk(open minor=%d type=%s\n, minor, v4l2_type_names[type]);
/* allocate + initialize per filehandle data */
fh = kzalloc(sizeof(*fh), GFP_KERNEL);
- if (NULL == fh) {
- unlock_kernel();
+ if (NULL == fh)
return -ENOMEM;
- }
+
+ lock_kernel();
file-private_data = fh;
fh-dev = dev;
Index: v4l-dvb-mc-uvc/linux/drivers/staging/cx25821/cx25821-video.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/staging/cx25821/cx25821-video.c
+++ v4l-dvb-mc-uvc/linux/drivers/staging/cx25821/cx25821-video.c
@@ -189,6 +189,7 @@ struct video_device *cx25821_vdev_init(s
vfd-release = video_device_release;
snprintf(vfd-name, sizeof(vfd-name), %s %s (%s), dev-name, type,
cx25821_boards[dev-board].name);
+ video_set_drvdata(vfd, dev);
return vfd;
}
Index: v4l-dvb-mc-uvc/linux/drivers/staging/cx25821/cx25821-video0.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/staging/cx25821/cx25821-video0.c
+++ v4l-dvb-mc-uvc/linux/drivers/staging/cx25821/cx25821-video0.c
@@ -95,36 +95,19 @@ static struct videobuf_queue_ops cx25821
static int video_open(struct file *file)
{
int minor = video_devdata(file)-minor;
- struct cx25821_dev *h, *dev = NULL;
+ struct cx25821_dev *dev = video_drvdata(file);
struct cx25821_fh *fh;
- struct list_head *list;
- enum v4l2_buf_type type = 0;
+ enum v4l2_buf_type type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
u32 pix_format;
- lock_kernel();
- list_for_each(list, cx25821_devlist) {
- h = list_entry(list, struct cx25821_dev, devlist);
-
- if (h-video_dev[SRAM_CH00]
-h-video_dev[SRAM_CH00]-minor == minor) {
- dev = h;
- type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
- }
- }
-
- if (NULL == dev) {
- unlock_kernel();
- return -ENODEV;
- }
-
printk(open minor=%d type=%s\n, minor, v4l2_type_names[type]);
/* allocate + initialize per filehandle data */
fh = kzalloc(sizeof(*fh), GFP_KERNEL);
- if (NULL == fh) {
- unlock_kernel();
+ if (NULL == fh)
return -ENOMEM;
- }
+
+ lock_kernel();
file-private_data = fh;
fh-dev = dev;
Index: v4l-dvb-mc-uvc/linux/drivers/staging/cx25821/cx25821-video1.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/staging/cx25821/cx25821-video1.c
+++ v4l-dvb-mc-uvc/linux/drivers/staging/cx25821/cx25821-video1.c
@@ -95,36 +95,19 @@ static struct videobuf_queue_ops cx25821
static int video_open(struct file *file)
{
int minor = video_devdata(file)-minor;
- struct cx25821_dev *h, *dev = NULL;
+ struct cx25821_dev *dev = video_drvdata(file);
struct cx25821_fh *fh;
- struct list_head *list;
- enum v4l2_buf_type type = 0;
+ enum v4l2_buf_type type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
u32 pix_format;
- lock_kernel();
- list_for_each(list, cx25821_devlist) {
- h = list_entry(list, struct cx25821_dev, devlist);
-
- if (h-video_dev[SRAM_CH01]
-h-video_dev[SRAM_CH01]-minor
v4l: Use the video_is_registered function in device drivers
Fix all device drivers to use the video_is_registered function instead
of checking video_device::minor.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Index: v4l-dvb-mc-uvc/linux/drivers/media/video/bt8xx/bttv-driver.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/media/video/bt8xx/bttv-driver.c
+++ v4l-dvb-mc-uvc/linux/drivers/media/video/bt8xx/bttv-driver.c
@@ -4240,21 +4240,21 @@ static struct video_device *vdev_init(st
static void bttv_unregister_video(struct bttv *btv)
{
if (btv-video_dev) {
- if (-1 != btv-video_dev-minor)
+ if (video_is_registered(btv-video_dev))
video_unregister_device(btv-video_dev);
else
video_device_release(btv-video_dev);
btv-video_dev = NULL;
}
if (btv-vbi_dev) {
- if (-1 != btv-vbi_dev-minor)
+ if (video_is_registered(btv-vbi_dev))
video_unregister_device(btv-vbi_dev);
else
video_device_release(btv-vbi_dev);
btv-vbi_dev = NULL;
}
if (btv-radio_dev) {
- if (-1 != btv-radio_dev-minor)
+ if (video_is_registered(btv-radio_dev))
video_unregister_device(btv-radio_dev);
else
video_device_release(btv-radio_dev);
Index: v4l-dvb-mc-uvc/linux/drivers/media/video/cx231xx/cx231xx-video.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/media/video/cx231xx/cx231xx-video.c
+++ v4l-dvb-mc-uvc/linux/drivers/media/video/cx231xx/cx231xx-video.c
@@ -2020,7 +2020,7 @@ void cx231xx_release_analog_resources(st
/*FIXME: I2C IR should be disconnected */
if (dev-radio_dev) {
- if (-1 != dev-radio_dev-minor)
+ if (video_is_registered(dev-radio_dev))
video_unregister_device(dev-radio_dev);
else
video_device_release(dev-radio_dev);
@@ -2029,7 +2029,7 @@ void cx231xx_release_analog_resources(st
if (dev-vbi_dev) {
cx231xx_info(V4L2 device /dev/%s deregistered\n,
video_device_node_name(dev-vbi_dev));
- if (-1 != dev-vbi_dev-minor)
+ if (video_is_registered(dev-vbi_dev))
video_unregister_device(dev-vbi_dev);
else
video_device_release(dev-vbi_dev);
@@ -2038,7 +2038,7 @@ void cx231xx_release_analog_resources(st
if (dev-vdev) {
cx231xx_info(V4L2 device /dev/%s deregistered\n,
video_device_node_name(dev-vdev));
- if (-1 != dev-vdev-minor)
+ if (video_is_registered(dev-vdev))
video_unregister_device(dev-vdev);
else
video_device_release(dev-vdev);
Index: v4l-dvb-mc-uvc/linux/drivers/media/video/cx23885/cx23885-417.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/media/video/cx23885/cx23885-417.c
+++ v4l-dvb-mc-uvc/linux/drivers/media/video/cx23885/cx23885-417.c
@@ -1753,7 +1753,7 @@ void cx23885_417_unregister(struct cx238
dprintk(1, %s()\n, __func__);
if (dev-v4l_device) {
- if (-1 != dev-v4l_device-minor)
+ if (video_is_registered(dev-v4l_device))
video_unregister_device(dev-v4l_device);
else
video_device_release(dev-v4l_device);
Index: v4l-dvb-mc-uvc/linux/drivers/media/video/cx23885/cx23885-video.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/media/video/cx23885/cx23885-video.c
+++ v4l-dvb-mc-uvc/linux/drivers/media/video/cx23885/cx23885-video.c
@@ -1691,14 +1691,14 @@ void cx23885_video_unregister(struct cx2
#if 0
if (dev-radio_dev) {
- if (-1 != dev-radio_dev-minor)
+ if (video_is_registered(dev-radio_dev))
video_unregister_device(dev-radio_dev);
else
video_device_release(dev-radio_dev);
dev-radio_dev = NULL;
}
if (dev-vbi_dev) {
- if (-1 != dev-vbi_dev-minor)
+ if (video_is_registered(dev-vbi_dev)
video_unregister_device(dev-vbi_dev);
else
video_device_release(dev-vbi_dev);
@@ -1707,7 +1707,7 @@ void cx23885_video_unregister(struct cx2
}
#endif
if (dev-video_dev) {
- if (-1 != dev-video_dev-minor)
+ if (video_is_registered(dev-video_dev))
video_unregister_device(dev-video_dev);
else
hdpvr: Replace video_is_unregistered with video_is_registered
Fix the hdpvr driver to use the video_is_registered function instead of
video_is_unregistered.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Index: v4l-dvb-mc-uvc/linux/drivers/media/video/hdpvr/hdpvr-video.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/media/video/hdpvr/hdpvr-video.c
+++ v4l-dvb-mc-uvc/linux/drivers/media/video/hdpvr/hdpvr-video.c
@@ -519,7 +519,7 @@ static unsigned int hdpvr_poll(struct fi
mutex_lock(dev-io_mutex);
- if (video_is_unregistered(dev-video_dev)) {
+ if (!video_is_registered(dev-video_dev)) {
mutex_unlock(dev-io_mutex);
return -EIO;
}
--
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
v4l: Use video_device_node_name() instead of the minor number
Instead of using the minor number in kernel log messages, use the device
node name as returned by the video_device_node_name() function. This
makes debug, informational and error messages easier to understand for
end users.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Index: v4l-dvb-mc-uvc/linux/drivers/staging/tm6000/tm6000-video.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/staging/tm6000/tm6000-video.c
+++ v4l-dvb-mc-uvc/linux/drivers/staging/tm6000/tm6000-video.c
@@ -1359,17 +1359,17 @@ static int vidioc_s_frequency (struct fi
static int tm6000_open(struct file *file)
{
- int minor = video_devdata(file)-minor;
+ struct video_device *vdev = video_devdata(file);
struct tm6000_core *dev = video_drvdata(file);
struct tm6000_fh *fh;
enum v4l2_buf_type type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
int i,rc;
- printk(KERN_INFO tm6000: open called (minor=%d)\n,minor);
+ printk(KERN_INFO tm6000: open called (dev=%s)\n,
+ video_device_node_name(vdev));
-
- dprintk(dev, V4L2_DEBUG_OPEN, tm6000: open called
- (minor=%d)\n,minor);
+ dprintk(dev, V4L2_DEBUG_OPEN, tm6000: open called (dev=%s)\n,
+ video_device_node_name(vdev));
#if 0 /* Avoids an oops at read() - seems to be semaphore related */
if (dev-users) {
@@ -1381,8 +1381,8 @@ static int tm6000_open(struct file *file
/* If more than one user, mutex should be added */
dev-users++;
- dprintk(dev, V4L2_DEBUG_OPEN, open minor=%d type=%s users=%d\n,
- minor,v4l2_type_names[type],dev-users);
+ dprintk(dev, V4L2_DEBUG_OPEN, open dev=%s type=%s users=%d\n,
+ video_device_node_name(vdev),v4l2_type_names[type],dev-users);
/* allocate + initialize per filehandle data */
fh = kzalloc(sizeof(*fh),GFP_KERNEL);
@@ -1494,9 +1494,10 @@ static int tm6000_release(struct file *f
{
struct tm6000_fh *fh = file-private_data;
struct tm6000_core *dev = fh-dev;
- int minor = video_devdata(file)-minor;
+ struct video_device*vdev = video_devdata(file);
- dprintk(dev, V4L2_DEBUG_OPEN, tm6000: close called (minor=%d,
users=%d)\n,minor,dev-users);
+ dprintk(dev, V4L2_DEBUG_OPEN, tm6000: close called (dev=%s,
users=%d)\n,
+ video_device_node_name(vdev), dev-users);
dev-users--;
Index: v4l-dvb-mc-uvc/linux/drivers/staging/cx25821/cx25821-audups11.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/staging/cx25821/cx25821-audups11.c
+++ v4l-dvb-mc-uvc/linux/drivers/staging/cx25821/cx25821-audups11.c
@@ -94,12 +94,13 @@ static struct videobuf_queue_ops cx25821
static int video_open(struct file *file)
{
- int minor = video_devdata(file)-minor;
+ struct video_device *vdev = video_devdata(file);
struct cx25821_dev *dev = video_drvdata(file);
struct cx25821_fh *fh;
enum v4l2_buf_type type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
- printk(open minor=%d type=%s\n, minor, v4l2_type_names[type]);
+ printk(open dev=%s type=%s\n, video_device_node_name(vdev),
+ v4l2_type_names[type]);
/* allocate + initialize per filehandle data */
fh = kzalloc(sizeof(*fh), GFP_KERNEL);
Index: v4l-dvb-mc-uvc/linux/drivers/staging/cx25821/cx25821-video0.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/staging/cx25821/cx25821-video0.c
+++ v4l-dvb-mc-uvc/linux/drivers/staging/cx25821/cx25821-video0.c
@@ -94,13 +94,14 @@ static struct videobuf_queue_ops cx25821
static int video_open(struct file *file)
{
- int minor = video_devdata(file)-minor;
+ struct video_device *vdev = video_devdata(file);
struct cx25821_dev *dev = video_drvdata(file);
struct cx25821_fh *fh;
enum v4l2_buf_type type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
u32 pix_format;
- printk(open minor=%d type=%s\n, minor, v4l2_type_names[type]);
+ printk(open dev=%s type=%s\n, video_device_node_name(vdev),
+ v4l2_type_names[type]);
/* allocate + initialize per filehandle data */
fh = kzalloc(sizeof(*fh), GFP_KERNEL);
Index: v4l-dvb-mc-uvc/linux/drivers/staging/cx25821/cx25821-video1.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/staging/cx25821/cx25821-video1.c
+++ v4l-dvb-mc-uvc/linux/drivers/staging/cx25821/cx25821-video1.c
@@ -94,13 +94,14 @@ static struct videobuf_queue_ops cx25821
static int video_open(struct file *file)
{
- int minor = video_devdata(file)-minor;
+ struct video_device *vdev = video_devdata(file);
struct cx25821_dev *dev = video_drvdata(file);
struct cx25821_fh *fh;
v4l: Remove unneeded video_device::minor assignments
Now that the video_device registration is tested using
video_is_registered(), drivers don't need to initialize the
video_device::minor field to -1 anymore.
Remove those unneeded assignments.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Index: v4l-dvb-mc-uvc/linux/drivers/media/video/cx231xx/cx231xx-video.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/media/video/cx231xx/cx231xx-video.c
+++ v4l-dvb-mc-uvc/linux/drivers/media/video/cx231xx/cx231xx-video.c
@@ -2277,7 +2277,6 @@ static const struct video_device cx231xx
.fops = cx231xx_v4l_fops,
.release = video_device_release,
.ioctl_ops= video_ioctl_ops,
- .minor= -1,
.tvnorms = V4L2_STD_ALL,
.current_norm = V4L2_STD_PAL,
};
@@ -2312,7 +2311,6 @@ static struct video_device cx231xx_radio
.name = cx231xx-radio,
.fops = radio_fops,
.ioctl_ops = radio_ioctl_ops,
- .minor = -1,
};
/ usb interface **/
@@ -2328,7 +2326,6 @@ static struct video_device *cx231xx_vdev
return NULL;
*vfd = *template;
- vfd-minor = -1;
vfd-v4l2_dev = dev-v4l2_dev;
vfd-release = video_device_release;
vfd-debug = video_debug;
Index: v4l-dvb-mc-uvc/linux/drivers/media/video/cx23885/cx23885-video.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/media/video/cx23885/cx23885-video.c
+++ v4l-dvb-mc-uvc/linux/drivers/media/video/cx23885/cx23885-video.c
@@ -353,7 +353,6 @@ static struct video_device *cx23885_vdev
if (NULL == vfd)
return NULL;
*vfd = *template;
- vfd-minor = -1;
vfd-v4l2_dev = dev-v4l2_dev;
vfd-release = video_device_release;
snprintf(vfd-name, sizeof(vfd-name), %s %s (%s),
@@ -1636,7 +1635,6 @@ static struct video_device cx23885_vbi_t
static struct video_device cx23885_video_template = {
.name = cx23885-video,
.fops = video_fops,
- .minor= -1,
.ioctl_ops= video_ioctl_ops,
.tvnorms = CX23885_NORMS,
.current_norm = V4L2_STD_NTSC_M,
@@ -1669,7 +1667,6 @@ static struct video_device cx23885_radio
.name = cx23885-radio,
.fops = radio_fops,
.ioctl_ops= radio_ioctl_ops,
- .minor= -1,
};
#endif
Index: v4l-dvb-mc-uvc/linux/drivers/media/video/em28xx/em28xx-video.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/media/video/em28xx/em28xx-video.c
+++ v4l-dvb-mc-uvc/linux/drivers/media/video/em28xx/em28xx-video.c
@@ -2462,8 +2462,6 @@ static const struct video_device em28xx_
.release= video_device_release,
.ioctl_ops = video_ioctl_ops,
- .minor = -1,
-
.tvnorms= V4L2_STD_ALL,
.current_norm = V4L2_STD_PAL,
};
@@ -2498,7 +2496,6 @@ static struct video_device em28xx_radio_
.name = em28xx-radio,
.fops = radio_fops,
.ioctl_ops= radio_ioctl_ops,
- .minor= -1,
};
/ usb interface **/
@@ -2516,7 +2513,6 @@ static struct video_device *em28xx_vdev_
return NULL;
*vfd= *template;
- vfd-minor = -1;
vfd-v4l2_dev = dev-v4l2_dev;
vfd-release= video_device_release;
vfd-debug = video_debug;
Index: v4l-dvb-mc-uvc/linux/drivers/media/video/usbvision/usbvision-video.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/media/video/usbvision/usbvision-video.c
+++ v4l-dvb-mc-uvc/linux/drivers/media/video/usbvision/usbvision-video.c
@@ -1328,7 +1328,6 @@ static struct video_device usbvision_vid
.ioctl_ops = usbvision_ioctl_ops,
.name = usbvision-video,
.release= video_device_release,
- .minor = -1,
.tvnorms = USBVISION_NORMS,
.current_norm = V4L2_STD_PAL
};
@@ -1362,7 +1361,6 @@ static struct video_device usbvision_rad
.fops = usbvision_radio_fops,
.name = usbvision-radio,
.release= video_device_release,
- .minor = -1,
.ioctl_ops = usbvision_radio_ioctl_ops,
.tvnorms = USBVISION_NORMS,
@@ -1382,7 +1380,6 @@ static struct video_device usbvision_vbi
.fops = usbvision_vbi_fops,
.release= video_device_release,
.name = usbvision-vbi,
-
v4l: Remove unneeded video_device::minor usage in drivers
The video_device::minor field is used where it shouldn't, either to
- test for error conditions that can't happen anymore with the current
v4l-dvb core,
- store the value in a driver private field that isn't used anymore,
- check the video device type where video_device::vfl_type should be
used, or
- create the name of a kernel thread that should get a stable name.
Remove or fix those use cases.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Index: v4l-dvb-mc-uvc/linux/drivers/media/radio/radio-tea5764.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/media/radio/radio-tea5764.c
+++ v4l-dvb-mc-uvc/linux/drivers/media/radio/radio-tea5764.c
@@ -462,12 +462,8 @@ static int vidioc_s_audio(struct file *f
static int tea5764_open(struct file *file)
{
/* Currently we support only one device */
- int minor = video_devdata(file)-minor;
struct tea5764_device *radio = video_drvdata(file);
- if (radio-videodev-minor != minor)
- return -ENODEV;
-
mutex_lock(radio-mutex);
/* Only exclusive access */
if (radio-users) {
Index: v4l-dvb-mc-uvc/linux/drivers/media/video/bt8xx/bttv-driver.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/media/video/bt8xx/bttv-driver.c
+++ v4l-dvb-mc-uvc/linux/drivers/media/video/bt8xx/bttv-driver.c
@@ -3234,7 +3234,6 @@ err:
static int bttv_open(struct file *file)
{
- int minor = video_devdata(file)-minor;
struct video_device *vdev = video_devdata(file);
struct bttv *btv = video_drvdata(file);
struct bttv_fh *fh;
@@ -3242,17 +3241,17 @@ static int bttv_open(struct file *file)
dprintk(KERN_DEBUG bttv: open dev=%s\n, video_device_node_name(vdev));
- lock_kernel();
- if (btv-video_dev-minor == minor) {
+ if (vdev-vfl_type == VFL_TYPE_GRABBER) {
type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
- } else if (btv-vbi_dev-minor == minor) {
+ } else if (vdev-vfl_type == VFL_TYPE_VBI) {
type = V4L2_BUF_TYPE_VBI_CAPTURE;
} else {
WARN_ON(1);
- unlock_kernel();
return -ENODEV;
}
+ lock_kernel();
+
dprintk(KERN_DEBUG bttv%d: open called (type=%s)\n,
btv-c.nr,v4l2_type_names[type]);
@@ -3436,7 +3435,6 @@ static struct video_device bttv_video_te
static int radio_open(struct file *file)
{
- int minor = video_devdata(file)-minor;
struct video_device *vdev = video_devdata(file);
struct bttv *btv = video_drvdata(file);
struct bttv_fh *fh;
@@ -3444,11 +3442,6 @@ static int radio_open(struct file *file)
dprintk(bttv: open dev=%s\n, video_device_node_name(vdev));
lock_kernel();
- WARN_ON(btv-radio_dev btv-radio_dev-minor != minor);
- if (!btv-radio_dev || btv-radio_dev-minor != minor) {
- unlock_kernel();
- return -ENODEV;
- }
dprintk(bttv%d: open called (radio)\n,btv-c.nr);
Index: v4l-dvb-mc-uvc/linux/drivers/media/video/omap24xxcam.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/media/video/omap24xxcam.c
+++ v4l-dvb-mc-uvc/linux/drivers/media/video/omap24xxcam.c
@@ -1450,12 +1450,11 @@ static int omap24xxcam_mmap(struct file
static int omap24xxcam_open(struct file *file)
{
- int minor = video_devdata(file)-minor;
struct omap24xxcam_device *cam = omap24xxcam.priv;
struct omap24xxcam_fh *fh;
struct v4l2_format format;
- if (!cam || !cam-vfd || (cam-vfd-minor != minor))
+ if (!cam || !cam-vfd)
return -ENODEV;
fh = kzalloc(sizeof(*fh), GFP_KERNEL);
Index: v4l-dvb-mc-uvc/linux/drivers/media/common/saa7146_fops.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/media/common/saa7146_fops.c
+++ v4l-dvb-mc-uvc/linux/drivers/media/common/saa7146_fops.c
@@ -1,8 +1,6 @@
#include media/saa7146_vv.h
#include compat.h
-#define BOARD_CAN_DO_VBI(dev) (dev-revision != 0 dev-vv_data-vbi_minor
!= -1)
-
//
/* resource management functions, shamelessly stolen from saa7134 driver */
@@ -456,9 +454,6 @@ int saa7146_vv_init(struct saa7146_dev*
configuration data) */
dev-ext_vv_data = ext_vv;
- vv-video_minor = -1;
- vv-vbi_minor = -1;
-
vv-d_clipping.cpu_addr = pci_alloc_consistent(dev-pci,
SAA7146_CLIPPING_MEM, vv-d_clipping.dma_handle);
if( NULL == vv-d_clipping.cpu_addr ) {
ERR((out of memory. aborting.\n));
@@ -497,7 +492,6 @@ EXPORT_SYMBOL_GPL(saa7146_vv_release);
int saa7146_register_device(struct video_device **vid, struct saa7146_dev* dev,
char *name,
RE: [PATCH/RFC] V4L core cleanups
Laurent, -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Laurent Pinchart Sent: Tuesday, November 17, 2009 6:39 PM To: linux-media@vger.kernel.org Cc: hverk...@xs4all.nl; mche...@infradead.org; sakari.ai...@maxwell.research.nokia.com Subject: [PATCH/RFC] V4L core cleanups Hi everybody, this patch sets attemp to clean up the V4L core to remove the video_device::minor and video_device::num references in most drivers. I think you're missing usual subject prefix: [PATCH #/total] Unless all patches are independent from eachother, which is something I'll hardly believe. Regards, Sergio There are two reasons for this. The first one is that drivers really shouldn't care about those fields, especially the minor number. This doesn't mean a driver can't request a specific device number, that remains a perfectly valid use case, but most use cases of those fields after device registration shouldn't be needed. The second reason is that most drivers use those fields in bogus ways, making it obvious they shouldn't have cared about them in the first place :-) We've had a video_drvdata function for a long time, but many drivers still have their own private minor - data mapping lists for historical reasons. That code is error prone and completely unneeded. So this patch sets tries to clean up the V4L core by porting drivers to the most recent APIs (which are actually quite old) and introducing a new helper function. The first two patches add and use the video_device_node_name function. The function returns a const pointer to the video device name. On systems using udev, the name is passed as a hint to udev and will likely become the /dev device node name, unless overwritten by udev rules (I've heard that some distributions put the V4L device nodes in /dev/v4l). Some drivers erroneously created the name from the video_device::minor field instead of video_device::num, which is fixed by the second patch. This is an example video_device_node_name usage typical from what can be found in the second patch. - printk(KERN_INFO bttv%d: registered device radio%d\n, - btv-c.nr, btv-radio_dev-num); + printk(KERN_INFO bttv%d: registered device %s\n, + btv-c.nr, video_device_node_name(btv-radio_dev)); The third patch removes left video_device::num usage from the drivers. The field was used to create information strings that shouldn't include the device node name (such as video_device::name) or that should be created using a stable identifier (such as i2c_adapter::name). The fourth, fifth and sixth patches replace video_is_unregistered with video_is_registered and use the new function in device drivers. As explained in the fourth patch commit message, the rationale behind that is to have video_is_registered return false when called on an initialized but not yet registered video_device instance. The function can be used instead of checking video_device::minor manually, making it less error-prone as drivers don't need to make sure they video_device::minor to -1 correctly for all error paths. A typical use case is - if (-1 != dev-radio_dev-minor) + if (video_is_registered(dev-radio_dev)) video_unregister_device(dev-radio_dev); else video_device_release(dev-radio_dev); The seventh patch replace local minor to data lists by video_drvdata(). The function has been there for a long time but wasn't used by many drivers, probably because they were written before it was available, or, for some of them, because they were written based on drivers that were not using it. This patch removes lots of identical unneeded code blocks, making the result less bug-prone. The eight patch removes now unneeded video_device::minor assignments to -1, as the previous patches made them unneeded. The last patch removes a few more video_device::minor users. As explained in the patch description, the field was used either to - test for error conditions that can't happen anymore with the current v4l-dvb core, - store the value in a driver private field that isn't used anymore, - check the video device type where video_device::vfl_type should be used, or - create the name of a kernel thread that should get a stable name. There are still two video_device::num users and those can easily be removed. Hans Verkuil is working on a patch, as one of the drivers is the ivtv driver and the other one is based on the same code. There are also still a few video_device::minor users. One of them is the pvrusb2 driver that creates sysfs attributes storing the minor numbers of the device nodes created by the driver. I'm not sure what to do about that one. All the others are V4L1 drivers that need the minor number for the VIDIOCGUNIT ioctl. Hopefully that will die when the
Re: [PATCH] Multifrontend support for saa7134
Hi Lukáš,
Am Dienstag, den 17.11.2009, 15:06 +0100 schrieb Lukáš Karas:
Hi Hermann
At first, sorry for my late reaction, I havn't enough time for hacking...
Thank you for detailed subscription. So, the main problem probably is LNB
supply
as I understand, yes?
Please, try modified patch, that turn on (off) LNB supply after software
reset.
I don't know if I do it right. Hacking without access to hardware is hard.
well, it is totally unchanged, also I had at least some Asus 3in1 up on
some F11 with the same results.
We need someone with some time and skills going through it.
If the i2c traffic is not corrupted, should be doable, else also ;)
I would not say, that MFE support on such an old driver has high prio.
Looking back on it, you see of course the roots for later stuff.
But given the low level of feedback, and they are already through on m$
now and bought the cx remains, means a now most likely working hardware
concept is already there, though.
If you, or likely even better Jean or both, have some time for it, I do
happily provide you with such hardware.
And can read some new book, eventually ;)
Cheers,
Hermann
Lukas
diff -uprN linux-a76d06e9ff9b/drivers/media/video/saa7134/saa7134-cards.c
linux/drivers/media/video/saa7134/saa7134-
cards.c
--- linux-a76d06e9ff9b/drivers/media/video/saa7134/saa7134-cards.c
2009-10-31 10:40:46.0 +0100
+++ linux/drivers/media/video/saa7134/saa7134-cards.c 2009-10-31
17:47:51.0 +0100
@@ -614,6 +614,7 @@ struct saa7134_board saa7134_boards[] =
.radio_addr = ADDR_UNSET,
.tda9887_conf = TDA9887_PRESENT,
.mpeg = SAA7134_MPEG_DVB,
+ .num_frontends = 1,
.inputs = {{
.name = name_tv,
.vmux = 1,
@@ -1352,6 +1353,7 @@ struct saa7134_board saa7134_boards[] =
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
.mpeg = SAA7134_MPEG_DVB,
+ .num_frontends = 1,
.inputs = {{
.name = name_tv,
.vmux = 1,
@@ -1895,6 +1897,7 @@ struct saa7134_board saa7134_boards[] =
.radio_addr = ADDR_UNSET,
.tda9887_conf = TDA9887_PRESENT | TDA9887_INTERCARRIER |
TDA9887_PORT2_INACTIVE,
.mpeg = SAA7134_MPEG_DVB,
+ .num_frontends = 1,
.inputs = {{
.name = name_tv,
.vmux = 3,
@@ -1987,6 +1990,7 @@ struct saa7134_board saa7134_boards[] =
.radio_addr = ADDR_UNSET,
.gpiomask = 0x0020,
.mpeg = SAA7134_MPEG_DVB,
+ .num_frontends = 1,
.inputs = {{
.name = name_tv,
.vmux = 1,
@@ -2020,6 +2024,7 @@ struct saa7134_board saa7134_boards[] =
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
.mpeg = SAA7134_MPEG_DVB,
+ .num_frontends = 1,
.inputs = {{
.name = name_comp1,
.vmux = 0,
@@ -2126,6 +2131,7 @@ struct saa7134_board saa7134_boards[] =
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
.mpeg = SAA7134_MPEG_DVB,
+ .num_frontends = 1,
.gpiomask = 0x0020,
.inputs = {{
.name = name_tv,
@@ -2426,6 +2432,7 @@ struct saa7134_board saa7134_boards[] =
.radio_addr = ADDR_UNSET,
.tda9887_conf = TDA9887_PRESENT | TDA9887_PORT1_ACTIVE,
.mpeg = SAA7134_MPEG_DVB,
+ .num_frontends = 1,
.inputs = {{
.name = name_tv,
.vmux = 3,
@@ -2450,6 +2457,7 @@ struct saa7134_board saa7134_boards[] =
.radio_addr = ADDR_UNSET,
.tda9887_conf = TDA9887_PRESENT | TDA9887_PORT1_ACTIVE,
.mpeg = SAA7134_MPEG_DVB,
+ .num_frontends = 1,
.inputs = {{
.name = name_tv,
.vmux = 3,
@@ -2473,6 +2481,7 @@ struct saa7134_board saa7134_boards[] =
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
.mpeg = SAA7134_MPEG_DVB,
+ .num_frontends = 1,
.inputs = {{
.name = name_comp1,
.vmux = 0,
@@ -2596,6 +2605,7 @@ struct saa7134_board saa7134_boards[] =
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
.mpeg = SAA7134_MPEG_DVB,
+
Re: KWorld UB435-Q Support
On Nov 17, 2009, at 9:37 AM, Devin Heitmueller wrote:
On Tue, Nov 17, 2009 at 9:15 AM, Jarod Wilson ja...@wilsonet.com wrote:
On Nov 17, 2009, at 1:03 AM, Robert Cicconetti wrote:
On Tue, Nov 17, 2009 at 12:55 AM, Michael Krufky mkru...@linuxtv.org
wrote:
[ 812.465930] tda18271: performing RF tracking filter calibration
[ 818.572446] tda18271: RF tracking filter calibration complete
[ 818.953946] tda18271: performing RF tracking filter calibration
[ 825.093211] tda18271: RF tracking filter calibration complete
If you see this happen more than once consecutively, and there is only 1
silicon tuner present, then it means something very bad is happening, and
there is a chance of burning out a part. I still wouldnt not recommend any
mainline merge until you can prevent this behavior -- I suspect that a GPIO
reset is being toggled where it shouldnt be, which should be harmless ...
but until we fix it, we cant be sure what damage might get done...
The RF tracking filter calibration is a procedure that should only happen
once while the tuner is powered on -- it should *only* be repeated if the
tuner indicated that calibration is necessary, and that would only happen
after a hardware reset.
This still looks fishy to me...
Agreed. I did manage to dig into this some more last night, something is
definitely still awry.
...
Hey Jarod,
I haven't seen your exact GPIO config but I noticed something
recently: the em28xx driver runs the dvb_gpio sequence whenever
starting streaming, not just whenever opening the DVB frontend. This
means that if your dvb_gpio definition strobes the tda18271 reset (as
opposed to just taking it out of reset), then the chip will get reset
whenever the streaming is started (a real problem if multiple tuning
attempts are performed without closing the frontend first).
Mauro seems to think this is intended behavior, although I cannot see
how this could possibly be correct, especially since the .init()
callback is not called in that case. I setup a tree to remove the
call, but never got far enough into the testing to confirm whether it
broke any improperly configured boards depending on the incorrect
behavior.
This tree, I presume.
http://kernellabs.com/hg/~dheitmueller/em28xx-modeswitch/
I just tacked on the very last patch there onto my local tree to test with one
of these sticks. Behavior is the same though, and the tda18271 reg dumps look
equally bad -- they're all reported 0x00.
As a test, you might want to check your dvb_gpio config and see if you
are pulling anything low and then high, and just remove the line that
sets the pin low and see if the recalibration still occurs.
I'm pretty sure you explained how to do this to me once before on irc, but its
been a while, and that knowledge has since leaked out of my brain... Currently,
I have:
/*
* KWorld PlusTV 340U and UB435-Q (ATSC) GPIOs map:
* EM_GPIO_0 - currently unknown
* EM_GPIO_1 - LED disable/enable (1 = off, 0 = on)
* EM_GPIO_2 - currently unknown
* EM_GPIO_3 - currently unknown
* EM_GPIO_4 - TDA18271HD tuner (1 = active, 0 = in reset)
* EM_GPIO_5 - LGDT3304 ATSC/QAM demod (1 = active, 0 = in reset)
* EM_GPIO_6 - currently unknown
* EM_GPIO_7 - currently unknown
*/
static struct em28xx_reg_seq kworld_a340_digital[] = {
/* only diff from default gpio is to keep 1 clear to turn on LED */
{EM28XX_R08_GPIO, 0x6d, ~EM_GPIO_4, 10},
{ -1, -1, -1, -1},
};
I've tried various combinations in here today, all without any significant
change in behavior. But I suspect I'm missing something I should be trying. Ah
well. Bed time. More poking tomorrow...
--
Jarod Wilson
ja...@wilsonet.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 2/3] radio-si470x: move some file operations to common file
The read and poll file operations of the si470x usb driver can be used
also equally on the si470x i2c driver, so they go to the common file.
Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
drivers/media/radio/si470x/radio-si470x-common.c | 98 ++
drivers/media/radio/si470x/radio-si470x-i2c.c| 15 +---
drivers/media/radio/si470x/radio-si470x-usb.c| 97 +-
drivers/media/radio/si470x/radio-si470x.h|3 +-
4 files changed, 104 insertions(+), 109 deletions(-)
diff --git a/drivers/media/radio/si470x/radio-si470x-common.c
b/drivers/media/radio/si470x/radio-si470x-common.c
index 7296cf4..f4645d4 100644
--- a/drivers/media/radio/si470x/radio-si470x-common.c
+++ b/drivers/media/radio/si470x/radio-si470x-common.c
@@ -426,6 +426,104 @@ int si470x_rds_on(struct si470x_device *radio)
/**
+ * File Operations Interface
+ **/
+
+/*
+ * si470x_fops_read - read RDS data
+ */
+static ssize_t si470x_fops_read(struct file *file, char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ struct si470x_device *radio = video_drvdata(file);
+ int retval = 0;
+ unsigned int block_count = 0;
+
+ /* switch on rds reception */
+ if ((radio-registers[SYSCONFIG1] SYSCONFIG1_RDS) == 0)
+ si470x_rds_on(radio);
+
+ /* block if no new data available */
+ while (radio-wr_index == radio-rd_index) {
+ if (file-f_flags O_NONBLOCK) {
+ retval = -EWOULDBLOCK;
+ goto done;
+ }
+ if (wait_event_interruptible(radio-read_queue,
+ radio-wr_index != radio-rd_index) 0) {
+ retval = -EINTR;
+ goto done;
+ }
+ }
+
+ /* calculate block count from byte count */
+ count /= 3;
+
+ /* copy RDS block out of internal buffer and to user buffer */
+ mutex_lock(radio-lock);
+ while (block_count count) {
+ if (radio-rd_index == radio-wr_index)
+ break;
+
+ /* always transfer rds complete blocks */
+ if (copy_to_user(buf, radio-buffer[radio-rd_index], 3))
+ /* retval = -EFAULT; */
+ break;
+
+ /* increment and wrap read pointer */
+ radio-rd_index += 3;
+ if (radio-rd_index = radio-buf_size)
+ radio-rd_index = 0;
+
+ /* increment counters */
+ block_count++;
+ buf += 3;
+ retval += 3;
+ }
+ mutex_unlock(radio-lock);
+
+done:
+ return retval;
+}
+
+
+/*
+ * si470x_fops_poll - poll RDS data
+ */
+static unsigned int si470x_fops_poll(struct file *file,
+ struct poll_table_struct *pts)
+{
+ struct si470x_device *radio = video_drvdata(file);
+ int retval = 0;
+
+ /* switch on rds reception */
+ if ((radio-registers[SYSCONFIG1] SYSCONFIG1_RDS) == 0)
+ si470x_rds_on(radio);
+
+ poll_wait(file, radio-read_queue, pts);
+
+ if (radio-rd_index != radio-wr_index)
+ retval = POLLIN | POLLRDNORM;
+
+ return retval;
+}
+
+
+/*
+ * si470x_fops - file operations interface
+ */
+static const struct v4l2_file_operations si470x_fops = {
+ .owner = THIS_MODULE,
+ .read = si470x_fops_read,
+ .poll = si470x_fops_poll,
+ .ioctl = video_ioctl2,
+ .open = si470x_fops_open,
+ .release= si470x_fops_release,
+};
+
+
+
+/**
* Video4Linux Interface
**/
diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c
b/drivers/media/radio/si470x/radio-si470x-i2c.c
index 2d53b6a..4816a6d 100644
--- a/drivers/media/radio/si470x/radio-si470x-i2c.c
+++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
@@ -173,7 +173,7 @@ int si470x_disconnect_check(struct si470x_device *radio)
/*
* si470x_fops_open - file open
*/
-static int si470x_fops_open(struct file *file)
+int si470x_fops_open(struct file *file)
{
struct si470x_device *radio = video_drvdata(file);
int retval = 0;
@@ -194,7 +194,7 @@ static int si470x_fops_open(struct file *file)
/*
* si470x_fops_release - file release
*/
-static int si470x_fops_release(struct file *file)
+int si470x_fops_release(struct file *file)
{
struct si470x_device *radio = video_drvdata(file);
int retval = 0;
@@ -215,17 +215,6 @@ static int si470x_fops_release(struct file *file)
}
-/*
- * si470x_fops - file operations interface
- */
[PATCH 3/3] radio-si470x: support RDS on si470x i2c driver
This patch is to support RDS on si470x i2c driver. The routine of RDS
operation is almost same with thing of usb driver, but this uses RDS
interrupt.
Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
drivers/media/radio/si470x/radio-si470x-i2c.c | 159 +++--
drivers/media/radio/si470x/radio-si470x.h |1 +
2 files changed, 152 insertions(+), 8 deletions(-)
diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c
b/drivers/media/radio/si470x/radio-si470x-i2c.c
index 4816a6d..77532e6 100644
--- a/drivers/media/radio/si470x/radio-si470x-i2c.c
+++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
@@ -22,22 +22,17 @@
*/
-/*
- * ToDo:
- * - RDS support
- */
-
-
/* driver definitions */
#define DRIVER_AUTHOR Joonyoung Shim jy0922.s...@samsung.com;
-#define DRIVER_KERNEL_VERSION KERNEL_VERSION(1, 0, 0)
+#define DRIVER_KERNEL_VERSION KERNEL_VERSION(1, 0, 1)
#define DRIVER_CARD Silicon Labs Si470x FM Radio Receiver
#define DRIVER_DESC I2C radio driver for Si470x FM Radio Receivers
-#define DRIVER_VERSION 1.0.0
+#define DRIVER_VERSION 1.0.1
/* kernel includes */
#include linux/i2c.h
#include linux/delay.h
+#include linux/interrupt.h
#include radio-si470x.h
@@ -62,6 +57,20 @@ static int radio_nr = -1;
module_param(radio_nr, int, 0444);
MODULE_PARM_DESC(radio_nr, Radio Nr);
+/* RDS buffer blocks */
+static unsigned int rds_buf = 100;
+module_param(rds_buf, uint, 0444);
+MODULE_PARM_DESC(rds_buf, RDS buffer entries: *100*);
+
+/* RDS maximum block errors */
+static unsigned short max_rds_errors = 1;
+/* 0 means 0 errors requiring correction */
+/* 1 means 1-2 errors requiring correction (used by original USBRadio.exe) */
+/* 2 means 3-5 errors requiring correction */
+/* 3 means 6+ errors or errors in checkword, correction not possible */
+module_param(max_rds_errors, ushort, 0644);
+MODULE_PARM_DESC(max_rds_errors, RDS maximum block errors: *1*);
+
/**
@@ -242,6 +251,105 @@ int si470x_vidioc_querycap(struct file *file, void *priv,
**/
/*
+ * si470x_i2c_interrupt_work - rds processing function
+ */
+static void si470x_i2c_interrupt_work(struct work_struct *work)
+{
+ struct si470x_device *radio = container_of(work,
+ struct si470x_device, radio_work);
+ unsigned char regnr;
+ unsigned char blocknum;
+ unsigned short bler; /* rds block errors */
+ unsigned short rds;
+ unsigned char tmpbuf[3];
+ int retval = 0;
+
+ /* safety checks */
+ if ((radio-registers[SYSCONFIG1] SYSCONFIG1_RDS) == 0)
+ return;
+
+ /* Update RDS registers */
+ for (regnr = 0; regnr RDS_REGISTER_NUM; regnr++) {
+ retval = si470x_get_register(radio, STATUSRSSI + regnr);
+ if (retval 0)
+ return;
+ }
+
+ /* get rds blocks */
+ if ((radio-registers[STATUSRSSI] STATUSRSSI_RDSR) == 0)
+ /* No RDS group ready, better luck next time */
+ return;
+
+ for (blocknum = 0; blocknum 4; blocknum++) {
+ switch (blocknum) {
+ default:
+ bler = (radio-registers[STATUSRSSI]
+ STATUSRSSI_BLERA) 9;
+ rds = radio-registers[RDSA];
+ break;
+ case 1:
+ bler = (radio-registers[READCHAN]
+ READCHAN_BLERB) 14;
+ rds = radio-registers[RDSB];
+ break;
+ case 2:
+ bler = (radio-registers[READCHAN]
+ READCHAN_BLERC) 12;
+ rds = radio-registers[RDSC];
+ break;
+ case 3:
+ bler = (radio-registers[READCHAN]
+ READCHAN_BLERD) 10;
+ rds = radio-registers[RDSD];
+ break;
+ };
+
+ /* Fill the V4L2 RDS buffer */
+ put_unaligned_le16(rds, tmpbuf);
+ tmpbuf[2] = blocknum; /* offset name */
+ tmpbuf[2] |= blocknum 3; /* received offset */
+ if (bler max_rds_errors)
+ tmpbuf[2] |= 0x80; /* uncorrectable errors */
+ else if (bler 0)
+ tmpbuf[2] |= 0x40; /* corrected error(s) */
+
+ /* copy RDS block to internal buffer */
+ memcpy(radio-buffer[radio-wr_index], tmpbuf, 3);
+ radio-wr_index += 3;
+
+ /* wrap write pointer */
+ if (radio-wr_index = radio-buf_size)
+ radio-wr_index = 0;
+
+ /* check for overflow */
Re: [PATCH 1/3] em-x270: don't use pxa_camera init() callback
Antonio Ospite wrote:
pxa_camera init() is going to be removed.
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
---
arch/arm/mach-pxa/em-x270.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
Acked-by: Mike Rapoport m...@compulab.co.il
diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa/em-x270.c
index aec7f42..f71f34c 100644
--- a/arch/arm/mach-pxa/em-x270.c
+++ b/arch/arm/mach-pxa/em-x270.c
@@ -967,7 +967,7 @@ static inline void em_x270_init_gpio_keys(void) {}
#if defined(CONFIG_VIDEO_PXA27x) || defined(CONFIG_VIDEO_PXA27x_MODULE)
static struct regulator *em_x270_camera_ldo;
-static int em_x270_sensor_init(struct device *dev)
+static int em_x270_sensor_init(void)
{
int ret;
@@ -996,7 +996,6 @@ static int em_x270_sensor_init(struct device *dev)
}
struct pxacamera_platform_data em_x270_camera_platform_data = {
- .init = em_x270_sensor_init,
.flags = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 |
PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN,
.mclk_10khz = 2600,
@@ -1049,8 +1048,10 @@ static struct platform_device em_x270_camera = {
static void __init em_x270_init_camera(void)
{
- pxa_set_camera_info(em_x270_camera_platform_data);
- platform_device_register(em_x270_camera);
+ if (em_x270_sensor_init() == 0) {
+ pxa_set_camera_info(em_x270_camera_platform_data);
+ platform_device_register(em_x270_camera);
+ }
}
#else
static inline void em_x270_init_camera(void) {}
--
Sincerely yours,
Mike.
--
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/3] radio-si470x: move some file operations to common file
On Wednesday 18 November 2009 07:42:41 Hans Verkuil wrote: On Wednesday 18 November 2009 07:21:30 Joonyoung Shim wrote: The read and poll file operations of the si470x usb driver can be used also equally on the si470x i2c driver, so they go to the common file. Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com Why on earth is the i2c driver registering a radio device? If I understand it correctly the usb and i2c driver are both registering a radio device where there should be only one! i2c drivers should in general never register video devices. That's the task of the bridge driver. Does anyone know why the current driver behaves like this? I think that should be fixed first. Regards, Hans It's too early in the morning. Forget what I said :-) The two drivers are independent, the usb driver doesn't depend on the i2c driver. Now it makes a lot more sense. 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: v4l: Use the video_drvdata function in drivers
On Wednesday 18 November 2009 01:38:48 Laurent Pinchart wrote:
Fix all device drivers to use the video_drvdata function instead of
maintaining a local list of minor to private data mappings. Call
video_set_drvdata to register the driver private pointer when not
already done.
Where applicable, the local list of mappings is completely removed when
it becomes unused.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Very nice cleanup!
But you need to check the lock_kernel calls carefully, I think one is now
unbalanced:
Index: v4l-dvb-mc-uvc/linux/drivers/media/video/cx88/cx88-video.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/media/video/cx88/cx88-video.c
+++ v4l-dvb-mc-uvc/linux/drivers/media/video/cx88/cx88-video.c
@@ -76,10 +76,6 @@ MODULE_PARM_DESC(vid_limit,capture memo
#define dprintk(level,fmt, arg...) if (video_debug = level) \
printk(KERN_DEBUG %s/0: fmt, core-name , ## arg)
-/* -- */
-
-static LIST_HEAD(cx8800_devlist);
-
/* --- */
/* static data */
@@ -980,31 +976,23 @@ static int get_ressource(struct cx8800_f
static int video_open(struct file *file)
{
int minor = video_devdata(file)-minor;
- struct cx8800_dev *h,*dev = NULL;
+ struct video_device *vdev = video_devdata(file);
+ struct cx8800_dev *dev = video_drvdata(file);
struct cx88_core *core;
struct cx8800_fh *fh;
enum v4l2_buf_type type = 0;
int radio = 0;
- lock_kernel();
Lock is removed.
- list_for_each_entry(h, cx8800_devlist, devlist) {
- if (h-video_dev-minor == minor) {
- dev = h;
- type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
- }
- if (h-vbi_dev-minor == minor) {
- dev = h;
- type = V4L2_BUF_TYPE_VBI_CAPTURE;
- }
- if (h-radio_dev
- h-radio_dev-minor == minor) {
- radio = 1;
- dev = h;
- }
- }
- if (NULL == dev) {
- unlock_kernel();
- return -ENODEV;
+ switch (vdev-vfl_type) {
+ case VFL_TYPE_GRABBER:
+ type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+ break;
+ case VFL_TYPE_VBI:
+ type = V4L2_BUF_TYPE_VBI_CAPTURE;
+ break;
+ case VFL_TYPE_RADIO:
+ radio = 1;
+ break;
}
But not added here. And I assume there is an unlock at the end of this
function as well.
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
