Re: Remote that breaks current system

2010-08-12 Thread Christoph Bartelmus
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

2010-08-12 Thread Dan Carpenter
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

2010-08-12 Thread Dan Carpenter
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

2010-08-12 Thread Dan Carpenter
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

2010-08-12 Thread Goga777
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

2010-08-12 Thread Matti J. Aaltonen
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

2010-08-12 Thread Hans Verkuil

 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

2010-08-12 Thread Matti J. Aaltonen
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.

2010-08-12 Thread Matti J. Aaltonen
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.

2010-08-12 Thread pramodh ag
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.

2010-08-12 Thread Matti J. Aaltonen
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

2010-08-12 Thread Maxim Levitsky
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

2010-08-12 Thread Dan Carpenter
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

2010-08-12 Thread Matthias Weber
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

2010-08-12 Thread Maxim Levitsky
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

2010-08-12 Thread Meelis Roos
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

2010-08-12 Thread Mauro Carvalho Chehab
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

2010-08-12 Thread Jarod Wilson
- 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

2010-08-12 Thread Guennadi Liakhovetski
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

2010-08-12 Thread Guennadi Liakhovetski
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

2010-08-12 Thread Guennadi Liakhovetski
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

2010-08-12 Thread Guennadi Liakhovetski
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

2010-08-12 Thread Guennadi Liakhovetski
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'

2010-08-12 Thread Douglas Schilling Landgraf
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