Re: Remote that breaks current system
Hi Jarod, on 11 Aug 10 at 10:38, Jarod Wilson wrote: On Mon, Aug 2, 2010 at 4:42 PM, Jon Smirl jonsm...@gmail.com wrote: On Mon, Aug 2, 2010 at 2:09 PM, Jarod Wilson ja...@redhat.com wrote: On Mon, Aug 02, 2010 at 01:13:22PM -0400, Jon Smirl wrote: On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus l...@bartelmus.de wrote: It has nothing to do with start bits. The Streamzap remote just sends 14 (sic!) bits instead of 13. The decoder expects 13 bits. Yes, the Streamzap remote does _not_ use standard RC-5. Did I mention this already? Yes. ;-) If the remote is sending a weird protocol then there are several choices: 1) implement raw mode 2) make a Stream-Zap protocol engine (it would be a 14b version of RC-5). Standard RC5 engine will still reject the messages. 3) throw away your Stream-Zap remotes I'd vote for #3, but #2 will probably make people happier. Hm. Yeah, I know a few people who are quite attached to their Streamzap remotes. I'm not a particularly big fan of it, I only got the thing off ebay to have the hardware so I could work on the driver. :) So yeah, #3 is probably not the best route. But I don't know that I'm a huge fan of #2 either. Another decoder engine just for one quirky remote seems excessive, and there's an option #4: 4) just keep passing data out to lirc by default. That's a decent idea. Implement the mainstream, standard protocols in the kernel and kick the weird stuff out to LIRC. We can avoid the whole world of raw mode, config files, etc. Let LIRC deal with all that. If the weird stuff gets enough users bring it in-kernel. Maybe StreamZap will suddenly sell a million units, you never know. It is easy to implement a StreamZap engine. Just copy the RC5 one. Rename everything and adjust it to require one more bit. You'll have to modify the RC5 to wait for a bit interval (timeout) before sending the data up. If you want to get fancy use a weak symbol in the StrreamZap engine to tell the RC5 engine if Stream Zap is loaded. Then you can decide to wait the extra bit interval or not. The other thought I had was to not load the engine by default, and only auto-load it from the streamzap driver itself. Let lircd handle the default remote in this case. If you want to use another remote that actually uses a standard protocol, and want to use in-kernel decoding for that, its just an ir-keytable call away. For giggles, I may tinker with implementing another decoder engine though, if only to force myself to actually pay more attention to protocol specifics. For the moment, I'm inclined to go ahead with the streamzap port as it is right now, and include either an empty or not-empty, but not-functional key table. So I spent a while beating on things the past few nights for giggles (and for a sanity break from vacation with too many kids...). I ended up doing a rather large amount of somewhat invasive work to the streamzap driver itself, but the end result is functional in-kernel decoding, and lirc userspace decode continues to behave correctly. RFC patch here: http://wilsonet.com/jarod/ir-core/IR-streamzap-in-kernel-decode.patch Core changes to streamzap.c itself: - had to enable reporting of a long space at the conclusion of each signal (which is what the lirc driver would do w/timeout_enabled set), otherwise I kept having issues with key bounce and/or old data being buffered (i.e., press up, cursor moves up. push down, cursor moves up then down, press left, it moves down, then left, etc.). Still not quite sure what the real problem is there, the lirc userspace decoder has no problems with it either way. - removed streamzap's internal delay buffer, as the ir-core kfifo seems to provide the necessary signal buffering just fine by itself. Can't see any significant difference in decode performance either in-kernel or via lirc with it removed, anyway. (Christoph, can you perhaps expand a bit on why the delay buffer was originally needed/how to reproduce the problem it was intended to solve? Maybe I'm just not triggering it yet.) Should be fine. Current lircd with timeout support shouldn't have a problem with that anymore. I was already thinking of suggesting to remove the delay buffer. Other fun stuff to note: - currently, loading up an rc5-sz decoder unconditionally, have considered only auto-loading it from the streamzap driver itself. Its a copy of the rc5 decoder with relatively minor tweaks to deal with the extra bit and resulting slightly different bit layout. Might actually be possible to merge back into the rc5 decoder itself, haven't really looked into that yet (should be entirely doable if there's an easy way to figure out early on if we need to grab 14 bits). There is no way until you see the 14th bit. - not sure the decoder is 100% correct, but it does get to the same scancodes as the lirc userspace now (with both a streamzap and mceusb receiver). Christoph -- To
[patch] V4L/DVB: unlock on error path
If we return directly here then we miss out on some mutex_unlock()s Signed-off-by: Dan Carpenter erro...@gmail.com diff --git a/drivers/media/video/s5p-fimc/fimc-core.c b/drivers/media/video/s5p-fimc/fimc-core.c index b151c7b..1beb226 100644 --- a/drivers/media/video/s5p-fimc/fimc-core.c +++ b/drivers/media/video/s5p-fimc/fimc-core.c @@ -822,7 +822,8 @@ static int fimc_m2m_s_fmt(struct file *file, void *priv, struct v4l2_format *f) } else { v4l2_err(ctx-fimc_dev-m2m.v4l2_dev, Wrong buffer/video queue type (%d)\n, f-type); - return -EINVAL; + ret = -EINVAL; + goto s_fmt_out; } pix = f-fmt.pix; -- 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: ene_ir: problems in unwinding on probe
There were a couple issues here. If the allocation failed for dev then it would lead to a NULL dereference. If request_irq() or request_region() failed it would release the irq and the region even though they were not successfully aquired. Signed-off-by: Dan Carpenter erro...@gmail.com diff --git a/drivers/media/IR/ene_ir.c b/drivers/media/IR/ene_ir.c index 5447750..8e5e964 100644 --- a/drivers/media/IR/ene_ir.c +++ b/drivers/media/IR/ene_ir.c @@ -781,21 +781,24 @@ static int ene_probe(struct pnp_dev *pnp_dev, const struct pnp_device_id *id) /* allocate memory */ input_dev = input_allocate_device(); + if (!input_dev) + goto err_out; ir_props = kzalloc(sizeof(struct ir_dev_props), GFP_KERNEL); + if (!ir_props) + goto err_input_dev; dev = kzalloc(sizeof(struct ene_device), GFP_KERNEL); - - if (!input_dev || !ir_props || !dev) - goto error; + if (!dev) + goto err_ir_props; /* validate resources */ error = -ENODEV; if (!pnp_port_valid(pnp_dev, 0) || pnp_port_len(pnp_dev, 0) ENE_MAX_IO) - goto error; + goto err_dev; if (!pnp_irq_valid(pnp_dev, 0)) - goto error; + goto err_dev; dev-hw_io = pnp_port_start(pnp_dev, 0); dev-irq = pnp_irq(pnp_dev, 0); @@ -804,11 +807,11 @@ static int ene_probe(struct pnp_dev *pnp_dev, const struct pnp_device_id *id) /* claim the resources */ error = -EBUSY; if (!request_region(dev-hw_io, ENE_MAX_IO, ENE_DRIVER_NAME)) - goto error; + goto err_dev; if (request_irq(dev-irq, ene_isr, IRQF_SHARED, ENE_DRIVER_NAME, (void *)dev)) - goto error; + goto err_region; pnp_set_drvdata(pnp_dev, dev); dev-pnp_dev = pnp_dev; @@ -816,7 +819,7 @@ static int ene_probe(struct pnp_dev *pnp_dev, const struct pnp_device_id *id) /* detect hardware version and features */ error = ene_hw_detect(dev); if (error) - goto error; + goto err_irq; ene_setup_settings(dev); @@ -889,20 +892,22 @@ static int ene_probe(struct pnp_dev *pnp_dev, const struct pnp_device_id *id) error = -ENODEV; if (ir_input_register(input_dev, RC_MAP_RC6_MCE, ir_props, ENE_DRIVER_NAME)) - goto error; - + goto err_irq; ene_printk(KERN_NOTICE, driver has been succesfully loaded\n); return 0; -error: - if (dev-irq) - free_irq(dev-irq, dev); - if (dev-hw_io) - release_region(dev-hw_io, ENE_MAX_IO); - input_free_device(input_dev); - kfree(ir_props); +err_irq: + free_irq(dev-irq, dev); +err_region: + release_region(dev-hw_io, ENE_MAX_IO); +err_dev: kfree(dev); +err_ir_props: + kfree(ir_props); +err_input_dev: + input_free_device(input_dev); +err_out: return error; } -- 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: ir-raw-event: null pointer dereference
The original code dereferenced ir-raw after freeing it and setting it to NULL. Signed-off-by: Dan Carpenter erro...@gmail.com diff --git a/drivers/media/IR/ir-raw-event.c b/drivers/media/IR/ir-raw-event.c index 43094e7..8e0e1b1 100644 --- a/drivers/media/IR/ir-raw-event.c +++ b/drivers/media/IR/ir-raw-event.c @@ -279,9 +279,11 @@ int ir_raw_event_register(struct input_dev *input_dev) rc%u, (unsigned int)ir-devno); if (IS_ERR(ir-raw-thread)) { + int ret = PTR_ERR(ir-raw-thread); + kfree(ir-raw); ir-raw = NULL; - return PTR_ERR(ir-raw-thread); + return ret; } mutex_lock(ir_raw_handler_lock); -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dvb_net.c:1237: error: ‘struct net_device’ has no member
hi with 2.6.35 kernel and current v4l-dvb I have other errors as described here is http://www.kernellabs.com/blog/?p=1397 CC [M] /home/fabio/src/v4l-dvb-drxd/v4l/dvb_filter.o CC [M] /home/fabio/src/v4l-dvb-drxd/v4l/dvb_ca_en50221.o CC [M] /home/fabio/src/v4l-dvb-drxd/v4l/dvb_frontend.o CC [M] /home/fabio/src/v4l-dvb-drxd/v4l/dvb_net.o /home/fabio/src/v4l-dvb-drxd/v4l/dvb_net.c:1179: warning: ‘struct dev_mc_list’ declared inside parameter list /home/fabio/src/v4l-dvb-drxd/v4l/dvb_net.c:1179: warning: its scope is only this definition or declaration, which is probably not what you want /home/fabio/src/v4l-dvb-drxd/v4l/dvb_net.c: In function ‘dvb_set_mc_filter’: /home/fabio/src/v4l-dvb-drxd/v4l/dvb_net.c:1186: error: dereferencing pointer to incomplete type /home/fabio/src/v4l-dvb-drxd/v4l/dvb_net.c: In function ‘wq_set_multicast_list’: /home/fabio/src/v4l-dvb-drxd/v4l/dvb_net.c:1226: error: ‘struct net_device’ has no member named ‘mc_count’ /home/fabio/src/v4l-dvb-drxd/v4l/dvb_net.c:1230: error: ‘struct net_device’ has no member named ‘mc_count’ /home/fabio/src/v4l-dvb-drxd/v4l/dvb_net.c:1236: error: ‘struct net_device’ has no member named ‘mc_list’ /home/fabio/src/v4l-dvb-drxd/v4l/dvb_net.c:1237: error: ‘struct net_device’ has no member named ‘mc_count’ /home/fabio/src/v4l-dvb-drxd/v4l/dvb_net.c:1238: error: dereferencing pointer to incomplete type /home/fabio/src/v4l-dvb-drxd/v4l/dvb_net.c:1238: warning: left-hand operand of comma expression has no effect /home/fabio/src/v4l-dvb-drxd/v4l/dvb_net.c:1238: warning: value computed is not used /home/fabio/src/v4l-dvb-drxd/v4l/dvb_net.c:1239: warning: passing argument 2 of ‘dvb_set_mc_filter’ from incompatible pointer type /home/fabio/src/v4l-dvb-drxd/v4l/dvb_net.c:1179: note: expected ‘struct dev_mc_list *’ but argument is of type ‘struct dev_mc_list *’ /home/fabio/src/v4l-dvb-drxd/v4l/dvb_net.c: In function ‘dvb_net_setup’: /home/fabio/src/v4l-dvb-drxd/v4l/dvb_net.c:1363: error: ‘struct net_device’ has no member named ‘mc_count’ make[3]: *** [/home/fabio/src/v4l-dvb-drxd/v4l/dvb_net.o] Error 1 make[2]: *** [_module_/home/fabio/src/v4l-dvb-drxd/v4l] Error 2 make[2]: Leaving directory `/usr/src/kernels/2.6.35-kal.i686′ make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/fabio/src/v4l-dvb-drxd/v4l’ make: *** [all] Error 2 hope that it will fix soon Goga -- 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: A problem with http://git.linuxtv.org/media_tree.git
On Wed, 2010-08-11 at 15:16 +0200, ext Mauro Carvalho Chehab wrote: Em 11-08-2010 08:44, Matti J. Aaltonen escreveu: Hi again. On Wed, 2010-08-11 at 14:34 +0300, Matti J. Aaltonen wrote: Hello. On Wed, 2010-08-11 at 12:56 +0200, ext Hans Verkuil wrote: Hi. I cloned your tree athttp://linuxtv.org/git/media_tree.git and checked out the origin/staging/v2.6.37 branch and the Documentation/video4linux/v4l2-controls.txt just isn't there. I asked one of my colleagues to do the same and the result was also the same. The file is in the v2.6.36 branch. It hasn't been merged yet in the v2.6.37 branch. 37 above was a typo, sorry. My point was that we couldn't find it in the origin/staging/v2.6.36 branch... and that the branch lags behind of what can be seen via the git web interface... B.R. Matti I'd suggest - if that's not too much trouble - that you'd clone the tree using http (from http://linuxtv.org/git/media_tree.git) and then checked out the 36 branch and see that it works for you and then post the command you used and then I'll admit what I did wrong - if necessary:-) You should try to avoid using http method for clone/fetch. It depends on some files that are created by running git update-server-info. There's a script to run it automatically after each push. Yet, the better is to use git. I guess I didn't emphasize my point enough... I would avoid using http if it wasn't the only protocol I can use to access your site... And if you have serious problems with it I think it would be fair to mention that on your git web page... Anyway, I tried it again just a moment ago and got: .. got f08c0c2dab44348919ec296254c3cc39d34e9f85 walk a63ecd835f075b21d7d5cef9580447f5fbb36263 error: Unable to find 4648030cc15d5a0ab19505774abe2a042c7d9ee3 under http://linuxtv.org/git/media_tree.git Cannot obtain needed tree 4648030cc15d5a0ab19505774abe2a042c7d9ee3 while processing commit a63ecd835f075b21d7d5cef9580447f5fbb36263. fatal: Fetch failed. Cheers, Matti I've just ran it right now. Maybe this solved the issue. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A problem with http://git.linuxtv.org/media_tree.git
On Wed, 2010-08-11 at 15:16 +0200, ext Mauro Carvalho Chehab wrote: Em 11-08-2010 08:44, Matti J. Aaltonen escreveu: Hi again. On Wed, 2010-08-11 at 14:34 +0300, Matti J. Aaltonen wrote: Hello. On Wed, 2010-08-11 at 12:56 +0200, ext Hans Verkuil wrote: Hi. I cloned your tree at http://linuxtv.org/git/media_tree.git and checked out the origin/staging/v2.6.37 branch and the Documentation/video4linux/v4l2-controls.txt just isn't there. I asked one of my colleagues to do the same and the result was also the same. The file is in the v2.6.36 branch. It hasn't been merged yet in the v2.6.37 branch. 37 above was a typo, sorry. My point was that we couldn't find it in the origin/staging/v2.6.36 branch... and that the branch lags behind of what can be seen via the git web interface... B.R. Matti I'd suggest - if that's not too much trouble - that you'd clone the tree using http (from http://linuxtv.org/git/media_tree.git) and then checked out the 36 branch and see that it works for you and then post the command you used and then I'll admit what I did wrong - if necessary:-) You should try to avoid using http method for clone/fetch. It depends on some files that are created by running git update-server-info. There's a script to run it automatically after each push. Yet, the better is to use git. I guess I didn't emphasize my point enough... I would avoid using http if it wasn't the only protocol I can use to access your site... And if you have serious problems with it I think it would be fair to mention that on your git web page... FYI: the control framework has been merged into the mainline, so you can get it from there as well. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- 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: A problem with http://git.linuxtv.org/media_tree.git
On Thu, 2010-08-12 at 12:29 +0200, ext Hans Verkuil wrote: On Wed, 2010-08-11 at 15:16 +0200, ext Mauro Carvalho Chehab wrote: Em 11-08-2010 08:44, Matti J. Aaltonen escreveu: Hi again. On Wed, 2010-08-11 at 14:34 +0300, Matti J. Aaltonen wrote: Hello. On Wed, 2010-08-11 at 12:56 +0200, ext Hans Verkuil wrote: Hi. I cloned your tree at http://linuxtv.org/git/media_tree.git and checked out the origin/staging/v2.6.37 branch and the Documentation/video4linux/v4l2-controls.txt just isn't there. I asked one of my colleagues to do the same and the result was also the same. The file is in the v2.6.36 branch. It hasn't been merged yet in the v2.6.37 branch. 37 above was a typo, sorry. My point was that we couldn't find it in the origin/staging/v2.6.36 branch... and that the branch lags behind of what can be seen via the git web interface... B.R. Matti I'd suggest - if that's not too much trouble - that you'd clone the tree using http (from http://linuxtv.org/git/media_tree.git) and then checked out the 36 branch and see that it works for you and then post the command you used and then I'll admit what I did wrong - if necessary:-) You should try to avoid using http method for clone/fetch. It depends on some files that are created by running git update-server-info. There's a script to run it automatically after each push. Yet, the better is to use git. I guess I didn't emphasize my point enough... I would avoid using http if it wasn't the only protocol I can use to access your site... And if you have serious problems with it I think it would be fair to mention that on your git web page... FYI: the control framework has been merged into the mainline, so you can get it from there as well. OK, good, the mainline tree can be cloned over http... Thanks, Matti 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
Re: [PATCH v7 4/5] V4L2: WL1273 FM Radio: Controls for the FM radio.
Hello Alexey On Wed, 2010-08-11 at 10:06 +0200, ext Alexey Klimov wrote: + + radio = kzalloc(sizeof(*radio), GFP_KERNEL); + if (!radio) + return -ENOMEM; + + radio-write_buf = kmalloc(256, GFP_KERNEL); + if (!radio-write_buf) + return -ENOMEM; I'm not sure but it looks like possible memory leak. Shouldn't you call to kfree(radio) before returning ENOMEM? Yes you're right... et_drvdata(radio-videodev, radio); + platform_set_drvdata(pdev, radio); + + return 0; + +err_video_register: + v4l2_device_unregister(radio-v4l2dev); +err_device_alloc: + kfree(radio); And i'm not sure about this error path.. Before kfree(radio) it's needed to call kfree(radio-write_buf), rigth? Looks like all erorr paths in this probe function have to be checked. Yes, I'll the the error handling here... Thanks, Matti -- Best regards, Klimov -- 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 4/5] V4L2: WL1273 FM Radio: Controls for the FM radio.
Matti, +/** + * wl1273_fm_set_tx_power() - Set the transmission power value. + * @core: A pointer to the device struct. + * @power: The new power value. + */ +static int wl1273_fm_set_tx_power(struct wl1273_core *core, u16 power) +{ + int r; + + if (core-mode == WL1273_MODE_OFF || + core-mode == WL1273_MODE_SUSPENDED) + return -EPERM; + + mutex_lock(core-lock); + + r = wl1273_fm_write_cmd(core, WL1273_POWER_LEV_SET, power); Output power level is specified in units of dBuV (as explained at http://www.linuxtv.org/downloads/v4l-dvb-apis/ch01s09.html#fm-tx-controls). Shouldn't it be converted to WL1273 specific power level value? My understanding: If output power level specified using V4L2_CID_TUNE_POWER_LEVEL is 122 (dB/uV), then power level value to be passed for WL1273 should be '0'. Please correct me, if I got this conversion wrong. Thanks and regards, Pramodh -- 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 4/5] V4L2: WL1273 FM Radio: Controls for the FM radio.
Hello. On Thu, 2010-08-12 at 14:10 +0200, ext pramodh ag wrote: Matti, +/** + * wl1273_fm_set_tx_power() -Set the transmission power value. + * @core:A pointer to the device struct. + * @power:The new power value. + */ +static int wl1273_fm_set_tx_power(struct wl1273_core *core, u16 power) +{ +int r; + +if (core-mode == WL1273_MODE_OFF || +core-mode == WL1273_MODE_SUSPENDED) +return -EPERM; + +mutex_lock(core-lock); + +r = wl1273_fm_write_cmd(core, WL1273_POWER_LEV_SET, power); Output power level is specified in units of dBuV (as explained at http://www.linuxtv.org/downloads/v4l-dvb-apis/ch01s09.html#fm-tx-controls). Shouldn't it be converted to WL1273 specific power level value? My understanding: If output power level specified using V4L2_CID_TUNE_POWER_LEVEL is 122 (dB/uV), then power level value to be passed for WL1273 should be '0'. Please correct me, if I got this conversion wrong. Thank you for pointing that out. I'll check and fix it... Regards, Matti Thanks and regards, Pramodh -- 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: ene_ir: problems in unwinding on probe
On Thu, 2010-08-12 at 09:46 +0200, Dan Carpenter wrote: There were a couple issues here. If the allocation failed for dev then it would lead to a NULL dereference. If request_irq() or request_region() failed it would release the irq and the region even though they were not successfully aquired. Signed-off-by: Dan Carpenter erro...@gmail.com I don't think this is needed. I just alloc all the stuff, and if one of allocations fail, I free them all. {k}free on NULL pointer is perfectly legal. Same about IO and IRQ. IRQ0 and IO 0 isn't valid, and I do test that in error path. Best regards, Maxim Levitsky diff --git a/drivers/media/IR/ene_ir.c b/drivers/media/IR/ene_ir.c index 5447750..8e5e964 100644 --- a/drivers/media/IR/ene_ir.c +++ b/drivers/media/IR/ene_ir.c @@ -781,21 +781,24 @@ static int ene_probe(struct pnp_dev *pnp_dev, const struct pnp_device_id *id) /* allocate memory */ input_dev = input_allocate_device(); + if (!input_dev) + goto err_out; ir_props = kzalloc(sizeof(struct ir_dev_props), GFP_KERNEL); + if (!ir_props) + goto err_input_dev; dev = kzalloc(sizeof(struct ene_device), GFP_KERNEL); - - if (!input_dev || !ir_props || !dev) - goto error; + if (!dev) + goto err_ir_props; /* validate resources */ error = -ENODEV; if (!pnp_port_valid(pnp_dev, 0) || pnp_port_len(pnp_dev, 0) ENE_MAX_IO) - goto error; + goto err_dev; if (!pnp_irq_valid(pnp_dev, 0)) - goto error; + goto err_dev; dev-hw_io = pnp_port_start(pnp_dev, 0); dev-irq = pnp_irq(pnp_dev, 0); @@ -804,11 +807,11 @@ static int ene_probe(struct pnp_dev *pnp_dev, const struct pnp_device_id *id) /* claim the resources */ error = -EBUSY; if (!request_region(dev-hw_io, ENE_MAX_IO, ENE_DRIVER_NAME)) - goto error; + goto err_dev; if (request_irq(dev-irq, ene_isr, IRQF_SHARED, ENE_DRIVER_NAME, (void *)dev)) - goto error; + goto err_region; pnp_set_drvdata(pnp_dev, dev); dev-pnp_dev = pnp_dev; @@ -816,7 +819,7 @@ static int ene_probe(struct pnp_dev *pnp_dev, const struct pnp_device_id *id) /* detect hardware version and features */ error = ene_hw_detect(dev); if (error) - goto error; + goto err_irq; ene_setup_settings(dev); @@ -889,20 +892,22 @@ static int ene_probe(struct pnp_dev *pnp_dev, const struct pnp_device_id *id) error = -ENODEV; if (ir_input_register(input_dev, RC_MAP_RC6_MCE, ir_props, ENE_DRIVER_NAME)) - goto error; - + goto err_irq; ene_printk(KERN_NOTICE, driver has been succesfully loaded\n); return 0; -error: - if (dev-irq) - free_irq(dev-irq, dev); - if (dev-hw_io) - release_region(dev-hw_io, ENE_MAX_IO); - input_free_device(input_dev); - kfree(ir_props); +err_irq: + free_irq(dev-irq, dev); +err_region: + release_region(dev-hw_io, ENE_MAX_IO); +err_dev: kfree(dev); +err_ir_props: + kfree(ir_props); +err_input_dev: + input_free_device(input_dev); +err_out: return error; } -- 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: ene_ir: problems in unwinding on probe
On Thu, Aug 12, 2010 at 05:35:04PM +0300, Maxim Levitsky wrote: On Thu, 2010-08-12 at 09:46 +0200, Dan Carpenter wrote: There were a couple issues here. If the allocation failed for dev then it would lead to a NULL dereference. If request_irq() or request_region() failed it would release the irq and the region even though they were not successfully aquired. Signed-off-by: Dan Carpenter erro...@gmail.com I don't think this is needed. I just alloc all the stuff, and if one of allocations fail, I free them all. {k}free on NULL pointer is perfectly legal. Same about IO and IRQ. IRQ0 and IO 0 isn't valid, and I do test that in error path. Here is the original code: Here is where we set dev. 785 dev = kzalloc(sizeof(struct ene_device), GFP_KERNEL); 786 787 if (!input_dev || !ir_props || !dev) 788 goto error; [snip] Here is where we set the IO and IRQ: 800 dev-hw_io = pnp_port_start(pnp_dev, 0); 801 dev-irq = pnp_irq(pnp_dev, 0); [snip] Here is where the request_region() and request_irq() are. 806 if (!request_region(dev-hw_io, ENE_MAX_IO, ENE_DRIVER_NAME)) 807 goto error; 808 809 if (request_irq(dev-irq, ene_isr, 810 IRQF_SHARED, ENE_DRIVER_NAME, (void *)dev)) 811 goto error; [snip] Here is the error label: 897 error: 898 if (dev-irq) Oops! The allocation of dev failed and this is a NULL dereference. 899 free_irq(dev-irq, dev); Oops! Request region failed and dev-irq is non-zero but request_irq() hasn't been called. 900 if (dev-hw_io) 901 release_region(dev-hw_io, ENE_MAX_IO); Oops! dev-hw_io is non-zero but request_region() failed and so we just released someone else's region. Hehe. :P regards, dan carpenter -- 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: libdvbsec - trying to control DiSEqC positioner
Hi. We are trying to use the libdvbsec-api from the dvb-apps package (/dvb_apps/lib/libdvbsec) to build our own DiSEqC positioner control. It's going to implement a kind of USALS/GotoX/GotoXX/DiSEqC1.3, whatever you want to call it (there's no hardware receiver provided atm). But at the moment there are a few problems with the positioner: For getting started I took a look at /util/gotox/gotox.c. In this file the function dvbsec_diseqc_goto_rotator_bearing is used. This function is for turning to a specific angle. (using 0x6E as command byte) For any reason our rotor/motor/positioner only wants to turn to western degrees (but in the full range of 75°W..0°). The positioner: JAEGER Genuine SG-2500A DiSEqC 1.2 H-H MOUNT I think this seems to be an OEM product as I compared several positioners. They all have the same instruction manual, pictures, ... I checked the hardware limits; they were not set. So theoretically the range of movement is 75°W..0°..75°E. I also tried to delete theoretical software limits by - calling the dvbsec_diseqc_disable_satpos_limits command before calling the dvbsec_diseqc_goto_rotator_bearing command - tried the same sending the raw DiSEqC command message (command byte 0x63) The positioner can manually be rotated in the complete range of movement of 75°W..0°..75°E. As I don't really want to manually control the motor any time and the dvbsec_diseqc_goto_rotator_bearing function doesn't work for me, I tried using the dvbsec_diseqc_goto_satpos_preset function. This works quite well, also for satellite with eastern longitude. The problem is: when choosing Astra (19.2E) for example, the motor of course turns to 19.2°E. This only works for your own position when you live at longitude 0°. This is why these motors provide something called recalculation/resynchronization. You go to the preset satellite position and correct the difference in longitude by manually turning the positioner. Afterwards you have to tell the positioner to correct all the satellite positions. This normally only has to be done once. Here the lib also offers a command: dvbsec_diseqc_recalculate_satpos_positions. I tried using it after calling the dvbsec_diseqc_goto_satpos_preset function. Unfortunately I am not quite sure which arguments to deliver. I once tried -1, -1 and then 0x00 0x00 and the the index number of the builtin satellite table entry. I am not sure how to use it correctly, but all in all it didn't work. Coming back to the dvbsec_diseqc_goto_rotator_bearing function: I am not sure if the specifications/ application notes which were made public are too old (I directly downloaded the files from EUTELSAT[1]), the implementation in the positioner differs, code in the lib is wrong or something else doesn't work correctly: If the angle delivered to the function is negative, the high nibble of byte 3 (the 4th byte) of the DiSEqC message is set to 0xD, else it's set to 0xE. The positioner application note (v1.0) says the high nibble of byte 3 is 0x0, 0x1 or 0xF. Are there any further documents, implementations,... experience with positioners? Any help provided will be great! Thanks! Cheers, Matthias [1] http://www.eutelsat.com/satellites/4_5_5.html Bus Specification, Positioner Application Note, etc PS: Not quite sure if this mail was also sent to linux-dvb as I got a mail saying deprecated? -- 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: ene_ir: problems in unwinding on probe
On Thu, 2010-08-12 at 18:19 +0200, Dan Carpenter wrote: On Thu, Aug 12, 2010 at 05:35:04PM +0300, Maxim Levitsky wrote: On Thu, 2010-08-12 at 09:46 +0200, Dan Carpenter wrote: There were a couple issues here. If the allocation failed for dev then it would lead to a NULL dereference. If request_irq() or request_region() failed it would release the irq and the region even though they were not successfully aquired. Signed-off-by: Dan Carpenter erro...@gmail.com I don't think this is needed. I just alloc all the stuff, and if one of allocations fail, I free them all. {k}free on NULL pointer is perfectly legal. Same about IO and IRQ. IRQ0 and IO 0 isn't valid, and I do test that in error path. Here is the original code: Here is where we set dev. 785 dev = kzalloc(sizeof(struct ene_device), GFP_KERNEL); 786 787 if (!input_dev || !ir_props || !dev) 788 goto error; [snip] Here is where we set the IO and IRQ: 800 dev-hw_io = pnp_port_start(pnp_dev, 0); 801 dev-irq = pnp_irq(pnp_dev, 0); [snip] Here is where the request_region() and request_irq() are. 806 if (!request_region(dev-hw_io, ENE_MAX_IO, ENE_DRIVER_NAME)) 807 goto error; 808 809 if (request_irq(dev-irq, ene_isr, 810 IRQF_SHARED, ENE_DRIVER_NAME, (void *)dev)) 811 goto error; [snip] Here is the error label: 897 error: 898 if (dev-irq) Oops! The allocation of dev failed and this is a NULL dereference. 899 free_irq(dev-irq, dev); Oops! Request region failed and dev-irq is non-zero but request_irq() hasn't been called. 900 if (dev-hw_io) 901 release_region(dev-hw_io, ENE_MAX_IO); Oops! dev-hw_io is non-zero but request_region() failed and so we just released someone else's region. Ok, this is something different. To be honest I was in hurry when I prepared the patch, so I didn't look at this. The intent was correct, and untill you pointed that out I somehow assumed that error patch does what I supposed it to do... well... In few days I will switch back to this driver and fix this problem. I also have quite a lot of work to do in this driver now that I have some hardware documentation (register renames are the fun part...). So thanks for catching this. Best regards, Maxim Levitsky -- 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] fix v4l2-ctrls compilation
Current git has broken v4l2-ctrls compilation - kzalloc et al are missing prototypes. Fix it by including linux/slab.h that contains the definitions. Signed-off-by: Meelis Roos mr...@linux.ee diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c index 84c1a53..ea8d32c 100644 --- a/drivers/media/video/v4l2-ctrls.c +++ b/drivers/media/video/v4l2-ctrls.c @@ -19,6 +19,7 @@ */ #include linux/ctype.h +#include linux/slab.h #include media/v4l2-ioctl.h #include media/v4l2-device.h #include media/v4l2-ctrls.h -- Meelis Roos mr...@linux.ee -- 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
[GIT PULL for 2.6.36] V4L/DVB fixes
Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus For 3 build fixes. Cheers, Mauro. The following changes since commit ad41a1e0cab07c5125456e8d38e5b1ab148d04aa: Merge branch 'io_remap_pfn_range' of git://www.jni.nu/cris (2010-08-12 10:17:19 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus Mauro Carvalho Chehab (2): V4L/DVB: Fix IR_CORE dependencies V4L/DVB: fix Kconfig to depends on VIDEO_IR Randy Dunlap (1): V4L/DVB: v4l2-ctrls.c: needs to include slab.h drivers/media/IR/Kconfig|9 - drivers/media/dvb/dm1105/Kconfig|2 +- drivers/media/dvb/dvb-usb/Kconfig |2 +- drivers/media/dvb/siano/Kconfig |2 +- drivers/media/dvb/ttpci/Kconfig |2 +- drivers/media/video/bt8xx/Kconfig |2 +- drivers/media/video/cx18/Kconfig|2 +- drivers/media/video/cx231xx/Kconfig |2 +- drivers/media/video/cx23885/Kconfig |2 +- drivers/media/video/cx88/Kconfig|2 +- drivers/media/video/em28xx/Kconfig |2 +- drivers/media/video/ivtv/Kconfig|2 +- drivers/media/video/saa7134/Kconfig |2 +- drivers/media/video/tlg2300/Kconfig |2 +- drivers/media/video/v4l2-ctrls.c|1 + 15 files changed, 22 insertions(+), 14 deletions(-) -- 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: ir-raw-event: null pointer dereference
- Dan Carpenter erro...@gmail.com wrote: The original code dereferenced ir-raw after freeing it and setting it to NULL. Signed-off-by: Dan Carpenter erro...@gmail.com Acked-by: Jarod Wilson ja...@redhat.com -- 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 v2] V4L2: avoid name conflicts in macros
sd and err are too common names to be used in macros for local variables. Prefix them with an underscore to avoid name clashing. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- v2: as suggested by Mauro, also patched v4l2_device_call_all and v4l2_device_call_until_err, as well as ivtv and cx18 specific macros drivers/media/video/cx18/cx18-driver.h | 19 +++--- drivers/media/video/ivtv/ivtv-driver.h | 14 ++-- include/media/v4l2-device.h| 57 ++-- 3 files changed, 63 insertions(+), 27 deletions(-) diff --git a/drivers/media/video/cx18/cx18-driver.h b/drivers/media/video/cx18/cx18-driver.h index 9bc51a9..7e43c7b 100644 --- a/drivers/media/video/cx18/cx18-driver.h +++ b/drivers/media/video/cx18/cx18-driver.h @@ -674,18 +674,25 @@ static inline int cx18_raw_vbi(const struct cx18 *cx) /* Call the specified callback for all subdevs with a grp_id bit matching the * mask in hw (if 0, then match them all). Ignore any errors. */ -#define cx18_call_hw(cx, hw, o, f, args...) \ - __v4l2_device_call_subdevs((cx)-v4l2_dev, \ - !(hw) || (sd-grp_id (hw)), o, f , ##args) +#define cx18_call_hw(cx, hw, o, f, args...)\ + do {\ + struct v4l2_subdev *__sd; \ + __v4l2_device_call_subdevs_p((cx)-v4l2_dev, __sd, \ + !(hw) || (__sd-grp_id (hw)), o, f , ##args); \ + } while (0) #define cx18_call_all(cx, o, f, args...) cx18_call_hw(cx, 0, o, f , ##args) /* Call the specified callback for all subdevs with a grp_id bit matching the * mask in hw (if 0, then match them all). If the callback returns an error * other than 0 or -ENOIOCTLCMD, then return with that error code. */ -#define cx18_call_hw_err(cx, hw, o, f, args...) \ - __v4l2_device_call_subdevs_until_err( \ - (cx)-v4l2_dev, !(hw) || (sd-grp_id (hw)), o, f , ##args) +#define cx18_call_hw_err(cx, hw, o, f, args...) \ +({ \ + struct v4l2_subdev *__sd; \ + __v4l2_device_call_subdevs_until_err_p((cx)-v4l2_dev, \ + __sd, !(hw) || (__sd-grp_id (hw)), o, f, \ + ##args);\ +}) #define cx18_call_all_err(cx, o, f, args...) \ cx18_call_hw_err(cx, 0, o, f , ##args) diff --git a/drivers/media/video/ivtv/ivtv-driver.h b/drivers/media/video/ivtv/ivtv-driver.h index 7580314..e61252c 100644 --- a/drivers/media/video/ivtv/ivtv-driver.h +++ b/drivers/media/video/ivtv/ivtv-driver.h @@ -811,15 +811,23 @@ static inline int ivtv_raw_vbi(const struct ivtv *itv) /* Call the specified callback for all subdevs matching hw (if 0, then match them all). Ignore any errors. */ #define ivtv_call_hw(itv, hw, o, f, args...) \ - __v4l2_device_call_subdevs((itv)-v4l2_dev, !(hw) || (sd-grp_id (hw)), o, f , ##args) + do {\ + struct v4l2_subdev *__sd; \ + __v4l2_device_call_subdevs_p((itv)-v4l2_dev, __sd,\ + !(hw) || (__sd-grp_id (hw)), o, f , ##args); \ + } while (0) #define ivtv_call_all(itv, o, f, args...) ivtv_call_hw(itv, 0, o, f , ##args) /* Call the specified callback for all subdevs matching hw (if 0, then match them all). If the callback returns an error other than 0 or -ENOIOCTLCMD, then return with that error code. */ -#define ivtv_call_hw_err(itv, hw, o, f, args...) \ - __v4l2_device_call_subdevs_until_err((itv)-v4l2_dev, !(hw) || (sd-grp_id (hw)), o, f , ##args) +#define ivtv_call_hw_err(itv, hw, o, f, args...) \ +({ \ + struct v4l2_subdev *__sd; \ + __v4l2_device_call_subdevs_until_err_p((itv)-v4l2_dev, __sd, \ + !(hw) || (__sd-grp_id (hw)), o, f , ##args); \ +}) #define ivtv_call_all_err(itv, o, f, args...) ivtv_call_hw_err(itv, 0, o, f , ##args) diff --git a/include/media/v4l2-device.h b/include/media/v4l2-device.h index 8bcbd7a..fe10464 100644 --- a/include/media/v4l2-device.h +++ b/include/media/v4l2-device.h @@ -101,46 +101,67 @@ void v4l2_device_unregister_subdev(struct v4l2_subdev *sd); /* Call the specified callback for all subdevs matching the condition. Ignore any errors. Note that you cannot add or delete a subdev while walking the subdevs list. */ -#define __v4l2_device_call_subdevs(v4l2_dev, cond, o, f, args...) \ +#define __v4l2_device_call_subdevs_p(v4l2_dev, sd, cond, o, f, args...) \
Re: [PATCH] v4l2-ctrls.c was missing slab.h
On Thu, 12 Aug 2010, Christopher Friedt wrote: Fixed broken compile of drivers/media/video/v4l2-ctrls.c. It failed due to missing #include linux/slab.h, and errored-out with implicit declaration of function kzalloc, kmalloc, ... Signed-off-by: Christopher Friedt chrisfri...@gmail.com --- drivers/media/video/v4l2-ctrls.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c index 84c1a53..1d09804 100644 --- a/drivers/media/video/v4l2-ctrls.c +++ b/drivers/media/video/v4l2-ctrls.c @@ -18,6 +18,7 @@ Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ +#include linux/slab.h #include linux/ctype.h an alphabetic order is preferred, even if it is not preserved elsewhere in the file... Thanks Guennadi #include media/v4l2-ioctl.h #include media/v4l2-device.h -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- 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
[PATCH] soc-camera: initialise videobuf immediately before allocating them
Only the streamer process has to initialise videobufs. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Janusz, this and the following patch can be useful, if we decide to implement dynamic switching between videobuf implementations. Only compile-tested... drivers/media/video/soc_camera.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c index a499cac..d90386c 100644 --- a/drivers/media/video/soc_camera.c +++ b/drivers/media/video/soc_camera.c @@ -158,6 +158,8 @@ static int soc_camera_reqbufs(struct file *file, void *priv, WARN_ON(priv != file-private_data); + ici-ops-init_videobuf(icf-vb_vidq, icd); + ret = videobuf_reqbufs(icf-vb_vidq, p); if (ret 0) return ret; @@ -409,8 +411,6 @@ static int soc_camera_open(struct file *file) file-private_data = icf; dev_dbg(icd-dev, camera device open\n); - ici-ops-init_videobuf(icf-vb_vidq, icd); - mutex_unlock(icd-video_lock); return 0; -- 1.7.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] soc-camera: allow only one video queue per device
Multiple user-space application instances can open the same video device, but it only makes sense for one of them to manage the videobuffer queue and set video format of the device. Restrict soc-camera respectively. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Also compile tested only - I'm away from my hardware drivers/media/video/mx1_camera.c |8 +- drivers/media/video/mx3_camera.c |6 +- drivers/media/video/pxa_camera.c |8 +- drivers/media/video/sh_mobile_ceu_camera.c |8 +- drivers/media/video/soc_camera.c | 178 ++-- include/media/soc_camera.h |9 +- 6 files changed, 107 insertions(+), 110 deletions(-) diff --git a/drivers/media/video/mx1_camera.c b/drivers/media/video/mx1_camera.c index 5c17f9e..5173cb5 100644 --- a/drivers/media/video/mx1_camera.c +++ b/drivers/media/video/mx1_camera.c @@ -638,7 +638,7 @@ static int mx1_camera_try_fmt(struct soc_camera_device *icd, return 0; } -static int mx1_camera_reqbufs(struct soc_camera_file *icf, +static int mx1_camera_reqbufs(struct soc_camera_device *icd, struct v4l2_requestbuffers *p) { int i; @@ -650,7 +650,7 @@ static int mx1_camera_reqbufs(struct soc_camera_file *icf, * it hadn't triggered */ for (i = 0; i p-count; i++) { - struct mx1_buffer *buf = container_of(icf-vb_vidq.bufs[i], + struct mx1_buffer *buf = container_of(icd-vb_vidq.bufs[i], struct mx1_buffer, vb); buf-inwork = 0; INIT_LIST_HEAD(buf-vb.queue); @@ -661,10 +661,10 @@ static int mx1_camera_reqbufs(struct soc_camera_file *icf, static unsigned int mx1_camera_poll(struct file *file, poll_table *pt) { - struct soc_camera_file *icf = file-private_data; + struct soc_camera_device *icd = file-private_data; struct mx1_buffer *buf; - buf = list_entry(icf-vb_vidq.stream.next, struct mx1_buffer, + buf = list_entry(icd-vb_vidq.stream.next, struct mx1_buffer, vb.stream); poll_wait(file, buf-vb.done, pt); diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c index a9be14c..1fb00b1 100644 --- a/drivers/media/video/mx3_camera.c +++ b/drivers/media/video/mx3_camera.c @@ -976,7 +976,7 @@ static int mx3_camera_try_fmt(struct soc_camera_device *icd, return ret; } -static int mx3_camera_reqbufs(struct soc_camera_file *icf, +static int mx3_camera_reqbufs(struct soc_camera_device *icd, struct v4l2_requestbuffers *p) { return 0; @@ -984,9 +984,9 @@ static int mx3_camera_reqbufs(struct soc_camera_file *icf, static unsigned int mx3_camera_poll(struct file *file, poll_table *pt) { - struct soc_camera_file *icf = file-private_data; + struct soc_camera_device *icd = file-private_data; - return videobuf_poll_stream(file, icf-vb_vidq, pt); + return videobuf_poll_stream(file, icd-vb_vidq, pt); } static int mx3_camera_querycap(struct soc_camera_host *ici, diff --git a/drivers/media/video/pxa_camera.c b/drivers/media/video/pxa_camera.c index 9de7d59..a8aaf09 100644 --- a/drivers/media/video/pxa_camera.c +++ b/drivers/media/video/pxa_camera.c @@ -1539,7 +1539,7 @@ static int pxa_camera_try_fmt(struct soc_camera_device *icd, return ret; } -static int pxa_camera_reqbufs(struct soc_camera_file *icf, +static int pxa_camera_reqbufs(struct soc_camera_device *icd, struct v4l2_requestbuffers *p) { int i; @@ -1551,7 +1551,7 @@ static int pxa_camera_reqbufs(struct soc_camera_file *icf, * it hadn't triggered */ for (i = 0; i p-count; i++) { - struct pxa_buffer *buf = container_of(icf-vb_vidq.bufs[i], + struct pxa_buffer *buf = container_of(icd-vb_vidq.bufs[i], struct pxa_buffer, vb); buf-inwork = 0; INIT_LIST_HEAD(buf-vb.queue); @@ -1562,10 +1562,10 @@ static int pxa_camera_reqbufs(struct soc_camera_file *icf, static unsigned int pxa_camera_poll(struct file *file, poll_table *pt) { - struct soc_camera_file *icf = file-private_data; + struct soc_camera_device *icd = file-private_data; struct pxa_buffer *buf; - buf = list_entry(icf-vb_vidq.stream.next, struct pxa_buffer, + buf = list_entry(icd-vb_vidq.stream.next, struct pxa_buffer, vb.stream); poll_wait(file, buf-vb.done, pt); diff --git a/drivers/media/video/sh_mobile_ceu_camera.c b/drivers/media/video/sh_mobile_ceu_camera.c index 2b24bd0..bfddad8 100644 --- a/drivers/media/video/sh_mobile_ceu_camera.c +++ b/drivers/media/video/sh_mobile_ceu_camera.c @@ -1726,7 +1726,7 @@ static int sh_mobile_ceu_try_fmt(struct soc_camera_device
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
On Sun, 1 Aug 2010, Janusz Krzysztofik wrote: Friday 30 July 2010 20:49:05 Janusz Krzysztofik napisaÅ(a): Friday 30 July 2010 13:07:42 Guennadi Liakhovetski napisaÅ(a): On Sun, 18 Jul 2010, Janusz Krzysztofik wrote: This is a V4L2 driver for TI OMAP1 SoC camera interface. Two versions of the driver are provided, using either videobuf-dma-contig or videobuf-dma-sg. The former uses less processing power, but often fails to allocate contignuous buffer memory. The latter is free of this problem, but generates tens of DMA interrupts per frame. Hm, would it be difficult to first try contig, and if it fails - fall back to sg? Hmm, let me think about it. Hi Gennadi, For me, your idea of frist trying contig and then falling back to sg if it fails, sounds great. However, I'm not sure if implementing it at a specific hardware driver level is a good solution. Nor soc_camera framework seems the right place for it either. I think the right way would be if implemented at the videobuf-core level. Then, drivers should be able to initialize both paths, providing queue callbacks for both sets of methods, contig and sg, for videobuf sole use. Ok, here're my thoughts about this: 1. We've discussed this dynamic switching a bit on IRC today. The first reaction was - you probably should concentrate on getting the contiguous version to work reliably. I.e., to reserve the memory in the board init code similar, how other contig users currently do it. But given problems with this aproach in the current ARM tree [1], this might be a bit difficult. Still, those problems have to be and will be fixed somehow eventually, so, you might prefer to still just go that route. 2. If you do want to do the switching - we also discussed, how forthcoming changes to the videobuf subsystem will affest this work. I do not think it would be possible to implement this switching in the videobuf core. Remember, with the videobuf API you first call the respective implementation init method, which doesn't fail. Then, in REQBUFS ioctl you call videobuf_reqbufs(), which might already fail but normally doesn't. The biggest problem is the mmap call with the contig videobuf implementation. This one is likely to fail. So, you would have to catch the failing mmap, call videobuf_mmap_free(), then init the SG videobuf, request buffers and mmap them... With my 2 patches from today, there is only one process (file descriptor, to be precise), that manages the videobuf queue. So, this all can only be implemented in your driver. [1] http://thread.gmane.org/gmane.linux.ports.sh.devel/8560 I'm not sure if I have enough skills to implement this idea. However, if there is a consensus on its general usfullness as a videobuf extension, I can have a look at it in my spare time. For now, I'd propose limiting my changes for v2 to splitting both methods into separate sections, not interleaved with #ifdefs like they are now, as you've already suggested. Yep, so, I think, your choice is either to drop sg completely, or to separate the two cleanly and switch between them dynamically in your driver. 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: 2.6.35 and current v4l-dvb - error: implicit declaration of function 'usb_buffer_free'
Hello, 2010/8/11 Goga777 goga...@bk.ru: Hi I can't compile current v4l-dvb with new 2.6.35 kernel arvdr:/usr/src/v4l-dvb# make make -C /usr/src/v4l-dvb/v4l make[1]: Entering directory `/usr/src/v4l-dvb/v4l' creating symbolic links... make -C firmware prep make[2]: Entering directory `/usr/src/v4l-dvb/v4l/firmware' make[2]: Leaving directory `/usr/src/v4l-dvb/v4l/firmware' make -C firmware make[2]: Entering directory `/usr/src/v4l-dvb/v4l/firmware' make[2]: Nothing to be done for `default'. make[2]: Leaving directory `/usr/src/v4l-dvb/v4l/firmware' Kernel build directory is /lib/modules/2.6.35-tux/build make -C /lib/modules/2.6.35-tux/build SUBDIRS=/usr/src/v4l-dvb/v4l modules make[2]: Entering directory `/usr/src/linux-2.6.35' CC [M] /usr/src/v4l-dvb/v4l/au0828-video.o /usr/src/v4l-dvb/v4l/au0828-video.c: In function 'au0828_uninit_isoc': /usr/src/v4l-dvb/v4l/au0828-video.c:185: error: implicit declaration of function 'usb_buffer_free' /usr/src/v4l-dvb/v4l/au0828-video.c: In function 'au0828_init_isoc': /usr/src/v4l-dvb/v4l/au0828-video.c:255: error: implicit declaration of function 'usb_buffer_alloc' /usr/src/v4l-dvb/v4l/au0828-video.c:256: warning: assignment makes pointer from integer without a cast make[3]: *** [/usr/src/v4l-dvb/v4l/au0828-video.o] Ошибка 1 make[2]: *** [_module_/usr/src/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-2.6.35' make[1]: *** [default] Ошибка 2 make[1]: Leaving directory `/usr/src/v4l-dvb/v4l' make: *** [all] Ошибка 2 Both functions were renamed in upstream, backport created and commited, please try again. Cheers 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