Re: MCEUSB memory leak and how to tell if ir_register_input() failure registered input_dev?
On Sun, 2010-06-27 at 23:34 -0400, Jarod Wilson wrote: On Sun, Jun 27, 2010 at 7:17 PM, Andy Walls awa...@md.metrocast.net wrote: Mauro and Jarrod, When ir_register_input() fails, it doesn't indicate whether or not it was able to register the input_dev or not. To me it looks like it can return with failure with the input_dev either way depending on the case. This makes proper cleanup of the input_dev in my cx23885_input_init() function difficult in the failure case, since the input subsystem has two different deallocators depending on if the device had been registered or not. Hm. I've done a double-take a few times now, but if input_register_device is successful, and something later in __ir_input_register fails, input_unregister_device *does* get called within __ir_input_register, so all you should have to do is call input_free_device in your init function's error path, no? I couldn't quite tell (with the constant stream of intteruptions I get at times). That's why I asked. :) I'll double check today once I'm done with getting the CX23888 IR Tx working. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[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:Sat Jul 3 19:00:21 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14993:9652f85e688a git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 41c5f984b67b331064e69acc9fca5e99bf73d400 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-armv5: WARNINGS linux-2.6.35-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-i686: WARNINGS linux-2.6.35-rc1-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35-rc1-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-mips: WARNINGS linux-2.6.35-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-powerpc64: WARNINGS linux-2.6.35-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS 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-x86_64: WARNINGS linux-2.6.35-rc1-x86_64: ERRORS 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: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.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
TT-3200 + CI slot - decoding
I've got: Kubuntu 10.04 64-bit + Skystar HD + CI Slot + Aston 2.18 + Cyfra+ (Seca2) card + Kaffeine 0.8.8 and I try to use it with s2-liplianin driver - it lock signal (90% success), but problem is with decoding... I've got audio without video, or video without audio, or slideshow – here only 5% attempts with full success... :( with v4l-dvb is the same... any help? -- Pozdrawiam! Gasiu -- 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 v3] IR/mceusb: kill pinnacle-device-specific nonsense
Em 03-07-2010 01:02, Jarod Wilson escreveu: I have pinnacle hardware now. None of this pinnacle-specific crap is at all necessary (in fact, some of it needed to be removed to actually make it work). The only thing unique about this device is that it often transfers inbound data w/a header of 0x90, meaning 16 bytes of IR data following it, so I had to make adjustments for that, and now its working perfectly fine. v2: stillborn v3: remove completely unnecessary usb_reset_device() call that only served to piss off the pinnacle device regularly and unify/simplify some of the generation-specific device initialization code. post-mortem: it seems the pinnacle hardware actually still gets pissed off from time to time, but I can (try) to fix that later (if possible). The patch is still quite helpful from a code reduction standpoint. Signed-off-by: Jarod Wilson ja...@redhat.com I've already applied a previous version of this patch: http://git.linuxtv.org/v4l-dvb.git?a=commit;h=afd46362e573276e3fb0a44834ad320c97947233 Could you please rebase it against my tree? --- Makefile |2 +- drivers/media/IR/mceusb.c | 110 + 2 files changed, 22 insertions(+), 90 deletions(-) diff --git a/Makefile b/Makefile index 6e39ec7..0417c74 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 35 -EXTRAVERSION = -rc1 +EXTRAVERSION = -rc1-ir Please, don't patch the upstream Makefile ;) 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: [git:v4l-dvb/other] V4L/DVB: drivers/media/video/pvrusb2: Add missing mutex_unlock
Hello Mike, Mike Isely wrote: Mauro: FYI, I posted an Acked-By: Mike Isely is...@pobox.com weeks ago, back on 27-May, immediately after the patch was posted. It's a great catch, and the bug has been there since basically the beginning of the driver. Was I ever supposed to see any kind of reaction to that ack (e.g. having the Acked-By added to the patch)? I had posted it in reply to the original patch, copied back to the patch author, to lkml, to linux-media, kernel-janitors, and Mauro. -Mike It seems my mistake since I have added CC instead of Acked-by, sorry. This happened because usually I add CC to the authors of drivers when I took patches from patchwork and I wanna notify them. In your case, I missed the acked-by. Mauro, if possible, could you please replace CC to the correct Acked-by before submit this patch to Linus? Thanks Douglas -- 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/mceusb: kill pinnacle-device-specific nonsense
On Saturday, July 3, 2010, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 03-07-2010 01:02, Jarod Wilson escreveu: I have pinnacle hardware now. None of this pinnacle-specific crap is at all necessary (in fact, some of it needed to be removed to actually make it work). The only thing unique about this device is that it often transfers inbound data w/a header of 0x90, meaning 16 bytes of IR data following it, so I had to make adjustments for that, and now its working perfectly fine. v2: stillborn v3: remove completely unnecessary usb_reset_device() call that only served to piss off the pinnacle device regularly and unify/simplify some of the generation-specific device initialization code. post-mortem: it seems the pinnacle hardware actually still gets pissed off from time to time, but I can (try) to fix that later (if possible). The patch is still quite helpful from a code reduction standpoint. Signed-off-by: Jarod Wilson ja...@redhat.com I've already applied a previous version of this patch: http://git.linuxtv.org/v4l-dvb.git?a=commit;h=afd46362e573276e3fb0a44834ad320c97947233 Could you please rebase it against my tree? D'oh, sure, will do, should be able to knock that out tonight. --- Makefile | 2 +- drivers/media/IR/mceusb.c | 110 + 2 files changed, 22 insertions(+), 90 deletions(-) diff --git a/Makefile b/Makefile index 6e39ec7..0417c74 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 35 -EXTRAVERSION = -rc1 +EXTRAVERSION = -rc1-ir Please, don't patch the upstream Makefile ;) Gah, I saw that and meant to remove it. The perils of rushing things the night before going on vacation... --jarod -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] IR/mceusb: unify and simplify different gen device init
Started out as an effort to try to tackle the last remaining issue I'm
having with this damned pinnacle device getting wedged the first time
its plugged in after an indeterminate length of not being plugged in.
Didn't get that solved yet, but did streamline the init code a bit more
and remove some superfluous gunk. Nukes a completely unneeded call to
usb_device_init() and several lines of overly complex crap in the gen1
device init path.
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/IR/mceusb.c | 47 ++--
1 files changed, 7 insertions(+), 40 deletions(-)
diff --git a/drivers/media/IR/mceusb.c b/drivers/media/IR/mceusb.c
index aaa40d8..46de9bc 100644
--- a/drivers/media/IR/mceusb.c
+++ b/drivers/media/IR/mceusb.c
@@ -766,47 +766,18 @@ static void mceusb_gen1_init(struct mceusb_dev *ir)
int i, ret;
int partial = 0;
struct device *dev = ir-dev;
- char *junk, *data;
-
- junk = kmalloc(2 * USB_BUFLEN, GFP_KERNEL);
- if (!junk) {
- dev_err(dev, %s: memory allocation failed!\n, __func__);
- return;
- }
+ char *data;
data = kzalloc(USB_CTRL_MSG_SZ, GFP_KERNEL);
if (!data) {
dev_err(dev, %s: memory allocation failed!\n, __func__);
- kfree(junk);
return;
}
/*
-* Clear off the first few messages. These look like calibration
-* or test data, I can't really tell. This also flushes in case
-* we have random ir data queued up.
-*/
- for (i = 0; i MCE_G1_INIT_MSGS; i++)
- usb_bulk_msg(ir-usbdev,
- usb_rcvbulkpipe(ir-usbdev,
- ir-usb_ep_in-bEndpointAddress),
- junk, sizeof(junk), partial, HZ * 10);
-
- /* Get Status */
- ret = usb_control_msg(ir-usbdev, usb_rcvctrlpipe(ir-usbdev, 0),
- USB_REQ_GET_STATUS, USB_DIR_IN,
- 0, 0, data, USB_CTRL_MSG_SZ, HZ * 3);
-
- /*ret = usb_get_status( ir-usbdev, 0, 0, data ); */
- dev_dbg(dev, %s - ret = %d status = 0x%x 0x%x\n, __func__,
- ret, data[0], data[1]);
-
- /*
-* This is a strange one. They issue a set address to the device
+* This is a strange one. Windows issues a set address to the device
* on the receive control pipe and expect a certain value pair back
*/
- memset(data, 0, sizeof(data));
-
ret = usb_control_msg(ir-usbdev, usb_rcvctrlpipe(ir-usbdev, 0),
USB_REQ_SET_ADDRESS, USB_TYPE_VENDOR, 0, 0,
data, USB_CTRL_MSG_SZ, HZ * 3);
@@ -834,16 +805,12 @@ static void mceusb_gen1_init(struct mceusb_dev *ir)
dev_dbg(dev, %s - retC = %d\n, __func__, ret);
kfree(data);
- kfree(junk);
};
static void mceusb_gen2_init(struct mceusb_dev *ir)
{
int maxp = ir-len_in;
- mce_sync_in(ir, NULL, maxp);
- mce_sync_in(ir, NULL, maxp);
-
/* device reset */
mce_async_out(ir, DEVICE_RESET, sizeof(DEVICE_RESET));
mce_sync_in(ir, NULL, maxp);
@@ -861,8 +828,6 @@ static void mceusb_gen3_init(struct mceusb_dev *ir)
{
int maxp = ir-len_in;
- mce_sync_in(ir, NULL, maxp);
-
/* device reset */
mce_async_out(ir, DEVICE_RESET, sizeof(DEVICE_RESET));
mce_sync_in(ir, NULL, maxp);
@@ -969,8 +934,6 @@ static int __devinit mceusb_dev_probe(struct usb_interface
*intf,
dev_dbg(intf-dev, : %s called\n, __func__);
- usb_reset_device(dev);
-
config = dev-actconfig;
idesc = intf-cur_altsetting;
@@ -1057,7 +1020,11 @@ static int __devinit mceusb_dev_probe(struct
usb_interface *intf,
if (!ir-idev)
goto input_dev_fail;
- /* inbound data */
+ /* flush buffers on the device */
+ mce_sync_in(ir, NULL, maxp);
+ mce_sync_in(ir, NULL, maxp);
+
+ /* wire up inbound data handler */
usb_fill_int_urb(ir-urb_in, dev, pipe, ir-buf_in,
maxp, (usb_complete_t) mceusb_dev_recv, ir, ep_in-bInterval);
ir-urb_in-transfer_dma = ir-dma_in;
--
1.7.1
--
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: auto-configure another 0xffdc device variant
Per Pieter Hoekstra: I have a Antec Fusion with a iMON Lcd and I get the following error: imon 6-1:1.0: Unknown 0xffdc device, defaulting to VFD and iMON IR (id 0x9e) The driver is functional if I load it like this: (I do not use a remote for it) modprobe imon display_type=1 (On Mythbuntu 10.04/2.6.32) This device is a lcd-type with support for a MCE remote. Looking at the source code, this device (0x9e) is the same as id 0x9f. Signed-off-by: Jarod Wilson ja...@redhat.com --- drivers/media/IR/imon.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/IR/imon.c b/drivers/media/IR/imon.c index 4b1fe9b..71eeb85 100644 --- a/drivers/media/IR/imon.c +++ b/drivers/media/IR/imon.c @@ -2059,6 +2059,7 @@ static void imon_get_ffdc_type(struct imon_context *ictx) detected_display_type = IMON_DISPLAY_TYPE_VFD; break; /* iMON LCD, MCE IR */ + case 0x9e: case 0x9f: dev_info(ictx-dev, 0xffdc iMON LCD, MCE IR); detected_display_type = IMON_DISPLAY_TYPE_LCD; -- 1.7.1 -- 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: [git:v4l-dvb/other] V4L/DVB: drivers/media/video/pvrusb2: Add missing mutex_unlock
On Sat, 3 Jul 2010, Douglas Schilling Landgraf wrote: Hello Mike, Mike Isely wrote: Mauro: FYI, I posted an Acked-By: Mike Isely is...@pobox.com weeks ago, back on 27-May, immediately after the patch was posted. It's a great catch, and the bug has been there since basically the beginning of the driver. Was I ever supposed to see any kind of reaction to that ack (e.g. having the Acked-By added to the patch)? I had posted it in reply to the original patch, copied back to the patch author, to lkml, to linux-media, kernel-janitors, and Mauro. -Mike It seems my mistake since I have added CC instead of Acked-by, sorry. This happened because usually I add CC to the authors of drivers when I took patches from patchwork and I wanna notify them. In your case, I missed the acked-by. Mauro, if possible, could you please replace CC to the correct Acked-by before submit this patch to Linus? Hmm, going through my old e-mail now I can see that the patch was picked up for -mm on 1-Jun. At that time I was marked as a CC: for the patch - which I'd expect as the driver maintainer. But no Acked-By: was showing. Maybe that's when the ack got missed. Obviously I have no issue with this patch. My only real concern is that nobody thinks I might have been ignoring it. Thanks for following up. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Firmware for HVR-1110
Hi JD, Am Samstag, den 03.07.2010, 03:32 +0100 schrieb JD: I'm confused as to what firmware in needed for the HVR-1110. Scouring the web, everywhere claims that the dvb-fe-tda10046 is required; however, dmesg logs show that this fails to be uploaded, and instead it is looking for dvb-fe-tda-10048: If I use tda-10048 then this seems to successfully loaded, but I am unable to find any channels with a scan; the dvb nodes within /dev/ are created and modules loaded, but dvbscan fails to tune. -- dmesg $ dmesg |grep firmware tda10048_firmware_upload: waiting for firmware upload (dvb-fe-tda10048-1.0.fw)... saa7134 :03:04.0: firmware: requesting dvb-fe-tda10048-1.0.fw tda10048_firmware_upload: firmware read 24878 bytes. tda10048_firmware_upload: firmware uploading tda10048_firmware_upload: firmware uploaded Any tips? Thanks. -- all variants of the HVR-1110 have a tda 10046. I can't see, how firmware loading can fail on auto detection of those and even switch over to tda10048 as an alternative. Do you force some card = number and are maybe on a not yet detected HVR-1120? Please provide the full dmesg log related to your card and make sure you are on Michael Krufky's latest patches. 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
Re: [PATCH] VIDEO: ivtvfb, remove unneeded NULL test
On Tue, 2010-06-22 at 13:41 +0200, Jiri Slaby wrote:
Stanse found that in ivtvfb_callback_cleanup there is an unneeded test
for itv being NULL. But itv is initialized as container_of with
non-zero offset, so it is never NULL (even if v4l2_dev is). This was
found because itv is dereferenced earlier than the test.
Signed-off-by: Jiri Slaby jsl...@suse.cz
Cc: Andy Walls awa...@md.metrocast.net
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Tejun Heo t...@kernel.org
Cc: Ian Armstrong i...@iarmst.demon.co.uk
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-media@vger.kernel.org
---
drivers/media/video/ivtv/ivtvfb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/ivtv/ivtvfb.c
b/drivers/media/video/ivtv/ivtvfb.c
index 9ff3425..5dc460e 100644
--- a/drivers/media/video/ivtv/ivtvfb.c
+++ b/drivers/media/video/ivtv/ivtvfb.c
@@ -1219,7 +1219,7 @@ static int ivtvfb_callback_cleanup(struct device *dev,
void *p)
struct ivtv *itv = container_of(v4l2_dev, struct ivtv, v4l2_dev);
struct osd_info *oi = itv-osd_info;
- if (itv (itv-v4l2_cap V4L2_CAP_VIDEO_OUTPUT)) {
+ if (itv-v4l2_cap V4L2_CAP_VIDEO_OUTPUT) {
if (unregister_framebuffer(itv-osd_info-ivtvfb_info)) {
IVTVFB_WARN(Framebuffer %d is in use, cannot unload\n,
itv-instance);
Jiri,
You missed an identical instance of the useless test 10 lines prior in
ivtvfb_callback_init(). :)
How about the patch below, instead?
Regards,
Andy
[PATCH] VIDEO: ivtvfb, fix NULL check
Jiri Slaby reported that stanse found ivtvfb_callback_cleanup has an
unneeded test for itv being NULL. itv was initialized as container_of
with non-zero offset, so it was never NULL (even if v4l2_dev was).
This fix now checks for v4l2_dev being NULL, and not itv.
Thanks to Jiri Slaby for reporting this problem and providing an initial
patch.
Reported-by: Jiri Slaby jsl...@suse.cz
Signed-off-by: Andy Walls awa...@md.metrocast.net
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Tejun Heo t...@kernel.org
Cc: Ian Armstrong i...@iarmst.demon.co.uk
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-media@vger.kernel.org
drivers/media/video/ivtv/ivtvfb.c | 21 -
1 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/ivtv/ivtvfb.c b/drivers/media/video/ivtv/ivtvfb
index 9ff3425..2b3259c 100644
--- a/drivers/media/video/ivtv/ivtvfb.c
+++ b/drivers/media/video/ivtv/ivtvfb.c
@@ -1201,9 +1201,14 @@ static int ivtvfb_init_card(struct ivtv *itv)
static int __init ivtvfb_callback_init(struct device *dev, void *p)
{
struct v4l2_device *v4l2_dev = dev_get_drvdata(dev);
- struct ivtv *itv = container_of(v4l2_dev, struct ivtv, v4l2_dev);
+ struct ivtv *itv;
- if (itv (itv-v4l2_cap V4L2_CAP_VIDEO_OUTPUT)) {
+ if (v4l2_dev == NULL)
+ return 0;
+
+ itv = container_of(v4l2_dev, struct ivtv, v4l2_dev);
+
+ if (itv-v4l2_cap V4L2_CAP_VIDEO_OUTPUT) {
if (ivtvfb_init_card(itv) == 0) {
IVTVFB_INFO(Framebuffer registered on %s\n,
itv-v4l2_dev.name);
@@ -1216,10 +1221,16 @@ static int __init ivtvfb_callback_init(struct device *de
static int ivtvfb_callback_cleanup(struct device *dev, void *p)
{
struct v4l2_device *v4l2_dev = dev_get_drvdata(dev);
- struct ivtv *itv = container_of(v4l2_dev, struct ivtv, v4l2_dev);
- struct osd_info *oi = itv-osd_info;
+ struct ivtv *itv;
+ struct osd_info *oi;
+
+ if (v4l2_dev == NULL)
+ return 0;
+
+ itv = container_of(v4l2_dev, struct ivtv, v4l2_dev);
+ oi = itv-osd_info;
- if (itv (itv-v4l2_cap V4L2_CAP_VIDEO_OUTPUT)) {
+ if (itv-v4l2_cap V4L2_CAP_VIDEO_OUTPUT) {
if (unregister_framebuffer(itv-osd_info-ivtvfb_info)) {
IVTVFB_WARN(Framebuffer %d is in use, cannot unload\n,
itv-instance);
--
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
[PATCHv6] mx2_camera: Add soc_camera support for i.MX25/i.MX27
This is the soc_camera support developed by Sascha Hauer for the i.MX27. Alan
Carvalho de Assis modified the original driver to get it working on more recent
kernels. I modified it further to add support for i.MX25. This driver has been
tested on i.MX25 and i.MX27 based platforms.
Signed-off-by: Baruch Siach bar...@tkos.co.il
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Changes v5 - v6
Typo fix: s/CONFIG_MX2_VIDEO/CONFIG_VIDEO_MX2_HOSTSUPPORT/
Changes v4 - v5
Comments from Uwe Kleine-König:
Enclose mx27 DMA related stuff in #ifdefs since the dma-mx1-mx2.h is no
longer accessible to mx25 builds
s/MX2_VIDEO/VIDEO_MX2_HOSTSUPPORT/
Changes v3 - v4
Address more comments from Guennadi Liakhovetski, including:
* Fix the double trigger handling of mx27 eMMA
* Add a FIXME comment in the code of eMMA overflow handling
Changes v2 - v3
Address more comments from Guennadi Liakhovetski.
Applied part of Sashca's patch that I forgot in v2.
Changes v1 - v2
Addressed the comments of Guennadi Liakhovetski except from the following:
1. The mclk_get_divisor implementation, since I don't know what this code
is good for
2. mx2_videobuf_release should not set pcdev-active on i.MX27, because
mx27_camera_frame_done needs this pointer
3. In mx27_camera_emma_buf_init I don't know the meaning of those hard
coded magic numbers
Applied i.MX27 fixes from Sascha.
arch/arm/plat-mxc/include/mach/memory.h |4 +-
arch/arm/plat-mxc/include/mach/mx2_cam.h | 46 +
drivers/media/video/Kconfig | 13 +
drivers/media/video/Makefile |1 +
drivers/media/video/mx2_camera.c | 1513 ++
5 files changed, 1575 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/plat-mxc/include/mach/mx2_cam.h
create mode 100644 drivers/media/video/mx2_camera.c
diff --git a/arch/arm/plat-mxc/include/mach/memory.h
b/arch/arm/plat-mxc/include/mach/memory.h
index c4b40c3..564ec9d 100644
--- a/arch/arm/plat-mxc/include/mach/memory.h
+++ b/arch/arm/plat-mxc/include/mach/memory.h
@@ -44,12 +44,12 @@
*/
#define CONSISTENT_DMA_SIZE SZ_8M
-#elif defined(CONFIG_MX1_VIDEO)
+#elif defined(CONFIG_MX1_VIDEO) || defined(CONFIG_VIDEO_MX2_HOSTSUPPORT)
/*
* Increase size of DMA-consistent memory region.
* This is required for i.MX camera driver to capture at least four VGA frames.
*/
#define CONSISTENT_DMA_SIZE SZ_4M
-#endif /* CONFIG_MX1_VIDEO */
+#endif /* CONFIG_MX1_VIDEO || CONFIG_VIDEO_MX2_HOSTSUPPORT */
#endif /* __ASM_ARCH_MXC_MEMORY_H__ */
diff --git a/arch/arm/plat-mxc/include/mach/mx2_cam.h
b/arch/arm/plat-mxc/include/mach/mx2_cam.h
new file mode 100644
index 000..3c080a3
--- /dev/null
+++ b/arch/arm/plat-mxc/include/mach/mx2_cam.h
@@ -0,0 +1,46 @@
+/*
+ * mx2-cam.h - i.MX27/i.MX25 camera driver header file
+ *
+ * Copyright (C) 2003, Intel Corporation
+ * Copyright (C) 2008, Sascha Hauer s.ha...@pengutronix.de
+ * Copyright (C) 2010, Baruch Siach bar...@tkos.co.il
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#ifndef __MACH_MX2_CAM_H_
+#define __MACH_MX2_CAM_H_
+
+#define MX2_CAMERA_SWAP16 (1 0)
+#define MX2_CAMERA_EXT_VSYNC (1 1)
+#define MX2_CAMERA_CCIR(1 2)
+#define MX2_CAMERA_CCIR_INTERLACE (1 3)
+#define MX2_CAMERA_HSYNC_HIGH (1 4)
+#define MX2_CAMERA_GATED_CLOCK (1 5)
+#define MX2_CAMERA_INV_DATA(1 6)
+#define MX2_CAMERA_PCLK_SAMPLE_RISING (1 7)
+#define MX2_CAMERA_PACK_DIR_MSB(1 8)
+
+/**
+ * struct mx2_camera_platform_data - optional platform data for mx2_camera
+ * @flags: any combination of MX2_CAMERA_*
+ * @clk: clock rate of the csi block / 2
+ */
+struct mx2_camera_platform_data {
+ unsigned long flags;
+ unsigned long clk;
+};
+
+#endif /* __MACH_MX2_CAM_H_ */
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index bdbc9d3..27e2acc 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -969,6 +969,19 @@ config VIDEO_OMAP2
---help---
This is a v4l2 driver for the TI OMAP2 camera capture interface
+config VIDEO_MX2_HOSTSUPPORT
+bool
+
+config VIDEO_MX2
+ tristate i.MX27/i.MX25
