Re: Doing a stable v4l-utils release
Hi Sergio, Aguirre, Sergio wrote: Hi, -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hans de Goede Sent: Tuesday, April 27, 2010 3:08 AM To: Hans Verkuil Cc: Linux Media Mailing List Subject: Re: Doing a stable v4l-utils release Hi, On 04/26/2010 09:55 AM, Hans Verkuil wrote: On Monday 26 April 2010 09:35:23 Hans de Goede wrote: Hi all, Currently v4l-utils is at version 0.7.91, which as the version suggests is meant as a beta release. As this release seems to be working well I would like to do a v4l-utils-0.8.0 release soon. This is a headsup, to give people a chance to notify me of any bugs they would like to see fixed first / any patches they would like to add first. This is a good opportunity to mention that I would like to run checkpatch over the libs and clean them up. I also know that there is a bug in the control handling code w.r.t. V4L2_CTRL_FLAG_NEXT_CTRL. I have a patch, but I'd like to do the clean up first. If no one else has major patch series that they need to apply, then I can start working on this. The clean up is just purely whitespace changes to improve readability, no functionality will be touched. I've no big changes planned on the short term, so from my pov go ahead. I have one question regarding this utils: Is it meant to be platform agnostic v4l2 utilities? I tried once to compile it for a ARM based CPU (OMAP3 to be specific) from my x86 using a Codesourcery cross compilation toolchain, but it required some changes, which I haven't done still... Anyways, before proposing patches for this, I just wanted to know how much priority you're giving to multi-platform support. The major usage of v4l-utils is on x86 and x86_64 archs. I don't see why not adding there a logic that will also work with ARM and other architectures, providing, of course, that they won't break compilation on x86/x86_64 ;) Eventually, maybe the qt tools (currently, qv4l2) may need a specific versions for those architectures, as they may need different graphics layouts, in order to better work on cellular phones and other devices that have smaller screens. 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: [PATCH-V7] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2
-Original Message- From: Aguirre, Sergio Sent: Wednesday, April 28, 2010 12:27 AM To: Hiremath, Vaibhav; linux-media@vger.kernel.org Cc: mche...@redhat.com; Karicheri, Muralidharan; hverk...@xs4all.nl Subject: RE: [PATCH-V7] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2 Vaibhav, -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hiremath, Vaibhav Sent: Wednesday, April 07, 2010 5:01 AM To: linux-media@vger.kernel.org Cc: mche...@redhat.com; Karicheri, Muralidharan; hverk...@xs4all.nl; Hiremath, Vaibhav Subject: [PATCH-V7] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2 From: Vaibhav Hiremath hvaib...@ti.com Features Supported - 1. Provides V4L2 user interface for the video pipelines of DSS 2. Basic streaming working on LCD, DVI and TV. 3. Works on latest DSS2 library from Tomi 4. Support for various pixel formats like YUV, UYVY, RGB32, RGB24, RGB565 5. Supports Alpha blending. 6. Supports Color keying both source and destination. 7. Supports rotation. 8. Supports cropping. 9. Supports Background color setting. 10. Allocated buffers to only needed size This patch is broken in latest kernel. There are 2 main problems: [Hiremath, Vaibhav] Sergio, I do have patch fixing this issue and waiting V4L2 master to get updated first. I have attached patch here. The very first thing is this patch has been created against latest V4L2/master branch and not linux-omap branch. So there could be some gap between the merges of 2 branches. Also on regular basis (almost daily) I am making sure that all the patches which are submitted to the list are still get applied cleanly and works, obviously against their respective repositories. Thanks, Vaibhav 1. ARCH_OMAP24XX and ARCH_OMAP34XX doesn't exist anymore in latest kernel. Tony has left only ARCH_OMAP2420, ARCH_OMAP2430 and ARCH_OMAP3430. So, I did the change represented in patch #0001. 2. It doesn't compile. See attached log. I was able to partially fix some problems: drivers/media/video/omap/omap_vout.c: In function 'vidioc_reqbufs': drivers/media/video/omap/omap_vout.c:1841: error: implicit declaration of function 'kfree' drivers/media/video/omap/omap_vout.c: In function 'omap_vout_create_video_devices': drivers/media/video/omap/omap_vout.c:2375: error: implicit declaration of function 'kmalloc' ... drivers/media/video/omap/omap_vout.c: In function 'omap_vout_probe': drivers/media/video/omap/omap_vout.c:2514: error: implicit declaration of function 'kzalloc' drivers/media/video/omap/omap_vout.c:2514: warning: assignment makes pointer from integer without a cast With the attached patch #0002. But still the other problems are related to latest DSS2 framework changes. Can you please take a look at those? Regards, Sergio Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- drivers/media/video/Kconfig |2 + drivers/media/video/Makefile|2 + drivers/media/video/omap/Kconfig| 11 + drivers/media/video/omap/Makefile |7 + drivers/media/video/omap/omap_vout.c| 2644 +++ drivers/media/video/omap/omap_voutdef.h | 147 ++ drivers/media/video/omap/omap_voutlib.c | 293 drivers/media/video/omap/omap_voutlib.h | 34 + 8 files changed, 3140 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/omap/Kconfig create mode 100644 drivers/media/video/omap/Makefile create mode 100644 drivers/media/video/omap/omap_vout.c create mode 100644 drivers/media/video/omap/omap_voutdef.h create mode 100644 drivers/media/video/omap/omap_voutlib.c create mode 100644 drivers/media/video/omap/omap_voutlib.h snip 0001-OMAP-V4L2-Display-Rebased-against-latest-DSS2-chang.patch Description: 0001-OMAP-V4L2-Display-Rebased-against-latest-DSS2-chang.patch
Re: Doing a stable v4l-utils release
On Tuesday 27 April 2010 10:08:06 Hans de Goede wrote: Hi, On 04/26/2010 09:55 AM, Hans Verkuil wrote: On Monday 26 April 2010 09:35:23 Hans de Goede wrote: Hi all, Currently v4l-utils is at version 0.7.91, which as the version suggests is meant as a beta release. As this release seems to be working well I would like to do a v4l-utils-0.8.0 release soon. This is a headsup, to give people a chance to notify me of any bugs they would like to see fixed first / any patches they would like to add first. This is a good opportunity to mention that I would like to run checkpatch over the libs and clean them up. I also know that there is a bug in the control handling code w.r.t. V4L2_CTRL_FLAG_NEXT_CTRL. I have a patch, but I'd like to do the clean up first. If no one else has major patch series that they need to apply, then I can start working on this. The clean up is just purely whitespace changes to improve readability, no functionality will be touched. I've no big changes planned on the short term, so from my pov go ahead. As you noticed I have cleaned up the includes, libv4l1 and libv4l2. libv4lconvert is a lot more work, so I will do that bit by bit, hopefully this week. Regards, Hans Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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 v4 1/3] v4l: Add a new ERROR flag for DQBUF after recoverable streaming errors
This flag is intended to indicate streaming errors, which might have
resulted in corrupted video data in the buffer, but the buffer can still
be reused and streaming may continue.
Setting this flag and returning 0 is different from returning EIO. The
latter should now indicate more serious (unrecoverable) errors.
This patch also solves a problem with the ioctl handling code in
vl42-ioctl.c, which does not copy buffer identification data back to the
userspace when EIO is returned, so there is no way for applications
to discover on which buffer the operation failed in such cases.
Signed-off-by: Pawel Osciak p.osc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
include/linux/videodev2.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 15d80f7..7b6e047 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -551,6 +551,8 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_KEYFRAME 0x0008 /* Image is a keyframe (I-frame) */
#define V4L2_BUF_FLAG_PFRAME 0x0010 /* Image is a P-frame */
#define V4L2_BUF_FLAG_BFRAME 0x0020 /* Image is a B-frame */
+/* Buffer is ready, but the data contained within is corrupted. */
+#define V4L2_BUF_FLAG_ERROR0x0040
#define V4L2_BUF_FLAG_TIMECODE 0x0100 /* timecode field is valid */
#define V4L2_BUF_FLAG_INPUT 0x0200 /* input field is valid */
--
1.7.1.rc1.12.ga601
--
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] v4l: videobuf: Add support for V4L2_BUF_FLAG_ERROR
From: Hans Verkuil hverk...@xs4all.nl
For recoverable stream errors dqbuf() now returns 0 and the error flag
is set instead of returning EIO.
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/videobuf-core.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/videobuf-core.c
b/drivers/media/video/videobuf-core.c
index 03b32e4..7d33784 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -285,8 +285,10 @@ static void videobuf_status(struct videobuf_queue *q,
struct v4l2_buffer *b,
case VIDEOBUF_ACTIVE:
b-flags |= V4L2_BUF_FLAG_QUEUED;
break;
- case VIDEOBUF_DONE:
case VIDEOBUF_ERROR:
+ b-flags |= V4L2_BUF_FLAG_ERROR;
+ /* fall through */
+ case VIDEOBUF_DONE:
b-flags |= V4L2_BUF_FLAG_DONE;
break;
case VIDEOBUF_NEEDS_INIT:
@@ -670,6 +672,7 @@ int videobuf_dqbuf(struct videobuf_queue *q,
MAGIC_CHECK(q-int_ops-magic, MAGIC_QTYPE_OPS);
+ memset(b, 0, sizeof(*b));
mutex_lock(q-vb_lock);
retval = stream_next_buffer(q, buf, nonblocking);
@@ -681,23 +684,20 @@ int videobuf_dqbuf(struct videobuf_queue *q,
switch (buf-state) {
case VIDEOBUF_ERROR:
dprintk(1, dqbuf: state is error\n);
- retval = -EIO;
- CALL(q, sync, q, buf);
- buf-state = VIDEOBUF_IDLE;
break;
case VIDEOBUF_DONE:
dprintk(1, dqbuf: state is done\n);
- CALL(q, sync, q, buf);
- buf-state = VIDEOBUF_IDLE;
break;
default:
dprintk(1, dqbuf: state invalid\n);
retval = -EINVAL;
goto done;
}
- list_del(buf-stream);
- memset(b, 0, sizeof(*b));
+ CALL(q, sync, q, buf);
videobuf_status(q, b, buf, q-type);
+ list_del(buf-stream);
+ buf-state = VIDEOBUF_IDLE;
+ b-flags = ~V4L2_BUF_FLAG_DONE;
done:
mutex_unlock(q-vb_lock);
return retval;
--
1.7.1.rc1.12.ga601
--
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 v4 3/3] v4l: Add documentation for the new error flag
Add documentation for V4L2_BUF_FLAG_ERROR. Signed-off-by: Pawel Osciak p.osc...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- Documentation/DocBook/v4l/io.xml | 10 ++ Documentation/DocBook/v4l/vidioc-qbuf.xml | 14 -- 2 files changed, 22 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/v4l/io.xml b/Documentation/DocBook/v4l/io.xml index e870330..c5632ff 100644 --- a/Documentation/DocBook/v4l/io.xml +++ b/Documentation/DocBook/v4l/io.xml @@ -702,6 +702,16 @@ They can be both cleared however, then the buffer is in dequeued state, in the application domain to say so./entry /row row + entryconstantV4L2_BUF_FLAG_ERROR/constant/entry + entry0x0040/entry + entryWhen this flag is set, the buffer has been dequeued + successfully, although the data might have been corrupted. + This is recoverable, streaming may continue as normal and + the buffer may be reused normally. + Drivers set this flag when the constantVIDIOC_DQBUF/constant + ioctl is called./entry + /row + row entryconstantV4L2_BUF_FLAG_KEYFRAME/constant/entry entry0x0008/entry entryDrivers set or clear this flag when calling the diff --git a/Documentation/DocBook/v4l/vidioc-qbuf.xml b/Documentation/DocBook/v4l/vidioc-qbuf.xml index b843bd7..ab691eb 100644 --- a/Documentation/DocBook/v4l/vidioc-qbuf.xml +++ b/Documentation/DocBook/v4l/vidioc-qbuf.xml @@ -111,7 +111,11 @@ from the driver's outgoing queue. They just set the and structfieldreserved/structfield fields of a v4l2-buffer; as above, when constantVIDIOC_DQBUF/constant is called with a pointer to this structure the driver fills the -remaining fields or returns an error code./para +remaining fields or returns an error code. The driver may also set +constantV4L2_BUF_FLAG_ERROR/constant in the structfieldflags/structfield +field. It indicates a non-critical (recoverable) streaming error. In such case +the application may continue as normal, but should be aware that data in the +dequeued buffer might be corrupted./para paraBy default constantVIDIOC_DQBUF/constant blocks when no buffer is in the outgoing queue. When the @@ -158,7 +162,13 @@ enqueue a user pointer buffer./para paraconstantVIDIOC_DQBUF/constant failed due to an internal error. Can also indicate temporary problems like signal loss. Note the driver might dequeue an (empty) buffer despite -returning an error, or even stop capturing./para +returning an error, or even stop capturing. Reusing such buffer may be unsafe +though and its details (e.g. structfieldindex/structfield) may not be +returned either. It is recommended that drivers indicate recoverable errors +by setting the constantV4L2_BUF_FLAG_ERROR/constant and returning 0 instead. +In that case the application should be able to safely reuse the buffer and +continue streaming. + /para /listitem /varlistentry /variablelist -- 1.7.1.rc1.12.ga601 -- 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
WinTV-Nova-HD-S2 firmware failure
Hello, I have a WinTV-Nova-HD-S2 (known as HVR4000Lite) card for HD receiving. After a while of browsing trough channels, I'm getting the message: cx24116_cmd_execute() Firmware not responding and the card fails to tune anymore. The only fix from this situation is to reload the drivers and the firmware gets initialized again. Any chance to have a workaround to automatically reload the firmware ? Regards, Doru. -- 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] TT S2-1600 allow more current for diseqc
Hello Guy, On 11.04.2010 23:18, Guy Martin wrote: Hi linux-media, The following patch increases the current limit for the isl6423 chip on the TT S2-1600 card. This allows DiSEqC to work with more complex and current demanding configurations. Signed-off-by: Guy Martingms...@tuxicoman.be I am sorry for the late reply. I advise not to pull this change into the kernel sources. The card has only been testet with the a maximum current of 515mA. Anything above is outside the specification for this card. Kind Regards André -- 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] tm6000: Properly set alternate when preparing to stream
patch seem work with no adverse effect or benefit? although the green
screen is still an issue if the buffer is cleared.
maybe its just perception Will this patch give a better quality video?
On Mon, Apr 26, 2010 at 10:24 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Although the code is getting the better alternates, it is not really using
it. Get the interface/alternate numbers and use it where needed.
This patch implements also one small fix at the last_line set, as
proposed by Bee Hock Goh beh...@gmail.com.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
--
Cheers,
Mauro
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index f795a3e..a7e9556 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -634,21 +634,24 @@ err:
/* high bandwidth multiplier, as encoded in highspeed endpoint descriptors */
#define hb_mult(wMaxPacketSize) (1 + (((wMaxPacketSize) 11) 0x03))
-static void get_max_endpoint ( struct usb_device *usbdev,
- char *msgtype,
- struct usb_host_endpoint *curr_e,
- unsigned int *maxsize,
- struct usb_host_endpoint **ep )
+static void get_max_endpoint(struct usb_device *udev,
+ struct usb_host_interface *alt,
+ char *msgtype,
+ struct usb_host_endpoint *curr_e,
+ struct tm6000_endpoint *tm_ep)
{
u16 tmp = le16_to_cpu(curr_e-desc.wMaxPacketSize);
unsigned int size = tmp 0x7ff;
- if (usbdev-speed == USB_SPEED_HIGH)
+ if (udev-speed == USB_SPEED_HIGH)
size = size * hb_mult (tmp);
- if (size*maxsize) {
- *ep = curr_e;
- *maxsize = size;
+ if (size tm_ep-maxsize) {
+ tm_ep-endp = curr_e;
+ tm_ep-maxsize = size;
+ tm_ep-bInterfaceNumber = alt-desc.bInterfaceNumber;
+ tm_ep-bAlternateSetting = alt-desc.bAlternateSetting;
+
printk(tm6000: %s endpoint: 0x%02x (max size=%u bytes)\n,
msgtype, curr_e-desc.bEndpointAddress,
size);
@@ -743,24 +746,28 @@ static int tm6000_usb_probe(struct usb_interface
*interface,
switch (e-desc.bmAttributes) {
case USB_ENDPOINT_XFER_BULK:
if (!dir_out) {
- get_max_endpoint (usbdev, Bulk IN,
e,
- dev-max_bulk_in,
- dev-bulk_in);
+ get_max_endpoint(usbdev,
+
interface-altsetting[i],
+ Bulk IN, e,
+ dev-bulk_in);
} else {
- get_max_endpoint (usbdev, Bulk OUT,
e,
- dev-max_bulk_out,
- dev-bulk_out);
+ get_max_endpoint(usbdev,
+
interface-altsetting[i],
+ Bulk OUT, e,
+ dev-bulk_out);
}
break;
case USB_ENDPOINT_XFER_ISOC:
if (!dir_out) {
- get_max_endpoint (usbdev, ISOC IN,
e,
- dev-max_isoc_in,
- dev-isoc_in);
+ get_max_endpoint(usbdev,
+
interface-altsetting[i],
+ ISOC IN, e,
+ dev-isoc_in);
} else {
- get_max_endpoint (usbdev, ISOC OUT,
e,
- dev-max_isoc_out,
- dev-isoc_out);
+ get_max_endpoint(usbdev,
+
interface-altsetting[i],
+ ISOC OUT, e,
+ dev-isoc_out);
}
[PULL] New error flag for DQBUF
Hello Mauro, could you please pull the following patches? https://patchwork.kernel.org/patch/95627/ https://patchwork.kernel.org/patch/95628/ https://patchwork.kernel.org/patch/95629/ Best regards -- Pawel Osciak Linux Platform Group Samsung Poland RD Center -- 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-V7] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2
-Original Message- From: Hiremath, Vaibhav Sent: Wednesday, April 28, 2010 1:17 AM To: Aguirre, Sergio; linux-media@vger.kernel.org Cc: mche...@redhat.com; Karicheri, Muralidharan; hverk...@xs4all.nl Subject: RE: [PATCH-V7] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2 -Original Message- From: Aguirre, Sergio Sent: Wednesday, April 28, 2010 12:27 AM To: Hiremath, Vaibhav; linux-media@vger.kernel.org Cc: mche...@redhat.com; Karicheri, Muralidharan; hverk...@xs4all.nl Subject: RE: [PATCH-V7] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2 Vaibhav, -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hiremath, Vaibhav Sent: Wednesday, April 07, 2010 5:01 AM To: linux-media@vger.kernel.org Cc: mche...@redhat.com; Karicheri, Muralidharan; hverk...@xs4all.nl; Hiremath, Vaibhav Subject: [PATCH-V7] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2 From: Vaibhav Hiremath hvaib...@ti.com Features Supported - 1. Provides V4L2 user interface for the video pipelines of DSS 2. Basic streaming working on LCD, DVI and TV. 3. Works on latest DSS2 library from Tomi 4. Support for various pixel formats like YUV, UYVY, RGB32, RGB24, RGB565 5. Supports Alpha blending. 6. Supports Color keying both source and destination. 7. Supports rotation. 8. Supports cropping. 9. Supports Background color setting. 10. Allocated buffers to only needed size This patch is broken in latest kernel. There are 2 main problems: [Hiremath, Vaibhav] Sergio, I do have patch fixing this issue and waiting V4L2 master to get updated first. I have attached patch here. The very first thing is this patch has been created against latest V4L2/master branch and not linux-omap branch. So there could be some gap between the merges of 2 branches. Also on regular basis (almost daily) I am making sure that all the patches which are submitted to the list are still get applied cleanly and works, obviously against their respective repositories. Ok, apologies. I didn't knew you kept an updated patch somewhere else. I sincerely thought you haven't reposted this patch again. I'll look to the most updated version. Thanks, Sergio Thanks, Vaibhav 1. ARCH_OMAP24XX and ARCH_OMAP34XX doesn't exist anymore in latest kernel. Tony has left only ARCH_OMAP2420, ARCH_OMAP2430 and ARCH_OMAP3430. So, I did the change represented in patch #0001. 2. It doesn't compile. See attached log. I was able to partially fix some problems: drivers/media/video/omap/omap_vout.c: In function 'vidioc_reqbufs': drivers/media/video/omap/omap_vout.c:1841: error: implicit declaration of function 'kfree' drivers/media/video/omap/omap_vout.c: In function 'omap_vout_create_video_devices': drivers/media/video/omap/omap_vout.c:2375: error: implicit declaration of function 'kmalloc' ... drivers/media/video/omap/omap_vout.c: In function 'omap_vout_probe': drivers/media/video/omap/omap_vout.c:2514: error: implicit declaration of function 'kzalloc' drivers/media/video/omap/omap_vout.c:2514: warning: assignment makes pointer from integer without a cast With the attached patch #0002. But still the other problems are related to latest DSS2 framework changes. Can you please take a look at those? Regards, Sergio Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- drivers/media/video/Kconfig |2 + drivers/media/video/Makefile|2 + drivers/media/video/omap/Kconfig| 11 + drivers/media/video/omap/Makefile |7 + drivers/media/video/omap/omap_vout.c| 2644 +++ drivers/media/video/omap/omap_voutdef.h | 147 ++ drivers/media/video/omap/omap_voutlib.c | 293 drivers/media/video/omap/omap_voutlib.h | 34 + 8 files changed, 3140 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/omap/Kconfig create mode 100644 drivers/media/video/omap/Makefile create mode 100644 drivers/media/video/omap/omap_vout.c create mode 100644 drivers/media/video/omap/omap_voutdef.h create mode 100644 drivers/media/video/omap/omap_voutlib.c create mode 100644 drivers/media/video/omap/omap_voutlib.h snip -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tm6000
Dmitri Belimov wrote: Hi Anyone can watch TV with tm6000 module?? I try mplayer. My PC crashed inside copy_streams function after some time. With my best regards, Dmitry. It is still causing panic on my tests. Probably, the routine is still writing something out of the buffer area. -- 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: [PATCH 10/10] bkl: Fix-up compile problems as a result of the bkl-pushdown.
Hi Arnd,
Arnd Bergmann wrote:
On Tuesday 27 April 2010, John Kacur wrote:
Well it is certainly possible that my fixup is not correct too - your
patch cannot be correct, because it doesn't compile! Here is what I get
when I apply your patch to a recent linus/master
Ah, I see.
make O=/bld/arnd/ drivers/media/video/v4l2-dev.o
-CUT A BUNCH OF STUFF OUT ---
CC drivers/media/video/v4l2-dev.o
/home/jkacur/jk-2.6/drivers/media/video/v4l2-dev.c: In function
‘v4l2_ioctl’:
/home/jkacur/jk-2.6/drivers/media/video/v4l2-dev.c:230: warning: passing
argument 1 of ‘vdev-fops-ioctl’ from incompatible pointer type
/home/jkacur/jk-2.6/drivers/media/video/v4l2-dev.c:230: note: expected
‘struct file *’ but argument is of type ‘struct inode *’
I didn't realize that the prototype for the locked -ioctl function in
v4l2 does not take the inode argument, so that needs to be dropped from
my patch (i.e. not added).
Or we do it slightly better and clean up the code a bit in the process.
Mauro, does this patch make sense to you? It would be good to have your
Ack so we can queue this in the series leading to the removal of the
-ioctl file operation. We can also do the minimal change and let you
take care of fixing this up in a different way in your own tree.
We had a similar discussion a while ago at linux-media. The idea is to do
it on a deeper level, changing the drivers to not need to use KBL.
Hans is working on those patches. Not sure about the current status.
Anyway, I think that the better is to apply first your patch, to avoid
breaking your patch series, and then ours, as we may otherwise have some
conflicts between your tree and drivers/media git tree.
So,
Acked-by: Mauro Carvalho Chehab mche...@redhat.com
---
Subject: v4l: convert v4l2-dev to unlocked_ioctl
v4l2 implements two separate file operations for drivers that use locked
and unlocked ioctl callbacks. Since we want to remove the ioctl file operation
in favor of the unlocked variant, this separation no longer seems helpful.
Unfortunately, there are still 77 drivers with locked ioctl functions in
their v4l2_file_operations, which need to be taken care of separately.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
drivers/media/video/v4l2-dev.c | 52 +++
1 files changed, 15 insertions(+), 37 deletions(-)
diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
index 7090699..ab198ba 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -25,6 +25,7 @@
#include linux/init.h
#include linux/kmod.h
#include linux/slab.h
+#include linux/smp_lock.h
#include asm/uaccess.h
#include asm/system.h
@@ -215,28 +216,24 @@ static unsigned int v4l2_poll(struct file *filp, struct
poll_table_struct *poll)
return vdev-fops-poll(filp, poll);
}
-static int v4l2_ioctl(struct inode *inode, struct file *filp,
- unsigned int cmd, unsigned long arg)
+static long v4l2_ioctl(struct file *filp, unsigned int cmd, unsigned long
arg)
{
struct video_device *vdev = video_devdata(filp);
+ int ret;
- if (!vdev-fops-ioctl)
- return -ENOTTY;
/* Allow ioctl to continue even if the device was unregistered.
Things like dequeueing buffers might still be useful. */
- return vdev-fops-ioctl(filp, cmd, arg);
-}
-
-static long v4l2_unlocked_ioctl(struct file *filp,
- unsigned int cmd, unsigned long arg)
-{
- struct video_device *vdev = video_devdata(filp);
+ if (vdev-fops-unlocked_ioctl) {
+ ret = vdev-fops-unlocked_ioctl(filp, cmd, arg);
+ } else if (vdev-fops-ioctl) {
+ /* TODO: convert all drivers to unlocked_ioctl */
+ lock_kernel();
+ ret = vdev-fops-ioctl(filp, cmd, arg);
+ unlock_kernel();
+ } else
+ ret = -ENOTTY;
- if (!vdev-fops-unlocked_ioctl)
- return -ENOTTY;
- /* Allow ioctl to continue even if the device was unregistered.
-Things like dequeueing buffers might still be useful. */
- return vdev-fops-unlocked_ioctl(filp, cmd, arg);
+ return ret;
}
#ifdef CONFIG_MMU
@@ -307,22 +304,6 @@ static int v4l2_release(struct inode *inode, struct file
*filp)
return ret;
}
-static const struct file_operations v4l2_unlocked_fops = {
- .owner = THIS_MODULE,
- .read = v4l2_read,
- .write = v4l2_write,
- .open = v4l2_open,
- .get_unmapped_area = v4l2_get_unmapped_area,
- .mmap = v4l2_mmap,
- .unlocked_ioctl = v4l2_unlocked_ioctl,
-#ifdef CONFIG_COMPAT
- .compat_ioctl = v4l2_compat_ioctl32,
-#endif
- .release = v4l2_release,
- .poll = v4l2_poll,
- .llseek = no_llseek,
-};
-
static const struct file_operations v4l2_fops = {
.owner = THIS_MODULE,
.read = v4l2_read,
@@ -330,7 +311,7 @@ static const struct
Re: [PATCH] TT S2-1600 allow more current for diseqc
Hello Guy, On 28.04.2010 10:33, Guy Martin wrote: On Wed, 28 Apr 2010 09:45:39 +0200 André Weidemannandre.weidem...@web.de wrote: I advise not to pull this change into the kernel sources. The card has only been testet with the a maximum current of 515mA. Anything above is outside the specification for this card. I'm currently running two of these cards in the same box with this patch. Actually, later on I've even set curlim = SEC_CURRENT_LIM_OFF because sometimes diseqc wasn't working fine and that seemed to solve the problem. I used to have skystar2 cards before and I did not run into those issues. Diseqc just worked fine. For reference each tt s2 is plugged to a diseqc switch with 4 output, each output connected to a quad lnb. How come there is such a high current drain to drive the switch plus the LNBs? From what I understand, the switch should only power one LNB at a time. Usually the switch plus the LNB should not drain more than 300-400mA, or am I wrong here? Is there another way to solve this ? Maybe add a module parameter for people who want to override the default ? I think this could be done. Nevertheless, the card would still operate outside its specification. Regards André -- 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 10/10] bkl: Fix-up compile problems as a result of the bkl-pushdown.
Hi Arnd,
Arnd Bergmann wrote:
On Tuesday 27 April 2010, John Kacur wrote:
Well it is certainly possible that my fixup is not correct too - your
patch cannot be correct, because it doesn't compile! Here is what I get
when I apply your patch to a recent linus/master
Ah, I see.
make O=/bld/arnd/ drivers/media/video/v4l2-dev.o
-CUT A BUNCH OF STUFF OUT ---
CC drivers/media/video/v4l2-dev.o
/home/jkacur/jk-2.6/drivers/media/video/v4l2-dev.c: In function
âv4l2_ioctlâ:
/home/jkacur/jk-2.6/drivers/media/video/v4l2-dev.c:230: warning:
passing
argument 1 of âvdev-fops-ioctlâ from incompatible pointer type
/home/jkacur/jk-2.6/drivers/media/video/v4l2-dev.c:230: note: expected
âstruct file *â but argument is of type âstruct inode *â
I didn't realize that the prototype for the locked -ioctl function in
v4l2 does not take the inode argument, so that needs to be dropped from
my patch (i.e. not added).
Or we do it slightly better and clean up the code a bit in the process.
Mauro, does this patch make sense to you? It would be good to have your
Ack so we can queue this in the series leading to the removal of the
-ioctl file operation. We can also do the minimal change and let you
take care of fixing this up in a different way in your own tree.
We had a similar discussion a while ago at linux-media. The idea is to do
it on a deeper level, changing the drivers to not need to use KBL.
Hans is working on those patches. Not sure about the current status.
I'm waiting for the event patch series from Sakari to go in before I can
continue working on this.
Anyway, I think that the better is to apply first your patch, to avoid
breaking your patch series, and then ours, as we may otherwise have some
conflicts between your tree and drivers/media git tree.
I have no real problem with this patch, as long as people realize that
this only moves the BKL from one place to another and does not really fix
any drivers.
Acked-by: Hans Verkuil hverk...@xs4all.nl
Regards,
Hans
So,
Acked-by: Mauro Carvalho Chehab mche...@redhat.com
---
Subject: v4l: convert v4l2-dev to unlocked_ioctl
v4l2 implements two separate file operations for drivers that use locked
and unlocked ioctl callbacks. Since we want to remove the ioctl file
operation
in favor of the unlocked variant, this separation no longer seems
helpful.
Unfortunately, there are still 77 drivers with locked ioctl functions in
their v4l2_file_operations, which need to be taken care of separately.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
drivers/media/video/v4l2-dev.c | 52
+++
1 files changed, 15 insertions(+), 37 deletions(-)
diff --git a/drivers/media/video/v4l2-dev.c
b/drivers/media/video/v4l2-dev.c
index 7090699..ab198ba 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -25,6 +25,7 @@
#include linux/init.h
#include linux/kmod.h
#include linux/slab.h
+#include linux/smp_lock.h
#include asm/uaccess.h
#include asm/system.h
@@ -215,28 +216,24 @@ static unsigned int v4l2_poll(struct file *filp,
struct poll_table_struct *poll)
return vdev-fops-poll(filp, poll);
}
-static int v4l2_ioctl(struct inode *inode, struct file *filp,
-unsigned int cmd, unsigned long arg)
+static long v4l2_ioctl(struct file *filp, unsigned int cmd, unsigned
long arg)
{
struct video_device *vdev = video_devdata(filp);
+int ret;
-if (!vdev-fops-ioctl)
-return -ENOTTY;
/* Allow ioctl to continue even if the device was unregistered.
Things like dequeueing buffers might still be useful. */
-return vdev-fops-ioctl(filp, cmd, arg);
-}
-
-static long v4l2_unlocked_ioctl(struct file *filp,
-unsigned int cmd, unsigned long arg)
-{
-struct video_device *vdev = video_devdata(filp);
+if (vdev-fops-unlocked_ioctl) {
+ret = vdev-fops-unlocked_ioctl(filp, cmd, arg);
+} else if (vdev-fops-ioctl) {
+/* TODO: convert all drivers to unlocked_ioctl */
+lock_kernel();
+ret = vdev-fops-ioctl(filp, cmd, arg);
+unlock_kernel();
+} else
+ret = -ENOTTY;
-if (!vdev-fops-unlocked_ioctl)
-return -ENOTTY;
-/* Allow ioctl to continue even if the device was unregistered.
- Things like dequeueing buffers might still be useful. */
-return vdev-fops-unlocked_ioctl(filp, cmd, arg);
+return ret;
}
#ifdef CONFIG_MMU
@@ -307,22 +304,6 @@ static int v4l2_release(struct inode *inode, struct
file *filp)
return ret;
}
-static const struct file_operations v4l2_unlocked_fops = {
-.owner = THIS_MODULE,
-.read = v4l2_read,
-.write = v4l2_write,
-.open = v4l2_open,
-.get_unmapped_area = v4l2_get_unmapped_area,
-.mmap = v4l2_mmap,
-.unlocked_ioctl = v4l2_unlocked_ioctl,
-#ifdef CONFIG_COMPAT
-
Re: [PATCH 10/10] bkl: Fix-up compile problems as a result of the bkl-pushdown.
Hi Hans, On Wednesday 28 April 2010 14:37:10 Hans Verkuil wrote: Arnd Bergmann wrote: [snip] Mauro, does this patch make sense to you? It would be good to have your Ack so we can queue this in the series leading to the removal of the -ioctl file operation. We can also do the minimal change and let you take care of fixing this up in a different way in your own tree. We had a similar discussion a while ago at linux-media. The idea is to do it on a deeper level, changing the drivers to not need to use KBL. Hans is working on those patches. Not sure about the current status. I'm waiting for the event patch series from Sakari to go in before I can continue working on this. Anyway, I think that the better is to apply first your patch, to avoid breaking your patch series, and then ours, as we may otherwise have some conflicts between your tree and drivers/media git tree. I have no real problem with this patch, as long as people realize that this only moves the BKL from one place to another and does not really fix any drivers. Seems that Arnd was more convincing than me. I've submitted the exact same patch a while ago :-) Of course this doesn't solve the BKL issue, but it pushes it one level down, closer to the drivers. Higher levels can then stop caring about it. Of course lower levels will still need to remove the BKL. -- 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
Re: [PATCH] TT S2-1600 allow more current for diseqc
On Wed, Apr 28, 2010 at 12:33 PM, Guy Martin gms...@tuxicoman.be wrote: On Wed, 28 Apr 2010 09:45:39 +0200 André Weidemann andre.weidem...@web.de wrote: I advise not to pull this change into the kernel sources. The card has only been testet with the a maximum current of 515mA. Anything above is outside the specification for this card. I'm currently running two of these cards in the same box with this patch. Actually, later on I've even set curlim = SEC_CURRENT_LIM_OFF because sometimes diseqc wasn't working fine and that seemed to solve the problem. I would advise to not do this: since disabling current limiting etc will cause a large problem in the case of a short circuit thereby no protection to the hardware. In such an event, it could probably damage the tracks carrying power on the card as well as the tracks on the motherboard, and in some cases the gold finches themselves and or the PCI connector. Generally, there are only a few devices capable of sourcing 0.5A, So I wonder Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] TT S2-1600 allow more current for diseqc
Hi Andre, On Wed, 28 Apr 2010 14:29:10 +0200 André Weidemann andre.weidem...@web.de wrote: How come there is such a high current drain to drive the switch plus the LNBs? From what I understand, the switch should only power one LNB at a time. Usually the switch plus the LNB should not drain more than 300-400mA, or am I wrong here? This is what I understood as well. It's cheap switch and LNBs so that may explain it :) I don't know how I can measure the current being drained tho. I only found out that increasing the limit made my setup work. It may be as well that the isl6423 driver doesnt' set the limit correctly and configures a lower current limit than what is expected. Is there another way to solve this ? Maybe add a module parameter for people who want to override the default ? I think this could be done. Nevertheless, the card would still operate outside its specification. Ok I'll work on a patch in that direction. Probably an integer parameter with multiple possible values allowing to choose the limit or disable it and add a big fat warning along the way. Cheers, Guy -- 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] V4L: Events: Include slab.h explicitly
Sergio Aguirre wrote: After commit ID: commit de380b55f92986c1a84198149cb71b7228d15fbd Author: Tejun Heo t...@kernel.org Date: Wed Mar 24 17:06:43 2010 +0900 percpu: don't implicitly include slab.h from percpu.h slab.h include was not longer implicitly included with sched.h. So, now we have to include slab.h explicitly. Signed-off-by: Sergio Aguirre saagui...@ti.com --- drivers/media/video/v4l2-event.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/v4l2-event.c b/drivers/media/video/v4l2-event.c index aea4332..7f31cd2 100644 --- a/drivers/media/video/v4l2-event.c +++ b/drivers/media/video/v4l2-event.c @@ -26,6 +26,7 @@ #include media/v4l2-fh.h #include media/v4l2-event.h +#include linux/slab.h #include linux/sched.h int v4l2_event_init(struct v4l2_fh *fh) Thanks for the patch, Sergio! I was going to say that I'll send a new pull request but apparently forgot to send this one in time. Anyway, this is now included in the patchset, merged with another patch. Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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 10/10] bkl: Fix-up compile problems as a result of the bkl-pushdown.
Laurent Pinchart wrote: Hi Hans, On Wednesday 28 April 2010 14:37:10 Hans Verkuil wrote: Arnd Bergmann wrote: [snip] Mauro, does this patch make sense to you? It would be good to have your Ack so we can queue this in the series leading to the removal of the -ioctl file operation. We can also do the minimal change and let you take care of fixing this up in a different way in your own tree. We had a similar discussion a while ago at linux-media. The idea is to do it on a deeper level, changing the drivers to not need to use KBL. Hans is working on those patches. Not sure about the current status. I'm waiting for the event patch series from Sakari to go in before I can continue working on this. Anyway, I think that the better is to apply first your patch, to avoid breaking your patch series, and then ours, as we may otherwise have some conflicts between your tree and drivers/media git tree. I have no real problem with this patch, as long as people realize that this only moves the BKL from one place to another and does not really fix any drivers. Seems that Arnd was more convincing than me. I've submitted the exact same patch a while ago :-) Same patch, different situation ;) Of course this doesn't solve the BKL issue, but it pushes it one level down, closer to the drivers. Higher levels can then stop caring about it. Of course lower levels will still need to remove the BKL. Yes. This patch doesn't change anything in practice, but it allows RT people to keep working on their series of changes, giving us a little more time to work on a definitive solution. If nacked, we would need to send an alternative patch for them, and, as this is not ready (and such patch applied via RT tree would likely cause merge conflicts with our patches), the better is to just ack and keep writing the patch that will solve the issue. Your patch were very useful, as it started the discussions for the BKL removal on drivers/media drivers. -- 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
debugging my Tevii S660 usb 2.0 dvb-s2 device
Hello all, I have bought a new tevii s660 device in december 3 months later (backorder) when i received my device i was having issues when loading the driver from the tevii website. First loading went ok but then i got hundreds of debug messages in dmesg. Later this device really died so i sent it back for rma. Now i have received a new device but still have the same issues. I got the old drivers from Artem: Re: [vdr] System unresponsive and picture breakup with VDR 1.7.10 and Tevii S660 (USB) (thanks for helping out) But still i have system freezes. and a channel scan freaks out my system and device. Does someone have time/ideas how to make this device work and how can i deliver the right info to make it happen. I'm no developer so programming is a problem but i'm happy to try patches if someone can help me out. So what info would be needed beside a dmesg/uname -a and how can i get the right information e.g. lsusb -vvv With kind regards William van de Velde -- 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] IR/imon: add proper auto-repeat support
Set the EV_REP bit, so reported key repeats actually make their
way out to userspace, and fix up the handling of repeats a bit,
routines for which are shamelessly heisted from ati_remote2.c.
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/IR/imon.c | 38 +++---
1 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/drivers/media/IR/imon.c b/drivers/media/IR/imon.c
index b65c31a..16e2e7f 100644
--- a/drivers/media/IR/imon.c
+++ b/drivers/media/IR/imon.c
@@ -130,6 +130,7 @@ struct imon_context {
u64 ir_type;/* iMON or MCE (RC6) IR protocol? */
u8 mce_toggle_bit; /* last mce toggle bit */
bool release_code; /* some keys send a release code */
+ unsigned long jiffies; /* repeat timer */
u8 display_type;/* store the display type */
bool pad_mouse; /* toggle kbd(0)/mouse(1) mode */
@@ -146,7 +147,6 @@ struct imon_context {
};
#define TOUCH_TIMEOUT (HZ/30)
-#define MCE_TIMEOUT_MS 200
/* vfd character device file operations */
static const struct file_operations vfd_fops = {
@@ -1394,6 +1394,8 @@ static int imon_parse_press_type(struct imon_context
*ictx,
unsigned char *buf, u8 ktype)
{
int press_type = 0;
+ int rep_delay = ictx-idev-rep[REP_DELAY];
+ int rep_period = ictx-idev-rep[REP_PERIOD];
/* key release of 0x02XX key */
if (ictx-kc == KEY_RESERVED buf[0] == 0x02 buf[3] == 0x00)
@@ -1418,12 +1420,12 @@ static int imon_parse_press_type(struct imon_context
*ictx,
ictx-mce_toggle_bit = buf[2];
press_type = 1;
mod_timer(ictx-itimer,
- jiffies + msecs_to_jiffies(MCE_TIMEOUT_MS));
+ jiffies + msecs_to_jiffies(rep_delay));
/* repeat */
} else {
press_type = 2;
mod_timer(ictx-itimer,
- jiffies + msecs_to_jiffies(MCE_TIMEOUT_MS));
+ jiffies + msecs_to_jiffies(rep_period));
}
/* incoherent or irrelevant data */
@@ -1458,12 +1460,14 @@ static void imon_incoming_packet(struct imon_context
*ictx,
u32 remote_key = 0;
struct input_dev *idev = NULL;
int press_type = 0;
- int msec;
+ int msec, rep_delay, rep_period;
struct timeval t;
static struct timeval prev_time = { 0, 0 };
u8 ktype = IMON_KEY_IMON;
idev = ictx-idev;
+ rep_delay = idev-rep[REP_DELAY];
+ rep_period = idev-rep[REP_PERIOD];
/* filter out junk data on the older 0xffdc imon devices */
if ((buf[0] == 0xff) (buf[7] == 0xff))
@@ -1529,8 +1533,28 @@ static void imon_incoming_packet(struct imon_context
*ictx,
}
press_type = imon_parse_press_type(ictx, buf, ktype);
- if (press_type 0)
+
+ switch (press_type) {
+ /* release */
+ case 0:
+ break;
+ /* press */
+ case 1:
+ ictx-jiffies = jiffies + msecs_to_jiffies(rep_delay);
+ break;
+ /* repeat */
+ case 2:
+ /* don't repeat too fast */
+ if (!time_after_eq(jiffies, ictx-jiffies))
+ return;
+
+ ictx-jiffies = jiffies + msecs_to_jiffies(rep_period);
+ break;
+ case -EINVAL:
+ default:
goto not_input_data;
+ break;
+ }
if (ictx-kc == KEY_UNKNOWN)
goto unknown_key;
@@ -1541,7 +1565,7 @@ static void imon_incoming_packet(struct imon_context
*ictx,
do_gettimeofday(t);
msec = tv2int(t, prev_time);
prev_time = t;
- if (msec 200)
+ if (msec rep_delay)
return;
}
@@ -1686,7 +1710,7 @@ static struct input_dev *imon_init_idev(struct
imon_context *ictx)
strlcat(ictx-phys_idev, /input0, sizeof(ictx-phys_idev));
idev-phys = ictx-phys_idev;
- idev-evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REL);
+ idev-evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REP) | BIT_MASK(EV_REL);
idev-keybit[BIT_WORD(BTN_MOUSE)] =
BIT_MASK(BTN_LEFT) | BIT_MASK(BTN_RIGHT);
--
Jarod Wilson
ja...@redhat.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] IR/imon: minor change_protocol fixups
This is a follow-up to my prior patch implementing ir-core's
change_protocol functionality in the imon driver, which eliminates
a false warning when change_protocol is called without a specific
protocol selected yet (i.e., still IR_TYPE_UNKNOWN). It also removes
some extraneous blank lines getting spewn into dmesg.
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/IR/imon.c | 20 +---
1 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/media/IR/imon.c b/drivers/media/IR/imon.c
index 16e2e7f..6fb3b05 100644
--- a/drivers/media/IR/imon.c
+++ b/drivers/media/IR/imon.c
@@ -999,7 +999,7 @@ int imon_ir_change_protocol(void *priv, u64 ir_type)
unsigned char ir_proto_packet[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x86 };
- if (!(ir_type ictx-props-allowed_protos))
+ if (ir_type !(ir_type ictx-props-allowed_protos))
dev_warn(dev, Looks like you're trying to use an IR protocol
this device does not support\n);
@@ -1014,12 +1014,11 @@ int imon_ir_change_protocol(void *priv, u64 ir_type)
break;
case IR_TYPE_UNKNOWN:
case IR_TYPE_OTHER:
- dev_dbg(dev, Configuring IR receiver for iMON protocol);
- if (pad_stabilize) {
- printk(KERN_CONT \n);
+ dev_dbg(dev, Configuring IR receiver for iMON protocol\n);
+ if (pad_stabilize)
pad_mouse = true;
- } else {
- printk(KERN_CONT (without PAD stabilization)\n);
+ else {
+ dev_dbg(dev, PAD stabilize functionality disabled\n);
pad_mouse = false;
}
/* ir_proto_packet[0] = 0x00; // already the default */
@@ -1027,12 +1026,11 @@ int imon_ir_change_protocol(void *priv, u64 ir_type)
break;
default:
dev_warn(dev, Unsupported IR protocol specified, overriding
-to iMON IR protocol);
- if (pad_stabilize) {
- printk(KERN_CONT \n);
+to iMON IR protocol\n);
+ if (pad_stabilize)
pad_mouse = true;
- } else {
- printk(KERN_CONT (without PAD stabilization)\n);
+ else {
+ dev_dbg(dev, PAD stabilize functionality disabled\n);
pad_mouse = false;
}
/* ir_proto_packet[0] = 0x00; // already the default */
--
Jarod Wilson
ja...@redhat.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: 0844-Staging-cx25821-fix-coding-style-issues-in-cx25821-a.patch
On Sun, Mar 14, 2010 at 06:13:16PM +0200, Olimpiu Pascariu wrote: From 9473816c446a6ca91905fc49a73732f70b5223b4 Mon Sep 17 00:00:00 2001 From: Olimpiu Pascariu olimpiu.pasca...@gmail.com Date: Sun, 14 Mar 2010 17:44:37 +0200 Subject: [PATCH 844/844] Staging: cx25821: fix coding style issues in cx25821-alsa.c This is a patch to the cx25821-alsa.c file that fixes up errors and warnings found by the checkpatch.pl tool Signed-off-by: Olimpiu Pascariu olimpiu.pasca...@gmail.com Parts of this patch have already been applied to the tree, from someone else, so this doesn't apply anymore, sorry :( thanks, greg k-h -- 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: debugging my Tevii S660 usb 2.0 dvb-s2 device
First some additional info. my current dmesg is full with messages like: [93953.934121] ds3000_readreg: read reg 0xfe, value 0x92 [93953.934128] ds3000_writereg: write reg 0xfe, value 0x9b [93953.953980] ds3000_writereg: write reg 0x29, value 0x80 [93953.974481] ds3000_writereg: write reg 0x25, value 0x8a [93953.991359] ds3000_writereg: write reg 0xc3, value 0x06 [93954.030037] ds3000_writereg: write reg 0xc8, value 0x0a [93954.050038] ds3000_writereg: write reg 0xc4, value 0x05 [93954.070040] ds3000_writereg: write reg 0xc7, value 0x24 [93954.090041] ds3000_writereg: write reg 0x61, value 0xab [93954.110048] ds3000_writereg: write reg 0x62, value 0x3a [93954.130037] ds3000_writereg: write reg 0x56, value 0x00 [93954.150036] ds3000_writereg: write reg 0x76, value 0x00 [93954.170041] ds3000_writereg: write reg 0x00, value 0x00 [93954.212100] ds3000_writereg: write reg 0xb2, value 0x00 filename: /lib/modules/2.6.33-020633-generic/kernel/drivers/media/dvb/frontends/ds3000.ko license:GPL author: Konstantin Dimitrov description:DVB Frontend module for Montage Technology DS3000/TS2020 hardware srcversion: 68E19175166A175DA0F8DA5 depends: vermagic: 2.6.33-020633-generic SMP mod_unload modversions parm: debug:Activates frontend debugging (default:0) (int) filename: /lib/modules/2.6.33-020633-generic/kernel/drivers/media/dvb/dvb-usb/teviis660.ko license:GPL version:0.2 description:Driver for TEVII S660 author: Bob Liu srcversion: 12CD426AC8F3EB7F840E7F8 alias: usb:v04B4pD660d*dc*dsc*dp*ic*isc*ip* alias: usb:v9022pD660d*dc*dsc*dp*ic*isc*ip* depends:dvb-usb vermagic: 2.6.33-020633-generic SMP mod_unload modversions parm: debug:set debugging level (1=info 2=xfer (or-able)). (int) parm: adapter_nr:DVB adapter numbers (array of short) after unloading and loading i get: [94168.701559] dvb-usb: found a 'TEVII S660 DVBS2 USB2.0' in cold state, will try to load a firmware [94168.701576] usb 1-3: firmware: requesting dvb-usb-teviis660.fw [94168.741456] dvb-usb: downloading firmware from file 'dvb-usb-teviis660.fw' [94168.741473] usb 1-3: firmware: requesting dvb-usb-teviis660.fw [94168.753227] teviis660: start downloading TEVIIS660 firmware [94169.100046] dvb-usb: found a 'TEVII S660 DVBS2 USB2.0' in warm state. [94169.100161] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [94169.100331] DVB: registering new adapter (TEVII S660 DVBS2 USB2.0) [94169.229153] dvb-usb: MAC address: 00:18:bd:5c:54:7f [94169.284778] ds3000_attach [94169.300277] ds3000_readreg: read reg 0x00, value 0xe0 [94169.320273] ds3000_readreg: read reg 0x01, value 0xc0 [94169.340272] ds3000_readreg: read reg 0x02, value 0x00 [94169.340279] DS3000 chip version: 0.192 attached. [94169.340285] S660: DS3000 attached. [94169.340293] DVB: registering adapter 0 frontend 0 (Montage Technology DS3000/TS2020)... [94169.341773] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb1/1-3/input/input6 [94169.341911] dvb-usb: schedule remote query interval to 150 msecs. [94169.341925] dvb-usb: TEVII S660 DVBS2 USB2.0 successfully initialized and connected. [94169.342015] usbcore: registered new interface driver teviis660 this is the output from lsusb -v for the tevii device Bus 001 Device 003: ID 9022:d660 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x9022 idProduct 0xd660 bcdDevice0.00 iManufacturer 1 TBS-Tech iProduct2 DVBS2BOX iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: WARNINGS
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:Wed Apr 28 19:00:24 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14605:5910305f6d48 git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: b88a1e83c9bfa5afbe1dd7481ea15fbea5ad9e55 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-rc1-armv5: OK linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-rc1-armv5-davinci: OK linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-armv5-ixp: OK linux-2.6.34-rc1-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-rc1-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS linux-2.6.23.17-i686: WARNINGS linux-2.6.24.7-i686: OK linux-2.6.25.20-i686: OK linux-2.6.26.8-i686: OK linux-2.6.27.44-i686: OK linux-2.6.28.10-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: OK linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-rc1-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-rc1-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-rc1-mips: OK linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.17-x86_64: WARNINGS linux-2.6.24.7-x86_64: OK linux-2.6.25.20-x86_64: OK linux-2.6.26.8-x86_64: OK linux-2.6.27.44-x86_64: OK linux-2.6.28.10-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: OK linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-rc1-x86_64: WARNINGS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.7-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.62-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.7-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/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IR/imon: add proper auto-repeat support
On Wed, Apr 28, 2010 at 01:37:00PM -0400, Jarod Wilson wrote: Set the EV_REP bit, so reported key repeats actually make their way out to userspace, and fix up the handling of repeats a bit, routines for which are shamelessly heisted from ati_remote2.c. Is it really needed? I'd expect input core handling auto-repeating for you as long as you set EV_REP flag. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] tm6000: bugfix analog init for tm6010
--
Stefan Ringel stefan.rin...@arcor.de
commit 32b6f5e24c4de1143c784fd82201ac32c191c3b0
Author: Stefan Ringel stefan.rin...@arcor.de
Date: Wed Apr 28 22:31:19 2010 +0200
tm6000: bugfix analog init for tm6010
- change value in function tm6000_set_fourcc_format
- disable digital source
- add vbi and audio init
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de
diff --git a/drivers/staging/tm6000/tm6000-core.c b/drivers/staging/tm6000/tm6000-core.c
index 0b4dc64..ff5d0b6 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -157,9 +157,9 @@ void tm6000_set_fourcc_format(struct tm6000_core *dev)
{
if (dev-dev_type == TM6010) {
if (dev-fourcc == V4L2_PIX_FMT_UYVY)
- tm6000_set_reg(dev, TM6010_REQ07_RC1_TRESHOLD, 0xfc);
+ tm6000_set_reg(dev, TM6010_REQ07_RC1_TRESHOLD, 0xd0);
else
- tm6000_set_reg(dev, TM6010_REQ07_RC1_TRESHOLD, 0xfd);
+ tm6000_set_reg(dev, TM6010_REQ07_RC1_TRESHOLD, 0x90);
} else {
if (dev-fourcc == V4L2_PIX_FMT_UYVY)
tm6000_set_reg(dev, TM6010_REQ07_RC1_TRESHOLD, 0xd0);
@@ -177,7 +177,79 @@ int tm6000_init_analog_mode (struct tm6000_core *dev)
val = tm6000_get_reg(dev, TM6010_REQ07_RCC_ACTIVE_VIDEO_IF, 0);
val |= 0x60;
tm6000_set_reg(dev, TM6010_REQ07_RCC_ACTIVE_VIDEO_IF, val);
- tm6000_set_reg(dev, TM6010_REQ07_RFE_POWER_DOWN, 0xcf);
+ val = tm6000_get_reg(dev, TM6010_REQ07_RC0_ACTIVE_VIDEO_SOURCE, 0);
+ val = ~0x40;
+ tm6000_set_reg(dev, TM6010_REQ07_RC0_ACTIVE_VIDEO_SOURCE, val);
+
+ /* Init teletext */
+ tm6000_set_reg(dev, TM6010_REQ07_R3F_RESET, 0x01);
+ tm6000_set_reg(dev, TM6010_REQ07_R41_TELETEXT_VBI_CODE1, 0x27);
+ tm6000_set_reg(dev, TM6010_REQ07_R42_VBI_DATA_HIGH_LEVEL, 0x55);
+ tm6000_set_reg(dev, TM6010_REQ07_R43_VBI_DATA_TYPE_LINE7, 0x66);
+ tm6000_set_reg(dev, TM6010_REQ07_R44_VBI_DATA_TYPE_LINE8, 0x66);
+ tm6000_set_reg(dev, TM6010_REQ07_R45_VBI_DATA_TYPE_LINE9, 0x66);
+ tm6000_set_reg(dev, TM6010_REQ07_R46_VBI_DATA_TYPE_LINE10, 0x66);
+ tm6000_set_reg(dev, TM6010_REQ07_R47_VBI_DATA_TYPE_LINE11, 0x66);
+ tm6000_set_reg(dev, TM6010_REQ07_R48_VBI_DATA_TYPE_LINE12, 0x66);
+ tm6000_set_reg(dev, TM6010_REQ07_R49_VBI_DATA_TYPE_LINE13, 0x66);
+ tm6000_set_reg(dev, TM6010_REQ07_R4A_VBI_DATA_TYPE_LINE14, 0x66);
+ tm6000_set_reg(dev, TM6010_REQ07_R4B_VBI_DATA_TYPE_LINE15, 0x66);
+ tm6000_set_reg(dev, TM6010_REQ07_R4C_VBI_DATA_TYPE_LINE16, 0x66);
+ tm6000_set_reg(dev, TM6010_REQ07_R4D_VBI_DATA_TYPE_LINE17, 0x66);
+ tm6000_set_reg(dev, TM6010_REQ07_R4E_VBI_DATA_TYPE_LINE18, 0x66);
+ tm6000_set_reg(dev, TM6010_REQ07_R4F_VBI_DATA_TYPE_LINE19, 0x66);
+ tm6000_set_reg(dev, TM6010_REQ07_R50_VBI_DATA_TYPE_LINE20, 0x66);
+ tm6000_set_reg(dev, TM6010_REQ07_R51_VBI_DATA_TYPE_LINE21, 0x66);
+ tm6000_set_reg(dev, TM6010_REQ07_R52_VBI_DATA_TYPE_LINE22, 0x66);
+ tm6000_set_reg(dev, TM6010_REQ07_R53_VBI_DATA_TYPE_LINE23, 0x00);
+ tm6000_set_reg(dev, TM6010_REQ07_R54_VBI_DATA_TYPE_RLINES, 0x00);
+ tm6000_set_reg(dev, TM6010_REQ07_R55_VBI_LOOP_FILTER_GAIN, 0x01);
+ tm6000_set_reg(dev, TM6010_REQ07_R56_VBI_LOOP_FILTER_I_GAIN, 0x00);
+ tm6000_set_reg(dev, TM6010_REQ07_R57_VBI_LOOP_FILTER_P_GAIN, 0x02);
+ tm6000_set_reg(dev, TM6010_REQ07_R58_VBI_CAPTION_DTO1, 0x35);
+ tm6000_set_reg(dev, TM6010_REQ07_R59_VBI_CAPTION_DTO0, 0xa0);
+ tm6000_set_reg(dev, TM6010_REQ07_R5A_VBI_TELETEXT_DTO1, 0x11);
+ tm6000_set_reg(dev, TM6010_REQ07_R5B_VBI_TELETEXT_DTO0, 0x4c);
+ tm6000_set_reg(dev, TM6010_REQ07_R40_TELETEXT_VBI_CODE0, 0x01);
+ tm6000_set_reg(dev, TM6010_REQ07_R3F_RESET, 0x00);
+
+
+ /* Init audio */
+ tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x00);
+ tm6000_set_reg(dev, TM6010_REQ08_R02_A_FIX_GAIN_CTRL, 0x04);
+ tm6000_set_reg(dev, TM6010_REQ08_R03_A_AUTO_GAIN_CTRL, 0x00);
+ tm6000_set_reg(dev, TM6010_REQ08_R04_A_SIF_AMP_CTRL, 0xa0);
+ tm6000_set_reg(dev, TM6010_REQ08_R05_A_STANDARD_MOD, 0x05);
+ tm6000_set_reg(dev, TM6010_REQ08_R06_A_SOUND_MOD, 0x06);
+ tm6000_set_reg(dev, TM6010_REQ08_R07_A_LEFT_VOL, 0x00);
+ tm6000_set_reg(dev, TM6010_REQ08_R08_A_RIGHT_VOL, 0x00);
+ tm6000_set_reg(dev, TM6010_REQ08_R09_A_MAIN_VOL, 0x08);
+ tm6000_set_reg(dev, TM6010_REQ08_R0A_A_I2S_MOD, 0x91);
+ tm6000_set_reg(dev, TM6010_REQ08_R0B_A_ASD_THRES1, 0x20);
+ tm6000_set_reg(dev, TM6010_REQ08_R0C_A_ASD_THRES2, 0x12);
+ tm6000_set_reg(dev, TM6010_REQ08_R0D_A_AMD_THRES, 0x20);
+ tm6000_set_reg(dev, TM6010_REQ08_R0E_A_MONO_THRES1, 0xf0);
+ tm6000_set_reg(dev, TM6010_REQ08_R0F_A_MONO_THRES2, 0x80);
+ tm6000_set_reg(dev, TM6010_REQ08_R10_A_MUTE_THRES1, 0xc0);
+ tm6000_set_reg(dev, TM6010_REQ08_R11_A_MUTE_THRES2, 0x80);
+ tm6000_set_reg(dev, TM6010_REQ08_R12_A_AGC_U, 0x12);
+ tm6000_set_reg(dev, TM6010_REQ08_R13_A_AGC_ERR_T, 0xfe);
+ tm6000_set_reg(dev, TM6010_REQ08_R14_A_AGC_GAIN_INIT, 0x20);
+ tm6000_set_reg(dev, TM6010_REQ08_R15_A_AGC_STEP_THR, 0x14);
+ tm6000_set_reg(dev, TM6010_REQ08_R16_A_AGC_GAIN_MAX, 0xfe);
+ tm6000_set_reg(dev,
Re: [PATCH] IR/imon: add proper auto-repeat support
On Wed, Apr 28, 2010 at 01:41:12PM -0700, Dmitry Torokhov wrote: On Wed, Apr 28, 2010 at 01:37:00PM -0400, Jarod Wilson wrote: Set the EV_REP bit, so reported key repeats actually make their way out to userspace, and fix up the handling of repeats a bit, routines for which are shamelessly heisted from ati_remote2.c. Is it really needed? I'd expect input core handling auto-repeating for you as long as you set EV_REP flag. In my own (albeit brief) testing, the heisted bits don't make a significant difference, but I had a user say that it helped a bit at suppressing what he perceived as extraneous repeats being passed through. In reality, setting a slightly higher rep delay or rep period might be the better answer here. Actually, I think I know exactly what was happening for said user. He's using a device that only supports mce mode, where these devices don't have a release code, they're timer-based, I think the repeat timeout of 200ms was triggering an auto-repeat every 33ms for 200ms, thus giving the appearance of way more repeats than the hardware actually sent. Okay, lemme rework this patch a bit, I think I can drop all that heisted crud, and simply bumping the release timer in mce mode by rep period ms instead of 200ms for repeats should be sufficient. Need to get my imon device that supports both imon and mce proto back into a state where I can use it for testing... -- Jarod Wilson ja...@redhat.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 0/2] UVC gadget driver
Hi everybody, Here's a new version of the UVC gadget driver I posted on the list some time ago, rebased on 2.6.34-rc5. The private events API has been replaced by the new V4L2 events API that will be available in 2.6.34 (the code is already available in the v4l-dvb tree on linuxtv.org, and should be pushed to git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-next.git very soon). Further testing of the changes related to the events API is required (this is planned for the next few days). As it seems to be the UVC gadget driver season (Robert Lukassen posted his own implementation - having a different goal - two days ago), I thought I'd post the patch as an RFC. I'd like the UVC function driver to make it to 2.6.35, comments are more than welcome. Laurent Pinchart (2): USB gadget: video class function driver USB gadget: Webcam device drivers/usb/gadget/Kconfig |9 +- drivers/usb/gadget/Makefile|2 + drivers/usb/gadget/f_uvc.c | 661 drivers/usb/gadget/f_uvc.h | 376 +++ drivers/usb/gadget/uvc.h | 242 +++ drivers/usb/gadget/uvc_queue.c | 583 +++ drivers/usb/gadget/uvc_queue.h | 89 ++ drivers/usb/gadget/uvc_v4l2.c | 374 +++ drivers/usb/gadget/uvc_video.c | 386 +++ drivers/usb/gadget/webcam.c| 399 10 files changed, 3120 insertions(+), 1 deletions(-) create mode 100644 drivers/usb/gadget/f_uvc.c create mode 100644 drivers/usb/gadget/f_uvc.h create mode 100644 drivers/usb/gadget/uvc.h create mode 100644 drivers/usb/gadget/uvc_queue.c create mode 100644 drivers/usb/gadget/uvc_queue.h create mode 100644 drivers/usb/gadget/uvc_v4l2.c create mode 100644 drivers/usb/gadget/uvc_video.c create mode 100644 drivers/usb/gadget/webcam.c -- 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
[RFC 2/2] USB gadget: Webcam device
This webcam gadget instantiates a UVC camera (360p and 720p resolutions
in YUYV and MJPEG).
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/usb/gadget/Kconfig |9 +-
drivers/usb/gadget/Makefile |2 +
drivers/usb/gadget/webcam.c | 399 +++
3 files changed, 409 insertions(+), 1 deletions(-)
create mode 100644 drivers/usb/gadget/webcam.c
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 11a3e0f..f7da73e 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -866,8 +866,16 @@ config USB_G_MULTI_CDC
# put drivers that need isochronous transfer support (for audio
# or video class gadget drivers), or specific hardware, here.
+config USB_G_WEBCAM
+ tristate USB Webcam Gadget
+ help
+ The Webcam Gadget acts as a USB Video Class device. It
+ provides a userspace API to process UVC control requests and
+ stream video data to the host.
-# - none yet
+ Say y to link the driver statically, or m to build a
+ dynamically linked module called g_webcam.
endchoice
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 43b51da..4dcdc7b 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -44,6 +44,7 @@ g_printer-objs:= printer.o
g_cdc-objs := cdc2.o
g_multi-objs := multi.o
g_nokia-objs := nokia.o
+g_webcam-objs := webcam.o
obj-$(CONFIG_USB_ZERO) += g_zero.o
obj-$(CONFIG_USB_AUDIO)+= g_audio.o
@@ -57,4 +58,5 @@ obj-$(CONFIG_USB_MIDI_GADGET) += g_midi.o
obj-$(CONFIG_USB_CDC_COMPOSITE) += g_cdc.o
obj-$(CONFIG_USB_G_MULTI) += g_multi.o
obj-$(CONFIG_USB_G_NOKIA) += g_nokia.o
+obj-$(CONFIG_USB_G_WEBCAM) += g_webcam.o
diff --git a/drivers/usb/gadget/webcam.c b/drivers/usb/gadget/webcam.c
new file mode 100644
index 000..417fd68
--- /dev/null
+++ b/drivers/usb/gadget/webcam.c
@@ -0,0 +1,399 @@
+/*
+ * webcam.c -- USB webcam gadget driver
+ *
+ * Copyright (C) 2009-2010
+ * Laurent Pinchart (laurent.pinch...@ideasonboard.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+#include linux/kernel.h
+#include linux/device.h
+#include linux/usb/video.h
+
+#include f_uvc.h
+
+/*
+ * Kbuild is not very cooperative with respect to linking separately
+ * compiled library objects into one module. So for now we won't use
+ * separate compilation ... ensuring init/exit sections work to shrink
+ * the runtime footprint, and giving us at least some parts of what
+ * a gcc --combine ... part1.c part2.c part3.c ... build would.
+ */
+#include composite.c
+#include usbstring.c
+#include config.c
+#include epautoconf.c
+
+#include f_uvc.c
+#include uvc_queue.c
+#include uvc_v4l2.c
+#include uvc_video.c
+
+/* --
+ * Device descriptor
+ */
+
+#define WEBCAM_VENDOR_ID 0x1d6b /* Linux Foundation */
+#define WEBCAM_PRODUCT_ID 0x0102 /* Webcam A/V gadget */
+#define WEBCAM_DEVICE_BCD 0x0010 /* 0.10 */
+
+static char webcam_vendor_label[] = Linux Foundation;
+static char webcam_product_label[] = Webcam gadget;
+static char webcam_config_label[] = Video;
+
+/* string IDs are assigned dynamically */
+
+#define STRING_MANUFACTURER_IDX0
+#define STRING_PRODUCT_IDX 1
+#define STRING_DESCRIPTION_IDX 2
+
+static struct usb_string webcam_strings[] = {
+ [STRING_MANUFACTURER_IDX].s = webcam_vendor_label,
+ [STRING_PRODUCT_IDX].s = webcam_product_label,
+ [STRING_DESCRIPTION_IDX].s = webcam_config_label,
+ { }
+};
+
+static struct usb_gadget_strings webcam_stringtab = {
+ .language = 0x0409, /* en-us */
+ .strings = webcam_strings,
+};
+
+static struct usb_gadget_strings *webcam_device_strings[] = {
+ webcam_stringtab,
+ NULL,
+};
+
+static struct usb_device_descriptor webcam_device_descriptor = {
+ .bLength= USB_DT_DEVICE_SIZE,
+ .bDescriptorType= USB_DT_DEVICE,
+ .bcdUSB = cpu_to_le16(0x0200),
+ .bDeviceClass = USB_CLASS_MISC,
+ .bDeviceSubClass= 0x02,
+ .bDeviceProtocol= 0x01,
+ .bMaxPacketSize0= 0, /* dynamic */
+ .idVendor = cpu_to_le16(WEBCAM_VENDOR_ID),
+ .idProduct = cpu_to_le16(WEBCAM_PRODUCT_ID),
+ .bcdDevice = cpu_to_le16(WEBCAM_DEVICE_BCD),
+ .iManufacturer = 0, /* dynamic */
+ .iProduct = 0, /* dynamic */
+
Re: [RFC 0/2] UVC gadget driver
On Thu, Apr 29, 2010 at 12:52:57AM +0200, Laurent Pinchart wrote: Hi everybody, Here's a new version of the UVC gadget driver I posted on the list some time ago, rebased on 2.6.34-rc5. The private events API has been replaced by the new V4L2 events API that will be available in 2.6.34 (the code is already available in the v4l-dvb tree on linuxtv.org, and should be pushed to git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-next.git very soon). Further testing of the changes related to the events API is required (this is planned for the next few days). As it seems to be the UVC gadget driver season (Robert Lukassen posted his own implementation - having a different goal - two days ago) What are the different goals here? Shouldn't there just be only one way to implement this, or am I missing something? , I thought I'd post the patch as an RFC. I'd like the UVC function driver to make it to 2.6.35, comments are more than welcome. It needs to get into my tree _now_ if you are wanting it in .35 Just fyi. thanks, greg k-h -- 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/5] Pushdown bkl from v4l ioctls
Hi, Linus suggested to rename struct v4l2_file_operations::ioctl into bkl_ioctl to eventually get something greppable and make its background explicit. While at it I thought it could be a good idea to just pushdown the bkl to every v4l drivers that have an .ioctl, so that we actually remove struct v4l2_file_operations::ioctl for good. It passed make allyesconfig on sparc. Please tell me what you think. Thanks. Frederic Weisbecker (5): v4l: Pushdown bkl into video_ioctl2 v4l: Use video_ioctl2_unlocked from drivers that don't want the bkl v4l: Change users of video_ioctl2 to use unlocked_ioctl v4l: Pushdown bkl to drivers that implement their own ioctl v4l: Remove struct v4l2_file_operations::ioctl drivers/media/common/saa7146_fops.c |2 +- drivers/media/radio/dsbr100.c|2 +- drivers/media/radio/radio-aimslab.c |2 +- drivers/media/radio/radio-aztech.c |2 +- drivers/media/radio/radio-cadet.c|2 +- drivers/media/radio/radio-gemtek-pci.c |2 +- drivers/media/radio/radio-gemtek.c |2 +- drivers/media/radio/radio-maestro.c |2 +- drivers/media/radio/radio-maxiradio.c|2 +- drivers/media/radio/radio-miropcm20.c|2 +- drivers/media/radio/radio-mr800.c|2 +- drivers/media/radio/radio-rtrack2.c |2 +- drivers/media/radio/radio-sf16fmi.c |2 +- drivers/media/radio/radio-sf16fmr2.c |2 +- drivers/media/radio/radio-si4713.c |2 +- drivers/media/radio/radio-tea5764.c |2 +- drivers/media/radio/radio-terratec.c |2 +- drivers/media/radio/radio-timb.c |2 +- drivers/media/radio/radio-trust.c|2 +- drivers/media/radio/radio-typhoon.c |2 +- drivers/media/radio/radio-zoltrix.c |2 +- drivers/media/radio/si470x/radio-si470x-common.c |2 +- drivers/media/video/arv.c|2 +- drivers/media/video/au0828/au0828-video.c| 14 drivers/media/video/bt8xx/bttv-driver.c | 26 +++--- drivers/media/video/bw-qcam.c| 11 +- drivers/media/video/c-qcam.c | 11 +- drivers/media/video/cafe_ccic.c | 14 drivers/media/video/cpia.c | 11 +- drivers/media/video/cpia2/cpia2_v4l.c| 11 +- drivers/media/video/cx18/cx18-streams.c | 12 +++--- drivers/media/video/cx231xx/cx231xx-video.c |4 +- drivers/media/video/cx23885/cx23885-417.c|2 +- drivers/media/video/cx23885/cx23885-video.c |4 +- drivers/media/video/cx88/cx88-blackbird.c|2 +- drivers/media/video/cx88/cx88-video.c|4 +- drivers/media/video/davinci/vpfe_capture.c |2 +- drivers/media/video/davinci/vpif_capture.c |2 +- drivers/media/video/davinci/vpif_display.c |2 +- drivers/media/video/em28xx/em28xx-video.c|4 +- drivers/media/video/et61x251/et61x251_core.c | 27 +++ drivers/media/video/gspca/gspca.c|2 +- drivers/media/video/hdpvr/hdpvr-video.c |2 +- drivers/media/video/meye.c |2 +- drivers/media/video/omap24xxcam.c| 10 +++--- drivers/media/video/ov511.c | 15 +--- drivers/media/video/pms.c|2 +- drivers/media/video/pvrusb2/pvrusb2-v4l2.c | 20 +++ drivers/media/video/pwc/pwc-if.c | 19 ++ drivers/media/video/s2255drv.c | 12 +++--- drivers/media/video/saa5246a.c | 11 -- drivers/media/video/saa5249.c|6 +++- drivers/media/video/saa7134/saa7134-empress.c| 14 drivers/media/video/saa7134/saa7134-video.c | 26 +++--- drivers/media/video/se401.c | 20 +++ drivers/media/video/sn9c102/sn9c102_core.c | 27 +++ drivers/media/video/soc_camera.c |2 +- drivers/media/video/stk-webcam.c | 14 drivers/media/video/stradis.c| 26 +++ drivers/media/video/stv680.c | 20 +++ drivers/media/video/tlg2300/pd-radio.c |8 ++-- drivers/media/video/tlg2300/pd-video.c |2 +- drivers/media/video/usbvideo/usbvideo.c | 21 drivers/media/video/usbvideo/vicam.c | 14 +++- drivers/media/video/usbvision/usbvision-video.c |4 +- drivers/media/video/uvc/uvc_v4l2.c | 11 +- drivers/media/video/v4l2-dev.c | 38 ++--- drivers/media/video/v4l2-ioctl.c
[PATCH 1/5] v4l: Pushdown bkl into video_ioctl2
video_ioctl2 is a generic ioctl helper used by a lot of drivers.
Most of them put it as their bkl'ed .ioctl callback, then let's
pushdown the bkl inside but also provide an unlocked version for
those that use it as an unlocked ioctl.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
---
drivers/media/video/v4l2-ioctl.c | 17 +++--
include/media/v4l2-ioctl.h |2 ++
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 3da8d8f..0ff2595 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -16,6 +16,7 @@
#include linux/slab.h
#include linux/types.h
#include linux/kernel.h
+#include linux/smp_lock.h
#define __OLD_VIDIOC_ /* To allow fixing old calls */
#include linux/videodev.h
@@ -2007,8 +2008,8 @@ static unsigned long cmd_input_size(unsigned int cmd)
}
}
-long video_ioctl2(struct file *file,
- unsigned int cmd, unsigned long arg)
+long video_ioctl2_unlocked(struct file *file,
+ unsigned int cmd, unsigned long arg)
{
charsbuf[128];
void*mbuf = NULL;
@@ -2102,4 +2103,16 @@ out:
kfree(mbuf);
return err;
}
+EXPORT_SYMBOL(video_ioctl2_unlocked);
+
+long video_ioctl2(struct file *file, unsigned int cmd, unsigned long arg)
+{
+ long ret;
+
+ lock_kernel();
+ ret = video_ioctl2_unlocked(file, cmd, arg);
+ unlock_kernel();
+
+ return ret;
+}
EXPORT_SYMBOL(video_ioctl2);
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index e8ba0f2..08b3e42 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -316,5 +316,7 @@ extern long video_usercopy(struct file *file, unsigned int
cmd,
/* Standard handlers for V4L ioctl's */
extern long video_ioctl2(struct file *file,
unsigned int cmd, unsigned long arg);
+extern long video_ioctl2_unlocked(struct file *file,
+ unsigned int cmd, unsigned long arg);
#endif /* _V4L2_IOCTL_H */
--
1.6.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] v4l: Change users of video_ioctl2 to use unlocked_ioctl
Now that video_ioctl2() got the bkl pushed down, update its users
to use .unlocked_ioctl instead of ioctl.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
---
drivers/media/common/saa7146_fops.c |2 +-
drivers/media/radio/dsbr100.c|2 +-
drivers/media/radio/radio-aimslab.c |2 +-
drivers/media/radio/radio-aztech.c |2 +-
drivers/media/radio/radio-cadet.c|2 +-
drivers/media/radio/radio-gemtek-pci.c |2 +-
drivers/media/radio/radio-gemtek.c |2 +-
drivers/media/radio/radio-maestro.c |2 +-
drivers/media/radio/radio-maxiradio.c|2 +-
drivers/media/radio/radio-miropcm20.c|2 +-
drivers/media/radio/radio-mr800.c|2 +-
drivers/media/radio/radio-rtrack2.c |2 +-
drivers/media/radio/radio-sf16fmi.c |2 +-
drivers/media/radio/radio-sf16fmr2.c |2 +-
drivers/media/radio/radio-si4713.c |2 +-
drivers/media/radio/radio-tea5764.c |2 +-
drivers/media/radio/radio-terratec.c |2 +-
drivers/media/radio/radio-timb.c |2 +-
drivers/media/radio/radio-trust.c|2 +-
drivers/media/radio/radio-typhoon.c |2 +-
drivers/media/radio/radio-zoltrix.c |2 +-
drivers/media/radio/si470x/radio-si470x-common.c |2 +-
drivers/media/video/arv.c|2 +-
drivers/media/video/au0828/au0828-video.c| 14 ++--
drivers/media/video/bt8xx/bttv-driver.c | 26 +++---
drivers/media/video/cafe_ccic.c | 14 ++--
drivers/media/video/cx18/cx18-streams.c | 12 +-
drivers/media/video/cx231xx/cx231xx-video.c |4 +-
drivers/media/video/cx23885/cx23885-417.c|2 +-
drivers/media/video/cx23885/cx23885-video.c |4 +-
drivers/media/video/cx88/cx88-blackbird.c|2 +-
drivers/media/video/cx88/cx88-video.c|4 +-
drivers/media/video/davinci/vpif_capture.c |2 +-
drivers/media/video/davinci/vpif_display.c |2 +-
drivers/media/video/em28xx/em28xx-video.c|4 +-
drivers/media/video/meye.c |2 +-
drivers/media/video/omap24xxcam.c| 10
drivers/media/video/pms.c|2 +-
drivers/media/video/s2255drv.c | 12 +-
drivers/media/video/saa7134/saa7134-empress.c| 14 ++--
drivers/media/video/saa7134/saa7134-video.c | 26 +++---
drivers/media/video/soc_camera.c |2 +-
drivers/media/video/stk-webcam.c | 14 ++--
drivers/media/video/tlg2300/pd-radio.c |8 +++---
drivers/media/video/tlg2300/pd-video.c |2 +-
drivers/media/video/usbvision/usbvision-video.c |4 +-
drivers/media/video/w9966.c |2 +-
drivers/media/video/zoran/zoran_driver.c | 16 ++--
drivers/media/video/zr364xx.c| 14 ++--
drivers/staging/cx25821/cx25821-video0.c | 14 ++--
drivers/staging/cx25821/cx25821-video1.c | 14 ++--
drivers/staging/cx25821/cx25821-video2.c | 14 ++--
drivers/staging/cx25821/cx25821-video3.c | 14 ++--
drivers/staging/cx25821/cx25821-video4.c | 14 ++--
drivers/staging/cx25821/cx25821-video5.c | 14 ++--
drivers/staging/cx25821/cx25821-video6.c | 14 ++--
drivers/staging/cx25821/cx25821-video7.c | 14 ++--
drivers/staging/go7007/go7007-v4l2.c |2 +-
drivers/staging/tm6000/tm6000-video.c|2 +-
sound/i2c/other/tea575x-tuner.c |2 +-
60 files changed, 191 insertions(+), 191 deletions(-)
diff --git a/drivers/media/common/saa7146_fops.c
b/drivers/media/common/saa7146_fops.c
index fd8e1f4..2e76112 100644
--- a/drivers/media/common/saa7146_fops.c
+++ b/drivers/media/common/saa7146_fops.c
@@ -396,7 +396,7 @@ static const struct v4l2_file_operations video_fops =
.write = fops_write,
.poll = fops_poll,
.mmap = fops_mmap,
- .ioctl = video_ioctl2,
+ .unlocked_ioctl = video_ioctl2,
};
static void vv_callback(struct saa7146_dev *dev, unsigned long status)
diff --git a/drivers/media/radio/dsbr100.c b/drivers/media/radio/dsbr100.c
index ed9cd7a..c3e952f 100644
--- a/drivers/media/radio/dsbr100.c
+++ b/drivers/media/radio/dsbr100.c
@@ -605,7 +605,7 @@ static void usb_dsbr100_video_device_release(struct
video_device *videodev)
/* File system interface */
static const struct v4l2_file_operations usb_dsbr100_fops = {
.owner = THIS_MODULE,
- .ioctl
[PATCH 4/5] v4l: Pushdown bkl to drivers that implement their own ioctl
These are the last remaining v4l drivers that implement the ioctl
callback.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
---
drivers/media/video/bw-qcam.c| 11 -
drivers/media/video/c-qcam.c | 11 -
drivers/media/video/cpia.c | 11 -
drivers/media/video/cpia2/cpia2_v4l.c| 11 -
drivers/media/video/et61x251/et61x251_core.c | 27 +++--
drivers/media/video/ov511.c | 15 -
drivers/media/video/pvrusb2/pvrusb2-v4l2.c | 20 --
drivers/media/video/pwc/pwc-if.c | 19 ++---
drivers/media/video/saa5246a.c | 11 ++---
drivers/media/video/saa5249.c|6 -
drivers/media/video/se401.c | 20 --
drivers/media/video/sn9c102/sn9c102_core.c | 27 +++--
drivers/media/video/stradis.c| 26 ++--
drivers/media/video/stv680.c | 20 --
drivers/media/video/usbvideo/usbvideo.c | 21 +--
drivers/media/video/usbvideo/vicam.c | 14 -
drivers/media/video/uvc/uvc_v4l2.c | 11 -
drivers/media/video/vivi.c |2 +-
drivers/media/video/w9968cf.c| 25 ++-
drivers/media/video/zc0301/zc0301_core.c | 27 +++--
drivers/staging/cx25821/cx25821-audups11.c | 18 ++--
drivers/staging/cx25821/cx25821-videoioctl.c | 27 +++--
drivers/staging/cx25821/cx25821-vidups10.c | 19 +++--
drivers/staging/cx25821/cx25821-vidups9.c| 18 ++--
drivers/staging/dream/camera/msm_v4l2.c | 27 ++---
25 files changed, 315 insertions(+), 129 deletions(-)
diff --git a/drivers/media/video/bw-qcam.c b/drivers/media/video/bw-qcam.c
index 3c9e754..11367b0 100644
--- a/drivers/media/video/bw-qcam.c
+++ b/drivers/media/video/bw-qcam.c
@@ -76,6 +76,7 @@ OTHER DEALINGS IN THE SOFTWARE.
#include media/v4l2-common.h
#include media/v4l2-ioctl.h
#include linux/mutex.h
+#include linux/smp_lock.h
#include asm/uaccess.h
#include bw-qcam.h
@@ -831,7 +832,13 @@ static long qcam_do_ioctl(struct file *file, unsigned int
cmd, void *arg)
static long qcam_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
{
- return video_usercopy(file, cmd, arg, qcam_do_ioctl);
+ long ret;
+
+ lock_kernel();
+ ret = video_usercopy(file, cmd, arg, qcam_do_ioctl);
+ unlock_kernel();
+
+ return ret;
}
static ssize_t qcam_read(struct file *file, char __user *buf,
@@ -879,7 +886,7 @@ static const struct v4l2_file_operations qcam_fops = {
.owner = THIS_MODULE,
.open = qcam_exclusive_open,
.release= qcam_exclusive_release,
- .ioctl = qcam_ioctl,
+ .unlocked_ioctl = qcam_ioctl,
.read = qcam_read,
};
static struct video_device qcam_template = {
diff --git a/drivers/media/video/c-qcam.c b/drivers/media/video/c-qcam.c
index 8f1dd88..0eb42fd 100644
--- a/drivers/media/video/c-qcam.c
+++ b/drivers/media/video/c-qcam.c
@@ -38,6 +38,7 @@
#include media/v4l2-ioctl.h
#include linux/mutex.h
#include linux/jiffies.h
+#include linux/smp_lock.h
#include asm/uaccess.h
@@ -663,7 +664,13 @@ static long qcam_do_ioctl(struct file *file, unsigned int
cmd, void *arg)
static long qcam_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
{
- return video_usercopy(file, cmd, arg, qcam_do_ioctl);
+ long ret;
+
+ lock_kernel();
+ ret = video_usercopy(file, cmd, arg, qcam_do_ioctl);
+ unlock_kernel();
+
+ return ret;
}
static ssize_t qcam_read(struct file *file, char __user *buf,
@@ -704,7 +711,7 @@ static const struct v4l2_file_operations qcam_fops = {
.owner = THIS_MODULE,
.open = qcam_exclusive_open,
.release= qcam_exclusive_release,
- .ioctl = qcam_ioctl,
+ .unlocked_ioctl = qcam_ioctl,
.read = qcam_read,
};
diff --git a/drivers/media/video/cpia.c b/drivers/media/video/cpia.c
index 933ae4c..f3f08cc 100644
--- a/drivers/media/video/cpia.c
+++ b/drivers/media/video/cpia.c
@@ -38,6 +38,7 @@
#include linux/ctype.h
#include linux/pagemap.h
#include linux/delay.h
+#include linux/smp_lock.h
#include asm/io.h
#include linux/mutex.h
@@ -3715,7 +3716,13 @@ static long cpia_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
static long cpia_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
{
- return video_usercopy(file, cmd, arg, cpia_do_ioctl);
+ long ret;
+
+ lock_kernel();
+ ret = video_usercopy(file, cmd, arg,
[PATCH 2/5] v4l: Use video_ioctl2_unlocked from drivers that don't want the bkl
There are three drivers that use video_ioctl2() as an unlocked_ioctl,
let them use the new video_ioctl2_unlocked.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
---
drivers/media/video/davinci/vpfe_capture.c |2 +-
drivers/media/video/gspca/gspca.c |2 +-
drivers/media/video/hdpvr/hdpvr-video.c|2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index aa1411f..61a3514 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -786,7 +786,7 @@ static const struct v4l2_file_operations vpfe_fops = {
.owner = THIS_MODULE,
.open = vpfe_open,
.release = vpfe_release,
- .unlocked_ioctl = video_ioctl2,
+ .unlocked_ioctl = video_ioctl2_unlocked,
.mmap = vpfe_mmap,
.poll = vpfe_poll
};
diff --git a/drivers/media/video/gspca/gspca.c
b/drivers/media/video/gspca/gspca.c
index 68a8431..a424c1d 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -2184,7 +2184,7 @@ static struct v4l2_file_operations dev_fops = {
.release = dev_close,
.read = dev_read,
.mmap = dev_mmap,
- .unlocked_ioctl = video_ioctl2,
+ .unlocked_ioctl = video_ioctl2_unlocked,
.poll = dev_poll,
};
diff --git a/drivers/media/video/hdpvr/hdpvr-video.c
b/drivers/media/video/hdpvr/hdpvr-video.c
index 196f82d..01b8a34 100644
--- a/drivers/media/video/hdpvr/hdpvr-video.c
+++ b/drivers/media/video/hdpvr/hdpvr-video.c
@@ -559,7 +559,7 @@ static const struct v4l2_file_operations hdpvr_fops = {
.release= hdpvr_release,
.read = hdpvr_read,
.poll = hdpvr_poll,
- .unlocked_ioctl = video_ioctl2,
+ .unlocked_ioctl = video_ioctl2_unlocked,
};
/*===*/
--
1.6.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
