Hauppauge Nova-S remote control broken in 2.6.38
I just installed a new 2.6.38.2 kernel and found that the remote control on my Hauppauge Nova-S plus is no longer working. dmesg shows that everything initialised OK: [8.002874] cx88/0: cx2388x v4l2 driver version 0.0.8 loaded [8.100260] IR NEC protocol handler initialized [8.132843] tveeprom 1-0050: Hauppauge model 92001, rev C1B1, serial# 2700305 [8.132853] tveeprom 1-0050: MAC address is 00:0d:fe:29:34:11 [8.132858] tveeprom 1-0050: tuner model is Conexant_CX24109 (idx 111, type 4) [8.132864] tveeprom 1-0050: TV standards ATSC/DVB Digital (eeprom 0x80) [8.132870] tveeprom 1-0050: audio processor is CX883 (idx 32) [8.132875] tveeprom 1-0050: decoder processor is CX883 (idx 22) [8.132879] tveeprom 1-0050: has no radio, has IR receiver, has no IR transmitter [8.132884] cx88[0]: hauppauge eeprom: model=92001 [8.229173] IR RC5(x) protocol handler initialized [8.261811] Registered IR keymap rc-hauppauge-new [8.272593] input: cx88 IR (Hauppauge Nova-S-Plus as /devices/pci:00/:00:0b.2/rc/rc0/input3 [8.275331] IR RC6 protocol handler initialized [8.278600] rc0: cx88 IR (Hauppauge Nova-S-Plus as /devices/pci:00/:00:0b.2/rc/rc0 [8.510290] lirc_dev: IR Remote Control driver registered, major 251 [8.581417] rc rc0: lirc_dev: driver ir-lirc-codec (cx88xx) registered at minor = 0 [8.581427] IR LIRC bridge handler initialized cat /proc/bus/input/devices ... I: Bus=0001 Vendor=0070 Product=9202 Version=0001 N: Name=cx88 IR (Hauppauge Nova-S-Plus P: Phys=pci-:00:0b.2/ir0 S: Sysfs=/devices/pci:00/:00:0b.2/rc/rc0/input3 But if I try to receive input events I see nothing: sudo evtest /dev/input/event3 Input driver version is 1.0.1 Input device ID: bus 0x1 vendor 0x70 product 0x9202 version 0x1 Input device name: cx88 IR (Hauppauge Nova-S-Plus Supported events: ... If I enable debug output: echo /sys/module/rc_core/parameters/debug 2 and press a key, dmesg shows: [ 481.765937] ir_raw_event_set_idle: leave idle mode [ 481.765948] ir_raw_event_store: sample: (01000us pulse) [ 481.765970] ir_rc5_decode: RC5(x) decode started at state 0 (1000us pulse) [ 481.765975] ir_rc5_decode: RC5(x) decode started at state 1 (111us pulse) [ 481.765981] ir_rc6_decode: RC6 decode started at state 0 (1000us pulse) [ 481.765986] ir_rc6_decode: RC6 decode failed at state 0 (1000us pulse) [ 481.765995] ir_lirc_decode: delivering 1000us pulse to lirc_dev [ 481.773939] ir_raw_event_store: sample: (00750us space) [ 481.773946] ir_raw_event_store: sample: (01000us pulse) [ 481.773950] ir_raw_event_store: sample: (00750us space) [ 481.773954] ir_raw_event_store: sample: (01000us pulse) [ 481.773958] ir_raw_event_store: sample: (01000us space) [ 481.773961] ir_raw_event_store: sample: (00750us pulse) [ 481.773965] ir_raw_event_store: sample: (01000us space) [ 481.773969] ir_raw_event_store: sample: (00750us pulse) [ 481.773973] ir_raw_event_store: sample: (01000us space) [ 481.774007] ir_rc5_decode: RC5(x) decode started at state 1 (750us space) [ 481.774013] ir_rc6_decode: RC6 decode started at state 0 (750us space) [ 481.774018] ir_rc6_decode: RC6 decode failed at state 0 (750us space) [ 481.774025] ir_lirc_decode: delivering 750us space to lirc_dev [ 481.774030] ir_rc5_decode: RC5(x) decode started at state 2 (1000us pulse) [ 481.774035] ir_rc5_decode: RC5(x) decode started at state 1 (111us pulse) [ 481.774039] ir_rc6_decode: RC6 decode started at state 0 (1000us pulse) [ 481.774043] ir_rc6_decode: RC6 decode failed at state 0 (1000us pulse) [ 481.774047] ir_lirc_decode: delivering 1000us pulse to lirc_dev [ 481.774051] ir_rc5_decode: RC5(x) decode started at state 1 (750us space) [ 481.774055] ir_rc6_decode: RC6 decode started at state 0 (750us space) [ 481.774059] ir_rc6_decode: RC6 decode failed at state 0 (750us space) [ 481.774063] ir_lirc_decode: delivering 750us space to lirc_dev So it looks like decoding is failing. I see that there have been extensive changes to the RC system from 2.6.37 and it appears that something broke in the transition. Any suggestions on where the problem might be? -- Lawrence -- 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] Fix AF9015 Dual tuner i2c write failures
2011/4/2 Antti Palosaari cr...@iki.fi: On 04/02/2011 04:45 PM, adq wrote: 2011/4/2 Antti Palosaaricr...@iki.fi: On 04/02/2011 02:06 PM, adq wrote: 2011/4/2 Antti Palosaaricr...@iki.fi: On 04/02/2011 04:24 AM, adq wrote: Hi, just been trying it out, with no success. On my test machine, FE0 no longer tunes, but FE1 is still fine, so I've just been testing FE0. You try to say other frontend / tuner is physically dead? Which one? No no - I can revive it by simply unplugging and replugging the device, but I was avoiding doing that to see if we could either track down something erroneous, or be able to reset it from software. It'd be /really/ handy if they'd connected that reset tuner GPIO :( There isn't a way to completely reset the device from software I take it? Or any other GPIOs hanging about I could test with? There is few I know, USB command 0x13 boots AF9015 somehow, USB command 0x5a reconnects it from USB bus. But most interesting one is demodulator reset register 0xe205, write 1 to that reg should reset it. Just tried writing 1 to 0xe205 - no change. OK. Looks like USB commands 0x13/0x5a will be done as part of a normal module reload? (In which case it doesn't fix it). I can actually reboot the machine completely, and the problem stays! Only physically unplugging the device sorts it. You are correct. I don't have any idea anymore. Only is wish to know if that happens in Windows too. Yeah, no more ideas here either, and I can't really try it under windows. Beginning to think its some hardware issue. As a workaround, if you make sure your software doesn't retune constantly, it seems to survive reasonably ok. The other one I have in my server is fine after a few weeks now I've turned off any auto EIT/signalmonitoring stuff in tvheadend. I just need to write a quick cron job to check the tuning still works. :( -- 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: Debug code in HG repositories
Em 10-01-2011 23:10, Oliver Endriss escreveu: On Monday 10 January 2011 13:04:54 Mauro Carvalho Chehab wrote: Em 07-01-2011 21:56, Oliver Endriss escreveu: ... There are large pieces of driver code which are currently unused, and nobody can tell whether they will ever be needed. On the other hand a developer spent days writing this stuff, and now it does not exist anymore - without any trace! The problem is not, that it is missing in the current snapshot, but that it has never been in the git repository, and there is no way to recover it. The Mercurial tree will stay there forever. We still have there the old CVS trees used by DVB and V4L development. Afaics, the only way to preserve this kind of code is 'out-of-tree'. It is a shame... :-( I see your point. It is harder for people to re-use that code, as they are not upstream. The main problem is that they do not even know that the code exists. Maybe I should add some comment to the driver, that someone should look into the HG repository, before he starts re-inventing the wheel. It is easy to recover the changes with: $ gentree.pl 2.6.37 --strip_dead_code linux/ /tmp/stripped $ gentree.pl 2.6.37 linux/ /tmp/not_stripped $ diff -upr /tmp/stripped/ /tmp/not_stripped/ /tmp/revert_removed_code.patch As a reference and further discussions, I'm enclosing the diff. The resulting diff is far from complete. In fact, the most interesting parts are missing. Apparently, the command gentree.pl 2.6.37 linux/ /tmp/not_stripped stripped all '#if 0' blocks, which are not followed by a comment. Just compare the original ngene_av.c with the resulting version in /tmp/non_stripped. Oliver, I fixed the script. Sorry for taking a long time. Too much stuff here. The fix patch were already merged at -hg. It will now produce the right results. A regex expression were waiting for something after #if 1/#if 0, with is generally ok, as lines end with \n. However, due to the usage of chomp, the \n character were removed, and the regex failed on lines with just '#if 0'. - On most places, the code inside #if 0 are just legacy stuff, where people were trying to implement a different code for something. However, at ngene, the code inside #if 0 are there just because the ngene developers didn't find time yet to work on them. So, it may make sense to add those code into mainstream, if people will uncomment part of those code. So, feel free to send me a patch adding the commented code, if you need. Thanks, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge Nova-S remote control broken in 2.6.38
Em 03-04-2011 08:41, Lawrence Rust escreveu: I just installed a new 2.6.38.2 kernel and found that the remote control on my Hauppauge Nova-S plus is no longer working. dmesg shows that everything initialised OK: [8.002874] cx88/0: cx2388x v4l2 driver version 0.0.8 loaded [8.100260] IR NEC protocol handler initialized [8.132843] tveeprom 1-0050: Hauppauge model 92001, rev C1B1, serial# 2700305 [8.132853] tveeprom 1-0050: MAC address is 00:0d:fe:29:34:11 [8.132858] tveeprom 1-0050: tuner model is Conexant_CX24109 (idx 111, type 4) [8.132864] tveeprom 1-0050: TV standards ATSC/DVB Digital (eeprom 0x80) [8.132870] tveeprom 1-0050: audio processor is CX883 (idx 32) [8.132875] tveeprom 1-0050: decoder processor is CX883 (idx 22) [8.132879] tveeprom 1-0050: has no radio, has IR receiver, has no IR transmitter [8.132884] cx88[0]: hauppauge eeprom: model=92001 [8.229173] IR RC5(x) protocol handler initialized [8.261811] Registered IR keymap rc-hauppauge-new [8.272593] input: cx88 IR (Hauppauge Nova-S-Plus as /devices/pci:00/:00:0b.2/rc/rc0/input3 [8.275331] IR RC6 protocol handler initialized [8.278600] rc0: cx88 IR (Hauppauge Nova-S-Plus as /devices/pci:00/:00:0b.2/rc/rc0 [8.510290] lirc_dev: IR Remote Control driver registered, major 251 [8.581417] rc rc0: lirc_dev: driver ir-lirc-codec (cx88xx) registered at minor = 0 [8.581427] IR LIRC bridge handler initialized cat /proc/bus/input/devices ... I: Bus=0001 Vendor=0070 Product=9202 Version=0001 N: Name=cx88 IR (Hauppauge Nova-S-Plus P: Phys=pci-:00:0b.2/ir0 S: Sysfs=/devices/pci:00/:00:0b.2/rc/rc0/input3 But if I try to receive input events I see nothing: sudo evtest /dev/input/event3 Input driver version is 1.0.1 Input device ID: bus 0x1 vendor 0x70 product 0x9202 version 0x1 Input device name: cx88 IR (Hauppauge Nova-S-Plus Supported events: ... If I enable debug output: echo /sys/module/rc_core/parameters/debug 2 and press a key, dmesg shows: [ 481.765937] ir_raw_event_set_idle: leave idle mode [ 481.765948] ir_raw_event_store: sample: (01000us pulse) [ 481.765970] ir_rc5_decode: RC5(x) decode started at state 0 (1000us pulse) [ 481.765975] ir_rc5_decode: RC5(x) decode started at state 1 (111us pulse) [ 481.765981] ir_rc6_decode: RC6 decode started at state 0 (1000us pulse) [ 481.765986] ir_rc6_decode: RC6 decode failed at state 0 (1000us pulse) [ 481.765995] ir_lirc_decode: delivering 1000us pulse to lirc_dev [ 481.773939] ir_raw_event_store: sample: (00750us space) [ 481.773946] ir_raw_event_store: sample: (01000us pulse) [ 481.773950] ir_raw_event_store: sample: (00750us space) [ 481.773954] ir_raw_event_store: sample: (01000us pulse) [ 481.773958] ir_raw_event_store: sample: (01000us space) [ 481.773961] ir_raw_event_store: sample: (00750us pulse) [ 481.773965] ir_raw_event_store: sample: (01000us space) [ 481.773969] ir_raw_event_store: sample: (00750us pulse) [ 481.773973] ir_raw_event_store: sample: (01000us space) [ 481.774007] ir_rc5_decode: RC5(x) decode started at state 1 (750us space) [ 481.774013] ir_rc6_decode: RC6 decode started at state 0 (750us space) [ 481.774018] ir_rc6_decode: RC6 decode failed at state 0 (750us space) [ 481.774025] ir_lirc_decode: delivering 750us space to lirc_dev [ 481.774030] ir_rc5_decode: RC5(x) decode started at state 2 (1000us pulse) [ 481.774035] ir_rc5_decode: RC5(x) decode started at state 1 (111us pulse) [ 481.774039] ir_rc6_decode: RC6 decode started at state 0 (1000us pulse) [ 481.774043] ir_rc6_decode: RC6 decode failed at state 0 (1000us pulse) [ 481.774047] ir_lirc_decode: delivering 1000us pulse to lirc_dev [ 481.774051] ir_rc5_decode: RC5(x) decode started at state 1 (750us space) [ 481.774055] ir_rc6_decode: RC6 decode started at state 0 (750us space) [ 481.774059] ir_rc6_decode: RC6 decode failed at state 0 (750us space) [ 481.774063] ir_lirc_decode: delivering 750us space to lirc_dev So it looks like decoding is failing. I see that there have been extensive changes to the RC system from 2.6.37 and it appears that something broke in the transition. Any suggestions on where the problem might be? Hmm...the above sequence seems incomplete to me. That's why the decoder failed: there aren't enough pulse/space codes there to be translated. Maybe your remote batteries are weak. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dibusb device with lock problems
Hi Mr Tux, On Saturday 02 April 2011 15:45:22 Mr Tux wrote: Hi list, hello Patrick, A locking problem with specific dib3000mb devices is still present in kernel 2.6.38. Now people upgrading from lenny to squeeze are also affected - see: [1] Please have a look at my previous post in [2] for a detailed description and links to this bug's history. I'm sending a cc of this to the people who once where affected by this bug or involved with the code change that introduced it. Anyone can confirm this is fixed/pending for his device and what dib3000mb device he is using out of the linuxtv wiki list of 14 dib3000mb devices [3]? I have 3 devices of the hama usb 1.1 series: [4], that's number 66 in the wiki listing - they all are affected by this bug with kernels 2.6.31 Thanks for some feedback. Can we fix this for good for the pending devices? [1] http://www.vdr-portal.de/index.php?page=ThreadpostID=991041 In the post on vdr-portal you're showing the kernel-output of 2.6.32 I guess, do you still have the kernel output of 2.6.26 (or any before 2.6.32)? I think this line is not normal in your case: dibusb: This device has the Thomson Cable onboard. Which is default. But to be sure I need you to test. TUning the device is not needed with the old kernel, just plugging it and checking that line should be enough. -- Patrick. -- 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: Skystar 2 2.6 broken in kernel 2.6.38
Hi, On Saturday 02 April 2011 21:30:53 Steffen Barszus wrote: Hi I just installed natty and found that one of the drivers i use is broken. Is this a known issue ? [6.115925] [ cut here ] [6.115931] WARNING: at /build/buildd/linux-2.6.38/fs/proc/generic.c:323 __xlate_proc_name+0xbb/0xd0() [6.115933] Hardware name: EP45T-UD3LR Actually the driver is not broken as it still works. This is a warning issued by the core because the driver is using a bad string. There have been a lot of attempts to fix it in the past, but they have been lost somewhere on the road. I hope this time it will make it. best regards, -- Patrick Boettcher - KernelLabs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vb2_plane 'mapped' signed bit field
On Sat, Apr 2, 2011 at 17:18, Dr. David Alan Gilbert li...@treblig.org wrote:
Hi Pawel,
'sparse' spotted that vb2_plane's mapped field is a signed
bitfield:
include/media/videobuf2-core.h:78:41 1 bit signed int
struct vb2_plane {
void *mem_priv;
int mapped:1;
};
that probably should be an unsigned int (I can see code that assigns
1 to it that just won't fit).
Hi David,
Thanks for the report, will fix soon.
--
Best regards,
Pawel Osciak
--
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] [media] dib0700: fix possible NULL pointer dereference
On Saturday 26 March 2011 19:23:56 Mariusz Kozlowski wrote: Seems like 'adap-fe' test for NULL was meant to be before we dereference that pointer. Signed-off-by: Mariusz Kozlowski m...@lab.zgora.pl Thanks, applied. -- Patrick Boettcher - KernelLabs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6.39] fixes - pull request
Hi Mauro, I cleaned my mailbox and collected some small fixes for 2.6.39 and for other version (stable is Cc'd in that case). Please pull from (sorry for the wrong branch name) http://git.linuxtv.org/pb/media_tree.git staging/for_v2.6.39 for [PATCH] Fix dependencies for Technisat USB2.0 DVB-S/S2 [PATCH] [media] dib0700: fix possible NULL pointer... FLEXCOP-PCI: fix __xlate_proc_name-warning for flexcop-pci DIB0700: fix typo in dib0700_devices.c Thanks, -- Patrick Boettcher - KernelLabs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[media] dib0700: get rid of on-stack dma buffers
Hi, since I got no reaction[1] on the vp702x driver, I proceed with the dib0700. There are multiple drivers in drivers/media/dvb/dvb-usb/ which use usb_control_msg to perform dma to stack-allocated buffers. This is a bad idea because of cache-coherency issues and on some platforms the stack is mapped virtually and also lib/dma-debug.c warn's about it at runtime. Patches to ec168, ce6230, au6610 and lmedm04 were already tested and reviewed and submitted for inclusion [2]. Patches to a800, vp7045, friio, dw2102, m920x and opera1 are still waiting for for review and testing [3]. This patch to dib0700 is a fix for a warning seen and reported by Zdenek Kabalec in Bug #15977 [4]. Florian Mickler (2): [media] dib0700: get rid of on-stack dma buffers [media] dib0700: remove unused variable Regards, Flo References: [1]: http://www.spinics.net/lists/linux-media/msg30448.html [2]: http://comments.gmane.org/gmane.linux.kernel/1115404 [3]: http://groups.google.com/group/fa.linux.kernel/browse_frm/thread/e169edc121b91181/f1498cd026a59fe2 [4]: https://bugzilla.kernel.org/show_bug.cgi?id=15977 -- 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 1/2] [media] dib0700: get rid of on-stack dma buffers
usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.
In lib/dma_debug.c the function check_for_stack even warns about it:
WARNING: at lib/dma-debug.c:866 check_for_stack
Note: This change is tested to compile only, as I don't have the hardware.
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=15977.
Reported-by: Zdenek Kabelac zdenek.kabe...@gmail.com
Signed-off-by: Florian Mickler flor...@mickler.org
---
[v2: use preallocated buffer; fix sizeof in one case]
[v3: use seperate kmalloc mapping for the preallocation,
dont ignore errors in probe codepaths ]
[v4: minor style nit: functions opening brace goes onto it's own line ]
[v5: use preallocated buffer whereever we have a dvb_usb_device
available even if it means acquiring i2c_mutex where we did previously
not + found some more on-stack buffers that escaped my first
review somehow...]
drivers/media/dvb/dvb-usb/dib0700.h |5 +-
drivers/media/dvb/dvb-usb/dib0700_core.c| 142 +-
drivers/media/dvb/dvb-usb/dib0700_devices.c |9 ++-
3 files changed, 125 insertions(+), 31 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700.h
b/drivers/media/dvb/dvb-usb/dib0700.h
index b2a87f2..368fbcf 100644
--- a/drivers/media/dvb/dvb-usb/dib0700.h
+++ b/drivers/media/dvb/dvb-usb/dib0700.h
@@ -46,8 +46,9 @@ struct dib0700_state {
u8 is_dib7000pc;
u8 fw_use_new_i2c_api;
u8 disable_streaming_master_mode;
-u32 fw_version;
-u32 nb_packet_buffer_size;
+ u32 fw_version;
+ u32 nb_packet_buffer_size;
+ u8 *buf; /* protected by dvb_usb_devices i2c_mutex */
};
extern int dib0700_get_version(struct dvb_usb_device *d, u32 *hwversion,
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index b79af68..ca80520 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -27,11 +27,16 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
int dib0700_get_version(struct dvb_usb_device *d, u32 *hwversion,
u32 *romversion, u32 *ramversion, u32 *fwtype)
{
- u8 b[16];
- int ret = usb_control_msg(d-udev, usb_rcvctrlpipe(d-udev, 0),
+ struct dib0700_state *st = d-priv;
+ int ret;
+ u8 *b = st-buf;
+
+ mutex_lock(d-i2c_mutex);
+
+ ret = usb_control_msg(d-udev, usb_rcvctrlpipe(d-udev, 0),
REQUEST_GET_VERSION,
USB_TYPE_VENDOR | USB_DIR_IN, 0, 0,
- b, sizeof(b), USB_CTRL_GET_TIMEOUT);
+ b, 16, USB_CTRL_GET_TIMEOUT);
if (hwversion != NULL)
*hwversion = (b[0] 24) | (b[1] 16) | (b[2] 8) |
b[3];
if (romversion != NULL)
@@ -40,6 +45,9 @@ int dib0700_get_version(struct dvb_usb_device *d, u32
*hwversion,
*ramversion = (b[8] 24) | (b[9] 16) | (b[10] 8) |
b[11];
if (fwtype != NULL)
*fwtype = (b[12] 24) | (b[13] 16) | (b[14] 8) |
b[15];
+
+ mutex_unlock(d-i2c_mutex);
+
return ret;
}
@@ -101,16 +109,30 @@ int dib0700_ctrl_rd(struct dvb_usb_device *d, u8 *tx, u8
txlen, u8 *rx, u8 rxlen
int dib0700_set_gpio(struct dvb_usb_device *d, enum dib07x0_gpios gpio, u8
gpio_dir, u8 gpio_val)
{
- u8 buf[3] = { REQUEST_SET_GPIO, gpio, ((gpio_dir 0x01) 7) |
((gpio_val 0x01) 6) };
- return dib0700_ctrl_wr(d, buf, sizeof(buf));
+ s16 ret;
+ struct dib0700_state *st = d-priv;
+ u8 *buf = st-buf;
+
+ mutex_lock(d-i2c_mutex);
+
+ buf[0] = REQUEST_SET_GPIO;
+ buf[1] = gpio;
+ buf[2] = ((gpio_dir 0x01) 7) | ((gpio_val 0x01) 6);
+ ret = dib0700_ctrl_wr(d, buf, 3);
+
+ mutex_unlock(d-i2c_mutex);
+
+ return ret;
}
static int dib0700_set_usb_xfer_len(struct dvb_usb_device *d, u16
nb_ts_packets)
{
struct dib0700_state *st = d-priv;
- u8 b[3];
+ u8 *b = st-buf;
int ret;
+ mutex_lock(d-i2c_mutex);
+
if (st-fw_version = 0x10201) {
b[0] = REQUEST_SET_USB_XFER_LEN;
b[1] = (nb_ts_packets 8) 0xff;
@@ -118,12 +140,14 @@ static int dib0700_set_usb_xfer_len(struct dvb_usb_device
*d, u16 nb_ts_packets)
deb_info(set the USB xfer len to %i Ts packet\n,
nb_ts_packets);
- ret = dib0700_ctrl_wr(d, b, sizeof(b));
+ ret = dib0700_ctrl_wr(d, b, 3);
} else {
deb_info(this firmware does not allow to change the USB xfer
len\n);
ret = -EIO;
}
+ mutex_unlock(d-i2c_mutex);
+
return ret;
}
@@ -137,11 +161,12 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap,
struct i2c_msg *msg,
properly support i2c read calls not preceded by a write */
[PATCH 2/2] [media] dib0700: remove unused variable
This variable is never used.
Signed-off-by: Florian Mickler flor...@mickler.org
---
drivers/media/dvb/dvb-usb/dib0700_core.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index ca80520..7f6f023 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -625,7 +625,6 @@ struct dib0700_rc_response {
static void dib0700_rc_urb_completion(struct urb *purb)
{
struct dvb_usb_device *d = purb-context;
- struct dib0700_state *st;
struct dib0700_rc_response *poll_reply;
u32 uninitialized_var(keycode);
u8 toggle;
@@ -640,7 +639,6 @@ static void dib0700_rc_urb_completion(struct urb *purb)
return;
}
- st = d-priv;
poll_reply = purb-transfer_buffer;
if (purb-status 0) {
--
1.7.4.1
--
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/RFC 0/4] V4L: new ioctl()s to support multi-sized video-buffers
Hi Guennadi, On Fri, Apr 1, 2011 at 01:12, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi all As discussed at the last V4L2 meeting in Warsaw, one of the prerequisites to support fast switching between different image formats is an ability to preallocate buffers of different sizes and handle them over to the driver in advance. This avoids the need to allocate buffers at the time of switching. This patch series is a first implementation of these ioctl()s, implemented for the sh_mobile_ceu_camera soc-camera host driver. Tested on an sh7722 migor SuperH platform. Yes, I know, documentation is missing yet;-) I will have to wait for documentation before doing a full review, it's hard to comment without it. Also, please mention how the new ioctls influence the state machine. Some questions and doubts I'm having: - Can you call CREATE more than once, before/after REQBUFS, for all streaming states? What about reading/writing? - Can driver decline CREATE if it is not supported? What if the format is not supported? - If we fail allocating in CREATE, should the whole queue be freed (as it is done in your patch I believe)? - I'm assuming REQBUFS(0) is to free buffers allocated with CREATE too? - Are we allowing DESTROY to free arbitrary span of buffers (i.e. those created with REQBUFS as well)? - Are holes in buffer indexes allowed? I don't like the ability to free an arbitrary span of buffers in the queue, it complicates checks in many places and I don't think is worth it... - I understand SUBMIT is optional? - Could you give an example of how this could be used in an application? -- Best regards, Pawel Osciak -- 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/RFC 2/4 v2] V4L: add videobuf2 helper functions to support multi-size video-buffers
Hi Gueannadi,
A preliminary quick scan over the patch while waiting for documentation.
On Fri, Apr 1, 2011 at 07:06, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
This patch extends the videobuf2 framework with new helper functions and
modifies existing ones to support multi-size video-buffers.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v2: fix offset calculation in __setup_offsets()
drivers/media/video/videobuf2-core.c | 195
++
include/media/videobuf2-core.h | 15 +++
2 files changed, 187 insertions(+), 23 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 71734a4..20e1572 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -41,7 +41,7 @@ module_param(debug, int, 0644);
* __vb2_buf_mem_alloc() - allocate video memory for the given buffer
*/
static int __vb2_buf_mem_alloc(struct vb2_buffer *vb,
- unsigned long *plane_sizes)
+ const unsigned long *plane_sizes)
{
struct vb2_queue *q = vb-vb2_queue;
void *mem_priv;
@@ -107,13 +107,22 @@ static void __vb2_buf_userptr_put(struct vb2_buffer *vb)
* __setup_offsets() - setup unique offsets (cookies) for every plane in
* every buffer on the queue
*/
-static void __setup_offsets(struct vb2_queue *q)
+static void __setup_offsets(struct vb2_queue *q, unsigned int n)
{
unsigned int buffer, plane;
struct vb2_buffer *vb;
- unsigned long off = 0;
+ unsigned long off;
- for (buffer = 0; buffer q-num_buffers; ++buffer) {
+ if (q-num_buffers) {
+ struct v4l2_plane *p;
+ vb = q-bufs[q-num_buffers - 1];
+ p = vb-v4l2_planes[vb-num_planes - 1];
+ off = PAGE_ALIGN(p-m.mem_offset + p-length);
+ } else {
+ off = 0;
+ }
+
+ for (buffer = q-num_buffers - n; buffer q-num_buffers; ++buffer) {
vb = q-bufs[buffer];
if (!vb)
continue;
@@ -139,7 +148,7 @@ static void __setup_offsets(struct vb2_queue *q)
*/
static int __vb2_queue_alloc(struct vb2_queue *q, enum v4l2_memory memory,
unsigned int num_buffers, unsigned int num_planes,
- unsigned long plane_sizes[])
+ const unsigned long plane_sizes[])
{
unsigned int buffer;
struct vb2_buffer *vb;
@@ -160,7 +169,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum
v4l2_memory memory,
vb-state = VB2_BUF_STATE_DEQUEUED;
vb-vb2_queue = q;
vb-num_planes = num_planes;
- vb-v4l2_buf.index = buffer;
+ vb-v4l2_buf.index = q-num_buffers + buffer;
vb-v4l2_buf.type = q-type;
vb-v4l2_buf.memory = memory;
@@ -188,12 +197,12 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum
v4l2_memory memory,
}
}
- q-bufs[buffer] = vb;
+ q-bufs[q-num_buffers + buffer] = vb;
}
- q-num_buffers = buffer;
+ q-num_buffers += buffer;
- __setup_offsets(q);
+ __setup_offsets(q, buffer);
dprintk(1, Allocated %d buffers, %d plane(s) each\n,
q-num_buffers, num_planes);
@@ -204,12 +213,13 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum
v4l2_memory memory,
/**
* __vb2_free_mem() - release all video buffer memory for a given queue
*/
-static void __vb2_free_mem(struct vb2_queue *q)
+static void __vb2_free_mem(struct vb2_queue *q, struct v4l2_buffer_span
*span)
{
unsigned int buffer;
struct vb2_buffer *vb;
- for (buffer = 0; buffer q-num_buffers; ++buffer) {
+ for (buffer = span-index; buffer span-index + span-count;
+ ++buffer) {
vb = q-bufs[buffer];
if (!vb)
continue;
@@ -222,18 +232,17 @@ static void __vb2_free_mem(struct vb2_queue *q)
}
}
-/**
- * __vb2_queue_free() - free the queue - video memory and related information
- * and return the queue to an uninitialized state. Might be called even if
the
- * queue has already been freed.
- */
-static void __vb2_queue_free(struct vb2_queue *q)
+int vb2_destroy_bufs(struct vb2_queue *q, struct v4l2_buffer_span *span)
{
- unsigned int buffer;
+ int buffer;
+
+ if (span-index + span-count q-num_buffers)
+ return -EINVAL;
Maybe it'd be better to free what we can here?
/* Call driver-provided cleanup function for each buffer, if provided
*/
if (q-ops-buf_cleanup) {
- for (buffer = 0; buffer q-num_buffers; ++buffer) {
+ for (buffer = span-index;
+
dibusb device with lock problems
hello Patrick, On Sunday 03 April 2011 17:37:00 Patrick Boettcher wrote: I think this line is not normal in your case: dibusb: This device has the Thomson Cable onboard. Which is default. Here's the output of dmesg in Lenny (kernel 2.6.26-1) where the tuning was fine: usb 2-1: new full speed USB device using ohci_hcd and address 3 usb 2-1: configuration #1 chosen from 1 choice usb 2-1: New USB device found, idVendor=1822, idProduct=3201 usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device' in cold state, will try to load a firmware firmware: requesting dvb-usb-dibusb-5.0.0.11.fw dvb-usb: downloading firmware from file 'dvb-usb-dibusb-5.0.0.11.fw' usbcore: registered new interface driver dvb_usb_dibusb_mb usb 2-1: USB disconnect, address 3 dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. usb 2-1: new full speed USB device using ohci_hcd and address 4 usb 2-1: configuration #1 chosen from 1 choice dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device' in warm state. dvb-usb: will use the device's hardware PID filter (table count: 16). DVB: registering new adapter (TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device) DVB: registering frontend 0 (DiBcom 3000M-B DVB-T)... dibusb: This device has the Thomson Cable onboard. Which is default. input: IR-receiver inside an USB DVB receiver as /class/input/input5 dvb-usb: schedule remote query interval to 150 msecs. dvb-usb: TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device successfully initialized and connected. usb 2-1: New USB device found, idVendor=1822, idProduct=3202 usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 2-1: Product: VP7041 usb 2-1: Manufacturer: TwinHan The Thomson line was there, nevertheless the locking was fine back then: 1st consecutive test run using tzap: using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 69000 Hz video pid 0x00a0, audio pid 0x0050 status 00 | signal 1d37 | snr | ber 001f | unc | status 1a | signal 2161 | snr 0046 | ber 001f | unc | FE_HAS_LOCK status 1b | signal | snr 0044 | ber 001f | unc | FE_HAS_LOCK status 1b | signal | snr 0046 | ber 8a18 | unc 0038 | FE_HAS_LOCK status 1b | signal | snr 004b | ber 4d60 | unc | FE_HAS_LOCK status 1b | signal f4dd | snr 003a | ber 3ee4 | unc | FE_HAS_LOCK 2nd consecutive test run using tzap: using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 69000 Hz video pid 0x00a0, audio pid 0x0050 status 02 | signal | snr | ber 001f | unc | status 1a | signal 9bd0 | snr 0043 | ber 001f | unc | FE_HAS_LOCK status 1b | signal | snr 0040 | ber 001f | unc | FE_HAS_LOCK status 1b | signal f4dd | snr 0044 | ber 8754 | unc 002e | FE_HAS_LOCK status 1b | signal | snr 0042 | ber 94a4 | unc | FE_HAS_LOCK status 1b | signal | snr 003a | ber 000187e8 | unc | FE_HAS_LOCK 3rd consecutive test run using tzap: using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 69000 Hz video pid 0x00a0, audio pid 0x0050 status 1e | signal 858e | snr 0058 | ber 001f | unc | FE_HAS_LOCK status 1b | signal | snr 004c | ber 001f | unc | FE_HAS_LOCK status 1b | signal | snr 0042 | ber 5b18 | unc 000c | FE_HAS_LOCK status 1b | signal | snr 0044 | ber 697c | unc | FE_HAS_LOCK status 1b | signal f4dd | snr 004e | ber 5f20 | unc | FE_HAS_LOCK status 1b | signal | snr 0055 | ber 5f20 | unc | FE_HAS_LOCK status 1b | signal | snr 0037 | ber 5400 | unc | FE_HAS_LOCK So even with a poorly aligned antenna I get some BER, but I always have the instant lock as expected. This changed with with the eeprom protection you introduced in 2.6.31, and the patch for Mario Bachmann never fixed it for my dib3000mb device. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Apr 3 19:00:31 CEST 2011 git hash:28df73703e738d8ae7a958350f74b08b2e9fe9ed gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] wl128x: Remove unused NO_OF_ENTRIES_IN_ARRAY macro.
Signed-off-by: Thiago Farina tfrans...@gmail.com --- drivers/media/radio/wl128x/fmdrv.h |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/media/radio/wl128x/fmdrv.h b/drivers/media/radio/wl128x/fmdrv.h index 5db6fd1..1a45a5d 100644 --- a/drivers/media/radio/wl128x/fmdrv.h +++ b/drivers/media/radio/wl128x/fmdrv.h @@ -55,8 +55,6 @@ #define FM_DRV_TX_TIMEOUT (5*HZ) /* 5 seconds */ #define FM_DRV_RX_SEEK_TIMEOUT (20*HZ) /* 20 seconds */ -#define NO_OF_ENTRIES_IN_ARRAY(array) (sizeof(array) / sizeof(array[0])) - #define fmerr(format, ...) \ printk(KERN_ERR fmdrv: format, ## __VA_ARGS__) #define fmwarn(format, ...) \ -- 1.7.3.2.343.g7d43d -- 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 1/3] [media] vb2: update and fix interface documentation
Update documentation for videobuf2 driver callbacks and memory operations.
Signed-off-by: Pawel Osciak pa...@osciak.com
---
include/media/videobuf2-core.h | 146 +---
1 files changed, 91 insertions(+), 55 deletions(-)
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index f87472a..4c1e91f 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -33,8 +33,11 @@ struct vb2_fileio_data;
* argument is the allocator private per-buffer structure
* previously returned from the alloc callback
* @get_userptr: acquire userspace memory for a hardware operation; used for
- * USERPTR memory types; vaddr is the address passed to the
- * videobuf layer when queuing a video buffer of USERPTR type;
+ * USERPTR memory types; alloc_ctx is the allocator private data,
+ * vaddr is the address passed to the videobuf layer when
+ * queuing a video buffer of USERPTR type, size is the size of
+ * that buffer and write=1 if the buffer will be written to
+ * by kernel/hardware (i.e. is a CAPTURE buffer);
* should return an allocator private per-buffer structure
* associated with the buffer on success, NULL on failure;
* the returned private structure will then be passed as buf_priv
@@ -44,9 +47,14 @@ struct vb2_fileio_data;
* @vaddr: return a kernel virtual address to a given memory buffer
* associated with the passed private structure or NULL if no
* such mapping exists
- * @cookie:return allocator specific cookie for a given memory buffer
- * associated with the passed private structure or NULL if not
- * available
+ * @cookie:return allocator-specific cookie for a given memory buffer,
+ * associated with the passed private structure, or NULL if not
+ * available; a cookie is a unique identifier for a buffer that
+ * driver will be able to use when communicating with hardware;
+ * for example, for devices accessing physical memory directly via
+ * physical addresses, it can point to a variable containing
+ * a physical address for the given buffer, which the driver can
+ * then pass to the device when setting up a HW operation
* @num_users: return the current number of users of a memory buffer;
* return 1 if the videobuf layer (or actually the driver using
* it) is the only user
@@ -74,8 +82,8 @@ struct vb2_mem_ops {
};
struct vb2_plane {
- void*mem_priv;
- int mapped:1;
+ void*mem_priv;
+ int mapped:1;
};
/**
@@ -93,10 +101,15 @@ enum vb2_io_modes {
};
/**
- * enum vb2_fileio_flags - flags for selecting a mode of the file io emulator,
- * by default the 'streaming' style is used by the file io emulator
- * @VB2_FILEIO_READ_ONCE: report EOF after reading the first buffer
- * @VB2_FILEIO_WRITE_IMMEDIATELY: queue buffer after each write() call
+ * enum vb2_fileio_flags - flags for selecting file IO (read/write) behavior
+ * @VB2_FILEIO_READ_ONCE: if set, the userspace will be able to read one
+ * full buffer only, an EOF will be reported after
+ * the first buffer has been read completely
+ * @VB2_FILEIO_WRITE_IMMEDIATELY: if set, do not wait for the buffer to be
+ * filled completely by userspace (possibly
+ * using multiple write() calls), but send it
+ * to the device immediately after the first
+ * write() call
*/
enum vb2_fileio_flags {
VB2_FILEIO_READ_ONCE= (1 0),
@@ -130,7 +143,10 @@ struct vb2_queue;
* @v4l2_buf: struct v4l2_buffer associated with this buffer; can
* be read by the driver and relevant entries can be
* changed by the driver in case of CAPTURE types
- * (such as timestamp)
+ * (such as timestamp); NOTE that even for single-planar
+ * types, the v4l2_planes[0] struct should be used
+ * instead of v4l2_buf for filling bytesused - drivers
+ * should use the vb2_set_plane_payload() function for that
* @v4l2_planes: struct v4l2_planes associated with this buffer; can
* be read by the driver and relevant entries can be
* changed by the driver in case of CAPTURE types
@@ -140,14 +156,13 @@ struct vb2_queue;
* should use the vb2_set_plane_payload() function for that
* @vb2_queue: the queue to which this driver belongs
* @num_planes:
[PATCH 2/3] [media] vb2: use unsigned int for the `mapped' bitfield
Signed-off-by: Pawel Osciak pa...@osciak.com
Reported-by: David Alan Gilbert li...@treblig.org
---
include/media/videobuf2-core.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 4c1e91f..f3bdbb2 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -83,7 +83,7 @@ struct vb2_mem_ops {
struct vb2_plane {
void*mem_priv;
- int mapped:1;
+ unsigned intmapped:1;
};
/**
--
1.7.4.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 3/3] [media] vb2: prevent drivers from requesting too many buffers/planes.
Add a sanity check to make sure drivers do not adjust the number of buffers or planes above the supported limit on reqbufs. Signed-off-by: Pawel Osciak pa...@osciak.com --- drivers/media/video/videobuf2-core.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/videobuf2-core.c b/drivers/media/video/videobuf2-core.c index 6698c77..6e69584 100644 --- a/drivers/media/video/videobuf2-core.c +++ b/drivers/media/video/videobuf2-core.c @@ -529,6 +529,11 @@ int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req) if (ret) return ret; + /* +* Make sure driver did not request more buffers/planes than we can handle. +*/ + BUG_ON (num_buffers VIDEO_MAX_FRAME || num_planes VIDEO_MAX_PLANES); + /* Finally, allocate buffers and video memory */ ret = __vb2_queue_alloc(q, req-memory, num_buffers, num_planes, plane_sizes); -- 1.7.4.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
vb2: stop_streaming() callback redesign
Hi, This series implements a slight redesign of the stop_streaming() callback in vb2. The callback has been made obligatory. The drivers are expected to finish all hardware operations and cede ownership of all buffers before returning, but are not required to call vb2_buffer_done() for any of them. The return value from this callback has also been removed. [PATCH 1/5] [media] vb2: redesign the stop_streaming() callback and make it obligatory [PATCH 2/5] [media] vivi: adapt to the new stop_streaming() callback behavior [PATCH 3/5] [media] s5p-fimc: remove stop_streaming() callback return [PATCH 4/5] [media] sh_mobile_ceu_camera: remove stop_streaming() callback return [PATCH 5/5] [media] mx3_camera: remove stop_streaming() callback return -- Best regards, Pawel Osciak -- 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 1/5] [media] vb2: redesign the stop_streaming() callback and make it obligatory
Drivers are now required to implement the stop_streaming() callback
to ensure that all ongoing hardware operations are finished and their
ownership of buffers is ceded.
Drivers do not have to call vb2_buffer_done() for each buffer they own
anymore.
Also remove the return value from the callback.
Signed-off-by: Pawel Osciak pa...@osciak.com
---
drivers/media/video/videobuf2-core.c | 16 ++--
include/media/videobuf2-core.h | 16 +++-
2 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 6e69584..59d5e8b 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -640,6 +640,9 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
vb2_buffer_state state)
struct vb2_queue *q = vb-vb2_queue;
unsigned long flags;
+ if (atomic_read(q-queued_count) == 0)
+ return;
+
if (vb-state != VB2_BUF_STATE_ACTIVE)
return;
@@ -1178,12 +1181,20 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
unsigned int i;
/*
-* Tell driver to stop all transactions and release all queued
+* Tell the driver to stop all transactions and release all queued
* buffers.
*/
if (q-streaming)
call_qop(q, stop_streaming, q);
+
+ /*
+* All buffers should now not be in use by the driver anymore, but we
+* have to manually set queued_count to 0, as the driver was not
+* required to call vb2_buffer_done() from stop_streaming() for all
+* buffers it had queued.
+*/
q-streaming = 0;
+ atomic_set(q-queued_count, 0);
/*
* Remove all buffers from videobuf's list...
@@ -1197,7 +1208,7 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
wake_up_all(q-done_wq);
/*
-* Reinitialize all buffers for next use.
+* Reinitialize all buffers for future use.
*/
for (i = 0; i q-num_buffers; ++i)
q-bufs[i]-state = VB2_BUF_STATE_DEQUEUED;
@@ -1440,6 +1451,7 @@ int vb2_queue_init(struct vb2_queue *q)
BUG_ON(!q-ops-queue_setup);
BUG_ON(!q-ops-buf_queue);
+ BUG_ON(!q-ops-stop_streaming);
INIT_LIST_HEAD(q-queued_list);
INIT_LIST_HEAD(q-done_list);
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index f3bdbb2..8115fe9 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -184,7 +184,7 @@ struct vb2_buffer {
/**
* struct vb2_ops - driver-specific callbacks to be implemented by the driver
- * Required: queue_setup, buf_queue. The rest is optional.
+ * Required: queue_setup, buf_queue, stop_streaming. The rest is optional.
*
* @queue_setup: used to negotiate queue parameters between the userspace
* and the driver; called before memory allocation;
@@ -231,13 +231,11 @@ struct vb2_buffer {
* the driver before streaming begins (such as enabling
* the device);
* @stop_streaming:called when the 'streaming' state must be disabled;
- * drivers should stop any DMA transactions here (or wait
- * until they are finished) and give back all the buffers
- * received via buf_queue() by calling vb2_buffer_done()
- * for each of them;
- * drivers can use the vb2_wait_for_all_buffers() function
- * here to wait for asynchronous completion events that
- * call vb2_buffer_done(), such as ISRs;
+ * drivers should stop any DMA transactions here (or wait
+ * until they are finished) before returning;
+ * drivers can use the vb2_wait_for_all_buffers() function
+ * here to wait for asynchronous completion events, such
+ * as ISRs;
* @buf_queue: passes a buffer to the driver; the driver may start
* a hardware operation on that buffer; this callback
* MUST return immediately, i.e. it may NOT wait for
@@ -259,7 +257,7 @@ struct vb2_ops {
void (*buf_cleanup)(struct vb2_buffer *vb);
int (*start_streaming)(struct vb2_queue *q);
- int (*stop_streaming)(struct vb2_queue *q);
+ void (*stop_streaming)(struct vb2_queue *q);
void (*buf_queue)(struct vb2_buffer *vb);
};
--
1.7.4.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 4/5] [media] sh_mobile_ceu_camera: remove stop_streaming() callback return
The stop_streaming() callback does not return a value anymore.
Signed-off-by: Pawel Osciak pa...@osciak.com
---
drivers/media/video/sh_mobile_ceu_camera.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c
b/drivers/media/video/sh_mobile_ceu_camera.c
index 3fb8f4c..28df50d 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -427,7 +427,7 @@ static int sh_mobile_ceu_videobuf_init(struct vb2_buffer
*vb)
return 0;
}
-static int sh_mobile_ceu_stop_streaming(struct vb2_queue *q)
+static void sh_mobile_ceu_stop_streaming(struct vb2_queue *q)
{
struct soc_camera_device *icd = container_of(q, struct
soc_camera_device, vb2_vidq);
struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
@@ -444,7 +444,7 @@ static int sh_mobile_ceu_stop_streaming(struct vb2_queue *q)
spin_unlock_irqrestore(pcdev-lock, flags);
- return sh_mobile_ceu_soft_reset(pcdev);
+ sh_mobile_ceu_soft_reset(pcdev);
}
static struct vb2_ops sh_mobile_ceu_videobuf_ops = {
--
1.7.4.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 5/5] [media] mx3_camera: remove stop_streaming() callback return
The stop_streaming() callback does not return a value anymore.
Signed-off-by: Pawel Osciak pa...@osciak.com
---
drivers/media/video/mx3_camera.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index 8630c0c..1703b93 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -400,7 +400,7 @@ static int mx3_videobuf_init(struct vb2_buffer *vb)
return 0;
}
-static int mx3_stop_streaming(struct vb2_queue *q)
+static void mx3_stop_streaming(struct vb2_queue *q)
{
struct soc_camera_device *icd = soc_camera_from_vb2q(q);
struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
@@ -425,8 +425,6 @@ static int mx3_stop_streaming(struct vb2_queue *q)
}
spin_unlock_irqrestore(mx3_cam-lock, flags);
-
- return 0;
}
static struct vb2_ops mx3_videobuf_ops = {
--
1.7.4.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 3/5] [media] s5p-fimc: remove stop_streaming() callback return
The stop_streaming() callback does not return a value anymore.
Signed-off-by: Pawel Osciak pa...@osciak.com
---
drivers/media/video/s5p-fimc/fimc-capture.c |4 ++--
drivers/media/video/s5p-fimc/fimc-core.c|4 +---
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 95f8b4e1..34e55a4 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -247,7 +247,7 @@ static int start_streaming(struct vb2_queue *q)
return 0;
}
-static int stop_streaming(struct vb2_queue *q)
+static void stop_streaming(struct vb2_queue *q)
{
struct fimc_ctx *ctx = q-drv_priv;
struct fimc_dev *fimc = ctx-fimc_dev;
@@ -255,7 +255,7 @@ static int stop_streaming(struct vb2_queue *q)
if (!fimc_capture_active(fimc))
return -EINVAL;
- return fimc_stop_capture(fimc);
+ fimc_stop_capture(fimc);
}
static unsigned int get_plane_size(struct fimc_frame *fr, unsigned int plane)
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 6c919b3..66571d7 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -348,13 +348,11 @@ static void fimc_m2m_shutdown(struct fimc_ctx *ctx)
fimc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
}
-static int stop_streaming(struct vb2_queue *q)
+static void stop_streaming(struct vb2_queue *q)
{
struct fimc_ctx *ctx = q-drv_priv;
fimc_m2m_shutdown(ctx);
-
- return 0;
}
static void fimc_capture_irq_handler(struct fimc_dev *fimc)
--
1.7.4.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 2/5] [media] vivi: adapt to the new stop_streaming() callback behavior
Drivers are no longer required to call vb2_buffer_done() for all buffers
they have queued in stop_streaming().
The return value for stop_streaming() has also been removed.
Signed-off-by: Pawel Osciak pa...@osciak.com
---
drivers/media/video/vivi.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c
index 2238a61..fcf11d7 100644
--- a/drivers/media/video/vivi.c
+++ b/drivers/media/video/vivi.c
@@ -627,8 +627,8 @@ static void vivi_stop_generating(struct vivi_dev *dev)
}
/*
-* Typical driver might need to wait here until dma engine stops.
-* In this case we can abort imiedetly, so it's just a noop.
+* A typical driver might need to stop the hardware here and wait
+* for any ongoing operations to finish.
*/
/* Release all active buffers */
@@ -636,7 +636,6 @@ static void vivi_stop_generating(struct vivi_dev *dev)
struct vivi_buffer *buf;
buf = list_entry(dma_q-active.next, struct vivi_buffer, list);
list_del(buf-list);
- vb2_buffer_done(buf-vb, VB2_BUF_STATE_ERROR);
dprintk(dev, 2, [%p/%d] done\n, buf, buf-vb.v4l2_buf.index);
}
}
@@ -766,13 +765,11 @@ static int start_streaming(struct vb2_queue *vq)
return vivi_start_generating(dev);
}
-/* abort streaming and wait for last buffer */
-static int stop_streaming(struct vb2_queue *vq)
+static void stop_streaming(struct vb2_queue *vq)
{
struct vivi_dev *dev = vb2_get_drv_priv(vq);
dprintk(dev, 1, %s\n, __func__);
vivi_stop_generating(dev);
- return 0;
}
static void vivi_lock(struct vb2_queue *vq)
--
1.7.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [media] cx88: use a mutex to protect cx8802_devlist
I added some printk entries and finally got suspicious output after
rmmod cx88_blackbird ; modprobe cx88_blackbird debug=true
[...]
cx88[0]/2: registered device video3 [mpeg]
cx88[0]/2-bb: mpeg_open
[cx88-blackbird.c,mpeg_open(),line 1059] mutex_lock(dev-core-lock);
cx88[0]/2-bb: Initialize codec
[...]
cx88[0]/2-bb: open dev=video3
[cx88-blackbird.c,mpeg_open(),line 1103] mutex_unlock(dev-core-lock);
// normal exit
[...]
cx88[1]/2: subsystem: 0070:9601, board: Hauppauge WinTV-HVR1300
DVB-T/Hybrid MPEG Encoder [card=56]
[cx88-blackbird.c,mpeg_release(),line 1122] mutex_lock(dev-core-lock);
cx88[0] core-active_ref=0
[cx88-mpeg.c,cx8802_request_release(),line 655]
// BANG !!! core-active_ref=-1
[cx88-blackbird.c,mpeg_release(),line 1129] drv-request_release(drv);
// drv-core-active_ref=(0-0)
[cx88-blackbird.c,mpeg_release(),line 1133]
mutex_unlock(dev-core-lock); // normal exit
cx88[1]/2-bb: cx8802_blackbird_probe
[...]
Analyzing this lead me to the conclusion, that a call to mpeg_open() in
cx88-blackbird.c
returns with 0 (= success)
while not actually having increased the active_ref count.
Here's the relevant code fragment ...
static int mpeg_open(struct file *file)
{
[...]
/* Make sure we can acquire the hardware */
drv = cx8802_get_driver(dev, CX88_MPEG_BLACKBIRD); // HOW TO
DEAL WITH NULL ??
if (drv) {
err = drv-request_acquire(drv);
if(err != 0) {
dprintk(1,%s: Unable to acquire hardware, %d\n, __func__,
err);
mutex_unlock(dev-core-lock);
return err;
}
}
[...]
return 0;
}
I suspect, that
drv = cx8802_get_driver(dev, CX88_MPEG_BLACKBIRD);
in my case might evaluates to NULL (not normally but during driver
initialization!?)
which then leads to
1) mpeg_open() returns with success
and
2) active_ref count has not been increased
which results in a negative active_ref count later on.
But I might as well be totally wrong.
Andi
On 02.04.2011 22:13, Andreas Huber wrote:
Hi Jonathan, thanks for locking into it.
I'll try to debug more deeply what's going wrong and keep you up to date.
Andi.
On 02.04.2011 21:29, Jonathan Nieder wrote:
Hi Andreas,
(please turn off HTML mail.)
Andreas Huber wrote:
There is a reference count bug in the driver code. The driver's
active_ref count may become negative which leads to unpredictable
behavior. (mpeg video device inaccessible, etc ...)
Hmm, the patchset didn't touch active_ref handling.
active_ref was added by v2.6.25-rc3~132^2~7 (V4L/DVB (7194):
cx88-mpeg: Allow concurrent access to cx88-mpeg devices, 2008-02-11)
and relies on three assumptions:
* (successful) calls to cx8802_driver::request_acquire are balanced
with calls to cx8802_driver::request_release;
* cx8802_driver::advise_acquire is non-null if and only if
cx8802_driver::advise_release is (since both are NULL for
blackbird, non-NULL for dvb);
* no data races.
I suppose it would be more idiomatic to use an atomic_t, but access to
active_ref was previously protected by the BKL and now it is protected
by core-lock. So it's not clear to me why this doesn't work.
Any hints? (e.g., a detailed reproduction recipe, or a log after
adding a printk to find out when exactly active_ref becomes negative)
Thanks for reporting.
Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/5] [media] vb2: redesign the stop_streaming() callback and make it obligatory
Hello,
On Monday, April 04, 2011 1:51 AM Pawel Osciak wrote:
Drivers are now required to implement the stop_streaming() callback
to ensure that all ongoing hardware operations are finished and their
ownership of buffers is ceded.
Drivers do not have to call vb2_buffer_done() for each buffer they own
anymore.
Also remove the return value from the callback.
Signed-off-by: Pawel Osciak pa...@osciak.com
---
drivers/media/video/videobuf2-core.c | 16 ++--
include/media/videobuf2-core.h | 16 +++-
2 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 6e69584..59d5e8b 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -640,6 +640,9 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
vb2_buffer_state state)
struct vb2_queue *q = vb-vb2_queue;
unsigned long flags;
+ if (atomic_read(q-queued_count) == 0)
+ return;
+
if (vb-state != VB2_BUF_STATE_ACTIVE)
return;
@@ -1178,12 +1181,20 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
unsigned int i;
/*
- * Tell driver to stop all transactions and release all queued
+ * Tell the driver to stop all transactions and release all queued
* buffers.
*/
if (q-streaming)
call_qop(q, stop_streaming, q);
+
+ /*
+ * All buffers should now not be in use by the driver anymore, but we
+ * have to manually set queued_count to 0, as the driver was not
+ * required to call vb2_buffer_done() from stop_streaming() for all
+ * buffers it had queued.
+ */
q-streaming = 0;
+ atomic_set(q-queued_count, 0);
If you removed the need to call vb2_buffer_done() then you must also call
wake_up_all(q-done_wq) to wake any other threads/processes that might be
sleeping waiting for buffers.
/*
* Remove all buffers from videobuf's list...
@@ -1197,7 +1208,7 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
wake_up_all(q-done_wq);
/*
- * Reinitialize all buffers for next use.
+ * Reinitialize all buffers for future use.
*/
for (i = 0; i q-num_buffers; ++i)
q-bufs[i]-state = VB2_BUF_STATE_DEQUEUED;
@@ -1440,6 +1451,7 @@ int vb2_queue_init(struct vb2_queue *q)
BUG_ON(!q-ops-queue_setup);
BUG_ON(!q-ops-buf_queue);
+ BUG_ON(!q-ops-stop_streaming);
INIT_LIST_HEAD(q-queued_list);
INIT_LIST_HEAD(q-done_list);
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index f3bdbb2..8115fe9 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -184,7 +184,7 @@ struct vb2_buffer {
/**
* struct vb2_ops - driver-specific callbacks to be implemented by the driver
- * Required: queue_setup, buf_queue. The rest is optional.
+ * Required: queue_setup, buf_queue, stop_streaming. The rest is optional.
*
* @queue_setup: used to negotiate queue parameters between the userspace
* and the driver; called before memory allocation;
@@ -231,13 +231,11 @@ struct vb2_buffer {
* the driver before streaming begins (such as enabling
* the device);
* @stop_streaming: called when the 'streaming' state must be disabled;
- * drivers should stop any DMA transactions here (or wait
- * until they are finished) and give back all the buffers
- * received via buf_queue() by calling vb2_buffer_done()
- * for each of them;
- * drivers can use the vb2_wait_for_all_buffers() function
- * here to wait for asynchronous completion events that
- * call vb2_buffer_done(), such as ISRs;
+ * drivers should stop any DMA transactions here (or wait
+ * until they are finished) before returning;
+ * drivers can use the vb2_wait_for_all_buffers() function
+ * here to wait for asynchronous completion events, such
+ * as ISRs;
* @buf_queue: passes a buffer to the driver; the driver may
start
* a hardware operation on that buffer; this callback
* MUST return immediately, i.e. it may NOT wait for
@@ -259,7 +257,7 @@ struct vb2_ops {
void (*buf_cleanup)(struct vb2_buffer *vb);
int (*start_streaming)(struct vb2_queue *q);
- int (*stop_streaming)(struct vb2_queue *q);
+ void (*stop_streaming)(struct vb2_queue *q);
void (*buf_queue)(struct vb2_buffer *vb);
};
Best regards
--
Marek Szyprowski
Samsung Poland RD Center
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
