[GIT PATCHES FOR 3.3] mx2 emma-prp mem2mem driver
Hi Mauro, The following changes since commit 240ab508aa9fb7a294b0ecb563b19ead000b2463: Mauro Carvalho Chehab (1): [media] [PATCH] don't reset the delivery system on DTV_CLEAR are available in the git repository at: git://github.com/jmartinc/video_visstrim.git for_v3.3 Javier Martin (2): MEM2MEM: Add support for eMMa-PrP mem2mem operations. MX2: Add platform definitions for eMMa-PrP device. arch/arm/mach-imx/clock-imx27.c |2 +- arch/arm/mach-imx/devices-imx27.h |2 + arch/arm/plat-mxc/devices/platform-mx2-camera.c | 18 + arch/arm/plat-mxc/include/mach/devices-common.h |2 + drivers/media/video/Kconfig | 10 + drivers/media/video/Makefile|2 + drivers/media/video/mx2_emmaprp.c | 1008 +++ 7 files changed, 1043 insertions(+), 1 deletions(-) create mode 100644 drivers/media/video/mx2_emmaprp.c -- 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
Two devices, same USB ID: one needs HID, the other doesn't. How to solve this?
Hi! I've made a video4linux driver for the USB Keene FM Transmitter. See: http://www.amazon.co.uk/Keene-Electronics-USB-FM-Transmitter/dp/B003GCHPDY/ref=sr_1_1?ie=UTF8qid=1326450476sr=8-1 The driver code is here: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/keene Unfortunately this device has exactly the same USB ID as the Logitech AudioHub USB speaker (http://www.logitech.com/en-us/439/3503). The AudioHub has HID support for volume keys, but the FM transmitter needs a custom V4L2 driver instead. I've attached the full lsusb -v output of both devices, but this is the diff of the two: $ diff keene.txt audiohub.txt -u --- keene.txt 2012-01-13 11:10:48.265399953 +0100 +++ audiohub.txt2012-01-13 11:09:45.185398935 +0100 @@ -1,5 +1,5 @@ -Bus 007 Device 009: ID 046d:0a0e Logitech, Inc. +Bus 003 Device 004: ID 046d:0a0e Logitech, Inc. Device Descriptor: bLength18 bDescriptorType 1 @@ -12,7 +12,7 @@ idProduct 0x0a0e bcdDevice1.00 iManufacturer 1 HOLTEK - iProduct2 B-LINK USB Audio + iProduct2 AudioHub Speaker iSerial 0 bNumConfigurations 1 Configuration Descriptor: @@ -22,9 +22,8 @@ bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 -bmAttributes 0xa0 +bmAttributes 0x80 (Bus Powered) - Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 @@ -152,7 +151,7 @@ bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report - wDescriptorLength 22 + wDescriptorLength 31 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: As you can see, the differences are very small. In my git tree I worked around it by adding the USB ID to the ignore list if the Keene driver is enabled, and ensuring that the Keene driver is disabled by default. But is there a better method to do this? At least the iProduct strings are different, is that something that can be tested in hid-core.c? Regards, Hans Bus 003 Device 004: ID 046d:0a0e Logitech, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x046d Logitech, Inc. idProduct 0x0a0e bcdDevice1.00 iManufacturer 1 HOLTEK iProduct2 AudioHub Speaker iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 135 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 0 iInterface 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 40 bInCollection 1 baInterfaceNr( 0) 1 AudioControl Interface Descriptor: bLength12 bDescriptorType36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 1 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bNrChannels 2 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength10 bDescriptorType36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID13 bSourceID 1 bControlSize1 bmaControls( 0) 0x03 Mute Control Volume Control bmaControls( 1) 0x00 bmaControls( 2) 0x00 iFeature0 AudioControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 3 wTerminalType 0x0301 Speaker bAssocTerminal 0 bSourceID 13 iTerminal 0 Interface Descriptor:
Re: Problem with WinTV HVR-930C
Daniel, Didn't work for me either - had to use repository. Same kernel base version, but on gentoo though. // Fredrik On Thu, Jan 12, 2012 at 19:02, Daniel Rindt daniel.ri...@googlemail.com wrote: Hello, i am running Fedora 16 64bit and have no luck to get working the WinTV HVR-930C. Invoked command lsusb told me: Bus 001 Device 002: ID 2040:1605 Hauppauge. Installed from update-testing-repository is the most recent kernel version kernel-3.1.8-2.fc16.x86_64. Loaded the em28xx by hand and shows up this in dmesg: [ 482.220534] IR NEC protocol handler initialized [ 482.228352] IR RC5(x) protocol handler initialized [ 482.229710] Linux media interface: v0.10 [ 482.235907] Linux video capture interface: v2.00 [ 482.240601] IR RC6 protocol handler initialized [ 482.257921] IR JVC protocol handler initialized [ 482.263175] IR Sony protocol handler initialized [ 482.268460] IR MCE Keyboard/mouse protocol handler initialized [ 482.273807] usbcore: registered new interface driver em28xx [ 482.273816] em28xx driver loaded [ 482.275215] lirc_dev: IR Remote Control driver registered, major 249 [ 482.285327] IR LIRC bridge handler initialized I am in doubt that the newest development is included in this kernel release. Or maybe i have do something wrong. Your help is much appreciated. Thanks Daniel -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Two devices, same USB ID: one needs HID, the other doesn't. How to solve this?
Hans Verkuil hverk...@xs4all.nl wrote: Hi! I've made a video4linux driver for the USB Keene FM Transmitter. See: http://www.amazon.co.uk/Keene-Electronics-USB-FM-Transmitter/dp/B003GCHPDY/ref=sr_1_1?ie=UTF8qid=1326450476sr=8-1 The driver code is here: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/keene Unfortunately this device has exactly the same USB ID as the Logitech AudioHub USB speaker (http://www.logitech.com/en-us/439/3503). The AudioHub has HID support for volume keys, but the FM transmitter needs a custom V4L2 driver instead. I've attached the full lsusb -v output of both devices, but this is the diff of the two: $ diff keene.txt audiohub.txt -u --- keene.txt 2012-01-13 11:10:48.265399953 +0100 +++ audiohub.txt2012-01-13 11:09:45.185398935 +0100 @@ -1,5 +1,5 @@ -Bus 007 Device 009: ID 046d:0a0e Logitech, Inc. +Bus 003 Device 004: ID 046d:0a0e Logitech, Inc. Device Descriptor: bLength18 bDescriptorType 1 @@ -12,7 +12,7 @@ idProduct 0x0a0e bcdDevice1.00 iManufacturer 1 HOLTEK - iProduct2 B-LINK USB Audio + iProduct2 AudioHub Speaker iSerial 0 bNumConfigurations 1 Configuration Descriptor: @@ -22,9 +22,8 @@ bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 -bmAttributes 0xa0 +bmAttributes 0x80 (Bus Powered) - Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 @@ -152,7 +151,7 @@ bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report - wDescriptorLength 22 + wDescriptorLength 31 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: As you can see, the differences are very small. In my git tree I worked around it by adding the USB ID to the ignore list if the Keene driver is enabled, and ensuring that the Keene driver is disabled by default. But is there a better method to do this? At least the iProduct strings are different, is that something that can be tested in hid-core.c? Regards, Hans Maybe it doesn't matter, but what do the Report Descriptors look like? http://www.slashdev.ca/2010/05/08/get-usb-report-descriptor-with-linux/ 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: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)
Em 12-01-2012 14:22, Gianluca Gennari escreveu: Il 11/01/2012 20:19, Jim Darby ha scritto: On 11/01/12 01:05, Antti Palosaari wrote: [snip] Also latest LinuxTV.org devel could be interesting to see. There is one patch that changes em28xx driver endpoint configuration. But as that patch is going for 3.3 it should not be cause of issue, but I wonder if it could fix... Use media_build.git if possible. Well, I built the kernel and installed it. Sadly I get entries of the form: dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to delivery system 0 which isn't what I was looking for. I guess there's a new API? It would appear this is from the set frontend call. This is most annoying as I'd like to try out the newest code. Is there a v3 to v3 transition document anywhere? Best regards, Jim. -- 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 Hi Jim, you spotted a regression in the latest media_build release from 11/01/2012. I had the same problem here: dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to delivery system 0 with 3 totally different sticks (em28xx, dvb-usb, as102). Everything was working fine with media_build drivers from 08/01/2011, so the problem originates from a patch committed in the last few days. In fact, I reverted this patch: http://patchwork.linuxtv.org/patch/9443/ and Kaffeine started working again with all my DVB-T sticks. Hmm... this patch shouldn't be causing troubles for an application that only uses DVBv3 call. Is Kaffeine filling the DTV_DELIVERY_SYSTEM with SYS_UNDEFINED (0)? If so, then Kaffeine has a bug, as it is requesting a non-existent delivery system. Could you please turn on the dvb-core debug, and see if it is trying to do a DVBv5 call with DTV_DELIVERY_SYSTEM? Thanks, Mauro Best regards, Gianluca -- 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: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)
Il 13/01/2012 12:21, Mauro Carvalho Chehab ha scritto: Em 12-01-2012 14:22, Gianluca Gennari escreveu: Il 11/01/2012 20:19, Jim Darby ha scritto: On 11/01/12 01:05, Antti Palosaari wrote: [snip] Also latest LinuxTV.org devel could be interesting to see. There is one patch that changes em28xx driver endpoint configuration. But as that patch is going for 3.3 it should not be cause of issue, but I wonder if it could fix... Use media_build.git if possible. Well, I built the kernel and installed it. Sadly I get entries of the form: dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to delivery system 0 which isn't what I was looking for. I guess there's a new API? It would appear this is from the set frontend call. This is most annoying as I'd like to try out the newest code. Is there a v3 to v3 transition document anywhere? Best regards, Jim. -- 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 Hi Jim, you spotted a regression in the latest media_build release from 11/01/2012. I had the same problem here: dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to delivery system 0 with 3 totally different sticks (em28xx, dvb-usb, as102). Everything was working fine with media_build drivers from 08/01/2011, so the problem originates from a patch committed in the last few days. In fact, I reverted this patch: http://patchwork.linuxtv.org/patch/9443/ and Kaffeine started working again with all my DVB-T sticks. Hmm... this patch shouldn't be causing troubles for an application that only uses DVBv3 call. Is Kaffeine filling the DTV_DELIVERY_SYSTEM with SYS_UNDEFINED (0)? If so, then Kaffeine has a bug, as it is requesting a non-existent delivery system. Could you please turn on the dvb-core debug, and see if it is trying to do a DVBv5 call with DTV_DELIVERY_SYSTEM? Thanks, Mauro Best regards, Gianluca Hi Mauro, I don't think Kaffeine is (intentionally) messing up with the delivery system. But maybe the issue I've reported is related to this other one. Maybe you remember that I reported a problem on the xc2028 tuner that was reloading all the firmwares each time a new frequency is tuned. As a consequence, the time to switch to a new channel was much higher that usual. I tracked down the problem to the fact that the xc2028 is put in power-off mode and then immediately woken-up each time Kaffeine sets a new frequency. I investigated the issue a bit deeper (enabling debugging also in the dvb-core) and this is what I discovered: [ 1635.878002] dvb_frontend_release [ 1635.878029] xc2028 9-0061: Putting xc2028/3028 into poweroff mode. [ 1635.878041] dvb_frontend_open [ 1635.939253] dvb_frontend_start [ 1635.939326] dvb_frontend_thread [ 1635.939332] DVB: initialising adapter 0 frontend 0 (Zarlink ZL10353 DVB-T)... [ 1635.939504] dvb_frontend_ioctl (76) [ 1635.942896] set_delivery_system() Using delivery system to 3 So the frontend is released and then reinitialized each time a new frequency is tuned. This strange behavior was introduced with the conversion of drivers to the DVBv5 API; before, the frontend was initialized just one time. This happens with all drivers: I reproduced the same issue with a stick using the as102 driver (which is completely different from the em28xx-dvb driver). Here is the relevant part of the log: [ 2339.647230] dvb_frontend_release [ 2339.656954] dvb_frontend_open [ 2339.665675] dvb_frontend_start [ 2339.665872] dvb_frontend_thread [ 2339.665878] DVB: initialising adapter 0 frontend 0 (Sky IT Digital Key (green led))... [ 2339.666049] dvb_frontend_ioctl (76) [ 2339.666053] set_delivery_system() Using delivery system to 3 [ 2339.666057] dtv_property_cache_sync() Preparing OFDM req [ 2339.666060] dvb_frontend_add_event I'm attaching a longer log file with 2 consecutive channel switches for each of the 2 drivers. I have no idea if this is a bug in Kaffeine that is triggered by the new DVBv3 emulation logic, or a bug in the emulation logic itself. Best regards, Gianluca tune a new channel: [ 1635.878002] dvb_frontend_release [ 1635.878029] xc2028 9-0061: Putting xc2028/3028 into poweroff mode. [ 1635.878041] dvb_frontend_open [ 1635.939253] dvb_frontend_start [ 1635.939326] dvb_frontend_thread [ 1635.939332] DVB: initialising adapter 0 frontend 0 (Zarlink ZL10353 DVB-T)... [ 1635.939504] dvb_frontend_ioctl (76) [ 1635.942896] set_delivery_system() Using delivery system to 3 [ 1635.942901] dtv_property_cache_sync() Preparing OFDM req [ 1635.942905] dvb_frontend_add_event [ 1635.942922] dvb_frontend_swzigzag_autotune: drift:0 inversion:0 auto_step:0 auto_sub_step:0 started_auto_step:0 [ 1635.951507] xc2028 9-0061: xc2028_set_params called [ 1635.951513] xc2028 9-0061: generic_set_freq called [ 1635.951517] xc2028 9-0061: should set frequency 514000
re: V4L/DVB (12892): DVB-API: add support for ISDB-T and ISDB-Tsb (version 5.1)
Hello Patrick Boettcher, I know this patch is really old but I was hoping you still might be able to take a look at it. The patch b6e760f30975: V4L/DVB (12892): DVB-API: add support for ISDB-T and ISDB-Tsb (version 5.1) from Aug 3, 2009, leads to the following warning: drivers/media/dvb/dvb-core/dvb_frontend.c:993:9: warning: Initializer entry defined twice drivers/media/dvb/dvb-core/dvb_frontend.c:1012:9: also defined here The following two sections are basically cut and paste except that the ones in the first section were changed to zeros. The second set of initializers over writes the first, so probably we could just remove the first section? drivers/media/dvb/dvb-core/dvb_frontend.c + _DTV_CMD(DTV_ISDBT_PARTIAL_RECEPTION, 1, 0), + _DTV_CMD(DTV_ISDBT_SOUND_BROADCASTING, 1, 0), + _DTV_CMD(DTV_ISDBT_SB_SUBCHANNEL_ID, 1, 0), + _DTV_CMD(DTV_ISDBT_SB_SEGMENT_IDX, 1, 0), + _DTV_CMD(DTV_ISDBT_SB_SEGMENT_COUNT, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERA_FEC, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERA_MODULATION, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERA_SEGMENT_COUNT, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERA_TIME_INTERLEAVING, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERB_FEC, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERB_MODULATION, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERB_SEGMENT_COUNT, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERB_TIME_INTERLEAVING, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERC_FEC, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERC_MODULATION, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERC_SEGMENT_COUNT, 1, 0), + _DTV_CMD(DTV_ISDBT_LAYERC_TIME_INTERLEAVING, 1, 0), + + _DTV_CMD(DTV_ISDBT_PARTIAL_RECEPTION, 0, 0), + _DTV_CMD(DTV_ISDBT_SOUND_BROADCASTING, 0, 0), + _DTV_CMD(DTV_ISDBT_SB_SUBCHANNEL_ID, 0, 0), + _DTV_CMD(DTV_ISDBT_SB_SEGMENT_IDX, 0, 0), + _DTV_CMD(DTV_ISDBT_SB_SEGMENT_COUNT, 0, 0), + _DTV_CMD(DTV_ISDBT_LAYERA_FEC, 0, 0), + _DTV_CMD(DTV_ISDBT_LAYERA_MODULATION, 0, 0), + _DTV_CMD(DTV_ISDBT_LAYERA_SEGMENT_COUNT, 0, 0), + _DTV_CMD(DTV_ISDBT_LAYERA_TIME_INTERLEAVING, 0, 0), + _DTV_CMD(DTV_ISDBT_LAYERB_FEC, 0, 0), + _DTV_CMD(DTV_ISDBT_LAYERB_MODULATION, 0, 0), + _DTV_CMD(DTV_ISDBT_LAYERB_SEGMENT_COUNT, 0, 0), + _DTV_CMD(DTV_ISDBT_LAYERB_TIME_INTERLEAVING, 0, 0), + _DTV_CMD(DTV_ISDBT_LAYERC_FEC, 0, 0), + _DTV_CMD(DTV_ISDBT_LAYERC_MODULATION, 0, 0), + _DTV_CMD(DTV_ISDBT_LAYERC_SEGMENT_COUNT, 0, 0), + _DTV_CMD(DTV_ISDBT_LAYERC_TIME_INTERLEAVING, 0, 0), regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)
On 13/01/12 11:21, Mauro Carvalho Chehab wrote: Hmm... this patch shouldn't be causing troubles for an application that only uses DVBv3 call. Is Kaffeine filling the DTV_DELIVERY_SYSTEM with SYS_UNDEFINED (0)? I think this is perhaps where (some of) our problems are starting. I just looked at the kaffeine source code and, as far as I can make out, DTV_DELIVERY_SYSTEM is filled out by performing a FE_SET_PROPERTY ioctl with a key/value pair of something like DTV_DELIVERY_SYSTEM/SYS_DVBS2 (amongst other parameters). The issue here is that kaffeine *only* performs any sort of FE_SET_PROPERTY ioctl for DVB-S2. It certainly doesn't for any form of DVB-T (2 or original). It would therefore appear that kaffeine is committing a sin of omission in not setting the front-end properties and hence we have this problem. Mauro, if you can confirm that this is the case and that with the latest linux-media drivers performing the FE_SET_PROPERTY ioctl is mandatory then I can work with the kaffeine developers and get this fixed. For reference, the existing kaffeine works with the stock 3.2.0 kernel. It's just the linux-media from linux-tv.org that breaks it. Many thanks, Jim. -- 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: Two devices, same USB ID: one needs HID, the other doesn't. How to solve this?
On Friday, January 13, 2012 12:16:51 Andy Walls wrote: Hans Verkuil hverk...@xs4all.nl wrote: Hi! I've made a video4linux driver for the USB Keene FM Transmitter. See: http://www.amazon.co.uk/Keene-Electronics-USB-FM-Transmitter/dp/B003GCHPDY/ref=sr_1_1?ie=UTF8qid=1326450476sr=8-1 The driver code is here: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/keene Unfortunately this device has exactly the same USB ID as the Logitech AudioHub USB speaker (http://www.logitech.com/en-us/439/3503). The AudioHub has HID support for volume keys, but the FM transmitter needs a custom V4L2 driver instead. I've attached the full lsusb -v output of both devices, but this is the diff of the two: $ diff keene.txt audiohub.txt -u --- keene.txt 2012-01-13 11:10:48.265399953 +0100 +++ audiohub.txt2012-01-13 11:09:45.185398935 +0100 @@ -1,5 +1,5 @@ -Bus 007 Device 009: ID 046d:0a0e Logitech, Inc. +Bus 003 Device 004: ID 046d:0a0e Logitech, Inc. Device Descriptor: bLength18 bDescriptorType 1 @@ -12,7 +12,7 @@ idProduct 0x0a0e bcdDevice1.00 iManufacturer 1 HOLTEK - iProduct2 B-LINK USB Audio + iProduct2 AudioHub Speaker iSerial 0 bNumConfigurations 1 Configuration Descriptor: @@ -22,9 +22,8 @@ bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 -bmAttributes 0xa0 +bmAttributes 0x80 (Bus Powered) - Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 @@ -152,7 +151,7 @@ bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report - wDescriptorLength 22 + wDescriptorLength 31 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: As you can see, the differences are very small. In my git tree I worked around it by adding the USB ID to the ignore list if the Keene driver is enabled, and ensuring that the Keene driver is disabled by default. But is there a better method to do this? At least the iProduct strings are different, is that something that can be tested in hid-core.c? Regards, Hans Maybe it doesn't matter, but what do the Report Descriptors look like? http://www.slashdev.ca/2010/05/08/get-usb-report-descriptor-with-linux/ Attached the new lsusb outputs, this time with the report descriptor. Note that if I plug in the Keene transmitter, then no input device is created: Jan 13 14:25:12 tschai kernel: [ 1686.020166] usb 7-4: new full-speed USB device number 3 using ohci_hcd Jan 13 14:25:12 tschai kernel: [ 1686.248735] generic-usb 0003:046D:0A0E.0009: hiddev0,hidraw4: USB HID v1.10 Device [HOLTEK B-LINK USB Audio ] on usb-:00:16.0-4/input2 Compare that to what happens when the audiohub is plugged in: Jan 13 14:25:49 tschai kernel: [ 1722.820125] usb 3-4: new high-speed USB device number 6 using ehci_hcd Jan 13 14:25:49 tschai kernel: [ 1722.973529] hub 3-4:1.0: USB hub found Jan 13 14:25:49 tschai kernel: [ 1722.973960] hub 3-4:1.0: 4 ports detected Jan 13 14:25:49 tschai kernel: [ 1723.250629] usb 3-4.4: new full-speed USB device number 7 using ehci_hcd Jan 13 14:25:49 tschai kernel: [ 1723.390888] input: HOLTEK AudioHub Speaker as /devices/pci:00/:00:16.2/usb3/3-4/3-4.4/3-4.4:1.2/input/input12 Jan 13 14:25:49 tschai kernel: [ 1723.391176] generic-usb 0003:046D:0A0E.000A: input,hidraw4: USB HID v1.10 Device [HOLTEK AudioHub Speaker] on usb-:00:16.2-4.4/input2 I'm no expert on usb and HID, so I hope someone can point me to a better solution. Regards, Hans Bus 003 Device 004: ID 046d:0a0e Logitech, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x046d Logitech, Inc. idProduct 0x0a0e bcdDevice1.00 iManufacturer 1 HOLTEK iProduct2 AudioHub Speaker iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 135 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device
Re: Two devices, same USB ID: one needs HID, the other doesn't. How to solve this?
On 13.01.2012 12:42, Hans Verkuil wrote: Hi! Hi! Adding Jiri Kosina, the HID maintainer. I've made a video4linux driver for the USB Keene FM Transmitter. See: http://www.amazon.co.uk/Keene-Electronics-USB-FM-Transmitter/dp/B003GCHPDY/ref=sr_1_1?ie=UTF8qid=1326450476sr=8-1 The driver code is here: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/keene Unfortunately this device has exactly the same USB ID as the Logitech AudioHub USB speaker (http://www.logitech.com/en-us/439/3503). The AudioHub has HID support for volume keys, but the FM transmitter needs a custom V4L2 driver instead. I've attached the full lsusb -v output of both devices, but this is the diff of the two: $ diff keene.txt audiohub.txt -u [...] @@ -152,7 +151,7 @@ bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report - wDescriptorLength 22 + wDescriptorLength 31 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: As you can see, the differences are very small. The HID Report descriptors could be interesting as they differ. You can look at them in: /sys/kernel/debug/hid/*/rdesc I guess one option would be to make this a regular HID driver like those in drivers/hid/hid-*.c (and just set the v4l things up if the descriptor is as expected, otherwise let standard HID-input handle them), but there is the issue of where to place the driver, then, as it can't be both in drivers/hid and drivers/media... Probably the easy way out is to simply add the device into drivers/hid/hid-core.c:hid_ignore(), by checking e.g. vendor+product+name, and hope all B-LINK USB Audio devices are FM transmitters (the name suggests that may not necessarily be the case, though). Report descriptor contents are not available at hid_ignore() point yet. In my git tree I worked around it by adding the USB ID to the ignore list if the Keene driver is enabled, and ensuring that the Keene driver is disabled by default. But is there a better method to do this? At least the iProduct strings are different, is that something that can be tested in hid-core.c? Regards, Hans -- Anssi Hannula -- 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] [media] dvb-core: preserve the delivery system at cache clear
The changeset 240ab508aa is incomplete, as the first thing that
happens at cache clear is to do a memset with 0 to the cache.
So, the delivery system needs to be explicitly preserved there.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
If Kaffeine doesn't call FE_SET_PROPERTY for non-DVB-S2, this should
fix the current issue.
drivers/media/dvb/dvb-core/dvb_frontend.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 2ad7faf..f5fa7aa 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -904,8 +904,11 @@ static int dvb_frontend_clear_cache(struct dvb_frontend
*fe)
{
struct dtv_frontend_properties *c = fe-dtv_property_cache;
int i;
+ u32 delsys;
+ delsys = c-delivery_system;
memset(c, 0, sizeof(struct dtv_frontend_properties));
+ c-delivery_system = delsys;
c-state = DTV_CLEAR;
--
1.7.8
--
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: Two devices, same USB ID: one needs HID, the other doesn't. How to solve this?
On Friday, January 13, 2012 14:34:49 Anssi Hannula wrote: On 13.01.2012 12:42, Hans Verkuil wrote: Hi! Hi! Adding Jiri Kosina, the HID maintainer. I've made a video4linux driver for the USB Keene FM Transmitter. See: http://www.amazon.co.uk/Keene-Electronics-USB-FM-Transmitter/dp/B003GCHPDY/ref=sr_1_1?ie=UTF8qid=1326450476sr=8-1 The driver code is here: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/keene Unfortunately this device has exactly the same USB ID as the Logitech AudioHub USB speaker (http://www.logitech.com/en-us/439/3503). The AudioHub has HID support for volume keys, but the FM transmitter needs a custom V4L2 driver instead. I've attached the full lsusb -v output of both devices, but this is the diff of the two: $ diff keene.txt audiohub.txt -u [...] @@ -152,7 +151,7 @@ bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report - wDescriptorLength 22 + wDescriptorLength 31 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: As you can see, the differences are very small. The HID Report descriptors could be interesting as they differ. You can look at them in: /sys/kernel/debug/hid/*/rdesc I guess one option would be to make this a regular HID driver like those in drivers/hid/hid-*.c (and just set the v4l things up if the descriptor is as expected, otherwise let standard HID-input handle them), but there is the issue of where to place the driver, then, as it can't be both in drivers/hid and drivers/media... Probably the easy way out is to simply add the device into drivers/hid/hid-core.c:hid_ignore(), by checking e.g. vendor+product+name, and hope all B-LINK USB Audio devices are FM transmitters (the name suggests that may not necessarily be the case, though). Report descriptor contents are not available at hid_ignore() point yet. I've done this and this works fine. I googled for B-LINK USB Audio and found only references to the Keene transmitter. Here is my patch for drivers/hid that solves this issue: [RFC PATCH] hid-core: ignore the Keene FM transmitter. The Keene FM transmitter USB device has the same USB ID as the Logitech AudioHub Speaker, but it should ignore the hid. Check if the name is that of the Keene device. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/hid/hid-core.c | 10 ++ drivers/hid/hid-ids.h |1 + 2 files changed, 11 insertions(+), 0 deletions(-) diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index af35384..f02d197 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -1973,6 +1973,16 @@ static bool hid_ignore(struct hid_device *hdev) if (hdev-product = USB_DEVICE_ID_LOGITECH_HARMONY_FIRST hdev-product = USB_DEVICE_ID_LOGITECH_HARMONY_LAST) return true; + /* +* The Keene FM transmitter USB device has the same USB ID as +* the Logitech AudioHub Speaker, but it should ignore the hid. +* Check if the name is that of the Keene device. +* For reference: the name of the AudioHub is +* HOLTEK AudioHub Speaker. +*/ + if (hdev-product == USB_DEVICE_ID_LOGITECH_AUDIOHUB + !strcmp(hdev-name, HOLTEK B-LINK USB Audio )) + return true; break; case USB_VENDOR_ID_SOUNDGRAPH: if (hdev-product = USB_DEVICE_ID_SOUNDGRAPH_IMON_FIRST diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index 4a441a6..2f6dc92 100644 --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @@ -440,6 +440,7 @@ #define USB_DEVICE_ID_LG_MULTITOUCH0x0064 #define USB_VENDOR_ID_LOGITECH 0x046d +#define USB_DEVICE_ID_LOGITECH_AUDIOHUB 0x0a0e #define USB_DEVICE_ID_LOGITECH_RECEIVER0xc101 #define USB_DEVICE_ID_LOGITECH_HARMONY_FIRST 0xc110 #define USB_DEVICE_ID_LOGITECH_HARMONY_LAST 0xc14f -- 1.7.7.3 Comments? Or even better, an Acked-by? I'd like to get this driver in for v3.4, that would be nice. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)
Il 13/01/2012 14:09, Jim Darby ha scritto: On 13/01/12 11:21, Mauro Carvalho Chehab wrote: Hmm... this patch shouldn't be causing troubles for an application that only uses DVBv3 call. Is Kaffeine filling the DTV_DELIVERY_SYSTEM with SYS_UNDEFINED (0)? I think this is perhaps where (some of) our problems are starting. I just looked at the kaffeine source code and, as far as I can make out, DTV_DELIVERY_SYSTEM is filled out by performing a FE_SET_PROPERTY ioctl with a key/value pair of something like DTV_DELIVERY_SYSTEM/SYS_DVBS2 (amongst other parameters). The issue here is that kaffeine *only* performs any sort of FE_SET_PROPERTY ioctl for DVB-S2. It certainly doesn't for any form of DVB-T (2 or original). It would therefore appear that kaffeine is committing a sin of omission in not setting the front-end properties and hence we have this problem. Hi Jim, that's because Kaffeine is using the new DVBv5 API to interface with DVB-S2 hardware (as this is the only API supported), while it is using the old DVBv3 API to interface to DVB-T/C hardware. It's not a real problem, as in dvb-core there is some emulation logic that takes care of supporting DVBv3 applications. Mauro, if you can confirm that this is the case and that with the latest linux-media drivers performing the FE_SET_PROPERTY ioctl is mandatory then I can work with the kaffeine developers and get this fixed. For reference, the existing kaffeine works with the stock 3.2.0 kernel. It's just the linux-media from linux-tv.org that breaks it. Mauro already fixed the bug I reported. But if you can work with the Kaffeine developers to adopt DVBv5 API also for DVB-T/C tuners, it would be a nice contribution. Best regards, Gianluca -- 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 brightness to OmniVision 5621 sensor
This patch add brightness control to OmniVision 5621 sensor.
Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
Jose Alberto
diff -ur linux/drivers/media/video/gspca/ov534_9.c linux.new/drivers/media/video/gspca/ov534_9.c
--- linux/drivers/media/video/gspca/ov534_9.c 2012-01-07 05:45:50.0 +0100
+++ linux.new/drivers/media/video/gspca/ov534_9.c 2012-01-13 14:38:49.600419671 +0100
@@ -1107,16 +1107,34 @@
{
struct sd *sd = (struct sd *) gspca_dev;
u8 val;
+ s8 sval;
if (gspca_dev-ctrl_dis (1 BRIGHTNESS))
return;
- val = sd-ctrls[BRIGHTNESS].val;
- if (val 8)
- val = 15 - val; /* f .. 8 */
- else
- val = val - 8; /* 0 .. 7 */
- sccb_write(gspca_dev, 0x55, /* brtn - brightness adjustment */
- 0x0f | (val 4));
+ if (sd-sensor == SENSOR_OV562x) {
+ sval = sd-ctrls[BRIGHTNESS].val;
+ val = 0x76;
+ val += sval;
+ sccb_write(gspca_dev, 0x24, val);
+ val = 0x6a;
+ val += sval;
+ sccb_write(gspca_dev, 0x25, val);
+ if (sval -40)
+ val = 0x71;
+ else if (sval 20)
+ val = 0x94;
+ else
+ val = 0xe6;
+ sccb_write(gspca_dev, 0x26, val);
+ } else {
+ val = sd-ctrls[BRIGHTNESS].val;
+ if (val 8)
+ val = 15 - val; /* f .. 8 */
+ else
+ val = val - 8; /* 0 .. 7 */
+ sccb_write(gspca_dev, 0x55, /* brtn - brightness adjustment */
+0x0f | (val 4));
+ }
}
static void setcontrast(struct gspca_dev *gspca_dev)
@@ -1339,7 +1357,16 @@
reg_w(gspca_dev, 0x56, 0x17);
} else if ((sensor_id 0xfff0) == 0x5620) {
sd-sensor = SENSOR_OV562x;
-
+ gspca_dev-ctrl_dis = (1 CONTRAST) |
+ (1 AUTOGAIN) |
+ (1 EXPOSURE) |
+ (1 SHARPNESS) |
+ (1 SATUR) |
+ (1 LIGHTFREQ);
+
+ sd-ctrls[BRIGHTNESS].min = -90;
+ sd-ctrls[BRIGHTNESS].max = 90;
+ sd-ctrls[BRIGHTNESS].def = 0;
gspca_dev-cam.cam_mode = ov562x_mode;
gspca_dev-cam.nmodes = ARRAY_SIZE(ov562x_mode);
@@ -1360,8 +1387,12 @@
{
struct sd *sd = (struct sd *) gspca_dev;
- if (sd-sensor == SENSOR_OV971x || sd-sensor == SENSOR_OV562x)
+ if (sd-sensor == SENSOR_OV971x)
return gspca_dev-usb_err;
+ else if (sd-sensor == SENSOR_OV562x) {
+ setbrightness(gspca_dev);
+ return gspca_dev-usb_err;
+ }
switch (gspca_dev-curr_mode) {
case QVGA_MODE: /* 320x240 */
sccb_w_array(gspca_dev, ov965x_start_1_vga,
Re: [PATCH] [media] dvb-core: preserve the delivery system at cache clear
Il 13/01/2012 14:50, Mauro Carvalho Chehab ha scritto:
The changeset 240ab508aa is incomplete, as the first thing that
happens at cache clear is to do a memset with 0 to the cache.
So, the delivery system needs to be explicitly preserved there.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
If Kaffeine doesn't call FE_SET_PROPERTY for non-DVB-S2, this should
fix the current issue.
drivers/media/dvb/dvb-core/dvb_frontend.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 2ad7faf..f5fa7aa 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -904,8 +904,11 @@ static int dvb_frontend_clear_cache(struct dvb_frontend
*fe)
{
struct dtv_frontend_properties *c = fe-dtv_property_cache;
int i;
+ u32 delsys;
+ delsys = c-delivery_system;
memset(c, 0, sizeof(struct dtv_frontend_properties));
+ c-delivery_system = delsys;
c-state = DTV_CLEAR;
Hi Mauro,
I applied this new patch on top of the current media_build tree and I
can confirm that the issue with Kaffeine is solved.
All of my DVB-T sticks works fine again.
Best regards,
Gianluca
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR 3.3 v3] HDIC HD29L2 DMB-TH demodulator driver
Mauro, Apply that if possible :) regards Antti The following changes since commit 240ab508aa9fb7a294b0ecb563b19ead000b2463: [media] [PATCH] don't reset the delivery system on DTV_CLEAR (2012-01-10 23:44:07 -0200) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git hdic_v3 Antti Palosaari (1): revert patch: HDIC HD29L2 DMB-TH USB2.0 reference design driver drivers/media/dvb/dvb-usb/Kconfig |7 - drivers/media/dvb/dvb-usb/Makefile |3 - drivers/media/dvb/dvb-usb/hdic.c | 365 drivers/media/dvb/dvb-usb/hdic.h | 45 - 4 files changed, 0 insertions(+), 420 deletions(-) delete mode 100644 drivers/media/dvb/dvb-usb/hdic.c delete mode 100644 drivers/media/dvb/dvb-usb/hdic.h -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Fri Jan 13 19:00:23 CET 2012 git hash:240ab508aa9fb7a294b0ecb563b19ead000b2463 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2-rc1-x86_64: WARNINGS spec-git: WARNINGS 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 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] s5p-jpeg: adapt to recent videobuf2 changes
queue_setup callback has been extended with struct v4l2_format *fmt
parameter in 2d86401c2c commit. This patch adds this parameter to
s5p-jpeg driver.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Andrzej Pietrasiewicz andrze...@samsung.com
---
drivers/media/video/s5p-jpeg/jpeg-core.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/s5p-jpeg/jpeg-core.c
b/drivers/media/video/s5p-jpeg/jpeg-core.c
index f841a3e..1105a87 100644
--- a/drivers/media/video/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/video/s5p-jpeg/jpeg-core.c
@@ -989,9 +989,10 @@ static struct v4l2_m2m_ops s5p_jpeg_m2m_ops = {
*
*/
-static int s5p_jpeg_queue_setup(struct vb2_queue *vq, unsigned int *nbuffers,
- unsigned int *nplanes, unsigned int sizes[],
- void *alloc_ctxs[])
+static int s5p_jpeg_queue_setup(struct vb2_queue *vq,
+ const struct v4l2_format *fmt,
+ unsigned int *nbuffers, unsigned int *nplanes,
+ unsigned int sizes[], void *alloc_ctxs[])
{
struct s5p_jpeg_ctx *ctx = vb2_get_drv_priv(vq);
struct s5p_jpeg_q_data *q_data = NULL;
--
1.7.1.569.g6f426
--
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 04/11] mm: page_alloc: introduce alloc_contig_range()
On Thu, Dec 29, 2011 at 01:39:05PM +0100, Marek Szyprowski wrote:
From: Michal Nazarewicz min...@mina86.com
+ /* Make sure all pages are isolated. */
+ if (!ret) {
+ lru_add_drain_all();
+ drain_all_pages();
+ if (WARN_ON(test_pages_isolated(start, end)))
+ ret = -EBUSY;
+ }
On Tue, 10 Jan 2012 15:16:13 +0100, Mel Gorman m...@csn.ul.ie wrote:
Another global IPI seems overkill. Drain pages only from the local CPU
(drain_pages(get_cpu()); put_cpu()) and test if the pages are isolated.
Is get_cpu() + put_cpu() required? Won't drain_local_pages() work?
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--
--
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 v2 6/8] media: v4l2: introduce two IOCTLs for object detection
Hi Ming,
sorry for the late response. It's all looking better now, however there
is still a few things that could be improved.
On 12/14/2011 03:00 PM, Ming Lei wrote:
This patch introduces two new IOCTLs and related data
structure which will be used by the coming video device
with object detect capability.
The two IOCTLs and related data structure will be used by
user space application to retrieve the results of object
detection.
The utility fdif[1] is useing the two IOCTLs to find
objects(faces) deteced in raw images or video streams.
[1],http://kernel.ubuntu.com/git?p=ming/fdif.git;a=shortlog;h=refs/heads/v4l2-fdif
Signed-off-by: Ming Leiming@canonical.com
---
v2:
- extend face detection API to object detection API
- introduce capability of V4L2_CAP_OBJ_DETECTION for object detection
- 32/64 safe array parameter
---
drivers/media/video/v4l2-ioctl.c | 41 -
include/linux/videodev2.h| 124
++
include/media/v4l2-ioctl.h |6 ++
3 files changed, 170 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c
index ded8b72..575d445 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -2140,6 +2140,30 @@ static long __video_do_ioctl(struct file *file,
dbgarg(cmd, index=%d, b-index);
break;
}
+ case VIDIOC_G_OD_RESULT:
+ {
+ struct v4l2_od_result *or = arg;
+
+ if (!ops-vidioc_g_od_result)
+ break;
+
+ ret = ops-vidioc_g_od_result(file, fh, or);
+
+ dbgarg(cmd, index=%d, or-frm_seq);
+ break;
+ }
+ case VIDIOC_G_OD_COUNT:
+ {
+ struct v4l2_od_count *oc = arg;
+
+ if (!ops-vidioc_g_od_count)
+ break;
+
+ ret = ops-vidioc_g_od_count(file, fh, oc);
+
+ dbgarg(cmd, index=%d, oc-frm_seq);
+ break;
+ }
I'm uncertain if we need this ioctl at all. Now struct v4l2_od_result is:
struct v4l2_od_result {
__u32 frame_sequence;
__u32 object_count;
__u32 reserved[6];
struct v4l2_od_object objects[0];
};
and
struct v4l2_od_object {
__u16 type;
__u16 confidence;
union {
struct v4l2_od_face_desc face;
struct v4l2_od_eye_desc eye;
struct v4l2_od_mouth_desc mouth;
__u8rawdata[60];
} o;
};
If we had added a 'size' field to struct v4l2_od_result, i.e.
struct v4l2_od_result {
__u32 size;
__u32 frame_sequence;
__u32 objects_count;
__u32 reserved[5];
struct v4l2_od_object objects[0];
};
the application could have allocated memory for the objects array and
have the 'size' member set to the size of that allocation. Then it
would have called VIDIOC_G_OD_RESULT and the driver would have filled
the 'objects' array, if it was big enough for the requested result
data. The driver would also update the 'objects_count'. If the size
would be too small to fit the result data, i.e.
size number_of_detected_objects * sizeof(struct v4l2_od_object)
the driver could return -ENOSPC error while also setting 'size' to
the required value. Something similar is done with
VIDIOC_G_EXT_CTRLS ioctl [3].
There is one more OD API requirement, for camera sensors with embedded
SoC ISP that support face detection, i.e. VIDIOC_G_OD_RESULT should
allow to retrieve face detection result for the very last image frame,
i.e. current frame.
One solution to support this could be adding a 'flags' field, i.e.
struct v4l2_od_result {
__u32 size;
__u32 flags;
__u32 frame_sequence;
__u32 objects_count;
__u16 group_index;
__u16 group_count;
__u16 reserved[7];
struct v4l2_od_object objects[0];
};
and additionally group_index to specify which face object the user is
interested in. I'm not saying we have to implement this now but it's
good to consider beforehand. The group_count would be used to return
the number of detected faces. What do you think ?
/* flags */
#define V4L2_OD_FL_SEL_FRAME_SEQ(0 0)
#define V4L2_OD_FL_SEL_FRAME_LAST (1 0)
#define V4L2_OD_FL_SEL_GROUP(1 1)
Or maybe we should just use face_ instead of group_ ?
default:
if (!ops-vidioc_default)
break;
@@ -2241,7 +2265,22 @@ static int check_array_args(unsigned int cmd, void
*parg, size_t *array_size,
static int is_64_32_array_args(unsigned
Re: [RFC PATCH 1/4] v4l: Add V4L2_CID_PRESET_WHITE_BALANCE menu control
On 01/11/2012 11:36 PM, Sakari Ailus wrote: This is what the spec says: This is an action control. When set (the value is ignored), the device will do a white balance and then hold the current setting. Contrast this with the boolean V4L2_CID_AUTO_WHITE_BALANCE, which, when activated, keeps adjusting the white balance. I wonder if that should be then changed --- or is it just me who got a different idea from the above description? Only you ? :-) Same as Laurent, I understood this control can be used to do white balance after pointing camera to a white object. Not sure if the description needs to be changed. Definitely it needs to be changed. Who will submit the patch? :-) If it really bugs you, feel free to send a patch :) Or I'll do it, but only after I handle all other pending controls from my to-do list. Cheers, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] dvb-core: preserve the delivery system at cache clear
Thanks for the patch Mauro. According to Gianluca that solves the backwards compatibility issue. This is great news. In other news I've tried a few experiments. Firstly I tried using a 3.2.0 unmodified straight out of the box kernel on my Core 2 64-bit system. I was unable to produce any faults. This would tend to lead one to suspect that it's a 32-bit problem or that my 32-bit machine is a bit flaky or slow. So, as I wanted to try the new alpha 3 for Mageia 2 (a Mandriva fork) out and it has a 3.0 kernel that seemed to be a good idea. The bad news is that I'd run out of hardware. So I thought I'd be clever and run it as a virtual machine on my Core 2 system. The good news is that it correctly recognised the stick and it seemed to work for standard definition. However, after setting it to record some HDTV programmes it failed. More importantly it failed in the same way as the 32-bit system. This makes me think it's some kind of timing problem. The USB passthrough of VirtualBox may well not operate at the performance required for HDTV. Also by this time I'd put the stick on a USB extension lead which may have adversely affected the power feed. For my next series of tests I plan to run it again on bare hardware. I'm going to try and use my older Core 2 machine which should have the CPU and electrical power. None of which explains why it works on the 32-bit Athlon XP 2200+ when it's running 3.0.0 though. And has done so reliably for some time. Maybe some other things are happening in the kernel that much up the device timing or something. Anyway, I'll keep people posted as to the progression of the testing. Best regards, Jim. -- 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
