Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
On Thu, Jun 23, 2011 at 06:08:03PM +0200, Geert Uytterhoeven wrote: On Wed, Jun 22, 2011 at 07:45, Florian Tobias Schandinat florianschandi...@gmx.de wrote: On 06/21/2011 10:31 PM, Laurent Pinchart wrote: On Tuesday 21 June 2011 22:49:14 Geert Uytterhoeven wrote: As FOURCC values are always 4 ASCII characters (hence all 4 bytes must be non-zero), I don't think there are any conflicts with existing values of nonstd. To make it even safer and easier to parse, you could set bit 31 of nonstd as a FOURCC indicator. I would then create a union between nonstd and fourcc, and document nonstd as being used for the legacy API only. Most existing drivers use a couple of nonstd bits only. The driver that (ab)uses nonstd the most is pxafb and uses bits 22:0. Bits 31:24 are never used as far as I can tell, so nonstd 0xff00 != 0 could be used as a FOURCC mode test. This assumes that FOURCCs will never have their last character set to '\0'. Is that a safe assumption for the future ? Yes, I think. The information I found indicates that space should be used for padding, so a \0 shouldn't exist. I think using only the nonstd field and requiring applications to check the capabilities would be possible, although not fool proof ;) So we can declare the 8 msb bits of nonstd reserved, and assume FOURCC if any of them is set. Nicely backwards compatible, as sane drivers should reject nonstd values they don't support (apps _will_ start filling in FOURCC values ignoring capabilities, won't they?). That seems like a reasonable case, but if we're going to do that then certainly the nonstd bit encoding needs to be documented and treated as a hard ABI. I'm not so sure about the if any bit in the upper byte is set assume FOURCC case though, there will presumably be other users in the future that will want bits for themselves, too. What exactly was the issue with having a FOURCC capability bit in the upper byte? -- 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] SOUND: Fix non-ISA_DMA_API build failure
At Thu, 23 Jun 2011 15:47:50 +0100, Ralf Baechle wrote: A build with ISA ISA_DMA !ISA_DMA_API results in: CC sound/isa/es18xx.o sound/isa/es18xx.c: In function ‘snd_es18xx_playback1_prepare’: sound/isa/es18xx.c:501:9: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/es18xx.c: In function ‘snd_es18xx_playback_pointer’: sound/isa/es18xx.c:818:3: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[2]: *** [sound/isa/es18xx.o] Error 1 CC sound/isa/sscape.o sound/isa/sscape.c: In function ‘upload_dma_data’: sound/isa/sscape.c:481:3: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[2]: *** [sound/isa/sscape.o] Error 1 CC sound/isa/ad1816a/ad1816a_lib.o sound/isa/ad1816a/ad1816a_lib.c: In function ‘snd_ad1816a_playback_prepare’: sound/isa/ad1816a/ad1816a_lib.c:244:2: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/ad1816a/ad1816a_lib.c: In function ‘snd_ad1816a_playback_pointer’: sound/isa/ad1816a/ad1816a_lib.c:302:2: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] sound/isa/ad1816a/ad1816a_lib.c: In function ‘snd_ad1816a_free’: sound/isa/ad1816a/ad1816a_lib.c:544:3: error: implicit declaration of function ‘snd_dma_disable’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/ad1816a/ad1816a_lib.o] Error 1 make[3]: Target `__build' not remade because of errors. make[2]: *** [sound/isa/ad1816a] Error 2 CC sound/isa/es1688/es1688_lib.o sound/isa/es1688/es1688_lib.c: In function ‘snd_es1688_playback_prepare’: sound/isa/es1688/es1688_lib.c:417:2: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/es1688/es1688_lib.c: In function ‘snd_es1688_playback_pointer’: sound/isa/es1688/es1688_lib.c:509:2: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/es1688/es1688_lib.o] Error 1 make[3]: Target `__build' not remade because of errors. make[2]: *** [sound/isa/es1688] Error 2 CC sound/isa/gus/gus_dma.o sound/isa/gus/gus_dma.c: In function ‘snd_gf1_dma_program’: sound/isa/gus/gus_dma.c:79:2: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/gus/gus_dma.c: In function ‘snd_gf1_dma_done’: sound/isa/gus/gus_dma.c:177:3: error: implicit declaration of function ‘snd_dma_disable’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/gus/gus_dma.o] Error 1 CC sound/isa/gus/gus_pcm.o sound/isa/gus/gus_pcm.c: In function ‘snd_gf1_pcm_capture_prepare’: sound/isa/gus/gus_pcm.c:591:2: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/gus/gus_pcm.c: In function ‘snd_gf1_pcm_capture_pointer’: sound/isa/gus/gus_pcm.c:619:2: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/gus/gus_pcm.o] Error 1 make[3]: Target `__build' not remade because of errors. make[2]: *** [sound/isa/gus] Error 2 CC sound/isa/sb/sb16_csp.o sound/isa/sb/sb16_csp.c: In function ‘snd_sb_csp_ioctl’: sound/isa/sb/sb16_csp.c:228:227: error: case label does not reduce to an integer constant make[3]: *** [sound/isa/sb/sb16_csp.o] Error 1 CC sound/isa/sb/sb16_main.o sound/isa/sb/sb16_main.c: In function ‘snd_sb16_playback_prepare’: sound/isa/sb/sb16_main.c:276:2: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/sb/sb16_main.c: In function ‘snd_sb16_playback_pointer’: sound/isa/sb/sb16_main.c:456:2: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/sb/sb16_main.o] Error 1 CC sound/isa/sb/sb8_main.o sound/isa/sb/sb8_main.c: In function ‘snd_sb8_playback_prepare’: sound/isa/sb/sb8_main.c:172:3: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/sb/sb8_main.c: In function ‘snd_sb8_playback_pointer’: sound/isa/sb/sb8_main.c:425:2: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/sb/sb8_main.o] Error 1 make[3]: Target `__build' not remade because of errors. make[2]: *** [sound/isa/sb] Error 2 CC
Re: [PATCH 12/37] Remove unneeded version.h includes (and add where needed) for drivers/media/video/
Hi Jesper,
On Friday 24 June 2011 00:17:01 Jesper Juhl wrote:
It was pointed out by 'make versioncheck' that linux/version.h was not
always being included where needed and sometimes included needlessly
in drivers/media/video/.
This patch fixes up the includes.
Signed-off-by: Jesper Juhl j...@chaosbits.net
[snip]
diff --git a/drivers/media/video/uvc/uvc_v4l2.c
b/drivers/media/video/uvc/uvc_v4l2.c index 543a803..7fbd389 100644
--- a/drivers/media/video/uvc/uvc_v4l2.c
+++ b/drivers/media/video/uvc/uvc_v4l2.c
@@ -12,7 +12,6 @@
*/
#include linux/kernel.h
-#include linux/version.h
#include linux/list.h
#include linux/module.h
#include linux/slab.h
uvc_v4l2.c uses KERNEL_VERSION explicitly. It includes linux/version.h through
linux/media.h, but I'd rather keep the explicit include.
diff --git a/drivers/media/video/uvc/uvcvideo.h
b/drivers/media/video/uvc/uvcvideo.h index 20107fd..1c0fe5e 100644
--- a/drivers/media/video/uvc/uvcvideo.h
+++ b/drivers/media/video/uvc/uvcvideo.h
@@ -101,6 +101,7 @@ struct uvc_xu_control {
#include linux/usb.h
#include linux/usb/video.h
#include linux/uvcvideo.h
+#include linux/version.h
#include media/media-device.h
#include media/v4l2-device.h
This file doesn't include linux/version.h anymore in 3.0-rc4.
--
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
dib0700 hangs when usb receiver is unplugged while watching TV
Hi All, I have the PCTV nanostick solo. This works perfectly, but when I pull out the stick while i'm watching TV, the driver crashes. When I replug the stick, there's no reaction in dmesg. To reproduce: 1)plugin the stick 1a)scan channels with scan, see also https://wiki.archlinux.org/index.php/Digitenne#Configure_Sasc-ng 2)use tzap, cat and mplayer to watch TV 3)unplug the stick 4)watch the fireworks in /var/log/everything.log (dmesg) See below for details. I run the following kernel: Linux cedric 2.6.39-ARCH #1 SMP PREEMPT Mon Jun 6 22:37:55 CEST 2011 x86_64 Intel(R) Core(TM)2 Duo CPU T5670 @ 1.80GHz GenuineIntel GNU/Linux Best regards, Cedric 1)plugin the stick. This yields the following messages in dmesg: [75262.399219] usb 2-4: new high speed USB device number 4 using ehci_hcd [75263.442900] IR NEC protocol handler initialized [75263.585643] dib0700: loaded with support for 20 different device-types [75263.586003] dvb-usb: found a 'Pinnacle PCTV 73e SE' in cold state, will try to load a firmware [75263.600941] IR RC5(x) protocol handler initialized [75263.626257] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' [75263.626871] IR RC6 protocol handler initialized [75263.825852] IR JVC protocol handler initialized [75263.830658] IR Sony protocol handler initialized [75263.841488] dib0700: firmware started successfully. [75264.121550] lirc_dev: IR Remote Control driver registered, major 250 [75264.123092] IR LIRC bridge handler initialized [75264.342633] dvb-usb: found a 'Pinnacle PCTV 73e SE' in warm state. [75264.342716] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [75264.342896] DVB: registering new adapter (Pinnacle PCTV 73e SE) [75264.545372] DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)... [75264.746115] DiB0070: successfully identified [75264.945842] Registered IR keymap rc-dib0700-rc5 [75264.946120] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb2/2-4/rc/rc0/input16 [75264.946234] rc0: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb2/2-4/rc/rc0 [75264.946443] dvb-usb: schedule remote query interval to 50 msecs. [75264.946447] dvb-usb: Pinnacle PCTV 73e SE successfully initialized and connected. [75264.946856] usbcore: registered new interface driver dvb_usb_dib0700 2) Use tzap, cat and mplayer to watch Nederland 1: $ tzap -a 0 -r 'Nederland 1' $ cat /dev/dvb/adapter0/dvr0 test.ts $ mplayer test.ts 3) Pull out the stick. This yields the following messages in dmesg: [77043.886483] usb 2-4: USB disconnect, device number 4 Now the kernel does no longer respond when I replug the stick. After 2 minutes, the following messages show up in dmesg: [77280.502349] INFO: task khubd:361 blocked for more than 120 seconds. [77280.502354] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [77280.502359] khubd D 0001015f4e25 0 361 2 0x [77280.502367] 880075bffbb0 0046 0001015f4e25 8ff4ed27 [77280.502375] 880075bffac0 880070bbff00 880075bfffd8 88007af5dbd0 [77280.502382] 880075bfffd8 880075bfffd8 880037f6dbd0 88007af5dbd0 [77280.502390] Call Trace: [77280.502403] [810559e0] ? try_to_wake_up+0x380/0x380 [77280.502410] [813e56dd] ? wait_for_completion+0x1d/0x20 [77280.502425] [a027cdd5] dvb_unregister_frontend+0xc5/0x110 [dvb_core] [77280.502432] [8107e050] ? abort_exclusive_wait+0xb0/0xb0 [77280.502440] [a0188592] dvb_usb_adapter_frontend_exit+0x22/0x40 [dvb_usb] [77280.502446] [a01874ac] dvb_usb_exit+0x4c/0xd0 [dvb_usb] [77280.502453] [a0187582] dvb_usb_device_exit+0x52/0x70 [dvb_usb] [77280.502474] [a02ead12] usb_unbind_interface+0x52/0x180 [usbcore] [77280.502483] [812e0515] __device_release_driver+0x75/0xe0 [77280.502493] [812e05ac] device_release_driver+0x2c/0x40 [77280.502497] [812e0058] bus_remove_device+0x78/0xb0 [77280.502501] [812dd91a] device_del+0x13a/0x1d0 [77280.502508] [a02e8ae4] usb_disable_device+0x74/0x130 [usbcore] [77280.502515] [a02e117c] usb_disconnect+0x8c/0x120 [usbcore] [77280.502522] [a02e2f4c] hub_thread+0x9fc/0x1220 [usbcore] [77280.502526] [8107e050] ? abort_exclusive_wait+0xb0/0xb0 [77280.502532] [a02e2550] ? usb_remote_wakeup+0x40/0x40 [usbcore] [77280.502536] [8107d6fc] kthread+0x8c/0xa0 [77280.502540] [813eac64] kernel_thread_helper+0x4/0x10 [77280.502544] [8107d670] ? kthread_worker_fn+0x190/0x190 [77280.502547] [813eac60] ? gs_change+0x13/0x13 [77400.502398] INFO: task khubd:361 blocked for more than 120 seconds. [77400.502403] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [77400.502407] khubd D 0001015f4e25 0 361 2 0x [77400.502416] 880075bffbb0 0046 0001015f4e25 8ff4ed27 [77400.502424] 880075bffac0 880070bbff00
dib0700 hangs when usb receiver is unplugged while watching TV
Hi All, I have the PCTV nanostick solo. This works perfectly, but when I pull out the stick while i'm watching TV, the driver crashes. When I replug the stick, there's no reaction in dmesg. To reproduce: 1)plugin the stick 1a)scan channels with scan, see also https://wiki.archlinux.org/index.php/Digitenne#Configure_Sasc-ng 2)use tzap, cat and mplayer to watch TV 3)unplug the stick 4)watch the fireworks in /var/log/everything.log (dmesg) See below for details. I run the following kernel: Linux cedric 2.6.39-ARCH #1 SMP PREEMPT Mon Jun 6 22:37:55 CEST 2011 x86_64 Intel(R) Core(TM)2 Duo CPU T5670 @ 1.80GHz GenuineIntel GNU/Linux Best regards, Cedric 1)plugin the stick. This yields the following messages in dmesg: [75262.399219] usb 2-4: new high speed USB device number 4 using ehci_hcd [75263.442900] IR NEC protocol handler initialized [75263.585643] dib0700: loaded with support for 20 different device-types [75263.586003] dvb-usb: found a 'Pinnacle PCTV 73e SE' in cold state, will try to load a firmware [75263.600941] IR RC5(x) protocol handler initialized [75263.626257] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' [75263.626871] IR RC6 protocol handler initialized [75263.825852] IR JVC protocol handler initialized [75263.830658] IR Sony protocol handler initialized [75263.841488] dib0700: firmware started successfully. [75264.121550] lirc_dev: IR Remote Control driver registered, major 250 [75264.123092] IR LIRC bridge handler initialized [75264.342633] dvb-usb: found a 'Pinnacle PCTV 73e SE' in warm state. [75264.342716] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [75264.342896] DVB: registering new adapter (Pinnacle PCTV 73e SE) [75264.545372] DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)... [75264.746115] DiB0070: successfully identified [75264.945842] Registered IR keymap rc-dib0700-rc5 [75264.946120] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb2/2-4/rc/rc0/input16 [75264.946234] rc0: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb2/2-4/rc/rc0 [75264.946443] dvb-usb: schedule remote query interval to 50 msecs. [75264.946447] dvb-usb: Pinnacle PCTV 73e SE successfully initialized and connected. [75264.946856] usbcore: registered new interface driver dvb_usb_dib0700 2) Use tzap, cat and mplayer to watch Nederland 1: $ tzap -a 0 -r 'Nederland 1' $ cat /dev/dvb/adapter0/dvr0 test.ts $ mplayer test.ts 3) Pull out the stick. This yields the following messages in dmesg: [77043.886483] usb 2-4: USB disconnect, device number 4 Now the kernel does no longer respond when I replug the stick. After 2 minutes, the following messages show up in dmesg: [77280.502349] INFO: task khubd:361 blocked for more than 120 seconds. [77280.502354] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [77280.502359] khubd D 0001015f4e25 0 361 2 0x [77280.502367] 880075bffbb0 0046 0001015f4e25 8ff4ed27 [77280.502375] 880075bffac0 880070bbff00 880075bfffd8 88007af5dbd0 [77280.502382] 880075bfffd8 880075bfffd8 880037f6dbd0 88007af5dbd0 [77280.502390] Call Trace: [77280.502403] [810559e0] ? try_to_wake_up+0x380/0x380 [77280.502410] [813e56dd] ? wait_for_completion+0x1d/0x20 [77280.502425] [a027cdd5] dvb_unregister_frontend+0xc5/0x110 [dvb_core] [77280.502432] [8107e050] ? abort_exclusive_wait+0xb0/0xb0 [77280.502440] [a0188592] dvb_usb_adapter_frontend_exit+0x22/0x40 [dvb_usb] [77280.502446] [a01874ac] dvb_usb_exit+0x4c/0xd0 [dvb_usb] [77280.502453] [a0187582] dvb_usb_device_exit+0x52/0x70 [dvb_usb] [77280.502474] [a02ead12] usb_unbind_interface+0x52/0x180 [usbcore] [77280.502483] [812e0515] __device_release_driver+0x75/0xe0 [77280.502493] [812e05ac] device_release_driver+0x2c/0x40 [77280.502497] [812e0058] bus_remove_device+0x78/0xb0 [77280.502501] [812dd91a] device_del+0x13a/0x1d0 [77280.502508] [a02e8ae4] usb_disable_device+0x74/0x130 [usbcore] [77280.502515] [a02e117c] usb_disconnect+0x8c/0x120 [usbcore] [77280.502522] [a02e2f4c] hub_thread+0x9fc/0x1220 [usbcore] [77280.502526] [8107e050] ? abort_exclusive_wait+0xb0/0xb0 [77280.502532] [a02e2550] ? usb_remote_wakeup+0x40/0x40 [usbcore] [77280.502536] [8107d6fc] kthread+0x8c/0xa0 [77280.502540] [813eac64] kernel_thread_helper+0x4/0x10 [77280.502544] [8107d670] ? kthread_worker_fn+0x190/0x190 [77280.502547] [813eac60] ? gs_change+0x13/0x13 [77400.502398] INFO: task khubd:361 blocked for more than 120 seconds. [77400.502403] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [77400.502407] khubd D 0001015f4e25 0 361 2 0x [77400.502416] 880075bffbb0 0046 0001015f4e25 8ff4ed27 [77400.502424] 880075bffac0 880070bbff00
Re: [DVB] Octopus driver status
Hi, On Thursday 23 June 2011 23:31:08 Sébastien RAILLARD wrote: Dear all, I'm looking at the Octopus DVB cards system from Digital Devices for a while as their system seems to be very interesting Here is link with their products: http://shop.digital-devices.de/epages/62357162.sf/en_GB/?ObjectPath=/Shops/6 2357162/Categories The good points I have found: * They support most of the common DVB standards: DVB-C, DVB-T, DVB-S and DVB-S2 * They are moderately priced * There is a CAM support with a CI adapter for unscrambling channels * They are using the now de-facto standard PCI-Express bus * The new Octopus system is using a LATTICE PCI-Express bridge that seems to be more future proof than the previous bridge Micronas APB7202A * They seem to be well engineered (Designed and manufactured in Germany as they say!) And now the doubts : * The DVB-C/T frontend driver is specific to this system and is very new, so as Devin said one week ago, it's maybe not yet production ready * The way the CAM is supported break all the existing userland DVB applications (gnutv, mumudvb, vlc, etc.) * There isn't so much information about the Digital Devices company and their products roadmap (at least in English) So, my two very simple questions to the developers who worked on the drivers (I think Oliver and Ralph did) and know the product: * How you feel the future about the Octopus driver? The drivers work fine. I am not aware of any problems. All Digital Devices cards and tuner variants are supported by the driver http://linuxtv.org/hg/~endriss/media_build_experimental ddbridge (Lattice bridge): - Octopus (all variants) - cineS2 v6 - DuoFlex S2 (stv0900 + stv6110 + lnbp21) - DuoFlex C/T (Micronas DRXK + NXP TDA18271C2) ngene bridge: - cineS2 (v4,v5), Satix S2 Dual - PCIe bridge, mini PCIe bridge - DuoFlex S2 (stv0900 + stv6110 + lnbp21) - DuoFlex C/T (Micronas DRXK + NXP TDA18271C2) For a German description, see http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/105803-aktuelle-treiber-für-octopus-ddbridge-cines2-ngene-ddbridge-duoflex-s2-duoflex-ct-sowie-tt-s2-6400 From an operational point of view, the driver is ready for the kernel. Unfortunately I did not have the time yet to clean up the coding-style. There are thousands of coding-style issues waiting to be fixed... * Do you think a compatibility mode (like module parameter) can be added to simulate the way the CAM is handled in the other drivers? Yes, this could be done: ++ The CI could be used with any application. -- The CI will be attached to one tuner exclusively. It is not very hard to implement this. Patches are welcome. ;-) CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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 v3] V4L: add media bus configuration subdev operations
On Thursday, June 23, 2011 23:53:11 Guennadi Liakhovetski wrote:
Add media bus configuration types and two subdev operations to get
supported mediabus configurations and to set a specific configuration.
Subdevs can support several configurations, e.g., they can send video data
on 1 or several lanes, can be configured to use a specific CSI-2 channel,
in such cases subdevice drivers return bitmasks with all respective bits
set. When a set-configuration operation is called, it has to specify a
non-ambiguous configuration.
Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v3: addressed comments by Hans - thanks!
1. moved too big inline function into a new .c file
2. changed flags types to int, local variables to bool, added const
3. accepting BT.656 now too
v2:
1. Removed parallel bus width flags. As Laurent correctly pointed out, bus
width can be configured based on the mediabus format.
2. Removed the clock parameter for now. Passing timing information between
the subdevices and the host / bridge driver is indeed necessary, but it is
not yet quite clear, what is the best way to do this. This requires more
thinking and can be added as an extra field to struct v4l2_mbus_config
later. The argument, that struct clk is still platform specific is
correct, but I am too tempted by the possibilities, the clkdev offers us
to give up this idea immediatrely. Maybe drivers, that need such a clock,
could use a platform callback to create a clock instance for them, or get
a clock object from the platform with platform data. However, there are
also opinions, that the clkdev API is completely unsuitable for this
purpose. I'd commit this without any timing first, and consider
possibilities as a second step.
drivers/media/video/Makefile|2 +-
drivers/media/video/v4l2-mediabus.c | 45 ++
include/media/v4l2-mediabus.h | 59
+++
include/media/v4l2-subdev.h |8 +
4 files changed, 113 insertions(+), 1 deletions(-)
create mode 100644 drivers/media/video/v4l2-mediabus.c
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index d9833f4..7adb683 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -11,7 +11,7 @@ stkwebcam-objs := stk-webcam.o stk-sensor.o
omap2cam-objs:= omap24xxcam.o omap24xxcam-dma.o
videodev-objs:= v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o
\
- v4l2-event.o v4l2-ctrls.o v4l2-subdev.o
+ v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-mediabus.o
# V4L2 core modules
diff --git a/drivers/media/video/v4l2-mediabus.c
b/drivers/media/video/v4l2-mediabus.c
new file mode 100644
index 000..c181e02
--- /dev/null
+++ b/drivers/media/video/v4l2-mediabus.c
@@ -0,0 +1,45 @@
+/*
+ * V4L2 mediabus
+ *
+ * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include media/v4l2-mediabus.h
+
+unsigned int v4l2_mbus_config_compatible(const struct v4l2_mbus_config *cfg,
+ unsigned int flags)
+{
+ unsigned long common_flags;
unsigned int
+ bool hsync = true, vsync = true, pclk, data, mode;
+ bool mipi_lanes, mipi_clock;
+
+ common_flags = cfg-flags flags;
+
+ switch (cfg-type) {
+ case V4L2_MBUS_PARALLEL:
+ hsync = common_flags (V4L2_MBUS_HSYNC_ACTIVE_HIGH |
+ V4L2_MBUS_HSYNC_ACTIVE_LOW);
+ vsync = common_flags (V4L2_MBUS_VSYNC_ACTIVE_HIGH |
+ V4L2_MBUS_VSYNC_ACTIVE_LOW);
Add a '/* fall through */' comment here.
+ case V4L2_MBUS_BT656:
+ pclk = common_flags (V4L2_MBUS_PCLK_SAMPLE_RISING |
+V4L2_MBUS_PCLK_SAMPLE_FALLING);
+ data = common_flags (V4L2_MBUS_DATA_ACTIVE_HIGH |
+V4L2_MBUS_DATA_ACTIVE_LOW);
+ mode = common_flags (V4L2_MBUS_MASTER | V4L2_MBUS_SLAVE);
+ return (!hsync || !vsync || !pclk || !data || !mode) ?
+ 0 : common_flags;
+ case V4L2_MBUS_CSI2:
+ mipi_lanes = common_flags V4L2_MBUS_CSI2_LANES;
+ mipi_clock = common_flags (V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK
|
+ V4L2_MBUS_CSI2_CONTINUOUS_CLOCK);
+ return (!mipi_lanes || !mipi_clock) ? 0 : common_flags;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(v4l2_mbus_config_compatible);
diff --git a/include/media/v4l2-mediabus.h
[PATCH] media: initial driver for ov5642 CMOS sensor
This is an initial driver release for the Omnivision 5642 CMOS sensor.
Signed-off-by: Bastian Hecht hec...@gmail.com
---
diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c
new file mode 100644
index 000..3cdae97
--- /dev/null
+++ b/drivers/media/video/ov5642.c
@@ -0,0 +1,1011 @@
+/*
+ * Driver for OV5642 CMOS Image Sensor from Omnivision
+ *
+ * Copyright (C) 2011, Bastian Hecht hec...@gmail.com
+ *
+ * Based on Sony IMX074 Camera Driver
+ * Copyright (C) 2010, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * Based on Omnivision OV7670 Camera Driver
+ * Copyright (C) 2006-7 Jonathan Corbet cor...@lwn.net
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/slab.h
+#include linux/videodev2.h
+
+#include media/soc_camera.h
+#include media/soc_mediabus.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-subdev.h
+
+/* OV5642 registers */
+#define REG_CHIP_ID_HIGH 0x300a
+#define REG_CHIP_ID_LOW0x300b
+
+#define REG_WINDOW_START_X_HIGH0x3800
+#define REG_WINDOW_START_X_LOW 0x3801
+#define REG_WINDOW_START_Y_HIGH0x3802
+#define REG_WINDOW_START_Y_LOW 0x3803
+#define REG_WINDOW_WIDTH_HIGH 0x3804
+#define REG_WINDOW_WIDTH_LOW 0x3805
+#define REG_WINDOW_HEIGHT_HIGH 0x3806
+#define REG_WINDOW_HEIGHT_LOW 0x3807
+#define REG_OUT_WIDTH_HIGH 0x3808
+#define REG_OUT_WIDTH_LOW 0x3809
+#define REG_OUT_HEIGHT_HIGH0x380a
+#define REG_OUT_HEIGHT_LOW 0x380b
+#define REG_OUT_TOTAL_WIDTH_HIGH 0x380c
+#define REG_OUT_TOTAL_WIDTH_LOW0x380d
+#define REG_OUT_TOTAL_HEIGHT_HIGH 0x380e
+#define REG_OUT_TOTAL_HEIGHT_LOW 0x380f
+
+/*
+ * define standard resolution.
+ * Works currently only for up to 720 lines
+ * eg. 320x240, 640x480, 800x600, 1280x720, 2048x720
+ */
+
+#define OV5642_WIDTH 1280
+#define OV5642_HEIGHT 720
+#define OV5642_TOTAL_WIDTH 3200
+#define OV5642_TOTAL_HEIGHT2000
+#define OV5642_SENSOR_SIZE_X 2592
+#define OV5642_SENSOR_SIZE_Y 1944
+
+struct regval_list {
+ u16 reg_num;
+ u8 value;
+};
+
+static struct regval_list ov5642_default_regs_init[] = {
+ { 0x3103, 0x93 },
+ { 0x3008, 0x82 },
+ { 0x3017, 0x7f },
+ { 0x3018, 0xfc },
+ { 0x3810, 0xc2 },
+ { 0x3615, 0xf0 },
+ { 0x3000, 0x0 },
+ { 0x3001, 0x0 },
+ { 0x3002, 0x0 },
+ { 0x3003, 0x0 },
+ { 0x3004, 0xff },
+ { 0x3030, 0x2b },
+ { 0x3011, 0x8 },
+ { 0x3010, 0x10 },
+ { 0x3604, 0x60 },
+ { 0x3622, 0x60 },
+ { 0x3621, 0x9 },
+ { 0x3709, 0x0 },
+ { 0x4000, 0x21 },
+ { 0x401d, 0x22 },
+ { 0x3600, 0x54 },
+ { 0x3605, 0x4 },
+ { 0x3606, 0x3f },
+ { 0x3c01, 0x80 },
+ { 0x300d, 0x22 },
+ { 0x3623, 0x22 },
+ { 0x5000, 0x4f },
+ { 0x5020, 0x4 },
+ { 0x5181, 0x79 },
+ { 0x5182, 0x0 },
+ { 0x5185, 0x22 },
+ { 0x5197, 0x1 },
+ { 0x5500, 0xa },
+ { 0x5504, 0x0 },
+ { 0x5505, 0x7f },
+ { 0x5080, 0x8 },
+ { 0x300e, 0x18 },
+ { 0x4610, 0x0 },
+ { 0x471d, 0x5 },
+ { 0x4708, 0x6 },
+ { 0x370c, 0xa0 },
+ { 0x5687, 0x94 },
+ { 0x501f, 0x0 },
+ { 0x5000, 0x4f },
+ { 0x5001, 0xcf },
+ { 0x4300, 0x30 },
+ { 0x4300, 0x30 },
+ { 0x460b, 0x35 },
+ { 0x471d, 0x0 },
+ { 0x3002, 0xc },
+ { 0x3002, 0x0 },
+ { 0x4713, 0x3 },
+ { 0x471c, 0x50 },
+ { 0x4721, 0x2 },
+ { 0x4402, 0x90 },
+ { 0x460c, 0x22 },
+ { 0x3815, 0x44 },
+ { 0x3503, 0x7 },
+ { 0x3501, 0x73 },
+ { 0x3502, 0x80 },
+ { 0x350b, 0x0 },
+ { 0x3818, 0xc8 },
+ { 0x3824, 0x11 },
+ { 0x3a00, 0x78 },
+ { 0x3a1a, 0x4 },
+ { 0x3a13, 0x30 },
+ { 0x3a18, 0x0 },
+ { 0x3a19, 0x7c },
+ { 0x3a08, 0x12 },
+ { 0x3a09, 0xc0 },
+ { 0x3a0a, 0xf },
+ { 0x3a0b, 0xa0 },
+ { 0x350c, 0x7 },
+ { 0x350d, 0xd0 },
+ { 0x3a0d, 0x8 },
+ { 0x3a0e, 0x6 },
+ { 0x3500, 0x0 },
+ { 0x3501, 0x0 },
+ { 0x3502, 0x0 },
+ { 0x350a, 0x0 },
+ { 0x350b, 0x0 },
+ { 0x3503, 0x0 },
+ { 0x3a0f, 0x3c },
+ { 0x3a10, 0x32 },
+ { 0x3a1b, 0x3c },
+ { 0x3a1e, 0x32 },
+ { 0x3a11, 0x80 },
+ { 0x3a1f, 0x20 },
+ { 0x3030, 0x2b },
+ { 0x3a02, 0x0 },
+ { 0x3a03, 0x7d },
+ { 0x3a04, 0x0 },
+ { 0x3a14, 0x0 },
+ { 0x3a15, 0x7d },
+ { 0x3a16, 0x0 },
+ { 0x3a00, 0x78 },
+ { 0x3a08, 0x9 },
+
Re: [PATCH] SOUND: Fix non-ISA_DMA_API build failure
On Fri, Jun 24, 2011 at 10:26:13AM +0200, Takashi Iwai wrote: Hrm... I still don't understand why ES18XX or others were selected at the first place. Isn't it covered by the conditional in sound/isa/Kconfig like below? menuconfig SND_ISA bool ISA sound devices depends on ISA ISA_DMA_API ... if SND_ISA ... config SND_ES18XX tristate Generic ESS ES18xx driver ... endif # SND_ISA Isn't SND_ISA=n in your case although ISA_DMA_API=n? The answer is hidden in this Kconfig warning: warning: (RADIO_MIROPCM20) selects SND_ISA which has unmet direct dependencies (SOUND !M68K SND ISA ISA_DMA_API) This is due to the following in drivers/media/radio/Kconfig: config RADIO_MIROPCM20 tristate miroSOUND PCM20 radio depends on ISA VIDEO_V4L2 SND select SND_ISA select SND_MIRO So SND_ISA gets forced on even though the dependency on ISA_DMA_API is not fulfilled. That's solved by adding the dependency on ISA_DMA_API to RADIO_MIROPCM20. Also, adlib driver is really only for ISA, so I see no big reason to allow this built for non-ISA. With the patch applied: [...] menuconfig SND_ISA bool ISA sound devices depends on ISA [...] if SND_ISA config SND_ADLIB tristate AdLib FM card select SND_OPL3_LIB [...] So the Adlib driver will still only be built with ISA enabled. The only thing that makes the Adlib driver different from all the others in the ifdef SND_ISA ... endif bracket is that it does not directly or indirectly use the ISA DMA API and that's in the end the reason why sound/isa/Kconfig needs to be changed. I originally approach this a different way but now that I'm explaining the details I notice that it probably makes sense to split this patch into two: o The drivers/media/radio/Kconfig part should be applied for 3.0 and maybe -stable. o The sound/isa/Kconfig part is basically only fixing the dependency for the Adlib driver allowing it to be built on non-ISA_DMA_API system and is material for the next release after 3.0. If you agree I'm going to repost the patch with aproprite log messages. Ralf -- 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] Octopus driver status
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Oliver Endriss Sent: vendredi 24 juin 2011 11:52 To: Sébastien RAILLARD (COEXSI) Cc: Linux Media Mailing List Subject: Re: [DVB] Octopus driver status Hi, On Thursday 23 June 2011 23:31:08 Sébastien RAILLARD wrote: Dear all, I'm looking at the Octopus DVB cards system from Digital Devices for a while as their system seems to be very interesting Here is link with their products: http://shop.digital-devices.de/epages/62357162.sf/en_GB/?ObjectPath=/S hops/6 2357162/Categories The good points I have found: * They support most of the common DVB standards: DVB-C, DVB-T, DVB-S and DVB-S2 * They are moderately priced * There is a CAM support with a CI adapter for unscrambling channels * They are using the now de-facto standard PCI-Express bus * The new Octopus system is using a LATTICE PCI-Express bridge that seems to be more future proof than the previous bridge Micronas APB7202A * They seem to be well engineered (Designed and manufactured in Germany as they say!) And now the doubts : * The DVB-C/T frontend driver is specific to this system and is very new, so as Devin said one week ago, it's maybe not yet production ready * The way the CAM is supported break all the existing userland DVB applications (gnutv, mumudvb, vlc, etc.) * There isn't so much information about the Digital Devices company and their products roadmap (at least in English) So, my two very simple questions to the developers who worked on the drivers (I think Oliver and Ralph did) and know the product: * How you feel the future about the Octopus driver? The drivers work fine. I am not aware of any problems. All Digital Devices cards and tuner variants are supported by the driver http://linuxtv.org/hg/~endriss/media_build_experimental ddbridge (Lattice bridge): - Octopus (all variants) - cineS2 v6 - DuoFlex S2 (stv0900 + stv6110 + lnbp21) - DuoFlex C/T (Micronas DRXK + NXP TDA18271C2) ngene bridge: - cineS2 (v4,v5), Satix S2 Dual - PCIe bridge, mini PCIe bridge - DuoFlex S2 (stv0900 + stv6110 + lnbp21) - DuoFlex C/T (Micronas DRXK + NXP TDA18271C2) For a German description, see http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb- s2/105803-aktuelle-treiber-für-octopus-ddbridge-cines2-ngene-ddbridge- duoflex-s2-duoflex-ct-sowie-tt-s2-6400 From an operational point of view, the driver is ready for the kernel. Unfortunately I did not have the time yet to clean up the coding-style. There are thousands of coding-style issues waiting to be fixed... Ok, thank you for the update. We will try some Octopus cards. * Do you think a compatibility mode (like module parameter) can be added to simulate the way the CAM is handled in the other drivers? Yes, this could be done: ++ The CI could be used with any application. -- The CI will be attached to one tuner exclusively. It is not very hard to implement this. Patches are welcome. ;-) Maybe I'll ask for advices!!! CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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
[RFC] Don't use linux/version.h anymore to indicate a per-driver version - Was: Re: [PATCH 03/37] Remove unneeded version.h includes from include/
Em 23-06-2011 18:58, Jesper Juhl escreveu:
It was pointed out by 'make versioncheck' that some includes of
linux/version.h were not needed in include/.
This patch removes them.
Signed-off-by: Jesper Juhl j...@chaosbits.net
---
include/linux/ceph/messenger.h |1 -
include/media/pwc-ioctl.h |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/include/linux/ceph/messenger.h b/include/linux/ceph/messenger.h
index 31d91a6..291aa6e 100644
--- a/include/linux/ceph/messenger.h
+++ b/include/linux/ceph/messenger.h
@@ -6,7 +6,6 @@
#include linux/net.h
#include linux/radix-tree.h
#include linux/uio.h
-#include linux/version.h
#include linux/workqueue.h
#include types.h
diff --git a/include/media/pwc-ioctl.h b/include/media/pwc-ioctl.h
index 0f19779..1ed1e61 100644
--- a/include/media/pwc-ioctl.h
+++ b/include/media/pwc-ioctl.h
@@ -53,7 +53,6 @@
*/
#include linux/types.h
-#include linux/version.h
/* Enumeration of image sizes */
#define PSZ_SQCIF0x00
The usage of version.h at the Linux media kernel is due to a V4L2 API
requirement[1],
where an ioctl query of VIDIOC_QUERYCAP type would return the driver version
formatted
with KERNEL_VERSION() macro.
[1] http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-querycap.html
While a few driver maintainers are careful enough to increment it on every new
kernel version where the driver was touched, others simply keep it outdated.
IMHO, it doesn't make much sense on having a per-driver version field: the V4L2
layer
should be enough to abstract hardware differences, and to avoid userspace to
have a per
driver list of hacks. I don't think that the userspace applications are really
using it.
Module versions should just use the MODULE_VERSION() macro.
So, IMO, the better would be to convert this field into a V4L2 API version field
instead like the enclosed patch. Of course, this also means to change the V4L2
API
Docbook. After that, we can cleanup all those linux/version.h code on all V4L
drivers.
The idea is that, every time we add something new at the V4L2 API, we'll
increment it
to match the current kernel version.
On a quick look, all drivers, except by one uses versions = KERNEL_VERSION(3,
0, 0).
The only exception is the pwc driver, with version is KERNEL_VERSION(10, 0,
12). Due to
a bug on it, it also reports its version as: 10.0.14 at module version. The
version
10.0.12 is reported there since 2006, even having suffered a major change, due
to the
removal of the V4L1 API, on changeset 479567ce3af7b99d645a3c53b8ca2fc65e46efdc.
So, I think it would be safe to change it to 3.0.0, as using the version here,
in the favor
of a greater good. We can keep the driver-specific version only at
Comments?
If others are ok with that, I'll prepare the changesets.
Cheers,
Mauro
-
[media] v4l2 core: Use a per-API version instead of a per driver version
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 213ba7d..d8fa571 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -16,6 +16,7 @@
#include linux/slab.h
#include linux/types.h
#include linux/kernel.hdiff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c
index 213ba7d..b19ad56 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -16,6 +16,7 @@
#include linux/slab.h
#include linux/types.h
#include linux/kernel.h
+#include linux/version.h
#include linux/videodev2.h
@@ -27,6 +28,8 @@
#include media/v4l2-device.h
#include media/v4l2-chip-ident.h
+#define V4L2_API_VERSION KERNEL_VERSION(3, 0, 0)
+
#define dbgarg(cmd, fmt, arg...) \
do {\
if (vfd-debug V4L2_DEBUG_IOCTL_ARG) {\
@@ -606,13 +609,16 @@ static long __video_do_ioctl(struct file *file,
break;
ret = ops-vidioc_querycap(file, fh, cap);
- if (!ret)
+ if (!ret) {
+ cap-version = V4L2_API_VERSION;
+
dbgarg(cmd, driver=%s, card=%s, bus=%s,
version=0x%08x,
capabilities=0x%08x\n,
cap-driver, cap-card, cap-bus_info,
cap-version,
cap-capabilities);
+ }
break;
}
--
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] Don't use linux/version.h anymore to indicate a per-driver version - Was: Re: [PATCH 03/37] Remove unneeded version.h includes from include/
On Friday, June 24, 2011 13:21:14 Mauro Carvalho Chehab wrote:
Em 23-06-2011 18:58, Jesper Juhl escreveu:
It was pointed out by 'make versioncheck' that some includes of
linux/version.h were not needed in include/.
This patch removes them.
Signed-off-by: Jesper Juhl j...@chaosbits.net
---
include/linux/ceph/messenger.h |1 -
include/media/pwc-ioctl.h |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/include/linux/ceph/messenger.h b/include/linux/ceph/messenger.h
index 31d91a6..291aa6e 100644
--- a/include/linux/ceph/messenger.h
+++ b/include/linux/ceph/messenger.h
@@ -6,7 +6,6 @@
#include linux/net.h
#include linux/radix-tree.h
#include linux/uio.h
-#include linux/version.h
#include linux/workqueue.h
#include types.h
diff --git a/include/media/pwc-ioctl.h b/include/media/pwc-ioctl.h
index 0f19779..1ed1e61 100644
--- a/include/media/pwc-ioctl.h
+++ b/include/media/pwc-ioctl.h
@@ -53,7 +53,6 @@
*/
#include linux/types.h
-#include linux/version.h
/* Enumeration of image sizes */
#define PSZ_SQCIF 0x00
The usage of version.h at the Linux media kernel is due to a V4L2 API
requirement[1],
where an ioctl query of VIDIOC_QUERYCAP type would return the driver version
formatted
with KERNEL_VERSION() macro.
[1] http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-querycap.html
While a few driver maintainers are careful enough to increment it on every new
kernel version where the driver was touched, others simply keep it outdated.
IMHO, it doesn't make much sense on having a per-driver version field: the
V4L2 layer
should be enough to abstract hardware differences, and to avoid userspace to
have a per
driver list of hacks. I don't think that the userspace applications are
really using it.
Applications are certainly using it. I know this for a fact for the ivtv driver
where
feature improvements are marked that way.
Without more research on how this is used I am not comfortable with this.
Regards,
Hans
Module versions should just use the MODULE_VERSION() macro.
So, IMO, the better would be to convert this field into a V4L2 API version
field
instead like the enclosed patch. Of course, this also means to change the
V4L2 API
Docbook. After that, we can cleanup all those linux/version.h code on all V4L
drivers.
The idea is that, every time we add something new at the V4L2 API, we'll
increment it
to match the current kernel version.
On a quick look, all drivers, except by one uses versions =
KERNEL_VERSION(3, 0, 0).
The only exception is the pwc driver, with version is KERNEL_VERSION(10, 0,
12). Due to
a bug on it, it also reports its version as: 10.0.14 at module version. The
version
10.0.12 is reported there since 2006, even having suffered a major change,
due to the
removal of the V4L1 API, on changeset
479567ce3af7b99d645a3c53b8ca2fc65e46efdc.
So, I think it would be safe to change it to 3.0.0, as using the version
here, in the favor
of a greater good. We can keep the driver-specific version only at
Comments?
If others are ok with that, I'll prepare the changesets.
Cheers,
Mauro
-
[media] v4l2 core: Use a per-API version instead of a per driver version
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c
index 213ba7d..d8fa571 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -16,6 +16,7 @@
#include linux/slab.h
#include linux/types.h
#include linux/kernel.hdiff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c
index 213ba7d..b19ad56 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -16,6 +16,7 @@
#include linux/slab.h
#include linux/types.h
#include linux/kernel.h
+#include linux/version.h
#include linux/videodev2.h
@@ -27,6 +28,8 @@
#include media/v4l2-device.h
#include media/v4l2-chip-ident.h
+#define V4L2_API_VERSION KERNEL_VERSION(3, 0, 0)
+
#define dbgarg(cmd, fmt, arg...) \
do {\
if (vfd-debug V4L2_DEBUG_IOCTL_ARG) {\
@@ -606,13 +609,16 @@ static long __video_do_ioctl(struct file *file,
break;
ret = ops-vidioc_querycap(file, fh, cap);
- if (!ret)
+ if (!ret) {
+ cap-version = V4L2_API_VERSION;
+
dbgarg(cmd, driver=%s, card=%s, bus=%s,
version=0x%08x,
capabilities=0x%08x\n,
cap-driver, cap-card, cap-bus_info,
cap-version,
cap-capabilities);
+ }
Re: [PATCH] SOUND: Fix non-ISA_DMA_API build failure
Em 24-06-2011 08:16, Ralf Baechle escreveu: On Fri, Jun 24, 2011 at 10:26:13AM +0200, Takashi Iwai wrote: Hrm... I still don't understand why ES18XX or others were selected at the first place. Isn't it covered by the conditional in sound/isa/Kconfig like below? menuconfig SND_ISA bool ISA sound devices depends on ISA ISA_DMA_API ... if SND_ISA ... config SND_ES18XX tristate Generic ESS ES18xx driver ... endif# SND_ISA Isn't SND_ISA=n in your case although ISA_DMA_API=n? The answer is hidden in this Kconfig warning: warning: (RADIO_MIROPCM20) selects SND_ISA which has unmet direct dependencies (SOUND !M68K SND ISA ISA_DMA_API) This is due to the following in drivers/media/radio/Kconfig: config RADIO_MIROPCM20 tristate miroSOUND PCM20 radio depends on ISA VIDEO_V4L2 SND select SND_ISA select SND_MIRO So SND_ISA gets forced on even though the dependency on ISA_DMA_API is not fulfilled. That's solved by adding the dependency on ISA_DMA_API to RADIO_MIROPCM20. Another option would be to convert the two above selects into depends on. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DVB] Octopus driver status
Em 24-06-2011 06:51, Oliver Endriss escreveu: Hi, On Thursday 23 June 2011 23:31:08 Sébastien RAILLARD wrote: Dear all, I'm looking at the Octopus DVB cards system from Digital Devices for a while as their system seems to be very interesting Here is link with their products: http://shop.digital-devices.de/epages/62357162.sf/en_GB/?ObjectPath=/Shops/6 2357162/Categories The good points I have found: * They support most of the common DVB standards: DVB-C, DVB-T, DVB-S and DVB-S2 * They are moderately priced * There is a CAM support with a CI adapter for unscrambling channels * They are using the now de-facto standard PCI-Express bus * The new Octopus system is using a LATTICE PCI-Express bridge that seems to be more future proof than the previous bridge Micronas APB7202A * They seem to be well engineered (Designed and manufactured in Germany as they say!) And now the doubts : * The DVB-C/T frontend driver is specific to this system and is very new, so as Devin said one week ago, it's maybe not yet production ready * The way the CAM is supported break all the existing userland DVB applications (gnutv, mumudvb, vlc, etc.) * There isn't so much information about the Digital Devices company and their products roadmap (at least in English) So, my two very simple questions to the developers who worked on the drivers (I think Oliver and Ralph did) and know the product: * How you feel the future about the Octopus driver? The drivers work fine. I am not aware of any problems. All Digital Devices cards and tuner variants are supported by the driver http://linuxtv.org/hg/~endriss/media_build_experimental ddbridge (Lattice bridge): - Octopus (all variants) - cineS2 v6 - DuoFlex S2 (stv0900 + stv6110 + lnbp21) - DuoFlex C/T (Micronas DRXK + NXP TDA18271C2) ngene bridge: - cineS2 (v4,v5), Satix S2 Dual - PCIe bridge, mini PCIe bridge - DuoFlex S2 (stv0900 + stv6110 + lnbp21) - DuoFlex C/T (Micronas DRXK + NXP TDA18271C2) For a German description, see http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/105803-aktuelle-treiber-für-octopus-ddbridge-cines2-ngene-ddbridge-duoflex-s2-duoflex-ct-sowie-tt-s2-6400 From an operational point of view, the driver is ready for the kernel. Unfortunately I did not have the time yet to clean up the coding-style. There are thousands of coding-style issues waiting to be fixed... Hi Oliver, If it is ok for you, I have here a few devices with DRXK that I'm seeking for some time to work with. I'll probably have some time this weekend for them, so I can do the CodingStyle cleanups, if it is ok for you. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] SOUND: Fix non-ISA_DMA_API build failure
On Fri, Jun 24, 2011 at 08:35:22AM -0300, Mauro Carvalho Chehab wrote: Em 24-06-2011 08:16, Ralf Baechle escreveu: tristate miroSOUND PCM20 radio depends on ISA VIDEO_V4L2 SND select SND_ISA select SND_MIRO So SND_ISA gets forced on even though the dependency on ISA_DMA_API is not fulfilled. That's solved by adding the dependency on ISA_DMA_API to RADIO_MIROPCM20. Another option would be to convert the two above selects into depends on. Depends has the disadvantage that users may have to enable unobvious options first before they are offered the one they are looking for and that's what a depends SND_ISA would cause in this case. Ralf -- 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] Don't use linux/version.h anymore to indicate a per-driver version - Was: Re: [PATCH 03/37] Remove unneeded version.h includes from include/
Applications are certainly using it. I know this for a fact for the ivtv driver where feature improvements are marked that way. Without more research on how this is used I am not comfortable with this. Regards, Hans MythTV has a bunch of these too (mainly so the code can adapt to driver bugs that are fixed in later revisions). Putting Mauro's patch upstream will definitely cause breakage. Also, it screws up the ability for users to get fixes through the media_build tree (unless you are increasing the revision constantly with every merge you do). 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: [PATCH] SOUND: Fix non-ISA_DMA_API build failure
At Fri, 24 Jun 2011 12:16:08 +0100, Ralf Baechle wrote: On Fri, Jun 24, 2011 at 10:26:13AM +0200, Takashi Iwai wrote: Hrm... I still don't understand why ES18XX or others were selected at the first place. Isn't it covered by the conditional in sound/isa/Kconfig like below? menuconfig SND_ISA bool ISA sound devices depends on ISA ISA_DMA_API ... if SND_ISA ... config SND_ES18XX tristate Generic ESS ES18xx driver ... endif # SND_ISA Isn't SND_ISA=n in your case although ISA_DMA_API=n? The answer is hidden in this Kconfig warning: warning: (RADIO_MIROPCM20) selects SND_ISA which has unmet direct dependencies (SOUND !M68K SND ISA ISA_DMA_API) This is due to the following in drivers/media/radio/Kconfig: config RADIO_MIROPCM20 tristate miroSOUND PCM20 radio depends on ISA VIDEO_V4L2 SND select SND_ISA select SND_MIRO So SND_ISA gets forced on even though the dependency on ISA_DMA_API is not fulfilled. That's solved by adding the dependency on ISA_DMA_API to RADIO_MIROPCM20. Ah, yeah, I see now. Also, adlib driver is really only for ISA, so I see no big reason to allow this built for non-ISA. With the patch applied: [...] menuconfig SND_ISA bool ISA sound devices depends on ISA [...] if SND_ISA config SND_ADLIB tristate AdLib FM card select SND_OPL3_LIB [...] So the Adlib driver will still only be built with ISA enabled. The only thing that makes the Adlib driver different from all the others in the ifdef SND_ISA ... endif bracket is that it does not directly or indirectly use the ISA DMA API and that's in the end the reason why sound/isa/Kconfig needs to be changed. I originally approach this a different way but now that I'm explaining the details I notice that it probably makes sense to split this patch into two: o The drivers/media/radio/Kconfig part should be applied for 3.0 and maybe -stable. Yes, this will be good. o The sound/isa/Kconfig part is basically only fixing the dependency for the Adlib driver allowing it to be built on non-ISA_DMA_API system and is material for the next release after 3.0. Any serious reason that snd-adlib must be built even with ISA=n? As the device is really present only for ISA, it doesn't make much sense to build this even though the driver itself doesn't need ISA_DMA_API. thanks, Takashi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6 v3] [media] ov9740: Cleanup hex casing inconsistencies
On Thu, 23 Jun 2011, ac...@nvidia.com wrote: From: Andrew Chew ac...@nvidia.com Made all hex number casing use lower-case throughout the entire driver for consistency. Signed-off-by: Andrew Chew ac...@nvidia.com All look good to me now, thanks! Queued for 3.1. Regards Guennadi --- drivers/media/video/ov9740.c | 111 +- 1 files changed, 55 insertions(+), 56 deletions(-) diff --git a/drivers/media/video/ov9740.c b/drivers/media/video/ov9740.c index 4d4ee4f..96811e4 100644 --- a/drivers/media/video/ov9740.c +++ b/drivers/media/video/ov9740.c @@ -44,12 +44,12 @@ #define OV9740_Y_ADDR_START_LO 0x0347 #define OV9740_X_ADDR_END_HI 0x0348 #define OV9740_X_ADDR_END_LO 0x0349 -#define OV9740_Y_ADDR_END_HI 0x034A -#define OV9740_Y_ADDR_END_LO 0x034B -#define OV9740_X_OUTPUT_SIZE_HI 0x034C -#define OV9740_X_OUTPUT_SIZE_LO 0x034D -#define OV9740_Y_OUTPUT_SIZE_HI 0x034E -#define OV9740_Y_OUTPUT_SIZE_LO 0x034F +#define OV9740_Y_ADDR_END_HI 0x034a +#define OV9740_Y_ADDR_END_LO 0x034b +#define OV9740_X_OUTPUT_SIZE_HI 0x034c +#define OV9740_X_OUTPUT_SIZE_LO 0x034d +#define OV9740_Y_OUTPUT_SIZE_HI 0x034e +#define OV9740_Y_OUTPUT_SIZE_LO 0x034f /* IO Control Registers */ #define OV9740_IO_CREL00 0x3002 @@ -89,28 +89,28 @@ #define OV9740_TIMING_CTRL35 0x3835 /* Banding Filter */ -#define OV9740_AEC_MAXEXPO_60_H 0x3A02 -#define OV9740_AEC_MAXEXPO_60_L 0x3A03 -#define OV9740_AEC_B50_STEP_HI 0x3A08 -#define OV9740_AEC_B50_STEP_LO 0x3A09 -#define OV9740_AEC_B60_STEP_HI 0x3A0A -#define OV9740_AEC_B60_STEP_LO 0x3A0B -#define OV9740_AEC_CTRL0D0x3A0D -#define OV9740_AEC_CTRL0E0x3A0E -#define OV9740_AEC_MAXEXPO_50_H 0x3A14 -#define OV9740_AEC_MAXEXPO_50_L 0x3A15 +#define OV9740_AEC_MAXEXPO_60_H 0x3a02 +#define OV9740_AEC_MAXEXPO_60_L 0x3a03 +#define OV9740_AEC_B50_STEP_HI 0x3a08 +#define OV9740_AEC_B50_STEP_LO 0x3a09 +#define OV9740_AEC_B60_STEP_HI 0x3a0a +#define OV9740_AEC_B60_STEP_LO 0x3a0b +#define OV9740_AEC_CTRL0D0x3a0d +#define OV9740_AEC_CTRL0E0x3a0e +#define OV9740_AEC_MAXEXPO_50_H 0x3a14 +#define OV9740_AEC_MAXEXPO_50_L 0x3a15 /* AEC/AGC Control */ #define OV9740_AEC_ENABLE0x3503 -#define OV9740_GAIN_CEILING_01 0x3A18 -#define OV9740_GAIN_CEILING_02 0x3A19 -#define OV9740_AEC_HI_THRESHOLD 0x3A11 -#define OV9740_AEC_3A1A 0x3A1A -#define OV9740_AEC_CTRL1B_WPT2 0x3A1B -#define OV9740_AEC_CTRL0F_WPT0x3A0F -#define OV9740_AEC_CTRL10_BPT0x3A10 -#define OV9740_AEC_CTRL1E_BPT2 0x3A1E -#define OV9740_AEC_LO_THRESHOLD 0x3A1F +#define OV9740_GAIN_CEILING_01 0x3a18 +#define OV9740_GAIN_CEILING_02 0x3a19 +#define OV9740_AEC_HI_THRESHOLD 0x3a11 +#define OV9740_AEC_3A1A 0x3a1a +#define OV9740_AEC_CTRL1B_WPT2 0x3a1b +#define OV9740_AEC_CTRL0F_WPT0x3a0f +#define OV9740_AEC_CTRL10_BPT0x3a10 +#define OV9740_AEC_CTRL1E_BPT2 0x3a1e +#define OV9740_AEC_LO_THRESHOLD 0x3a1f /* BLC Control */ #define OV9740_BLC_AUTO_ENABLE 0x4002 @@ -132,7 +132,7 @@ #define OV9740_VT_SYS_CLK_DIV0x0303 #define OV9740_VT_PIX_CLK_DIV0x0301 #define OV9740_PLL_CTRL3010 0x3010 -#define OV9740_VFIFO_CTRL00 0x460E +#define OV9740_VFIFO_CTRL00 0x460e /* ISP Control */ #define OV9740_ISP_CTRL000x5000 @@ -141,9 +141,9 @@ #define OV9740_ISP_CTRL050x5005 #define OV9740_ISP_CTRL120x5012 #define OV9740_ISP_CTRL190x5019 -#define OV9740_ISP_CTRL1A0x501A -#define OV9740_ISP_CTRL1E0x501E -#define OV9740_ISP_CTRL1F0x501F +#define OV9740_ISP_CTRL1A0x501a +#define OV9740_ISP_CTRL1E0x501e +#define OV9740_ISP_CTRL1F0x501f #define OV9740_ISP_CTRL200x5020 #define OV9740_ISP_CTRL210x5021 @@ -158,12 +158,12 @@ #define OV9740_AWB_ADV_CTRL040x5187 #define OV9740_AWB_ADV_CTRL050x5188 #define OV9740_AWB_ADV_CTRL060x5189 -#define OV9740_AWB_ADV_CTRL070x518A -#define OV9740_AWB_ADV_CTRL080x518B -#define OV9740_AWB_ADV_CTRL090x518C -#define OV9740_AWB_ADV_CTRL10
Re: [DVB] Octopus driver status
On 24 June 2011 12:57, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 24-06-2011 06:51, Oliver Endriss escreveu: Hi, On Thursday 23 June 2011 23:31:08 Sébastien RAILLARD wrote: Dear all, I'm looking at the Octopus DVB cards system from Digital Devices for a while as their system seems to be very interesting Here is link with their products: http://shop.digital-devices.de/epages/62357162.sf/en_GB/?ObjectPath=/Shops/6 2357162/Categories The good points I have found: * They support most of the common DVB standards: DVB-C, DVB-T, DVB-S and DVB-S2 * They are moderately priced * There is a CAM support with a CI adapter for unscrambling channels * They are using the now de-facto standard PCI-Express bus * The new Octopus system is using a LATTICE PCI-Express bridge that seems to be more future proof than the previous bridge Micronas APB7202A * They seem to be well engineered (Designed and manufactured in Germany as they say!) And now the doubts : * The DVB-C/T frontend driver is specific to this system and is very new, so as Devin said one week ago, it's maybe not yet production ready * The way the CAM is supported break all the existing userland DVB applications (gnutv, mumudvb, vlc, etc.) * There isn't so much information about the Digital Devices company and their products roadmap (at least in English) So, my two very simple questions to the developers who worked on the drivers (I think Oliver and Ralph did) and know the product: * How you feel the future about the Octopus driver? The drivers work fine. I am not aware of any problems. All Digital Devices cards and tuner variants are supported by the driver http://linuxtv.org/hg/~endriss/media_build_experimental ddbridge (Lattice bridge): - Octopus (all variants) - cineS2 v6 - DuoFlex S2 (stv0900 + stv6110 + lnbp21) - DuoFlex C/T (Micronas DRXK + NXP TDA18271C2) ngene bridge: - cineS2 (v4,v5), Satix S2 Dual - PCIe bridge, mini PCIe bridge - DuoFlex S2 (stv0900 + stv6110 + lnbp21) - DuoFlex C/T (Micronas DRXK + NXP TDA18271C2) For a German description, see http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/105803-aktuelle-treiber-für-octopus-ddbridge-cines2-ngene-ddbridge-duoflex-s2-duoflex-ct-sowie-tt-s2-6400 From an operational point of view, the driver is ready for the kernel. Unfortunately I did not have the time yet to clean up the coding-style. There are thousands of coding-style issues waiting to be fixed... Hi Oliver, If it is ok for you, I have here a few devices with DRXK that I'm seeking for some time to work with. I'll probably have some time this weekend for them, so I can do the CodingStyle cleanups, if it is ok for you. Cheers, Mauro. -- Do you have a Terratec Cinergy 2400i? It belongs to the ngene family but has PLL tuners. http://linuxtv.org/wiki/index.php/TerraTec_Cinergy_2400i_DVB-T There are some drivers floating on the net that I have got to work in Ubuntu 8.04 but the current ngene drivers has moved on a long way and left it behind. Si. -- 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] SOUND: Fix non-ISA_DMA_API build failure
On Fri, Jun 24, 2011 at 02:22:41PM +0200, Takashi Iwai wrote: o The drivers/media/radio/Kconfig part should be applied for 3.0 and maybe -stable. Yes, this will be good. I just tested that segment only and it works as expected. Will repost in a minute. o The sound/isa/Kconfig part is basically only fixing the dependency for the Adlib driver allowing it to be built on non-ISA_DMA_API system and is material for the next release after 3.0. Any serious reason that snd-adlib must be built even with ISA=n? Definately not. As the device is really present only for ISA, it doesn't make much sense to build this even though the driver itself doesn't need ISA_DMA_API. I'm not aware of any systems that could use the Adlib in a ISA=n environment. That's why my patch left the dependency on ISA untouched. Ralf -- 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] SOUND: Fix non-ISA_DMA_API build failure
At Fri, 24 Jun 2011 14:08:18 +0100, Ralf Baechle wrote: On Fri, Jun 24, 2011 at 02:22:41PM +0200, Takashi Iwai wrote: o The drivers/media/radio/Kconfig part should be applied for 3.0 and maybe -stable. Yes, this will be good. I just tested that segment only and it works as expected. Will repost in a minute. Great, thanks. o The sound/isa/Kconfig part is basically only fixing the dependency for the Adlib driver allowing it to be built on non-ISA_DMA_API system and is material for the next release after 3.0. Any serious reason that snd-adlib must be built even with ISA=n? Definately not. As the device is really present only for ISA, it doesn't make much sense to build this even though the driver itself doesn't need ISA_DMA_API. I'm not aware of any systems that could use the Adlib in a ISA=n environment. That's why my patch left the dependency on ISA untouched. OK, but this would just make things complex, I'm afraid. Practically the only user of snd-adlib is the old x86 with ISA support, which implies ISA_DMA_API=y, too. Thus I don't want to touch sound/isa/Kconfig just for snd-adlib being built for some funky Kconfig setup :) thanks, Takashi -- 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] SOUND: Fix non-ISA_DMA_API build failure
On Thursday 23 June 2011 16:47:50 Ralf Baechle wrote: Fixed by adding an explicit dependency on ISA_DMA_API for all of the config statment that either result in the direction inclusion of code that calls the ISA DMA API or selects something which in turn would use the ISA DMA API. The sole ISA sound driver that does not use the ISA DMA API is the Adlib driver so replaced the dependency of SND_ISA on ISA_DMA_API and add it to each of the drivers individually. Do we really care all that much about the Adlib driver on platforms without ISA_DMA_API? Right now all of sound/isa/ is hidden behind ISA_DMA_API and I think that's acceptable diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig index e4c97fd..0aeed28 100644 --- a/drivers/media/radio/Kconfig +++ b/drivers/media/radio/Kconfig @@ -168,7 +168,7 @@ config RADIO_MAXIRADIO config RADIO_MIROPCM20 tristate miroSOUND PCM20 radio - depends on ISA VIDEO_V4L2 SND + depends on ISA ISA_DMA_API VIDEO_V4L2 SND select SND_ISA select SND_MIRO ---help--- Then this hunk by itself would be enough to solve the compile errors, AFAICT. Arnd -- 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: Fix non-ISA_DMA_API link failure of sound code
A build with ISA ISA_DMA !ISA_DMA_API results in: CC sound/isa/es18xx.o sound/isa/es18xx.c: In function ‘snd_es18xx_playback1_prepare’: sound/isa/es18xx.c:501:9: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/es18xx.c: In function ‘snd_es18xx_playback_pointer’: sound/isa/es18xx.c:818:3: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[2]: *** [sound/isa/es18xx.o] Error 1 CC sound/isa/sscape.o sound/isa/sscape.c: In function ‘upload_dma_data’: sound/isa/sscape.c:481:3: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[2]: *** [sound/isa/sscape.o] Error 1 CC sound/isa/ad1816a/ad1816a_lib.o sound/isa/ad1816a/ad1816a_lib.c: In function ‘snd_ad1816a_playback_prepare’: sound/isa/ad1816a/ad1816a_lib.c:244:2: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/ad1816a/ad1816a_lib.c: In function ‘snd_ad1816a_playback_pointer’: sound/isa/ad1816a/ad1816a_lib.c:302:2: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] sound/isa/ad1816a/ad1816a_lib.c: In function ‘snd_ad1816a_free’: sound/isa/ad1816a/ad1816a_lib.c:544:3: error: implicit declaration of function ‘snd_dma_disable’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/ad1816a/ad1816a_lib.o] Error 1 make[3]: Target `__build' not remade because of errors. make[2]: *** [sound/isa/ad1816a] Error 2 CC sound/isa/es1688/es1688_lib.o sound/isa/es1688/es1688_lib.c: In function ‘snd_es1688_playback_prepare’: sound/isa/es1688/es1688_lib.c:417:2: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/es1688/es1688_lib.c: In function ‘snd_es1688_playback_pointer’: sound/isa/es1688/es1688_lib.c:509:2: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/es1688/es1688_lib.o] Error 1 make[3]: Target `__build' not remade because of errors. make[2]: *** [sound/isa/es1688] Error 2 CC sound/isa/gus/gus_dma.o sound/isa/gus/gus_dma.c: In function ‘snd_gf1_dma_program’: sound/isa/gus/gus_dma.c:79:2: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/gus/gus_dma.c: In function ‘snd_gf1_dma_done’: sound/isa/gus/gus_dma.c:177:3: error: implicit declaration of function ‘snd_dma_disable’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/gus/gus_dma.o] Error 1 CC sound/isa/gus/gus_pcm.o sound/isa/gus/gus_pcm.c: In function ‘snd_gf1_pcm_capture_prepare’: sound/isa/gus/gus_pcm.c:591:2: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/gus/gus_pcm.c: In function ‘snd_gf1_pcm_capture_pointer’: sound/isa/gus/gus_pcm.c:619:2: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/gus/gus_pcm.o] Error 1 make[3]: Target `__build' not remade because of errors. make[2]: *** [sound/isa/gus] Error 2 CC sound/isa/sb/sb16_csp.o sound/isa/sb/sb16_csp.c: In function ‘snd_sb_csp_ioctl’: sound/isa/sb/sb16_csp.c:228:227: error: case label does not reduce to an integer constant make[3]: *** [sound/isa/sb/sb16_csp.o] Error 1 CC sound/isa/sb/sb16_main.o sound/isa/sb/sb16_main.c: In function ‘snd_sb16_playback_prepare’: sound/isa/sb/sb16_main.c:276:2: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/sb/sb16_main.c: In function ‘snd_sb16_playback_pointer’: sound/isa/sb/sb16_main.c:456:2: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/sb/sb16_main.o] Error 1 CC sound/isa/sb/sb8_main.o sound/isa/sb/sb8_main.c: In function ‘snd_sb8_playback_prepare’: sound/isa/sb/sb8_main.c:172:3: error: implicit declaration of function ‘snd_dma_program’ [-Werror=implicit-function-declaration] sound/isa/sb/sb8_main.c: In function ‘snd_sb8_playback_pointer’: sound/isa/sb/sb8_main.c:425:2: error: implicit declaration of function ‘snd_dma_pointer’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [sound/isa/sb/sb8_main.o] Error 1 make[3]: Target `__build' not remade because of errors. make[2]: *** [sound/isa/sb] Error 2 CC sound/isa/wss/wss_lib.o sound/isa/wss/wss_lib.c: In function ‘snd_wss_playback_prepare’: sound/isa/wss/wss_lib.c:1025:2: error: implicit declaration of
Re: [DVB] Octopus driver status
Em 24-06-2011 09:44, Simon Liddicott escreveu: On 24 June 2011 12:57, Mauro Carvalho Chehab mche...@redhat.com mailto:mche...@redhat.com wrote: Em 24-06-2011 06:51, Oliver Endriss escreveu: Hi, On Thursday 23 June 2011 23:31:08 Sébastien RAILLARD wrote: Dear all, I'm looking at the Octopus DVB cards system from Digital Devices for a while as their system seems to be very interesting Here is link with their products: http://shop.digital-devices.de/epages/62357162.sf/en_GB/?ObjectPath=/Shops/6 2357162/Categories The good points I have found: * They support most of the common DVB standards: DVB-C, DVB-T, DVB-S and DVB-S2 * They are moderately priced * There is a CAM support with a CI adapter for unscrambling channels * They are using the now de-facto standard PCI-Express bus * The new Octopus system is using a LATTICE PCI-Express bridge that seems to be more future proof than the previous bridge Micronas APB7202A * They seem to be well engineered (Designed and manufactured in Germany as they say!) And now the doubts : * The DVB-C/T frontend driver is specific to this system and is very new, so as Devin said one week ago, it's maybe not yet production ready * The way the CAM is supported break all the existing userland DVB applications (gnutv, mumudvb, vlc, etc.) * There isn't so much information about the Digital Devices company and their products roadmap (at least in English) So, my two very simple questions to the developers who worked on the drivers (I think Oliver and Ralph did) and know the product: * How you feel the future about the Octopus driver? The drivers work fine. I am not aware of any problems. All Digital Devices cards and tuner variants are supported by the driver http://linuxtv.org/hg/~endriss/media_build_experimental ddbridge (Lattice bridge): - Octopus (all variants) - cineS2 v6 - DuoFlex S2 (stv0900 + stv6110 + lnbp21) - DuoFlex C/T (Micronas DRXK + NXP TDA18271C2) ngene bridge: - cineS2 (v4,v5), Satix S2 Dual - PCIe bridge, mini PCIe bridge - DuoFlex S2 (stv0900 + stv6110 + lnbp21) - DuoFlex C/T (Micronas DRXK + NXP TDA18271C2) For a German description, see http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/105803-aktuelle-treiber-für-octopus-ddbridge-cines2-ngene-ddbridge-duoflex-s2-duoflex-ct-sowie-tt-s2-6400 http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/105803-aktuelle-treiber-f%C3%BCr-octopus-ddbridge-cines2-ngene-ddbridge-duoflex-s2-duoflex-ct-sowie-tt-s2-6400 From an operational point of view, the driver is ready for the kernel. Unfortunately I did not have the time yet to clean up the coding-style. There are thousands of coding-style issues waiting to be fixed... Hi Oliver, If it is ok for you, I have here a few devices with DRXK that I'm seeking for some time to work with. I'll probably have some time this weekend for them, so I can do the CodingStyle cleanups, if it is ok for you. Cheers, Mauro. -- Do you have a Terratec Cinergy 2400i? I don't have. I have a few Terratec DVB-C devices here with DRXK, using different bridge drivers. I started looking on them based on a released DRXK driver, but, as Oliver already had some work on the drxk driver, it is better to merge Oliver series first and then I start working on adding DRXK support to the other drivers, to avoid duplicated work at the DRXK drivers. It belongs to the ngene family but has PLL tuners. http://linuxtv.org/wiki/index.php/TerraTec_Cinergy_2400i_DVB-T There are some drivers floating on the net that I have got to work in Ubuntu 8.04 but the current ngene drivers has moved on a long way and left it behind. Si. -- 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] SOUND: Fix non-ISA_DMA_API build failure
On Fri, Jun 24, 2011 at 03:19:44PM +0200, Arnd Bergmann wrote: The sole ISA sound driver that does not use the ISA DMA API is the Adlib driver so replaced the dependency of SND_ISA on ISA_DMA_API and add it to each of the drivers individually. Do we really care all that much about the Adlib driver on platforms without ISA_DMA_API? Right now all of sound/isa/ is hidden behind ISA_DMA_API and I think that's acceptable When looking into this build error I started untangling the mess from the isa from the sounds end and found the media bits as the root cause after I finished the sound bits. I honestly don't care about the Adlib - until I plug an Adlib into one of my SGI Indigo² and that's unlikely to happen :) diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig index e4c97fd..0aeed28 100644 --- a/drivers/media/radio/Kconfig +++ b/drivers/media/radio/Kconfig @@ -168,7 +168,7 @@ config RADIO_MAXIRADIO config RADIO_MIROPCM20 tristate miroSOUND PCM20 radio - depends on ISA VIDEO_V4L2 SND + depends on ISA ISA_DMA_API VIDEO_V4L2 SND select SND_ISA select SND_MIRO ---help--- Then this hunk by itself would be enough to solve the compile errors, AFAICT. It is, I've tested that. Ralf -- 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 00/35]: System Firmware and SMBIOS Support
On Thursday 23 June 2011 19:22:06 Prarit Bhargava wrote: This new patchset reworks the existing DMI code into two separate layers. It is based off of the feedback I received previously when discussing the SMBIOS version patch on LKML. Hi Prarit, No objections to the patches, but when you send out a series as long as this one, please ensure that all patches are sent as replies to the introductory mail. Also, do not repeat the one-line patch summary in the body of the email. When using git send-email --thread --no-chain-reply, this works automatically. It will also let you put the Cc list into the patch description and work out where to send each patch. Arnd -- 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] Don't use linux/version.h anymore to indicate a per-driver version - Was: Re: [PATCH 03/37] Remove unneeded version.h includes from include/
On Fri, Jun 24, 2011 at 9:29 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: MythTV has a bunch of these too (mainly so the code can adapt to driver bugs that are fixed in later revisions). Putting Mauro's patch upstream will definitely cause breakage. It shouldn't, as ivtv driver version is lower than 3.0.0. All the old bug fixes aren't needed if version is = 3.0.0. Besides that, trusting on a driver revision number to detect that a bug is there is not the right thing to do, as version numbers are never increased at the stable kernels (nor distro modified kernels take care of increasing revision number as patches are backported there). The versions are increased at the discretion of the driver maintainer, usually when there is some userland visible change in driver behavior. I assure you the application developers don't *want* to rely on such a mechanism, but there have definitely been cases in the past where there was no easy way to detect the behavior of the driver from userland. It lets application developers work around things like violations of the V4L2 standard which get fixed in newer revisions of the driver. It provides them the ability to put a hack in their code that says if (version X) then this driver feature is broken and I shouldn't use it. In other words, relying on it doesn't work fine. It's the best (and really only solution) we have today. Also, it screws up the ability for users to get fixes through the media_build tree (unless you are increasing the revision constantly with every merge you do). Why? Developers don't increase version numbers on every applied patch (with is great, as it avoids merge conflicts). The driver maintainer doesn't *have* to increase the version - he does it when he thinks it's appropriate. The point is you are taking that discretion out of *their* hands, and you yourself are unaware of when it is actually needed. You need to stop looking at this from a purist standpoint and think of how application developers actually use the API. They need tools like this to allow them to work around driver bugs while having a source codebase which operates against different kernels (including kernels that may still have those bugs). Sure, in a perfect world where drivers don't have bugs and applications don't have to run against older kernels, what you are saying is not illogical. But then again, we don't live in a perfect world. 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: [RFC] Don't use linux/version.h anymore to indicate a per-driver version - Was: Re: [PATCH 03/37] Remove unneeded version.h includes from include/
On Friday, June 24, 2011 15:45:59 Devin Heitmueller wrote: On Fri, Jun 24, 2011 at 9:29 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: MythTV has a bunch of these too (mainly so the code can adapt to driver bugs that are fixed in later revisions). Putting Mauro's patch upstream will definitely cause breakage. It shouldn't, as ivtv driver version is lower than 3.0.0. All the old bug fixes aren't needed if version is = 3.0.0. Besides that, trusting on a driver revision number to detect that a bug is there is not the right thing to do, as version numbers are never increased at the stable kernels (nor distro modified kernels take care of increasing revision number as patches are backported there). The versions are increased at the discretion of the driver maintainer, usually when there is some userland visible change in driver behavior. I assure you the application developers don't *want* to rely on such a mechanism, but there have definitely been cases in the past where there was no easy way to detect the behavior of the driver from userland. It lets application developers work around things like violations of the V4L2 standard which get fixed in newer revisions of the driver. It provides them the ability to put a hack in their code that says if (version X) then this driver feature is broken and I shouldn't use it. Indeed. Ideally we shouldn't need it. But reality is different. What we have right now works and I see no compelling reason to change the behavior. Regards, Hans In other words, relying on it doesn't work fine. It's the best (and really only solution) we have today. Also, it screws up the ability for users to get fixes through the media_build tree (unless you are increasing the revision constantly with every merge you do). Why? Developers don't increase version numbers on every applied patch (with is great, as it avoids merge conflicts). The driver maintainer doesn't *have* to increase the version - he does it when he thinks it's appropriate. The point is you are taking that discretion out of *their* hands, and you yourself are unaware of when it is actually needed. You need to stop looking at this from a purist standpoint and think of how application developers actually use the API. They need tools like this to allow them to work around driver bugs while having a source codebase which operates against different kernels (including kernels that may still have those bugs). Sure, in a perfect world where drivers don't have bugs and applications don't have to run against older kernels, what you are saying is not illogical. But then again, we don't live in a perfect world. Devin -- 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
Summary of brainstorm about cropping and pipeline configuration
Hello Everyone, This mail summarizes IRC meeting about extensions to crop/compose API in V4L2. Please refer to the links below for further details. http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/32899 http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/32152 The discussion took place from 31 May to 6 Jun. Many offside topic were analyzed. This summary covers following issues: Section 1-4. Pipeline configuration. Section 5. S_FRAMESIZE ioctl Section 6. S_SELECTION ioctl Section 7. Backward compatibility issues 1. Introduction to the pipeline configuration. It is assumed that the pipeline may contain following blocks. A cropping device that cuts a part of an input image and pass that part to further parts of the pipeline. A scaler is a device responsible changing resolution of processed image data. The composer is a device that allows to paste an image into a part of the other image. The composing operation may involve scaling if resolution of destination area differs from the input image. The pipeline configuration strongly depends on hardware capabilities. The main issue is presence of a scaler and a composer. The effects of ioctls may change dramatically depending on presence of HW pieces. The expected behaviours separated by hardware configuration is described in the following paragraphs. 1.1. No composer, no scaler. S_FMT is optional. S_FMT does not change anything except fourcc. The width and height from S_FMT are ignored and they are substituted by width and height of a cropping rectangle. 1.2. Composer, no scaler. S_FMT sets the pixel format and the buffer size. The driver will adjust the size, the minimum size being the S_CROP rectangle, and the maximum size is a driver-defined limit. The size of a compose rectangle is equal to the crop rectangle. User can adjust offsets but the whole compose rectangle must lay inside the buffer. 1.3. No composer, scaler. Scaler is configured by S_FMT and S_CROP. The composing rectangle is always equal to S_FMT. 1.4. Composer, scaler. It is considered to be the most difficult case. The scaler is configured by S_CROP and (S_FMT xor composing rectangle). If the composing rectangle is not defined then its size is equal to S_FMT, and the offset is top/left corner. 2. Configuration flow for video capture. There was a lot of discussion about configuration order for capture devices. Two solutions were proposed: 2.1. Transaction based setup. It was considered good at media controller level. It is more general and flexible for applications that know capabilities of hardware exactly. However this approach is too complex for standard applications. 2.2. Specify in detail in what order the ioctls should be called. It is preferable solution because it suits to simple applications with simple pipelines. 2.2.1. Assumptions: - Standard pipeline is a pipeline that can be defined using following operation (in order): * load from source (video receiver, sensor) * crop * scale/rotate/convert format * compose * store to sink (memory) - Setting a part at higher in a pipeline resets all parts below. - Enforcing an order of ioctls means than an ioctl can reset parameters of other ioctls down the pipeline, but not up the pipeline. - Compatibility with existing applications. The configuration achieved by calling ioctl S_STD/S_DV_PRESET, S_CROP, S_FMT must satisfy all requirements specified in current V4L2 documentation. - Sequence S_STD/S_DV_PRESET, S_CROP, S_FMT must always end with a buffer without any margin - all essential parts of standard pipeline must be mapped to dedicated ioctls - all steps are optional, driver should be able to work on default configuration - no need for S_SCALE ioctl, use cropping and composing rectangles to set scalers. 2.2.2. The proposed order of ioctls: - Select input using S_INPUT - Input resolution: S_STD, S_DV_PRESET or S_FRAMESIZE (upcoming extension). - Set cropping S_CROP/S_SELECTION. - Set rotation using controls. - Set composing rectangle using S_SELECTION. - Set buffer format using S_FMT. 2.2.4 Discussion about order of compose and S_FMT. 2.2.4.1. Proposition I. Use special bit passed in v4l2_pix_format::priv field. If bit is not set then S_FMT resets the compose rectangle to a full S_FMT resolution. If bit is set then format size is adjusted to contain the composing rectangle. The composing rectangle is left untouched. The priv field is used by drivers: pwc, stk-webcam and solo6x10. Moreover dependency of ioctls is broken. If there is no composer then S_FMT forces composing rectangle, and therefore forces scaling configuration. Scaling is above format in the pipeline. 2.2.4.2. Proposition II. Setting compose always resets format and introduces bounds for format. It is similar to Proposition I but the special bit is always on. The difference is that composing is configured before buffer format. Only setup of crop/composing pair is used
Re: [RFC] Don't use linux/version.h anymore to indicate a per-driver version - Was: Re: [PATCH 03/37] Remove unneeded version.h includes from include/
Em 24-06-2011 10:54, Hans Verkuil escreveu: On Friday, June 24, 2011 15:45:59 Devin Heitmueller wrote: On Fri, Jun 24, 2011 at 9:29 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: MythTV has a bunch of these too (mainly so the code can adapt to driver bugs that are fixed in later revisions). Putting Mauro's patch upstream will definitely cause breakage. It shouldn't, as ivtv driver version is lower than 3.0.0. All the old bug fixes aren't needed if version is = 3.0.0. Besides that, trusting on a driver revision number to detect that a bug is there is not the right thing to do, as version numbers are never increased at the stable kernels (nor distro modified kernels take care of increasing revision number as patches are backported there). The versions are increased at the discretion of the driver maintainer, usually when there is some userland visible change in driver behavior. I assure you the application developers don't *want* to rely on such a mechanism, but there have definitely been cases in the past where there was no easy way to detect the behavior of the driver from userland. It lets application developers work around things like violations of the V4L2 standard which get fixed in newer revisions of the driver. It provides them the ability to put a hack in their code that says if (version X) then this driver feature is broken and I shouldn't use it. Indeed. Ideally we shouldn't need it. But reality is different. What we have right now works and I see no compelling reason to change the behavior. A per-driver version only works if the user is running a vanilla kernel without any stable patches applied. I doubt that this covers the large amount of the users: they'll either use an stable patched kernel or a distribution-specific one. On both cases, the driver version is not associated with a bug fix, as the driver maintainers just take care of increasing the driver version once per each new kernel version (when they care enough). Also, a git blame for the V4L2 drivers shows that only a few drivers have their version increased as changes are applied there. So, relying on cap-version has a minimal chance of working only with a few drivers, with vanilla *.0 kernels. Anyway, I think that we should at least apply the enclosed patch, and remove KERNEL_VERSION and linux/version.h includes for the drivers that didn't change its version in the past 2 kernel releases. I'll work later on the linux/version.h cleanup patches. Cheers, Mauro - [media] v4l2-ioctl: Add a default value for kernel version Most drivers don't increase kernel versions as newer features are added or bug fixes are solved. So, vidioc_querycap returned value for cap-version is meaningless. Instead of keeping this situation forever, let's add a default value matching the current Linux version. Drivers that want to keep their own version control can still do it, as they can override the default value for cap-version. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c index 213ba7d..61ac6bf 100644 --- a/drivers/media/video/v4l2-ioctl.c +++ b/drivers/media/video/v4l2-ioctl.c @@ -16,6 +16,7 @@ #include linux/slab.h #include linux/types.h #include linux/kernel.h +#include linux/version.h #include linux/videodev2.h @@ -605,6 +606,7 @@ static long __video_do_ioctl(struct file *file, if (!ops-vidioc_querycap) break; + cap-version = LINUX_VERSION_CODE; ret = ops-vidioc_querycap(file, fh, cap); if (!ret) dbgarg(cmd, driver=%s, card=%s, bus=%s, -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] USB: EHCI: Move sysfs related bits into ehci-sysfs.c
The only sysfs attr implemented so far is companion from ehci-hub.c,
but in the next patch we are going to add another sysfs file, so prior
to that let's structure things and move already-in-there sysfs code to
separate file.
Signed-off-by: Kirill Smelkov k...@mns.spb.ru
---
drivers/usb/host/ehci-hcd.c |5 +-
drivers/usb/host/ehci-hub.c | 75
drivers/usb/host/ehci-sysfs.c | 94 +
3 files changed, 97 insertions(+), 77 deletions(-)
create mode 100644 drivers/usb/host/ehci-sysfs.c
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index e18862c..8306155 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -336,6 +336,7 @@ static void ehci_work(struct ehci_hcd *ehci);
#include ehci-mem.c
#include ehci-q.c
#include ehci-sched.c
+#include ehci-sysfs.c
/*-*/
@@ -520,7 +521,7 @@ static void ehci_stop (struct usb_hcd *hcd)
ehci_reset (ehci);
spin_unlock_irq(ehci-lock);
- remove_companion_file(ehci);
+ remove_sysfs_files(ehci);
remove_debug_files (ehci);
/* root hub is shut down separately (first, when possible) */
@@ -754,7 +755,7 @@ static int ehci_run (struct usb_hcd *hcd)
* since the class device isn't created that early.
*/
create_debug_files(ehci);
- create_companion_file(ehci);
+ create_sysfs_files(ehci);
return 0;
}
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index ea6184b..d9e8d71 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -471,29 +471,6 @@ static int ehci_bus_resume (struct usb_hcd *hcd)
/*-*/
-/* Display the ports dedicated to the companion controller */
-static ssize_t show_companion(struct device *dev,
- struct device_attribute *attr,
- char *buf)
-{
- struct ehci_hcd *ehci;
- int nports, index, n;
- int count = PAGE_SIZE;
- char*ptr = buf;
-
- ehci = hcd_to_ehci(bus_to_hcd(dev_get_drvdata(dev)));
- nports = HCS_N_PORTS(ehci-hcs_params);
-
- for (index = 0; index nports; ++index) {
- if (test_bit(index, ehci-companion_ports)) {
- n = scnprintf(ptr, count, %d\n, index + 1);
- ptr += n;
- count -= n;
- }
- }
- return ptr - buf;
-}
-
/*
* Sets the owner of a port
*/
@@ -528,58 +505,6 @@ static void set_owner(struct ehci_hcd *ehci, int portnum,
int new_owner)
}
}
-/*
- * Dedicate or undedicate a port to the companion controller.
- * Syntax is [-]portnum, where a leading '-' sign means
- * return control of the port to the EHCI controller.
- */
-static ssize_t store_companion(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t count)
-{
- struct ehci_hcd *ehci;
- int portnum, new_owner;
-
- ehci = hcd_to_ehci(bus_to_hcd(dev_get_drvdata(dev)));
- new_owner = PORT_OWNER; /* Owned by companion */
- if (sscanf(buf, %d, portnum) != 1)
- return -EINVAL;
- if (portnum 0) {
- portnum = - portnum;
- new_owner = 0; /* Owned by EHCI */
- }
- if (portnum = 0 || portnum HCS_N_PORTS(ehci-hcs_params))
- return -ENOENT;
- portnum--;
- if (new_owner)
- set_bit(portnum, ehci-companion_ports);
- else
- clear_bit(portnum, ehci-companion_ports);
- set_owner(ehci, portnum, new_owner);
- return count;
-}
-static DEVICE_ATTR(companion, 0644, show_companion, store_companion);
-
-static inline int create_companion_file(struct ehci_hcd *ehci)
-{
- int i = 0;
-
- /* with integrated TT there is no companion! */
- if (!ehci_is_TDI(ehci))
- i = device_create_file(ehci_to_hcd(ehci)-self.controller,
- dev_attr_companion);
- return i;
-}
-
-static inline void remove_companion_file(struct ehci_hcd *ehci)
-{
- /* with integrated TT there is no companion! */
- if (!ehci_is_TDI(ehci))
- device_remove_file(ehci_to_hcd(ehci)-self.controller,
- dev_attr_companion);
-}
-
-
/*-*/
static int check_reset_complete (
diff --git a/drivers/usb/host/ehci-sysfs.c b/drivers/usb/host/ehci-sysfs.c
new file mode 100644
index 000..347c8cb
--- /dev/null
+++ b/drivers/usb/host/ehci-sysfs.c
@@ -0,0 +1,94 @@
+/*
+ * Copyright (C)
[PATCH v2 2/2] USB: EHCI: Allow users to override 80% max periodic bandwidth
There are cases, when 80% max isochronous bandwidth is too limiting.
For example I have two USB video capture cards which stream uncompressed
video, and to stream full NTSC + PAL videos we'd need
NTSC 640x480 YUV422 @30fps ~17.6 MB/s
PAL 720x576 YUV422 @25fps ~19.7 MB/s
isoc bandwidth.
Now, due to limited alt settings in capture devices NTSC one ends up
streaming with max_pkt_size=2688 and PAL with max_pkt_size=2892, both
with interval=1. In terms of microframe time allocation this gives
NTSC~53us
PAL ~57us
and together
~110us100us == 80% of 125us uframe time.
So those two devices can't work together simultaneously because the'd
over allocate isochronous bandwidth.
80% seemed a bit arbitrary to me, and I've tried to raise it to 90% and
both devices started to work together, so I though sometimes it would be
a good idea for users to override hardcoded default of max 80% isoc
bandwidth.
After all, isn't it a user who should decide how to load the bus? If I
can live with 10% or even 5% bulk bandwidth that should be ok. I'm a USB
newcomer, but that 80% set in stone by USB 2.0 specification seems to be
chosen pretty arbitrary to me, just to serve as a reasonable default.
NOTE: for two streams with max_pkt_size=3072 (worst case) both time
allocation would be 60us+60us=120us which is 96% periodic bandwidth
leaving 4% for bulk and control. Alan Stern suggested that bulk then
would be problematic (less than 300*8 bittimes left per microframe), but
I think that is still enough for control traffic.
Signed-off-by: Kirill Smelkov k...@mns.spb.ru
---
drivers/usb/host/ehci-hcd.c |6 +++
drivers/usb/host/ehci-sched.c | 17 +++
drivers/usb/host/ehci-sysfs.c | 98 +++--
drivers/usb/host/ehci.h |2 +
4 files changed, 109 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 8306155..4ee62be 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -572,6 +572,12 @@ static int ehci_init(struct usb_hcd *hcd)
hcc_params = ehci_readl(ehci, ehci-caps-hcc_params);
/*
+* by default set standard 80% (== 100 usec/uframe) max periodic
+* bandwidth as required by USB 2.0
+*/
+ ehci-uframe_periodic_max = 100;
+
+ /*
* hw default: 1K periodic list heads, one per frame.
* periodic_size can shrink by USBCMD update if hcc_params allows.
*/
diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
index 6c9fbe3..2abf854 100644
--- a/drivers/usb/host/ehci-sched.c
+++ b/drivers/usb/host/ehci-sched.c
@@ -172,7 +172,7 @@ periodic_usecs (struct ehci_hcd *ehci, unsigned frame,
unsigned uframe)
}
}
#ifdef DEBUG
- if (usecs 100)
+ if (usecs ehci-uframe_periodic_max)
ehci_err (ehci, uframe %d sched overrun: %d usecs\n,
frame * 8 + uframe, usecs);
#endif
@@ -709,11 +709,8 @@ static int check_period (
if (uframe = 8)
return 0;
- /*
-* 80% periodic == 100 usec/uframe available
-* convert usecs we need to max already claimed
-*/
- usecs = 100 - usecs;
+ /* convert usecs we need to max already claimed */
+ usecs = ehci-uframe_periodic_max - usecs;
/* we know 2 and 4 uframe intervals were rejected; so
* for period 0, check _every_ microframe in the schedule.
@@ -1286,9 +1283,9 @@ itd_slot_ok (
{
uframe %= period;
do {
- /* can't commit more than 80% periodic == 100 usec */
+ /* can't commit more than uframe_periodic_max usec */
if (periodic_usecs (ehci, uframe 3, uframe 0x7)
-(100 - usecs))
+(ehci-uframe_periodic_max - usecs))
return 0;
/* we know urb-interval is 2^N uframes */
@@ -1345,7 +1342,7 @@ sitd_slot_ok (
#endif
/* check starts (OUT uses more than one) */
- max_used = 100 - stream-usecs;
+ max_used = ehci-uframe_periodic_max - stream-usecs;
for (tmp = stream-raw_mask 0xff; tmp; tmp = 1, uf++) {
if (periodic_usecs (ehci, frame, uf) max_used)
return 0;
@@ -1354,7 +1351,7 @@ sitd_slot_ok (
/* for IN, check CSPLIT */
if (stream-c_usecs) {
uf = uframe 7;
- max_used = 100 - stream-c_usecs;
+ max_used = ehci-uframe_periodic_max - stream-c_usecs;
do {
tmp = 1 uf;
tmp = 8;
diff --git a/drivers/usb/host/ehci-sysfs.c b/drivers/usb/host/ehci-sysfs.c
index 347c8cb..fe212ef 100644
--- a/drivers/usb/host/ehci-sysfs.c
+++
Re: [RFC, PATCH] USB: EHCI: Allow users to override 80% max periodic bandwidth
On Thu, Jun 23, 2011 at 01:14:04PM -0400, Alan Stern wrote: On Thu, 23 Jun 2011, Kirill Smelkov wrote: At 480 Mb/s, each microframe holds 7500 bytes (less if you count bit-stuffing). 4% of that is 300 bytes, which is not enough for a 512-byte bulk packet. I think you'd run into trouble trying to do any serious bulk transfers on such a tight schedule. Yes, you seem to be right. I still think 4% is maybe enough for control traffic. It should be. Ok then. At least devices could be start/stopped, and frankly if someone loads the bus with two high-bandwidth isoc streams, there is no reason to expect any bulk transfer to happen at all. @@ -571,6 +579,14 @@ static int ehci_init(struct usb_hcd *hcd) hcc_params = ehci_readl(ehci, ehci-caps-hcc_params); /* +* tell user, if using non-standard (80% == 100 usec/uframe) bandwidth +*/ + if (uframe_periodic_max != 100) + ehci_info(ehci, using non-standard max periodic bandwith + (%u%% == %u usec/uframe), + 100*uframe_periodic_max/125, uframe_periodic_max); + + /* Check for invalid values. This should never be less than 100 or greater than 125. Ok. By the way, why should we limit it to be not less than 100? Likewise, a user who knows exactly what he/she is doing could limit periodic bandwidth to be less than 80% required by USB specification. What's the point? If you want to use less than 80% of your bandwidth for periodic transfers, go ahead and do so. You don't need to change the limit. I though it would be good for generality -- i.e. if someone wants to limit maximum isoc bandwidth to say 50% so that would never be overallocated by that limit that would be handy. But I agree - it's a bit artificial, so in updated patch I've left what you originally suggested to be 100 = uframe_periodic_max 125 (ommitting =125). Thanks, Kirill -- 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
cx18 init lockdep spew
I only just recently acquired a Hauppauge HVR-1600 cards, and at least both
2.6.39 and 3.0-rc4 kernels with copious debug spew enabled spit out the
lockdep spew included below. Haven't looked into it at all yet, but I
thought I'd ask before I do if it is already a known issue.
[ 11.856504] Linux video capture interface: v2.00
[ 12.306435] cx18: Start initialization, version 1.5.0
[ 12.308789] cx18-0: Initializing card 0
[ 12.310751] cx18-0: Autodetected Hauppauge card
[ 12.313403] cx18 :02:04.0: PCI INT A - GSI 18 (level, low) - IRQ 18
[ 12.346552] cx18-0: cx23418 revision 0101 (B)
[ 12.437931]
[ 12.437933] =
[ 12.438014] [ INFO: possible recursive locking detected ]
[ 12.438014] 3.0.0-rc4+ #15
[ 12.438014] -
[ 12.438014] work_for_cpu/743 is trying to acquire lock:
[ 12.438014] (hdl-lock){+.+.+.}, at: [a02403e2]
handler_new_ref+0xe9/0x183 [videodev]
[ 12.438014]
[ 12.438014] but task is already holding lock:
[ 12.438014] (hdl-lock){+.+.+.}, at: [a02404c5]
v4l2_ctrl_add_handler+0x49/0x8e [videodev]
[ 12.438014]
[ 12.438014] other info that might help us debug this:
[ 12.438014] Possible unsafe locking scenario:
[ 12.438014]
[ 12.438014]CPU0
[ 12.438014]
[ 12.438014] lock(hdl-lock);
[ 12.438014] lock(hdl-lock);
[ 12.438014]
[ 12.438014] *** DEADLOCK ***
[ 12.438014]
[ 12.438014] May be due to missing lock nesting notation
[ 12.438014]
[ 12.438014] 1 lock held by work_for_cpu/743:
[ 12.438014] #0: (hdl-lock){+.+.+.}, at: [a02404c5]
v4l2_ctrl_add_handler+0x49/0x8e [videodev]
[ 12.438014]
[ 12.438014] stack backtrace:
[ 12.438014] Pid: 743, comm: work_for_cpu Not tainted 3.0.0-rc4+ #15
[ 12.438014] Call Trace:
[ 12.438014] [81087815] __lock_acquire+0x917/0xcf7
[ 12.438014] [810849d6] ? trace_hardirqs_off+0xd/0xf
[ 12.438014] [81084f1a] ? lock_release_holdtime.part.8+0x6b/0x72
[ 12.438014] [a02403e2] ? handler_new_ref+0xe9/0x183 [videodev]
[ 12.438014] [81088082] lock_acquire+0xbf/0x103
[ 12.438014] [a02403e2] ? handler_new_ref+0xe9/0x183 [videodev]
[ 12.438014] [81088358] ? mark_held_locks+0x4b/0x6d
[ 12.438014] [a02403e2] ? handler_new_ref+0xe9/0x183 [videodev]
[ 12.438014] [814c9ae2] __mutex_lock_common+0x4c/0x361
[ 12.438014] [a02403e2] ? handler_new_ref+0xe9/0x183 [videodev]
[ 12.438014] [a024026d] ? kzalloc.constprop.15+0x13/0x15 [videodev]
[ 12.438014] [811241f1] ? __kmalloc+0xfa/0x10c
[ 12.438014] [814c9f06] mutex_lock_nested+0x40/0x45
[ 12.438014] [a02403e2] handler_new_ref+0xe9/0x183 [videodev]
[ 12.438014] [a02404e0] v4l2_ctrl_add_handler+0x64/0x8e [videodev]
[ 12.438014] [a023d6c5] v4l2_device_register_subdev+0xcb/0x141
[videodev]
[ 12.438014] [a0291e64] cx18_av_probe+0x291/0x2bd [cx18]
[ 12.438014] [814ca03b] ? mutex_unlock+0xe/0x10
[ 12.438014] [a0295623] cx18_probe+0xd43/0x1343 [cx18]
[ 12.438014] [814cb5f8] ? _raw_spin_unlock_irqrestore+0x45/0x52
[ 12.438014] [814cb600] ? _raw_spin_unlock_irqrestore+0x4d/0x52
[ 12.438014] [8106d0b8] ? move_linked_works+0x6e/0x6e
[ 12.438014] [812720b2] local_pci_probe+0x44/0x75
[ 12.438014] [8106d0ce] do_work_for_cpu+0x16/0x28
[ 12.438014] [8107344d] kthread+0xa8/0xb0
[ 12.438014] [814d3324] kernel_thread_helper+0x4/0x10
[ 12.438014] [814cb9d4] ? retint_restore_args+0x13/0x13
[ 12.438014] [810733a5] ? __init_kthread_worker+0x5a/0x5a[
12.438014] [814d3320] ? gs_change+0x13/0x13
[ 12.663073] tveeprom 6-0050: Hauppauge model 74021, rev C1B2, serial#
1561046[ 12.664488] tveeprom 6-0050: MAC address is 00:0d:fe:17:d1:d6
[ 12.665871] tveeprom 6-0050: tuner model is TCL M2523_5N_E (idx 112, type 50)
[ 12.667299] tveeprom 6-0050: TV standards NTSC(M) (eeprom 0x08)
[ 12.668749] tveeprom 6-0050: audio processor is CX23418 (idx 38)
[ 12.670207] tveeprom 6-0050: decoder processor is CX23418 (idx 31)
[ 12.671694] tveeprom 6-0050: has no radio, has IR receiver, has IR
transmitter
[ 12.673218] cx18-0: Autodetected Hauppauge HVR-1600
[ 12.674752] cx18-0: Simultaneous Digital and Analog TV capture supported[
12.824476] i2c-core: driver [tuner] using legacy suspend method
[ 12.826135] i2c-core: driver [tuner] using legacy resume method
[ 12.843402] tuner 7-0061: Tuner -1 found with type(s) Radio TV.
[ 12.878152] cs5345 6-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
[ 12.952064] tuner-simple 7-0061: creating new instance
[ 12.953712] tuner-simple 7-0061: type set to 50 (TCL 2002N)
[ 12.967854] cx18-0: Registered device video0 for encoder MPEG (64 x 32.00 kB)
[ 12.969552] DVB: registering new
[PATCH] [media] Stop using linux/version.h on most drivers
All the modified drivers didn't have any version increment since Jan, 1 2011. Several of them didn't have any version increment for a long time, even having new features and important bug fixes happening. As we're now filling the QUERYCAP version with the current Kernel Release, we don't need to maintain a per-driver version control anymore. So, let's just use the default. In order to preserve the Kernel module version history, a KERNEL_VERSION() macro were added to all modified drivers, and the extraver number were incremented. I opted to preserve the per-driver version control to a few drivers: cx18, davinci, fsl-viu, gspca, ivtv, m5mols, soc_camera, pwc, s2255, s5p-fimc and sh_vou. The rationale is that the per-driver version control seems to be actively maintained on those. A few drivers are still using the legacy way to handle ioctl's. So, we can't do such change on them, otherwise, they'll break. Those are: uvc, pvrusb2, et61x251 and sn9c102. Yet, I think that the better for them would be to just use the default version numbering, instead of doing that by themselves. While here, removed a few not needed include linux/version.h. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- Note: This patch assumes that cap-version = LINUX_VERSION_CODE is filled inside v4l2-ioctl [1] [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg33547.html drivers/media/video/arv.c |5 ++--- drivers/media/video/au0828/au0828-core.c|1 + drivers/media/video/au0828/au0828-video.c |5 - drivers/media/video/bt8xx/bttv-driver.c | 14 -- drivers/media/video/bt8xx/bttvp.h |3 --- drivers/media/video/bw-qcam.c |3 +-- drivers/media/video/c-qcam.c|3 +-- drivers/media/video/cpia2/cpia2.h |5 - drivers/media/video/cpia2/cpia2_v4l.c | 12 drivers/media/video/cx231xx/cx231xx-video.c | 14 -- drivers/media/video/cx231xx/cx231xx.h |1 - drivers/media/video/cx23885/altera-ci.c |1 - drivers/media/video/cx23885/cx23885-417.c |1 - drivers/media/video/cx23885/cx23885-core.c | 13 +++-- drivers/media/video/cx23885/cx23885-video.c |1 - drivers/media/video/cx23885/cx23885.h |3 +-- drivers/media/video/cx88/cx88-alsa.c| 19 --- drivers/media/video/cx88/cx88-blackbird.c | 20 +++- drivers/media/video/cx88/cx88-dvb.c | 18 +++--- drivers/media/video/cx88/cx88-mpeg.c| 11 +++ drivers/media/video/cx88/cx88-video.c | 21 +++-- drivers/media/video/cx88/cx88.h |4 ++-- drivers/media/video/em28xx/em28xx-video.c | 14 +- drivers/media/video/gspca/gl860/gl860.h |1 - drivers/media/video/hdpvr/hdpvr-core.c |1 + drivers/media/video/hdpvr/hdpvr-video.c |2 -- drivers/media/video/hdpvr/hdpvr.h |6 -- drivers/media/video/mem2mem_testdev.c |4 +--- drivers/media/video/pms.c |4 +--- drivers/media/video/pwc/pwc-ioctl.h |1 - drivers/media/video/pwc/pwc.h |8 drivers/media/video/saa7134/saa7134-core.c | 12 drivers/media/video/saa7134/saa7134-empress.c |1 - drivers/media/video/saa7134/saa7134-video.c |2 -- drivers/media/video/saa7134/saa7134.h |3 +-- drivers/media/video/saa7164/saa7164.h |1 - drivers/media/video/timblogiw.c |1 - drivers/media/video/tlg2300/pd-common.h |1 - drivers/media/video/tlg2300/pd-main.c |1 + drivers/media/video/tlg2300/pd-radio.c |2 -- drivers/media/video/usbvision/usbvision-video.c | 12 +--- drivers/media/video/vino.c |5 + drivers/media/video/vivi.c | 14 -- drivers/media/video/w9966.c |4 +--- drivers/media/video/zoran/zoran.h |4 drivers/media/video/zoran/zoran_card.c |7 +-- drivers/media/video/zoran/zoran_driver.c|3 --- drivers/media/video/zr364xx.c |6 ++ 48 files changed, 71 insertions(+), 227 deletions(-) diff --git a/drivers/media/video/arv.c b/drivers/media/video/arv.c index f989f28..b6ed44a 100644 --- a/drivers/media/video/arv.c +++ b/drivers/media/video/arv.c @@ -27,7 +27,6 @@ #include linux/slab.h #include linux/mm.h #include linux/sched.h -#include linux/version.h #include linux/videodev2.h #include media/v4l2-common.h #include media/v4l2-device.h @@ -54,7 +53,7 @@ */ #define USE_INT0 /* Don't modify */ -#define VERSION0.04 +#define VERSION0.0.5 #define
Re: [RFC] Don't use linux/version.h anymore to indicate a per-driver version - Was: Re: [PATCH 03/37] Remove unneeded version.h includes from include/
On Jun 24 Mauro Carvalho Chehab wrote: Em 24-06-2011 10:54, Hans Verkuil escreveu: On Friday, June 24, 2011 15:45:59 Devin Heitmueller wrote: The versions are increased at the discretion of the driver maintainer, usually when there is some userland visible change in driver behavior. I assure you the application developers don't *want* to rely on such a mechanism, but there have definitely been cases in the past where there was no easy way to detect the behavior of the driver from userland. It lets application developers work around things like violations of the V4L2 standard which get fixed in newer revisions of the driver. It provides them the ability to put a hack in their code that says if (version X) then this driver feature is broken and I shouldn't use it. Indeed. Ideally we shouldn't need it. But reality is different. What we have right now works and I see no compelling reason to change the behavior. A per-driver version only works if the user is running a vanilla kernel without any stable patches applied. I doubt that this covers the large amount of the users: they'll either use an stable patched kernel or a distribution-specific one. On both cases, the driver version is not associated with a bug fix, as the driver maintainers just take care of increasing the driver version once per each new kernel version (when they care enough). Also, a git blame for the V4L2 drivers shows that only a few drivers have their version increased as changes are applied there. So, relying on cap-version has a minimal chance of working only with a few drivers, with vanilla *.0 kernels. If the driver version is in fact an ABI version, then the driver author should really increase it only when ABI behavior is changed (and only if the behavior change can only be communicated by version number --- e.g. addition of an ioctl is not among such reasons). And the author should commit behavior changing implementation and version number change in a single changeset. And anybody who backmerges such an ABI behavior change into another kernel branch (stable, longterm, distro...) must backmerge the associated version number change too. Of course sometimes people realize this only after the fact. Or driver authors don't have a clear understanding of ABI versioning to begin with. I am saying so because I had to learn it too; I certainly wasn't born with an instinct knowledge how to do it properly. (Disclaimer: I have no stake in drivers/media/ ABIs. But I am involved in maintaining a userspace ABI elsewhere in drivers/firewire/, and one of the userspace libraries that use this ABI.) -- Stefan Richter -=-==-== -==- ==--- http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri Jun 24 19:00:35 CEST 2011 git hash:7023c7dbc3944f42aa1d6910a6098c5f9e23d3f1 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS 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-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 spec-git: ERRORS 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
Re: [RFC] Don't use linux/version.h anymore to indicate a per-driver version - Was: Re: [PATCH 03/37] Remove unneeded version.h includes from include/
On Fri, Jun 24, 2011 at 2:34 PM, Stefan Richter stef...@s5r6.in-berlin.de wrote: If the driver version is in fact an ABI version, then the driver author should really increase it only when ABI behavior is changed (and only if the behavior change can only be communicated by version number --- e.g. addition of an ioctl is not among such reasons). And the author should commit behavior changing implementation and version number change in a single changeset. And anybody who backmerges such an ABI behavior change into another kernel branch (stable, longterm, distro...) must backmerge the associated version number change too. Of course sometimes people realize this only after the fact. Or driver authors don't have a clear understanding of ABI versioning to begin with. I am saying so because I had to learn it too; I certainly wasn't born with an instinct knowledge how to do it properly. (Disclaimer: I have no stake in drivers/media/ ABIs. But I am involved in maintaining a userspace ABI elsewhere in drivers/firewire/, and one of the userspace libraries that use this ABI.) Hi Stefan, To be clear, I don't think anyone is actually proposing that the driver version number really be used as any form of formal ABI versioning scheme. In almost all cases, it's so the application can know to *not* do something is the driver is older than X. Given all the cases I've seen, it doesn't really hurt anything if the driver contains a fix from newer than X, aside from the fact that the application won't take advantage of whatever feature/functionality the fix made work. In other words, I think from a backport standpoint, it usually doesn't *hurt* anything if a fix is backported without the version being incremented, aside from applications not knowing that the feature/fix is present. Really, this is all about applications being able to jam a hack into their code that translates to don't call this ioctl() with some particular argument if it's driver W less than version X, because the driver had a bug that is likely to panic the guy's PC. Sure, it's a crummy solution, but at this point it's the best that we have got. 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: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
On Fri, Jun 24, 2011 at 08:19, Paul Mundt let...@linux-sh.org wrote:
On Thu, Jun 23, 2011 at 06:08:03PM +0200, Geert Uytterhoeven wrote:
On Wed, Jun 22, 2011 at 07:45, Florian Tobias Schandinat
florianschandi...@gmx.de wrote:
On 06/21/2011 10:31 PM, Laurent Pinchart wrote:
On Tuesday 21 June 2011 22:49:14 Geert Uytterhoeven wrote:
As FOURCC values are always 4 ASCII characters (hence all 4 bytes must
be non-zero), I don't think there are any conflicts with existing values
of
nonstd. To make it even safer and easier to parse, you could set bit 31
of
nonstd as a FOURCC indicator.
I would then create a union between nonstd and fourcc, and document nonstd
as
being used for the legacy API only. Most existing drivers use a couple of
nonstd bits only. The driver that (ab)uses nonstd the most is pxafb and
uses
bits 22:0. Bits 31:24 are never used as far as I can tell, so nonstd
0xff00 != 0 could be used as a FOURCC mode test.
This assumes that FOURCCs will never have their last character set to
'\0'. Is
that a safe assumption for the future ?
Yes, I think. The information I found indicates that space should be used
for padding, so a \0 shouldn't exist.
I think using only the nonstd field and requiring applications to check the
capabilities would be possible, although not fool proof ;)
So we can declare the 8 msb bits of nonstd reserved, and assume FOURCC if
any of them is set.
Nicely backwards compatible, as sane drivers should reject nonstd values they
don't support (apps _will_ start filling in FOURCC values ignoring
capabilities,
won't they?).
That seems like a reasonable case, but if we're going to do that then
certainly the nonstd bit encoding needs to be documented and treated as a
hard ABI.
I'm not so sure about the if any bit in the upper byte is set assume
FOURCC case though, there will presumably be other users in the future
that will want bits for themselves, too. What exactly was the issue with
having a FOURCC capability bit in the upper byte?
That indeed gives less issues (as long as you don't stuff 8-bit ASCII
in the MSB)
and more bits for tradiditional nonstd users.
BTW, after giving it some more thought: what does the FB_CAP_FOURCC buys
us? It's not like all drivers will support whatever random FOURCC mode
you give them,
so you have to check whether it's supported by doing a set_var first.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
On 06/24/2011 06:55 PM, Geert Uytterhoeven wrote: On Fri, Jun 24, 2011 at 08:19, Paul Mundtlet...@linux-sh.org wrote: On Thu, Jun 23, 2011 at 06:08:03PM +0200, Geert Uytterhoeven wrote: On Wed, Jun 22, 2011 at 07:45, Florian Tobias Schandinat florianschandi...@gmx.de wrote: On 06/21/2011 10:31 PM, Laurent Pinchart wrote: On Tuesday 21 June 2011 22:49:14 Geert Uytterhoeven wrote: As FOURCC values are always 4 ASCII characters (hence all 4 bytes must be non-zero), I don't think there are any conflicts with existing values of nonstd. To make it even safer and easier to parse, you could set bit 31 of nonstd as a FOURCC indicator. I would then create a union between nonstd and fourcc, and document nonstd as being used for the legacy API only. Most existing drivers use a couple of nonstd bits only. The driver that (ab)uses nonstd the most is pxafb and uses bits 22:0. Bits 31:24 are never used as far as I can tell, so nonstd 0xff00 != 0 could be used as a FOURCC mode test. This assumes that FOURCCs will never have their last character set to '\0'. Is that a safe assumption for the future ? Yes, I think. The information I found indicates that space should be used for padding, so a \0 shouldn't exist. I think using only the nonstd field and requiring applications to check the capabilities would be possible, although not fool proof ;) So we can declare the 8 msb bits of nonstd reserved, and assume FOURCC if any of them is set. Nicely backwards compatible, as sane drivers should reject nonstd values they don't support (apps _will_ start filling in FOURCC values ignoring capabilities, won't they?). That seems like a reasonable case, but if we're going to do that then certainly the nonstd bit encoding needs to be documented and treated as a hard ABI. I'm not so sure about the if any bit in the upper byte is set assume FOURCC case though, there will presumably be other users in the future that will want bits for themselves, too. What exactly was the issue with having a FOURCC capability bit in the upper byte? That indeed gives less issues (as long as you don't stuff 8-bit ASCII in the MSB) and more bits for tradiditional nonstd users. The only disadvantage I can see is that it requires adding this bit in the application and stripping it when interpreting it. But I think the 24 lower bits should be enough for driver specific behavior (as the current values really can only be interpreted per driver). BTW, after giving it some more thought: what does the FB_CAP_FOURCC buys us? It's not like all drivers will support whatever random FOURCC mode you give them, so you have to check whether it's supported by doing a set_var first. Because any solution purely based on the nonstd field is insane. The abuse of that field is just too widespread. Drivers that use nonstd usually only check whether it is zero or nonzero and others will just interpret parts of nonstd and ignore the rest. They will happily accept FOURCC values in the nonstd and just doing the wrong thing. Even if we would fix those the problems applications will run into with older kernels will remain. Greetings, Florian Tobias Schandinat -- 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
[RFC] vb2: Push buffer allocation and freeing into drivers
Here's a little something I decided to hack on rather than addressing all
the real work I have to do.
Videobuf2 currently manages buffer allocation for drivers, even though
drivers typically encapsulate the vb2_buffer instance in a larger
structure; that requires vb2 to know the driver's structure size and
imposes a fragile the vb2_buffer field must be first requirement.
This patch pushes buffer allocation and freeing down into the drivers,
which is where the real knowledge of the structure layout exists. To that
end, buffer_init() has been renamed buffer_alloc(), and it is called at
the beginning of the process. As it happens, no in-tree driver depends on
any kind of central initialization in its buffer_init() function, so this
move causes no problems.
The patch deletes almost as much code as it adds; in particular, error
handling gets simpler. It's compile-tested on everything I could, and run
tested with vivi and mmp-camera. The patch is against linuxtv/for_v3.1,
so it doesn't include the mmp-camera hunks (since videobuf2 support for
that driver isn't upstream yet.)
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/mem2mem_testdev.c | 20 ++-
drivers/media/video/mx3_camera.c| 19 +-
drivers/media/video/s5p-fimc/fimc-capture.c | 18 --
drivers/media/video/s5p-fimc/fimc-core.c| 20 ++-
drivers/media/video/sh_mobile_ceu_camera.c | 20 ++-
drivers/media/video/videobuf2-core.c| 49 ++-
drivers/media/video/vivi.c | 16 +---
include/media/videobuf2-core.h | 16 -
8 files changed, 98 insertions(+), 80 deletions(-)
diff --git a/drivers/media/video/mem2mem_testdev.c
b/drivers/media/video/mem2mem_testdev.c
index b03d74e..05d8f62 100644
--- a/drivers/media/video/mem2mem_testdev.c
+++ b/drivers/media/video/mem2mem_testdev.c
@@ -789,6 +789,22 @@ static int m2mtest_buf_prepare(struct vb2_buffer *vb)
return 0;
}
+static struct vb2_buffer *m2mtest_buf_alloc(struct vb2_queue *q)
+{
+ struct v4l2_m2m_buffer *buf;
+
+ buf = kzalloc(sizeof(*buf), GFP_KERNEL);
+ if (buf == NULL)
+ return NULL;
+ return buf-vb;
+}
+
+static void m2mtest_buf_cleanup(struct vb2_buffer *vb)
+{
+ kfree(container_of(vb, struct v4l2_m2m_buffer, vb));
+}
+
+
static void m2mtest_buf_queue(struct vb2_buffer *vb)
{
struct m2mtest_ctx *ctx = vb2_get_drv_priv(vb-vb2_queue);
@@ -797,6 +813,8 @@ static void m2mtest_buf_queue(struct vb2_buffer *vb)
static struct vb2_ops m2mtest_qops = {
.queue_setup = m2mtest_queue_setup,
+ .buf_alloc = m2mtest_buf_alloc,
+ .buf_cleanup = m2mtest_buf_cleanup,
.buf_prepare = m2mtest_buf_prepare,
.buf_queue = m2mtest_buf_queue,
};
@@ -810,7 +828,6 @@ static int queue_init(void *priv, struct vb2_queue *src_vq,
struct vb2_queue *ds
src_vq-type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
src_vq-io_modes = VB2_MMAP;
src_vq-drv_priv = ctx;
- src_vq-buf_struct_size = sizeof(struct v4l2_m2m_buffer);
src_vq-ops = m2mtest_qops;
src_vq-mem_ops = vb2_vmalloc_memops;
@@ -822,7 +839,6 @@ static int queue_init(void *priv, struct vb2_queue *src_vq,
struct vb2_queue *ds
dst_vq-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
dst_vq-io_modes = VB2_MMAP;
dst_vq-drv_priv = ctx;
- dst_vq-buf_struct_size = sizeof(struct v4l2_m2m_buffer);
dst_vq-ops = m2mtest_qops;
dst_vq-mem_ops = vb2_vmalloc_memops;
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index c7680eb..fc981d4 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -68,7 +68,6 @@ enum csi_buffer_state {
};
struct mx3_camera_buffer {
- /* common v4l buffer stuff -- must be first */
struct vb2_buffer vb;
enum csi_buffer_state state;
struct list_headqueue;
@@ -374,10 +373,6 @@ static void mx3_videobuf_release(struct vb2_buffer *vb)
if (mx3_cam-active == buf)
mx3_cam-active = NULL;
- /* Doesn't hurt also if the list is empty */
- list_del_init(buf-queue);
- buf-state = CSI_BUF_NEEDS_INIT;
-
if (txd) {
buf-txd = NULL;
if (mx3_cam-idmac_channel[0])
@@ -385,11 +380,16 @@ static void mx3_videobuf_release(struct vb2_buffer *vb)
}
spin_unlock_irqrestore(mx3_cam-lock, flags);
+ kfree(buf);
}
-static int mx3_videobuf_init(struct vb2_buffer *vb)
+static struct vb2_buffer *mx3_videobuf_alloc(struct vb2_queue *q)
{
- struct mx3_camera_buffer *buf = to_mx3_vb(vb);
+ struct mx3_camera_buffer *buf;
+
+ buf = kzalloc(sizeof(*buf), GFP_KERNEL);
+ if (buf == NULL)
+ return NULL;
/* This is for locking debugging
The return value of __vb2_queue_alloc()
On Fri, 24 Jun 2011 14:19:27 -0600
Jonathan Corbet cor...@lwn.net wrote:
Here's a little something I decided to hack on rather than addressing all
the real work I have to do.
...and while I was looking at this code, I noticed one little curious
thing:
int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req)
{
/* ... */
/* Finally, allocate buffers and video memory */
ret = __vb2_queue_alloc(q, req-memory, num_buffers, num_planes,
plane_sizes);
if (ret 0) {
dprintk(1, Memory allocation failed with error: %d\n, ret);
return ret;
}
If you actually look at __vb2_queue_alloc(), it claims to return the
number of buffers actually allocated, and an inspection of the code bears
up that claim. So it can never return a negative value. Do you maybe
want if (ret = 0) { there instead? One assumes there will be few
drivers so accommodating as to work with zero buffers.
Thanks,
jon
--
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] Don't use linux/version.h anymore to indicate a per-driver version - Was: Re: [PATCH 03/37] Remove unneeded version.h includes from include/
On Fri, 2011-06-24 at 14:48 -0400, Devin Heitmueller wrote: On Fri, Jun 24, 2011 at 2:34 PM, Stefan Richter stef...@s5r6.in-berlin.de wrote: If the driver version is in fact an ABI version, then the driver author should really increase it only when ABI behavior is changed (and only if the behavior change can only be communicated by version number --- e.g. addition of an ioctl is not among such reasons). And the author should commit behavior changing implementation and version number change in a single changeset. And anybody who backmerges such an ABI behavior change into another kernel branch (stable, longterm, distro...) must backmerge the associated version number change too. Of course sometimes people realize this only after the fact. Or driver authors don't have a clear understanding of ABI versioning to begin with. I am saying so because I had to learn it too; I certainly wasn't born with an instinct knowledge how to do it properly. (Disclaimer: I have no stake in drivers/media/ ABIs. But I am involved in maintaining a userspace ABI elsewhere in drivers/firewire/, and one of the userspace libraries that use this ABI.) Hi Stefan, To be clear, I don't think anyone is actually proposing that the driver version number really be used as any form of formal ABI versioning scheme. In almost all cases, it's so the application can know to *not* do something is the driver is older than X. MythTV, for example, used to use the driver version to work around old VBI bugs and MPEG encoder quirks that the older version of the driver may not have known how to handle: https://github.com/MythTV/mythtv/blob/b98d3a98e3187000ae652df5ffebe2beb5221ba7/mythtv/libs/libmythtv/mpegrecorder.cpp#L335 But for newer versions, MythTV could avoid using its own odd hacks. The bleeding edge MythTV now has most of these removed. Given all the cases I've seen, it doesn't really hurt anything if the driver contains a fix from newer than X, aside from the fact that the application won't take advantage of whatever feature/functionality the fix made work. In other words, I think from a backport standpoint, it usually doesn't *hurt* anything if a fix is backported without the version being incremented, aside from applications not knowing that the feature/fix is present. That seems to be the case to me. Really, this is all about applications being able to jam a hack into their code that translates to don't call this ioctl() with some particular argument if it's driver W less than version X, because the driver had a bug that is likely to panic the guy's PC. Well, not even panics per se, but some thing like the VBI is broken, or the volume control doesn't work, IR blaster is works for this version, or something else stupid that is very visible to the end user. I also use the driver version for troubleshooting problem with users. I roughly know what wasn't working in what version of the cx18 and ivtv drivers. If the end user can tell me the driver version (using v4l2-ctl --log-status) along with his symptoms, it makes my life easier. Being able to efficiently help the end user is a win for both me and the end user. Sure, it's a crummy solution, but at this point it's the best that we have got Yup. We do have crummier solutions: Telling the end user to read their kernel source code to figure out what bugs their driver release has, and to then adjust their application command line arguments accordingly. ;) 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: [RFC] Don't use linux/version.h anymore to indicate a per-driver version - Was: Re: [PATCH 03/37] Remove unneeded version.h includes from include/
On Jun 24 Devin Heitmueller wrote: Really, this is all about applications being able to jam a hack into their code that translates to don't call this ioctl() with some particular argument if it's driver W less than version X, because the driver had a bug that is likely to panic the guy's PC. Sure, it's a crummy solution, but at this point it's the best that we have got. The second best. The best that we have got is that the user runs a fixed kernel. Anyway; if this is the only purpose that this interface version¹ serves, then Mauro's subsystem-centralized solution has the benefit that it eliminates mistakes due to oversight by individual driver authors. Especially because the kind of implementation behavior changes that are tracked by this type of version datum are sometimes just discovered or documented in hindsight. On the other hand, Mauro's solution is redundant to the uname(2) syscall. ¹) Yes, it is still an ABI version, nothing less. With all its backwards and forwards compatibility ramifications. -- Stefan Richter -=-==-== -==- ==--- http://arcgraph.de/sr/ -- 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] Don't use linux/version.h anymore to indicate a per-driver version - Was: Re: [PATCH 03/37] Remove unneeded version.h includes from include/
On Jun 24 Andy Walls wrote: I also use the driver version for troubleshooting problem with users. I roughly know what wasn't working in what version of the cx18 and ivtv drivers. If the end user can tell me the driver version (using v4l2-ctl --log-status) along with his symptoms, it makes my life easier. Easier: I run Ubuntu 10.4. I run kernel 2.6.32. One of these is usually already included in the first post or IRC message from the user. Separate driver versions are only needed on platforms where drivers are not distributed by the operating system distributor, or driver source code is not released within kernel source code. -- Stefan Richter -=-==-== -==- ==--- http://arcgraph.de/sr/ -- 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] Don't use linux/version.h anymore to indicate a per-driver version - Was: Re: [PATCH 03/37] Remove unneeded version.h includes from include/
On Fri, Jun 24, 2011 at 5:20 PM, Stefan Richter stef...@s5r6.in-berlin.de wrote: Easier: I run Ubuntu 10.4. I run kernel 2.6.32. One of these is usually already included in the first post or IRC message from the user. Separate driver versions are only needed on platforms where drivers are not distributed by the operating system distributor, or driver source code is not released within kernel source code. Unfortunately, this doesn't work as all too often the user has Ubuntu 10.1 but I installed the latest media_build tree a few months ago. Hence they are not necessarily on a particular binary release from a distro but rather have a mix of a distro's binary release and a v4l-dvb tree compiled from source. 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: cx18 init lockdep spew
On Fri, 2011-06-24 at 13:39 -0400, Jarod Wilson wrote: I only just recently acquired a Hauppauge HVR-1600 cards, and at least both 2.6.39 and 3.0-rc4 kernels with copious debug spew enabled spit out the lockdep spew included below. Haven't looked into it at all yet, but I thought I'd ask before I do if it is already a known issue. Why, yes, it is. See comments 11-13 of this bug assigned to Jarod Wilson in Dec 2010: https://bugzilla.redhat.com/show_bug.cgi?id=662384 Also please ask ja...@redhat.com to send you some off-list emails he received from me on 21-22 Dec 2010. ;) Oh, look, some nice fellow submitted a patch to get rid of the false alarms: http://www.mail-archive.com/linux-media@vger.kernel.org/msg26097.html https://patchwork.kernel.org/patch/431311/ ;) I'm not sure if it still applies cleanly, but it's not that hard to grok. The lockdep happiness comes from the lock being initialized in a macro. That is what's critical to spread all lock instances from one class into many individual classes for lockdep. The issue is the control handling framework creates instances where the bridge driver acquires its own control handler lock and subsequently a subdev driver lock (or maybe the other way around). Since the framework instantiated all the handler locks in the same common function, lockdep considers them one class and can't/won't think of them as different. If you don't like my patch above, you can try some magic lockdep calls in v4l2_ctrl_add_handler() to make lockdep ignore that particular recursion for the hdl-lock lock class (for a depth of 1?), knowing that it is allowed. For reference: http://lkml.org/lkml/2009/9/2/83 I'm pretty sure mutex_lock_nested(...-lock, 1) is what we needed in v4l2_ctrl_add_handler(). Here is a DVB and I2C related use of mutex_lock_nested() that was added some years ago: http://www.jikos.cz/~jikos/dev/lockdep_fix_recursive_i2c_transfer.patch It is different from our current use case, in that the lock ordering relationship was well defined. I think that I2C lock class recursion in DVB could have been solved better with lock class annotations vs. nesting. 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: [RFC] Don't use linux/version.h anymore to indicate a per-driver version - Was: Re: [PATCH 03/37] Remove unneeded version.h includes from include/
Em 24-06-2011 15:34, Stefan Richter escreveu: On Jun 24 Mauro Carvalho Chehab wrote: Em 24-06-2011 10:54, Hans Verkuil escreveu: On Friday, June 24, 2011 15:45:59 Devin Heitmueller wrote: The versions are increased at the discretion of the driver maintainer, usually when there is some userland visible change in driver behavior. I assure you the application developers don't *want* to rely on such a mechanism, but there have definitely been cases in the past where there was no easy way to detect the behavior of the driver from userland. It lets application developers work around things like violations of the V4L2 standard which get fixed in newer revisions of the driver. It provides them the ability to put a hack in their code that says if (version X) then this driver feature is broken and I shouldn't use it. Indeed. Ideally we shouldn't need it. But reality is different. What we have right now works and I see no compelling reason to change the behavior. A per-driver version only works if the user is running a vanilla kernel without any stable patches applied. I doubt that this covers the large amount of the users: they'll either use an stable patched kernel or a distribution-specific one. On both cases, the driver version is not associated with a bug fix, as the driver maintainers just take care of increasing the driver version once per each new kernel version (when they care enough). Also, a git blame for the V4L2 drivers shows that only a few drivers have their version increased as changes are applied there. So, relying on cap-version has a minimal chance of working only with a few drivers, with vanilla *.0 kernels. If the driver version is in fact an ABI version, then the driver author should really increase it only when ABI behavior is changed (and only if the behavior change can only be communicated by version number --- e.g. addition of an ioctl is not among such reasons). And the author should commit behavior changing implementation and version number change in a single changeset. Yes, but driver version were never used as such. Several drivers got lots of updates, ABI change behavior (like the removal of V4L1 API), etc without having a single driver version increment. Other drivers increase it even on minor changes. IMO, it makes no sense on keeping it, but removing this field would break userspace, as a few programs seem to use it. And anybody who backmerges such an ABI behavior change into another kernel branch (stable, longterm, distro...) must backmerge the associated version number change too. Yes, but, again, this doesn't happen. In general, the drivers that use it either increment the version number on a separate patch, or integrate it with one of the patches. It is easy to take a look at ivtv, as it has a separate file with the version number: $ git log --oneline drivers/media/video/ivtv/ivtv-version.h 4359e5b V4L/DVB: ivtv: Increment driver version due to firmware loading changes c019f90 V4L/DVB (10965): ivtv: bump version c58dc0b V4L/DVB (8633): ivtv: update ivtv version number be303e1 V4L/DVB (7930): ivtv: bump version to 1.3.0. fcbbf6f V4L/DVB (7759): ivtv: increase version number to 1.2.1 0170a48 V4L/DVB (6762): ivtv: update version number to 1.2 612570f V4L/DVB (6091): ivtv: header cleanup f38a798 V4L/DVB (5909): ivtv: update version to 1.1 to mark ivtv-fb support 1a0adaf V4L/DVB (5345): ivtv driver for Conexant cx23416/cx23415 MPEG encoder/decoder Looking at the details of the above commits, on several cases there's no explanation why the version was incremented, or why an userspace application should bother to have any special treatment for that version or for the previous one. The date of the commits also don't help much: Date: Sat Jun 12 13:55:33 2010 -0300 Date: Wed Mar 11 18:50:04 2009 -0300 Date: Wed Sep 3 16:46:58 2008 -0300 Date: Sat May 24 12:43:43 2008 -0300 Date: Sat Apr 26 09:43:22 2008 -0300 Date: Fri Dec 7 20:31:17 2007 -0300 Date: Thu Aug 23 05:42:59 2007 -0300 Date: Sun Jul 22 08:39:43 2007 -0300 Date: Fri Apr 27 12:31:25 2007 -0300 Even when there seems to have a good reason for version bump, like on this example (from cx18 driver): commit 9982be8 Author: Andy Walls awa...@radix.net Date: Wed Apr 15 20:49:19 2009 -0300 V4L/DVB (11620): cx18: Increment version due to significant buffer handling changes Version bump from 1.1.0 to 1.2.0 Signed-off-by: Andy Walls awa...@radix.net Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com The commit message doesn't help to tell the application developer how version 1.1.0 is different than version 1.2.0. Also, as this is on a separate commit, if the buffer changes were backported into a stable or distro kernel, the application will have no way to detect the differences. On several cases, the version upgrade is simply due to the addition of a new type of support, like this one: commit 437b775
Re: [RFC] Don't use linux/version.h anymore to indicate a per-driver version - Was: Re: [PATCH 03/37] Remove unneeded version.h includes from include/
Em 24-06-2011 18:22, Devin Heitmueller escreveu: On Fri, Jun 24, 2011 at 5:20 PM, Stefan Richter stef...@s5r6.in-berlin.de wrote: Easier: I run Ubuntu 10.4. I run kernel 2.6.32. One of these is usually already included in the first post or IRC message from the user. Separate driver versions are only needed on platforms where drivers are not distributed by the operating system distributor, or driver source code is not released within kernel source code. Unfortunately, this doesn't work as all too often the user has Ubuntu 10.1 but I installed the latest media_build tree a few months ago. Hence they are not necessarily on a particular binary release from a distro but rather have a mix of a distro's binary release and a v4l-dvb tree compiled from source. # modprobe vivi # dmesg WARNING: You are using an experimental version of the media stack. As the driver is backported to an older kernel, it doesn't offer enough quality for its usage in production. Use it with care. Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): d3302689d697a99d565ea37c8fb9a19a1a5d0f06 [media] rc-core: fix winbond-cir issues 6337ae50f81c99efbf9fa924c9d1b8b51efbcef2 [media] rc/redrat3: dereferencing null pointer ad0fc4c9ac8bf871b7bf874b2cd34b6b65f099c7 [media] rc: double unlock in rc_register_device() vivi-000: V4L2 device registered as video0 Video Technology Magazine Virtual Video Capture Board ver 0.8.0 successfully loaded. The git changeset is a way better than a version number. Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Don't use linux/version.h anymore to indicate a per-driver version - Was: Re: [PATCH 03/37] Remove unneeded version.h includes from include/
Em 24-06-2011 18:10, Stefan Richter escreveu: On Jun 24 Devin Heitmueller wrote: Really, this is all about applications being able to jam a hack into their code that translates to don't call this ioctl() with some particular argument if it's driver W less than version X, because the driver had a bug that is likely to panic the guy's PC. Sure, it's a crummy solution, but at this point it's the best that we have got. The second best. The best that we have got is that the user runs a fixed kernel. Anyway; if this is the only purpose that this interface version¹ serves, then Mauro's subsystem-centralized solution has the benefit that it eliminates mistakes due to oversight by individual driver authors. Especially because the kind of implementation behavior changes that are tracked by this type of version datum are sometimes just discovered or documented in hindsight. On the other hand, Mauro's solution is redundant to the uname(2) syscall. Yes. That's why my initial proposal were to add some value to it by not associating it with the kernel version, but with a number that will be incremented only if the V4L2 API changes. ¹) Yes, it is still an ABI version, nothing less. With all its backwards and forwards compatibility ramifications. -- 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] Don't use linux/version.h anymore to indicate a per-driver version - Was: Re: [PATCH 03/37] Remove unneeded version.h includes from include/
Em 24-06-2011 18:04, Andy Walls escreveu: On Fri, 2011-06-24 at 14:48 -0400, Devin Heitmueller wrote: On Fri, Jun 24, 2011 at 2:34 PM, Stefan Richter stef...@s5r6.in-berlin.de wrote: If the driver version is in fact an ABI version, then the driver author should really increase it only when ABI behavior is changed (and only if the behavior change can only be communicated by version number --- e.g. addition of an ioctl is not among such reasons). And the author should commit behavior changing implementation and version number change in a single changeset. And anybody who backmerges such an ABI behavior change into another kernel branch (stable, longterm, distro...) must backmerge the associated version number change too. Of course sometimes people realize this only after the fact. Or driver authors don't have a clear understanding of ABI versioning to begin with. I am saying so because I had to learn it too; I certainly wasn't born with an instinct knowledge how to do it properly. (Disclaimer: I have no stake in drivers/media/ ABIs. But I am involved in maintaining a userspace ABI elsewhere in drivers/firewire/, and one of the userspace libraries that use this ABI.) Hi Stefan, To be clear, I don't think anyone is actually proposing that the driver version number really be used as any form of formal ABI versioning scheme. In almost all cases, it's so the application can know to *not* do something is the driver is older than X. MythTV, for example, used to use the driver version to work around old VBI bugs and MPEG encoder quirks that the older version of the driver may not have known how to handle: https://github.com/MythTV/mythtv/blob/b98d3a98e3187000ae652df5ffebe2beb5221ba7/mythtv/libs/libmythtv/mpegrecorder.cpp#L335 But for newer versions, MythTV could avoid using its own odd hacks. The bleeding edge MythTV now has most of these removed. Removing it is a good thing. Really, this is all about applications being able to jam a hack into their code that translates to don't call this ioctl() with some particular argument if it's driver W less than version X, because the driver had a bug that is likely to panic the guy's PC. Well, not even panics per se, but some thing like the VBI is broken, or the volume control doesn't work, IR blaster is works for this version, or something else stupid that is very visible to the end user. I also use the driver version for troubleshooting problem with users. I roughly know what wasn't working in what version of the cx18 and ivtv drivers. If the end user can tell me the driver version (using v4l2-ctl --log-status) along with his symptoms, it makes my life easier. Being able to efficiently help the end user is a win for both me and the end user. If you add it to MODULE_VERSION, you can get the version with: $ modinfo -F version vivi 0.8.1 Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Don't use linux/version.h anymore to indicate a per-driver version - Was: Re: [PATCH 03/37] Remove unneeded version.h includes from include/
On Jun 24 Devin Heitmueller wrote: On Fri, Jun 24, 2011 at 5:20 PM, Stefan Richter stef...@s5r6.in-berlin.de wrote: Easier: I run Ubuntu 10.4. I run kernel 2.6.32. One of these is usually already included in the first post or IRC message from the user. Separate driver versions are only needed on platforms where drivers are not distributed by the operating system distributor, or driver source code is not released within kernel source code. Unfortunately, this doesn't work as all too often the user has Ubuntu 10.1 but I installed the latest media_build tree a few months ago. Hence they are not necessarily on a particular binary release from a distro but rather have a mix of a distro's binary release and a v4l-dvb tree compiled from source. If you release out-of-kernel-source driver sources for compilation against binary kernels, and you have got users who go through this procedure, then the user can for sure tell you the SCM version of the driver. Besides, isn't this outdated practice in times where Joe Enduser can get the very latest -rc kernel prepackaged on many distributions, including ones like Ubuntu? [Sorry, I'm getting perhaps a bit off-topic.] -- Stefan Richter -=-==-== -==- ==--= http://arcgraph.de/sr/ -- 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] Don't use linux/version.h anymore to indicate a per-driver version - Was: Re: [PATCH 03/37] Remove unneeded version.h includes from include/
On Fri, 2011-06-24 at 19:16 -0300, Mauro Carvalho Chehab wrote: Em 24-06-2011 18:04, Andy Walls escreveu: On Fri, 2011-06-24 at 14:48 -0400, Devin Heitmueller wrote: On Fri, Jun 24, 2011 at 2:34 PM, Stefan Richter stef...@s5r6.in-berlin.de wrote: If the driver version is in fact an ABI version, then the driver author should really increase it only when ABI behavior is changed (and only if the behavior change can only be communicated by version number --- e.g. addition of an ioctl is not among such reasons). And the author should commit behavior changing implementation and version number change in a single changeset. And anybody who backmerges such an ABI behavior change into another kernel branch (stable, longterm, distro...) must backmerge the associated version number change too. Of course sometimes people realize this only after the fact. Or driver authors don't have a clear understanding of ABI versioning to begin with. I am saying so because I had to learn it too; I certainly wasn't born with an instinct knowledge how to do it properly. (Disclaimer: I have no stake in drivers/media/ ABIs. But I am involved in maintaining a userspace ABI elsewhere in drivers/firewire/, and one of the userspace libraries that use this ABI.) Hi Stefan, To be clear, I don't think anyone is actually proposing that the driver version number really be used as any form of formal ABI versioning scheme. In almost all cases, it's so the application can know to *not* do something is the driver is older than X. MythTV, for example, used to use the driver version to work around old VBI bugs and MPEG encoder quirks that the older version of the driver may not have known how to handle: https://github.com/MythTV/mythtv/blob/b98d3a98e3187000ae652df5ffebe2beb5221ba7/mythtv/libs/libmythtv/mpegrecorder.cpp#L335 But for newer versions, MythTV could avoid using its own odd hacks. The bleeding edge MythTV now has most of these removed. Removing it is a good thing. Really, this is all about applications being able to jam a hack into their code that translates to don't call this ioctl() with some particular argument if it's driver W less than version X, because the driver had a bug that is likely to panic the guy's PC. Well, not even panics per se, but some thing like the VBI is broken, or the volume control doesn't work, IR blaster is works for this version, or something else stupid that is very visible to the end user. I also use the driver version for troubleshooting problem with users. I roughly know what wasn't working in what version of the cx18 and ivtv drivers. If the end user can tell me the driver version (using v4l2-ctl --log-status) along with his symptoms, it makes my life easier. Being able to efficiently help the end user is a win for both me and the end user. If you add it to MODULE_VERSION, you can get the version with: $ modinfo -F version vivi 0.8.1 Well, since you mention it http://git.linuxtv.org/media_tree.git?a=blob;f=drivers/media/video/cx18/cx18-driver.c;h=9e2f870f4258665ae6093c762f752d45147a8c98;hb=staging/for_v3.1#l252 http://git.linuxtv.org/media_tree.git?a=blob;f=drivers/media/video/ivtv/ivtv-driver.c;h=0fb75524484d909af4925c3c33c9f12cf6d6519e;hb=staging/for_v3.1#l280 However, since I often must ask for the output of v4l2-ctl --log-status, which already has the version number, I never need to ask the user to run /sbin/modinfo for the version. 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: [RFC] Don't use linux/version.h anymore to indicate a per-driver version - Was: Re: [PATCH 03/37] Remove unneeded version.h includes from include/
Em 24-06-2011 19:39, Stefan Richter escreveu: On Jun 24 Devin Heitmueller wrote: On Fri, Jun 24, 2011 at 5:20 PM, Stefan Richter stef...@s5r6.in-berlin.de wrote: Easier: I run Ubuntu 10.4. I run kernel 2.6.32. One of these is usually already included in the first post or IRC message from the user. Separate driver versions are only needed on platforms where drivers are not distributed by the operating system distributor, or driver source code is not released within kernel source code. Unfortunately, this doesn't work as all too often the user has Ubuntu 10.1 but I installed the latest media_build tree a few months ago. Hence they are not necessarily on a particular binary release from a distro but rather have a mix of a distro's binary release and a v4l-dvb tree compiled from source. If you release out-of-kernel-source driver sources for compilation against binary kernels, and you have got users who go through this procedure, then the user can for sure tell you the SCM version of the driver. Yes, and this is currently provided. The dmesg will show the last 3 git commits. A developer can just use git diff or git log to discover what changed since those commits. Besides, isn't this outdated practice in times where Joe Enduser can get the very latest -rc kernel prepackaged on many distributions, including ones like Ubuntu? Perhaps, but the cost to maintain the out-of-tree driver git tree is cheap. We provide just a small building system, with a script that downloads a daily tarball with just drivers/media and the corresponding includes (and a few drivers/staging). The building system has a couple patches to allow backport compilation since 2.6.32. Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] v4l2 core: return -ENOIOCTLCMD if an ioctl doesn't exist
Currently, -EINVAL is used to return either when an IOCTL is not
implemented, or if the ioctl was not implemented.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
Documentation/DocBook/media/Makefile |1 +
Documentation/DocBook/media/v4l/func-ioctl.xml | 17 +
drivers/media/video/v4l2-ioctl.c |4 ++--
3 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/Documentation/DocBook/media/Makefile
b/Documentation/DocBook/media/Makefile
index 8cb27f3..93722da 100644
--- a/Documentation/DocBook/media/Makefile
+++ b/Documentation/DocBook/media/Makefile
@@ -117,6 +117,7 @@ ERRORS = \
EPERM \
ERANGE \
EPIPE \
+ ENOIOCTLCMD \
ESCAPE = \
-e s//\\amp;/g \
diff --git a/Documentation/DocBook/media/v4l/func-ioctl.xml
b/Documentation/DocBook/media/v4l/func-ioctl.xml
index b60fd37..0c97ba9 100644
--- a/Documentation/DocBook/media/v4l/func-ioctl.xml
+++ b/Documentation/DocBook/media/v4l/func-ioctl.xml
@@ -132,14 +132,15 @@ complete the request./para
VIDIOC-S-CTRL; ioctl to a value which is out of bounds./para
/listitem
/varlistentry
+ varlistentry
+ termerrorcodeENOIOCTLCMD/errorcode/term
+ listitem
+ paraThe application attempted to use a non-existent ioctl. This is
returned by the V4L2 core only.
+ Applications should be able to handle this error code, in order
to detect if a new ioctl is
+ not implemented at the current Kernel version. Kernel versions
lower than 3.0 returns EINVAL to
+ non-existing ioctl's./para
+ /listitem
+ /varlistentry
/variablelist
/refsect1
/refentry
-
-!--
-Local Variables:
-mode: sgml
-sgml-parent-document: v4l2.sgml
-indent-tabs-mode: nil
-End:
---
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 61ac6bf..a0a2466 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -543,12 +543,12 @@ static long __video_do_ioctl(struct file *file,
struct v4l2_fh *vfh = NULL;
struct v4l2_format f_copy;
int use_fh_prio = 0;
- long ret = -EINVAL;
+ long ret = -ENOIOCTLCMD;
if (ops == NULL) {
printk(KERN_WARNING videodev: \%s\ has no ioctl_ops.\n,
vfd-name);
- return -EINVAL;
+ return ret;
}
if ((vfd-debug V4L2_DEBUG_IOCTL)
--
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] Octopus driver status
Hi Mauro, On Friday 24 June 2011 13:57:16 Mauro Carvalho Chehab wrote: Em 24-06-2011 06:51, Oliver Endriss escreveu: Hi, On Thursday 23 June 2011 23:31:08 Sébastien RAILLARD wrote: Dear all, I'm looking at the Octopus DVB cards system from Digital Devices for a while as their system seems to be very interesting Here is link with their products: http://shop.digital-devices.de/epages/62357162.sf/en_GB/?ObjectPath=/Shops/6 2357162/Categories The good points I have found: * They support most of the common DVB standards: DVB-C, DVB-T, DVB-S and DVB-S2 * They are moderately priced * There is a CAM support with a CI adapter for unscrambling channels * They are using the now de-facto standard PCI-Express bus * The new Octopus system is using a LATTICE PCI-Express bridge that seems to be more future proof than the previous bridge Micronas APB7202A * They seem to be well engineered (Designed and manufactured in Germany as they say!) And now the doubts : * The DVB-C/T frontend driver is specific to this system and is very new, so as Devin said one week ago, it's maybe not yet production ready * The way the CAM is supported break all the existing userland DVB applications (gnutv, mumudvb, vlc, etc.) * There isn't so much information about the Digital Devices company and their products roadmap (at least in English) So, my two very simple questions to the developers who worked on the drivers (I think Oliver and Ralph did) and know the product: * How you feel the future about the Octopus driver? The drivers work fine. I am not aware of any problems. All Digital Devices cards and tuner variants are supported by the driver http://linuxtv.org/hg/~endriss/media_build_experimental ddbridge (Lattice bridge): - Octopus (all variants) - cineS2 v6 - DuoFlex S2 (stv0900 + stv6110 + lnbp21) - DuoFlex C/T (Micronas DRXK + NXP TDA18271C2) ngene bridge: - cineS2 (v4,v5), Satix S2 Dual - PCIe bridge, mini PCIe bridge - DuoFlex S2 (stv0900 + stv6110 + lnbp21) - DuoFlex C/T (Micronas DRXK + NXP TDA18271C2) For a German description, see http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/105803-aktuelle-treiber-für-octopus-ddbridge-cines2-ngene-ddbridge-duoflex-s2-duoflex-ct-sowie-tt-s2-6400 From an operational point of view, the driver is ready for the kernel. Unfortunately I did not have the time yet to clean up the coding-style. There are thousands of coding-style issues waiting to be fixed... Hi Oliver, If it is ok for you, I have here a few devices with DRXK that I'm seeking for some time to work with. I'll probably have some time this weekend for them, so I can do the CodingStyle cleanups, if it is ok for you. Just for the record: Ralph did most of the work. I just contributed some glue stuff. I'll check with Ralph, whether he has any updates pending. These should be applied before fixing the coding-style. If you could wait until next weekend, I could prepare a patch series, which you could start with. The current repository has some files at the wrong places, etc. CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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] Octopus driver status
On Friday 24 June 2011 14:44:50 Simon Liddicott wrote: Do you have a Terratec Cinergy 2400i? It belongs to the ngene family but has PLL tuners. http://linuxtv.org/wiki/index.php/TerraTec_Cinergy_2400i_DVB-T There are some drivers floating on the net that I have got to work in Ubuntu 8.04 but the current ngene drivers has moved on a long way and left it behind. Sorry, I do not have this device, and I have no plans to work on it. Terratec did not contribute in any way to the ngene driver. [1] As always, patches are welcome. CU Oliver [1] Some time ago I had a look at that driver, and found that it could not be added to the kernel, due to an GPL-incompatible proprietary license for some files. -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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
