WinTV-HVR-1250 Linux (analog)
Hi, I was just wondering if anyone could tell me is this card works for analog TV (NTSC, PAL). I see from this page it says something about analog not supported which doesn't seem right. What does this really mean? It is supported under Linux since kernel 2.6.27. (Note: Analog support is not implemented yet). http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1250 Thanks, hope someone can help.. -- 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] hdpvr: enable IR part
On Jan 15, 2011, at 12:37 AM, Jarod Wilson wrote: > On Jan 14, 2011, at 11:35 PM, Andy Walls wrote: > >> On Fri, 2011-01-14 at 21:30 -0500, Jarod Wilson wrote: >>> On Jan 14, 2011, at 5:08 PM, Jarod Wilson wrote: >> >> Registered IR keymap rc-hauppauge-new >> input: i2c IR (HD PVR) as /devices/virtual/rc/rc1/input6 >> rc1: i2c IR (HD PVR) as /devices/virtual/rc/rc1 >> ir-kbd-i2c: i2c IR (HD PVR) detected at i2c-1/1-0071/ir0 [Hauppage HD >> PVR I2C] >>> >>> And it *almost* works. Every key on the bundled remote is recognized, but >>> every press gets feedback about like this w/evtest: >>> >>> Event: time 1295058330.966180, type 4 (Misc), code 4 (ScanCode), value 29 >>> Event: time 1295058330.966212, type 1 (Key), code 401 (Blue), value 1 >>> Event: time 1295058330.966220, -- Report Sync >>> Event: time 1295058331.066175, type 4 (Misc), code 4 (ScanCode), value 29 >>> Event: time 1295058331.166290, type 4 (Misc), code 4 (ScanCode), value 29 >>> Event: time 1295058331.275664, type 4 (Misc), code 4 (ScanCode), value 29 >>> Event: time 1295058331.376160, type 4 (Misc), code 4 (ScanCode), value 29 >>> Event: time 1295058331.465505, type 1 (Key), code 401 (Blue), value 2 >>> Event: time 1295058331.476161, type 4 (Misc), code 4 (ScanCode), value 29 >>> Event: time 1295058331.498502, type 1 (Key), code 401 (Blue), value 2 >>> Event: time 1295058331.531504, type 1 (Key), code 401 (Blue), value 2 >>> Event: time 1295058331.564503, type 1 (Key), code 401 (Blue), value 2 >>> Event: time 1295058331.576153, type 4 (Misc), code 4 (ScanCode), value 29 >>> Event: time 1295058331.597502, type 1 (Key), code 401 (Blue), value 2 >>> Event: time 1295058331.630501, type 1 (Key), code 401 (Blue), value 2 >>> Event: time 1295058331.663502, type 1 (Key), code 401 (Blue), value 2 >>> Event: time 1295058331.696500, type 1 (Key), code 401 (Blue), value 2 >>> Event: time 1295058331.729503, type 1 (Key), code 401 (Blue), value 2 >>> Event: time 1295058331.762502, type 1 (Key), code 401 (Blue), value 2 >>> Event: time 1295058331.795500, type 1 (Key), code 401 (Blue), value 2 >>> Event: time 1295058331.825507, type 1 (Key), code 401 (Blue), value 0 >>> Event: time 1295058331.825526, -- Report Sync >>> >>> That's just a single short press. With arrow keys, its quite funky to >>> watch in, say, mythtv UI menus. Hit up, and it moves up one, stalls for a >>> second, then moves up several more. >> >> Hmm bizzarre. > > Shouldn't have said "stalls for a second", its a just brief pause, but > regardless, yeah, its kinda odd. Okay, last spam before I head off to bed... :) I can get ir-kbd-i2c behavior to pretty much match lirc_zilog wrt key repeat, by simply setting init_data->polling_interval = 260; in hdpvr-i2c.c, which matches up with the delay in lirc_zilog. With the 260 interval: Event: time 1295072449.490542, -- Report Sync Event: time 1295072453.321206, type 4 (Misc), code 4 (ScanCode), value 15 Event: time 1295072453.321245, type 1 (Key), code 108 (Down), value 1 Event: time 1295072453.321252, -- Report Sync Event: time 1295072453.570512, type 1 (Key), code 108 (Down), value 0 Event: time 1295072453.570544, -- Report Sync Event: time 1295072453.575718, type 4 (Misc), code 4 (ScanCode), value 15 Event: time 1295072453.575744, type 1 (Key), code 108 (Down), value 1 Event: time 1295072453.575752, -- Report Sync Event: time 1295072453.816215, type 4 (Misc), code 4 (ScanCode), value 15 Event: time 1295072454.065515, type 1 (Key), code 108 (Down), value 0 Event: time 1295072454.065544, -- Report Sync Lowering this a bit, I can get split personality, one press will look like what I was originally seeing, another will look like the 260 output. Adding filtering (return 0 if buf[0] != 0x80) doesn't help any. The final thing I've noticed tonight is that ir-kbd-i2c calls rc_keydown using a value of 0 for its 3rd parameter. From rc-main.c: * @toggle: the toggle value (protocol dependent, if the protocol doesn't * support toggle values, this should be set to zero) Well, in this case, the protocol *does* use a toggle, so that's probably something that could use fixing. Not sure it actually has anything to do with the odd repeats I'm seeing. Okay, wasn't too much work to pass along toggle values too, but it didn't help any. I'll sleep on it. -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hdpvr: enable IR part
On Jan 15, 2011, at 12:37 AM, Jarod Wilson wrote: ... >> BTW, a checkpatch and compiler tested lirc_zilog.c is here: >> >> http://git.linuxtv.org/awalls/media_tree.git?a=shortlog;h=refs/heads/z8 >> >> It should fix all the binding and allocation problems related to >> ir_probe()/ir_remove(). Except I suspect it may leak the Rx poll >> kthread. That's possibly another bug to add to the list. >> >> Anyway, $DIETY knows if the lirc_zilog module actually still works after >> all my hacks. Give it a test if you are adventurous. I won't be able >> to test until tomorrow evening. > > I'll try to grab those and give them a test tomorrow, and hey, I've even got > a baseline to test against now. Forgot to mention: I think it was suggested that one could use ir-kbd-i2c for receive and lirc_zilog for transmit, at the same time. With ir-kbd-i2c already loaded, lirc_zilog currently won't bind to anything. -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hdpvr: enable IR part
On Jan 14, 2011, at 11:35 PM, Andy Walls wrote: > On Fri, 2011-01-14 at 21:30 -0500, Jarod Wilson wrote: >> On Jan 14, 2011, at 5:08 PM, Jarod Wilson wrote: > > Registered IR keymap rc-hauppauge-new > input: i2c IR (HD PVR) as /devices/virtual/rc/rc1/input6 > rc1: i2c IR (HD PVR) as /devices/virtual/rc/rc1 > ir-kbd-i2c: i2c IR (HD PVR) detected at i2c-1/1-0071/ir0 [Hauppage HD PVR > I2C] >> >> And it *almost* works. Every key on the bundled remote is recognized, but >> every press gets feedback about like this w/evtest: >> >> Event: time 1295058330.966180, type 4 (Misc), code 4 (ScanCode), value 29 >> Event: time 1295058330.966212, type 1 (Key), code 401 (Blue), value 1 >> Event: time 1295058330.966220, -- Report Sync >> Event: time 1295058331.066175, type 4 (Misc), code 4 (ScanCode), value 29 >> Event: time 1295058331.166290, type 4 (Misc), code 4 (ScanCode), value 29 >> Event: time 1295058331.275664, type 4 (Misc), code 4 (ScanCode), value 29 >> Event: time 1295058331.376160, type 4 (Misc), code 4 (ScanCode), value 29 >> Event: time 1295058331.465505, type 1 (Key), code 401 (Blue), value 2 >> Event: time 1295058331.476161, type 4 (Misc), code 4 (ScanCode), value 29 >> Event: time 1295058331.498502, type 1 (Key), code 401 (Blue), value 2 >> Event: time 1295058331.531504, type 1 (Key), code 401 (Blue), value 2 >> Event: time 1295058331.564503, type 1 (Key), code 401 (Blue), value 2 >> Event: time 1295058331.576153, type 4 (Misc), code 4 (ScanCode), value 29 >> Event: time 1295058331.597502, type 1 (Key), code 401 (Blue), value 2 >> Event: time 1295058331.630501, type 1 (Key), code 401 (Blue), value 2 >> Event: time 1295058331.663502, type 1 (Key), code 401 (Blue), value 2 >> Event: time 1295058331.696500, type 1 (Key), code 401 (Blue), value 2 >> Event: time 1295058331.729503, type 1 (Key), code 401 (Blue), value 2 >> Event: time 1295058331.762502, type 1 (Key), code 401 (Blue), value 2 >> Event: time 1295058331.795500, type 1 (Key), code 401 (Blue), value 2 >> Event: time 1295058331.825507, type 1 (Key), code 401 (Blue), value 0 >> Event: time 1295058331.825526, -- Report Sync >> >> That's just a single short press. With arrow keys, its quite funky to >> watch in, say, mythtv UI menus. Hit up, and it moves up one, stalls for a >> second, then moves up several more. > > Hmm bizzarre. Shouldn't have said "stalls for a second", its a just brief pause, but regardless, yeah, its kinda odd. >> ... Note, that code in lirc_zilog.c indicates that ir-kbd-i2c.c's function get_key_haup_xvr() *may* need some additions to account for the Rx data format. I'm not sure of this though. (Or a custom get_key() in the hdpvr module could be provided as a function pointer to ir-kbd-i2c.c via platform_data.) I will provide a debug patch in another email so that it's easier to see the data ir-kbd-i2c.c sees coming from the Z8. >>> >>> I'll tack that onto the machine I've got hooked to the hdpvr and see what >>> I can see this weekend, thanks much for the pointers. >> >> I'm inclined to think that it does indeed need some of the changes from >> lirc_zilog brought over (or the custom get_key()). Now on to adding that >> patch and some testing with lirc_zilog... A single button press w/ir-kbd-i2c debugging and your patch: ir-kbd-i2c: ir_poll_key ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 54 00T. ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=21 ir-kbd-i2c: ir_poll_key ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 54 00T. ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=21 ir-kbd-i2c: ir_poll_key ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 54 00T. ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=21 ir-kbd-i2c: ir_poll_key ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 54 00T. ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=21 ir-kbd-i2c: ir_poll_key ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 54 00T. ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=21 ir-kbd-i2c: ir_poll_key ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 54 00T. ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=21 > Yes, maybe both the Rx data parsing *and* the precise delay between Rx > polls. Receive with lirc_zilog does actually work slightly better, though its still not perfect. Each key press (using irw to watch) always results in at least two lines of output, both with sequence number 00 (i.e., two distinct events), and holding a button down results in a stream of 00 events. So repeat is obviously busted. But I don't see the wackiness that is happening w/ir-kbd-i2c. Oh, and transmit works too. So this patch and the buffer alloc patch have now been formally tested. Unless we go the custom get_key() route inside the hdpvr driver, I think the re
no sound with WinTV HVR-980 - Help
Hello I am running the following OS "Ubuntu 10.04.1 LTS" with Mythtv I have a WinTv HVR-980 and hvae no sound with video see errors below any assistance would be appreciated. I should have a /dev/dsp1 but I can not find it? [ 28.349674] em28xx #0: Config register raw data: 0xd0 [ 28.350444] em28xx #0: AC97 vendor ID = 0x [ 28.350819] em28xx #0: AC97 features = 0x6a90 [ 28.350822] em28xx #0: Empia 202 AC97 audio processor detected [ 28.588908] em28xx #0: v4l2 driver version 0.1.2 [ 28.676311] em28xx #0: V4L2 video device registered as /dev/video0 [ 28.676315] em28xx #0: V4L2 VBI device registered as /dev/vbi0 [ 28.692112] usbcore: registered new interface driver em28xx [ 28.692117] em28xx driver loaded [ 28.706196] em28xx_alsa: disagrees about version of symbol snd_pcm_new [ 28.706201] em28xx_alsa: Unknown symbol snd_pcm_new [ 28.706319] em28xx_alsa: disagrees about version of symbol snd_card_register [ 28.706322] em28xx_alsa: Unknown symbol snd_card_register [ 28.706438] em28xx_alsa: disagrees about version of symbol snd_card_free [ 28.706440] em28xx_alsa: Unknown symbol snd_card_free [ 28.706673] em28xx_alsa: disagrees about version of symbol snd_pcm_lib_ioctl [ 28.706675] em28xx_alsa: Unknown symbol snd_pcm_lib_ioctl [ 28.706988] em28xx_alsa: disagrees about version of symbol snd_pcm_set_ops [ 28.706990] em28xx_alsa: Unknown symbol snd_pcm_set_ops [ 28.707209] em28xx_alsa: disagrees about version of symbol snd_pcm_hw_constraint_integer [ 28.707212] em28xx_alsa: Unknown symbol snd_pcm_hw_constraint_integer [ 28.707657] em28xx_alsa: disagrees about version of symbol snd_card_create [ 28.707660] em28xx_alsa: Unknown symbol snd_card_create [ 28.707766] em28xx_alsa: disagrees about version of symbol snd_pcm_period_elapsed [ 28.707768] em28xx_alsa: Unknown symbol snd_pcm_period_elapsed [ 28.910841] em28xx #0/2: xc3028 attached [ 28.910844] DVB: registering new adapter (em28xx #0) [ 28.911226] Successfully loaded em28xx-dvb -- 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] hdpvr: enable IR part
On Fri, 2011-01-14 at 21:30 -0500, Jarod Wilson wrote: > On Jan 14, 2011, at 5:08 PM, Jarod Wilson wrote: > >>> Registered IR keymap rc-hauppauge-new > >>> input: i2c IR (HD PVR) as /devices/virtual/rc/rc1/input6 > >>> rc1: i2c IR (HD PVR) as /devices/virtual/rc/rc1 > >>> ir-kbd-i2c: i2c IR (HD PVR) detected at i2c-1/1-0071/ir0 [Hauppage HD PVR > >>> I2C] > > And it *almost* works. Every key on the bundled remote is recognized, but > every press gets feedback about like this w/evtest: > > Event: time 1295058330.966180, type 4 (Misc), code 4 (ScanCode), value 29 > Event: time 1295058330.966212, type 1 (Key), code 401 (Blue), value 1 > Event: time 1295058330.966220, -- Report Sync > Event: time 1295058331.066175, type 4 (Misc), code 4 (ScanCode), value 29 > Event: time 1295058331.166290, type 4 (Misc), code 4 (ScanCode), value 29 > Event: time 1295058331.275664, type 4 (Misc), code 4 (ScanCode), value 29 > Event: time 1295058331.376160, type 4 (Misc), code 4 (ScanCode), value 29 > Event: time 1295058331.465505, type 1 (Key), code 401 (Blue), value 2 > Event: time 1295058331.476161, type 4 (Misc), code 4 (ScanCode), value 29 > Event: time 1295058331.498502, type 1 (Key), code 401 (Blue), value 2 > Event: time 1295058331.531504, type 1 (Key), code 401 (Blue), value 2 > Event: time 1295058331.564503, type 1 (Key), code 401 (Blue), value 2 > Event: time 1295058331.576153, type 4 (Misc), code 4 (ScanCode), value 29 > Event: time 1295058331.597502, type 1 (Key), code 401 (Blue), value 2 > Event: time 1295058331.630501, type 1 (Key), code 401 (Blue), value 2 > Event: time 1295058331.663502, type 1 (Key), code 401 (Blue), value 2 > Event: time 1295058331.696500, type 1 (Key), code 401 (Blue), value 2 > Event: time 1295058331.729503, type 1 (Key), code 401 (Blue), value 2 > Event: time 1295058331.762502, type 1 (Key), code 401 (Blue), value 2 > Event: time 1295058331.795500, type 1 (Key), code 401 (Blue), value 2 > Event: time 1295058331.825507, type 1 (Key), code 401 (Blue), value 0 > Event: time 1295058331.825526, -- Report Sync > > That's just a single short press. With arrow keys, its quite funky to > watch in, say, mythtv UI menus. Hit up, and it moves up one, stalls for a > second, then moves up several more. Hmm bizzarre. > ... > >> Note, that code in lirc_zilog.c indicates that ir-kbd-i2c.c's function > >> get_key_haup_xvr() *may* need some additions to account for the Rx data > >> format. I'm not sure of this though. (Or a custom get_key() in the > >> hdpvr module could be provided as a function pointer to ir-kbd-i2c.c via > >> platform_data.) > >> > >> I will provide a debug patch in another email so that it's easier to see > >> the data ir-kbd-i2c.c sees coming from the Z8. > > > > I'll tack that onto the machine I've got hooked to the hdpvr and see what > > I can see this weekend, thanks much for the pointers. > > I'm inclined to think that it does indeed need some of the changes from > lirc_zilog brought over (or the custom get_key()). Now on to adding that > patch and some testing with lirc_zilog... Yes, maybe both the Rx data parsing *and* the precise delay between Rx polls. BTW, a checkpatch and compiler tested lirc_zilog.c is here: http://git.linuxtv.org/awalls/media_tree.git?a=shortlog;h=refs/heads/z8 It should fix all the binding and allocation problems related to ir_probe()/ir_remove(). Except I suspect it may leak the Rx poll kthread. That's possibly another bug to add to the list. Anyway, $DIETY knows if the lirc_zilog module actually still works after all my hacks. Give it a test if you are adventurous. I won't be able to test until tomorrow evening. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hdpvr: enable IR part
On Jan 14, 2011, at 5:08 PM, Jarod Wilson wrote: > On Fri, Jan 14, 2011 at 04:44:40PM -0500, Andy Walls wrote: >> On Fri, 2011-01-14 at 14:54 -0500, Jarod Wilson wrote: >>> A number of things going on here, but the end result is that the IR part >>> on the hdpvr gets enabled, and can be used with ir-kbd-i2c and/or >>> lirc_zilog. >>> >>> First up, there are some conditional build fixes that come into play >>> whether i2c is built-in or modular. Second, we're swapping out >>> i2c_new_probed_device() for i2c_new_device(), as in my testing, probing >>> always fails, but we *know* that all hdpvr devices have a z8 chip at >>> 0x70 and 0x71. Third, we're poking at an i2c address directly without a >>> client, and writing some magic bits to actually turn on this IR part >>> (this could use some improvement in the future). Fourth, some of the >>> i2c_adapter storage has been reworked, as the existing implementation >>> used to lead to an oops following i2c changes c. 2.6.31. >>> >>> Earlier editions of this patch have been floating around the 'net for a >>> while, including being patched into Fedora kernels, and they *do* work. >>> This specific version isn't yet tested, beyond loading ir-kbd-i2c and >>> confirming that it does bind to the RX address of the hdpvr: >>> >>> Registered IR keymap rc-hauppauge-new >>> input: i2c IR (HD PVR) as /devices/virtual/rc/rc1/input6 >>> rc1: i2c IR (HD PVR) as /devices/virtual/rc/rc1 >>> ir-kbd-i2c: i2c IR (HD PVR) detected at i2c-1/1-0071/ir0 [Hauppage HD PVR >>> I2C] And it *almost* works. Every key on the bundled remote is recognized, but every press gets feedback about like this w/evtest: Event: time 1295058330.966180, type 4 (Misc), code 4 (ScanCode), value 29 Event: time 1295058330.966212, type 1 (Key), code 401 (Blue), value 1 Event: time 1295058330.966220, -- Report Sync Event: time 1295058331.066175, type 4 (Misc), code 4 (ScanCode), value 29 Event: time 1295058331.166290, type 4 (Misc), code 4 (ScanCode), value 29 Event: time 1295058331.275664, type 4 (Misc), code 4 (ScanCode), value 29 Event: time 1295058331.376160, type 4 (Misc), code 4 (ScanCode), value 29 Event: time 1295058331.465505, type 1 (Key), code 401 (Blue), value 2 Event: time 1295058331.476161, type 4 (Misc), code 4 (ScanCode), value 29 Event: time 1295058331.498502, type 1 (Key), code 401 (Blue), value 2 Event: time 1295058331.531504, type 1 (Key), code 401 (Blue), value 2 Event: time 1295058331.564503, type 1 (Key), code 401 (Blue), value 2 Event: time 1295058331.576153, type 4 (Misc), code 4 (ScanCode), value 29 Event: time 1295058331.597502, type 1 (Key), code 401 (Blue), value 2 Event: time 1295058331.630501, type 1 (Key), code 401 (Blue), value 2 Event: time 1295058331.663502, type 1 (Key), code 401 (Blue), value 2 Event: time 1295058331.696500, type 1 (Key), code 401 (Blue), value 2 Event: time 1295058331.729503, type 1 (Key), code 401 (Blue), value 2 Event: time 1295058331.762502, type 1 (Key), code 401 (Blue), value 2 Event: time 1295058331.795500, type 1 (Key), code 401 (Blue), value 2 Event: time 1295058331.825507, type 1 (Key), code 401 (Blue), value 0 Event: time 1295058331.825526, -- Report Sync That's just a single short press. With arrow keys, its quite funky to watch in, say, mythtv UI menus. Hit up, and it moves up one, stalls for a second, then moves up several more. ... >> Note, that code in lirc_zilog.c indicates that ir-kbd-i2c.c's function >> get_key_haup_xvr() *may* need some additions to account for the Rx data >> format. I'm not sure of this though. (Or a custom get_key() in the >> hdpvr module could be provided as a function pointer to ir-kbd-i2c.c via >> platform_data.) >> >> I will provide a debug patch in another email so that it's easier to see >> the data ir-kbd-i2c.c sees coming from the Z8. > > I'll tack that onto the machine I've got hooked to the hdpvr and see what > I can see this weekend, thanks much for the pointers. I'm inclined to think that it does indeed need some of the changes from lirc_zilog brought over (or the custom get_key()). Now on to adding that patch and some testing with lirc_zilog... -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
VIDIOC_INT_RESET still needed in ivtv for the moment
Hans, A few weeks ago you asked if VIDIOC_INT_RESET is still needed in ivtv. I can now say for certain, that yes, it is still needed. See this from 2008: http://www.mail-archive.com/ivtv-users@ivtvdriver.org/msg08613.html It will not be needed after I get two things done: 1. patch ivtv to issue a GPIO reset of the IR chip at module load. 2. add a way for the cx18, ivtv, and hdpvr bridge drivers to provide a reset callback to lirc_zilog. (I know ivtv and cx18 can provide one.) After that, cx18 and ivtv will not need the VIDIOC_INT_RESET ioctl(). Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hdpvr: enable IR part
On Fri, Jan 14, 2011 at 04:44:40PM -0500, Andy Walls wrote: > On Fri, 2011-01-14 at 14:54 -0500, Jarod Wilson wrote: > > A number of things going on here, but the end result is that the IR part > > on the hdpvr gets enabled, and can be used with ir-kbd-i2c and/or > > lirc_zilog. > > > > First up, there are some conditional build fixes that come into play > > whether i2c is built-in or modular. Second, we're swapping out > > i2c_new_probed_device() for i2c_new_device(), as in my testing, probing > > always fails, but we *know* that all hdpvr devices have a z8 chip at > > 0x70 and 0x71. Third, we're poking at an i2c address directly without a > > client, and writing some magic bits to actually turn on this IR part > > (this could use some improvement in the future). Fourth, some of the > > i2c_adapter storage has been reworked, as the existing implementation > > used to lead to an oops following i2c changes c. 2.6.31. > > > > Earlier editions of this patch have been floating around the 'net for a > > while, including being patched into Fedora kernels, and they *do* work. > > This specific version isn't yet tested, beyond loading ir-kbd-i2c and > > confirming that it does bind to the RX address of the hdpvr: > > > > Registered IR keymap rc-hauppauge-new > > input: i2c IR (HD PVR) as /devices/virtual/rc/rc1/input6 > > rc1: i2c IR (HD PVR) as /devices/virtual/rc/rc1 > > ir-kbd-i2c: i2c IR (HD PVR) detected at i2c-1/1-0071/ir0 [Hauppage HD PVR > > I2C] > > > > (Yes, I'm posting before fully testing, and I do have a reason for that, > > and will post a v2 after testing this weekend, if need be)... > > As discussed on IRC > 1. no need to probe for the Z8 as HD PVR always has one. Did a bit further prodding w/i2cdetect under Jean's guidance[1]. The hdpvr hardware doesn't like the quick writes used by the i2c_new_probed_device() routine, but does work with short reads for detection. That would require writing a custom probe routine though, and just isn't worth the effort on the hdpvr, since we know it always has an IR part, so i2c_new_device() really is the way to go here. [1] 'i2cdetect -l' shows my hdpvr at i2c-1, 'i2cdetect 1', which probes similar to i2_new_probed_device() doesn't return a device where expected, but 'i2cdetect -r 1', which uses a short read, does. > 2. accessing the chip at address 0x54 directly should eventually be > reworked with nicer i2c subsystem methods, but that can wait Agreed, this should be cleaned up at some point. > Note, that code in lirc_zilog.c indicates that ir-kbd-i2c.c's function > get_key_haup_xvr() *may* need some additions to account for the Rx data > format. I'm not sure of this though. (Or a custom get_key() in the > hdpvr module could be provided as a function pointer to ir-kbd-i2c.c via > platform_data.) > > I will provide a debug patch in another email so that it's easier to see > the data ir-kbd-i2c.c sees coming from the Z8. I'll tack that onto the machine I've got hooked to the hdpvr and see what I can see this weekend, thanks much for the pointers. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ir-kbd-i2c: Add debug to examine received data in get_key_haup_common()
Add a hex dump of the received bytes for tester reporting of actual data received from the hardware. Signed-off-by: Andy Walls --- My heart won't be broken if this never makes it into the kernel. Regards, Andy diff --git a/drivers/media/video/ir-kbd-i2c.c b/drivers/media/video/ir-kbd-i2c.c index c87b6bc..b27fc43 100644 --- a/drivers/media/video/ir-kbd-i2c.c +++ b/drivers/media/video/ir-kbd-i2c.c @@ -76,6 +76,11 @@ static int get_key_haup_common(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw, if (size != i2c_master_recv(ir->c, buf, size)) return -EIO; + if (debug >= 2) + print_hex_dump_bytes(MODULE_NAME +": get_key_haup_common: received bytes: ", +DUMP_PREFIX_NONE, buf, size); + /* split rc5 data block ... */ start = (buf[offset] >> 7) &1; range = (buf[offset] >> 6) &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] hdpvr: enable IR part
On Fri, 2011-01-14 at 14:54 -0500, Jarod Wilson wrote:
> A number of things going on here, but the end result is that the IR part
> on the hdpvr gets enabled, and can be used with ir-kbd-i2c and/or
> lirc_zilog.
>
> First up, there are some conditional build fixes that come into play
> whether i2c is built-in or modular. Second, we're swapping out
> i2c_new_probed_device() for i2c_new_device(), as in my testing, probing
> always fails, but we *know* that all hdpvr devices have a z8 chip at
> 0x70 and 0x71. Third, we're poking at an i2c address directly without a
> client, and writing some magic bits to actually turn on this IR part
> (this could use some improvement in the future). Fourth, some of the
> i2c_adapter storage has been reworked, as the existing implementation
> used to lead to an oops following i2c changes c. 2.6.31.
>
> Earlier editions of this patch have been floating around the 'net for a
> while, including being patched into Fedora kernels, and they *do* work.
> This specific version isn't yet tested, beyond loading ir-kbd-i2c and
> confirming that it does bind to the RX address of the hdpvr:
>
> Registered IR keymap rc-hauppauge-new
> input: i2c IR (HD PVR) as /devices/virtual/rc/rc1/input6
> rc1: i2c IR (HD PVR) as /devices/virtual/rc/rc1
> ir-kbd-i2c: i2c IR (HD PVR) detected at i2c-1/1-0071/ir0 [Hauppage HD PVR I2C]
>
> (Yes, I'm posting before fully testing, and I do have a reason for that,
> and will post a v2 after testing this weekend, if need be)...
As discussed on IRC
1. no need to probe for the Z8 as HD PVR always has one.
2. accessing the chip at address 0x54 directly should eventually be
reworked with nicer i2c subsystem methods, but that can wait
So
Acked-by: Andy Walls
Note, that code in lirc_zilog.c indicates that ir-kbd-i2c.c's function
get_key_haup_xvr() *may* need some additions to account for the Rx data
format. I'm not sure of this though. (Or a custom get_key() in the
hdpvr module could be provided as a function pointer to ir-kbd-i2c.c via
platform_data.)
I will provide a debug patch in another email so that it's easier to see
the data ir-kbd-i2c.c sees coming from the Z8.
Regards,
Andy
> Signed-off-by: Jarod Wilson
> ---
> drivers/media/video/hdpvr/Makefile |4 +-
> drivers/media/video/hdpvr/hdpvr-core.c | 10 +--
> drivers/media/video/hdpvr/hdpvr-i2c.c | 120
> +++
> drivers/media/video/hdpvr/hdpvr-video.c |7 +--
> drivers/media/video/hdpvr/hdpvr.h |2 +-
> 5 files changed, 66 insertions(+), 77 deletions(-)
>
> diff --git a/drivers/media/video/hdpvr/Makefile
> b/drivers/media/video/hdpvr/Makefile
> index e0230fc..3baa9f6 100644
> --- a/drivers/media/video/hdpvr/Makefile
> +++ b/drivers/media/video/hdpvr/Makefile
> @@ -1,6 +1,4 @@
> -hdpvr-objs := hdpvr-control.o hdpvr-core.o hdpvr-video.o
> -
> -hdpvr-$(CONFIG_I2C) += hdpvr-i2c.o
> +hdpvr-objs := hdpvr-control.o hdpvr-core.o hdpvr-video.o hdpvr-i2c.o
>
> obj-$(CONFIG_VIDEO_HDPVR) += hdpvr.o
>
> diff --git a/drivers/media/video/hdpvr/hdpvr-core.c
> b/drivers/media/video/hdpvr/hdpvr-core.c
> index f7d1ee5..a6572e5 100644
> --- a/drivers/media/video/hdpvr/hdpvr-core.c
> +++ b/drivers/media/video/hdpvr/hdpvr-core.c
> @@ -378,19 +378,17 @@ static int hdpvr_probe(struct usb_interface *interface,
> goto error;
> }
>
> -#ifdef CONFIG_I2C
> - /* until i2c is working properly */
> - retval = 0; /* hdpvr_register_i2c_adapter(dev); */
> +#if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE)
> + retval = hdpvr_register_i2c_adapter(dev);
> if (retval < 0) {
> v4l2_err(&dev->v4l2_dev, "registering i2c adapter failed\n");
> goto error;
> }
>
> - /* until i2c is working properly */
> - retval = 0; /* hdpvr_register_i2c_ir(dev); */
> + retval = hdpvr_register_i2c_ir(dev);
> if (retval < 0)
> v4l2_err(&dev->v4l2_dev, "registering i2c IR devices failed\n");
> -#endif /* CONFIG_I2C */
> +#endif
>
> /* let the user know what node this device is now attached to */
> v4l2_info(&dev->v4l2_dev, "device now attached to %s\n",
> diff --git a/drivers/media/video/hdpvr/hdpvr-i2c.c
> b/drivers/media/video/hdpvr/hdpvr-i2c.c
> index 24966aa..c0696c3 100644
> --- a/drivers/media/video/hdpvr/hdpvr-i2c.c
> +++ b/drivers/media/video/hdpvr/hdpvr-i2c.c
> @@ -13,6 +13,8 @@
> *
> */
>
> +#if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE)
> +
> #include
> #include
>
> @@ -28,55 +30,31 @@
> #define Z8F0811_IR_TX_I2C_ADDR 0x70
> #define Z8F0811_IR_RX_I2C_ADDR 0x71
>
> -static const u8 ir_i2c_addrs[] = {
> - Z8F0811_IR_TX_I2C_ADDR,
> - Z8F0811_IR_RX_I2C_ADDR,
> -};
>
> -static const char * const ir_devicenames[] = {
> - "ir_tx_z8f0811_hdpvr",
> - "ir_rx_z8f0811_hdpvr",
> +static struct i2c_board_info hdpvr_i2c_board_info = {
> + I2C_BOARD_INFO("ir_tx_z8f0811_hdpvr", Z8F0811_IR_TX_I2C_ADDR),
> + I
Re: [PATCH v2] hdpvr: reduce latency of i2c read/write w/recycled buffer
On Fri, 14 Jan 2011 16:08:38 -0500, Jarod Wilson wrote: > The current hdpvr code kmalloc's a new buffer for every i2c read and > write. Rather than do that, lets allocate a buffer in the driver's > device struct and just use that every time. > > The size I've chosen for the buffer is the maximum size I could > ascertain might be used by either ir-kbd-i2c or lirc_zilog, plus a bit > of padding (lirc_zilog may use up to 100 bytes on tx, rounded that up > to 128). > > Note that this might also remedy user reports of very sluggish behavior > of IR receive with hdpvr hardware. > > v2: make sure (len <= (dev->i2c_buf)) [Jean Delvare] > > Reported-by: Jean Delvare > Signed-off-by: Jarod Wilson Acked-by: Jean Delvare -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] hdpvr: reduce latency of i2c read/write w/recycled buffer
The current hdpvr code kmalloc's a new buffer for every i2c read and
write. Rather than do that, lets allocate a buffer in the driver's
device struct and just use that every time.
The size I've chosen for the buffer is the maximum size I could
ascertain might be used by either ir-kbd-i2c or lirc_zilog, plus a bit
of padding (lirc_zilog may use up to 100 bytes on tx, rounded that up
to 128).
Note that this might also remedy user reports of very sluggish behavior
of IR receive with hdpvr hardware.
v2: make sure (len <= (dev->i2c_buf)) [Jean Delvare]
Reported-by: Jean Delvare
Signed-off-by: Jarod Wilson
---
Nb: This patch was done atop my prior patch 'hdpvr: enable IR part',
and serves no purpose if that patch isn't applied first.
drivers/media/video/hdpvr/hdpvr-i2c.c | 30 +-
drivers/media/video/hdpvr/hdpvr.h |3 +++
2 files changed, 16 insertions(+), 17 deletions(-)
diff --git a/drivers/media/video/hdpvr/hdpvr-i2c.c
b/drivers/media/video/hdpvr/hdpvr-i2c.c
index c0696c3..2adfe90 100644
--- a/drivers/media/video/hdpvr/hdpvr-i2c.c
+++ b/drivers/media/video/hdpvr/hdpvr-i2c.c
@@ -57,23 +57,21 @@ static int hdpvr_i2c_read(struct hdpvr_device *dev, int bus,
unsigned char addr, char *data, int len)
{
int ret;
- char *buf = kmalloc(len, GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
+
+ if (len > sizeof(dev->i2c_buf))
+ return -EINVAL;
ret = usb_control_msg(dev->udev,
usb_rcvctrlpipe(dev->udev, 0),
REQTYPE_I2C_READ, CTRL_READ_REQUEST,
- (bus << 8) | addr, 0, buf, len, 1000);
+ (bus << 8) | addr, 0, &dev->i2c_buf, len, 1000);
if (ret == len) {
- memcpy(data, buf, len);
+ memcpy(data, &dev->i2c_buf, len);
ret = 0;
} else if (ret >= 0)
ret = -EIO;
- kfree(buf);
-
return ret;
}
@@ -81,31 +79,29 @@ static int hdpvr_i2c_write(struct hdpvr_device *dev, int
bus,
unsigned char addr, char *data, int len)
{
int ret;
- char *buf = kmalloc(len, GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
- memcpy(buf, data, len);
+ if (len > sizeof(dev->i2c_buf))
+ return -EINVAL;
+
+ memcpy(&dev->i2c_buf, data, len);
ret = usb_control_msg(dev->udev,
usb_sndctrlpipe(dev->udev, 0),
REQTYPE_I2C_WRITE, CTRL_WRITE_REQUEST,
- (bus << 8) | addr, 0, buf, len, 1000);
+ (bus << 8) | addr, 0, &dev->i2c_buf, len, 1000);
if (ret < 0)
- goto error;
+ return ret;
ret = usb_control_msg(dev->udev,
usb_rcvctrlpipe(dev->udev, 0),
REQTYPE_I2C_WRITE_STATT, CTRL_READ_REQUEST,
- 0, 0, buf, 2, 1000);
+ 0, 0, &dev->i2c_buf, 2, 1000);
- if ((ret == 2) && (buf[1] == (len - 1)))
+ if ((ret == 2) && (dev->i2c_buf[1] == (len - 1)))
ret = 0;
else if (ret >= 0)
ret = -EIO;
-error:
- kfree(buf);
return ret;
}
diff --git a/drivers/media/video/hdpvr/hdpvr.h
b/drivers/media/video/hdpvr/hdpvr.h
index 29f7426..ee74e3b 100644
--- a/drivers/media/video/hdpvr/hdpvr.h
+++ b/drivers/media/video/hdpvr/hdpvr.h
@@ -25,6 +25,7 @@
KERNEL_VERSION(HDPVR_MAJOR_VERSION, HDPVR_MINOR_VERSION, HDPVR_RELEASE)
#define HDPVR_MAX 8
+#define HDPVR_I2C_MAX_SIZE 128
/* Define these values to match your devices */
#define HD_PVR_VENDOR_ID 0x2040
@@ -109,6 +110,8 @@ struct hdpvr_device {
struct i2c_adapter i2c_adapter;
/* I2C lock */
struct mutexi2c_mutex;
+ /* I2C message buffer space */
+ chari2c_buf[HDPVR_I2C_MAX_SIZE];
/* For passing data to ir-kbd-i2c */
struct IR_i2c_init_data ir_i2c_init_data;
--
1.7.1
--
Jarod Wilson
ja...@redhat.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hdpvr: reduce latency of i2c read/write w/recycled buffer
On Fri, Jan 14, 2011 at 09:35:24PM +0100, Jean Delvare wrote:
> Hi Jarod,
>
> On Fri, 14 Jan 2011 15:01:09 -0500, Jarod Wilson wrote:
> > The current hdpvr code kmalloc's a new buffer for every i2c read and
> > write. Rather than do that, lets allocate a buffer in the driver's
> > device struct and just use that every time.
> >
> > The size I've chosen for the buffer is the maximum size I could
> > ascertain might be used by either ir-kbd-i2c or lirc_zilog, plus a bit
> > of padding (lirc_zilog may use up to 100 bytes on tx, rounded that up
> > to 128).
>
> Definitely a good move, as discussed on IRC earlier this week.
>
> > Note that this might also remedy user reports of very sluggish behavior
> > of IR receive with hdpvr hardware.
>
> Maybe. But the fact that the Zilog is unresponsive during processing of
> sent data certainly contributes to this feeling too.
I believe this was the case even when tx wasn't in use, so I'm hopeful.
> > diff --git a/drivers/media/video/hdpvr/hdpvr-i2c.c
> > b/drivers/media/video/hdpvr/hdpvr-i2c.c
> > index c0696c3..7f1a313 100644
> > --- a/drivers/media/video/hdpvr/hdpvr-i2c.c
> > +++ b/drivers/media/video/hdpvr/hdpvr-i2c.c
> > @@ -57,23 +57,18 @@ static int hdpvr_i2c_read(struct hdpvr_device *dev, int
> > bus,
> > unsigned char addr, char *data, int len)
> > {
> > int ret;
> > - char *buf = kmalloc(len, GFP_KERNEL);
> > - if (!buf)
> > - return -ENOMEM;
> >
> > ret = usb_control_msg(dev->udev,
> > usb_rcvctrlpipe(dev->udev, 0),
> > REQTYPE_I2C_READ, CTRL_READ_REQUEST,
> > - (bus << 8) | addr, 0, buf, len, 1000);
> > + (bus << 8) | addr, 0, &dev->i2c_buf, len, 1000);
>
> Shouldn't you first ensure that len <= sizeof(dev->i2c_buf)? It should
> hopefully always be the case, but... if it isn't, you'll corrupt your
> data structure and possibly more.
...
> > @@ -81,31 +76,26 @@ static int hdpvr_i2c_write(struct hdpvr_device *dev,
> > int bus,
> >unsigned char addr, char *data, int len)
> > {
> > int ret;
> > - char *buf = kmalloc(len, GFP_KERNEL);
> > - if (!buf)
> > - return -ENOMEM;
> >
> > - memcpy(buf, data, len);
> > + memcpy(&dev->i2c_buf, data, len);
>
> Same here.
Yeah, while it *shouldn't* happen, making sure seems prudent. v2 in a
moment.
--
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] Add a 10 bpp packed greyscale format.
Add a 10 bits per pixel greyscale format in a packed array representation,
naming it Y10P. Such pixel format is supplied for instance by the Kinect
sensor device.
Signed-off-by: Antonio Ospite
---
Hi, this version should look better than the previous one.
It's not marked as RFC anymore, is it in a submittable state?
Comments from native English speakers always appreciated.
A rendered version of the documentation is _temporarily_ here:
http://shell.studenti.unina.it/~ospite/tmp/V4L2-PIX-FMT-Y10P.html
The main recipient is linux-media, but OpenKinect is on Cc so someone there
could double check the information is actually true.
Regards,
Antonio Ospite
http://ao2.it
Documentation/DocBook/media-entities.tmpl |1 +
Documentation/DocBook/v4l/pixfmt-y10p.xml | 43 +
Documentation/DocBook/v4l/pixfmt.xml |1 +
Documentation/DocBook/v4l/videodev2.h.xml |1 +
include/linux/videodev2.h |1 +
5 files changed, 47 insertions(+), 0 deletions(-)
create mode 100644 Documentation/DocBook/v4l/pixfmt-y10p.xml
diff --git a/Documentation/DocBook/media-entities.tmpl
b/Documentation/DocBook/media-entities.tmpl
index be34dcb..2b18de5 100644
--- a/Documentation/DocBook/media-entities.tmpl
+++ b/Documentation/DocBook/media-entities.tmpl
@@ -253,6 +253,7 @@
+
diff --git a/Documentation/DocBook/v4l/pixfmt-y10p.xml
b/Documentation/DocBook/v4l/pixfmt-y10p.xml
new file mode 100644
index 000..5323ffe
--- /dev/null
+++ b/Documentation/DocBook/v4l/pixfmt-y10p.xml
@@ -0,0 +1,43 @@
+
+
+V4L2_PIX_FMT_Y10P ('Y10P')
+&manvol;
+
+
+V4L2_PIX_FMT_Y10P
+Grey-scale image as a packed array
+
+
+Description
+
+This is a packed grey-scale image format with a depth of 10 bits per
+ pixel. Pixels are stored in a packed array of 10bit bits per pixel, with
+ no padding between them and with the most significant bits coming first
+ from the left.
+
+
+ V4L2_PIX_FMT_Y10P 4 pixel data stream taking
5 bytes
+
+
+ Packed representation
+ pixels cross the byte boundary and have a ratio of 5 bytes for
each 4
+ pixels.
+
+
+
+
+
+ Y'00[9:2]
+
Y'00[1:0]Y'01[9:4]
+
Y'01[3:0]Y'02[9:6]
+
Y'02[5:0]Y'03[9:8]
+ Y'03[7:0]
+
+
+
+
+
+
+
+
+
diff --git a/Documentation/DocBook/v4l/pixfmt.xml
b/Documentation/DocBook/v4l/pixfmt.xml
index d7c4671..3682701 100644
--- a/Documentation/DocBook/v4l/pixfmt.xml
+++ b/Documentation/DocBook/v4l/pixfmt.xml
@@ -592,6 +592,7 @@ information.
&sub-packed-yuv;
&sub-grey;
&sub-y10;
+&sub-y10p;
&sub-y16;
&sub-yuyv;
&sub-uyvy;
diff --git a/Documentation/DocBook/v4l/videodev2.h.xml
b/Documentation/DocBook/v4l/videodev2.h.xml
index 325b23b..773496c 100644
--- a/Documentation/DocBook/v4l/videodev2.h.xml
+++ b/Documentation/DocBook/v4l/videodev2.h.xml
@@ -289,6 +289,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_Y4
v4l2_fourcc('Y', '0', '4', ' ') /* 4 Greyscale */
#define V4L2_PIX_FMT_Y6
v4l2_fourcc('Y', '0', '6', ' ') /* 6 Greyscale */
#define V4L2_PIX_FMT_Y10
v4l2_fourcc('Y', '1', '0', ' ') /* 10 Greyscale */
+#define V4L2_PIX_FMT_Y10P
v4l2_fourcc('Y', '1', '0', 'P') /* 10 Greyscale as a packed array */
#define V4L2_PIX_FMT_Y16
v4l2_fourcc('Y', '1', '6', ' ') /* 16 Greyscale */
/* Palette formats */
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 5f6f470..7682581 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -288,6 +288,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_Y4 v4l2_fourcc('Y', '0', '4', ' ') /* 4 Greyscale
*/
#define V4L2_PIX_FMT_Y6 v4l2_fourcc('Y', '0', '6', ' ') /* 6 Greyscale
*/
#define V4L2_PIX_FMT_Y10 v4l2_fourcc('Y', '1', '0', ' ') /* 10 Greyscale
*/
+#define V4L2_PIX_FMT_Y10Pv4l2_fourcc('Y', '1', '0', 'P') /* 10 Greyscale
as a packed array */
#define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16 Greyscale
*/
/* Palette formats */
--
1.7.2.3
--
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] hdpvr: reduce latency of i2c read/write w/recycled buffer
Hi Jarod,
On Fri, 14 Jan 2011 15:01:09 -0500, Jarod Wilson wrote:
> The current hdpvr code kmalloc's a new buffer for every i2c read and
> write. Rather than do that, lets allocate a buffer in the driver's
> device struct and just use that every time.
>
> The size I've chosen for the buffer is the maximum size I could
> ascertain might be used by either ir-kbd-i2c or lirc_zilog, plus a bit
> of padding (lirc_zilog may use up to 100 bytes on tx, rounded that up
> to 128).
Definitely a good move, as discussed on IRC earlier this week.
> Note that this might also remedy user reports of very sluggish behavior
> of IR receive with hdpvr hardware.
Maybe. But the fact that the Zilog is unresponsive during processing of
sent data certainly contributes to this feeling too.
>
> Reported-by: Jean Delvare
> Signed-off-by: Jarod Wilson
> ---
>
> Nb: This patch was done atop my prior patch 'hdpvr: enable IR part',
> and serves no purpose if that patch isn't applied first.
>
> drivers/media/video/hdpvr/hdpvr-i2c.c | 24 +++-
> drivers/media/video/hdpvr/hdpvr.h |3 +++
> 2 files changed, 10 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/media/video/hdpvr/hdpvr-i2c.c
> b/drivers/media/video/hdpvr/hdpvr-i2c.c
> index c0696c3..7f1a313 100644
> --- a/drivers/media/video/hdpvr/hdpvr-i2c.c
> +++ b/drivers/media/video/hdpvr/hdpvr-i2c.c
> @@ -57,23 +57,18 @@ static int hdpvr_i2c_read(struct hdpvr_device *dev, int
> bus,
> unsigned char addr, char *data, int len)
> {
> int ret;
> - char *buf = kmalloc(len, GFP_KERNEL);
> - if (!buf)
> - return -ENOMEM;
>
> ret = usb_control_msg(dev->udev,
> usb_rcvctrlpipe(dev->udev, 0),
> REQTYPE_I2C_READ, CTRL_READ_REQUEST,
> - (bus << 8) | addr, 0, buf, len, 1000);
> + (bus << 8) | addr, 0, &dev->i2c_buf, len, 1000);
Shouldn't you first ensure that len <= sizeof(dev->i2c_buf)? It should
hopefully always be the case, but... if it isn't, you'll corrupt your
data structure and possibly more.
>
> if (ret == len) {
> - memcpy(data, buf, len);
> + memcpy(data, &dev->i2c_buf, len);
> ret = 0;
> } else if (ret >= 0)
> ret = -EIO;
>
> - kfree(buf);
> -
> return ret;
> }
>
> @@ -81,31 +76,26 @@ static int hdpvr_i2c_write(struct hdpvr_device *dev, int
> bus,
> unsigned char addr, char *data, int len)
> {
> int ret;
> - char *buf = kmalloc(len, GFP_KERNEL);
> - if (!buf)
> - return -ENOMEM;
>
> - memcpy(buf, data, len);
> + memcpy(&dev->i2c_buf, data, len);
Same here.
> ret = usb_control_msg(dev->udev,
> usb_sndctrlpipe(dev->udev, 0),
> REQTYPE_I2C_WRITE, CTRL_WRITE_REQUEST,
> - (bus << 8) | addr, 0, buf, len, 1000);
> + (bus << 8) | addr, 0, &dev->i2c_buf, len, 1000);
>
> if (ret < 0)
> - goto error;
> + return ret;
>
> ret = usb_control_msg(dev->udev,
> usb_rcvctrlpipe(dev->udev, 0),
> REQTYPE_I2C_WRITE_STATT, CTRL_READ_REQUEST,
> - 0, 0, buf, 2, 1000);
> + 0, 0, &dev->i2c_buf, 2, 1000);
>
> - if ((ret == 2) && (buf[1] == (len - 1)))
> + if ((ret == 2) && (dev->i2c_buf[1] == (len - 1)))
> ret = 0;
> else if (ret >= 0)
> ret = -EIO;
>
> -error:
> - kfree(buf);
> return ret;
> }
>
> diff --git a/drivers/media/video/hdpvr/hdpvr.h
> b/drivers/media/video/hdpvr/hdpvr.h
> index 29f7426..ee74e3b 100644
> --- a/drivers/media/video/hdpvr/hdpvr.h
> +++ b/drivers/media/video/hdpvr/hdpvr.h
> @@ -25,6 +25,7 @@
> KERNEL_VERSION(HDPVR_MAJOR_VERSION, HDPVR_MINOR_VERSION, HDPVR_RELEASE)
>
> #define HDPVR_MAX 8
> +#define HDPVR_I2C_MAX_SIZE 128
>
> /* Define these values to match your devices */
> #define HD_PVR_VENDOR_ID 0x2040
> @@ -109,6 +110,8 @@ struct hdpvr_device {
> struct i2c_adapter i2c_adapter;
> /* I2C lock */
> struct mutexi2c_mutex;
> + /* I2C message buffer space */
> + chari2c_buf[HDPVR_I2C_MAX_SIZE];
>
> /* For passing data to ir-kbd-i2c */
> struct IR_i2c_init_data ir_i2c_init_data;
Other than that, it looks pretty good.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] hdpvr: reduce latency of i2c read/write w/recycled buffer
The current hdpvr code kmalloc's a new buffer for every i2c read and
write. Rather than do that, lets allocate a buffer in the driver's
device struct and just use that every time.
The size I've chosen for the buffer is the maximum size I could
ascertain might be used by either ir-kbd-i2c or lirc_zilog, plus a bit
of padding (lirc_zilog may use up to 100 bytes on tx, rounded that up
to 128).
Note that this might also remedy user reports of very sluggish behavior
of IR receive with hdpvr hardware.
Reported-by: Jean Delvare
Signed-off-by: Jarod Wilson
---
Nb: This patch was done atop my prior patch 'hdpvr: enable IR part',
and serves no purpose if that patch isn't applied first.
drivers/media/video/hdpvr/hdpvr-i2c.c | 24 +++-
drivers/media/video/hdpvr/hdpvr.h |3 +++
2 files changed, 10 insertions(+), 17 deletions(-)
diff --git a/drivers/media/video/hdpvr/hdpvr-i2c.c
b/drivers/media/video/hdpvr/hdpvr-i2c.c
index c0696c3..7f1a313 100644
--- a/drivers/media/video/hdpvr/hdpvr-i2c.c
+++ b/drivers/media/video/hdpvr/hdpvr-i2c.c
@@ -57,23 +57,18 @@ static int hdpvr_i2c_read(struct hdpvr_device *dev, int bus,
unsigned char addr, char *data, int len)
{
int ret;
- char *buf = kmalloc(len, GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
ret = usb_control_msg(dev->udev,
usb_rcvctrlpipe(dev->udev, 0),
REQTYPE_I2C_READ, CTRL_READ_REQUEST,
- (bus << 8) | addr, 0, buf, len, 1000);
+ (bus << 8) | addr, 0, &dev->i2c_buf, len, 1000);
if (ret == len) {
- memcpy(data, buf, len);
+ memcpy(data, &dev->i2c_buf, len);
ret = 0;
} else if (ret >= 0)
ret = -EIO;
- kfree(buf);
-
return ret;
}
@@ -81,31 +76,26 @@ static int hdpvr_i2c_write(struct hdpvr_device *dev, int
bus,
unsigned char addr, char *data, int len)
{
int ret;
- char *buf = kmalloc(len, GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
- memcpy(buf, data, len);
+ memcpy(&dev->i2c_buf, data, len);
ret = usb_control_msg(dev->udev,
usb_sndctrlpipe(dev->udev, 0),
REQTYPE_I2C_WRITE, CTRL_WRITE_REQUEST,
- (bus << 8) | addr, 0, buf, len, 1000);
+ (bus << 8) | addr, 0, &dev->i2c_buf, len, 1000);
if (ret < 0)
- goto error;
+ return ret;
ret = usb_control_msg(dev->udev,
usb_rcvctrlpipe(dev->udev, 0),
REQTYPE_I2C_WRITE_STATT, CTRL_READ_REQUEST,
- 0, 0, buf, 2, 1000);
+ 0, 0, &dev->i2c_buf, 2, 1000);
- if ((ret == 2) && (buf[1] == (len - 1)))
+ if ((ret == 2) && (dev->i2c_buf[1] == (len - 1)))
ret = 0;
else if (ret >= 0)
ret = -EIO;
-error:
- kfree(buf);
return ret;
}
diff --git a/drivers/media/video/hdpvr/hdpvr.h
b/drivers/media/video/hdpvr/hdpvr.h
index 29f7426..ee74e3b 100644
--- a/drivers/media/video/hdpvr/hdpvr.h
+++ b/drivers/media/video/hdpvr/hdpvr.h
@@ -25,6 +25,7 @@
KERNEL_VERSION(HDPVR_MAJOR_VERSION, HDPVR_MINOR_VERSION, HDPVR_RELEASE)
#define HDPVR_MAX 8
+#define HDPVR_I2C_MAX_SIZE 128
/* Define these values to match your devices */
#define HD_PVR_VENDOR_ID 0x2040
@@ -109,6 +110,8 @@ struct hdpvr_device {
struct i2c_adapter i2c_adapter;
/* I2C lock */
struct mutexi2c_mutex;
+ /* I2C message buffer space */
+ chari2c_buf[HDPVR_I2C_MAX_SIZE];
/* For passing data to ir-kbd-i2c */
struct IR_i2c_init_data ir_i2c_init_data;
--
1.7.1
--
Jarod Wilson
ja...@redhat.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dvb_usb_dib0700 driver woes with Pinnacle 72e stick
Alfredo Braunstein wrote: > Hi & happy new year, > > I recently bought a Pinnacle 72e USB stick, (lsusb says: Bus 002 > Device 011: ID 2304:0236 Pinnacle Systems, Inc. [hex]. The stick says > "pinnacle" on front > and "72e" and "1100" on the back) which seemed to be supported by the > dvb_usb_dib0700 driver. Some update. Strangely enough, the problem seems to be related to a too *strong* terrestrial signal. If I plug a small antenna instead of the one on the rooftop, things get much better. Likewise, reception improves vastly if I use the roof antenna with a longer coaxial cable. Now, the Windows driver seems to be able to attenuate the signal somehow, as after initializing under windows and before cold booting the roof top antenna works like a charm (as stated on previous mail). The small antenna stops working (signal probably too weak?). Does this ring any bell? Is it possible to make the driver to attenuate the signal (possibly via an option)? Some pointers on where to look? Thanks again, A/ -- 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] hdpvr: enable IR part
A number of things going on here, but the end result is that the IR part
on the hdpvr gets enabled, and can be used with ir-kbd-i2c and/or
lirc_zilog.
First up, there are some conditional build fixes that come into play
whether i2c is built-in or modular. Second, we're swapping out
i2c_new_probed_device() for i2c_new_device(), as in my testing, probing
always fails, but we *know* that all hdpvr devices have a z8 chip at
0x70 and 0x71. Third, we're poking at an i2c address directly without a
client, and writing some magic bits to actually turn on this IR part
(this could use some improvement in the future). Fourth, some of the
i2c_adapter storage has been reworked, as the existing implementation
used to lead to an oops following i2c changes c. 2.6.31.
Earlier editions of this patch have been floating around the 'net for a
while, including being patched into Fedora kernels, and they *do* work.
This specific version isn't yet tested, beyond loading ir-kbd-i2c and
confirming that it does bind to the RX address of the hdpvr:
Registered IR keymap rc-hauppauge-new
input: i2c IR (HD PVR) as /devices/virtual/rc/rc1/input6
rc1: i2c IR (HD PVR) as /devices/virtual/rc/rc1
ir-kbd-i2c: i2c IR (HD PVR) detected at i2c-1/1-0071/ir0 [Hauppage HD PVR I2C]
(Yes, I'm posting before fully testing, and I do have a reason for that,
and will post a v2 after testing this weekend, if need be)...
Signed-off-by: Jarod Wilson
---
drivers/media/video/hdpvr/Makefile |4 +-
drivers/media/video/hdpvr/hdpvr-core.c | 10 +--
drivers/media/video/hdpvr/hdpvr-i2c.c | 120 +++
drivers/media/video/hdpvr/hdpvr-video.c |7 +--
drivers/media/video/hdpvr/hdpvr.h |2 +-
5 files changed, 66 insertions(+), 77 deletions(-)
diff --git a/drivers/media/video/hdpvr/Makefile
b/drivers/media/video/hdpvr/Makefile
index e0230fc..3baa9f6 100644
--- a/drivers/media/video/hdpvr/Makefile
+++ b/drivers/media/video/hdpvr/Makefile
@@ -1,6 +1,4 @@
-hdpvr-objs := hdpvr-control.o hdpvr-core.o hdpvr-video.o
-
-hdpvr-$(CONFIG_I2C) += hdpvr-i2c.o
+hdpvr-objs := hdpvr-control.o hdpvr-core.o hdpvr-video.o hdpvr-i2c.o
obj-$(CONFIG_VIDEO_HDPVR) += hdpvr.o
diff --git a/drivers/media/video/hdpvr/hdpvr-core.c
b/drivers/media/video/hdpvr/hdpvr-core.c
index f7d1ee5..a6572e5 100644
--- a/drivers/media/video/hdpvr/hdpvr-core.c
+++ b/drivers/media/video/hdpvr/hdpvr-core.c
@@ -378,19 +378,17 @@ static int hdpvr_probe(struct usb_interface *interface,
goto error;
}
-#ifdef CONFIG_I2C
- /* until i2c is working properly */
- retval = 0; /* hdpvr_register_i2c_adapter(dev); */
+#if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE)
+ retval = hdpvr_register_i2c_adapter(dev);
if (retval < 0) {
v4l2_err(&dev->v4l2_dev, "registering i2c adapter failed\n");
goto error;
}
- /* until i2c is working properly */
- retval = 0; /* hdpvr_register_i2c_ir(dev); */
+ retval = hdpvr_register_i2c_ir(dev);
if (retval < 0)
v4l2_err(&dev->v4l2_dev, "registering i2c IR devices failed\n");
-#endif /* CONFIG_I2C */
+#endif
/* let the user know what node this device is now attached to */
v4l2_info(&dev->v4l2_dev, "device now attached to %s\n",
diff --git a/drivers/media/video/hdpvr/hdpvr-i2c.c
b/drivers/media/video/hdpvr/hdpvr-i2c.c
index 24966aa..c0696c3 100644
--- a/drivers/media/video/hdpvr/hdpvr-i2c.c
+++ b/drivers/media/video/hdpvr/hdpvr-i2c.c
@@ -13,6 +13,8 @@
*
*/
+#if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE)
+
#include
#include
@@ -28,55 +30,31 @@
#define Z8F0811_IR_TX_I2C_ADDR 0x70
#define Z8F0811_IR_RX_I2C_ADDR 0x71
-static const u8 ir_i2c_addrs[] = {
- Z8F0811_IR_TX_I2C_ADDR,
- Z8F0811_IR_RX_I2C_ADDR,
-};
-static const char * const ir_devicenames[] = {
- "ir_tx_z8f0811_hdpvr",
- "ir_rx_z8f0811_hdpvr",
+static struct i2c_board_info hdpvr_i2c_board_info = {
+ I2C_BOARD_INFO("ir_tx_z8f0811_hdpvr", Z8F0811_IR_TX_I2C_ADDR),
+ I2C_BOARD_INFO("ir_rx_z8f0811_hdpvr", Z8F0811_IR_RX_I2C_ADDR),
};
-static int hdpvr_new_i2c_ir(struct hdpvr_device *dev, struct i2c_adapter *adap,
- const char *type, u8 addr)
+int hdpvr_register_i2c_ir(struct hdpvr_device *dev)
{
- struct i2c_board_info info;
+ struct i2c_client *c;
struct IR_i2c_init_data *init_data = &dev->ir_i2c_init_data;
- unsigned short addr_list[2] = { addr, I2C_CLIENT_END };
-
- memset(&info, 0, sizeof(struct i2c_board_info));
- strlcpy(info.type, type, I2C_NAME_SIZE);
/* Our default information for ir-kbd-i2c.c to use */
- switch (addr) {
- case Z8F0811_IR_RX_I2C_ADDR:
- init_data->ir_codes = RC_MAP_HAUPPAUGE_NEW;
- init_data->internal_get_key_func = IR_KBD_GET_KEY_HAUP_XVR;
- init_data->type = RC_TYPE_RC5;
- init_data->name =
[cron job] v4l-dvb daily build: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri Jan 14 19:00:49 CET 2011 git master: 59365d136d205cc20fe666ca7f89b1c5001b0d5a git media-master: 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 spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 A linux-media.tar.bz2 archive with the latest media git sources that can be used with the media_build tree is available here: http://www.xs4all.nl/~hverkuil/logs/Friday-linux-media.tar.bz2 Rename to linux-media.tar.bz2, put it in the media_build/linux directory, go to the directory and type 'make untar'. 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 0/1 v2] libv4l: Add plugin support
Hi Hans, here is second version of plugin support for libv4l2. Changes in v2: * Remove calls of v4l2_plugin_foo functions in the beginning of coresponding v4l2_foo functions and instead replace SYS_FOO calls. * Add to v4l2_dev_info device operation structure which can hold plugin callbacks or dyrect syscall(SYS_foo, ...) calls. * Under libv4lconvert also replace SYS_FOO cals with device operations. This required also to add dev_ops field to v4lconvert_data and v4lcontrol_data. --- v1: Here is initial version of plugin support for libv4l, based on your RFC. It is provided by functions v4l2_plugin_[open,close,etc]. When open() is called libv4l dlopens files in /usr/lib/libv4l/plugins 1 at a time and call open() callback passing through the applications parameters unmodified. If a plugin is relevant for the specified device node, it can indicate so by returning a value other then -1 (the actual file descriptor). As soon as a plugin returns another value then -1 plugin loading stops and information about it (fd and corresponding library handle) is stored. For each function v4l2_[ioctl,read,close,etc] is called corresponding v4l2_plugin_* function which looks if there is loaded plugin for that file and call it's callbacks. v4l2_plugin_* functions indicate by their first argument if plugin was used, and if it was not then v4l2_* functions proceed with their usual behavior. Yordan Kamenov (1): Add plugin support to libv4l lib/include/libv4l2-plugin.h | 43 +++ lib/include/libv4l2.h |4 +- lib/include/libv4lconvert.h|5 +- lib/libv4l1/libv4l1.c |2 +- lib/libv4l2/Makefile |4 +- lib/libv4l2/libv4l2-priv.h | 24 ++ lib/libv4l2/libv4l2.c | 128 +++--- lib/libv4l2/v4l2-plugin.c | 344 lib/libv4l2/v4l2convert.c | 23 ++- lib/libv4lconvert/control/libv4lcontrol-priv.h |3 + lib/libv4lconvert/control/libv4lcontrol.c | 26 +- lib/libv4lconvert/control/libv4lcontrol.h |5 +- lib/libv4lconvert/libv4lconvert-priv.h |1 + lib/libv4lconvert/libv4lconvert.c | 25 +- 14 files changed, 573 insertions(+), 64 deletions(-) create mode 100644 lib/include/libv4l2-plugin.h create mode 100644 lib/libv4l2/v4l2-plugin.c -- 1.7.3.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
[PATCH 1/1 v2] Add plugin support to libv4l
A libv4l2 plugin will sit in between libv4l2 itself and the
actual /dev/video device node a fd refers to. It will be called each time
libv4l2 wants to do an operation (read/write/ioctl/mmap/munmap) on the
actual /dev/video node in question.
Signed-off-by: Yordan Kamenov
---
lib/include/libv4l2-plugin.h | 43 +++
lib/include/libv4l2.h |4 +-
lib/include/libv4lconvert.h|5 +-
lib/libv4l1/libv4l1.c |2 +-
lib/libv4l2/Makefile |4 +-
lib/libv4l2/libv4l2-priv.h | 24 ++
lib/libv4l2/libv4l2.c | 128 +++---
lib/libv4l2/v4l2-plugin.c | 344
lib/libv4l2/v4l2convert.c | 23 ++-
lib/libv4lconvert/control/libv4lcontrol-priv.h |3 +
lib/libv4lconvert/control/libv4lcontrol.c | 26 +-
lib/libv4lconvert/control/libv4lcontrol.h |5 +-
lib/libv4lconvert/libv4lconvert-priv.h |1 +
lib/libv4lconvert/libv4lconvert.c | 25 +-
14 files changed, 573 insertions(+), 64 deletions(-)
create mode 100644 lib/include/libv4l2-plugin.h
create mode 100644 lib/libv4l2/v4l2-plugin.c
diff --git a/lib/include/libv4l2-plugin.h b/lib/include/libv4l2-plugin.h
new file mode 100644
index 000..3971735
--- /dev/null
+++ b/lib/include/libv4l2-plugin.h
@@ -0,0 +1,43 @@
+/*
+* Copyright (C) 2010 Nokia Corporation
+
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU Lesser General Public License as published by
+* the Free Software Foundation; either version 2.1 of the License, or
+* (at your option) any later version.
+*
+* This program is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+* Lesser General Public License for more details.
+*
+* You should have received a copy of the GNU Lesser General Public License
+* along with this program; if not, write to the Free Software
+* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+*/
+
+#ifndef __LIBV4L2_PLUGIN_H
+#define __LIBV4L2_PLUGIN_H
+
+#include
+
+/* Structure libv4l2_dev_ops holds the calls from libv4ls to video nodes.
+ They can be normal open/clode/ioctl etc. or any of them may be replaced
+ with a callback by a loaded plugin.
+*/
+
+struct libv4l2_dev_ops {
+ int (*open)(const char *file, int oflag, mode_t mode);
+ int (*close)(int fd);
+ int (*ioctl)(int fd, unsigned long int request, void *arg);
+ ssize_t (*read)(int fd, void *buffer, size_t n);
+ void *(*mmap)(void *start, size_t length, int prot, int flags,
+ int fd, int64_t offset);
+ int (*munmap)(void *_start, size_t length);
+};
+
+/* Plugin utility functions */
+void libv4l2_set_plugindata(int fd, void *plugin_data);
+void *libv4l2_get_plugindata(int fd);
+
+#endif
diff --git a/lib/include/libv4l2.h b/lib/include/libv4l2.h
index cc0ab4a..5db000f 100644
--- a/lib/include/libv4l2.h
+++ b/lib/include/libv4l2.h
@@ -22,6 +22,7 @@
#include
#include
#include
+#include "libv4l2-plugin.h"
#ifdef __cplusplus
extern "C" {
@@ -106,7 +107,8 @@ LIBV4L_PUBLIC int v4l2_get_control(int fd, int cid);
Returns fd on success, -1 if the fd is not suitable for use through libv4l2
(note the fd is left open in this case). */
-LIBV4L_PUBLIC int v4l2_fd_open(int fd, int v4l2_flags);
+LIBV4L_PUBLIC int v4l2_fd_open(int fd, struct libv4l2_dev_ops *dev_ops,
+ int v4l2_flags);
#ifdef __cplusplus
}
diff --git a/lib/include/libv4lconvert.h b/lib/include/libv4lconvert.h
index 0264290..f210b2d 100644
--- a/lib/include/libv4lconvert.h
+++ b/lib/include/libv4lconvert.h
@@ -38,6 +38,8 @@
#include
+#include "libv4l2-plugin.h"
+
#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */
@@ -50,7 +52,8 @@ extern "C" {
struct v4lconvert_data;
-LIBV4L_PUBLIC struct v4lconvert_data *v4lconvert_create(int fd);
+LIBV4L_PUBLIC struct v4lconvert_data *v4lconvert_create(int fd,
+ struct libv4l2_dev_ops *dev_ops);
LIBV4L_PUBLIC void v4lconvert_destroy(struct v4lconvert_data *data);
/* When doing flipping / rotating / video-processing, only supported
diff --git a/lib/libv4l1/libv4l1.c b/lib/libv4l1/libv4l1.c
index fee0fb7..180db0e 100644
--- a/lib/libv4l1/libv4l1.c
+++ b/lib/libv4l1/libv4l1.c
@@ -342,7 +342,7 @@ int v4l1_open(const char *file, int oflag, ...)
/* Register with libv4l2, as we use that todo format conversion and
read()
emulation for us */
- if (v4l2_fd_open(fd, 0) == -1) {
+ if (v4l2_fd_open(fd, NULL, 0) == -1) {
int saved_err = errno;
SYS_CLOSE(fd);
diff --git a/lib/libv4l2/Makefile b/lib/libv4l2/Makefile
index d78632f..eb1c019 100644
--- a/lib/libv4l2/Makefi
Re: [PATCH] dib7000m/p: struct alignment fix
Hi again, On Wed, 12 Jan 2011, Mauro Carvalho Chehab wrote: Em 12-01-2011 11:17, Robin Humble escreveu: Hi, this is basically a re-post of http://www.linuxtv.org/pipermail/linux-dvb/2010-September/032744.html which fixes an Oops when tuning eg. AVerMedia DVB-T Volar, Hauppauge Nova-T, Winfast DTV. it seems to be quite commonly reported on this list. [ 809.128579] BUG: unable to handle kernel NULL pointer dereference at 0012 [ 809.128586] IP: [] i2c_transfer+0x16/0x124 [i2c_core] [ 809.128598] PGD 669a7067 PUD 79e5f067 PMD 0 [ 809.128604] Oops: [#1] SMP [ 809.128608] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq [ 809.128612] CPU 0 [ 809.128614] Modules linked in: tcp_lp fuse coretemp hwmon_vid cpufreq_ondemand acpi_cpufreq freq_table mperf ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 xfs exportfs uinput mt2060 mxl5005s af9013 dvb_usb_dib0700 ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder dib7000p dib0090 dib7000m dvb_usb_af9015 dib0070 dvb_usb dib8000 dvb_core dib3000mc ir_rc6_decoder dibx000_common snd_hda_codec_intelhdmi ir_rc5_decoder snd_hda_codec_realtek snd_hda_intel ir_nec_decoder snd_hda_codec ldusb i2c_i801 snd_hwdep snd_seq snd_seq_device rc_core atl1 asus_atk0110 snd_pcm snd_timer mii snd soundcore snd_page_alloc iTCO_wdt iTCO_vendor_support microcode raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 ata_generic firewire_ohci pata_acpi firewire_core crc_itu_t pata_jmicron i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan] [ 809.128692] [ 809.128696] Pid: 2525, comm: tzap Not tainted 2.6.35.10-72.fc14.x86_64 #1 P5E-VM HDMI/P5E-VM HDMI [ 809.128700] RIP: 0010:[] [] i2c_transfer+0x16/0x124 [i2c_core] [ 809.128708] RSP: 0018:880064a83ae8 EFLAGS: 00010296 [ 809.128712] RAX: 880064a83b58 RBX: 00eb RCX: [ 809.128715] RDX: 0002 RSI: 880064a83b38 RDI: 0002 [ 809.128718] RBP: 880064a83b28 R08: 880079bcf7c0 R09: 5d80 [ 809.128721] R10: 0005 R11: 4a38 R12: 0001 [ 809.128725] R13: R14: c900237e8000 R15: c90023907000 [ 809.128729] FS: 7f2ff2dd3720() GS:88000200() knlGS: [ 809.128732] CS: 0010 DS: ES: CR0: 80050033 [ 809.128736] CR2: 0012 CR3: 7830d000 CR4: 06f0 [ 809.128739] DR0: DR1: DR2: [ 809.128743] DR3: DR6: 0ff0 DR7: 0400 [ 809.128746] Process tzap (pid: 2525, threadinfo 880064a82000, task 8800379745c0) [ 809.128749] Stack: [ 809.128751] 880064a83af8 8103c142 880079c41a90 00eb [ 809.128757] <0> 0001 c900237e8000 c90023907000 [ 809.128762] <0> 880064a83b88 a0407124 00020030 880064a83b68 [ 809.128768] Call Trace: [ 809.128776] [] ? need_resched+0x23/0x2d [ 809.128783] [] dib7000p_read_word+0x6d/0xbc [dib7000p] [ 809.128789] [] ? usb_submit_urb+0x2f8/0x33a [ 809.128795] [] dib7000p_pid_filter_ctrl+0x2d/0x90 [dib7000p] [ 809.128802] [] stk70x0p_pid_filter_ctrl+0x19/0x1e [dvb_usb_dib0700] [ 809.128809] [] dvb_usb_ctrl_feed+0xd7/0x123 [dvb_usb] [ 809.128815] [] dvb_usb_start_feed+0x13/0x15 [dvb_usb] [ 809.128825] [] dmx_ts_feed_start_filtering+0x7d/0xd1 [dvb_core] [ 809.128833] [] dvb_dmxdev_start_feed.clone.1+0xbd/0xeb [dvb_core] [ 809.128841] [] dvb_dmxdev_filter_start+0x2cf/0x31b [dvb_core] [ 809.128847] [] ? _raw_spin_lock_irq+0x1f/0x21 [ 809.128854] [] dvb_demux_do_ioctl+0x27b/0x4c0 [dvb_core] [ 809.128859] [] ? should_resched+0xe/0x2e [ 809.128867] [] dvb_usercopy+0xe4/0x16b [dvb_core] [ 809.128874] [] ? dvb_demux_do_ioctl+0x0/0x4c0 [dvb_core] [ 809.128881] [] ? inode_has_perm.clone.20+0x79/0x8f [ 809.128886] [] ? remove_wait_queue+0x35/0x41 [ 809.128891] [] ? _raw_spin_unlock_irqrestore+0x17/0x19 [ 809.128898] [] dvb_demux_ioctl+0x15/0x19 [dvb_core] [ 809.128903] [] vfs_ioctl+0x36/0xa7 [ 809.128908] [] do_vfs_ioctl+0x468/0x49b [ 809.128912] [] sys_ioctl+0x56/0x79 [ 809.128917] [] system_call_fastpath+0x16/0x1b [ 809.128920] Code: 89 55 f8 48 83 c7 58 48 c7 c2 47 32 01 a0 e8 92 09 2c e1 c9 c3 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 0f 1f 44 00 00 <48> 8b 47 10 48 89 fb 49 89 f6 41 89 d7 48 83 38 00 0f 84 92 00 [ 809.128965] RIP [] i2c_transfer+0x16/0x124 [i2c_core] [ 809.128973] RSP [ 809.128975] CR2: 0012 [ 809.128979] ---[ end trace 6919129d55f94398 ]--- this Oops occurs for me on all >2.6.32 kernels, including the current linux-media dvb git tree, and Fedora (13,14) kernels. Ubuntu has a bug open for the issue: https://bugs.launchpad.net/u
Re: OMAP3 ISP and tvp5151 driver.
Hi Enric, On Thursday 13 January 2011 13:27:43 Enric Balletbò i Serra wrote: > 2011/1/12 Laurent Pinchart : > > On Wednesday 12 January 2011 12:58:04 Enric Balletbò i Serra wrote: > >> Hi all, > >> > >> As explained in my first mail I would like port the tvp515x driver to > >> new media framework, I'm a newbie with the v4l2 API and of course with > >> the new media framework API, so sorry if next questions are stupid or > >> trivial (please, patience with me). > >> > >> My idea is follow this link schem: > >> > >> --- > >> > >> - || | 1 > >> > >> | --> | OMAP3 ISP CCDC OUTPUT | > >> | TVP515x | 0 | -> | 0 | OMAP3 ISP CCDC --- | > >> > >> > >> || | 2 | > >> --- > > > > ASCII art would look much better if you drew it in a non-proportional > > font, with 80 character per line at most. > > > >> Where: > >> * TVP515x is /dev/v4l-subdev8 c 81 15 > >> * OMAP3 ISP CCDC is /dev/v4l-subdev2 c 81 4 > >> * OMAP3 ISP CCDC OUTPUT is /dev/video2 c 81 5 > >> > >> Then activate these links with > >> > >> ./media-ctl -r -l '"tvp5150 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 > >> ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' > >> Resetting all links to disabled > >> Setting up link 16:0 -> 5:0 [1] > >> Setting up link 5:1 -> 6:0 [1] > >> > >> I'm on the right way or I'm completely lost ? > > > > That's correct. > > > >> I think the next step is adapt the tvp515x driver to new media > >> framework, I'm not sure how to do this, someone can give some points ? > > > > You need to implement subdev pad operations. get_fmt and set_fmt are > > required. > > I configured the TVP5151 to 8-bit 4:2:3 YCbCr output format. Is 8-bit > 4:2:3 YCbCr output format implemented in OMAP3 ISP CCDC ? I suppose you mean 4:2:2. The CCDC doesn't support that yet. > >> Once this is done, I suppose I can test using gstreamer, for example > >> using something like this. > >> > >>gst-launch v4l2src device=/dev/video2 ! ffmpegcolorspace ! > >> xvimagesink > >> > >> I'm right in this point ? > > > > You need to specify the format explicitly. It must be identical to the > > format configured on pad CCDC:1. > > Can you give me an example using gstreamer ? I'm not a gstreamer expert, sorry. > Running yavta I get > > # ./yavta -f SGRBG10 -s 720x525 -n 4 --capture=4 --skip 3 -F /dev/video2 > Device /dev/video2 opened: OMAP3 ISP CCDC output (media). > Video format set: width: 720 height: 525 buffer size: 756000 > Video format: BA10 (30314142) 720x525 > 4 buffers requested. > length: 756000 offset: 0 > Buffer 0 mapped at address 0x400f2000. > length: 756000 offset: 757760 > Buffer 1 mapped at address 0x40385000. > length: 756000 offset: 1515520 > Buffer 2 mapped at address 0x40466000. > length: 756000 offset: 2273280 > Buffer 3 mapped at address 0x405ed000. > Unable to start streaming: 22. > Unable to dequeue buffer (22). > 4 buffers released. > > I know the format is not correct, but, is the "Unable to start > streaming: 22" error related to the format or is related to another > problem ? That usually means that the format configured on the video device node (SGRBG10 720x525 in this case) is different than the format setup on the connected subdev output (CCDC pad 1 in this case). My guess is that you probably forgot to setup formats on the subdev pads (using media-ctl -f). -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [linux-media] API V3 vs SAPI behavior difference in reading tuning parameters
> -Original Message- > From: Andreas Oberritter [mailto:o...@linuxtv.org] > Sent: Friday, January 14, 2011 5:32 PM > Albeit, DVB-SI data isn't perfect and misconfiguration at the > transmitter happens (e.g. wrong FEC values), especially where most of > the parameters are signaled in-band (e.g. TPS for DVB-T). It's a better > user experience if the reception continues to work, even if the user > didn't specify AUTO. Exactly. In the French DVB-T network, there is no regional NIT, only one common national NIT. As a consequence, all tuning parameters (frequency but also FEC, guard interval, etc) are wrong in the terrestrial delivery descriptors because for a given TS they are obviously not identical on all transmitters. Moreover, these parameters change over time (many transmitters recently moved from 2/3 - 1/32 to 3/4 - 1/8). In such networks, nobody "knows" for sure the modulation parameters. This is why it is a good thing that the tuners can 1) find the actual parameters and 2) report them to the application whenever it requests them. > I'd rather understand non-AUTO parameters that way: "Try these first, > but if you want and if you can, you're free to try other parameters." Exactly, for the same reasons as above. This is why the new behavior of S2API (compared to API V3) is quite unfortunate. On a pragmatic standpoint, this is really a major step backward. -Thierry -- 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: [linux-media] API V3 vs SAPI behavior difference in reading tuning parameters
On 01/14/2011 04:12 PM, Devin Heitmueller wrote: > On Fri, Jan 14, 2011 at 8:35 AM, Thierry LELEGARD > wrote: >> But there is worse. If I set a wrong parameter in the tuning operation, >> for instance guard interval 1/32, the API V3 returns the correct value >> which is actually used by the tuner (GUARD_INTERVAL_1_8), while S2API >> returns the "cached" value which was set while tuning (GUARD_INTERVAL_1_32). > > This is actually a bad thing. If you specify the wrong parameter and > it still works, then that can lead to all sort of misleading behavior. > For example, imagine the next person who submits scan results based > on using such a driver. It works for him because his driver lied, but > the resulting file works for nobody else. Scan results should contain the input parameters, because the transmission parameters can change any time (not included in any official frequency sheet of the provider) and because some parameters vary slightly with environmental influences (e.g. DVB-S frequency - i've heard of that a lot and there's code to handle it in dvb_frontend.c, but is it actually true?) and some might be read back too imprecisely to be usable with a different chipset (e.g. symbol rate). > If you specify an explicit value incorrectly (not auto) and it still > works, that is a driver bug which should be fixed. It's not possible to manually specify every single parameter or every combination of parameters (i.e. some AUTO, some not) with all devices. If you want to catch this, you'd have to compare the data read back to the data from userspace to clear the lock status on mismatch, even if a valid TS is being received. This would be worse, in my opinion. How much tolerance would you allow for parameters that aren't enums, e.g. frequency and symbol rate? Albeit, DVB-SI data isn't perfect and misconfiguration at the transmitter happens (e.g. wrong FEC values), especially where most of the parameters are signaled in-band (e.g. TPS for DVB-T). It's a better user experience if the reception continues to work, even if the user didn't specify AUTO. I'd rather understand non-AUTO parameters that way: "Try these first, but if you want and if you can, you're free to try other parameters." After all, most of the users tune to a mux in order to acquire a lock and not to prove that there's no signal. Regards, Andreas -- 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: [Linux-uvc-devel] Logitech C910 driver problem
Radek, Please attach the full dmesg output when starting video capture with the second camera. Also increase log verbosity first: something like this: rmmod uvcvideo modprobe uvcvideo trace=65535 You should also refer your capture settings (if I remember MJPG 640x480@24 fps) and that if you use one c910 and one c600 everything works fine. Note: Cc linux-media since you also posted this thread there. Regards, Paulo 2011/1/14 Radek Mašín : > Hello, > I'm trying to get working two Logitech C910 cameras in one computer and I'm > unable to > do it. I connect both cameras to one USB controller and first camera is > starting capture > without problem, but when I try to start second camera during first camera is > running, > I get message in log "uvcvideo: Failed to submit URB 0" and capturing fails. > I have discussed this problem on quickcamteam forum and it seems, that there > is problem > with uvcvideo driver for this camera. > Cameras have been tested in two different systems (SuSe 11.2 and Ubuntu > 10.10) and on > both systems I get same behavior. > > Thank you > Radek Masin > ___ > Linux-uvc-devel mailing list > linux-uvc-de...@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/linux-uvc-devel > -- 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: [RFC] Cropping and scaling with subdev pad-level operations
Hi Laurent, My apologies that this reply is so late, but I knew I had to sit down and think carefully about this and I didn't have time for that until today. I've decided not to quote your post but instead restate the problem in my own words. Seen abstractly you have an entity with inputs, outputs and a processing pipeline that transforms the input(s) to the output(s) somehow. And each stage of that pipeline has its own configuration. You want to provide the developer that sets up such an entity with a systematic and well-defined procedure while at the same time you want to keep the entity's code as simple as possible. Part of this procedure is already decided: you always start with defining the inputs. The confusion begins with how to setup the configuration and the outputs. I think the only reasonably way is to configure the pipeline stages in strict order from the input to the output. So you start with defining the inputs. For a scaler the next thing to set is the crop rectangle. And then finally the output. At each stage the entity will only check if the configuration parameters can work with the input. It may make the rest of the pipeline invalid, but that's OK for now. The final step comes when the output is defined. If that returns OK, then you know the whole pipeline is valid. So what to do when you have an input and an output configured and someone suddenly changes the crop configuration to a value that doesn't work with that input/output combinations? The two options I've seen are: 1) modify the crop configuration to fit the output 2) modify the output configuration to fit the crop But there is a third option which I think works much better: 3) accept the crop configuration if it fits the input, but report back to the caller that it invalidates the output. What the entity does with this crop configuration is purely up to the entity: it can just store it in a shadow configuration and wait with applying it to the hardware until it receives a consistent output format, or it can modify the output format to fit the crop configuration. In any case, if changes are made, then they should be made 'upstream'. This makes the behavior consistent. As long as you work your way from input to output, you know that any configuration you've set for earlier stages stay put and won't change unexpectedly. And if you decide to change a 'mid-pipeline' configuration, then you will get a status back that tells you whether or not you broke the upstream configuration. The advantage is that at any stage the driver code just has to check whether the new configuration is valid given the input (in which case the call will succeed) and whether the new configuration is valid for the current output and report that in a status field. Note that 'input' and 'output' do not necessarily refer to pads, it may also refer to stages of a pipeline. And the same principle should hold for both the subdev API and for the 'main' V4L API (more about that later). A suggested alternative was to do the configuration atomically. I do not think that is a good idea because it is so very hard to do things atomically. It is hard to use and it is hard to implement. The extended controls API for example has been defined years ago and there are very few drivers that implement it (let alone implement it correctly). It took the creation of the control framework (almost 2000 lines of code) to make it possible to implement it easily in drivers and I've just started out converting all drivers to this framework. And this is just for simple controls... So this sounds simple, but in practice I think it will be a disaster. I like to cut things up in small pieces, and working your way through a pipeline as proposed makes each part much easier. Since the subdev API is not yet set in stone it shouldn't be hard to provide such feedback. For the existing V4L2 API it can be a bit harder: VIDIOC_S_FMT: struct v4l2_pix_format has a priv field which I believe is never used. So we might hijack that as a flags field instead. VIDIOC_S_CROP: Can't do anything with that. However, we could define a TRY_CROP that does give back the information (i.e. 'if you try this crop rectangle, then the upstream pipeline will become invalid'). Not ideal, but it should work. ROTATE control: two options: either use one of the top bits in the control ID field (the top four bits are reserved as flags, one of them is the NEXT_CTRL flag). Or change the reserved2 field to a flags field. VIDIOC_S_STD: Can't be done. VIDIOC_S_INPUT: Can't be done. VIDIOC_S_OUTPUT: Can't be done. For these three you might be able to store some sort of information in their ENUM counterparts. VIDIOC_S_DV_PRESET: easy to add. VIDIOC_S_DV_TIMINGS: easy to add. VIDIOC_S_AUDIO/VIDIOC_S_AUDOUT: easy to add, but not sure if it is needed. I'm sure there are a lot of details to sort out if we apply this principle as well to the V4L2 API, but I think that for subdevs this
[PULL] request for 2.6.38-rc1
Hi Mauro, if it is not too late, here is a pull request for some new devices from DiBcom. It would be nice to have it in 2.6.38-rc1. Pull from git://linuxtv.org/pb/media_tree.git staging/for_2.6.38-rc1.dibcom for DiB: Codingstype updates DiB0700: add support for several board-layouts DiB7090: add support for the dib7090 based DIB9000: initial support added DiB0090: misc improvements DiBx000: add addition i2c-interface names DiB8000: add diversity support DiB0700: add function to change I2C-speed drivers/media/dvb/dvb-usb/dib0700.h |2 + drivers/media/dvb/dvb-usb/dib0700_core.c | 47 +- drivers/media/dvb/dvb-usb/dib0700_devices.c | 1374 ++-- drivers/media/dvb/dvb-usb/dvb-usb-ids.h |5 + drivers/media/dvb/frontends/Kconfig |8 + drivers/media/dvb/frontends/Makefile |1 + drivers/media/dvb/frontends/dib0090.c| 1583 ++ drivers/media/dvb/frontends/dib0090.h| 31 + drivers/media/dvb/frontends/dib7000p.c | 1943 -- drivers/media/dvb/frontends/dib7000p.h | 96 +- drivers/media/dvb/frontends/dib8000.c| 833 ++ drivers/media/dvb/frontends/dib8000.h| 20 + drivers/media/dvb/frontends/dib9000.c| 2350 ++ drivers/media/dvb/frontends/dib9000.h| 131 ++ drivers/media/dvb/frontends/dibx000_common.c | 279 +++- drivers/media/dvb/frontends/dibx000_common.h | 152 ++- 16 files changed, 7487 insertions(+), 1368 deletions(-) best regards, -- Patrick Boettcher - Kernel Labs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dib7000m/p: struct alignment fix
Hi, On Wed, 12 Jan 2011, Robin Humble wrote: Ubuntu has a bug open for the issue: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/654791 but the disable pid filtering workaround one person uses there doesn't work for me. Sorry for the delay, but I only realized today that this bug exists. We are currently creating a proper fix for it. best regards, -- Patrick Boettcher - Kernel Labs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-media] API V3 vs SAPI behavior difference in reading tuning parameters
On Fri, Jan 14, 2011 at 8:35 AM, Thierry LELEGARD wrote: > But there is worse. If I set a wrong parameter in the tuning operation, > for instance guard interval 1/32, the API V3 returns the correct value > which is actually used by the tuner (GUARD_INTERVAL_1_8), while S2API > returns the "cached" value which was set while tuning (GUARD_INTERVAL_1_32). This is actually a bad thing. If you specify the wrong parameter and it still works, then that can lead to all sort of misleading behavior. For example, imagine the next person who submits scan results based on using such a driver. It works for him because his driver lied, but the resulting file works for nobody else. If you specify an explicit value incorrectly (not auto) and it still works, that is a driver bug which should be fixed. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-media] API V3 vs SAPI behavior difference in reading tuning parameters
Hello Thierry, On 01/14/2011 02:35 PM, Thierry LELEGARD wrote: > Dear all, > > I would like to report an annoying behavior difference between S2API and the > legacy DVB API (V3) when _reading_ the current tuning configuration. > > In short, API V3 is able to report the _actual_ tuning parameters as used by > the driver and corresponding to the actual broadcast steam. On the other hand, > S2API reports cached values which were specified in the tuning operation and > these values may be generic (*_AUTO symbols) or even wrong. if that's still the case in Git (I didn't verify), then it should indeed be changed to behave like v3 does. Would you mind to submit a patch, please? > But there is worse. If I set a wrong parameter in the tuning operation, > for instance guard interval 1/32, the API V3 returns the correct value > which is actually used by the tuner (GUARD_INTERVAL_1_8), while S2API > returns the "cached" value which was set while tuning (GUARD_INTERVAL_1_32). That behaviour, however, is implementation specific and can't be relied upon. In theory, the driver should always use the specified parameters, unless set to *_AUTO. But there are cases like yours, where the driver forces automatic detection of some parameters. This may or may not be required by the underlying device. Regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 2.6.38] gspca for_2.6.38
On Thu, 13 Jan 2011 17:30:21 +0100 Jean-Francois Moine wrote: > On Thu, 13 Jan 2011 12:38:04 +0100 > Antonio Ospite wrote: > > > > Jean-François Moine (9): > > [...] > > > gspca - ov534: Use the new video control mechanism > > > > In this commit, is there a reason why you didn't rename also > > sd_setagc() into setagc() like for the other functions? > > > > I am going to test the changes and report back if there's anything > > more, I like the cleanup tho. > > Hi Antonio, > > With the new video control mechanism, the '.set_control' function is > called only when capture is active. Otherwise, the '.set' function is > called in any case, and here, it activates/inactivates the auto white > balance control... Oh, I forgot to disable the awb when the agc is > disabled! > So the convention you used for function names is: .set = sd_setFOO; and .set_control = setBAR; right? Tested with guvcview, when toggling the Autoexposure control I get this message: control id: 0x009a0901 failed to set (error -1) control id: 0x009a0901 failed to get value (error -1) Similar error with qv4l2: Error Auto Exposure (1): Invalid argument And because of that the manual Exposure control does not work either. However I verified these errors are also in 2.6.35, so I think your conversion is fine, there must be something else going on; maybe I should open another thread, as there is also the pending issue of changing framerates "live", unrelated to the control changes as well. I hope to be able to look at these issues soon, if nobody else does before. Thanks, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? pgplS6ExHdskm.pgp Description: PGP signature
[linux-media] API V3 vs SAPI behavior difference in reading tuning parameters
Dear all, I would like to report an annoying behavior difference between S2API and the legacy DVB API (V3) when _reading_ the current tuning configuration. In short, API V3 is able to report the _actual_ tuning parameters as used by the driver and corresponding to the actual broadcast steam. On the other hand, S2API reports cached values which were specified in the tuning operation and these values may be generic (*_AUTO symbols) or even wrong. Logically, it seems that the difference is located in the API and not in the driver. Here is the configuration I test: Kernel 2.6.35.10-74.fc14.i686 (Fedora 14) Hauppauge WinTV-Nova-T-500 (dual DVB-T, DiBcom 3000MC/P) I tune to a frequency and let many parameters to their *_AUTO value: DTV_TRANSMISSION_MODE DTV_GUARD_INTERVAL DTV_CODE_RATE_HP DTV_CODE_RATE_LP The tuning is performed correctly and reception is effective. The tuner finds the right parameters. With API V3, after reading the frontend state (FE_GET_FRONTEND), the returned values are correct. I can see that actual code rate HP is 3/4, LP 1/2, transmission mode 8K and guard interval 1/8. However, on the same machine, after reading the frontend state using S2API (FE_GET_PROPERTY), all returned values are the *_AUTO values I specified while tuning. But there is worse. If I set a wrong parameter in the tuning operation, for instance guard interval 1/32, the API V3 returns the correct value which is actually used by the tuner (GUARD_INTERVAL_1_8), while S2API returns the "cached" value which was set while tuning (GUARD_INTERVAL_1_32). So, the driver is able 1) to find the correct actual parameter and 2) to report this actual value since API V3 returns it. But it seems that API V3 returns the actual tuning parameter as used by the driver while S2API returns a cached value which was used while tuning. This seems an annoying regression. An application is no longer able to determine the modulation parameter of an actual stream. As a final note, there is no difference if the tuning operation is performed using API V3 or S2API, the difference is only in the reading operation (FE_GET_FRONTEND vs. FE_GET_PROPERTY). Best regards, -Thierry -- 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 v14 2/2] davinci vpbe: board specific additions
This patch implements tables for display timings,outputs and
other board related functionalities.
Signed-off-by: Manjunath Hadli
Acked-by: Muralidharan Karicheri
Acked-by: Hans Verkuil
---
arch/arm/mach-davinci/board-dm644x-evm.c | 84 -
1 files changed, 69 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 0ca90b8..95ea13d 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -176,18 +176,6 @@ static struct platform_device davinci_evm_nandflash_device
= {
.resource = davinci_evm_nandflash_resource,
};
-static u64 davinci_fb_dma_mask = DMA_BIT_MASK(32);
-
-static struct platform_device davinci_fb_device = {
- .name = "davincifb",
- .id = -1,
- .dev = {
- .dma_mask = &davinci_fb_dma_mask,
- .coherent_dma_mask = DMA_BIT_MASK(32),
- },
- .num_resources = 0,
-};
-
static struct tvp514x_platform_data tvp5146_pdata = {
.clk_polarity = 0,
.hs_polarity = 1,
@@ -337,7 +325,6 @@ static struct pcf857x_platform_data pcf_data_u2 = {
.teardown = evm_led_teardown,
};
-
/* U18 - A/V clock generator and user switch */
static int sw_gpio;
@@ -404,7 +391,6 @@ static struct pcf857x_platform_data pcf_data_u18 = {
.teardown = evm_u18_teardown,
};
-
/* U35 - various I/O signals used to manage USB, CF, ATA, etc */
static int
@@ -616,8 +602,73 @@ static void __init evm_init_i2c(void)
i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));
}
+#define VENC_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/* venc standards timings */
+static struct vpbe_enc_mode_info vbpe_enc_std_timings[] = {
+ {"ntsc", VPBE_ENC_STD, {V4L2_STD_525_60}, 1, 720, 480,
+ {11, 10}, {3, 1001}, 0x79, 0, 0x10, 0, 0, 0, 0},
+ {"pal", VPBE_ENC_STD, {V4L2_STD_625_50}, 1, 720, 576,
+ {54, 59}, {25, 1}, 0x7E, 0, 0x16, 0, 0, 0, 0},
+};
+
+/* venc dv preset timings */
+static struct vpbe_enc_mode_info vbpe_enc_preset_timings[] = {
+ {"480p59_94", VPBE_ENC_DV_PRESET, {V4L2_DV_480P59_94}, 0, 720, 480,
+ {1, 1}, {5994, 100}, 0x80, 0, 0x20, 0, 0, 0, 0},
+ {"576p50", VPBE_ENC_DV_PRESET, {V4L2_DV_576P50}, 0, 720, 576,
+ {1, 1}, {50, 1}, 0x7E, 0, 0x30, 0, 0, 0, 0},
+};
+
+/*
+ * The outputs available from VPBE + encoders. Keep the order same
+ * as that of encoders. First that from venc followed by that from
+ * encoders. Index in the output refers to index on a particular encoder.
+ * Driver uses this index to pass it to encoder when it supports more than
+ * one output. Application uses index of the array to set an output.
+ */
+static struct vpbe_output dm644x_vpbe_outputs[] = {
+ {
+ .output = {
+ .index = 0,
+ .name = "Composite",
+ .type = V4L2_OUTPUT_TYPE_ANALOG,
+ .std = VENC_STD_ALL,
+ .capabilities = V4L2_OUT_CAP_STD,
+ },
+ .subdev_name = VPBE_VENC_SUBDEV_NAME,
+ .default_mode = "ntsc",
+ .num_modes = ARRAY_SIZE(vbpe_enc_std_timings),
+ .modes = vbpe_enc_std_timings,
+ },
+ {
+ .output = {
+ .index = 1,
+ .name = "Component",
+ .type = V4L2_OUTPUT_TYPE_ANALOG,
+ .capabilities = V4L2_OUT_CAP_PRESETS,
+ },
+ .subdev_name = VPBE_VENC_SUBDEV_NAME,
+ .default_mode = "480p59_94",
+ .num_modes = ARRAY_SIZE(vbpe_enc_preset_timings),
+ .modes = vbpe_enc_preset_timings,
+ },
+};
+
+static struct vpbe_display_config vpbe_display_cfg = {
+ .module_name = "dm644x-vpbe-display",
+ .i2c_adapter_id = 1,
+ .osd = {
+ .module_name = VPBE_OSD_SUBDEV_NAME,
+ },
+ .venc = {
+ .module_name = VPBE_VENC_SUBDEV_NAME,
+ },
+ .num_outputs = ARRAY_SIZE(dm644x_vpbe_outputs),
+ .outputs = dm644x_vpbe_outputs,
+};
+
static struct platform_device *davinci_evm_devices[] __initdata = {
- &davinci_fb_device,
&rtc_dev,
};
@@ -630,6 +681,9 @@ davinci_evm_map_io(void)
{
/* setup input configuration for VPFE input devices */
dm644x_set_vpfe_config(&vpfe_cfg);
+
+ /* setup configuration for vpbe devices */
+ dm644x_set_vpbe_display_config(&vpbe_display_cfg);
dm644x_init();
}
--
1.6.2.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
[PATCH v14 6/6] davinci vpbe: Readme text for Dm6446 vpbe
Please refer to this file for detailed documentation of davinci vpbe v4l2 driver. Signed-off-by: Manjunath Hadli Acked-by: Muralidharan Karicheri Acked-by: Hans Verkuil --- Documentation/video4linux/README.davinci-vpbe | 93 + 1 files changed, 93 insertions(+), 0 deletions(-) create mode 100644 Documentation/video4linux/README.davinci-vpbe diff --git a/Documentation/video4linux/README.davinci-vpbe b/Documentation/video4linux/README.davinci-vpbe new file mode 100644 index 000..7a460b0 --- /dev/null +++ b/Documentation/video4linux/README.davinci-vpbe @@ -0,0 +1,93 @@ + +VPBE V4L2 driver design + == + + File partitioning + - + V4L2 display device driver + drivers/media/video/davinci/vpbe_display.c + drivers/media/video/davinci/vpbe_display.h + + VPBE display controller + drivers/media/video/davinci/vpbe.c + drivers/media/video/davinci/vpbe.h + + VPBE venc sub device driver + drivers/media/video/davinci/vpbe_venc.c + drivers/media/video/davinci/vpbe_venc.h + drivers/media/video/davinci/vpbe_venc_regs.h + + VPBE osd driver + drivers/media/video/davinci/vpbe_osd.c + drivers/media/video/davinci/vpbe_osd.h + drivers/media/video/davinci/vpbe_osd_regs.h + + Functional partitioning + --- + + Consists of the following (in the same order as the list under file + partitioning):- + + 1. V4L2 display driver +Implements creation of video2 and video3 device nodes and +provides v4l2 device interface to manage VID0 and VID1 layers. + + 2. Display controller +Loads up VENC, OSD and external encoders such as ths8200. It provides +a set of API calls to V4L2 drivers to set the output/standards +in the VENC or external sub devices. It also provides +a device object to access the services from OSD subdevice +using sub device ops. The connection of external encoders to VENC LCD +controller port is done at init time based on default output and standard +selection or at run time when application change the output through +V4L2 IOCTLs. + +When connected to an external encoder, vpbe controller is also responsible +for setting up the interface between VENC and external encoders based on +board specific settings (specified in board-xxx-evm.c). This allows +interfacing external encoders such as ths8200. The setup_if_config() +is implemented for this as well as configure_venc() (part of the next patch) +API to set timings in VENC for a specific display resolution. As of this +patch series, the interconnection and enabling and setting of the external +encoders is not present, and would be a part of the next patch series. + + 3. VENC subdevice module +Responsible for setting outputs provided through internal DACs and also +setting timings at LCD controller port when external encoders are connected +at the port or LCD panel timings required. When external encoder/LCD panel +is connected, the timings for a specific standard/preset is retrieved from +the board specific table and the values are used to set the timings in +venc using non-standard timing mode. + +Support LCD Panel displays using the VENC. For example to support a Logic +PD display, it requires setting up the LCD controller port with a set of +timings for the resolution supported and setting the dot clock. So we could +add the available outputs as a board specific entry (i.e add the "LogicPD" +output name to board-xxx-evm.c). A table of timings for various LCDs +supported can be maintained in the board specific setup file to support +various LCD displays.As of this patch a basic driver is present, and this +support for external encoders and displays forms a part of the next +patch series. + + 4. OSD module +OSD module implements all OSD layer management and hardware specific +features. The VPBE module interacts with the OSD for enabling and +disabling appropriate features of the OSD. + + Current status:- + + A fully functional working version of the V4L2 driver is available. This + driver has been tested with NTSC and PAL standards and buffer streaming. + + Following are TBDs. + + vpbe display controller +- Add support for external encoders. +- add support for selecting external encoder as default at probe time. + + vpbe venc sub device +- add timings for supporting ths8200 +- add support for LogicPD LCD. + + FB drivers +- Add support for fbdev drivers.- Ready and part of subsequent patches. -- 1.6.2.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
[PATCH v14 0/2] platform changes for DM6446 VPBE v4l2 driver
version14 : addressed Shekhar's comments on: 1. Implemetation of single io_remap of system module base address 2. Minor changes in the GPL comments cover letter addition: Need the 6 main driver patches for DM6446 VPBE v4l2 driver for build. Signed-off-by: Manjunath Hadli Acked-by: Muralidharan Karicheri Acked-by: Hans Verkuil Manjunath Hadli (2): davinci vpbe: platform specific additions davinci vpbe: board specific additions arch/arm/mach-davinci/board-dm644x-evm.c | 84 ++--- arch/arm/mach-davinci/devices.c | 11 +- arch/arm/mach-davinci/dm355.c |3 + arch/arm/mach-davinci/dm365.c |3 + arch/arm/mach-davinci/dm644x.c| 167 +++-- arch/arm/mach-davinci/dm646x.c|3 + arch/arm/mach-davinci/include/mach/dm644x.h | 10 ++ arch/arm/mach-davinci/include/mach/hardware.h |5 + 8 files changed, 253 insertions(+), 33 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
[PATCH v14 1/2] davinci vpbe: platform specific additions
This patch implements the overall device creation for the Video
display driver.
Signed-off-by: Manjunath Hadli
Acked-by: Muralidharan Karicheri
Acked-by: Hans Verkuil
---
arch/arm/mach-davinci/devices.c | 11 +-
arch/arm/mach-davinci/dm355.c |3 +
arch/arm/mach-davinci/dm365.c |3 +
arch/arm/mach-davinci/dm644x.c| 167 +++--
arch/arm/mach-davinci/dm646x.c|3 +
arch/arm/mach-davinci/include/mach/dm644x.h | 10 ++
arch/arm/mach-davinci/include/mach/hardware.h |5 +
7 files changed, 184 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index 22ebc64..f435c7d 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -33,6 +33,8 @@
#define DM365_MMCSD0_BASE 0x01D11000
#define DM365_MMCSD1_BASE 0x01D0
+void __iomem *davinci_sysmodbase;
+
static struct resource i2c_resources[] = {
{
.start = DAVINCI_I2C_BASE,
@@ -209,9 +211,7 @@ void __init davinci_setup_mmc(int module, struct
davinci_mmc_config *config)
davinci_cfg_reg(DM355_SD1_DATA2);
davinci_cfg_reg(DM355_SD1_DATA3);
} else if (cpu_is_davinci_dm365()) {
- void __iomem *pupdctl1 =
- IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE + 0x7c);
-
+ void __iomem *pupdctl1 = DAVINCI_SYSMODULE_VIRT(0x7c);
/* Configure pull down control */
__raw_writel((__raw_readl(pupdctl1) & ~0xfc0),
pupdctl1);
@@ -242,10 +242,7 @@ void __init davinci_setup_mmc(int module, struct
davinci_mmc_config *config)
SZ_4K - 1;
mmcsd0_resources[2].start = IRQ_DM365_SDIOINT0;
} else if (cpu_is_davinci_dm644x()) {
- /* REVISIT: should this be in board-init code? */
- void __iomem *base =
- IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
-
+ void __iomem *base = DAVINCI_SYSMODULE_VIRT(0);
/* Power-on 3.3V IO cells */
__raw_writel(0, base + DM64XX_VDD3P3V_PWDN);
/*Set up the pull regiter for MMC */
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 2652af1..106bc1b 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -878,6 +878,9 @@ void __init dm355_init_asp1(u32 evt_enable, struct
snd_platform_data *pdata)
void __init dm355_init(void)
{
+ davinci_sysmodbase = ioremap_nocache(DAVINCI_SYSTEM_MODULE_BASE, 0x800);
+ if (!davinci_sysmodbase)
+ return;
davinci_common_init(&davinci_soc_info_dm355);
}
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index c466d71..178c610 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1132,6 +1132,9 @@ void __init dm365_init_rtc(void)
void __init dm365_init(void)
{
+ davinci_sysmodbase = ioremap_nocache(DAVINCI_SYSTEM_MODULE_BASE, 0x800);
+ if (!davinci_sysmodbase)
+ return;
davinci_common_init(&davinci_soc_info_dm365);
}
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 9a2376b..8831026 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -590,8 +590,8 @@ static struct resource dm644x_vpss_resources[] = {
{
/* VPSS Base address */
.name = "vpss",
- .start = 0x01c73400,
- .end= 0x01c73400 + 0xff,
+ .start = DM644X_VPSS_REG_BASE,
+ .end= DM644X_VPSS_REG_BASE + 0xff,
.flags = IORESOURCE_MEM,
},
};
@@ -618,6 +618,7 @@ static struct resource vpfe_resources[] = {
};
static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+
static struct resource dm644x_ccdc_resource[] = {
/* CCDC Base address */
{
@@ -654,6 +655,134 @@ void dm644x_set_vpfe_config(struct vpfe_config *cfg)
vpfe_capture_dev.dev.platform_data = cfg;
}
+static struct resource dm644x_osd_resources[] = {
+ {
+ .start = DM644X_OSD_REG_BASE,
+ .end= DM644X_OSD_REG_BASE + 0x1ff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static u64 dm644x_osd_dma_mask = DMA_BIT_MASK(32);
+
+static struct osd_platform_data osd_data = {
+ .vpbe_type = DM644X_VPBE,
+ .field_inv_wa_enable = 0,
+};
+
+static struct platform_device dm644x_osd_dev = {
+ .name = VPBE_OSD_SUBDEV_NAME,
+ .id = -1,
+ .num_resources = ARRAY_SIZE
[PATCH v14 5/6] davinci vpbe: Build infrastructure for VPBE driver
This patch adds the build infra-structure for Davinci VPBE dislay driver. Signed-off-by: Manjunath Hadli Acked-by: Muralidharan Karicheri Acked-by: Hans Verkuil --- drivers/media/video/davinci/Kconfig | 22 ++ drivers/media/video/davinci/Makefile |2 ++ 2 files changed, 24 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig index 6b19540..a7f11e7 100644 --- a/drivers/media/video/davinci/Kconfig +++ b/drivers/media/video/davinci/Kconfig @@ -91,3 +91,25 @@ config VIDEO_ISIF To compile this driver as a module, choose M here: the module will be called vpfe. + +config VIDEO_DM644X_VPBE + tristate "DM644X VPBE HW module" + select VIDEO_VPSS_SYSTEM + select VIDEOBUF_DMA_CONTIG + help + Enables VPBE modules used for display on a DM644x + SoC. + + To compile this driver as a module, choose M here: the + module will be called vpbe. + + +config VIDEO_VPBE_DISPLAY + tristate "VPBE V4L2 Display driver" + select VIDEO_DM644X_VPBE + default y + help + Enables VPBE V4L2 Display driver on a DMXXX device + + To compile this driver as a module, choose M here: the + module will be called vpbe_display. diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile index a379557..ae7dafb 100644 --- a/drivers/media/video/davinci/Makefile +++ b/drivers/media/video/davinci/Makefile @@ -16,3 +16,5 @@ obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o obj-$(CONFIG_VIDEO_ISIF) += isif.o +obj-$(CONFIG_VIDEO_DM644X_VPBE) += vpbe.o vpbe_osd.o vpbe_venc.o +obj-$(CONFIG_VIDEO_VPBE_DISPLAY) += vpbe_display.o -- 1.6.2.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
[PATCH v14 3/6] davinci vpbe: OSD(On Screen Display) block
This patch implements the functionality of the OSD block
of the VPBE. The OSD in total supports 4 planes or Video
sources - 2 mainly RGB and 2 Video. The patch implements general
handling of all the planes, with specific emphasis on the Video
plane capabilities as the Video planes are supported through the
V4L2 driver.
Signed-off-by: Manjunath Hadli
Acked-by: Muralidharan Karicheri
Acked-by: Hans Verkuil
---
drivers/media/video/davinci/vpbe_osd.c | 1216 +++
drivers/media/video/davinci/vpbe_osd_regs.h | 364
include/media/davinci/vpbe_osd.h| 397 +
3 files changed, 1977 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpbe_osd.c
create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h
create mode 100644 include/media/davinci/vpbe_osd.h
diff --git a/drivers/media/video/davinci/vpbe_osd.c
b/drivers/media/video/davinci/vpbe_osd.c
new file mode 100644
index 000..bbc43ea
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe_osd.c
@@ -0,0 +1,1216 @@
+/*
+ * Copyright (C) 2007-2010 Texas Instruments Inc
+ * Copyright (C) 2007 MontaVista Software, Inc.
+ *
+ * Andy Lowe (al...@mvista.com), MontaVista Software
+ * - Initial version
+ * Murali Karicheri (mkarich...@gmail.com), Texas Instruments Ltd.
+ * - ported to sub device interface
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+#include "vpbe_osd_regs.h"
+
+#define MODULE_NAMEVPBE_OSD_SUBDEV_NAME
+
+/* register access routines */
+static inline u32 osd_read(struct osd_state *sd, u32 offset)
+{
+ struct osd_state *osd = sd;
+ return readl(osd->osd_base + offset);
+}
+
+static inline u32 osd_write(struct osd_state *sd, u32 val, u32 offset)
+{
+ struct osd_state *osd = sd;
+ writel(val, osd->osd_base + offset);
+ return val;
+}
+
+static inline u32 osd_set(struct osd_state *sd, u32 mask, u32 offset)
+{
+ struct osd_state *osd = sd;
+
+ u32 addr = osd->osd_base + offset;
+ u32 val = readl(addr) | mask;
+
+ writel(val, addr);
+ return val;
+}
+
+static inline u32 osd_clear(struct osd_state *sd, u32 mask, u32 offset)
+{
+ struct osd_state *osd = sd;
+ u32 addr = osd->osd_base + offset;
+ u32 val = readl(addr) & ~mask;
+
+ writel(val, addr);
+ return val;
+}
+
+static inline u32 osd_modify(struct osd_state *sd, u32 mask, u32 val,
+u32 offset)
+{
+ struct osd_state *osd = sd;
+
+ u32 addr = osd->osd_base + offset;
+ u32 new_val = (readl(addr) & ~mask) | (val & mask);
+ writel(new_val, addr);
+ return new_val;
+}
+
+/* define some macros for layer and pixfmt classification */
+#define is_osd_win(layer) (((layer) == WIN_OSD0) || ((layer) == WIN_OSD1))
+#define is_vid_win(layer) (((layer) == WIN_VID0) || ((layer) == WIN_VID1))
+#define is_rgb_pixfmt(pixfmt) \
+ (((pixfmt) == PIXFMT_RGB565) || ((pixfmt) == PIXFMT_RGB888))
+#define is_yc_pixfmt(pixfmt) \
+ (((pixfmt) == PIXFMT_YCbCrI) || ((pixfmt) == PIXFMT_YCrCbI) || \
+ ((pixfmt) == PIXFMT_NV12))
+#define MAX_WIN_SIZE OSD_VIDWIN0XP_V0X
+#define MAX_LINE_LENGTH (OSD_VIDWIN0OFST_V0LO << 5)
+
+/**
+ * _osd_dm6446_vid0_pingpong() - field inversion fix for DM6446
+ * @sd - ptr to struct osd_state
+ * @field_inversion - inversion flag
+ * @fb_base_phys - frame buffer address
+ * @lconfig - ptr to layer config
+ *
+ * This routine implements a workaround for the field signal inversion silicon
+ * erratum described in Advisory 1.3.8 for the DM6446. The fb_base_phys and
+ * lconfig parameters apply to the vid0 window. This routine should be called
+ * whenever the vid0 layer configuration or start address is modified, or when
+ * the OSD field inversion setting is modified.
+ * Returns: 1 if the ping-pong buffers need to be toggled in the vsync isr, or
+ * 0 otherwise
+ */
+static int _osd_dm6446_vid0_pingpong(struct osd_state *sd,
+int field_inversion,
+unsigned long fb_base_phys,
+const struct osd_layer_config *lconfig)
+{
+ struct osd_platform_data *pdata;
+
[PATCH v14 4/6] davinci vpbe: VENC( Video Encoder) implementation
This patch adds the VENC or the Video encoder, which is responsible
for the blending of all source planes and timing generation for Video
modes like NTSC, PAL and other digital outputs. the VENC implementation
currently supports COMPOSITE and COMPONENT outputs and NTSC and PAL
resolutions through the analog DACs. The venc block is implemented
as a subdevice, allowing for additional external and internal encoders
of other kind to plug-in.
Signed-off-by: Manjunath Hadli
Acked-by: Muralidharan Karicheri
Acked-by: Hans Verkuil
---
drivers/media/video/davinci/vpbe_venc.c | 556 ++
drivers/media/video/davinci/vpbe_venc_regs.h | 177
include/media/davinci/vpbe_venc.h| 41 ++
3 files changed, 774 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpbe_venc.c
create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h
create mode 100644 include/media/davinci/vpbe_venc.h
diff --git a/drivers/media/video/davinci/vpbe_venc.c
b/drivers/media/video/davinci/vpbe_venc.c
new file mode 100644
index 000..1131e2d
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe_venc.c
@@ -0,0 +1,556 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+
+#include "vpbe_venc_regs.h"
+
+#define MODULE_NAMEVPBE_VENC_SUBDEV_NAME
+
+static int debug = 2;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "Debug level 0-2");
+
+struct venc_state {
+ struct v4l2_subdev sd;
+ struct venc_callback *callback;
+ struct venc_platform_data *pdata;
+ struct device *pdev;
+ u32 output;
+ v4l2_std_id std;
+ spinlock_t lock;
+ void __iomem *venc_base;
+ void __iomem *vdaccfg_reg;
+};
+
+static inline struct venc_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct venc_state, sd);
+}
+
+static inline u32 venc_read(struct v4l2_subdev *sd, u32 offset)
+{
+ struct venc_state *venc = to_state(sd);
+
+ return readl(venc->venc_base + offset);
+}
+
+static inline u32 venc_write(struct v4l2_subdev *sd, u32 offset, u32 val)
+{
+ struct venc_state *venc = to_state(sd);
+ writel(val, (venc->venc_base + offset));
+ return val;
+}
+
+static inline u32 venc_modify(struct v4l2_subdev *sd, u32 offset,
+u32 val, u32 mask)
+{
+ u32 new_val = (venc_read(sd, offset) & ~mask) | (val & mask);
+
+ venc_write(sd, offset, new_val);
+ return new_val;
+}
+
+static inline u32 vdaccfg_write(struct v4l2_subdev *sd, u32 val)
+{
+ struct venc_state *venc = to_state(sd);
+
+ writel(val, venc->vdaccfg_reg);
+
+ val = readl(venc->vdaccfg_reg);
+ return val;
+}
+
+/* This function sets the dac of the VPBE for various outputs
+ */
+static int venc_set_dac(struct v4l2_subdev *sd, u32 out_index)
+{
+ int ret = 0;
+
+ switch (out_index) {
+ case 0:
+ v4l2_dbg(debug, 1, sd, "Setting output to Composite\n");
+ venc_write(sd, VENC_DACSEL, 0);
+ break;
+ case 1:
+ v4l2_dbg(debug, 1, sd, "Setting output to S-Video\n");
+ venc_write(sd, VENC_DACSEL, 0x210);
+ break;
+ case 2:
+ venc_write(sd, VENC_DACSEL, 0x543);
+ break;
+ default:
+ ret = -EINVAL;
+ }
+ return ret;
+}
+
+static void venc_enabledigitaloutput(struct v4l2_subdev *sd, int benable)
+{
+ v4l2_dbg(debug, 2, sd, "venc_enabledigitaloutput\n");
+
+ if (benable) {
+ venc_write(sd, VENC_VMOD, 0);
+ venc_write(sd, VENC_CVBS, 0);
+ venc_write(sd, VENC_LCDOUT, 0);
+ venc_write(sd, VENC_HSPLS, 0);
+ venc_write(sd, VENC_HSTART, 0);
+ venc_write(sd, VENC_HVALID, 0);
+ venc_write(sd, VENC_HINT, 0);
+ venc_write(sd, VENC_VSPLS, 0);
+ venc_write(sd, VENC_VSTART, 0);
+ venc_write(sd, VENC_VVALID, 0);
+ venc_write(sd, VENC_VINT, 0);
+ venc_write(sd,
[PATCH v14 2/6] davinci vpbe: VPBE display driver
This patch implements the core functionality of the dislay driver,
mainly controlling the VENC and other encoders, and acting as
the one point interface for the main V4L2 driver. This implements
the core of each of the V4L2 IOCTLs.
Signed-off-by: Manjunath Hadli
Acked-by: Muralidharan Karicheri
Acked-by: Hans Verkuil
---
drivers/media/video/davinci/vpbe.c | 826
include/media/davinci/vpbe.h | 185
2 files changed, 1011 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpbe.c
create mode 100644 include/media/davinci/vpbe.h
diff --git a/drivers/media/video/davinci/vpbe.c
b/drivers/media/video/davinci/vpbe.c
new file mode 100644
index 000..d3aaf1e
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe.c
@@ -0,0 +1,826 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#define VPBE_DEFAULT_OUTPUT"Composite"
+#define VPBE_DEFAULT_MODE "ntsc"
+
+static char *def_output = VPBE_DEFAULT_OUTPUT;
+static char *def_mode = VPBE_DEFAULT_MODE;
+static struct osd_state *osd_device;
+static struct venc_platform_data *venc_device;
+static int debug;
+
+module_param(def_output, charp, S_IRUGO);
+module_param(def_mode, charp, S_IRUGO);
+module_param(debug, int, 0644);
+
+MODULE_PARM_DESC(def_output, "vpbe output name (default:Composite)");
+MODULE_PARM_DESC(def_mode, "vpbe output mode name (default:ntsc");
+MODULE_PARM_DESC(debug, "Debug level 0-1");
+
+MODULE_DESCRIPTION("TI DMXXX VPBE Display controller");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Texas Instruments");
+
+/**
+ * vpbe_current_encoder_info - Get config info for current encoder
+ * @vpbe_dev - vpbe device ptr
+ *
+ * Return ptr to current encoder config info
+ */
+static struct encoder_config_info*
+vpbe_current_encoder_info(struct vpbe_device *vpbe_dev)
+{
+ struct vpbe_display_config *vpbe_config = vpbe_dev->cfg;
+ int index = vpbe_dev->current_sd_index;
+
+ return ((index == 0) ? &vpbe_config->venc :
+ &vpbe_config->ext_encoders[index-1]);
+}
+
+/**
+ * vpbe_find_encoder_sd_index - Given a name find encoder sd index
+ *
+ * @vpbe_config - ptr to vpbe cfg
+ * @output_index - index used by application
+ *
+ * Return sd index of the encoder
+ */
+static int vpbe_find_encoder_sd_index(struct vpbe_display_config *vpbe_config,
+int index)
+{
+ char *encoder_name = vpbe_config->outputs[index].subdev_name;
+ int i;
+
+ /* Venc is always first */
+ if (!strcmp(encoder_name, vpbe_config->venc.module_name))
+ return 0;
+
+ for (i = 0; i < vpbe_config->num_ext_encoders; i++) {
+ if (!strcmp(encoder_name,
+vpbe_config->ext_encoders[i].module_name))
+ return i+1;
+ }
+ return -EINVAL;
+}
+
+/**
+ * vpbe_g_cropcap - Get crop capabilities of the display
+ * @vpbe_dev - vpbe device ptr
+ * @cropcap - cropcap is a ptr to struct v4l2_cropcap
+ *
+ * Update the crop capabilities in crop cap for current
+ * mode
+ */
+static int vpbe_g_cropcap(struct vpbe_device *vpbe_dev,
+ struct v4l2_cropcap *cropcap)
+{
+ if (NULL == cropcap)
+ return -EINVAL;
+ cropcap->bounds.left = 0;
+ cropcap->bounds.top = 0;
+ cropcap->bounds.width = vpbe_dev->current_timings.xres;
+ cropcap->bounds.height = vpbe_dev->current_timings.yres;
+ cropcap->defrect = cropcap->bounds;
+ return 0;
+}
+
+/**
+ * vpbe_enum_outputs - enumerate outputs
+ * @vpbe_dev - vpbe device ptr
+ * @output - ptr to v4l2_output structure
+ *
+ * Enumerates the outputs available at the vpbe display
+ * returns the status, -EINVAL if end of output list
+ */
+static int vpbe_enum_outputs(struct vpbe_device *vpbe_dev,
+struct v4l2_output *output)
+{
+ struct vpbe_display_config *vpbe_config = vpbe_dev->cfg;
+ int temp_index = output->index;
+
+ if (temp_index >= vpbe_config->num_outputs)
+ return -EINVAL;
+
+ *output = vpbe_config->outputs[temp_index].output;
+
media_build: build against 2.6.32 fails on rc-technisat-usb2.c
$ cat /proc/version_signature Ubuntu 2.6.32-26.47-generic 2.6.32.24+drm33.11 Building from git: $ cd ~/git/clones/v4l-dvb $ git log -1 commit aeb13b434d0953050306435cd3134d65547dbcf4 Author: Mauro Carvalho Chehab Date: Wed Jan 5 13:31:15 2011 -0200 cx25821: Fix compilation breakage due to BKL dependency ... $ cd ~/git/clones/new_build $ git log -1 commit 6da048c31318ddeb9b19d899403a91f4c10e34dc Author: Vincent McIntyre Date: Thu Jan 13 10:41:14 2011 -0200 Update it to cover hdpvr-i2c.c Signed-off-by: Mauro Carvalho Chehab Building via make tar DIR=... ; make untar; etc fails at this point: CC [M] /home/vjm/git/clones/linuxtv.org/new_build/v4l/rc-streamzap.o CC [M] /home/vjm/git/clones/linuxtv.org/new_build/v4l/rc-tbs-nec.o make[4]: *** No rule to make target `/home/vjm/git/clones/linuxtv.org/new_build/v4l/rc-technisat-usb2.c', needed by `/home/vjm/git/clones/linuxtv.org/new_build/v4l/rc-technisat-usb2.o'. Stop. I'll take a look but thought I should report this. Cheers Vince -- 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] addition to v2.6.35_i2c_new_probed_device.patch (was: Re: Debug code in HG repositories)
On 1/13/11, Mauro Carvalho Chehab wrote: >> This seems to be a relatively simple patch, inline below. >> This is against the linux-media tree, I could not figure out how >> to turn it into a clean patch of >> media_build/backports/v2.6.35_i2c_new_probed_device.patch >> I did look for guidance on how to do this in >> media_build/README.patches but could not find anything that looked >> relevant. > > Well, there are two ways for doing it: > Thanks for your explanation. I was quite puzzled for some time why I could not find the commit id in the git log, now I understand why. >> The code now compiles for me but I don't know if it will actually >> work, I don't have the hardware. > > Ok, I did the above procedure, adding your patch to the diff. Please test. > That bit works now (from git, the tarball downloaded by build.sh hasn't caught up). Thanks for applying. However the build now fails on a separate issue, which I'll put in a new thread. Cheers Vince -- 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: [RFC/PATCH v6 3/4] MFC: Add MFC 5.1 V4L2 driver
I added my comments.
I guess that Kamil's way could be possible to run seq. of dynamic resolution
change.
> -Original Message-
> From: Jonghun Han [mailto:jonghun@samsung.com]
> Sent: Friday, January 14, 2011 6:45 PM
> To: 'Kamil Debski'; linux-media@vger.kernel.org; linux-samsung-
> s...@vger.kernel.org
> Cc: 'Marek Szyprowski'; pa...@osciak.com; kyungmin.p...@samsung.com;
> jaeryul...@samsung.com; kgene@samsung.com
> Subject: RE: [RFC/PATCH v6 3/4] MFC: Add MFC 5.1 V4L2 driver
>
>
> Hi,
>
> I was confused the source and destination.
> I agree with you mostly.
>
> In my opinion, the way how to notify the resolution change is return value
> of the DQBUF.
> But if we use DQBUF, there are some problem as below.
>
> DQBUF means that the buffer has been operated already and application will
> have the buffer's right.
>
> Although application new QBUF destination buffers after changing
> destination(CAPTURE),
> driver cannot re-decode the I-frame which has the resolution change
> information
> because the I-frame has been dequeued already.
> If application re-QBUF the buffer, the buffer sequence will be out of
> order
> as below.
> Original: I -> B -> B .
> Out of order: missed -> B -> B -> I .
>
> How do you think about the following sequence.
>
> 1. getting the resolution change from the MFC H/W
>
> 2. copy the buffer to driver's internal memory.
>
> 3. send the result with DQBUF
>
> 4. changing destination buffers by application
>
> 5. QBUF for new destination buffers
>
> 6. in the first vb2_try_schedule
> re-decode the driver's internal buffer instead of the B frame.
>
> 7. in the next vb2_try_schedule
> decode the B frame in order.
>
> I also welcome your comments.
In the blocking sequence, blocking will be done in DQBUF.
1. QBUF done for I1 frame with hdr(first buf, res. chd)
: Copy I1 frame in the driver
2. DQBUF done for I1 frame
3. QBUF P2,P3,P4 frame, but it should NOT be DEQUED which means
Qbufed p2,p3,p4 is not executed
: P4(third buf) -> P3(second buf) -> P2 frame(first buf)
4. While waiting for DEQUE about P2, copied I1 frame is executed for
INIT_CODEC
5. Copied I1 frame is runned FRAME_START after dst buffer is reallocated
(5~9 in your seq.)
6. Queued P2 frame is executed, then DQBUF will be OK
>
> Best regards,
>
> > -Original Message-
> > From: Kamil Debski [mailto:k.deb...@samsung.com]
> > Sent: Friday, January 14, 2011 4:24 PM
> > To: 'Jonghun Han'; linux-media@vger.kernel.org; linux-samsung-
> > s...@vger.kernel.org
> > Cc: Marek Szyprowski; pa...@osciak.com; kyungmin.p...@samsung.com;
> > jaeryul...@samsung.com; kgene@samsung.com
> > Subject: RE: [RFC/PATCH v6 3/4] MFC: Add MFC 5.1 V4L2 driver
> >
> > Hi,
> >
> > > -Original Message-
> > > From: Jonghun Han [mailto:jonghun@samsung.com]
> > >
> > > Hi,
> > >
> > > Kamil Debski wrote:
> > >
> > >
> > >
> > > > +/* Reqeust buffers */
> > > > +static int vidioc_reqbufs(struct file *file, void *priv,
> > > > + struct v4l2_requestbuffers
> > > *reqbufs)
> > > > +{
> > > > + struct s5p_mfc_dev *dev = video_drvdata(file);
> > > > + struct s5p_mfc_ctx *ctx = priv;
> > > > + int ret = 0;
> > > > + unsigned long flags;
> > > > +
> > > > + mfc_debug_enter();
> > > > + mfc_debug("Memory type: %d\n", reqbufs->memory);
> > > > + if (reqbufs->memory != V4L2_MEMORY_MMAP) {
> > > > + mfc_err("Only V4L2_MEMORY_MAP is supported.\n");
> > > > + return -EINVAL;
> > > > + }
> > > > + if (reqbufs->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> > > > + /* Can only request buffers after an instance has
been
> > > opened.*/
> > > > + if (ctx->state == MFCINST_DEC_GOT_INST) {
> > > > + /* Decoding */
> > > > + if (ctx->output_state != QUEUE_FREE) {
> > > > + mfc_err("Bufs have already been
> > > requested.\n");
> > > > + return -EINVAL;
> > > > + }
> > > > + ret = vb2_reqbufs(&ctx->vq_src, reqbufs);
> > > > + if (ret) {
> > > > + mfc_err("vb2_reqbufs on output
> failed.\n");
> > > > + return ret;
> > > > + }
> > > > + mfc_debug("vb2_reqbufs: %d\n", ret);
> > > > + ctx->output_state = QUEUE_BUFS_REQUESTED;
> > > > + }
> > > > + } else if (reqbufs->type ==
> > > > V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> > > > + if (ctx->capture_state != QUEUE_FREE) {
> > > > + mfc_err("Bufs have already been
requested.\n");
> > > > + return -EINVAL;
> > > > + }
> > > > + ctx->capture_state = QUEUE_BUFS_REQUESTED;
> > > > +
RE: [RFC/PATCH v6 3/4] MFC: Add MFC 5.1 V4L2 driver
Hi,
I was confused the source and destination.
I agree with you mostly.
In my opinion, the way how to notify the resolution change is return value
of the DQBUF.
But if we use DQBUF, there are some problem as below.
DQBUF means that the buffer has been operated already and application will
have the buffer's right.
Although application new QBUF destination buffers after changing
destination(CAPTURE),
driver cannot re-decode the I-frame which has the resolution change
information
because the I-frame has been dequeued already.
If application re-QBUF the buffer, the buffer sequence will be out of order
as below.
Original: I -> B -> B .
Out of order: missed -> B -> B -> I .
How do you think about the following sequence.
1. getting the resolution change from the MFC H/W
2. copy the buffer to driver's internal memory.
3. send the result with DQBUF
4. changing destination buffers by application
5. QBUF for new destination buffers
6. in the first vb2_try_schedule
re-decode the driver's internal buffer instead of the B frame.
7. in the next vb2_try_schedule
decode the B frame in order.
I also welcome your comments.
Best regards,
> -Original Message-
> From: Kamil Debski [mailto:k.deb...@samsung.com]
> Sent: Friday, January 14, 2011 4:24 PM
> To: 'Jonghun Han'; linux-media@vger.kernel.org; linux-samsung-
> s...@vger.kernel.org
> Cc: Marek Szyprowski; pa...@osciak.com; kyungmin.p...@samsung.com;
> jaeryul...@samsung.com; kgene@samsung.com
> Subject: RE: [RFC/PATCH v6 3/4] MFC: Add MFC 5.1 V4L2 driver
>
> Hi,
>
> > -Original Message-
> > From: Jonghun Han [mailto:jonghun@samsung.com]
> >
> > Hi,
> >
> > Kamil Debski wrote:
> >
> >
> >
> > > +/* Reqeust buffers */
> > > +static int vidioc_reqbufs(struct file *file, void *priv,
> > > + struct v4l2_requestbuffers
> > *reqbufs)
> > > +{
> > > + struct s5p_mfc_dev *dev = video_drvdata(file);
> > > + struct s5p_mfc_ctx *ctx = priv;
> > > + int ret = 0;
> > > + unsigned long flags;
> > > +
> > > + mfc_debug_enter();
> > > + mfc_debug("Memory type: %d\n", reqbufs->memory);
> > > + if (reqbufs->memory != V4L2_MEMORY_MMAP) {
> > > + mfc_err("Only V4L2_MEMORY_MAP is supported.\n");
> > > + return -EINVAL;
> > > + }
> > > + if (reqbufs->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> > > + /* Can only request buffers after an instance has been
> > opened.*/
> > > + if (ctx->state == MFCINST_DEC_GOT_INST) {
> > > + /* Decoding */
> > > + if (ctx->output_state != QUEUE_FREE) {
> > > + mfc_err("Bufs have already been
> > requested.\n");
> > > + return -EINVAL;
> > > + }
> > > + ret = vb2_reqbufs(&ctx->vq_src, reqbufs);
> > > + if (ret) {
> > > + mfc_err("vb2_reqbufs on output failed.\n");
> > > + return ret;
> > > + }
> > > + mfc_debug("vb2_reqbufs: %d\n", ret);
> > > + ctx->output_state = QUEUE_BUFS_REQUESTED;
> > > + }
> > > + } else if (reqbufs->type ==
> > > V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> > > + if (ctx->capture_state != QUEUE_FREE) {
> > > + mfc_err("Bufs have already been requested.\n");
> > > + return -EINVAL;
> > > + }
> > > + ctx->capture_state = QUEUE_BUFS_REQUESTED;
> > > + ret = vb2_reqbufs(&ctx->vq_dst, reqbufs);
> > > + if (ret) {
> > > + mfc_err("vb2_reqbufs on capture failed.\n");
> > > + return ret;
> > > + }
> > > + if (reqbufs->count < ctx->dpb_count) {
> > > + mfc_err("Not enough buffers allocated.\n");
> > > + reqbufs->count = 0;
> > > + ret = vb2_reqbufs(&ctx->vq_dst, reqbufs);
> > > + return -ENOMEM;
> > > + }
> > > + ctx->total_dpb_count = reqbufs->count;
> > > + ret = s5p_mfc_alloc_dec_buffers(ctx);
> > > + if (ret) {
> > > + mfc_err("Failed to allocate decoding buffers.\n");
> > > + reqbufs->count = 0;
> > > + ret = vb2_reqbufs(&ctx->vq_dst, reqbufs);
> > > + return -ENOMEM;
> > > + }
> > > + if (ctx->dst_bufs_cnt == ctx->total_dpb_count) {
> > > + ctx->capture_state = QUEUE_BUFS_MMAPED;
> > > + } else {
> > > + mfc_err("Not all buffers passed to buf_init.\n");
> > > + reqbufs->count = 0;
> > > + ret = vb2_reqbufs(&ctx->vq_dst, reqbufs);
> > > + s5p_mfc_release_dec_buffers(ctx);
> > > + return -ENOMEM;
> > > + }
> > > + if (s5p_mfc_ctx_ready(ctx)) {
> > > + spin_lock_irqsave(&dev->condlock, flags);
> > > + set_bit(ctx->num, &dev->ctx_work_bits);
> > > +
Re: [PATCH][rfc] media, video, stv06xx, pb0100: Don't potentially deref NULL in pb0100_start().
Hi, On 01/13/2011 11:05 PM, Jesper Juhl wrote: usb_altnum_to_altsetting() may return NULL. If it does we'll dereference a NULL pointer in drivers/media/video/gspca/stv06xx/stv06xx_pb0100.c::pb0100_start(). As far as I can tell there's not really anything more sensible than -ENODEV that we can return in that situation, but I'm not at all intimate with this code so I'd like a bit of review/comments on this before it's applied. Anyway, here's a proposed patch. Hi, On 01/13/2011 11:05 PM, Jesper Juhl wrote: > usb_altnum_to_altsetting() may return NULL. If it does we'll dereference a > NULL pointer in > drivers/media/video/gspca/stv06xx/stv06xx_pb0100.c::pb0100_start(). > As far as I can tell there's not really anything more sensible than > -ENODEV that we can return in that situation, but I'm not at all intimate > with this code so I'd like a bit of review/comments on this before it's > applied. > Anyway, here's a proposed patch. > pb0100_start gets called from stv06xx_start, which also does a usb_altnum_to_altsetting(intf, sd->gspca_dev.alt); and does contain the NULL check before calling pb0100_start. So I left out the check on purpose, to keep the code compact in IMHO better readable. Still I agree this is a bit tricky. So not NACK but not ACK either. What do others think? Regards, Hans Signed-off-by: Jesper Juhl --- stv06xx_pb0100.c |2 ++ 1 file changed, 2 insertions(+) compile tested only. diff --git a/drivers/media/video/gspca/stv06xx/stv06xx_pb0100.c b/drivers/media/video/gspca/stv06xx/stv06xx_pb0100.c index ac47b4c..75a5b9c 100644 --- a/drivers/media/video/gspca/stv06xx/stv06xx_pb0100.c +++ b/drivers/media/video/gspca/stv06xx/stv06xx_pb0100.c @@ -217,6 +217,8 @@ static int pb0100_start(struct sd *sd) intf = usb_ifnum_to_if(sd->gspca_dev.dev, sd->gspca_dev.iface); alt = usb_altnum_to_altsetting(intf, sd->gspca_dev.alt); + if (!alt) + return -ENODEV; packet_size = le16_to_cpu(alt->endpoint[0].desc.wMaxPacketSize); /* If we don't have enough bandwidth use a lower framerate */ -- 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
