Re: [PATCH] libv4l: add support for RGB565 format
Hi,
Thanks for the patch I've applied it to my tree, and it will be in the
to be released soon libv4l-0.6.0 release.
Regards,
Hans
On 07/03/2009 04:19 AM, Mauro Carvalho Chehab wrote:
Currently, em28xx driver outputs webcams only at RGB565 format. However,
several webcam applications don't support this format.
In order to properly work with those applications, a RGB565 handler should be
added at libv4l.
Tested with Silvercrest 1.3 mpix with v4l2grab (V4L2, with native libv4l
support) and two LD_PRELOAD applications: camorama (V4L1 API) and skype (using
compat32).
Signed-off-by: Mauro Carvalho Chehabmche...@redhat.com
diff --git a/v4l2-apps/libv4l/libv4lconvert/libv4lconvert-priv.h
b/v4l2-apps/libv4l/libv4lconvert/libv4lconvert-priv.h
--- a/v4l2-apps/libv4l/libv4lconvert/libv4lconvert-priv.h
+++ b/v4l2-apps/libv4l/libv4lconvert/libv4lconvert-priv.h
@@ -184,6 +184,15 @@ void v4lconvert_swap_rgb(const unsigned
void v4lconvert_swap_uv(const unsigned char *src, unsigned char *dst,
const struct v4l2_format *src_fmt);
+void v4lconvert_rgb565_to_rgb24(const unsigned char *src, unsigned char *dest,
+ int width, int height);
+
+void v4lconvert_rgb565_to_bgr24(const unsigned char *src, unsigned char *dest,
+ int width, int height);
+
+void v4lconvert_rgb565_to_yuv420(const unsigned char *src, unsigned char *dest,
+ const struct v4l2_format *src_fmt, int yvu);
+
void v4lconvert_spca501_to_yuv420(const unsigned char *src, unsigned char
*dst,
int width, int height, int yvu);
diff --git a/v4l2-apps/libv4l/libv4lconvert/libv4lconvert.c
b/v4l2-apps/libv4l/libv4lconvert/libv4lconvert.c
--- a/v4l2-apps/libv4l/libv4lconvert/libv4lconvert.c
+++ b/v4l2-apps/libv4l/libv4lconvert/libv4lconvert.c
@@ -46,6 +46,7 @@ static const struct v4lconvert_pixfmt su
{ V4L2_PIX_FMT_YUYV, 0 },
{ V4L2_PIX_FMT_YVYU, 0 },
{ V4L2_PIX_FMT_UYVY, 0 },
+ { V4L2_PIX_FMT_RGB565, 0 },
{ V4L2_PIX_FMT_SN9C20X_I420, V4LCONVERT_NEEDS_CONVERSION },
{ V4L2_PIX_FMT_SBGGR8, V4LCONVERT_NEEDS_CONVERSION },
{ V4L2_PIX_FMT_SGBRG8, V4LCONVERT_NEEDS_CONVERSION },
@@ -787,6 +788,23 @@ static int v4lconvert_convert_pixfmt(str
}
break;
+case V4L2_PIX_FMT_RGB565:
+ switch (dest_pix_fmt) {
+ case V4L2_PIX_FMT_RGB24:
+ v4lconvert_rgb565_to_rgb24(src, dest, width, height);
+ break;
+ case V4L2_PIX_FMT_BGR24:
+ v4lconvert_rgb565_to_bgr24(src, dest, width, height);
+ break;
+ case V4L2_PIX_FMT_YUV420:
+ v4lconvert_rgb565_to_yuv420(src, dest, fmt, 0);
+ break;
+ case V4L2_PIX_FMT_YVU420:
+ v4lconvert_rgb565_to_yuv420(src, dest, fmt, 1);
+ break;
+ }
+ break;
+
case V4L2_PIX_FMT_RGB24:
switch (dest_pix_fmt) {
case V4L2_PIX_FMT_BGR24:
diff --git a/v4l2-apps/libv4l/libv4lconvert/rgbyuv.c
b/v4l2-apps/libv4l/libv4lconvert/rgbyuv.c
--- a/v4l2-apps/libv4l/libv4lconvert/rgbyuv.c
+++ b/v4l2-apps/libv4l/libv4lconvert/rgbyuv.c
@@ -1,8 +1,10 @@
/*
# RGB- YUV conversion routines
+# (C) 2008 Hans de Goedej.w.r.dego...@hhs.nl
-# (C) 2008 Hans de Goedej.w.r.dego...@hhs.nl
+# RGB565 conversion routines
+# (C) 2009 Mauro Carvalho Chehabmche...@redhat.com
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
@@ -472,3 +474,103 @@ void v4lconvert_swap_uv(const unsigned c
src += src_fmt-fmt.pix.bytesperline / 2;
}
}
+
+void v4lconvert_rgb565_to_rgb24(const unsigned char *src, unsigned char *dest,
+ int width, int height)
+{
+ int j;
+ while (--height= 0) {
+for (j = 0; j width; j++) {
+ unsigned short tmp = *(unsigned short *)src;
+
+ /* Original format: rggg gggb */
+ *dest++ = 0xf8 (tmp 8);
+ *dest++ = 0xfc (tmp 3);
+ *dest++ = 0xf8 (tmp 3);
+
+ src += 2;
+}
+ }
+}
+
+void v4lconvert_rgb565_to_bgr24(const unsigned char *src, unsigned char *dest,
+ int width, int height)
+{
+ int j;
+ while (--height= 0) {
+for (j = 0; j width; j++) {
+ unsigned short tmp = *(unsigned short *)src;
+
+ /* Original format: rggg gggb */
+ *dest++ = 0xf8 (tmp 3);
+ *dest++ = 0xfc (tmp 3);
+ *dest++ = 0xf8 (tmp 8);
+
+ src += 2;
+}
+ }
+}
+
+void v4lconvert_rgb565_to_yuv420(const unsigned char *src, unsigned char *dest,
+ const struct v4l2_format *src_fmt, int yvu)
+{
+ int x, y;
+ unsigned short tmp;
+ unsigned char *udest, *vdest;
+ unsigned r[4], g[4], b[4];
+ int avg_src[3];
+
+ /* Y */
+ for (y = 0; y src_fmt-fmt.pix.height; y++) {
+for (x = 0; x src_fmt-fmt.pix.width; x++) {
+ tmp = *(unsigned short *)src;
+ r[0] = 0xf8 (tmp 3);
+ g[0] = 0xfc (tmp 3);
+ b[0] = 0xf8 (tmp 8);
+ RGB2Y(r[0], g[0], b[0], *dest++);
+ src += 2;
+}
+src += src_fmt-fmt.pix.bytesperline - 2 *
Re: [PATCH 1/11 - v3] vpfe capture bridge driver for DM355 and DM6446
On Thursday 02 July 2009 22:32:38 m-kariche...@ti.com wrote:
From: Muralidharan Karicheri m-kariche...@ti.com
Re-sending to add description (and also experimental status) for
VPFE_CMD_S_CCDC_RAW_PARAMS and updating debug prints with \n and
fixing an error coder ENOMEM
VPFE Capture bridge driver
This is version, v3 of vpfe capture bridge driver for doing video
capture on DM355 and DM6446 evms. The ccdc hw modules register with the
driver and are used for configuring the CCD Controller for a specific
decoder interface. The driver also registers the sub devices required
for a specific evm. More than one sub devices can be registered.
This allows driver to switch dynamically to capture video from
any sub device that is registered. Currently only one sub device
(tvp5146) is supported. But in future this driver is expected
to do capture from sensor devices such as Micron's MT9T001,MT9T031
and MT9P031 etc. The driver currently supports MMAP based IO.
Following are the updates based on review comments:-
1) clean up of setting bus parameters in ccdc
2) removed v4l2_routing structure type
3) module authors, description changes
4) pixel aspect constants removed
Reviewed by: Hans Verkuil hverk...@xs4all.nl
Reviewed by: Laurent Pinchart laurent.pinch...@skynet.be
Reviewed by: Alexey Klimov klimov.li...@gmail.com
Reviewed by: Mauro Carvalho Chehab mche...@infradead.org
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
drivers/media/video/davinci/vpfe_capture.c | 2138
include/media/davinci/vpfe_capture.h | 195 +++
include/media/davinci/vpfe_types.h | 51 +
3 files changed, 2384 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpfe_capture.c
create mode 100644 include/media/davinci/vpfe_capture.h
create mode 100644 include/media/davinci/vpfe_types.h
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
new file mode 100644
index 000..600da0d
--- /dev/null
+++ b/drivers/media/video/davinci/vpfe_capture.c
snip
+/*
+ * vpfe_probe : This function creates device entries by register
+ * itself to the V4L2 driver and initializes fields of each
+ * device objects
+ */
+static __init int vpfe_probe(struct platform_device *pdev)
+{
+ struct vpfe_config *vpfe_cfg;
+ struct resource *res1;
+ struct vpfe_device *vpfe_dev;
+ struct i2c_adapter *i2c_adap;
+ struct i2c_client *client;
+ struct video_device *vfd;
+ int ret = -ENOMEM, i, j;
+ int num_subdevs = 0;
snip
+
+ for (i = 0; i num_subdevs; i++) {
+ struct vpfe_subdev_info *sdinfo = vpfe_cfg-sub_devs[i];
+ struct v4l2_input *inps;
+
+ list_for_each_entry(client, i2c_adap-clients, list) {
+ if (!strcmp(client-name, sdinfo-name))
+ break;
+ }
This no longer compiles :-(
The latest linux git tree no longer has the i2c_adap-clients field, nor is
there a 'list' field in struct i2c_client.
The initialization of the subdevs should be done in a similar way as
vpif_probe does it in vpif_display.c (see my v4l-dvb-dm646x tree).
Using i2c core internals as is being done here is a really bad idea.
Of course, when this was written originally the v4l2_i2c_new_subdev_board()
function didn't exist yet, and you need that one in order to implement this
properly.
I've made a new v4l-dvb-vpfe-cap tree with your latest changes, but it is
obviously impossible to merge at the moment and fixing this problem is, I
suspect, a non-trivial change.
I see three options:
1) You manage to come up with a proper fix very quickly,
2) We postpone everything until the next merge window,
3) We only merge the tvp514x patches (not sure whether this is a useful
alternative or not).
Mauro, the v4l-dvb-dm646x tree for which I posted a pull request a week ago
compiles fine against the latest linux-git tree, so it shouldn't be a problem
(I hope :-) ) to merge that one for 2.6.31.
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: Call for testers: Terratec Cinergy T XS USB support
Hi all, On Mon, Jun 29, 2009 at 4:00 PM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: Hello all, A few weeks ago, I did some work on support for the Terratec Cinergy T XS USB product. I successfully got the zl10353 version working and issued a PULL request last week (http://www.kernellabs.com/hg/~dheitmueller/em28xx-terratec-zl10353) There will be an alternative driver entirely in userspace available which works across all major kernelversions and distributions. It will support the old em28xx devices and handle audio routing for the most popular TV applications directly. This system makes compiling the drivers unnecessary across all available linux systems between 2.6.15 and ongoing. This package also allows commercial drivers from vendors, the API itself is almost the same as the video4linux/linuxdvb API. Installing a driver takes less than five seconds without having to take care about the kernel API or having to set up a development system. Aside of that it's operating system independent (working on Linux, MacOSX and FreeBSD). I think this is the way to go for the future since it adds more possibilities to the drivers, and it eases up and speeds up driver development dramatically. Best Regards, Markus However, the other version of the product, which contains a mt352 is not yet working. I am looking for people who own the device and would be willing to do testing of a tree to help debug the issue. Ideal candidates should have the experience using DVB devices under Linux in addition to some other known-working tuner product so we can be sure that certain frequencies are available and that the antenna/location work properly. If you are willing to provide remote SSH access for short periods of time if necessary, also indicate that in your email. Please email me if you are interested in helping out getting the device working. Thank you, 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 -- 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
cx23885 HVR-1700 broken in v4l drivers vs standard kernel
Hi if I use stock kernel (Suse) 2.6.27.23-0.1 the card works, scans and plays DVB-T channels. if I use the latest v4l drivers the card is recognised, and picked up, tunes a channel, but cannot find any DVB-T channels. I'm afraid I'm not sure what to look for Thanks -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: eMPIA Silvercrest 2710
Em Fri, 03 Jul 2009 11:05:29 +0200 Hans de Goede hdego...@redhat.com escreveu: My that webcam has done some interesting travelling (me - Dough - you), I'm glad it finally ended at someone who has managed to get it to produce a picture under Linux. Yes. Thank you for borrow it! Hmm, having to specify the card=71 parameter, sucks, that makes this a very non plug and play / not just working experience for end users. Question would it be possible to modify the em28xx driver to, when it sees the generic usb-id, setup the i2c controller approriately and then check: 1) If there is anything at the i2c address of the mt9v011 sensor 2) Read a couple of identification registers (often sensors have special non changing registers for this) 3) If both the 1 and 2 test succeed set card to 71 itself ? The mt9v011 sensor has an unique ID, that can be read via register 0. One of the issues is that it is using the same address as tvp5150 (that can also be probed, since it also provides an unique ID via some register). This is how we handle the problem of having one generic usb-id for a certain bridge, with various different sensors used in different cams, I know the em28xx is a lot more complicated as it does a lot more, but this may still work ? Yes, it may work. with the new i2c binding method, it would not be that hard to do such method, but it would require some rework at em28xx-cards, since some boards require a pre-i2c binding initialization, so board detection happens too early inside the driver. 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: pxa_camera: Oops in pxa_camera_probe.
On Wed, 1 Jul 2009 20:43:25 +0200 Antonio Ospite osp...@studenti.unina.it wrote: Hi, I get this with pxa-camera in mainline linux (from today). I haven't touched my board code which used to work in 2.6.30 I think I've tracked down the cause. The board code is triggering a bug in pxa_camera. The same should apply to mioa701 as well. Linux video capture interface: v2.00 Unable to handle kernel NULL pointer dereference at virtual address 0060 pgd = c0004000 [0060] *pgd= Internal error: Oops: f5 [#1] PREEMPT Modules linked in: CPU: 0Tainted: GW (2.6.31-rc1-ezxdev #1) PC is at dev_driver_string+0x0/0x38 LR is at pxa_camera_probe+0x144/0x428 The offending dev_driver_str() here is the one in the dev_warn() call in mclk_get_divisor(). This is what is happening: in struct pxacamera_platform_data I have: .mclk_10khz = 5000, which makes the test in mclk_get_divisor() succeed calling dev_warn to report that the clock has been limited, but pcdev-soc_host.dev is still uninitialized at this time. I could lower the value in my platform data and avoid the bug, but it would be good to have this fixed ASAP anyway. The attached rough patch fixes the problem, but you will surely come out with a better one :) Thanks, Antonio -- 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? mclk_get_divisor uses pcdev-soc_host.dev, make sure it is initialized. Signed-off-by: Antonio Ospite osp...@studenti.unina.it diff --git a/drivers/media/video/pxa_camera.c b/drivers/media/video/pxa_camera.c index 46e0d8a..e048d25 100644 --- a/drivers/media/video/pxa_camera.c +++ b/drivers/media/video/pxa_camera.c @@ -1579,6 +1579,7 @@ static int __devinit pxa_camera_probe(struct platform_device *pdev) pcdev-mclk = 2000; } + pcdev-soc_host.dev = pdev-dev; pcdev-mclk_divisor = mclk_get_divisor(pcdev); INIT_LIST_HEAD(pcdev-capture); @@ -1644,7 +1645,6 @@ static int __devinit pxa_camera_probe(struct platform_device *pdev) pcdev-soc_host.drv_name = PXA_CAM_DRV_NAME; pcdev-soc_host.ops = pxa_soc_camera_host_ops; pcdev-soc_host.priv = pcdev; - pcdev-soc_host.dev = pdev-dev; pcdev-soc_host.nr = pdev-id; err = soc_camera_host_register(pcdev-soc_host); pgpFWUTYnD6jS.pgp Description: PGP signature
[PULL] http://linuxtv.org/hg/~awalls/v4l-dvb
Mauro, Please pull from http://linuxtv.org/hg/~awalls/v4l-dvb for the following 3 changesets: 01/03: cx18: Update Yuan MPC-718 card entry with better information and guesses http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=e772d4b3fd33 02/03: get_dvb_firmware: Add Yuan MPC718 MT352 DVB-T firmware extraction http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=29af7bb72b6f 03/03: cx18: Add DVB-T support for Yuan MPC-718 cards with an MT352 or ZL10353 http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=6a1449b89b45 Documentation/dvb/get_dvb_firmware| 52 ++- drivers/media/video/cx18/cx18-cards.c | 38 +--- drivers/media/video/cx18/cx18-dvb.c | 160 ++ 3 files changed, 235 insertions(+), 15 deletions(-) Tested-by: Steve Firth firth...@btinternet.com (for MPC-718 units with a Zarlink MT352 demodulator) Thanks, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Who is interested in analog support for dib0700 devices?
Hello all, Some discussion I have been having with Andrej Falout has prompted me to consider finally adding analog support for dib0700 based devices? As a result, I am interested in trying to figure out how many people care about this. In particular, this is a rather large project, so I want to get an idea how many people would actually benefit from this support (and might be willing to donate a couple of dollars toward the effort). I've got all the specs and information required to do the work - it's just a matter of deciding whether it is worth spending three or four weeks of my time that could be spent doing stuff that I would almost certainly consider more interesting. If you are interested in seeing this work, please reply here, or email me privately. Also, include what dib0700 based device you have (and what video decoder and tuner chips it uses if you happen to know). Thanks, 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
[PULL] http://linuxtv.org/hg/~pinchartl/uvcvideo/
Mauro, Please pull from http://linuxtv.org/hg/~pinchartl/uvcvideo/ for the following 5 changesets: uvcvideo: Use class-specific descriptor types from usb/ch9.h uvcvideo: Prefix all UVC constants with UVC_ uvcvideo: Remove unused Logitech-specific constants uvcvideo: Move UVC definitions to linux/usb/video.h uvcvideo: Set PROBE_MINMAX quirk for Aveo Technology webcams b/linux/include/linux/usb/video.h | 164 linux/drivers/media/video/uvc/uvc_ctrl.c | 205 --- linux/drivers/media/video/uvc/uvc_driver.c | 139 +- linux/drivers/media/video/uvc/uvc_v4l2.c | 14 - linux/drivers/media/video/uvc/uvc_video.c | 30 +- linux/drivers/media/video/uvc/uvcvideo.h | 374 - 6 files changed, 474 insertions(+), 452 deletions(-) The fourth patch (Move UVC definitions to linux/usb/video.h) has been submitted to the linux-usb mailing list and acked by Greh KH. Thanks, 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: Digital Audio Broadcast (DAB) devices support
Hmmm, seems my original reply didn't make it into the archive I use, or else the list... No matter... Anyway, sorry for the delay in this reply: On Wed, 1 Jul 2009, Andrej Falout wrote: Thanks for that Barry, it seems Terratec Cinergy Piranha was indeed discontinued, as I cant find it in shops anywhere? It's still on the web site (http://www.terratec.net/en/products/Cinergy_Piranha_1668.html) These days you will probably have the best luck via ebay or similar, though I had seen some shops which appeared to be wanting to clear out their old inventory -- this may depend on where you search, though. But on Terratec site, there is no mention of Linux drivers for this product. This is -- to me, with background knowledge -- no big surprise, as the support which exists is not so much `drivers' as you might expect to find packaged on a CDROM with loads of other useless drivel, but rather, more of an expert-playground thing where the linux driver is patched to give access to a proprietary API which gives you access to be able to tune into the DAB family of broadcasts. There does not even exist an official application for tuning into a particular broadcast stream, although for someone familiar with DAB broadcasting and the API which Siano has made available, this should be no problem -- one list subscriber had in fact written a somewhat primitive tuning application which I've been using (and many thanks, you know who you are), though it in no way matches the needs of today's GUI-infested youth. You will want to search the linux-dvb mailing lists for posts from one Uri Shkolnik to find pointers to the needed patches that can be used with the Siano devices. But as I say, if you want a polished product that you can plug in and use, that is likely still a way off. What Uri, Siano, and the author of the utility I use to tune, have provided, is a ground-level introduction to the DAB family, that can be scripted for tuning a particular service, but which is unsuitable for channel zapping or other non-dedicated listening. I suspect that what Siano has made available is intended more for suppliers who include their chipsets in integrated handy devices or similar receivers which hide their function from the end-user. Still, if you have a particular service you wish to receive via the DAB family, with minimal interest in zapping to other stations during advertising or tediously-repeated songs, then the ``hacker- oriented'' solution made available to the not-faint-hearted may be a good solution. Obligatory disclaimer: ``It werkz fer me'' so for the masses, fergiddabou'it. Anyone else know of something equivalent that works on Linux? For laughs, I g00gled again to see what is new in the last months. There appear to be a number of chinese products out there which can tune DBM as well as the DAB family. However, I see no mention of chip manufacturer. Probably the best one can do here is to plug in such a device -- if readily available -- and see if the USB ID corresponds to Siano or some similar manufacturer. I don't know how widespread these devices are, nor do I know if any of today's devices include the chip announced by (I believe) Dibcom a year or more ago. Apart from the handful of Siano devices, I am not aware of any DAB-family devices with any sort of linux support, but I would hope that as this form of broadcasting gains prominence in certain countries, that more devices will make available support for linux. With the current political situation, this appears to focus on chinese and similar manufacturers, even where development is mandated for France, Switzerland, Germany, and other european countries. As far as the V4L or linux-dvb interface is concerned, as the Eureka 147 family of broadcasts is very different from the DVB family, there is not yet any provision for any application to access the former, so for now, you will have to make do with the API offered via Siano for their devices. Whether this will change is up to the manufacturers or distributors of any such devices, or an expert on the Eureka-147 family, and whether such changes can get added into the appropriate Linux API. barry bouwsma -- 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
Best device I tested so far! - Pinnacle PCTV 72e - Device Information
Hello everybody, So after some hints in an other thread, I bought myself a PCTV 72e to bad Pinnacle soled his department to Hauppauge, so this device is EOL (end of live) But this is so far the best device I tested, it works almost out of the box :D The only thing missing is a firmware package in debian or a mainstream v4l dvb firmware package. The device works with wscan, mplayer, totem-xine and seems to be stable and no need for any custom compiling. See my logs for more information, Best regards, Jelle de Jong $ uname -a Linux debian-eeepc 2.6.30-1-686 #1 SMP Sun Jun 14 16:11:32 UTC 2009 i686 GNU/Linux $ dpkg -l | grep 2.6.30 ii linux-image-2.6.30-1-686 2.6.30-1 Linux 2.6.30 image on PPro/Celeron/PII/PIII/P4 ii linux-libc-dev 2.6.30-1 Linux support headers for userspace development $dmesg [29064.200612] usb 1-3.1: new high speed USB device using ehci_hcd and address 9 [29064.293015] usb 1-3.1: New USB device found, idVendor=2304, idProduct=0236 [29064.293030] usb 1-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [29064.293042] usb 1-3.1: Product: Pinnacle 72e [29064.293051] usb 1-3.1: Manufacturer: LITEON [29064.293060] usb 1-3.1: SerialNumber: JIL [29064.293392] usb 1-3.1: configuration #1 chosen from 1 choice [29064.356772] dib0700: loaded with support for 9 different device-types [29064.357083] dvb-usb: found a 'Pinnacle PCTV 72e' in cold state, will try to load a firmware [29064.357104] usb 1-3.1: firmware: requesting dvb-usb-dib0700-1.20.fw [29064.364772] dvb-usb: did not find the firmware file. (dvb-usb-dib0700-1.20.fw) Please see linux/Documentation/dvb/ for more details on firmware-problems. (-2) [29064.364855] usbcore: registered new interface driver dvb_usb_dib0700 http://linuxtv.org/wiki/index.php/Pinnacle_PCTV_72e # apt-cache search dvb-usb-dib0700 wget http://www.wi-bw.tfh-wildau.de/~pboettch/home/files/dvb-usb-dib0700-1.20.fw sudo mv --verbose dvb-usb-dib0700-1.20.fw /lib/firmware/ $dmesg [29518.906075] usb 1-3.1: USB disconnect, address 9 [29521.408543] usb 1-3.1: new high speed USB device using ehci_hcd and address 10 [29521.500951] usb 1-3.1: New USB device found, idVendor=2304, idProduct=0236 [29521.500966] usb 1-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [29521.500978] usb 1-3.1: Product: Pinnacle 72e [29521.500987] usb 1-3.1: Manufacturer: LITEON [29521.500996] usb 1-3.1: SerialNumber: JIL [29521.501344] usb 1-3.1: configuration #1 chosen from 1 choice [29521.501683] dvb-usb: found a 'Pinnacle PCTV 72e' in cold state, will try to load a firmware [29521.501699] usb 1-3.1: firmware: requesting dvb-usb-dib0700-1.20.fw [29521.535594] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' [29521.742192] dib0700: firmware started successfully. [29522.244109] dvb-usb: found a 'Pinnacle PCTV 72e' in warm state. [29522.244258] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [29522.244793] DVB: registering new adapter (Pinnacle PCTV 72e) [29522.469189] DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)... [29522.661316] DiB0070: successfully identified [29522.661690] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb1/1-3/1-3.1/input/input12 [29522.661867] dvb-usb: schedule remote query interval to 50 msecs. [29522.661880] dvb-usb: Pinnacle PCTV 72e successfully initialized and connected. -_-_-_-_ Getting frontend capabilities-_-_-_-_ Using DVB API 5.0 frontend DiBcom 7000PC supports INVERSION_AUTO QAM_AUTO TRANSMISSION_MODE_AUTO GUARD_INTERVAL_AUTO HIERARCHY_AUTO FEC_AUTO -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ $ sudo lsusb -vvv -d 2304:0236 Bus 001 Device 009: ID 2304:0236 Pinnacle Systems, Inc. [hex] Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x2304 Pinnacle Systems, Inc. [hex] idProduct 0x0236 bcdDevice1.00 iManufacturer 1 LITEON iProduct2 Pinnacle 72e iSerial 3 JIL bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 46 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA
Re: Call for testers: Terratec Cinergy T XS USB support
Markus Rechberger wrote: Hi all, On Mon, Jun 29, 2009 at 4:00 PM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: Hello all, A few weeks ago, I did some work on support for the Terratec Cinergy T XS USB product. I successfully got the zl10353 version working and issued a PULL request last week (http://www.kernellabs.com/hg/~dheitmueller/em28xx-terratec-zl10353) There will be an alternative driver entirely in userspace available which works across all major kernelversions and distributions. It will support the old em28xx devices and handle audio routing for the most popular TV applications directly. This system makes compiling the drivers unnecessary across all available linux systems between 2.6.15 and ongoing. This package also allows commercial drivers from vendors, the API itself is almost the same as the video4linux/linuxdvb API. Installing a driver takes less than five seconds without having to take care about the kernel API or having to set up a development system. Aside of that it's operating system independent (working on Linux, MacOSX and FreeBSD). I think this is the way to go for the future since it adds more possibilities to the drivers, and it eases up and speeds up driver development dramatically. Best Regards, Markus ROTFLOL (well actually it was more like a rather bemused smile) -- simon -- 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: Call for testers: Terratec Cinergy T XS USB support
Markus Rechberger wrote: Hi all, On Mon, Jun 29, 2009 at 4:00 PM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: Hello all, A few weeks ago, I did some work on support for the Terratec Cinergy T XS USB product. �I successfully got the zl10353 version working and issued a PULL request last week (http://www.kernellabs.com/hg/~dheitmueller/em28xx-terratec-zl10353) There will be an alternative driver entirely in userspace available which works across all major kernelversions and distributions. It will support the old em28xx devices and handle audio routing for the most popular TV applications directly. This system makes compiling the drivers unnecessary across all available linux systems between 2.6.15 and ongoing. This package also allows commercial drivers from vendors, the API itself is almost the same as the video4linux/linuxdvb API. Installing a driver takes less than five seconds without having to take care about the kernel API or having to set up a development system. Aside of that it's operating system independent (working on Linux, MacOSX and FreeBSD). I think this is the way to go for the future since it adds more possibilities to the drivers, and it eases up and speeds up driver development dramatically. Still keep feeling an itch to response to this. I am not interested in any proprietary driver binaries and I tried to work with you and contributed documentation, testing and lot of time to your em28xx project. I feel mislead and wasted my time trying to help you. Please don't response to this mail in this thread make a separate public thread if you want to discus it. I don't like thread highjacking. You are more then welcome to contribute code back in small patches for one change at a time that meets the Linux kernel licensing and coding guidelines. I sometimes got the feeling you are doing more good then harm working for Empiatech. Best regards, Jelle de Jong -- 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: Call for testers: Terratec Cinergy T XS USB support
Jelle de Jong wrote: sometimes got the feeling you are doing more good then harm working for Empiatech. typograpical correction: that should have been; more harm then good ... Best regards, Jelle de Jong -- 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]stv680: kfree called before usb_kill_urb
The irq handler will touch memory. Even in the error case some URBs may
complete. Thus no memory must be kfreed before all URBs are killed.
Signed-off-by: Oliver Neukum oli...@neukum.org
--
commit e91d238d2b6f83f9b64b57b570ee150b1cd008e7
Author: Oliver Neukum oneu...@linux-d698.(none)
Date: Fri Jul 3 18:18:26 2009 +0200
stv680: fix access to freed memory in error case
in the error case some URBs may be active and access memory
URBs must be killed before any memory is freed
diff --git a/drivers/media/video/stv680.c b/drivers/media/video/stv680.c
index 75f286f..58c0148 100644
--- a/drivers/media/video/stv680.c
+++ b/drivers/media/video/stv680.c
@@ -733,10 +733,6 @@ static int stv680_start_stream (struct usb_stv *stv680)
return 0;
nomem_err:
- for (i = 0; i STV680_NUMSCRATCH; i++) {
- kfree(stv680-scratch[i].data);
- stv680-scratch[i].data = NULL;
- }
for (i = 0; i STV680_NUMSBUF; i++) {
usb_kill_urb(stv680-urb[i]);
usb_free_urb(stv680-urb[i]);
@@ -744,6 +740,11 @@ static int stv680_start_stream (struct usb_stv *stv680)
kfree(stv680-sbuf[i].data);
stv680-sbuf[i].data = NULL;
}
+ /* used in irq, free only as all URBs are dead */
+ for (i = 0; i STV680_NUMSCRATCH; i++) {
+ kfree(stv680-scratch[i].data);
+ stv680-scratch[i].data = NULL;
+ }
return -ENOMEM;
}
--
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
[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:Fri Jul 3 19:00:04 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12171:ba13f1c60e2e gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-rc1-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.31-rc1-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-rc1-armv5-omap2: ERRORS 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-rc1-i686: ERRORS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-rc1-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-rc1-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-rc1-powerpc64: ERRORS 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-rc1-x86_64: ERRORS sparse (linux-2.6.30): OK sparse (linux-2.6.31-rc1): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: 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: ERRORS 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/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: eMpia Microscope Camera
(re-adding the mailing list) On Fri, 3 Jul 2009, Wally wrote: Hello Guennadi, hello Mauro that's means i have to wait or is there a workaround or something else i can do for now ? you can either wait, or hack the mt9m001 driver to work for you, or help with development. 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: soc-camera: status, roadmap
Guennadi Liakhovetski wrote: On Wed, 10 Jun 2009, Guennadi Liakhovetski wrote: 2. The above means, I'll have to maintain and update my patches for a whole 2.6.31 development cycle. In this time I'll try to update and upload them as a quilt patch series and announce it on the list a couple of times. As promised, I just uploaded my current tree snapshot at http://download.open-technology.de/soc-camera/20090617/ This is nothing remarkable, just my current patch-stack for those working with the soc-camera framework. It is still based on a linux-next snapshot of 07.05.2009 history branch. The exact commit on which the stack is based is, as usual, in -base. This is still based off 2.6.30-rc4, and I expect to upgrade next time after 2.6.31-rc1. Hi Guennadi, I notice you've posted newer version of these patches on your website. 20090701/ I was wondering what tree these are based on? I can't seem to track down the base commit. Thanks, Jonathan -- 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: soc-camera: status, roadmap
On Fri, 3 Jul 2009, Jonathan Cameron wrote: Guennadi Liakhovetski wrote: On Wed, 10 Jun 2009, Guennadi Liakhovetski wrote: 2. The above means, I'll have to maintain and update my patches for a whole 2.6.31 development cycle. In this time I'll try to update and upload them as a quilt patch series and announce it on the list a couple of times. As promised, I just uploaded my current tree snapshot at http://download.open-technology.de/soc-camera/20090617/ This is nothing remarkable, just my current patch-stack for those working with the soc-camera framework. It is still based on a linux-next snapshot of 07.05.2009 history branch. The exact commit on which the stack is based is, as usual, in -base. This is still based off 2.6.30-rc4, and I expect to upgrade next time after 2.6.31-rc1. Hi Guennadi, I notice you've posted newer version of these patches on your website. 20090701/ I was wondering what tree these are based on? I can't seem to track down the base commit. It has been announced here: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/7492/focus=7534 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: pxa_camera: Oops in pxa_camera_probe.
On Fri, 3 Jul 2009, Antonio Ospite wrote: On Wed, 1 Jul 2009 20:43:25 +0200 Antonio Ospite osp...@studenti.unina.it wrote: Hi, I get this with pxa-camera in mainline linux (from today). I haven't touched my board code which used to work in 2.6.30 I think I've tracked down the cause. The board code is triggering a bug in pxa_camera. The same should apply to mioa701 as well. Linux video capture interface: v2.00 Unable to handle kernel NULL pointer dereference at virtual address 0060 pgd = c0004000 [0060] *pgd= Internal error: Oops: f5 [#1] PREEMPT Modules linked in: CPU: 0Tainted: GW (2.6.31-rc1-ezxdev #1) PC is at dev_driver_string+0x0/0x38 LR is at pxa_camera_probe+0x144/0x428 The offending dev_driver_str() here is the one in the dev_warn() call in mclk_get_divisor(). This is what is happening: in struct pxacamera_platform_data I have: .mclk_10khz = 5000, which makes the test in mclk_get_divisor() succeed calling dev_warn to report that the clock has been limited, but pcdev-soc_host.dev is still uninitialized at this time. I could lower the value in my platform data and avoid the bug, but it would be good to have this fixed ASAP anyway. The attached rough patch fixes the problem, but you will surely come out with a better one :) Why should I? Your patch seems correct to me so far, thanks. I'll push it for 2.6.31. Please, next time inline your patch as described in Documentation/SubmittingPatches. 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] cx88: High resolution timer for Remote Controls
On Thu, 2 Jul 2009 16:50:35 +0200, Jean Delvare wrote: From: Andrzej Hajda andrzej.ha...@wp.pl Patch solves problem of missed keystrokes on some remote controls, as reported on http://bugzilla.kernel.org/show_bug.cgi?id=9637 . Signed-off-by: Andrzej Hajda andrzej.ha...@wp.pl Signed-off-by: Jean Delvare kh...@linux-fr.org --- Resending because last attempt resulted in folded lines: http://www.spinics.net/lists/linux-media/msg06884.html Patch was already resent by Andrzej on June 4th but apparently it was overlooked. Trent Piepho commented on the compatibility with kernels older than 2.6.20 being possibly broken: http://www.spinics.net/lists/linux-media/msg06885.html I don't think this is the case. The kernel version test was there because the workqueue API changed in 2.6.20, but the hrtimer API did not have such a change. This is why the version check has gone. It is highly probable that the hrtimer API had its own incompatible changes since it was introduced in kernel 2.6.16. By looking at the code, I found the following ones: * hrtimer_forward_now() was added with kernel 2.6.25 only: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=5e05ad7d4e3b11f935998882b5d9c3b257137f1b But this is an inline function, so I presume this shouldn't be too difficult to add to a compatibility header. * Before 2.6.21, HRTIMER_MODE_REL was named HRTIMER_REL: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c9cb2e3d7c9178ab75d0942f96abb3abe0369906 This too should be solvable in a compatibility header. The rest doesn't seem to cause compatibility issues, but only actual testing would confirm that. Actually there were more compatibility issues, the most important one being that not all functions of the hrtimer API are exported before 2.6.22. So unfortunately this bug fix means that the cx88 driver will no longer build on kernels 2.6.22. I'll post a new patch with this change, and another one for the hrtimer compatibility code. -- 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 2/2] cx88: High resolution timer for Remote Controls
Patch solves problem of missed keystrokes on some remote controls,
as reported on http://bugzilla.kernel.org/show_bug.cgi?id=9637 .
Signed-off-by: Andrzej Hajda andrzej.ha...@wp.pl
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
Changes:
* Driver no longer builds on kernels 2.6.22, so add an entry to
v4l/versions.txt
* Add a missing static.
Build-tested on 2.6.22.
linux/drivers/media/video/cx88/cx88-input.c | 37
v4l/versions.txt|2 +
2 files changed, 19 insertions(+), 20 deletions(-)
--- a/linux/drivers/media/video/cx88/cx88-input.c
+++ b/linux/drivers/media/video/cx88/cx88-input.c
@@ -23,7 +23,7 @@
*/
#include linux/init.h
-#include linux/delay.h
+#include linux/hrtimer.h
#include linux/input.h
#include linux/pci.h
#include linux/module.h
@@ -49,7 +49,7 @@ struct cx88_IR {
/* poll external decoder */
int polling;
- struct delayed_work work;
+ struct hrtimer timer;
u32 gpio_addr;
u32 last_gpio;
u32 mask_keycode;
@@ -145,31 +145,28 @@ static void cx88_ir_handle_key(struct cx
}
}
-#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20)
-static void cx88_ir_work(void *data)
-#else
-static void cx88_ir_work(struct work_struct *work)
-#endif
+static enum hrtimer_restart cx88_ir_work(struct hrtimer *timer)
{
-#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20)
- struct cx88_IR *ir = data;
-#else
- struct cx88_IR *ir = container_of(work, struct cx88_IR, work.work);
-#endif
+ unsigned long missed;
+ struct cx88_IR *ir = container_of(timer, struct cx88_IR, timer);
cx88_ir_handle_key(ir);
- schedule_delayed_work(ir-work, msecs_to_jiffies(ir-polling));
+ missed = hrtimer_forward_now(ir-timer,
+ktime_set(0, ir-polling * 100));
+ if (missed 1)
+ ir_dprintk(Missed ticks %ld\n, missed - 1);
+
+ return HRTIMER_RESTART;
}
void cx88_ir_start(struct cx88_core *core, struct cx88_IR *ir)
{
if (ir-polling) {
-#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20)
- INIT_DELAYED_WORK(ir-work, cx88_ir_work, ir);
-#else
- INIT_DELAYED_WORK(ir-work, cx88_ir_work);
-#endif
- schedule_delayed_work(ir-work, 0);
+ hrtimer_init(ir-timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+ ir-timer.function = cx88_ir_work;
+ hrtimer_start(ir-timer,
+ ktime_set(0, ir-polling * 100),
+ HRTIMER_MODE_REL);
}
if (ir-sampling) {
core-pci_irqmask |= PCI_INT_IR_SMPINT;
@@ -186,7 +183,7 @@ void cx88_ir_stop(struct cx88_core *core
}
if (ir-polling)
- cancel_delayed_work_sync(ir-work);
+ hrtimer_cancel(ir-timer);
}
/* -- */
--- a/v4l/versions.txt
+++ b/v4l/versions.txt
@@ -34,6 +34,8 @@ DVB_DRX397XD
DVB_DM1105
# This driver needs print_hex_dump
DVB_FIREDTV
+# This driver needs hrtimer API
+VIDEO_CX88
[2.6.20]
#This driver requires HID_REQ_GET_REPORT
--
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 repost 1/4] V4L: radio-si470x, fix lock imbalance
There is one path with omitted unlock in si470x_fops_release. Fix that. Signed-off-by: Jiri Slaby jirisl...@gmail.com --- drivers/media/radio/radio-si470x.c |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/media/radio/radio-si470x.c b/drivers/media/radio/radio-si470x.c index 640421c..46d2163 100644 --- a/drivers/media/radio/radio-si470x.c +++ b/drivers/media/radio/radio-si470x.c @@ -1200,7 +1200,7 @@ static int si470x_fops_release(struct file *file) video_unregister_device(radio-videodev); kfree(radio-buffer); kfree(radio); - goto done; + goto unlock; } /* stop rds reception */ @@ -1213,9 +1213,8 @@ static int si470x_fops_release(struct file *file) retval = si470x_stop(radio); usb_autopm_put_interface(radio-intf); } - +unlock: mutex_unlock(radio-disconnect_lock); - done: return retval; } -- 1.6.3.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 repost 2/4] V4L: em28xx, fix lock imbalance
There is one omitted unlock in em28xx_usb_probe. Fix that.
Signed-off-by: Jiri Slaby jirisl...@gmail.com
---
drivers/media/video/em28xx/em28xx-cards.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index 36abb35..922d21d 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -2445,6 +2445,7 @@ static int em28xx_usb_probe(struct usb_interface
*interface,
retval = em28xx_init_dev(dev, udev, interface, nr);
if (retval) {
em28xx_devused = ~(1dev-devno);
+ mutex_unlock(dev-lock);
kfree(dev);
goto err;
}
--
1.6.3.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 repost 3/4] V4L: hdpvr, fix lock imbalances
There are many lock imbalances in this driver. Fix all found.
Signed-off-by: Jiri Slaby jirisl...@gmail.com
---
drivers/media/video/hdpvr/hdpvr-core.c | 12 ++--
drivers/media/video/hdpvr/hdpvr-video.c |6 --
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/hdpvr/hdpvr-core.c
b/drivers/media/video/hdpvr/hdpvr-core.c
index 188bd5a..1c9bc94 100644
--- a/drivers/media/video/hdpvr/hdpvr-core.c
+++ b/drivers/media/video/hdpvr/hdpvr-core.c
@@ -126,7 +126,7 @@ static int device_authorization(struct hdpvr_device *dev)
char *print_buf = kzalloc(5*buf_size+1, GFP_KERNEL);
if (!print_buf) {
v4l2_err(dev-v4l2_dev, Out of memory\n);
- goto error;
+ return retval;
}
#endif
@@ -140,7 +140,7 @@ static int device_authorization(struct hdpvr_device *dev)
if (ret != 46) {
v4l2_err(dev-v4l2_dev,
unexpected answer of status request, len %d\n, ret);
- goto error;
+ goto unlock;
}
#ifdef HDPVR_DEBUG
else {
@@ -163,7 +163,7 @@ static int device_authorization(struct hdpvr_device *dev)
v4l2_err(dev-v4l2_dev, unknown firmware version 0x%x\n,
dev-usbc_buf[1]);
ret = -EINVAL;
- goto error;
+ goto unlock;
}
response = dev-usbc_buf+38;
@@ -188,10 +188,10 @@ static int device_authorization(struct hdpvr_device *dev)
1);
v4l2_dbg(MSG_INFO, hdpvr_debug, dev-v4l2_dev,
magic request returned %d\n, ret);
- mutex_unlock(dev-usbc_mutex);
retval = ret != 8;
-error:
+unlock:
+ mutex_unlock(dev-usbc_mutex);
return retval;
}
@@ -350,6 +350,7 @@ static int hdpvr_probe(struct usb_interface *interface,
mutex_lock(dev-io_mutex);
if (hdpvr_alloc_buffers(dev, NUM_BUFFERS)) {
+ mutex_unlock(dev-io_mutex);
v4l2_err(dev-v4l2_dev,
allocating transfer buffers failed\n);
goto error;
@@ -381,7 +382,6 @@ static int hdpvr_probe(struct usb_interface *interface,
error:
if (dev) {
- mutex_unlock(dev-io_mutex);
/* this frees allocated memory */
hdpvr_delete(dev);
}
diff --git a/drivers/media/video/hdpvr/hdpvr-video.c
b/drivers/media/video/hdpvr/hdpvr-video.c
index ccd47f5..5937de2 100644
--- a/drivers/media/video/hdpvr/hdpvr-video.c
+++ b/drivers/media/video/hdpvr/hdpvr-video.c
@@ -375,6 +375,7 @@ static int hdpvr_open(struct file *file)
* in resumption */
mutex_lock(dev-io_mutex);
dev-open_count++;
+ mutex_unlock(dev-io_mutex);
fh-dev = dev;
@@ -383,7 +384,6 @@ static int hdpvr_open(struct file *file)
retval = 0;
err:
- mutex_unlock(dev-io_mutex);
return retval;
}
@@ -519,8 +519,10 @@ static unsigned int hdpvr_poll(struct file *filp,
poll_table *wait)
mutex_lock(dev-io_mutex);
- if (video_is_unregistered(dev-video_dev))
+ if (video_is_unregistered(dev-video_dev)) {
+ mutex_unlock(dev-io_mutex);
return -EIO;
+ }
if (dev-status == STATUS_IDLE) {
if (hdpvr_start_streaming(dev)) {
--
1.6.3.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 repost 4/4] V4L: saa7134, fix lock imbalance
There seems to be one superfluos unlock in a poll function. Remove it. Signed-off-by: Jiri Slaby jirisl...@gmail.com --- drivers/media/video/saa7134/saa7134-video.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/saa7134/saa7134-video.c b/drivers/media/video/saa7134/saa7134-video.c index 82b57a6..dd9aab0 100644 --- a/drivers/media/video/saa7134/saa7134-video.c +++ b/drivers/media/video/saa7134/saa7134-video.c @@ -1443,7 +1443,6 @@ video_poll(struct file *file, struct poll_table_struct *wait) fh-cap.ops-buf_queue(fh-cap,fh-cap.read_buf); fh-cap.read_off = 0; } - mutex_unlock(fh-cap.vb_lock); buf = fh-cap.read_buf; } -- 1.6.3.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
Re: pxa_camera: Oops in pxa_camera_probe.
On Fri, 3 Jul 2009 22:03:27 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Fri, 3 Jul 2009, Antonio Ospite wrote: Linux video capture interface: v2.00 Unable to handle kernel NULL pointer dereference at virtual address 0060 pgd = c0004000 [0060] *pgd= Internal error: Oops: f5 [#1] PREEMPT Modules linked in: CPU: 0Tainted: GW (2.6.31-rc1-ezxdev #1) PC is at dev_driver_string+0x0/0x38 LR is at pxa_camera_probe+0x144/0x428 The offending dev_driver_str() here is the one in the dev_warn() call in mclk_get_divisor(). This is what is happening: in struct pxacamera_platform_data I have: .mclk_10khz = 5000, which makes the test in mclk_get_divisor() succeed calling dev_warn to report that the clock has been limited, but pcdev-soc_host.dev is still uninitialized at this time. I could lower the value in my platform data and avoid the bug, but it would be good to have this fixed ASAP anyway. The attached rough patch fixes the problem, but you will surely come out with a better one :) Why should I? Your patch seems correct to me so far, thanks. I'll push it for 2.6.31. Please, next time inline your patch as described in Documentation/SubmittingPatches. Well, it should be correct, I just thought it could be considered unpretty with the pcdev-soc_host initializations scattered here and there, that's what I was referring to. But, if this is ok to you, it's ok to me too :) Ciao, Antonio -- 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? pgpA5hJKv0j2w.pgp Description: PGP signature
Re: RFC: Remote control sensors and Linux input layer
Hi, Am Mittwoch, den 01.07.2009, 13:13 +0200 schrieb Krzysztof Halasa: hermann pitton hermann-pit...@arcor.de writes: your prior mail with the RFC is only on linux-input. Well, I posted it to linux-input, -media, -kernel. Krzysztof, sorry, my bad. Mails did not arrive in timely manner as usual after some heavy thunderstorms here. I wonder, why you don't start with the remote coming with your Avermedia card, but with some Philips remote coming with your TV. Because I use the later. I will capture the AverMedia codes for complete support but it's lower priority for me. It is years back, but we don't know until today, waiting nine months or so then, if we did break the bttv device ... Please keep the comments. I will, of course, keep the ones which still apply. And of course it would be very nice to have RC5 support on transmitters and receivers capable for it. Cheers, Hermann -- 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
Ralink RTL2831U
Moi Jelle, On 06/26/2009 11:26 AM, Jelle de Jong wrote: Question for Antti if he had any luck with the devices (rtl2831-r2) I send? I have been busy with other drivers, but now I have time for this. It was a little bit tricky to take sniffs from Windows because sniffer crashed very easily with this device :o But after testing about all drivers I found and after countless blue-screens I finally got one good sniff. From sniff I see this device is rather simple to program. And device you send have MT2060 tuner. With a any luck and without other summer activities (I am still hoping warm weather and beach activities :) it will not take many days to get picture. After that I will move relevant parts from the current Ralink driver to the new driver... I will keep informed about driver status. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
